Roo2ng

SIM cards

The SRLabs Team

SRLabs Template v12

SIM cards are fully programmable computer systems

Applica'ons on modern SIM card

Smartcard with real-2me opera2ng system

Basic func'ons Simple le system Java virtual machine

Iden2ca2on (IMSI) Address book Custom Java apps
Authen2ca2on (Ki & SMS messages Roaming mgmt
Hash func2on)
Session keys Payment
Tracking

2
SIM security involves many layers from smartcards to cryptography
and Java process separa2on
SIM card includes various protec'on mechanisms

User authen'ca'on B Applica'on separa'on:

by simple comparison Java VM sand boxing
PIN/PUK
numbers
Individual protec2on
logic for banking
SIM authen'ca'on applets, iden2ca2on
by cryptographic hash func2on applets, etc.
(oLen Comp128 in GSM; Ki
Milenage in 3G/4G)

A Secure Java deployment

using DES/3DES/AES OTA
signature + encryp2on keys

Storage protec'on Java crypto API: DES/3DES/AES;

through proprietary smartcard some2mes RSA
security mechanisms

3
Agenda

SIM card background

A GeDng on to the SIM

B Stealing SIM secrets

4
OTA security level is chosen by server while SIM ILLUSTRATIVE

enforces mandatory minimum level

Binary SMS communica'on

OTA server Target app / key set # SIM card stores mul2ple
ini2ates key sets, possibly with
remote Command Used Reque- dierent protec2on levels
transac2on possibly security sted
encrypted level security Key set 3
and/or level Key set 2
signed
Key set 1
Man-
DES 3DES AES datory
Response protected Encry-
according to request,
p2on
but not below minimum
level stored on card Signa-

ture

5
OTA error handling is underspecied, possibly opening acack
surface

Binary SMS communica'on

AOacker SIM card

probes cards Command with Use: DES Request: DES with DES
to gain wrong signature signature signature key
material for (prevalence of DES
DES key keys varies between
Response to mal-signed request diers by card type
cracking operators; can be up
a.(25%* to 100%)
of cards) (No response)

Some2mes
b.(50%*) Error message with all-zeros
signatures

c.(25%*) DES
Error message
signature

Data useable for key cracking

6
* Es2mated from rela2vely small and geographically skewed measurement set
OTA DES do not withstand key cracking

Challenge: Derive 56 bit DES key from OTA response signature

Cracking strategies Investment Cracking 'me

EUR 1.000 6 months
Be pa'ent
Brute force on GPU

EUR 50.000 1 day

Throw money at it
Brute force on FPGA cluster

Ride the rainbow EUR 1.500 + 1 minute

Time-memory trade-o 1 year pre-computa2on (but <100% success rate)
using large hard disks & GPU Only possible when OTA
response is fully predictable

7
Acacker SMS asks for DES-signed SMS response with fully
predictable content
Acack-specic features
Command packet
is sent by the acacker to provoke response
UDHI PID DCS UDH CPL CHL SPI KIc KID TAR CNTR PCNTR CC Data
1 127 246 027000 Packet Header No ciphering No DES App 01 Padding Rand. Generic
length length Sign cipher signature counter invalid command
PoR request

Packet details: 0 0 0 1 0 0 1 0 0 0 1 0 1 0 0 1

No ciphering Do not cipher PoR

Cryptographic Sign PoR
checksum Send PoR in any case

Response packet No
may oer acack surface response
UDH RPL RHL TAR CNTR PCNTR Status Code CC Data or
027100 Packet Header App 01 Padding Status Code Crypto- Response
length length counter Checksum

Signature over predictable data useable

for rainbow table key cracking

8
Pre-computa2on tables store DES code book in condensed form

K K K
E233 2F06 503A OCFE

K K K
DB18 B951 CAF3 77CF
K K K Collision
22CB A8F3 CAF3 77CF

K K K
87A4 49A6 118F B33F

The uncondensed code book is petabytes in size. Tables provide a

trade-o: Longer chains := less storage, but also longer acack 2me

9
Table op2miza2on: Rainbow tables mi2gate the eect of collisions

K1 K2 K3
E233 44B2 BBA8 1B22
Collision
K1 K2 K3
DB18 ODE3 44B2 5DE2
K1 K2 K3
22CB 6C7A 55D2 922A

K1 K2 K3
87A4 11F6 362E C7D5

Rainbow tables have no mergers, but an exponen2ally higher acack 2me

10
Source:ct
Video and live demo: Remotely cracking OTA key

11
Video source: hcp://www.heise.de/security/ar2kel/DES-Hack-exponiert-Millionen-SIM-Karten-1920898.html
OTA acacks extend beyond DES signatures

Many mobile operators responded to the looming SIM hacking risk considerate and faster than
we could have wished for others (too?) quickly concluded they were not aected

Recent operator statements Does it make sense?

No. Encryp2ng a known plaintext with DES is as bad
We use encryp2on instead of signa- as signing it. Even when both are required, the
tures; the acack does not apply here acack s2ll applies (but needs two rainbow tables)

No. virtually all SIMs are Java cards. Even if you are
not using those capabili2es, an acacker may (and
We dont even use OTA
will probably nd that you never cared to update
the keys of this virtual waste land)

Maybe. 3DES is good, but have you
We only use 3DES made sure to use full entropy 112/168 bit keys
instead of mul2ple copies of a 56 bit key?
changed all the standard keys?
heard of downgrade a*acks?

12
For some cards, even 3DES keys are crackable

Downgrade aOack ow
AOacker Request DES-signed Some SIM
Command
response (KID = 1) cards with
3DES key
Crack rst Error DES-signed use lower signature
third of key schemes when
requested (in viola2on
Request 2-key 3DES
Command of the standard)
response (KID = 5)
Crack
second Error 2-key 3DES-signed 3-key 3DES
third* 2-key 3DES
Request 3-key 3DES DES
Command
response (KID = 9) 56 56 56
Crack bit bit bit
nal Error 3-key 3DES-signed
third*

13
* Must be brute-forced; Rainbow table acack no longer possible
Only some cards provide crackable plaintext-signature pairs

Acacker sends OTA command with wrong DES signature reques2ng DES-signed response

Cards responding with a valid DES signature are vulnerable

CC length No 0 Bytes 8 Bytes

response

CC content All zero or other Valid signature

xed pacern (random pacern)

DES crack
No Yes

DES
downgrade No Yes

Vulnerable No
Not to this acack
No No No Yes Yes

14
Agenda

SIM card background

A Getng on to the SIM

B Stealing SIM secrets

15
Java virus does not automa2cally have access to all SIM assets
Java sand box
should protect
cri'cal data on
OTA-deployed SIM virus can access SIM Toolkit API SIM Data access on SIM would enable further abuse

Standard STK Protected

func'on Abuse poten'al func'on Abuse poten'al
Premium SMS fraud SIM cloning
Send SMS Read Ki
Decrypt all 2G/3G/4G trac

Dial phone Circumvent caller-ID checks

Read OTA Lateral acacks
numbers, send Mess with voice mail keys
DTMF tones
Clone NFC payment takers
Redirect incoming calls; Read Java
and other future SIM
Send USSD some2mes also SMS processes
applica2ons
numbers Abuse USSD-based payment
schemes
Write to Flash Alter OS to prevent
Track vic2m or EEPROM vulnerability patching
Query phone
loca'on and
seDngs

Open URL in Phishing

phone Malware deployment to phone
browser Any other browser-based acack

16
Java VM on many SIMs fails to conne malicious applets

Java VM
needs to
Java virus may try to intrude on enforce Other Java programs and na've
other parts of SIM sandbox SIM func'ons store value secrets
boundaries
of each app Data in SIM Abuse scenario
Ki SIM cloning:
SMS/call
Banking
Simplis2c memory boundary Java VM enforces fraud,
applets
viola2on acempt:
X = small_array[1000000]
X array boundaries
and stops request Iden2ca-
Steal balance
2on applets Impersonate

More complex construct

All secret informa2on on SIM is
to violate memory Java VM fails to
boundaries
(responsible disclosure
! detect viola2on &
processes request
exposed to malicious applets
through vulnerabili2es in several
popular Java implementa2ons
with vendors ongoing)

17
Putng it all together Remote SIM cloning

Inltrate card with malicious

A B Exltrate valuable data
Java applet

Ac'on Send binary SMS Crack DES Leverage gaps in Java VM

with OTA signing key, then memory separa2on to access
command to sign Java virus & arbitrary SIM card data
card, reques2ng send through
card response binary SMS

Result Card may Card installs and Malicious applet extracts
respond with a executes signed Ki, banking applets, etc., and
DES- signed error Java applet send to acacker via SMS
message

18
Wide-scale SIM hacking risk must be mi2gated on several layers
Low High
Mi'ga'on layer for
OTA hacking risk Eec'veness Cost
Prevents probing in home Func2onality
Filter OTA messages Network operators
network; leaves SIMs exposed readily
from unapproved short-term
when roaming, to fake base available in
sources mi2ga2on op2on
sta2ons, and to phone malware most SMSCs

Deac2vate OTA on Prevents acack (but also any Can be done

card future use of OTA w/ DES key) through SMS

Prevents acack (expect for Some cards

Use 3DES or AES OTA where downgrade acack need replacing,
keys works) others updates Network
operators mid-
Prevents the acack Some cards term mi2ga2on
Use cards that do not op2on
need to be
disclose crypto texts
replaced

Filter suspicious Prevents the acack New soLware Complimentary

func2on for mi2ga2on op2on
messages on phone for phone
base band future phones
manufacturers

19
Industry response was encouraging for responsibly disclosing
hacking research
The responsible disclosure went
surprisingly well and is worth
Take aways from a number of responsible disclosure that all
men2oning
went well (except for one)
We disclosed several months ahead
Find construc've partners in the industry; ask other
of the release to trusted contracts
hackers for their recommenda2ons
made around previous releases
Disclose early and dont be surprised if even the most
Experts from a few large companies
mo2vated disclosure partner takes months to distribute
veried the results and created best
the informa2on conden2ally in their industry
prac2ce responses
Bring someone with disclosure experience to mee2ngs
Industry associa2ons disseminated
guidelines to all other operators Expect friendliness and remind your partner of the
required e2quece should they ever act rude or arrogant
Many networks are now well
underway implemen2ng ltering Help your technical contacts win the internal bacles:
and reconguring cards Refuse to speak to their lawyers; never sign an NDA prior
to your disclosure
Only a single lawyer stumbled into
the interac2on, but quickly leL Be extremely careful accep2ng money; and only ever to
help with mi2ga2on

20
Take aways

A Some DES-secured SIM-cards allow for

remote key cracking and applet installa2on

B Java vulnerabili2es enable acacker to

remotely extract Ki, banking applet data

Mi2ga2on op2ons exist on network,

baseband, and SIM card level

Ques2ons?

Karsten Nohl <nohl@srlabs.de>

21