Implementing secure digital data transfer in

portable handheld embedded devices: Part 3

Anoop MS, Tata Elxsi Ltd. India
10/15/2008 12:13 AM EDT
This three part tutorial provides an overview of the end hardware and software security requirements
in an embedded device involved in secure digital data transfer and how to prevent a variety of
possible attacks. Part 3:Proprietary Technologies for secure data transfer. Proprietary security
modules are implemented on some devices for secure data transfer between compliant devices. The
modules can be some or all of the modules mentioned in Part 1, such as Encryption/Decryption, Key
Agreement, Digital Certificate or Digital Signature.
Proprietary technologies implemented in a device are usually kept secret to enforce additional
security for data transferred between the devices. It is therefore incumbent on the device
manufacturer not to disclose the proprietary technology, from or outside the device, and thereby
compromising the security enforced by their usage.
The device manufacturer should find a method to store the software module in the device so that the
secrecy of the technology is not compromised from the device. Code (Binary image) of these
proprietary technology software modules usually will be in clear text inside the device.
Thus, if someone gain access to the code in the device it may be easy to extract and understand the
implementation of the software module with the help of code reengineering tools like "objdump."
In this case, the device must prevent access to retrieve the code by placing it inside Secure SoC or
encrypting and storing it using a secret key known only to the device manufacturer.
If the code is stored encrypted, the boot loader of the device must support the decryption and loading
of the code during execution and the secret key used for encryption and decryption of the code can
be stored in the device by the methods specified in Part 2.
A proprietary technology can be either a device manufacturer specific or a standard specific. In the
case of device manufacturer specific technology, secure data transfer can happen only between the
devices of same manufacturer. One example of this is the Apple iPod music player.
Apple can use their proprietary technology for secured transfer of files between their compliant
devices or applications like iPod, iTunes and iTunes Store. Since the devices are from a single
manufacturer, keeping the proprietary technology secret within the device manufacturer seems to be
practically possible.
If the proprietary technology is specified by a standard body, it can be used to enforce additional
security between devices from different manufacturers. In this case, the standard body will disclose
the technology to the device manufacturer on an agreement, usually legal, to not to disclose the
technology.
Examples of such technologies are M6 encryption technology used in DTCP [11] and the DFAST
scrambling algorithm used in OpenCable's CableCARD-Host interface protocol [10].
Maintaining the secrecy of the technology becomes more and more difficult as the number of
Pgina 1 de 4
11/04/2012 http://www.eetimes.com/General/PrintView/4008133
manufacturer to whom the technology is circulated increases. As the number of manufacturers
increases, the security provided by these technologies becomes minimal or even negligible. In this
case it is therefore important that the security of data transfer of such device does not rely only on the
secrecy of these proprietary technologies.
Revocation List
Though the security measures as explained in Part 1 are used for secure storage of secret keys in the
device, the chances of an intruder retrieving it cannot be ruled out completely. In devices with only
'tamper evident' security measures, it is possible to retrieve the secret keys from the device's Non
Volatile Memory but with physical tampering of the device.
Generally each device will have a separate set of secret key so that compromising one devices secret
key doesn't compromise the security others. But in the case of devices handling copy-protected
digital multimedia content through network, compromising the secret key of a single device results
in the compromise of the security of all the copy-protected content handled by that device.
One vulnerable device can thus results in helping an unauthorized device to access the copy
protected content, decrypt it and distribute countless copies of the copy protected content.
If came to notice, a broadcaster can prevent such device to communicate with other devices in the
network to get the copy protected content by adding the device ID in a list called as the revocation
list. All trusted devices would have the access to revocation list from the broadcaster and will stop
communicating with the device whose security is compromised.
Keys/certificate handling during device manufacture
In many cases, the different hardware and software components in an embedded device are supplied
by different vendors. The hardware vendors provide the hardware component and the associated
drivers for the device whereas the software vendor provides the software components.
The device manufacturer or the deice vendor assembles these hardware and software components to
make the product, which is marketed with an aim of attaining revenue. The secret key for each
device has to be loaded in to the device during manufacture.
It is usually is in the interest of the device vendors to protect the secret keys of devices and therefore
the device vendors may refrain from sharing the secret keys with different hardware and software
vendors.
But at least some part of the software has to use the shared secret and also as explained in Part 2, the
device need hardware support to store the secret key securely in the device.
With the support of hardware and software vendors, the device manufacturer can store secret keys
securely in the device, not disclosing it to the hardware and software vendor. There are two methods
to handle the secret keys during production of a device.
1. The hardware vendor supplies hardware with write-protected Secure ROM, pre-programmed with
a unique random number for each device or for a set of devices. This random number can be used as
a hardware master key to encrypt device secret keys.
2. The hardware vendor supplies hardware with programmable Secure ROM that can be
programmed by the device manufacturer with device secret keys.
Pgina 2 de 4
11/04/2012 http://www.eetimes.com/General/PrintView/4008133
In the first case, where the hardware comes with a pre-programmed random number inside the
Secure ROM, the random number acts as a hardware key or a master key that can be used to encrypt
the secret keys of the device.
The software vendor provides software methods/code to encrypt/decrypt secret keys using the
hardware key. The device manufacturer can use the encryption method to encrypt and store the
secret keys inside the device using the hardware key.
The decryption method will be the part of device firmware that goes along with the device to decrypt
and use the stored secret keys using the hardware key. In case 2 where the hardware comes with
programmable Secure ROM, the hardware vendor also supplies the software module or drivers to
program/write the Secure ROM with the keys.
The software vendor or the device vendor now will have the flexibility to decide whether to store the
secret keys or a master key to 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 are different for each device, these will not be code-signed along with the
firmware as discussed earlier in this series.
Otherwise the device manufacturer needs to sign (using any software provided by the software
manufacturer) the firmware code for each device. The device manufacturer will load the device
certificate or encrypted keys for each device on the ROM location as specified by the software
vendor. The certificate handling software component loads the certificate for processing from the
specified location.
The root CA certificate is unique for all the devices communicating using the same protocol and its
unauthorized modification or substitution results in compromise of device security, the root CA
certificate is code-signed along with the firmware code.
Conclusion
Currently available security measures for the secure transfer of data between two devices are
matured enough to defeat any third party attempts to decrypt and gain access to the protected
content.
However the security measures available to protect stored secure data, like secret keys, within a
device are not yet foolproof. A tamper resistant protection mechanism in a device may require
hardware circuits to 'zero'ise the secret keys when a physical attack is made on the Secure SoC.
The more the hardware security measures implemented in a device to protect its secret keys and
Figure 6. Handling of secret keys when the hardware vendor supplies the
hardware with preprogrammed hardware key.
Pgina 3 de 4
11/04/2012 http://www.eetimes.com/General/PrintView/4008133
other secure data, the more costly the device will be. Thus the hardware security measures
implemented in the device are a trade of between the cost of implementation and the cost of the data
protected.
<> Achieving a cost effective yet foolproof method to protect the secret keys and secure data within
the device will be a boon to the owner of the contents that needs security, especially to the content
provider 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 an engineering graduate in
Information Technology and has been associated with Tata Elxsi for 4 years. He has experience in
the field of embedded network security that includes algorithms such as DH, RSA, DSA and ECC
and protocols such as DTCP and DTV onditional Access security. He can be 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, Digital Signature Standard (DSS), January 2000, Available at
http://csrc.nist.gov/publications/
[3] RSA Laboratories, PKCS#1 v2.1: RSA Cryptography Standard, June 2002.
[4] RFC 2631, Diffie-Hellman Key Agreement Method, June 1999, Available at http://tools.ietf.org.
[5] Certicom, Standards for Efficient Cryptography, SEC 1: Elliptic Curve 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, Advanced Encryption Standard (AES), November 2001, Available at
http://csrc.nist.gov/publications.
[8] NIST, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, May
2004, Available at http://csrc.nist.gov/publications.
[9] FIPS 140-2, Security requirements for cryptographic modules, May 2001, Available at
http://csrc.nist.gov/publications.
[10] OpenCable, OpenCable System Security Specification, October 2006, Available at
http://www.cablelabs.com/.
[11] DTLA, Digital Transmission Content Protection Specification Volume 1 (Informational
Version), October 2007, Available at http://www.dtcp.com/data/.
[12] Anoop MS, Public Key Cryptography " Applications algorithm and mathematical explanations,
May 2007, Available at http://msitbox.blogspot.com/.
[13] Anoop MS, Elliptic Curve Cryptography - An implementation guide, May 2007, Available at
http://msitbox.blogspot.com.
[14] Openssl.
[15] Certicom.
[16] RSA Laboratories.
Pgina 4 de 4
11/04/2012 http://www.eetimes.com/General/PrintView/4008133