1. Composing Security Policies on Java Cards Michael McDougall with Rajeev Alur and Carl A. Gunter University of Pennsylvania April 26, 2004

2. HCES April 26, 2004 2 The Problem Predictable program behavior important, but difficult –Bugs are expensive or worse –Safety/Security critical applications Payment card application needs to combine policies Want to understand what will happen when these policies are integrated –Bugs, conflicts

3. HCES April 26, 2004 3 Current approaches Formal models: automata, logic –Not appropriate for this kind of policy integration –Too restricted or too general Formal methods: model checking, theorem proving, constraint solvers –Work best when tied to a succinct model –Want to exploit domain specific knowledge

4. HCES April 26, 2004 4 Our solution A new formal model: policy automata –Combines state machines with voting, using defeasible logic Polaris: a tool for creating, analyzing and compiling policy automata

5. HCES April 26, 2004 5 Open Embedded Systems Chips are getting cheaper, embedded into more and more devices Need to balance functionality with dependability OpEm: Open Embedded Systems –Flexible, more functionality –Safety- and security-critical Specific domain: access control

6. HCES April 26, 2004 6 Application: Programmable Payment Cards Smart Cards: –Size of a credit card –Contains CPU + memory Application: user-configurable payment cards Example: a card linked to a grant –Parent writes policy, gives to child –Hierarchy of stakeholders: Penn School of Engineering Computer Science

7. HCES April 26, 2004 7 Hierarchy of Policies Penn Engineering Professor Comp Sci Grad Student P1 P2 P3 P4 P1 P2 P3 P4

8. HCES April 26, 2004 8 Purchasing Policies Restrictive –Administrative: all merchants must be approved –Risk Reduction: No more than 5 purchases No purchases over $4000 No more than $300 a day –Safety: cannot buy conflicting prescription drugs Permissive –Must be able to pay for ambulance

9. HCES April 26, 2004 9 Modular Policies Often composed of sub-policies: –different stakeholders –policies evolve over time –different problems (or attacks) –easier to understand and modify Composing sub-policies can lead to conflicts or other unintended effects

10. HCES April 26, 2004 10 Our Proposed Approach Policy Automata –State machine + a non-monotonic voting system –State machine stores information, chooses vote –Votes are coalesced into Yes/No/Conflict

11. HCES April 26, 2004 11 Other Applications Purchasing and related systems –Food and drug interactions –Checking out equipment Network access –IP packet filters –HTTP request access control Access to restricted areas In general –wherever stateful policies are used for access control

12. HCES April 26, 2004 12 Formal Model State machine + Votes Policy Automaton Policy Automaton Policy Automaton request vote Resolution function Conflict or Yes/No

13. HCES April 26, 2004 13 Defeasible Logic as Votes Defeasible Logic: non-monotonic logic with efficient inference algorithm Special literal “yes” Votes –lists of rules Resolution function –yes not provable f= no (reject) –yes provable and : yes provable f= > (conflict) –yes provable f= yes (accept)

14. HCES April 26, 2004 14 Analysis Conflict freedom Policy redundancy Specification Safety properties

15. HCES April 26, 2004 15 Example Automaton: Purchasing “At most 2 purchases over $100” m1m2m3 yes & t.p>100 yes & t.p>100 if true then {} ) yes if true then {} ) yes if t.p >100 then {} ) : yes  R: M:

16. HCES April 26, 2004 16 Example Automaton: Drug Interaction Drugs interacting with tofranil m0 if (t.class ==MAOI) then {} ! : yes if (t.class==ALBUTEROL) then {} Ã : yes else {} ! tof

17. HCES April 26, 2004 17 platform Polaris Architecture Front end Analysis engine Code generator automata, properties results, counter- examples automata Java Card compiler (Oberthur) Java Card Java applets

18. HCES April 26, 2004 18 Java Card Runtime Architecture Manager Applet P1 P2 P3 Policy Applets trans. info votes update Card terminal

19. HCES April 26, 2004 19 Conclusion Model-based design A unique formal model –Domain-specific model –Stateful policy integration with conflict resolution –Combines state machines and defeasible logic Implementation of development framework –Adapt formal methods techniques to model Implementation of flexible payment card –Embedded defeasible logic engine

20. HCES April 26, 2004 20 The End