Das Grundkonzept: EI als X.509 2.0

Motivation und Arbeitsrahmen

Die Elektronische Identität (EI) soll

  • jedem Nutzer die Möglichkeit eröffnen, ohne große Vorkenntnisse und ohne großen Aufwand [1] für Sicherheit in seiner Kommunikation zu sorgen,
  • die Abhängigkeiten von den für normale Nutzer kaum noch zu durchschauenden CA-Betrieb beseitigen,
  • durch Buchführung der Aktivitäten auf vom Nutzer kontrollierten Systemen eine hohe Sicherheit der Authentizität eines Kommunikationspartners gewährleisten.
  • alle Datenströme verschlüsseln.

Die Schnittstellen, an denen das EI-Konzept greifen soll, sind damit die Netzwerkschnittstellen der Geräte des Nutzers. Diese lassen sich in zwei Kategorien unterteilen:

  1. WAN- oder externe Schnittstellen, die mit beliebigen anderen System Daten austauschen können,
  2. LAN-, VPN- oder interne Schnittstellen, die nur mit bestimmten anderen Geräten (in der Regel die des Nutzers) Daten austauschen dürfen. [8]

Das EI-Konzept umfasst nicht die Absicherung der Systeme selbst, wie beispielsweise die Verschlüsselung der Daten auf dem Datenträger oder die Absicherung gegen Malware jeglicher Art.

Das Werkzeug: EI - Zertifikate

Das EI-Konzept setzt auf dem X.509-Zertifikat-Konzept auf, auf dem TLS usw. aufbauen. Zertifikate ermöglichen eine öffentliche Aushandlung geheimer Schlüssel und eine Authentifizierung des Kommunikationspartners. Jedes teilnehmende System muss über mindestens ein EI-Zertifikat verfügen.

Das X.509-Konzept stammt aus dem Jahr 1988, ist also ca. 30 Jahre alt. Das bedeutet, dass

  • man sich um Kinderkrankheiten wenig Gedanken machen muss,
  • auf sehr viel vorhandene Softwaresysteme zurückgegriffen werden kann, was die Einführung eines neuen Systems stark erleichtert,
  • nach 30 Jahren doch einiges an Verkrustung vorhanden ist und ein neues System nicht als Spielerei, sondern als notwendige Reform angesehen werden muss.

EI-Zertifikate sind erweiterte X.509-Zertifikate. Die Erweiterung besteht im Wesentlichen aus spezifischen Ergänzungen im DN-Bereich des Zertifikats. Ein Zertifikat, das diese Ergänzungen aufweist, gilt als EI-Zertifikat, ohne diese Ergänzungen als X.509-Zertifikat.

Da alle Anwendungen, die bereits X.509-Zertifikate verwenden, unbekannte Erweiterungen nicht beachten, können mit EI-Zertifikaten sämtliche bestehenden X.509-Anwendungen bedient werden; umgekehrt kann das EI-Anwendungsschema auch mit X.509-Zertifikaten umgehen, wobei die Funktionalität in diesem Fall auf das X.509-Anwendungsschema beschränkt ist. [9]

Die Erweiterungen bestehen (mindestens) aus den Pflicht-Feldern (OID-Ziffernkombination + Bezeichnung) [10]

2.16.276.99.1:  EI.Identifier
2.16.276.99.2:  EI.Generation
2.16.276.99.3:  EI.Sibling

EI.Identifier bezeichnet eine Familie von EI-Zertifikaten. Ein Identifier ist eine hinreichend lange zufällige Größe, um jede Familie weltweit einmalig kennzeichnen zu können. Eine Familie ist einem Nutzer oder einem Gerät fest zugeordnet, idealerweise lebenslang. Eine Familie kann beliebig viele Zertifikate umfassen, die durch die beiden anderen Feldinhalte gekennzeichnet werden.

EI.Generation bezeichnet eine historische Folge von EI-Zertifikaten. EI-Zertifikate können eine beliebig lange Zeit gültig sein (X.509-Verfallsdatum eines Zertifikats), gültig und verwendbar in einer Familie ist jeoch nur die letzte Generation; alle vorhergehenden Generationen verlieren mit der Erzeugung eines Zertifikats einer neuen Generation automatisch ihre Gültigkeit, unabhängig vom Verfallsdatum. [2]

EI.Sibling bezeichnet verschiedene Zertifikate einer Generation. Aus verschiedenen Gründen ist es nicht möglich/sinnvoll, alle Anwendungen mit einem Zertifikat zu bedienen. Alle Geschwisterzertifikate der neuesten Generation gültig [3]

Wichtig

Eine Kombination muss eindeutig sein.

Hinweis: die Felder werden im X.509-Schema mit Object Identifiern OID gekennzeichnet. Hierbei handelt es sich um ein international verwaltetes eindeutiges Zahlenschema. Die hier verwendeten OID sind vorläufig; ihre Aufnahme in das Normschema ist noch nicht beantragt.

Über die Pflichtfelder hinaus sind weitere Felder optional definiert

2.16.276.99.4:  EI.ConfirmationInterface
2.16.276.99.8:  EI.Owner
2.16.276.99.10: EI.Description
2.16.276.99.11: EI.Restriction

EI.ConfirmationInterface enthält Schnittstellen zum System des Nutzers, mit deren Hilfe Kommunikationspartner verifizieren können, ob vorgelegte EI-Zertifikate dem Nutzer gehören und keine Fälschungen darstellen. Da CA - anders als im X.509-Schema - für Authentifizierungen nicht benutzt werden müssen, muss eine Authentifizierung auch beim Zertifikatinhaber direkt erfolgen können. Wird keine CA-Authentifizierung verwendet, sollte der Nutzer mindestens ein Interface einrichten, um unnötigen Aufwand im Betrieb zu vermeiden.

EI.Owner enthält persönliche Daten des Nutzers. Diese sind zwar teilweise bereits in den DN-Daten des X.509-Bereiches enthalten, die unterschiedlichen Regeln bei der Zertifikatprüfung machen im EI-Schema allerdings ein eigenes übergeordnetes Datenfeld dafür notwendig.

EI.Description kann weitere freie Informationen aufnehmen.

Beide Datenfelder werden zusammen mit EI.Restriction zusätzlich eingesetzt, um eine sichere Authentifizierung in der offline-Kommunikation zu erreichen (offline-Kommunikation: die Kommunikationspartner sind nicht direkt miteinander verbunden und können daher kein Verhandlungsprotokoll durchführen. Beispiel: Email).

Basisregeln für EI-Zertifikate

X.509-Zertifikate sind bestimmten Nutzunsgregeln unterworfen, die in verschiedenen RFC beschrieben sind (und einigen weiteren, die anscheinend auf Gentlemen Agreements der verschiedenen Browserhersteller beruhen). EI-Zertifikate, die in X.509-Umgebungen verwendet werden, müssen diesen Regeln genügen (-> allein hieraus folgt die Notwendigkeit von Geschwisterzertifikaten).

Beispiel: der Nutzungszweck von Zertifikaten ist im X.509-Schema begrenzt. Verschiedene Nutzungszwecke setzen in der Regel unterschiedliche Zertifikate voraus. Auch ist die Nutzungsdauer häufig begrenzt. Im EI-Schema werden dazu verschiedene Zertifikate angelegt, die sich durch ihre Geschwister-ID unterscheiden.

Ändern sich wesentliche Dinge, wird eine neue Generation erzeugt. Technische Gründe können u.a. der Verdacht sein, dass die verwendeten Schlüssel nicht mehr sicher sind. Durch eine neue Generation werden (mit einer Ausnahme) alle Zertifikate der vorhergehenden Generation ungültig, d.h. es müssen möglicherweise in der neuen Generation viele Geschwisterzertifikate erzeugt werden, um die alte Funktionalität zu erreichen.

EI-Zertifikate in EI-Umgebungen sind in der Regel keinen Nutzungsbeschränkungen unterworfen; was das Public-Key-Schema zulässt, darf auch eingesetzt werden. [4] Wo es eine sichere Authentifizierung verlangt, müssen können allerdings bestimmte Regeln vorgegeben werden.

Eine sichere Zuordnung eines Zertifikats zu einer URL oder einem Nutzer wird im X.509-Schema durch entsprechende DN-Bezeichnungen und die CA-Signatur erreicht. Im EI-Schema wird dies durch die Buchführung der Zertifikatnutzung beim Nutzer erreicht, die eine Zertifikatfamilie einer bestimmten URL oder einem Nutzer zuordnet. Die X.509-Felder sind hierbei (weitgehend) unerheblich. Um eine weitere Einschränkung der Nutzung auf bestimmte Zertifikate zu ermöglichen, sind Einträge in den Feldern EI.Owner , EI:Descriptione und EI.Restriction vorgesehen.

EI-Zertifikate können

  • selbstsigniert [5] ,
  • durch X.509-Zertifikate signiert oder
  • durch EI-Zertifikate signiert sein.

In EI-Umgebungen können selbstsignierte oder durch reine X.509-Zertifikate signierte EI-Zertifikate universell eingesetzt werden.

Von EI-Zertifikaten signierte EI-Zertifikate unterliegen der Beschränkung, dass sie ausschließlich für die Kommunikation mit Partnern eingesetzt werden dürfen, die mit dem gleichen Signaturzertifikat signierte Zertifikate vorweisen. Auf diese Weise wird auf Zertifikatebene ein geschlossenes Netzwerk (VPN) definiert, ohne dass zusätzliche Schritte notwendig sind. Die Zertifikate eines geschlossenen Netzwerkes müssen weder der gleichen Familie entstammen noch dem gleichen Inhaber zugeordnet sein. Für solche lokal gültigen Zertifikate gelten fallweise besondere Regeln.

Alle im Rahmen von Kommunikationsvorgängen verwendeten Zertifikate (EI + X.509) werden in einer vom Nutzer kontrollierten Datenbank gespeichert. Die Datenbank ist eine Einwegdatenbank, d.h. einmal aufgenommene Zertifikate können nicht mehr entfernt werden. Dies ist einer der wesentlichen Unterschiede zum bestehenden X.509-Zertifikatschema, in dem Zertifikate nur dann in einer Datenbank gespeichert werden, wenn sie nicht von einer CA signiert sind und vom Nutzer akzeptiert werden. Alle Zertifikate,

  • die mit einem privaten Schlüssel gespeichert werden, gelten als eigene Zertifikate,
  • ohne privaten Schlüssel als Fremdzertifikate.

In einer Familie können entweder eigene oder fremde Zertifikate vorliegen; eine Vermischung ist nicht zulässig.

Jede Verwendung eines Zertifikats wird mit weiteren Informationen (z.B. URL) in einer Log-Datenbank notiert. Die Log-Datei ist (idealerweise) ebenfalls eine Einwegdatenbank. Die Bindung EI-Familie <-> URL erfolgt mit Hilfe der Log-Datenbank. Ist einmal eine Verbindung registriert, wird ein Verbindungsversuch mit der URL und einem Zertifikat einer anderen Familie vom System abgelehnt.

Beispiel: Legt der Server der Seite HTTPS://THIS_SITE.COM ein Zertifikat mit ID=45 vor, zu einem späteren Zeitpunkt aber ein Zertifikat mit ID=4711, lehnt das System die Verbindung ab. Die URL kann so auch ohne CA nicht gestohlen werden. Ev. entstehende Konflikte muss der Nutzer manuell auflösen.

Die Zertifikate können für die Nutzung zugelassen oder gesperrt sein. Die Zulassung oder Sperrung erfolgt nach im Weiteren beschriebenen Regeln. Nicht genau einzuordnende Zertifikate werden in einer zusätzlichen Prüfdatenbank gespeichert, bis ihr Status geklärt ist. Diese Zertifikate können nicht genutzt werden und besitzen keinen Einfluss auf den Zustand der anderen Zertifikate. Ob ein Zertifikat verwendet werden darf oder nicht, unterliegt damit der lokalen Entscheidung eines Nutzers. Grundsätzlich werden zwar auch die Regeln beachtet, die im X.509-Schema gelten, aber es kann trotzdem der Fall eintreten, dass Zertifikate bei unterschiedlichen Nutzern verschiedene Zustände besitzen. Generell sind Zertifikate nicht nutzbar, wenn

  • die Gültigkeitsdauer überschritten ist, [6]
  • das zur Signatur verwendete Zertifikat ungültig ist, [7]
  • ein gültiges Zertifikat einer neueren Generation vorliegt (wobei die Sperre auch dann weitergilt, wenn das Zertifikat der neueren Generation wieder ungültig wird),
  • der Nutzer ein Zertifikat manuell sperrt,
  • das System die Gültigkeit erst überprüfen muss,
  • ein Zertifikat für einen Zweck verwendet werden soll, für das bereits ein anderes Zertifikat registriert ist.

Umgekehrt kann der Nutzer aber auch manuell Vertrauenszustände vergeben, die Systementscheidungen teilweise aufheben. Da verschiedene Sperr- und Zulassungsgründe auftreten und auf verschiedene Zertifikat- und Kommunikationstypen treffen, bedarf das Verwaltungsschema einer ausführlichen Beschreibung, die in den folgenden Abschnitten erfolgt.

[1]Bitte beachten: “ohne großen Aufwand”! Leider ist hier wie im täglichen Leben nichts völlig umsonst zu haben. Einen kleinen Aufwand wirst du treiben müssen. Ob dir das Wenige bereits zu viel oder dir deine Sicherheit der Aufwand wert ist, musst du selbst entscheiden.
[2]Hiervon gibt es Ausnahmen bei bestimmten Nutzungsformen, die in einem späteren Teilkapitel beschrieben werden.
[3]Der Anwender kann einzelne Geschwisterzertifikate o.B.d.A. für ungültig erklären, ohne dass die anderen davon betroffen sind.
[4]Es sei darauf hingewiesen, dass hierbei auch Kombinationen definiert werden können, die im X.509-Anwendungsschema ungültig sind und zu einer Unbenutzbarkeit führen.
[5]Das EI-Schema erlaubt auch die Erzeugung von Zertifikaten mit Public-Key-Systemen, die kein statischen Signaturen erzeugen können, wie beispielsweise den RVB-Algorithmus. Sie Signatur wird in solchen Zertifikaten durch einen unverschlüsselten Hash-Wert ersetzt. Da klassische X.509-Umgebungen die Algorithmen in der Regel nicht unterstützen, können solche EI-Zertifikate nur in EI-Umgebungen verwendet werden, dort jedoch weitgehend wie X.509-Zertifikate behandelt werden.
[6]Für statische Signaturen besteht das Problem, dass ein Zertifikat ablaufen kann, ohne dass das betroffene Dokument ungültig wird. Das gilt generell, also auch für das X.509-Schema, und muss durch spezielle Protokolle behoben werden.
[7]Das betrifft vorzugsweise CA-signierte Zertifikate. Im EI-Schema ist es im Gegensatz zum X.509-Schema aber möglich, dass ungültige Zertifikate wieder gültig werden. In diesem Fall werden abhängige Zertifikate anschließend ebenfalls wieder gültig.
[8]Wie die Bezeichnung andeutet, ist der Begriff “interne Schnittstelle” nicht an ein physikalisches LAN gebunden, sondern beschreibt eher eine erweiterte VPN-Funktionalität (Virtual Private Network).
[9]Damit ein EI-Zertifikat im X.509-Schema eingesetzt werden kann, müssen die restlichen Datenfelder den Regeln für den X.509-Einsatz genügen. Das macht es u.U. notwendig, mehrere EI-Zertifikate für unterschiedliche X.509-Einsatzbereiche zu definieren, obwohl im reinen EI-Betrieb eines genügen würde. Dem wird bei der Definition der EI-Datenfelder bereits Rechnung getragen.
[10]Object Identifier (OID) sind international genormte Kennziffern für bestimmte Daten. Die Struktur der Daten wird mit Hilfe der ASN.1-Notation (Abstract Syntax Notation 1, beschrieben in den Normen X.680 und X.690). Dadurch werden die Daten zu offenen Systemen, die von allen Entwicklern eingesetzt werden können, ohne dass eine Abstimmung untereinander notwendig wird. Auch auf diesen Themenbereich können wir in diesem Rahmen nicht näher eingehen.