FAQ Categories

FAQs under 'Technical'

← Back to all FAQs

What is the difference between MULTOS, the MULTOS Scheme, the MULTOS Consortium and MAOSCO?

These four terms are often used interchangeably, but they do each have a distinct role to play; MULTOS is the highly secure, multi-application operating system designed specifically for Smart cards (the only commercially available O/S to have been so). It is loaded onto cards during the silicon manufacture, and is protected throughout the whole process by digital keys, ensuring that at no time can the security of the card be compromised.

The MULTOS Scheme is the name given to the infrastructure surrounding manufacture, personalisation and management of MULTOS cards. At the core of the MULTOS Scheme is the Key Management Authority; the trusted third party that controls the card Issuer keys and digital certificates. The scheme is often referred to as “Issuer-centric”, the Card Issuer has sole control of what gets loaded and deleted into their card.

The MULTOS Consortium is a group of globally based, industry-wide companies, whose remit is to develop, manage and promote MULTOS and the MULTOS product specifications. The members may be business competitors, but all share the common goal of propagating MULTOS, and so work together to this end.

The MULTOS Consortium is managed by MAOSCO Ltd.; a Secretariat, charged with managing the MULTOS Specification development, Type Approval of new MULTOS products, and promoting MULTOS and the Consortium members worldwide. MAOSCO will organise speaking events, trade show attendance and Consortium forums for members to make use of to push their own area of MULTOS expertise.

What is the difference between MULTOS and Step/one?

MULTOS and MULTOS Step/one are essentially the same product; both are built based on the same MULTOS Specifications. However, there are some fundamental differences.

  • Step/one was developed specifically for financial issuers who are migrating to EMV with Static Data Authentication (SDA), and is lower-cost, non-RSA capable version of “Full” MULTOS.
  • Instead of using a central KMA, the cryptographic services for step/one are handled by an issuer-controlled software called Control Centre and are based around symmetric cryptography (Triple DES) rather than asymmetric (RSA).
  • step/one applications are fully compatible with “Full” MULTOS, and the loading/deleting of these applications is handled in exactly the same way in both versions.

Aside from RSA cryptographic support, the same security principles are followed for MULTOS step/one as for “Full” MULTOS.

Where can I get a MULTOS card?

MULTOS and MAOSCO do not issue cards. Many card issuing organisations worldwide use the MULTOS Operating System on their cards as the high security platform on which to offer their particular services. Examples of these may be Credit or Debit in the case of a Financial institution, an ID programme in the case of a government, or Driver’s license in the case of a Department of Transport.

What are the main differences between Javacard and MULTOS?

These are some of the main differences between Javacard and MULTOS:-

Security architecture

  • is built in to MULTOS, for Javacard it is provided by GlobalPlatform
  • uses asymmetric keys for MULTOS vs symmetric for Javacard/GP
  • uses a firewall to separate applications on card vs. off-card verification methods for Javacard
  • Applications / data loaded onto cards via secure packets for MULTOS vs a secure channel for Javacard/GP

Type approval

MULTOS has a mandatory type approval process – provides confidence in the security and interoperability of MULTOS implementations. Testing is performed by independent 3rd party laboratories. Commercially this means that applications can be deployed on MULTOS platforms from multiple suppliers.

Generic loading

Once you have a script for loading applications to MULTOS (whatever the machine or device), it does not need to be changed for each implementation or application.

Application Personalisation

Application perso is usually done off-line, in advance with MULTOS as opposed to at perso time on the perso machine.

Can I write applications in Java?

Yes, but is is more usual to write applications in ‘C’ as there is more support and resulting applications tend to be smaller and faster. The Java environment is used mostly for porting applications originally written for Javacard to MULTOS.

Is MULTOS Global Platform compliant?

MULTOS forms part of the GP specifications and implementations of this GP specification for MULTOS have been done. As for compliance, testing a MULTOS implementation of GP should be similar to testing a Javacard implementation of GP.

What languages can I write MULTOS applications in?

There are three options for writing MULTOS applications:-

  • A native assembly language called MEL
  • C (the most commonly used)
  • Java

Why is MULTOS secure?

There are many factors contributing to the overall security of MULTOS. Here are the main ones.

Firstly, the MULTOS Type Approval Policy ensures that only secure chips are used for MULTOS implementations and that all implementations are subject to a security evaluation. See the policy for details.

The operating system then implements an on-chip firewall that prevents one application from trying to access or modify the code or data of another application on the chip.

The key scheme used for loading applications and their data uses:-

  • Application Load Certificates (ALCs) to ensure the integrity and authenticity of applications and gives an issuer control over what applications can be loaded. ALCs are created at the issuer’s request by a Key Management Authority (KMA) and chips verify the authenticity of ALCs on loading using the KMA’s public key.
  • a unique asymmetric key pair per chip to secure data packets to be sent to the card. Certified copies (provided by the KMA) of the chip public keys are used during data preparation or personalisation to create a unique encrypted packet for each chip which only the chip with the matching private key can read.

What are the differences between Codelets and Romlets?

Codelets are a way to place commonly-used code into ROM or EEPROM so a single copy of the code can be shared by many applications. Because ROM uses much less die area than EEPROM, it’s a good way of squeezing bigger programs into the small space of a smart card. It also means that personalised ALU size can be greatly reduced (speeding up application loading) as the majority of the code portion is already in ROM.

Romlets are selectable applications (with an AID) contained completely in ROM. They have full access to Public and the stack but only read-only access to Static data (used for fixed application and personalised data). In practice Romlets are rarely used.

Is MULTOS FIPS140-2 compliant?

All FIPS 140-2 certifications are for complete products; hardware +  firmware (O/S) +  software + particular configurations thereof.

Ref [FIPS 140-2] 4.1 “A cryptographic module shall be a set of hardware, software, firmware, or some combination thereof that implements cryptographic functions or processes, including cryptographic algorithms and, optionally, key generation, and is contained within a defined cryptographic boundary.”

MULTOS implementations can provide the hardware and O/S parts of such products and as relevant variants are already Common Criteria certified, it is a good choice for products wishing to achieve FIPS140-2 certification.