Ein Bloomfilter ist eine probabilistische Datenstruktur entwickelt in den 70-iger Jahren von Burton Howard Bloom. Ziel ist es, rechen- und speicherplatzeffizient die Information zu erhalten, ob sich ein Element entweder in einer Menge befindet oder nicht (bspw. gesperrt oder nichtgesperrt). Dabei werden Hashfunktionen auf eine Weise eingesetzt, die dazu führt, dass es zu falschpositiven Antworten kommen kann. Dies akzeptiert man oft bis zu einem bestimmen Maße als Preis für die besondere Effizienz. Durch im Vortrag aufgeführte aktuelle Entwicklungen im PKI-Bereich ist es nun möglich Bloomfilter auf eine bestimmte Weise zu kaskadieren und so zu einer Fehlerrate von null zu gelangen (Larisch et al. 2017).
Warum sind Sperrinformationen wichtig? Durch eine „Public Key Infrastructure“ (PKI) werden durch die Aufführung innerhalb eines Zertifikats verschiedene Attribute (Name, FQDN, Berechtigungsinformationen, Gültigkeitszeiträume, öffentliche Schlüssel etc.) als Tupel aneinander gebunden. Die Attribute in den Zertifikaten bilden eine digitale Identität und die Zertifikate werden durch eine „Certificate Authority“ (CA) ausgegeben. Durch die in der für die CA und die Zertifikatsbeantragenden geltenden „Certificate Policy“ (CP) und „Certification Practice Statement“ (CPS) werden u. a. Maßnahmen zum Schutz der Vertraulichkeit der zu den Zertifikaten zugehörigen privaten Schlüssel definiert. Diese Maßnahmen können leider die privaten Schlüssel nie mit absoluter Sicherheit schützen – es entsteht ein Restrisiko. Um dieses weiter zu minimieren gibt es klassischerweise zwei Maßnahmen. Einerseits kann man die Gültigkeitsdauer der Zertifikate sehr kurz wählen. Bei bestimmten Berechtigungszertifikaten innerhalb der PKI des neuen Personalausweises sind diese bspw. nur zwei Tage gültig. Eine Kompromittierung der privaten Schlüssel hat damit eine zeitlich sehr begrenzte Auswirkung – die Schadenshöhe wird verringert, was letztendlich zu einer Risikoverminderung führt. Andererseits kann man als CA die Sperrbarkeit von Zertifikaten anbieten und die Klienten dazu verpflichten vor der Nutzung eines Zertifikats dieses auf dessen Sperrstatus hin zu prüfen. Die Verbreitung der Sperrinformationen gestaltet sich oftmals als ein besonders problematischer Teil einer PKI. Klassischerweise werden Sperrinformationen über „Certificate Revocation List“ (CRL) oder über das „Online Certificate Status Protocol“ (OCSP) verteilt. Probleme der Verfügbarkeit dieser Sperrinformationen in der Praxis führen dazu, dass aktuelle Webbrowser, die über TLS gesichert Daten abrufen (HTTPS), oft ganz oder teilweise auf das Abrufen der Sperrinformationen verzichten. Damit wird nicht das erwünschte Sicherheitsniveau (d. h. das gewünschte akzeptable Risikoniveau) erreicht.
Man wünscht sich, dass Sperrinformationen (insbesondere bei interaktiven Anwendungen, bspw. bei Webbrowsern) immer sofort für alle möglichen Zertifikate verfügbar sind. Und dies möglichst lokal damit weniger unerwünschte Informationen über das Nutzungsverhalten abfließen. Für die Sicherung von TLS/HTTPS im Internet sind viele Millionen X.509-Zertifikate ausgegeben worden. Rund 30 Millionen davon sind aktuell zeitlich gültig. Davon sind rund 12 Millionen gesperrt worden. Will man dafür alle Sperrinformationen mit einer klassischen CRL verteilen, benötigt man rund 3 GiB Speicherplatz, was für die meisten Klienten (bspw. Smartphones) sowohl in Bezug auf die Verteilung als auch auf die dezentrale Speicherung zu viel ist. Mit dem Ansatz über kaskadierte Bloomfilter (Larisch et al. 2017) erreicht man diese Informationsverteilung mittels 10 MiB bzw. rund 580 KiB tägliche Aktualisierung der Datenstruktur. Damit wird es erstmals praktikabel für große Public-Key Infrastrukturen mit Millionen von Zertifikaten vollständig dezentral Sperrinformation vorzuhalten und regelmäßig (bspw. täglich) zu aktualisieren.
Das Grundprinzip der kaskadierten Bloomfilter ist auch außerhalb von PKI-Sperrinformationen interessant. Es ist leicht übertragbar auf Anwendungsfälle bei denen ja/nein-Informationen zu einer Vielzahl von Objekten innerhalb einer abgeschlossenen Menge sowohl rechen- als auch speicherplatzeffizient dezentral verfügbar gemacht werden sollen.
Literatur:
CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers
James Larisch, David Choffnes, Dave Levin, Bruce M. Maggs, Alan Mislove, Christo Wilson
2017
Session Category : IT-Sicherheit in der Praxis