Zertifikatslaufzeiten und Schlüssellängen in einer PKI

[joseph_halter 0]

Hallo zusammen,

 

diese Dokumente: https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr02102/tr02102_node.html

Davon kann man ableiten, dass, wenn man eine RSA-Verschlüsselung mit Länge 2000 Bit einsetzt, man nach Empfehlung des BSI "sicher" verschlüsselt (bis Ende 2023).

Wenn man beispielsweise intern zig Webserver betreibt und dafür alle Zertifikate firmenintern selber ausstellt, ist das schon eine Performance-relevante Entscheidung, ob man RSA 2048 Bit oder RSA 4096 Bit benutzt, also eine Kostenfrage.

Viele Fragen aber bleiben noch ungeklärt. Mich beschäftigen vorallem folgende Fragen, die ich euch gerne stellen würde.

Gibt es Empfehlungen des BSI zu Laufzeiten von Zertifikaten? Eben auch zu Stammzertifizierungsstellenzertifikaten?

Falls nein: Was sind eure Empfehlungen? Was sind eure Quellen dieser Empfehlungen? Große Schlüssellängen und kurze Laufzeiten bedeuten ja oft mehr Kosten. Selbst wenn automatisiert verteilt wird, verursacht das Netzwerktraffic und Rechnerbelastung. Das muss man begründen. Gibt es irgendwo eine zentrale Website zu diesem Thema, die auch aktualisiert wird mit solchen Empfehlungen? Eine verständliche Seite, die die wichtigsten Daten wie empfohlene Laufzeit, etc. zusammenfasst?

 

Einfache Empfehlung die beispielsweise sagt: rootCA = RSA4096 Bit, max. 10 Jahre, subCA = RSA4096 Bit ohne dass man gleich ein ganzes Buch lesen muss.

 

Wie lange wählt ihr die Gültigkeitsdauer euer Zertifizierungsstellenzertifikate in einer ein- oder zweistufigen PKI? Wie handhabt ihr eure Verschlüsselungstechnologien und Schlüssellängen in euren Unternehmen?

Wie lange sind eure internen Webserverzertifikate gültig?

 

Mich interessiert vor allem wie ihr das ganze begründet wenn einer kritisch fragt. Sorry für die vielen Fragen.

 

Grüße

bearbeitet 19. November 2020 von joseph_halter
Singular war falsch, jetzt steht da Plural

[NilsK 2.957]

Moin,

 

ich glaube, bezüglich der Performance hast du falsche Vorstellungen. Ein Zertifikat mit 4096 Bit auszustellen (was heute übliche Empfehlung ist), ist keine ernsthafte Herausforderung. Ein CA-Server ist typischerweise nicht groß dimensioniert, die meisten Kunden betreiben sowas als eine eher kleine VM. 

 

Die Zertifikatslaufzeit berechnet man normalerweise rückwärts, ausgehend von der maximalen Laufzeit der Endzertifikate. Eine typische Rechnung geht so:

• Laufzeit ausgestellter Zertifikate nicht über 2 Jahre (wobei der typische Wert darunter liegt, etwa 1/2 oder 1 Jahr; manchmal auch nur Wochen oder Tage)
• Die Issuing CA soll Zertifikate mindestens einmal verlängern können, bevor ihr eigenes Zertifikat ausläuft, also: Lifetime Issuing CA = 2 * Laufzeit Zertifikat + Puffer; im Beispiel also: 2 * 2 Jahre + 1 Jahr = 5 Jahre
• Genauso auch die Root CA, deren Zertifikat es auch zulassen soll, die CA-Zertifikate einmal zu verlängern: Lifetime Root CA = 2 * Laufzeit Issuing CA + Puffer; also: 2 * 5 Jahre + 1 Jahr = 11 Jahre

Wichtig ist, dass das Design der PKI zu den Anforderungen des Unternehmens passt und dass man die Technik einordnen kann. Eine interne CA setzt man praktisch nur noch für interne Zwecke ein, extern erreichbare Systeme versorgt man mit kommerziellen Zertifikaten oder per Let's Encrypt. Die Laufzeit eines (internen) Webserver-Zertifikats ist dann weniger kritisch, wobei ich da heute auch nicht mehr über 1 Jahr setzen würde, eher weniger. Der Bequemlichkeitsgewinn durch lange Laufzeiten rächt sich zumeist durch mangelnde Routine mit dem Wechselvorgang.

 

Gruß, Nils

 

[Dukel 455]

Laufzeit des Root Zertifikats = Zeit bis zur Rente + x Jahre Puffer ;)

bearbeitet 19. November 2020 von Dukel

[joseph_halter 0]

vor 8 Stunden schrieb NilsK:

Moin,

 

ich glaube, bezüglich der Performance hast du falsche Vorstellungen. Ein Zertifikat mit 4096 Bit auszustellen (was heute übliche Empfehlung ist), ist keine ernsthafte Herausforderung. Ein CA-Server ist typischerweise nicht groß dimensioniert, die meisten Kunden betreiben sowas als eine eher kleine VM. 

 

Die Zertifikatslaufzeit berechnet man normalerweise rückwärts, ausgehend von der maximalen Laufzeit der Endzertifikate. Eine typische Rechnung geht so:

• Laufzeit ausgestellter Zertifikate nicht über 2 Jahre (wobei der typische Wert darunter liegt, etwa 1/2 oder 1 Jahr; manchmal auch nur Wochen oder Tage)
• Die Issuing CA soll Zertifikate mindestens einmal verlängern können, bevor ihr eigenes Zertifikat ausläuft, also: Lifetime Issuing CA = 2 * Laufzeit Zertifikat + Puffer; im Beispiel also: 2 * 2 Jahre + 1 Jahr = 5 Jahre
• Genauso auch die Root CA, deren Zertifikat es auch zulassen soll, die CA-Zertifikate einmal zu verlängern: Lifetime Root CA = 2 * Laufzeit Issuing CA + Puffer; also: 2 * 5 Jahre + 1 Jahr = 11 Jahre

Wichtig ist, dass das Design der PKI zu den Anforderungen des Unternehmens passt und dass man die Technik einordnen kann. Eine interne CA setzt man praktisch nur noch für interne Zwecke ein, extern erreichbare Systeme versorgt man mit kommerziellen Zertifikaten oder per Let's Encrypt. Die Laufzeit eines (internen) Webserver-Zertifikats ist dann weniger kritisch, wobei ich da heute auch nicht mehr über 1 Jahr setzen würde, eher weniger. Der Bequemlichkeitsgewinn durch lange Laufzeiten rächt sich zumeist durch mangelnde Routine mit dem Wechselvorgang.

 

Gruß, Nils

 

Ich danke dir, das ist deutlich.

 

In einem modernen, internen Netzwerk mit hunderten Clients, einigen Appliances und vielen VPN-S2S-Tunnel meinst du also, dass es von der Netzwerkperformance her kein Problem ist, alle RSA-Zertifikate auch für interne Webserver (ungefähr 50 interne Webserver) auf 4096 Bit zu heben?

 

Was für Quellen fügst du zu deinen Empfehlungen oben an, wenn jemand kritisch ist und diese Laufzeiten länger haben will. Worauf beziehst du dich da außer dass es "Best Practice" ist?

bearbeitet 20. November 2020 von joseph_halter

[NorbertFe 2.061]

vor 1 Stunde schrieb joseph_halter:

Was für Quellen fügst du zu deinen Empfehlungen oben an, wenn jemand kritisch ist und diese Laufzeiten länger haben will.

Fragst du dann nicht kritisch zurück? Mal ehrlich, schau dir doch einfach mal die öffentlichen pki Zertifikate an. Da wirst du dann ähnliche Laufzeiten der CAs finden. Und serverzertifikate werden seit einiger Zeit nur noch Jahresweise ausgestellt. Wenn dir also jemand so kritische Fragen stellt, kennt er sich vermutlich gut genug aus, dass man sich mit ihm zur Diskussion hinsetzen kann.

 

ansonsten ist bei 4096 Bit zu berücksichtigen, dass alle Server und Clients das auch unterstützen müssen.

 

aber in einem modernen Netzwerk ist das sicherlich der Fall. Akkulaufzeit berücksichtige ich hier mal nicht. ;)

[NilsK 2.957]

Moin,

 

vor 2 Stunden schrieb joseph_halter:

dass es von der Netzwerkperformance her kein Problem ist

das "Netzwerk" hat damit nun überhaupt nichts zu tun. Und die Zahl an Zertfikatsempfängern, die du angibst, ist gering, nicht hoch. Das sind gerade mal ein paar hundert Zertifikate, die werden ja nicht alle auf einmal ausgestellt. Und selbst wenn - es wäre ja kein Problem, wenn das "ein paar Minuten" dauert. Wir reden hier ja von einmaligen Vorgängen, die sich normalerweise nur alle paar Wochen, Monate oder noch seltener abspielen. Die Verzögerung in dem Prozess ist auch organisatorisch, denn jemand (oder etwas) muss das Zertifikat ja genehmigen. Das Erzeugen spielt da zeitlich keine Rolle.

 

Behalte auch im Kopf, dass asymmetrische Verschlüsselung nicht für Massendaten eingesetzt wird, sondern nur für den Schlüsselaustausch (fast ausschließlich). Die VPN-Session selbst (oder der Web-Traffic, die Dateiverschlüsselung, ... usw.) wird symmetrisch verschlüsselt, das geht viel schneller. Und der Schlüssel dafür wird eben asymmetrisch verschlüsselt.

 

vor 2 Stunden schrieb joseph_halter:

Was für Quellen fügst du zu deinen Empfehlungen oben an, wenn jemand kritisch ist und diese Laufzeiten länger haben will.

Gar keine, solche Fragen hat mir an der Stelle noch niemand gestellt. Auch nicht im Finanzsektor oder in der Atomindustrie. Abgesehen davon, ist das dermaßen "Best Practice", dass das niemandem fragwürdig erscheint, der die Materie kennt.

 

Gruß, Nils

PS. ich habe mir gerade mal dieses gruselige BSI-Papier angesehen, das sicher zu einem der schlimmsten aus dem Hause zählt. Abgesehen davon, dass man dort die relevanten Informationen geschickt zwischen akademischem Blabla versteckt (das in dem Papier nichts zu suchen hat), sind die Aussagen zur Laufzeit von Zertifikaten alle nur "sollte"-Angaben. Daraus ergibt sich also nicht mal für die Organisationen eine Verpflichtung, die sich den Maßnahmen unterwerfen. Die Jahreszahlen, die dort angegeben sind, beziehen sich auf den Einsatz vom Schlüsseln "geringer" Länge, also auf konkrete Verschlüsselungsvorgänge (das hat mit Zertifikatslaufzeiten nichts zu tun). Selbst das ist aber nur theoretisch hergeleitet.

bearbeitet 20. November 2020 von NilsK

[joseph_halter 0]

Danke euch. Ja klar. Bei uns gibt es intern die Weisung, sich an die Empfehlungen des BSI zu halten. Da ich zur Gültigkeitsdauer von Zertifikaten da nicht wirklich was finde...bzw. ok, es gibt eine Website zu öffentlichen PKIs mit Sicherheitsstandard "Hoch", aber das sind wir nicht.

 

Aber jetzt kann ich mich an eure Empfehlungen halten. Wegen den 4096Bit RSA-Keys habe ich in irgendeinem Online-Artikel zu PKIs gelesen, dass man sich bewusst sein soll, dass bei der Verwendung dieser Keys höhere Leistung und auch Netzwerkleistung benötigt wird. Ich frage mich aber irgendwie auch, was damit gemeint sein soll. 4Kibibit sind ja nicht gerade sehr viele Daten zu übertragen und wenn der Key eh nur am Anfang der Übertragung für den Schlüsselaustausch genutzt wird...?

bearbeitet 20. November 2020 von joseph_halter

[NilsK 2.957]

Moin,

 

möglicherweise ein sehr alter Artikel. Man liest auch oft noch Kompatibilitätsbedenken zu 4096-Bit-Schlüsseln, wie Norbert es ja oben auch angemerkt hat. Tatsächlich habe ich aber schon jahrelang keine Geräte mehr bei Kunden angetroffen, die das nicht gekonnt hätten. Solche Pauschalbedenken halten sich aber gern ewig.

 

Die Einwände, die man wirklich zu PKI haben kann, beziehen sich einerseits auf die konzeptionellen Grundlagen (aus meiner Sicht ist das ganze Prinzip "krank" und nicht vertrauenswürdig, aber wir haben nichts Besseres) und vor allem auf die organisatorische Umsetzung. Mit Zertifikaten wird einfach unglaublich geschlurt, und dann sollte man es lieber ganz bleiben lassen. Wer die passenden Prozesse nicht festlegen und einhalten kann, sollte einfach keine PKI betreiben.

 

Gruß, Nils

 

[mwiederkehr 382]

vor 30 Minuten schrieb joseph_halter:

Wegen den 4096Bit RSA-Keys habe ich in irgendeinem Online-Artikel zu PKIs gelesen, dass man sich bewusst sein soll, dass bei der Verwendung dieser Keys höhere Leistung und auch Netzwerkleistung benötigt wird. Ich frage mich aber irgendwie auch, was damit gemeint sein soll. 4Kibibit sind ja nicht gerade sehr viele Daten zu übertragen und wenn der Key eh nur am Anfang der Übertragung für den Schlüsselaustausch genutzt wird...?

Je länger der Key, desto länger dauert der Handshake für den Schlüsselaustausch. Der Unterschied zwischen 2048 und 4096 Bit ist messbar, aber nicht spürbar: https://expeditedsecurity.com/blog/measuring-ssl-rsa-keys/

 

Wenn Du nicht gerade den Load Balancer für google.com oder facebook.com betreibst, ist die Schlüssellänge bezüglich Performance nicht relevant.

[NilsK 2.957]

Moin,

 

vor 12 Minuten schrieb mwiederkehr:

Je länger der Key, desto länger dauert der Handshake für den Schlüsselaustausch.

ach schau. Auf die Betrachtung wäre ich gar nicht gekommen. Danke für den Hinweis.

 

vor 12 Minuten schrieb mwiederkehr:

Wenn Du nicht gerade den Load Balancer für google.com oder facebook.com betreibst

Und das könnte der Grund sein, warum ich so nicht gedacht habe. 

 

Gruß, Nils