The use of cameras is essential to advanced driver assistance systems and autonomous driving. Today, the systems used to deliver the most advanced SAE level 2 features typically utilize up to six cameras. This number is projected to increase significantly over time, with one OEM indicating the need to integrate up to 45 cameras and other sensors, including radars and lidars to deliver the most advanced level-3 ADAS features and pave the way for higher levels of automation.
It is essential for OEMs to not only make their camera-enabled ADAS systems functionally safe, but also ensure they are protected against cybersecurity risks such as installation of illegitimate substandard automotive imaging sensor components, malicious manipulation of sensor data to cause an ADAS or ADS failure, and privacy violations from unauthorized access to location-revealing images, internal cabin images and image-related metadata.
Key Camera Security Requirements
Recognizing the critical and sensitive role camera data plays within ADAS and ADS applications and the need to protect against identified cybersecurity risks, the following security requirements must be taken into consideration:
- End-to-end data protection. It is essential for automotive imaging systems to be protected "end-to-end," from the source of image data within each image sensor, to the data sink within the sensor’s corresponding ECU SoC. This requirement strongly favors the implementation of application layer security (as opposed to link layer), which by default, provides end-to-end security to the imaging system irrespective of the underlying communication network topology.
- Component authentication. Key components within the automotive imaging system must be trusted. This requires the capability to authenticate system components and facilitate the authentication of not only the camera image sensors (by the ECU), but also the authentication of other communication network components used to connect the image sensor to the ECU (e.g., SerDes bridges).
- Source-selective security. The authenticity and integrity of source automotive imaging data generated by the image sensors must be verified by the ECU. This requires adding authentication tags containing message authentication codes (MACs) to image data streams. Given the huge volume of automotive imaging data created by image sensors, this is not a trivial task, and advanced techniques such as implementing partial data integrity protection -- where the level of protection is "flexed" based on the criticality of the data sent within each image frame -- may be leveraged to optimize the overall system design. This can have the additional benefit of reducing the heat generated in or nearby the sensors and reducing system power consumption.
- Configurable data encryption. Where there is a risk of malicious data exfiltration from the imaging system, end-to-end data encryption may be applied to protect the image data generated by image sensors. Again, given the high data volume, solutions that allow the strength of encryption to be configured depending upon the level of risk should be leveraged to optimize the overall system design.
- Secure command and control interfaces. It is essential to secure camera command-and-control interfaces, which today typically leverage I2C side-channel interfaces, to mitigate risks arising from misconfigured sensors.
- Standards-based framework. Existing, industry-verified security standards should be leveraged within the automotive imaging system. A golden rule of cybersecurity is not to "cook your own" security mechanisms.
The security requirements identified above present several design challenges that must be overcome within the automotive imaging system. For instance:
- Similar to all other electronic systems within a vehicle, imaging system security functions must be designed to operate with strict power and heat dissipation targets to limit the overall cost and complexity of the system.
- Because of the massive amount of data generated by image sensors, these systems require the use of specialized high-speed SerDes communication links within a vehicle. It is essential that security functions operate with minimal data overhead, so they do not overburden SerDes bandwidth.
- To minimize cable harness weight and complexity, and to streamline system integration, multiple cameras within the imaging system may be connected using various communication network topologies such as in a daisy chain or tree structure. It is highly desirable that security functions are agnostic of the underlying network topology and enable end-to-end security irrespective of the network components (bridges, forwarding elements, etc.) used to provide the communication network.
- Because developing the in-vehicle network system for an automotive imaging system from scratch would be a significant undertaking, automotive architectures tend to evolve with each generation of a vehicle, rather than be redesigned each time. Therefore, the use of imaging system security protocols that are “end-to-end” and independent of the underlying in-vehicle network architecture greatly benefits system integrators.
MIPI Security Framework for Camera
MIPI Camera Serial Interface 2 (CSI-2) is widely used within vehicles on the road today. Developed initially for the mobile phone market, CSI-2 has become the de facto camera imaging protocol and has been used in billions of electronic devices. To address the need for a standardized SerDes solution to simplify the integration of cameras and displays in automotive, MIPI Alliance recently introduced a connectivity framework called MASS, short for MIPI Automotive SerDes Solutions.
The framework’s initial focus was the development of MIPI A-PHY, a long-reach, highly reliable, asymmetric serial interface with a reach of up to 15 meters. Specifications for built-in functional safety have been developed for the MASS framework, and in 2023 a suite of security specifications are being introduced to address the key security requirements for automotive cameras.
The specifications in the suite include:
● MIPI Camera Service Extensions (CSE) v2.0 – to apply data integrity protection and optional encryption to CSI-2 data. This is in addition to the functional safety services provided in CSE v1.0.
● MIPI Command and Control Interface Service Extensions (CCISE) v1.0 – to apply data integrity protection and optional encryption to the MIPI command and control (CCI) interface based on I2C.
● MIPI Security v1.0 – defines a system security management suite using the DMTF (Distributed Management Task Force) SPDM (Security Protocol and Data Model) architecture to authenticate and establish secure sessions between system components and manage security services such as those provided by CSE and CCISE.
● MIPI Security Profiles v1.0 – a set of common security profiles to enable interoperability, including profiling SPDM authentication mechanisms used in the MIPI Security specification.
These security specifications bring end-to-end security to automotive imaging applications that leverage MIPI CSI-2. The framework enables key security functionality, including authentication of system components, data integrity protection and data encryption. It provides implementers with a choice of security protocols, ciphersuites, integrity tag modes and security controls, providing a high degree of implementation flexibility to balance required security levels against processing efficiency, implementation complexity, thermal regulation and power consumption. A key attribute to achieve this flexibility is the framework’s support of source-selective security, which enables a developer to flex the level of security based on the structure of the CSI-2 image frame.
The key features of the MIPI security framework are:
- Choice of security protocol. Developers can choose between two MIPI data service protocols, the Service Extensions Packet (SEP) or Frame-Based Service Extensions Data (FSED). SEP-based security adds security headers and footers to each CSI-2 packet (or frame), whereas FSED security is a simpler approach that adds two or three additional CSI-2-based packets to an image frame to accomplish frame-based security. These protocols support the construction and transmission of Message Authentication Code (MAC) tags for integrity protection of the CSI-2 messages and support optional data encryption.
- Choice of ciphersuites. The framework defines two types of ciphersuite, one for efficiency and one for performance. The "efficiency" ciphersuites provide AES-CMAC data integrity only (no encryption) and are targeted toward lower performance sensors with limited hardware resources. The "performance" ciphersuites provide AES-GMAC data integrity and optional AES-CTR encryption and are targeted at higher performance sensors with dedicated hardware support. Both ciphersuites support use of AES with 128- and 256-bit key lengths.
- Choice of integrity tag modes. The framework offers multiple tag mode options when using the SEP and FSED protocols. This allows the implementer to choose how often MAC tags are computed and transmitted. For example, when using SEP, the implementer has the choice to send the Message Authentication Code (MAC) tag on a per-message, per-data-type or per-frame basis.
- Highly granular security controls. The framework allows highly granular security control over the different segments of the CSI-2 image frame to enable a “sliding scale” of security levels to be implemented. At the highest security level, full data integrity and encryption can be applied to the whole image frame; whereas at partial integrity levels, source selective integrity protection can be applied to a subset of data within an image frame. At the lowest security level, no data integrity can be applied to the image data. The level of security is configurable on a frame-by-frame basis.
The initial suite of four specifications is expected to be released in mid-2023. Future additions to add security for MIPI DSI-2 display applications, also targeted at automotive use, are slated for 2024.
Further information can be found on the MIPI website, where one can also view a recording of a recent MIPI security forum.
About the authors
Philip Hawkes is co-chair of the MIPI Security Working Group. His experience covers mobile networks, location technologies, IoT/M2M, WiFi and wired connectivity. Phil is currently a principal engineer, technology, at Qualcomm Technologies Inc., and started his career as a symmetric cryptography expert involved in both design and analysis of algorithms.
Rick Wietfeldt is co-chair of the MIPI Security Working Group and serves as vice chair of the MIPI Alliance Board of Directors. He is also a senior director, technology, at Qualcomm, where he established the Advanced Connectivity Technology office responsible for the standards development organizations (SDOs) that drive mobile interface standards. Rick is a frequent author and has been awarded numerous patents in mobile device architecture and operation.