Single Blog Bubble Icon

With the addition of the MIPI Camera Service Extensions (CSESM) specification to Introspect Technology’s SV5C-DPTXCPTX and SV5C-DPRXCPRX, we are helping the automotive industry validate the security and functional safety features in next generation image sensors and electronic control units (ECUs). However, what really is the MIPI CSE specification and how is it related to the MIPI CSI-2® specification? Read on to learn how the industry is standardizing the process of encryption and security on vision systems developed for autonomous driving.

CSE is a Standardized Application Layer Above CSI-2

Increasingly, autonomous driving ECU architectures are focusing on ensuring security and functional safety in the entire data path from an image sensor (or radar sensor) all the way through the cables and bridge devices until the ECU processing engines. To achieve this, implementers are currently forced to create their own proprietary encryption and cryptography algorithms, and this is illustrated in Figure 1 (a).

Figure 1: Before (a) and after (b) integration of MIPI CSE.

 

The challenges with implementing proprietary cryptography algorithms are twofold. For one, there is significant engineering effort that needs to be applied on each system implementation. More importantly, the implementation of proprietary algorithms requires the addition of extra components and processing elements. This adds cost, weight, and complexity to any autonomous driving system.
So, the MIPI CSE specification is a standardized application layer for defining encryption and cryptography in a MIPI-based vision system, and this is illustrated in Figure 1(b). The arrival of this application layer can offer several benefits to system implementers. For example, if an image sensor integrates MIPI CSE directly into the sensor, a system integrator does not need to add extra components for encryption and message authentication. Additionally, any CPU or GPU maker can standardize the design of their receivers and thus reduce long-term nonrecurring engineering costs.
The inputs to a MIPI CSE block are varied, and they naturally include image sensor pixel data as well as control data related to authentication and encryption. At the same time, the output of a MIPI CSE block is always a CSI-2 stream. That is, to a low-level MIPI CSI-2 controller, the MPI CSE block appears as if it is a sensor, and this is described next.

The MIPI CSE Specification Transforms MIPI CSI-2 Streams

Referring to Figure 2, we see the two packet types supported in MIPI CSI-2. In the first part of the figure, we see a short packet definition, which is used for indicating Frame Start or Frame End packets. In the second part of the figure, we show a long packet structure. In a short packet, the source device (such as an image sensor) transmits 4 header bytes, and the header fields are largely unpopulated. There is no other data being sent after the header in a short packet. On the other hand, when a long packet is transmitted, the header bytes include important information such as the data type of the packet being sent, the number of words transmitted in the packet, and also some error correction codes. And of course, payload data is transmitted after the 4 header bytes, and two bytes are appended at the end of the packet for CRC.

CSI-2 short and long packets.
Figure 2: CSI-2 short and long packets.

 

Taking the Frame Start packet as an example, let us see how this simple packet is transformed by a CSE application layer. In Figure 3, we show the complete packet construction – of Frame Start – after it has been processed by the CSE layer. First, it is important to note that this is a 100% compatible CSI-2 packet. There is no change to the MIPI CSI-2 communication protocol whatsoever. We have simply transformed the short packet into a long packet. This is because the MIPI CSE layer has added “wrapper” information around the frame start packet. This wrapper information includes encryption among other things.

Complete MIPI CSI-2 packet illustration after processing by the CSE layer.
Figure 3: Complete MIPI CSI-2 packet illustration after processing by the CSE layer.

 

Now looking at the header bytes of this new packet in Figure 3, we see that the first byte has a value of 0x3E, and this is a new data type that tells the MIPI CSI-2 controller that the data being sent is “CSE data”. This is reminiscent of the 2E data type in CSI-2, which is used to denote non-image embedded data in CSI-2. The rest of the header is compliant to the MIPI CSI-2 protocol – for example, the bytes 0x12, 0x00 indicate the word count in this long packet, and the last two bytes are CRC bytes.
Other than the header and CRC bytes, why did we need to send 18 payload bytes to simply indicate a frame start? This is the crux of the MIPI CSE specification. It encrypts the data being sent so that sniffing the packet would not reveal whether it was a Frame Start or not. And it also adds authentication messages to help the receiver decrypt the packet. It is a complex protocol, but do not despair because Introspect has complete validation capability, and this is described next!

Introspect’s MIPI CSE Specification Validation and Vector Generation

Introspect has developed a complete set of tools for generating CSE data (from image sensor data) and for decoding and validating CSE encrypted data. This makes the process of designing a CSE application layer so much easier, and it also ensures that the industry has a golden standard for interoperability testing. Referring to Figure 4, we show an example protocol capture of a MIPI CSE stream. As can be seen, the top part of the viewer shows the time course of packets being received, and they are all denoted as “sep” or “3E” packets. That is, details about the CSI-based frame are completely obfuscated due to the packetization provided under the service extension packet (sep) protocol. Then, the bottom panel shows how a single one of these “sep” packets is decoded, and this reveals the underlying image transmission being defined in that packet. Specifically, the packet shown in this figure is an RGB888 long packet. We also see the message authentication code (mac) value of 0xE199122C. Obtaining this kind of detailed information is critical to rapidly designing and validating the MIPI CSE specification.

 

CSE test result packet
Figure 4: Example capture of MIPI CSE stream with Introspect’s SV5C-DPRXCPRX Protocol Analyzer.

 

Below is a short video introduction to MIPI CSE Analysis License with Introspect’s award-winning Pinetree software. Viewers will learn how to send a CSI image pattern and enable CSE security settings.

 

Summary

The MIPI CSE specification is an application layer that sits on top of the MIPI CSI-2 low level protocol. In this blog, we introduced the basic concepts of this application layer and how it is used to transform image sensor data into encrypted CSI-2 packet streams. As you can imagine, the MIPI CSE specification is a very complex protocol, and it includes so many variations/options for both security and functional safety. Without the Introspect tools for validating all these options, the design of secure autonomous driving systems becomes a very daunting task!

So, here’s to a safer ride during your next summer road trip.

For more information on Introspect’s CSE and CSI-2 solutions, send us an email at info@introspect.ca.

Single Blog Bubble Icon
Copyright © 2023 Introspect Technology