Andreas Bogk wrote on 1999-09-15 00:04 UTC:
> The usual setup for DPA involves a 10 Ohm resistor which sits in the
> power supply and measuring the voltage across that resistor. The
> countermeasure we're talking about is an on-chip capacitor that
> smoothes the power consumption, or a power supply inside an
> tamper-resistant package such as the Dallas iButton, which essentially
> serves the same purpose.
The battery in the Dallas iButton is *NOT* there to power CPU
operations. This battery acts only to provide the around 1 nA data
retention current needed by the SRAM to keep its data reliably when
external power is removed. As soon as external power is supplied, the
internal Li battery is disconnected by the CPU power supply management
system.
The iButton does however have a power supply buffer capacitor on board.
Its primary function is to maintain power in communications mode. The
iButton can operate in two modes: communication and calculation. In
communication mode, only a large shift register is operated that is
connected to the serial port. Power is drawn from the interface pull-up
resistor during the transmitted 1 bits. While a 0 bit is transmitted,
the shift register draws its energy from the internal capacitor. In
calculating mode, the interface shorts the pull-up resistor, such that
the iButton CPU is now directly connected to the full power supply, but
it can't communicate any more.
By the way, one rather simple yet effective power analysis
countermeasure is described in
http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf
Adding a random bit stream generator into the internal clock line that
switches between genuine CPU cycles and realistic dummy loads at a
clock-cycle level can help to add sufficient amounts of timing variation
to make DPA infeasible. While software-based random-delay loops can
usually be rather easily spotted with single-shot cross-correlation
techniques and therefore be compensated by the power analyser before
applying the usual algorithms, the time intervals between two clock
cycles does usually not provide enough information to reliably
resynchronize externally with the program flow.
Another approach is to use asynchronous processors, which do not depend
on an external clock at all, and whose power consumption spectrum tends
to smooth itself out very nicely. Designing attacks and defenses against
asynchronous smartcard processors promises to become a highly
interesting area of work. (By the way, if you are seriously interested
in working in this field, we have just received a substantial grant to
develop invasive and non-invasive attacks on upcoming asynchronous
high-security smartcard CPU technologies, and we will be offering very
soon 2-3 research PhD student and post-doc positions for people with a
strong interest in microelectronics, tamper resistance, digital signal
processing and hardware security. Contact us me for details if you are
interested. <http://www.cl.cam.ac.uk/Research/Security/tamper/>).
At typical smartcard frequencies, the information leaking in the power
signal is spread across the entire HF and VHF band. It does not seem to
be too practical to place sufficiently good passive RC or LC filters
onto a chip given the current CMOS processes commonly used for 8-bit
microcontrollers. Another approach is to add a broadband OpAmp that
implements a current regulator. Make the CPU draw a constant current and
dissipate any power not needed by the CPU temporarily in an on-chip
resistor. This works nicely for low frequencies, but is also rather
difficult to do with normal CMOS processes in the VHF bands. It would be
possible to add such an opamp as a separate second chip, but many
customers are not likely to pay two dollars more for the entire
smartcard just for power-analysis protection. The challenge is to get a
really cheap countermeasure.
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
