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

[Part 1 covers the general Android architecture, including a look at the basic Android platform and the associated framework, as well as commonly used terminology like "rooting" and "flashing." Part 2 takes a deep dive into what really happens at the hardware level during an unlock operation, and tricks that hackers use to fool or bypass bootloaders and install custom ROMs. Part 3 covers various flavors of bootloaders that are offered by the manufacturer to provide levels of protection/security and the way some of them get compromised.]

This is the fourth article in a series and the final one; the first three articles focused on understanding hardware and software aspects of the Android/open system, associated components, along with how hackers bypass security mechanisms to unlock phones as well as defeat security mechanisms in order to get a root access and install custom ROM to customize a phone to suit their needs.

Due to the open nature of Android OS, manufacturers will always be under pressure to provide a mechanism that will allow Android developers to install custom ROMs, which is one of the main attractions for many developers adopting Android. On the other hand, this will always keep a check on security measures that are deployed to be able to meet the best of both the worlds (enough security to protect the consumers that will never customize their phone versus capability to unlock and load custom ROM for developers who wants to customize their phones) versus what could have been done further to strengthen security measures and avoid manipulations.

Leveraging the security solutions described earlier in this series, let's apply them to embedded products other than mobile phones, that do not have this manufacturer dilemma and are mainly concerned with providing reasonable security.

Authenticated Boot
A secure system's foundation should consist of a hardware platform and critical code that executes on that platform. On-chip ROM could be used to verify the authenticity and integrity of the critical code that controls the overall operation of the system.

The boot process gains control of the system immediately after reset by executing known boot code that is resident in the on-chip ROM. After verifying the authenticity of the Bootloader residing in external memory (i.e. NOR or NAND Flash) the boot process uses established cryptographic techniques to validate the authenticity and integrity of the operating system code and data in external memory.

The Authenticated boot in the system boot ROM protects the platform from executing unauthorized software (malware) during the boot sequence. Figure 1 shows the process of Authenticated boot.

The flow relies on digital signatures which are created using a Secure Hash Algorithm (SHA) method and a Public Key Crypto system (e.g., RSA). A Public-Private key pair is generated using a secure build environment. Under the build environment, software image is hashed and signed using private key. This creates a digital signature that along with the image is stored in the external Flash as shown in the figure.

The signature verification process is followed during device boot as part of authenticated boot in the on-chip ROM. Reference Hash is calculated by Asymmetric decryption using Public key and compared with Hash generated from the image. If the contents of the software image have been modified in any way, the two digests will not match and the verification will fail.

Also note that it would further strengthen the security if Hash of the public key is stored in on-chip fuses or one time programmable memory. This would ensure that if a hacker manages to tamper with the signature and installs corresponding matching public key, verification will still fail since it will compare the Public key hash stored in one time programmable memory (OTP) with the Hash generated from the public key stored in the image.

There are other implications on Certificate revocation that need a new public key to be installed, but that is outside the scope of this paper.

The flow described shares a lot of similarity with security implemented on the latest phones that come with a signed Bootloader. The next section shows another layer of protection with encrypted boot.