Ungestiefelte Karte Zertifikate und Smartcards im Preboot-Einsatz zur Festplattenverschlüsselung

Ordnungsmerkmale

erschienen in: <kes> 2005^#4, Seite 11

Rubrik: Management und Wissen

Schlagwort: Festplatten-Verschlüsselung

Zusammenfassung: Mobile Festplatten brauchen besonderen Schutz. Neuerdings kann zertifikatbasierte Verschlüsselung per Smartcard auch bei einer Preboot-Authentifizierung eingesetzt werden. Was es dabei und bei der Einbindung in eine PKI zu beachten gilt, schildert der folgende Artikel.

Autor: Von Arne Jacobsen, Gütersloh

Dass ein Windows-Passwort zum Schutz mobiler Endgeräte unzureichend ist, hat sich wohl mittlerweile herumgesprochen – es kann über Boot- oder Diagnose-CDs leicht umgangen werden. Einen wirklichen Schutz gegen unbefugtes Lesen bieten im Verlustfall nur Lösungen zur Verschlüsselung der Daten. Um chiffrierte Daten stark abzusichern und die Systeme managbar zu halten, setzen vor allem File- und Container-basierte Programme schon länger auch auf Smartcard-Technik und Public-Key-Infrastrukturen (PKIs). Die Nutzung von Zertifikaten und Smartcards zur Authentifizierung von Benutzern bei so genannten Preboot-Authentication-Systemen (PBA) ist indes ein neuer Trend, den mittlerweile viele namhafte Hersteller verfolgen.

Der Vorteil von PBA-Lösungen ist die stetige Verschlüsselung der gesamten Festplatte, sodass alle Daten wirksam geschützt sind – unabhängig vom gewählten Speicherort. Dateibasierte Chiffriersysteme oder so genannte Container-Lösungen, die ein virtuelles Laufwerk mit verschlüsselten Daten in einer einzelnen Datei anlegen, eignen sich hingegen nur bedingt, um beim Verlust eines Endgeräts den Zugriff von Dritten zu verhindern: Letztlich erfordern solche Lösungen die Mitwirkung des Anwenders – speichert dieser Dateien nicht in dem zu verschlüsselten Laufwerk (Container) beziehungsweise Ordner, so liegen diese Daten weiterhin im Klartext auf der Festplatte vor. Zudem sollte auch sichergestellt sein, dass Auslagerungsdateien ebenfalls verschlüsselt abgelegt werden.

Preboot-Verschlüsselung im System-Kontext

Dies lässt sich sicher erreichen, indem bereits vor dem Start des eigentlichen Betriebssystems eine Authentifizierung an einem Preboot-System stattfinden muss. Schlägt diese fehl, so bleiben bei PBA die Daten auf der Festplatte verschlüsselt – ein Umgehen des im System vorhandenen Betriebssystems führt also für einen Angreifer nicht zum Erfolg.

Der Treiber zur Ver- und Entschlüsselung (im Bsp. SafeBoot) sitzt "zwischen" Betriebssystem und Festplattensteuerung.

Nach dem Booten des Betriebssystems laden PBA-Systeme eine Filtersoftware, die "über" dem Festplattentreiber liegt. Damit werden in der Folge jegliche Daten, die auf die Festplatte geschrieben werden, automatisch verschlüsselt und alle Daten, die in den Arbeitsspeicher gelesen werden, automatisch entschlüsselt. Die Sicherung läuft für den Benutzer völlig transparent ab. Alle gespeicherten Daten bleiben auf der Festplatte ohne Zutun des Benutzers zu jedem Zeitpunkt verschlüsselt. Lediglich die Daten im Arbeitsspeicher liegen im Klartext vor und können entsprechend den Benutzerberechtigungen genutzt werden.

Zur eigentlichen Verschlüsselung der Daten nutzen praktisch alle Systeme symmetrische Krypto-Algorithmen, da diese von der Performance her eindeutige Vorteile bieten. Als "State of the Art" gilt hierbei zurzeit der Advanced Encryption Standard (AES) mit einer Schlüssellänge von 256 Bit.

Starke Authentifizierung

Die Authentifizierung am PBA-System kann im einfachsten Fall über ein statisches Passwort erfolgen, aus dem die Software – meist über eine Hash-Funktion – einen symmetrischen Key generiert, mit dem der eigentliche Festplatten-Schlüssel chiffriert ist. Dieses Verfahren ist sehr gängig und wird auch heute noch in den meisten Fällen angewendet.

Probleme statischer Passworte sind jedoch, dass diese erraten, durchprobiert (Brute Force) oder ausgespäht werden können. Höhere Sicherheit bietet eine so genannte zwei-Faktor-Authentifizierung, die das eindimensionale Passwort durch zwei unabhängige Anmelde-Faktoren ersetzt. In der Praxis hat sich hierfür die Kombination "Wissen und Besitz" bewährt und durchgesetzt. In diesem Fall benötigt man zur Anmeldung eine Smartcard oder ein USB-Token (Besitz) sowie eine persönliche Geheimzahl (PIN = Wissen) – alternativ wäre auch eine biometrische Komponente möglich. Kann der Benutzer nicht beide notwendigen Faktoren vorweisen, so schlägt die Authentifizierung fehl.

Angesichts der generell wachsenden Bedeutung von Public-Key-Infrastrukturen und digitalen Zertifikaten als Authentifizierungsmedium sollte heutzutage eine Smartcard (oder ein USB-Token – im Folgenden möge dies implizit immer als Alternative gelten) nicht mehr nur als sicheres Speichermedium für ein statisches Passwort oder einen symmetrischen Schlüssel dienen, sondern Zertifikate beherbergen und auch für den Einsatz zur Verschlüsselung nutzbar machen. Neben der Authentifizierung in den verschiedensten Lösungen, wie beispielsweise Virtual Private Networks (VPNs) oder Webservern, werden Zertifikate auch für elektronische Unterschriften (Signatur) immer wichtiger.

Da Zertifikate mit asymmetrischer Kryptographie (Public Key) arbeiten, kommt bei der Nutzung für die Festplattenverschlüsselung ein Hybridverfahren zum Einsatz: Der letztlich verwendete symmetrische Schlüssel (Machine Key) wird mit dem Public Key des Benutzer(zertifikat)s chiffriert und auf der Festplatte abgelegt – dies kann nun naturgemäß für beliebig viele Anwender oder Administratoren beziehungsweise Zertifikate und Smartcards geschehen. Zur Entschlüsselung und Nutzung des Maschinenschlüssels ist ein "passender" Private Key eines der Zertifikate notwendig, der hochsicher auf der Smartcard abgelegt ist und diese niemals verlässt.

Hauptprotagonisten der Smartcard-Kryptographie sind weiterhin der RSA-Algorithmus oder Verfahren auf der Basis elliptischer Kurven (Elliptic Curve Cryptography, ECC). Hochwertige Karten sind von verschiedenen Herstellern (z. B. Siemens, Giesecke & Devrient, GemPlus oder Datakey) mit unterschiedlichen Smartcard-Betriebssystemen (z. B. CardOS, TCOS, StarCOS) verfügbar – Vergleichbares gilt wiederum für USB-Krypto-Token. Bei der Wahl einer Festplattenverschlüsselung ist darauf zu achten, dass der Anbieter ein möglichst breites Spektrum von Karten oder Token unterstützt, damit die Wahl des Authentifizierungs-Mediums sich an den Bedürfnissen der umgebenden PKI und nicht nur an den Bedürfnissen der Festplattenverschlüsselungs-Lösung ausrichten kann.

Smartcard pre-boot

Die Anbindung von Smartcards und damit Zertifikaten vor dem Start eines Betriebssystems (preboot) ist eine Technik, die Hersteller erst seit kurzem beherrschen. Die Herausforderung, die es hierbei zu lösen galt, war die Kommunikation mit der Karte in einem Preboot-System: Der Zugriff auf eine Smartcard erfolgt über ein Chipkartenterminal, für das nach dem Start der gängigen Betriebssysteme entsprechende Schnittstellen zur Verfügung stehen (PC/SC bzw. CT/API) – Gleiches gilt für die Karten und Zertifikate (z. B. per Cryptography Service Provider – CSP – bzw. PKCS#11). Alle diese Standards setzen jedoch ein 32-Bit-Standard-Betriebssystem wie Linux oder Windows voraus – Preboot-Systeme sind in der Regel jedoch herstellerspezifisch und müssen daher eigene Lösungen mitbringen, um Smartcard-Reader, die Karten und ihre Zertifikate zu integrieren.

Management-Anforderungen

Die Integration einer PBA-Lösung in eine vorhandene Public-Key-Infrastruktur beziehungsweise Smartcard-Lösung erfordert ein zentrales Management. Dieses sollte unbedingt in vorhandene Verzeichnis-Strukturen (Directory) integriert sein, sodass keine redundante Benutzerführung nötig ist, aber dennoch eine Anbindung an das zertifikatverwaltende System existiert. So kann das Directory dem zentralen Management die Benutzer und die zugehörigen Zertifikate mitteilen und es ist später auch einfach möglich, bestimmte Notebooks (oder andere Festplatten) für bestimmte Benutzergruppen oder spezifische Benutzer zu chiffrieren.

In der Praxis setzen sich dabei zunehmend das Windows Active Directory (AD) sowie als Certificate-Authority-Lösung die Windows 2003 CA durch; doch auch Novell NDS findet man noch häufig. Ein zentrales Management der PBA-/Verschlüsselungs-Lösung sollte (mindestens) diese beiden Systeme unterstützen; eine allgemeine LDAP-Schnittstelle sorgt für zusätzliche Möglichkeiten.

Eine weitere wichtige Anforderung – vor allem bei großen Installationen – ist, dass die Ausbringung der Verschlüsselungssoftware auf die Rechner vollständig ferngesteuert erfolgen kann; auch die Zuweisung oder Änderung von Benutzern auf Maschinen sollte ohne lokale Administration möglich sein. Damit jeder zu verschlüsselnde Rechner über eine vorhandene Softwareverteilung mit einem Preboot-System versehen werden kann, ist es wichtig, dass dazu keine benutzerspezifischen Pakete ausgebracht werden müssen. Erst nachdem die Software installiert ist, synchronisiert sich in solchen Systemen die jeweilige Maschine mit dem zentralen Management und bekommt Benutzer und Verschlüsselungszertifikat(e) zugewiesen.

Die Smartcard mit dem entsprechenden geheimen Schlüssel (Private Key) erhält der Benutzer über ein Smartcard-Management-System. Dieses schreibt – sofern der Schlüssel nicht innerhalb der Karte generiert wird – sowohl den geheimen Schlüssel als auch das Zertifikat auf die Smartcard und liefert das Zertifikat an das Directory. Das zentrale PBA-Management sollte hiervon unabhängig und direkt in das entsprechende Directory integriert sein, damit auch hier egal ist, welches Smartcard-Management-System zum Einsatz kommt.

Fault Management

Sollte ein Anwender in der misslichen Lage sein, seine Smartcard verloren oder vergessen zu haben, so ist es wichtig, ihm Möglichkeiten zum Weiterarbeiten zu geben, ohne die Sicherheit des Systems zu gefährden. Da bei Notebooks nicht davon auszugehen ist, dass ein ständiger Netzwerkzugriff besteht, sollte die PBA-Lösung auch eine Möglichkeit zum Offline-Recovery vorsehen.

Ein mögliches Verfahren hierzu basiert auf "Challenge and Response": Hierbei meldet sich der Anwender telefonisch bei seinem Helpdesk und nennt nach erfolgreicher Identifikation einen speziellen – vom System generierten – User Code, woraufhin er einen eindeutigen Recovery Code erhält, der es ihm ermöglicht temporär auf ein statisches Passwort zur Entschlüsselung der Festplatte umzusteigen. Hier kann es sinnvoll sein, wenn die PBA-Lösung auch für eine bestimmte Zeit auf die Nutzung eines statischen Passwort umzuschalten ist, um Szenarien abzudecken, in denen ein Benutzer für längere Zeit nicht die Möglichkeit hat, eine neue Smartcard zu erhalten.

Sollte eine Karte dauerhaft verloren sein, so muss eine Ersatzkarte mit einem neuen Schlüsselpaar ausgestellt werden. Das zentrale PBA-Management muss dann das zugehörige Zertifikat allen Rechnern bekannt machen, auf die der Benutzer berechtigten Zugriff hat. Auch dieser Vorgang sollte unter Einbezug des Verzeichnisdienstes möglichst automatisiert ablaufen: Sobald ein neues Zertifikat für den Benutzer im Directory abgelegt ist, kann das zentrale Management es auf die entsprechenden Maschinen verteilen. Sobald der Benutzer seine neue Smartcard besitzt und seinen Rechner synchronisiert hat, kann er dann mit der neuen Karte weiterarbeiten.

Umgekehrt muss die PBA-Lösung natürlich auch das Sperren von Karten beziehungsweise Zertifikaten über Certificate Revocation Lists (CRLs) – eine Nutzung des Online Certificate Status Protocol (OCSP) ist "preboot" mangels Onlineverbindung nicht möglich.

Fazit

Zertifikate und Smartcards (bzw. USB-Token) sind ein hochsicheres und benutzerfreundliches Medium zur Authentifizierung an Preboot-Authentication-Lösungen. Voraussetzung für ein handhabbares Arbeiten – besonders in großen Installationen – ist, dass sich das PBA-System möglichst umfassend und flexibel in vorhandene Public-Key-Infrastrukturen integrieren und über ein zentrales Management administrieren lässt.

Arne Jacobsen ist Sales Manager der Control Break International GmbH.