JavaCard vs MULTOS
Card vs CardJavaCard domine avec plus de 90 % de parts de marché et un modèle de développement basé sur Java, tandis que MULTOS offre une certification EAL plus élevée et un modèle de sécurité post-émission plus strict.
JavaCard vs MULTOS
JavaCard et MULTOS sont les deux principales plateformes de cartes à puce multi-applicatives ouvertes. Toutes deux prennent en charge le chargement et l'exécution de plusieurs applications dans des domaines de sécurité isolés sur une même puce. Elles se disputent le plus directement les scénarios multi-applicatifs à haute sécurité tels que les cartes bancaires, l'identité gouvernementale et les cartes de paiement.
Vue d'ensemble
JavaCard utilise une machine virtuelle à bytecode Java (JCVM) embarquée sur la carte. Les applets sont écrites dans un sous-ensemble de Java, compilées en bytecode, converties en fichiers CAP JavaCard, puis chargées via un canal sécurisé GlobalPlatform. JavaCard est régie par Oracle (spécification) et GlobalPlatform (gestion du cycle de vie). C'est la plateforme multi-applicative dominante dans le monde — la plupart des cartes de paiement EMV, cartes SIM et cartes eID gouvernementales fonctionnent sous JavaCard.
MULTOS (Multi-application Operating System) utilise un exécutif MULTOS et prend en charge plusieurs langages d'application : le MEL (MULTOS Executable Language, un bytecode de bas niveau), et optionnellement le C ou Java via des compilateurs certifiés. MULTOS est régie par MULTOS International. Les applications sont chargées via l'ALU MULTOS (Application Load Unit), signée par l'autorité de certification MULTOS — aucune application ne peut être chargée sans l'autorisation de la CA MULTOS, ce qui offre un contrôle de la chaîne d'approvisionnement plus strict que le modèle de chargement ouvert de GlobalPlatform. MULTOS bénéficie d'une forte adoption dans les programmes de cartes bancaires britanniques et européens.
Différences clés
- Machine virtuelle de la plateforme : bytecode Java / JCVM (JavaCard) vs bytecode MEL / exécutif MULTOS (MULTOS)
- Gouvernance : spécification Oracle + GlobalPlatform (JavaCard) vs MULTOS International (MULTOS)
- Autorisation de chargement des applications : domaine de sécurité GlobalPlatform avec les clés de l'émetteur (JavaCard) vs ALU signée par la CA MULTOS obligatoire (MULTOS)
- Prise en charge des langages : sous-ensemble Java (JavaCard) ; MEL, C, Java-vers-MEL (MULTOS)
- Certification de sécurité : puces JavaCard — CC EAL4 à 6+ ; MULTOS — historiquement axé sur une forte certification CC EAL4-5+
- Parts de marché : JavaCard — dominant mondialement (EMV, SIM, eID) ; MULTOS — fort au Royaume-Uni et dans l'UE bancaire, marginal ailleurs
- Écosystème applicatif : JavaCard — des milliers d'applets certifiées provenant de centaines de fournisseurs ; MULTOS — un écosystème plus restreint mais soigneusement sélectionné
- Isolation multi-applicative : les deux offrent un pare-feu applicatif mis en œuvre matériellement
Cas d'usage
JavaCard est le choix par défaut pour : - Les cartes de paiement EMV (quasiment toutes) - Les cartes SIM/eSIM (l'ETSI impose une plateforme compatible JavaCard) - L'eID gouvernementale et les cartes PIV/CAC - Les cartes de transport nécessitant une interface à contact ou double interface - Tout déploiement nécessitant l'accès au vaste écosystème mondial d'applets JavaCard
MULTOS est privilégiée pour : - Les programmes de cartes bancaires britanniques historiquement standardisés sur MULTOS (programmes historiques de Barclays, HSBC) - Les déploiements bancaires à haute sécurité où l'autorisation d'application par la CA MULTOS constitue un atout de sécurité - Les déploiements privilégiant la performance au niveau MEL (le bytecode MEL s'exécute plus rapidement que le bytecode JCVM pour certaines opérations)
Verdict
JavaCard constitue le choix par défaut sûr pour les nouveaux déploiements, en raison de sa position dominante sur le marché, de son écosystème d'applets plus vaste et de son support d'outils omniprésent. MULTOS offre un véritable avantage de sécurité grâce à son modèle de chargement d'applications contrôlé par une CA, qui empêche le chargement d'applets non autorisées même si les clés du domaine de sécurité de la carte sont compromises. Pour les institutions financières britanniques disposant de programmes MULTOS existants, la continuité est logique. Pour les nouveaux déploiements à l'échelle mondiale, l'ampleur de l'écosystème et la conformité aux normes de JavaCard en font le choix logique, sauf si le modèle de sécurité spécifique de MULTOS répond à un scénario de menace documenté.
Recommendation
JavaCard pour l'ampleur de l'écosystème et la disponibilité des développeurs ; MULTOS pour une sécurité certifiée maximale.
Frequently Asked Questions
JavaCard runs a subset of the Java Virtual Machine on the card, allowing applets written in the Java programming language to be loaded and executed in isolated sandboxes. MULTOS (Multi-application Operating System) uses the MEL (MULTOS Executable Language) — a stack-based virtual machine with formal security proofs — and a mathematically verified application separation model. Both support multi-application smart cards, but MULTOS emphasizes provable security; JavaCard emphasizes developer familiarity.
JavaCard holds a dominant market share in payment cards due to the large pool of Java developers, broad chip vendor support (NXP, Infineon, Samsung, Thales), and GlobalPlatform integration. MULTOS is preferred by some Europay-origin issuers and high-security deployments that value its formal separation proofs and certified execution model. Both platforms are EMVCo-approved for EMV payment applications.
No — JavaCard and MULTOS are distinct operating systems with incompatible virtual machine architectures and bytecode formats. A card ships with one OS pre-installed by the chip manufacturer; a JavaCard applet (.cap file) cannot run on MULTOS, and a MEL application cannot run on JavaCard. Card personalization bureaus must manage separate card body inventory for each OS they support.
MULTOS was designed from the ground up with formal security proofs for application separation and has historically been certified at EAL5+. JavaCard platforms also achieve EAL5+ or EAL6 certifications, but the formal verification is applied to the chip hardware and OS rather than the VM execution model itself. In practice, both platforms meet the security requirements of the most demanding payment and government identity programs.
Each comparison provides a side-by-side analysis covering interface type, chip architecture, security certification, communication protocol, application domains, and cost. Card-vs-card comparisons focus on specific products, while cross-technology comparisons evaluate broader categories like Contact vs Contactless or EMV vs MIFARE.