Next meeting of the task force will be March 23 and 24 in Cupertino. This is a Monday and Tuesday immediately prior to the
JavaOne conference.
Presentation by Eric Vetillard (Gemplus)
Interoperability
- The same methodology has been used
- gather requirements through e-mail
- make a summary
- have a meeting to finalize the requirements
- The issue is far more intricate
- The meeting has not gone as far as the first one
Market requirements
- card interoperability
- after issuance download of applets
- programmable in Java
- same security level as Java
- target platform: 16K ROM - 8K EEPROM - 512 B RAM
- standard APIs
- Scalability towards Java
- "distributability" of applets
- products available by 1998/99 (to be refined)
More than requirements, but not yet a solution:
- support VM-specific data-type size and layout, by using meta-data as linking information
- avoid bias toward a particular chip architecture
- keep the properties of the original Java byte code, in particular on terms of security
- the post processor output includes linking information
- card input must be comparable in size to the executable code
Assumption is that there will be some type of post processor that takes the class file output from the compiler and prepares a file
which can be downloaded into the card.
More
- do not require complex transformation of code on card at install time
- indicate resources required on card to install
- allow link information to be removed from card after installation
- One objective: define one base format that can be downloaded and executed on all cards.
Some discussion about whether we should use a FAT file format.
Basic architecture
Class files
Post-processor (which processes class files based on Link information)
It creates a FAT File which contains the file which can be downloaded into the card and is
Future Work
- First, finish the requirements
- Meeting minutes will be distributed
- The remaining requirements will be discussed off-line
- Then, make a first draft for a proposal
- Sun is leading the work
- Some members have proposed their help (Bull, Gemplus, SLB, G&D)
- Discuss this first draft around JavaOne
Presentation by Patrice Peyret (JavaSoft)
Interoperability task force
Summary of requirements
- enable interoperable post-issuance installation of applets into cards of known size
- programmable in Java (subset)
- benefit from established Java security
- upward compatibility (to bigger cards)
- efficiently distributable
Technical constraints
- byte code
- file format
- installation
- extensibility
- security
- versionning
- tools
- (must be specified in sufficient detail to be implementable)
Byte code
- allow early and late binding
- unbiased to internal bus width (8, 16, 31 bits)
- verifiable
- completely specified; syntax and semantics
- when semantics differ from Java, ensure
File format
- input to card approximately same size equivalent assembly code: limited to byte code and lookups required
- outputs of post-processor be reversible back into class files (verifiability)
- linking information separate from byte code
- file may contain applet(s), packages
- no complex transformations required in putting file on card
Installation
- Install protocol compatible with GSM SMS transport
- Make it possible to indicate to the card the intended operational size
- allow link information to be removed by card after installation
Scoping Diagram (essentially the same figure as Eric's)
Next Steps
- draft will be created with interested and available parties over the next few weeks
- circulate a draft before the next task force meeting
- next meeting will be March 23 & 24 in San Jose
File system presentation
- compare file system to
- implementation of German Geldkarte (ZKA)
- implementation according to ETSI TE9 EN 726 standard
- Analyze differences
- Try to implement specs with JC API
General problems
- file system is not supporting
- secure messaging
- access control as define for the projects
- file status
Subclassing of Files and File System
- missing information about
- access control objects
- file status
- local security status
- add by overwriting access methods
- SM checks
- access checks
- file status checks
Command Set
- Create/Delete file is missing
- add to subclass of FS
- no requirement to Base Class, since different in each implementation
- commands modifying the file status missing
- invalidate/rehabilitate
- add to subclass of FS
- seek command missing
- write not used
Unresolved problems
- constructor of FS fixes the number of children
- not according to ISO
- remove parameter from constructor
- access checking needs selection of a file by SFI
- deliver method: SelectBySFI (byte SFI)
- Mapping of SFI to file not specified
- local to DF or global by path
- fixed mapping or dynamic by a changeable translation table
- specify mapping
- implementation of seek needs modified findRecord
- findRecord (byte direction, byte current RecordNumber, byte offsetInRecord, byte[] buffer)
- add this method
- Auth flag not usable
- 8 flags are required
- remove or enhance
- supported functions of commands are not specified
- not all functions are needed for Projects
- ISO specifies profiles
- Implementation: large size of FS classes
Actions to FS
- set up task force to
- select requirements
- define supported functionality in commands
- define mapping for SFI
- propose changes
Cryptography presentation
Cryptography: what can we talk about?
- JavaCard Specifications are in the public domain and as such can be discussed
- Implementation is controlled by US export and discussing implementation issues would need export authorization by US partners
Functional problems
- DES MAC uses decryption
- Standards like ISO 9797, ANSI 9.9 and 9.19 define encryption
- there are security problems by using decryption
- DES_3 MAC using triple DES for each round
- not according to standards
- 24 byte DES_3 not supported by API
Other problems
- Status of G&D proposal
- accepted by JCF
- no response from JavaSoft
- Export regulations
- do not allow the export of JavaCards with this API
- do we really need?
Second part of Cryptography presentation by G&D
Distributed a paper copy of the G&D proposal
Bertrand du Castel's list of issues:
- 16/8/512 discussion
- task force membership
- contents of Rev 2.1
- interoperability in Rev 2.1? Politics?
- File system discussion (requirements)
- Size of file system (partitioning)
- G&D and Hitachi proposal
- Export issues
- byte code verification (where?)
- Hanel & Vetillard to send Web site presentation to du Castel.
JavaSoft: Vendor implementations are not prevented from doing byte code verification inside the card. However, the intent is that a
"signed" applet has had byte code verification done on it.
We'll fold the byte code verification discussion into the file system discussion.
Bertrand will put the export issues
question before the Business Committee to see if the JCF wants to explore export questions as a group rather than individually.
Task force membership: this was set up in response to a
suggestion by Eric Vetillard. The group is limited to one representative from each company. The need is to keep the table small enough to have a good technical discussion. Eric says there's no problem
with adding additional companies if they have someone willing to take on the task.
Cryptography discussion:
Patrice feels that the G&D/Hitachi proposal is very close to the existing API spec. G&D feels that their proposal offers an API
for which it will be easier to obtain export licensing.
From G&D's standpoint, the real concern is being able to export a card with the "cryptography API" on it.
As a process
for further discussion on this, Thomas Frey (G&D) will be the focal point for the discussions on cryptography and export. Anyone interested in this discussion should send a message to him and get
involved in the discussion. If you don't get involved via Thomas, then don't complain later about the results of the effort.
Thomas would like people to send him requirements and then we can use
this as the basis for a further discussion with JavaSoft.
File system discussion:
The "size of the FS class" problem is at a very preliminary state today. In many implementations, the FS class will be
comprised of "dead code" because the individual implementations will overwrite major sections of the FS code.
For further discussion on the File System, Walter Haenel (IBM) will be the
focal point. Follow the same process as indicated above for cryptography.
Interoperability discussion:
Is there any reason to think there are other issues beyond what we've identified in the requirements? Patrice and Eric think we're
"clean" here.
Contents of Rev 2.1:
- This should put the persistence question to rest.
- Have until the end of Feb. for revisions; perhaps cryptography and file system mods could be considered in this time frame.
- What about interoperability?
- Proposal by end of March, at meeting in concert with JavaOne
- So, interoperability may not be included in Rev 2.1. This is a "platform spec" rather than an API, so JavaSoft
will have to consider the relationship of this with respect to the Rev 2.1 Specification.
Bertrand asked Eric to send a summary in two weeks regarding this issue of interoperability and Rev 2.1.
################################################## ############
Joint Business/Technical Committee Session
Review of Business Committee Meeting
1. New possible members (Java Card licensees)
- Motorola
- NatWest
- Oberthur
- etc.
2. Discussion of the process for admitting new members to the JCF.
3. Approved a new definition of the "Observer" status. This will be updated on the Web site. Also, the definition of
Strategic Partner will be included.
4. It would be nice to have a "white paper" on the business domain "neutrality" of the core specification.
Perhaps the Technical Committee can add this as an action item.
5. Agreed that the three founding members would each make available 1/3 of a person worth of resources that can be applied to
general JCF work. Bull will be responsible for charging back this expense to all of the members. It should be in the range of $10K per year per member.
6. Consideration of adding "Transportation" as a new "business segment". Conclusion is that this market segment
is not mature enough to do this.
7. Approved an "official boilerplate text" for communicating JCF activities.
8. Follow-up actions
- establish good dialogue with ETSI (particularly SMG9 subgroup).
- ETSI proposed to do a "requirements" proposal.
- JCF to respond with an API spec.
- ETSI will be invited to officially participate in the JCF activities.
9. Discussion about the maintenance of the standard in the future. Decided that this would be the responsibility of ETSI.
10. Banking industry: we will send them a letter asking them their process to describe their (business segment) requirements. Visa
had indicated that this effort would happen "fairly soon".
11. Expand the participation of the ITSEC business domain Strategic Partners. IBM would like to be invited to participate as an
"ITSEC company".
12. Within a few months, want to make a request to the PC/SC Work group and the OCF group to "register" Java Card service
provider and card agents in these respective architectures.
13. Need to review the GSA specification on smart cards. Need to provide comments to GSA by the end of February.
14. Discussion about the next meeting date and venue. Strategic Partners suggested they would prefer to have meetings involving SPs
to be in Europe.
Next meeting on April 7 & 8 in Paris, hosted by Gemplus.
Technical Committee Wrap-up
1. Goal of the GSM group is to present an initial draft specification supporting GSM 11.11 and GSM 11.14 at the next JCF meeting in
early April.
Members of this working group:
- Augustin (Gemplus) [group leader]
- Borgs (G&D)
- Hild (IBM)
- Christian Dietrich (Schlumberger)
- Vulletic (KeyCorp)
- Lorre (DLR)
2. Financial group
The Strategic Partners of this group will work among themselves to develop a statement of requirements.
3. IT Group
Several new people expressed an interest in participating in this group.
- Vetillard (G+)
- Depinay (DLR)
- Bolignano (Bull)
- Hanel (IBM)
- DiPrizio (Motorola)
4. Include a description (by April) of the architecture for compatibility of "enhanced communcation capabilities" (e.g.
secure messaging) with OCF and PC/SC architecture.
