Gabe Moretti, Senior Editor
I had a conversation with Majid Bemanian, Director of Segment Marketing at Imagination Technologies about system security. His general view is that for any system to operate as it was intended by the manufacturer (OEM) or operator, a mechanism of unalterable checks-and-balances needs to be engraved or burned into the system. Such a mechanism acts as a trusted agent that can start the system, validate its operation, provide trusted services, and if necessary shut down the system in the event of compromise.
CD: you mentioned the term “Root of Trust”. How do you define it?
MB: One technique to have such checks and balances is implementation of Root-of-Trust (RoT). RoT anchors crypto keys and trusted code into the system in such a way that it cannot be altered. Therefore, the rationale would be – If the keys and code code that are burned into the system cannot be changed and come from a source that I trust, then by definition, the system operating under its supervision can be trusted; extension to the trusted code and keys that are validated by a trusted entity (RoT) can also be trusted. Together, this forms a Chain-of-Trust.
Once the user has confirmed that the system is in its intended trusted operational state, it can then be assumed to be original (not cloned).
CD: How can we choose a protection level?
MB: To determine the level of protection required, we first need to determine what specifically we are protecting.
To protect stored content such as passwords, photos, code, sensory information (e.g. from a heart monitor), etc., encryption can provide a level of privacy. One must also protect the encryption key(s) which are used to enforce protection. To protect software, authentication and encryption are essential.
Authentication assures the software running on the system is original and from the intended OEM and starts its operation in the intended state defined by the OEM/operator. An authentication procedure can be implemented leveraging an asymmetric cryptography process where there are key-pairs to assure robust authentication. Key pairs include a private key to sign and public key to validate the authenticity of the software.
Encryption is often used alongside authentication to ensure that the software remains private, with encryption keys to make software inaccessible.
CD: How do we choose an protection strategy?
MB: Once we know what we are protecting and how to protect it, we must ask what attack vector(s) we are protecting the system. If the system is at rest, it is possible for a physical attack to penetrate the system. If the system is in-motion, a cyber/network or side-channel attack in addition to a physical attack can compromise the system.
If we look at a connected lightbulb versus a heart monitor or pacemaker, we can see that not only will they need different levels of protection given their criticality, but also that the likelihood of certain attacks would be different in each case. Each comes at a different cost – a system design consideration.
In physical attacks, we need to determine the potential access methods to the system and implement the correct defensive measures. Removing the JTAG connector and traces connected to the device may be sufficient for a connected lightbulb. However protection against a side channel attack such as Differential Power Analysis (DPA) may be needed for a heart monitor or M2M payment system.
CD: How do we respond to a security attack?
MB: A Runtime Integrity Check can offer a mechanism to determine if a system had been compromised post standard operation; hence, runtime. One can implement Runtime Integrity Check in the background to periodically check for vulnerabilities/signs of system compromise. Then corrective steps can be taken. If a system has been authenticated and is operating as intended but an attack is still successful in gaining access, one can shut down the system, reboot or simply flag and notify an authorized agent.
Another area to consider is response to malfunctioning. There are many mechanisms to detect tampering and provide a response. Tamper-evident markings provide a visual indication and are the simplest form of protection. This common method is intended to detect interference with the system and the content residing on it. Of course in most cases, the technique is not acceptable to provide a trusted and secure system. As part of RoT functionally, tamper monitoring is needed. This can monitor changes in a device’s physical properties such as temperature, and various tamper responses can be implemented if tampering is detected. Many different techniques that can be implemented to respond to a tamper, e.g. a simple alarm/notification to self-destruct secret keys and data.
CD: What you say requires architectural planning and careful implementation which in turn translate in development cost.
MB: For many connected devices, compliance and conformance to certain industry rules pose a significant time and cost investment which designers must consider. But an insecure system is not competitive, in fact it may be dangerous and result in far greater losses to customers and consumers.
CD: Thank you.