OEMs and battery pirates are constantly in a quality-control tug of war.
So how do companies ward off deviants and dodge the lemons?
Battery-management ICs fall into three basic
categories: chargers, gas gauges, and authentication
chips. Chargers control how a charging current is safely
applied to a battery pack. Gas gauges tell the system how
much charge is stored in the battery at any given time.
Authentication chips indicate whether the installed battery
is approved or not.
Although charging is the most fundamental technology,
designing a charging circuit isn't nearly as exciting as
foiling battery counterfeiters, or determining precisely
how much time is left before a user's application goes to
a black screen, so we will take up those three battery
functions in reverse order.
Authentication
Suppose you're selling laptops
or cell phones and your products develop a reputation for
bursting into flames and burning uncontrollably. If you
say that the victims of those events were using pirated
batteries, particularly if those pirated batteries were
superficially indistinguishable from the real thing, your
reputation will surely sink. You want your system to be
able to distinguish carefully manufactured and testapproved
batteries from something hijacked from recycling
bins and prettied up with counterfeit labels.
Battery-authentication schemes range from simply
customizing the battery's form factor to a hierarchy of
challenge-and-response schemes. Making the battery
packs in different shapes isn't much more secure than
using no authentication at all. If the end-product is built in
any great volume, there's considerable incentive for
pirates to copy the battery package. If the end-product
volume is low, it probably uses a generic battery that can
also be profitably copied by pirates.
The most basic form of electronic authentication is one
in which a controller in the end product sends a command
to read identification data from the battery (Fig. 1). Such
data typically includes a product family code, a unique
identification number, and a CRC value. The response to
an interrogation is compared with data accessible by the
controller in the end product. If the response from the battery
doesn't match, action is taken.
Incidentally, this action may not be rejection of the
bogus battery. In some end applications, such as power
tools, lots of counterfeit batteries can infiltrate the community,
and the power-tool OEM doesn't want a reputation
for making fussy chargers. In this environment, it
may make sense to just have the charger top off the
counterfeit battery at a safe (i.e., very slow) rate, ensuring
that the battery, and others from the same source, hit the
recycle bin after a few slow-charge experiences.
In these basic schemes (in fact, in all schemes), the
host controller generally communicates with the chip in
the battery through a dedicated general-purpose I/O.
This leads to the Achilles heel of simple "send me your ID
data" approaches. It's too easy for pirates to read battery
IDs and copy them in pirate batteries.
A more robust alternative involves the host controller
sending random sequences of bits as a challenge to the battery pack. In this case, both the controller and the battery
chip contain a secret key for an algorithm that operates
on the random sequence.
When the battery returns a response, the controller
compares it with the transformed sequence that it generated.
If there's a match, the battery is authentic. Because
every challenge is different, the scheme is fairly secure-
until a pirate gets his hands on the key, either by applying
cryptographic analysis to a large number of responses or
by simple bribery.
Taking challenge-response up to a higher security level
involves cyclic redundancy checking (CRC). This approach
combines a challenge and a secret ID, processed through a
CRC algorithm with a random polynomial and seed value.
Typically, a 16-bit CRC response is generated from a
16-bit CRC seed, a 96-bit device ID, and a 32-bit random
challenge. The CRC polynomial, CRC seed, and 96-bit ID
are different in every battery. They're stored as encrypted
text in public memory and as plain text in private memory.
In a challenge, the controller in the end product reads
the encrypted device ID, along with the polynomial and
seed values from the battery authentication chip's public
memory. It decrypts those values using its secret key and
then generates a 32-bit random challenge, which is transmitted
to the battery chip. In turn, a plain-text version of the
polynomial coefficients, seed, and device ID, along with the
32-bit random challenge from the host, are used to calculate
the authentication CRC value, which is then returned.