563.5 Tamper-Resistant Software Architectures

1. 563.5 Tamper-Resistant Software Architectures Presented by: Carl A. Gunter University of Illinois Spring 2006

2. Tamper-Resistant Software • It is common for software vendors to place their software into the hands of not-fully-trusted parties. • Such vendors seek to limit the ways in which this software can be used while maintaining valuable flexibility. • Case study: OpEm Project at Penn.

3. Embedded Computers • Embedded computer systems are ones installed in host devices such as: • Appliances • Cell phones • Medical devices • Vehicles • They typically have one or more constraints on: • Form (viz. size, shape, and weight) • Power • Location (mobility) • This results in limits on memory, computation, and connectivity.

4. Open APIs • Servers and desktop computers typically offer the ability to add software from independent vendors through an open Application Programming Interface (API). • Some small mobile devices offer this as well: • Typical for PDAs • Coming for cell phones • Devices with open APIs have advantages: • Greater flexibility • Independent vendor support

5. Vertical Integration Applications Internal API Hardware Vendor 1 Vendor 2 Vendor 3

6. Toward Horizontal Integration Applications Open API Hardware

7. Open APIs for Embedded Computers • Most embedded computers do not offer open APIs. • Such devices often have significant constraints on safety (vehicles) and/or security (key tokens). • Issues relate to • Flexibility (how much customization is useful?) • Portability (will it work on all devices?) • Extensibility (can it add new functions?) • Predictability (are there bad interactions?) • Deliverability (how is software updated?)

8. Delivery Architectures

9. Programmable Microwave Ovens • Microwave ovens are very widely used and they are crudely programmable: • Hardware: microwave oven vendors • Software: frozen food manufacturers • There are key programming limitations. • User bottleneck • Standardization • Complexity (e.g. multi-modal ovens) • “Network dependencies” Goodloe McDougall Gunter Alur 02

10. Sample Recipe 1. Make 1 inch slit in plastic 2. 50% power for 5 minutes 3. Remove plastic overwrap 4. Rotate tray 1/2 turn 5. 100% for 1:45 English language recipe taken from food package

11. M/W Architectural Options • Access recipe over the Internet (Sharp) • Put the program on the package as a linear barcode (TrueCook+, compare VCR+) • Use a linear barcode to index a recipe in a DB • Use a Java program encoded in an “active” 2D barcode (OpEm) Kit Yam, 1999

12. Recipe as Java Program Enhanced recipe with extra functionality • Handles cooling • Adapts to oven capabilities while (inMicro.getCookTime() < 300) { try { inMicro.cook(50, 300 - inMicro.getCookTime(), true); } catch (PauseException pe) { try { inMicro.decrementCookTime(1); } catch (StartException se) { //loop again } } } Fragment of Java program

13. Xerox DataGlyph: 1KB per Sq inch Aztec: 1.9KB Java Program as Barcode “I expect you can cook most things in one kilobyte.” Roger Needham

14. Active Barcode Recipes: Lessons • Delivery mechanism is a primary constraint. • Compression works even on small programs. • Small programs offer a better opportunity for analysis. • Existing formal approaches do not match the problem exactly: would like to do more analysis for a simpler problem. • Example: show, statically, that a given recipe uses no more than n minutes of power and no less than m minutes.

15. Advantages of Remote Control • Embedded computers have many constraints. • Why not shift intelligence to capable computers and control devices over a network? • Example: smart cards vs. magnetic stripes. • Vending machines • Coffee shops

16. Payment Cards • Payment cards are a ubiquitous means for making purchases. There are several kinds: • Credit cards • Charge cards • Debit cards • They are issued by parties such as banks and stores. • Approvals and payments are managed by card networks such as Visa, MasterCard, and American Express.

17. How Payment Cards Work (Open Loop Systems)

18. Payment Cards on the Internet

19. Fraud • Fraud is a major problem for Internet-based payment card transactions. • The Secure Electronic Transactions (SET) protocol was designed by MasterCard and Visa in 1996 to address this. Now controlled by SETCo. • Efforts were made to protect SET secrets from untrusted hosts by using a smart card • Chip Electronic Commerce (CEC) Spec, EMV • Chip SET (C-Set), Cybercard • vWALLET, e-COMM pilot, Gemplus, Visa International, France Telecom, BNP, Societe Generale, Credit Lyonnais • Doch, SET for the JavaCard (more later), M Lyubich • Other fraud prevention mechanisms: Verified by Visa

20. Alice Claire Secure Transaction Problem Secure Channels Bob Place Order Request Payment Make Payment Deliver Goods

21. Programmable Payment Cards (PPCs) • Cards are commonly issued by banks to enterprises for use by enterprise employees. (“Corporate Cards”.) • The bank/payment gateway enforce limited policies such as payment limits. • Enterprises often want customized policies that banks do not wish to enforce. • Can such policies be enforced by placing them as programs on the payment cards? • Related work: card and financial management integration (eg. AMS). Gunter 03

22. Applications and Challenges for PPCs • Applications • Families • GSM phones • Raises many questions about architectures for embedded control. • Can the card programming be made extensible? • Which code goes where? • Does the card have enough computing capacity to enforce policy? • Does the card have enough information to enforce policy? • Is there a feasible trust model?

23. Technologies for PPCs • Smart cards • Java Cards • GlobalPlatform • On-card verification of Java byte code • SET on Java cards

24. Smart Cards • Smart cards (integrated circuit cards) were invented in late 1960’s. • Widely used for personal identification, payment, communication, physical access. • Microprocessor contact cards communicate and receive power through a Card Acceptance Device (CAD) attached to a host. • Three kinds of memory • Read Only Memory (ROM), ~64KB • Electrical Erasable Programmable Read-Only Memory (EEPROM), ~16-64KB • Random Access Memory (RAM), ~1-2KB

25. Java Cards • API for using Java to program smart cards was introduced by Slumberger, Austin TX in 1996. • Standard supported now by Sun • JavaCard API • Java Card Runtime Environment (JCRE) • Java Card Virtual Machine (JCVM) • Implemented by many card vendors. • Other programmable cards: MultOS, Smart Card for Windows.

26. GlobalPlatform • Difficult to verify byte code on cards. • Multi-application cards may integrate applications that do not trust each other. • Open Platform was introduced by Visa in 1990 to provide a foundation for secure multi-application cards. • GlobalPlatform industry consortium now maintains the standard. • This is coming to be implemented by several card vendors, especially for the Java Card. • This will provide an open API for smart cards.

27. GlobalPlatform Architecture

28. Global Platform Process

29. Byte Code Verification on Java Cards • Sun Java byte code verifier takes uses too much memory to run on a smart card. • Defensive virtual machine that checks types dynamically is expensive. • Can perhaps use “verification evidence” to ease card verification burden. • Technique used in Sun CLDC for mobiles: • Pre-verifier produces type maps. • These are used to aid verification on the mobile device.

30. Process for Safe Bytecode on Card CAP = Converted APlet Leroy 2002

31. With On-Card Verification

32. Payment Protocols for Java Cards • SET is a complex protocol. Implementing it on Java Cards is a challenge. • Work of Mykhailo Lyubich shows how to do this for protection of confidentiality of keys and card secrets. • Target property: after a card is removed from a corrupted terminal, the terminal cannot perform further unauthorized transactions. • This also “protects” the card from its user.

33. Challenges for SET on Java Cards • Checking certificates is a challenge. • Certificate chains are large and can be of variable size. • Certificates have expiration dates, but cards may not have clocks. • Sample problem • PReq message includes information for P such as the PANData encrypted under the key of P • If the terminal is trusted to check the certificate of P it could substitute its own key for this encryption. • Possible to address certificate and time problems and determine operations that must be on card based on multi-level security model. • Doch prototype software implements SET with confidentiality protection.

34. PPC Design and Implementation • Many of the necessary technologies are in place • Smart cards (IBM JCOP21id, Oberthur CosmopolIC 2.1v4, 32KB) • Java Card 2.1.1 • GlobalPlatform 2.0.1 • Doch implements SET on the Java Card for confidentiality • Need to design and implement • SET for authorization on the GlobalPlatform • An architecture for policies and their integration • Someday: on-card verification

35. Refinement Architecture • Refinement is a well-understood central concept in formal modeling of computer systems. • Specify a family of sensitive events • Show that an implementation limits the collection of sensitive events • Non-sensitive events may be added • Filtering is a simple way to ensure refinement • Example: packet network filtering firewall

36. Conjunctive Filter Model • We implement PPCs as a conjunction of PReq filters. • The filters are written in the Java Card language and implement predicates over OrderDesc, PurchAmt. • The extensible framework is installed by the primary provider. • Policies may be installed by one or more secondary providers. • Users may select their own hosts and host software.

37. Card Programming Process Card Issuer Card Certification Server Primary Provider Create card with security domain(s). Secondary Provider Host User

38. Card Card Programming Process Card Issuer Certification Server Program transaction applet, get card. Primary Provider TApp Secondary Provider Host User

39. Card Card Programming Process Card Issuer Certification Server Certify applet code, create installation instructions. TApp Primary Provider Secondary Provider Host User

40. Card Card Programming Process Card Issuer Certification Server Obtain certified CAP file and authorized load and install instructions. Primary Provider TApp Secondary Provider Host User

41. Card Card Programming Process Card Issuer Certification Server Install TApp. Primary Provider TApp Secondary Provider Host User

42. Card Card Programming Process Card Issuer Certification Server Create, obtain certification for, and install approval applet. Primary Provider Secondary Provider TApp AApp Host User

43. Card TApp AApp Card Programming Process Card Issuer Certification Server Primary Provider Obtain card and user-trusted host code. Use card in user-trusted host. Secondary Provider Host Host Code User

44. PPC Installation Messages Host Card Manager AApp TApp Load and Install CAP Install Select Request AID Object AID Object Register OK OK OK

45. Card TApp AApp Trust Relations Merchant Payment Gateway Secondary Provider Host Host Code User

46. Card TApp AApp Card Use Process Merchant Payment Gateway Complete SET Transaction Secondary Provider Select Purchase Item Host Host Code User Obtain Approvals

47. PPC Purchase Messages Host TApp AApp 1 AApp 2 OrderDesc, PurchAmt OrderDesc, PurchAmt Ok OrderDesc, PurchAmt Ok PReq

48. PPC Prototype Implementation • Doch on IBM JCOP with GlobalPlatform extensions • Refinement architecture implemented using simple conjunction of filters • Compete version for Oberthur cards • Needed: an approach to getting timely off-card data

49. Current and Future Work • Policies for GSM • Policy integration: Polaris • Code splitting: Protocols and Implementation of Smart Card Enabled Security (PISCES)

50. Policies for GSM • Program the SIM in a cell phone so that it restricts calls • Limit calls that might exceed base service charges. • Nanny can only call the parents. • Architecture in current protocols trusts the Mobile Environment (ME). • Design a protocol to take the ME out of the trusted base. Weiner Gunter 04