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

Gadyatskaya et al. - NODES Winter School

2

03/02/2012

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

Gadyatskaya et al. - NODES Winter School

3

03/02/2012

… but it was not here (yet)

Gadyatskaya et al. - NODES Winter School

4

Malaysian card allows lot of applets but no interaction: firewall guarantee security

Evolution Interaction Security

Most commercial cards locked before deployment: security of interaction certified off line ??

03/02/2012

The usual evocative picture

Image from D1.1 of SecureChange project

5

Gadyatskaya et al. - NODES Winter School 03/02/2012

What Really Happens

Gadyatskaya et al. - NODES Winter School

Integrated Circuit Native OS

Installer & Loader

JCRE

JCVM

(Interpreter) Native API Java Card API

CAP file

Applet C Applet B

Firewall

.java .class Compiler Converter

Instance

Export file

6

checks bytecode well formed and signature from domains Calls to services are allowed if you know AID Once you are in you are in….

Export file Export file Export file C 03/02/2012

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

Gadyatskaya et al. - NODES Winter School

7

03/02/2012

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

Gadyatskaya et al. - NODES Winter School

8

03/02/2012

Security-by-Contract Scheme

Gadyatskaya et al. - NODES Winter School

9

Contract CAP Bytecode Contract matches Bytecode?

Loading

Claim Checker

Yes

Policy Checker Contract matches Policy?

Yes No No Linking and Installation

Stop

Free the memory Retrieve Policy Policy Storage

Contract App1 Contract AppN

…

Update Policy

Integrated with the JCRE

03/02/2012

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

Hierarchy of contract models

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

Gadyatskaya et al. - NODES Winter School

11

03/02/2012

The “as-on-a-mobile” Architecture

Gadyatskaya et al. - NODES Winter School

12 Hardware Operating System Java API Native API JVM Loader JCRE Applet N Applet 1 Policy Checker Claim Checker

Java Firewall

Just ask results Outside protocols

03/02/2012

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

Gadyatskaya et al. - NODES Winter School

13

03/02/2012

Loader

Our Second Architecture

JCRE

Gadyatskaya et al. - NODES Winter School

14 Hardware Operating System Java API Native API JVM Applet N Applet 1

Java Firewall

Do everything

Claim checker Policy checker

03/02/2012

What really is in a Contract?

Gadyatskaya et al. - NODES Winter School

Contract of a package AppClaim AppPolicy Provided services Called services Authorizations for services access Functionally necessary services

<Interface token, method token> <Provider package AID, Interface token, method token> <Interface token, method token, Authorized package AID> <Provider package AID, Interface token, method token>

15

03/02/2012

What ClaimChecker really do?

• Claim Checker swipes raw data from loaded

CAP file

16

Source code of jTicket applet CAP file of jTicket applet

… getstatic_b 4 invokeinterface 2, 18, 0 putstatic_b 4 return

constant_pool[18] { ... External PackageToken: 2, ClassToken: 0 ...} Constant Pool component

Method component

package_info[2] { … AID_length 6 AID (1, 2, 3, 4, 5, 0) }

Import component

private void getCredit() { final AID Purse_AID = JCSystem.lookupAID(PurseAID,(short)0, (byte)PurseAID.length); if (Purse_AID == null) ISOException.throwIt(ISO7816.SW_CONDITIONS_ NOT_SATISFIED); CreditObject = (CreditInterface) (JCSystem.getAppletShareableInterfaceObject (Purse_AID, CreditDetails)); Points = CreditObject.charge(Points); }

Called service <0,0> from package AID 0x010203040500

Called method token Called interface token

Actual service invocation Bytecodes of getCredit()

Gadyatskaya et al. - NODES Winter School 03/02/2012

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

Gadyatskaya et al. - NODES Winter School

17

03/02/2012

Loader

Our Third Architecture

JCRE

Gadyatskaya et al. - NODES Winter School

18 Hardware Operating System Java API Native API JVM Applet N Policy Store

Java Firewall

Claim checker Policy checker Applet 1

03/02/2012

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  can’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

Gadyatskaya et al. - NODES Winter School

19

03/02/2012

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

Gadyatskaya et al. - NODES Winter School

20

03/02/2012

Security Policy on the card

Gadyatskaya et al. - NODES Winter School

Policy (fixed size) All loaded contracts in an internal bit-arrays format

Policy on the card

Mapping Maintains correspondence between on-card IDs and AIDs WishList MayCall Possible future authorizations for applets not yet on the card Called services from applets not yet on the card So far we assume 10 loaded applets, 8 services each

Small size and (frequent) efficient

• perations

Big size and (rare) slow

• perations

Big size and (rare) slow

• perations

21

03/02/2012

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

Gadyatskaya et al. - NODES Winter School

22

03/02/2012

The real challenges ahead

• Solve conflicts among contracts

– So far we just reject latest update – Maybe different priority among applets?

• Include Policies on Usage of Libraries

– Libraries are services but a lot (compared to applets)

• Java Card 3.0

– not yet accepted by industry, so no access to the JCRE

Gadyatskaya et al. - NODES Winter School

23

03/02/2012

Send us your applets …

• lga.gadyatskaya@unitn.it

more info at www.disi.unitn.it/~gadyatskaya/sxc.html