1 / 57

Java Card Technology Ch03: Overview

Java Card Technology Ch03: Overview. Instructors: Fu-Chiung Cheng ( 鄭福炯 ) Associate Professor Computer Science & Engineering Tatung University. Content. Architecture Overview Java Card Language Subset Java Card Virtual Machine Java Card Installer and off Card Installation Program

moesha
Télécharger la présentation

Java Card Technology Ch03: Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Java Card TechnologyCh03: Overview Instructors: Fu-Chiung Cheng (鄭福炯) Associate Professor Computer Science & Engineering Tatung University

  2. Content • Architecture Overview • Java Card Language Subset • Java Card Virtual Machine • Java Card Installer and off Card Installation Program • Java Card Runtime Environment

  3. Architecture Overview • Java card technology enables programs written in Java to run on smart cards and other resource-constrained devices. • Smart cards represent one of the smallest computing platforms in use. • How to fit Java system into a smart card? (Smart cards have 1K of RAM,16K of EEPROM, 24K of ROM) • Support only a subset of features • apply a split model to implement JVM

  4. Architecture Overview • JCVM (Java Card Virtual Machine) is split into : • Part that runs off-card • Part that runs on-card • Off-card process: • Processing tasks that are not constrained to execute at runtime • Class loading, bytecode verification, resolution and linking, and optimization

  5. Architecture Overview • On-card process: • defines a runtime environment that supports the smart card memory, communication, security and application execution model • Java Card runtime environment conforms to the smart card international standard ISO 7816

  6. Architecture Overview • Java Card Technology contains: • Java Card Virtual Machine (JCVM) Specification: define a subset of the Java Programming language and virtual machine architecture suitable for smart card applications • Java Card Runtime environment (JCRE): describe Java Card runtime behavior, including memory management, applet management and other runtime features • Java Card Application Programming Interface Specification (APIs): describe the set of core and extension Java package and class for programming smart card applications

  7. Java Card Language Subset • Support only a carefully chosen, customized subset of feature of java language • Due to small memory footprint of Java card • Well suited for writing programs for smart card applications • Preserving the object-oriented capabilities • Many advanced smart cards provide a garbage collection mechanism to enable object deletion

  8. Supported Java feature Small primitive data types: boolean, byte, short One-dimensional array Java packages, classes, interfaces, and exceptions Java object-oriented feature: inheritance, virtual methods, overloading and dynamic object creation, access scope, and binding rules The int keyword and 32-bit integer data type support are optional Unsupported Java feature Large primitive data type: long, double, float Characters and strings Multidimensional arrays Dynamic class loading Security manager Thread Object serialization Object cloning Java Card Language Subset

  9. Java Card Virtual Machine • Java card virtual machine(JCVM) is implemented as two separate pieces: • The on card portion of JCVM includes the java bytecode interpreter • The converter is the off-card piece of JCVM which runs on a PC or workstation • The two pieces implement all the VM function and generate some output file like CAP (converted applet) file and export file

  10. Java Card Virtual Machine Converter interpreter Class files CAP file

  11. CAP File and Export File • The converter loads and preprocess the class files and outputs a CAP file • A CAP file contains an executable binary representation of the class in Java package • A CAP file is a JAR file that contains a set of components. • Each component describes an aspect of CAP file content, such as class information, executable bytecode, linking information, verification information and so forth • The CAP file format is optimized for small small footprint by compact data structure and limited indirection.

  12. CAP File and Export File • Export file are not loaded onto smart card and thus are not directly used by interpreter • Export file can be thought of as the header files in C programming language • It contains public API information for an entire package of classes • It defines access scoop, class name, signature of method and fields • It contains linking information used for resolving interpackage references on the card

  13. Java Card Converter • The converter processed one class at a time, the conversion unit of it is a package • The converter takes two input : class files and export files

  14. Java Card Converter • During the conversion, the converter performs tasks that a JVM in a desktop environment would perform at class-loading time: • Verifies that the load images of the java classes are well formed • Checks for Java Card language subset violations • Performs static variables initialization • Optimizes bytecode • Allocates storage and creates VM data structures to represent classes

  15. Java Card interpreter • Java Card interpreter provides runtime support of Java language model and thus allows hardware independence of applet code • Tasks: • Executes byecode instructions and ultimately execute applets • Controls memory allocation and object creation • Plays a crucial role in ensuring runtime security

  16. Java Card Installer and Off-Card Installation Program • The interpreter does not itself load CAP file. • Java card installer is the mechanism to download and install a CAP file • The Java Card installer resides within card. • Java card installer cooperates with an off-card installation program. • The installation program transmits the executable binary in a CAP file to installer via card acceptance (CAD) • Then the JC installer writes the binary into memory of card, links with other class and creates and initializes any data structures that are used

  17. Java Card Installer and Off-Card Installation Program

  18. Java Card Runtime Environment • Java card runtime environment (JCRE) consists of a Java Card system components that run inside a smart card • JCVM, JC APIs, industry-specific extension and JCRE system classes. • JCRE is responsible for (JCRE == JC OS) • Card resource management • Network communication • Applet execution • On-card system and applet security

  19. On-Card System Architecture

  20. On-Card System Architecture • JCVM • executes bytecodes, • controls memory allocation, • manages objects, and • enforces the runtime security • Native methods: • Provide support to the JCVM and system classes • Handle low-level communication protocols, memory management, crytographic support

  21. On-Card System Architecture • System classes • are analogues to an OS core • manage transactions • manage communication between the host applications and Java Card applet • control applet creation, selection and deseletion

  22. On-Card System Architecture • Java Card Application framework classes • define the four core and extension API packages • This framework makes it relatively easy to create an applet. • Applets access JCRE services through framework classes. • Industry-specific extension • Add-on libraries to provide additional services or to refine the security and system model • Example: Open Platform extends the JCRE services to meet financial industries’ specific security needs.

  23. On-Card System Architecture • Installer • Enables the secure downloading of software and applets onto the card after the card is made and issued to the card holder • Cooperates with the off-card installation program • Is an optional JCRE component • Java Card applet • User applications on JC platform • Applets are downloadable

  24. JCRE Lifetime • JCRE is initialized at card initialization time • JCRE initialization is performed only once during the card lifetime • JCRE initialization: • initialize the virtual machine • Create objects for providing JCRE services • Manage applets • Applets installation • JCRE creates applet instance • Applets create objects to store data

  25. CAD Session • CAD Session: • The period from the time the card is inserted into the card acceptance devices (CAD) and is powered up until the time the card is removed from the CAD • During a CAD session, the JCRE operates like a typical smart card (i.e. support APDU I/O communication). See Fig 3.5 on page 38 • APDUs are sent (Command APDUs and Response APDUs)

  26. CAD Session • After a JCRE is reset, the JCRE enters into a loop, waiting for APDU commands from the host • The host sends APDU commands to the Java Card, using the serial communication interface via the card input/output contact point • When a command arrives, the JCRE either selects an applet to run as instructed in the command or forwards the command to the currently selected applet

  27. CAD Session • The selected applet then takes control and processes the APDU command • When finished, the applet sends a response to the host application and surrenders control to the JCRE • This process repeats when the next command arrives.

  28. Java Card Runtime Features • Besides supporting the Java language runtime model, the JCRE supports three additional runtime features • Persistent and transient objects • Atomic operations and transaction • Applet firewall and the sharing mechanisms

  29. Java Card Runtime Features • Persistent and transient objects • By default, Java Card objects are persistent and are created in persistent memory • The space and data of such objects span CAD sessions • For security and performance reasons, applet can create objects in RAM • Such objects are called transient objects • Transient objects contain temporary data that are not persistent across CAD sessions

  30. Java Card Runtime Features • Atomic operations and transaction • JCVM ensures that each write operation to a single field in an object or in a class is atomic • The updated field either gets the new value or is restored to the previous value • JCRE provides transaction APIs • An applet can include several write operations in a transaction • Either all updates in a transaction are complete or none of them proceeds

  31. Java Card Runtime Features • Applet firewall and the sharing mechanisms • The applet firewall isolates applets • Each applet runs within a designated space • The existence and operation of one applet has no effect on the other applets on the card • The applet firewall is enforced by the JCVM as it executes bytecodes • JCVM permits shared data access through secure sharing mechanishms

  32. Java Card APIs • Java Card APIs consist of customized classes for programming smart card applications according to the ISO 7816 models • Java Card APIs contains • 3 Core packages • java.lang • javacard.framework • javacard.security • One extension package • javacardx.crypto

  33. Java Card APIs • Classes are not supported • GUI interfaces • Network I/O • Desktop file system I/O • The reasons: • No display • Different network protocol • Different file system structure

  34. Java.lang Package Table 3.2

  35. Javacard.framework Package • javacard.framework provides framework classes and interfaces for the core functionality of Java Card applet • Import classes: • Applet class: provides a framework for applet execution • APDU class: APDUs are carried by the transmission protocol (Transmission protocol are T=0 or T=1) • JCSystem class: control applet execution, resource management, transaction management and inter-applet object sharing

  36. Javacard.framework Package • Import classes: • PIN class: • Short for personal identification number • provide the common form of password to authenticating card holders

  37. Javacard.security Package • Provides a framework for cryptographic functions • javacard.security • defines a key factory class keyBuilder and various interfaces used in symmetric (DES) and asymmetric (DSA and RSA) algorithms • Supports abstract base classes RandomData, Signature, and MessageDigest

  38. Javacardx.crypto Package • Is an extension package • Contains cryptographic classes and interfaces • Defines the abstract base class Clipher • Support encryption and decryption functions • Does not provide any implementation • There is a coprocessor on smart cards to perform crytographic computation

  39. Java Card Applet • Java Card Applets is not the same as the J2SE Applet • JC applet is a Java program, that adhere to a set of conventions, and can run within the Java Card runtime environment • They can be dynamically downloaded onto the card • Multiple applets can coexist on a single Java card, and an applet can have multiple instances

  40. Package and Applet Naming Convention • Each applet instance is uniquely identified by Application Identifier (AID) • Each Java package is also assigned an AID • ISO 7816 specifies AIDs to be used for unique identification of card application and certain kinds of files Resource Identifier Proprietary Identifier Extension

  41. Package and Applet Naming Convention (cont.) • The AID for a package is constructed by concatenating • the company’s RID • A PIX for that package • ISO controls the assignment of RIDs to companies; each company has a unique RID. • Companies manage assignment of PIXs • The RID in an AID identifies an applet provider

  42. Package and Applet Naming Convention (cont.) • Package AID = • Company’s RID • Package PIX • Applet AID = • Company’s RID (Applet provider’s RID) • Applet PIX

  43. Package and Applet Naming Convention (cont.) • The package AID and the default applet AID for each applet defined in the package • Specified in the CAP file • Supplied to the converter when the CAP file is generated

  44. Applet Development Process

  45. Applet Development Process • Step 1: • A developer writes one or more Java Classes and • compiles the source code with a Java compiler • Produce one or more class files • Step 2: • Applet is run, tested and debugged in a simulation environment • The overall functional aspects of applet are tested

  46. Applet Development Process • Step 3: • Class files are converted to a CAP file • A CAD file and an export file are created for each package • Step 4: • CAP files are loaded and tested in an emulation environment • Runtime behaviors of applet are tested • Applet firewall • Transient and persistent objects

  47. Applet Installation • ROM Applets • Pre-issuance or Post-issuance Applets • Post-issuance Applets Installation • Error Recovery during Applet Installation • Installation Constraints

  48. Applet Installation ` • Masking • The process of writing the permanent components into the non-mutable memory of a chip • When a Java Card is manufactured, the smart card proprietary system and Java Card runtime environment (native methods, JCVM, Framework APIs and libraries) are burned into ROM.

  49. ROM Applets • Applet classes can be masked in ROM together with JCRE and other system components during the process of card manufacturing • Applet instances are instantiated in EEPROM by the JCRE during the JCRE initialization. Such applets are called ROM applets • ROM applet content are controlled by issuers • ROM applet are allowed to declare native methods (not checked by JCVM)

  50. Pre-issuance or Post-issuance Applets • Java Card applet classes and associated class libraries can be downloaded and written into the mutable memory (EEPROM) after the card is manufactured • Pre-issuance and post-issuance are downloaded before or after the card has been issued • Pre-issuance applets are treated the same way as the ROM applets • Post-issuance applets are not allowed to declare native methods (security reason)

More Related