Security and Trust Services API for J2ME™ Technology (JSR-177)

●Zhiqun ChenSpecification Lead, JSR-177Sun Microsystems, Inc.

JavaPolis 2003

●Piotr CoftaPrincipal Scientist

Nokia

●Olli ImmonenSr Software Engineer

Nokia

Overall Presentation Goal

●Learn about the API in JSR177 that provides security and trust services to J2ME™ applications

Speaker’s Qualifications

● Zhiqun Chen is the Specification Lead for JSR-177. She speaks frequently on Java Card and security-related topics. She is the author of the book “Java Card Technology for Smart Cards.”

● Piotr Cofta works as a Principal Scientist for Nokia. He participated in the development of JSR-177 specification. He publishes and speaks on subjects of trust and security.

● Olli Immonen is a member of JSR-177 EG. He specializes in mobile platforms, authentication tokens, cryptographic libraries and smart card interaction. He was an editor of WIM and OMA security specifications.

Presentation Agenda

● JSR-177 Overview● Communication API

• APDU • Java Card RMI

● Access Control Mechanism● PKI: Signature Services and User Certificate

Management API● Cryptography API● Q&A

JSR-177 Overview

● Developed through the Java Community Process™ (JCP™)• Java™ Specification Request (JSR) filed in March

2002• Community Review in April, 2003• Public Review in October, 2003

● Expert group consists of leading wireless operators, handset manufacturers, smart card manufacturers, and security solution providers

● http://jcp.org/en/jsr/detail?id=177

JSR-177 Goal

● Provide APIs for security and trust services through integration of a Security Element (SE)• Commonly a smart card

● Interaction with security element provide:• Secure storage for sensitive data• Cryptographic operations • Secure execution environment for custom

and enabling security features

JSR-177 Scope

● Smart Card Communication• Support communication with smart card applications• Communication protocols

- APDU, (U)SAT, and JCRMI

● Application Level Digital Signature andUser Credential Management• Support formatted digital signatures• Support user credential management which includes creating

certificate signing requests, adding user credentials, and removing credentials

● Cryptography API• Provide a subset of the J2SE cryptography API• Support basic cryptographic operations that include signature

verification, encryption, and decryption.

JSR-177 API Packaging

● SATSA-APDU Optional Package• Support communication with smart card applications using

APDUs• Support communication with (U)SAT applications of an (U)SIM

card

● SATSA-JCRMI Optional Package• Define a Java Card™ RMI client API to support remote method

invocation of Java Card™ objects

● SATSA-PKI Optional Package• Support application-level digital signature and user credential

management

● SATSA-CRYPTO Optional Package• Provide basic cryptographic operations to support signature

verification, encryption, and decryption

JSR-177 API Security

● Define permissions to protect access tothe JSR177 API when it is deployed onMIDP 2.0 devices

● Recommended SE access control policy• Provide an access control model that allows the

SE to control the usage of its resources• Provide fine-grained access control• Apply to the smart card communication API

within the scope of this specification

Smart card access

JSR177 APIs

(U)SAT

Card App. Card App.

J2ME AppJ2ME App

APDU

Logical Channels

Java Card RMI

J2ME VM

APDU Communication Manager(Native Functions)

APDU

SAT App.Card App.

APDU access

● Low-level general-purpose access• applications must understand APDU• uses GCF concept

● Access from J2ME application to applications on smart card

● ISO 7816-4 cards (incl. JavaCards)● JavaCards extra support -> JCRMI access● Separate logical channels● Not synchronised (except for close())

Example – APDU access

try { acn = (APDUConnection)Connector.open (“apdu:0;target=A0.0.0.67.4.7.1F.3.2C.3”);

responseAPDU = acn.exchangeAPDU(commandAPDU); ... } catch (IOException e) { ... } finally { ... if(acn != null) { acn.close(); } ... }

ATR support

● ATR – answer to reset• basic characteristic of the card• shared by all applications• read-only• no application control over reset

responseAPDU = acn.getATR();

● Application must process the response

Special support for SAT

● SAT == (U)SIM Application Toolkit• operator’s application in SIM• specified set of APDUs

acn = (APDUConnection)Connector.open (“apdu:0;target=SAT”);

● Extra support provided• only for operator MIDlets• only ENVELOPE command• only channel 0• (U)SIM-specific handling of response bytes• (U)SIM is responsible for proactive sessions

JCRMI communication

● Object-oriented distributed applications• complexity hiding, no APDUs on application level• looks like method invocation• requires local proxy

● JavaCard 2.2 • on-board RMI support• logical channels (one channel per connection)• logical channel used either by APDU or JCRMI, no sharing

● Subset of J2SE RMI• static stubs• stubs coming with application

JCRMI architecture

method( params )

Response APDU

Return value

Client App Proxy

Prepares thecommand

Decodes theresponse

Decodes the command

RMIservice

method( params )

Return value

Prepares theresponse

remoteobject

Command APDU

JCRMI - example

try { JavaCardRMIConnection connection = (JavaCardRMIConnection)Connector.open

(“jcrmi:0;AID=A0.0.0.67.4.7.1F.3.2C.3”);

Counter counter = (Counter) connection.getInitialReference(); ... currentValue = counter.add(50); ... connection.close(); } catch (Exception e) { ... }

PIN support

● PIN support is available for APDU and JCRMI● All-inclusive method to enter PIN

• securely asks the user for PIN• allows for cancellation• formats PIN into APDU• sends APDU to the card• collects the response

responseAPDU=acn.enterPIN(pinID);

● PIN is identified by its number in the -> Access Control List

● PIN is never disclosed to the application● Methods exist to manage PINs

Access control

● Applies to• APDU (but not SAT)• JCRMI• does not apply to PKI

● Principles• identified application on both sides• policy specified by the card• access control executed by the implementation

Access control

APDU

JSR177 APIs

(U)SAT Java Card RMI

APDU Communication Manager(Native Functions)

J2ME VM

Card App.

J2ME AppJ2ME AppApplication

Signature

Access Controlimpl.

Access Control Files

Logical Channels

Card App.

APDU

Card App.SAT App.Card App.

Access Control Files

● Access Control Files• stored in the Security Element • root file stored in the ‘well known’ place• one file per application (plus one for the entire SE)• each non-root file contains the list of Access Control Entries

● Access Control Entry• principals (who can access)• permissions (what access)• PIN info (if needed)

Access Control Entry Example

ASN.1 value notation { principals { rootid

'A9993E364706816ABA3E25717850C26C9CD0D89D'H, -- hash of root certificate } permissions { apduMaskPermission '00B0000000110000'H, -- permission for READ operation }}BER encoding3024A0160414A9993E364706816ABA3E25717850C26C9CD0D89DA10A040800B0000000110000

SATSA-PKI

● Digital Signatures ● Message Signature Service● User Credential Management

Digital Signature

Display text

User enters Signature PIN

Signature PIN

Hash of text

SignatureSignature, signed data, certificate

Security Element

TerminalApplication Text to be

signed

Message Signature Service

● High level API for generating digital signatures● UI

• Text to be signed• Certificate (-> private key) selection• PIN entry

● SE communication and implementation● Generate CMS formatted messages

• RFC 2630, RFC2634 and OMA ECMAScript signText

• links credential (certificate), signed data and cryptographic signature

● Distinction between methods based on• Behaviour• Key usage

CMSMessageSignatureService

● sign (String stringToSign, int options, String[] caNames, String securityElementPrompt)• Always display String to sign (UTF-8)• Implementation handles user PIN entry• Non-Repudiation Key usage

● authenticate (String stringToAuthenticate, …• Authenticate Key usage• Rest is same as sign

● authenticate (byte[] byteArrayToAuthenticate, …• Does not display byte array• Rest is same as authenticate (String stringToAuthenticate, …

Sample Code

try {

String stringToSign = new String("Pay 50 eur");

String caName = new String("cn=CA, o=XBank, c=fi");

String[] caNames = new String[1];

CMSMessageSignatureService.sign( stringToSign, SIG_INCLUDE_CERTIFICATE | SIG_INCLUDE_CONTENT, caNames, null);

} catch (CMSMessageSignatureServiceException ce) {

if (ce.getReason() == ce.CRYPTO_FORMAT_ERROR) {

...

}

}

User Credential Management

● Need a link between public key and user identity● Provided through PKI using X.509 certificates● Number of provisioning models

• Establish link during manufacture• Establish link at point of sale• Establish link independent of manufacture or sale process

● Can only certify a key after generation• Key may not be generated at time of sale or manufacture

● Enrolling a user in a PKI contains• Technical steps (POP, retrieve public key, issue certificate, return

certificate)• Non-technical steps (proof of identity, multiple authorisers, registration

process)

● Provide technical building blocks for User Credential Management• Separate process from technology for registration

UserCredentialManager

● generateCSR• Generate PKCS #10 Certificate Request• Key selection through algorithm, key usage and key length• Allows key generation to be forced (if implemented on SE)

● addCredential• Add a credential (certificate or certificate URL)

● removeCredential• Remove a credential

Sample Code

try { // Obtain an enrollment request

String nameInfo = new String("CN=BeJUG"); enrollmentRequest = UserCredentialManager.generateCSR

(nameInfo, ALGORITHM_RSA, 1024,

KEY_USAGE_NON_REPUDIATION, securityElementID,

securityElementPrompt, false, null);

// Send it to server using HTTP POST

// ...

// Store the certificate on the security element

UserCredentialManager.addCredential( "BeJUG", pkiPath, url);

} catch (UserCredentialManagerException pkie) {

...

}

SATSA-CRYPTO

● Crypto API Overview● Crypto Packages

Crypto API Overview

● Subset of the J2SE Java Cryptographic Extension (JCE)

● Result of subsetting: 90 K -> 7 K (just declarations)

● Subsetting criteria• Include minimum number of classes and methods to satisfy

selected use cases, not satisfied by other SATSA packages- Signing with Security Element keys supported in SATSA-PKI- Arbitrary smart card access supported in SATSA-APDU and

SATSA-JCRMI

• Support only a default Cryptographic Service Provider- Current J2ME platform does not support loadable libraries

● Expose crypto contained in the platform• E.g. the MIDP 2.0 platform has RSA and SHA-1 algorithms

Crypto Packages

● java.security, java.security.spec• Handling public keys (KeyFactory, X509EncodedKeySpec)• Computing digests (MessageDigest)• Signature verification (Signature)

● javax.crypto, javax.crypto.spec• Handling symmetric encryption keys and parameters

(SecretKeySpec)• Symmetric encryption and decryption, asymmetric encryption

(Cipher)

● Note: private key operations supported in SATSA-PKI (CMSMessageSignatureService)

Sample Code

try {

// Construct public key from X.509 encoded value

X509EncodedKeySpec pubKeySpec = new X509EncodedKeySpec(encodedPubKey);

KeyFactory keyFactory = KeyFactory.getInstance("RSA");

PublicKey pubKey = keyFactory.generatePublic(pubKeySpec);

// Verify the signature

Signature sig = Signature.getInstance("SHA1withRSA");

sig.initVerify(pubKey);

sig.update(data, 0, signedData.length);

boolean result = sig.verify(signature, 0, signature.length);

} catch ...

Summary – JSR177 (SATSA)

● What’s that? Security and trust services API for J2ME technology

● What’s in?• APDU communication with access control and SAT support• JCRMI support for JavaCards• PKI, authentication, authorization, certificate management• Cryptographic library

● What is the Security Element? Most commonly smart card.

● What status? Public Review● Where? http://jcp.org/en/jsr/detail?id=177● How large? 198 pages.

Q&A