verification_slides

IntroductionJava Cards

An augmented bytecode verifier

Java Card Bytecode VerificationDesigning a new verification system

Alessio Parzian

European Institute of Innovation and TechnologyUniversity of Twente

Security & Privacy

August 5, 2015

Alessio Parzian Bytecode Verification

Contents

1 IntroductionMobile devices and paymentsThe secure elementThe management issue

2 Java CardsIn a nutshellAttack vectors

3 An augmented bytecode verifierRequirement analysisA new scenarioTechnicalities

Mobile devices and paymentsThe secure elementThe management issue

“The convergence of payments and mobile communications is notjust logical – It is inevitable”

– John Coghlan, Ex CEO Visa USA

7−→ Contactless payment adoption7−→ Mobile device ubiquity7−→ Expanded mobile functionalities

Figure 1A physical secure element (SE)in an Android mobile device.

7→ NXP Solution: Java Card SE + NFC

DefinitionProtected area, independentfrom the application processorof the device, which is capableof storing and processingsensitive information of thedevice holder.

ServicesAuthentication, encryption ofprivate data, data integrity andnon-repudiation are typicalservices that a secure elementprovides.

Figure 1A physical secure element (SE)in an Android mobile device.

7→ NXP Solution: Java Card SE + NFC

DefinitionProtected area, independentfrom the application processorof the device, which is capableof storing and processingsensitive information of thedevice holder.

ServicesAuthentication, encryption ofprivate data, data integrity andnon-repudiation are typicalservices that a secure elementprovides.

The parties involved

Card ManufacturerAuthority that fabricates the raw hardware and software.

Card IssuerAuthority that controls the secure element content.

Application DeveloperAuthority that implement applets.

The ideal SE initialization and management

Card Issuer can add libraries onto an SE as neededCard Issuer can outsource freely the development of appletsA SE is largely customizable by end users who can installapplets as needed 7→ Applet MarketApplets from different Card Issuers can be installed on thesame SEA SE is as flexible as a mobile operating system, but moresecure

7→ Java Card has all the features to allow that!7→ Dynamism and Multi-application.

The current SE initialization and management

A Card Issuer asks NXP to initialize a security domain on a SEA Card Issuer hands libraries/applets to be installed to NXPNXP verifies the requested software and installs it onto the SEThe SE is released and will not be further personalized

Too many drawbacks

1 Not enough flexibilityNo post issuance uploadsNo multi-applicationStrong relationship between a SE manufacturer and a cardissuer required

2 Card Issuer are looking for new solutions7→ Host-based card emulation

3 Potential of Java Card SE only partially used

Too many drawbacks

As a SE manufacturer, NXP Semiconductors, is strongly interestedto invert this trend. But how can this be achieved?

1 Studied advantages and weaknesses of Java Card2 Classified its current vulnerabilities and attacks vectors3 Analyzed stakeholders business requirements4 Designed an innovative applet verification system

An augmented bytecode verifierIn a nutshellAttack vectors

Architecture

Applet Applet Applet

Java Card FrameworkAPIs

Java CardVirtual Machine

Native Operating System

Underlying Hardware

Smartcard (On-card)

CardAcceptanceDevice(CAD)

Hostapplication

Host/PC (Off-card)

responses

commands

Java Card

Runtime

Environment

BackendApplication

Remote server

respon

commandsFigure 2

The Java Card smartcard architecture

Benefits

- Interoperability, developed applets can be run on anyJava-enabled smartcard.

- Multi-application, multiple applets can reside on the samesmartcard.

- Dynamism, applets can be added after a smartcard issuance.- Enhanced security, built-in dedicated security mechanismsare deployed in the architecture.

Defined a new nomenclature and classified attack vectors byvulnerability. Hereafter the most relevant:

1 Power Analysis and Manipulation- Differential Power Analysis- Fault Injection

2 Applet Exploitation- Hidden commands- Unchecked parameters- Unsafe crypto protocols

3 Type Confusion 7→ byte == short ??- Obtaining the right to load code- Injection of ill-formed code- Run a developed attack vector

Requirement analysisA new scenarioTechnicalities

The concept

OracleVerifier

CAPExport files

Additional ChecksTyped verification over export files

Transaction moduleFault Injection module

SigningSystem

Device’sSecure Element

Figure 3The Off-card verifier working principle

Research QuestionHow can we design a process such that an augmentedbytecode verifier can be used to provide a flexible and

highly-secure system for applet installation?

Business requirements and their impact

Priority

Major Moderate Minor

Requirement

1. Hostile Environment 3

2. Verification enforcement 3

3. Flexible relationships 3

4. Code confidentiality 3

5. Transparency 3

6. Uploads monitoring 3

Table 1Stakeholders’ business requirements priority

A system story

Assumption: SEs already initialized and released

CI 7→ NXP Service RequestNXP 7→ CI Augmented bytecode verifier releaseCI Libraries development, verification, uploadCI 7→ AD Applet development outsourcingCI 7→ NXP Service request for ADNXP 7→ CI 7→ AD Augmented bytecode verifier releaseAD Applet development, verification, uploadEndUser Applet download, installation

A system story

Phases identification

Stakeholders have different requirements, different roles, differentresources and are numerically distant. Therefore, they must betreated separately to be much more effective in designing thesystem architecture. Three phases for each stakeholder can beidentified:

- Activation, which refers to the moment where a newstakeholder registers into the service.

- Usage, which refers to the phase where content, intended tobe uploaded onto one or more secure elements, is verified.

- Distribution, which refers to the step of uploading a verifiedcontent onto one or more secure elements as needed.

A system story from a card issuer perspective

Assumption: Focus on the Usage phase

The system distributed architecture I

CardIssuers1..N

Verifier1..N

VerifiedCAP Database

Location 1..N

NXPbackend

Verifier LicensesCertificates

SignedExport Files

(JCOP,lib,app)

Location αEntities CardinalityNXP - Card Issuer → 1:NNXP - Verifier→ 1:NCard Issuer - Verifier→ 1:1

Trusted AreaUntrusted Area

1. CAP & export file

6. Signed CAP

7. Signed CAP upload

2. License verification & oncard exp file applet retrieval

4. Report final process outcome

5. Upload of the signed applet export files

3. Verification modules

Figure 4The distributed architecture from the Card Issuer perspective

A system story from an application developer perspective

Assumption: Focus on the Usage phase

The system distributed architecture II

ApplicationDeveloper

Verifier1..N

Location 1..N

Card Issuer1..N

VerifiedCAP

Database

CertificatesApplicationDevelopers

Location a..z

NXPbackend

ReleasedVerifier Licenses

Certificates

SignedExport Files

(JCOP,applets)

Location αEntities CardinalityNXP - Card Issuer → 1:NNXP - Verifier→ 1:NCard Issuer - App. Developer→ 1:NApp. Developer - Verifier→ 1:1

Trusted AreaTrustworthy AreaUntrusted Area

1. CAP & export file

7. Signed CAP

8. Signed CAP forwarded 9. Signed CAP file resigned and uploaded

4. Card issuer cryptographic confirmation for uploading

2. License verification & oncard exp file applet retrieval

5. Report final process outcome

6. Upload of the signed applet export file

3. Verification modules

Figure 5The distributed architecture from the Application Developer perspective

The protocol concept

Components: augmented bytecode verifier, Java Cardtoken, NXP backendRemote secure tunnel between the Java Card token and NXPbackend 7→ monitoring the verifierLocal secure tunnel between the Java Card token and theverifier 7→ avoid MITM attacksUse of finite automata to enforce statesUse of timers to further decrease the attack surfaceCryptographic confirmations from a Card Issuer and NXPbefore signing

7→ Security centralized in NXP hands7→ Distribution left in Card Issuers hands

From inside the verifier

MAIN EXECUTION

1. CAP file

1. Exp file

10. Signed CAP file

10. Signed Exp file

Modules1 .. k

Java CardToken

App. Developer Location

2. License verification

nmodules

4. Magic

numbers 5.Crypto

confirmation

7. CAP,exp

8. Signed CAP,exp

9. Exp upload

Figure 6The augmented bytecode verifier at the Application Developer location

Security mechanisms to counteract white-box attacks

BinaryEncryption

Code Obfuscation and Flattening

On disk In memory Executing

VerifierCode

VariablesConstants

Figure 7States of the software attackable in a white-box

scenario

White-box Cryptography

RuntimeIntegrityCheck

BinaryEncryption

VerifierCode

VariablesConstants

scenario

BinaryEncryption

VerifierCode

VariablesConstants

scenario

BinaryEncryption

VerifierCode

VariablesConstants

scenario

BinaryEncryption

VerifierCode

VariablesConstants

scenario

Runtime Integrity Check

ThreatAn attacker is able to modify a check with another

self-implemented module

NXP m2 Main execution h Token

Build module M from m1 and m2

Run MCompute Magic Number 7→ session dependentCompute Hash hSend h to the token for verification

White-box CryptoThreat

An attacker is able to perform a MITM attack between the mainexecution and the token

Lookup tables lt

Main execution

Session key sk

Bidirectional tunnel

Symmetric cryptographySecure tunnel between NXP and token7→ sk and lk securely deliveredMain Execution is an untrusted entity7→ white-box crypto using fixed key approachLookup tables initialized each session according with sk

Edge cases

It is not feasible to forecast the effects of a breach in a White-boxscenario, thus security mechanisms to deal with edge cases mustbe designed.

1 Key Renewability2 License Revocation3 Verifier Binary Diversity

Edge cases

Implementation Direction

Modules in Java

High-level languagePortable binariesOracle verifier source

Main Execution in C

Effective obfuscation/flatteningLess reversibleMore complex

Communication through JNIEven if modules can be considered as conceptually independent piece ofsoftware from the main execution, they are strongly interconnected andcontrolled by means of our runtime integrity check mechanism proposed andthe two involved trusted party, NXP and token, which can monitor thecorrectness of the operations throughout the entire process of verification.

Thank you for yourAttention.

Content Outline

1 IntroductionMobile devices and paymentsThe secure elementThe management issue

2 Java CardsIn a nutshellAttack vectors

3 An augmented bytecode verifierRequirement analysisA new scenarioTechnicalities

Do you haveany questions?

A new nomenclature

A nomenclature that covers all feasible classes of attacks on JavaCards, namely logical attacks, physical attacks and side channelattacks. Each class introduces, at a high level, feasible attacktypes grouped by vulnerabilities along with the commoncountermeasures that should be taken to counteract those attacks.

Scenario Properties

1 The verification process is successfully completed2 CAP and export files preserve their integrity after verification3 Stakeholders are always authenticated prior to any action to

avoid unwanted behaviours4 Revocation can be always applied to avoid relevant failures5 The augmented bytecode verifier is strongly resilient to

white-box scenario attacks

verification_slides

Documents

Transcript of verification_slides