Implementing secure digital data transfer in portable handheld embedded devices: Part 1 - Embedded.com

Implementing secure digital data transfer in portable handheld embedded devices: Part 1

Embedded or handheld devices are getting increasingly connected and aremore and more involved in network communications. The users of thesedevices are now able to execute almost all the network/internetapplications that run in a PC on these devices.

These devices are also increasingly involved in transfer of securedata through public networks that needs protection from unauthorizedaccess and thus the security requirements in embedded devices havebecome critical.

Secure data falls in different categories requiring different levelsof security. Based on who wants to protect the data, the secure datacanbe partitioned into two segments: the User's private data and the Userrestricteddata.

The User's private data are those data which when its security iscompromised impacts directly on the user. A simple example ofcompromising such security is having access to a user's internetbanking password. But in case of User restricted data, it's not theuser but the content (data) provider who suffers direct loss oncompromising the security of that data. Examples of such data includedigital multimedia content such as copyrighted digital photos, audioand video contents.

Secure data not only requires protection during transfer but alsowhile handling the data at the end user devices. Vulnerability at theend user device, like easy access to the secret keys that are used toencrypt or decrypt the data, can easily turn down the entire securitymechanisms.

The protocol involved for the secure transmission of either of theabove mentioned contents through a public network uses more or less thesame techniques but the handling of the User restricted data at theuser's end involves much more care since the content is protected fromtheuser itself!

Thus an embedded device must not only incorprate methods or protocolfor secure data transfer but should also include security methods todefeat attempts of unauthorized access to secure data from the deviceitself. The security needs for an embedded device thus can beclassified into two parts:

* Security needs for data transfer, and
* Security needs within the device

The data in a public network passes through a number of untrustedintermediate points. Therefore the secure data must be scrambled insuch a way that the data will be useless or unintelligible for anyonewho is having unauthorized access to the secure data.

This can be achieved with the help of cryptographic methods such asEncryption/Decryption, Key Agreement, Digital Signatures and DigitalCertificates, which are explained below.

Data Encryption
Encryption is the process of scrambling/encrypting any amount of datausing a (secret) key so that only the recipient, who is having accessto the key, will be able to descramble/decrypt the data.

The algorithm used for the encryption can be any publicly availablealgorithm like DES (Data Encryption Standard) [2], 3DES (Triple DataEncryption Standard) [8], AES (Advances Encryption Standard) [7] or anyalgorithm proprietary to a device manufacturer.

The key is known only between the communicating devices and willtypically of length 100s of bits. If publicly available algorithms areused, the security of the transferred data totally depends on thesecrecy of the keys used for the encryption.

Sharing and maintaining the secret key between the communicatingdevices without any unauthorized entity getting access to the keys isimportant for foolproof secure data communication. These keys caneither be embedded in the device prior to the communication, exchangedoffline in a secure manner or established online using any keyagreement algorithm as explained later in this series.

The storage of the secret keys within the device is also criticalfor ensuring the complete protection of data. Security requirements forthe storage of secret keys in the device are discussed in later in thisseries.

Public-Key Key Agreement Algorithm
When there are 100's of devices in a network, sharing and maintainingsecret keys between all the devices for data encryption seemsdifficult, even unrealistic.

This is where a Key Agreement Algorithm can be useful. Using KeyAgreementalgorithm, a shared secret can be established between communicatingparties without the need for exchanging any secret keys or secretparameters online or offline. 

The key agreement algorithm is a Public-Key cryptography algorithm.Devices that use Key agreement algorithm will have a Private-Key and anassociated Public-Key. The Private-Key is generally a random number ofhundreds or few thousands of bits and the Public-Keys are derived fromthe Private-Key using the one-way function specified by the keyagreement algorithm.

One-way functions are mathematical functions in which the forwardoperation can be done easily but the reverse operation is too difficultthat it is practically impossible. The Public-Key is derived using thePrivate-Key on the forward operation of the one-way function. Thereverse operation of obtaining the Private-Key from the Public-Key istoo difficult that it is practically impossible.

Devices that need to establish shared secret between themselvesexchange their Public-Keys and public constants, if any. Both thedevices, on receiving the other devices Public-Key, perform keygeneration operation using its Private-Key to obtain the shared secret.The key agreement works in such a way that the shared secret calculatedby both the devices will be the same.

For example, assume P be the Private-Key of a device and U(P, C) tobe the Public-Key of the device. The representation U(P, C) showsthat the Public-Key of a device is derived from the Private-Key P ofthat device and some shared constants C known by all the devices takingpart in the communication.

Consider two devices A and B (Figure1, below ). assume PA and UA (PA ,C) are the Private-Key andPublic-Key of device A and PB and UB (PB ,C) are the Private-Key andPublic-Key of device B respectively. Both device exchanges theirPublic-Keys.

Device A, having got the Public-Key of B, calculates key KA =Generate_Key(PA , UB (PB , C)) and DeviceB, having got the Public-Key ofA, calculates key KB = Generate_Key(PB , UA (PA ,C))

Figure1. Devices that need to establish shared secret communications betweenone another must first exchange their Public-Keys and public constants.

The key generation algorithm 'Generate_Key' will be such that thegenerated keys at the device A and B will be the same, that is sharedsecret KA =KB =K(PA , PB , C).

It is impossible for any middleman, who only has access to thePublic-Keys, UA (PA , C) and UB (PB , C), to obtainthe shared secret Kunless he/she has got the access to the Private-Key, PA or PB of any ofthe communicating device. Examples of key generation algorithms are DH(Diffie Hellman) [4] and ECDH (Elliptic Curve Diffie Hellman) [5].

In the key agreement algorithm the Private-Key used is a secret keyand should not be shared with any other devices in the network,including to the device with which it is communicating. It is only theagreed shared secret key that is known between the communicatingdevices.

It must also be ensured that the Private-Key is not disclosed fromthe device. The safe storage of the Private-Key of key agreementalgorithm on the device is thus important. Security requirements forsafe storage of secret keys are discussed later in this series.

Digital Signature
The device in a network may be communicating with an unknown or lessfamiliar device located 100s of kilometers apart. The communication mayalso require routing through many intermediate points.

During the Key Agreement process,in order to establish a secret key,anymiddleman can substitute a device's Public-Key for its Public-Key andthus establish a shared secret with the device.

In order to establish shared secrets by using the key agreementalgorithm, it is important for device to receive an authenticatedPublic-Key from the peer. For authenticated exchange of Public-Key,Digital Signature and Digital Certificates are used.

Figure2. A device in a network wanting to establish secure communicationswith an unknown or less familiar device apart must share secrets usingthe key agreement algorithm in order to receive an authenticatedPublic-Key from the peer.

Digital signaturing is a Public-Key method to verify theauthenticityof a received data from the peer. In Digital Signature, as in the KeyAgreement algorithm, a device uses a pair of keys, 'Sign Private-Key'and 'Sign Public-Key'.

Only the device knows its Sign Private-Key whereas the SignPublic-Key is distributed to all the communicating devices. A devicesigns the message using a signatures algorithm with its SignPrivate-Key to generate a signature. Any device that has got theaccess to the Sign Public-Key of the signed device can verify the datawith the signature using the signature verification algorithm.

If any third party modifies the data or signature, the verificationfails. Since only the signed device knows its Sign Private-Key, it willbe impossible for any other device to forge the signature. Examples ofDigital Signature algorithms are RSA [3], DSA (Digital SignatureAlgorithm) [2] or ECDSA (Elliptic Curve Digital Signature Algorithm)[5].

Digital Certificate
Even while using the digital signature algorithm, the 'Sign Public-Key'from a peer device has to be obtained by using an authenticated way toensurethe authenticity of a received message. For key agreement or digitalsignature the authenticated transfer of Public-Key in a large networkis difficult and often not possible without a centralized trustedauthority.

This centralized authority is trusted by all the devices in thenetwork. This authority is generally known as trusted CertificateAuthority or CA. The CA signs the Public-Keys of devices along with thedevice ID using the CA's Private-Key to generate the signature.

The CA signed data of a device (Public-Key, IDs etc.) along withthe signature arranged in a standard format is called as a certificate.Certificates are issued by the CA to all devices taking part in thecommunication. Any device, having the CA's Public-Key installed, canverify the authenticity of the received certificate and thus thePublic-Key of the peer device. One popular certificate format is X.509[6].

To obtain its certificate, a device requests the certificatefrom the CA by sending its Public-Key, unique IDs and otherinformation as required by the CA. The CA usually does some backgroundcheck to ensure the device is not hostile before issuing thecertificate. The certificate obtained bya device is rarely changed and the process of obtaining a digitalcertificate for an embedded device is usually done offline.

Once the communicating devices obtain their certificates from theCA,they exchange their respective certificates in order to establish asharedsecret between themselves. Any device on receiving a peer certificateverifies it using theCA's Public-Key. Since the CA Public-Key is common to all the devicestaking part in the communication and is never changed, it can bepre-installed on all the devices in a network generally through anumber of offlinetrusted methods.

Once a peer authenticates the device certificate, the device can usethe Public-Key in the certificate to sign any message send by thedevice to the peer to prove the messages authenticity. The CA may bedifferent for different networks and for different communicationprotocol.

Certificate Hierarchy
As the number of devices taking part in the secure communicationincreases and the location of these devices is distributed overdifferent parts of the world, a single certificate authority may notsuffice to issue and maintain certificates for all such devices.The use of a Certificate Hierarchy is the best way to deal with thissituation..

In Certificate Hierarchy, there is a Trusted Root CA that will grantpermission to other CAs to allow them to issue certificates to thecommunicating devices.The Root CA will issue the certificate for the respective intermediatecertificate authority.

An intermediate CA will issue certificates to the devices. Inaddition to issuing certificates to the devices, the intermediate CA'salso give its certificate (issued by root CA) to the devices.There can be multiple levels of certificate hierarchy in which theintermediate CA's will grant permission to other CAs to issuecertificate to the communicating devices.

If a device obtains a certificate from an intermediate CA, it notonly receives its own device certificate but also the certificate ofthe intermediate CA, which is issued by the root CA. If there aremultiple levela of intermediate CAa above the CA that issuedcertificateto the device, the device will receive certificate of all intermediateCA's up to the root CA.

During a secure communication a device may ask all the intermediatecertificates from its peers for successful verification of the receiveddevice certificate.

Example: Key Agreement algorithm
An example of key agreement protocol using digital certificates anddigital signatures is shown in Figure3 below. A single certificate hierarchy is assumed in thisexample.

Figure3. Before establishing secure connections to a network, a device needsto acquire the device certificate from the Certification Authority (CA).

Before connecting to the network, a device acquires a devicecertificate from the CA. The certificate will have a 'Sign Public-Key'and the device will have a 'Sign Private-Key' corresponding to the SignPublic-Key in the certificate stored securely in the device to preventit from disclosure.

The Sign Public-Key and Sign Private-Key can be of any digitalsignature algorithms such as RSA or DSA. The Sign Private-Key can beused to sign any data sent by the device to prove the authenticity ofits data.

For key agreement, the device uses any key agreement algorithms likeDH or ECDH. The device generates a Public-Key and a Private-Key pairfor key agreement algorithm. Let it be 'KeyGen Public-Key' and 'KeyGenPrivate-Key'.

The device signs the KeyGen Public-Key with the Sign Private-Keythat corresponds to the Sign Public-Key in the certificate. Oncesigned, the device sends the KeyGen Public-Key, its signature and itsdevice certificate to the peer device.

Similarly the device receives these sets of data from the peerdevice. On receiving the KeyGen Public-Key, signature and devicecertificate from the peer device, the device verifies the signature ofthe KeyGen Public-Key with the Sign Public-Key in the peer device'scertificate.

The device then verifies the peer device's certificate using theroot CA certificate stored in the device. Once the verificationprocesses are successfully completed, the device proceeds with the keygeneration algorithm to obtain a shared secret using the device'sKeyGen Private-Key and peer device's KeyGen Public-Key.

The same process also takes place at the peer device and the sharessecret generated by both the devices will be the same. The certificatePrivate-Key and the generated shared secret are stored inside a devicepersistent memory and needs protection from disclosure.

The KeyGen Private-Key is also not disclosed but is valid only tillthe shared secret generation and is generally disposed after the sharedsecret process is over. The KeyGen Private-Key is thus never stored.

Next in Part 2: Security needswithin the device

Anoop MS is a Senior Engineer at Tata Elxsi Ltd, India. He is anengineering graduate in Information Technology and has been associatedwith Tata Elxsi for 4 years. He has experience in the field of embeddednetwork security that includes algorithms such as DH, RSA, DSA and ECCand protocols such as DTCP and DTV onditional Access security. He canbe contacted at anoopms@tataelxsi.co.in.

References
[1] Alfred J. Menezes, Paul C.van Oorschot and Scott A. Vanstone, Handbook of Applied Cryptography,CRC Press, 1996
[2] FIPS PUB 186-2, DigitalSignature Standard (DSS), January 2000, Available at http://csrc.nist.gov/publications/
[3]
RSA Laboratories, PKCS#1 v2.1: RSACryptography Standard, June 2002.
[4] RFC 2631, Diffie-HellmanKey Agreement Method, June 1999, Available at http://tools.ietf.org.
[5] Certicom, Standards for Efficient Cryptography, SEC 1: EllipticCurve Cryptography, Version 1.0, September 2000, Available at http://www.secg.org/download/.
[6] ITU, Recommendation X.509,Available at http://www.itu.int/rec
[7] FIPS 197, AdvancedEncryption Standard (AES), November 2001, Available at http://csrc.nist.gov/publications.
[8] NIST, Recommendation forthe Triple Data Encryption Algorithm (TDEA) Block Cipher, May 2004,Available at http://csrc.nist.gov/publications.
[9] FIPS 140-2, Securityrequirements for cryptographic modules, May 2001, Available at http://csrc.nist.gov/publications.
[10] OpenCable, OpenCableSystem Security Specification, October 2006, Available at http://www.cablelabs.com/.
[11] DTLA, Digital TransmissionContent Protection Specification Volume 1 (Informational Version),October 2007, Available at http://www.dtcp.com/data/.
[12] Anoop MS, Public KeyCryptography ” Applications algorithm and mathematical explanations,May 2007, Available at http://msitbox.blogspot.com/.
[13] Anoop MS, Elliptic CurveCryptography – An implementation guide, May 2007,Available at http://msitbox.blogspot.com.
[14] Openssl.
[15] Certicom.
[16] RSA Laboratories.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.