Resources

The automotive industry is getting more and more mature in the development of secure products. However, this is only the enabler of building vehicle ecosystems resilient against the cybersecurity threats, and it still needs further countermeasures related to the product. Although ISO/SAE 21434 provides an entire chapter covering assembly phase of the product lifecycle, it leaves the implementation to the companies. Product cybersecurity matters at the production line are way beyond OT (Operational Technology)security.

 
In this article we will discuss the major concerns and best practices to control cyber risks introduced by the production process. This way we will take another step towards a world where the steering wheel remains in the hands of the road users. 

 

Case study – Battery Management Sensor (BMS)

To escort our readers towards the understanding of the situation with the product cybersecurity at the assembly process, we take a simple, small ECU as an example, the BMS. It is a battery management sensor, which – in our case - contains a TITMS microcontroller with JTAG (Joint Test Action Group)debug interface and internal flash which implements LIN (Local Interconnect Network) communication and BSL (Boostrap Loader) interface. It also contains a shunt resistor as well, which is used for measuring the current running towards to the battery ground connector. 

What does the BMS do? It measures the battery voltage to provide feedback about both charge level and battery health. By this the primary goal is to decide whether the vehicle can trigger the auto start and auto stop feature of the engine to preserve the fuel consumption. However, it is useful for maintenance as well to be able to decide whether the battery is facing the end of his life cycle. 

What can happen if we start to abuse these features? The battery can eventually go dead if we kill it by spoofing/tampering BMS signal causing Denial of Service. However, it can cause DoS for all the features relying on the battery charge level as well. 

 

How do the BMS gets into the car?

It starts at the semicounductor factory, where the microcontroller unit peripherals are created on the silicon wafer during the manufacturing process. Then in the production process they set up the default MCU (Microcontroller Unit) configuration. After this the Boot ROM (Read Only Memory) firmware is written to the MCU to a one-time programmable areaand the default Boot Sequence is set for the MCU.

After the MCU leaves the semiconductor factory it is shipped to an electronic factory with ECU product lines. There the firmware gets flashed onto the MCU to implement system functionality, and the sensor calibration data is adjusted in the MCU, for example to compensate random offsets. After this, manufacturing locks might be saved onto the product to provide the evidence that due care and the due diligence was carried out at the manufacturing process by the organization. Next the supplier secrets (e.g., keys, passwords etc.) are flashed onto the MCU. It is important that the Security Configuration should be modified before shipping the MCU to the customer. 

The final step for the system is to be integrated into a vehicle by a well-known global OEM (Original Equipment Manufacturer). The logs can be put in the retention on a server to preserve for later use and might be deleted from the MCU to provide space for additional applications or data. The further calibration data (e.g. adjusting type of battery to the MCU) can also be set. A certain set of crypto data (e.g., keys, certificates) should be replaced as well to assure the OEM control on cybersecurity functions. Then the vehicle data is set to bound the component to the vehicle ecosystem, for example the identification number of the vehicle and the engine. This way the BMS (Battery Management System) of theECU (Electronic Control Unit) will be an integral part of the vehicle ecosystem. 

However, what have we seen so far in this scenario? The road to the roads. The MCU was manufactured in a semiconductor factory in China, then it was shipped to an Indonesian electronical device factory. After that the ECU was shipped back to China for being stored in a Centre of Logistics, and as the next step the system was shipped to Japan to make a vehicle. After this long way the vehicle was then shipped to other parts of the world where it can get further customization in dealership garages. 

 

The product manufacturing puts the cyber security of the product at risk

Here we can talk about three things: confidentiality, availability and integrity. 

Let’s start with confidentiality. Confidential data is accessed and managed during production by human and technical actors. By confidential data we can think about symmetric keys and passwords, Intellectual Property, and even other crypto-material like the unique identification number of the MCU. 

There is also availability aspect of the data. There is a lot of data generated, for example the logs and ECU-unique crypto material. The loss of certain data can cause a serious issue and can make maintenance and warranty activities non-feasible. It can affect crypto-material for accessing debug ports and the assembly line of the test code. 

The integrity of the data is also a central aspect of the vehicle industry. The content of the ECU gets modified step by step during the supply chain. If it happens out of the OEM’s trust boundaries that is a nightmare for them because the contents get modified by unauthorized actors. For example, the electronic components can be modified, the software code and the configuration data can be compromised, and key material as well. It is important that all of them heavily influence the end behavior of the product. 

 

Confidentiality of product data during production 

The access policies to confidential data (at both physical and logical level) can be difficult to be maintained at the assembly lines. This is because there are multiple access points to the content of the data. There are many assembly phases that need the data for fulfillment of their objectives. Besides, the distributed access itself can be a reason as well. These phases are sharedin most of the cases between several companies in a complex supply chain, therefore a certain amount of confidential information will necessarily leave the boundaries of its owners. The owners haveno direct control on the data that is used outside of their boundaries. These threats may target distributed confidential information for broad audience, by stealing the data carrier containing confidential information, copy the data from the carrier or using the data breach of the IT system to get this information. 

What might be the best practices to handle this kind of security concerns? 

• Non-Disclosure Agreement for secret data: It should be done both inside of the organizations with the employees and outside of the organizations with the supplier. With this the complete risk is not taken care of, but at least there is legal evidence in our hand.

• End-to-End encryption for the secret data: It should be practiced both inside and outside of the organization to prevent the eavesdropping of the communication lines from getting the secrets we want to protect. The best solution is to encrypt the data before being sent and decrypted only inside the MCU. For this, only the secrecy of one master key shall be maintained in the wild unsecure world. 

• Principles of need-to-know and least privilege: We should only distribute the information to the entities who certainly need it and avoid sending any information which is unnecessary for their operation. With this way we can reduce the attack surface and limit the amount of data lost in case of a breach. 

• Temporary data that should be finalized in-house: We should change secret materials to the final ones managed and known by only them, as soon as the product reaches their perimeters. This way even if one of our suppliers get a data breach, then it won't have any effect to the crypto materials they use inside our product. 

• Disable the black doors for the product before shipment: This way if any malicious actor gets access to the product, they won't be able to get the data via the abuse of the debug interfaces. 

 

Integrity of product data during production 

The integrity of the product data is important both for the data received by the organization and also the data sent by the organization. 

For the data received by the organization, the first we should ensure is the chain of custody. We should make sure that our suppliers seal the backdoors before shipment to prevent the unauthorized access. We should also check the data for unauthorized modification. 

There are some practical examples for protecting the integrity of the product data received from our suppliers. The first and the best is torequire the them to digitally sign the memory content of the ECUs with leveraging a PKI (Public KeyInfrastructure). However, if it is not possible, requiring the supplier to create hashes according to the ECU content and to send those hashes out-of-band can work as well.   

For the data sent by the organization, we also should make sure that we seal the backdoors for our product we ship to our customers as well, and that the appropriate content is being shipped by checking what do we ship within the ECUs and the work packages we are meant to provide (e.g., by taking snapshots, fingerprints according to the MCU contents). 

 

Availability of product data during production 

The production creates data that might be crucial for business continuity aspects of the organization. For example, snapshots, fingerprints, and test results related to the data stored on the product. These are necessary for carrying out warranty claim or forensic analysis in case if an integrity-related claim is raised during the product lifecycle. 

Crypto-material extracted from the product might also be necessary as well for certain purposes, for example for the derivation of keys for accessing ECU services. Without this data, these services might not be possible to be accessed. 

So, we can say that the Availability aspect of the production data should be revised carefully, while the definition of Cybersecurity Goals should also consider them. 

 

ISO/SAE 21434 on the Cybersecurity of the Assembly Line 

What does the ISO (International Organization for Standardization) standard of vehicle cybersecurity say about the assembly line, more precisely the production? Let’s take a look at some important clauses: 

• Clause 5:A cybersecurity management system for the production processes should be established in order to support the activities of clause 12. This is mostly an OT security topic that shouldbe addressed via coordination between different stakeholders of the organization.  

• Clause 10: Procedures to ensure cybersecurity after the development of the component should be specified, if applicable. There should be specified procedures for the correct integration and initialization of cybersecurity controls, as well as maintaining cybersecurity throughout production. As the outcome of these activities, there should be cybersecurity requirements for post development, which should contain the production-level controls.  

• Clause 12: A production control plan should be created that applies the cybersecurity requirements for post-development. It can be included as part of the overall production plan, but it can be a separate document as well. The plan should include the sequence of the steps that apply the cybersecurity requirements for post development, the production tools and equipment, cybersecurity controls to prevent unauthorized alteration during production, and the methods to confirm that the cybersecurity requirements for post development are met. 

So the ISO/SAE 21434 says that the production control plan should be implemented. It means that we should be able to set up what we plan to do, and then when we set up the plan, we should implement it as well. 

 

Production Control Plan

Just to summarize the topic, we should be able to tell that what do we leverage during the production. For example, what the software and the hardware toolchain is and what equipment we use. If we are aware of them, we should know the sequence of the steps that we plan to apply during the manufacturing of the product, because the cybersecurity requirement should be applied on them. And after all, the assurance steps ensuring that the cybersecurity of the product is unharmed in the end of the production line should be defined. If we manage to do it, then the cyber security controls in terms of both OT, IT and the product cyber security can be defined as well.  

 

The impact of PCAutomotive

And how can PCAutomotive support the organizations to overcome the challenges manifested by the production and the supply chain? 

We provide Cybersecurity Consultation for Production also, which has two dimensions. The first dimension is Compliance Consultancy. It is for meeting the requirements for the needed regulations and standards. These services contain the provision of the document templates and process development activities. 

On the other hand, PC Automotive is eager to have Technology Consultancy, which contains multiple pillars. One of them is TARA (Threat Analysis and Risk Assessment method) which includes the production dimension as well, which makes it unique on the market, while the other is Production Control Planning, enabling the organizations to keep the security risk related to the assembly line under the threshold, while keeping the financial cost necessitated by these additional, cyber related steps in a reasonable amount, enabling a profitable operation.