Sunday, December 7, 2014

ARM® TrustZone® technology - from Monitor Mode to Dedicated Security Co-Processing and the Secure Element(s)

In the last blog post I explained how software running in normal world was different from software running in secure world. Each world, secure and normal, has an operating system and a set of applications that run on that operating system. The operating systems and application software are different between the two worlds.


I mentioned a key point in the last blog post: when you turn the power on to your phone, ARM®-Cortex®-based smartphones with ARM® TrustZone® technology allow two operating systems start up at the same time. The operating system in the secure world is called secure OS, and the operating system in the normal world is called normal OS. While both operating systems  run on the same physical processor, the secure OS typically has access to additional physical resources and hardware peripherals.


The reasons for this are best quoted from the ARM® TrustZone® technology Web page
A design that places the sensitive resources in the Secure world, and implements robust software running on the secure processor cores, can protect assets against many possible attacks, including those which are normally difficult to secure, such as passwords entered using a keyboard or touch-screen. By separating security sensitive peripherals through hardware, a designer can limit the number of sub-systems that need to go through security evaluation and therefore save costs when submitting a device for security certification. - ARM.com
NOTE: there are variations on how software is implemented in secure world - from a simple synchronous library of code to a full blown operating system.

The execution of the normal OS and secure OS is interleaved over time via a context-switching mechanism called monitor mode. Monitor mode is responsible for time-slicing the execution of the normal OS and secure OS via context switching the state of each world on the physical processor. Monitor mode is explicitly triggered via a dedicated instruction or special type of exception. The explicit methods by which monitor mode is triggered contrast the typical scheduling algorithms that trigger context switching in modern day preemptive operating systems.

There are varying levels of complexity in regards to how the physical hardware in which secure world runs on is designed. These range from both worlds running on the same physical processor core to secure world running on a completely separate processor core.

Another type of physical hardware design entails an additional microprocessor that is separate from the main processor.  The secure world software stack (secure OS and secure applications) are run on a dedicated co-processor.  This design is not mutually exclusive with a secure OS running on the main ARM® processor.  The normal OS still runs on the main ARM® processor and a secure OS can still run on the main ARM® processor if the main ARM® processor has ARM® TrustZone® technology.  A different secure OS and secure application software can run on the dedicated co-processor.  

Client applications running on a secure OS can communicate with the main ARM® processor via a set of APIs and commands. There are certain benefits to the secure OS always running on a dedicated security processor core or co-processor. 

The operating system that runs on the co-processor can be optimized for just the co-processor.  There are many types of dedicated co-processors.  The ARM® SecurCore® microprocessor is one type of dedicated co-processor.  ARM® SecurCore® microprocessors are used in systems that require dedicated processors for security sensitive applications such as SIM cards, e-Government, Banking, and Identification.  Designs that incorporate ARM® SecurCore® microprocessors can realize multiple key benefits including build performance improvements, energy efficiency, and physical security. Designing and building an operating system for a single chip means that the operating system can be built to use all of the features and only those features that the chip provides.

In summary, here are the key points:
  • Operating system software runs on the main ARM® processor or application processor.
  • Software applications run on the application processor.
  • ARM® processors in ARM®-based mobile phones may or may not have ARM® TrustZone® processor security technology.  If the ARM® processor has ARM® TrustZone® processor security technology, then it may or may not be used.
  • There are additional processors on mobile phones that act as dedicated security co-processors. These include the secure element on the UICC or SIM card (UICC based SE) and the secure element that has been soldered on the printed circuit board.  The secure element that has been soldered to the printed circuit board is called the embedded SE.  If you have an iPhone® 6, an iPhone® 6 Plus, or a Samsung S5, Galaxy Nexus, Nexus S, Nexus 7, Sony Xperia series, and a host of others, then there is a secure element soldered onto the printed circuit board.  If your phone has a secure element that has been soldered onto the printed circuit board, then it is most likely contained within the packaging of a larger SoC that also contains the Near field communication (NFC) Radio-Frequency (RF) controller.  Last but not least, it is entirely possible that your phone contains a secure element on the microSD card. However; you would know if it did because you would have explicitly ordered it and it would probably not work out of the box.
  • The embedded SE and UICC based SE run a trusted OS.  Trusted applications run on top of the trusted OS.  In contrast to the trusted OS that runs within secure world on a main ARM processor with ARM® TrustZone® processor security technology, the trusted OS that runs on the embedded SE and UICC based SE does not share full hardware peripheral or direct normal world software access on the main application processor.
  • The UICC based SE and embedded SE are protected by cryptographic keys.  Client software applications running on the trusted OS in a processor with ARM® TrustZone® architecture security extensions are also protected by cryptographic keys.
  • There are multiple standards bodies that have established APIs, architecture documents, design documents, and so-forth for the trusted operating system and trusted applications that run on the UICC based SE and embedded SE.  These entities are also responsible for the hardware interface on the physical secure element.
NOTE: This was a high-level, technical overview.

ARM and Cortex are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. ARM and TrustZone are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. ARM and SecurCore are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert, QorIQ, QorIQ Qonverge, Qorivva, Ready Play, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid and Xtrinsic are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. iPhone is a trademark of Apple Inc., registered in the U.S. and other countries.

No comments:

Post a Comment