Benutzer:MeileGuster/Key Management Interoperability Protocol - Versionsgeschichte

Plankton314: lf

2014-09-23T15:45:58Z

← Nächstältere Version		Version vom 23. September 2014, 17:45 Uhr
Zeile 57:		Zeile 57:
	\|-		\|-
	\| Operation Policy Name \|\|		\| Operation Policy Name \|\|
	* Beschreibung, welche [[~~Clients~~]] welche Operationen auf dem Objekt ausführen dürfen		* Beschreibung, welche [[Client]]s welche Operationen auf dem Objekt ausführen dürfen
	* [[Server]] hat mindestens eine Standard-Einstellung (default policy)		* [[Server]] hat mindestens eine Standard-Einstellung (default policy)
	\|-		\|-
Zeile 214:		Zeile 214:
	\|}		\|}

	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.		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 [[Client]]s beantragt werden (zum Beispiel vom [[Administrator]] oder vom Ersteller eines Objekts). Die Identität dieser [[Client]]s muss mittels [[Authentifizierung]] überprüft werden.
	{\| class="wikitable"		{\| class="wikitable"
	\|-		\|-
Zeile 308:		Zeile 308:
	=== Beispiel Nachricht Enkodierung ===		=== Beispiel Nachricht Enkodierung ===
	Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines [[Schlüssel (Kryptologie) \| symmetrischen Schlüssels]] kann folgendermassen aussehen, als Byte-Strom in [[Hexadezimalsystem \| hexadezimaler Form]] dargestellt.		Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines [[Schlüssel (Kryptologie) \| symmetrischen Schlüssels]] kann folgendermassen aussehen, als Byte-Strom in [[Hexadezimalsystem \| hexadezimaler Form]] dargestellt.
	Aufgeschlüsselt nach dem TTLV Schema und gemäss KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des [[~~Clients~~]] an den [[Server]] . Der [[Client]] verlangt einen [[Schlüssel (Kryptologie) \| symmetrischen Schlüssel]] zur [[Verschlüsselung \| Ver- und Entschlüsselung]] mit dem [[AES \| AES-Algorithmus]]. Der [[Schlüssel (Kryptologie) \|Schlüssel]] soll eine Länge von 128 [[Bit]] haben.		Aufgeschlüsselt nach dem TTLV Schema und gemäss KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des [[Client]]s an den [[Server]] . Der [[Client]] verlangt einen [[Schlüssel (Kryptologie) \| symmetrischen Schlüssel]] zur [[Verschlüsselung \| Ver- und Entschlüsselung]] mit dem [[AES \| AES-Algorithmus]]. Der [[Schlüssel (Kryptologie) \|Schlüssel]] soll eine Länge von 128 [[Bit]] haben.

	[[File:Codierte KMIP Nachricht.PNG\|KMIP Nachricht nach TTLV aufgeschlüsselt]]		[[File:Codierte KMIP Nachricht.PNG\|KMIP Nachricht nach TTLV aufgeschlüsselt]]

CommonsDelinker: NachrichtenFormat_Aufbau.png entfernt, auf Commons von Fastily gelöscht. Grund: Media without a license as of 2 March 2013

2013-03-10T00:44:12Z

NachrichtenFormat_Aufbau.png entfernt, auf Commons von Fastily gelöscht. Grund: Media without a license as of 2 March 2013

← Nächstältere Version		Version vom 10. März 2013, 02:44 Uhr
Zeile 290:		Zeile 290:
	=== Nachrichten-Format ===		=== Nachrichten-Format ===
	Eine Nachricht besteht immer aus einem [[Header]], gefolgt von einem oder mehreren gestapelten [[Stapelverarbeitung \| Batch-Objekten]] und optionalen Nachrichten-Erweiterungen.		Eine Nachricht besteht immer aus einem [[Header]], gefolgt von einem oder mehreren gestapelten [[Stapelverarbeitung \| Batch-Objekten]] und optionalen Nachrichten-Erweiterungen.

	[[File:NachrichtenFormat Aufbau.png\|Aufbau von KMIP Nachrichten]]

	[[File:KMIP Nachrichten Format RequestMessage.png\|miniatur\|Aufbau einer KMIP Request Nachricht]]		[[File:KMIP Nachrichten Format RequestMessage.png\|miniatur\|Aufbau einer KMIP Request Nachricht]]

MeileGuster am 20. Februar 2013 um 16:12 Uhr

2013-02-20T16:12:45Z

← Nächstältere Version		Version vom 20. Februar 2013, 18:12 Uhr
Zeile 7:		Zeile 7:
	Bei den Objekten wird zwischen Base Objects (Basis Objekten) 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 .		Bei den Objekten wird zwischen Base Objects (Basis Objekten) 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 (Kryptologie) \| Schlüssel]] und [[Digitales Zertifikat \| Zertifikate]]. Ausserdem 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 [[symmetrisches Kryptosystem\| symmetrischen Schlüssel]] erstellt werden, in welcher der [[Algorithmus]] und die Länge des [[Schlüssel (Kryptologie) \| Schlüssels]] definiert sind. Wenn ein [[Schlüssel (Kryptologie) \| Schlüssel]] nach diesen Spezifikationen erstellt werden soll, wird der Name des Templates anstelle der gewünschten Attribute übergeben. Um weitere geheimzuhaltende Objekte zu speichern, werden das Secret Data Objekt (z.B. für [[Passwort \| 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 (Kryptologie) \| Schlüssel]] gespeichert, obwohl der [[Server]] den verwendeten [[Verschlüsselung \| Verschlüsselungs]]-Algorithmus nicht unterstützt.		Ein Managed Object ist ein Objekt mit kryptographischem Inhalt, das vom KLM-System verwaltet wird. Dazu gehören die verschiedenen [[Schlüssel (Kryptologie) \| Schlüssel]] und [[Digitales Zertifikat \| Zertifikate]]. Ausserdem 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 [[symmetrisches Kryptosystem\| symmetrischen Schlüssel]] erstellt werden, in welcher der [[Algorithmus]] und die Länge des [[Schlüssel (Kryptologie) \| Schlüssels]] definiert sind. Wenn ein [[Schlüssel (Kryptologie) \| Schlüssel]] nach diesen Spezifikationen erstellt werden soll, wird der Name des Templates anstelle der gewünschten Attribute übergeben. Um weitere geheimzuhaltende Objekte zu speichern, werden das Secret Data Objekt (z.B. für [[Passwort \| 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 (Kryptologie) \| Schlüssel]] gespeichert, obwohl der [[Server]] den verwendeten [[Verschlüsselung \| Verschlüsselungs]]-Algorithmus nicht unterstützt.


	==== Attribute ====		==== Attribute ====

MeileGuster am 20. Februar 2013 um 16:07 Uhr

2013-02-20T16:07:55Z

← Nächstältere Version		Version vom 20. Februar 2013, 18:07 Uhr
Zeile 299:		Zeile 299:

	Um eine einfache Verarbeitung zu garantieren, wird eine Tag-Type-Length-Value (TTLV) [[Codierung]] verwendet (siehe Abbildung).		Um eine einfache Verarbeitung zu garantieren, wird eine Tag-Type-Length-Value (TTLV) [[Codierung]] verwendet (siehe Abbildung).
	[[File:TTLV-Codierung der KMIP Nachricht.png~~\|thumb~~\|TTLV-Codierung der KMIP Nachricht]]		[[File:TTLV-Codierung der KMIP Nachricht.png\|TTLV-Codierung der KMIP Nachricht]]
	* '''Tag''': Kennzeichnung der nachfolgenden Informationen des TTLV-Segments, codiert als sechsstellige [[Hexadezimalsystem \| Hexadezimalzahl]], wobei diese immer mit 42 beginnt („42XXXX“)		* '''Tag''': Kennzeichnung der nachfolgenden Informationen des TTLV-Segments, codiert als sechsstellige [[Hexadezimalsystem \| 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)		* '''Type''': Typ der nachfolgenden Informationen (Structure, Integer, Long Integer, Big Integer, Enumeration, Boolean, Text String, Byte String, Date-Time, Interval)
Zeile 308:		Zeile 308:

	=== Beispiel Nachricht Enkodierung ===		=== Beispiel Nachricht Enkodierung ===
	Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines [[Schlüssel (Kryptologie) \| symmetrischen Schlüssels] kann folgendermassen aussehen, als Byte-Strom in [[Hexadezimalsystem \| hexadezimaler Form]] dargestellt.		Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines [[Schlüssel (Kryptologie) \| symmetrischen Schlüssels]] kann folgendermassen aussehen, als Byte-Strom in [[Hexadezimalsystem \| hexadezimaler Form]] dargestellt.
		⚫	Aufgeschlüsselt nach dem TTLV Schema und gemäss KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des [[Clients]] an den [[Server]] . Der [[Client]] verlangt einen [[Schlüssel (Kryptologie) \| symmetrischen Schlüssel]] zur [[Verschlüsselung \| Ver- und Entschlüsselung]] mit dem [[AES \| AES-Algorithmus]]. Der [[Schlüssel (Kryptologie) \|Schlüssel]] soll eine Länge von 128 [[Bit]] haben.

	[[File:Codierte KMIP Nachricht.PNG\|KMIP Nachricht nach TTLV aufgeschlüsselt]]		[[File:Codierte KMIP Nachricht.PNG\|KMIP Nachricht nach TTLV aufgeschlüsselt]]

⚫	Aufgeschlüsselt nach dem TTLV Schema und gemäss KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des [[Clients]] an den [[Server]] ~~(Abbildung 17)~~. Der [[Client]] verlangt einen [[Schlüssel (Kryptologie) \| symmetrischen Schlüssel]] zur [[Verschlüsselung \| Ver- und Entschlüsselung]] mit dem [[AES \| AES-Algorithmus]]. Der [[Schlüssel (Kryptologie) \|Schlüssel]] soll eine Länge von 128 [[Bit]] haben.

	[[File:KMIP Nachricht nach TTLV codiert.png\|KMIP Nachricht nach TTLV codiert]]		[[File:KMIP Nachricht nach TTLV codiert.png\|KMIP Nachricht nach TTLV codiert]]

MeileGuster am 20. Februar 2013 um 16:04 Uhr

2013-02-20T16:04:46Z

← Nächstältere Version		Version vom 20. Februar 2013, 18:04 Uhr
Zeile 2:		Zeile 2:

	=== Protokolldefinition ===		=== Protokolldefinition ===
	In der [[http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html KMIP Spezifikation]] wird definiert, wie eine Nachricht aussehen muss und welche Informationen ausgetauscht werden können. 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. <ref>http://docs.oasis-open.org/kmip/spec/v1.0/cs01/kmip-spec-1.0-cs-01.pdf</ref> Die Protokoll-Spezifikation gibt nicht vor, 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 [[Transport Layer Security \| Transport Layer Security TLS]] verwendet. TLS dient nicht nur der Authentifizierung, es stellt auch die [[Integrität (Informationssicherheit) \| Integrität der Daten]] sicher.<ref>http://docs.oasis-open.org/kmip/profiles/v1.0/cs01/kmip-profiles-1.0-cs-01.pdf</ref>		In der [http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html KMIP Spezifikation] wird definiert, wie eine Nachricht aussehen muss und welche Informationen ausgetauscht werden können. 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.<ref>http://docs.oasis-open.org/kmip/spec/v1.0/cs01/kmip-spec-1.0-cs-01.pdf</ref> Die Protokoll-Spezifikation gibt nicht vor, 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 [[Transport Layer Security \| Transport Layer Security TLS]] verwendet. TLS dient nicht nur der Authentifizierung, es stellt auch die [[Integrität (Informationssicherheit) \| Integrität der Daten]] sicher.<ref>http://docs.oasis-open.org/kmip/profiles/v1.0/cs01/kmip-profiles-1.0-cs-01.pdf</ref>

	==== Objekte ====		==== Objekte ====
Zeile 136:		Zeile 136:
	===== Client-to-Server Operationen =====		===== 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 [[Stapelverarbeitung \| Batch]] zusammengefasst werden.		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 [[Stapelverarbeitung \| Batch]] zusammengefasst werden.
	Untenstehende Tabelle enthält die Operationen, die ein neues Objekt erzeugen oder Inhalte eines bestehenden Objekts erneuern. Das KLMS kann selbst [[Digitales Zertifikat \| Zertifikate ]] ausstellen, oder die Zertifizierung von einem externen Dienst ([[Zertifizierungsstelle \| certification authority]]) anfordern.		Untenstehende Tabelle enthält die Operationen, die ein neues Objekt erzeugen oder Inhalte eines bestehenden Objekts erneuern. Das KLMS kann selbst [[Digitales Zertifikat \| Zertifikate ]] ausstellen, oder die Zertifizierung von einem externen Dienst ([[Zertifizierungsstelle \|certification authority]]) anfordern.

	{\| class="wikitable"		{\| class="wikitable"
Zeile 208:		Zeile 208:
	\| Add Attribute \|\|		\| Add Attribute \|\|
	* Erstellen eines neuen Attributs zu einem bestehenden Objekt		* Erstellen eines neuen Attributs zu einem bestehenden Objekt
	* Mehrere neue Attribute können zu einem [[Stapelverarbeitung \| Batch] zusammengefasst werden		* Mehrere neue Attribute können zu einem [[Stapelverarbeitung \|Batch]] zusammengefasst werden
	\|-		\|-
	\| Modify Attribute\|\| Änderung eines Attributs		\| Modify Attribute\|\| Änderung eines Attributs
Zeile 290:		Zeile 290:

	=== Nachrichten-Format ===		=== Nachrichten-Format ===
	Eine Nachricht besteht immer aus einem [[Header]], gefolgt von einem oder mehreren gestapelten [[Stapelverarbeitung \|Batch-Objekten]] und optionalen Nachrichten-Erweiterungen.		Eine Nachricht besteht immer aus einem [[Header]], gefolgt von einem oder mehreren gestapelten [[Stapelverarbeitung \| Batch-Objekten]] und optionalen Nachrichten-Erweiterungen.
	[[File:NachrichtenFormat Aufbau.png\|Aufbau von KMIP Nachrichten]]		[[File:NachrichtenFormat Aufbau.png\|Aufbau von KMIP Nachrichten]]

⚫	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.

	[[File:KMIP Nachrichten Format RequestMessage.png\|miniatur\|Aufbau einer KMIP Request Nachricht]]		[[File:KMIP Nachrichten Format RequestMessage.png\|miniatur\|Aufbau einer KMIP Request Nachricht]]
	[[File:KMIP Nachrichten Format ResponseMessage.png\|miniatur\|Aufbau einer KMIP Response Nachricht]]		[[File:KMIP Nachrichten Format ResponseMessage.png\|miniatur\|Aufbau 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).		Um eine einfache Verarbeitung zu garantieren, wird eine Tag-Type-Length-Value (TTLV) [[Codierung]] verwendet (siehe Abbildung).

MeileGuster: /* Protokolldefinition */

2013-02-20T15:59:54Z

Protokolldefinition

← Nächstältere Version		Version vom 20. Februar 2013, 17:59 Uhr
Zeile 2:		Zeile 2:

	=== Protokolldefinition ===		=== Protokolldefinition ===
	In der [[http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html KMIP Spezifikation]] wird definiert, wie eine Nachricht aussehen muss und welche Informationen ausgetauscht werden können. 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. <ref>http://docs.oasis-open.org/kmip/spec/v1.0/cs01/kmip-spec-1.0-cs-01.pdf</ref> Die Protokoll-Spezifikation gibt nicht vor, 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 [[Transport Layer Security \| Transport Layer Security TLS]] verwendet. TLS dient nicht nur der Authentifizierung, es stellt auch die [[Integrität (Informationssicherheit) \| Integrität der Daten]] sicher. <ref>http://docs.oasis-open.org/kmip/profiles/v1.0/cs01/kmip-profiles-1.0-cs-01.pdf</ref>		In der [[http://docs.oasis-open.org/kmip/spec/v1.0/os/kmip-spec-1.0-os.html KMIP Spezifikation]] wird definiert, wie eine Nachricht aussehen muss und welche Informationen ausgetauscht werden können. 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. <ref>http://docs.oasis-open.org/kmip/spec/v1.0/cs01/kmip-spec-1.0-cs-01.pdf</ref> Die Protokoll-Spezifikation gibt nicht vor, 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 [[Transport Layer Security \| Transport Layer Security TLS]] verwendet. TLS dient nicht nur der Authentifizierung, es stellt auch die [[Integrität (Informationssicherheit) \| Integrität der Daten]] sicher.<ref>http://docs.oasis-open.org/kmip/profiles/v1.0/cs01/kmip-profiles-1.0-cs-01.pdf</ref>

	==== Objekte ====		==== Objekte ====

MeileGuster am 20. Februar 2013 um 15:58 Uhr

2013-02-20T15:58:55Z

← Nächstältere Version		Version vom 20. Februar 2013, 17:58 Uhr
Zeile 131:		Zeile 131:
	\|}		\|}

	=== Operationen ===		==== 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äss Verwendungszweck.		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äss Verwendungszweck.

	==== Client-to-Server Operationen ====		===== 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 [[Stapelverarbeitung \| Batch]] zusammengefasst werden.		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 [[Stapelverarbeitung \| Batch]] zusammengefasst werden.
	Untenstehende Tabelle enthält die Operationen, die ein neues Objekt erzeugen oder Inhalte eines bestehenden Objekts erneuern. Das KLMS kann selbst [[Digitales Zertifikat \| Zertifikate ]] ausstellen, oder die Zertifizierung von einem externen Dienst ([[Zertifizierungsstelle \| certification authority]]) anfordern.		Untenstehende Tabelle enthält die Operationen, die ein neues Objekt erzeugen oder Inhalte eines bestehenden Objekts erneuern. Das KLMS kann selbst [[Digitales Zertifikat \| Zertifikate ]] ausstellen, oder die Zertifizierung von einem externen Dienst ([[Zertifizierungsstelle \| certification authority]]) anfordern.
Zeile 271:		Zeile 271:
	\|}		\|}

	==== Server-to-Client Operationen ====		===== 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.		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 [[Client]]s beim [[Server]] anmelden. Die Art der Anmeldung wird nicht im [[Kommunikationsprotokoll \|Protokoll]] spezifiziert. Es wird jedoch erwartet, dass eine [[Authentifizierung]] stattfindet, die einen [[Man-in-the-middle-Angriff\| Man-in-the-Middle-Angriff]]<ref>Kurose und Ross: Computernetzwerke - Der Top-Down-Ansatz. Pearson Deutschland GmbH, München 2012, </ref> verhindert.		Bei Anwendung dieser Operationen müssen sich die [[Client]]s beim [[Server]] anmelden. Die Art der Anmeldung wird nicht im [[Kommunikationsprotokoll \|Protokoll]] spezifiziert. Es wird jedoch erwartet, dass eine [[Authentifizierung]] stattfindet, die einen [[Man-in-the-middle-Angriff\| Man-in-the-Middle-Angriff]]<ref>Kurose und Ross: Computernetzwerke - Der Top-Down-Ansatz. Pearson Deutschland GmbH, München 2012, </ref> verhindert.
Zeile 316:		Zeile 316:
	[[File:KMIP Nachricht nach TTLV codiert.png\|KMIP Nachricht nach TTLV codiert]]		[[File:KMIP Nachricht nach TTLV codiert.png\|KMIP Nachricht nach TTLV codiert]]

			=== Use Cases ===
			Zusätzlich zur Spezifikation wurden [[Anwendungsfall \| Use Cases]] entwickelt<ref>http://docs.oasis-open.org/kmip/usecases/v1.0/cs01/kmip-usecases-1.0-cs-01.doc</ref>. Dabei wurden die Abläufe von verschiedenen Szenarien und die auszutauschenden Nachrichten beschrieben. Die [[Anwendungsfall \| Use Cases]] können einerseits dazu verwendet werden, den Ablauf einer Kommunikation nachzuvollziehen. Andererseits kann damit eine [[Implementierung \| Implementationen]] des KMIP, die auf einem KLMS läuft, getestet werden. Die [[Anwendungsfall \| Use Cases]] enthalten nur realistische Anwendungen, sie eignen sich nicht dazu, mögliche Angriffe auf das System zu testen.

	== Weblinks ==		== Weblinks ==

MeileGuster am 20. Februar 2013 um 15:54 Uhr

2013-02-20T15:54:26Z

← Nächstältere Version		Version vom 20. Februar 2013, 17:54 Uhr
Zeile 310:		Zeile 310:
	Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines [[Schlüssel (Kryptologie) \| symmetrischen Schlüssels] kann folgendermassen aussehen, als Byte-Strom in [[Hexadezimalsystem \| hexadezimaler Form]] dargestellt.		Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines [[Schlüssel (Kryptologie) \| symmetrischen Schlüssels] kann folgendermassen aussehen, als Byte-Strom in [[Hexadezimalsystem \| hexadezimaler Form]] dargestellt.

	[[File:Codierte KMIP Nachricht.PNG~~\|thumb~~\|KMIP Nachricht nach TTLV aufgeschlüsselt]]		[[File:Codierte KMIP Nachricht.PNG\|KMIP Nachricht nach TTLV aufgeschlüsselt]]

	Aufgeschlüsselt nach dem TTLV Schema und gemäss KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des [[Clients]] an den [[Server]] (Abbildung 17). Der [[Client]] verlangt einen [[Schlüssel (Kryptologie) \| symmetrischen Schlüssel]] zur [[Verschlüsselung \| Ver- und Entschlüsselung]] mit dem [[AES \| AES-Algorithmus]]. Der [[Schlüssel (Kryptologie) \|Schlüssel]] soll eine Länge von 128 [[Bit]] haben.		Aufgeschlüsselt nach dem TTLV Schema und gemäss KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des [[Clients]] an den [[Server]] (Abbildung 17). Der [[Client]] verlangt einen [[Schlüssel (Kryptologie) \| symmetrischen Schlüssel]] zur [[Verschlüsselung \| Ver- und Entschlüsselung]] mit dem [[AES \| AES-Algorithmus]]. Der [[Schlüssel (Kryptologie) \|Schlüssel]] soll eine Länge von 128 [[Bit]] haben.

MeileGuster am 20. Februar 2013 um 15:53 Uhr

2013-02-20T15:53:27Z

← Nächstältere Version		Version vom 20. Februar 2013, 17:53 Uhr
Zeile 290:		Zeile 290:

	=== Nachrichten-Format ===		=== Nachrichten-Format ===
	Eine Nachricht besteht immer aus einem Header, gefolgt von einem oder mehreren gestapelten Batch-Objekten und optionalen Nachrichten-Erweiterungen.		Eine Nachricht besteht immer aus einem [[Header]], gefolgt von einem oder mehreren gestapelten [[Stapelverarbeitung \|Batch-Objekten]] und optionalen Nachrichten-Erweiterungen.
	[[File:NachrichtenFormat Aufbau.png\|Aufbau von KMIP Nachrichten]]		[[File:NachrichtenFormat Aufbau.png\|Aufbau von KMIP Nachrichten]]

	Im Header wird zwischen zwei Nachrichtentypen unterschieden: Request und Response. In beiden Headern ist jeweils die Protokoll-Version und der Batch Count angegeben. 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.		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.

	[[File:KMIP Nachrichten Format RequestMessage.png\|miniatur\|Aufbau einer KMIP Request Nachricht]]		[[File:KMIP Nachrichten Format RequestMessage.png\|miniatur\|Aufbau einer KMIP Request Nachricht]]
	[[File:KMIP Nachrichten Format ResponseMessage.png\|miniatur\|Aufbau einer KMIP Response Nachricht]]		[[File:KMIP Nachrichten Format ResponseMessage.png\|miniatur\|Aufbau einer KMIP Response Nachricht]]

			Um eine einfache Verarbeitung zu garantieren, wird eine Tag-Type-Length-Value (TTLV) [[Codierung]] verwendet (siehe Abbildung).
			[[File:TTLV-Codierung der KMIP Nachricht.png\|thumb\|TTLV-Codierung der KMIP Nachricht]]
			* '''Tag''': Kennzeichnung der nachfolgenden Informationen des TTLV-Segments, codiert als sechsstellige [[Hexadezimalsystem \| 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 [[Byte \| 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 [[Byte \|Bytes]] aller in der Struktur enthaltenen Elemente angegeben.

			=== Beispiel Nachricht Enkodierung ===
			Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines [[Schlüssel (Kryptologie) \| symmetrischen Schlüssels] kann folgendermassen aussehen, als Byte-Strom in [[Hexadezimalsystem \| hexadezimaler Form]] dargestellt.

			[[File:Codierte KMIP Nachricht.PNG\|thumb\|KMIP Nachricht nach TTLV aufgeschlüsselt]]

			Aufgeschlüsselt nach dem TTLV Schema und gemäss KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des [[Clients]] an den [[Server]] (Abbildung 17). Der [[Client]] verlangt einen [[Schlüssel (Kryptologie) \| symmetrischen Schlüssel]] zur [[Verschlüsselung \| Ver- und Entschlüsselung]] mit dem [[AES \| AES-Algorithmus]]. Der [[Schlüssel (Kryptologie) \|Schlüssel]] soll eine Länge von 128 [[Bit]] haben.

			[[File:KMIP Nachricht nach TTLV codiert.png\|KMIP Nachricht nach TTLV codiert]]

MeileGuster am 20. Februar 2013 um 12:04 Uhr

2013-02-20T12:04:47Z

← Nächstältere Version		Version vom 20. Februar 2013, 14:04 Uhr
Zeile 295:		Zeile 295:
	Im Header wird zwischen zwei Nachrichtentypen unterschieden: Request und Response. In beiden Headern ist jeweils die Protokoll-Version und der Batch Count angegeben. 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.		Im Header wird zwischen zwei Nachrichtentypen unterschieden: Request und Response. In beiden Headern ist jeweils die Protokoll-Version und der Batch Count angegeben. 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.

	[[File:KMIP Nachrichten Format RequestMessage.png\|~~miniature~~\|Aufbau einer KMIP Request Nachricht]]		[[File:KMIP Nachrichten Format RequestMessage.png\|miniatur\|Aufbau einer KMIP Request Nachricht]]
	[[File:KMIP Nachrichten Format ResponseMessage.png\|~~miniature~~\|Aufbau einer KMIP Response Nachricht]]		[[File:KMIP Nachrichten Format ResponseMessage.png\|miniatur\|Aufbau einer KMIP Response Nachricht]]

← Nächstältere Version		Version vom 20. Februar 2013, 17:54 Uhr
Zeile 310:		Zeile 310:
	Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines [[Schlüssel (Kryptologie) \| symmetrischen Schlüssels] kann folgendermassen aussehen, als Byte-Strom in [[Hexadezimalsystem \| hexadezimaler Form]] dargestellt.		Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines [[Schlüssel (Kryptologie) \| symmetrischen Schlüssels] kann folgendermassen aussehen, als Byte-Strom in [[Hexadezimalsystem \| hexadezimaler Form]] dargestellt.

	[[File:Codierte KMIP Nachricht.PNG~~\|thumb~~\|KMIP Nachricht nach TTLV aufgeschlüsselt]]		[[File:Codierte KMIP Nachricht.PNG\|KMIP Nachricht nach TTLV aufgeschlüsselt]]

	Aufgeschlüsselt nach dem TTLV Schema und gemäss KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des [[Clients]] an den [[Server]] (Abbildung 17). Der [[Client]] verlangt einen [[Schlüssel (Kryptologie) \| symmetrischen Schlüssel]] zur [[Verschlüsselung \| Ver- und Entschlüsselung]] mit dem [[AES \| AES-Algorithmus]]. Der [[Schlüssel (Kryptologie) \|Schlüssel]] soll eine Länge von 128 [[Bit]] haben.		Aufgeschlüsselt nach dem TTLV Schema und gemäss KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des [[Clients]] an den [[Server]] (Abbildung 17). Der [[Client]] verlangt einen [[Schlüssel (Kryptologie) \| symmetrischen Schlüssel]] zur [[Verschlüsselung \| Ver- und Entschlüsselung]] mit dem [[AES \| AES-Algorithmus]]. Der [[Schlüssel (Kryptologie) \|Schlüssel]] soll eine Länge von 128 [[Bit]] haben.

← Nächstältere Version		Version vom 20. Februar 2013, 17:53 Uhr
Zeile 290:		Zeile 290:

	=== Nachrichten-Format ===		=== Nachrichten-Format ===
	Eine Nachricht besteht immer aus einem Header, gefolgt von einem oder mehreren gestapelten Batch-Objekten und optionalen Nachrichten-Erweiterungen.		Eine Nachricht besteht immer aus einem [[Header]], gefolgt von einem oder mehreren gestapelten [[Stapelverarbeitung \|Batch-Objekten]] und optionalen Nachrichten-Erweiterungen.
	[[File:NachrichtenFormat Aufbau.png\|Aufbau von KMIP Nachrichten]]		[[File:NachrichtenFormat Aufbau.png\|Aufbau von KMIP Nachrichten]]

	Im Header wird zwischen zwei Nachrichtentypen unterschieden: Request und Response. In beiden Headern ist jeweils die Protokoll-Version und der Batch Count angegeben. 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.		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.

	[[File:KMIP Nachrichten Format RequestMessage.png\|miniatur\|Aufbau einer KMIP Request Nachricht]]		[[File:KMIP Nachrichten Format RequestMessage.png\|miniatur\|Aufbau einer KMIP Request Nachricht]]
	[[File:KMIP Nachrichten Format ResponseMessage.png\|miniatur\|Aufbau einer KMIP Response Nachricht]]		[[File:KMIP Nachrichten Format ResponseMessage.png\|miniatur\|Aufbau einer KMIP Response Nachricht]]

			Um eine einfache Verarbeitung zu garantieren, wird eine Tag-Type-Length-Value (TTLV) [[Codierung]] verwendet (siehe Abbildung).
			[[File:TTLV-Codierung der KMIP Nachricht.png\|thumb\|TTLV-Codierung der KMIP Nachricht]]
			* '''Tag''': Kennzeichnung der nachfolgenden Informationen des TTLV-Segments, codiert als sechsstellige [[Hexadezimalsystem \| 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 [[Byte \| 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 [[Byte \|Bytes]] aller in der Struktur enthaltenen Elemente angegeben.

			=== Beispiel Nachricht Enkodierung ===
			Eine Nachricht vom KMIP Client an den KLMS Server zur Erstellung eines [[Schlüssel (Kryptologie) \| symmetrischen Schlüssels] kann folgendermassen aussehen, als Byte-Strom in [[Hexadezimalsystem \| hexadezimaler Form]] dargestellt.

			[[File:Codierte KMIP Nachricht.PNG\|thumb\|KMIP Nachricht nach TTLV aufgeschlüsselt]]

			Aufgeschlüsselt nach dem TTLV Schema und gemäss KMIP Spezifikation interpretiert, ist diese Nachricht eine Anfrage des [[Clients]] an den [[Server]] (Abbildung 17). Der [[Client]] verlangt einen [[Schlüssel (Kryptologie) \| symmetrischen Schlüssel]] zur [[Verschlüsselung \| Ver- und Entschlüsselung]] mit dem [[AES \| AES-Algorithmus]]. Der [[Schlüssel (Kryptologie) \|Schlüssel]] soll eine Länge von 128 [[Bit]] haben.

			[[File:KMIP Nachricht nach TTLV codiert.png\|KMIP Nachricht nach TTLV codiert]]