X.509 - Zertifikate

X.509-Zertifikate werden durch das CA-gestützte Management überwacht. Wir führen keine speziellen Kontrollen durch und akzeptieren zunächst alle Zertifikate im automatischen Betrieb. Anwendungsabhängig kann der Nutzer allerdings verlangen, dass eine verifizierte CA das Zertifikat signiert hat oder er es ausdrücklich freigibt.

Angriffe betrachten wir hier nicht, da diese im X.509-Rahmen ausführlich diskutiert werden.

EI - Zertifikate

EI-Zertifikate bilden eine Familie und sind nur dann CA-signiert, wenn dies aus rechtlichen oder verwendungstechnischen Gründen erforderlich ist. Das eröffnet einem Angreifer eine Reihe von Möglichkeiten:

  • Er kann ein gefälschtes Zertifikat der Familie senden, das mit dem EI-Index eines korrekten Zertifikats übereinstimmt.
  • Er kann ein gefälschtes Zertifikat mit einer unbenutzten Sibling-Nr. versenden.
  • Er kann ein gefälschtes Zertifikat mit einer höheren Generation-Nr. versenden.

Da EI-Zertifikate beim ersten Empfang eines Familienmitglied akzeptiert werden, fällt ein Betrugsversuch frühestens dann auf, wenn ein weiteres empfangen wird. Da die Reihenfolge “Angreifer-Inhaber” nicht festgestellt werden kann, kann die Automatik nur bedingt reagieren. Wir halten folgende Logik für zielführend, wenn die Zertifikate verschiedene Indizes besitzen:

  • Das neue Zertifikat ist

    • vom Nutzer als TRUSTED bestätigt,
    • von einer TRUSTED-CA signiert.

    In Verbindung mit weiteren Zertifikaten der Familie wird lediglich die Generationenfolge für die Nutzbarkeit bearbeitet.

  • Das neue Zertifikat wird zusammen mit weiteren Zertifikaten einer bekannten Familie im Rahmen eines UPGRADE durch den Eigentümer, der ein neues Zertifikat auf diesem Weg bekannt machen will, hochgeladen und ist dadurch automatisch TRUSTED.

  • Das neue Zertifikat wird im Rahmen einer Kommunikation hochgeladen und besitzt die gleiche Key-ID wie mindestens eines der vorhandenen. Es stammt somit mutmaßlich vom gleichen Aussteller. Für die Statusfestlegung wird zufällig eines der Zertifikate mit gleicher Key-ID herangezogen.

    • Ist das Referenzzertifikat verwendbar, kann das neue verwendet werden. Es wird jedoch die Generationenfolge überprüft.

    • Ist das Referenzzertifikat nicht verwendbar, wird das neue gesperrt und ein automatischer Upgrade eingeleitet. Eine Generationenprüfung erfolgt nicht.

      Anmerkung: das neue Zertifikat wird automatisch nicht zugelassen, wenn das alte einer alten Generation angehört. Da der Grund für eine neue Generation nicht bekannt ist und auch in einer Schlüsselkompromittierung bestehen kann, darf das neue Zertifikat aus Sicherheitsgründen nicht zugelassen werden.

  • Das neue Zertifikat verwendet einen neuen Schlüssel. Es wird gesperrt und ein automatischer Upgrade eingeleitet.

Wichtig

Ein Upgrade kann durch Anforderung (siehe Text) oder präventiv erfolgen (wenn der Kommunikationspartner Zertifikate bekannt machen will, um Wartezeiten bis zur Anforderung zu vermeiden). Aus den Log-Dateien sind beiden Partner alle Zertifikate, die gesendet oder empfangen wurden, bekannt. Ein Upgrade wird nur akzeptiert, wenn alle bereits bekannten Zertifikate der Familie bestätigt werden. Wird nur ein Teil bestätigt, wird ein neues Zertifikat nicht akzeptiert, da es sich auch um einen Angriff handeln könnte, bei dem der Angreifer nicht über alle geheimen Schlüssel verfügt.

“Doppelte” EI-Zertifikate

Doppelte EI-Zertifikate besitzen die gleiche Kombination ID/Generation/Sibling, aber ansonsten verschiedene Inhalte. Es ist zwar denkbar, dass ein Nutzer durch Fehler so etwas produziert, aber sehr unwahrscheinlich. Eher denkbar sind Angriffe mit gefälschten Zertifikaten. Es kann aber immer nur ein Zertifikat mit einem bestimmten Index in der Datenbank gespeichert werden. Eines muss in die Tabelle “bad_certs” verschoben werden.

  1. Unkritischer Fall: das Zertifikat in der Datenbank ist TRUSTED, das neue nicht. Das neue wird in bad_certs verschoben.
  2. Teilkritischer Fall: das neue Zertifikat ist TRUSTED, das alte nicht. Die Zertifikate werden ausgetauscht, das alte in bad_certs verschoben. Da nun alte Verwendungen in einem anderen Licht erscheinen, ist dieser Fall teilkritisch.
  3. Kritischer Fall: beide Zertifikat sind entweder TRUSTED oder UNTRUSTED. Beide werden mit EI_VORBIDDEN gekennzeichnet. Der Konflikt kann ausschließlich vom User aufgehoben werden.

Overwrite-Funktionen

Wenn Nutzer neue Zertifikate/Zertifikatgenerationen an Kommunikationspartner senden, ist kaum eine Störung der Kommunikation zu erwarten. Allerdings kann dabei das Problem entstehen, dass ein Partner Zertifikate erhält, die “ihn nichts angehen”. Eine Overwrite-Funktion ist daher für das Aussetzen präventiver Upgrades vorzusehen.

In diesem Fall können aber Zustände auftreten, die die Nutzung einer Kommunikationsverbindung verzögern (Upgrade einholen), aber zur Vermeidung von Betrug notwendig sind. Als zweite Overwrite-Funktion können unzulässige Zertifikate durch den Nutzer zugelassen werden, wenn die Anwendungssicherheit das erlaubt.