• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Architecture and security - Gauthier Van Damme (IBBT-COSIC- K.U.Leuven) & Kris Vanhecke( IBBT-WICA-UGent)
 

Architecture and security - Gauthier Van Damme (IBBT-COSIC- K.U.Leuven) & Kris Vanhecke( IBBT-WICA-UGent)

on

  • 614 views

 

Statistics

Views

Total Views
614
Views on SlideShare
598
Embed Views
16

Actions

Likes
0
Downloads
12
Comments
0

2 Embeds 16

http://events.ibbt.be 14
http://events.iminds.be 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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
  • Gauthier van damme van cosic , kuleuven en samen met wica van gent
  • Security issues van offline digitaal systeem geven: moeilijker dan online omdat geen direct controle  duidelijk uitleggen OS: niet OS zelf maar malware/virus op systeem SE: veilige hw
  • The voucher issuer that wants to add a user to the system, contacts the TSM and gives him the user phone number The TSM which is the only one that has has access to the SE uploads both the phone and the se application through OTA communication on the users phone Once installed, the SE applet will generate internally a secret key pair and output its public key to the TSM The TSM transfers the public key to the issuer, which creates a certificate on it. This is send back to the user which then can prove the authenticity of his public key to other users/terminals
  • Different actors, PKI for max security, Voucher lifecycle explained: from issuer and back: short  more in detail during different use cases Sleutel gebruik focus!!!!!!!!!! -  met publieke sleutel sessie sleutel aanmaken: in alle transacties zelfde systeem zeggen Zeggen handset 2 daarna gebruik te maken van ontvangen vouchers
  • After this short description of the system I’ll get a bit more technical, sorry for that As I said, there are two component active on the user phone First the midlet which is an applciation running on the OS will act as an interface to the user through the gui/keypad and will also route both encrypted vouchers received by mms or by transfer to or from the SE. The their is also this famous SE i’ve been talking about which is a java card and acts as a secure token and thus is the security backbone of the system. It will... See bullets
  • Here we briefly discuss a few aspects of OS especially relevant in the context of the NFC-Voucher demonstrator. MIDLET suite = applications And it also contains a push registry and some security which i’ll discuss in the following slides
  • The PushRegistry, based on a predetermined timer, or from an inbound network connection.
  • As I mentionned, the phone OS has some security feature So for example ... Sending an SMS requires explicit user confirmation But as you can see, these features are far from enough to protect a critical system like ours against malware or other type of attacks And this is why we came to using this SE for all critical data and voucher management
  • But the insecurity of the OS is not the only reason we use the SE. Although NFC has a small communication range, major security issues were shown to exist. This means that even if the OS could be trusted, the contactless communication used enables outsiders to attack the system as well. The attacker could for example ... See bullets And all these problems imply 3 major risks in our offline voucher scheme ... See bullets So the SE will not only be needed to have a secure environment for managing critical data, but will also be used to secure the contactless transactions
  • And securing the contacless transactions of course leads us to the use of strong cryptography! And for this we used the functionalities of the SE to the fullest. First as i already said, only a TSM can load applets on the SE and the user or OS has only limited (controlled) access to the SE Then we choose not to have any voucher leave the secure element unencrypted. This solves the problem of vouchers getting stolen or getting duplicated as no user will ever see any voucher unencrypted. Finally we choose to have every voucher to be signed digitally by the issuer to avoid vouchers being created. This is because only the issuer will be able to create a provably signature on the vouchers using his secret key. So this way, our theoretical system solved all the major issues from the previous slide. The only thing left was to implement the system.
  • And this is where, even though our architecture and thus the security offered did not change, we encountered some unfortunate limitations. The SE contained in the phones we use is .... The first problem we encountered is that our cryptografic primitives of choice were not available. For example we would have used ECC as public key scheme instead of RSA to reduce the key length for the same amount of security. This would have given us shorter vouchers as the signature on the vouchers is as long as the key length and thus less data would have to be transfered in every transaction. The second problem which is a major one concerning the speed of the system is the very slow memory access in the java card. This is why for example a private key siganture generation takes approximatly 300 ms to execute instead of the 30ms the hardware would theoretically be cappable of. A third issue which is related to the other is the limited amount of memory: As the vouchers are relatively long due to the long signature, only a limited amount of vouchers can be stored. But ok, these issues do not affect the system’s security but only the system’s speed. And this closes the more technical part of this presentation
  • I will now get in more detail on what the user can do inside this voucher system. This slides gives an overview of the different features that were developed. The three scenarios that we will look at in more detail are receiving new vouchers via MMS, making payments at the cash desk and transferring vouchers to other users. During the hands on demo you will be able to explore the other features of the prototype.
  • So here are the three use cases again You have the mms transfer from issuer to user (show on slide) You have NFC payments of vouchers at a cash desk ... And you have nfc voucher transfer to other users...
  • MMS blabla, was developped for sending sound/images but can also be used to send raw data. Depending on some value in the MMS, the phone OS will send the MMS not to the user inbox but will launch the voucher midlet that will then send the data to the SE. More specifically, the NFC voucher MMS contains the vouchers encrypted under the public key of the user For example, sending 20 vouchers will result in approximatly 3 kByte of data. And here i also want to emphase again that the major part of this data is used by the signature on the voucher, so here again a signature scheme with smaller signature would pay off.
  • Sleuteluitwisseling ook kort herhalen: sessiesleutel ifv van publieke afgesproken De verschillende fases goed uitleggen! (verschil volgende slide: 1 fase) At the payment desk, the user will touch the payment terminal. The internal security element then interacts with the external reader, exchanging public keys and setting up a session key. The user then removes his phone and The voucher application (MIDlet) is launched, asking the user to confirm the payment amount the MIDlet communicates with the secure element approving or not the requested voucher transaction and the user touches the terminal again to transfer the vouchers, encrypted under the session key and so finish the transaction. The Midlet can now inform the user that his balance has changed
  • Note that in ‘3’, the protocol is executed between the two secure elements, the MIDlet only acting as an APDU router Use ‘sender’ and ‘receiver’!!!!!!!!!!!!!!!!!!!!!!!! Same as previous: don’t forget to explain the session key and the encryption of the vouchers under this key
  • So to conclude, first of all we look at the security problems that were solved and those that were not. As I already explained, most of the problems were solved. Only one small problem which is not really depends on the security but more on the transaction protocol remains. As you can see in the previous slide, if during the transfer of the encrypted vouchers, the connection gets broken, then the vouchers can get lost in transaction. To prevent this we do not remove the vouchers from the sender’s phone untill an acknolagment from the receiver is send. Instead we mark the vouchers that are leaving the sender’s phone as ‘dirty’. With this system, when these vocuhers do arrive proparly, and thus the sendere receives the Acknoledgment, the vouchers can be removed, and if they do not (or if the ACK does not) arrive, then the vouchers are not completely lost and the user can claim his dirty vouchers back at the end of their expiration date, if no one else has consumed them (because in the case the vouchers arrive but the ack does not, vouchers get ‘duplicated’).
  • Finally, we think of this system as very promising. Compared to other fdigital payment systems it has major improvement. For example cheking your balance anytime anywere or transfer from usre to user. And this without having any known security risk. The only downside of the system is the Speed. This is due as explained to different factors: large vouchers, limitations of SE/Phones hardware. For example tranferring one voucher to another user needs approximatly 6 seconds while a payment takes 4 second. The difference between thes two figures lies in the fact that during a payment, one side of the protocol lies a much more performent payment terminal. But as you will see in the demo after this presentation, these timings are not so disatrous as they look, especially knowing that better hardware would solve most of this. Thank you!

Architecture and security - Gauthier Van Damme (IBBT-COSIC- K.U.Leuven) & Kris Vanhecke( IBBT-WICA-UGent) Architecture and security - Gauthier Van Damme (IBBT-COSIC- K.U.Leuven) & Kris Vanhecke( IBBT-WICA-UGent) Presentation Transcript

  • Architecture and security Gauthier Van Damme, IBBT/COSIC, K.U.Leuven Kris Vanhecke, IBBT/WICA, UGent
  • Table of content
    • System overview
      • Fundamental idea
      • The NFC Voucher system
    • Technical: user-side components
      • MIDlet running on NFC phone OS (S40)
      • Secure Element (SE) for secure voucher manipulation
    • Practical: user-side features
      • Voucher management
      • Voucher use cases
    • Conclusions
  • System overview: fundamentals
    • Offline system implies important security issues
    •  Focus on maximal security
    • Therefore: PKI to create circle of trust:
      • Issuer certifies users
      •  Users can be trusted and if necessary revoked
      • Efficient key management
      •  Breaking one link does not scale to the system
      • OS of mobile devices can’t be trusted
      •  Use trusted platform on phones: SE
  • The NFC Voucher System Registration TSM Handset Voucher Issuer 4 2 3 5 MIDlet/Applet Public Key Certificate 1 Phone Number Public Key/Certificate
  • The NFC Voucher System
  • Technical – User-side components
    • MIDLet, running in the S40 OS of the (Nokia) phone
      • GUI/Keypad
      • Receiving Vouchers through MMS (encrypted)
      • Communication proxy for Voucher transfer with SE’s
    • Java Card (2.2.1) applet, running in SE
    •  Security backbone of the system
      • Receive & store Vouchers
      • Voucher transfer and payment protocol
      • Stores all sensitive data and cryptographic keys
  • OS Features (Java based)
    • The MIDlet Suite
      • Java Archive (JAR)
      • Java Application Descriptor (JAD)
    • JSR-257 Contactless Communication API
      • Control the NFC interface
      • ISO-14443 communication with SE
    • Push Registry
    • Some Security
  • Push Registry
    • MIDlets can be launched automatically by the Application Management Software
      • Timer based
      • Inbound network connections
    • Static registration in JAD descriptors
    • Possible use cases
      • Timely warnings about expiring vouchers
      • Intercept incoming MMS messages that carry vouchers
  • Security aspects
    • Access to some APIs is restricted
      • Some require explicit user confirmation
      • Some actions can only be performed by trusted MIDlets
    • X.509 PKI public key digital certificates.
      • Verisign
      • Thawte
    • Only trusted MIDlets may connect to the internal Secure Element
  • SE: security backbone of the system
    • Security in offline payment systems is critical
    • NFC has limited range but security issues remain: (Haselsteiner & Breitfuss [RFIDSec2006])
      • Eavesdropping up to 10m from active devices
      • Data modification possible for some transfer rates
      • Denial-of-Service always possible
    • Risks for NFC Voucher scheme:
      • Re-routing of Vouchers in transit (stealing)
      • Loss of Vouchers
      • Counterfeiting or duplication
  • The Java Card applet on the SE
    • Strong cryptography is needed on top of the NFC
    • Maximum use of SE functionalities:
      • Controlled by the Trusted Service Manager (TSM)
        • Java Card applet will be deployed by TSM
        • Application in SE gets a PKI key pair on initialization
        • Limited applet access by OS/MIDlet
      • No Voucher leaves the SE unencrypted
      • Issuer Signed Vouchers: Vouchers have a digital signature
  • Limitations of the SE
    • Unfortunately the Java Card used is not perfect
    • ( NXP SmartMX with G&D's Sm@rtCafe Expert 3.1 OS)
    • Preferred cryptographic primitives are not available
      • RSA (1024 bit keys) used instead of ECC (160 bit keys)
      • 3DES used instead of more efficient AES
    • Memory issues limit the speed of every operation:
  • Practical: user-side features Check Balance Review History Make Payment MMS Intercept Phone 2 Phone Configuration
  • Use Cases in more detail
    • Receiving new Vouchers via MMS
    • Making a payment at the cash desk
    • Tranferring Vouchers to other users
  • 1. Receiving new vouchers via MMS
    • Multimedia Messaging Service
      • MMS Encapsulation Specification
      • Payload
        • Images, sound files
        • SMIL file to describe message layout
    • NFC-Voucher MMS
      • Payload is binary data: encrypted vouchers
      • 20 vouchers: 3 kB of binary data
      • MIDlet sends data to SE through APDU calls
  • 2. Making a payment at the cash desk MIDlet 1 2 3 Notification External Reader Detected ISO 14443 (APDUs) Check new balance JSR-257
  • 3. Transferring Vouchers to users MIDlet 2 3 4 Notification JSR-257 MIDlet JSR-257 Initialize transaction 1 Start protocol Execute protocol 4
  • Conclusions: Security issues solved/remaining
    • Solved:
      • Vouchers can not be created (signature)
      • Voucher can not be duplicated (they do not leave SE unencrypted)
      • Vouchers can not be stolen as users are identified
    • Remaining issues:
      • Vouchers can sometimes appear ‘lost in transaction’
  • Conclusions: usability
    • Promising technology
      • Improvement compared to other systems (e.g. Proton)
      • High enough security for Voucher payments
    • But needs speed improvements:
      • ~6sec for NFC Phone-to-Phone transfer
      • ~4sec for payments