HiSolutions Research

Wie lang sollte ein RSA-Schlüssel sein?

Zu dieser Frage herrscht Uneinigkeit in unserer Branche. Das BSI benennt als Anforderung, dass bei TLS-Verbindungen eine RSA-Schlüssellänge von mindestens 3.000 Bits verwendet werden sollte. Die US-Standardisierungsbehörde NIST gibt an, dass RSA-Schlüssellängen mit 2.048 Bit noch bis 2030 als ausreichend sicher gelten.

Wichtig in dieser Diskussion ist, den Anwendungsfall von RSA im TLS-Verfahren zu berücksichtigen. Es wird verwendet, um die Authentizität des Servers gegenüber dem Client zu bestätigen – und im Fall von mTLS auch die des Clients gegenüber dem Server. Obwohl mittels RSA keine Inhalte verschlüsselt werden und ein mögliches Brechen eines RSA-Schlüssels in der Zukunft keine Auswirkungen auf bereits aufgezeichneten verschlüsselten Verkehr hätte (die Anwendung von Perfect-Forward-Secrecy vorausgesetzt), muss die Sicherheit des Signaturverfahrens für die Verwendungsdauer des Schlüssels gewährleistet sein: üblicherweise ein Jahr bei öffentlichen Client/Server-Zertifikaten, ca. 3-5 Jahre bei internen Client/Server-Zertifikaten oder ca. 20-30 Jahre bei CA-Zertifikaten.

Ein Wechsel zu einem Zertifikat mit einem längeren Schlüssel hat nicht nur formale, sondern auch praktische Auswirkungen auf die Leistung des Servers, da mit der Schlüssellänge auch die benötigte Rechenzeit für die Signaturerstellung steigt. Webserver, die viele Verbindungsaufbauten gleichzeitig bedienen, müssen bei einem längeren Schlüssel bei jedem Verbindungsaufbau die aufwendigeren Signaturen erstellen und ggf. Signaturprüfungen durchführen, was zu einer höheren Belastung führen kann. Damit steigt auch das Risiko für DDoS-Attacken bei längeren Schlüsseln.

Dieser Diskurs wirkt auf uns jedoch wenig zielführend. Die Schlüssellänge bei RSA ist ein reiner Wettlauf gegen die Zeit, da klassische Computer immer leistungsstärker werden. Und spätestens mit dem Erscheinen eines kryptografisch relevanten Quantencomputers hat sich das Thema RSA erledigt, da für diesen das Ermitteln des geheimen Schlüssels auf Basis des öffentlichen Schlüssels kein schweres Problem mehr darstellt. Auch wenn elliptische Kurven (ECC) noch zur klassischen asymmetrischen Kryptografie zählen, sollten diese anstelle des RSA-Verfahrens eingesetzt werden, da sie mit geringeren Schlüssellängen auskommen und eine bessere Gesamtperformance bieten. Oder besser, man geht den Weg, den auch die Messenger-App Signal eingeschlagen hat, mit einer Komposition aus ECC und einem PQC-Kandidaten, um gegen kryptografisch relevante Quantencomputer gewappnet zu sein.

Meldung auf heise online: https://www.heise.de/news/Microsoft-RSA-Schluessellaengen-von-2048-Bit-reichen-fuer-TLS-Zertifikate-9657480.html

Wissenschaftliches Paper zum Vergleich von RSA und ECC: https://www.researchgate.net/publication/322558426_RSA_and_ECC_A_comparative_analysis

Blogpost von Signal zu deren PQC-Strategie: https://signal.org/blog/pqxdh/

Kein Ende-zu-Ende gut, alles gut bei E-Mail

Ende-zu-Ende-Verschlüsselung ist heute bei E-Mails faktisch nicht vorhanden. Es gibt dafür zwei große Konzepte bzw. Standards: PGP (inline/MIME) und S/MIME. Doch sowohl mangels intuitiver Verwendung in den gängigsten E-Mail-Anwendungen als auch aufgrund des schlechten Rufs – hauptsächlich in Bezug auf Benutzbarkeit, aber auch auf Sicherheit – finden sie keine große Akzeptanz.

Dann halt WhatsApp?

Die gängigen Messenger sind inzwischen deutlich sicherer als E-Mail. Viele Organisationen scheuen zudem den Aufwand, eine Ende-zu-Ende-Verschlüsselung einzuführen. Sie fürchten einerseits die schlechte Außenwirkung, wenn E-Mails erst nach organisatorischem Aufwand ausgetauscht werden können (Schlüsselaustausch), und andererseits den Verlust von E-Mail-Historie (Backups), wenn Schlüsselmaterial verlorengeht. Auch das Einbinden von Spam- und Viren-Scanner ist keine einfache Angelegenheit. Es herrscht noch immer das Mantra: „Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie.“

Stellt eine Organisation die Möglichkeit, E-Mails verschlüsselt zu senden, als Option zur Verfügung, greifen die Mitarbeiterinnen und Mitarbeiter nur sehr selten darauf zurück. Oft sind es vermeintlich nur “nicht-sensible” Informationen, die ausgetauscht werden. Später, bei kritischeren Daten, heißt es häufig, einmal sei keinmal – bis dann hochsensible Informationen zeitkritisch ausgetauscht werden müssen und keine Zeit mehr für einen Schlüsselaustausch ist.

Pfeiler der Verschlüsselung

Eine gute E-Mail-Verschlüsselung basiert auf drei Pfeilern:

  1. Sichere Software,
  2. Schulung (zur richtigen Verwendung) und
  3. Sensibilisierung (zur Motivation)

Schwächelt nur ein Pfeiler, bricht die ganze Konstruktion zusammen. Gerade die dritte Säule hat einen großen Feind: den Frust. Zu häufig kommt es vor, dass die Gegenseite aus verschiedenen Gründen nicht in der Lage ist, verschlüsselte E-Mail-Kommunikation durchzuführen, während eine unverschlüsselte E-Mail einfach funktioniert.

„Wir haben ein E-Mail-Gateway, das kann das alles.“, ist ein Lösungsansatz, den man öfters mal hört. Es ist richtig, E-Mail-Gateways adressieren einige Schwächen gängiger E-Mail-Anwendungen. Aber intuitive Verwendung ist auch hier Fehlanzeige. Meistens gilt auch hier: Die E-Mail muss raus – und der Schlüsselaustausch verbleibt beim Endanwender. Im Zweifel wird die E-Mail dann doch unverschlüsselt versandt.

Ist eine Verschlüsselung nur optional, kann man aus Versehen unverschlüsselt versenden oder die Notwendigkeit verschlüsselt zu versenden solange hinauszögern, bis eine vertrauliche E-Mail aus zeitlichen Gründen unverschlüsselt versendet werden muss.

Zentrale Qual: S/MIME

S/MIME ist vergleichbar mit HTTPS in folgender Hinsicht: Es braucht eine Welt umspannendes Netz aus PKIs (Public-Key-Infrastrukturen), um gut zu funktionieren.

Was S/MIME im Gegensatz zu HTTPS fehlt, ist ein Schlüsselaustausch-Element. Beim Entwurf von S/MIME (1995) stellte man sich einen Verzeichnisdienst oder eine Verzeichnisdienst-Infrastruktur vor, hatte jedoch die Rechnung ohne den Datenschutz gemacht. Die Alternative zu einem Verzeichnis, sich gegenseitig signierte E-Mails zu senden, kann schnell zu einem größeren Delay führen, wenn nicht beide Parteien gleichzeitig am Rechner sitzen.

Was S/MIME mit HTTPS gemeinsam hat, es werden vertrauenswürdige Zertifizierungsstellen benötigt. Man kann eine eigene Zertifizierungsstelle aufbauen, doch dann hat man das Problem, diese als vertrauenswürdig an alle (auch potentielle) Kommunikationspartner zu verteilen. Hier gibt es keinen einheitlich definierten Weg. Oder man wendet sich an die wenigen öffentlich anerkannten Zertifizierungsstellen, die neben Server-Zertifikaten auch Personen-Zertifikate ausstellen. Diese lassen sich dies jedoch gut bezahlen, vor allem im Vergleich zu Server-Zertifikaten, wo der öffentliche Dienst Let’s Encrypt für einen drastischen Preisverfall gesorgt hat. Ob aber eine öffentlich anerkannte Zertifizierungsstelle wirklich gute Arbeit leistet, ist auch nicht immer sichergestellt. Hier gibt es im Bereich der Server-Zertifikate viele Negativ-Beispiele. Nicht umsonst drohen Größen wie Google, Mozilla und Apple mit dem Rauswurf von Zertifizierungsstellen, wenn diese einmal wieder “Blödsinn” gemacht haben. Nur gibt es eine solche Marktmacht bei S/MIME nicht.

Pretty Bad: PGP

PGP hat von Anfang an auf eine PKI verzichten wollen, kommt aber ohne einen (dezentralen) Verzeichnisdienst auch nicht wirklich aus. Und die Idee eines Web-Of-Trust kann man weitestgehend als gescheitert betrachten, da braucht man noch nicht einmal die Datenschutz-Karte zu zücken:

„Ach ja, ich konnte Deine E-Mail nicht öffnen“ – und das Tage oder Wochen nach dem Versenden der E-Mail und erst auf Nachfrage. Trotz Schlüsselaustauschs. Was ist passiert? Der Empfänger hat seinen Schlüssel „verloren“, sieht aber keine Notwendigkeit zu handeln, weder proaktiv noch reaktiv. Solche E-Mail-Empfänger adressieren ganz klar den Feind „Frust“.

Transportverschlüsselung als Rettung?

„Aber was ist mit der Transportverschlüsselung, da kann doch dann auch keiner mitlesen?“ Das Hauptproblem auch hier: Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie. Schlägt beim Versenden die Zertifikatsprüfung fehlt, wird trotzdem übertragen. Bietet die Gegenstelle keine Verschlüsselung an, wird trotzdem übertragen. Interessanterweise ist es immer erstmal ein Fehler des Senders, wenn eine E-Mail nicht versendet werden kann, auch wenn die Gegenstelle sich nicht an geltende Normen hält. Auch das Thema Sender-Authentizität wird von der Transportverschlüsselung nicht geleistet.