Java Cards

NXP JCOP 4 Security Target Lite v3.4

2020-07-14 16:04:21 M&W SmartCard 2

Document Information

Info

Content

Keywords

ASE, JCOP, Common Criteria, EAL6 augmented

Abstract

This document contains information to fulfill the requirements of the Common Criteria component ASE for the Evaluation of the JCOP 4 P71 developed and provided by NXP Semiconductors, Business Unit Security & Connectivity, according to the Common Criteria for Information Technology Security Evaluation Version 3.1 at EAL6 augmented

Rev

Date

Description

1.0

2018-11-16

Initial version

1.1

2018-11-19

Changed document status to Final

2.0

2019-01-07

ST-Lite based on ST Rev. 2.1

2.2

2019-02-22

ST-Lite based on ST Rev. 2.2

3.0

2019-03-04

ST-Lite based on ST Rev. 3.0

3.1

2019-03-11

ST-Lite based on ST Rev. 3.1

3.2

2019-03-25

ST-Lite based on ST Rev. 3.2

3.3

2019-05-29

ST-Lite based on ST Rev. 3.3

3.4

2019-06-06

ST-Lite based on ST Rev. 3.4

ST Introduction (ASE_INT)

1.1     ST Reference and TOE Reference

Title

JCOP 4 P71 Security Target Lite for JCOP 4 P71 / SE050

Version

Revision 3.4

Date

2019-06-06

Product Type

Java Card

TOE name

JCOP 4 P71

Certification ID

NSCIB-CC-180212

CC version

Common Criteria for Information Technology Security Evaluation Version 3.1, Revision 5, April 2017 (Part 1 [2], Part 2 [3] and Part 3 [4])

Tab. 1.1: ST Reference and TOE reference

1.2    TOE Overview

The TOE consists of the Micro Controller and a software stack which is stored on the Micro Controller and which can be executed by the Micro Controller. The software stack can be further split into the following components:

•Firmware for booting and low level functionality of the Micro Controller (MC FW) like writing to flash memory. This includes software for implementing cryptographic operations, called Crypto Library.

•Software for implementing a Java Card Virtual Machine [40], a Java Card Runtime Environment [39] and a Java Card Application Programming Interface [38], called JCVM, JCRE and JCAPI.

•Software for implementing content management according to GlobalPlatform [37], called GlobalPlatform (GP) Framework.

•Software for executing native libraries, called Secure Box.

The TOE is also referred to as JCOP 4 P71. The JCOP 4 Operating System (JCOP4 OS) consists of the software stack without the Crypto Library (Crypto Lib) and without the Micro Controller Firmware (MC FW). The TOE uses one or more communication interfaces to communicate with its environment.

The complete TOE is depicted in Figure 1.1. The elements are described in more detail in Section 1.3.

NXP JCOP 4 Security Target Lite v3.4

Fig. 1.1: Components of the TOE

Figure 1.1 shows the components of the TOE. The TOE is a composite product on top of CC certified Hardware, Firmware and Crypto Library. Part of the TOE are the JCVM, JCRE, JCAPI and the GP Framework. Also included is optional functionality and the Secure Box mechanism. The Secure Box Native Librarys provide native functions for untrusted third parties and are not part of the TOE.

The figure shows Java Card applets which are small programs in Java language that can be executed by the TOE, but are not part of the TOE.

1.2.1 Usage and Major Security Features of the TOE

The usage of the TOE is focused on security critical applications in small form factors. One main usage scenario is the use of so called smart cards. Examples of such cards are banking cards or electronic drivers’ licenses. The TOE can also be used in an electronic passport. Another usage scenario is device authentication, where the TOE can be used to prove the authenticity or originality of a device like an accessory for a gaming console.

The TOE provides a variety of security features. The hardware of the Micro Controller already protects against logical and physical attacks by applying various sensors to detect manipulations and by processing data in ways which protect against leakage of data by side channel analysis. With the software stack the TOE provides many cryptographic primitives for encryption and decryption of data but also for signing and signature verification. Also the software stack contains security features to protect against attacks.

The following list contains the features of this TOE:

•4 different communication protocols:

1.ISO 7816 T=1,

2.ISO 7816 T=0,

3.ISO 14443 T=CL,

4.I2C Slave2.

•Cryptographic algorithms and functionality:

1.Data Encryption Standard with 3 keys (3DES) for en-/decryption (CBC and ECB) and MAC generation and verification (Retail-MAC, CMAC and CBC-MAC).

2.Advanced Encryption Standard (AES) for en-/decryption (CBC, ECB and counter mode) and MAC generation and verification (CMAC, CBC-MAC).

3.Rivest Shamir Adleman asymmetric algorithm (RSA) and RSA CRT for en-/decryption and signature generation and verification.

4.RSA and RSA Chinese Remainder Theorem (CRT) key generation1.

5.Elliptic Curve Cryptography (ECC) over GF(p) for signature generation and verification (ECDSA)1.

6.ECC over GF(p) key generation1.

7.Random number generation according to class DRG.3 or DRG.4 of AIS 20 [41].

8.Diffie-Hellman with ECDH and modular exponentiation1.

9.SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 hash algorithm.

1Optional functionality

2Only for Configuration Secure Authentication, see Chapter 1.3.1.3.2

10.Following cryptographic algorithms are part of the TOE but without claims for security functional re-quirements:

(a)KoreanSEED1,

(b)AES in Counter with CBC-MAC mode (AES CCM)1 2,

(c)Keyed-Hash Message Authentication Code (HMAC)1 2,

(d)HMAC based Key Derivation Function (HKDF) [32] 1 2,

(e)Elliptic Curve Direct Anonymous Attestation (ECDAA) [27] 1 2,

(f)Elliptic curve cryptography based on Edwards and Montgomery curves1 2,

•Java Card functionality:

1.Executing the Java byte codes which are generated from the Java compiler when Java source code is compiled.

2.Managing memory allocation of code and data of applets.

3.Enforcing access rules between applets and the JCRE.

4.Mapping of Java method calls to native implementations of e.g. cryptographic operation.

5.Support for Extended Length APDUs.

6.Garbage Collection with memory reclamation and compaction.

7.Persistent Memory Management and Transaction Mechanism.

•GlobalPlatform functionality:

1.Loading of Java packages.

2.Instantiating applet instances.

3.Removing of Java packages.

4.Removing of applet instances.

5.Issuer Security Domain (ISD), Supplementary Security Domain (SSD).

6.Creating SSDs.

7.Associating applets to Security Domains.

8.Installation of keys.

9.Verification of signatures of signed applets.

10.Verification of signatures for commands.

11.CVM Management (Global PIN).

1Optional functionality

2Only for Configuration Secure Authentication, see Chapter 1.3.1.3.2

12.Secure Channel Protocol (SCP01, SCP02 andSCP03).

13.Delegated Management, Data Authentication Pattern (DAP).

14.Post-issuance installation and deletion of applets and packages.

15.Compliance to several GP configurations.

•NXP Proprietary Functionality

1.Proprietary secure messaging accelerator interface for applets which are used for electronic passport as defined by ICAO or electronic driver license1.

2.Secure Box1.

3.Java Card API for data encryption via PUF [22].

1.2.2 TOE Type

The TOE is a Java Card with a GP Framework. It can be used to load and execute off-card verified Java Card applets.

1.2.3Required non-TOE Hardware/Software/Firmware

Three groups of users shall be distinguished here.

The first group is the end-users group, which uses the TOE with one or more loaded applets in the final form factor like a banking card or an electronic passport. These users only require a communication device to be able to communicate with the TOE. The communication protocol of the TOE is standardized in either ISO7816 [31] (T=1, T=0), ISO14443 [10] (T=CL), or UM10204 [28] (I2C Slave, only for Configuration Secure Authentication).

The second group of users are administrators of cards. They want to configure the card by using the Configu-ration Module, to install additional applets and to configure and personalise these applets. These users require the same equipment as end-users.

The third group of users wants to develop Java Card applets and execute them on the TOE. These applet devel-opers need in addition to the communication device a set of tools for the development of applets. This set of toolscan be obtained from the TOE vendor and comprises elements such as PC development environment, byte code verifier, compiler, linker and debugger.

1.3   TOE Description

1.3.1 TOE Components and Composite Certification

The certification of this TOE is a composite certification. The following sections provide a more detailed description of the components of Figure 1.1.It is also made clear whether a component is covered by a previous certification or whether it is covered in the certification of this TOE.

1Optional functionality

1.3.1.1 Micro Controller

The Micro Controller is a secure smart card controller from NXP’s SmartMX3 family. The Micro Controller contains a co-processor for symmetric cryptographic operations, supporting DES and AES, as well as an accelerator for asymmetric cryptographic algorithms. The Micro Controller further contains a physical random number generator. The supported memory technologies are volatile (Random Access Memory (RAM)) and non-volatile (Read Only Memory (ROM) and FLASH) memory.

Access to all memory types is controlled by a Memory Management Unit (MMU) which allows to separate and restrict access to parts of the memory.

The Micro Controller has been certified in a previous certification and the results are re-used for this certification. The exact reference to the previous certification is given in the following Table 1.2:

Name

NXP Secure Smart Card Controller N7121 with IC Dedi cated Software and Crypto Library

Certification ID

BSI-DSZ-CC-1040

Reference

[20]

Tab. 1.2: Reference to Certified Micro Controller

1.3.1.2 Security IC Dedicated Software

1.3.1.2.1   MC FW (Micro Controller Firmware)

The Micro Controller Firmware is used for testing of the Micro Controller at production, for booting of the Micro Controller after power-up or after reset, for configuration of communication devices and for writing data to volatile and non-volatile memory.

The MC FW has been certified together with the Micro Controller and the same references ([20]) as given for the Micro Controller also apply for the MC FW.

1.3.1.2.2   Crypto Library

The Crypto Library provides implementations for symmetric and asymmetric cryptographic operations, hashing, the generation of hybrid deterministic and hybrid physical random numbers and further tools like secure copy and compare. Some of the cryptographic algorithms offered by the Crypto Lib are not certified, see 1.3.1.4.

The symmetric cryptographic operations comprise the algorithms 3DES, AES and KoreanSEED. These algorithms use the symmetric co-processor of the Micro Controller.

The supported asymmetric cryptographic operations are ECC and RSA. These algorithms use the Public Key Crypto Coprocessor (PKCC) of the Micro Controller for the cryptographic operations.

The Crypto Library has been certified together with the Micro Controller and the same references ([20])as given for the Micro Controller also apply.

1.3.1.3Security IC Embedded Software

1.3.1.3.1   JCOP 4 P71

JCOP 4 OS consists of JCVM, JCRE, JCAPI and GP framework. It is implemented according to the Java Card Specification and GlobalPlatform version listed below. Additionally it consists of a proprietary API, which is de-scribed in the UGM [14], [15].

JCVM, JCRE, and JCAPI version implemented in the TOE

Version 3.0.5 Classic [40] [39] [38]

Tab. 1.3: Java Card Specification Version

GP Framework version implemented in the TOE

Version 2.3 [37]

Amendment D, Secure Channel Protocol ’03’

Version 1.1.1 [36]

Tab. 1.4: GlobalPlatform Version

The JCOP 4 OS component can be identified by using the IDENTIFY APDU command (see UGM [14], [15]). This command returns the card identification data, which includes a Platform ID, a Patch ID and other information that allows to identify the content in ROM, FLASH and loaded patches (if any). The Platform ID is a data string that allows to identify the JCOP 4 OS component.

The TOE also includes a Configuration Module (see 1.3.2) which is used for personalisation and configuration of the TOE. It must be deleted after the personalisation is finished (end of Phase 6 ”Personalisation”) by using the DELETE APDU command. Once the Configuration Module is deleted, it is no longer possible to configure the TOE.

The TOE contains further functionality for integrity protection of user data via an EDC, for counting detected attacks by an attack counter, going into a mode of restricted functionality in case too many attacks have been detected, encryption of user data via PUF [22] and optional functionality as described in 1.3.2.

1.3.1.3.2   TOE Configurations

The TOE is available in two configurations, of which the first configuration has two versions:

Configuration

JCOP version

User manual

Configuration Banking & Secure ID

JCOP 4

P71 v4.7 R1.00.4, JCOP 4 P71 v4.7 R1.01.4

[14]

Configuration Secure Authentication

JCOP 4

SE050 v4.7 R2.00.11

[15]

Tab. 1.5: JCOP configurations and versions

All three versions offer the same common functionality. The version of Configuration Secure Authentication offers additional functionality for I2C Slave protocol, timer functionality, and following cryptographic algorithms:AES CCM, HMAC, HKDF, ECDAA, elliptic curve cryptography based on Edwards and Montgomery curves. Config-uration Secure Authentication does not implement the Mifare host interface, therefore the Security Functional Requirements of EMG group are not applicable for this configuration.

All three versions are covered by this Security Target, they can be differentiated by the response data of the IDENTIFY command (see UGM [14], [15]).

1.3.1.4 Excluded functionality

All Secure Box Native Libraries are not not part of the TOE. No security functional requirements are claimed on KoreanSEED, AES CCM, HMAC, HKDF, ECDAA, elliptic curve cryptography based on Edwards and Montgomery curvesand FIPS self-tests, they are TSF non-interfering.

1.3.2 Optional TOE Functionality

Some dedicated functionality of the TOE can be removed in order to free up memory.

Following functionality is optional:

•RSA key generation,

•Elliptic curve cryptographic functionality,

•Accelerator for integrated mapping of the PACE protocol,

•Korean Seed cryptographic functionality,

•eGov accelerators,

•TOE self-tests according to FIPS 140-2 [8],

•PIV secure messaging as defined by NIST.SP800-73-4 [18],

•SecureBox,

•TOE Configuration Module: The TOE Configuration Module has to be deleted at the end of life cycle phase 6 [14], [15],

•AES CCM as defined in the Java Card AEADCipher API [38], HMAC and HKDF cryptographic functionality as defined in the Java Card API [38] and the UGM [14], [15]. Timer functionality as defined in the UGM [14], [15]. This functionality is available only in Configuration Secure Authentication of the TOE.

•ECDAA [27] and elliptic curve cryptography based on Edwards and Montgomery curves. This functionality is available only in Configuration Secure Authentication of the TOE.

•I2C slave protocol and T = 1 over I2C. This functionality is available only in Configuration Secure Authenti-cation of the TOE.

1.3.3TOE Life Cycle

The life cycle for this Java Card is based on the general smart card life cycle defined in the Java Card Protection

Profile - Open Configuration [13], see Figure 1.2.

NXP JCOP 4 Security Target Lite v3.4

Fig. 1.2: TOE Life Cycle within Product Life Cycle




Phase

Name

Description

1

Security IC Embedded Software Development


The Security IC Embedded Software Developer is in charge of

• SmartCard embedded software development including the development of Java Card applets and

• specification of IC pre-personalization requirements, though the actual data for IC pre-personalization come from phase 4, 5, or 6.




2

Security IC Development

The IC Developer



• designs the IC,

• develops Security IC Dedicated Software,

• provides information, software or tools to the Security IC Embedded Software Developer, and

• receives the embedded software from the developer, through trusted delivery and verification procedures.

From the IC design, Security IC Dedicated Software and SmartCard Embedded Software, the IC Developer

• constructs the SmartCard IC database, necessary for the IC photomask fabrication.




3

Security IC Manufacturing

The IC Manufacturer is responsible for



• producing the IC through three main steps: IC manufactur-ing, IC testing, and IC pre-personalization.

The IC Mask Manufacturer

• generates the masks for the IC manufacturing based upon an output from the SmartCard IC database. Configuration items may be changed.




4

Security IC Packaging

The IC Packaging Manufacturer is responsible for



• IC packaging and testing.

5

Composite Product Integration

The Composite Product Manufacturer is responsible for



• SmartCard product finishing process including applet load-ing and testing. Configuration items may be changed by using the Configuration Module.




6

Personalization

The Personalizer is responsible for



• SmartCard (including applet) personalization and final tests. User Applets may be loaded onto the chip at the personalization process and configuration items may be changed by using the Configuration Module, which must be deleted at the end of this cycle by using the DELETE APDU command.




7

Operational Usage

The Consumer of Composite Product is responsible for



• SmartCard product delivery to the SmartCard end-user, and the end of life process.

• applets may be loaded onto the chip.

Tab. 1.6: Life-cycle

The evaluation process is limited to phases 1 to 5. User Applet development is outside the scope of this evalua-tion. Applets can be loaded into FLASH in phases 3, 4, 5, and 6. Applet loading in phase 7 is also allowed. This means post-issuance loading of applets can be done for a certified TOE.

The Configuration Module is loaded into FLASH and has special privileges to personalize and configure the TOE. Before life cycle Phase 7 "Operational Use" the Configuration Module is deleted and hence it is ensured that its functionality cannot be used after wards. It is possible to load patch code into FLASH in phases 3, 4, 5, and 6. The certification is only valid for the ROM code having the Platform Identifiers and the Patch IDs (if applicable) as stated in Table 1.7.

The delivery process from NXP to their customers (to phase 4 or phase 5 of the life cycle) guarantees, that the customer is aware of the exact versions of the different parts of the TOE as outlined above.

TOE documentation is delivered in electronic form (encrypted according to defined mailing procedures).

Note: Phases 1 to 3 are under the TOE developer scope of control. Therefore, the objectives for the environment related to phase 1 to 3 are covered by Assurance measures, which are materialized by documents and procedures evaluated through the TOE evaluation process.

During phases 4 to 7 the TOE is no more under the developer control. In this environment, the TOE protects itself with its own Security functions. But some additional usage procedures must also be followed in order to ensure that the TOE is correctly and securely handled, and not damaged or comprised. This ST assumes (A.USE_ DIAG, A.USE_KEYS)that users handle securely the TOE and related Objectives for the environment are defined(OE.USE_DIAG, OE.USE_KEYS).

1.3.4 TOE Identification

1.3.4.1 TOE Delivery

The delivery comprises the following items:

Type

Name

Version

Form of delivery

Hardware

NXP Secure Smart Card Controller N7121 with IC Dedicated Software and Crypto Library


Micro Controller includingon-chip software: Firmware and Crypto Lib1


JCOP 4 OS

ROM Code (Platform ID)

see UGM

On-chip software2:

JCOP 4 OS


FLASH content (FLASH ID)

([14], [15])

Patch Code (Patch ID)


Document

User Guidance and Administration Manual [14],

[15]


Electronic document3


Document


HW Objective Data Sheet [19] (Configuration Banking & Secure ID)

Electronic document3


Document

HW Objective Data Sheet [23] (Configuration Secure Authentication)

Electronic document3


Tab. 1.7: Delivery Items

1.3.4.2 TOE Identification

The TOE can be identified by using the Platform ID, the FLASH ID and the Patch ID. The IDENTIFY command and the identification output for this TOE are described in detail in the UGM ([14], [15]). The IDENTIFY command also returns information about presence of optional functionality and allows to identify the TOE Configuration.

JCOP 4 P71 v4.7 R1.00.4, JCOP 4 P71 v4.7 R1.01.4 and JCOP 4 SE050 v4.7 R2.00.11 are friendly names for

1The TOE is delivered as wafer or module. The TOE can be collected at NXP site or is being shipped to the customer. See [14], [15] for details.

2included in the Micro Controller

3via NXP DocStore [21]

the TOE which are unique amongst all JCOP variants at NXP.

1.3.5 Evaluated Package Types

A number of package types are supported for this TOE. All package types, which are covered by the certification of the used hardware (see [20]), are also allowed to be used in combination with each product of this TOE.

The package types do not influence the security functionality of the TOE. They only define which pads are con-nected in the package and for what purpose and in which environment the chip can be used. Note that the security of the TOE is not dependent on which pad is connected or not - the connections just define how the product can be used. If the TOE is delivered as wafer the customer can choose the connection on his own.

9    Contents

1 ST Introduction (ASE_INT)

1.1 ST Reference and TOE Reference

1.2 TOE Overview


1.2.1 Usage and Major Security Features of the TOE

1.2.2 TOE Type

1.2.3 Required non-TOE Hardware/Software/Firmware

1.3 TOE Description


1.3.1 TOE Components and Composite Certi fication

1.3.2 Optional TOE Functionality

1.3.3 TOE Life Cycle

1.3.4 TOE Identification

1.3.5 Evaluated Package Types


2 Conformance Claims (ASE_CCL)


2.1 CC Conformance Claim

2.2 Package Claim

2.3 PP Claim

2.4 Conformance Claim Rationale


2.4.1 TOE Type

2.4.2 SPD Statement

2.4.3 Security Objectives Statement

2.4.4 Security Functional Requirements State ment

3 Security Aspects


3.1 Confidentiality

3.2 Integrity

3.3 Unauthorized Executions

3.4 Bytecode Verification

3.5 Card Management

3.6 Services

3.7 External Memory

3.8 Configuration Module

3.9 Modular Design

3.10 Restricted Mode

4 Security Problem Definition (ASE_SPD)


4.1 Assets


4.1.1 User Data

4.1.2 TSF Data

4.2 Threats


4.2.1 Confidentiality

4.2.2 Integrity

4.2.3 Identity Usurpation

4.2.4 Unauthorized Execution

4.2.5 Denial of Service

4.2.6 Card Management

4.2.7 Services

4.2.8 Miscellaneous

4.2.9 Operating System

4.2.10 Random Numbers

4.2.11 Configuration Module

4.2.12 Secure Box

4.2.13 Module replacement

4.2.14 Restricted Mode

4.3 Organisational Security Policies

4.4 Assumptions

5 Security Objectives


5.1 Security Objectives for the TOE


5.1.1 Identification

5.1.2 Execution

5.1.3 Services

5.1.4 Object Deletion

5.1.5 Applet Management

5.1.6 External Memory

5.1.7 Card Management

5.1.8 Smart Card Platform

5.1.9 Secure Box

5.1.10 Random Numbers

5.1.11 Configuration Module

5.1.12 Restricted Mode

5.2 Security Objectives for the Operational Environment

5.3 Security Objectives Rationale


5.3.1 Threats

5.3.2 Organisational Security Policies

5.3.3 Assumptions


6 Extended Components Definition (ASE_ECD)


6.1 Definition of Family ”Audit Data Storage (FAU_SAS)”

6.2 Definition of Family ”TOE emanation (FPT_EMSEC)”

7 Security Requirements (ASE_REQ)


7.1 Definitions


7.1.1 Groups

7.1.2 Subjects

7.1.3 Objects

7.1.4 Informations

7.1.5 Security Attributes

7.1.6 Operations

7.2 Security Functional Requirements


7.2.1 COREG_LC Security Functional Requirements

7.2.2 INSTG Security Functional Requirements

7.2.3 ADELG Security Functional Requirements

7.2.4 RMIG Security Functional Requirements

7.2.5 ODELG Security Functional Requirements

7.2.6 CarG Security Functional Requirements .

7.2.7 EMG Security Functional Requirements .

7.2.8 ConfG Security Functional Requirements

7.2.9 SecBoxG Security Functional Requirements

7.2.10 ModDesG Security Functional Requirements

7.2.11 RMG Security Functional Requirements .

7.2.12 Further Security Functional Requirements

7.3 Security Assurance Requirements

7.4 Security Requirements Rationale for the TOE


7.4.1 Identification

7.4.2 Execution

7.4.3 Services

7.4.4 Object Deletion

7.4.5 Applet Management

7.4.6 External Memory

7.4.7 Card Management

7.4.8 Smart Card Platform

7.4.9 Random Numbers

7.4.10 Configuration Module

7.4.11 Secure Box

7.4.12 Restricted Mode

7.5 SFR Dependencies


7.5.1 Rationale for Exclusion of Dependencies


7.6 Security Assurance Requirements Rationale

8 TOE summary specification (ASE_TSS)


8.1 Introduction

8.2 Security Functionality

8.3 Protection against Interference and Logical Tampering

8.4 Protection against Bypass of Security Related Actions

9 Contents

10 Glossary

11 Acronyms

12 Bibliography

13 Legal information


13.1 Definitions

13.2 Disclaimers

13.3 Licenses

13.4 Patents

13.5 Trademarks

Java Card is an open standard from Sun Microsystems for a smart card developmentplatform. Smart cards created using the Java Card platform have Java applets stored on them. The applets can be added to or changed after the card is issued.

There are two basic types of smart cards. The memory smart card is the familiar removable memory device; it usually features read and write capabilities and perhaps security features. The more complex version, the processor smart card, is a very small and extremely portable computing device that could be carried in your wallet. Java-based smart cards belong to the latter category. They store data on an integrated microprocessor chip. Applets are loaded into the memory of the microprocessor and run by the Java Virtual Machine. Similarly to MULTOS, another smart card development technology, Java Card enables multiple application programs to be installed and coexist independently. Individual applets are protected by a firewall to preserve their integrity and prevent tampering. Applications can be updated dynamically.

In the United States, the Department of Defense, Visa, and American Express are among the organizations creating Java Card-based applications.


Home
Product
News
Contact us