Who cares about side-channel attacks?

[Wouter Slegers]

L.S.,

Peter convinced my to publicly comment on this.

Thierry Moreau <thierry.moreau at connotech.com> wrote:
> >>But they've all been unlocked using easier attacks, surely?
That was also my first response. In evaluation labs specialized in
checking devices (mostly smartcards and other financial devices) the
whole spread of attacks are tested against. Side-channel analysis is
arguably the most sexy of them all, but I have yet to see any hint let
alone proof that it is used in the field.
Perturbation attacks (messing with the execution of the code) by means
of glitches in the supply voltage is still the undisputed number 1 in
field attacks on individual smartcards.
Protocol/API-level attacks are the biggest one on system level in my
opinion. Card sharing is currently a good example.

Timing analysis is quite possible to pull of in straightforward
implementations as demonstrated over the Internet on OpenSSL prior to
their implementation of blinding
(http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf). But frankly, I
have never heard of such an attack actually being used in the field.
Real side channel analysis (DPA, EMA etc) seems mostly limited to
academics and labs, not the field.

>From that regard, side channel analysis is currently the more expensive
attack (the academic papers are good, but do not underestimate the
difficulty in implementing it in non-ideal noisy environments), which
suggest that protecting for it is not such a high priority at the moment
(it is not the weakest link).

> >The published ones seem to be the (relatively) easy ones, but the
> >ones that have been tried (and either not published or just had the
> >easy outcome published) have been pretty amazing.
Which suggests that keeping side channel analysis as part of the
possible attacks is a good idea. The broad scope of attacks seems to be
done in the field, which means that it is interesting for the defenders
to invest effort in that also.
In a way, the enthousiast attackers on the internet form a sort of
loosly parallel attack, not so much obviously focussing on one weak
spot but using a broad spectrum approach.

> >This is another one of these things where real figures are going to
> >be near-impossible to come by, even harder than my hypothetical
> >public vendor survey of who uses SCA protection.  
I'm afraid that the best at this moment is mostly rumors. There is some
knowledge about attacks in the field but it is spread out a lot and the
ones that aggregate this information are not sharing this (it also gives
the attackers a view on what works and what not).

I've seen quite a few publicly available examples of voltage
manipulation on old style smartcards, (not so-)secure embedded CPUs. Old
style physical reverse engineering is getting within the range of
students now (recent reverse engineering of crypto-1 is a good example).

Examples of side channel analysis on real systems I however have never
seen in the field. Any rumors would be highly appreciated.

> >attacks for example, there's everything from security 101 lack of
> >checking/validation and 1980s MSDOS-era A20# issues through to Bunnie
> >Huang's FPGA-based homebrew logic analyser and use of timing attacks
> >to recover device keys (oh, and there's an example of a real-world
> >side-channel attack for you),
?? As I read his story, he eavesdropped the bus between the bridge chip
and the CPU to recover the real bootloader code with the real RC4 key,
not the incorrect one in the ROM (very nasty trick, kudo's for the
Microsoft development team there ;-) ). 
Ref http://www.xenatera.com/bunnie/proj/anatak/AIM-2002-008.pdf

Nevertheless, this is a good example of economically unreasonable
attacks: Bunnie spent something like 4 months of his master thesis' time
on hacking the Xbox and then gave that knowledge away for free on the
internet. 4 months of "honest work" would have bought him that Xbox and
all consoles he could have wanted for quite some time...

[snip good list of things to consider]
> This gives an idea of analyses that drives security-related spendings 
> (in my limited experience). Clients (intend to) pay for protections that 
> will prevent financial losses and major public relations impacts (and 
> then cut operating budgets soon after the project gets its 
> authorization!). The consultant study must clearly link attackers' 
> motivations to impacts and to countermeasures.
I agree. From commercial point of view, the developer's point of view of
side channel analysis protection (and most other protections I think)
is I think:
Costs: 
- Additional resources in the device (memory, CPU time). Unless the
  device is severely resource bound (like a very tight power budget,
  really limited memory sizes like in a smartcard), this is not really a
  cost.
- Significant and specialized additional development resources to
  implement the countermeasures well. To do the whole protection, not
  just the blinding, well is a real engineering effort. It also requires
  a specific type of expertise that is not so easy to get or develop
  (although it is great fun to do for the developer as a person), i.e.
  it is expensive in your development personel costs.
- Testing and production might suffer from the security measures. This
  can be surprisingly expensive in terms of production speed.
- Reliability in the field of the product is potentially going to
  suffer, because of the risk of the countermeasures tripping in the
  field. Out there the power is bad (looking just like a voltage glitch
  attack), the sun is on the device (looking just like a temperature
  attack), the device falls of the counter (causing a short disconnect
  in the tamper sensors connectors, looking just like a tamper event).
  Because it is hard to get good information on these events in the
  field (attacks and accidents alike), the reliability takes an unknown
  but potentially high hit. This is the big cost in the eyes of
  management (and in mine).

Benefits:
- No compromittation of the resources. But in many cases, it is not the
  product's resources that are compromised...
- Warm fuzzy feeling.

If you look at it this way, it makes no sense to implement
countermeasures. Unless the costs are reduced by doing exactly what
Peter had already excluded: using a ready made crypto library /
smartcard /... that is already tested and shown to work.

Or, which is my experience, because regulations in the product domain
force the developer to have these countermeasures and show them to be
effective to third parties (evaluation labs). This is the domain of
financial organisations with their accreditations, and government(-like)
organisations requiring Common Criteria evaluations.
(Which also is excluded by Peter: the group that does this because they
have no choice).

> Does SCA protection enter the picture? Marginally at best.
For real threats out there, I agree that it is not as high a priority
as perturbation or API attacks are.
It is however relatively easy to implement only the blinding of the SCA
protection (just take a crypto library that does this). Implementing the
real anti-perturbation and side channel analysis protection, that is
where it becomes a serious amount of work.

So in short, I would see the group that Peter was looking for, as an
economic anomaly ;-) Although I would be fascinated to hear why it is
interesting for them to do anyway.

With kind regards,
Wouter Slegers

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com