High Security HS-Device

[Mario]

Hi

Section 26.1.1 of the AM335x Technical Reference Manual (TRM) states:

This device has two types of production devices: a high-secure (HS) device and a general-purpose (GP) device. The fundamental difference between these two types of production devices is the approach to secure booting. …

Are high-secure variants of OSD335x available too?

Thanks,
Mario

[Erik Welsh]

Mario,

Unfortunately, we do not offer a high-secure variant of the OSD335x.   The AM335x inside the OSD335x family is a general purpose (GP) processor and does not support the TI secure boot flow nor the Trustzone extensions within the Cortex A8.  In order to achieve secure boot, you must have external circuitry, i.e. a TPM (Trusted Platform Module) and secure NOR flash.  You can find these components on the OSD3358-SM-RED (https://octavosystems.com/octavo_products/osd3358-sm-red/).

If you look at the AM335x Linux boot process (https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/osd335x-lesson-2-linux-boot-process-with-the-osd335x/), you can see that there are 4 main components: ROM Bootloader, Secondary Program Loader (SPL), U-Boot, and Linux kernel.  Given that the ROM bootloader is read-only and cannot be modified, from a security perspective, you only need to validate the integrity of the other pieces (depending on the application, you may or may not want to verify the integrity of the file system or a piece of the file system).  Unfortunately, the ROM Bootloader does not perform an integrity check (i.e. signature verification) of the SPL.  Therefore, in order to have a hardware-based root of trust, you must make the SPL read-only and un-modifiable. The easiest way to do this is to use a small SPI based flash that has a one time, non-reversable lock, which is what has been included on the OSD3358-SM-RED board (see the “Security and write protection” sections of the flash memory datatsheet). Once the SPL has verified the integrity of U-Boot using the TPM to verify the signature, you can use a secure version of U-Boot to continue the chain of trust for secure boot.

 

In general, microSD/SD cards are not flexible enough to implement the above scheme. However, if you are able to make the entire microSD card un-modifiable (i.e. write protected) and only use a RAM disk or a secondary memory for things that need to be written, then you would not need to implement the SPL in the SPI boot flash. A couple of resources that you can look at to help with secure boot:

 

TPM datasheet and capabilities:

• http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8883S-TPM-AT97SC3205T-Datasheet-Summary.pdf  
• https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2014.pdf

BeagleBone CryptoCape:

• https://www.sparkfun.com/products/retired/12773  (see Documents section)
• https://cryptotronix.com/products/cryptocape/

Secure U-Boot:

• https://github.com/theopolis/u-boot-sboot 

Cryptographic cores within the AM335x:

• http://processors.wiki.ti.com/index.php/Cryptography_Users_Guide
• http://processors.wiki.ti.com/index.php/AM335x_Crypto_Performance
• https://datko.net/2013/10/03/howto_crypto_beaglebone_black/?

Blogs describing process of securing U-Boot:

• https://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html

 

[Mario]

Thanks for your fast and detailed answer!

If I understand correctly, one could still break in by exchanging the secure NOR device or selecting another boot device via SYSBOOT pins?

I also wonder if an AM335x HS-device could simply be replaced by a GP-device in order to bypass verification of the SPL, assuming that both variants are pin-to-pin compatible.

Well, I’m new to the topic and maybe I miss something.

[Erik Welsh]

Mario,

You are correct. The above scheme with the secure NOR does not provide security against physical attacks.

One way you can counter replacing a HS device with a GP device is to use encryption on a portion or all of the boot image with a secret known only to the device. Therefore, the boot image not only has to be authenticated but also some of it must be decrypted in order to be executed. If you are interested in security, there are a number of different books and websites on the fundamentals of encryption, authentication, etc. that are very interesting. It is a fun topic to dive into.

[Author]

Posts