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

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

Proprietary security modules are implemented on some devices for securedata transfer between compliant devices. The modules can be some or allof the modules mentioned in Part 1, such asEncryption/Decryption, Key Agreement, Digital Certificate or DigitalSignature.

Proprietary technologies implemented in a device are usually keptsecret to enforce additional security for data transferred between thedevices. It is therefore incumbent on the device manufacturer not todisclose the proprietary technology, from or outside the device, andthereby compromising the security enforced by their usage.

The device manufacturer should find a method to store the softwaremodule in the device so that the secrecy of the technology is notcompromised from the device. Code (Binary image) of these proprietarytechnology software modules usually will be in clear text inside thedevice.

Thus, if someone gain access to the code in the device it may beeasy to extract and understand the implementation of the softwaremodule with the help of code reengineering tools like “objdump.”

In this case, the device must prevent access to retrieve the code byplacing it inside Secure SoC or encrypting and storing it using asecret key known only to the device manufacturer.

If the code is stored encrypted, the boot loader of the device mustsupport the decryption and loading of the code during execution and thesecret key used for encryption and decryption of the code can be storedin the device by the methods specified in Part 2.

A proprietary technology can be either a device manufacturerspecific or a standard specific. In the case of device manufacturerspecific technology, secure data transfer can happen only between thedevices of same manufacturer. One example of this is the Apple iPodmusic player.

Apple can use their proprietary technology for secured transfer offiles between their compliant devices or applications like iPod, iTunesand iTunes Store. Since the devices are from a single manufacturer,keeping the proprietary technology secret within the devicemanufacturer seems to be practically possible.

If the proprietary technology is specified by a standard body, itcan be used to enforce additional security between devices fromdifferent manufacturers. In this case, the standard body will disclosethe technology to the device manufacturer on an agreement, usuallylegal, to not to disclose the technology.

Examples of such technologies are M6 encryption technology used inDTCP [11] and the DFAST scrambling algorithm used in OpenCable'sCableCARD-Host interface protocol [10].

Maintaining the secrecy of the technology becomes more and moredifficult as the number of manufacturer to whom the technology iscirculated increases. As the number of manufacturers increases, thesecurity provided by these technologies becomes minimal or evennegligible. In this case it is therefore important that the security ofdata transfer of such device does not rely only on the secrecy of theseproprietary technologies.

Revocation List
Though the security measures as explained in Part 1 are used for securestorage of secret keys in the device, the chances of an intruderretrieving it cannot be ruled out completely. In devices with only'tamper evident' security measures, it is possible to retrieve thesecret keys from the device's Non Volatile Memory but with physicaltampering of the device.

Generally each device will have a separate set of secret key so thatcompromising one devices secret key doesn't compromise the securityothers. But in the case of devices handling copy-protected digitalmultimedia content through network, compromising the secret key of asingle device results in the compromise of the security of all thecopy-protected content handled by that device.

One vulnerable device can thus results in helping an unauthorizeddevice to access the copy protected content, decrypt it and distributecountless copies of the copy protected content.

If came to notice, a broadcaster can prevent such device tocommunicate with other devices in the network to get the copy protectedcontent by adding the device ID in a list called as the revocationlist. All trusted devices would have the access to revocation list fromthe broadcaster and will stop communicating with the device whosesecurity is compromised.

Keys/certificate handling duringdevice manufacture
In many cases, the different hardware and software components in anembedded device are supplied by different vendors. The hardware vendorsprovide the hardware component and the associated drivers for thedevice whereas the software vendor provides the software components.

The device manufacturer or the deice vendor assembles these hardwareand software components to make the product, which is marketed with anaim of attaining revenue. The secret key for each device has to beloaded in to the device during manufacture.

It is usually is in the interest of the device vendors to protectthe secret keys of devices and therefore the device vendors may refrainfrom sharing the secret keys with different hardware and softwarevendors.

But at least some part of the software has to use the shared secretand also as explained in Part 2, the device need hardwaresupport to store the secret key securely in the device.

With the support of hardware and software vendors, the devicemanufacturer can store secret keys securely in the device, notdisclosing it to the hardware and software vendor. There are twomethods to handle the secret keys during production of a device.

1. The hardware vendorsupplies hardware with write-protected Secure ROM, pre-programmed witha unique random number for each device or for a set of devices. Thisrandom number can be used as a hardware master key to encrypt devicesecret keys.

2. The hardware vendorsupplies hardware with programmable Secure ROM that can be programmedby the device manufacturer with device secret keys.

Figure6. Handling of secret keys when the hardware vendor supplies thehardware with preprogrammed hardware key.

In the first case, where the hardware comes with a pre-programmedrandom number inside the Secure ROM, the random number acts as ahardware key or a master key that can be used to encrypt the secretkeys of the device.

The software vendor provides software methods/code toencrypt/decrypt secret keys using the hardware key. The devicemanufacturer can use the encryption method to encrypt and store thesecret keys inside the device using the hardware key.

The decryption method will be the part of device firmware that goesalong with the device to decrypt and use the stored secret keys usingthe hardware key. In case 2 where the hardware comes with programmableSecure ROM, the hardware vendor also supplies the software module ordrivers to program/write the Secure ROM with the keys.

The software vendor or the device vendor now will have theflexibility to decide whether to store the secret keys or a master keyto encrypt the secret keys to be stored in the Secure ROM.

Usually the device certificates of each device will be different.Since the device certificate and the encrypted secret keys aredifferent for each device, these will not be code-signed along with thefirmware as discussed earlier in this series.

Otherwise the device manufacturer needs to sign (using any softwareprovided by the software manufacturer) the firmware code for eachdevice. The device manufacturer will load the device certificate orencrypted keys for each device on the ROM location as specified by thesoftware vendor. The certificate handling software component loads thecertificate for processing from the specified location.

The root CA certificate is unique for all the devices communicatingusing the same protocol and its unauthorized modification orsubstitution results in compromise of device security, the root CAcertificate is code-signed along with the firmware code.

Conclusion
Currently available security measures for the secure transfer of databetween two devices are matured enough to defeat any third partyattempts to decrypt and gain access to the protected content.

However the security measures available to protect stored securedata, like secret keys, within a device are not yet foolproof. A tamperresistant protection mechanism in a device may require hardwarecircuits to 'zero'ise the secret keys when a physical attack is made onthe Secure SoC.

The more the hardware security measures implemented in a device toprotect its secret keys and other secure data, the more costly thedevice will be. Thus the hardware security measures implemented in thedevice are a trade of between the cost of implementation and the costof the data protected.

<> Achieving a cost effective yet foolproof method to protect thesecret keys and secure data within the device will be a boon to theowner of the contents that needs security, especially to the contentprovider of copy-protected digital contents.

To read Part 1, go to “Security needs for data transfer.”
To read Part 2, go to “Security needs within 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, Handbookof 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.