The UICC: Recent Work of ETSI TC Smart Card Platform


Published on

From 9th ETSI Security Workshop, Sophia Antipolis, France, 15‐16 January 2014

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The UICC: Recent Work of ETSI TC Smart Card Platform

  1. 1. Dr. Klaus Vedder Chairman ETSI TC SCP The UICC  Recent Work of ETSI TC Smart Card Platform 9th ETSI Security Workshop, Sophia Antipolis, France, 15‐16 January 2014 © ETSI 2014. All rights reserved
  2. 2. ETSI TC Smart Card Platform Home of the UICC The most widely deployed secure element   world wide The most widely deployed secure element ‐ world‐wide 26 Years of Dedication and Real‐life Experience TC SCP was founded in March 2000 as the successor of SMG9, the people who specified the SIM,  the most successful smart card application ever the most successful smart card application ever The Mission Create a series of specifications for a smart card platform, based on real‐life requirements, on  which other bodies from inside and outside the telecom‐world can base their system specific  applications to achieve compatibility between all applications resident on the smart car li i hi ibili b ll li i id h The Work ETSI TC SCP has published over fifty specifications on smart cards encompassing for every topic  the whole range from requirements via the technical solution to the test specification; topics  g q p ; p range from administrative commands to APIs, browsers, Internet connectivity, Machine‐to‐ Machine, new interfaces for high speed and the NFC chipset as well as remote management All can be downloaded free of charge from the ETSI website The specifications are application agnostic,  p pp g they are not restricted to the world of telecommunications They can be used as a (secure) platform for basically any smart card application 2
  3. 3. The Smart Card Market 8000 7595 7105 7000 6135 6000 5320 M M. units 5000 4185 4000 3446 2656 3000 2000 1000 1469 280 1889 1390 2004 2005 2040 880 750 510 2650 1480 1050 4520 410 336 1050 650 1200 3200 3400 2008 2009 4000 4700 5100 5350 0 2006 2007 Industry & Government Payment 2010 2011 2012 2013e Telecommunication Source: Eurosmart, SIMalliance
  4. 4. Some Numbers Roughly 33 billion smart cards for use in mobile communications have  been delivered to the market in the last ten years been delivered to the market in the last ten years This is about 3 times  to the moon and back  to the moon and back if put next to each other  in the ID‐1 format The numbers are still growing though at a slower rate Payment cards are gaining ground due to issuance of EMV cards in China  and North America dN hA i About 50% of the Telecom cards delivered over the last years are Java™  y cards 4
  5. 5. SIM Broken ? 1998: Comp 128‐1 (A3/A8) successfully attacked 1998 C 128 1 (A3/A8) f ll k d • black box attack against the GSM‐MoU example algorithm  • does not utilise any hardware or software property of the SIM • attack against just one card, not against the system itself k i j d i h i lf • chosen plaintext‐ciphertext attack  • approximately 160.000 ‐ 200.000 very specific challenges were then • required to calculate the secret, subscription specific key Ki required to calculate the secret subscription specific key Ki PIN has to be known or PIN‐check disabled authentication counter with "automatic silencing" of the SIM is no longer  a valid countermeasure  a valid countermeasure • only 3.000 to 36.000 challenges to calculate Ki needed now The answer is: NO The SIM has successfully stood the test of time 5
  6. 6. Bug or Bad Choice ? “… This talk ends this myth of unbreakable SIM cards …  and illustrates that the cards ‐ lik d ill t t th t th d like any other computing system  th ti t – are plagued by implementation and configuration bugs.“ Announcement of a presentation by  Karsten Nohl for the Black  Hat Conference in Las Vegas end of July 2013  ( ( bl kh ) Or, as found somewhere else: Or as found somewhere else: “Note, in most cases this is not a ‘bug’ causing the problem.   , g g p It is poor security choices being made by network operators.” 6
  7. 7. The Attack – Aim and Risks The aim is to break the OTA security of the SIM to be able to  download malicious applications to a Java SIM d l d li i li ti t J SIM A malicious application can, without the user realizing this, A malicious application can without the user realizing this • Trace the device and the user • Send SMSs to premium numbers • Divert incoming and outgoing calls • Silently include third parties on a call • Try to exploit a flawed implementation of the security framework of  y p p y the SIM OS and read the authentication key Ki and clone the SIM Note: after a successful attack remote file management (RFM) is also possible   Note: after a successful attack remote file management (RFM) is also possible
  8. 8. The Attack The attacker sends a rogue binary SMS to the target phone  number saying  here is an OTA application for you The number saying “here is an OTA application for you”. The  binary SMS includes a signature field, and the attacker doesn’t  know the OTA key at this point so the signature will be  incorrect. incorrect A UICC may then react in one of four ways: (a) it may reject the incoming message and not send a response; ‐ the recommended way by the 3GPP specification since 2012 (b) it may send an unsigned response saying “your signature was invalid”; (c) it may send what looks like a signed response saying “your signature was invalid”,  but with all‐zeroes in the signature field; (d) it may send a genuinely signed response saying “your signature was invalid” ‐ discarded in the relevant UICC specifications in late 2013. If the SIM answers according to (d) the attacker can calculate  If the SIM answers according to (d) the attacker can calculate the OTA message authentication key using rainbow tables
  9. 9. The Attack  ‐ Prerequisites The SIM uses Single DES for OTA security ‐ or has Triple DES configured as Single DES  h T i l DES fi d Si l DES • Single DES had been deprecated in the relevant ETSI specification in 2008 The SIM responds to a fake download request with a specific  eS espo ds to a a e do oad equest t a spec c MAC containing known data The network allows the forwarding of binary messages – now blocked in (probably most) networks bl k d i ( b bl ) k • The possession of the card or a (cheap) fake base station will however do Rainbow tables for the specific MAC are available which can be  Rainbow tables for the specific MAC are available which can be used to break the key within seconds The OTA implementation does not use a different key for the  enciphering of the OTA application or does not encipher it at all h f h l d h ll
  10. 10. The Extended Attack At 30C3 (30th Chaos Computer Congress) in December 2013,  Karsten Nohl et al. (SRLabs) presented a refined version of the  K t N hl t l (SRL b ) t d fi d i f th attack • A PC tool that systematically scans the SIM (connected via a card reader)  for vulnerable addresses of SIM applications (esp. applications for  remote management) and weak or even missing values for the security  level required for incoming messages • Find a TAR (Toolkit Application Reference) with an attached MSL (Minimum  • Security Level)  of “0” (i.e., no security required for downloading an  application) or with MSL=MAC and try to break the DES key of the MAC (if  DES is used) DES is used) A false base station will do the trick as well • The tool is available at They were able to exploit the attack and load a rogue applet  Th bl l i h k dl d l onto a 4FF SIM from an iPhone 5s 10
  11. 11. The Road to embedded UICCs 3FF Plug-in 4FF MFF2 The SIM card has evolved to meet market requirements • St Strongly driven by size requirements, and to meet portability regulations l di b i i t dt t t bilit l ti • Memory, security and interfaces to meet application requirements Move to the embedded UICC (specifically the soldered MFF2) • Ti Triggered by SIM requirements to address the M2M market such as limited  d b SIM i t t dd th M2M k t h li it d • accessibility, reliability Delivers benefits in size / space, reduced production cost in all types of devices An embedded UICC is a “UICC which is not easily accessible or replaceable, is  not intended to be removed or replaced in the terminal, and enables the  secure changing of subscriptions” (ETSI TS 103 383)
  12. 12. The Road Towards Subscription Management  Some M2M applications require new form factors such as MFF2  Provisioning of subscription over-the-air (after production, outside of factory) for M2M is needed y)  New ecosystem with dynamic subscription management (provisioning and changing of subscriptions and profiles) originates for M2M
  13. 13. The embedded UICC in 2013 TC SCP accepted the following new specification • ETSI TS 103 383: Smart Cards; Embedded UICC; Requirements Specification  f • “The present document enables remote management of an embedded UICC (eUICC) for purposes of changing an MNO subscription without requiring a  physical removal and replacement of the UICC in the end Device. The present document develops use cases and requirements for the "enhanced, remote management" of a UICC, which is  embedded in a communication device, i.e. where the UICC is not intended to be removed. This type of embedded UICC  (eUICC) is compatible with Machine to Machine (M2M) applications. The eUICC may be embedded at the manufacturing site  (eUICC) is compatible with Machine‐to‐Machine (M2M) applications. The eUICC may be embedded at the manufacturing site in advance, depending on the country and network operator, and is compatible for use in a variety of end‐user equipment. In  these scenarios there may be a requirement to remotely change a subscription easily, similar to what is currently achieved by physically changing the UICC. “ Work is continuing by members of all parties  having some  interest in the topic – device manufacturers, chipset manufacturers, SIM manufacturers and  mobile network operators , p , p SCP started the following new Work Item • Smart Cards; Embedded UICC; Physical, Logical, and Electrical  Characteristics •Definition of the architecture of the eUICC and its relation to the remote profile provisioning/management system;  13 definition of the physical, logical, and electrical characteristics of the eUICC‐Terminal interface according to TS 103 383  requirements; definition of the profile structure; definition of transmission protocols; identification of the eUICC and  profiles; definition of robust processes for creating containers, loading, installing, enabling, disabling, and deleting of  profiles; definition of a complete security mechanism covering authorisation, authentication, integrity and  profiles; definition of a complete security mechanism covering authorisation authentication integrity and confidentiality of profile management and operations, as well as procedures to protect against spoofing, replay attacks,  and profile cloning; definition of the credentials to perform the loading, installation, and management of profiles;  definition of the process to manage these credentials in the eUICC; definition of policy enforcement function •An evaluation of existing standardised mechanisms will be performed in order to assess possible re‐use and extension
  14. 14. Some Work Completed in 2013 Card Application Toolkit Security • Security for encapsulated Card Application Toolkit (CAT) Security for encapsulated Card Application Toolkit (CAT) • Definition of a mechanism that allows securing of encapsulated CAT  • commands and envelopes. The mechanism can be used on top of the AT  commands defined for CAT over the modem interface.  Security for CAT Security for CAT • Definition of a mechanism that allows securing of CAT commands and  envelopes. Existing security mechanisms from TS 102 484 are re‐used Requirements for environmental information to be stored in  Requirements for environmental information to be stored in the UICC Specification of a mechanism that allows the SIM to use the  p network based configuration mechanism for DNS servers. This  allows better integration of IP SIM based services into the  Operator's infrastructure 14
  15. 15. Some Other Work in 2013 Work continued on P2P mode for contactless communications Enhancement of test specifications • TC SCP is the only standardisation committee providing test  specifications for (nearly) all  its Technical Specifications Test environment integrity, test case execution • Development of a technical report (TR) that defines how to optimally set  up the test environment to execute test case implementations based on  up the test environment to execute test case implementations based on ETSI TC SCP test specifications UICC Access Optimisations • A l i fi Analysis of issues related to the reduction of the time for the terminal to  l d h d i f h i f h i l access the content on the UICC in order to provide a better user  experience Joint work with GlobalPlatform and the NFC Forum on the  Joint work with GlobalPlatform and the NFC Forum on the routing of applications in case of multiple Secure Elements 15
  16. 16. Some New Work Items UICC Access Optimisation • A l i fi Analysis of issues related to the reduction of the time for the terminal to access  l t d t th d ti f th ti f th t i lt • the content on the UICC in order to provide a better user experience Background: The UICC is a platform that was designed for multiple application  support. While this platform was often used for a single application in the past, it  support. While this platform was often used for a single application in the past, it is more and more frequent that multiple applications reside on the UICC (e.g.  USIM + ISIM + CSIM). The current work in other Technical Committees and  organizations may create even further applications to be hosted on the UICC,  such as the M2M Service Module  h h M2M S i M d l Use cases and requirements related to the addition of new  contactless features • New usages of the UICC in contactless environment shall be taken into account  by the ETSI specifications. For instance, several types of secure elements may use  the HCI as an interface. In order to increase interoperability and avoid  proprietary implementations, there is a need to standardise interaction between  proprietary implementations there is a need to standardise interaction between the UICC and these secure elements through HCI  16
  17. 17. The Future: A Smart and Secure Platform The scope TC SCP is too narrow to really satisfy today’s  industry requirements  i d t i t • The interface of the UICC to the outside world need to take the respective  • • ecosystems into account as shown by the discussion on the embedded UICC There are other Secure Elements than the UICC in (mobile) devices There are other Secure Elements than the UICC in (mobile) devices There is a need  for harmonization  across industry sectors  to gain scale effects to  achieve a single platform for the various applications What we aim for: delivery of a smart and secure platform What we aim for: delivery of a smart and secure platform • A generic platform for securely managing identities, authentication and  • • • 17 authorization, based on the consolidated requirements of multiple industries Not only a smart and secure element but also the necessary entities in the  surrounding system (for e.g. issuance, activation, remote application  management) Common understanding of the security requirements and security levels used by  each party each party Best in class interoperability
  18. 18. Shaping the Future of Smart Security Together An ETSI framework where all sectors can express/develop  their requirements with a level playing field for all their requirements with a level playing field for all Mobile Telecoms Banking and  Financial  Services Government &  Identity Id tit Key Players Key Players Key Players Key Players Key Players Use Cases Use Cases Use Cases Use Cases Use Cases Requirements Set #1 Requirements Set #2 Requirements Set #3 Requirements Set #4 Requirements Set #5 Aggregation of: Transportation  Machine‐Type  and Access  Communications  Control (M2M) Sectors Requirements Generic Needs Common decision regarding the setup of future activities Work on technical specifications and compliance aspects 18
  19. 19. Dr. Dr Klaus Vedder Group Senior Vice President Giesecke & Devrient GmbH Prinzregentenstr. 159 81607 Munich Germany Next SCP Plenary Meeting 12-14 February at ETSI see:
  20. 20. TC SCP Working Structure SCP • Final acceptance of Work Items to be progressed by Working Groups Final acceptance of Work Items to be progressed by Working Groups • Acceptance for publication of all Technical Specifications and Technical Reports  • as well as Change Requests to published documents Input to its work is received from ETSI members such as TC M2M as well as  3GPP, 3GPP2, GlobalPlatform, GSM Association, Global Certification Forum  f f (GCF), NFC Forum, OMA,  … SCP REQ Q • Working Group SCP REQ is responsible for developing the requirements for the  Smart Card Platform SCP TEC • Working Group SCP TEC is responsible for the technical realisation of the  requirements developed by SCP REQ and accepted by SCP SCP TEST • W ki G Working Group SCP TEST is responsible for the development of test  SCP TEST i ibl f th d l t ft t specifications for deliverables produced by SCP TEC and accepted by SCP 20
  21. 21. Structure and Officials SCP Plenary y Chair: Klaus Vedder, G&D Vice Chair: Heiko Kruse, Morpho Vice Chair: Denis Praca, Gemalto SCP Requirement WG SCP Technical WG Chair: Davide Pratone, Telecom Italia Chair: Paul Jolivet, LG Vice Chair: Heiko Kruse, Morpho Vice Chair: Denis Praca, Gemalto Vice Chair: Sebastian Hans, Oracle SCP Testing WG Chair: Andreas Bertling, Comprion Vice Chair: Christophe Dubois, Gemalto