Under the Hood: The nuts and bolts of Tanktwo’s battery security technology (BatSec Series 5/6)
[ Missed the previous posts? Read part 1, part 2, part 3, and part 4 ]
In software-defined batteries (SDBs), the hardware and software are intertwined. You can’t ensure a system’s security without ensuring the two components work together seamlessly.
Apple is a good example: You can steal an iPhone, but the iCloud lock is so secure that you can’t do much with the hardware. To use an iPhone, you need physical access to the device. And the software layer controls the rights to use it.
Like how a stolen iPhone doesn’t get you very far, unauthorized users can't activate a stolen battery built on the Tanktwo Battery Operating System (TBOS). What’s left is an expensive, 500-pound doorstop.
We build our battery security approach on existing security principles, but the multidimensionality of the discipline makes it complex and challenging to execute:
Companies must translate contractual, practical, and operational principles or guidelines into a playbook for the technology to execute. (Like the example we used here.)
They must support the system with information security implementation to provide the abstract limitation, permission, and authorization to support #1.
They must support the software commands with electronic-based hardware implementation. After all, airtight information security is worthless if a threat actor can bypass the security system through hardware weaknesses.
To help product builders and service providers overcome the complexity of battery security, we build the entire architecture into TBOS and abstract it from the battery system’s application.
The plug-and-play solution allows you to customize this security layer and sandwich it between any battery system and application. You can also update it via software to ensure ongoing compliance with changing guidelines, business requirements, and regulations.
Our software architecture uses the internet’s security backbone to protect access to battery systems with digital keys and certificates. The multidimensional approach involves many components, which intertwine to create a multi-layered web to address physical and cyber threats. Here’s an overview of these principles (buckle down!):
Battery security key management
Key management is the most critical principle behind battery access control and sandboxing. It’s the process of generating, distributing, storing, and revoking cryptographic keys for securing communications in various information systems to ensure data confidentiality, integrity, and authenticity.
Let’s illustrate the key management concept with the school example:
Various users (e.g., principal, secretary, groundskeeper) have different job functions and need to access various locked assets to do their job. Each user is issued a set of keys to perform their duty:
But who decides which role gets which keys? We must define people or entities authorized to assign keys:
However, we run into weaknesses when the key issuer and key user overlap. For instance, John Deere has been reluctant to issue keys to users to enable equipment repair — leading to major headaches for the parties involved and illustrating how a well-designed key management system is essential for the proper functioning of the ecosystem.
As such, we must introduce another layer in our battery security architecture to provide checks and balances.
This example matrix describes which key turners can unlock which battery capabilities and which entities can issue keys:
But how do you prevent the key assigners from turning on “god mode” and doing whatever they want?
The check and balances come from a traditional commercial contractual agreement, stating the roles and responsibilities of each party. In the example above, the courier company (the customer) has the intrinsic rights to:
The vehicle, which it owns.
The driver and fleet managers, typically through an employment contract.
The power company (e.g., that supplies green energy.)
The courier company also has a licensing agreement with Tanktwo to use our SDB technology to power its fleet.
Meanwhile, the leasing company is the legal owner of the battery and has traditional commercial contracts with its customer (i.e., the courier company) and a cell data specialist to optimize cell performance and fine-tune battery parameters. It also has a standard license agreement with Tanktwo to use our technology in their batteries.
The critical component is the ability to turn the contractual principles into a set of rules that the technology can execute — and we built our algorithms from the ground up to support this capability.
The battery security onion
What guides key issuance in battery management? The more potential harm an action can cause, the fewer people should have the power to execute that action.
To that end, we establish keys for roughly four layers/categories: User abuse control, mismanagement or service personnel error mitigation, financial harm control, and physical harm control to leverage advanced principles of proven operating systems.
Here’s what the layers in the battery security onion mean, in oversimplified terms:
If you don’t know what you’re doing and are poking around in the innermost circle, you could cause a fire or explosion. The risk of personal harm is high if anything goes wrong here.
If you don’t know what you’re doing and have access to the “financial harm control” layer, you could cause irreparable damage. But you will probably survive.
If you’re an incompetent maintenance shop manager playing in the “service personnel mitigation” layer, you may prevent the electric buses from going out the following day and get yourself fired.
If you’re a regular human, the “user abuse control” is for you. This layer covers behaviors like slamming an electric truck into reverse at 70mph — it shouldn’t happen, but someone will do it someday. But ideally, not too many things break.
The battery security onion informs the level of access control to implement — i.e., who should be allowed to touch what. It’s critical because in battery technology, a tiny typo could lead to disastrous consequences.
Let’s say the cell chemistry data specialist with access to the innermost layer determined that raising the maximum cell charging voltage from 4.20V to 4.25V is safe. But they make a typo and key in 5.25V. Without the appropriate checks and balances, the error will lead to a violent battery fire the next time someone charges the pack.
That’s why our battery security architecture prohibits actions that could cause physical harm altogether and protect specific parameters and actions with a belt-and-suspender approach — requiring more than one key to unlock a function:
In the above example, the min/max state of charge (SoC) setting requires sign-off by the leasing company (the owner) and the cell chemistry data specialist because the decision involves deep battery chemistry knowledge and insights into the financial implication (since widening the SoC window can accelerate deterioration and impact the remaining useful life.)
The Tanktwo battery security processor: Layering battery security fundamentals
The TBOS security system starts with the battery security processor (BSP). We burn the serial number and version data into the chip write-once memory, which can’t be altered afterward in any way. Then, we add the BSP to the SDB circuit board, where it’s paired with other chips (e.g., CPU, flash ROM.)
Next, we layer down different components — like adding the lithium and setting some low-level limits (e.g., temperature and current limits). Then, we define details about the owner, application, operator, and user — adding keys to the key repository for granular access control, authentication, etc. (e.g., who can access or change which function and under what circumstances.)
When the battery changes ownership, we can adjust the set of keys to change access privilege and other security perimeters by revoking, rewriting, or substituting existing ones.
The BSP contains several types of key repositories: write once, read many; write once, read never; write-until-write protected, and rewritable — allowing us to balance security, granularity, and flexibility.
Up next: Let’s take a step back…
All the technology stuff is really cool. But why go down that rabbit hole?
Our next (and last) installment of this series will zoom out and look at the implication of battery security in the age of accelerated electrification.
