Embedded Security Step by Step
So, you’ve got your great idea on how to revolutionize the market! Wait, before you start, have you addressed security?
Let’s address security step-by-step
1. Ensure Ownership and Integrity of the Product – Secure Boot:
Once the product hardware is there, can someone change its code? Replace servers’ names? Insert botnets? There are many ways such changes can impact your market share and margins.
Secure Boot – Secure boot ensures that only code image digitally signed by you can run on the device. It does so by computing a hash on the firmware and signing it with a private key that your company secures. A public key is stored on the device, and as its name hints, it is not secret, but must be immutable because it is the claim of ownership in hardware, it is one of your Root-of-Trust. The device uses this public key to verify the signature and the integrity of the image. What if it fails? Nothing else gets executed. Of course, it is important to cover any crucial common configurations like remote servers’ names, FCC-15 related configurations, automotive performance tuning etc.
2. Protect your Intellectual Properties (IP)
Even if your product enforces signed images, that does not mean your ideas are protected. The image cannot be modified but it can be reverse-engineered. Competitors may reverse the code and use it to compete with you. Hackers will scrutinize it to identify weaknesses or bugs they can exploit. To prevent that, the image must be encrypted on flash, decrypted, locked and executed from internal RAM or obfuscated external RAM such that there is no way to capture it on the external data bus. The encryption key is derived from another Root-of-Trust (bound to hardware) but unlike the secure boot authentication key which is public, this encryption key is a secret symmetric key. In addition, this key is ‘global’ i.e. used by many devices, hence any access to this sensitive asset must be prevented. Yet, your software needs to use it. How to protect the key? More on that soon.
3. Support Firmware Upgrade
Moreover, what if you want to fix, enhance or improve your product in field, or maybe address a security hole? It is essential to enable over-the-air (OTA) firmware upgrade. In the case of IoT it is common to put some of the upgrade burden on the mobile application in order to keep the IoT device simple. Of course, the downloadable image must be signed and encrypted, especially when the mobile application is the middle-man, a great place for hackers to capture the firmware, study it and replace it with something else.
4. Prevent Firmware rollback
Even once security holes are fixed via a firmware upgrade, hackers may compare the new and old images to identify the fix (a great way to find where the security hole was!) and then downgrade the firmware image to the original version; after all, the previous file is legitimate and therefore will pass secure boot verification. Once replaced, the hackers will explore that security hole. To prevent that, an anti-rollback mechanism is added to allow a new version to invalidate the older ones.
5. Firmware is secured; what about the interfaces?
Every interface of the device is added to its attack surface as it exposes the device to new threats. So, in addition to what we talked so far regarding protection of the code, the interfaces need to be protected as well; here are some examples:
· Ethernet and IP
Connected devices usually have some form of TCP/IP connection, over the Ethernet, Wi-Fi, BT, Thread, and so forth. The one thing all these communication technologies have in common are UDP or TCP ports that can reach anywhere on the globe and potentially be reached back. We like to assume that firewalls block hackers, but attacks can come from LAN (behind the firewall, e.g. mobile applications) or holes in the firewall, through infected DNS or proxies. Here are a few steps to prevent such attacks:
- Close all ports, use client mode when possible.
- If a port is left open, it must only serve secure protocol like IPsec, TLS, SSH, etc.
- Authentication should be mutual and based on certificates.
· Web Server
IoT devices, routers, and other connected devices usually allow for remote management via a web server. A device’s web server would violate the above recommendations (open port, no certificate, no HTTPS, default passwords) so it’s best to let the mobile app handle the UI, but otherwise enforce a strong password policy and never initiate it to a global default password - make them unique per device.
· Debug port, USB port and other Interfaces
The ability to disable debug is essential to protect software intellectual property. Debug port and other interfaces that can gain access to memory should be disabled for commercial products and only re-enabled with password or public key-based authentication. Global passwords are a big risk because they can easily leak and are hard or impossible to replace; On the other hand, debug password per device requires key provisioning and database of keys. Alternatively, a public key can offer a better and cleaner solution that avoids the provisioning, database and isolation of the global key.
6. Putting it all together
Implementing each of the above piece-by-piece would be a big risk to the product timeline and quality. Trying to reduce costs and develop security solutions without the required skills will not effectively thwart real-world attacks.
But here is the thing: we at Inside Secure have already figured it out and solved those issues. Our solutions have been in the market protecting products for ten years and counting. And the best part? We’ve packed them all together, so you don’t need to solve each problem feature by feature; instead, get all of the solutions you need in a single core.
7. Introducing Root-of-Trust Engine: A True Security Swiss Army Knife
Root-of Trust Engine is an embedded HSM or a Secure Enclave. It is an IP core that sets a hardware boundary around your secrets in a way that no external software can access them directly; yet, external software can issue requests, and if these requests are approved by Root-of-Trust Engine, the internal controller will issue the operation without revealing the secrets outside of the safe box. Let’s examine how this is done, step by step:
· Hardware Boundary
There is no data bus or any interface from outside the boundary to the internal address space. Root-of-Trust Engine uses ‘mailboxes’ for that purpose. The mailbox is a buffer that’s either facing the host or the internal processor. The host writes a command to the mailbox and issues it. At this point the mailbox switches to the internal side, Root-of-Trust Engine processes the command and writes the result to the mailbox which in turn switches back to the host.
This implementation of Root-of-Trust Engine was reviewed by ATSEC and is approved for FIPS 140-2 Level 2.
· Asset Store – the Keys
Keys have many different properties: storage type, life cycle (e.g. active, inactive, invalid), are they secret or public, ownership, usage, and more. Secure Asset Store addresses all those properties and offers flexible solutions for different needs. We asked initially how to protect the image encryption key, the asset store at Root-of-Trust Engine is the answer. It allows a flexible key derivation that addresses different designs and multiple keys, in case software vendors need to be isolated from one another.
· Crypto Accelerators and Full Range Cryptography
Root-of-Trust Engine embeds an array of crypto cores including HASH, symmetric and asymmetric engines on top of a fully digital true random number generator (TRNG), an essential component of any crypto-system. To accelerate operations on the host address space (e.g. firmware image decryption and hashing), the crypto cores can have a master interface with DMA - without violating the boundary - as this is a data bus to from those engines without any control.
A rich API enables utilizing these crypto cores along with the DMA by many operations.
· Secure boot
Root-of-Trust Engine supports all the secure boot features we mentioned at the opening of this article.
· Secure Debug
Root-of-Trust Engine can control different levels of debugging privileges, different owners, and public key-based authentication.
· Multi Core Support
Root-of-Trust Engine supports multiple cores, isolates their contents and does not require extra locks or semaphores since each execution environment has its own driver and can operate on a separate mailbox. When designing a product-line that includes large and small SoCs, software migration and compatibility across such product-line is essential. Having the same driver code running on all execution environments and all dies assure smooth software migration.
· Programmable Root-of-Trust Engine
Inside Secure recently announced a new member to the RoT Engine, the Programmable RoT. The Programmable RoT unleashes many new use-cases as it allows OEM to put code inside the secure perimeter, isolated from attacks mounted on the other CPUs (including attacks on TEE like TrustZone or cache attacks like Spectre and Meltdown).
Examples for such use-cases could be SSL/TLS Client – enabling a direct tunnel between the cloud and the RoT allowing for trusted remote management, authentication, attestation and SW version control, SKU management and more.
Another example related to mission-critical markets. Programmability is required to assure an OEM can fix issues found after deployment, e.g. Automotive “Evita Full” requires programmability.
Inside Secure Programmable RoT meets or exceeds those and other mission-critical markets requirements
· And More
We didn’t discuss many other capabilities of Root-of-Trust Engine such as Side Channel Attacks (SCA) and Fault Injection (FI) and others as this article needs to remain a manageable size. We also didn’t touch on the security protocol IP cores, key derivation for every application, TLS and IPsec SW toolkits for VPNs and interface protection, and more...
For more information about all of these, please return a note and we will be happy to continue the exchange of information with your company.