
Ledger's Advanced Side Channel Analysis Repository - JBBP2
https://github.com/Ledger-Donjon/lascar
======
fpgaminer
I recently learned about side channel attacks on ChaCha20, and all other ARX
ciphers.

ChaCha20 and its kin are of course resistant to timing side channels by their
nature. Without thinking about it I had assumed they would resist other forms
of side channel too (cache, power, EM, etc). ChaCha20 performs the exact same
operations every time, regardless of its inputs. And the mixing should
eventually lead to an even mixture of flip-flopping towards the middle of the
cipher. So, how could it be exposed to any side channel?

Well apparently it's still weak to power (and EM by proxy) analysis:
[https://eprint.iacr.org/2017/1021](https://eprint.iacr.org/2017/1021)

I haven't had the time or inclination to study the paper in depth. But if
understood it correctly, the very act of accessing memory exposes the data
being accessed. Even if the power difference between accessing, say 0xaf and
0x30 is so infinitesimal, it's apparently enough to correlate with power
analysis and crack keys.

Quite amazing.

~~~
colmmacc
It can be easy to forget because we all sort of mentally accept it, but
ChaCha20 is length preserving, and so is trivially vulnerable to by far the
simplest network side channel: size based traffic analysis. AES-GCM is too, in
the same way, but AES-CBC was actually a /little/ better because it's padded
to the nearest block which provides a small measure of length hiding.

Imagine you're a state authority who wants to know who is looking at what on
the internet. It's pretty easy to fingerprint websites and webpages by size;
the pattern of HTML, images, video, and CSS, is highly unique. There are
published papers doing this against Google Maps tiles, and Netflix movies.
It's very very practical. It's utterly feasible for authorities to build these
fingerprint DBs, and to fingerprint any traffic they have visibility of.

------
xvilka
Riscure also made a high quality side channel analysis toolkit - JIsca[1]. It
is written in Julia and can be easily integrated with Chip Whisperer.

[1] [https://github.com/Riscure/Jlsca](https://github.com/Riscure/Jlsca)

~~~
P3b7_
Lascar is about to be officially integrated in ChipWhisperer
[https://github.com/newaetech/chipwhisperer/blob/cw5dev/softw...](https://github.com/newaetech/chipwhisperer/blob/cw5dev/software/jupyter/In_Progress/Lascar.ipynb)

------
rohan1024
Okay I'm feeling left out here. I've no idea what this is. Can anyone please
explain what is this and what is its use?

~~~
edelans
For those wondering what is a side-channel attack : here is a definition from
Wikipedia :

In computer security, a side-channel attack is any attack based on information
gained from the implementation of a computer system, rather than weaknesses in
the implemented algorithm itself (e.g. cryptanalysis and software bugs).
Timing information, power consumption, electromagnetic leaks or even sound can
provide an extra source of information, which can be exploited.

[https://en.wikipedia.org/wiki/Side-
channel_attack](https://en.wikipedia.org/wiki/Side-channel_attack)

~~~
DrPhish
The easiest to understand example of this is bypassing a naive login prompt:

If the function to test a password that has been entered stops as soon as
there is a wrong character, it's trivial to write a program to send it a
modified password each run and see how long it takes to come back. If it takes
slightly longer than last time, then you have one more character correct.
Iterate until you have the complete password.

It's one cheesy thing that Hollywood does that at least worked at some point
in the past, ie. the hacker that uses a program to crack a password one
character at a time (preferably as the clock ticks down to some impending
disaster)

~~~
jolmg
Sorry for my skepticism, but even in old systems, wouldn't such a time would
be too small to measure even by a program on the same computer? and I imagine
that having a preemptive scheduler makes things even more complicated.

It's hard to imagine the attack you describe being viable.

~~~
teej
My understanding of timing attacks is that they can be used when you can
trigger the code path thousands of times quickly. This gives you execution
time averages and distributions. Also, they're typically used against
cryptographic hash functions which are more expensive than just a string
compare.

[https://en.wikipedia.org/wiki/Timing_attack](https://en.wikipedia.org/wiki/Timing_attack)

~~~
jolmg
But if you use cryptographic hash functions, then you can't do the timing
attack described because any one character change changes the whole hash.

~~~
Nursie
Not for cracking a password perhaps, but imagine you have a system that looks
at a MAC'd ciphertext. You want the system to attempt to decrypt a malicious
ciphertext you've generated, but it won't until you have passed its MAC check.

With a timing attack, you can iterate the bytes of the MAC, itself probably
based on a cryptographic hash like HMAC(sha256), until you get something that
gets to the second stage.

You reduce MAC-forging complexity from 2 to the power of the number of MAC
bits, to 256 times the number of bytes in the MAC.

------
nabnob
Wow, this is the first time I've heard of side channel analysis and I'm super
impressed by the creativity involved in these attacks.

Based on reading a couple wikipedia articles, is it correct to say that most
of these attacks require access to the device that you're trying to crack?

~~~
fpgaminer
> is it correct to say that most of these attacks require access to the device
> that you're trying to crack?

Some, yes. A classic example of a side channel attack that doesn't require
physical access:

An authentication server which naively compares passwords (or even their
hashes). Say they just `if (request.password != expected_password) return
Error.403`. This type of naive comparison which will use memcmp or something
similar creates a timing side channel. This happens because it compares the
passwords one byte at a time, and returns early as soon as it finds a
mismatched byte. So the length of time the server spends authenticating the
passwords is dependent on how many bytes the passwords have in common. i.e.
"password" != "deadbeef" takes 1 comparison, whereas "password" != "peadbeef"
takes 2 comparisons.

So an attacker can submit 256 requests to the server, cycling through every
possible first byte. Whichever request takes the longest tells the attacker
what the first byte of the password is. So they fix the first byte, and then
repeat 256 times for the second password. And so forth until the password is
cracked.

This takes only O(N) time to crack, where N is the length of the password.

Though this is a simple example, it ends up being a very common attack vector.
And as noted, this can be performed remotely.

(In practice things are a bit more complicated, but make attacks like this no
less of a threat. You first need to determine the password length (easy, same
timing side channel). And then you probably need to submit several times more
requests per password attempt so you can average out the "noise" of request
times. Rate limiting, etc ameliorate attacks, but are no excuse for not using
constant-time algorithms.)

------
hart_russell
Is this an attack that can be mitigated by a firmware update?

~~~
anfractuosity
[https://en.wikipedia.org/wiki/Side-
channel_attack#Countermea...](https://en.wikipedia.org/wiki/Side-
channel_attack#Countermeasures) might be of interest especially this part:

"In the case of timing attacks against targets whose computation times are
quantized into discrete clock cycle counts, an effective countermeasure
against is to design the software to be isochronous, that is to run in an
exactly constant amount of time, independently of secret values. This makes
timing attacks impossible.[14] Such countermeasures can be difficult to
implement in practice, since even individual instructions can have variable
timing on some CPUs."

