Open Trust Protocol (OTrP) addresses security of billions of connected devices

By Marc Canel, vice president of security systems, ARM, www.arm.com

A group of leading technology security experts led by ARM, Intercede, Solacia and Symantec recently released the results of months of collaboration that set out to assess the security challenges of connecting billions of devices across multiple sectors; including industrial, home, health services and transportation. Their conclusion was that any system could be compromised unless a system-level root of trust was established – and for the continued development of a truly connected world, trust between all devices and service providers is essential. To deal with the risk, the companies collaborated on the Open Trust Protocol (OTrP), which combines a secure architecture with trusted code management using technologies proven in large scale banking and sensitive data applications on mass-market devices such as smartphones and tablets. In this article we explore the objectives of OTrP, how the technology works, its use cases and the ecosystem that is delivering it.

Why OTrP?

The objectives of developing OTrP were threefold.

• Create an open international protocol defining how devices trust each other in a connected environment. The protocol would be based on existing open technologies with proven robustness and commercial attractiveness in existing markets. The Public Key Infrastructure architecture (PKI), including the mature concepts around certificate authorities, was selected as the basic underlying system.
• Given the reuse of the PKI architecture, it was imperative to create an open market for the certificates that would enable applications to authenticate resources in devices. It was a key requirement to have a mechanism by which certificate authorities can all compete and access devices in which they push their certificates to authenticate resources.
• With an open protocol, it is possible for multiple vendors to create either client or server solutions. This strategy enables an open and active market of developers of both client and server solutions.

Collaboration began in early 2015, and membership of the OTrP Alliance soon grew to 13 companies. To encourage widespread adoption, the alliance also worked with international standards bodies such as the IETF and Global Platform to get OTrP adopted as a protocol within their organizations.

The OTrP technology

As a protocol, OTrP adds a messaging layer on top of the Public Key Infrastructure (PKI) architecture. OTrP is reusing the Trusted Execution Environment (TEE) concept that increases security and robustness in the system by physically separating the regular operating system of a device from its security sensitive applications. Given the heterogeneity of the devices in the connected world, Trusted Services Managers (TSMs) are used to manage keys in the devices to create security domains, authenticate resources, and load applications. OTrP defines a protocol between a TSM and a TEE and relies on IETF-defined end-to-end security mechanisms, namely JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Key (JWK). The specification assumes that a device that uses OTrP is equipped with a TEE and is pre-provisioned with a device-unique public/private key pair that is securely stored. This key pair is referred to as the 'root of trust'. A service provider uses such a device to run Trusted Applications (TA).

The key components of the OTrP system are:

• TSM:  The TSM is responsible for originating and coordinating lifecycle management activity on a particular TEE.  It is at the core of the protocol and manages the trust in the devices on behalf of service providers. In addition, the TSM provides Security Domain management and trusted applications management in a device, in particular over-the-air updates to keep trusted applications up to date.
• Certificate authority: Mutual trust between a device, a TSM and services providers is based on certificates.  A device embeds a list of root certificates, called trust anchors, from trusted certificate authorities that will be used to validate a TSM. A TSM will remotely validate a device by checking that a device comes with a certificate from a trusted certificate authority.
• TEE:  The TEE resides in the device chip security zone and is responsible for protecting applications from attack, enabling them to perform secure operations.

OTrP establishes appropriate trust anchors to enable TEE and TSMs to communicate in a secure way when performing lifecycle management transactions. The main trust relationships between the components are that the TSM must be able to ensure a TEE is genuine, the TEE must be able to ensure a TSM is genuine, and the Secure Boot must be able to ensure a TEE is genuine.

Use cases

There are multiple examples of use cases for OTrP that span both the mobile and the Internet of Things applications. They are based on the dynamic loading of a security sensitive application into the TEE of a client device via a TSM to perform a task for a server system. Here is a small subset: 

• Identity management for enterprise systems
• Strong authentication & display protection for payment systems
• Enterprise systems: VPN, secure access to web sites
• Digital Rights Management applications
• Automotive systems: authentication, pay as you drive, in-application purchasing
• Healthcare: authentication, privacy management               
• Home automation: authentication, privacy

OTrP ecosystem and business model

By identifying the key components in the system, OTrP defines an ecosystem of partners that deliver trust in the applications of the devices. As indicated in this diagram, the Trusted Applications Manager (TAM/TSM) plays a central role in enabling trust between the partners.

The protocol is available for download from the IETF website today for prototyping and testing.

OTrP as a protocol does not define a business model; it only defines the entities that take part in the ecosystem. The protocol integrates all the tracking elements to enable any business model selected by the partners. In other words, the business model can be TAM/TSM centric, or TEE centric, or certificate authority centric, or application centric, with either one of these entities having the ability to control the pricing of the trust services.