The MPCOS range
The GPK range
Like all smartcards and contrary to memory cards the MPCOS card's memory cannot be accessed directly. All requests for reading or writing must go through and authorized by the CPU of the card.
MPCOS-EMV cards are compliant to the standard ISO 7816-1/2/3/4, and its OS (Multi-application Payment Chip Operating System) is capable of implementing EMV (Europay/Mastercard/Visa) compatible electronic purse solutions.
The cards of the MPCOS range use a 112 bit 3DES algorithm for symmetric cryptography. The keys used for encoding/decoding are both stored int he smartcard and the terminal used. The keys are stored using security modules. In case of functions where the security of the transaction is important, authentication takes place before the termination, when one and of the transaction (a card, terminal, etc.) checks whether or not the other end belongs to the same system. To fulfill this both devices must share the same 3DES key, if they don't the transaction fails and cannot be carried out.
Files can be accessed on various levels: they can be unprotected, protected by PIN, or 3DES key, or both. Files protected by a 32bit cone (PIN) cannot be accessed without the input of the right code, and this code remains valid until a certain duration, ended by a reset function or the removal of the card. In MPCOS several secret codes of different type can be stored.
The main characteristic of the MPCOS-EMV cards is that they were especially designed for to work with financial transactions, defined by demands of leading credit card companies. In the card several independent electronic purses can be stored, each containing the actual balance of the purse. Thus in the purse the amount is physically present, after necessary authentication the balance can be read, can be used for credit or debit functions. The access to electronic purses is protected by the highest security level, credit and debit functions are protected by 3DES keys.
Java cards - GemXpresso range
In cases where the distribution of keys can not be carried out easily (in systems using symmetric keys both the cards and the accepting terminals must share must know the same DES keys), it is more advantageous to use asyimmetric (public) keys. For electronic messaging through the Internet and commertial transactions a commitee led by Visa and Mastercard developed the SET (Secure Electronic Transaction)
Standard, which was announced in 1st June 1997.
GPK (Gemplus Public Key) 16000 is the first public key smart card to combine digital signature, on-board key generation, and electronic payment with multi-application functionality.
The GPK16000 smart card, with its advanced cryptographic co-processor, can be used to secure Internet, Intranet and Extranet transactions in such applications as electronic commerce and computer security. GPK16000 features full cryptographic functionality, including 1024-bit RSA-based digital signature at sub-second speed and 4 Kbytes of application memory.
Additionally, it provides an on-board key generation mechanism that ensures that the private component of the public key that performs the cardholder's digital signature is never seen outside the card. GPK16000 keys, whether generated internally or loaded by the issuer, can be certified by any certification authority through the card's ability to store industry-standard X.509 certificates in the card's memory. The card has also been specifically designed to strengthen the security of Web sites that rely on the SSL3 protocol for mutual authentication of client and Web server. The card complies to the standards ISO 7816-1/2/3/4 capable of using RSA, DSA/DDS, DES 3DES, MD5 and SHA1 algorithms, and fully EMV compatibile.
The Java-based smart card is not a traditional smart card. Instead of containing a fixed application or set of applications, it contains a basic operating system on which applications can be securely loads and executed.
Smart cards represent one of the smallest computing platforms in use today. The memory configuration of a smart card might have on the order of 1K of RAM, 16K of EEPROM, and 24 K of ROM. The greatest challenge of Java Card technology design is to fit Java system software in a smart card while conserving enough space for applications. The solution is to support only a subset of the features of the Java language and to apply a split model to implement the Java virtual machine.
The Java Card virtual machine is split into two part: one that runs off-card and the other that runs on-card. Many processing tasks that are not constrained to execute at runtime, such as class loading, byte code verification, resolution and linking, and optimization, are dedicated to the virtual machine that is running off-card where resources are usually not a concern.
Smart cards differ from desktop computers is several ways. In addition to providing Java language support, Java Card technology defines a runtime environment that supports the smart card memory, communication, security and application execution model. The Java Card runtime environment conforms to the smart card international standard ISO 7816.
The most significant feature of the Java Card runtime environment is that it provides a clear separation between the smart card system and the applications. The runtime environment encapsulates the underlying complexity and details of the smart card system. Applications request system services and resources through a well-defined high-level programming interface.
Therefore, Java Card technology essentially defines a platform on which applications written in the Java programming language can run in smart cards and other memory-constrained devices. (Applications written for the Java Card platform are referred to as applets.) Because of the split virtual machine architecture, this platform is distributed between the smart card and desktop environment in both space and time. It consists of three parts, each defined in a specification.
The Java-based smart card is dynamic by design. Both the card and loaded applets are modifiable before or after the card issuance. Card functionalities are dependant on the life circle state of the card. The Java-based smart card and applets loaded into the card can exist in different states, depending on their phases of development and activities.
Cards pass through several stages: from the Card Manufacturer to the end user via the card issuer, or optionally, an Application Provider. At each stage the cards have differing security permissions, related to the operations allowed by the card.