By navigating our site, you agree to allow us to use cookies, in accordance with our Privacy Policy.

Securing In-vehicle Network Communications

By Todd Slack, Security Product Marketing, Microchip Technology

Most people assume that the role of semiconductors in automotive security primarily revolves around car alarms and key fobs. Car theft is undoubtedly a concern, but electronic components such as internal electronic control units (ECUs) used for communications inside the vehicle and to the environment pose a greater security risk. These connected cars leverage technologies such as Bluetooth®, USB, LTE, 5G, Wi-Fi®, etc. It is estimated that close to 50 percent of all new vehicles sold last year were likely connected vehicles, and this is expected to go up to about 95 percent by 2030. While connected cars bring a world of convenience, it can also increase the attack surface. Automakers impacted by vehicle hacking have had to deal with expensive recalls, lawsuits, and reputational damage. While there are several ways to fight and minimize software bugs that make them accessible to hackers, it's near impossible to do away with them completely. As long as new code exists, hackers will find a way to introduce new bugs. Hackers often target the Controller Area Network (CAN bus) in a vehicle. For instance, a bug in the Bluetooth connection can provide a way into the vehicle operating system. In turn, this can be used to remotely manipulate messages on the CAN bus. Modern vehicles can have up to 100 ECUs, including several safety-critical ones. The CAN bus adopts a simple protocol that is low-cost, extremely robust, and reasonably immune to electric disturbance. Therefore, it is a reliable option for safety-critical nodes to communicate with one another. However, since there is zero security in the protocol, any successful hacking attempt can wreak havoc on in-vehicle communications. Whether it is engaging windshield wipers, turning off headlights, distracting the driver by controlling audio, creating incorrect instrument cluster alarms, displaying the wrong speed, moving seats, or driving the car off the road, these attempts can seriously compromise safety. Luckily, the advent of CAN FD can add a layer of security by sparing bytes in the message payload. It uses a Message Authentication Code (MAC) to cryptographically verify the authenticity of the message and filter out any spoofed messages. There are two types of MACs – a hash-based HMAC or the more popular AES symmetric key block cypher-based CMAC. OEMs are responding to security hacks by updating their cybersecurity specifications. While some have mandated the updating of their safety-critical ECUs, others are upgrading all of their connected ECUs. Cryptographic verification can help implement a secure boot. This means verifying that the boot and application code running on a host controller is in a trusted state at power on, reset, and often repeated at a prescribed cadence once booted. Another focus area is secure firmware updates, which also require cryptographic security implementations. Software can be a loophole for bugs and thus firmware bug patches are necessary for field applications. Typically, incoming firmware payloads are encrypted with a symmetric (AES) key and signed with an asymmetric private key, most commonly Elliptic Curve Cryptography (ECC). When the host controller is presented with an upgrade image, it does not take action until the signature of the payload is verified by the embedded public ECC key. Post verification, the image can be decrypted to make way for the controller firmware upgrade with a bug patch or feature enhancement. Battery Authentication With the growing adoption of electric vehicles, there is an increasing need for battery authentication. In general, battery packs are designed with replaceable battery modules within the larger pack. In case of any battery failures, it allows for the individual module to be replaced, rather than changing the entire battery pack. However, designing and authenticating the battery pack is important to minimize safety hazards, which may result in a vehicle fire. Cryptographic authentication of each module can help ensure that module is neither hazardous nor under-performing. Enforcement of ecosystem management by OEM does not only prevent potential hazards but also protects its brand reputation. Cryptographic authentication involves setting up customer-specific signing keys to provision devices with customer-specific x.509 certificate chains as well as a unique device level certificate based on a unique ECC keypair. The device is mounted on each battery module. In the event of a battery module replacement, the Battery Management System (BMS), also known as the battery gateway, will query the module for its unique X.509 certificate and validate the signature chains up to a trusted root. After validating the signature, a challenge is introduced to the module for authentication with the associated private key without transmission on the bus, sometimes via RF transmission. As the BMS/gateway is the communication point to the external world to provide regular battery health status reports to the cloud, the security use case can include functions such as secure boot, secure firmware update, as well as Transport Layer Security (TLS) to create a secure communication channel with the cloud. All the security implementations require secure key storage, which involves solid hardware-based security. Standard attacks such as micro-probing, fault injection, electromagnetic side-channel attacks, temperature/power cycling/supply glitching, and timing attacks can often compromise even secure microcontrollers. Therefore, selecting the right device that can perform cryptographic heavy lifting as well as to protect the keys against these sorts of attacks is essential. Specialized security devices come in a variety of architectures including Hardware Security Modules (HSM) both on-die and external, secure elements, secure storage subsystems, key vaults, smartcards, etc. These devices must protect the keys in secure memory from the above attacks. Assessing Vulnerability OEMs can verify the effectiveness of their security implementations through a third-party vulnerability assessment. The third party must be accredited by trustworthy sources such as the National Institute of Standards of Technology (NIST) in North America, the Federal Office for Information Security (BSI) in Germany, or the globally recognized Senior Officials Group Information Systems Security (SOGIS). SOGIS accredited labs rely on an internationally recognized Joint Interpretation Library (JIL) vulnerability assessment scoring system that requires a “white box” assessment. The IC vendor is required to provide lab documentation on the device design such as dataflow, sub-system, and memory map definition. Other details such as hardware and firmware start-up sequence, description of security protection mechanism, full datasheet, security and bootloader guidance documentation, code, algorithm implementation, programming script, communication protocol, die layout, and source code are also required. The lab reviews the submitted information and then conducts attacks against the sample devices. Points are allotted based on a variety of factors such as the time taken to extract a secret key, level of expertise required, knowledge and access to the target of evaluation (TOE), hacking equipment complexity and cost, ease of access to samples, etc. The devices are scored as ‘No Rating’, ‘Basic’, ‘Enhanced Basic’, ‘Moderate’, or ‘High’. Anything other than a ‘High’ rating implies that the lab was successful in extracting private key(s) from the device. Devices such as Microchip’s CryptoAutomotive™ TrustAnchor100 (TA100) external HSM that have a JIL “High” score are able to withstand attacks for over 3 months, at which point the lab declares the device “Not Practical” to attack. On Die Versus Off Die HSM For previous generation ECUs served by standard MCUs, on-die solutions such as 32-bit dual-core MCUs prove to be an expensive upgrade to fulfill security mandates of OEMs. These can also slow down time to market since they require the application code to be completely rearchitected. In-house security code development can be risky while outsourcing it to a third party can be cost-prohibitive. For Tier 1 suppliers, dealing with multiple types of ECUs with varying performance and peripheral requirements can be challenging. External HMS’ or companion secure elements can help address this by significantly reducing the security upgrade burden for Tier 1 suppliers. They can either be added next to a standard MCU in an existing design or bolted onto all-new designs with different host MCU requirements. External HSMs such as TA100 come pre-provisioned with security code, keys, and certificates which help to significantly reduce the time to market. Since the crypto-library is MCU agnostic, it can be used with any MCU. By reducing risk, time to market, and the overall cost, Tier 1 suppliers have an opportunity to get ahead of their competitors who take the fully rearchitected path. With safety and brand reputation being top concerns in the age of connected cars and heavy in-vehicle network communications traffic, it is more important than ever to select truly secure devices. Choosing devices that are vetted by third parties and follow government and compliance mandates is most critical.Most people assume that the role of semiconductors in automotive security primarily revolves around car alarms and key fobs. Car theft is undoubtedly a concern, but electronic components such as internal electronic control units (ECUs) used for communications inside the vehicle and to the environment pose a greater security risk. These connected cars leverage technologies such as Bluetooth®, USB, LTE, 5G, Wi-Fi®, etc. It is estimated that close to 50 percent of all new vehicles sold last year were likely connected vehicles, and this is expected to go up to about 95 percent by 2030. While connected cars bring a world of convenience, it can also increase the attack surface.

Automakers impacted by vehicle hacking have had to deal with expensive recalls, lawsuits, and reputational damage. While there are several ways to fight and minimize software bugs that make them accessible to hackers, it’s near impossible to do away with them completely. As long as new code exists, hackers will find a way to introduce new bugs.

Hackers often target the Controller Area Network (CAN bus) in a vehicle. For instance, a bug in the Bluetooth connection can provide a way into the vehicle operating system. In turn, this can be used to remotely manipulate messages on the CAN bus. Modern vehicles can have up to 100 ECUs, including several safety-critical ones. The CAN bus adopts a simple protocol that is low-cost, extremely robust, and reasonably immune to electric disturbance. Therefore, it is a reliable option for safety-critical nodes to communicate with one another. However, since there is zero security in the protocol, any successful hacking attempt can wreak havoc on in-vehicle communications. Whether it is engaging windshield wipers, turning off headlights, distracting the driver by controlling audio, creating incorrect instrument cluster alarms, displaying the wrong speed, moving seats, or driving the car off the road, these attempts can seriously compromise safety. Luckily, the advent of CAN FD can add a layer of security by sparing bytes in the message payload. It uses a Message Authentication Code (MAC) to cryptographically verify the authenticity of the message and filter out any spoofed messages. There are two types of MACs – a hash-based HMAC or the more popular AES symmetric key block cypher-based CMAC.

OEMs are responding to security hacks by updating their cybersecurity specifications. While some have mandated the updating of their safety-critical ECUs, others are upgrading all of their connected ECUs. Cryptographic verification can help implement a secure boot. This means verifying that the boot and application code running on a host controller is in a trusted state at power on, reset, and often repeated at a prescribed cadence once booted. Another focus area is secure firmware updates, which also require cryptographic security implementations. Software can be a loophole for bugs and thus firmware bug patches are necessary for field applications. Typically, incoming firmware payloads are encrypted with a symmetric (AES) key and signed with an asymmetric private key, most commonly Elliptic Curve Cryptography (ECC). When the host controller is presented with an upgrade image, it does not take action until the signature of the payload is verified by the embedded public ECC key. Post verification, the image can be decrypted to make way for the controller firmware upgrade with a bug patch or feature enhancement.

Battery Authentication

With the growing adoption of electric vehicles, there is an increasing need for battery authentication. In general, battery packs are designed with replaceable battery modules within the larger pack. In case of any battery failures, it allows for the individual module to be replaced, rather than changing the entire battery pack. However, designing and authenticating the battery pack is important to minimize safety hazards, which may result in a vehicle fire. Cryptographic authentication of each module can help ensure that module is neither hazardous nor under-performing. Enforcement of ecosystem management by OEM does not only prevent potential hazards but also protects its brand reputation.

Cryptographic authentication involves setting up customer-specific signing keys to provision devices with customer-specific x.509 certificate chains as well as a unique device level certificate based on a unique ECC keypair. The device is mounted on each battery module. In the event of a battery module replacement, the Battery Management System (BMS), also known as the battery gateway, will query the module for its unique X.509 certificate and validate the signature chains up to a trusted root. After validating the signature, a challenge is introduced to the module for authentication with the associated private key without transmission on the bus, sometimes via RF transmission. As the BMS/gateway is the communication point to the external world to provide regular battery health status reports to the cloud, the security use case can include functions such as secure boot, secure firmware update, as well as Transport Layer Security (TLS) to create a secure communication channel with the cloud.

All the security implementations require secure key storage, which involves solid hardware-based security. Standard attacks such as micro-probing, fault injection, electromagnetic side-channel attacks, temperature/power cycling/supply glitching, and timing attacks can often compromise even secure microcontrollers. Therefore, selecting the right device that can perform cryptographic heavy lifting as well as to protect the keys against these sorts of attacks is essential. Specialized security devices come in a variety of architectures including Hardware Security Modules (HSM) both on-die and external, secure elements, secure storage subsystems, key vaults, smartcards, etc. These devices must protect the keys in secure memory from the above attacks.

Assessing Vulnerability

OEMs can verify the effectiveness of their security implementations through a third-party vulnerability assessment. The third party must be accredited by trustworthy sources such as the National Institute of Standards of Technology (NIST) in North America, the Federal Office for Information Security (BSI) in Germany, or the globally recognized Senior Officials Group Information Systems Security (SOGIS). SOGIS accredited labs rely on an internationally recognized Joint Interpretation Library (JIL) vulnerability assessment scoring system that requires a “white box” assessment. The IC vendor is required to provide lab documentation on the device design such as dataflow, sub-system, and memory map definition. Other details such as hardware and firmware start-up sequence, description of security protection mechanism, full datasheet, security and bootloader guidance documentation, code, algorithm implementation, programming script, communication protocol, die layout, and source code are also required. The lab reviews the submitted information and then conducts attacks against the sample devices. Points are allotted based on a variety of factors such as the time taken to extract a secret key, level of expertise required, knowledge and access to the target of evaluation (TOE), hacking equipment complexity and cost, ease of access to samples, etc.

The devices are scored as ‘No Rating’, ‘Basic’, ‘Enhanced Basic’, ‘Moderate’, or ‘High’. Anything other than a ‘High’ rating implies that the lab was successful in extracting private key(s) from the device. Devices such as Microchip’s CryptoAutomotive™ TrustAnchor100 (TA100) external HSM that have a JIL “High” score are able to withstand attacks for over 3 months, at which point the lab declares the device “Not Practical” to attack.

On Die Versus Off Die HSM

For previous generation ECUs served by standard MCUs, on-die solutions such as 32-bit dual-core MCUs prove to be an expensive upgrade to fulfill security mandates of OEMs. These can also slow down time to market since they require the application code to be completely rearchitected. In-house security code development can be risky while outsourcing it to a third party can be cost-prohibitive. For Tier 1 suppliers, dealing with multiple types of ECUs with varying performance and peripheral requirements can be challenging.

External HMS’ or companion secure elements can help address this by significantly reducing the security upgrade burden for Tier 1 suppliers. They can either be added next to a standard MCU in an existing design or bolted onto all-new designs with different host MCU requirements. External HSMs such as TA100 come pre-provisioned with security code, keys, and certificates which help to significantly reduce the time to market. Since the crypto-library is MCU agnostic, it can be used with any MCU. By reducing risk, time to market, and the overall cost, Tier 1 suppliers have an opportunity to get ahead of their competitors who take the fully rearchitected path.

With safety and brand reputation being top concerns in the age of connected cars and heavy in-vehicle network communications traffic, it is more important than ever to select truly secure devices. Choosing devices that are vetted by third parties and follow government and compliance mandates is most critical.

Tags

BiS Team

BIS Infotech is a vivid one stop online source protracting all the exclusive affairs of the Consumer and Business Technology. We have well accomplished on delivering expert views, reviews, and stories empowering millions with impartial and nonpareil opinions. Technology has become an inexorable part of our daily lifestyle and with BIS Infotech expertise, millions of intriguers everyday are finding for itself a crony hangout zone.

Related Articles

Upcoming Events