crypto-policies - Überblick über systemweite
Krypto-Richtlinien
Die Sicherheit kryptographischer Komponenten des Betriebssystems
bleibt im Laufe der Zeit nicht konstant. Algorithmen, wie kryptographisches
Hashen und Verschlüsseln, haben typischerweise eine Lebensdauer, nach
der sie als zu riskant oder sogar klar unsicher betrachtet werden. Das
bedeutet, das solche Einstellungen aus den Voreinstellungen stufenweise
herausgenommen oder komplett deaktiviert werden müssen, falls sie ein
nicht reparierbares Problem hervorrufen würden.
Während in der Vergangenheit die Algorithmen nicht
konsistent deaktiviert wurden und verschiedene Anwendungen verschiedene
Richtlinien zugrunde legten, erlauben es die systemweiten
Krypto-Richtlinien, denen die Krypto-Kernkomponenten folgen, das konsistente
und systemweite Markieren von Algorithmen als veraltet und deren
Deaktivierung.
Die einzelnen Richtlinienstufen (DEFAULT, LEGACY,
FUTURE und FIPS) sind im Paket crypto-policies(7)
enthalten. In der Zukunft wird es auch einen Mechanismus zur leichten
Erstellung und dem leichten Einsatz von Richtlinien, die vom
Systemadministrator oder einem Drittparteienlieferanten definiert wurden,
geben.
Zur Begründung siehe RFC 7457 für eine Liste
von Angriffen, die Nutzen aus veralteten Kryptoalgorithmen ziehen.
Crypto-policies gelten für die Konfiguration der
kryptographischen Kern-Subsysteme und decken die Protokolle TLS,
IKE, IPSec, DNSSec und Kerberos ab, d.h. die
unterstützten sicheren Kommunikationsprotokolle im grundlegenden
Betriebssystem.
Sobald eine Anwendung im Betriebssystem ausgeführt wird,
folgt sie der Vorgabe oder der ausgewählten Richtlinie und lehnt es
ab, auf Algorithmen und Protokolle zurückzufallen, die nicht
innerhalb der Richtlinie liegen, außer der Anwender hat dies
ausdrücklich erbeten. Das bedeutet, dass die Richtlinie auf das
Standardverhalten der Anwendungen angewandt wird, wenn diese innerhalb der
vom System bereitgestellten Konfiguration betrieben werden, der Benutzer
dies aber für Anwendungen gezielt außer Kraft setzen kann.
Die Richtlinien stellen derzeit Einstellungen für die
folgenden Anwendungen und Bibliotheken bereit:
•BIND-DNS-Nameserver-Daemon
•GnuTLS-TLS-Bibliothek
•OpenJDK-Laufzeitumgebung
•Kerberos 5-Bibliothek
•Libreswan-IPsec- und
IKE-Protokollimplementierung
•NSS-TLS-Bibliothek
•OpenSSH-SSH2-Protokollimplementierung
•OpenSSL-TLS-Bibliothek
•libssh-SSH2-Protokollimplementierung
Anwendungen, die die obigen Bibliotheken und Werkzeuge verwenden,
sind von den kryptographischen Richtlinien abgedeckt, außer dies wird
durch ausdrückliche Konfiguration unterbunden.
LEGACY
Diese Richtlinie stellt die maximale
Kompatibilität mit herkömmlichen Systemen bereit; sie ist
weniger sicher und unterstützt die Protokolle
TLS 1.0,
TLS 1.1 und
SSH2 und neuere. Die Algorithmen
DSA,
3DES und
RC4 sind erlaubt, während die Parameter von
RSA und
Diffie-Hellman akzeptiert werden, wenn sie
größer als 1024 bit sind. Diese Stufe stellt mindestens
64-Bit-Sicherheit bereit.
•MACs: alle HMAC mit SHA-1 oder
besser und alle modernen MACs (Poly1305 usw.)
•Kurven: alle Primzahlen >= 255 bit
(einschließlich Bernstein-Kurven)
•Signaturalgorithmen: mit Hash SHA1 oder
besser (DSA erlaubt)
•TLS-Chiffren: alle verfügbaren
>= 112-bit-Schlüssel, >= 128-bit-Block (einschließlich
RC4 und 3DES)
•Nicht-TLS-Chiffren: wie bei TLS-Chiffren
mit hinzugefügtem Camellia
•Schlüsselaustausch: ECDHE,
RSA, DHE
•DH-Parametergröße: >=
1023
•RSA-Schlüsselgröße:
>= 1023
•DSA-Parametergröße: >=
1023
•TLS-Protokolle: TLS >= 1.0,
DTLS >= 1.0
DEFAULT
Die Richtlinie
DEFAULT ist eine vernünftige
Vorgaberichtlinie gemäß heutigen Standards. Sie erlaubt die
Protokolle
TLS 1.0,
TLS 1.1,
TLS 1.2 und
TLS 1.3
sowie
IKEv2 und
SSH2. Die Parameter von
Diffie-Hellman
werden akzeptiert, falls sie mindestens 1023 bit lang sind. Die Stufe stellt
mindestens 80-Bit-Sicherheit bereit.
•MACs: alle HMAC mit SHA-1 oder
besser und alle modernen MACs (Poly1305 usw.)
•Kurven: alle Primzahlen >= 255 bit
(einschließlich Bernstein-Kurven)
•Signatur-Algorithmen: mit SHA-1-Hash oder
besser (kein DSA)
•TLS-Chiffren: >=
128-bit-Schlüssel, >= 128-bit-Block (AES, ChaCha20,
einschließlich AES-CBC)
•nicht-TLS-Chiffren: wie bei TLS-Chiffren
mit hinzugefügtem Camellia
•Schlüsselaustausch: ECDHE,
RSA, DHE (kein DHE-DSS)
•DH-Parametergröße: >=
1023
•RSA-Schlüsselgrößen:
>= 2048
•TLS-Protokolle: TLS >= 1.0,
DTLS >= 1.0
NEXT
Die
NEXT-Richtlinie ist eine Richtlinie, die
für die zukünftige Veröffentlichung des Betriebssystems
vorbereitet wurde, so dass sie leicht getestet werden kann. Sie erlaubt die
Protokolle
TLS 1.2 und
TLS 1.3 sowie
IKEv2 und
SSH2. Die Parameter für
RSA und
Diffie-Hellman
werden akzeptiert, falls sie größer als 2047 bit sind. Die Stufe
stellt mindestens 112-Bit-Sicherheit bereit, mit der Ausnahme von
SHA-1-Signaturen, die für
DNSSec und andere noch
verbreitete veraltete Anwendung von
SHA-1-Signaturen benötigt
werden.
•MACs: alle HMAC mit SHA-1 oder
besser und alle modernen MACs (Poly1305 usw.)
•Kurven: alle Primzahlen >= 255 bit
(einschließlich Bernstein-Kurven)
•Signatur-Algorithmen: mit SHA-1-Hash oder
besser (kein DSA)
•TLS-Chiffren: >=
128-bit-Schlüssel, >= 128-bit-Block (AES, ChaCha20,
einschließlich AES-CBC)
•nicht-TLS-Chiffren: wie bei TLS-Chiffren
mit hinzugefügtem Camellia
•Schlüsselaustausch: ECDHE,
RSA, DHE (kein DHE-DSS)
•DH-Parametergröße: >=
2048
•RSA-Schlüsselgrößen:
>= 2048
•TLS-Protokolle: TLS >= 1.2,
DTLS >= 1.2
FUTURE
Eine konservative Sicherheitsstufe, von der angenommen
wird, dass sie allen zukünftigen Angriffen in der nächsten Zeit
widerstehen wird. Diese Stufe erlaubt keine Verwendung der
SHA-1-Signaturalgorithmen. Diese Stufe stellt auch einige
(unvollständige) Vorbereitungen für
Post-Quanten-Verschlüsselungsunterstützung in Form von
symmetrischen 256-bit-Verschlüsselungsanforderungen bereit. Die
Parameter für
RSA und
Diffie-Hellman werden akzeptiert,
wenn sie größer als 3071 bit sind. Die Stufe stellt mindestens
128-bit-Sicherheit bereit.
•MACs: alle HMAC mit SHA-256 oder
besser und alle modernen MACs (Poly1305 usw.)
•Kurven: alle Primzahlen >= 255 bit
(einschließlich Bernstein-Kurven)
•Signatur-Algorithmen: mit SHA-256-Hash
oder besser (kein DSA)
•TLS-Chiffren: >=
256-bit-Schlüssel, >= 128-bit-Block, nur Chiffren mit
authentifizierter Verschlüsselung (AE)
•nicht-TLS-Chiffren: wie bei TLS-Chiffren
mit hinzugefügten nicht-AE-Chiffren und Camellia
•Schlüsselaustausch: ECDHE,
DHE (kein DHE-DSS, kein RSA)
•DH-Parametergröße: >=
3072
•RSA-Schlüsselgrößen:
>= 3072
•TLS-Protokolle: TLS >= 1.2,
DTLS >= 1.2
FIPS
Eine Stufe, die die
FIPS 140-2-Anforderungen
erfüllt. Diese Richtlinie wird intern vom Werkzeug
fips-mode-setup(8) verwandt, das das System in den
FIPS
140-2-Konformitätsmodus umschalten kann. Diese Stufe stellt
mindestens 112-bit-Sicherheit bereit.
•MACs: alle HMAC mit SHA1 oder
besser
•Kurven: alle Primzahlen >= 256 bit
•Signatur-Algorithmen: mit SHA-256-Hash
oder besser (kein DSA)
•TLS-Chiffren: >= 128-bit
Schlüssel, >= 128-bit-Block (AES, einschließlich
AES-CBC)
•nicht-TLS-Chiffren: wie bei
TLS-Chiffren
•Schlüsselaustausch: ECDHE,
DHE (kein DHE-DSS, kein RSA)
•DH-Parametergröße: >=
2048
•RSA-Parametergröße: >=
2048
•TLS-Protokolle: TLS >= 1.2,
DTLS >= 1.2
EMPTY
Alle kryptographischen Algorithmen sind deaktiviert (nur
zur Fehlersuche, verwenden Sie das nicht).
Die Kryptorichtlinien-Definitionsdateien haben eine einfache
Syntax, die der Syntax einer INI-Datei Schlüssel =
Wert folgt und folgende besondere Eigenschaften hat:
•Kommentare werden durch ein #-Zeichen
angezeigt. Alles, was diesem Zeichen auf der Zeile folgt, wird
ignoriert.
•Rückwärtsschrägstrichzeichen
\, denen sofort ein Zeilenendezeichen folgt, stellen eine
Zeilenfortführung dar. Die nachfolgende Zeile wird an die aktuelle
Zeile angehängt, nachdem der Rückwärtsschrägstrich
und das Zeilenendezeichen entfernt wurden.
•Gültige Typen können entweder
dezimale Ganzzahlen, beliebige Zeichenketten oder Listen von Zeichenketten
ohne Leerraumzeichen sein, die durch eine beliebige Anzahl von Leerraumzeichen
getrennt werden.
Die erlaubten Schlüssel sind:
•mac: Liste der erlaubten
MAC-Algorithmen
•group: Liste der erlaubten Gruppen oder
elliptischen Kurven für den Schlüsselaustausch
•hash: Liste der erlaubten
kryptographischen Algorithmen für Hashes
(Nachrichtenzusammenfassungen)
•sign: Liste der erlaubten
Signaturalgorithmen
•tls_cipher: Liste der erlaubten
symmetrischen Verschlüsselungsalgorithmen (einschließlich der
Modi) für die Anwendung mit dem TLS-Protokoll
•cipher: Liste der erlaubten symmetrischen
Verschlüsselungsalgorithmen (einschließlich der Modi) für
die Anwendung mit den anderen Protokollen
•key_exchange: Liste der erlaubten
Schlüsselaustauschalgorithmen
•protocol: Liste der erlaubten TLS- und
DTLS-Protokollversionen
•ike_protocol: Liste der erlaubten
IKE-Protokollversionen
•min_tls_version: Niedrigste erlaubte
TLS-Protokollversion
•min_dtls_version: Niedrigste erlaubte
DTLS-Protokollversion
•min_dh_size: Ganzzahlwert der minimalen
Anzahl an Bits der Parameter für den
DH-Schlüsselaustausch
•min_dsa_size: Ganzzahlwert der minimalen
Anzahl an Bits für DSA-Schlüssel
•min_rsa_size: Ganzzahlwert der minimalen
Anzahl an Bits für RSA-Schlüssel
•sha1_in_certs: Wert von 1, falls
SHA1 in Zertifikatssignaturen erlaubt ist und 0 andernfalls (gilt nur
für das GnuTLS Backend)
Die vollständigen Richtliniendateien habe die Endung
.pol, die Richtlinien-Moduldefinitionsdateien haben die Endung
.pmod. In den Richtlinien-Moduldateien müssen nicht alle oben
aufgeführten Werte für alle Schlüssel gesetzt sein.
Die Listen, die in der Grundlage (den vollständigen
Richtlinen) gesetzt sind, werden durch die in den Moduldateien festgelegten
Listen wie folgt verändert:
•-Listeneintrag: Der
Listeneintrag wird aus der in der grundlegenden Datei festgelegten
Liste entfernt.
•+Listeneintrag: Der
Listeneintrag wird am Anfang der in der grundlegenden Datei
festgelegten Liste eingefügt. Die Einfügungen erfolgen in der
Reihenfolge des Auftauchens in der Richtlinienmoduldatei, so dass die
abschließende Reihenfolge in der Liste invertiert sein wird.
•Listeneintrag oder
Listeneintrag+: Der Listeneintrag wird am Ende der in der
grundlegenden Datei festgelegten Liste angehängt.
Werte, die keine Listen sind, werden aus den Richtliniendateien
heraus einfach außer Kraft gesetzt.
update-crypto-policies(8)
Dieser Befehl verwaltet die für die verschiedenen
kryptographischen Backends verfügbaren Richtlinien und erlaubt es dem
Systemverwalter, die aktive Stufe der kryptographischen Richtlinien zu
ändern.
fips-mode-setup(8)
Dieser Befehl erlaubt es dem Systemadministrator, den
System-FIPS-Modus zu aktivieren oder deaktivieren und auch die
kryptographische Richtlinienstufe FIPS anzuwenden, die die erlaubten
Algorithmen und Protokolle auf die in der FIPS 140-2 geforderten
beschränkt.
Ausnahmen:
•Anwendungen in der Sprache Go folgen der
systemweiten Richtlinie noch nicht.
•GnuPG-2-Anwendungen folgen der
systemweiten Richtlinie nicht.
Im Allgemeinen werden nur übertragene Daten bei der
systemweiten Richtlinie abgedeckt.
Falls der Systemadministrator die systemweite Richtlinienstufe mit
dem Befehl update-crypto-policies(8) ändert, wird empfohlen,
das System neu zu starten, da die einzelnen zugrundeliegenden Bibliotheken
ihre Konfigurationsdateien normalerweise während ihrer
Initialisierung lesen. Die Änderungen der Richtlinienstufe finden
daher in den meisten Fällen nur statt, wenn die Anwendungen, die die
zugrundeliegenden Bibliotheken verwenden, neu gestartet werden.
Entfernte Chiffre-Suiten und Protokolle
Die folgenden Chiffre-Suiten und Protokolle sind
vollständig aus den oben aufgeführten kryptographischen
Kern-Bibliotheken entfernt:
•DES
•Alle für den Export geeigneten
Chiffre-Suiten
•MD5 in Signaturen
•SSLv2
•SSLv3
•Alle ECC-Kurven kleiner als 224 bit
•Alle Binärfeld-ECC-Kurven
Chiffren-Suiten und Protokolle, die auf allen
Richtlinien-Stufen deaktiviert sind
Die folgenden Chiffren-Suiten und Protokolle sind
verfügbar, aber in allen Krypto-Richtlinien-Stufen deaktiviert. Sie
können nur durch explizite Konfiguration von einzelnen Anwendungen
aktiviert werden:
•DH mit Parametern < 1024 bit
•RSA mit
Schlüsselgrößen < 1024 bit
•Camellia
•ARIA
•SEED
•IDEA
•Reine Integritäts-Chiffre-Suiten
•TLS CBC-Modus-Chiffre-Suiten, die
SHA-384 HMAC verwenden
•AES-CCM8
•Alle ECC, die inkompatibel zu TLS
1.3 sind, einschließlich secp256k1
•IKEv1
/etc/crypto-policies/back-ends
Die einzelnen kryptographischen
Backend-Konfigurationsdateien. Normalerweise werden sie auf die im Paket
crypto-policies ausgelieferte Konfiguration verlinkt, außer eine
Konfiguration aus local.d wird hinzugefügt.
/etc/crypto-policies/config
Die aktiv auf dem System gesetzte
Krypto-Richtlinien-Stufe.
/etc/crypto-policies/local.d
Zusätzliche Konfiguration, die von anderen Paketen
ausgeliefert oder vom Systemadministrator erstellt wurde. Die Inhalte der
<back-end>-file.config wird an die Konfiguration vom
Richtlinien-Backend, wie es vom Paket crypto-policies ausgeliefert wurde,
angehängt.
Geschrieben von Tomáš Mráz.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von
Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU General
Public License Version 3 oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite
finden, schicken Sie bitte eine E-Mail an die
Mailingliste
der Übersetzer.