Ensuring the safety of wireless battery management systems

In early discussions with electric vehicle (EV) OEMs about the technical and business benefits of wireless battery management systems (wBMS), it seems that there are many challenges, but if successful, the rewards are very large. The many inherent advantages of wireless connectivity over wired/wired architectures have been proven in countless commercial applications, and BMS is next.

Figure 1. Electric vehicle using a wireless battery management system (wBMS).

The benefits of lighter, modular and compact EV battery packs that are free of cumbersome communication harnesses are widely accepted. By eliminating up to 90% of battery pack wiring and 15% of battery pack volume, the overall vehicle design and footprint can be significantly simplified, as well as bill of materials (BOM) costs, development complexity and associated manual installation/maintenance costs.

More importantly, a single wireless battery design can be easily scaled across an OEM’s entire EV line, precluding extensive and costly redesign of battery pack harnesses for each make and model. With wBMS, OEMs are free to modify their vehicle frame designs without worrying about having to rewire.

In the long term, continued reductions in vehicle weight and battery pack size will be critical to extending the range of EVs in the coming years. As such, wBMS technology will continue to play an important role in helping OEMs improve range, thereby addressing range anxiety.

Not only is this expected to spur greater overall EV market adoption, but range will remain a key differentiator between EV OEMs in the future.

New safety standards

There are many challenges to overcome to realize the promise offered by wBMS. The wireless communications used in a wBMS need to be robust enough to interference while the car is in motion, and the system must be secure under all conditions. However, a robust and secure design alone may not be enough to combat hacking—that’s where system security comes into play.

Interference sources vary depending on where the car is traveling (urban vs. rural, for example) and whether someone is using another wireless device operating in the same frequency band in the car. Reflections within the battery pack can also degrade performance, depending on the materials used to house the battery cells. wBMS signals are likely to fluctuate, which can disrupt communications under natural conditions, not to mention in the face of malicious attackers.

If wBMS communications are disrupted in some way, the car can revert to a “safe mode,” reducing performance to allow the driver to take remedial action, or park safely in the event of a complete loss of wBMS communications. This can be achieved with a proper security design that considers all possible failure modes in the system and implements end-to-end security mechanisms that account for random failures of components.

But security design does not account for hacking, which could include remote control of the car. During the 2016 Black Hat conference, researchers demonstrated this possibility on a car, gaining remote access through the vehicle gateway. Therefore, wireless robustness and fail-safe design are not enough; they need to be complemented by information security. The Black Hat presentation was a valuable lesson that wireless systems in future cars cannot be used as just another remote interface. In contrast, traditional wired battery packs do not provide remote access, so to access battery data, hackers would need physical access to the high-voltage environment in the vehicle.

As shown in Figure 2, additional security challenges may arise throughout the EV battery lifecycle. At ADI, our approach to designing a wBMS focuses on understanding the different stages of an EV battery from birth to factory deployment and maintenance, and finally to the next lifecycle or end of life. These use cases define the various functions that a wBMS must support. For example, preventing unauthorized remote access is a consideration during EV deployment, but flexible access is required during manufacturing. Another example is repairability, where right to repair laws require vehicle owners to resolve issues caused by the battery or the associated wBMS. This means that a legal update must support the software in the wBMS, and the update mechanism should not compromise the safety of the vehicle.

In addition, when EV batteries no longer meet EV performance standards, they are sometimes redeployed in the energy sector. This requires securely transferring ownership of an EV battery from its first lifecycle to the next. Since batteries are devices without built-in intelligence, an accompanying wBMS is required to enforce appropriate security policies that best fit the EV battery lifecycle. Data stored in the automotive application needs to be securely erased before transitioning to its second use.

ADI anticipated these issues and addressed them based on our own core design principles, which place high value and exhaustive scrutiny on maintaining and enhancing security integrity from process to product. In parallel, the ISO/SAE 21434 standard on “Road Vehicles: Cybersecurity Engineering,” which has been in development for the past three years, was officially released in August 2021. It defines a similarly exhaustive end-to-end process framework with four levels of cybersecurity assurance. Automotive OEMs and suppliers are scored on a scale of 1 to 4, with 4 indicating the highest level of conformance (see Figure 3).

Figure 2. EV battery life cycle and its associated wBMS life cycle.

Figure 3. ISO/SAE 21434 framework and CAL 4 expectations.

ADI’s wBMS approach complies with the requirements of ISO/SAE 21434, which applies to the highest level of inspection and rigor required for safety product development in the automotive industry. To this end, ADI worked with TÜV-Nord, a well-known and trusted certification laboratory, to evaluate our internal development policies and processes. This resulted in our policies and processes being reviewed for full compliance with the new standard ISO 21434, as shown in Figure 4.


Figure 4. Certificate from TÜV-Nord.

Rigorous review from device to network

Following our systematic process in wBMS product design, a threat assessment and risk analysis (TARA) was conducted to map the threat state based on how customers use the product. By understanding the functions of the system and the various ways it will be used during its life cycle, we can determine which critical assets need to be protected and from which potential threats.

There are several options for TARA techniques, including the well-known Microsoft STRIDE approach, which attempts to model threats by considering the six threats abbreviated by the word STRIDE: deception, tampering, repudiation, information disclosure, denial of service, and escalation of privilege. We can then apply this to the different interfaces of the components that make up the wBMS system, as shown in Figure 5.

Figure 5. Threat considerations for wBMS.

These interfaces are natural stopping points along the data and control flow paths where potential attackers may gain unauthorized access to system assets. At these points, by playing the role of an attacker and attempting to access threat tests, we can map out possible attack paths and determine the likelihood of the threat occurring as well as assess the ultimate consequences. We then repeat this thought process at different lifecycle stages, as the likelihood and impact of threats may vary depending on the environment in which the product is located (e.g., warehouse vs. deployment). This information will indicate the need for certain countermeasures.

Take the wireless channel between the wireless monitor and the wBMS manager as an example, as shown in Figure 5. If the asset is data from the wireless monitor and there is a concern about the data value being leaked to an eavesdropper, then we may want to encrypt the data as it passes through the wireless channel. If we are concerned about the data being tampered with as it passes through the channel, then we may want to protect the data using a data integrity mechanism, such as a message integrity code. If the concern is identifying the origin of the data, then we will need a way to authenticate the wireless monitor to the wBMS manager.

Through this exercise, we can identify the key security goals for the wBMS system, as shown in Figure 6. These goals require some mechanisms to achieve.

Fig. 6. Security goals of wBMS.

Many times, we are often asked how far we have come towards a particular security goal. If more countermeasures are added, it will almost certainly improve the overall security posture of the product, but it will be costly and may cause inconvenience to the end consumer when using the product. A common strategy is to mitigate the most likely threats with the easiest to deploy. More complex attacks tend to target higher value assets and may require more robust security countermeasures, but these may be extremely unlikely and therefore have a low return on implementation.

For example, in a wBMS, it is extremely unlikely that the IC components can be physically tampered with to obtain battery data measurements while the vehicle is in motion, as it would take a highly trained mechanic with deep knowledge of EV batteries to control the car parts while the car is in motion. If they exist, a real-life attacker may try easier paths. A common type of attack on networked systems is a denial of service (DoS) attack - depriving the user of the product's utility. You can create a portable wireless jammer to try to interfere with wBMS functionality, but you can just as easily puncture a tire.

This step of reconciling risks with an appropriate set of mitigation measures is called risk analysis. By weighing the impact and likelihood of relevant threats before and after taking appropriate countermeasures, we can determine whether the remaining risk has been reasonably minimized. Ultimately, this can help customers meet the required security features at an acceptable cost.

The TARA for wBMS points out two important aspects of wBMS security: device-level security and wireless network security.

The first rule of any security system is "Keep your keys secret!" This means in the device and in our global manufacturing operations. ADI's wBMS device security considers the hardware, IC, and the underlying software on the IC, and ensures that the system can securely boot from immutable memory to a trusted platform to run code. All software code is authenticated before execution, and any field software updates require authorization through pre-installed credentials. After the system is deployed in the vehicle, rolling back to the previous (and potentially vulnerable) version of the software is prohibited. In addition, once the system is deployed, the debug port is locked, eliminating unauthorized backdoors. Network security is

designed to protect over-the-air communications between the wBMS battery monitoring node and the network manager inside the battery pack enclosure. Security begins with network joining, where the membership of all participating nodes is checked. This prevents random nodes from joining the network even if they happen to be physically close. Mutual authentication of nodes to the network manager at the application layer will further secure the wireless communication channel, making it impossible for a man-in-the-middle attacker to masquerade as a legitimate node to the manager and vice versa. Additionally, to ensure that only the intended recipient can access the data, AES-based encryption is used to encrypt the data, preventing information leakage to any potential eavesdroppers.

Protecting Keys

As with all security systems, at the heart of security is a set of cryptographic algorithms and keys. ADI’s wBMS follows NIST-approved guidelines, which means selecting algorithms and key sizes consistent with a minimum 128-bit security strength suitable for static data protection (e.g., AES-128, SHA-256, EC-256) and using algorithms from well-tested wireless communication standards such as IEEE 802.15.4.

The keys used in device security are typically installed during ADI’s manufacturing process and never leave the IC device. These keys used to ensure system security are in turn physically protected by the IC device both in use and at rest, preventing unauthorized access. The hierarchical key framework then protects all application-level keys, including those used for network security, by saving them as encrypted blocks in non-volatile memory.

To facilitate mutual authentication of nodes in the network, ADI’s wBMS provides each wBMS node with a unique public-private key pair and a signed public key certificate during the manufacturing process. The signed certificate allows the node to verify that it is communicating with another legitimate ADI node and a valid network member, while the unique public-private key pair is used by the node in a key agreement scheme to establish a secure communication channel with another node or with the BMS controller. One benefit of this approach is that it is easier to install the wBMS without the need for a secure installation environment, as the nodes are programmed to automatically handle network security after deployment.

In contrast, past schemes that used pre-shared keys to establish secure channels typically required a secure installation environment and installers to manually program the key values ​​of the communication endpoints. To simplify and reduce the cost of dealing with the key distribution problem, assigning a default public network key to all nodes in the network is often a shortcut that many people take. This often leads to a destructive, disruptive disaster as the hard lessons learned.

As OEMs scale up production, being able to leverage the same wBMS and varying numbers of wireless nodes across different EV platforms and installed at different manufacturing or service sites, which must be secure, we favor a distributed key approach to simplify the overall key management complexity.

Conclusion

The full benefits of wBMS technology can only be realized if security is ensured from the device to the network and throughout the lifecycle of the EV battery. From this perspective, security requires a system-level design philosophy that includes both processes and products.

ADI anticipated the core cybersecurity issues addressed by the ISO/SAE 21434 standard during its drafting and incorporated them into our own wBMS design and development ethos. We are proud to be one of the first technology suppliers to achieve ISO/SAE 21434 compliance on our policies and processes and are currently in the process of certifying our wBMS technology to the highest cybersecurity assurance levels.