Architecture and security - Gauthier Van Damme (IBBT-COSIC- K.U.Leuven) & Kris Vanhecke( IBBT-WICA-UGent)
•Als PPT, PDF herunterladen•
1 gefällt mir•596 views
![Table of content ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Architecture and security - Gauthier Van Damme (IBBT-COSIC- K.U.Leuven) & Kris Vanhecke( IBBT-WICA-UGent)
Ähnlich wie Architecture and security - Gauthier Van Damme (IBBT-COSIC- K.U.Leuven) & Kris Vanhecke( IBBT-WICA-UGent) (20)
Mehr von imec.archive
Mehr von imec.archive (20)
Architecture and security - Gauthier Van Damme (IBBT-COSIC- K.U.Leuven) & Kris Vanhecke( IBBT-WICA-UGent)
- 1. Architecture and security Gauthier Van Damme, IBBT/COSIC, K.U.Leuven Kris Vanhecke, IBBT/WICA, UGent
- 4. The NFC Voucher System Registration TSM Handset Voucher Issuer 4 2 3 5 MIDlet/Applet Public Key Certificate 1 Phone Number Public Key/Certificate
- 5. The NFC Voucher System
- 13. Practical: user-side features Check Balance Review History Make Payment MMS Intercept Phone 2 Phone Configuration
- 16. 2. Making a payment at the cash desk MIDlet 1 2 3 Notification External Reader Detected ISO 14443 (APDUs) Check new balance JSR-257
- 17. 3. Transferring Vouchers to users MIDlet 2 3 4 Notification JSR-257 MIDlet JSR-257 Initialize transaction 1 Start protocol Execute protocol 4
Hinweis der Redaktion
- 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!