Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/328 Thanks!
OK, thank you very much for the
introduction.
I'm Sebastian.
I used to be a penetration tester and so
on and so on.
Now I went back to the to the university
and now I'm a professor at
the University of Applied Sciences
where I teach and I
and I do research in information
security.
I did two formal talks at CCC
at this very premise.
One was three years ago.
Time is on my side and one was
two years ago.
And both are have a related
topic because we're going to look
at timing attacks in
this talk as well.
This talk is based on an academic paper
and I've linked it over here.
If you just Google it, you will find a
link to the presentation
of of of the academic paper.
If you're interested in that.
Obviously, it's joint work.
What I'm presenting here. So this is not
solely my work that
I'm presenting here, but there's like
a large amount of people who helped.
And basically what
I was doing is the timing part of the
attack. But we will we will see that
later on.
OK, so there were lots
and lots of as little as spox
in the in the last years, so
you all probably have heard of of
Heartbleed and poodle and crime and beast
and so on.
So there's like a huge amount
of research and breaking SSL
research in the last years.
It's not a thing of only the last
few years, but also like maybe something
like 10 years ago or so or more than 10
years ago that we saw other types of
attacks. So, for example, the
Brenly bunny attack, which was a timing
attack against SSL and
also oblation bathetic,
it's named after Danny Oblation because
I think he's from Switzerland.
Um, and he found
this attack in 1998
against a very early version of
of SSL.
And what we are going to do today in this
talk is we will have a look whether
the the attack this the exact same
attack, steelworker's,
some of the bugs that were discovered,
like in the in the past,
some of them were protocol level bugs and
some of them were implementation level
bugs.
That's an interesting distinction.
So can we fix Abuk
just from the implementation side or do
we have to fix the protocol?
Generally speaking, people
refrain from fixing a
crypto protocol because it requires a lot
of work and it's not compatible to
all versions and so on and so on.
But generally speaking, when you design
a crypto protocol, it will pretty
much stay the same or it has to
be supported for the upcoming years.
And also, depending
how you design the the
crypto protocol decides how much
effort it is to implement the protocol.
And not that I'm not speaking about
effort in terms of lines, lines of
code, but
something like how fragile is the
protocol to implement.
So how careful have to do you have
to be at the at the implementation level?
And what we are going to see today is
some kind of.
So we have like in 1995
when SSL was proposed, the SSL
version three was proposed.
They made some decisions that we
now know are vulnerable and
they never changed it.
So the SSL protocol itself is still
a protocol against the Blazin Bahais
attack if you don't
be very careful in the in
the implementation phase.
And we're going to look at the implementation.
So just a quick primer of
how SSL really looks like this is really
a very short introduction.
There's a new book by Evan Restitch.
He's he's explaining very well all the
foundations of SSL and how it works and
so on. So if you want to take a deep look
at SSL, you might want to look at this at
this book.
I'm just going to present these parts
which are relevant for this talk.
So what is relevant for this talk is
some kind of a hybrid protocol.
So it has some symmetric crypto
and some symmetric crypto.
And generally the symmetric
crypto is used for
for an ciphering, the actual content.
So when we use HTP, for
example, the traffic itself
will be encrypted with a symmetric
cipher, for example, A-S and
with a random session key.
And this random session key will be
exchanged between client and
server using asymmetric crypto.
Um, so this is like
the client since a client or the server
since a server.
Hello.
He sends a certificate and this
certificate contains a public key.
So the client receives the public key.
Then he randomly,
randomly chooses
a certain key.
It's really just random and encrypted
with a public key of the server and sends
it over to the server.
Now both have the same session key and
can talk encrypted
when an attacker is able to somehow
decipher this session key.
Obviously, the the decision
is broken because the attacker can then
decrypt the whole session and you don't
have confidentiality anymore.
This session ticket, as I was saying,
is called the Prima's a secret or
RPM's.
And, uh, yeah, as I said, the
the client encrypted with a service
public key and sends it over to the
server. And then the actual
session key is the master secret.
And this depends on the Prima's a secret,
right.
So this is the most this is anything
that you have to understand in order to
to to follow this talk.
You don't have to know more on this.
OK, the attack that I'm
going to present here is
old, it's 14 years old,
it was developed by Danny Oblation back
in 98 and it works like this.
You have a client and a server
and they do they do a handshake
and they exchange the Prima's a secret.
Right. So the session Kiffer, if
you want, the attacker is
a passive man in the middle, which
means he just eavesdrops on the
on the connection and now has like
he has recorded the encrypted
handshake.
And what he wants to do now is break
this like the premise,
a secret, the session keep.
And he does that solely by
requesting but by doing certain requests
to the server and measuring
response times, for example, or analyzing
our records and anything that comes from
from the server.
So that's our ataca scenario, and
that's a very general attack scenario,
um, if you look at ataca scenarios,
for example, for a crime
or a beast, which were former attacks
in the last few years, they have a very
different a model
so that it only works in
the context, for example, because
the attacker has to force the victim
to perform many encrypted connections
of the same channel.
Right. So he requires that we
don't need this in oblation attack.
We just need to record the handshake.
And we have to we must be able to
issue requests to the server and
measure something.
Right. And what we what we measure that
we're going to see it later on.
And this scenario means
that our attack is not only
applicable to https, but
also to pop
three S or IMAP s.
So anywhere in any context where telexes
used or attack
can be applied potentially depending on
the implementation.
Um, now, it's not that we
have broken all the ciphers that
that are used since that's not the case.
So there's like various
ways of doing the encryption and doing
the handshake and so on and so on.
And what we can break with
our attack is this list of ciphers.
Most of them are still
used quite often, at least
before like like
it changed in the last one or two years
since Snowden told us
what what the NSA is capable of.
So since then, things changed.
But before that, those were, I guess, the
most used ciphers everywhere.
Basically, we can break all the ciphers,
but none of the elliptic curve
suites because they have a different
type of of key
exchange and none of the
Helgeland suits.
So if you're using these and you should
use these because they're in generally
more secure and also at
least it's more it's more performant.
OK, um, the RSA encryption
algorithm, it's really it's really very
elegant, very short.
So when you want to encrypt something,
you take your message, raise it to
the power of E and E, the public key
mod. And, um,
and when you want to decrypt em, you just
take the ciphertext, raise
it to the power of D and D is the private
key, uh, modulus.
And then you get the then you get the
message back.
One thing that is also very important in
order to understand Bahasa tech
is that RSA is malleable,
um, malleable in
German form, umba
means that an attacker can make
predictable changes to the ciphertext
without knowing the clear text.
So I give you a ciphertext or you give me
a ciphertext. Let's put it this way.
Then I can make changes to the ciphertext
that have predictable effects on the
clear text, even thought I don't know
the clear text and even thought I don't
know the result of my computation that
agisted. Right.
So you can, for example, do
multiplication.
So that's an important
that's an important thing that we have to
keep in mind when we when we go
further.
Another thing that is a very important
I guess the second thing that is very
important, we need to use some kind of
padding because
the, um, the Prima's a secret
that we use for asymmetric encryption is
very short. We just
we just need forty eight bytes.
So it's very short.
But
RSA is some kind of a block cipher.
So when we have
two thousand forty eight bits are is a
kiss, we always have to encrypt
two thousand forty two thousand forty
eight bits.
Right. So um we
have a forty, forty eight bits over here,
but the whole thing is like 256
bytes. So we need to use some kind of
padding.
And until the decision
was made in 1995 to use a
standard, a petting standard that
is called Peake's one inversion one dot
five. And always when I say
Pickus one in this talk, I mean
version one, dot five.
There's also a version two, which is much
more secure, but always when when.
So it's like Peake's one
in version two.
Right. So this is secure.
But always when I say Pickus one, I mean
Worsham one, dot five.
OK, such as that, you know,
and the the padding scheme is very,
very easy actually.
It always has to start with a 0002,
at least for the encryption type.
So you always have 0002,
then you have two hundred and five bytes
with non-zero padding.
And this, this is supposed to be random.
Whatever comes in here should be somehow
a little bit random and
it must not contain zeros
because the the end of
the padding will be denoted by, by a
terabyte.
And right then
then comes the Prima's a secret and
the Prima's a secret is a forty six
bytes of of a random string like that's
the section key that we use that we use
for the symmetric encryption.
And this is the part that the attacker
wants to, wants to break.
This is the important part.
The zero three zero one is
somehow deterministic.
It means in this case that the protocol
version was tearless 1.0
at.
So very easy, very easy to understand.
Now, what does Marcus attack mean?
And unfortunately, I do not have enough
time to go very deeply into a
heart attack, but
only from a
bird's eye view, it means
when when a service is susceptible
to a black box attack, it
allows splashing. Barhoum, who is in
possession of an RC ciphertext,
I call it sea, to recover the
plain text of it M0
under certain conditions.
And the condition for this is that
it requires an oracle.
So we need to have we call it oblation,
the Oracle.
And this Oracle
does a very specific thing.
It decrypts the ciphertext and
responds with one or zero or true
or false. You can take whatever boolean
answer you want, depending on whether
the decrypted message starts with 0002
or not.
I also remember PKC as one inversion
one that five requires that
it always starts with a 0002.
And when we can construct
from this oblation the oracle that tells
us exactly this.
So true or false, does this ciphertext
start with 0002?
Then we can decrypt the whole ciphertext
just by issuing many requests.
Right. So we have to agree with the
Oracle many times.
And the reason for that is
when the Oracle answers with one, the
adversary knows something
about the, uh, about
the range, the possible range
of the hours, a clear text,
and it will be in this range.
And you don't have to understand exactly
why this here is the case.
The important part is here is a two
and here's a three.
And we know that when
when the Oracle tells us one.
Yes. This was PKC US one complaint.
It starts with 0002.
Then we know that the
clear text, which is just an integer RSA
works with integers, is larger
then something, something with
two.
So it starts with a leading to and
it's a smaller then something with
a with a with a leading three
because otherwise it would be zero zero
zero three.
That's not the case.
So we have to issue many, many Oracle
requests. And for each request we learn a
little bit more about the clear text.
OK, this was the theory part.
Now we come to the to the practical part,
we have to talk about the strength
of the Oracle.
In an ideal world, we just
want to have an oracle that
we can fit any ciphertext in.
And it will tell us, yes, it starts with
0002 or not
in in reality,
this is a bit this is a bit different
because I told
you PKC has won the format.
It starts with zero zero zero two,
but it performs some more.
So there's non-zero padding.
And when there's non-zero padding, you
should check whether there is a zero in
the non-zero padding because otherwise it
would be not a non-zero padding.
Right. So we just want to have
one oracle that tells us, yes, this
starts with 0002.
But what happens when we have
a zero in here?
Then this might fail.
Or if this zero byte
here is not there, this might fail.
Or if this zero three zero
one is not there, then it might also
fail.
So these are all additional checks
that a test server might
perform
in order to find out whether
the ciphertext decrypts to has
one conferment clear text.
That's a problem, and the more checks
we have, the worse performs
the Oracle because we could have
ciphertext that decrypt to
a to a plain text that starts with
0002.
But because of the additional checks, the
Oracle says, no, this was not because
it's confirmed.
Right.
So fewer checks result in stronger
oracle and it's better for the attacker
and the other way around, the more checks
we perform, the worse is the attack,
right?
OK, so now, 1998, let's
go back to 1998, an abortion ban came
with his with his famous paper.
What did people in the Tiller's
consortium say?
Well, they said, OK, let's just stick to
this one in version one, that five
perring for compatibility reasons,
everything is for compatibility reasons.
That's a problem, right?
That's really a problem.
But they made the decision.
No, we just stick to the padding.
We know that it's vulnerable.
But let's just look whether we can find
an implementation that is not vulnerable.
And this is what they did.
They just said we make the requirement
for the implementations
that PKC as one conferment
and nonconformist messages
must be treated equally.
They must be indistinguishable for the
attacker.
So that means, for example, we had
to unify all our conditions because
the, um,
in the, uh,
in the first blush in Bihar, uh,
paper, in the original Blankenbaker
paper, he exploited error messages.
So the SSL implementations
told the attacker specifically, no,
this was invalid.
All this as well petting, but it worked
because of something else.
It didn't work. Right.
So they prevented
this by saying, OK, we just send one
error message and the error message just
says something went wrong.
So we sent over a ciphertext.
The server makes this thing and does all
the checking. It just says, no, something
went wrong. But we don't know which.
Right. We don't know whether the wedding
was correct or not.
But something else could have could have
gone wrong.
Something like this. Right.
So this is what they said, unify all our
conditions.
We checked for this, so we tried,
so we created a lot of test cases,
something like fuzzing you might you
might call it fuzzing and tried
to find out whether we can find
Oracle in different test implementations.
So this is an example for Java, for
example, where we can provoke some
error condition, where we can create
oblation by Oracle.
Right.
And this is a very weird oracle
in a sense.
Right. So it will throw a
very specific error.
And it's called an internal error.
If the clitic starts with 0002
and the clear text contains a zero by
proceeded with a non-zero by it
and somewhere in in
this area here.
So it's only valid if it if it happens in
this area.
So some programing error that
happened there.
Because of this, we could apply these
straight 14 year old
attack against this against
the server.
But we have to talk about the Oracle
strength, right.
Oracle strength.
You remember we have a clear text
that starts with 0002.
That's the one that we want to have for
the attack.
But we do additional checks because
of these additional checks.
The Oracle might still say, no, it's not
valid or something like this.
And here the Oracle strength
really depends on the bit size on
like on the key size of
the RSA keys.
So for 1024
bits, we have only
two to PROMETA
success rate.
That means for,
let's say, four for 1000
ciphertext. That all start with zero
two. We only have two where
it really says, OK, this is a this is a
Pickus, one compliant,
apexes, one compliant keep.
And the interesting thing is the Oracle
strength increases with a bit size.
So that means when you use four thousand
ninety six keys, which is the most
secure, this is
the worst in our case
because the Oracle is very good.
So in three of four ciphertext
that start with zero zero zero two, the
Oracle tells us, yes, the speaker because
one compliant.
Right, so, um, usually
people tell you that for
a bit like the bigger the bit,
the bit sizes, the bigger the key sizes,
the the more secure
encryption scheme is.
And here it's just the other way around.
This is often the case for, um, for
sexual attacks.
Right.
So the attack performance, we couldn't
attack in reality, um,
1000 keys because it
just has a very low ratio.
So the Oracle is very bad.
It required us 12 hours
for to recover.
Prima's a secret of a two thousand forty
eight key and only
six hours for four thousand
ninety six keys.
OK, um, so
here we just checked for the obvious,
so we just took the 1998
paper and created a few test
cases, did some fuzzing and tried to
find out whether it worked or it didn't.
When you look closely at linebacker's
paper from 1998,
he will tell you that he created his
his oracle using
error messages.
So it just only looked at the error
messages and nothing more.
And there's a small sentence where he
said, in theory, it could be possible
to make one of these oracles
over a timing subchannel.
And this is where we got the motivation
to look to to dig a little deeper
and look whether we could construct
a black oracle just from timing
information.
We had some experience with
timing based attacks because we applied
it against a standard called XML
encryption.
You will find the details in my
in the top three years ago.
So from 28, 28, C,
C three was it.
But just in a nutshell, I will explain
how this worked.
So basically, XML encryption is a
standard that allows you to, um,
to cut out a part of an of
an ex, some lairy
encrypted symmetrically,
let's say, with A s
and a random key.
And then you take this random key
encrypted with the receiver's
public key and put it to the
to the same document.
And this is what you see here.
So down here you have the actual
symmetrically encrypted
part that you want to hide
that where you want to guarantee the
confidentiality.
And over here you have this random
the random session key quotes
that is itself encrypted with a public
key of the receiver.
Right.
So we could attack
this because all the implementations that
we looked at worked as follows,
decrypt the session key in the first
step. So this is this part
return an error if, uh,
if M does not comply with Peake's
one else, decrypt
key data and key data.
Is this part down here.
So the whole symmetric decryption
only happens if
the key that was there was used there
was this one conferment,
which is great because we can measure the
timing between.
Between these two steps,
right? So when we can measure this,
then we have one and we can construct
a circle from this.
The good thing is we can
the attacker can influence how long it
takes for the of
the decryption to finish because
he can just put arbitrary garbage
down here megabyte wise.
So it will take hundreds of milliseconds,
even seconds to decrypt.
And it just it can be garbage.
It doesn't have to, like,
be passable at all or something like this
because it will be passed later on.
We just want the decryption to be
happening. And this is where we
constructed the the timing,
the timing. Erkel right.
And here you see just
this not only worked over the over
local network, but also over the
Internet. So we did some measurements
over the Internet and that also worked.
And so that was just a short
shot.
Yeah, of course.
OK, so we have already
experienced timing based
attacks blasting the attack
was applied against Tlas, so
it's somehow natural to go
back to Tlas and try with the
timing. This thing works against tearless
as well.
Let's look at the standard,
what the people said, how
to, um, how to prevent
timing attacks against blankenbaker,
we take the last standard of tearless
in version 1.0
and they said, well, we make the
processing of valid records and invalid
records indistinguishable.
And this is just a snippet of the
standard. So they had some kind of
some kind of pseudocode
where they explain how the PKK
has won. Verification is supposed to be
happening so that no
timing, so no
timing can arise.
So we generate a random string out
of forty eight random bytes.
This is a random PMAs that will be
generated any time.
Then we decrypt the message to recover
the plaintext.
And if the PKK as one
kid padding in the plaintext is
not correct, we use
our that is the randomly
generated string as the Prima's
a secret and just continue
with with the with the SSL
protocol.
This has the advantage that it will
well server and client now
have different keys.
So as soon as they start
a like talking on
on a symmetric level, it will
fail. And what will also fail
is like the schmick, um,
authentication.
So there is one part that I haven't
explained yet, and that is also not
necessary. Just know
that it will it will fail later
on somewhere in the protocol.
It will later fail.
And this failure does not correspond
to whether it's pixelation, confinement
or not.
So that's a good thing.
What they proposed here.
This is how it's supposed to work.
He is just I want to repeat this
one more so we generate a random key,
a random RPM's PMAs are, and in
case of a Pickus one in
Bellizzi proceed with RPM's are
in the protocol.
The good thing here is the random RPM's
will always be generated always
independently, whether
the the key that was received from
the client was because, as one confirmed
or not, and provokes
an error condition in the later stage.
OK, but what about tell one, not one and
one, not 1.0.
These are older.
So right now I have shown you the the
newest version
of the standard.
In the older standards, there was
no pseudocode listed.
It was just this sentence that was in
here.
So the best way to avoid vulnerability to
this attack is to treat incorrectly
formatted messages in a manner
indistinguishable from correctly
formatted RSA blocks.
This this we all understood, right?
So there must not be any
difference between a PKC as one
conferment, a cipher text
and pixels, one conforming ciphertext.
And then they said Afar's.
When it receives an incorrectly formatted
RSA block, a server should generate a
random forty eight byte value and proceed
using it.
And there's a difference.
Do you see the difference?
Exactly. So only when it receives
and incorrectly formatted RSA block, a
server should generate a random forty
eight byte value and proceed using it.
So the forty eight random bytes
will only be received if
the key that was coming in is not PKC
one conforming.
So that's interesting.
What does it mean, right?
So we have a differently we decrypt
the ciphertext, we do all these
PCAs one heading checks,
and if they fail, we generate
a random prima's a secret and proceed
with a random prima's a secret.
And if it's not the case, if it is
because one informant, then we just
proceed with this particular RPM's.
This has one advantage
that is that makes it
clear for me why they chose
this approach and the former standard.
It's much more efficient or maybe not
much more efficient, but more efficient.
So when it comes to tearless performance,
it's very important.
And when all of a sudden for each
and every incoming tearless handshake,
you have to get a forty eight
byte random string.
This will take some time depending on the
hardware and so on and so on.
But this might be in the milliseconds
area, right.
Can be a few microseconds, can be a few
milliseconds. And this, this
obviously if they informa versions
of the standards they thought, no, it's
not worth it. Right. So nobody can
construct a timing from this.
And we checked.
All right, let's do some timing
measurements, how
to perform timing, Charles
itself is the talk is
a whole talk is right.
And I always keep saying this.
I thought I should do an on talk.
The good thing is I did an on talk for
this. Right. So you can just look at the
video recordings from
2083 there.
Explain how to do timing measurements
with a normal computer over a network.
And how do you cancel out the jitter
and how can you deal with statistics and
so on and so on.
How can you not prevent timing trends?
Right. That's the the talk
that came that came later.
If you're interested in that, you can
have a look at this as well.
The first thing that we did is we
used a
testing framework, it's called time.
I don't know what the abbreviation
really, really means, but it's credit to
Christopher Meyer.
He did this in his PhD thesis.
And it's basically a framework for
fuzzing tearless implementations
so you can generate
various requests
and and do testing.
So it's very easy and convenient to do
testing for tearless.
The problem is it's written in Java.
That's really a problem, right?
And I mean, I was expecting
some trouble when it's written in Java,
but I am so basically I
didn't know that it's that difficult to
the timing measurements in in Java.
And so we had to do a
different approach.
And here is just I
try to condense all the things
that I've learned in between, like
in the years of doing timing attacks
over networks.
What should you do in when you
want to do timing attacks?
Right. So no memory menaged programing
languages, no Java, no personal perl,
no. You name it.
Just you see, just use a sampler
where you have a single threat.
That's exactly what you want.
And and so on and so on.
And there you have already some
you might have some issues there as well.
Right. But you have these memory managed
programing languages as well.
Choose your part of the network wisely.
So there's really no there's really
no use of doing it over wi fi or
your 3G modem or whatever.
Just go as near as you can to the
target that you want to attack.
When your attack is somewhere
buried in a in
a data center.
You might want to rent hardware in
the same data center, for example, write
short paths, Thoroughgood,
disable the power management on your
on your measurement machine.
So when you use Linux as
a measuring platform,
you should, like, disable, for example,
until speed step and there's some
equivalent from AMP.
It goes under a different name, but it
has the same effect there.
You can use the CPU, Freck utils,
its user, and so you can just install
them and set your CPU to
a fixed frequency.
And there's also something which are
called spacy states or sleep
states.
Um, they will just
like Puti or certain, they will put
certain Kooris to sleep
and in order for them to wake up, this
takes some some time.
And it's Jeta to your measurements so you
can just disable this with a kernel
put parameter on Linux.
What I haven't put on this list is you
can also fix a process to
a certain core so you can disable certain
course, um,
and so that it only that your
measurement script only runs on this
particular core.
You should do this as well.
Um, don't use fancy
server hardware
because they do something that is called
interop coalescing and interrupt
coalescing means um
or in the old days when one
packet arrived at your, at your, at
your network card, it sent an interrupt
to your kernel for each and every packet.
And you want exactly this.
The modern hardware and not
only the server hardware but also in
laptops, it's building and so on
and so on. And there's something called
intellectualizing. So whenever a packet
comes in, um, the hardware will
still wait for, for some microseconds.
That's configurable.
Whether other packets are also coming
in so that it only sends one interrupt
for many packets and you don't
want this.
So you use very old and cheap network
interfaces. And we did this
stop all tasks and demands on your local
machine. No, your idea should be
self-explanatory.
And what you also want to do, you want to
do so with timing measurements.
You have to repeat the same measurements
over and over again in order to do
statistics on it, in order to filter
out the the noise.
And you want to skip the first few
hundred measurements because usually you
have some some caches warming up.
So you want to skip these.
OK, start and end point
for measurements is also something that
that can be quite, quite interesting.
So, for example, when the request that
you're sending is very big, you don't
want to press the timer.
Right. And and then start sending,
sending, sending, sending, sending and
then waiting, waiting, waiting.
And then come the first packets,
come in off the response and then you
then you set the timer down here.
You don't want to do this.
What you what you can do if
if you have the possibility is you sent
all the bytes of the request that you
want to measure.
You send all the bytes, but
not the last one. So and minus one, if
the messages and bytes big
is sent and minus one, then you start
the timer, then you start ascent, the
last part of the request, then
you wait for the receiver of the end
of the response could be the first
byte or something else.
And then you stop the time and then you
receive the rest of the of it.
OK, this is our measurements
set up, and basically it's our
time frame work just showed
in in a in a in a different angle
and the timing critical part is
somewhere somewhere over here.
And I told you, it's like time is
written in Java, which is very convenient
for for programing, but not very good for
timing measurements.
And so we decided to just cut out
the critical the timing critical part
and and and build a module
that is written in C and assembly.
Um, so
I didn't want to write a full blown
tearless client in C, so I looked around
what was there and then I looked at the
SSL right for maybe an
hour or two.
Then I closed the editor and
went for a walk.
Right.
The reason the reason for that is it's
really, um, um,
yeah, it's I mean,
Krypto is difficult, right?
And you see that Krypto is very difficult
when you look at the at the code of SSL
for SSL, um,
uh, the API is very,
um, it's very hard to understand.
Right. And obviously there's no API
for doing a timing attack on tearless in
SSL. Right.
So I wanted to reuse a part of
an offer of another client
and I found this with a very tiny
embedded SSL implementation called
Matrix SSL, um,
have it written here.
And we just patched this.
So it's called the Code of Matrix SSL
stippled. It's very small.
And the good thing is there's no weird
API thingy happening
there. You just have to
send and receive, for example.
So you're doing operations really on
the socket level, which is exactly what
we want, very clean code base
or maybe not very clean, but it's
a clean code base, no complex API
wrappers, and
they even come with a client and a server
just as an example.
Right. So they bring their ship with
examples. And we just patched the client
so that it does whatever you want.
And what we want is
we want this client to do a
handshake with a prima's a secret
that we send him.
Right. And so it was just we just created
this command line tool that just
idealize handshake with a basically
four encoded pimsleur, which is
generated.
And it will it will just
it takes the PMS and then you have just a
lock here and then you grep over the lock
and just get all the timings that you
want.
So you see, it's very inefficient.
But what we called it here, but it's just
research. Right. So we just so we called
for each and every measurement that we
did.
We called a new process
from Java land to the sea
land here and there.
Right. So it's so all the numbers that
I'm showing to you, obviously not
very not very good.
You could probably make them faster
by a factor of two, I guess, but still
come on its research.
Right.
So how did I do?
So this is really this is really a
code that I pitched in there.
You have some wire loop where it gets
some data that it wants to send over to
the, uh, over to the server.
And here you have your sentence's call.
And after that, we just, um,
we we measure the skeptics.
If you're interested in the details here,
just look look, my my talk from three
years ago.
And then we get like the, um,
the statistics like
how many clock cycles were
have passed until
this until the CPU was initialized
at this point, as is now in start.
And here we have the end
here we have just received threats.
It's very easy.
Just basic circuit programing.
Very nice.
And, uh, down here, we get the end
now we have like the start takes and the
antics, which are substract them
and then we get the amount of takes that
passed.
Um, um, uh, and that
it took for for the server to just
to do its thing.
So that was, uh, pretty much to set up,
uh. Now let's look at the code.
Let's look at SSL.
OK, this is a real source code of
SSL, I think it's half a year
ago or so in 1.0
dot one dot e or I,
um, and everything
that is relevant for oblation Barcus
attack happens within, let's say, 50
lines of code or so.
So here this line is
important because there we decrypt
whatever came from the from, from
the client. So the client since the
encrypted RPM's, this will be a decrypted
over here and we have some
status here that is passed as E!
Um, and this will
be used over here.
And then we just check in this particular
if statement here, whether some
some decryption failure happened and
if this decryption failure happened,
what do we do?
We get some Suddaby success.
We got some random bytes.
We generate a random prima's
a secret and,
uh, generate the Masaaki.
So this is really the old way
of preventing the
attack. So if and only
if, uh, the Prima's
a secret that came in was not
this one, confirm it.
Then we then we generate
a random key and
continue with that.
So how does this look like when we look
at the measurements?
We found that it's this generation of
40 of forty eight
bits of random data is
one and a half microseconds.
This obviously depends on the
on on the platform that is used and so
on and so on. But one and a half
microseconds, this is something that we
can measure in a local network.
And this is what we did.
The problem that we found was
open SSL did something very good,
you don't hear this very often, but this
is a presentation where we say they did
something very good because they did a
very strict pickiest one checking.
So they not only check for does it start
with 0002, they also
checked out some non-zero petting,
not contain any zero bites and it's
to zero bite on the on on
the ride space and so on and so
on and so on. So they did everything
right.
And this led to the fact that the Oracle
strength itself is very weak.
That means even if we send
a ciphertext, the decrypts to
a plane takes starting with 0002,
we still have a very low probability
that the Oracle will tell us it's a valid
it's because it's one relet,
so therefore we couldn't attack
optimizes.
All right.
So we didn't even try we just
did the math and
said that it will
be a successful attack, will
require us four times
10 to the power of 12 requests.
And this is not not practical anymore.
This is not something where I would sleep
very well.
Right. So this should be fixed
and it is fixed in the meantime.
But still, it's not something practical
that we could do in our lab.
Let's look at the third channel, and this
time again, we look at the Java
implementation of of Tlas.
So these were the same guys
that had this like the different error
message, right?
20 slides ago or so.
And when you look at this so we have
some master secret here and we want to
generate the master secret
so we get some information
and try to generate the master circuit
over here.
And what you see here is there's a lot
of, um, a lot of exception handling.
Right. So what they did here is actually
textbook Java implementation.
This is how I teach programing
beginners how to do how to do object
oriented according.
Right.
The problem is this is not a really good
idea to do this in a timing.
Critical sense.
Right. So it
basically means you don't see this at the
court here, only show this to
to to show you that there's
a lot of exception, handling and
catching and throwing you acceptance
and so on and so on.
It led to the fact that
we could exploit this so
that we could execute a timing based
attack against JSC.
The Oracle strength was very strong,
so they do very few checks.
So when you send over a ciphertext and a
decrypts to a plaintext, starting with
0002, we have a 60
percent chance that the Oracle will tell
us, yes, this is a Pyxis one, confirm
it. And it means that we could
like break one single tearless
handshake within just about
18000 requests and 20 hours,
which is pretty good.
Um,
the fourth channel and maybe the
most critical channel was,
uh, when we looked at
some hardware accelerators,
um, concretely at those
from the from the company cavium.
So whenever you buy a big
appliance for big money, that does
the SSL termination for you.
So let's assume you have a lot of
requests that you have to process
and you have a lot of application servers
and a load balancer.
Then usually the the
servers behind the load balancer,
they don't terminate.
It makes some box before
that does it.
And if you buy such a box,
uh, it is often
it often contains a hardware acceleration
for four tiles or at least for the
underlying crypto primitives such
as A-S and RSA and things like
that, so that the process,
the expensive part of the crypto
operations is performed on separate
hardware.
This comes in various flavors
for servers. You can you can also buy
this and plug it in by a PCI.
Then you need a driver and so on and so
on.
So, yeah, and it's then relevant when
you have like a big installation and you
have to deal with many thousands
of incoming tearless handshakes and
connections and so on and so on,
then you need an appliance like this.
So we analyze this as well.
And concretely, we looked at the
products of five big IP owned
and IBM data power, so we didn't
have the actual card.
We just use products or measured against
products that have these cards installed.
And this is very
interesting, a very interesting behavior,
what we found here.
So,
for example, it doesn't verify whether
the clear text begins with 0002.
It just verifies that it
starts with something zero two,
which is weird.
Um, but
one possible explanation.
I mean, we have talked to the developers,
but we have we didn't ask them
about this, but I guess it's, again,
something performance so that
they didn't care about the first part.
They only care about the second.
But this brings this
brought us a little trouble
because the linebacker's algorithm,
the textbook algorithm requires
that something starts with 0002.
So we had to adapt this
algorithm so that it also works with
something or 02,
which makes the Oracle somewhat weaker.
But we could still apply the attack
and we required four million
queries. Which is which
is which is a lot.
But it took 41 hours
to decipher tearless handshake
of one like one single
handshake.
OK, let's just make
a summary, so the first thing
that this is not something new, but
not many people have achieved this so
far. Timing attacks against
single digit microsecond delays
in TCP connections are practical.
So there are other papers who
did this against details.
For example, that is a diagram
based ServiceSource, like Euterpe,
for example, you send something and
something comes back.
It's a bit more involved and you want to
do the same over over TCAP connections.
But we found that it still works, which
is good.
A bad design and I should have quotes
here in bad design, a cryptographic
protocols might haunt you for decades to
come.
Um, when in 1995,
they make the decision that RSA
and PKC is one in version one, DOT five
is a good idea.
They brought a lot of trouble.
They didn't know that this can be
exploited that easily.
During that time. They had to wait until
1998 and until all
this. But the problem is we have been
living with a protocol that is
known to be broken for 14 years.
And now I hope it makes
sense when you when you remember
the thing that I said on one of my first
slides where I said protocol
decisions
like it can be very fragile.
Right. So everything that you have seen
here, like the implementation of tools in
this specific part, it's very, very
fragile. And you have to be very, very
careful to do exactly the right
thing.
And then also what is taunting
us is Makinen and encrypt.
So obviously
it's not possible and it's protocol
to just send them random
ciphertext over there and expect the
server to do something useful with it.
But also,
you have a thing that
guarantees your authenticity.
So you have a message authentication
code, and this is where where it
will fail any time.
But the problem here is, um,
you have Mac then encrypt.
That means the message authentication
code is a pendant
to the clear text and then encrypt
it.
Which I'm
sorry, which.
Yeah, so yes, sir, thank
you very much. So the problem here,
obviously, is in order to check the
message authentication code, you have to
decrypt the ciphertext beforehand.
So there's a lot of code running
before you can actually check whether
this is a valid message.
Right. So this is about what you want
to do is encrypt then Mac.
So you'll make like your encrypted
clear text.
You have a cipher text and then you do
your message translocation code on this.
And then the authentication code is
appended to the to the cipher text and
sent over to to
the receiver.
Yeah, implementing classes is a
minefield, and this may explain
why everyone keeps complaining
on the quality of of SSL,
for example. Right.
So, um, look at the Java code
looks much better.
This is really nicely object
oriented and everything, but can also be
broken. And it's broken in more
ways, I think, than than
ourselves.
OK, guys, thank you very much.
I'll be around at, uh, until the 30th.
So if you if you want to talk to me, just
just do it. I'm happy.
Thank you very much.
Now, it's a little bit time for
questions, I know that there's a one
question on the Internet and there
were discussion of this question for some
time now. So even if they managed
to answer it, maybe it's interesting for
everybody else. So I think we should
start with this.
Yes, there was some discussion
going on about, uh,
how hard is it to prevent
this kind of attack?
And, um.
Is it possible to do some random slip
in the code to prevent
the attacks?
OK, so the question was, is it
is it possible to fix it with just a
random delay? Right.
No, that's really a bad idea.
I've spoken this at length at my 2093
talk so you can can have a look at that.
The reason for that is you will decrease
the performance and the attack will still
be possible.
So this is not not a good idea.
You should just fix it in a code.
It's possible.
And at least for open source code, you
have you have like the source code.
So there are some more questions, and I
ask everybody who's leaving to be
a little bit more silent so that the
people who want to get the answers
can hear them. Thank you.
I specifically am interested in hearing
about how to mitigate these problems in
the future. You were referring to
sort of the the guys
who worked on standardization.
They did make some mistake.
But on the other hand, the work
is taking place in an open forum.
So there's a possibility for people to
engage and that would obviously help.
But what are other ways to
deal with those issues in the future?
So the problem is really so
Tlas was in 1995,
SML encryption that exactly the same
arose in in someone in the 2000s
when it was long known that this is
vulnerable.
There's a new thing that is called
Jason Vep Encryption Jocie.
They did the same errors
over and over again.
So we just see the same errors in
protocol design over and over again.
And they always argue that you need
to you need to support
these broken ciphers for compatibility
reasons.
So they have like the they have the
problem. If they don't support the broken
ciphers, nobody will use the standard.
That's the problem.
Which is a pity.
Sorry, the last question, when
they are
in your presentation, you talked a lot
about PKC is 105.
Did you have a look at the signature
scheme as well? And can you tell us if
this is somehow affected by
this problem as well?
Like the signature theme that is
is one inversion, one that five.
I don't think this is part of one point
five. The question is if the piece a
signature scheme has has a similar
problem. Um, not
not that I know of.
Of.