Technical Committee Meeting, Paris, 7 - 8 April 1998

Presentations 7 April

Presentations 8 April

Presentations to be made at the next Java Card Forum on June 3-5:

Horizontal domains

Mario di Prizio: Overall framework description
Walter Haenel: Operations - problem domain/analysis/requirements
Augustin Farrugia: API - problem domain/analysis/requirements
Tim Jurgensen: Platform (SPI) - problem domain/analysis/requirements

Vertical domains

TBD: GSM

Tim Jurgensen: IT

David Wentker: Financial

Tuesday, April 7

In Master's chamber
We gather for big feast.
We stab it with our steely knives,
But we just can't kill the beast.
"Hotel California"
The Eagles

First, we had a quick roundtable introduction of attendees. While this is not a meeting with the Strategic Partners, there are several non-member attendees who have agreed to help with some of the vertical domain API development work. Specifically, there are people from the ETSI group (telecom), Visa and Citibank (financial), and Security Dynamics (IT).

The general agenda will be to have a short, joint meeting of the Business and Technical Committees followed by separate meetings of the two committees for most of the two days. We'll conclude with a final joint meeting of the two committees at the end of the day on Wednesday.

Bertrand reviewed the Technical Committee agenda which had been distributed shortly before the meeting. It was decided that we need to meet in a joint group later on today (Tuesday) in order to hear the presentation on cryptography and discuss a joint approach to export/import restrictions. In addition, we'll meet jointly tomorrow (Wednesday) to discuss the issue of bytecodes (the topic also includes the issue of binary load file format for applets).

Business Committee Agenda (Michel Roux)

• Approval of the report of last meeting
• Review of pending action items
• Interoperability between Java Card and terminals (technical workgroup
• Feedback from Sun on Javaone
• Status on licensees (Sun)
• Next meeting with Strategic Partners

Bertrand asked that the following items be added to the Business Committee:

• Semantic model of Java Card and security; do we want to have a joint effort in this area or do we want to work separately?
• Export issues; do we want to have a joint effort in this area or do we want to work separately?
• As we work up the various vertical APIs, we're going to run into the issue of Intellectual Property use and ownership fairly soon; how do we handle it?

Technical Committee Meeting

GSM API Market Requirements and API Development
(Presentation by Fabien Thieret)

There have been two meetings of the SMG9 (ETSI) working group concerning the GSM API. These occurred on 25-26 March and 6 April.

The working group was divided into two sub-groups: "compatibility" and "security". The compatibility group is looking at compatibility among a variety of the GSM standards; specifically among the GSM 11.11 (SIM specification), 11.14 (handset development toolkit), and 3.49 (security aspects of the SIM card) standards.

The security group has discussed applet certification. They've looked at what MULTOS did for this issue. The work group also wants to address the issue of (security of) object sharing. Gemplus will be providing a proposal for how to handle applet management. Whether this is viewed as a replacement for the "Java Card Framework" or an enhancement has to be discussed. Augustin suggests that it will be an augmentation of the "framework", not a replacement. It doesn't require a modification to the JavaSoft defined run-time executive.

A proposal on "object sharing" plus Access Conditions will be prepared by Schlumberger.

A proposal on GSM compatibility is being prepared by Orange and Motorola.

Yesterday's meeting (April 6) looked at SIM API; discussion topics and issues included:

• The full SIM API must be updated to be compliant with Java Card 2.1 Specification; specifically with the file system, exceptions, and PIN handling.
• SW; description from the ETSI document.
• GSM API uses only T=0 protocol; GetResponse is used; issue
• Toolkit Framework
• Toolkit Applet triggering; how are short messages received from the network and then dispatched to the applet. This is a second dispatcher on top of the Java Card run-time environment

Working group homework for the next meeting (France, 27-29 April): this working group is developing a document (GSM 2.19) which is intended to be adopted by ETSI.

• SIM API update to comply with JC 2.1 (Augustine)
• Access conditions
• Object sharing
• Application identification
• Document template (for SIM API in the "large sense"; i.e. covers more than just the API)
• Work with JavaSoft on the 2.1 Specification

Augustine can provide a current version of the draft GSM API document. (PDF, 81K)

SMSC (Mobile Service Center) - when can applets be loaded onto the card:

• during personalization
• at card issuing (over the air)
• at the point of sale

Does application identification have anything to do with AIDs? Could be; AIDs are not excluded yet (in GSM environment) but are not yet defined.

[Complex drawing by Fabien at this point. It outlines the current thinking within the ETSI group about how applets are loaded onto a card. This figure is not yet ready for general release.]

There was a discussion at this point (stimulated by Patrice Peyret) regarding whether the GSM was going to require rewriting a card file system in Java in order to meet the requirements of the GSM API. The concensus opinion seemed to be that this should not be required.

Bertrand presented a list of elements that he identified in the GSM presentation that one might expect to find in the other vertical domain API discussions/presentations:

• PIN management
• Applet management
• Object sharing
• Access conditions
• Application identification
• Document template
• File system
• Toolkit framework - how to load and launch applications
• Applet triggering - and dispatching
• Server environment for applet loading

Presentation on IT Requirements

Tim Jurgensen gave a presentation on IT Market Requirements and very early considerations on the API which might be specified in response to those requirements. The market requirement presented have been determined in two meetings of an IT sub-group of the JCF along with Strategic Partners specfically interested in IT.

[Ed note: Included below are all of the slides of the presentation, some of which were not shown in the meeting due to the logistics of copying the slides manually.]

• Scope of IT Market Requirements
• Provide security (tokens) for Information Technology applications
• Provide security mechanisms for Java Card (on-card) applications]
• Provide security mechanisms for other Java Card domain APIs
• Customer Needs
• Security Infrastructure API
• Extension of Communication Capabilities
• Card Management API
• Common Object Store
• Security Infrastructure
• Biometric framework
• Secure access mechanism (access conditions)
• Authorization extensions
• Secure messaging (ISO 7816-4?)
• Extension of Communication Capabilities
• RMI (?)
• Wrapper class for APDU handling
• Easier programming (card and terminal)
• Communication paths; e.g. server to card
• Card Management
• Secure, dynamic applet loading
• Secure, dynamic applet removal
• Card capability information
• requesting (query) mechanism
• reply structure
• reply contents; e.g. vendor, JVM version, JC API version, keylengths, resources, etc
• Common Object Store
• Naming objects (across application boundaries)
• Sharing objects
• Database-like facilities for querying objects
• Object store
• Business Framework
• Customers of IT API include
• Facilities management (Physical Access)
• IT management (Logical Access)
• Other vertical domain API business elements

IT API is largely aimed at Infrastructure

• Security Requirements
• Identity authentication
• Privilege authorization
• Transaction non-repudiation
• Trust management
• Transaction Privacy (encryption/decryption) separable from other security mechanisms (authentication) to comply with export/import/use restrictions
• Technology (Security
• Classical smart card security technology
• Public-key infrastructures
• Private-key infrastructures
• Authorization framework
• Wide area network security technologies
• Physical access technologies
• Technology (Communication Facilities)
• IDL
• Remote Method Invocation
• Directory/name services
• Cross platform thread extension (?)
• Cross platform exception propagation (?)
• Regulatory and Standards Environments
• Import/export environments
• Network security standards
• Public key infrastructure standards (PKCS)
• Private key infrastructure standards (Kerberos)
• Computer system security standards
• CDSA
• CAPI
• Other?
• Domain specific standards (GSM, Financial)
• Interoperability
• Of PKI components (keys, certificates, etc.)
• Of PKI APIs
• Of IT components, e.g.:
• SSL
• MIME
• Of Java Card Apps
• Value Proposition
• IT facilities form the base security foundation for other vertical domain APIs
• IT facilities are aimed at infrastructure

These Market Requirements will be submitted for review by the IT sub-group and then to the JCF leadership for approval and further distribution.

Presentation (VISA) by David Wentker

"The Visa Open Platform"

This presentation emanates from the fact that Visa has changed its policy regarding the use of products based on the Open Platform Specification . The gist of this policy change is:

Before:

Products based on the specification could only be sold to Visa Members.

Now:

No restriction regarding the sale of products based on the (Open Platform) specification

Open Platform is:

• Multi-application smart card system architecture for the financial industry.

Specifications and Requirements for:

• cards
• card production
• card acceptance devices
• application development tools
• back-office systems

Intended as an implementation guide which builds upon the Java Card standard to enable manufacturers to produce complete, consistent, secure and interoperable Java Card products for Visa Members

Design Principles

• Multi-application cards are the target
• Issuers must have mechanisms to control the content of their cards
• Issuers will partner with others who will provide and own applications on the issuers' cards.
• Issuers must be able to change the content of their carfds during the carfd lifetime.
• Issuers may delegate some control over card content changes to business partners.
• Application owners must have mechanisms to ensure the security of their applications separate from the issuer.

Card Specification Contents - Card Architecture

• Security Architecture
• Card production description
• Initialization
• Card states
• Personalization standards and practices
• Post-Issuance Card Management
• Load architecture

Spec also includes security policies for Visa branded cards.

Card Architecture

[Figure 1]

Main System Applet:
The Main System Applet belongs to the Issuer and ultimately controls the entire card.

• Card life cycle state management.
• Overall Card content management and auditing.
• Controls Post-issuance application loading.
• May assist in applet personalization.

Auxiliary System Applets:
Auxiliary System Applets are optional components which can be placed on a card to represent the security interest of the issuer's business partners.

• Partial card content management.
• Partial control over post-issuance application loading.
• May assist in applet personalization.

Development Status

1. Specification Published 30/9/97

• Architecture stabilized
• Initialization & Personalization commands defined (APDU)
• Post Issuance Loading commands defined (APDU)
• Open Platform API defined for interface between System Applets alone and System Applets with other applets.

There will be a pilot program (which includes issuance of cards) in Singapore starting in June.

2. Specification to be Published 9/98

• Improved implementation detail.
• Security implementation extended to include asymmetric cryptography.
• External specification defined for material needed for vendor product documentation.

Visa will be investing in a number of security evaluations, including for the Java Card Virtual Machine

Visa will be attempting to impact export restrictions (favorably) with respect to Open Platform.

Currently, Visa would not allow a sub-setted implementation of Open Platform. They will be looking at whether there's sub-settable core that they could define. They're willing to talk about sub-setting if someone has a strong reason to want to do it.

Bertrand observed that we're very likely to come up with comparable APIs in some domains (i.e. comparable to the OP spec), therefore, it would be very nice if we were able to adopt the OP spec (at least in those areas).

Discussion to try and find some commonality (Mario Di Prizio, Facilitator)

Opportunities for commonality

• PIN management
• Applet management
• Object sharing
• Access conditions
• Toolkit framework; e.g., load/launch applications
• Toolkit applet triggering; e.g. dispatch events
• Application identification
• Document template
• Server environment
• During personalization
• Over the air
• Point of sale
• File system
• Card resource management
• Non-ISO protocol
• Naming objects
• Security infrastructure
• Biometric, access, authorization, certificates, key management, secure messaging
• Key recovery
• Exception propagation
• Main system applet
• Auxiliary system applet
• Card life-cycle and state management
• Applet life-cycle and state management
• States: installed, registered, loaded, etc.
• Remote method invocation

Now, let's look at grouping these opportunities:

• Security Infrastructure
• PIN management
• Access conditions
• Biometric, access, authorization, certificates, key management, secure messaging
• Key Recovery
• Enhanced Communications
• Non-ISO protocol
• Remote method invocation
• Exception propagation
• Card Management
• Card resource management
• Applet management
• Toolkit framework; e.g., load/launch applications
• Application identification
• Server environment
• During personalization
• Over the air
• Point of sale
• Main system applet
• Auxiliary system applet
• Card life-cycle and state management
• Applet life-cycle and state management
• States: installed, registered, loaded, etc.
• Common Object Store
• Object sharing
• Naming objects

Cryptography Presentation by Thomas Stocker

The crypto API as now defined as a Java Card extension API, the method for verifying and computing a MAC (using decryption) is not done as it is typically done within other existing systems.

This presentation was the latest in a long series of presentations trying to patch up the Crypto API. There seems to be general agreement that we need this.

Java^TM is a trademark of Sun Microsystems

[Java Card Forum] [Charter] [Calendar] [Contacts] [Communications]
[Technical] [Business] [Memberships]

Webmaster