MULTOS Application Development

MULTOS Application Development

MULTOS (Multi-application Operating System) is a high-security smart card platform developed by Mondex International and now governed by the MULTOS Consortium. Where JavaCard uses a Java Virtual Machine, MULTOS runs native compiled applications in an isolated multi-application environment certified to Common Criteria EAL5+. This makes it the platform of choice for high-assurance deployments including banking, government ID, and transport.

MULTOS Platform Architecture

MULTOS enforces strict application isolation at the hardware level. Each application occupies its own protected memory segment; the OS kernel mediates all inter-application communication and resource access.

┌─────────────────────────────────────────────┐
│  Application 1  │  Application 2  │  App N  │
│  (MEL bytecode) │  (MEL bytecode) │         │
├─────────────────────────────────────────────┤
│         MULTOS Kernel (OS layer)            │
├─────────────────────────────────────────────┤
│    Crypto coprocessor │ Flash │ RAM │ I/O   │
│    ([secure element]) │       │     │       │
└─────────────────────────────────────────────┘

The kernel exposes a rich set of primitive system calls — cryptographic operations, APDU I/O, and memory management — via a standardised API.

MEL — MULTOS Executable Language

MEL (MULTOS Executable Language) is a stack-based bytecode language, similar in concept to Java bytecode but designed explicitly for constrained smart card hardware. Developers write MULTOS applications in C (using a subset of ISO C90) or directly in MEL assembly, then compile with the MULTOS C Compiler (MCC) toolchain.

/* Simple MULTOS C application — echo APDU data */
#include <multos.h>

void main(void) {
    WORD dataLen;

    /* Read APDU command data length */
    dataLen = La;   /* La = available length in Application Data area */

    /* Copy from APDU input to output buffer */
    MultosBlockCopy(dataLen, APPLICATION_DATA, APPLICATION_DATA);

    /* Return SW1SW2 = 9000 (success) */
    ExitSW(0x9000);
}

Key MULTOS C primitives:

Application Loading via KMA

Applications are loaded onto a MULTOS card through the Key Management Authority (KMA) infrastructure — a root-of-trust hierarchy that prevents unauthorised code from running on certified cards.

The load process:

1. Application Certificate (ALCert): Developer submits compiled MEL binary to the MULTOS Consortium; a certificate is issued binding the hash to a developer ID.
2. Application Load Block (ALB): The ALCert is combined with the binary into an ALB — a signed, encrypted package the card's OS verifies before installation.
3. Card-side verification: The MULTOS OS checks the ALB signature against the KMA public key embedded at manufacture, then loads the application into protected memory.
4. Application deletion: Requires a signed Delete Certificate from the developer or card issuer — applications cannot self-delete or be forcibly removed without authorisation.

This chain-of-trust contrasts with JavaCard's GlobalPlatform loading, where the Issuer Security Domain (ISD) controls installation rather than a centralised KMA.

Multi-Application Isolation

Development Toolchain

• MULTOS C Compiler (MCC): Cross-compiles ISO C90 to MEL bytecode.
• MULTOS Simulator: Software emulator for functional testing without hardware.
• MULTOS Developer Portal: Issues development certificates for test cards.
• HeTeSo (MULTOS test suite): Conformance test scripts for MULTOS OS primitives.

Test APDUs using the APDU Builder. To identify a MULTOS card from its ATR, use the ATR Parser — MULTOS cards report a characteristic historical byte sequence.

Security Best Practices

• Minimise public primitives: Only export APDUs that the application genuinely needs.
• Input validation: Check Lc and La bounds before every buffer operation.
• Atomic updates: Use MULTOS transactional write primitives for any multi-field update to prevent torn state if power is interrupted mid-write.
• Cryptographic hygiene: Use on-card key generation (MultosGenerateRSAKeyPair) rather than importing externally generated keys wherever possible.