Archiv für den Monat: Januar 2018

Version 3.7 des CP DFN-PKI „Global“, Änderungen an weiteren Dokumenten

Als Ergebnis des letztjährigen Audits der DFN-PKI tritt zum 15.02.2018 eine neue Version 3.7 der Zertifizierungsrichtlinie der DFN-PKI im Sicherheitsniveau „Global“ in Kraft.

Die wichtigsten Änderungen sind im Einzelnen:

  • Neuer Audit-Standard ETSI EN 319 411-1
  • Klarstellungen bzgl. Verbots von E-Mail-Adressen in Serverzertifikaten
  • Klarstellungen bzgl. der Sperrgründe in Kapitel 4.9.1

Das neue CP finden Sie unter der folgenden URL:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.7.pdf

Mit Änderungsmarkierungen:
https://www.pki.dfn.de/fileadmin/PKI/Policy-Archiv/DFN-PKI_CP_V3.7_redline.pdf

Änderungen an den Dokumenten „Pflichten der Teilnehmer“ und „Informationen für Zertifikatinhaber“

In „Pflichten der Teilnehmer“ wurden Regelungen für den Betrieb von Mailgateways aufgenommen. Des Weiteren wurde ein Passus zum regelmäßigen Audit der DFN-PKI „Global“ und die Notwendigkeit der Unterstützung durch die Teilnehmer ergänzt.

In „Informationen für Zertifikatinhaber“ wurden Hinweise für den Betrieb von Mailgateways und zur oben aufgeführten Veröffentlichung von Serverzertifikaten in Certificate Transparency eingeführt.

Die Dokumente finden Sie unter:

https://www.dfn.de/fileadmin/PKI/anleitungen/Pflichten-der-Teilnehmer_V1.3.pdf

https://www.dfn.de/fileadmin/PKI/anleitungen/Informationen-fuer-Zertifikatinhaber_V1.2.pdf

Mit Änderungsmarkierungen:

https://www.dfn.de/fileadmin/PKI/anleitungen/Pflichten-der-Teilnehmer_V1.3_redline.pdf

https://www.dfn.de/fileadmin/PKI/anleitungen/Informationen-fuer-Zertifikatinhaber_V1.2_redline.pdf

(jbr, 30.01.2018)

Certificate Transparency in der DFN-PKI

Als Konsequenz aus Problemen mit den Zertifizierungsprozessen bei einigen CAs, die in den letzten Jahren offenbar wurden, haben Forscher u.a. von Google ein System namens Certificate Transparency (CT) entwickelt.

Hierbei handelt es sich um einen Mechanismus, mit dem ausgestellte Serverzertifikate von einer oder mehreren Sammelpunkten öffentlich einsehbar gehalten werden. Ziel ist die Erhöhung der Transparenz der Browser-PKI durch die komplette Überprüfbarkeit der CAs durch die Öffentlichkeit.

Diese Sammelpunkte sind die Kernkomponenten des Certificate Transparency Systems, sie werden als Certificate Transparency Logs (CT-Logs) bezeichnet und von beliebigen Parteien betrieben. Über kryptographische Beweise (Consistency Proofs über Merkle Hash Trees) ist sichergestellt, dass Außenstehende eine nachträgliche Manipulation des CT-Logs bemerken können.

Einen technischen Überblick über die Funktionsweise bietet https://www.certificate-transparency.org

Weitere Erläuterungen finden sich in folgendem Golem-Artikel (die dort dargestellte Timeline von Google Chrome ist allerdings überholt): https://www.golem.de/news/certificate-transparency-betrug-mit-tsl-zertifikaten-wird-fast-unmoeglich-1610-124024.html

Praktischer Einsatz

Google hat angekündigt, dass sein Browser Chrome ab Frühjahr 2018 erzwingen wird, dass neu ausgestellte Serverzertifikate der öffentlichen Browser-PKI in CT-Logs veröffentlicht werden. Chrome setzt dies um, indem beim TLS-Verbindungsaufbau das Vorhandensein von mehreren sogenannten Signed Certificate Timestamps (SCTs), kryptographisch gesicherte Artefakte von der Veröffentlichung eines Zertifikats, geprüft wird. Können von Chrome keine SCTs geprüft werden, wird die Webseite als unsicher klassifiziert, wobei die genaue Art der Darstellung in Chrome noch unbekannt ist.

Es gehört inzwischen zu den Qualitätsmerkmalen einer PKI, am Certificate Transparency System teilzunehmen und ausgestellte Serverzertifikate über CT-Logs verfügbar zu machen. Auch die DFN-PKI wird selbstverständlich Certificate Transparency unterstützen. Ab 26.02.2018 werden alle Serverzertifikate in der DFN-PKI Sicherheitsniveau Global in CT-Logs veröffentlicht.

Wichtig: Es gibt keine Auswirkungen auf bereits ausgestellte Serverzertifikate! Diese sind nicht betroffen, bleiben nach unserem Kenntnisstand auch in Google Chrome voll gültig und müssen nicht ausgetauscht werden.

Die DFN-PKI wird die folgenden CT-Logs verwenden:
https://plausible.ct.nordu.net
https://mammoth.ct.comodo.com
https://sabre.ct.comodo.com
https://ct.googleapis.com/rocketeer
https://ct.googleapis.com/pilot

(Diese Liste stellt den aktuellen Stand vom Februar 2018 dar. Die von der DFN-PKI verwendeten CT-Logs können sich kurzfristig und ohne Vorankündigung ändern. Zertifikate aus der DFN-PKI können über Uploads von Dritten auch in anderen als den aufgeführten CT-Logs erscheinen. Eine aktuelle Liste ist erhältlich über https://www.pki.dfn.de/faqpki/faqpki-allgemein/#c19130)

Auslieferung von SCTs

Die DFN-PKI stellt die oben erwähnten notwendigen Signed Certificate Timestamps direkt als Erweiterung in den ausgestellten Serverzertifikaten zur Verfügung („Embedded SCT“). Ein Beispiel mit eingebetteten SCTs finden Sie unter: https://crt.sh/?id=313019897

Grundsätzlich gibt es im Certificate Transparency System noch weitere Möglichkeiten, wie die SCTs einem Browser zugänglich gemacht werden können („OCSP Stapling“, „TLS Extension“). Diese anderen Varianten setzen aber üblicherweise Konfigurationseingriffe des Serveradministrators voraus.

Durch die von der DFN-PKI gewählte Variante der Embedded SCT müssen Serveradministratoren keine Änderungen an ihrem System vornehmen.

Zustimmung zur Veröffentlichung

Neben der rein technischen Anbindung, die von der DFN-PKI in den letzten Monaten umgesetzt worden ist, ergibt sich eine Änderung für Antragssteller: Wird ein Serverzertifikat in der DFN-PKI im Sicherheitsniveau Global beantragt, so muss in Zukunft der Antragssteller der Veröffentlichung zustimmen. Ohne diese Zustimmung wird in der DFN-PKI in Zukunft kein Serverzertifikat mehr erstellt werden können.

Des Weiteren ist eine Rücknahme dieser Zustimmung nicht mehr möglich. Technischer Hintergrund: Ein einmal mit Certificate Transparency veröffentlichtes Zertifikat kann technisch nicht mehr „depubliziert“ werden.

Nutzerzertifikate sind selbstverständlich von dieser Änderung nicht betroffen und werden generell nicht durch die DFN-PKI in den CT-Logs veröffentlicht. Je nach Grundeinstellung Ihres PKI-Zugangs sind auch weiterhin nicht-öffentliche Nutzerzertifikate möglich, die damit dann auch nicht über die von der DFN-PKI selbst betriebenen Verzeichnisdienste (LDAP und Web-Suche) veröffentlicht werden. Die gesetzlich vorgeschriebenen Widerrufsmöglichkeiten werden für Nutzerzertifikate natürlich ebenfalls vollumfänglich angeboten.

 (jbr, 30.01.2018)

Löschen privater Schlüssel in Firefox

Firefox speichert die privaten Schlüssel zu importierten Zertifikaten in einer Datenbank im Benutzerprofil. Dabei können zwei unterschiedliche Datenbankformate zur Anwendung kommen: Bisheriger Standard war die Berkeley DB, mit Firefox 58 wird ausschließlich SQLite zum Einsatz kommen.

Löschprobleme

Die aktuell überwiegend verwendete Berkeley DB markiert zu löschende Schlüssel lediglich als gelöscht, statt sie tatsächlich zu entfernen. Ist die DB nicht durch ein Masterpasswort geschützt, lassen sich die Schlüssel nach dem vermeintlichen Löschen weiterhin auslesen. (Die Verwendung eines Masterpassworts ist grundsätzlich ratsam, da die privaten Schlüssel sonst permanent ungeschützt auf der Festplatte liegen.)

In einem einfachen Experiment lässt sich das Problem nachvollziehen:

Unter der besonderen Adresse „about:support“ lässt sich das Profilverzeichnis öffnen; dort findet sich die key3.db, in der Firefox die privaten Schlüssel speichert. Beobachtet man diese Datei in einem Hexeditor, während man ein Zertifikat importiert, stellt man fest, dass sich ein signifikanter Block durch den neu hinzukommenden Schlüssel ändert. Löscht man das Zertifikat wieder, ist der Unterschied nur wenige Bytes groß. Der Schlüssel wird also nicht korrekt entfernt.

Won’t fix

Dieses Verhalten wird von den Entwicklern als Bug eingestuft, aber vermutlich nicht mehr behoben, da neue Firefox-Versionen nicht mehr betroffen sein werden:

https://bugzilla.mozilla.org/show_bug.cgi?id=1413994

Ab Firefox 58 wird eine bestehende Berkeley DB von Firefox auf eine SQLite-DB aktualisiert. Das neue Format hat das Löschproblem nicht mehr, daher wird es auch keine Aktualisierung der zugrunde liegenden Bibliothek geben.

Problematisch ist jedoch, dass bestehende key3.db-Dateien nicht entfernt werden. In langlebigen Profilordnern oder deren archivierten Backups werden also auch noch in einigen Jahren die längst gelöscht geglaubten Schlüssel zu finden sein.

Abhilfe

Der wichtigste Schritt ist das Setzen eines Masterpassworts. Ohne ein Masterpasswort sind die privaten Schlüssel nicht ausreichend geschützt. Denn unabhängig vom identifizierten Bug können ungeschützte private Schlüssel durch forensische Analyse aus früheren Versionen der key3.db von einer Festplatte extrahiert werden.

Das Passwort kann in den Einstellungen unter „Sicherheit“ gesetzt werden. (Direkt erreichbar unter about:preferences#security)

Unabhängig davon, ob ein Masterpasswort aktiv verwendet wird oder nicht, sorgt ein zwischenzeitliches Ändern des Passwortes (falls man kein Masterpasswort verwenden möchte: Aktivieren –> Setzen –> wieder Deaktivieren) für die Verwendung eines neuen Salzes, so dass die Datenbank neu verschlüsselt wird. Gelöschte Schlüssel werden dabei nicht verändert und können mit dem neuen Salz nicht mehr entschlüsselt werden. Daher sorgt eine Änderung des Masterpasswortes dafür, dass gelöschte Schlüssel unzugänglich werden.

Linux-Benutzer können mit folgenden Befehlen auf der Kommandozeile ein neues Masterpasswort setzen:

# Pfad zum Firefoxprofil (bei mehreren Profilen das Sternchen ersetzen)
 profile=~/.mozilla/firefox/*.default
 # Anzeigen vorhandener privater Schlüssel
 certutil -d $profile -K
 # Setzen eines neuen Masterpasswortes
 certutil -d $profile -W

Falls bislang kein Masterpasswort gesetzt war, kann die entsprechende Frage einfach mit Enter beantwortet werden.

Wichtig: Firefox muss vollständig beendet worden sein, bevor versucht wird, mit separaten Programmen wie certutil auf die Datenbank zuzugreifen! Andernfalls kann die Datenbank unwiderruflich beschädigt werden.

Für die Verwendung von certutil gibt es weitere Informationen unter:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_tools_:_certutil

Nach dem Umstieg auf Firefox 58 kann die key3.db gelöscht (eventuell mit vorherigem Backup auf USB-Stick o.ä.) und damit alle potentiellen Altlasten entfernt werden.

(11.01.2018, Finn Nielsen)

ETSI-Audit 2017 abgeschlossen

Auch 2017 wurde die DFN-PKI selbstverständlich auditiert. Im Gegensatz zu den vergangenen Jahren wurde diesmal der Standard ETSI EN 319 411-1 verwendet.

Hintergrund hierfür: Zur Umsetzung der eIDAS-Verordnung wurden die europäischen technischen Richtlinien und Standards für Trust Service Provider durch die ETSI grundlegend umgestaltet. Damit wurde auch die bisherige ETSI TS 102 042, nach der die DFN-PKI bisher auditiert wurde, durch die ETSI EN 319 411-1 abgelöst.

Auch diesmal fanden angekündigte und vorbereitete Besuche bei Teilnehmern der DFN-PKI statt, bei der die Arbeit des Teilnehmerservice stichprobenartig untersucht wurde. Wir bedanken uns wieder bei allen Einrichtungen, die ein erfolgreiches Audit der DFN-PKI  ermöglicht haben!

Die Bescheinigung über das Audit ist auf den Webseiten von TÜViT zu finden: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/6771UD_s.pdf

 

(jbr, 08.01.2017)