Wo ist der Schlüssel, eine Analyse über Schlüsselablage, Schlüsselgenerierung, Schutzmethoden

Schatz, wo liegt der Schlüssel?

In diesem Beitrag wird erklärt, wo Software-Verschlüsselung in ZIP, PDF, S/MIME, BitLocker, EFS, TrueCrypt/VeraCrypt die Schlüssel speichert. Zusätzlich gehe ich auf weitere kryptographische Software ein: PKI und Smartcards, Linux sshd, putty SSH und Webserver https/SSL Schlüssel.Die primären Aspekte in dem Beitrag ist (1) die Schlüsselablage, (2) wie sichere Schlüssel erzeugt werden und (3) wie diese geschützt sind.

ZIP Verschlüsselung

7Zip: ZIP 2.0 (ZipCrypto) und AES256 Verschlüsselung
7Zip: ZIP 2.0 (ZipCrypto) und AES256 Verschlüsselung

Trotz unterschiedlicher ZIP Software-Anbieter werden nur zwei Verschlüsselungsmethoden unterstützt: Zip 2.0 (bei 7-Zip “ZipCrypto” genannt) und AES-Verschlüsselung mit der Stärke 128-Bit, 192-Bit und 256-Bit. Bei Zip 2.0 wird aus dem eingegebenen Passwort ein 40-Bit Schlüssel errechnet und der Dateninhalt mit diesem Key kodiert, wobei der AES-Verschlüsselung die gewünschte Keylänge von 128/192/256-Bit aus dem eingegebenen Passwort und einem Zufallswert (“Salt”) pro Datei in 1000 Durchläufen errechnet wird. Beide Methoden verschlüsseln nur den Dateninhalt, nicht die Dateiattribute wie Dateinamen, Dateigröße, Erstellungsdatum.

Leider sind beide Methoden durch Brute-Force angreifbar, da eine ZIP Datei beliebig oft dupliziert werden kann und auf tausenden Systemen gleichzeitig nach dem verwendeten Passwort gesucht werden kann. Der Schwachpunkt der Lösung ist primär das Passwort, jedoch durch die “SureZip” Angriffsmethode auch direkt der 40-Bit Verschlüsselungsschlüssel von Zip 2.0. ZIP unterstützt keinen Recovery-Schlüssel. Durch die quelloffene Implementierung der Algorithmen sehe ich wenig Gefahr für eine versteckte Kompromittierungsmethode oder Backdoor.

Meine Empfehlung ist die AES-Verschlüsselung mit einem starken Password (13 Zeichen oder mehr) zu nutzen und das starke Passwort an einem sicheren Ort zu verwahren.

PDF Verschlüsselung

Bei PDF gibt es eine lange Historie der Verschlüsselung, die bis zur Acrobat Version 4.0 und PDF-Version 1.3 aus dem Jahr 1999 zurückreicht.  Mit Version 6.0 wurde im Jahr 2003 eine 128-Bit-RC4 kurze Zeit später mit Version 7.0 und PDF-Version 1.6 die AES-128 Verschlüsselung angeboten, wobei fünf Jahre später 2010 mit Acrobat X auch AES-256 hinzu kam.

Es gibt zwei unterschiedliche Passworte. Das “Benutzerkennwort” zum Öffnen eines Dokumentes und das “Berechtigungskennwort”, um die Einstellungen wie Drucken-Erlauben, Bearbeiten, Kopieren und weitere einzuschränken.

Die Erstellung von verschlüsselten PDFs ist der kostenpflichtigen Software Adobe Acrobat vorbehalten und kann mit dem Adobe Reader nicht erstellt werden. Auch bei dem PDFCreator ist die Verschlüsselung erst nach einer Lizenzierung eines Moduls um 20€ möglich. Kostenfrei – jedoch nur mit AES-128 – kann jedoch der PDF24 Creator genutzt werden, der folgende Einstellmerkmale bietet:

PDF Verschlüsselungsoptionen von PDF24 Creator
PDF Verschlüsselungsoptionen von PDF24 Creator
PDF Sicherheit

Auch die PDF-Verschlüsselung ist per Brute-Force-Angriff angreifbar. Je schwächer die Passworte, desto kürzer ist die Zeit des Errechnens. Der RC4 oder AES-Verschlüsselungsschlüssel selbst wird bei jeder Dokumentnutzung aus dem Passwort und mehreren, dokumentenspezifischen Teilen (“Salts”) errechnet und nicht im Dokument gespeichert. Bei den Berechtigungen verlässt sich Adobe auf den jeweiligen PDF-Viewer, dieser muss die Berechtigungseinschränkungen in der Software umsetzen. Nach kurzer Recherche konnte ich mehrere Tools finden, die Beschränkungen per Knopfdruck aufheben können.

Da es eine Vielzahl von PDF-Libraries unterschiedlicher Hersteller gibt, gehe ich davon aus, dass es auch bei der PDF-Verschlüsselung keine Backdoor gibt. Ein Recovery-Key ist auch nicht vorgesehen und implementiert. Die Geheimdienste nutzen jedoch sicherlich genügend Rechenpower, um zeichenbasierte Passworte in wenigen Sekunden zu knacken. Für die geschäftliche Nutzung sehe ich PDF-Verschlüsselung mit AES-128 oder AES-256 und einem starken Passwort (>8 Zeichen) als ausreichend.

E-Mail Verschlüsselung per S/MIME Schlüssel

Bei der Nutzung von E-Mail-Verschlüsselung nach dem S/MIME Standard wird der gesamte E-Mail-Body in einem Hybridverfahren in einen PKCS#7 Container als Mime-Typ .p7m verschlüsselt. Hierzu wird zuerst ein symmetrischer 3DES oder AES Schlüssel von dem sendenden E-Mail-Client erzeugt und die E-Mail-Nachricht (der Body) mit diesem Schlüssel verschlüsselt.  Dann wird ein PKCS#7 Header erzeugt in dem dieser symmetrische Schlüssel über die asymmetrischen, öffentlichen S/MIME-Schlüssel aller E-Mail-Empfänger kodiert ablegt wird. Nur der Besitzer eines privaten S/MIME Schlüssels für den verschlüsselt wurde kann die Nachricht entschlüsseln.

Ein S/MIME-Schlüssel ist i.d.R. ein RSA 1024-Bit oder 2048-Bit Schlüssel – zukünftig vermehrt auch ECC-Schlüssel – und kann als .pfx (=.p12) Datei genutzt werden. Im Falle von Outlook wird der Microsoft Zertifikatsspeicher benutzt.  Beide Methoden unterstützen ein starkes Passwort für den privaten S/MIME Schlüssel. Sofern man der Microsoft Kryptographie traut, ist dies eine sichere Methode. Alternativ können RSA- und ECC-Schlüssel auch auf kommerziellen Smartcards gespeichert werden, die den Schlüssel mit einem Hardware-Crypto-Chip und einer Smartcard-PIN schützen.

Schlüsselschutz und -stärke
Outlook symmetrische Verschlüsselung Auswahlliste RC2 + 3DES + AES
Outlook symmetrische Verschlüsselung Auswahlliste RC2 + 3DES + AES

Bei der S/MIME-Verschlüsselung wird kryptographisch zumeist über den Benutzer-S/MIME-Schlüssel gesprochen. Die größere Gefahr für die vertraulichen E-Mails sehe ich aber beim symmetrischen Schlüssel, mit dem der Nachrichten-Inhalt tatsächlich verschlüsselt ist. In der Einstellung der meisten E-Mail-Clients eine Voreinstellung von 3DES, die einer Schlüssellänge von 112-Bit entspricht. Dies entspricht heute nicht mehr dem aktuellen Stand der Technik. Des Weiteren wird der RC2 / 3DES / AES Schlüssel von dem E-Mail-Client ohne besondere Benutzerinteraktion erzeugt. Wenn ein Geheimdienst S/MIME verschlüsselte Nachrichten mitlesen möchte, dann wäre ein Backdoor in dieser Schlüsselerzeugung der einfachste Weg…

Self-Signed Zertifikat oder Trust-Center Zertifikat?

Mit einigen Tools wie openssl kann man sich sein S/MIME Zertifikat und Schlüssel selbst erstellen. Dies ist zwar sicher aber nicht praktikabel. Selbsterstellte (self-signed) Zertifikate werden von Kommunikationspartnern als unsicher eingestuft und erscheinen Warnmeldungen im Mail-Client des Empfängers.

Vertrauensvoller ist die Nutzung von gekauften Zertifikaten eines Trust-Centers wie die österreichische A-Trust, die deutsche D-Trust oder die schweizerische QuoVadis oder SwissSign. Bei der Nutzung von Trust-Center Zertifikaten gibt es unterschiedliche Beantragungsprozesse. Bitte beachte, dass du unbedingt einen Certificate-Signing-Request (CSR) erstellt, den du vom Trust-Center unterschreiben lässt und als Zertifikat zurückerhältst. In diesem Fall verlässt der private Schlüssel niemals deinen PC. Die Alternative ist, dass das Trust-Center das Schlüsselpaar ausstellt und den öffentlichen Schlüssel in dem Zertifikat unterschreibt. In diesem Fall hat das Trust-Center ggfls. auch Kopien deines privaten Schlüssels, dass ich als äußerst kritisch betrachte.

S/MIME Einschätzung

Eine Brute-Force-Attacke gegen einen sicher erzeugten RSA 2048-Bit Schlüssel gehe ich als ausgeschlossen, sofern dem Angreifer die passwortgeschützte .pfx Schlüsseldatei nicht zur Verfügung steht. Zum Testen und für dir bekannte Kontakt kannst du auch ein S/MIME Zertifikat entsprechend meines How-To Artikels “S/MIME Zertifikat mit OpenSSL erstellen” generieren.

Der BitLocker Schlüssel

Im Gegensatz zur Verschlüsselung von einzelnen PDFs oder einzelnen E-Mail-Nachrichten verschlüsselt BitLocker die Windows Startpartition und optional auch weitere Datenpartitionen. Hierzu ist der elementare Zugangsschlüssel der Full-Volume-Encryption-Key (FVEK), der pro verschlüsselter Partition erstellt und sicher gespeichert wird.

Wie kann man aber einen solch wichtigen Verschlüsselungsschlüssel sicher speichern? Der FVEK liegt in den BitLocker Metadaten innerhalb der verschlüsselten Partition. Eine BitLocker verschlüsselte Partition hat eine eindeutige Erkennung über den Text “-FVE-FS-” in den ersten Bytes der Partition und neben anderen Informationen auch drei Zeiger auf die BitLocker Metadaten. Innerhalb dieser drei Kopien der Metadaten liegt der FVEK verschlüsselt für einen weiteren Schlüssel den Volume-Master-Key (VMK). Der VMK ist somit der einzige Schlüssel der den FVEK schützt. Der Grund für die dreifache Speicherung der BitLocker Metadaten ist, damit bei einem Festplattendefekt einzelner Sektoren die wichtige Verschlüsselungsinformation aus alternativen Festplattensektoren geladen werden kann.

BitLocker Protektoren

Der VMK hingehen ist ebenfalls in den BitLocker Metadaten der verschlüsselten Partition gespeichert, aber mehrfach abgelegt und dann jeweils mit einem anderen Schlüssel verschlüsselt. Dies sind die sogenannten Protektoren (Englisch: Protectors) von BitLocker. Ein Protektor kann der TPM Chip sein (mit oder ohne PIN), dann ist der VMK mit einem RSA Schlüssel der im TPM Chip liegt verschlüsselt. Ein anderer Protektor kann ein Benutzer-Passwort sein. Hier wird aus dem Passwort ein Schlüssel abgeleitet und so der VMK entschlüsselt (der wiederum den FVEK öffnen kann). Weitere Protektoren sind ein Schlüssel auf einem USB-Stick oder Kombinationen mehrere Protektoren.

Eine Sonderrolle hat der VMK, wenn die BitLocker Verschlüsselung temporär ausgesetzt (Englisch: suspended) wird. Dann wird der VMK im Klartext in den BitLocker Metadaten gespeichert und das System kann ohne PIN/Passwort/Schlüssel gestartet werden.

BitLocker Recovery

Das Recovery-Passwort von BitLocker ist ebenfalls ein Protektor, hier wird der VMK zusätzlich zur Standard Entschlüsselungsmethode ein weiteres Mal gespeichert, eben verschlüsselt für das Recovery-Passwort.

Die Nutzung einer zweistufigen Verschlüsselung, der VMK schützt den FVEK, der FVEK ver- und entschlüsselt die Sektoren der Partition, ist eine gängige Methode der Verschlüsselung, da ein Schlüsselwechsel möglich ist. Da nur der VMK getauscht wird und nicht der FVEK kann ein Schlüsselwechsel ohne Umverschlüsselung aller Sektoren der Partition erfolgen. Ein periodischer Schlüsselwechsel ist eine häufige Forderung der IT-Sicherheitsexperten und auch in vielen Compliance Anforderungen verankert.

Anders verhält sich der VMK bei Datenpartitionen, also weiteren Partitionen neben der Windows Systempartition. Für diese Partitionen wird der VMK in der Regel unverschlüsselt in der Registry gespeichert, die Registry jedoch liegt auf der verschlüsselten Systempartition also gut geschützt solange das System nicht gestartet ist.

Sicherheitsbetrachtung BitLocker

BitLocker schützt nur Daten solange der PC/Notebook/Server nicht gebootet wurde und die BitLocker-Verschlüsselung noch nicht aktiv ist! Sobald das System gestartet ist der FVEK Verschlüsselungsschlüssel im Speicher geladen und alle gestarteten Anwendungen (inklusive Viren und Malware…) können beliebig Daten der Festplatte lesen. Daher empfehle ich eine Kombination aus BitLocker Festplattenverschlüsselung und einer File&Folder-Verschlüsselung, da die File&Folder-Verschlüsselung auch während der aktiven Nutzung vertrauliche Daten schützt.

Den Microsoft BitLocker betrachte ich als sichere Verschlüsselung, wenn er mit TPM-Chip und TPM-PIN betrieben wird. Mit TPM, aber ohne PIN startet das System automatisch und dann kann ein Angreifer den automatisch aktivierten FVEK mit diversen Attacken aus dem Hauptspeicher auslesen.

BitLocker mit Zwei-Faktoren-Authentifizierung

Die Nutzung eines USB-Sticks mit Schlüssel für die Aktivierung der BitLocker-Verschlüsselung hat den Nachteil, dass der Schlüssel am USB-Speicher beliebig kopiert werden kann und so ohne Wissen des Eigentümers in fremde Hände gelangen kann. Ggfls. kann auch eine Malware prüfen ob ein USB-Speicher mit einem BitLocker-Schlüssel gesteckt ist und den Schlüssel über das Internet kopieren. So kann durch Fremde zu einem beliebigen späteren Zeitpunkt das System entschlüsselt werden.

Der Schutz per Benutzer-Passwort alleine ist in der Regel zu schwach. Benutzer können bei der Passworteingabe beobachtet werden oder das Passwort kann per Brute-Force-Attacke oder Wörterbuch-Attacke geknackt werden.

Microsoft EFS Schlüssel

Das Microsoft Encrypting File System (EFS) nutzt einen zur Laufzeit generierten RSA 2048-Bit Schlüssel, der leider nicht mehr ganz zeitgemäß mit SHA1 signiert ist. In Firmenumgebungen mit einer Microsoft CA kommt dieser Schlüssel von der Unternehmens-PKI, in diesem Fall gibt es eine geschlossene Zertifikatskette zum Unternehmens-Root-Zertifikat. Auf Einzel-PCs oder auf Firmengeräten ohne dahinterliegende Enterprise-CA werden die Benutzerzertifikate beim Verschlüsseln der ersten Datei selbstständig angelegt. Beispielhaft ein EFS Zertifikat eines meiner Testgeräte in der Anwendung certmgr.msc dargestellt:

Microsoft Self-Signed EFS Zertifikat
Microsoft Self-Signed EFS Zertifikat

Durch Doppelklick sieht man die Eigenschaften des EFS Zertifikates:

EFS Encrypted File System Verschlüsselungszertifikat mit privatem RSA 2048-Bit Schlüssel
EFS Encrypted File System Verschlüsselungszertifikat mit privatem RSA 2048-Bit Schlüssel

In der Standardeinstellung ist der private Verschlüsselungsschlüssel im Microsoft Zertifikatsspeicher gespeichert und ohne eigenen Passwortschutz hinterlegt. Des Weiteren kann und muss der private Schlüssel per Exportfunktion gesichert werden, damit im Verlustfall der Schlüssel wieder geladen werden kann. Bei Verlust des Schlüssels hat man keinen Zugriff auf seine EFS verschlüsselten Daten, daher ist ein Backup dringend anzuraten.

EFS Sicherheitsbedenken

Sicherheitstechnisch sind sowohl der verwende SHA1 Hash, als auch der fehlende Passwortschutz und die Exportierbarkeit des privaten Schlüssels höchst bedenklich,  daher schlage ich folgende Vorgangsweise nach der automatischen Schlüsselerzeugung vor:

  • vorerst noch keine wichtigen Daten verschlüsseln, sondern eine Testdatei verschlüsseln
  • Backup des Zertifikats mit privatem Schlüssel in eine passwortgeschützte .PFX Datei. Die passwortgeschützte .PFX Datei unbedingt auf CD brennen und mit einem Passworthinweis an einem sicheren Ort (Safe) verwahren. Die Notebook-Festplatte ist KEIN geeignetes Backup-Medium für einen Verschlüsselungsschlüssel!
  • Löschen des EFS Zertifikates aus dem Microsoft Zertifikatsspeichers. Aufruf per Start > certmgr.msc > Eigene Zertifikate -> Zertifikate -> Zertifikat auswählen -> Rechte Maustaste > “Löschen”
  • Importieren des Backup .PFX ohne die Option “Schlüssel als exportierbar markieren.”

Hinweis: Obwohl es bei anderen Anwendungen prächtig funktioniert, unterstützt EFS keine “Hohe Sicherheit für den privaten Schlüssel” beim EFS-Softwarezertifikat, das bedeutet der Schlüssel kann nicht durch ein zusätzliches Benutzer-Passwort bei der ersten Benutzung durch die Anwendung geschützt werden. Es werden nur Softwarezertifikate unterstützt, die ohne Passwortschutz im Microsoft-Zertifikatsspeicher liegen.

EFS Tipps & Tricks

Ich habe meinen EFS-Schlüssel erfolgreich auf einen Kobil-USB-Cryptotoken importiert. Der Kobil-USB-Cryptotoken wird über eine cv cryptovision Middleware angesprochen und unterstützt die Microsoft CSP Schnittstelle. Da der Kobil-Token eine USB-Smartcard mit PIN-Schutz ist, kann man über den Weg seinen EFS Schlüssel auf einer eigenen Hardware mit PIN-Schutz speichern. Beim Zugriff auf eine EFS verschlüsselte Datei wird man aufgefordert die PIN des Crypto-Tokens einzugeben und die EFS Verschlüsselung erfolgt transparent über den Crypto-Token. Ich gehe davon aus, dass der Zwei-Faktoren-Schutz mit Smartcard und PIN auch mit anderen Smartcards und anderen Crypto-Token funktioniert.

TrueCrypt / VeraCrypt Schlüssel

Die TrueCrypt bzw. VeraCrypt Verschlüsselung basiert auf den bewährten Krypto-Standards PKCS#5 (Passwort basierte Schlüsselgenerierung) und PKCS#11 (Smartcard Schlüsselnutzung). Bei der Festplattenverschlüsselung, bei TrueCrypt/VeraCrypt System Encryption genannt, wird keine Smartcardunterstützung oder KeyFile Unterstützung angeboten, daher basieren die Verschlüsselungs-Schlüssel immer auf PKCS#5.

Maximale Entropie bei der Schlüsselfindung

Vereinfacht gesprochen liest TrueCrypt/VeraCrypt den 512 Byte Header des Containers oder des VeraCrypt Boot-Loaders [Anmerkung: bei der Festplattenverschlüsselung liegt der Header am Ende der Boot-Loader Partition] und nutzt die ersten 64 Bytes des Headers als “Salt” für die Schlüsselerstellung. Zu dem (1) “Salt” kommen das (2) Passwort, dass der Benutzer eingeben muss und optional (3) ein Wert namens “PIM” der einen Durchlaufzähler darstellt wie oft der Schlüssel in sich neu durchrechnet. Mit allen Werten 1-3 wird dann der Festplatten- oder Container-Verschlüsselungsschlüssel errechnet. Weitere 512 Bytes nach den ersten 65K Bytes der verschlüsselten Partition werden gelesen und über den errechneten Schlüssel entschlüsselt. Sofern sich in diesen entschlüsselten ersten Bytes der Wert “VERA” findet, ist der Schlüssel korrekt und die Partition bzw. der Container ist ein TrueCrypt/VeraCrypt Container.

Weitere detaillierte Informationen zum Header und der PKCS#5 Methode findest du in der VeraCrypt Dokumentation.

Aufwendig, aber sehr sicher

Im Gegensatz zu anderen Verschlüsselungslösungen verzichtet TrueCrypt/VeraCrypt darauf, dass der Verschlüsselungsschlüssel geschützt im Header abgespeichert wird. Man kann auch nicht erkennen ob es sich überhaupt um TrueCrypt/VeraCrypt verschlüsselte Daten handelt, da vom Header eigentlich nur die ersten 64 Byte als Salt genutzt werden. Top!

Da ich davon ausgehe, dass die verwendete PKCS#5 Methode sicher für eine Schlüsselerstellung ist, sehe ich als Angriffsmöglichkeit nur per Keylogger das Passwort des Benutzers abzugreifen. Hierzu kann ein Keylogger eingesetzt werden der die VeraCrypt Windows Anwendung ausspäht, während ein Benutzer ein Container-Passwort eingibt, oder ein weiterer Boot-Loader vor dem TrueCrypt/VeraCrypt Boot-Loader wird installiert und protokolliert die Tastatureingaben während dem TrueCrypt/VeraCrypt Boot-Loader.

TrueCrypt bzw. VeraCrypt: Wiederherstellung oder Brute-Force?

Im Rescue-Verfahren mit der Rescue-CD kann der Schlüssel auch ohne Passwort abgespeichert sein. Daher sollte man auf sein Rescue ISO Image bzw. seine gebrannte Rescue-CD SEHR gut aufpassen, da beim Vergessen des Passwortes oder der PIM keine Wiederherstellung möglich ist. Durch die hohen Wiederholungszyklen bei der Schlüsselerrechnung dauert jeder Versuch bei der Brute-Force Attacke sehr lange. Ich gehe davon aus, dass eine Brute-Force-Attacke auch mit hoher CPU Leistung nicht möglich ist.

PKI Schlüssel auf einer Smartcard

Mitarbeiter von Unternehmen kennen es vielleicht: eine multifunktionalter Ausweis-Smartcard mit Zutrittskontrolle, Kantinenguthaben, Windows-Anmeldung und anderen Software-Funktionen.

Die Windows-Anmeldung und PC-Nutzung der Smartcard erfolgt über eine Crypto- oder PKI-Smartcard. Eine solche Smartcard wird als bedruckbare Plastikkarte im Scheckkartenformat angeboten, oder als USB-Crypto-Token für den Schlüsselbund. Für den Betrieb der Scheckkarten-Smartcard ist ein Smartcard-Leser notwendig, der in die Tastatur oder den Notebook eingebaut sein kann, oder als externer USB-Leser am Schreibtisch steht.

Smartcard Reader mit PKI Smartcard
Smartcard Reader mit PKI Smartcard

Was verbirgt sich aber hinter einer PKI Smartcard? Der goldene Chip ist ein eigener Micro-Prozessor mit eigenem Flash-Speicher und definierten Krypto-Funktionen. Moderne Smartcards sind oft Java Karten mit einem JCOP Betriebsystem. Auf dem JCOP Betriebssystem laufen dann unterschiedliche speziell programmierte Java-Applets die für die wichtigen PKI Funktionen wie Schlüsselspeicherung (gesichert am Flash-Speicher der Smartcard), Schlüsselnutzung, digitale Signatur, Authentisierung ermöglichen.

Der Smartcard-Prozessor

Wie passt so ein mächtiges Betriebssystem auf so einen kleinen goldenen Chip? Das ist möglich, weil der Micro-Prozessor auf viele wichtige Dinge verzichtet: er hat kein RAM, sondern “nur” seinen Flash-Speicher, er hat keinen eigenen Takt-Quarz, sondern erhält seinen Takt über einen der acht PINs, er hat keine Stromversorgung oder Batterie und auch kein BIOS oder eine Echtzeituhr wie die meisten anderen Computer. Der externe Takt wird übrigens geteilt und im Chip multipliziert, so kommt eine 32-Bit Java Card auf einige MHz.

Kryptografische Schlüssel können entweder in Software erstellt werden und auf die Smartcard importiert werden oder direkt über den Smartcard-Prozessor über das Smartcard-Betriebssystem erstellt werden. Bei asymmetrischen Schlüsseln erzeugt der Prozessor dann sowohl den privaten als auch den öffentlichen Schlüssel. Der private Schlüssel wird sofort verschlüsselt im eigenen Flash-Speicher gespeichert und der öffentliche Schlüssel wird an den Client zurückgegeben der das X.509 Zertifikat erzeugen kann (bzw. von der Certificate Authority erzeugen lassen kann).

Das Erzeugen der Schlüssel direkt auf der Smartcard ist die höchstmögliche Sicherheit für einen kryptografischen Schlüssel.

Smartcard PIN &, PUK

Ein Teil des Flashs, nämlich der in dem die Schlüssel gespeichert sind, sind über einen Smartcard-Schlüssel verschlüsselt. Dieser wiederum wird nur durch die Benutzer-PIN aktiviert. Sollte der Benutzer seine PIN vergessen haben, gibt es in der Regel noch eine Admin-PIN oder manchmal auch PUK genannt. Diese ist vergleichbar mit der Super-PIN oder PUK der Handy-SIM für das entsperren oder rücksetzen der Benutzer-PIN zuständig. Ein Auslesen des Flash-Speichers, speziell der Teil in dem die Schlüssel gespeichert sind, wird vom Smartcard-Betriebssystem nicht erlaubt. Daher gelten Smartcard zu den sichersten Schlüsselspeichern überhaupt.

Integrierter Schutz vor Brute-Force-Attacken

Was macht aber eine Smartcard-Sicherheit so unschlagbar? Die Smartcard schützt für Brute-Force-Attacken, also dem sequenziellen Ausprobieren von PINs, indem die Smartcard ähnlich der Bank-Karte sich nach 5- bis 8-maligen falschen PINs einfach sperrt. Dann wird der lange PUK oder Admin-PIN benötigt, den man aber auch nicht unendlich oft ausprobieren kann. Dann nämlich sperrt sich die Smartcard für immer und löscht ggfls. sogar alle gespeicherten Informationen.

Wie viel Speicher hat eine Smartcard?

Zu guter Letzt noch die Frage wie viel Information man auf einer Smartcard speichern kann? Da Flash hat oft 256 KByte oder 128 KByte, davon nutzt das Betriebssystem mehr als die Hälfte. Daher bleiben zumeist zwischen 72 KByte und 64 KByte für Benutzerdaten und als Schlüsselspeicher. Um ein MP3 mit 4 MByte zu speichern bräuchtest du daher mindestens 57 Smartcards. Nutze besser einen USB-Stick dafür. Für RSA 2048 Bit oder AES 256 Bit Schüssel reicht der Speicher aber mehrfach aus. Theoretisch könnte eine Smartcard bis zu 281 RSA 2048 Bit speichern. In der Praxis sind es aber nur rd. 8-10 Schlüssel, da die X.509 Zertifikate zu den Schlüsseln (3-5 KByte je Zertifikat) auch auf der Smartcard gespeichert werden

Linux sshd – Sichere Identifikation ohne Passwort

Seit vielen Jahren ist OpenSSL der Linux ssh-Deamon nahezu aller Linux Distributionen. Der Weg den Port 22 in der Firewall oder am NAT-Router freizuschalten und per Username + Passwort auf einen SSH-Server zuzugreifen ist sehr einfach und verlockend, ABER unsicher.

Das Passwort kann über Brute-Force Attacken gehackt werden, da der Server ja 24h im Internet erreichbar ist und die wenigsten Administratoren ihre Auth-Logs prüfen. Des Weiteren gelingt eine Man-in-the-Middle-Attache bei solchen Diensten mit wenigen Mitteln, wenn der Nutzer aus einem öffentlichen oder kompromittierten Netzwerk auf den SSH-Server zugreift, da ihm einfach ein falscher Server für die User-/Passworteingabe vorgespiegelt wird und so die Zugangsdaten abgegriffen werden.

Viel sicherer ist das Deaktivieren der Passwort Benutzeridentifikation und Nutzung von langen Kryptographischen Schlüsseln für den Remote-Zugriff. Diese Einstellungen möchte ich hiermit vorstellen.

ssh Schlüsselerzeugung

Da ich nicht weiß, wie lange Zugriffsschlüssel schon auf dem Server liegt und ob dieser nicht bereits in fremden Händen ist, generiere ich im ersten Schritt einen neues RSA 4096-Bit Schlüsselpaar.

user1@server:/etc/ssh$ ssh-keygen -t rsa -b 4096
 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/user1/.ssh/id_rsa):
 Enter passphrase (empty for no passphrase): *******
 Enter same passphrase again: ********
 Your identification has been saved in /home/user1/.ssh/id_rsa.
 Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
 The key fingerprint is:
 SHA256:3lfSIuQD/v6DkreixSN5arP4UoViLHsLVjzR8nf7Utg aschuster@server1
 The key's randomart image is:
 +---[RSA 4096]----+
 |        .        |
 |       o .       |
 |      o + .. .   |
 | . B o.o+. .     |
 |  = o oS.++o o   |
 |  + . .+ oooE+   |
 |  . o oo *.o+.   |
 |   o.o=+o+.o     |
 |   .+=+ +o+..    |
 +----[SHA256]-----+
Kopieren des öffentlichen Schlüssel auf das Zielsystem

Nun muss der erzeugte öffentliche Schlüssel auf das Zielsystem kopiert werden, dies geschieht entweder mit

$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

oder man kopiert den öffentlichen Schlüssel vom Quellsystem /home/username/.ssh/id_rsa.pub per ssh oder ftp auf das Zielsystem. Anschließend per cat Befehl an das Ende der Datei /home/username/.ssh/authorized_keys , z.B. am Zielsystem per

$ cat id_rsa.pub >> ~/.ssh/authorized_keys

## nun die Rechte am Zielsystem korrekt vergeben
$ chmod 700 /home/username/.ssh
$ chmod 600 /home/username/.ssh/authorized_keys
Nutzung des Schlüssels statt eines Passworts

Nun kann man sich ohne Passwort, dafür per 4096-Bit Schlüssel anmelden.

$ ssh username@zielserver

Sobald das klappt kann man in der Datei /etc/ssh/sshd_config die folgenden Optionen ändern, um die unsichere Passwort-Anmeldung per ssh zu unterbinden.

UsePAM no
PasswortAuthentication no

Anschließend den SSH-Server neu starten oder zumindest die Konfiguration neu einlesen, per sudo /etc/init.d/ssh reload . Ggfls. ist das in Eurer Linux Distribution auch ein anderer Befehl zum Service-Restart/Reload

Solltet ihr verschlüsselte Home-Verzeichnisse verwenden verweise ich auf folgende Anleitung für Ubuntu die den Eintrag AuthorizedKeysFile ändert.

PUTTY SSH per Schlüssel

Sofern ihr den oberen Punkt SSH Schlüsselerzeugung bereits durchgeführt habt, liegt in einem Userverzeichnis unter .ssh/ eine Datei mit dem privaten Schlüssel unter dem Namen “id_rsa”. Diese Datei muss nun für den PUTTY Windows Client vorbereitet werden. Da PUTTY das Format nicht direkt lesen kann, installiere ich nun die putty-tools, z.B. unter Ubuntu mit # apt-get install putty-tools

Dann in Verzeichnis des id_rsa.pub den folgenden Befehl ausführen

$ puttygen id_rsa -o id_putty -O private

Im Anschluss die Datei “id_putty” auf den Windows Client kopieren und im PUTTY Tool “puttygen” konvertieren und per Save private key lokal speichern.

PUTTY Konvertierung des openssl Schlüssel in einen PUTTY Schlüssel
PUTTY Konvertierung des openssl Schlüssel in einen PUTTY Schlüssel

Nun klappt auch der Zugriff auf den Linux Server per Schlüsseldatei, die zuvor unter PUTTY noch für die Verbindung unter Connection -> SSH -> Auth definiert werden muss.

PUTTY Konfiguration der Schlüsseldatei für den ssh Zugriff
PUTTY Konfiguration der Schlüsseldatei für den ssh Zugriff

Hier der Screenshot vom Zugriff, bei dem der Usernamen und das Passwort für die Schlüsseldatei angegeben werden muss, wodurch eine Brute-Force-Attacke aus dem Internet nicht mehr möglich ist.

PUTTY Login mit Schlüsseldatei, Username und Passwort der Schlüsseldatei
PUTTY Login mit Schlüsseldatei, Username und Passwort der Schlüsseldatei

Der SSL Schlüssel einer Webseite

Der Schlüssel für die HTTPS Verschlüsselung eines Web-Servers liegt in der Regel direkt im Dateisystem des Webservers. Der private Schlüssel hat keinen Passwortschutz, da sonst bei jedem Start des Webserver-Dienstes jemand das Passwort für den Schlüssel eingeben muss. Da heute Webserver in der Regel in virtuellen Umgebungen beim Provider stehen, gibt es keinen wirksamen Schutz für einen SSL Schlüssel. (Anmerkung: doch es gibt technische Lösungen, die erfordern aber Smartcards oder sehr teure HSM Systeme, gerne helfe ich bei Sicherheits-Konzepten)

Wo findest du den Schlüssel und das Webserver-Zertifikat?

Die Antwort steht direkt in der Webserver-Konfiguration, wie in meinem Beispiel ein Linux/Apache2 Server in der Datei /etc/apache2/sites-enabled/000-default.conf .

# Auszug aus /etc/apache2/sites-enabled/000-default.conf
 <VirtualHost *:443>
 SSLEngine on
 SSLCertificateFile /etc/ssl/certs/apache.crt
 SSLCertificateKeyFile /etc/ssl/private/apache.key

ServerAdmin webmaster@localhost
 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined

# Pfad zu den Webinhalten
 DocumentRoot /var/www/html
 </VirtualHost>
Das SSL-Zertifikat

Das Webserver-Zertifikat (der öffentliche Schlüssel “apache.crt”) ist der Inhalt der dem Web-Besucher angeboten wird, um die Webverbindung zu verschlüsseln. Technisch gesehen wird bei dem HTTPS Verbindungsaufbau in einem frühen Schritt ein 3DES oder AES Schlüssel generiert, mit dem alle Webinhalte verschlüsselt geladen werden.

So kannst du den Inhalt deines Zertifikats anzeigen. Ein paar wichtige Zertifikatsinhalte habe ich fett markiert.

  1. SHA256 Signatur für das Zertifikat, nicht den alten MD5 oder den kürzlich abgelösten SHA1
  2. Gültigkeit des Zertifikates: in meinem Fall bis 2. Mai 2018, 18:23h -> exakt dann wird mein Webserver bei Webbesuchern Fehler melden! Also rechtzeitig das Zertifikat erneuern.
  3. RSA Schlüssel in der Länge von 2048 Bit, heute der aktuelle Stand der Technik 🙂
user@server1:/home/user$ cd /etc/ssl/certs
 user@server1:/etc/ssl/certs$ openssl x509 -text -noout -in apache.crt
 Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number:
 92:e4:14:e0:e8:89:77:6c
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: C=AT, ST=Vienna, L=Vienna, O=Andreas Schuster, OU=Sales, CN=server1/emailAddress=my_mail_address@gmail.com
 Validity
 Not Before: Feb 22 18:23:19 2016 GMT
 Not After : May  2 18:23:19 2018 GMT
 Subject: C=AT, ST=Vienna, L=Vienna, O=Andreas Schuster, OU=Sales, CN=server1/emailAddress=my_mail_address@gmail.com
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 Public-Key: (2048 bit)
 Modulus:
 00:b6:f4:c2:95:8c:10:69:47:5e:c1:5b:b7:a1:00:
 23:07:ca:cf:bf:10:c4:d7:25:c9:43:20:01:43:41:
 ... 14 Zeilen gekürzt...
 12:50:b3:70:e8:24:54:da:ee:4d:7c:9e:d0:a5:be:
 34:21
 Exponent: 65537 (0x10001)
 X509v3 extensions:
 X509v3 Subject Key Identifier:
 D5:B5:B8:D8:8D:FD:25:5F:0C:1A:98:D0:2B:5F:F5:63:76:B7:CA:66
 X509v3 Authority Key Identifier:
 keyid:D5:B5:B8:D8:8D:FD:25:5F:0C:1A:98:D0:2B:5F:F5:63:76:B7:CA:66

X509v3 Basic Constraints:
 CA:TRUE
 Signature Algorithm: sha256WithRSAEncryption
 61:e1:99:80:c5:a3:49:0d:08:82:f2:05:aa:35:7d:bd:1a:26:
 47:ac:63:b7:6b:8e:0c:d2:3a:ca:91:eb:30:7e:49:30:d4:6b:
 ... 11 Zeilen gekürzt...
 0f:82:47:57:8f:43:64:72:c7:f0:74:fc:72:54:43:e5:1d:7f:
 6e:64:6a:82

Der öffentliche Schlüssel (das Zertifikat) wird dem Client angeboten um eine verschlüsselte Verbindung aufzubauen, aber wie nimmt der Server die verschlüsselte Verbindung an und entschlüsselt diese? Die Antwort ist der passende private Schlüssel zum Zertifikat.

Wie kann man den privaten Schlüssel prüfen und anzeigen?

Dieser Befehl ist nur als root möglich, da Zugriff auf /etc/ssl/private nur für Benutzer “root” oder Gruppe “ssl-cert” möglich ist.

root@server1:/# cd /etc/ssl/private
root@server1:/etc/ssl/private# openssl rsa -in apache.key -check
 RSA key ok
 writing RSA key
 -----BEGIN RSA PRIVATE KEY-----
 MIIEpAIBAAKCAQEAtvTClYwQaUdewVu3oQAjB8rPvxDE1yXJQyABQ0EimIJnj199
 98ixzY1JdCl0MheR6oZSizqz3pymJfn02DJBVq4UFvqRAsOQruEvntK9NHrZXBzU
 ... 22 Zeilen gekürzt...
 s/O7zf/vmpPun4n411GJ4wys4hX58PUHkUuZETjF9QQcvt8jf6Jk3A==
 -----END RSA PRIVATE KEY-----

Teile bitte Deine Erfahrung mit kryptografischer Schlüsselspeicherung? Gute als auch negative Beispiele sind herzlich willkommen! Schreibe nun dein Kommentar.

3 Gedanken zu „Schatz, wo liegt der Schlüssel?“

    1. Hallo Markus,

      Vielen Dank für das Lob! Ich denke je größer die Sicherheits-Awareness in Österreich und Deutschland wird, desto eher haben Hacker und Cyber-Betrüger keine Chance mehr.

      sichere Grüße, Andreas

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert