• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Microcontroller Tips

Microcontroller engineering resources, new microcontroller products and electronics engineering news

  • Products
    • 8-bit
    • 16-bit
    • 32-bit
    • 64-bit
  • Applications
    • 5G
    • Automotive
    • Connectivity
    • Consumer Electronics
    • EV Engineering
    • Industrial
    • IoT
    • Medical
    • Security
    • Telecommunications
    • Wearables
    • Wireless
  • Learn
    • eBooks / Tech Tips
    • EE Training Days
    • FAQs
    • Learning Center
    • Tech Toolboxes
    • Webinars/Digital Events
  • Resources
    • Design Guide Library
    • DesignFast
    • LEAP Awards
    • Podcasts
    • White Papers
  • Videos
    • EE Videos & Interviews
    • Teardown Videos
  • EE Forums
    • EDABoard.com
    • Electro-Tech-Online.com
  • Engineering Training Days
  • Advertise
  • Subscribe

Navigating in-vehicle network communications securely

August 3, 2021 By Todd Slack Leave a Comment

Hardware security modules help thwart hackers bent on getting control of EVs.

Todd Slack • Microchip Technology
Roughly half of all new vehicles sold this year will be connected vehicles, and estimates are that figure will rise to around 95% by 2030. Those connections via Bluetooth, USB, LTE, 5G, Wi-Fi, and so forth have dramatically increased the attack surface that must be secured against hackers.

hacks
Well-publicized hacks make the need for device security obvious.

The vehicle Controller Area Network (CAN bus) is a common target for hackers. Demonstrations have shown that hackers can exploit a bug in the Bluetooth protocol to gain access to the vehicle operating system. This attack vector, in turn, provided remote access to manipulate messages on the CAN bus.

Modern vehicles can have up to 100 ECUs with many safety critical ECUs communicating on the CAN bus. The CAN bus uses a simple protocol that is inexpensive, extremely robust, and relatively immune to electric disturbance which makes for reliable communication among safety critical nodes. The downside is that for decades, there has been zero security in the protocol. Hackers who gain access can send spoofed messages and wreak havoc on in-vehicle communications. Some examples include engaging or disengaging windshield wipers, turning off headlights, distracting the driver by manipulating audio, creating false instrument cluster alarms, incorrectly displaying speed, moving seats, or even driving the car off the road.

The good news is that with the advent of CAN FD (FD stands for flexible data rate, specified in ISO 11898-1) there are additional bytes available in the message payload to add security. CAN FD includes a Message Authentication Code (MAC) to cryptographically verify the authenticity of the message, thereby filtering out any spoofed messages. There are two types of MACs to choose from: A hash-based HMAC or an AES symmetric key block cypher based CMAC. CMAC is implemented the overwhelming majority of the time.

OEMs have been busy updating their cybersecurity specifications in response to the numerous hacks. Almost all OEMs now require safety critical ECUs to implement new cybersecurity requirements, and some OEMs require that 100% of connected ECUs be upgraded.

The foundational security block is to implement secure boot. Secure boot involves cryptographic verification that the boot and application code is unchanged and is in a trusted state at power-on. And verification is often repeated at a prescribed cadence once booted.

A close second in security procedures is the requirement to support secure firmware updates. Of course, all software can be subject to bugs; so firmware bug patches that can be applied in the field are often a necessity. These firmware updates also require cryptographic security. Typically incoming firmware payloads encrypted with a symmetric (AES) key and signed with an asymmetric private key, most often Elliptic Curve Cryptography (ECC). (As a brief review, with a symmetric key, the same key is used to encrypt and decrypt the message. With asymmetric keys, two different keys, called the public and private keys, are used. ECC is based on the algebraic structure of elliptic curves over finite fields and allows use of smaller keys compared to non-EC cryptography.)

The third addition in security evolution is message authentication. When an encrypted image is presented to the host controller, no action is taken until the signature of the payload is verified by the public ECC key embedded in the controller. Once the signature is verified, the image can be decrypted and the controller firmware upgraded with the bug patch or feature enhancement.

AES basics

The Advanced Encryption Standard is a symmetric block cipher. A block cipher is a deterministic algorithm operating on fixed-length groups of bits called blocks. AES actually includes three block ciphers: AES-128, AES-192 and AES-256. The numbers denote the number of bits in the key used to encrypt and decrypt a block of messages. Thus each cipher encrypts and decrypts data in blocks of 128 bits using cryptographic keys of 128, 192 and 256 bits, respectively.

The first step of AES encryption is to put the data into an array. Then the cipher transformations are repeated over multiple encryption rounds. A round consists of several processing steps that include substitution, transposition and mixing of the input plaintext to transform it into the final output of ciphertext. There are 10 rounds for 128-bit keys, 12 rounds for 192-bit keys and 14 rounds for 256-bit keys.

The first transformation in the AES encryption cipher is substitution of data using a substitution table; the second transformation shifts data rows, and the third mixes columns. The last transformation takes place on each column using a different part of the encryption key. Longer keys need more rounds to complete.

EV security

Unique to the electric vehicle space is the growing need for battery authentication. Most battery packs are comprised of replaceable battery modules so a module that fails can be replaced without replacing the entire pack. Poorly designed modules can be safety hazards that cause vehicle fires. Thus ecosystem management is important; each module must be cryptographically authenticated. Authentication verifies each module manufacturer has been vetted and approved by the OEM. Similarly, a module that does not cause fires but instead under-performs is equally bad. Poor performance can damage brand reputations, yet another reason to cryptographically verify who manufactured the module.

You might wonder what it means to cryptographically verify a battery module. The process is accomplished by setting up customer-specific signing keys. The keys are used to provision devices with customer-specific x.509 certificate chains and a unique device-level certificate based upon a unique ECC key pair. (An X. 509 certificate is a digital certificate employing the international X. 509 public key infrastructure (PKI) standard to verify that a public key belongs to the entity contained within the certificate.)

The provisioned device is mounted on each battery module. When a battery module is replaced within the pack the battery management system (BMS), also known as the battery gateway, will query the module for its unique X.509 certificate and verify the signature chains up to a trusted root.

After signature verification, the module is challenged with the task of signing the associated private key. Successful completion proves knowledge of a secret without transmitting it on the bus or via RF. The use case at the module level stops there.

Within the BMS, OEMs often require a more complex use case. The BMS/gateway is the communication point to the outside world providing routine battery health status reports to the cloud. So security for communication channel with the cloud may be expanded to include secure boot, secure firmware update, and Transport Layer Security (TLS, a standard protocol providing authentication, privacy and data integrity between two communicating computer applications).

The security implementations discussed here require secure key storage which can only happen via true hardware-based security. It can be easy to extract keys from standard microcontrollers, and even from many claiming to be “secure microcontrollers,” via standard attacks through micro-probing (attaching microscopic needles on the internal wiring of a chip), fault injection (by creating voltage glitches, clock glitches, injecting a temporal fault during a cryptographic operation with a laser module, etc.), electromagnetic side channel attacks (performing signal analysis on the electromagnetic radiation the device emits) , temperature/power cycling/supply glitching, and timing attacks, to name a few.

It is important to select the right device for cryptographic heavy lifting and to protect the keys against these sorts of attacks. Specialized security devices come in a variety of architectures. They have varying terminology like Hardware Security Modules (HSM) both on-die and external, secure elements, secure storage subsystems, key vault, smartcards, etc. All these devices must include tamper protection against the aforementioned attacks to prevent access to the keys in their secure memory.

When is security good enough?

The best way to prove security worthiness is to submit the secure device to a third-party for a vulnerability assessment. The third-party should be accredited by a trustworthy source like the National Institute of Standards of Technology (NIST) recognized in North America, the Federal Office for Information Security (BSI) in Germany, or the globally recognized Senior Officials Group Information Systems Security (SOGIS).

The TA100 CryptoAutomotive Security IC can be found in SOIC-8, SOIC-14, AND VQFN-24 packages and is powered by an internal MCU running dedicated software loaded into the ROM and nonvolatile memory during chip manufacture. Nonvolatile memory is used for certificate storage and secret/private key storage. There is no direct access to the memories from the external pins of the device and there is no available programming or debug interface.
The TA100 8-pin SOIC mikroBUS-compatible socket board helps develop systems employing TA100 HSMs. The TA100 secure elements are one-time-programmable devices. Having a socket board allows developers to reuse the board with multiple TA100 sample devices for a given application or for multiple different applications. The 8-pin SOIC socket board is capable of being used with versions of the TA100 device having I2C and SPI interfaces.

SOGIS-accredited labs use a globally recognized Joint Interpretation Library (JIL) vulnerability assessment scoring system which requires a “white box” assessment. The submitting IC vendor must provide the lab documentation on the device design. The documentation includes data-flow, sub-system, memory map definition, hardware and firmware start-up sequence, description of security protection mechanisms, full datasheet, security and bootloader guidance documentation, all code available (RTL and C level, crypto library, FW), algorithm implementations, programming scripts, communication protocol, die layout, and source code. The lab reviews all documentation and maps out a plan of attack against the submitted sample devices.

The scoring system allots points based on how long it takes to extract a secret key, the level of expertise required (recent college grad up to multiple experts), knowledge of the target of evaluation (TOE), access to the TOE (how many sample devices to perform a successful attack), hacking equipment complexity and cost, and ease of access to samples. JIL scores begin with no rating and progress to Basic, Enhanced Basic, Moderate, and High being the best achievable score. Anything below JIL High means the lab was able to extract private key(s) from the device.

Devices like Microchip’s CryptoAutomotive TrustAnchor100 (TA100) external HSM which have received a score of JIL High, are able to withstand attacks for more than three months of attack, at which point the lab declares the device “not practical” to attack.

On die or off die, that is the question. On-die solutions like 32-bit dual-core MCUs can represent an expensive upgrade to previous-generation ECU tasks perfectly well served by a standard MCU before true security became mandatory. Dual-core MCUs can also introduce significant development delays given the requirement to completely rearchitect the application code. It can be extremely risky to take on the security code development in-house and cost prohibitive to pay a third-party. It can also be difficult for Tier 1 suppliers to deploy the solution across multiple types of ECUs given that each type can have varying performance and peripheral requirements.

This is where external HSMs or companion secure elements can significantly reduce the security upgrade burden. They can be added to a standard MCU in an existing design or be bolted onto all new designs with different host MCU requirements. External HSMs like the TA100 come pre-provisioned with all security code, keys and certificates. External HSMs are easily portable to any MCU given the associated crypto-library that is MCU agnostic.

With today’s connected cars and heavy in-vehicle network communications traffic, the need for automotive security clearly stretches far beyond car alarms. With safety and brand reputation at stake, it is as important as ever to select truly secure devices vetted by third parties when upgrading ECUs to satisfy the plethora of new OEM cybersecurity specifications.

References
Microchip Technology, “Optimizing Cybersecurity in Your Autonomous Vehicle Designs”

You may also like:

  • router security
    Worst suspicions confirmed: The terrible security of internet routers
  • BLE hacks
    Breaking BLE — Vulnerabilities in pairing protocols leave Bluetooth devices…
  • RF won't hurt you
    No, IoT RF radiation won’t cause a pandemic
  • lidar
    A better way to measure LiDAR
  • flash
    Flash memory keeps cars connected

Filed Under: Applications, Automotive, FAQ, Featured, Security Tagged With: FAQ, microchiptechnology

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Featured Contributions

Five challenges for developing next-generation ADAS and autonomous vehicles

Securing IoT devices against quantum computing risks

RISC-V implementation strategies for certification of safety-critical systems

What’s new with Matter: how Matter 1.4 is reshaping interoperability and energy management

Edge AI: Revolutionizing real-time data processing and automation

More Featured Contributions

EE TECH TOOLBOX

“ee
Tech Toolbox: Internet of Things
Explore practical strategies for minimizing attack surfaces, managing memory efficiently, and securing firmware. Download now to ensure your IoT implementations remain secure, efficient, and future-ready.

EE Learning Center

EE Learning Center

EE ENGINEERING TRAINING DAYS

engineering
“bills
“microcontroller
EXPAND YOUR KNOWLEDGE AND STAY CONNECTED
Get the latest info on technologies, tools and strategies for EE professionals.

RSS Current EDABoard.com discussions

  • What is the purpose of the diode from gate to GND in normal Colpitts oscillator Circuits?
  • How can I get the frequency please help!
  • 12VAC to 12VDC 5A on 250ft 12AWG
  • ILI9163 LCD driver
  • Elektronik devre

RSS Current Electro-Tech-Online.com Discussions

  • 100uF bypass Caps?
  • Fuel Auto Shutoff
  • Actin group needed for effective PCB software tutorials
  • how to work on pcbs that are thick
  • compatible eth ports for laptop

DesignFast

Design Fast Logo
Component Selection Made Simple.

Try it Today
design fast globle

Footer

Microcontroller Tips

EE World Online Network

  • 5G Technology World
  • EE World Online
  • Engineers Garage
  • Analog IC Tips
  • Battery Power Tips
  • Connector Tips
  • DesignFast
  • EDA Board Forums
  • Electro Tech Online Forums
  • EV Engineering
  • Power Electronic Tips
  • Sensor Tips
  • Test and Measurement Tips

Microcontroller Tips

  • Subscribe to our newsletter
  • Advertise with us
  • Contact us
  • About us

Copyright © 2025 · WTWH Media LLC and its licensors. All rights reserved.
The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of WTWH Media.

Privacy Policy