Exploring the Open Trust Protocol

Download this article in PDF format.

A group of leading technology security experts led by ARM, Intercede, Solacia, and Symantec recently released the results of a collaborative effort 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, there must be trust between all devices and service providers.

To deal with the risk, the companies collaborated on the Open Trust Protocol (OTrP), which combines a secure architecture with trusted code management. It leverages technologies proven in large-scale banking and sensitive data applications on mass-market devices such as smartphones and tablets.

Here, we explore the objectives of OTrP, how the technology works, its use cases, and the ecosystem delivering it.

Why OTrP?

The objectives of developing OTrP were threefold:

1. 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 (PKI) architecture, including the mature concepts around certificate authorities, was selected as the basic underlying system.
2. 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.  In other words, having an open market for certificates was a key objective of the project.
3.  With an open protocol, it’s 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 PKI architecture. OTrP reuses 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 utilizing OTrP is equipped with a TEE and is pre-provisioned with a device-unique public/private key pair, which 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 (TAs).

The key components of the OTrP system (Fig.1) are:

• Trusted Services Manager (TSM): The TSM is responsible for originating and coordinating lifecycle management activity on a particular TEE. It’s 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 TA management in a device, in particular over-the-air updates to keep TAs 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.
• Trusted Execution Environment in the device: 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 TEEs and TSMs to communicate in a secure way when performing lifecycle management transactions. The main trust relationships between the components are:

• The TSM must be able to ensure that a TEE is genuine.
• The TEE must be able to ensure that a TSM is genuine.
• The secure boot sequence of the TEE device must be able to ensure that the TEE is genuine.