Sign In
Forgot Password?
Sign In | | Create Account

Internet of Things Security: Answering Audience Questions, by Felix Baum

A few weeks ago we held one of our Google+ On-Air Hangouts on Internet of Things Security.  You can view the full video using the embedded YouTube video below.  During this hangout we received some excellent questions from the audience, and one of our presenters, Felix Baum has taken the time to answer three of them.


How is the transition between secure and normal carried out? What part controls that?

TrustZone offers two separate execution worlds: secure domain and non-secure domain. A TrustZone capable ARM processor can operate in a secure as well as non-secure state. In other words, a single physical core can execute the program from both secure and non-secure worlds in time sliced fashion. Each secure and non-secure state has its independent privilege levels. For example, when MEHV runs on a Cortex-A9 target, each guest OS runs in a non-secure state, and the Mentor hypervisor runs in the secure state. On a Cortex-15 target, the guest OS and the hypervisor both run in a non-secure state, but hypervisor runs at a higher privilege level than the guest OS.

A separate processor mode called Monitor mode is implemented when the ARM architecture supports security extension. This Monitor mode controls switching between non-secure and secure states. Registers for all critical resources, such as coprocessor registers controlling MMU, exception table, and so on, are banked. That is, two separate copies of the same register, one for each world, are available when the ARM processor implements security extension. This provides isolation of resources and increased security.

The TrustZone Client module within Linux kernel invokes Monitor or SMC command handler that acts as gatekeeper between the non-secure and secure worlds. Entry into the secure world from the non-secure world must pass through this Monitor (SMC handler). The Monitor then interacts with the MEHV secure kernel. A dispatcher in the secure kernel spawns the required secure service task.

To learn more about TrustZone please refer to: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/index.html

What about the Hardware Security modules used in Smartcard world?

A secure element (SE) is a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (e.g. key management) in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities.

There are three different form factors of SE: Universal Integrated Circuit Card (UICC), embedded SE and microSD. Both the UICC and microSD are removable. Each form factor links to a different business implementation and satisfies a different market need.

GlobalPlatform is form factor agnostic and, as such, is working to standardize all three SE technologies. Selection of an SE is a business choice that will be made by the service provider or end user. GlobalPlatform’s concern lies with standardization and interoperability of application management within an SE, whatever the form factor.

Work to standardize all three form factors is to the benefit of the market. Service providers and application developers can have confidence in the standards of SEs when developing their products. Broader development and deployment reduces costs and time to market. With standardization and interoperability across the marketplace, developers will only need to make one application, where they once needed to create three.

What is TEE?

The Trusted Execution Environment (TEE) is a specification created by GlobalPlatform.  The TEE specification aims to provide a framework or a set of APIs for developing secure embedded applications for various embedded platforms. Embedded software in devices interacts with the cloud and deploys a multitude of applications that are open to third-party development. This increases the risk of attacks on such devices and embedded systems. A TEE aims to provide protection against software attacks. It cannot protect against extreme physical attacks.

A TEE can be viewed as an intermediate solution that can offer more security than a typical feature rich operating system, such as an Embedded Linux distribution, by allowing tighter access control to the secured resources. Comparatively, traditional ways of providing security like Secure Elements (SE) that are present in the credit cards, SIM, and so on, have tamper resistant hardware and provide good access control over the protected resource. However, they lack in performance, flexibility, and adaptability towards varying and increasing end user needs.

A TEE aims to offer a compromise between the security provided by dedicated hardware based approaches, and the performance and feature richness provided by the embedded operating system. The TEE framework allows adjustments to the level of security based on the importance of the asset it needs to protect. Implementation of the TEE framework/API can be vendor specific. This makes TEE framework technology agnostic or architecture independent. A TEE combines hardware as well as software mechanisms to offer security. ARM Trust Zone technology is used within MEHV to implement a TEE.  To learn more click here: http://www.globalplatform.org/mediaguidetee.asp

More question answers are on the way next week so stay tuned and thanks for your participation.  You can view Felix’s and the others entire presentation by clicking here: http://www.mentor.com/embedded-software/multimedia/security-strategies-iot-systems?clp=1.

hardware security module, internet-of-things, ARM, TEE, TrustZone, IoT, Security

More Blog Posts

Comments

No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

 
Online Chat