Das JavaCard-Betriebssystem Raphael Karte & Bert Nitsche

Übersicht Anforderungen und Eigenschaften eines Chipkarten-Betriebssystems Aktuelle Systeme im Überblick Die JavaCard-Plattform „natives“ Chipkarten - Betriebssystem JCRE JCVM JCAPI Sicherheitsaspekte Ausblick

Chipkarten-Betriebssysteme: Anforderungen u. Eigenschaften Keine Benutzeroberfläche Kein Zugriff auf ext. Speicher Sehr geringer Speicherbedarf (3-30kB) hohe Sicherheit für Programme und Daten Schnelle Ausführung der Kommunikation und kryptograph. Algorithmen gefordert Keine Möglichkeit zur Änderung

Proprietäre Betriebssysteme Keine klare Trennung von Anwendung und OS API ist OS-spezifisch Applikationen oft in Assembler (Übergang zu Hochsprachen) Applikationen i.a. nicht nachladbar Geringe Hardwareanforderungen Hohe Performance Standard-konform (z.B. ISO 7816, EMV)

Offene Plattformen Nutzt VM-Technik In Hochsprache programmierbar Klare Trennung zw. Anwendung und OS plattformunabhängige API In Hochsprache programmierbar Anwendungen nachladbar Höhere Speicheranforderungen Geringere Performance Standard-konform, z.B. ISO 7816, EMV

JavaCard Plattform

Natives Betriebssystem Enthält zeitkritische und hardwarenahe Routinen I/O Manager Übertragungsprotokolle Fehlererkennung und -korrektur Kryptographie – Algorithmen Direkte Hardware und Speicherzugriffe Speichermanagement

JavaCard Runtime Environment Beschreibt Laufzeitverhalten der Plattform Enthält Systemklassen für bestimmte Dienste Applet-Management Auswahl des Applets, Firewall, Object Sharing, Installation Transaktions-Management Verwaltung transienter Objekte und von Channels Kann native methods enthalten Installer JavaCard Virtual Machine (JCVM) JavaCard Application Programming Interface (JCAPI) Sonstige Erweiterungen (z.B. VISA Open Platform API)

Die JavaCard VM Aufgaben: Aufbau: Bytecode ausführen Klassen und Objekte verwalten Verschiedene Anwendungen separieren Abgesicherte Nutzung gemeinsamer Datenbereiche Aufbau:

Möglichkeiten der JCVM Package-Konzept Vererbung Virtuelle Methoden Iterfaces Exceptions Atomare Operationen Datentypen boolean, byte, short Keine Threads Kein Security-Manager Keine Finalize-Methode Keine Datentypen String, char, double, float, long oder mehrdim. Arrays Keine Garbage Collection

Namen für Klassen und Packages JavaVM: Unicode-Strings, die wie Internet-Domainnamen strukturiert sind JCVM: ApplicationIdentifier (AID) RID : 5 Byte, von Registrierungsstelle vergeben PIX: 0-11 Byte, vom Anbieter gewählt

Token-Konzept CAB-File enthält Token als Referenz zu anderen Packages, bzw. für Klassen und Methoden

RuntimeExceptions

Objekttypen Persistente Objekte Transistente Objekte Inhalt bleibt bis zum Löschen des Cardlets erhalten Zugriff atomar Nicht referenzierte Objekte verbleiben im Speicher Transistente Objekte Verlieren bei Stromausfall ihren Inhalt Zugriff nicht atomar Bisher nur Typen boolean, byte, short und Object als TOs realisierbar JCSystem JCSystem.makeTransientShortArray (20, JCSystem JCSystem.CLEAR_ON_.CLEAR_ON_DESELECT);

JavaCard API Core-Packages (1) Object, Throwable, Exception-Klassen java.lang Object, Throwable, Exception-Klassen javacard.framework AID - kapselt den ApplicationIdentifier APDU - Kommunikation mit der Außenwelt Applet - Basisklasse aller Anwendungen JCSystem - Ressourcen-Management OwnerPIN - Authorisation Util - hilfreiche Zusatz-Funktionen

JavaCard API Core-Packages (2) Ein Subset des normalen java.io-Package java.rmi Ein Remote-Interface zur Realisierung von Klassen, deren Methoden durch das CAD aufgerufen werden Javacard.framework.service Ein Interface zur Realisierung von Sicherheits-Mechanismen und Diensten, welche direkt auf APDU-Daten zugreifen

JavaCard API Core-Packages (3) Extension-Package Hashing-Algorithmen javacard.security Hashing-Algorithmen Zufallsgenerator Methoden zum gesicherten Schlüsselaustausch Extension-Package javacardx.crypto Implementation des asymmetrischen RSA-Algorithmus und mehrerer symmetrischer Algorithmen Interface zur Realisierung eigener Krypto-Algorithmen

Sicherheitsaspekte Java JavaCard Keiner Pointer-Arithmetik Feldergrenzen zur Laufzeit überwacht Strikte Typprüfung Überwachte Objektzugriffe JavaCard Firewall Transaktions-Mechanismus Kein direkter Hardware-Zugriff durch Applet ...

Zukünftige Entwicklungen Chipkarte als aktives Element Superchipkarten (mit Display, Folientastatur, eigener Stromversorgung, etc.) Netzanschluss On-the-Fly-Installation von Software-Komponenten Karte als Kleinst-Computer