Introducing the MIPI Security Framework: Taking Security to the Next Level

The aim of the MIPI Security Framework is to add end-to-end security to applications that leverage existing MIPI specifications. Initially focused on MIPI CSI-2^® image sensor applications in automotive, this framework is designed to enable authentication of system components, data integrity protection and data encryption. It will also be developer friendly–providing a choice of protocols, cryptographic algorithms, integrity tag modes and security protection levels.

This post will explain our motivation for creating a new standard security framework, provide an overview of the specifications and describe the flexibility that we’ve built into the framework. To wrap up, we’ll share a preview of upcoming development efforts and let you know how to learn more and get involved in our work.

Trust in Embedded Electronic Systems

For consumers to trust their lives to automated vehicles and for companies to trust their businesses to smart connected factories, the embedded electronic systems that underpin these new services must be secure.

However, the challenges in securing these systems cannot be underestimated. The underlying components that make up these systems are becoming ever more numerous and distributed, and it is likely that these systems will consist of many complex subcomponents, each containing their own microprocessors, connected over a local network and sourced from multiple vendors. These challenges mean that traditional security practices, such as the use of proprietary security methods or purely physical security, are not practical or effective at securing complex embedded systems.

For the electronics industry to overcome these challenges, a new security framework for embedded systems is required.

A New Security Framework for Embedded Systems

Security threats have traditionally been regarded as external to an embedded system. For example, historically in the automotive industry, vehicle manufacturers made it difficult for someone to break into and start a vehicle; but, if physical entry was obtained, access to in-vehicle electronic systems was largely left unprotected and the data from these systems was easily accessible via the vehicle's OBD-II port.

For traditional vehicles this type of perimeter security may be acceptable, but for future generations of automated vehicles, where embedded electronic systems are tasked with making critical life-or-death decisions, such a security model is inconceivable. A new framework to secure such systems is essential to reduce risk and enable principles such as "zero-trust" and "end-to-end" security to be implemented within embedded systems.

Understanding this need, MIPI formed a Security Investigation Group in 2019 (a precursor to the current Security Working Group) to explore a security framework that could be applied to existing MIPI specifications used for embedded camera and display applications. The group was acutely aware that applying security to such embedded applications presents unique computation, power and heat dissipation challenges. This meant that the direct adoption of pre-existing security frameworks developed to secure computer networks or internet services, would likely not be a viable option.

The subsequent Security Working Group, established in 2021, identified the key requirements for embedded systems and evaluated which existing security standards could best serve as a basis for securing such systems.

The following requirements for a security framework were identified:

• Enable key security goals of authentication (one way and two-way/mutual, based on certificate or pre-shared key credentials), integrity protection (full/partial) and optional encryption
• Provide a choice of protocols, cryptographic algorithms, integrity tag modes and security protection levels to allow flexibility in implementation
• Be "source-selective," enabling the security level to be customized to the specific security requirements of the target application (e.g., a camera sensor application) and to system-level considerations such as power supply and heat dissipation
• Enable application-layer security–transcending any underlying communication network topology
• Enable "end-to-end" security, with data secured from data source (e.g., within a sensor) to data sink (e.g., within a SoC controller), avoiding risks of "multi-hop" security and "man-in-the-middle" attacks
• Target advanced driver-assistance systems (ADAS) and autonomous driving systems (ADS) applications initially, but also be applicable to other (e.g., machine vision) applications

Leveraging DMTF’s SPDM

Upon completion of the Security Working Group’s evaluation and through a liaison with DMTF.org, MIPI chose to leverage two DMTF specifications within its security framework: Security Protocol and Data Model (SPDM) specification (known as DSP0274) and Secured Messages using SPDM specification (known as DSP0277).

Use of SPDM, which itself leverages Transport Layer Security (TLS), provides flexibility and efficiency, having been designed to secure applications, such as within IT infrastructure, that present many similar challenges to securing the automotive applications initially targeted by the MIPI Security Framework.

SPDM is used within the framework to provide a full-system security-management suite that is used to authenticate components within the system; establish secure transport channels using session keys; and using these secure channels, read/write security context parameters within the system.

Initial Focus: Securing Image Sensor Data

Image sensors connected over long-reach in-vehicle networks are essential to the latest ADAS and ADS. Both the number and criticality of these image sensors deployed in safety-critical applications will continue to increase with each new generation of automotive architecture, and MIPI CSI-2 (coupled with a MIPI PHY such as A-PHY^®, or other MIPI-board approved PHY) has already become the de facto image sensor protocol within these architectures.

There is clearly a need to protect CSI-2 image sensor data from security risks such as the installation of illegitimate or substandard components, malicious manipulation of sensor data and potential privacy violations from unauthorized access to location-revealing images. To mitigate these threats, the MIPI Security Framework is designed to protect MIPI CSI-2 image data (and any associated command and control data) "end-to-end" between image sensor components and their related electronic control units (ECUs). This framework is uniquely effective in both its security extent and implementation flexibility.

Applying Security to MASS

The MIPI Security Framework was designed to complement MIPI Automotive SerDes Solutions (MASS), which provides a full stack of connectivity solutions for automotive applications.

As shown in the figure, the initial security specifications complement the MASS image sensor "stack" by adding security to both the Camera Service Extensions layer and the Command and Control Interface, meaning that security is applied at the application level to both the main data stream and any sideband command and control data. It should also be noted that the security services defined within the new specifications are fully complementary to the existing automotive functional safety services provided by MASS.

The initial release of the framework consists of four new specifications: 

• MIPI Security^℠ v1.0 provides the baseline specification that defines a system security management suite (based on the DMTF SPDM standard) and data service protocols to authenticate and establish secure sessions between system components and manage security contexts.
• MIPI Camera Service Extensions (CSE^℠) v2.0 adds security service extensions to apply data integrity protection and optional encryption to CSI-2 data. The previous version, CSE v1.0, supported the functional safety extensions to CSI-2 data.
• MIPI Command and Control Interface Service Extensions (MIPI CCISE^℠) v1.0 defines security extensions to apply data integrity protection and optional encryption to I2C based command and control interfaces.
• MIPI Security Profiles^℠ v1.0 defines a set of common security profiles to enable interoperability.

Application-Level "End-to-End" Security

A key requirement of the framework is to provide "end-to-end" security. Whereas other embedded security methods such as MACsec 802.1AE protect only the link layer and provide only multi-hop security within complex network topologies, the MIPI Security Framework provides application-level protection that protects across all physical attack points. The security it provides is "end-to-end," or "silicon to silicon," in that the security transcends all link layer components to provide complete security from the source of sensor data in sensor silicon to the ultimate sink of that data in the system-on-chip (SoC) silicon.

Being implemented at the application layer, end-to-end protection is guaranteed–irrespective of the underlying communication network and network topology (e.g., unicast, multicast, daisy-chain), providing complete flexibility for developers to leverage any combination of underlying network components (such as bridges, aggregators and forwarding elements) to achieve the most efficient solutions for their applications.

High Scalability Provides Flexibility

The framework is designed to be highly scalable, providing a high degree of implementation flexibility for application developers to balance required security levels against processing efficiency, implementation complexity, thermal regulation and power consumption.  

It provides this flexibility in four ways:

• Choice of implementing protocols. The framework allows the implementer to choose between two data service protocols. Each protocol embeds the necessary Message Authentication Code (MAC) for integrity protection into a CSI-2 data stream. The two data service protocols are called Service Extensions Packet (SEP) and Frame-Based Service Extensions Data (FSED). SEP-based security is provided by adding SEP headers and footers to each CSI-2 packet (or frame), whereas FSED security is provided via the addition of (up to) three additional CSI-2-based packets to an image frame. The choice of FSED or SEP security protocol is an implementation choice, and only one protocol is active in a system at a given time. Generally speaking, FSED is simpler than SEP; and if highly-granular per-packet security is required, then SEP should be selected (FSED only supports per-frame operation). If a simpler per-frame security is needed, then FSED may be selected (although SEP also supports a per-frame option). Both protocols can be implemented with a high level of commonality to enable dual-protocol implementations if required.

• Choice of ciphersuites. The framework defines two sets of data integrity protection algorithms (or ciphersuites) based on the desired sensor performance level–one for efficiency and one for performance. The "efficiency" ciphersuite provides AES-CMAC data integrity only (no encryption) and is targeted toward sensors with limited hardware resources typically operating below 2-Gbps data rates. The "performance" ciphersuite provides AES-GMAC data integrity and optional AES-CTR encryption and is targeted at sensors with dedicated hardware support for these security protocols and typically operating above 2-Gbps data rates. Both ciphersuites support use of AES with 128- and 256-bit key lengths.

• Choice of tag modes. Tag modes refer to the granularity and frequency at which the integrity Message Authentication Code (MAC) is computed and transmitted by the sensors. The framework offers multiple tag mode options when using both the SEP and FSED data service protocols. This allows the implementer to choose how often the tag is computed and transmitted. When using SEP, the implementer has the choice to send the MAC tag on a per-message, per-data-type or per-frame basis, whereas FSED operates only on a per-frame-basis. The per-frame tag modes for SEP and FSED are designed to support both performance and efficiency ciphersuites respectively. The different tag modes offer the ability to identify (verify) potential data modifications on different time-scales, packet-scales or frame partition-scales, meaning the different modes serve to modify the time scale on which integrity verification is performed. 

• Highly granular security controls. The framework enables a new security paradigm, which provides highly granular security controls over the different segments of the CSI-2 image frame to enable a "sliding scale" of security levels to be implemented. This scale includes: at the highest security level, applying full data integrity and encryption to the whole image frame; partial security levels, where source selective integrity protection is applied to a subset of data within an image frame; and the lowest security level, applying no data integrity. The level of security is configurable on a frame-by-frame basis with camera stream data being augmented with packets/messages containing the relevant security information.

What’s Coming Next and Available Resources

The initial suite of MIPI security specifications is well advanced, with three of the initial four specifications expected to enter the adoption process by the end of the year and the remaining specification, CCISE, scheduled to enter adoption in early 2024.

As covered in this post, the initial focus has been on creating a framework that enables security within MIPI CSI-2 based applications. But the work does not stop there, and future additions to the framework to secure other MIPI protocols are already underway. The immediate next goal is to add security to MIPI DSI-2^℠ display applications, again focused on automotive, with a target release date of late 2024.

To learn more about MIPI security, download the presentation and watch the recording from the January 2023 MIPI CSI‑2 Security Forum.

In addition, you can stay up to date on the latest specification releases, new resources and other activities by signing up or the MIPI Security mailing list.