Processes & Standards
How we develop secure software for cars.
As no system can be 100% secure, developing secure software means defending it against well-defined threats, and one of the best ways to protect a system is by trying to attack it. That’s why in the process of risk assessment, our engineers and security experts explore potential threats by “thinking like a hacker”. In this process, a threat is described by different aspects:
The concept below is an exemplary design on how to defend the gateway ECU. It addresses risks across the entire development cycle, from the people that write the software all the way to the external services on the internet. The architecture utilizes a concept called “Defense in depth” which means that different layers of protection are implemented to stop attackers from compromising the system. The concept is a result of a careful evaluation of which threats are statistically likely to happen along with what is economically feasible to implement.
Awareness | Device | Network | |||||
People (Example) Threat | Organization Threat | Supply Chain Threat | Hardware Threat | Embedded Software Threat | In-Vehicle Network Threat | External lnterface Threat | Cloud Threat |
Mitigation | Mitigation | Mitigation | Mitigation | Mitigation | Mitigation | Mitigation | Mitigation |
Processes & Standards Controlling who in an organization has access to what, and how they gain access or make use of their access. This is to prevent unauthorized parties from gaining access to confidential information or important assets, and can also control proper usage and security of this information or these assets even for those authorized to access them. | HW/SW Robustness and Hardening The reduction of the surface of vulnerability of a piece of hardware or software by removing possible channels of attack, such as removing unnecessary features, services, and connections, or deactivating these by default until needed at a later point. Hardening can also involve the automated or manual analysis of hardware and software for faults and vulnerabilities, and modifying the vulnerable pieces to remove the security flaws. | Packet Filtering Filtering of unknown or blacklisted packets to ensure that only valid packets of information are read and processed. | RXSWIN Regulation X Software Identification Number: This is an identifier each vehicle may one day have to have to be authorized to receive over the air software updates, requested by car manufacturers and approved by government agencies. | ||||
Training Training employees on what needs to be protected, and how they are to help protect the organization. This can range from having employees verify that all employees display a badge in the office proving that they’re employees, to ensuring that guests aren’t allowed entry to the business premises unless they are accompanied by an employee. | Key Management System Vehicle Key Management Systems manage the security and encryption keys that vehicles use to secure their information, whether it’s stored in the vehicle or communicated to an external service. These key management systems will generate, certify, distribute, use, and eventually revoke security and encryption keys to ensure the confidentiality of the keys themselves. | HSM Hardware Security Module (HSM) is a hardened, tamper-resistant, physical computing device which handles storage, processing, and management of cryptographic keys. HSMs are used for encryption and decryption of data, along with the creation and verification of digital signatures. | OTA Update Enabling every vehicle to download software remotely, over the air (OTA). This functionality allows the introduction of software updates without the need for the driver to come into the body shop. All data is itself encrypted and sent with encrypted connections, with signature checks at every step. | ||||
Secure Environment A system which implements controlled storage and usage of information, protecting that information from data loss events or system compromises. | FDS Failure Detection System (FDS): When a component begins to behave aberrantly, either by responding too slowly, too quickly, erratically, or not responding at all, a failure can be detected and countermeasures can be deployed to prevent the failed component from impacting the rest of the system. | Authentication Authentication means that the data has not been modified while in transit, and the receiver can verify the source. | App/Diag Filter A firewall to filter out unknown or unallowed application or diagnostic requests coming from any part of the vehicle. This can block or delay hackers from trying to compromise the vehicle through a standard diagnostic port, or from having already compromised another component in the vehicle and sending bad requests from the compromised component. | ||||
Jtag Lock Locking the JTAG interface so that only authorized users can access the interface, or entirely burning some of the JTAG pins to prevent anyone from using the JTAG interface as a device is leaving the manufacturing plant. | VLAN IDs Assigning IDs to all known devices in a Virtual Local Area Network, and only accepting messages coming from those devices to eliminate the potential for unknown devices to be introduced to the vehicle in an attempt to compromise it. | Access Control Limiting the vehicle’s connection access to only pre-approved servers which can prove their identities. | |||||
IDS Intrusion Detection System (IDS): When an interface begins to behave erratically, either by sending abnormal messages, or sending messages at abnormal times, it may be possible that there has been an intrusion in the system where an attacker has replaced a component with their own malicious component. An intrusion detection system can detect these unauthorized entries into the system and execute predefined security measures to prevent further impact to the system. . | E2E-TLS End-to-End Transport Layer Security provides a cryptographic protocol to enable encrypted communications to and from the vehicle without allowing any other listener to be able to decrypt the messages or modify them without being detected. | ||||||
Isolated Execution Providing contained runtime environments where systems can be run in isolation from one another, such that in the event of one system compromise the integrity of all other systems is unaffected. | |||||||
Secure Storage Secure storage of data on hardware such that external sources cannot understand or access the stored data due to data encryption and restricted data access. | |||||||
Secure boot Authenticating that the applications that are stored in the system’s long-term storage have been signed by an authorized party, preventing unknown and unauthorized applications from running on the hardware. | |||||||
Runtime protection Analyzing inputs to a system in real time to detect whether an input could compromise the integrity of the software. If an input is found to be capable of compromising the system, predefined security measures are executed to attempt to prevent the potential system compromise. | |||||||
Correct implementation and execution of security measures is what counts when satisfying the criteria of a security concept. Poor implementation decisions can lead to unexpected failures of security measures, and can even create new vulnerabilities themselves. To guarantee higher code quality and minimize the possibility for errors and resulting vulnerabilities, we follow security best practices:
To make sure that the software we developed is behaving exactly as defined, doesn’t collapse when confronted with unexpected circumstances, and is not compromised when targeted directly through an orchestrated attack, we perform four categories of tests:
Security does not stop after the software went live in cars. To make sure that our systems remain secure after deployment we apply two main measures:
As systems become ever more complex, attackers find increasingly sophisticated ways to attack them. Our best weapon in this uphill battle is to hire exceptionally talented engineers and continuously invest developing their skills.