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

Applications

Internal API

Hardware

Vendor 1 Vendor 2 Vendor 3

Vertical Integration

Hardware

Applications

Toward Horizontal Integration

Open API

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

UserRemovable

Media

NetworkLink

EmbeddedComputer

Host Device RemoteControl

RemoteData

NetworkLink

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. Make 1 inch slit in plastic2. 50% power for 5 minutes3. Remove plastic overwrap4. Rotate tray 1/2 turn5. 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 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

Java Program as Barcode

Xerox DataGlyph:

1KB per Sq inch Aztec: 1.9KBAztec: 1.9KB

“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

Cardholder Acquirer

Issuer

PaymentGateway

Merchant

(Open Loop Systems)

Payment Cards on the Internet

InternetCardholder Host Merchant

PaymentGateway

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

BobAlice Claire

Place Order

Request Payment

Make Payment

Deliver Goods

Secure Channels

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

Runtime Environment

CardManager

ProviderApplication

ProviderApplication

Provider SecurityDomains

GlobalPlatformAPI

Global Platform Process

1 Smart CardProduced with

Security Domains

2 Smart Cardis Activated

3 Provider WritesApplication

4 Security DomainAssigned to

Application Provider

5 ApplicationProvider ReceivesSecurity Domain

Keys

6 CertifierApproves

Application

8 ProviderDownloads

Application toCard Through

CAD

7 CertifierSupplies

AuthenticationData

9 Provider InstallsApplication

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

1 Java Compiler

2 CAP Converter

3 AssuranceTransformer

4 AssuranceProcessor

5 Applet Installer

6 Non-DefensiveVM

JavaSource

Class File

CAP File

TransformedCAP File

VerifiedCAP File

VerifiedApplet

On-Card ProcessingOff-Card Processing

CAP =Converted APlet

Leroy 2002

GlobalPlatform Process with On-Card Verification

1 Smart CardProduced with

Security Domains

2 Smart Cardis Activated

3 Provider WritesApplication

4 Security DomainAssigned to

Application Provider

5 ApplicationProvider ReceivesSecurity Domain

Keys

6 CertifierApproves

Application

8 ProviderDownloads

Application toCard Through

CAD

7 CertifierSupplies

AuthenticationData

9 Provider InstallsApplication

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

TheirServer

OurServer

SYN

SYN/ACK

TheirClient

OurClient

Our Firewall

SYN

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

User

Secondary Provider

Certification Server

Create cardwith security domain(s).

Card

Host

Card Programming Process

Card Issuer

Primary Provider

User

Secondary Provider

Certification ServerProgram transaction applet, get card.

TAppCard

Host

Card Programming Process

Card Issuer

Primary Provider

User

Secondary Provider

Certification ServerCertify applet code, create installation instructions.

TApp

Card

Host

Card Programming Process

Card Issuer

Primary Provider

User

Secondary Provider

Certification ServerObtain certified CAP file and authorized load and install

instructions.

Card

Host

TApp

Card Programming Process

Card Issuer

Primary Provider

User

Secondary Provider

Certification Server

Install TApp.

Card

Host

TApp

Card Programming Process

Card Issuer

Primary Provider

User

Secondary Provider

Certification Server

Create, obtain certification for, and install approval applet.

Card

Host

TApp

AApp

Card Programming Process

Card Issuer

Primary Provider

User

Secondary Provider

Certification Server

Obtain card and user-trusted host code. Use

card in user-trusted host.

Host

CardTApp

AApp

HostCode

PPC Installation Messages

TAppAAppHost Card Manager

Load and Install CAP

Install

Select

Request AID Object

AID Object

OK

Register

OK

OK

Trust Relations

Merchant

User

Secondary Provider

Payment Gateway

Host

CardTApp

AApp

HostCode

Card Use Process

Merchant

User

Secondary Provider

Payment Gateway

Host

CardTApp

AApp

HostCode

Select Purchase Item

Obtain Approvals

Complete SET Transaction

PPC Purchase Messages

AApp 2AApp 1Host TApp

Ok

PReq

Ok

OrderDesc, PurchAmt

OrderDesc, PurchAmt

OrderDesc, PurchAmt

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 off-

card 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

if price > tshould reject

if t=0

should reject

Cash Card Policy

if merchant = hospital must approve; uses++

if uses=5

Emergency Card Policy

if item not candy should approve

Parental Policy

Finite StateAutomata

Policy Analysis Framework

Firewall Policy

Java CardPurchases

Policy

HTTP RequestHandling Policy

ObjectMethod

Invariants

Policy Automata

FirewallRules

…

JavaCardApplets

ApacheModules

Code Generation

Analysis

RuntimeChecks

NonmonotonicLogic

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

Frontend

Analysisengine

Code generator

Java Cardcompiler

(Oberthur)

Java Card

automata,properties

results,counter-examples

automataJava

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 Projecthttp://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

BobAlice Claire

b, H(c), D

H(b), D

D = SAlice[H(b), H(c)], EClaire{c, H(b)}

SET Protocol

MC P

Bella, Massacci, Paulson, 2002

LIDM, ChallCPInitReq

LIDM,XID,ChallC,ChallM PInitRes

OIDualSign, PIDualSignPReq

LIDM,XID,H(OIData),HOD,PIDualSignAuthReq

LIDM,XID, PurchAmt,authCode

AuthResLIDM,XID,ChallC,H(PurchAmt) PRes

Dual Signature Data

HOD = H(OrderDesc, PurchAmt) OIData = XID, ChallC, HOD, ChallM

PIHead = LIDM, XID, HOD, PurchAmt, M, H(XID, CardSecret)

PIData = PIHead, PANData

OIDualSign = OIData, H(PIData) PIDualSign = SC[H(PIData), H(OIData)],

EP{PIData, H(OIData)}

b

c

Globally unique transaction identifier