Open APIs for Embedded
Security
Carl A. Gunter
OpEm Project
University of Pennsylvania
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.
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
Vertical Integration
Applications
Internal API
Hardware
Vendor 1
Vendor 2
Vendor 3
Toward Horizontal Integration
Applications
Open API
Hardware
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 is useful?)
Portability (will it work on all devices?)
Extensibility (can it grow?)
Predictability (are there bad interactions?)
Deliverability
Delivery Architectures
User
Removable
Media
Remote
Data
Embedded
Computer
Network
Link
Host Device
Network
Link
Remote
Control
Case Study: 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”
Penn OpEm 2002
Sample Recipe
1.
2.
3.
4.
5.
Make 1 inch slit in plastic
50% power for 5 minutes
Remove plastic overwrap
Rotate tray 1/2 turn
100% for 1:45
English language recipe taken from food package
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
Recipe as Java Program
Enhanced recipe
with extra
functionality


while (inMicro.getCookTime() < 300) {
try {
inMicro.cook(50, 300 - inMicro.getCookTime(), true);
} catch (PauseException pe) {
Handles cooling
Adapts to oven
capabilities
try {
inMicro.decrementCookTime(1);
} catch (StartException se) {
//loop again
}
}
}
Fragment of Java program
Java Program as Barcode
Xerox DataGlyph:
Aztec: 1.9KB
1KB per Sq inch
“I expect you can cook most things in one kilobyte.”
Roger Needham
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.
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
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.
How Payment Cards Work
Payment
Gateway
Issuer
Cardholder
Merchant
(Open Loop Systems)
Acquirer
Payment Cards on the Internet
Internet
Cardholder
Host
Merchant
Payment
Gateway
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
Secure Transaction Problem
Alice
Secure Channels
Bob
Claire
Place Order
Request Payment
Make Payment
Deliver Goods
Case Study: 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).
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?
Technologies for PPCs
 Smart cards
 Java Cards
 GlobalPlatform
 On-card verification of Java byte code
 SET on Java cards
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
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.
Java Card Features
 Supports:
 Packages, classes, interfaces, exceptions, inheritance,
dynamic object creation
 Booleans, bytes, shorts, 1D arrays
 Does not support:
 Dynamic class loading, multi-D arrays, object
serialization, threads, GC
 Longs, floats, characters, strings, multi-D arrays
 Java security manager
 Provides security using “applet firewalls”. Sharing
between applet packages uses Sharable Interface
Objects (SIOs).
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.
GlobalPlatform Architecture
GlobalPlatform
API
Provider Security
Domains
Provider
Application
Card
Manager
Provider
Application
Runtime Environment
Global Platform Process
1 Smart Card
Produced with
Security Domains
6 Certifier
Approves
Application
2 Smart Card
is Activated
7 Certifier
Supplies
Authentication
Data
3 Provider Writes
Application
8 Provider
Downloads
Application to
Card Through
CAD
4 Security Domain
Assigned to
Application Provider
9 Provider Installs
Application
5 Application
Provider Receives
Security Domain
Keys
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.
Transformations and Restrictions
 Technique developed by Xavier Leroy uses
transformations to ensure feasibility of on-card
verification
 Two assumptions about Java program


Operand stack is empty at all branch and branch target
instructions.
For each method evaluation, each register has only
one type.
 One assumption about Java runtime
 Initializes non-parameter registers on method entry to
a safe value.
Process for Safe Bytecode on Card
Java
Source
4 Assurance
Processor
1 Java Compiler
Verified
CAP File
Class File
CAP =
Converted APlet
2 CAP Converter
5 Applet Installer
Verified
Applet
CAP File
3 Assurance
Transformer
Off-Card Processing
Transformed
CAP File
6 Non-Defensive
VM
On-Card Processing
Leroy 2002
GlobalPlatform Process with On-Card
Verification
1 Smart Card
Produced with
Security Domains
6 Certifier
Approves
Application
2 Smart Card
is Activated
7 Certifier
Supplies
Authentication
Data
3 Provider Writes
Application
8 Provider
Downloads
Application to
Card Through
CAD
4 Security Domain
Assigned to
Application Provider
9 Provider Installs
Application
5 Application
Provider Receives
Security Domain
Keys
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.
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.
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
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
Example: SYN Filtering Firewalls
Their
Client
SYN
SYN
Our
Client
Our Firewall
Their
Server
SYN/ACK
Our
Server
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.
Card Programming Process
Card Issuer
Primary Provider
Card
Certification Server
Create card
with security
domain(s).
Secondary Provider
Host
User
Card Programming Process
Card Issuer
Primary Provider
Certification Server
Program transaction
applet, get card.
TApp
Card
Secondary Provider
Host
User
Card Programming Process
Card Issuer
Certification Server
Certify applet code, create
installation instructions.
Primary Provider
TApp
Card
Secondary Provider
Host
User
Card Programming Process
Card Issuer
Certification Server
Obtain certified CAP file and
authorized load and install
instructions.
Primary Provider
TApp
Card
Secondary Provider
Host
User
Card Programming Process
Card Issuer
Certification Server
Install TApp.
Primary Provider
Card
TApp
Secondary Provider
Host
User
Card Programming Process
Card Issuer
Primary Provider
Secondary Provider
Certification Server
Create, obtain certification for, and
install approval applet.
Card
TApp
AApp
Host
User
Card Programming Process
Card Issuer
Certification Server
Primary Provider
Secondary Provider
Obtain card and user-trusted
host code. Use card in usertrusted host.
Host
User
Card
TApp
AApp
Host
Code
PPC Installation Messages
Host
Card Manager
AApp
TApp
Load and Install CAP
Install
Select
Request AID Object
AID Object
Register
OK
OK
OK
Trust Relations
Merchant
Payment Gateway
Secondary Provider
Host
User
Card
TApp
AApp
Host
Code
Card Use Process
Merchant
Payment Gateway
Complete SET Transaction
Secondary Provider
Select Purchase Item
User
Host
Card
TApp
Obtain Approvals
AApp
Host
Code
PPC Purchase Messages
Host
TApp
AApp 1
AApp 2
OrderDesc, PurchAmt
OrderDesc, PurchAmt
Ok
OrderDesc, PurchAmt
Ok
PReq
PPC Prototype Implementation
 Doch on IBM JCOP with GlobalPlatform
extensions
 Refinement architecture implemented using
simple conjunction of filters
 Compete version for Oberthur cards
 Completing modifications in Doch to address
integrity concerns
 Developing an approach to getting timely offcard data
Future Work
 Investigate other platforms, viz. GSM.
 Extend the refinement architecture beyond
the conjunctive filter implementation and
create an analysis system (Polaris).
 General design methodology for smart cards:
Protocols and Implementation of Smart Card
Enabled Security (PISCES Project).
Policies using should / must
if price <= t
should approve; t=t-price
Parental Policy
if t=0
if price > t
should reject
if item not candy
should approve
should reject
Cash Card Policy
if merchant = hospital
must approve; uses++
if uses=5
Emergency Card Policy
Policy Analysis Framework
Firewall
Policy
Analysis
Java Card
Purchases
Policy
HTTP Request
Handling Policy
Policy Automata
Object
Method
Invariants
Nonmonotonic
Logic
Finite State
Automata
Code Generation
Firewall
Rules
JavaCard
Applets
Apache
Modules
Runtime
Checks
…
Policy Automata
 Finite state machines that vote on whether to
approve a transaction.
 Votes are rules in defeasible logic.
 Resolver function takes votes and determines
action: yes, no, or contradiction.
 Defeasible logic enables systematic and
semantically clear prioritization of policies
under composition.
 Model checking can determine possibility of
contradictions.
Polaris Architecture
automata,
properties
Front
end
Analysis
engine
Java Card
results,
counterexamples
automata
Code
generator
Java
Java Card
compiler
(Oberthur)
applets
OpEm Project
 Rajeev Alur, Carl A. Gunter, professors
 Alwyn Goodloe, Michael McDougall, Jason
Simas, PhD students
 Watee Arjsamat, staff
 Funded by NSF and ARO
 http://www.securitylab.cis.upenn.edu/opem
Professor Perspective
 “The smart card is the first time someone has
been able to create an API for the credit
card,” Alur said.
Graduate Student Perspective
 “I think we are advancing the state of the art”
by improving flexibility and security, said
Michael McDougall, a second-year [sic]
graduate student.
College Student Perspective
 “I guess it’s not a bad thing,” College junior
Mary Hoang said. “If parents are going to
give their kids money, they should have some
control over what [the kids] buy.”
Management Perspective
 “We’re always interested in exploring new
ways to be more efficient,” Senior Vice
President for Finance and Treasurer Craig
Carnaroli said when asked if Penn would
adopt the technology if it became
commercially available. “But we would need
to study it first.”
OpEm Project
http://www.securitylab.cis.upenn.edu/opem
The End
Cryptographic Notation
 H(a) – hash of a
 SA[H(a),H(b)] – signature of A on H(a)
concatenated with H(b)
 EC{c, H(b)} – encryption of c, H(b) for C
Method of Dual Signatures
Alice
Bob
b, H(c), D
Claire
D = SAlice[H(b), H(c)],
EClaire{c, H(b)}
H(b), D
SET Protocol
C
PInitReq
M
LIDM, ChallC
LIDM,XID,ChallC,ChallM
PReq
P
PInitRes
OIDualSign, PIDualSign
AuthReq LIDM,XID,H(OIData),HOD,PIDualSign
LIDM,XID, PurchAmt,authCode
AuthRes
LIDM,XID,ChallC,H(PurchAmt)
PRes
Bella, Massacci, Paulson, 2002
Dual Signature Data
 HOD = H(OrderDesc, PurchAmt)
b 
OIData = XID, ChallC, HOD, ChallM
Globally unique transaction identifier
 PIHead = LIDM, XID, HOD, PurchAmt, M,
c
H(XID, CardSecret)
 PIData = PIHead, PANData
 OIDualSign = OIData, H(PIData)
 PIDualSign = SC[H(PIData), H(OIData)],
EP{PIData, H(OIData)}