Starke Authentifizierung durch Smart Cards und biometrische Daten

Post date: Jun 6, 2012 5:43:54 AM

In einem JEE Kontext, kann man ein Mappen zwichen dem Smart Card Realm eines JAAS Loginmodul und den JEE Rollen durchführen und dann kann man Zugang auf diese Daten mit dem Subject und deren Liste von Principals erhalten. Durch dieses Verfahren wird die starke Authentifizierung durch Smart Cards und biometrische Daten unterstützt.

Optimale Vorgehensweisen

1) Einheitliches Token (Zeichen) für den physischen und logischen Zugang durch duale Schnittstellen (kontakt und kontaktlose). Gesteigerte Anlagenrendite. Verbesserte Auditierung, Uberwachung, Identitätsmanagement und Authentifizierung.

2) Begrenzung des Herunterladens der Applets nach der Smartcard-Ausgabe.

3) Widerruf des Zugangs durch Reset der PIN.

4) Starke Authentifizierung (PIN = was Du weisst, Zertifikat = was Du besitzt).

Tücken

1) Komplexität der Architektur die von der geografischen Verbreitung abhängig ist. Die Infrastruktur bezüglich Directory Services kann Performance und Skalierbarkeitsprobleme auslösen.

2) Smartcards können verloren, gestohlen oder durch Personifikation widerrufen falls keine biometrische Daten auf der Card gespeichert sind.

Sicherheitsmodell

Eine Untermenge von Java und JVM eingebaute Sicherheitsmechanismen werden in dieser Architektur eingesetzt. Java Applets werden vorzeichenbehaftet mit Hilfe der digitalen Signatur um Ihre Integrität (Vollständigkeit) und Nichtabstreitbarkeit zu gewährleisten. Nur wenn die Uberprüfung der digitalen Signatur erfolgreich ist, darf ein Java Card Applet auf der Card installiert werden. Applet basierten Kontexte die durch Firewall-Partitionierung erstellt wurden isolieren die Ausführung der Applets und wenn explizite Ubertragung der Objekte zwischen Applets notwendig ist dann gibt es eine verteilbare Schnittstelle (Shareable) die benutzt werden kann, um diese Ubertragung zu implementieren.

Cardeigene Funktionen die mit dem Cardsbetriebssystem verbunden sind können nur von Anbietercardapplets aufgerufen werden. Die Cardapplets werden mit Hilfe von komprimmierten Archiven verteilt. Die Instanzen dieser Applets werden mit einem Application ID (AID) identifiziert – gekennzeichnet – und sie laufen solange die Card unter Verwendung (aktiv ist) ist und sie schließen Ihre Ausführung wenn sie deinstalliert werden. Firmeneigene Werkzeuge die von dem Cardanbieter erstellt wurden, werden verwendet um die Installierung der Applets durchzuführen. Diese Applets sind nicht geeignet, in einem Webbrowser zu funktionieren/laufen.

Das Authentifizierungsmodell ist von der Clientplattform abhängig. Web Clients können Smartcard-Authentifizierung durch Browser-Plugin durchführen, PAM/JAAS wird für Unix basierten Clients und GINA DLL Programmbibliothek wird für Windows-basierten Clients verwendet. Die Anmeldedaten (Credentials) wie CUID werden auf der Serverseite in einem Directory Server gespeichert und die Ubertragung der Daten zwischen der Smartcard und diesem Server wird durch das Secure Pipe Entwurfsmuster versichert (hier kann man SSL benutzen).

Auf der Smartcard werden X.509 digitale Zertifikate vorinstalliert zusammen mit einem öffentlichen Schlüssel, einem privaten Schlüssel und Card Unique Identifier (CUID). Standards der Public-Key-Kryptographie wie PKCS #11, #15 werden bei dieser Architektur berücksichtigt. Bei der Einschreibung/Aufnahme der Benutzerdaten wird der Benuzer um eine PIN Nummer gefragt.

Auf der Ebene des Directory Server gibt es ein PKCS#11 compliant Hardwaresicherheitsmodul die die Verbindung mit dem Smartcard Aufnahme/Personalisierungssystem herstellt. Der Smart Card Authentifizierung Server generiert eine Challenge/Herausforderung und benutzt den öffentlichen Schlüssel und das Card Unique Identifier (CUID) um die Zugangsdaten bezüglich der Authentifizierung zu überprüfen.

Funktionsfähiges (Operationales) Modell

SmartCard Aufnahme und Terminierung (Abschluss) wird durch das Löschen des öffentlichen Schlüssel von dem LDAP Server implementiert und der vorläufige Widerruf wird durch den PIN-Reset (Nachstellung) versichert. Die Smart Card Authentifizierung kann durch das Challenge Response Protokoll oder durch Certificate Validation Protocol Responder ausgeführt werden. Durch diesen Ablauf wird der Status von Zertifikaten überprüft und eine Antwort wie „gültig“, „widerrufen“ und „unbekannt“ berechnet.