Dr. Carsten Ohl.
Thank you very much.
We saw we ran out of research topics in our research mission of warning people about outdated
security and others and ourselves went through all the old systems from the 80s and early
90s, found proprietary crypto, broke that.
This time we looked at an application where we didn't think we could find quite as much
because it's much newer, much more modern, still kind of having its use potential in
the future, not so much in the past, and it's built around standard cryptography.
So these are SIM cards.
However, we did find quite a lot and want to share this today.
Not just the research results, but also a little bit of, sorry, around the responsible
disclosure which I think is pretty unique, at least as far as our research are concerned.
We're looking at the problem here that was not just found and discussed openly, but also
in a lot of places fixed quickly, and at least in my research world that usually doesn't
happen.
So, all right, SIM cards.
Originally invented to create a link between a phone and a contract so that the charges
are built to the right person, also that the right number rings at the right phone.
So it's the bonding between the handset and the number and the charges.
Since then though, this is more than 20 years ago that they came up with the SIM card, it
has been heavily extended.
First by simple functions for older phones like storing text messages, storing the address
book, things that didn't fit on phones back then apparently.
Today, these functions are still there but rarely used.
However, the SIM card keeps growing through Java software.
And pretty much every SIM card for the last 10 years or so was able to run Java software.
And not just the Java software that it came with from the factory, but also new Java software
that you can download in form of apps.
So these are not apps that you would go to an app store and click, I want this, but rather
apps that somebody else says you should have on your phone and it's pretty much outside
of your control what is running on the Java.
So it's the operator dictating that.
And users that are popular in the wild are for instance roaming management where your
network operator may have preferential pricing with some networks in the country but not
others, so that the SIM card steers your phone to use certain networks and not others.
You'll notice that when you're traveling that your phone always wants one network even though
you're allowed to also use the others.
In the developing world, also payment is a popular SIM card application.
I hope nobody gets seasick.
I couldn't look at this very long.
Payment is very popular.
Africa, for instance, some countries do the majority of banking through mobile instead
of retail banking so that they never really had retail banking and then mobile came around
and now they're happy with that.
It's coming to us slowly too in the form of NFC payment tokens.
So also the European or developed countries SIM cards will become payment tokens that
has been coming for a long time and everybody expects it to be here any moment but they
have for the last five years that too.
So it's heavily extensible and what the future brings nobody can tell.
But for most everybody these functions lay bare.
You don't notice that something useful would have on the SIM card.
However, even though you don't get the benefit out of it, you do incur risk by having this
and that's what we want to discuss today.
Few words on what we are not going to discuss today because SIM cards are a large collection
of security functions.
So some that we won't cover are the pin codes of breaking this four digit pin code.
No interest in this.
In fact, the attacks we're doing are completely outside of what's protected with the pin code.
So that's a different part of the SIM card.
These are we concerned with the authentication function.
Some of you may remember the COM 128 hacks from six years ago.
So those were also an attack on a SIM card but on a function that's this hashing function
that we're not concerned with here.
These are we concerned with the smart card security.
Every SIM card is a smart card and of course that brings a lot of protection.
There's just good talks for instance by Christinowski where he shows how to break a smart card.
So this is a lot more effort, something like a few weeks in a well equipped lab.
But then of course through that you get access to the SIM card.
Would like it much faster and easier way, especially one that's non-destructive.
So in this talk we're concerned with Java software as it's running on the card and as
it's being deployed to the card with the protocols that facilitate that.
And we want to concentrate on these two things.
How does Java software get put onto the card and how can we possibly abuse that?
And then once it's on the card, what can it do and how can you possibly elevate the privileges
that it has, kind of routing the card.
Sounds good.
Right?
So these protocols that are used to deploy Java onto the card called OTA over the air
and they work by sending text messages of a specific format.
So these are not text messages that the user would ever get to see.
They are specified as the handset must send them directly to the SIM card and pretty much
every handset does that.
So this is universally supported by phones.
Don't inform the user, just put it on the SIM card.
And for things like roaming management, that's probably advantageous.
The user doesn't want to be buzzed with all that management stuff that goes on in the
background.
There are security functions that are commonly used.
You can both require cryptographic signatures.
So this is Max because this is symmetric key crypto as well as encryption, again, symmetric
key crypto.
And most every card that we have come across requires signatures.
Some cards in addition, require encryption.
A few cards only require encryption.
And if you think about it, since it's symmetric anyway, it doesn't make a big difference whether
you use encryption or signatures as long as the commands are well formatted.
So the communication is facilitated through these SMS that are then encrypted and assigned.
And the keys that are used as well as the security level that is required for this communication
is burned into the card at manufacturing time.
So you're not supposed to change anything about this.
In particular, you're not supposed to change the use of the encryption algorithm later on.
And a lot of manufacturers, well, network operators I should say, choose the worst of
three choices.
So among AES, triple-desk and DES, they go with the 70s era DES algorithm.
Nobody really knows why.
And if you ask them, it's just kind of a legacy thing.
And in fact, even when you ask the people that wrote these standards, they don't really
remember why they put DES in there at all.
So this was specified at the end of the 90s.
And back then, most everybody has already moved away from DES to triple-desk for backwards
compatibility with all the hardware or to AES predecessors.
It wasn't standardized back then yet, but people already knew how to build better, faster
block ciphers than triple-desk.
So somehow it snuck into this standard, and we find that about half of the world's SIM
card used this very old standard.
Sometimes in a mix with newer standards too.
So every card can have different keys of different security levels, but of course, weakest link
security principle applies.
So whatever the weakest key is makes the card vulnerable.
The use of DES would allow for an attack where, let's say, you passively intercepted one of
these messages, you could brute force the key.
An academic attack may be practical in a few circumstances, but certainly limited in two
ways.
First, you get to wait for some auto communication to happen.
Probably your best chance is to hang out at an airport, for instance, where a lot of roaming
management will happen to phones that just landed in a new country.
But it's still, you know, you're gambling, and you'll get random people's auto messages.
Secondly, to brute force a desk key, even though it has been shown possible many, many
times before, still expensive.
The first machine to do it was Deepcrack that costed a million dollars.
Today it's cheaper, but still perhaps at a price point where you say that's not worth
it for breaking SIM cards.
So we want to lift these two limitations.
The first limitation being that you have to wait for auto to be sent by other people.
Here's a way now to force the card to send you auto text to work with.
And this is what used to be a gap in the specification.
They fixed it by now, but even new cards don't necessarily implement a new standard always.
They didn't specify what happens when you receive a wrong command or a correct command
with the wrong signature, I should say.
Some cards just ignore that.
They say the signature didn't match.
I'll throw this away.
Some cards respond with an error message, and some of these cards sign the error message.
Perhaps thinking that, you know, if they didn't do this, it would allow some form of denial
of service against the auto server, because now everybody can send error messages unsigned.
So the behavior differs.
And when they do send a signed error message, that of course is now a message that you can
break the key from.
And about a quarter of the SIM cards that we tested over the last couple of years have
this behavior.
And we also measured it at home with your help, and we'll come to those results in the
end.
And it seems that our sample set definitely holds up.
So that lifted the first limitation.
Now you can just give them a phone number.
Find a message to work with, right?
You sent a wrongly signed message to the phone, and it may respond with a signed error message.
Still you have the second issue that you don't want the $1 million machine, or rather today
it will be 50,000 euro for an FPGA cluster that breaks a desk key in one day.
Still maybe not worth it.
However, you could, if one condition holds, compute rainbow tables.
The very same thing we computed to break A51, another cipher with a too small key used in
phones.
So the desk key is 56 bits.
Brute forcing it takes a day on an expensive machine.
Precomputing it also takes a few brute force cycles, but you'd only have to do it once.
Precomputing though relies on the property that the message is predictable, that you
can force a phone to sign a very specific message.
And each phone should please sign the same message, because for this message and only
this message you precomputed the tables, right?
So let's look at the communication as it's happening and investigate whether the hacker
can actually get a known chosen response.
So the query simply states, you know, this is a binary SMS through some header, so this
is the type that the phone knows to send to the SIM card.
It specifies the security, both the security that it uses.
So this for instance says, I don't use encryption, but I put a signature on it.
And it also specifies kind of as a wish list what it would like for the SIM card to respond
with.
And it says also you should not encrypt, but please sign it and send it anyway, even in
an error case.
So not all SIM cards honor this bit, but those that do that then give us plain text.
It says which key should be used.
So there's a couple of different keys and you may need to kind of brute force them through
several SMS.
Not all of them may be vulnerable.
It targets a specific application.
Each of them can have their own keys.
And it includes a signature, of course a wrong signature.
We can't compute at this point the right signature.
The card then responds again as a binary SMS, again the application number.
It includes a counter.
This is meant as a security feature against replay attacks.
Fortunately for this attack, the counter is only checked after the signature is being
checked.
So since the error code says the signature is wrong, the card never got around to checking
whether the counter matches and it just copies the counter from the response.
And the response itself is this error code.
So five fields, one, two, three, four, and the fifth at the end, are either chosen or
static and only those go into the crypto signature.
So somebody can choose the entire message now and then compute the rainbow tables.
So a lot of design decisions influence this here.
That now it's not the million dollar machine anymore, but it's a single computer to break
one of these keys.
And before I explain how that actually works, let's actually start doing that because it
takes sometimes a minute longer than I would like for this demo.
And let's start by collecting signatures from one of these cards.
So I'm not going to do this over the air.
That's pretty unreliable.
And in fact, a lot of networks also started filtering these queries by now, kind of firewalling
from the attack.
So we'll do this passively.
But using the exact same messages I would be sending over the air.
Let's see this tool I want.
The font size.
Let's see how they do this.
Command plus already.
So that broke it a little bit.
So basically what this does is it sends SMS.
It pretends to be the phone, and it sends those SMS that it received onto the SIM card.
And then sometimes the SIM card responds with a cryptographic signature.
That's what you see at the end.
Sometimes it doesn't.
And this goes through, as I said before, kind of brute forces the different keys.
At least the first six is actually more, but in our experience they're never really used.
And it uses a few different messages.
So actually we run a few different attacks in parallel here just because there's different
error codes sometimes coming back.
For each of them we need our own rainbow table though.
And then we take one of these cryptographic signatures and then run it through a cracker.
All right.
Submit.
Let's see.
So this is now going on in the background.
May take like two or three minutes.
Sometimes it's faster.
Let's come back to this in a little bit.
Let me explain in the meantime what's happening here.
What is a rainbow table?
Rainbow table is an optimization on a code book.
And a code book is when you compute a secret mapping for every possibility and keep a record
of it.
It's kind of like the phone book, right?
If you consider the mapping between a person's name and their phone number to be a secret
operation it's simple to go one way by calling them.
It's pretty hard to go the other way, right?
Unless of course you call everybody until you hit the right person.
It's brute force.
But while doing that you can write the phone book, right?
Because then you know everybody's phone number.
And that's exactly the simplest time memory trade off point where you spend a lot of space,
phone book pages, but little optimization.
And in fact with a single look up you can then find everybody's number.
Now doing this for two to the 56 entries is petabytes in size.
So this may not be an optimal attack unless you have infinite hard disk space.
There are other trade off points though and that's where it gets interesting and gets
into this discussion of rainbow table.
So instead of just having a two column data set you have a multi column data set and they
are linked through in this case the desk computation.
So you start with a random value and you compute desks on it.
You treat this as a key again and compute desks and treat this as a key again and compute
desks.
So it's the same, right?
We predicted the plaintext before.
And this data set also is kind of like the phone book only a little bit more complicated.
But let's assume the same values are covered in this entire data set of which then you
only keep the first and the last column.
The rest you throw away.
And if this like in our case is 32,000 links then you only need I guess 16,000 of the storage,
right, of original.
So then you come from petabytes to terabytes, much more manageable, just cheap hard disks.
However, the look up of course now is more complicated.
It's not a simple look into the phone book.
Instead you have to do some more computation.
So let's say you observed this value as a signature 2F06.
You try to find it in your data set and it's not there.
You didn't install this value.
So what you do is you compute the desk function on it, right, kind of working your way backwards
into the set.
You again look into it, still not there.
You compute the desk function on it again.
Now you find it, right, in this case because it's two links from the end.
You find it here.
You know what chain it belongs to.
And if the public value is in the chain, the secret value is also in it just one step before.
So you recompute the chain up to this point and you got your secret.
So that's the simple time memory trade off.
Now in this super simple case, it doesn't actually work very well because as you can
see here, sometimes values collide and then you generate a lot of redundancy.
Chains become more and more similar and if this is terabytes in size, most of it will
be redundant.
And that's where people came up with this idea of now rainbow table, meaning you use
a different color in each iteration and this color can be as simple as an X of a static
value.
So this would be the desk computation still, but X01, desk computation X02, X03 and so
forth.
Now if you have a collision here and it's not exactly in the same column, you don't
generate redundancy so much.
So that's the optimization we needed to do to achieve any reasonable coverage with this.
And our data set is still not perfect, something like 30% coverage, but as a proof of concept,
it certainly works well.
So let's go back here and this actually does say crack now, so it did find a 56-bit key
here on a standard computer, not this computer, but one back in Berlin in however long this
took now, a few minutes.
So that's the first, that's the cryptographic optimization that now at least I think moves
this into the realm where everybody could be attacking SIM cards, right?
The cost is very low now.
All right, everybody good on rainbow tables?
Everybody got the concept?
So time memory tradeoff, you spend a little bit more time now than it was the code book
through all these computations.
In fact, quadratic, so that's what moves it into minutes, but you can store it on a simple
computer.
Oops.
So yeah, let's skip this because I've already shown you how to catch the signatures.
What I'd like to discuss now for just a minute is how some of the companies responded to
this research, some of the network operators.
So I should say before that a lot of them responded very constructively, but still some
shrug it off a little bit too quickly.
One of the American operators, for instance, publicly said to the press, we didn't even
look at the problem, we know we're not affected.
And I think this is a little bit too fast.
So here's three things that the operators came back with saying.
Some of them point out that they don't even require signatures, so this attack wouldn't
apply and said they use encryption.
And you know, both is CBC, so it really is a replacement.
However, that actually makes the attack worse because more cards respond with an encrypted
error message when you ask them than with a signed error message.
And the only difference now being that you'd have to compute a different rainbow table
because now you're not predicting the crypto signature anymore.
Now you're predicting the encrypted version of it.
So whichever operator said that, now they should go back and check the exact configuration.
Others stated that they don't use OTA at all.
Well, good for them.
However, their SIM cards do.
And even if you as an operator lost your keys, they're still there and crackable.
So in fact, I think that may make it a lot worse because you may not even have changed
the key from factory keys.
You may never have considered updating to a new encryption standard.
So those operators certainly also need to go back and do a little bit more homework.
Now the third case is the most interesting because it actually follows what we would
recommend them.
They say we have triple deaths.
We're not affected.
Now some of them forget that, of course, they only changed over to triple deaths, say, a
year ago or two, and many SIM cards are older.
But even if they had triple deaths for a long time, they could still be affected.
And that's for at least three reasons.
There's probably more ways to screw this up.
Some operators changed from deaths to triple deaths on the cards, but not in a database
layout.
So they still only have 56 bits to store a key, which either means they use 56 bit and
then pad it with zeros, or they use the same 56 bit key multiple times.
And if you do, so there's two variants of triple deaths.
There's a two key variant and a three key variant.
If you use the two key variant, at least you get something different if you use the same
key twice than what deaths would look like.
But in a three key variant, it's encrypt, decrypt, encrypt.
So if you use the same key, they just cancel out.
And one operator, at least, was very confused when we told them we could break it with our
desk table because they thought they were using triple deaths, but they have downgraded
it automatically to death, just spending more time computing the exact same thing.
Some operators did not change the standard keys.
So a triple death key that is a standard programming key for this would be 0A, 0A, 0A.
That's not very hard to crack.
And then some cards, this is only on very specific cards, are attackable through a downgrade
attack.
Kind of stumbled across that by accident, too.
It's also something that the standard is not so super clear on, but everybody who thinks
about it for a minute sees how stupid it is to not implement it the way where downgrade
isn't possible.
So what's a downgrade attack?
This where the card is kind enough to sign error messages, whatever you request it to
sign it with.
So if you say, I sent you a death signature, and then the card says, no, your signature
was wrong, and it signs that was death.
If you send it a triple death signature, it again signs the error messages with what you
chose.
You still need to break the triple death key.
It will not accept anything unless it's triple death signed as correct.
However, now you can crack these in portions.
The key is stored in the memory as three different 56-bit values.
And when you specify an algorithm that uses a shorter key, it just takes the first part
of the key.
So we already know how to break a 56-bit key, the first 56-bit key.
That's through the signed error message, look it up in the rainbow table.
The second one now would be signed with a 112-bit key.
So that's too hard to brute force or to build a rainbow table for.
However, since the first 56 bits are already known from the earlier attack, the entropy
collapses to a 56-bit set mode.
So you have now a brute force attack on 56-bit.
And even the last one where they really used the state of the art three key triple death
and becomes a 56-bit problem.
So I need to emphasize, this is only on a few cards from certain manufacturers.
But still, with Java operator set, we didn't even look at the problem.
We are not affected.
They better look at this before they conclude.
So downgrade attack on triple death.
So to summarize this first part, cards are affected when they're responding to a wrong
signature with a cryptographic signature.
Not just zeros in the signature field, but actually valid signature.
And if they either using death, then they're affected directly.
Or when they're prone to this downgrade attack, then they are affected a little less severely.
Because now somebody would actually have to go through two brute force cycles instead
of just computing a rainbow table.
But so all in all, somewhere between half a billion and a billion cards, we estimate,
are affected by this fall into this box.
So it's not everybody's card.
In fact, it's just a small percentage because there's billions of cards.
But small percentage of billions still is a large, large number.
Everybody got so far?
Then we move into the second part now to see what a, let's call it a virus, a Java virus
on the SIM card could do.
Now you crack the Otaki to sign viruses and you can deploy them again through SMS, probably
more than one SMS.
But these are, you can basically send arbitrary lengths Java onto the card.
And the card exposes certain functions to all Java applets that of course the virus
can abuse.
Included obvious things like sending SMS.
That's how an applet would usually communicate with its server.
But also included a function set that where it's not all that clear why a SIM applet would
ever need to do that.
For instance, dialing a number for you and then sending DTMF tones.
That's very useful for a virus that wants to lock into your voicemail and reconfigure
things or forward messages.
Not sure where else it would be useful.
USSD is asterisk, 100 hash, these short codes.
It's also used by some SIM applets as a more reliable communication channel than SMS.
USSD doesn't get buffered somewhere and maybe delayed.
So it's clear why it's on there.
For abuse it would allow you to for instance change the voicemail number and redirect all
calls.
Perhaps if you do it smartly you'd redirect it, but then again redirect it to the original
number so you sit in the middle.
You have to switch off the redirect quickly though.
So it's a timing exercise.
The SIM card for whatever reason is allowed to ask for your GPS coordinates and then send
it through silent SMS to whoever is asking.
Supposedly in some countries this is actually used and people are regularly tracked.
But again, the virus can abuse this.
And then the most interesting one that I've never seen in use is the SIM card can ask
your phone to open a URL in the browser.
And of course that allows for all kinds of interesting attacks where you ask the user
to install an app or spoof a banking website, anything like that.
So these are all the functions that are exposed to any Java and that are accessible no matter
what.
There's also data on the SIM card that should be protected.
For instance the master key, this KI key from which all the other cryptographic keys derive
that protect communication.
So GSM, UMTS, LTE, everything is protected by cryptography at different security levels
as we know.
And all of this derives from one master key.
So that would be a very interesting key to steal as are some other items on the SIM card.
But since this is Java software, it should really be constrained to its own memory space
through sandbox.
And building a sandbox should not be all that hard, one would think.
However, those security companies that build SIM cards apparently fail at even this basic
exercise.
I should say again, some of them, right?
Not every SIM vendor is equal here.
But the main two one are and equal in the sense that they can't implement Java sandboxes
apparently.
So through some queries that are basically just exceeding array bounds but in less than
very straightforward ways, the Java is allowed to read anywhere in memory and even write
anywhere in memory.
And the construct we're not disclosing exactly, we're still in responsible disclosure.
The construct has to do with multi-d referencing.
So if you just give a simple integer or I guess short in this Java world to the too
small array, if you exceed it, that is checked and you get an exception that says, well,
you're trying to read a value from your array that doesn't even exist.
It exceeds the bound.
But if this value is fetched a little bit more complex through multiple dereferencing,
apparently the check doesn't happen anymore.
And then you're allowed to read and write anywhere.
So meaning you can, for instance, steal this master key to decrypt all communication.
You can read any other Java process that also lives in its little sandbox, but now you're
underneath all of this and really break into any security they may come up with in the
future because now you're on the operating system level.
And to show what's then possible, let's see.
So we cracked this key.
We deployed the virus.
The virus read this very specific part of memory that's this Ki key and that allows
us to basically emulate the card.
So I have a phone here that has no SIM card in it, but also I have a little piece of software
that emulates the SIM card entirely from this stolen Ki value.
And let's see.
So this is now using the OsmoCon software.
It's very popular for a whole range of attacks on GSM.
Let's see.
So now this should be logging into one of the Dutch networks, and then we can use it
as a normal phone.
This step sometimes takes a long time, so let's be patient for a few seconds.
These phones, they used to be a few euros on eBay.
They've gotten up in price every single year, but they are very useful.
Let's also come back to this in a minute or so.
Not sure what exactly it's negotiating here.
So to summarize the attack and what I'll show once this logs in, against a certain percentage
of SIM cards and at least a couple hundred million SIM cards, somebody can just give
them a phone number, send commands there, get stuff back, run it a few minutes through
a rainbow table, have a key with which they can sign Java software, download the Java
software onto the card, already do a bunch of abuse, like send SMS to expensive numbers,
but also then further dig into the card by breaking out of the Java sandbox and read
and write anywhere in the SIM card to the point where you can do a full SIM clone.
Yeah, thanks.
Let's restart this because I'd really like to show you the clone SIM.
We'll come back to it in a minute.
Sorry, demos are always a bit of a risk.
Let's discuss just for a brief moment what network operators or others can now do to
prevent this type of an attack.
The obvious short-term thing to do, of course, is to filter these very strange messages that
the attacker is exchanging with the phone.
This should not really happen that two phones exchange these management messages.
They should only ever be sent between phones and the OTR server.
But even that's a little bit complex because how do you know what are OTR servers of, let's
say, other networks for which you have to hand down the OTR messages to their roaming
users?
So as a short-term solution, a lot of networks have actually implemented this already, which
makes it harder and harder for us to research this or even demo it over the air.
So when we tested this morning, probably the Dutch network actually filters what we're
trying to send to Germany and get back from there.
Sometimes they over-filter a little bit.
For instance, roaming optimization in one big European country doesn't work right now,
so they really filter everything.
In one instance, even FaceTime stopped working.
When you try to start an Apple phone video chat, they send a specific SMS of a different
type so it shouldn't be caught by the filter, but they definitely over-filter it significantly
in a few cases and maybe now it's swinging back.
Some networks don't yet filter, so it's all over the place.
However, no level of filtering is, for instance, going to prevent image catcher-based malware
installation.
So when you just start a fake base station, and there's a couple around here too, I noticed,
that of course then circumvents any type of network-level filter.
You talk to the phone directly.
Same with a virus on the phone side, let's say an Android virus, that can of course speak
to the SIM card directly if they wanted to maybe put the root, get a little deeper than
Android side.
So operators are encouraged, and some of them are doing it already, to find more long-term
solutions.
One long-term solution, especially for those operators that don't use the OTA much anyway,
would be to just deactivate it.
In fact, on some cards you can do that yourself by sending too many wrong signatures to it.
Eventually it'll stop responding.
It has an error counter in it.
And just six or ten is usually enough.
So some operators actually did move to deactivate OTA and then probably will then replace cards
eventually or hope that you replace your card.
And they came up with the next form factor and the next form factor, so now people are
kind of pressured more into using newer cards.
More elegant solutions, however, reconfigure the cards.
And this is probably my favorite part of this entire research.
And I only realized how they do it like a week ago.
So the standard very specifically says you're not allowed to change your security settings,
probably thinking that otherwise people could do downgrades of the security settings.
But this time they want to do an upgrade from DES to Tribble DES or AES, not allowed very
specifically.
So to do it anyway, what at least one operator has done is they put a Java applet on the
card that then uses the sandbox exploit to hack into the operating system and rewrite
parts of the operating system.
I think that goes a long way in showing how good industry can be at adopting a hacker
mindset.
And I didn't think they would do it this way.
But yeah, apparently that's what they do.
Now ironically, of course, those cards that don't have the Java bug, so that only have
one bug, they don't get to patch the one bug.
They're lacking the second one.
So sometimes it helps to be double vulnerable to then prevent the worst vulnerability.
And then as a perhaps complimentary long-term solution, I think phones should really give
users more control over these auto messages.
Every baseband could possibly filter these messages too.
The phone doesn't have to, from strange sources, hand down SMS to the SIM card.
But it does.
And it gives you absolutely no control over what's going on.
Very, very old Nokia phones, they still ask you, do you allow the SIM card to respond
to some strange SMS?
And you could say no.
I'd like for this feature to come back and to at least have some way of modifying it,
perhaps in Android.
Right, so okay, so this actually finally logged in.
So it's connected with Vodafone now, but it has nothing to do with Vodafone really.
It's a roaming card.
So let's try to call myself.
No prank calls, please, on this number.
Oops.
So, and this looks like this is ringing.
So my, I'm trying to hide the phone number so they don't deactivate this card.
So this phone with no SIM card is now calling me based on a cracked KI key.
Oops.
Thank you.
All right.
So some operators already moved to preventing this.
Others are lagging a little bit behind, but hopefully we'll do so too soon.
We estimated somebody who really wanted to put all these pieces together would take six
months.
It took three years, but of course now we already said where to look and what tools
to use.
So in six months, there could actually be criminal abuse of this.
So this is plenty of time for all network operators to come around and fix these bugs,
perhaps by exploiting their own cards, if that's what it takes.
And we did actually think that by now already a lot of cards would have some of these bugs
disabled.
My colleagues here for the last three days and today again ran a workshop here to test
cards.
And many of you came and thank you had your cards read out by us.
And we did think that we would now observe that a lot of cards already did get fixed,
like with the networks that we're in close touch with.
But that doesn't actually seem to be the case.
In fact, your sample set, of course not representative, but so those cards that we did sample actually
give out more plain text than the cards we collected over the last couple of years.
And this is even though some of your networks will already have fixed this.
So it seems that currently the networks are heavily focusing on filtering, but not many
are doing something to the card to improve it yet.
So during the same workshops, we also found yet another issue that we hadn't been aware
of and that is terribly chosen keys.
So here just a couple of example keys from cards that we broke over the last three days.
So you see this key, how it has all these zeros.
So this has at most 16 bits of entropy.
So there's eight ones in it, so you'd think that they flip the coin 16 times.
That's breakable even on my laptop in a few seconds.
And if you have a terrible entropy source that generated this key, moving to AES for
instance does not help.
So a lot more cards could be affected once people start specifically looking for instance
for weak keys.
And this was not an isolated case.
So you see how all these keys actually fall short of their 56-bit entropy limit.
So this one could be just a sampling variance.
It could very well be that this is 56-bit, but all of these are clearly fall way short
of the mark.
So we hope sincerely that this is not the research that broke SIM cards and then they
got fixed.
It's the research that starts a whole research field of breaking SIM cards in a lot of ways.
And I think this would be an interesting avenue here.
Few words and then I'm done on responsible disclosure.
And we don't usually talk about this very specifically because it's the same old story
almost every time.
You publish research results, industry tries to talk you down, criminals find it more interesting
than industry, criminals actually do it, industry can't talk you down anymore, they fix it eventually.
Not this time though, at least for those operators that were open enough to start this dialogue
months ago already.
So we've been in many, many months of responsible disclosure now and found that everybody is
working very hard for this to be fixed.
And I think the hacking into their own cards to fix them goes a long way to showing the
mutual respect, right?
Both from us that we respect them and don't want to hurt them too much if we can prevent
it but also they for our methods and our results and our ambition to actually make it better
by making it worse in the short term, right?
By showing the problem and then fixing it.
Interestingly enough, the sentiment in the industry this time didn't have to be convinced
first.
We finally talked to people, it's after we told a lot of lawyers, leave us alone, we're
not going to sign an NDA.
Just accept this as free research that you can use but don't try to get us into your
machine.
This time they didn't even try.
And I think the times have changed a little bit.
I think that it definitely helps that no company now wants to be responsible for the NSA hacking
into your phone, right?
I want somebody else to be responsible for that.
But also I think what helps in this case is that it doesn't just affect the privacy of
potentially everybody, it also affects their revenue streams, right?
So they focus on something where they can lose money.
Ironically all the other research we have done in related areas like the A51 research,
these things have not been patched yet.
So we have four years worth of results of which only the most recent has been fixed
in record time.
So perhaps we need to find a way of creating criminal business cases around these other
attacks that would actually hurt them financially for them to change.
On the right hand side here, just for future reference, a few lessons learned from our
interaction with industry.
And I hope this research was motivating enough so you do get to break your own SIM card,
find new ways of doing it.
And once you do perhaps this helps you work constructively with industry to fix this.
It's definitely very, very rewarding for us to see how much change we already initiated.
And so overall a great, great research project that I think helps everybody in the end.
Well, with that, thank you so much for your attention.
I'm afraid we don't have time for Q&A after the sessions.
I'm sorry.
Yeah.
So we can do all the questions and everything in this age tent.
My colleagues are already there and we'll do one final round of reading everybody's
SIM cards who's interested and then we'll do questions there too.
So age tent.