Yesterday we ran our live webinar covering our Arm CryptoCell technology. We covered how attacks on devices are becoming more sophisticated and the impact this has on your security solution. We also gave viewers an introduction to platform security and the benefits of hardware-based security. We learnt how security delivers improvements on power and performance, whilst offering new use cases and business models. Thanks to everyone who joined us for the webinar, we had a great attendance and some insightful questions.
If you missed the webinar the good news is that you can still catch up, just click the link below. Keep reading to catch up on some of the questions you may have missed.
Watch webinar
If you are interested in other security related webinars, check out:
Meet the Experts: Arm TrustZone - understanding system security -webinar
How to Build Trust and Security into your Embedded Device -webinar series
We see that use cases are split into two categories:
Yes, CryptoCell can be used with any execution environment capable of running code (for example a processor dedicated for security tasks or even the main application processor). The decision of where to execute the CryptoCell code from (i.e. security related SW) should take into consideration both PPA and threat model considerations.
We believe the combination of CryptoCell with TrustZone isolation technology (for both Cortex-A and Cortex-M CPUs) provides an excellent “operation point”, addressing many use cases.
Unfortunately, such guarantees cannot be made. At the end of the day, the robustness depends on the threat model that is addressed (and mainly – what is not addressed within the assumptions constructing the threat model) and how well designed, tested and reviewed the system is. As there is lots of code going into today’s devices, it is almost impossible to assure there are no flaws through which hackers can gain privileges they were not supposed to get. However, within the applicable threat model (i.e. a reasonable set of assumptions on the attackers funding and expertise), CryptoCell can assure the security of critical assets and operations.
The ability to provide an unpredictable stream of bits or numbers, is important for multiple security needs. This includes generation of keys or assuring that stale messages are not being replayed over a communication channel. Nowadays there are different sources of entropy and different ways to extract entropy from a given source. In the CryptoCell case the TRNG is completely digital and made out of standard library cells. When it comes to entropy, some standards require “the statistical behaviour of the digitized noise signal to be inconspicuous". Others omit this requirement for perfect statistical properties of the generated data and emphasize the entropy contained in that data and how to extract it. CryptoCell offers support for different standards and drafts like the NIST800-90B draft and the German AIS-31 standard.
This is a very fragmented ecosystem and different organizations are involved in the creation of a device and a service, these organizations often don’t even know each other, let alone trust each other. However, they still own execution environments and assets on the final device. Naturally these organizations want to protect their assets, against the other parties involved in forming the device. Arm allows secure multiple ownership of assets in CryptoCell, by having multiple sets of roots of trust, owned by different entities. Let’s take debug as an example - the scheme we support allows separation of debug and access rights, where one entity cannot grant debug rights related to domains and assets belonging to another entity. In this example, an OEM can own the execution space where market applications execute and a chip vendor can own the execution environment running the communication stacks.
Yes, larger SoCs tend to have “control plane” security needs as well (for example - not only data intensive use cases) and CryptoCell-3xx can be used in that context. As both families of CryptoCell - the 300 aimed at efficiency and the 700 aimed at performance – offer the same set of services, they are interchangeable, based on the desired performance grade.
Although this does seem a fit for the different profiles, there is enough variance in the Cortex-A families and Cortex-M families to ensure there is overlap. A good example of this is the Cortex-M7 processor, which has a cache and a good PPA. This processor may have the required performance for some wearable devices, equally as much as the lower end Cortex-A processors such as the Cortex-A5 or Cortex-A32 processors.
Yes, there are a number of Trusted OS’es available for Cortex-A processors, there are open source developments such as the Linaro OP TEE (Open source TEE), as well as commercial TEEs such as the TEEs from Trustonic and Sierrawear. The development of TrustZone systems is bringing a lot of TEE’s from many vendors.
The webinar link doesn't work. How can I find the presentation ?