Das Key Management Interoperability Protocol (KMIP) bietet einen einheitlichen Standard für die Kommunikation zwischen einem Key Lifecycle Management System (KLMS) und dessen Clients. Dadurch kann eine zentrale Schlüsselverwaltung eingesetzt werden und die Datensicherheit erhöht werden. Das Protokoll wird von der OASIS standardisiert.[1]
Protokolldefinition
In der KMIP-Spezifikation wird definiert, wie eine Nachricht aussehen muss und welche Informationen ausgetauscht werden können.[2] Einige Funktionalitäten von Client und Server, zum Beispiel die Fehlerbehandlung, werden vorgegeben. Andere können wie gewünscht umgesetzt werden. Ein Client oder Server muss nicht die vollständige, im Protokoll definierte Funktionalität umsetzen, sondern nur die tatsächlich benötigte.[3] Die Protokoll-Spezifikation gibt den Port 5696[4] vor, nicht aber wie die Authentifizierung zwischen Client und Server abläuft. Allerdings werden in einem zugehörigen Dokument zwei Authentifizierungs-Profile beschrieben. Bei beiden Profilen werden Versionen des TLS verwendet. TLS dient nicht nur der Authentifizierung, es stellt auch die Integrität der Daten sicher.[5]
Objekte
Bei den Objekten wird zwischen Base Objects (Basisobjekten) und Managed Objects (verwalteten Objekten) unterschieden. Base Objects sind Informationen, die ein Managed Object spezifizieren. Zu den Base Objects gehören zum Beispiel Attribute, Key Value und Key Wrapping Data.
Ein Managed Object ist ein Objekt mit kryptographischem Inhalt, das vom KLM-System verwaltet wird. Dazu gehören die verschiedenen Schlüssel und Zertifikate. Außerdem können Templates (Vorlagen) erstellt werden, die dem Administrator eines KLM-Systems ermöglichen, Attribute von oft genutzten Prozessen zusammenzufassen. Zum Beispiel kann eine Vorlage für einen symmetrischen Schlüssel erstellt werden, in welcher der Algorithmus und die Länge des Schlüssels definiert sind. Wenn ein Schlüssel nach diesen Spezifikationen erstellt werden soll, wird der Name der Vorlage anstelle der gewünschten Attribute übergeben. Um weitere geheimzuhaltende Objekte zu speichern, werden das Secret Data Objekt (z. B. für Passwörter) oder das Opaque Object verwendet. Die Daten im Opaque Object müssen vom Server nicht interpretiert werden können. Es wird zum Beispiel ein Schlüssel gespeichert, obwohl der Server den verwendeten Verschlüsselungs-Algorithmus nicht unterstützt.
Attribute
Um die Managed Objects zu spezifizieren, gibt es verschiedene Attribute. In der Tabelle sind alle Attribute mit ihren wichtigsten Eigenschaften aufgelistet. Es gibt Attribute, die für jedes Objekt oder für bestimmte Objekte zwingend sind, andere sind optional. Von einigen Attributen können pro Objekt mehrere Instanzen vorhanden sein. Wichtig ist dies zum Beispiel beim Link. Ein Public Key hat einen Link zum zugehörigen Private Key und zusätzlich zum Zertifikat, das den Schlüssel mit einer Identität verknüpft. In der KMIP-Spezifikation wird zudem für jedes Attribut beschrieben, wer es erstellen, ändern, löschen darf und bei welchen Operationen das Attribut implizit gesetzt wird.
Attribut
Beschreibung
Unique Identifier
Eindeutige Bezeichnung eines Objekts innerhalb eines KLMS
Wird vom Server bei der Erstellung gesetzt und kann nicht verändert werden
Name
Name des Objekts
Vom Client gesetzt
Vom Client benötigt, um das Objekt zu referenzieren
Object Type
Typ des Objekts (Public Key, Private Key, etc.)
Cryptographic Algorithm
Algorithmus, der vom Objekt verwendet wird (RSA, DES, AES etc.)
Identifikation eines Zertifikats (Aussteller des Zertifikats und, wenn vorhanden, Seriennummer)
Certificate Subject
Identifikation des Subjekts (Person oder Gerät) eines Zertifikats
Kann mehrere Beschreibungen beinhalten (Name, E-Mail-Adresse, IP-Adresse etc.)
Certificate Issuer
Identifikation des Ausstellers eines Zertifikats
Kann mehrere Beschreibungen beinhalten (Name, E-Mail-Adresse, IP-Adresse etc.)
Digest
Hash-Wert von Schlüssel, Zertifikat, Secret Data oder Opaque Object
Mehrere Hash-Werte möglich (mit verschiedenen Algorithmen)
Operation Policy Name
Beschreibung, welche Clients welche Operationen auf dem Objekt ausführen dürfen
Server hat mindestens eine Standard-Einstellung (default policy)
Cryptographic Usage Mask
Bit-Maske
Beschreibt die erlaubten Anwendungen eines Schlüssels
Lease Time
Intervall, währenddessen das Objekt genutzt werden darf
Usage Limits
Beschreibt die limitierte Nutzung eines Objekts
Nutzung begrenzt nur Operationen zum Schutz von Informationen (z. B. Verschlüsselung), Operationen zur Verarbeitung geschützter Informationen (z. B. Entschlüsselung) sind unbegrenzt nutzbar
Enthält Einheit (z. B. zu verschlüsselnde Bytes), aktuellen Zähler und total erlaubte Anzahl Einheiten
State
Aktueller Status des Objekts
Kann nur vom Server verändert werden
Initial Date
Zeit und Datum der Erstellung/Registrierung des Objekts
Activation Date
Zeit und Datum der Aktivierung
Objekt darf ab dem Aktivierungsdatum für schützende Operationen (Entschlüsseln oder unwrapping) genutzt werden
Process Start Date
Zeit und Datum, ab wann das Objekt für die Bearbeitung von verschlüsselten Informationen genutzt werden darf
Darf nicht früher sein als die Aktivierungszeit
Protect Stop Date
Zeit und Datum, ab wann ein Objekt nicht mehr für schützende Operationen (Verschlüsseln oder wrapping) eingesetzt werden darf
Darf nicht später sein als Deaktivierungszeit
Deactivation Date
Zeit und Datum der Deaktivierung
Destroy Date
Zeit und Datum des Löschens des Objekts
Compromise Occurrence Date
Zeit und Datum, ab wann das Objekt als kompromittiert gilt
Compromise Date
Zeit und Datum der Zustandsänderung in den Compromised State
Revocation Reason
Grund, warum ein Objekt annulliert wird
Archive Date
Zeit und Datum, wann das Objekt archiviert wurde
Object Group
Name einer Objekt-Gruppe
Link
Zusammenhänge zwischen den Objekten (Private Key – Public Key, Public Key – Certificate, etc.)
Mehrere Links pro Objekt möglich
Application Specific Information
Zusätzliche, applikationsspezifische Informationen zu einem Objekt
Contact Information
Kontaktinformationen (Personen/Geräte, die für ein Objekt verantwortlich sind)
Last Change Date
Zeit und Datum der letzten Änderung
Custom Attribute
Anbieterspezifisches Attribut
Client- oder serverseitig
Operationen
Bei den Operationen wird unterschieden, von wem sie initiiert werden. Die meisten davon sind Client-to-Server-Operationen. Zusätzlich gibt es wenige Server-to-Client-Operationen. In der KMIP-Spezifikation wird jeweils beschrieben, welche Informationen eine Anfrage und die dazugehörige Antwort beinhalten. In den folgenden Unterkapiteln werden die Operationen und ihre wichtigsten Eigenschaften aufgelistet. Die Aufteilung erfolgt gemäß Verwendungszweck.
Client-to-Server-Operationen
Ein Client kann eine Teilmenge oder alle Operationen unterstützen. Möchte er mehrere Operationen gleichzeitig an den Server senden, können diese in einer Nachricht zu einem Batch zusammengefasst werden.
Untenstehende Tabelle enthält die Operationen, die ein neues Objekt erzeugen oder Inhalte eines bestehenden Objekts erneuern. Das KLMS kann selbst Zertifikate ausstellen, oder die Zertifizierung von einem externen Dienst (certification authority) anfordern.
Automatisches Erstellen eines Link-Attributs, das die beiden neuen Objekte verbindet
Register
Registrierung eines Objekts, das vom Client übergeben wird
Anfrage enthält mindestens die Attribute Cryptographic Algorithm, Cryptographic Length und Cryptographic Usage Mask
Re-key
Erstellen eines symmetrischen Schlüssels, der einen existierenden Schlüssel ersetzt
Attribute werden vom existierenden Schlüssel übernommen (Cryptographic Algorithm, Cryptographic Length, etc.) oder neu gesetzt (Initial Date, Unique Identifier, etc.)
Automatisches Erstellen eines Link-Attributs, das den alten mit dem neuen Schlüssel verbindet
Derive Key
Symmetrischen Schlüssel/Secret Data ableiten aus Schlüssel / Secret Data
Abzuleitendes Objekt muss dem KLMS bekannt sein
Derive Key Bit in der Cryptographic Usage Mask muss gesetzt sein
Automatisches Erstellen eines Link-Attributs, welches das Ursprungsobjekt mit dem abgeleiteten Objekt verbindet
Certify
Erstellen eines Zertifikats für einen öffentlichen Schlüssel
Automatisches Erstellen eines Link-Attributs, welches das Zertifikat mit dem Public Key verbindet
Re-Certify
Erneuerung eines Zertifikats
Automatisches Erstellen eines Link-Attributs, welches das alte mit dem neuen Zertifikat verbindet
Operationen, die benötigt werden, um Objekte aufzufinden und abzurufen und um deren Verwendung zu prüfen, werden in der nächsten Tabelle aufgelistet.
Operation
Beschreibung
Locate
Suchen eines Objekts, das durch ein oder mehrere Attribute beschrieben wird
Erfolglose Suche resultiert in leerer Antwort
Erfolgreiche Suche resultiert in Antwort mit einem oder mehreren Unique Identifiers
Check
Verwendung des Objekts für eine bestimmte Anwendung überprüfen
Bei erlaubter Anwendung wird mit dem Unique Identifier geantwortet
Bei unerlaubter Anwendung werden die für das Scheitern der Anfrage verantwortlichen Attribute zurückgesendet
Get
Abrufen eines Objekts
Auswahl des Objekts mit dem Unique Identifier
In der folgenden Tabelle werden die Operationen angegeben, die sich auf die Attribute von Objekten beziehen. Die Auswahl des gewünschten Objekts erfolgt jeweils mit dem Unique Identifier, die Auswahl des Attributs mit dem Attributnamen.
Operation
Beschreibung
Get Attributes
Abfrage von bestimmten Attributen eines Objekts
Get Attribute List
Abfrage aller Attribute eines Objekts
Add Attribute
Erstellen eines neuen Attributs zu einem bestehenden Objekt
Mehrere neue Attribute können zu einem Batch zusammengefasst werden.
Modify Attribute
Änderung eines Attributs
Delete Attribute
Löschen eines Attributs
Operationen, die in der nächsten Tabelle aufgelistet werden, beschäftigen sich mit der Nutzung von Objekten. Die Objektauswahl erfolgt wie schon oben erwähnt mit der Angabe des Unique Identifiers. Einige der folgenden Operationen dürfen nur von bestimmten Clients beantragt werden (zum Beispiel vom Administrator oder vom Ersteller eines Objekts). Die Identität dieser Clients muss mittels Authentifizierung überprüft werden.
Operation
Beschreibung
Obtain Lease
Verlängerung der Nutzungsdauer
Get Usage Allocation
Zuteilung von nutzbaren Einheiten für Schutzfunktionen (vgl. Usage Limits)
Activate
Aktivierung eines Objekts
Zustandswechsel von Pre-Active zu Active
Revoke
Annullierung eines Objekts
Revocation Reason enthält den Grund der Annullierung
Je nach Grund Zustandswechsel zu Compromised oder Deactivated
Destroy
Löschen eines Schlüssels oder einer Vorlage
Objekte im Zustand Pre-Active oder Deactivated werden sofort gelöscht
Objekte im Zustand Active werden zuerst deaktiviert
Archive
Archivierung eines Objekts
Recover
Wiederherstellen eines archivierten Objekts
Validate
Bestätigung der Gültigkeit einer Zertifikats -Kette (certificate chain)
Anfrage kann Zertifikate und Unique Identifiers enthalten
Die nächste Tabelle beschreibt die asynchronen Operationen sowie eine Operation zur Befragung des Servers. Operationen werden als asynchron bezeichnet, wenn der Server nicht sofort antwortet. Der Client kann zu einem späteren Zeitpunkt die Poll-Operation ausführen, um die Antwort zu erhalten. Dieses Vorgehen wird gewählt, wenn Operationen eine gewisse Bearbeitungszeit benötigen (z. B. Wiederherstellen eines Objekts).
Operation
Beschreibung
Query
Abfrage von Server-spezifischen Eigenschaften
Option „Query Operations“ listet die vom Server unterstützten Operationen auf
Option „Query Objects“ listet die vom Server unterstützten Objekttypen auf
Cancel
Abbrechen einer asynchronen Operation
Antwort des Servers enthält das Resultat (abgebrochen, Abbruch nicht möglich, Operation vor dem Abbruch fertiggestellt, fehlgeschlagen, nicht verfügbar)
Poll
Abfrage einer asynchronen Operation
Bei laufender Operation wird der Status pending (ausstehend) zurückgegeben
Bei abgeschlossener Operation wird das Resultat der Operation zurückgegeben
Server-to-Client-Operationen
Für gewisse Abläufe ist es sinnvoll, dass ein KLM-Server eine Kommunikation initiiert. Dabei sendet der Server dem Client eine Anfrage (Request Message). Der Client antwortet mit einer Response Message.
Bei Anwendung dieser Operationen müssen sich die Clients beim Server anmelden. Die Art der Anmeldung wird nicht im Protokoll spezifiziert. Es wird jedoch erwartet, dass eine Authentifizierung stattfindet, die einen Man-in-the-middle-Angriff[6] verhindert.
Operation
Beschreibung
Notify
Benachrichtigung bei Ereignissen, die zur Änderung von Attributen geführt haben
Objekt wird mit Unique Identifier beschrieben
Benachrichtigung enthält Liste der veränderten Attribute
Put
Übermittlung von Objekten zum Client
New: neues Objekt wird übermittelt
Replace: Objekt ersetzt existierendes Objekt (z. B. neues Zertifikat)
Nachrichten-Format
Eine Nachricht besteht immer aus einem Header, gefolgt von einem oder mehreren gestapelten Batch-Objekten und optionalen Nachrichten-Erweiterungen.
Aufbau einer KMIP Request NachrichtAufbau einer KMIP Response Nachricht
Im Header wird zwischen zwei Nachrichtentypen unterschieden: Request und Response. In beiden Headern ist jeweils die Protokoll-Version und der Batch Count angegeben. Der Batch Count gibt an, wie viele Operationen mit dieser Nachricht angefordert werden. Dazu kommen weitere Daten, abhängig vom Typ. Ein Batch-Objekt spezifiziert die gewünschte Operation und beinhaltet alle dafür benötigten Attribute. Die gepunkteten Attribute in den folgenden Abbildungen sind optional.
Um eine einfache Verarbeitung zu garantieren, wird eine Tag-Type-Length-Value (TTLV) Codierung verwendet (siehe Abbildung).
Tag: Kennzeichnung der nachfolgenden Informationen des TTLV-Segments, codiert als sechsstellige Hexadezimalzahl, wobei diese immer mit 42 beginnt („42XXXX“)
Type: Typ der nachfolgenden Informationen (Structure, Integer, Long Integer, Big Integer, Enumeration, Boolean, Text String, Byte String, Date-Time, Interval)
Length: Länge der nachfolgenden Informationen in Bytes
Value: Der eigentliche Wert bzw. Kern des TTLV-Segments (je nach Datentyp verschieden codiert)
Mit Strukturen werden verschachtelte Inhalte erstellt. Im Value-Teil einer Struktur können weitere TTLV-Segmente vorkommen. Als Länge der Struktur wird dann die Anzahl der Bytes aller in der Struktur enthaltenen Elemente angegeben.
Beispiel Nachricht Enkodierung
Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines symmetrischen Schlüssels kann folgendermaßen aussehen, als Byte-Strom in hexadezimaler Form dargestellt.
Aufgeschlüsselt nach dem TTLV Schema und gemäß KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des Clients an den Server. Der Client verlangt einen symmetrischen Schlüssel zur Ver- und Entschlüsselung mit dem AES-Algorithmus. Der Schlüssel soll eine Länge von 128 Bit haben.
Use Cases
Zusätzlich zur Spezifikation wurden Use Cases entwickelt[7]. Dabei wurden die Abläufe von verschiedenen Szenarien und die auszutauschenden Nachrichten beschrieben. Die Use Cases können einerseits dazu verwendet werden, den Ablauf einer Kommunikation nachzuvollziehen. Andererseits kann damit eine Implementationen des KMIP, die auf einem KLMS läuft, getestet werden. Die Use Cases enthalten nur realistische Anwendungen, sie eignen sich nicht dazu, mögliche Angriffe auf das System zu testen.
Open Source Implementation KMIP4J
Während einige Software-Unternehmen schon eine Weile mit proprietärenImplementationen von KMIP arbeiten, gab es bisher noch keine frei verfügbare Software. Mit KMIP4J gibt es nun eine Open-Source-Implementation von KMIP 1.0. Diese ist auf SourceForge verfügbar.
