Deciphering phone and embedded security - Part 4: Ideal platform for next-generation embedded devices

The problem with the previous flow described is that even though it adds sufficient security by verifying the digital signature during boot that is hard to tamper or change, the software image is still always in the clear and accessible.

Figure 2 shows the concept of image authentication using encrypted boot. Under the build environment, the software image is encrypted using symmetric cryptography (e.g., AES) with a randomly generated "secret key". An encrypted image is stored in external Flash along with key blob.

The secret key is encrypted with another random key that is unique to every device and gets stored as Key blob in the external memory. It is important to add more salt or randomness to the key that is used to encrypt the secret key making it extremely difficult to de-cipher.

The resultant key (shown as "OTP Key" in Figure 2) that is finally used to encrypt the secret key should only be available to the device internally and must not be accessible; otherwise its purpose is defeated. During the device boot facilitated by internal ROM (that is not accessible anyway), key blob is decrypted using Symmetric Cryptography (e.g., AES) to recover the secret key that is finally used to decrypt the encrypted software image.

NOTE: The encrypted boot technique would still include signature generation and verification (not shown in the figure).

Security during external Bootloader loading
Part II of this series looked at some ways that hackers fool or trick the phone to make a ROM bootloader think that it has an empty flash Bootloader. One technique described was to short-circuit flash power to ground via Testpoint. This temporarily disrupts power to the flash chip, allowing ROM bootloader to run an external bootloader on the phone thus bypassing any security checks allowing complete visibility of almost anything including ESN and IMEI, as well as EEPROM and any valid keys.

This can be easily avoided by allowing only a signed external Bootloader to be loaded, thus ensuring that there exists no means to manipulate/load external image from non-trusted sources with the external Bootloader always subjected to signature verification.

In addition, remember to always follow this rule:

"Security at any point should never be reduced but only increased".

For example if a system allows JTAG access with different security levels (no security to max security), the system should allow only security-level changes until and unless the above statement holds good or else assume the system is vulnerable.

At the end of the day, there is no general rule or set of guidelines to ensure the system is un-hackable. Just like there is no free security, there is no full security. Rather, what can be ensured is to increase the cost of attack by deploying or implementing techniques like the ones mentioned in this article so that the system may be considered "secure" if the hack involves a reasonable amount of money and time with an acceptable risk level.

For more articles like this and others related to designing for the embedded Internet, visit Embedded Internet Designline and/or subscribe to the biweekly Embedded Internet newsletter (free registration).