JavaCard-kontrollierter, sicherer Zugriff auf persönliche Dokumente und Berechtigungen

JavaCard-kontrollierter, sicherer Zugriff auf pers ¨onliche Dokumente und Berechtigungen

Konzept, Implementierung und Leistungsmessung – Extended Abstract Clemens H. Cap Nico Maibaum Lars Heyden

Heinz Nixdorf Stiftungslehrstuhl¹f¨ur

Informations und Kommunikationsdienste, Universit¨at Rostock {cap, maibaum, heyden}@informatik.uni-rostock.de

1 Einleitung

Smartcards werden zunehmend fester Bestandteil unseres Lebens. Sie sind typischerweise Prozes- sorkarten mit pers ¨onlichen Informationen ¨uber den Inhaber, digitaler Signaturfunktion und Platz f¨ur weitere Anwendungen. Das Laden von Kartenapplikationen erfolgt vor der Auslieferung, sp¨ateres Nachladen kann erm¨oglicht werden. In vielen Anwendungen entsteht die Frage nach der Speiche- rung elektronischer Dokumente. Papierbasierte Dokumente kann jeder B¨urger einfach nach Hause tragen und in einem Aktenordner aufbewahren. Mit elektronischen Dokumenten ist dieses nicht m¨oglich. Allein der Platzbedarf f¨ur signierte und verschl¨usselte Personaldokumente im eGovern- ment ¨uberschreitet den auf Chipkarten f¨ur Dokumente verf¨ugbaren Speicherplatz von rund 16 KB.

Eine Auslagerung auf andere Speichermedien (z.B. CD-Rom mit kleinerem Format, optische Spei- cherkarte, Floppy, USB-Flash-Dongle) erweist sich aufgrund des relativ raschen Wechsels einge- setzter Technologien als wenig sinnvoll. Ein virtuelles Speicherkonzept, bei dem eine Referenz auf einem tragbaren Kleinstger¨at – hier einer Smartcard – auf ein Archiv im Netz verweist, eignet sich besser, wirft aber massive Sicherheitsfragen auf.

Ergebnis ist ein serverbasiertes sicheres Archiv elektronischer Dokumente. Eine Java-basierte Smart- card kontrolliert den Zugriff, kryptographische Funktionen garantieren Vertraulichkeit und Authen- tizit¨at, gemeinsam mit einer Vertragsbedingung ist die Verf¨ugbarkeit sichergestellt. Die Program- mierschnittstelle l¨aßt dieses Archiv wie eine transparente, kryptographisch abgesicherte, virtuelle Speichererweiterung der JavaCard aussehen. Dank der Secure Card Extension (SCE) haben auf der JavaCard scheinbar auch gr¨oßere pers ¨onliche Dokumente und Berechtigungsnachweise Platz.

Anwendung: Eine prototypische Implementierung ist im Rahmen des EU Projekts FASME zur Speicherung von eGovernment-Dokumenten eingesetzt [CMH01], [MCH⁺01]. Dieses Papier er- reicht eine weitere Reduktion im Speicherbedarf durch Hash-Ketten und Akkumulator-Funktionen und stellt die Leistungsf¨ahigkeit des Konzepts dar.

2 Konzept

Komponenten der Secure Card Extension (SCE) sind die Anwendung, der Client, die JavaCard und der Server. Aufgrund ihrer Hardware betrachten wir die JavaCard als sicher und vertrauen ihr den privaten Schl¨ussel des Benutzers an. Der Client ist ein mobiles Endger¨at des Benutzers (Organi- zer, PDA oder CDA (Citizen Digital Assistant, siehe [MSC02]) und stellt die Benuterschnittstelle zur Anwendung dar. Wir erachten den Client und die Anwendung als sicher im Sinne spezifikati-

1Unterst¨utzt durch die Heinz-Nixdorf Stiftung, das F¨unfte Rahmenprogramm der EU, Projekt FASME, IST- 1999-10882 und die Firma Unagon GmbH, Rostock.

433

onstreuer Funktionsweise, vertrauen ihnen aber nicht private Schl¨ussel an. Der Server ist ein nicht vertrauensw¨urdiger Datei-Dienst eines kommerziellen Anbieters. Er kann ¨uber eine Netzwerkver- bindung erreicht werden, die mit SSL abgesichert werden kann. Dieser Server steht zur Speicherung der Dokumente bereit.

Die SCE stellt die folgenden Funktionen bereit: Erstellung und Verwaltung der Credentials, mit denen der Anwender nachweisen kann, daß er ein bestimmtes Dokument dem Server zur Aufbe- wahrung gegeben hat. Sicherung der Integrit¨at gegen Manipulation durch den Server. Sicherung der Vertraulichkeit gegen Unbefugte, insbesondere den speichernden Server.

Die Speicherung der Dokumente auf einem mobilen Endger¨at ist m¨oglich, aber wenig sinnvoll: Bei Verlust des Endger¨ats sind auch die Dokumente verloren. Das Endger¨at ist reines Zugangsger¨at und kann von mehreren Benutzern verwendet werden. Die Smartcard bzw. SIM Card ist als Personali- sierungsmodul “Tr¨ager” der “Identit¨at” des Anwenders.

Die Credentials bewirken Nicht-Abstreitbarkeit; gemeinsam mit einer Vertragsbedingung sichern sie die Verf¨ugbarkeit der Dokumente: Verweigert der Server die Herausgabe zur Speicherung ¨ubergebe- ner Dokumente, so kann der Benutzer mit den Credentials eine Vertragsverletzung nachweisen und Schadensersatz fordern. Geeignete, nicht zu stark einschr¨ankende Randbedingungen erlauben die Speicherung der Credentials beliebig vieler Dokumente in konstantem Speicher. Die Schnittstelle zur SCE spiegelt der Anwendung ein sicheres, virtuelles Dateisystem auf der JavaCard vor.

Grundidee: Hash-Ketten. Will die Anwendung ein Dokument auf (dem SCE) der Karte ablegen, so sendet sie das DokumentDan die Karte. Diese bestimmt den Hashwertr=f(D)und verbindet die- sen mit dem auf der Karte gespeicherten Masterhashmzu einem neuen Masterhashm⁰=f(r·m).

Die SCE sendet das Dokument an den Server, der ebenso den Hashwertf(D)bestimmt und in sei- nen MasterhashM⁰ = f(r·M)einrechnet. Waren die Masterhash-Werte von Karte und Server vorher gleich (m=M) so sind sie es auch nachher. Karte und Server ¨uberpr¨ufen dieses und ver- sichern sich durch Signaturen auf den Masterhash-Werten vom neuen Stand. Verweigert der Server sp¨ater die Herausgabe eines Dokuments, so kann der Benutzer mit dem vom Server signierten Ma- sterhash vom Server eine Darlegung verlangen, wie sich der signierte Masterhash insgesamt ergeben hat. Dieser war aus einem StartwertM₀durch schrittweises Hinzuf¨ugen von Dokumentenhashs ent- standen, etwa nach Speicherung dreier DokumenteM₃=f(f(D₃)·f(f(D₂)·f(f(D₁)·M₀))).

Aufgrund von Komplexit¨atseigenschaften kann der ServerM₃nur erhalten haben, wenn er Kenntnis von den DokumentenD₁, D₂, D₃hatte. Er muß diese Dokumente herausgeben oder Vertragsstrafe zahlen.

Verbesserung: Zur Sicherung von Vertraulichkeit und Integrit¨at wird das Dokument verschl¨usselt und eine sichere Verbindung zwischen dem Dokument und seinem Namen geschaffen (sonst k¨onnte der Server die Anfrage nach dem F¨uhrerschein mit der Geburtsurkunde beantworten). K¨onnen Do- kumente unter demselben Namen mehrere Versionen haben, so muß die Karte pr¨ufen k¨onnen, ob der Server die korrekte Version geliefert hat. Diese Pr¨ufung soll die Karte im “Routinebetrieb” von sich aus durchf¨uhren k¨onnen – die zeitraubende Offenlegung der gesamten Hash-Kette soll dem Ausnah- mefall vorbehalten bleiben, in dem die Karte eine Unregelm¨aßigkeit festgestellt hat oder der Server behauptet, ein Dokument nicht gespeichert zu haben. Ebenfalls muß aus den Masterhash-Werten, die im Laufe der Zeit anfallen, der aktuelle feststellbar sein. Dazu erforderliche Details werden in einer separaten Publikation dargestellt.

Erweiterung: Sicherer Akkumulator. Verlangt der Benutzer die Offenlegung der Hash-Kette, so hat der Server die seit Vertragsbeginn gespeicherten Dokumente vorzulegen, und so die Hashwer- te nachzuweisen. Veraltete Versionen k¨onnen nicht entfernt oder gel¨oscht werden. Die Erweiterung der Hash-Funktion zur Akkumulatorfunktion bietet Abhilfe. Ein sicherer Akkumulator [BdM93], [San00] als quasikommutative Einweg-Hashfunktiona(x, y)mith(h(x, y₁), y₂) =h(h(x, y₂), y₁).

434

Damit spielt die Reihenfolge, in der Dokumenten-Hashwerte zu einem Masterhash gef¨ugt werden, keine Rolle. Besteht ein Masterhash aus drei Dokumenten-Hashs:M₃ = h(h(h(M₀, r₁), r₂), r₃) so kann durchM₃ =h(h(h(M₀, r₁), r₃), r₂)der Hashwert eines “inneren” DokumentsD₂ nach außen bewegt werden. Will die Karte das DokumentD₂l¨oschen, so beauftragt sie den Server, den WertZ =h(h(M₀, r₁), r₃)der verbleibenden Dokumente zu bestimmen. Da der Server alle Doku- mente besitzt, kann er diesen Wert berechnen. Die Karte kann den Wert nicht berechnen, aber ¨uber h(Z, r₂) =M₃pr¨ufen. Abschließend einigen sich Karte und Server auf den neuen MasterhashZ und der Server kannD₂l¨oschen.

3 Implementierung

Die SCE ist vollst¨andig Java-basiert und besteht aus Client, Karte und Server, die ¨uber standardisierte Protokolle und APIs miteinander gekoppelt sind.

Client: Auf dem Client-Rechner befindet sich der SCE-Client und die Anwendung des Kartenin- habers, ¨uber die er seine Dokumente verwaltet. Der SCE-Client ist f¨ur die Anwendung die Schnitt- stelle zur SCE. Er wurde unter J2SE 1.4 entwickelt. F¨ur die Kommunikation mit der Smart Card kommt das “OpenCard Framework” (OCF) zum Einsatz. F¨ur ein Kartenleseger¨at wird entweder ein OCF-Treiber oder ein PC/SC-Treiber ben¨otigt. F¨ur die Kommunikation mit dem Server wird RMI-IIOP verwendet. Zus¨atzlich kann die Verbindung mit SSL gesichert werden, wobei dann ein Client-Zertifikat notwendig ist.

Die Kartenanwendung wurde f¨ur eine JavaCard nach Version 2.1.1 geschrieben. Sie ist aufgeteilt in Kommunikationsteil, API-Teil und Speicherteil. Der Kommunikationsteil ¨ubernimmt den Empfang der Command APDUs und den Versand der Response APDUs. Der API-Teil enth¨alt die zentralen SCE-Funktionen sowie Hash- und Verschl¨usselungsoperationen.

Der Server wurde nach der J2EE 1.3 Spezifikation implementiert. Die Server-Objekte sind f¨ur Container Managed Persistence konfiguriert. Die Datenbank-Anfragen sind als EJB-QL-Abfragen in Deployment Descriptoren spezifiziert. F¨ur kryptographische Funktionen wurde BouncyCastle (www.bouncycastle.org) eingebunden, da J2SE und J2EE keine RSA-Verschl¨usselung bereit- stellen. Als J2EE-Server wurde die Referenzimplementierung von Sun mit der Datenbank Clouds- cape verwendet.

4 Leistungsanalyse

Es wurde die JavaCard “Smart Cafe 1.12, Crypt” von Giesecke & Devrient und die J2EE-Referenz- implementierung von Sun auf einem Pentium 3, 600 MHz, 256 Mb RAM eingesetzt. Der Kartenleser war seriell unter 9600 Baud angebunden. Bei den Spr¨ungen im Graphen in Abb. 1 ¨uberschreitet ein Dokument eine Blockgr¨oße und eine weitere APDU muß zur Karte gesendet werden. Die Anzahl der Bytes, die pro APDU gesendet werden k¨onnen, ist auf 255 beschr¨ankt. Sowohl die ¨Ubertragungsge- schwindigkeit zum Kartenleser als auch die eingesetzte J2EE-Datenbank stellen Referenzszenarien dar. Bei beiden Komponenten ist Raum f¨ur Optimierung.

5 Anwendung und Ausblick

Eine Variante der Architektur ist im eGovernment Projekt FASME zur Speicherung administrativer Dokumente auf einer JavaCard eingesetzt. Die FASME Card, eine JavaCard mit SCE Speichererwei- terung, tritt gegen¨uber den eGovernment Anwendungen als Archiv aller Dokumente des B¨urgers auf.

Der Zugriff kann nur mit Einverst¨andnis des Karteninhabers erfolgen, das durch biometrische Ver- fahren gesichert wird. Im Rahmen der weiteren Entwicklung im eGovernment und mit der Umset- zung der EU-Richtlinie f¨ur digitale Signaturen werden mehr Dokumente nur elektronisch vorliegen.

Private Emails ¨uber Drittanbieter sind heute selbstverst¨andlich. Es ist aber fraglich, ob Anwender

435

Performanztest

0 5 10 15 20 25 30 35 40 45

160 320 480 640 800 960 1120 1280 1440 1600 1760 1920 2080 2240 2400 2560 2720 2880

Dokumentengröße (Bytes)

benötigteZeit(Sek)

Store Store

Load

Dokumenten Store/Load Leistung

0 2 4 6 8 10 12 14

5 40 75 110 145 180 215 250 285 320 355 390 425 460 495 530 565 600

Dokumentengröße [Byte]

benötigteZeit(Sek)

avgCardStore

avgServerStore avgCardLoad

avgServerLoad

Abbildung 1: Leistungsmessung der SCE Architektur.

auch mit der Speicherung von Geburtsurkunden, F¨uhrerscheinen etc. bei diesen Anbietern einver- standen sind. Nicht ganz zuverl¨assiges Gesch¨aftsgebaren – im Internet keine Seltenheit – k¨onnte zum Verlust von Personaldokumenten f¨uhren. Die L¨osung ist f¨ur Personaldokumente, Ausweise und Zeugnisse (1 - 10 kB) geeignet. Bei gr¨osseren Dokumenten dauert die Kommunikation zur Karte relativ lange. Hier hilft ein hybrides Verfahren, bei dem die SCE symmetrische Schl¨ussel verwaltet und die kryptographischen Operationen auf dem Client (PDA) ausgef¨uhrt werden.

Literaturverzeichnis

[BdM93] J. Benaloh and M. de Mare. One-Way Accumulators: A Decentralized Alternative to Digital Signatures. In EUROCRYPT93, number 765 in LNCS. Springer, 1993.

[CMH01] C. H. Cap, N. Maibaum, and L. Heyden. Extending the Data Storage Capabilities of a Java-based Smartcard. In 6th IEEE Symp. on Comp. and Comm. (ISCC), 2001.

[MCH⁺01] N. Maibaum, C. H. Cap, L. Heyden, R. Riedl, and A. Ostveen. Final Report on the Prototype of the Complete JavaCard Middleware. Deliverable to the IST Programme of the European Commission Research Project FASME, IST-1999-10882, 2001.

[MSC02] N. Maibaum, I. Sedov, and C. H. Cap. A Citizen Digital Assistant for e-Government.

In EGOV: eGovernment – State of the Art and Perspectives. Springer LNCS, 2002.

[San00] T. Sander. Efficient accumulators without trapdoor. In 2nd Int. Conf. on Information and Communication Security (ICICS), pages 252–262, 2000.

Danksagung: Wir verdanken die Idee zur Erweiterung einer Smartcard mit virtuellen Speicherkon- zepten einer Anregung von F. MATTERN.

436