Systemweite Crypto-Policies in CentOS

Einführung und Begriffe

RHEL/CentOS 8 unterstützt systemweite Crypto-Policies: einmal festgelegt, werden die gewählten Verschlüsselungsalgorithmen, Ciphers, MACs etc. von einer steigenden Zahl an Bibliotheken und damit Programmen verwendet. Die Einrichtung ist zudem denkbar einfach und ohne Spezial-KnowHow mit nur einem Kommando machbar. Damit entfällt in vielen Teilen die unterschiedliche Crypto-Konfiguration einzelner Server-Prozesse. Steigen die Anforderungen an die Sicherheit, bringt ein Kommando das gesamte System auf einen neuen Stand.

Der Befehl dafür lautet update-crypto-policies. Der Befehl generiert Crypto-Policies in /etc/crypto-policies/back-ends, die bereits von folgenden Bibliotheken verwendet werden:

  • BIND

  • GnuTLS library

  • Libkrb5

  • Libreswan

  • NSS library

  • OpenJDK

  • OpenSSH

  • OpenSSL library

Anwendungen und Sprachen, die diese Bibliotheken verwenden, folgen damit automatisch den System-Policies. Beispiele dafür sind Apache httpd, Nginx, PHP und andere.

Tipp

Crypto-Policies für SSH werden durch ein Include-File bereitgestellt - bei der Konfiguration des SSH-Daemons sollte man dies zwecks Anwendungsreihenfolge der Parameter im Hinterkopf behalten.

Unter CentOS 8 sind vier Crypto-Policies definiert:

  • LEGACY: Maximale Kompatibilität zu Altsystemen

  • DEFAULT: Kompromiss zwischen Sicherheit und Kompatibilität

  • FIPS: Compliant zu FIPS140-2

  • FUTURE: Aktuell höchste Sicherheitsstufe, ältere Clients werden sich nicht mehr verbinden können

Diese Policies sind „one-size-fits-all“. Eine feinere Anpassung ist möglich, es lassen sich aber auch eigene Crypto-Policies auf der grünen Wiese erstellen.

Unter CentOS 8 sind folgende Ciphersuites und Protokolle nicht mehr verfügbar:

  • All binary field ECC curves (since RHEL 6)

  • All ECC curves < 224 bits (since RHEL 6)

  • All export grade cipher suites (since RHEL 7)

  • DES (since RHEL 7)

  • MD5 in signatures (since RHEL 7)

  • SSLv2 (since RHEL 7)

  • SSLv3 (since RHEL 8)

Noch möglich, aber in allen Policies abgeschaltet:

  • DH with parameters < 1024 bits

  • RSA with key size < 1024 bits

  • Camellia

  • ARIA

  • SEED

  • IDEA

  • Integrity-only cipher suites

  • TLS CBC mode cipher suites using SHA-384 HMAC

  • AES-CCM8

  • All ECC curves incompatible with TLS 1.3, including secp256k1

  • IKEv1 (since RHEL 8)

Siehe auch

Crypto-Policies im Vergleich

LEGACY

DEFAULT

FIPS

FUTURE

3DES

yes

no

no

no

CBC mode ciphers

yes

yes

yes

no

DH

min. 1024-bit

min. 2048-bit

min. 2048-bit

min. 3072-bit

DSA

yes

no

no

no

IKEv1

no

no

no

no

RC4

yes

no

no

no

RSA

min. 1024-bit

min. 2048-bit

min. 2048-bit

min. 3072-bit

SHA-1 and SHA-224 signatures in certificates

yes

yes

yes

no

SHA-1 in digital signatures

yes

yes

no

no

Symmetric ciphers with keys < 256 bits

yes

yes

yes

no

TLS v1.0

yes

no

no

no

TLS v1.1

yes

no

no

no

Crypto-Policy setzen

Welche Crypto-Policy wird gerade verwendet?

update-crypto-policies --show

Crypto-Policy auf FUTURE setzen:

update-crypto-policies --set FUTURE
reboot
update-crypto-policies --show

Crypto-Policy auf FIPS setzen:

fips-mode-setup --enable
# Kernel initramdisks are being regenerated. This might take some time.
reboot
fips-mode-setup --check

Achtung

Das EPEL-Repository funktioniert Stand 2020-12 unter der FUTURE Crypto-Policy nicht. Fehlermeldung: SSL certificate problem: CA certificate key too weak. Das Problem ist, dass RSA-Keys > 3072 Bit verlangt werden. Das Zertifikat auf https://download.fedoraproject.org erfüllt dies, dessen Intermediate-Zertifikate von digicert jedoch nicht (diese sind bei 2048 Bit).

Die einzelnen Crypto-Settings lassen sich in den Policy-Dateien einsehen:

cat /usr/share/crypto-policies/policies/FUTURE.pol

Crypto-Policy anpassen

Erst ab CentOS 8.2 möglich: Um eine bestehende Crypto-Policy anzupassen, müssen sogenannte Modifier-Dateien mit der Endung pmod und grossgeschriebenem Dateinamen (!!) in /etc/crypto-policies/policies/modules abgelegt werden.

Im Beispiel sollen in der DEFAULT-Policy die Key-Exchange-Mechanismen RSA und PSK abgeschaltet werden, da sie keine Perfect-Forward-Secrecy unterstützen. Zusätzlich werden noch weitere Veränderungen an der Crypto-Policy vorgenommen:

/etc/crypto-policies/policies/modules/PFS-KEX.pmod
key_exchange = -RSA -PSK
/etc/crypto-policies/policies/modules/MYCRYPTO1.pmod
sha1_in_certs = 0
min_rsa_size = 3072
/etc/crypto-policies/policies/modules/NO-CAMELLIA.pmod
cipher = -CAMELLIA-256-GCM -CAMELLIA-256-CBC -CAMELLIA-128-GCM -CAMELLIA-128-CBC
update-crypto-policies --show
# DEFAULT
update-crypto-policies --set DEFAULT:PFS-KEX:MYCRYPTO1:NO-CAMELLIA
reboot
update-crypto-policies --show

Tipp

Am nachvollziehbarsten ist es, beispielsweise /usr/share/crypto-policies/policies/FUTURE.pol nach /etc/crypto-policies/policies/modules/LINUXFABRIK.pmod zu kopieren, anzupassen und diese per update-crypto-policies --set FUTURE:LINUXFABRIK zu verwenden.


Know How

Kryptographische Protokolle

Eine grobe Zusammenfassung, was die Protokolle ausmacht und was sie voneinander unterscheidet.

Secure Sockets Layer (SSL)

Ursprünglich 1994 für die Absicherung von HTTP durch Netscape entwickelt, wofür es bis heute hauptsächlich eingesetzt wird. Der Aufruf „https://“ führt zu einem „HTTP auf einer SSL-Schicht“. SSL ist jedoch nicht spezifisch auf HTTP zugeschnitten, sondern wird auch unterhalb von IMAP, POP3, SMTP usw. verwendet. Die SSL-Versionen 2 und 3 gelten als unsicher. Auf ihren Einsatz sollte verzichtet werden.

Transport Layer Security (TLS)

TLS v1.0 enstand 1999 und meldet sich im Header als „SSL v3.1“. Die konkrete Implementierung OpenSSL bietet unter anderem das Kommandozeilenprogramm openssl zum Beantragen, Erzeugen und Verwalten von Zertifikaten. Die Funktionsweise ist zweigeteilt.

  1. Authentifizierung:
    Der Server identifiziert sich gegenüber dem Client mit einem X.509-Zertifikat. Der Client überprüft die Vertrauenswürdigkeit des X.509-Zertifikats gegen eine Public-Key-Infrastruktur (PKI) und ob der Servername mit dem im Zertifikat übereinstimmt. Der Client identifiziert sich optional mit einem eigenen Zertifikat (das sogenannte „two-way SSL“).
  2. Verschlüsselung:
    Je nach Serverkonfiguration sendet der Client dem Server eine mit dem öffentlichen Schlüssel des Servers verschlüsselte geheime Zufallszahl, oder beide berechnen mit dem Diffie-Hellman-Schlüsselaustausch ein gemeinsames Geheimnis, aus dem ein kryptographischer Schlüssel abgeleitet wird. Die gesamte nachfolgende Kommunikation wird mit Hilfe des Schlüssels und nach Aushandlung eines Algorithmus wie AES, 3DES, Arcfour etc. verschlüsselt und zum Schutz von Nachrichten-Integrität und -Authentizität mit einem „Message Authentication Code“ (MAC) abgesichert.
Secure Shell (SSH)

Das seit 1995 entwickelte SSH ist ein auf TCP aufsetzendes Transport- und Benutzerauthentifizierungsprotokoll plus eine Sammlung an Tools. Es wird meist dazu genutzt, eine entfernte Kommandozeile lokal zu verwenden, Dateien auf einen entfernten Rechner zu senden oder von diesem zu kopieren. Die Funktionsweise ist auch hier zweigeteilt.

  1. Authentifizierung:
    Der Server identifiziert sich gegenüber dem Client mit einem RSA-, DSA- oder ECDSA-Zertifikat. Der Client identifiziert sich mit einem Passwort oder per Public Key Authentifizierungsmethode (mit einem privaten Schlüssel; sein öffentlicher Schlüssel ist auf dem Server hinterlegt). Private Schlüssel können zusätzlich mit einem Passwort geschützt werden. Weitere Elemente wie YubiKey können zur Authentifizierung hinzugezogen werden.
  2. Verschlüsselung:
    Die gesamte nachfolgende Kommunikation wird nach Erzeugung eines geheimen Schlüssels und Aushandlung eines Algorithmus wie AES, 3DES, Arcfour etc. verschlüsselt und zum Schutz von Nachrichten-Integrität und Authentizität mit einem MAC abgesichert.

SSL/TLS ist nicht mit SSH zu verwechseln:

  • Eine TLS Server-Authentifizierung ist immer optional. Das Protokoll unterstützt auch einen voll-anonymen Betrieb, bei dem sich keine Seite identifizieren muss. Solche Verbindungen sind anfällig für Man-in-the-Middle-Attacken. Im SSH Transport Layer ist die Server-Authentifizierung Pflicht, was gegen solche Attacken schützt. Zwar könnte ein Client die Prüfung des öffentlichen Serverschlüssels z.B. per .ssh/known_hosts überspringen, trotzdem muss das bewusst implementiert werden.

  • TLS authentifiziert Clients und Server mittels X.509-Zertifikaten. Im Vergleich zu SSH erschwert dies den Einsatz von TLS in der Praxis, da es eine funktionierende PKI voraussetzt. Zudem sind Zertifikate komplizierter zu erstellen und zu verwalten; dafür bietet eine PKI ein skalierbares Schlüsselmanagement, was SSH fehlt.

  • TLS bietet nur „Public Key“ als Client-Authentifizierungsmethode, also bei weitem nicht die Bandbreite wie SSH.

  • TLS kann mit dem Funktionsumfang von SSH nicht mithalten: das SSH Connection Protocol (SSH-CONN) verwendet einen darunterliegenden SSH Transport Layer (SSH-TRANS), um einer Anwendung mehrere logische Datenkanäle zu multiplexen sowie die Möglichkeit zur entfernten Ausführung von Programmen, Terminal-Management, getunnelte TCP-Verbindungen, Flow Control etc. zur Verfügung zu stellen. Werden solche Techniken mit TLS verwendet, ist es kombiniert mit einem anderen Protokoll (z.B. eine HTTP-basierte Passwort-Authentifizierung in einem SSL-Tunnel).

  • Beispiel aus der Praxis ist der Unterschied zwischen SFTP und FTPS. SFTP ist SSL-basiertes FTP und wird vom OpenSSH-Daemon umgesetzt - für einen Linux-Server perfekt, auf einem Windows-Server schwierig. Sicheres FTP unter Windows ist meist als FTPS implementiert, also FTP über SSL (Gespann IIS und IE).

Die Gemeinsamkeiten zwischen SSL/TLS und SSH:

  • Beide bieten einen Full-Duplex Byte-Stream zu ihren Clients mit kryptographisch abgesicherter Verschlüsselung und Datenintegrität sowie optionaler Benutzerauthentifizierung - in grossen Teilen auf Basis der gleichen Verschlüsselungsalgorithmen.

  • Unter Linux wird OpenSSL benötigt, um OpenSSH zu compilieren - jedoch nur, weil OpenSSH Verschlüsselungsbibliotheken aus OpenSSL verwendet; sonst hat OpenSSH nichts mit OpenSSL zu tun.

Schlüsselaustauschverfahren

Andere Begriffe: Key Exchange, Kx, Kex, Handshake Encryption, Key Agreement Protocol

Gängige Verfahren für den Schlüsselaustausch sind:

  • 1976. Diffie-Hellman-Schlüsselaustausch. Beide Partner senden sich über einen unsicheren Kanal eine Nachricht und berechnen mit Hilfe mathematischer Funktionen den geheimen Schlüssel, die in die eine Richtung (für die Gesprächspartner) schnell, zurück dagegen (für Man-in-the-Middle) nur mit grösstem Aufwand ermittelbar sind. Heute wird die Nachricht mit grossen Primzahlen und diskreten Logarithmen berechnet, zur Verhinderung von Man-in-the Middle-Attacken digital signiert und mit einem MAC abgesichert. Kann im Gegensatz zu RSA nicht dazu verwendet werden, Zertifikate zu signieren.
  • ECDH:
    Elliptic Curve Diffie-Hellman. DH-Implementierung mittels elliptischer Kurven. Gruppen auf bestimmten elliptischen Kurven eignen sich für eine effiziente Berechnung von Potenzen, die das Diffie-Hellman-Problem schwer lösbar machen.
  • ECDH/ECDSA:
    Elliptic Curve Diffie–Hellman / Elliptic Curve Digital Signature Algorithm. Bietet Forward Secrecy.
  • Kerberos.
  • Pre-shared Key. Schlüssel sind vor der Kommunikation beiden Teilnehmern bekannt, zum Beispiel im WLAN (Verschlüsselungsmethode WPA-PSK). Im Internet aufgrund der notwendigen Schlüsselverteilung nicht einsetzbar, hier werden Public-Key-Verfahren eingesetzt.
  • 1977. War das erste veröffentlichte asymmetrische Verschlüsselungsverfahren überhaupt, entwickelt am MIT. Die Firma RSA Security hat eine schlüsselsignierende Certificate Authority etabliert, die 1995 zu Verisign wurde - in 2013 mit einem Umsatz von knapp 1 Mrd. Dollar. Auch wenn RSA als wahres Multitalent neben Schlüsselaustausch und Authentifizierung noch zur Verschlüsselung eingesetzt werden kann, ist es im Vergleich zu Verfahren wie 3DES und AES mindestens um den Faktor 1000 langsamer. In der Praxis wird RSA daher meist nur zum Austausch eines Schlüssels für die symmetrische Verschlüsselung benutzt (und kommt auch als Verschlüsselungsverfahren unter RHEL / CentOS nicht vor). Für die Verschlüsselung der Daten werden andere Verfahren eingesetzt.

Warnung

SSL-abgesicherte Web-, Mail-, SSH- und VPN-Server verwenden bei DHE_EXPORT die ursprünglich von der US-Regierung abgeschwächten, für den Export zugelassenen Methoden - das heisst, Server und Client dürfen sich damit auf nur 512 Bit breite Primzahlen beschränken, die auf fast allen Systemen auch noch aus nur zweien ausgewählt wird.

Die auf den DH-Algorithmus zielende Logjam-Attacke von Ende Mai 2015 nutzt den Umstand, dass man eine bekannte Primzahl im Vorfeld der Attacke bereits so zerlegen kann, dass der Rechenaufwand zur Rückberechnung des Sitzungschlüssels extrem sinkt (im Schnitt 90 Sekunden).

Abhilfe: Primzahlen ab 2048 Bit Länge verwenden, oder auf DHE verzichten und auf Diffie-Hellman mit elliptischen Kurven (ECDH) umsteigen, dem ein gänzlich anderes mathematisches Problem zugrundeliegt.

Verschlüsselungsverfahren

Andere Begriffe: Cipher, Chiffre, Encoding, Enc

Die Verschlüsselung ist eine Funktion, die abhängig von einem Schlüssel einen Klartext in einen Geheimtext überführt. Mit der Umkehrfunktion erhält man aus dem Geheimtext wieder den Klartext. Verschlüsselungs-Algorithmen unterteilen sich in symmetrische und asymmetrische Methoden.

Symmetrische Verschlüsselungsverfahren

Bei symmetrischen Algorithmen besitzen beide Kommunikationspartner denselben Schlüssel und müssen diesen vor Beginn der Kommunikation sicher ausgetauscht haben (zum Beispiel mittels Diffie-Hellman-Schlüsselaustausch oder der Zusendung per Post). Der Schlüssel wird zur Verschlüsselung als auch zur Entschlüsselung verwendet. Typische Schlüssellängen sind z.B. 128, 192 oder 256 Bit.

Bemerkung

Das symmetrische Verschlüsselungsverfahren AES mit 128 Bit Schlüssellänge und das asymmetrische Verfahren RSA mit 2048 Bit Schlüssellänge werden 2015 als (gerade) noch ausreichend sicher betrachtet. Es wird empfohlen, AES mit 256 Bit und RSA mit 4096 Bit zu verwenden, falls besonders schützenswerte Daten abgesichert werden müssen.

Symmetrische Verfahren können Klartext auf zwei Arten verschlüsseln:

  1. Bei der Blockverschlüsselung (Block Siphers) wird der Klartext vor der Verschlüsselung in Blöcke gleicher Grösse aufgeteilt. Zu kleine Blöcke werden durch bedeutungslose Zeichen aufgefüllt, so dass sie eine höhere Übertragungskapazität in Anspruch nehmen. Eine typische Blockgrösse ist z.B. 128 Bit. Ein Verschlüsselungsalgorithmus beschreibt zunächst nur, wie ein Block verarbeitet wird. Zur Verarbeitung einer Nachricht beliebiger Länge lassen sich Blockchiffres in verschiedenen Betriebsmodi verwenden. Beispiele für Betriebsmodi („Mode of Operation“) sind:

    • Authenticated Encryption with Associated Data. Algorithmentypen, die verhindern, dass auf jede beliebige Nachricht die Entschlüsselung angewendet werden kann (z.B. aus Angreifer-Sicht einem „Decryption Oracle“ Brute Force Nachrichten zur Entschlüsselung senden, um diese zu analysieren) - nur korrekt nach Schema verschlüsselte Nachrichten können entschlüsselt werden. Konkrete Verteter dieses Betriebsmodus sind:
      • Counter with CBC-MAC; kombiniert den Counter Mode zur Verschlüsselung mit dem CBC-MAC-Modus zur Integritätssicherung
      • Carter–Wegman with CTR Mode; kombiniert den CTR Mode zur Verschlüsselung mit dem polynomialen Carter–Wegman MAC.
      • 2003. Kombiniert den CTR Mode zur Verschlüsselung mit dem OMAC.
      • Galois/Counter Mode; 2004. Basiert auf CTR, auf Parallelität und hohen Datendurchsatz ausgelegt. Kommt auch in Festplatten zum Einsatz. Die GCM-Operation benötigt vier Eingabewerte: einen geheimen Schlüssel, einen Initialisierungsvektor, den Klartext und einen Wert für „additional authenticated data“ (AAD). Er liefert zwei Ergebnisse, den Chiffretext (gleich lang wie der Klartext) und ein Autorisierungs-Tag.
      • Integrity Aware Parallelizable Mode. War der erste Modus, der Verschlüsselung und Integritätssicherung in einem Schritt erledigte. Verdrängt durch GCM.
      • Offset Codebook Mode; 2001. Erledigt Verschlüsselung und Integritätssicherung in einem Schritt. Verdrängt durch GCM.
    • Cipher Block Chaining; aus dem Jahr 1976. Der Block wird per XOR (exklusives Oder) verknüpft. Sehr gut bei nicht-zufälligen (also alltäglichen) Inhalten. Zerstört Klartextmuster, identische Klartextblöcke ergeben unterschiedliche Geheimtexte, erschwert Angriffe, ist aber anfällig für den Plaintext Recovery Attack, wird daher durch den Vulnerability-Scanner „Nessus“ von Tenable bemängelt.
    • Electronic Codebook; aufgrund von konzeptionellen Schwächen nicht empfohlener Betriebsmodus, da die verschlüsselten Blöcke unter Umständen Rückschlüsse auf die Originalnachricht zulassen. In RHEL nicht verfügbar.
    • One-key MAC; ähnlich wie CBC. Patentfrei, free for all use.
  2. Bei der Stromverschlüsselung (Stream Ciphers) wird der Klartext zeichen- oder bitweise verschlüsselt. Folgende Betriebsmodi schalten eine Blockverschlüsselung in eine Stromverschlüsselung um:

    • Cipher Feedback; ähnlich wie CBC. Klartext wird bitweise XOR (exklusives ODER) verknüpft.
    • Counter Mode. Klartext wird bitweise XOR (exklusives ODER) verknüpft. Der Unterschied zu anderen liegt in der Verknüpfung einer Zufallszahl pro Chiffrat mit einem Zähler.
    • Output Feedback. Klartext wird bitweise XOR (exklusives ODER) verknüpft.

In RHEL / CentOS an der einen oder anderen Stelle verwendete symmetrische Algorithmen sind:

  • 3DES, TripleDES:
    1998. Dreifach-DES-Verschlüsselung mit drei unabhängigen, voneinander verschiedenen Schlüsseln. Schlüssellänge 168 („3des(168)“), 112 or 56 Bit, Blockgrösse 64 Bit.
  • 1998. Seit dem Jahr 2000 ist der hinter dem „Advanced Encryption Standard“ steckende Rijndael-Algorithmus ein FIPS. In Intel- und AMD-Prozessoren sind Befehlsinstruktionen für AES nutzbar. Schlüssellänge 128 („aes128“), 192 („aes192“) oder 256 Bit („aes256“). Bei den CBC-Varianten beträgt die Blockgrösse 128 Bit.
  • AESGCM:
    2008/2009. AES mit implizitem AEAD-Modus GCM. Hochgradig performant. In TLS erst ab Version 1.2 verfügbar.
  • Blowfish (BF):
    1993. Blockverschlüsselung; Schlüssellänge zwischen 32 und 448 Bit (Standard 128 Bit), Blockgrösse 64 Bit. Frei verwendbar, sehr sicher, langsam.
  • 2000. Durch Mitsubishi Japan entwickelte Blockverschlüsselung. Wird seit Firefox 37 nicht mehr unterstützt (wichtig bei Einsatz in einem Webserver wie Apache). Schlüssellänge 128, 192 oder 256 Bit, Blockgrösse 128 Bit.
  • CAST-128, CAST5:
    1996. CAST5 ist eine alternative Bezeichnung für CAST-128. Schlüssellänge 40 bis 128 Bit, Blockgrösse 64 Bit.
  • 1977. Data Encryption Standard. Blockverschlüsselung; Schlüssellänge 56 Bit, Blockgrösse 64 Bit. DES gilt seit 1999 als kompromittiert, auf den Einsatz sollte verzichtet werden.
  • 1991. International Data Encryption Algorithm. Projekt der ETH Zürich und der Ascom Systec AG. Von PES abgeleitete Blockverschlüsselung. Schlüssellänge 128 Bit, Blockgrösse 64 Bit.
  • 1987. Schlüssellänge 8 bis 1024 Bit (Standard: 64 Bit), Blockgrösse 64 Bit. Die Schlüssel sind aus heutiger Sicht zu kurz, auf den Einsatz von RC2 sollte verzichtet werden.
  • RC4, ARCFOUR, ARC4:
    1987. „Rivest Cipher 4“ (RC4) ist ein kommerzielles Produkt sowie ein eingetragenes Warenzeichen, daher wird, um Trademark-Probleme zu vermeiden, oft von ARCFOUR bzw. ARC4 geredet. Das ursprünglich geheimgehaltene Protokoll wurde 1987 geleakt. Stromverschlüsselung, Schlüssellänge zwischen 40 und 2048 Bit. Mozilla und Microsoft empfehlen aufgrund von Schwachstellen, auf RC4 / ARCFOUR zu verzichten; PuTTY, SSLLabs und Nessus monieren ebenfalls den Einsatz von RC4. Im Februar 2015 wurde RFC 7465 veröffentlicht, der RC4 für Verschlüsselung verbietet.
  • 1998. Wurde im Jahre 2000 als Ersatz für DES zum Advanced Encryption Standard (AES) der US-Behörden erhoben, Details siehe AES.
  • 1998. Koreanische Blockverschlüsselung, ausserhalb Südkoreas kaum anzutreffen, wird in Webbrowsern auch nicht unterstützt (wurde in Firefox 27 entfernt). Schlüssellänge 128 Bit, Blockgrösse 128 Bit.

Asymmetrische Verschlüsselungsverfahren

Bei einem asymmetrischen „Public-Key-Kryptosystem“ benötigen die kommunizierenden Parteien keinen gemeinsamen geheimen Schlüssel. Ein Benutzer erzeugt hier ein Schlüsselpaar, das aus einem geheimen Teil (privater Schlüssel) und einem nicht geheimen Teil (öffentlicher Schlüssel) besteht.

Die Verfahren werden beispielsweise in SSH, TLS und im E-Mail-Verkehr (OpenPGP, S/MIME) angewendet.

Signierung und Authentifizierung

Andere Begriffe: Au

Diese Algorithmen dienen der Schlüsselerzeugung und Authentifizierung.

  • Digital Signature Algorithm. Entworfen von der NSA (FIPS 186-2). DSA benötigt sehr viele und sehr gute Zufallszahlen, was nicht in allen Umgebungen gewährleistet ist. Zudem müssen DSA-Schlüssel exakt 1024 Bit lang sein.
  • 1991. „Digital Signature Standard“ der NIST. Der Standard umfasst DSA, ECDSA und RSA.
  • ECDH

  • Übertragung des DSA auf elliptische Kurven. Die ECDSA-Schlüssellänge kann 256, 384 oder 521 (richtig gelesen: 521) Bit betragen (entspricht der Grösse der elliptischen Kurve).
  • KRB5

  • PSK

  • RSA:
    768 Bit breite Schlüssel wurden geknackt, bis ins Jahr 2019 sind Schlüssel mit einer Mindestlänge von 1976 Bit geeignet, empfohlen sind mindestens 2048 Bit.

Datenintegritätsverfahren

Andere Begriffe: MACs, Hash, Message Digest, Digest Algorithms, Hash Function

Ein „Message Authentication Code“ (MAC) sichert den Ursprung von Daten und prüft ihre Integrität. MAC-Algorithmen erfordern zwei Eingabeparameter, erstens die zu schützenden Daten und zweitens einen geheimen Schlüssel, und berechnen aus beidem eine Prüfsumme, den Message Authentication Code.

  • 1991. Message-Digest Algorithm 5. Erzeugt auf heutigen Systemen sehr performant einen 128 Bit breiten Hashwert. Gilt in kryptografischen Verfahren als nicht mehr sicher, da es mit überschaubarem Aufwand möglich ist, unterschiedliche Nachrichten zu erzeugen, die den gleichen MD5-Hashwert aufweisen.
  • 1996. In Belgien offen entwickelte, kryptographische Hash-Funktion. Erzeugt 128, 160, 256 oder 320 Bit breite Hashes.
  • SHA-1 / SHA1:
    1993. Von der NSA entwickelt. Erzeugt 160 Bit breite Hashes. Gilt seit 2005 als kompromittiert. Microsoft Windows und Mozilla Firefox werden ab 2017 SHA-1-Zertifikate über SSL nicht mehr akzeptieren, simpleSAMLphp erlaubt SHA-1 seit dem 01.01.2014 nicht mehr.
  • Hash-Funktion mit 256 Bit breitem Hashwert. SHA256 ist ein Vertreter aus der Gruppe der kryptographischen SHA-2-Funktionen (Nachfolger von SHA-1). Von der NSA entwickelt.
  • SHA384:
    wie SHA256, jedoch mit 384 Bit breitem Hashwert.

MAC-Verfahren werden unterschiedlich klassifiziert:

  • Keyed-Hash MAC. Das MAC-Verfahren basiert auf einer kryptographischen Funktion und wird auch so benannt, z.B. „hmac-md5“.
  • MAC based on Universal Hashing. Der MAC wird aus einer Gruppe von MAC-Verfahren nach einem geheimen, zufälligen Prozess ausgewählt.

Reihenfolge MAC-Berechnung vs. Verschlüsselung

Was sollte zuerst erfolgen - die MAC-Berechnung und dann die Verschlüsselung, oder umgekehrt? Siehe auch den Wikipedia-Artikel zum Thema Authenticated Encryption.

  • MAC-then-Encrypt:
    Hash auf den Klartext berechnen, an den Klartext anhängen, dann beides zusammen verschlüsseln (Standard in TLS - war eine Fehlentscheidung beim Design; so wurde Padding Oracle POODLE möglich)
  • Encrypt-and-MAC:
    Hash auf den Klartext berechnen, Klartext verschlüsseln, Hash anhängen (Standard in SSH)
  • Encrypt-then-MAC (etm):
    Klartext verschlüsseln, Hash berechnen und anhängen (Standard in IPSec)

Encrypt-then-MAC (etm) ist in den meisten Fällen das ideale Szenario. Änderungen am verschlüsselten Text können ohne gültigen MAC schon vor der Entschlüsselung verworfen werden. Der MAC kann ausserdem nicht verwendet werden, um auf den Klartext zu schliessen.

MAC-then-Encrypt ist sicher, wenn die Verschlüsselungsfunktion im CBC- oder allgemein im Stream-Modus arbeitet; ansonsten könnten bei MAC-then-Encrypt und Encrypt-and-MAC aufgrund der auf den Klartext angewendeten MAC-Funktion Daten rekonstruiert werden.