Embedding Security - Step by Step
by Ron Keidar - Inside Secure
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 not be modified 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., as part of the protected image.
2. Protect your Intellectual Property
Even if your product enforces signed images, that does not mean it protects your ideas . 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 data bus. The encryption key is derived from another Root-of-Trust (bound to hardware) but unlike the 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 FW Upgrade
Moreover, what if you want to fix, enhance or improve your product, 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.
Figure 1 – Security essentials
4. Prevent FW rollback
Even once security holes are fixed via a firmware upgrade, hackers may compare the 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.
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 Vault-IP: A True Security Swiss Army Knife
Vault-IP 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 Vault-IP, 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:
Figure 2 – Vault-IP schematic diagram
There is no data bus or any interface from outside the boundary to the internal address space. Vault-IP 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, Vault-IP processes the command and writes the result to the mailbox which in turn switches back to the host.
This implementation of Vault IP 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. Vault-IP 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 Vault-IP 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
Vault-IP 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.
Vault-IP supports all the Secure Boot features we mentioned at the opening of this article.
Vault-IP can control different levels of debugging privileges, different owners, and public key-based authentication.
Multi Core Support
Vault-IP 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.
Different configurations of Vault-IP allow trading off size and functionality:
Figure 3: Vault-IP configurations
We didn’t discuss many other capabilities of Vault-IP as this article needs to remain on a manageable size. We also didn’t touch 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.
8. Related links:
Vault-IP family of products
Vault-IP FIPS Security Policy - by ATSEC
When Toasters, Cars, Thermostats and Fridges Attack - Right-Sizing the SoC Security Architecture for the New Connected World - IPSoC, Dec. 2016, by Inside Secure