One-Time-Programmable Memories For IoT Security

Security in the IoT space is an issue of major concern. Hackers are attacking IoT devices across all layers of the infrastructure, from the application layer down to protocol, to the physical and deep into the IoT devices.

I intend to focus on vulnerability prevention for IoT devices at the lowest level: memory structure and key storage. I conclude with indicating highly important features aimed to impede the detection of content that few OTP memory providers implement in their products.

The Root of Trust

The fundamental and primary level of security in IoT devices reside in the “Root of Trust” (RoT) as the origin of a “Secure Boot” process, a boot performed on instantly verified (hence secure) firmware and software.

The RoT is “Root” because it is the very first code that the MCU in the IoT device executes at power-up or after a hard reset. It is executed prior to any other code, including BIOS and operating system. Moreover, RoT is “of Trust” because:

• It is the only inherently trusted code. It is written by the IoT manufacturer in embedded non-volatile memory (eNVM), including ROM, OTP or Flash. The eNVM is then made write protected, therefore non-modifiable by external attacks.
• Prior to the execution of each and every code that follows, a key-based verification (decryption) of integrity and authenticity for that code takes place to ensure the code can be trusted. Such a chain of verifications constitutes the “Chain of Trust.”

The signature: Integrity and Authenticity verification

Let’s see how the verification of integrity and authenticity of codes work. To understand, it is necessary to remember how executable codes are hashed and signed to guarantee authenticity (the certainty of the originator) and integrity (the code was not tampered).

Before deploying the code to the field through the proper channels, the originator of the code produces a digital signature of the code. It does so by generating a unique “digest” for that code through a hashing algorithm, like SHA-2 or the newer SHA-3. Then, there are two mainstream methods for key encryption:

1. Asymmetric encryption method: with RSA or ECC algorithms for cryptography the originator produces two keys, one private (secretly and securely held by the originator) and one public that will be stored in the IoT. The originator will then generate a signature of the code by encrypting the digest with the private key. This signature will then be appended to the code itself prior to deployment to the field.
2. Symmetric encryption method: with AES algorithms for cryptography the originator produces one secret key that will be stored in the IoT. The originator will then generate a signature of the code by encrypting the digest with the secret key. This signature will then be appended to the code itself prior to deployment to the field.

Whatever method is used, the IoT contains the key. Let’s assume the MCU is now required to run the newly deployed code. Using that key, the MCU will decrypt the appended signature, obtaining the digest. It will then run the proper SHA algorithm on the code, again obtaining a digest. If the two match, it means the code is untouched and is the exact image of the original. It is a trusted code that passes the verification of authenticity (the signature was decrypted with the originator’s key) and integrity (the two digests match).

Although this description is simplified because it omits the hierarchical key certification through the public key infrastructure that addresses the essential verification of the originator’s identity, the end user is certain about the origin, safety and purpose of the code.

Asymmetric and Symmetric methods, the basic difference

The public key generated with RSA or ECC is nothing secret, can only be used for verification and does not work for any other purpose. The only harm that hackers can do to public keys is to modify them, making them invalid and unusable. That’s why the end user must make the public key unchangeable and store them in non-writable eNVM.

The secret key instead is used for both signature (encryption) and verification (decryption). If hackers get hold of secret keys, they can do enormous harm by changing the binary executable at their will, encrypt the digest with the secret key and deploy it in entire classes of IoT. (By the way, this is true also for the private key described above). That’s why the end user or recipient of the code must store the secret key in ways that ensure the near impossibility to read or detect its content.

On the positive side, the added value of AES algorithms is that their computational weight is much less than RSA and ECC. This can be an important matter to consider for low-power, battery-operated IoT.

Secure Boot through Chain of Trust

The verification process described above occurs as the “Chain of Trust.” After power up, when the MCU is required to run some code that was not yet used in the current session, the signature verification starts. Upon successful completion, the code will be available for the entire session with no further verification.

At power up, the RoT will verify the signature of the BIOS and let the MCU run it after successful completion of the verification. The BIOS will call for the signature verification of the operating system that will call for the verification of the application. And so on.

As stated above, the Root of Trust is the only code that is inherently secure and trusted since is the root of the chain.

The chain of trust is a chain of signature verifications starting from the RoT.

OTP offering in the Secure Boot

OTP providers are continuously facing the challenges of enhancing security in the IoT space. The implementation of features that make the OTP unattackable is not mainstream practice. To securely store the secret keys generated for Symmetric encryption, the end user should demand these features:

• The OTP must detect voltage and signal tampering. In such an event, the OTP should output invalid data.
• One and zero bitcells should have an identical power footprint, defeating SEM imaging and power profiling.
• Random output data should interleave real output data to obfuscate data probing.
• Writing of the OTP should be disabled in hard mode, impeding data modification.
• The OTP should be fully redundant, duplicating the memory array.

In general, such features come at the cost of lower access time and larger physical area. This should not be a problem since the size of keys fit well in few Kbytes, requiring a small OTP area. For storing public keys where secrecy is not required, such features are not necessary, but the option to disable content modification may be required.

Needless to say, the race and fight between memory providers and security hackers is intensifying, pushing the creativity of memory designers deeper within the security space.