Datenbank

Zertifikate

Alle Zertifikate, d.h. reine X.509-Zertifikate und EI-Zertifikate, werden in einer Tabelle mit fortlaufendem Index abgelegt. Ein Löschen der Einträge erfolgt nicht; der durchgehende fortlaufende Index ist Teil der Datenbankintegrität.

Zertifikate, die im Distinguished Name (DN) keine EI-Felder enthalten, werden als reine X.509-Zertifikate interpretiert. Ein Index ist durch die Spalten

  • Subject-DN
  • Subject-Key-ID
  • Gültigkeits-Ende
  • Issuer-DN

definiert. Nach X.509-Schema können sich bei gleichbleibendem DN (= Identifier für einen bestimmten Inhaber) die anderen Felder einzeln ändern, was zu dem recht umfangreichen Index führt.

Enthält ein Zertifikat EI-Felder, handelt es sich um ein EI-Zertifikat mit dem zweiten Index (bei reinen X.509-Zertifikaten wird dieser Index ausgesetzt)

  • EI-Identifier
  • EI-Generation
  • EI-Sibling

Der “Gebrauchswert” eines Zertifikats ist in einer Spalte “status” abgelegt.

Alarme

Zertifikate, die grundsätzliche Regeln verletzen und auf möglichen Betrug hinweisen, werden in der Tabelle “bad_certs” abgelegt. Solche Ereignisse sind vom Nutzer zu bearbeiten, da sie auch zum Sperren von Zertifikaten in der Haupttabelle führen können, die von der Automatik nicht mehr behoben werden können.

Statistik

Jede Verbindung zu anderen Systemen wird mit eigenem Zertifikat, Fremdzertifikat, Arbeitsobjektkennung und Fremdstatus in einer log-Tabelle gespeichert. Die statistische Auswertung hat Einfluss auf die Vertrauenswürdigkeit eines Zertifikats.

Status von Zertifikaten

Eigene/fremde Zertifikate

Eigene Zertifikate sind solche, die mit einem privaten Schlüssel in der Datenbank abgelegt sind. Sie erhalten den Status EI_PRIVATE_KEY_KNOWN.

Fremde Zertifikate besitzen keinen privaten Schlüssel. Formal eigene Zertifikate, für die aus irgendwelchen Gründen kein privater Schlüssel hinterlegt ist, werden grundsätzlich als Fremdzertifikate angesehen.

Ein Fremdzertifikat kann durch Hinzufügen des (gültigen) privaten Schlüssels jederzeit in ein eigenes Zertifikat umgewandelt werden. Ein privater Schlüssel kann nicht entfernt werden.

X.509- oder EI-Status spielt keine Rolle.

Grundregel für EI-Zertifikate

EI-Zertifikate besitzen den Status IS_EI_CERT.

Gültigkeit besitzen ausschließlich Zertifikate der letzten Generation. Sobald eine neue Generation existiert, erhalten alle Zertifikate alter Generationen den Status EI_OLD_GENERATION + EI_USAGE_DENIED.

Der Status wird jedoch nur in dieser Form besetzt, wenn mindestens ein Zertifikat der neuen Generation nicht den Status EI_USAGE_DENIED besitzt.

Bei fremden Zertifikaten muss ausgeschlossen werden, dass durch eine gefälschte neue Generation ein Angriff erfolgt. In solchen Fällen sind zusätzliche Schritte notwendig (siehe unten).

Zertifikatregistrierung

Zur Registrierung werden Zertifikate an die Datenbankschnittstelle übergeben. Die Registrierung betrifft sowohl neue als auch bereits in der Datenbank gespeicherte Zertifikate. Der Arbeitsmodus wird im Übergabestatus mit Status-Werten oberhalb 6000 angegeben.

  • NO_MODE. Die Zertifikate werden von der Kommunikationsschnittstelle übergeben oder manuell hochgeladen. Sie können Status-Informationen des X.509-Prüfsystems enthalten und neu oder bekannt sein. Die Statusinformationen werden nach vorhandenem Datenbankinhalt und nach festgelegten Prioritäten überarbeitet.
  • USER_DEFINED_STATE. Das Vertrauensniveau kann durch den Nutzer ausschließlich an bereits gespeicherten Fremd-Zertifikaten verändert werden. Neue Zertifikate müssen zuvor im Modus NO_MODE hochgeladen werden. Der Nutzer kann folgende Statusinformationen ändern:
    • EI_VORBIDDEN. Diese Zertifikate dürfen nicht verwendet werden. Der Status hat die gleiche Wirkung wie EI_USAGE_DENIED, kann aber ausschließlich vom Nutzer wieder aufgehoben werden.
    • EI_VERIFIED. Die Echtheit des Zertifikats ist vom Nutzer bestätigt. Sofern nicht andere Gründe (Zeit abgelaufen, alte Generation, Rückruf) vorliegen, wird dem Zertifikat unbedingt vertraut.
    • IS_X509_CA. Kennzeichnung eines (reinen) X509-Zertifikats als CA. Das Setzen oder Entfernen dieses Zustands hat Auswirkungen auf andere Zertifikate (siehe Signaturen).
  • EI_AV_NOTIFIED, EI_AV_SEND, EI_UP_NOTIFIED. Für das Zertifikat sind im Rahmen der Automatik externe Bestätigungen notwendig bzw. angefordert bzw. sind auszusenden. Sonst keine Auswirkungen.
  • EI_AV_ANSWER, EI_UP_INCOMING. Antwort auf eine Verifikationsanfrage bzw. automatisches Upgrade durch ein anderes System. Statusinformationen werden außerhalb der normalen Priorität verändert.

X.509-Zustände

Im Rahmen eines Verbindungsaufbaus werden vom Botan-X.509-System eine Reihe von Zuständen vergeben, die ebenfalls notiert werden. Kritische Zustände:

  • CERT_HAS_EXPIRED. Der Status wird auc vom EI-System überprüft und genutzt.
  • CERT_IS_REVOKED. Antworten auf CRL- oder OCSP-Auswertungen. Entspricht in der Wirkung den EI_VORBIDDEN / EI_USAGE_DENIED - Statusinformationen und kann nicht überschrieben werden.
  • CRL_BAD_SIGNATURE, SIGNATURE_ERROR. Entsprechenden Prüfungen werden auch im EI-System durchgeführt. Solche Zertifikate gelangen beim manuellen Import nicht in die Datenbank und werden bei Verbindungen geblockt.
  • Andere Zustände. X.509 blockiert im Normalmodus bei einer Reihe weiterer Zustände während des Verbindungsaufbaus. Im EI-Schema wird die Blockierung in der Regel im automatischen Betrieb aufgehoben. Die Zustände werden jedoch notiert und können von den Anwendungsmanagern berücksichtigt werden.

Signaturen

EI-Zertifikate, die durch ein anderes EI-Zertifikat signiert sind, definieren ein lokales Netzwerk (Status EI_SIGNED_BY_EI).

EI-Zertifkate, die durch ein X.509-Zertifikat signiert sind, sind im globalen Netz verwendbar (Status EI_SIGNED_BY_X509 oder EI_SELF_SIGNED).

X509-Zertifikate können vom Nutzer als CA ausgewiesen werden (Status IS_X509_CA). Damit signierte Zertifikate erhalten den Status EI_CA_VERIFIED, was EI_VERIFIED entspricht (siehe USER_DEFINED_STATE).

Neue Zertifikate

  • X.509-Zertifikate werden mit dem Status EI_USE_30 in die Datenbank aufgenommen. Sie müssen lediglich die nach EI-Regeln abgemilderten Standard-X.509-Prüfungen überstehen. Ihre Nutzung kann nur durch die Anwendungsmanager abgelehnt oder eingeschränkt werden.

  • EI-Zertifikate mit unbekannter EI-Kennung werden wie X.509-Zertifikate behandelt. Für EI-Zertifikate mit bereits bekannter EI-Kennung gelten weitere Regeln:

    • Das Zertifikat ist EI-fremdsigniert und wird akzeptiert. Eine Nutzung ist nur in einem lokalen EI-Netz möglich, d.h. auf das eigene System kann nur zugegriffen werden, wenn dieses ein gültiges EI-Zertifikat mit gleicher Signatur aufweist.
    • Das Zertifikat verwendet einen bereits von anderen Zertifikaten der gleichen EI-ID bekannten Schlüssel. Es wird vorbehaltlos akzeptiert.
    • Das Zertifikat verwendet einen unbekannten Schlüssel. Es könnte sich um einen Angriff handeln. Das Zertifikat wird mit EI_USAGE_DENIED und EI_AV_NOTIFIED markiert und ist vorläufig nicht gültig. Verbindungen werden abgewiesen.

    Gültige neue Zertifikate haben Einfluss auf andere Zertifikate mit der gleiche EI-ID (EI_OLD_GENERATION)

“Bad Certificates”

  1. Ein anderes EI-Zertifikat mit gleichem Index ist bereits in der Datenbank. Das vorhandene Zertifikat wird mit EI_RISKY_USE markiert (und vorläufig nicht genutzt, es sei denn, der Nutzer lässt dies selbst ausdrücklich zu), das neue Zertifikat wird in die bad_certs-Tabelle eingetragen und kann vom Nutzer überprüft werden.

    Da nicht entschieden werden kann, ob das erste oder das zweite Zertifikat das gültige ist, muss der Nutzer selbst tätig werden.

  2. Mehrere andere Zertifikate mit der gleichen EI-ID sind bereits in der Datenbank.

    • Im NO_MODE-Arbeitsmodus wird das vorhandene Zertifikat mit dem gleichen Index wird nicht verändert, das neue in die bad_certs-Datenbank übernommen.
    • Im EI_AV_ANSWER- und EI_UP_INCOMING-Modus wird das neue Zertifikat bestätigt, das alte ist aus eine Fälschung (und sollte normalerweise noch nicht aktiv sein). Das neue Zertifikat ersetzt in der Datenbank das alte, das in die bad_certs-Tabelle übernommen wird.

Verifikation von Zertifikaten

Im EI_AV-Modus sendet das System Kontrollnachrichten an den Partner, sofern dieser eine online- oder email-API anbietet (sonst sind Zustände nur durch Nutzeraktionen zu korrigieren):

ei_identifier[1] ; ei_generation[1] ; ei_sibling[1] ; encrypted_with_public_key[1](random[1])
ei_identifier[2] ; ei_generation[2] ; ei_sibling[2] ; encrypted_with_public_key[2](random[2])
...

Gesendet werden alle bekannten Index-Kennungen. Nicht bekannte Indexkennungen werden nicht abgefragt, um die Privatsphäre des Partners zu gewährleisten. Da dieser über die log-Tabelle weiß, welche Indizes er verwendet hat, kann er das kontrollieren und Nachweise verweigern. Die Antwort enthält zum genauen Vergleich die entschlüsselten Geheimnisse sowie die dazu gehörenden Zertifikate.

Um Stockungen durch Prüfungen zu vermeiden, soll das Management bei neuen EI-Zertifikaten seinerseits präventive Update-Meldungen an seine Partner absetzen:

to_foreign_manager:
-------------------

ei_identifier[1] ; ei_generation[1] ; ei_sibling[1]
ei_identifier[2] ; ei_generation[2] ; ei_sibling[2]
...

from_foreign_manager:
---------------------

ei_identifier[1] ; ei_generation[1] ; ei_sibling[1] ; random[1]
ei_identifier[2] ; ei_generation[2] ; ei_sibling[2] ; random[2]
...

to_foreign_manager:
-------------------
certificate[1] ; encrypted_with_private_key[1](random[1])
certificate[2] ; encrypted_with_private_key[2](random[2])
...

Die Dynamik aus anderer Sicht

Nutzerimportierte Zertifikate

Der Nutzer kann

  • Zertifikate erzeugen,
  • Zertifikate aus externen Quellen (Dateien) importieren,
  • den Zustand bereits vorhandener Zertifikate verändern,
  • private Schlüssel hinzufügen (Zustand EI_PRIVATE_KEY_KNOWN.

Private Schlüssel können nicht mehr entfernt werden. Er hat Rückgriff auf folgende Zustände von Zertifikaten:

  • EI_VORBIDDEN: sperrt ein Zertifikat vor der weiteren Nutzung.
  • EI_VERIFIED: das Zertifikat ist vom Nutzer geprüft und sicher
  • IS_X509_CA: das Zertifikat ist ein Root-Zertifikate einer anerkannten Certificate Authority

Die Zustände können beliebige gesetzt oder entfernt werden.

Ein Zertifikat kann zwei prinzipielle Zustände aufweisen:

TRUSTED. Dem Zertifikat wird vertraut, weil mindestens einer der folgenden Zustände vorliegt:

  • EI_PRIVATE_KEY_KNOWN: der private Schlüssel ist bekannt, es ist ein eigenes Zertifikat
  • EI_VERIFIED: der Nutzer hat sich von der Vertrauenswürdigkeit überzeugt, gleiches gilt für
  • IS_X509_CA,davon abgeleitet:
  • EI_CA_VERIFIED: das Zertifikat ist von einem trusted-Zertifikat signiert und damit implizit trusted (X509-Schema)
  • EI_UPGRADE_VERIFIED:das Zertifikat ist im Rahmen eines automatischen Updates von der Gegenstelle verifiziert worden

DO_NOT_USE. Das Zertifikat darf nicht verwendet werden, unabhängig davon, ob es TRUSTED ist oder nicht. Dazu darf keiner der im Folgenden beschriebenen Zustände gesetzt sein:

  • CERT_HAS_EXPIRED: die Gültigkeitsdauer des Zertifikats ist überschritten (X509). Dieser Zustand kann nicht mehr aufgehoben werden.
  • CERT_IS_REVOKED: das Zertifikat wurde durch eine CRL oder OCSP zurückgezogen (X509)
  • EI_VORBIDDEN: der Nutzer hat das Zertifika gesperrt
  • EI_OLD_GENERATION: das Zertifikat gehört zu einer alten Generation und ist nicht mehr gültig. Der Zustand setzt voraus, dass ein bestätigtes Zertifikat einer höheren Generation vorliegt, das nicht gesperrt ist. Der Zustand kann nicht zurück genommen werden, auch wenn das Zertifikat der höheren Generation gesperrt wird.
  • EI_USAGE_DENIED: das Zertifikat ist noch nicht gültig, weil es noch nicht bestätigt wurde. Der Zustand wird gelöscht, sobald ein Zertifikat den Zustand “TRUSTED” erhält. Es kann aber weiter durch einen anderen Grund gesperrt sein.
  • EI_SIGNED_BY_INVALID_CERT: das signierende Zertifikat ist im Zustand DO_NOT_USE. Dem signierten Zertifikat darf daher auch nicht mehr vertraut werden. Wird das signierende Zertifikat wieder in einen gültigen Zustand versetzt, sind auch rekursiv diese Sperrungen zu beseitigen.
  • EI_UPGRADE_INVALID: ein Zertifikat wurde im Rahmen einer automatischen Prüfung von der Gegenstelle als gefälschtes Zertifikat identifiziert. Dieser Zustand zurück genommen werden, in dem der Nutzer EI_VERIFIED für dieses Zertifikat setzt.

Fehlermöglichkeiten beim Nutzerimport

Bei einem Dateiimport kann der private Schlüssel falsch ausgewählt werden. In diesem Fall wird der Schlüssel nicht importiert, sondern nur das Zertifikat. Der Nutzer hat die Möglichkeit, in einem weiteren Import den Schlüssel hinzuzufügen.

Der Index des zu importierenden Zertifikats ist bereits in der Datenbank vorhanden, die Zertifikate sind jedoch verschieden. Dieser Fall kann beispielsweise auftreten, wenn durch einen vorhergehenden automatischen Importschritt ein gefälschtes Zertifikat importiert wurde, das nun vom Nutzer ersetz werden soll (es sind auch andere Gründe bis hin zu schweren Nutzerfehlern denkbar). Das weitere Vorgehen hängt von den Zuständen der Zertifikate ab:

  • Beide Zertifikate besitzen den gleichen TRUSTED-Zustand (d.h. TRUSTED oder NOT_TRUSTED). Das neue Zertifikat wird in die Tabelle bad_certs verschoben, das alte Zertifikat wird in den Zustand EI_VORBIDDEN versetzt.
  • Das alte Zertifikat ist TRUSTED, das neue nicht: am Zustand des alten Zertifikats ändert sich nichts, das neue wird in die Tabelle bad_certs verschoben.
  • Das neue Zertifikat ist TRUSTED, das alte nicht: das alte wird in die Tabelle bad_certs verschoben, das neue kommt in die Datenbank. Die mit dem alten Zertifikat signierten Zertifikate werden mit EI_SIGNED_BY_INVALID_CERT signiert.

In allen Fällen muss der Nutzer kontrollieren, ob die Automatik die korrekte Entscheidung getroffen hat.

Auswirkungen auf andere Zertifikate

Zertifikate der gleichen EI-ID werden von Statusänderungen nicht berührt. Wenn eine Familie in den Zustand TRUSTED versetzt werden soll, muss dies für jedes Familienmitglied einzeln erfolgen.

Auswirkungen bestehen auf alle mit dem Zertifikat signierten Zertifikate und deren Nachfolgern:

  • TRUSTET <-> UNTRUSTED führt zum Wechsel EI_CA_VERIFIED <-> —
  • VALID <-> UNVALID führt zum Wechsel — <-> EI_SIGNED_BY_INVALID_CERT