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

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

Whether it is the Private-Key of any Public-Key algorithm as discussedin Part 1 in this series, or anypreviously negotiated shared secret between the devices, the securityof transferred data over a network depends in the secrecy of thesekeys.

To enforce additional security, some cryptographic algorithms mayalso specify a set of constant values that should not be disclosed fromthe device. These secret keys and secret values stored in the devicethat requires protection from unauthorized exposure are referred as'secret keys' in series of articles.

The secret keys are stored inside the device, some even for thelifetime of the device. Hardware and software security measuresimplemented in the device must defeat unauthorized access attempts toretrieve these secret keys. Also, there are data such as the Root CACertificate in the device that can be disclosed but should be preventedform unauthorized modification.

If the Root CA certificate could be modified, attackers could makethe device to accept any certificate by substituting a fake root CAcertificate thus defeating the purpose certificate and securecommunication. It is therefore also important that the data such asRoot CA Certificates in the device is not subjected to unauthorizedmodification.

The level of security within the device varies depending on thenature of the protected content. The need for device security is morein the case of device handling user restricted data likecopy-protected* video than in the case of user's private data likepersonal files or bank transactions.

In the case of the user's private data, this usually occurs becausethe user will suffer the direct loss on compromising such data and as aresult he/she becomes responsible for restricting physical access tothe secret keys and other secured contents stored in the device.

Also, the general implementation of secure data transfer protocolsrecommends a unique secret key for each device. Therefore if thehardware security of any device is compromised, it doesn't affect thesecurity of any other device in the network.

In the case of User restricted data, however, compromising thesecret key of a single device results in the compromise of the securityof all the copy-protected content handled by that device. Onevulnerable device can thus result in helping an unauthorized device toaccess the copy-protected content, decrypt it and distribute countlesscopies of the same.

Secure SoC (System-on-Chip)
A secure SoC (Figure 4, below )can be designed that incorporates the hardware and software supportrequired to enforce the security within the device and therebydefeating the physical attack that compromises the security of thedevice.

This Secure SoC provides physical protection to secret keys bykeeping the components like Secure ROM, which is handling the secretkeys, inside the chip. During execution time, the protected secure keyshas to be loaded to the RAM in clear text and during that time the busto the RAM can be monitored to access the secret keys.

This can be prevented by allocating buffers for secret keys orintermediate values of cryptographic operations involving secret keysin the Internal RAM of the Secure SoC. This prevents the protected keysbeing available to any bus outside the Secure SoC.

The Secure Bootloader in the Secure SoC ensures that the deviceboots up with the genuine OS or firmware with right process privileges.The MMU (Memory Management Unit) configured by the OS permits theaccess to the buffers in the Internal RAM that involves secret keyoperations only to the secure processes with special OS privileges.

In the case where the Secure ROM is limited or pre-programmed by thehardware manufacturer, the Secure ROM can be programmed with a masterkey. This master key can be used to encrypt and store the device secretkeys in the internal ROM.

Figure4. A Secure SoC provides physical protection to secret keys by keepingthe components like Secure ROM, which is handling the secret keys,inside the chip.

In ideal case of a Secure SoC, there are several condidtions thatmust be satisfied :

1) Secure ROM cannot bephysically accessed to retrieve the secret keys.

2) Buses inside the SecureSoC cannot be monitored to obtain protected data or keys.

3) Removal or replacementof any components in the Secure SoC should be impossible or shouldprevent the SoC from working.

The level of physical protection can vary depending on the value ofthe protected content. The protection can be merely tamper detection ofSoC to zeroing of all stored content in the SoC when a physical accessattempt is made.

Tamper detection protection method does not prevent an attacker fromobtaining the data from the chip but will only makes it possible toknow whether the chip has been tampered with or not. The zeroingrequires special power supply and hardware support that makes the chipmore expensive.

The NIST(National Institute of Standards and Technology) issued FIPS140-2 [9] publication specifies different levels of hardware andsoftware security requirements for device that involved in storage andtransfer of sensitive information.

Now, let's go into a bit more detail on the role of each componentin the Secure SoC: 1) ROM, 2) internal RAM and secureprocesses, 3) securebootloader and code signing, 4) encryption/decryption engine, and 5) system timing ” and how they contribute to ensuring secure storage ofsecret keys and other protected data.

Secure ROM. One method forstoring the device secret keys securely in the persistent storage of adevice is to encrypt the secret keys before storing. Thus even ifanyone managed to get the data out of persistent storage he/she willnever be able to understand the secret keys.

To encrypt any data two things are generally required, an encryptionalgorithm and a key for encryption. If any well-known algorithm likeAES is used for encryption of the secret keys, then the strength of theencryption is only as strong as the secrecy of the key used for theencryption.

Thus the same problem faced for the storage of secret keys is facedagain for the storage of the key that is used for encrypting the secretkeys. This problem is repeated unless an encryption algorithm is usedthat is known only to the device manufacturer.

If a device proprietary algorithm is used for encryption and storageof the secret keys, the security of the secret keys are only as strongas the secrecy of the algorithm.

Since the code binary is stored in clear text in the device memoryand plenty of tools for reengineering the code like 'objdump' areavailable, the chance of exposing the secret keys cannot be overlooked.

Another method to store the secret keys is to store it inside aSecure ROM. The Secure ROM resides inside the Secure SoC in the device.The hardware controller of the Secure ROM descrambles the data beforeretrieving it back from the ROM. This hardware support will prevent theunauthorized physical access to retrieve the secret key stored in theSecure ROM.

The buffers that hold the secret keys or the intermediate values ofcryptographic operations involving the secret keys are allocated in theInternal RAM of the Secure SoC. Thus the secret keys are prevented frombeing available to any bus outside the Secure SoC.

In the case where the Secure ROM is limited or pre-programmed by thehardware manufacturer, the Secure ROM can be programmed with a devicemaster key. The device master key is a key unique to each devicehardware or Secure SoC that can be further used to encrypt and storethe device secret keys in a less Secure ROM.

The possible vulnerabilities in the implementation of Secure ROMinclude:

1. The Secure ROM isphysically removed from the Secure SoC, placed it in another device andworks to retrieve the protected keys.

2. The bus between SecureROM and RAM is accessed to retrieve the protected keys.

3. Anunprivileged/unauthorized application running on the device gets accessto the API for retrieving the secret keys from the Secure ROM.

Ideally, in a properly designed Secure SoC, the first twovulnerabilities don't exist. The third vulnerability can be preventedby use of the Secure Bootloader and implementation of right processprivileges and thus not allow an unprivileged application to run andaccess the restricted memory locations of the device.

Internal RAM and Secure Processes. The buffers for secret keys or intermediate values of cryptographicoperations involving secret keys are allocated in the Internal RAM ofthe Secure SoC to prevent the secret keys being available to any busoutside the Secure SoC.

Let this memory area in the Internal RAM be called the Secure MemoryArea. Not every process should access this memory area. Only processeswith special OS privilege, Secure Process, should be able to access theSecure Memory Area. This is analogous to processes with administrativeprivilege or root privilege in an operating system.

The OS during boot up configures the memory management unit topermit access to Secure Memory Area to only the Secure Processes. It isalso important that the MMU configuration code in the OS is notmodified by an unauthorized user to get access to the secure memoryarea.

This can be ensured by the use of Secure Bootloader and code signingas discussed elsewhere in this series. The Secure Processes areconfigured to start during device boot up.

The OS should disallow any unauthorized processes to run as SecureProcess or to start a new Secure Process. This can prevent anydownloaded application, if supported by the device, to access theSecure Memory Area to read the secret keys.

The result of an operation performed by a Secure Process on thesecret keys is usually public data such as encrypted data or aPublic-Key. These output data are requires by other less privilegeprocesses to perform operation such as transmitting the output data toother device. There can be several ways of calling a Secure Process bya less privileged process.

For example, suppose the Secure Processes waits for a semaphorebefore getting the input data and start executing. The input databuffer will be a non-secure memory area. Any less privilege process canfill the input buffer and signal a Secure Process, by releasing thesemaphore, to start execution.

The Secure Process, on receiving the signal, does the correspondingcryptographic operation on the input data with the secret keys. Theoutput of the operation is placed in the non-secure memory area fromwhere the less privilege process can read the output.

Secure Boot-Loader and Code Signing. The secret keys, though protected by hardware security measure, have tobe exposed through some API's for use. It is necessary to ensure thatthe firmware of the device cannot be modified so that an unauthorizeduser can use these API's to extracts the secret keys from the device.

The firmware also contains secure critical code such as code thathandles security critical hardware configuration like Internal RAMconfiguration to specify access permissions. Any attempt on overridingthe firmware components of the device thus must be turned down. Thepresence of Secure Bootloader can ensure this.

On startup before loading the firmware code, the Secure Bootloaderchecks whether the firmware is genuine or not and prevents the devicefrom booting up if the device firmware is modified or replaced. Anexample of a Secure Bootloader implementation is shown in Figure 5 below.

Figure5. The public key and the private key are generated by the devicemanufacturer and are used for the signing and verification of thedevice firmware code. The private key has to be kept secret by thedevice manufacturer.

The Secure Bootloader resides on a write protected ROM inside theSecure SoC. Keeping Secure Bootloader in a write protected ROM ensuresthat the Secure Bootloader itself is never modified.

In addition to the general boot initialization code, the SecureBootloader contains a signature verification module of the firmwarecode and the code verification Public-Key to verify the firmware code.

The firmware code is signed using the device manufacturer's codeverification Private-Key. The Secure Bootloader, on boot up checks thevalidity of the code by verifying the signature using the codeverification Public-Key.

Though the Private-Key that used to sign the firmware code is nevershipped along with the device, it has to be kept secret by the devicemanufacturer. The compromise in the secrecy of the Private-Key thatused to sign the firmware code enables anyone, who is having access tothe Private-Key, to write and sign a code that is acceptable by theSecure Bootloader.

If the firmware of the device is non-upgradeable then the level ofsecurity in the boot loader can be enforced in much simpler methodwithout the presence of a Secure Bootloader.

In such case, writing the entire firmware in a read-only memory andconfiguring the boot loader to boot only from the read-only memory areacan prevent any unauthorized firmware component to run on the device.But in many case, non-upgradeable firmware brings too many limitationson a device.

There are files, like root CA certificate, which when modified canresult in the compromise of the device security. Such files also needto be signed along with the firmware code of the device.

There are also files specific to each device, like encrypted secretkeys or device certificates, which when modified prevents the devicefrom secure data transfer but does not compromise the security of thedevice.

The signing of these device specific files will cause overheadduring the production of the device or during the upgrade of the devicefirmware where the device manufacturer needs to sign the firmware codefor each device. Since the device security is not compromised by themodification of these files, these files can be kept in the devicewithout being signed.

Encryption and decryption engine. In many secure protocol implementations, the shared secret generated bythe Key Agreement algorithm as discussed earlier in this series is usedas a master key and the sub-keys are generated that are used for theprocess of encryption and decryption.

When used as the master key, the shared secret is stored in thedevice till expiry time as specified by the protocol and the lifetimewill be in the order of days or even months depending on the protocolused for data transfer.

But the lifetime of sub-keys will be generally small in the order ofseconds. In this case the security requirement of the shared secret ishigher and hence stored securely in the device.

However, the security requirement of the sub-keys is not thatcritical as that of the secret keys like shared secret or certificatePrivate-Keys. The sub-keys generation protocol will also be such thatit is impossible to derive the master key from the sub keys.

In such cases where the security of keys (sub-keys) used forencryption and decryption is not so critical, the encryption anddecryption engine (module) can reside outside the secure SoC.

The sub-keys are generated inside the Secure SoC and are passed tothe encryption/decryption engine outside the Secure SoC. In some otherprotocols the shared secret or secret keys itself forencryption/decryption.

In such case, the encryption/decryption engine should reside insidethe SoC to prevent the key from being available on the bus outside theSecure SoC. The encryption and decryption engine thus can be locatedinside or outside the Secure SoC depending on the security need of thekeys used for encryption and decryption.

System Timing. The digitalcertificate of a device generally comes with a validity period. Thevalidity periods varies across different protocol implementation.

Some protocols like SSL (Secure Socket Layer) specify a fixedvalidity period of a few years or decades whereas other protocols likeDTCP (Digital Transmission Content Protection) specifies infinitevalidly period for a certificate.

The system time in an embedded device will generally have interfacesto user to set or modify the system time. For certificate verificationprocess, any device should maintain a system time that is differentfrom the system time modified by a user so that users are not able tomodify the system time to force a device accept an expired certificate.It is also important that the timer keeps counting even after when thedevice is in the switched off state.

Unauthorized modification of system time is not so critical in manycases where the device handles certificates with validity periodsnumbering 20-30 yrs or more. This timeframe is sufficiently larger thanthe lifetime of many devices.

Also, the chance for root CA to update the root certificate withinthis time frame is also high. If the CA changes a root CA certificate,the devices must update the root and the intermediate CA certificatesand should acquire a new device certificate from the CA.

Next, in Part 3: ProprietaryTechnologies for secure data transfer.
To read Part 1, go to “Security needs for data transfer.”

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.