Key length versus life time

In Anbetracht der aktuellen Entwicklungen bei Quanten-Computern (siehe auch hier: www.heise.de/tr/artikel/Google-liefert-offizielles-Paper-zur-Quantum-Supremacy-4566013.html) und den Empfehlungen zu Key Length – zu Deutsch Schüssellängen, ein paar Gedanken zu den praktischen Umsetzungen: Nach Kerkhoff’s Maxime sollen lediglich die Schlüssel sicher sein und der Algorithmus gut bekannt und weitgehend untersucht. Also ist die «Wahl» der Schlüssel – mit hardware-basierter Sicherheit und die Schlüssellänge der entscheidende Faktor. Das gilt für die Sicherheit beim Signieren von E-Mails, Dokumenten, der Signierung der Zertifikate und beim zertifikatsbasierten Authentisieren, sowie beim Verschlüsseln von Daten und Netzwerkverkehr und beim Austausch der symmetrischen Schlüssel.

In der Praxis kommen wir oft auf das Thema, dass die Erzeugung oder die Aufbewahrung der Schlüssel nicht so streng gesehen wird. Im Spannungsfeld von Rechenaufwand, Kosten, Zeit und den vorhandenen Möglichkeiten, wird die Sicherheit manchmal ins Abseits gestellt. Auch bei der Länge der Schlüssel wird gern auf die Erfahrungen oder besser die gewohnten Konfigurationen zurückgegriffen. Dabei müssen wir hier doch gerade ein paar Jahre in die Zukunft kalkulieren. Client Zertifikate lassen sich meist noch recht einfach austauschen, da macht die Anzahl und die Art und Weise des Verteilens den Unterschied. Aber bei den Schlüsseln der Zertifizierungsinstanzen (das sind die, die Client Zertifikate signieren und damit deren Gültigkeit bestätigen) ist besondere Sorgfalt geboten. Denn diese Signaturen sollten über mehr Jahre bestand haben, wurden. Wenn diese Schlüssel erneuert werden müssen, weil sie nicht mehr sicher sind, dann konsequenterweise auch deren Client-Zertifikate.

In Diskussionen hört man gern: Wir halten uns einfach an die Richtlinien, die wir in den letzten Jahren oder Jahrzenten entwickelten haben. Wenn es dann nicht mehr gut ist, dann passen wir uns an. Jetzt schon mehr Aufwand und Kosten zu erzeugen, ist nicht sinnvoll.

Hier müssen wir einfach , was denn noch sicher ist, so lange die Zertifikate genutzt werden sollen. Und auch wofür sie genutzt werden. Folgende Kernelemente müssen kritisch hinterfragt werden:

• • für welchen Algorithmus; also asym: RSA, ECC oder symmetrisch: AES, Blowfish, …
  • geforderte Sicherheitslevel; Aufwand zur Entschlüsselung muss grösser als der Werte der Information sein oder man muss sich darauf verlassen können. Eine Netzwerkauthentisierung macht nicht viel Sinn, wenn ich im Zweifel annehmen muss, dass sie manipulierbar ist.
  • Menge der Daten die mit dem Key’s verarbeitet werden,
  • sicher auch die Plattform
  • Die Einsatzzeit, Erneuerung der Keys –> eine digitale Signatur muss unter Umständen auch in vielen Jahren noch safe sein. Bei langfristiger Datenverschlüsselung, z.B. Backup Daten, müssen dies eventuell mindestens 10 Jahre sicher sein oder bei Datenverschlüsselung müssen auch die DEKs ausgetauscht werden.

Bei einem, hoffentlich noch bekannten Brettspiel, hiess das Zwickmühle. Also was ist notwendig und können wir das umsetzen oder uns leisten?

Seit der Erfindung der asymmetrischen Kryptographie in den 1970er Jahren wissen wir, dass die Schlüssellängen angepasste werden müssen. Kerkhoff’s Maxime hin oder her (1883 – immer wieder spannend, wie alt das schon ist), die Schlüssellänge muss nach oben angepasst werden.

Nun sind wir im Jahre 2019 und unter den ersten Quantencomputer mehr denn je gezwungen, über zukünftigen Schlüssellängen nachzudenken und noch bewusster zu entscheiden, wie viel Sicherheit wir definieren müssen. Vor allem definieren wir das für die nächsten Jahre und in einer Kette von Zertifikaten eventuell sogar für mehr als 10 Jahre. Von Jahrzehnten will ich lieber nicht reden. Der Blick in diese Glaskugel bedarf Infrarotlicht-Augen, und die habe ich nicht.

Laut BSI, NIST und ähnlichen Instituten sollen 2022 mehr als 3000 Bits genutzt werden? Naja «irgendwo» habe ich sogar mal 2017 gelesen. Übrigens zwei spannende Links in diesem Zusammenhang für alle, die noch mehr über die Schlüssellänge wissen möchten:

• • en.wikipedia.org/wiki/Key_size
  • www.keylength.com

Vom Wikipedia-Artikel erlaube ich mir, folgende Tabelle zu zitieren:

As of 2016, the NSA’s Commercial National Security Algorithm Suite includes:

Wenn wir heute Schlüssel erzeugen, dann machen wir das meist für viele Jahre in die Zukunft. Vor allem Schlüssel, die in einer Kette Vertrauen schaffen sollen, müssen sicher sein und genau deshalb halten wir uns an die Empfehlungen.

Natürlich können wir dann die Zertifikate erst im Falle des Falles ersetzen. Aber welche Kosten dann entstehen und unter Umständen auch welcher Schaden, das muss in die Überlegungen einfliessen. Spielen wir das mal durch. Wenn wir das Zertifikate der Zertifizierungsinstanz ersetzen müssen, dann auch alle Client Zertifikate, die von dieser Instanz signiert wurden. Im Falle von Automatic Enrolment, also zum Beispiel Client-Computer-Zertifikaten, mag das noch «schnell» gemacht sein. Für alle anderen Host-Zertifikate für interne Web-Server, die manuell ausgestellt wurden, ist der Aufwand ungleich höher und unter Umständen doppelt so teuer. Bei Benutzer-Zertifikaten, die natürlich auf einer Smart Card sind, ist der Aufwand fast nicht mehr kalkulierbar. Der Austausch der Karten oder das Re-Enrolment kann in grösseren Umgebungen, je nach Verfahren, z.B. persönliches Erscheinen, so richtig teuer werden, wenn man Reisen, Arbeitszeitausfall oder eventuell Anschaffung neuer Karten in Kauf nehmen muss.

Mit elliptischen Kurven sieht das wieder etwas entspannter aus, da hier die mathematische Operation etwas komplizierter sind, aber die Schlüssellängen an sich kürzer. Es gibt für die praktische Verwendung eigentlich nur definierte Kurven, die man verwenden kann. P-256, P384 und P-521. Ja zwei-fünf-eins. Alternativen sind in RFC’s definiert, aber müssen nun auch in den Produkten Einzug halten. Da sind Software Produkte wie Browser schneller als die Hardware-Chips. Wichtig ist hier die Kompatibilität, die man vorab prüfen muss. Auch wenn wir seit 2008 die Suite-B, also ECC, als Alternative offiziell nutzen können und diese auch gut bekannt ist, muss man die Verwendung sicherlich genau prüfen. Bei der Anmeldung an einem Rechner ist das recht einfach umzusetzen, nur wenn das Zertifikat dann später für anderes verwendet werden soll, können sich Inkompatibilitäten zeugen. Bei dem Einsatz für Signaturen ist die Frage noch etwas heikler.

Insbesondere die Kompatibilität mit Webbrowsern und ECC P-521 könnte ein Problem sein.

Zum Beispiel aktuell im Browser «ERR_SSL_VERSION_OR_CIPHER_MISMATCH»: code.google.com/p/chromium/issues/detail?id=478225

Für ECC P-256 und P-384 konnte ich die Probleme nicht nachvollziehen.

Und hier noch ein Beispiel für die Herausforderungen mit «neueren» Technologien, insbesondere mit ECC: Golem.de/news/tpm-fail-schluessel-aus-tmp-chips-lassen-sich-extrahieren-1911-144955.html

Also bauen wir so eine Kette mal auf. Wenn 2022 keine Zertifikate mit weniger als 3000 Bits empfohlen werden, dann müssen wir diese Karten also 2022 ersetzen oder wir überlegen heute, ob es Sinn macht, Karten zu kaufen, die schon heute 4096 Bits können. Im Falle von Document-Signing stellt sich die Frage eigentlich nicht. Bei Smart Cards für Authentisierungszwecken kann man das vielleicht noch akzeptieren, wenn keine Regularien einzuhalten sind und man es halt nicht so ganz sicher haben muss, aber für Signaturen an Dokumenten sollten diese auch in 10 oder mehr Jahre vertrauenswürdig sein, auch wenn das Zertifikat vielleicht schon längst abgelaufen ist. Die Signatur der Zertifikate selbst, und damit die Schlüssellängen der CA-Zertifikate müssen die Vertrauenswürdigkeit bieten. Also hier müssen die Schlüssellängen rauf. Oder man wechselt auf EEC.

Auch hier zwei Beispiele: Wenn wir heute DEK – Data Encryptition Key – definieren dann ist die Frage, wie lange diese im Einsatz sein werden. Bei Backups wahrscheinlich 10 Jahre. Dann sind wir mit 128Bit für AES noch gut dran. Es sei denn, in den nächsten 33 Jahre passiert Entscheidendes. Wie hoch ist diese Wahrscheinlichkeit? Ich würde behaupten nahe 1.

Hier ist auch der Zeitraum der entscheidende Faktor. Das Ersetzen ist nicht wirklich ein praktisches Problem, aber man macht das ungern und lieber geplant. Aber 2048 Bits für 3 Jahre für den Schlüsselaustausch/DH-Group würde schon nicht mehr die Empfehlung entsprechen. Wie die Keys gesichert sind ist hier noch die viel spannendere Frage.

Fast ein ähnlicher Fall, da ja die Zertifikate / Keys für die verschlüsselte Kommunikation eingesetzt werden. Wer hat heute schon 4096 Bits für RSA im Einsatz? Die Keys liegen auf einem HSM und nicht einfach plain auf der Festplatte?  Das wäre sicherlich sehr vorbildlich.

• • Bei einer PKI und wenn sie nur für interne Zwecke ist, sollte man auch sorgfältig abwägen und die Konsequenzen bedenken. Wenn man aus Kostengründen oder aus Kompatibilitätsgründen, auf weniger sichere Schlüssel setzt, dann muss man den Plan B vorab zumindest genau definieren. Leider bringt das Leben die Pläne oft genug ins Wanken. Auch das wissen wir vorher.
  • Client-Zertifikate am liebsten 5 Jahre, CA-Zertifikate 10, 20 oder sogar 30 Jahre, am liebsten bis zur Pensionierung. 2048 Bit sind einfach nicht mehr good enough.

• • 4096 Bit sind nach heutiger Betrachtung wirklich gut, aber wie oben angedeutet, wird das nicht so bleiben. Also Life time runter.

Generell sei noch auf einen wirklich guten Artikel von heise.de verwiesen: www.heise.de/security/artikel/Kryptographie-in-der-IT-Empfehlungen-zu-Verschluesselung-und-Verfahren-3221002.html

Background Info: Funktionen und übliche Schlüsselnamen: www.cryptomathic.com/news-events/blog/classification-of-cryptographic-keys-functions-and-properties