Der Leitfaden eines jeden guten Sicherheitsingenieurs ist: »Sicherheit
ist kein Produkt sondern ein Prozess.« Es steckt mehr dahinter,
als starke Kryptographie in ein System zu integrieren. Es bedeutet, das
gesamte System so zu entwerfen, dass alle Sicherheitsmaßnahmen -
inklusive der Kryptographie - zusammenarbeiten.
- Bruce Schneier, Autor von Applied Cryptography.
Kryptographie
Inhaltsverzeichnis
Warum liefern wir Kryptographie aus?
OpenSSH.
Pseudozufallszahlengeneratoren (PRNG): ARC4,
...
Kryptographische Hashfunktionen: MD5, SHA1, ...
Symmetrische Verschlüsselungsverfahren: DES,
Blowfish, ...
Unterstützung für kryptographische Hardware
Internationale Kryptographen gesucht
Weitere Quellen
Warum liefern wir Kryptographie
aus?
In drei Worten: Weil wir können.
Das OpenBSD-Projekt ist in Kanada beheimatet.
Die Exportkontrollliste von Kanada
beinhaltet keine signifikanten Beschränkungen bezüglich des
Exports von kryptographischer Software und ist sogar noch offener
was den Export frei erhältlicher kryptographischer Software angeht.
Marc Plumb hat
einige
Nachforschungen betrieben, um die Kryptographiegesetze zu prüfen.
Daher hat das OpenBSD-Projekt Kryptographie in zahlreichen Stellen im
Betriebssystem integriert. Wir verlangen, dass die kryptographische
Software, die wir benutzen wollen, frei
erhältlich ist und guten Lizenzen unterliegt. Wir benutzen keine
Kryptographie mit unzulänglichen Lizenzen direkt. Wir verlangen
außerdem, dass solche Software aus Ländern mit vernünftigen
Exportbedingungen kommt, da wir nicht die Gesetze irgendeines Landes
brechen wollen. Die kryptographischen Komponenten, die wir momentan
benutzen, wurden in Argentinien, Australien, Deutschland,
Griechenland, Kanada, Norwegen und Schweden geschrieben.
Wenn wir OpenBSD-Releases oder -Snapshots machen, erzeugen wir diese
in freien Ländern, um sicherzustellen, dass sowohl Quelltexte als auch
Binärdateien frei von Beschränkungen sind.
In der Vergangenheit wurden unsere Releases in Kanada, Schweden und
Deutschland erzeugt.
OpenBSD wird mit Kerberos V ausgeliefert.
Die Codebasis, die wir benutzen, ist die exportierbare Heimdal-Version
aus Schweden. Unsere X11-Quellen wurden ebenfalls so erweitert, dass
sie Gebrauch von Kerberos machen.
OpenBSD war das erste Betriebssystem, das mit einem IPsec-Stack
ausgeliefert wurde. IPsec ist Teil des Systems seit der
Veröffentlichung des OpenBSD-Releases 2.1 im Jahre 1997. Unser voll
konformer kernelinterner IPsec-Stack mit möglicher
Hardwareunterstützung durch Zusatzkarten und unser eigener freier
ISAKMP-Daemon wird als eine der Maschinen im IPsec conformance
testbed der VPNC benutzt.
Heutzutage ist Kryptographie eine wichtige Sache, um die
Sicherheit eines Betriebssystems zu
erhöhen. Die in OpenBSD integrierte Kryptographie kann in folgende
Bereiche klassifiziert werden:
OpenSSH
Seit dem Release 2.6 hat OpenBSD
OpenSSH integriert; eine absolut
freie und nicht patentierte Version von ssh.
OpenSSH interagiert auch mit ssh
Version 1 und hat viele weitere Funktionalitäten,
-
alle Teile restriktiver Natur wurden entfernt (also Patente, siehe
ssl)
jegliche lizenzierten oder patentierten Komponenten stammten aus
externen Bibliotheken.
-
wurde um das Protokoll Version 1.5 erweitert.
-
beinhaltet Unterstützung für Kerberosauthentifizierung und
Ticketpassing.
-
unterstützte Einmalpasswörter durch
skey.
Grob gesagt haben wir eine Version von ssh mit freier Lizenz genommen
und sie OpenBSD-fiziert. Ungefähr ein Jahr später haben wir OpenSSH so
erweitert, dass es nun auch das SSH-2-Protokoll beherrscht. Das
Resultat ist, dass alle drei großen SSH-Protokolle unterstützt
werden: 1.3, 1.5, 2.0.
Pseudozufallszahlengeneratoren
Ein Pseudozufallszahlengenerator (PRNG = Pseudo Random Number
Generator) versorgt Applikationen mit einem Zahlenstrom, der einen
erheblichen Einfluss auf die Sicherheit des Systems hat:
- Es sollte für einen Außenstehenden unmöglich sein, sogar mit
Kenntnis der bisherigen Zahlen weitere Zahlen vorherzusagen.
- Die generierten Zahlen sollten keine sich wiederholenden Muster
aufweisen, d. h. der PRNG sollte einen sehr langen Kreislauf haben.
Ein PRNG ist eigentlich nur ein Algorithmus, bei dem mit den selben
Startwerten auch die selben Ergebnisse herauskommen.
Bei einem Mehrbenutzersystem gibt es viele Möglichkeiten, den PRNG mit
Zufallsdaten zu füttern.
Der OpenBSD-Kernel benutzt das Mausinterrupttiming,
Netzwerkdateninterruptverzögerungen, die Zeit zwischen Tastendrücken
und Festplatten-E/A-Informationen, um Zufallszahlen zu bekommen.
Zufallszahlen stehen den Kernelroutinen zur Verfügung und werden an
Userlandprogramme weitergegeben. Bisher werden Zufallszahlen benutzt
von:
- Dynamische sin_port-Zuweisung in bind(2).
- PIDs von Prozessen.
- IP-Datagramm-IDs.
- RPC-Transaktions-IDs (XID).
- NFS-RPC-Transaktions-IDs (XID).
- DNS-Abfrage-IDs.
- Inode-Generierungsnummern, siehe getfh(2) und fsirand(8).
- Timingstörungen in traceroute(8).
- Stärkere temporäre Namen für mktemp(3) und mkstemp(3).
- Zufälligkeit zum TCP-ISS hinzugefügt, um spoofing-Angriffe zu
verhindern.
- Zufälliges Padding in IPsec-esp_old-Paketen.
- Um Salts für die verschiedenen Passwortalgorithmen zu generieren.
- Um vorgetäuschte S/Key-Herausforderungen zu generieren.
- In isakmpd, um lebende Beweise für Schlüsselaustausch zu haben.
Kryptographische Hashfunktionen
Eine Hashfunktion komprimiert ihre eingegebenen Daten zu einer
Zeichenkette konstanter Länge. Mit einer kryptographischen Hashfunktion
können folgende Szenarien nicht eintreten:
- Zwei Eingaben erzeugen die selbe Ausgabe (resistent gegen
Kollisionen).
- Eine andere Eingabe für eine gegebene Eingabe erzeugt die selbe
Ausgabe (2nd preimage resistant).
In OpenBSD werden MD5, SHA1, und RIPEMD-160 als kryptographische
Hashfunktionen benutzt,
z. B. hier:
- In S/Key,
um Einmalpasswörter bereitzustellen.
- In IPsec
und
isakmpd(8),
um die Herkunft von Daten zu authentifizieren und Paketintegrität
zu gewährleisten.
- Um MD5-Passwörter im FreeBSD-Stil bereitzustellen (kein Standard),
siehe passwd.conf(5)
- In libssl für die digitale Signatur von Nachrichten.
Symmetrische Verschlüsselungsalgorithmen
Symmetrische Verfahren werden benutzt, um Daten zu ver- und
entschlüsseln. Normalerweise werden sie mit einem Schlüssel zur Ver- und
einem Schlüssel zur Entschlüsselung gebraucht. Die Sicherheit eines
symmetrischen Algorithmus sollte wirklich nur auf den Schlüsseln
beruhen.
OpenBSD stellt symmetrische Verfahren wie DES, 3DES, Blowfish und Cast
für Kernel- und Userlandprogramme zur Verfügung, die an vielen Plätzen,
wie z. B. an diesen, benutzt werden:
- In der libc für die Erstellung von Blowfish-Passwörtern. Siehe dazu auch das USENIX paper.
- In IPsec, um Vertrauen in die Netzwerkschicht zu bringen.
- In isakmpd, um den Austausch von IPsec-Schlüsselmaterial zu schützen.
- In AFS, um die Nachrichten zu schützen, die über das Netzwerk gehen,
und um Vertrauen im Zugriff auf entfernte Dateisysteme zu
gewährleisten.
- In libssl, um Applikationen über das kryptographisch sichere und
zudem de facto Standard-SSL-Protokoll laufen zu lassen.
Unterstützung für kryptographische Hardware
OpenBSD unterstützt seit Release 2.7 einige kryptographische Hardware
wie etwa Hardwarebeschleuniger und Zufallszahlengeneratoren.
-
IPsec crypto dequeue
Unser IPsec-Stack wurde so verändert, dass kryptographische
Funktionen auch außer der Reihe gemacht werden können. Die
meisten Software-IPsec-Stacks müssen die kryptographischen
Funktionen mit jedem einzelnen Paket durchführen, das sie behandeln.
Das resultiert in synchroner Leistungsfähigkeit. Um Hardware sauber
und schnell zu nutzen, muss man diese zwei Komponenten trennen -
wie von uns durchgeführt. Tatsächlich springt dabei sogar etwas
Leistung für die Softwareseite heraus.
-
Hifn 7751
Karten, die den Hifn 7751 verwenden, können
als symmetrischer kryptographischer Hardwarebeschleuniger benutzt
werden, z. B.
Soekris VPN1201 oder
VPN1211
(hier zu kaufen)
oder PowerCrypt.
Die momentan dabei erreichte Leistung beträgt 64 Mbit/s für
3DES/SHA1 ESP, wenn man einen einzelnen Hifn 7751 auf jeder Seite
eines Tunnels hat: das ist fast eine 600%ige Verbesserung gegenüber
einer P3/550-CPU. An weiteren Verbesserungen bezüglich einiger
Punkte wird noch gearbeitet, aber mit dem Stand vom 13. April 2000
wird der Code als stabil angesehen. Wir haben unseren eigenen Treiber
geschrieben, um diesen Chip zu unterstützen, anstatt den (in den
USA geschriebenen)
Powercrypt-Treiber zu
benutzen; außerdem arbeitet unser Treiber sauber mit IPsec zusammen.
Der 7751 wird in Bezug auf Industriestandard als langsam angesehen
und viele Anbieter haben schnellere Chips (auch Hifn hat einen
schnelleren aber auch teureren Chip).
Die Spitzenleistung mit 3DES SHA1 ESP beträgt etwa 64 Mbit/s.
Nachdem 2.9 veröffentlicht wurde, wurde noch Unterstützung für
den Hifn-7951-Chip hinzugefügt; eine vereinfachte Version des 7751,
die einen Beschleuniger für öffentliche Schlüssel enthält
(noch nicht unterstützt) und einen Zufallszahlengenerator
(unterstützt). Die Karten wurden von
Soekris Engineering gespendet.
Nach der Veröffentlichung von 3.0 wurde dann noch Unterstützung
für den Hifn-7811-Chip hinzugefügt; einer schnelleren Version
des 7751 (etwa 130 Mbit/s) mit einem Zufallszahlengenerator.
Die Karte wurde von GTGI
gespendet.
Nachdem 3.2 veröffentlicht wurde, wurde eine Unterstützung für
den LZS-Kompressionsalgorithmus hinzugefügt, der von
ipcomp(4)
benutzt wird.
Nachdem 3.4 veröffentlicht wurde, wurde Unterstützung für die
7955- und 7956-Chips hinzugefügt. Zusätzlich zu allen Funktionen
des vorherigen 7951-Chips beherrschen diese AES.
Hifn war anfänglich eine Firma, mit der schwer umzugehen war
(sie haben uns angedroht, uns wegen unseres außerhalb der USA
stattgefundenem Reverseengineerings ihres crypto-unlock-Algorithmus
zu verklagen), aber in letzter Zeit haben sie uns besser unterstützt
und uns Boards gegeben.
-
Hifn 6500
Dieses Gerät ist eine asymmetrische Kryptoeinheit. Sie unterstützt
RSA-, DSA- und DH-Algorithmen sowie andere häufig vorkommende
Funktionen. Es enthält einen sehr schnellen Zufallszahlengenerator.
Wir haben ein Gerät, die ganze Dokumentation, und Beispielquelltext.
Mit 3.1 arbeiten sowohl der Zufallsgenerator als auch die
Big-Number-Unit.
-
Hifn 7814/7851/7854
Dieses Gerät ist ein Paketprozessor und eine asymmetrische
Kryptoeinheit. Es unterstützt RSA-, DSA- und DH-Algorithmen sowie
andere wichtige Big-Number-Funktionen und verfügt auch über einen
Zufallszahlengenerator. Momentan werden die Big-Number-Engine und
der Zufallszahlengenerator unterstützt (keine Pakettransformationen).
-
Broadcom BCM5801/BCM5802/BCM5805/BCM5820/BCM5821/BCM5822/5823
(oder der Beta Chip Bluesteelnet 5501/5601)
Direkt nach der Veröffentlichung von OpenBSD 2.7 konnten wir
erstmalige Unterstützung für diese frühen Versionen erreichen, die
uns der Hersteller zur Verfügung gestellt hat (insbesondere mit dem
Testchip 5501). Diese Geräte liefern die schnellste symmetrische
Kryptographie, die wir bisher gesehen haben.
Bluesteelnet wurde von Broadcom aufgekauft und hat danach richtige
Komponenten gemacht. Ihre neue BCM5805 ist ähnlich, außer dass sie
auch eine asymmetrische Maschine hinzugefügt haben, um DSA-, RSA-
und ähnliche Algorithmen zu unterstützen. Mit einer
annähernd doppelt so hohen Geschwindigkeit wie die der Hifn wird
dieser Chip hoffentlich bald verbreiteter sein.
Die Leute von Broadcom/Bluesteelnet waren wirklich großartig. Sie
gaben uns die komplette Dokumentation für ihre Chips,
Beispielquelltext und dazu noch eine ausreichende Menge Karten,
um das Ganze zu testen.
Nach 2.8 wurde dieser Treiber auch dahingehend modifiziert, dass er
Zufallszahlen auf dem BCM5805 und ähnlichen Versionen produziert
und diese dann in den Entropiepool des Kernels übergibt.
Nach 2.9 wurde Unterstützung für den BCM5820 hinzugefügt, was
größtenteils eine schnellere (64 Bit, höhere Taktrate) Version des
BCM5805 ist. Noch ungetestete Unterstützung für den BCM5821 wurde
auch nach 3.0 hinzugefügt.
Mit 3.1 wurde die Big-Number-Engine unterstützt und
RSA/DH/DSA-Operationen konnten beschleunigt werden.
Unterstützung für den BCM5801, BCM5802, BCM5821 und BCM5822 wurden
vor OpenBSD 3.2 hinzugefügt (die ungetestete BCM5821-Unterstützung
in 3.1 hat wegen einiger nicht dokumentierter
Interrupthandlingprobleme nicht funktioniert).
Partielle Unterstützung für BCM5823 wurde bei 3.4 hinzugefügt. Der
Chip unterstützt AES, der Treiber aber nicht.
-
Securealink PCC-ISES
Der PCC-ISES
ist ein neuer Chipsatz aus den Niederlanden. Wir haben
Probehardware und Dokumentation - die Arbeit an einem Treiber
ist im Gange. Im Moment kann der Treiber bereits Zufallszahlen an
den Entropiepool des Kernels liefern.
-
SafeNet SafeXcel 1141/1741
Nach der Veröffentlichung von 3.4 wurde die Unterstützung für diese
zwei Chips hinzugefügt - diese wurden in etlichen
SafeNet-Kryptokarten
eingesetzt. Unterstützt symmetrische Operationen mit DES,
Triple-DES, AES, MD5 und SHA-1, RNG, Publickey-Operationen und
vollständige IPsec-Paketverarbeitung.
- SafeNet SafeXcel 1840
Wir haben Dokumentation und Probehardware für den
SafeNet 1840-Kryptochip
bekommen. Wir arbeiten daran, wenigstens die RNG- und symmetrische
Kryptographie dieser Devices zu unterstützen.
- SafeNet SafeXcel 2141
Wir haben Dokumentation und Probehardware für die
SafeNet-Kryptochips
bekommen. Wir arbeiten daran, wenigstens die symmetrische
Kryptographie zu unterstützen.
-
3com 3cr990
3com hat uns einen Treiber gegeben, um die Ethernetseite dieses
Chipsets zu unterstützen. Wir haben basierend darauf einen
eigenen Ethernettreiber geschrieben. Der Treiber wurde jetzt in
OpenBSD eingefügt, da wir eine freie Lizenz für den Microcode
erhalten haben. Wegen schlechter Dokumentation und einem Mangel an
Kooperation (der teilweise durch die hohen Austauschraten bei 3com
begründet ist), werden die IPsec-Funktionen des Chips nicht
unterstützt ... Daher hat sich das Ganze als gar nicht sinnvolle
Erfahrung herausgestellt.
- Intel IPsec card
Intel tut viel für ihre Netzwerkprodukte, aber im Gegensatz zu
allen anderen Anbietern weigert sich Intel standhaft, uns
Dokumentation zu geben. Wir haben mit etwa fünf Technikern
gesprochen, die an der Entwicklung dieser Produkte beteiligt sind.
Sie alle wollten, dass wir Dokumentation bekommen. Sie loben uns für
das, was wir bisher getan haben. Aber ihre Hände sind vom Management
gebunden, die für sich keinen Vorteil sehen, wenn sie uns
Dokumentation geben. Vergiss Intel (wenn du Gigabitethernethardware
kaufen willst, empfehlen wir alles andere ... aus eben dem selben
Grund: Die meisten Treiber, die wir bisher geschrieben haben, wurden
ohne Dokumentation geschrieben).
-
Intel 82802AB/82802AC Firmware Hub RNG
Der 82802-FWH-Chip (zu finden auf i810-, i820-, i840-, i850- und
i860-Motherboards) enthält einen Zufallszahlengenerator (RNG).
Hoch performantes IPsec benötigt mehr Zufallszahlenentropie. Seit
dem 10. April 2000 unterstützen wir den RNG. Wir werden
Unterstützung für weitere RNGs auf anderen Kryptochips hinzufügen.
- VIA C3 RNG
Die neuere VIA-C3-CPU enthält einen Zufallszahlengenerator als
Anweisung. Seit 3.3 wird dieser
Zufallszahlengenerator im Kernel dazu genutzt, den Entropiepool zu
füllen.
- VIA-C3-AES-Befehle
VIA-C3-CPUs mit Step 8 oder späterem Nehemiah-Core enthalten eine
AES-Implementation, auf die mittels einfacher Befehle zugegriffen
werden kann. Seit 3.4 unterstützt der Kernel
die Benutzung im Kontext von IPsec und exportiert sie mittels
/dev/crypto. Mit 3.5 wurden die
Geschwindigkeiten erheblich verbessert und OpenSSL benutzt die
neuen Befehle direkt ohne die Notwendigkeit eines Zugriffs auf den
Kernel, was zu einer erheblichen Geschwindigkeitssteigerung
für Anwendungen führt, die OpenSSL verwenden, um AES-Verschlüsselung
zu bekommen (AES-128 wurde mit 780 MByte/s gemessen).
- OpenSSL
Jahre zuvor hatten wir einen großen Plan, Kryptokarten zu
unterstützen, die RSA/DH/DSA automatisch über OpenSSL-Aufrufe
können. Seit OpenBSD 3.2 funktioniert diese Unterstützung und jede
Karte mit einer solchen Funktionalität, die unterstützt wird, wird
automatisch die Hardware benutzen - einschließlich OpenSSH und dem
httpd im SSL-Modus. An den Applikationen werden keinerlei
Änderungen benötigt.
Wenn jemand beim Schreiben der Treiber helfen will, bitte einfach
herkommen und mithelfen.
Internationale Kryptographen gesucht
Natürlich braucht unser Projekt Leute, die an diesen Systemen arbeiten.
Wenn ein nicht amerikanischer Kryptograph, den die oben erwähnten
Zwänge nicht betreffen, an Mitarbeit an unserer eingebetteten
Kryptographie interessiert ist, soll er uns kontaktieren.
Weitere Quellen
Eine Reihe Leute aus dem OpenBSD-Team haben Vorträge über
die Veränderungen geschrieben, die sie in OpenBSD eingeführt haben.
Die Postscript-Versionen sind hier erhältlich:
- A Future-Adaptable Password Scheme.
Usenix 1999,
von Niels Provos,
David Mazieres.
Papierform und
Folien.
- Cryptography in OpenBSD: An Overview.
Usenix 1999,
von Theo de Raadt,
Niklas Hallqvist,
Artur Grabowski,
Angelos D. Keromytis,
Niels Provos.
Papierform und
Folien.
- Implementing Internet Key Exchange (IKE).
Usenix 2000,
von Niklas Hallqvist und
Angelos D. Keromytis.
Papierform und
Folien.
- Encrypting Virtual Memory.
Usenix Security 2000,
Niels Provos.
Papierform und
Folien.
- The Design of the OpenBSD Cryptographic Framework.
Usenix 2003, von
Angelos D. Keromytis,
Jason L. Wright, und
Theo de Raadt.
Papierform.
- Cryptography As an Operating System Service: A Case Study.
ACM Transactions on Computer Systems,
Februar 2006, von
Angelos D. Keromytis,
Jason L. Wright und
Theo de Raadt.
Papierform.
www@openbsd.org
$OpenBSD: crypto.html,v 1.90 2008/03/09 13:37:10 tobias Exp $