The Open Trust Protocol (OTrP) in Automotive



How to continue developing a truly connected world.

In the automotive and many other segments, what characterizes the IoT market is the connection of many devices to a centralized, decentralized or mesh network. The rollout of these devices in the field and the management of the applications is a logistics and security challenge.

Cars have multiple processors handling a large number of tasks. The applications cover various areas such as vehicle control, audio and video entertainment, mapping and navigation, payment, cockpit information and Advanced Driver Assistance Systems (ADAS). Over time, the requirements and regulations in all these areas change. New applications are created, and old ones need updates. The systems hosting these applications need to offer a mechanism which protects various software applications within secure domains to ensure each application’s isolation. Isolating one application from the next is especially needed as automotive electronics become more and more powerful—and as these electronics take on multiple tasks instead of being specialized for one function or another. Other applications such as control systems will also need isolation and protection in secure containers.

Figure 1: Key components of the OTrP system.

Figure 1: Key components of the OTrP system.

These applications are not static. They require either functional upgrades, or they get updates with fixes. In a connected vehicle, depending upon the features purchased by the customer, various pieces of code will get downloaded and managed dynamically. Maintenance of the car becomes more sophisticated over time. Updating maintenance systems makes tracking additional data from the sensors and the car’s other control systems possible. Navigation and management systems gain enhancements as the car learns driver and passenger use patterns.

Various parties can supply the applications. For example, the control functions may come from the car OEM, while a financial services company makes the payment applications available and still another entity, the IVI system vendor, supplies entertainment and mapping applications. The consumer may also choose the application developer in areas such as payment, entertainment and mapping. This situation creates an applications provisioning challenge for the car OEM, as all these developers need to push their own code to the car.

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 for the continued development of a truly connected world, trust between all processors and service providers is essential. In the case of the transportation industry and automotive, a flexible, secure and dynamic mechanism is required to establish trust between the multiple applications developers and various systems of a car. 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.

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

Why OTrP?

The objectives of developing OTrP are threefold:

  1. Create an open 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 (CAs), 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 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 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 and especially in automotive, Trusted Services Managers (TSMs) are used to manage keys in the processors to create security domains in the various ECUs, 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 processor 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 (TA).

The key components of the OTrP system are:

  1. 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 TA management in a processor, in particular over-the-air updates to keep TAs up to date.
  2. Certificate Authority (CA): Mutual trust among 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.
  3. TEE: The TEE resides in the processor 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. Several trust relationships need to be set up:

  1. The TSM must be able to ensure a TEE is genuine.
  2. The TEE must be able to ensure a TSM is genuine.
  3. The Device, though its Trusted Firmware, must be able to ensure that a TEE is genuine.

OTrP enables OEMs in the automotive industry to ensure that only approved applications developers will load code within the car throughout its life. Given the complexity of car systems, gate keeping access to the various systems of the car is a key function of the OEM and its management of ongoing car maintenance.

Figure 2: OTrP defines an ecosystem of partners that deliver trust in the applications of the devices.

Figure 2: OTrP defines an ecosystem of partners that deliver trust in the applications of the devices.

Transportation Use Cases
There are multiple examples of use cases for OTrP in the automotive industry. 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:

  1. Installation of payment application
  2. Installation of Digital Rights Management applications in the IVI system
  3. Installation of advanced features: upgrade of cockpit functions, entertainment systems
  4. User Management: authentication, profile management and privacy
  5. Update of maintenance systems collecting data from the car
  6. Update of control systems

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 Figure 2, the Trusted Services Manager (TSM) plays a central role in enabling trust between the partners.

The role of the TSM can be played by the automotive OEM or another party designated by the OEM as the gate keeper to the car. Several TSMs can be set up to control the car: for example, the OEM can choose to have a TSM for the navigation and mapping systems and a different TSM for the audio and video entertainment systems, offering further isolation between the management systems of the car. OTrP allows the OEM to have several TSMs for applications sharing the same processor: for example, the IVI vendor could operate as the TSM for the IVI system. Another TSM vendor will manage another set of applications such as the Cockpit Display applications.

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. Therefore, the automotive OEM and its tier 1 suppliers can choose the business model that suits them best for the car. For example, the TSM managing the cockpit functions will have a business model controlled by the warranty and maintenance policies of the OEM, whereas the TSM managing entertainment functions that can be upgraded on demand by the consumer would be based on a different business model, involving usage fees.

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


Canel_MarcMarc Canel is VP of Security Systems, ARM.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google