Rooting SIM cards by Karsten Nohl
Upcoming SlideShare
Loading in...5
×
 

Rooting SIM cards by Karsten Nohl

on

  • 1,556 views

Some DES-secured SIM cards allow for remote key cracking and applet installation; ...

Some DES-secured SIM cards allow for remote key cracking and applet installation;
Java vulnerabilities enable attacker to remotely extract Ki, banking applet data;
Mitigation options exist on network, baseband, and SIM card level.

Statistics

Views

Total Views
1,556
Slideshare-icon Views on SlideShare
1,556
Embed Views
0

Actions

Likes
1
Downloads
44
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Rooting SIM cards by Karsten Nohl Rooting SIM cards by Karsten Nohl Presentation Transcript

    • 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  file  system   Java  virtual  machine   §  Iden2fica2on  (IMSI)   §  Address  book   Custom  Java  apps     §  Authen2ca2on  (Ki  &   Hash  func2on)   §  SMS  messages   §  Roaming  mgmt   §  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   by  simple  comparison   PIN/PUK   numbers   SIM  authen'ca'on   by  cryptographic  hash  func2on   (oLen  Comp128  in  GSM;     Ki   Milenage  in  3G/4G)   B   Applica'on  separa'on:     Java  VM  sand  boxing   Individual  protec2on   logic  for  banking   applets,  iden2fica2on   applets,  etc.   …     A      Secure  Java  deployment   using  DES/3DES/AES   signature  +  encryp2on   Storage  protec'on   through  proprietary  smartcard   security  mechanisms   OTA   keys   Java  crypto  API:  DES/3DES/AES;   some2mes  RSA   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   enforces  mandatory  minimum  level   ILLUSTRATIVE   Binary  SMS  communica'on   OTA  server   ini2ates   remote   transac2on   Target  app  /  key  set  #   Command  –   Used   possibly   security   encrypted   level   and/or   signed   Reque-­‐ sted   security   level   SIM  card  stores  mul2ple     key  sets,  possibly  with     different  protec2on  levels   Key  set  3   Key  set  2   Key  set  1   Man-­‐   DES   3DES   AES   datory   Response  protected   according  to  request,   but  not  below  minimum   level  stored  on  card   Encry-­‐   p2on       Signa-­‐   ture   ü 5  
    • OTA  error  handling  is  underspecified,  possibly  opening  acack   surface   Binary  SMS  communica'on   AOacker   probes  cards   to  gain   material  for   DES  key   cracking     Command  with   wrong  signature   Use:  DES   signature   Request:  DES   signature   Response  to  mal-­‐signed  request  differs  by  card  type   a. (25%*     of  cards)   SIM  card     with  DES     key     (prevalence  of  DES   keys  varies  between   operators;  can  be  up   to  100%)   (No  response)   b. (50%*)   Error  message   Some2mes   with  all-­‐zeros   signatures   c. (25%*)   Error  message   DES   signature   Data  useable  for  key  cracking    *  Es2mated  from  rela2vely  small  and  geographically  skewed  measurement  set   6  
    • OTA  DES  do  not  withstand  key  cracking   Challenge:  Derive  56  bit  DES  key  from  OTA  response  signature   Cracking  strategies   Be  pa'ent   Brute  force  on  GPU   Throw  money  at  it   Brute  force  on  FPGA  cluster   Ride  the  rainbow   Time-­‐memory  trade-­‐off   using  large  hard  disks  &  GPU   Investment   Cracking  'me   EUR  1.000   6  months   EUR  50.000   1  day   EUR  1.500  +     1  year  pre-­‐computa2on   1  minute     (but  <100%  success  rate)   Only  possible  when  OTA   response  is  fully  predictable   7  
    • Acacker  SMS  asks  for  DES-­‐signed  SMS  response  with  fully   predictable  content   Acack-­‐specific  features   Command  packet   is  sent  by  the  acacker  to  provoke  response   UDHI   PID   DCS   UDH   CPL   CHL   SPI   KIc   KID   1   127   246   027000   Packet   Header   § No  ciphering   No   DES   length   length   § Sign   cipher   signature   § PoR  request   TAR   CNTR   App   01   PCNTR   CC   Data   Padding   Rand.   Generic   counter   invalid   command   Packet  details:   0   0   0   1   0   0   1   0   0   0   1   0   1   0   0   1   § No  ciphering   § Cryptographic   checksum   § Do  not  cipher  PoR   § Sign  PoR   § Send  PoR  in  any  case   Response  packet   may  offer  acack  surface   UDH   RPL   RHL   TAR   027100   Packet     Header   App   length   length   No   response   CNTR   01   PCNTR   Padding   counter   Status  Code   CC   Status  Code   Crypto-­‐ Checksum   Data   Response   –or  –   Signature  over  predictable  data  useable   for  rainbow  table  key  cracking   8  
    • Pre-­‐computa2on  tables  store  DES  code  book  in  condensed  form   E233   DB18   22CB   87A4   K   K   K   K   2F06   B951   A8F3   49A6   K   K   K   K   503A   CAF3   CAF3   118F   K   K   K   K   OCFE   77CF   77CF   Collision   B33F   The  uncondensed  code  book  is  petabytes  in  size.  Tables  provide  a   trade-­‐off:  Longer  chains  :=    less  storage,  but  also  longer  acack  2me   9  
    • Table  op2miza2on:  Rainbow  tables  mi2gate  the  effect  of  collisions   E233   DB18   22CB   87A4   K1   K1   K1   K1   44B2   ODE3   6C7A   11F6   K2   Collision   K2   K2   K2   BBA8   44B2   55D2   362E   K3   K3   K3   K3   1B22   5DE2   922A   C7D5   Rainbow  tables  have  no  mergers,  but  an  exponen2ally  higher  acack  2me   Source:c’t   10  
    • Video  and  live  demo:  Remotely  cracking  OTA  key   Video  source:  hcp://www.heise.de/security/ar2kel/DES-­‐Hack-­‐exponiert-­‐Millionen-­‐SIM-­‐Karten-­‐1920898.html     11  
    • 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  affected   Recent  operator  statements   We  use  encryp2on  instead  of  signa-­‐ tures;  the  acack  does  not  apply  here   We  don’t  even  use  OTA   We  only  use  3DES   Does  it  make  sense?   §  No.  Encryp2ng  a  known  plaintext  with  DES  is  as  bad   as  signing  it.  Even  when  both  are  required,  the   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   will  probably  find  that  you  never  cared  to  update   the  keys  of  this  virtual  waste  land)     §  Maybe.  3DES  is  good,  but  have  you  …   –  …  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  flow   AOacker   Crack  first   third  of  key   Command      Error   Command   Crack   second   third*      Error   Command   Crack     final   third*      Error    *  Must  be  brute-­‐forced;  Rainbow  table  acack  no  longer  possible   Request  DES-­‐signed   response  (KID  =  1)   DES-­‐signed   Request  2-­‐key  3DES   response    (KID  =  5)   2-­‐key  3DES-­‐signed   Request  3-­‐key  3DES   response    (KID  =  9)   Some  SIM     cards  with     3DES  key     use  lower  signature   schemes  when   requested  (in  viola2on   of  the  standard)   3-­‐key  3DES   2-­‐key  3DES   DES   56   bit   56   bit   56   bit   3-­‐key  3DES-­‐signed   13  
    • 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   response   0  Bytes   CC  content   8  Bytes   All  zero  or  other   fixed  pacern   Valid  signature   (random  pacern)   DES  crack   No   DES   downgrade   Vulnerable   No   No   to  this  acack   Not   No   No   No   Yes   Yes   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   OTA-­‐deployed  SIM  virus  can  access  SIM  Toolkit  API   Standard  STK   func'on   Send  SMS   Abuse  poten'al   §  Premium  SMS  fraud   §  Circumvent  caller-­‐ID  checks   Dial  phone   numbers,  send   §  Mess  with  voice  mail   DTMF  tones   Send  USSD   numbers   §  Redirect  incoming  calls;   some2mes  also  SMS   §  Abuse  USSD-­‐based  payment   schemes   Query  phone   loca'on  and   seDngs   §  Track  vic2m   Open  URL  in   phone   browser   Java  sand  box   should  protect   cri'cal  data  on   SIM   Data  access  on  SIM  would  enable  further  abuse   Protected   func'on   Read  Ki   Read  OTA   keys   Read  Java   processes   Abuse  poten'al   §  SIM  cloning   §  Decrypt  all  2G/3G/4G  traffic   §  Lateral  acacks   §  Clone  NFC  payment  takers   and  other  future  SIM   applica2ons   Write  to  Flash     §  Alter  OS  to  prevent   vulnerability  patching   or  EEPROM   §  Phishing   §  Malware  deployment  to  phone   §  Any  other  browser-­‐based  acack   16  
    • Java  VM  on  many  SIMs  fails  to  confine  malicious  applets   Java  VM   needs  to   Java  virus  may  try  to  intrude  on   Other  Java  programs  and  na've   enforce   other  parts  of  SIM   SIM  func'ons  store  value  secrets   sandbox     boundaries   Abuse  scenario   of  each  app   Data  in  SIM         §  SIM  cloning:   §  Ki     SMS/call   §  Banking   Simplis2c  memory  boundary   fraud,  …   Java  VM  enforces   applets   viola2on  acempt:   array  boundaries   §  Steal  balance   §  Iden2fica-­‐ X  =  small_array[1000000]   and  stops  request   2on  applets   §  Impersonate     X   More  complex  construct   to  violate  memory   boundaries     (responsible  disclosure   with  vendors  ongoing)   Java  VM  fails  to   detect  viola2on  &   processes  request   !   All  secret  informa2on  on  SIM  is   exposed  to  malicious  applets   through  vulnerabili2es  in  several   popular  Java  implementa2ons   17  
    • Putng  it  all  together  –  Remote  SIM  cloning   A   Ac'on   Result   Infiltrate  card  with  malicious   Java  applet   Send  binary  SMS   with  OTA   command  to   card,  reques2ng   card  response     Card  may   respond  with  a   DES-­‐  signed  error   message   Crack  DES   signing  key,  then   sign  Java  virus  &   send  through   binary  SMS     Card  installs  and   executes  signed   Java  applet   B   Exfiltrate  valuable  data   Leverage  gaps  in  Java  VM   memory  separa2on  to  access   arbitrary  SIM  card  data         Malicious  applet  extracts     Ki,  banking  applets,  etc.,  and   send  to  acacker  via  SMS   18  
    • Wide-­‐scale  SIM  hacking  risk  must  be  mi2gated  on  several  layers   Mi'ga'on  layer  for   OTA  hacking  risk   Low   Effec'veness   High   Cost   Filter  OTA  messages   from  unapproved   sources   Prevents  probing  in  home   network;  leaves  SIMs  exposed   when  roaming,  to  fake  base   sta2ons,  and  to  phone  malware   Func2onality   readily   available  in   most  SMSCs   Deac2vate  OTA  on   card   Prevents  acack  (but  also  any   future  use  of  OTA  w/  DES  key)   Can  be  done   through  SMS   Use  3DES  or  AES  OTA   keys   Prevents  acack  (expect  for   where  downgrade  acack   works)   Some  cards   need  replacing,     others  updates   Network   operators  mid-­‐ term  mi2ga2on   Some  cards   op2on   need  to  be   replaced   Use  cards  that  do  not   disclose  crypto  texts   Filter  suspicious   messages  on  phone   base  band   Prevents  the  acack   Prevents  the  acack   Network  operators   short-­‐term   mi2ga2on  op2on   New  soLware   Complimentary   mi2ga2on  op2on   func2on  for   for  phone   future  phones   manufacturers   19  
    • Industry  response  was  encouraging  for  responsibly  disclosing   hacking  research   The  responsible  disclosure  went     surprisingly  well  and  is  worth   men2oning   Take  aways  from  a  number  of  responsible  disclosure  that  all   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  don’t  be  surprised  if  even  the  most   §  Experts  from  a  few  large  companies   mo2vated  disclosure  partner  takes  months  to  distribute   verified  the  results  and  created  best   the  informa2on  confiden2ally  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  filtering   §  Help  your  technical  contacts  win  the  internal  bacles:   and  reconfiguring  cards   Refuse  to  speak  to  their  lawyers;  never  sign  an  NDA  prior   to  your  disclosure   §  Only  a  single  lawyer  stumbled  into   §  Be  extremely  careful  accep2ng  money;  and  only  ever  to   the  interac2on,  but  quickly  leL   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