2. Security
research
is
successful
if
vulnerabili=es
get
removed
2
Industry
assesses
impact
and
implements
counter
measures
Security
researchers
discover
new
vulnerability
classes
(and
some=mes
mi=ga=ons)
This
talk
focuses
on
the
industry
response
to
mobile
network
security
research
4. SIM
cards
are
fully
programmable
computer
systems
4
Applica=ons
on
modern
SIM
card
Basic
func=ons
§ Iden=fica=on
(IMSI)
§ Authen=ca=on
(Ki
&
Hash
func=on)
Simple
file
system
§ Address
book
§ SMS
messages
§ Session
keys
Custom
Java
apps
§ Roaming
mgmt
§ Payment
§ Tracking
Java
virtual
machine
Smartcard
with
real-‐=me
opera=ng
system
5. SIM
have
many
security
layers
from
smartcards
to
cryptography
and
Java
process
separa=on
5
by
cryptographic
hash
func=on
(oVen
Comp128
in
GSM;
Milenage
in
3G/4G)
User
authen=ca=on
by
simple
comparison
Secure
Java
deployment
using
DES/3DES/AES
signature
+
encryp=on
SIM
authen=ca=on
Individual
protec=on
logic
for
banking
applets,
iden=fica=on
applets,
etc.
…
Java
crypto
API:
DES/3DES/AES;
some=mes
RSA
Applica=on
separa=on:
Java
VM
sand
boxing
SIM
card
includes
various
protec=on
mechanisms
Ki
PIN/PUK
numbers
OTA
keys
through
proprietary
smartcard
security
mechanisms
Storage
protec=on
6. OTA
security
level
is
chosen
by
server
while
SIM
enforces
mandatory
minimum
level
6
ILLUSTRATIVE
OTA
server
ini=ates
remote
transac=on
Binary
SMS
communica=on
Response
protected
according
to
request,
but
not
below
minimum
level
stored
on
card
SIM
card
stores
mul=ple
key
sets,
possibly
with
different
protec=on
levels
Key
set
1
Key
set
2
Key
set
3
Encry-‐
p=on
Signa-‐
ture
DES
3DES
AES
Man-‐
datory
ü
Command
–
possibly
encrypted
and/or
signed
Used
security
level
Reque-‐
sted
security
level
Target
app
/
key
set
#
7. OTA
error
handling
is
underspecified,
possibly
opening
a9ack
surface
7
A<acker
probes
cards
to
gain
material
for
DES
key
cracking
SIM
card
with
DES
key
(prevalence
of
DES
keys
varies
between
operators;
can
be
up
to
100%)
Binary
SMS
communica=on
Command
with
wrong
signature
Use:
DES
signature
Request:
DES
signature
Response
to
mal-‐signed
request
differs
by
card
type
c. (25%*)
b. (50%*)
a. (25%*
of
cards)
(No
response)
Error
message
DES
signature
Error
message
Some=mes
with
all-‐zeros
signatures
Data
useable
for
key
cracking
*
Es=mated
from
a
geographically
skewed
measurement
set
8. OTA
DES
do
not
withstand
key
cracking
8
Challenge:
Derive
56
bit
DES
key
from
OTA
response
signature
Cracking
strategies
Investment
Cracking
=me
Be
pa=ent
Brute
force
on
GPU
EUR
1.000
6
months
Throw
money
at
it
Brute
force
on
FPGA
cluster
EUR
50.000
1
day
Ride
the
rainbow
Time-‐memory
trade-‐off
using
large
hard
disks
&
GPU
EUR
1.500
+
1
year
pre-‐computa=on
1
minute
(but
<100%
success
rate)
Only
possible
when
OTA
response
is
fully
predictable
9. For
some
cards,
even
3DES
keys
are
crackable
9
Downgrade
a<ack
flow
Some
SIM
cards
with
3DES
key
use
lower
signature
schemes
when
requested
(in
viola=on
of
the
standard)
*
Must
be
brute-‐forced;
Rainbow
table
a9ack
no
longer
possible
A<acker
Command
Request
DES-‐signed
response
(KID
=
1)
Error
DES-‐signed
Command
Request
2-‐key
3DES
response
(KID
=
5)
Error
2-‐key
3DES-‐signed
Command
Request
3-‐key
3DES
response
(KID
=
9)
Error
3-‐key
3DES-‐signed
56
bit
56
bit
56
bit
Crack
first
third
of
key
Crack
second
third*
Crack
final
third*
3-‐key
3DES
2-‐key
3DES
DES
10. Java
virus
does
not
automa=cally
have
access
to
all
SIM
assets
10
Java
sand
box
should
protect
cri=cal
data
on
SIM
OTA-‐deployed
SIM
virus
can
access
SIM
Toolkit
API
Standard
STK
func=on
Abuse
poten=al
Send
SMS
§ Premium
SMS
fraud
Dial
phone
numbers,
send
DTMF
tones
§ Circumvent
caller-‐ID
checks
§ Mess
with
voice
mail
Send
USSD
numbers
§ Redirect
incoming
calls;
some=mes
also
SMS
§ Abuse
USSD-‐based
payment
schemes
Query
phone
loca=on
and
seUngs
§ Track
vic=m
Open
URL
in
phone
browser
§ Phishing
§ Malware
deployment
to
phone
§ Any
other
browser-‐based
a9ack
Data
access
on
SIM
would
enable
further
abuse
Protected
func=on
Read
Ki
Read
OTA
keys
Read
Java
processes
Write
to
Flash
or
EEPROM
Abuse
poten=al
§ SIM
cloning
§ Decrypt
all
2G/3G/4G
traffic
§ Lateral
a9acks
§ Clone
NFC
payment
takers
and
other
future
SIM
applica=ons
§ Alter
OS
to
prevent
vulnerability
patching
Read
hash
func=on
§ Reverse-‐engineer
proprietary
authen=ca=on
func=ons;
perhaps
find
weaknesses
Possible
on
some
SIMs
due
to
bug
in
their
Java
VM
11. SIM
security
research
mo=vated
some
technology
upgrades
11
Security
researchers
published
several
SIM
card
a<acks
Industry
reacted
swiVly
but
not
thoroughly
Finding
Anybody
can
send
management
SMS
to
SIM
cards
1
Many
networks
started
filtering
the
most
obvious
a9ack
messages
The
OTA
app
mgmt
interface
is
not
always
protected
with
good
crypto
2
Some
operators
phased
out
DES
keys
in
favor
of
3DES
SIM
applica=ons
can
break
out
of
their
JavaCard
sandbox
3
The
vulnerability
has
not
been
addressed
yet
in
affected
cards
Response
12. 12
1
Best
prac=ce
filters
Imple-‐
mented
filters
Several
message
types
may
go
to
the
SIM
Some
phones
also
forward
other
types
Many
networks
only
filter
one
type
Binary
SMS
can
take
many
forms
to
circumvent
filters
SMS
field
PID
DCS
UDHI
User
data
127
*
*
*
*
246
or
22
*
*
*
*
1
027000…
127
*
*
*
*
*
0
027000…
vs.
13. Misconfigura=ons
in
SIMs
go
well
beyond
DES
keys
13
ILLUSTRATIVE
2
2.
Verify
that
all
SIM
applica=ons
enforce
cryptography
1.
Verify
that
all
keys
are
3DES
or
AES
Applica=on
(TAR)
Keyset
1:
3DES
2:
3DES
…
16:
DES
Sign
+
encrypt
Sign
+
encrypt
Sign
000000
Unprotected
(MSL=0)
Sign
Sign
000001
FFFFFF
…
…
…
…
SIM
configura=ons
need
to
be
assessed
in
two
dimensions
14. A9ack
example–
Persistent
infec=on
of
modern
SIM
card
14
Target
—
New
nano-‐SIM
(October
2013)
in
iPhone
5s
from
major
European
carrier
A<ack
steps
A
B
D
C
Lure
the
phone
onto
fake
base
sta=on
to
circumvent
network
filters
Scan
the
SIM
remotely
for
configura=on
issues
(on
the
SIM
in
this
demo:
discover
TAR
with
MSL=0)
Install
Java
virus
through
vulnerable
TAR
Let
phone
connect
back
to
normal
network,
maintain
persistent
access
through
SMS-‐C&C
15. Self-‐assessment
tool:
Find
bugs
in
your
SIM
card’s
configura=on
15
§ Find
cryptographic
a9ack
surface:
– Signature
disclosure
– 3DES
downgrade
§ Enumerate
logical
a9ack
surface:
Detect
hidden
applica=on
TARs
and
test
their
security
level
§ Upload
traces
to
gsmmap.org
for
further
analysis
(Thank
you.)
Tool
name
Purpose
Requirements
Source
SIMtester
PC/SC
smartcard
reader
–or–
Osmocom
phone
opensource.srlabs.de
17. GSM
intercept
a9acks
are
s=ll
under
addressed
17
To
protect
customers,
mobile
networks
must
support
and
harden
two
encryp=on
standards
The
majority
of
mobile
phone
calls
worldwide
s=ll
uses
2G
GSM
frequencies
Older
phones
only
support
A5/1
encryp=on
Protec=on
status:
Available
strengthening
measures
are
rarely
seen
1
A5/3
protects
much
be9er
Protec=on
status:
S=ll
only
a
minority
of
networks
support
A5/3
2
19.
A5/3
makes
intercept
much
harder,
but
decryp=on
is
s=ll
possible
for
well-‐funded
spy
agencies
19
Speed
Success
Rate
Cost
A5/1.
One
computer
with
2TB
storage
decrypts
short
transac=ons
(SMS)
with
95%
success
in
1s
(aggregated)
A5/3.
400
computers
break
one
1-‐minute
call
per
minute
with
50%
success
Challenge:
A5/3
decryp=on
is
computa=onally
two
million
=mes
more
difficult
2
21. You
can
help:
Measuring
mobile
network
security
from
Android
or
Linux
21
Tool
name
GSMmap.apk
xgoldscanner
OsmocomBB
Purpose
Collect
network
traces
on
Android
phone
and
upload
for
analysis
to
gsmmap.org
Record
network
traces
for
analysis
in
Linux
Update
to
Sylvain’s
burst_ind
setup
to
capture
network
traces
for
analysis
in
Linux
Requirements
Rooted
Samsung
Galaxy
S2/S3
An
older
Motorola
phone
(C123,
…)
Samsung
Galaxy
S2,
S3,
Note
2,
or
Nexus
Source
opensource.srlabs.de
OsmocomBB
git:
gsmmap
branch
Google
Play:
GSMmap
22. Live
ISO
puts
mobile
security
tools
on
ready-‐to-‐use
USB
s=ck
22
GSM
map
live
ISO
bundles
mobile
security
tools
Network
measurement
with
Galaxy
S2/S3
Network
measurement
&
IMSI
catcher
detec=on
with
Osmocom
BB
phone
SIM
card
assessment
with
PC/SC
reader
or
Osmocom
BB
phone
Download
and
How-‐Tos
opensource.srlabs.de
24. Thank
you!
Ques=ons?
24
Karsten
Nohl
<nohl@srlabs.de>
Many
thanks
to
Lukas
Kuzmiak,
Luca
Mele<e,
and
Linus
Neumann
for
crea=ng
and
suppor=ng
our
research
tools!
Research
supported
by
