JavaCard (erste Schritte) - Revision history

Wolfm: /* Implementierung */

2022-11-08T13:27:19Z

Implementierung

← Older revision		Revision as of 13:27, 8 November 2022
Line 474:		Line 474:
	HMAC_SHA_256(hmac_init, (short)0, (short)(wrapped_aes_length + 2), working_buf_32, (short)0);		HMAC_SHA_256(hmac_init, (short)0, (short)(wrapped_aes_length + 2), working_buf_32, (short)0);

	// ~~Vergleichte~~ den ~~erstellten~~ HMAC mit dem mitgesendeten. Falls unterschiedlich ist die Authentifizierung fehlgeschlagen.		// Vergleicht den berechneten HMAC mit dem mitgesendeten. Falls unterschiedlich, ist die Authentifizierung fehlgeschlagen.
	if (Util.arrayCompare(ram_buf, t_offset, working_buf_32, (short)0, HMAC_HASH_SIZE) != (byte)0) {		if (Util.arrayCompare(ram_buf, t_offset, working_buf_32, (short)0, HMAC_HASH_SIZE) != (byte)0) {
	ISOException.throwIt((short)0x9862);		ISOException.throwIt((short)0x9862);

Wolfm: /* Implementierung */

2022-11-08T13:17:36Z

Implementierung

← Older revision		Revision as of 13:17, 8 November 2022
Line 495:		Line 495:
	// Durchlaufe jedes Byte		// Durchlaufe jedes Byte
	for (short i = 0; i < incoming_length; i++) {		for (short i = 0; i < incoming_length; i++) {
	// Falls ein neuer Block erreicht wird, wird dieser ~~vercshlüsselt~~ und der Initialisierungvektor 'iv' inkrementiert.		// Falls ein neuer Block erreicht wird, wird dieser verschlüsselt und der Initialisierungvektor 'iv' inkrementiert.
	if (offset == 0) {		if (offset == 0) {
	aesCipher.doFinal(iv, (short)0, AES_BLOCK_SIZE, working_buf_32, (short)0);		aesCipher.doFinal(iv, (short)0, AES_BLOCK_SIZE, working_buf_32, (short)0);

Wolfm: /* Ablauf */

2022-11-08T13:07:46Z

Ablauf

← Older revision		Revision as of 13:07, 8 November 2022
Line 276:		Line 276:
	</pre>		</pre>

	Wie man sehen kann, werden die Serverschlüssel <code>Ka</code> und <code>Ke</code> zum "Wrappen" also zum verschlüsseln und zum Bilden eines HMACs verwendet. Die Erstellung von Metadaten ist optional, kann aber zur späteren Authentifizierung beitragen, z.B. durch das Angeben einer Nutzer-ID, oder um die Gültigkeit des Schlüssels nachzuweisen, z.B. durch einen Timestamp. Die Länge des gewrappten Schlüssels <code>WKc</code> lässt sich vorab bestimmen, da der HMAC-SHA256 <code>T</code> eine Länge von 32 Byte hat, der AES-256-CTR kein Padding ~~erzeugt~~, d.h. die Länge des Inputs ist gleich der Länge des Outputs, und <code>len</code> eine festgelegte Größe von 2 Byte hat.		Wie man sehen kann, werden die Serverschlüssel <code>Ka</code> und <code>Ke</code> zum "Wrappen" also zum verschlüsseln und zum Bilden eines HMACs verwendet. Die Erstellung von Metadaten ist optional, kann aber zur späteren Authentifizierung beitragen, z.B. durch das Angeben einer Nutzer-ID, oder um die Gültigkeit des Schlüssels nachzuweisen, z.B. durch einen Timestamp. Die Länge des gewrappten Schlüssels <code>WKc</code> lässt sich vorab bestimmen, da der HMAC-SHA256 <code>T</code> eine Länge von 32 Byte hat, der AES-256-CTR kein Padding erfordert, d.h. die Länge des Inputs ist gleich der Länge des Outputs, und <code>len</code> eine festgelegte Größe von 2 Byte hat.

	In der operativen Phase - also beim Verbindungsaufbau - entpackt der Server den "gewrappten" Schlüssel, welchen er von dem jeweiligen Klienten gesendet bekommt. Mit dem AES-Entschlüsselungsschlüssel <code>Ke</code> und dem Initialisierungsvektor <code>IV</code> entschlüsselt der Server sowohl den Klient-Key <code>Kc</code> als auch die Metadaten, und kann deren Integrität durch Hinzunahme der Länge und dem folgenden Erstellen des HMACs überprüfen, indem dieser mit <code>T</code> verglichen wird. Ist dies erfolgreich, kann die verschlüsselte Kommunikation zwischen Server und Client beginnen, da beide im Besitz des Schlüssels <code>Kc</code> sind.		In der operativen Phase - also beim Verbindungsaufbau - entpackt der Server den "gewrappten" Schlüssel, welchen er von dem jeweiligen Klienten gesendet bekommt. Mit dem AES-Entschlüsselungsschlüssel <code>Ke</code> und dem Initialisierungsvektor <code>IV</code> entschlüsselt der Server sowohl den Klient-Key <code>Kc</code> als auch die Metadaten, und kann deren Integrität durch Hinzunahme der Länge und dem folgenden Erstellen des HMACs überprüfen, indem dieser mit <code>T</code> verglichen wird. Ist dies erfolgreich, kann die verschlüsselte Kommunikation zwischen Server und Client beginnen, da beide im Besitz des Schlüssels <code>Kc</code> sind.

Wolfm: /* Ablauf */

2022-11-08T13:05:51Z

Ablauf

← Older revision		Revision as of 13:05, 8 November 2022
Line 244:		Line 244:
	[[File:server_key.png\|600px]]		[[File:server_key.png\|600px]]

	Ähnlich erfolgt die Erstellung des Klientenschlüssels, dieser wird mit <code>openvpn --genkey tls-crypt-v2-client --tls-crypt-v2 <server_key></code>, unter Nennung des Serverschlüssels, ~~getan~~. Dieser ist jedoch deutlich einfacher aufgebaut und besteht lediglich aus dem Klientenschlüssel <code>Kc</code>, sowie dem mit den Serverschlüsseln bereits "gewrappten" Schlüssel <code>WKc</code>. Der Schlüssel <code>Kc</code> hat eine feste Länge von 256 Byte, der gewrappte Schlüssel <code>WKc</code> hat eine flexible Länge, je nachdem welche Metadaten hinzugefügt werden. Die folgenden Abbildungen verdeutlichen dies.		Ähnlich erfolgt die Erstellung des Klientenschlüssels, dieser wird mit <code>openvpn --genkey tls-crypt-v2-client --tls-crypt-v2 <server_key></code>, unter Nennung des Serverschlüssels, erzeugt. Dieser ist jedoch deutlich einfacher aufgebaut und besteht lediglich aus dem Klientenschlüssel <code>Kc</code>, sowie dem mit den Serverschlüsseln bereits "gewrappten" Schlüssel <code>WKc</code>. Der Schlüssel <code>Kc</code> hat eine feste Länge von 256 Byte, der gewrappte Schlüssel <code>WKc</code> hat eine flexible Länge, je nachdem welche Metadaten hinzugefügt werden. Die folgenden Abbildungen verdeutlichen dies.
	<pre>		<pre>
	-----BEGIN OpenVPN tls-crypt-v2 client key-----		-----BEGIN OpenVPN tls-crypt-v2 client key-----

Wolfm: /* Key Unwrapping */

2022-11-08T13:03:54Z

Key Unwrapping

← Older revision		Revision as of 13:03, 8 November 2022
Line 223:		Line 223:
	==Key Unwrapping==		==Key Unwrapping==

	Im folgenden wird das tls-crypt-v2 [https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt] Verfahren besprochen, welches von OpenVPN Servern genutzt werden kann, um bereits den TLS-Handshake symmetrisch zu verschlüsseln, um eine ~~quentensichere~~ Verbindung mit Klienten zu ermöglichen (also den Diffie-Hellmann-Schlüsselaustausch zusätzlich zu schützen). Bei der älteren Version tls-crypt(-v1), bei dem sowohl der Server als auch die Klienten einen vorher geteilten Schlüssel nutzen, gab es das Risiko, dass nach Kompromittierung eines einzelnen Schlüssels, die gesamte Sicherheit verloren ist. tls-crypt-v2 unterscheidet sich dadurch, dass jeder Klient einen eigenen Schlüssel bekommt.		Im folgenden wird das tls-crypt-v2 [https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt] Verfahren besprochen, welches von OpenVPN Servern genutzt werden kann, um bereits den TLS-Handshake symmetrisch zu verschlüsseln, um eine quantensichere Verbindung mit Klienten zu ermöglichen (also den Diffie-Hellmann-Schlüsselaustausch zusätzlich zu schützen). Bei der älteren Version tls-crypt(-v1), bei dem sowohl der Server als auch die Klienten einen vorher geteilten Schlüssel nutzen, gab es das Risiko, dass nach Kompromittierung eines einzelnen Schlüssels, die gesamte Sicherheit verloren ist. tls-crypt-v2 unterscheidet sich dadurch, dass jeder Klient einen eigenen Schlüssel bekommt.

	Jeder klientspezifische Schlüssel wird zusätzlich mit den Schlüssen des Servers "gewrappt", d.h. er wird verschlüsselt und ein HMAC gebildet. Dieser gewrappte Key wird in der operativen Phase, also beim Verbindungsaufbau, an den Server geschickt. Bei erfolgreicher Entschlüsselung und Authentifizierung kann die verschlüsselte Kommunikation über den Klientenschlüssel beginnen.		Jeder klientspezifische Schlüssel wird zusätzlich mit den Schlüssen des Servers "gewrappt", d.h. er wird verschlüsselt und ein HMAC gebildet. Dieser gewrappte Key wird in der operativen Phase, also beim Verbindungsaufbau, an den Server geschickt. Bei erfolgreicher Entschlüsselung und Authentifizierung kann die verschlüsselte Kommunikation über den Klientenschlüssel beginnen.

Wolfm: /* Key Unwrapping */

2022-11-08T13:03:31Z

Key Unwrapping

← Older revision		Revision as of 13:03, 8 November 2022
Line 223:		Line 223:
	==Key Unwrapping==		==Key Unwrapping==

	Im folgenden wird das tls-crypt-v2 [https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt] Verfahren besprochen, welches von OpenVPN Servern genutzt werden kann, um ~~eine~~ ~~verschlüsselte~~ TLS-Verbindung mit Klienten zu ermöglichen. Bei der älteren Version tls-crypt(-v1), bei dem sowohl der Server als auch die Klienten einen vorher geteilten Schlüssel nutzen, gab es das Risiko, dass nach ~~Komprimitierung~~ eines einzelnen Schlüssels, die gesamte Sicherheit verloren ist. tls-crypt-v2 unterscheidet sich dadurch, dass jeder Klient einen eigenen Schlüssel bekommt.		Im folgenden wird das tls-crypt-v2 [https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt] Verfahren besprochen, welches von OpenVPN Servern genutzt werden kann, um bereits den TLS-Handshake symmetrisch zu verschlüsseln, um eine quentensichere Verbindung mit Klienten zu ermöglichen (also den Diffie-Hellmann-Schlüsselaustausch zusätzlich zu schützen). Bei der älteren Version tls-crypt(-v1), bei dem sowohl der Server als auch die Klienten einen vorher geteilten Schlüssel nutzen, gab es das Risiko, dass nach Kompromittierung eines einzelnen Schlüssels, die gesamte Sicherheit verloren ist. tls-crypt-v2 unterscheidet sich dadurch, dass jeder Klient einen eigenen Schlüssel bekommt.

	Jeder klientspezifische Schlüssel wird zusätzlich mit den Schlüssen des Servers "gewrappt", d.h. er wird verschlüsselt und ein HMAC gebildet. Dieser gewrappte Key wird in der operativen Phase, also beim Verbindungsaufbau, an den Server geschickt. Bei erfolgreicher Entschlüsselung und Authentifizierung kann die verschlüsselte Kommunikation über den Klientenschlüssel beginnen.		Jeder klientspezifische Schlüssel wird zusätzlich mit den Schlüssen des Servers "gewrappt", d.h. er wird verschlüsselt und ein HMAC gebildet. Dieser gewrappte Key wird in der operativen Phase, also beim Verbindungsaufbau, an den Server geschickt. Bei erfolgreicher Entschlüsselung und Authentifizierung kann die verschlüsselte Kommunikation über den Klientenschlüssel beginnen.

Vogtmarv: /* Guthaben verändern */

2022-10-18T17:33:12Z

Guthaben verändern

← Older revision		Revision as of 17:33, 18 October 2022
Line 52:		Line 52:
	Alternativ kann das Guthaben auch mit <code>B030000001[AMOUNT, 1 Bytes]</code> reduziert werden.		Alternativ kann das Guthaben auch mit <code>B030000001[AMOUNT, 1 Bytes]</code> reduziert werden.

	Von besonderem Interesse sind hier die mit "A" vorangestellten Teile des Trace, da diese die Kommunikation mit der Karte beschreiben. Im ersten Schritt wird hier sichtbar per Command APDU das Applet ausgewählt, was die Karte mit dem Returncode <code>0x9000</code> (steht für "Erfolgreich") quittiert. Danach erfolgt die Übertragung der für die Guthabenerhöhung zuständige APDU, welche von der Karte ebenfalls mit <code>0x9000</code> beantwortet wird. An den Antworten der Karte ist jeweils auch die Zeit bis zum Eintreffen der Antwort annotiert, was Rückschlüsse auf die Performance der in der Karte ausgeführten Algorithmen zulässt.		Von besonderem Interesse sind hier die mit "A" vorangestellten Teile des Trace, da diese die Kommunikation mit der Karte beschreiben. Im ersten Schritt wird hier sichtbar per Command APDU das Applet ausgewählt, was die Karte mit dem Returncode <code>0x9000</code> (steht für "Erfolgreich") quittiert. Danach erfolgt die Übertragung der für die Guthabenerhöhung zuständige APDU, welche von der Karte ebenfalls mit <code>0x9000</code> beantwortet wird. An den Antworten der Karte ist jeweils auch die Zeit bis zum Eintreffen der Antwort annotiert, was Rückschlüsse auf die Performance der in der Karte ausgeführten Algorithmen, wie des späteren Unwrappings, zulässt.

	===Guthaben auslesen===		===Guthaben auslesen===

Vogtmarv: /* Guthaben verändern */

2022-10-18T17:32:25Z

Guthaben verändern

← Older revision		Revision as of 17:32, 18 October 2022
Line 52:		Line 52:
	Alternativ kann das Guthaben auch mit <code>B030000001[AMOUNT, 1 Bytes]</code> reduziert werden.		Alternativ kann das Guthaben auch mit <code>B030000001[AMOUNT, 1 Bytes]</code> reduziert werden.

	Von besonderem Interesse sind hier die mit "A" vorangestellten Teile des Trace, da diese die Kommunikation mit der Karte beschreiben. Im ersten Schritt wird hier sichtbar per Command APDU das Applet ausgewählt, was die Karte mit dem Returncode <code>0x9000</code> (steht für "Erfolgreich") quittiert. Danach erfolgt die Übertragung der für die Guthabenerhöhung zuständige APDU, welche von der Karte ebenfalls mit <code>0x9000</code> beantwortet wird. An den Antworten der Karte ist jeweils auch die Zeit bis zum Eintreffen der Antwort annotiert.		Von besonderem Interesse sind hier die mit "A" vorangestellten Teile des Trace, da diese die Kommunikation mit der Karte beschreiben. Im ersten Schritt wird hier sichtbar per Command APDU das Applet ausgewählt, was die Karte mit dem Returncode <code>0x9000</code> (steht für "Erfolgreich") quittiert. Danach erfolgt die Übertragung der für die Guthabenerhöhung zuständige APDU, welche von der Karte ebenfalls mit <code>0x9000</code> beantwortet wird. An den Antworten der Karte ist jeweils auch die Zeit bis zum Eintreffen der Antwort annotiert, was Rückschlüsse auf die Performance der in der Karte ausgeführten Algorithmen zulässt.

	===Guthaben auslesen===		===Guthaben auslesen===

Vogtmarv: /* Guthaben verändern */

2022-10-18T17:28:34Z

Guthaben verändern

← Older revision		Revision as of 17:28, 18 October 2022
Line 50:		Line 50:
	</pre>		</pre>

	Alternativ kann das Guthaben auch mit <code>B030000001[AMOUNT, 1 Bytes]</code> reduziert werden. ~~Die Antwort <code>0x9000</code> steht hier für "Erfolgreich".~~		Alternativ kann das Guthaben auch mit <code>B030000001[AMOUNT, 1 Bytes]</code> reduziert werden.

			Von besonderem Interesse sind hier die mit "A" vorangestellten Teile des Trace, da diese die Kommunikation mit der Karte beschreiben. Im ersten Schritt wird hier sichtbar per Command APDU das Applet ausgewählt, was die Karte mit dem Returncode <code>0x9000</code> (steht für "Erfolgreich") quittiert. Danach erfolgt die Übertragung der für die Guthabenerhöhung zuständige APDU, welche von der Karte ebenfalls mit <code>0x9000</code> beantwortet wird. An den Antworten der Karte ist jeweils auch die Zeit bis zum Eintreffen der Antwort annotiert.

	===Guthaben auslesen===		===Guthaben auslesen===

Kantiemp: /* Implementierung */

2022-10-15T16:24:38Z

Implementierung

Show changes