Supporting Software Evolution for Open Smart Cards by - PowerPoint PPT Presentation

Supporting Software Evolution for Open Smart Cards by Security-by-Contract Olga Gadyatskaya* Joint work with F. Massacci*, N. Dragoni + , E. Lostal* *University of Trento (Italy) + Technical University of Denmark (Denmark) NODES Winter School, Turku, Finland 03.02.2012

A Marriage for Interest • M-payments, M- ticketing, M-facebook etc. etc • Wanna do lots sensitive things on the phone? – how ePurse talks to eTicket securely? • Use the smart card as the secure element! – Apps talks within the card securely 2 03/02/2012 Gadyatskaya et al. - NODES Winter School

M- Business wants more… • “EIS” – Evolution, Interaction and Security – E: Own updates are independent (over the air OTA) – I: Own applet can interact with business partner – S: Own security policy is respected • Any pair widely popular in the wild, it’s the combination that’s missing 3 03/02/2012 Gadyatskaya et al. - NODES Winter School

… but it was not here (yet) Most commercial cards locked before deployment: Security ?? Malaysian card security of interaction allows lot of applets certified off line but no interaction: firewall guarantee security Interaction Evolution 4 03/02/2012 Gadyatskaya et al. - NODES Winter School

The usual evocative picture Image from D1.1 of SecureChange project 5 03/02/2012 Gadyatskaya et al. - NODES Winter School

What Really Happens Once you are in you are in… . .java Firewall Instance Applet B Applet C Compiler Export Export file JCRE Export file Java Card API .class file C Installer & JCVM Loader Native API (Interpreter) Converter CAP file Calls to services are allowed if you know AID Native OS Export Integrated Circuit file checks bytecode well formed and signature from domains 6 03/02/2012 Gadyatskaya et al. - NODES Winter School

How does JC really works? • Applets interact through firewall using shareable interfaces – ePurse by DBank offers chargeCredit . – jTicket by DBahn invokes chargeCredit @ePurse • How access control is done – jTicket asks JCRE for reference to chargeCredit. – JCRE passes call to ePurse, – In chargeCredit ’s code ePurse checks caller AIDs in a list – ePurse returns a reference to chargeCredit service. • Technical Consequences – jTicket got a reference  can use service from now on – ePurse wants jTicket to stop using service  must update code – If ePurse doesn’t check  anybody knowing AID can use it • Business Consequence  No EIS, No OTA 7 03/02/2012 Gadyatskaya et al. - NODES Winter School

Design Targets • Same security of interacting smart cards with access control embedded in the code – Apps can arbitrarily restrict caller AID to services • Adding Business Flexibility of OTA uploads – Asynchronous & independent • On a challenging hardware platform – RAM footprint <1KB, ROM footprint <10KB • No changes to external loading protocols 8 03/02/2012 Gadyatskaya et al. - NODES Winter School

Security-by-Contract Scheme Policy Storage … Contract Contract App1 AppN Retrieve Update Policy Policy CAP Claim Checker Policy Checker Linking and Bytecode Contract Contract Installation Loading Yes Yes matches matches Contract Bytecode? Policy? Integrated No No with the JCRE Stop Free the memory 9 03/02/2012 Gadyatskaya et al. - NODES Winter School

Hierarchy of contract models Level 0 : application as 2 lists of services, the services it can provide and the services it intends to use. Level 1 : application as a call graph, where edges are the invocations of the services. Level 2 : application as a call graph, where states are marked as acceptable or error. Level 3 : application as a call graph with an information flow direction Gadyatskaya et al. - NODES Winter School 03/02/2012

The chosen model • Apps come equipped with a contract – Claims • I may provide these shareable interfaces with these services • I may call those methods from those interfaces – Security Rules • I can only be called by this Application/Package – Functional Rules • I need these methods from those interfaces • When new apps arrives platform will check – contract complies with bytecode – contract acceptable to other applets 11 03/02/2012 Gadyatskaya et al. - NODES Winter School

The “as -on-a-mobile ” Architecture Policy Java Firewall Checker Outside protocols Applet N Applet 1 Claim Checker JCRE Just ask results Java API Loader JVM Native API Operating System Hardware 12 03/02/2012 Gadyatskaya et al. - NODES Winter School

First Engineering problem • Implemented Policy Checker – POLICY’ 11 short paper – Footprint of checker 11KB and policy 2KB • BUT Require changing existing loading protocols! – Loading protocol standard plus check results of 1+2 – New protocol with policy checker – New protocol with claim checker • Loader can trust policy checker, but claim checker? – Needs signatures and certification – Too small improvement to justify new protocols 13 03/02/2012 Gadyatskaya et al. - NODES Winter School

Our Second Architecture Java Firewall Applet 1 Applet N JCRE Java API Loader Policy Do everything checker JVM Native API Claim checker Operating System Hardware 14 03/02/2012 Gadyatskaya et al. - NODES Winter School

What really is in a Contract? Contract of a package AppClaim AppPolicy Provided services Authorizations for services access <Interface token, method token> <Interface token, method token, Authorized package AID> Called services Functionally necessary services <Provider package AID, <Provider package AID, Interface token, method token> Interface token, method token> 15 03/02/2012 Gadyatskaya et al. - NODES Winter School

What ClaimChecker really do? • Claim Checker swipes raw data from loaded CAP file CAP file of jTicket applet Source code of jTicket applet component private void getCredit() { package_info[ 2 ] { … Import final AID Purse_AID = AID_length 6 JCSystem.lookupAID(PurseAID,(short)0, AID ( 1, 2, 3, 4, 5, 0 ) } (byte)PurseAID.length); Constant Pool if (Purse_AID == null) component constant_pool[ 18 ] { ... ISOException.throwIt(ISO7816.SW_CONDITIONS_ NOT_SATISFIED); External PackageToken: 2 , ClassToken: 0 ...} Called interface token CreditObject = (CreditInterface) (JCSystem.getAppletShareableInterfaceObject Bytecodes of getCredit() (Purse_AID, CreditDetails)); component … Points = CreditObject.charge(Points); getstatic_b 4 } Method Actual service invocation invokeinterface 2, 18, 0 putstatic_b 4 Called service <0,0> from Called method token return package AID 0x010203040500 16 03/02/2012 Gadyatskaya et al. - NODES Winter School

Second Engineering Problem • More Effective and Efficient – Checkers no longer trust external checks of code – Eliminate check of signature! – Both checkers can be implemented in C • But where do we put the policy? – We need to retrieve it and store it somewhere… – but loader is “ printed ” • We could have a “ static int policy[]’’ but that ’s not going to work in the ROM 17 03/02/2012 Gadyatskaya et al. - NODES Winter School

Our Third Architecture Java Firewall Policy Applet N Applet 1 Store JCRE Java API Loader Policy checker JVM Native API Claim checker Operating System Hardware 18 03/02/2012 Gadyatskaya et al. - NODES Winter School

Third Engineering Problem • How to deliver the contract to the checker? – Can’t change the protocol… • Both Checkers need Applet AIDs… – AIDs are “big”  don’t want to store the same AID multiple times – AIDs only known at OTA’s time  c an’t “ print ” them in Loader • A bit of help from the platform – AID are mapped into Package ID (much shorter) – But still you have rules for AIDs not yet on board 19 03/02/2012 Gadyatskaya et al. - NODES Winter School

Third Engineering Idea • Each Applet includes contract in CAP file customized component – No need to send it separately – Arrives with applet, can be discarded afterwards • Checkers do not need trust anyone – everything is supplied within one single CAP file • PolicyStore references applet contract with PID – Mapping table from PID to AID in Applet – Checkers only get short matrix with loaded PIDs 20 03/02/2012 Gadyatskaya et al. - NODES Winter School

Security Policy on the card So far we assume 10 loaded applets, 8 services each Policy on the card Small size and Policy (fixed size) MayCall (frequent) Possible future authorizations efficient All loaded contracts in an operations for applets not yet on the internal bit-arrays format card Big size and (rare) slow Mapping WishList Big size and operations Maintains correspondence Called services from applets (rare) slow between on-card IDs and not yet on the card operations AIDs 21 03/02/2012 Gadyatskaya et al. - NODES Winter School

It really works on a card • Developer ’s Version (run on PC simulator) – ClaimChecker  10KB – PolicyChecker+SxCInstaller  10KB – Policy Applet  6KB (in EEPROM) • JavaCard ’s version (on Gemalto ’s emulator) – ClaimChecker  1KB – PolicyChecker  0.9KB • To put numbers in perspective – JC Installer  6KB – JCRE (Loader+Linker)  20KB 22 03/02/2012 Gadyatskaya et al. - NODES Winter School