security-by-contract for software evolution in smart-cards fabio massacci joint work with n....

Security-by-Contract for Software Evolution in Smart-Cards

Fabio MassacciJoint work with N. Dragoni, O.

Gadyaskaya, I. Siahaan

Fabio Massacci - Dagstuhl Seminar on Evolving Critical System

2

A Recollection of Memories• ESORICS 2000

– Presented my first paper in a security conference– Attended a talk by Pierre Bibier on model-checking multi-

application smart-cards

• Google Scholar on Multi-Application Smart Cards– First article in 1990– Patents dating back to 1996– Slate of articles and books in 1995-2005

• 20 years is a long time…


3

JavaCards = JRE + Global Platform• Global Platform = Middleware (with Open Specs)

– Lots of smart-card deployed with those specs

• GlobalPlatform specifications– support loading and un-loading of many applications on the

fly and asynchronously– JRE allows interactions among apps (unless firewall rules

are hacked into the card)

• Still/Yet/But… – there is no fielded multi-application smart card– one by Gemalto possibly to appear in 2010


4

The Applet Lifecycle


5

The Card Platform


6

Lots of Security Interactions You Want to Control

• Policy for security domains:– Transport cannot call Bank;– Ticketing only can be called after a call to Bank.

• Applications installed on the platform:– Application ePurse with services ID1, ID2 belongs to Transport;– Application JTicket with service ID3 belongs to Ticketing.

• New application m-Pay arrives on the platform. – m-Pay will only call shareable interfaces ID1, ID2, ID3– m-Pay will only allow call ID5 after calling ID3

• Advanced Desired Behaviore– m-Pay will only call shareable interfaces ID1, ID2, ID3, ID4 – Information flow only TO and FROM service ID1 at any point – Call Flow TO service ID2 only after service call FROM ID3


7

“The” Requirement of Smart Card• Platform as a whole must be CC certified for each

stakeholder– Pre-issuance when card is prepared, can use SWENG– Multi-apps by different stakeholders have asynch evolution– Cannot recall the 10K+ cards….– All later changes must show they meet the same policy

• Solution 1 – Theory –Design Time Adaptation– Certify the app for all evolution of itself AND its fellow apps

• Solution 2 – Another Theory – Rum-Time Adaptation– Run-time monitor new apps interaction with old apps

• Solution 3 – Practice– Don’t allow post-issuance evolution…


8

Out of the dilemma• When many say theory does not meet with practice,

what is really needed is more theory (I. Kant)• What we want

– Download new apps, delete old apps, update new apps– Apps are signed and come with their own “policy”– New apps should not interact with old apps (if that’s not

wanted) but should interact with old apps (If that’s wanted)

• Solution 4 – Certify Deployment Process– Security-by-Contract


9

Security-by-Contract• Stolen from Meyer’s Programming-by-Contract

and Model-Carrying-Code– Works for Mobile Systems!

• Apps come with a contract describing relevant security interactions– Security API + Shareable Interfaces– Needed calls to other security domains– Allowed calls by other security domains– Forbidden calls by other security domains


10

SxC possible workflow

04/21/23

Contract ExtractorContract Extractor

Policy Information

Point

Policy Information

Point

ComparerComparer

Application bytecode

Application bytecode

Application claim

Policy

Yes/No

Call graph or automaton

CompilerCompiler

Call graph or automaton

Policy

JAR

Policy works on Claim


11

Trade-Offs• Contract Extraction on SmartCard?

– Extracted from bytecode• only simple contracts and no TTP

– Attached with a signature• Allows complex contract and requires TTP• (but app needs signature from SD anyhow)

• Policy/Contract MatchMaking– Automatic on the Card

• Simple contracts and no TTP– Outsourced to TTP (and result signed)

• More complex contract but requires signature and connection (but the very download of app requires connection!)


12

Smart card Outside world

TrustedTrusted UntrustedUntrusted

New application,

C

New application,

C

time

time

Policy PPolicy P

Claim C,Policy PClaim C,Policy P

Do crypto

Do crypto

PkPkRun full

MatchMakingalgorithm

Run full MatchMaking

algorithmResultsResults

PkPk

Check cryptoCheck crypto

Results: verification result and hashes of claim and policy in case of success

Store*Store*

GP GP

*: what to save and where


13

Open Questions• On Mobile Phones worked

– Extraction for Rich Policies• Barthes et al. PCC on Java Cards

– MatchMaking with full SAT Solver modulo theories for rich policies (Only open url x if protocol(x)= “https”)

• Vanorberghe et al. ISTR 2008, Dragoni et al EuroPKI 2007 for .NET– Extraction + MatchMaking for very simple policies

• Ewan et al. CCS on Adroid

• On SmartCards?– Extraction and MatchMaking works on very simple policies

• Ghindici et al. CARDIS 2008– Richer policies must be tried…

security-by-contract for software evolution in smart-cards fabio massacci joint work with n....

Documents