Safer netboot - Revision history

Wolfm: /* Weitere Ideen ... */

2019-11-15T12:34:38Z

Weitere Ideen ...

← Older revision		Revision as of 12:34, 15 November 2019
Line 249:		Line 249:
	* Die Anforderung 1. kann zumindest halbwegs mit abgeschlossenen Gehäusen in Poolräumen, oder Onboard-Netzwerkkarten, oder bei Servern mit schlicht und einfach nicht zugänglichen Räumen umgesetzt werden. Die Anforderung 2. setzt 3. voraus und ist in den meisten Fällen ohnehin zu erfüllen, um einen sicheren Rechnerbetrieb zu gewährleisten. Anforderung 3. kann über das setzen der Bootorder, Abschalten externer Laufwerke zum Booten mit dem BIOS-Passwort abgesichert werden.		* Die Anforderung 1. kann zumindest halbwegs mit abgeschlossenen Gehäusen in Poolräumen, oder Onboard-Netzwerkkarten, oder bei Servern mit schlicht und einfach nicht zugänglichen Räumen umgesetzt werden. Die Anforderung 2. setzt 3. voraus und ist in den meisten Fällen ohnehin zu erfüllen, um einen sicheren Rechnerbetrieb zu gewährleisten. Anforderung 3. kann über das setzen der Bootorder, Abschalten externer Laufwerke zum Booten mit dem BIOS-Passwort abgesichert werden.

	=== Weitere Ideen ~~...~~ ===		=== Weitere Ideen ===
	* Um z.B. Poolrechner mit individuellen Konfigurationen, privaten Schlüsseln, oder Scripten aus dem Netz zu booten, kann benutzt werden, dass mehrere INITRD-Einträge in iPXE benutzt werden können. Man könnte also etwa durch den Webserver für alle Poolrechner KERNEL und INITRD gemeinsam vorhalten und die individuellen (kleinen) Zusätze in eine extra INITRDX auslagern, die dann der Webserver statisch vorhält oder dynamisch erzeugt und gemäß der durch das jeweilige Clientzertifikat bewiesenen Identität des bootenden Rechners ausgeliefert wird. <source lang=bash>		* Um z.B. Poolrechner mit individuellen Konfigurationen, privaten Schlüsseln, oder Scripten aus dem Netz zu booten, kann benutzt werden, dass mehrere INITRD-Einträge in iPXE benutzt werden können. Man könnte also etwa durch den Webserver für alle Poolrechner KERNEL und INITRD gemeinsam vorhalten und die individuellen (kleinen) Zusätze in eine extra INITRDX auslagern, die dann der Webserver statisch vorhält oder dynamisch erzeugt und gemäß der durch das jeweilige Clientzertifikat bewiesenen Identität des bootenden Rechners ausgeliefert wird. <source lang=bash>
	#!ipxe # Shebang		#!ipxe # Shebang

Wolfm: /* Weitere Ideen ... */

2019-11-15T12:32:28Z

Weitere Ideen ...

← Older revision		Revision as of 12:32, 15 November 2019
Line 255:		Line 255:
	kernel https://192.168.5.22/vmlinuz # lade Kernel über HTTPS von URL		kernel https://192.168.5.22/vmlinuz # lade Kernel über HTTPS von URL
	initrd https://192.168.5.22/initrd # lade initrd über HTTPS von URL		initrd https://192.168.5.22/initrd # lade initrd über HTTPS von URL
			# lade zusätzliche Datei, blende diese unter dem Namen /sbin/init mit den Rechten 755 ein.
	initrd https://192.168.5.22/initrdx ~~# lade individualisierte initrdx~~		initrd https://192.168.5.22/initrdx /sbin/init mode=755
	boot # Bootvorgang		boot # Bootvorgang
	</source> Das sollte dazu führen, dass das Default-Dateisystem in der INITRD in iPXE mit den Zusätzen in INITRDX überlagert wird.		</source> Das sollte gemäß [[https://ipxe.org/cmd/imgfetch\| iPXE Dokumentation initrd]] dazu führen, dass das Default-Dateisystem in der INITRD in iPXE mit den Zusätzen in INITRDX überlagert wird.
	* Auch das beidseitig authentisierte Nachladen von iPXE-Skripten und anzeigen von Bootmenüs und anschließende Booten von anderen Systemen (KERNEL+INITRD) könnte ausgetestet werden.		* Auch das beidseitig authentisierte Nachladen von iPXE-Skripten und anzeigen von Bootmenüs und anschließende Booten von anderen Systemen (KERNEL+INITRD) könnte ausgetestet werden.
	* Zusätzlich zur Authentisierung mit Clientzertifikaten scheint iPXE auch eine "Basic Auth" auf Basis von Passworten gegenüber dem Webserver zu unterstützen. So wäre es denkbar, beim Booten die Wahl zwischen verschiedenen Systemen zwar anzubieten, das Defaultsystem könnte automatisch nach einem kurzen Timout gebootet werden. Wird jedoch ein anderer Eintrag gewählt, der z.B. nur für Administratoren zugänglich sein, so könnte dieser dann zum Download der Kernels+INITRD oder weiterer iPXE-Skripte zusätzlich ein Passwort erfordern.		* Zusätzlich zur Authentisierung mit Clientzertifikaten scheint iPXE auch eine "Basic Auth" auf Basis von Passworten gegenüber dem Webserver zu unterstützen. So wäre es denkbar, beim Booten die Wahl zwischen verschiedenen Systemen zwar anzubieten, das Defaultsystem könnte automatisch nach einem kurzen Timout gebootet werden. Wird jedoch ein anderer Eintrag gewählt, der z.B. nur für Administratoren zugänglich sein, so könnte dieser dann zum Download der Kernels+INITRD oder weiterer iPXE-Skripte zusätzlich ein Passwort erfordern.

Wolfm: /* Weitere Ideen ... */

2019-11-15T12:22:57Z

Weitere Ideen ...

← Older revision		Revision as of 12:22, 15 November 2019
Line 261:		Line 261:
	* Zusätzlich zur Authentisierung mit Clientzertifikaten scheint iPXE auch eine "Basic Auth" auf Basis von Passworten gegenüber dem Webserver zu unterstützen. So wäre es denkbar, beim Booten die Wahl zwischen verschiedenen Systemen zwar anzubieten, das Defaultsystem könnte automatisch nach einem kurzen Timout gebootet werden. Wird jedoch ein anderer Eintrag gewählt, der z.B. nur für Administratoren zugänglich sein, so könnte dieser dann zum Download der Kernels+INITRD oder weiterer iPXE-Skripte zusätzlich ein Passwort erfordern.		* Zusätzlich zur Authentisierung mit Clientzertifikaten scheint iPXE auch eine "Basic Auth" auf Basis von Passworten gegenüber dem Webserver zu unterstützen. So wäre es denkbar, beim Booten die Wahl zwischen verschiedenen Systemen zwar anzubieten, das Defaultsystem könnte automatisch nach einem kurzen Timout gebootet werden. Wird jedoch ein anderer Eintrag gewählt, der z.B. nur für Administratoren zugänglich sein, so könnte dieser dann zum Download der Kernels+INITRD oder weiterer iPXE-Skripte zusätzlich ein Passwort erfordern.
	* Beim CHAIN-BOOT ist zu beachten, dass nach dem Booten eines anderen Kernels die der Firmware der Netzwerkkarte hinterlegten Zertifikat und der private Schlüssel zum Clientzertifikat nicht mehr benutzt werden können.		* Beim CHAIN-BOOT ist zu beachten, dass nach dem Booten eines anderen Kernels die der Firmware der Netzwerkkarte hinterlegten Zertifikat und der private Schlüssel zum Clientzertifikat nicht mehr benutzt werden können.
	* Nicht benötigte Boot-Mechanismen im iPXE sollten im Konfigurationsfile ggf. abgeschaltet werden <code>/src/config/general.h<code>, damit das erzeugte ROM nicht größer als nötig wird und keine unnötige Angriffsfläche geboten wird.		* Nicht benötigte Boot-Mechanismen im iPXE sollten im Konfigurationsfile ggf. abgeschaltet werden <code>/src/config/general.h</code>, damit das erzeugte ROM nicht größer als nötig wird und keine unnötige Angriffsfläche geboten wird.
	* Auch nachgeladene iPXE-Skripte sollten nicht gestatten, in iPXE als Shell eigene Kommandos einzugeben (außer, der Zugriff erforderte bereits eine stärkere Authentisierung, wie das Administratorpasswort).		* Auch nachgeladene iPXE-Skripte sollten nicht gestatten, in iPXE als Shell eigene Kommandos einzugeben (außer, der Zugriff erforderte bereits eine stärkere Authentisierung, wie das Administratorpasswort).

Wolfm: /* Weitere Ideen ... */

2019-11-15T12:22:34Z

Weitere Ideen ...

← Older revision		Revision as of 12:22, 15 November 2019
Line 260:		Line 260:
	* Auch das beidseitig authentisierte Nachladen von iPXE-Skripten und anzeigen von Bootmenüs und anschließende Booten von anderen Systemen (KERNEL+INITRD) könnte ausgetestet werden.		* Auch das beidseitig authentisierte Nachladen von iPXE-Skripten und anzeigen von Bootmenüs und anschließende Booten von anderen Systemen (KERNEL+INITRD) könnte ausgetestet werden.
	* Zusätzlich zur Authentisierung mit Clientzertifikaten scheint iPXE auch eine "Basic Auth" auf Basis von Passworten gegenüber dem Webserver zu unterstützen. So wäre es denkbar, beim Booten die Wahl zwischen verschiedenen Systemen zwar anzubieten, das Defaultsystem könnte automatisch nach einem kurzen Timout gebootet werden. Wird jedoch ein anderer Eintrag gewählt, der z.B. nur für Administratoren zugänglich sein, so könnte dieser dann zum Download der Kernels+INITRD oder weiterer iPXE-Skripte zusätzlich ein Passwort erfordern.		* Zusätzlich zur Authentisierung mit Clientzertifikaten scheint iPXE auch eine "Basic Auth" auf Basis von Passworten gegenüber dem Webserver zu unterstützen. So wäre es denkbar, beim Booten die Wahl zwischen verschiedenen Systemen zwar anzubieten, das Defaultsystem könnte automatisch nach einem kurzen Timout gebootet werden. Wird jedoch ein anderer Eintrag gewählt, der z.B. nur für Administratoren zugänglich sein, so könnte dieser dann zum Download der Kernels+INITRD oder weiterer iPXE-Skripte zusätzlich ein Passwort erfordern.
			* Beim CHAIN-BOOT ist zu beachten, dass nach dem Booten eines anderen Kernels die der Firmware der Netzwerkkarte hinterlegten Zertifikat und der private Schlüssel zum Clientzertifikat nicht mehr benutzt werden können.
			* Nicht benötigte Boot-Mechanismen im iPXE sollten im Konfigurationsfile ggf. abgeschaltet werden <code>/src/config/general.h<code>, damit das erzeugte ROM nicht größer als nötig wird und keine unnötige Angriffsfläche geboten wird.
			* Auch nachgeladene iPXE-Skripte sollten nicht gestatten, in iPXE als Shell eigene Kommandos einzugeben (außer, der Zugriff erforderte bereits eine stärkere Authentisierung, wie das Administratorpasswort).

Wolfm: /* Weitere Ideen ... */

2019-11-15T12:13:01Z

Weitere Ideen ...

← Older revision		Revision as of 12:13, 15 November 2019
Line 250:		Line 250:

	=== Weitere Ideen ... ===		=== Weitere Ideen ... ===
	* Um z.B. Poolrechner mit individuellen Konfigurationen, privaten Schlüsseln, oder Scripten aus dem Netz zu booten, kann benutzt werden, dass mehrere INITRD-Einträge in iPXE benutzt werden können. Man könnte also etwa durch den Webserver für alle Poolrechner KERNEL und INITRD gemeinsam vorhalten und die individuellen (kleinen) Zusätze in eine extra INITRDX auslagern, die dann der Webserver statisch vorhält oder dynamisch erzeugt und gemäß der durch das jeweilige Clientzertifikat bewiesenen Identität des bootenden Rechners ausgeliefert wird.		* Um z.B. Poolrechner mit individuellen Konfigurationen, privaten Schlüsseln, oder Scripten aus dem Netz zu booten, kann benutzt werden, dass mehrere INITRD-Einträge in iPXE benutzt werden können. Man könnte also etwa durch den Webserver für alle Poolrechner KERNEL und INITRD gemeinsam vorhalten und die individuellen (kleinen) Zusätze in eine extra INITRDX auslagern, die dann der Webserver statisch vorhält oder dynamisch erzeugt und gemäß der durch das jeweilige Clientzertifikat bewiesenen Identität des bootenden Rechners ausgeliefert wird. <source lang=bash>
	<source lang=bash>
	#!ipxe # Shebang		#!ipxe # Shebang
	dhcp # Netzwerkkonfiguration über DHCP bekommen		dhcp # Netzwerkkonfiguration über DHCP bekommen
Line 258:		Line 257:
	initrd https://192.168.5.22/initrdx # lade individualisierte initrdx		initrd https://192.168.5.22/initrdx # lade individualisierte initrdx
	boot # Bootvorgang		boot # Bootvorgang
			</source> Das sollte dazu führen, dass das Default-Dateisystem in der INITRD in iPXE mit den Zusätzen in INITRDX überlagert wird.
	</source>
			* Auch das beidseitig authentisierte Nachladen von iPXE-Skripten und anzeigen von Bootmenüs und anschließende Booten von anderen Systemen (KERNEL+INITRD) könnte ausgetestet werden.
			* Zusätzlich zur Authentisierung mit Clientzertifikaten scheint iPXE auch eine "Basic Auth" auf Basis von Passworten gegenüber dem Webserver zu unterstützen. So wäre es denkbar, beim Booten die Wahl zwischen verschiedenen Systemen zwar anzubieten, das Defaultsystem könnte automatisch nach einem kurzen Timout gebootet werden. Wird jedoch ein anderer Eintrag gewählt, der z.B. nur für Administratoren zugänglich sein, so könnte dieser dann zum Download der Kernels+INITRD oder weiterer iPXE-Skripte zusätzlich ein Passwort erfordern.

Wolfm: /* Weitere Ideen ... */

2019-11-15T12:02:57Z

Weitere Ideen ...

← Older revision		Revision as of 12:02, 15 November 2019
Line 251:		Line 251:
	=== Weitere Ideen ... ===		=== Weitere Ideen ... ===
	* Um z.B. Poolrechner mit individuellen Konfigurationen, privaten Schlüsseln, oder Scripten aus dem Netz zu booten, kann benutzt werden, dass mehrere INITRD-Einträge in iPXE benutzt werden können. Man könnte also etwa durch den Webserver für alle Poolrechner KERNEL und INITRD gemeinsam vorhalten und die individuellen (kleinen) Zusätze in eine extra INITRDX auslagern, die dann der Webserver statisch vorhält oder dynamisch erzeugt und gemäß der durch das jeweilige Clientzertifikat bewiesenen Identität des bootenden Rechners ausgeliefert wird.		* Um z.B. Poolrechner mit individuellen Konfigurationen, privaten Schlüsseln, oder Scripten aus dem Netz zu booten, kann benutzt werden, dass mehrere INITRD-Einträge in iPXE benutzt werden können. Man könnte also etwa durch den Webserver für alle Poolrechner KERNEL und INITRD gemeinsam vorhalten und die individuellen (kleinen) Zusätze in eine extra INITRDX auslagern, die dann der Webserver statisch vorhält oder dynamisch erzeugt und gemäß der durch das jeweilige Clientzertifikat bewiesenen Identität des bootenden Rechners ausgeliefert wird.
			<source lang=bash>
	#!ipxe # Shebang		#!ipxe # Shebang
	dhcp # Netzwerkkonfiguration über DHCP bekommen		dhcp # Netzwerkkonfiguration über DHCP bekommen

Wolfm: /* Bemerkungen, Probleme, Ideen */

2019-11-15T12:02:18Z

Bemerkungen, Probleme, Ideen

← Older revision		Revision as of 12:02, 15 November 2019
Line 239:		Line 239:
	Damit ist im Sinne eines Proof of Concept gezeigt, dass der von uns gewählte Ansatz geeignet ist, das Booten aus dem Netzwerk abzusichern.		Damit ist im Sinne eines Proof of Concept gezeigt, dass der von uns gewählte Ansatz geeignet ist, das Booten aus dem Netzwerk abzusichern.

	=== Bemerkungen, Probleme~~, Ideen~~ ===		=== Bemerkungen, Probleme===
	* iPXE unterstützt als stärkste <code>Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)</code> und bietet diese zur Aushandlung im ClientHello auch an. Der Apache sollte so konfiguriert werden, dass diese auch gewählt wird. "forward secure" Cipher Suites sind nicht möglich. Dies ist für unser Szenario aber hinnehmbar.		* iPXE unterstützt als stärkste <code>Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)</code> und bietet diese zur Aushandlung im ClientHello auch an. Der Apache sollte so konfiguriert werden, dass diese auch gewählt wird. "forward secure" Cipher Suites sind nicht möglich. Dies ist für unser Szenario aber hinnehmbar.
	* Es ist zumindest überlegenswert, 3072 Bit oder gar 4096 Bit RSA-Schlüssel zu verwenden, um eine dauerhaft sicherere Authentifizierungsmethode zu verwenden, da das Flashen relativ langwierig ist. Entsprechend könnten auch die Laufzeiten der CA sowie der im ROM enthaltenen Clientzertifikate erhöht werden (orientiert an: BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen).		* Es ist zumindest überlegenswert, 3072 Bit oder gar 4096 Bit RSA-Schlüssel zu verwenden, um eine dauerhaft sicherere Authentifizierungsmethode zu verwenden, da das Flashen relativ langwierig ist. Entsprechend könnten auch die Laufzeiten der CA sowie der im ROM enthaltenen Clientzertifikate erhöht werden (orientiert an: BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen).
	* Wenn das System produktiv eingesetzt werden soll, ist es aus unser Sicht unbedingt kompromittiere oder nicht mehr genutzte Zertifikate revoziert werden und die CRL auch vom [[Safer_netboot#apache.conf\|Webserver (bislang auskommentiert)]] geprüft werden.		* Wenn das System produktiv eingesetzt werden soll, ist es aus unser Sicht unbedingt kompromittiere oder nicht mehr genutzte Zertifikate revoziert werden und die CRL auch vom [[Safer_netboot#apache.conf\|Webserver (bislang auskommentiert)]] geprüft werden.
	* Man sollte sich bewusst sein, dass der '''private Schlüssel''' zum Clientzertifikat in der Firmware auf der Netzkarte gespeichert ist. Wie wir beim erstellen gesehen haben, kann man das ROM von dort auch wieder auslesen, wenn man Zugriff mit Root-Rechten auf die ~~Netzwerkarte~~ hat. Daraus ergeben sich die folgenden Anforderungen, um den '''Schlüssel zu schützen''':		* Man sollte sich bewusst sein, dass der '''private Schlüssel''' zum Clientzertifikat in der Firmware auf der Netzkarte gespeichert ist. Wie wir beim erstellen gesehen haben, kann man das ROM von dort auch wieder auslesen, wenn man Zugriff mit Root-Rechten auf die Netzwerkkarte hat. Daraus ergeben sich die folgenden Anforderungen, um den '''Schlüssel zu schützen''':
	# Angreifer dürfen keinen physischen Zugriff zu der Netzwerkkarte bekommen!		*# Angreifer dürfen keinen physischen Zugriff zu der Netzwerkkarte bekommen!
	# Angreifer dürfen nicht Root-Rechten im gebooteten Betriebssystem bekommen!		*# Angreifer dürfen nicht Root-Rechten im gebooteten Betriebssystem bekommen!
	# Angreifern darf es nicht möglich sein, ein andres OS zu booten!		*# Angreifern darf es nicht möglich sein, ein andres OS zu booten!
	Die Anforderung 1.) kann zumindest halbwegs mit abgeschlossenen Gehäusen in Poolräumen, oder Onboard-Netzwerkkarten, oder bei Servern mit schlicht und einfach nicht zugänglichen Räumen umgesetzt werden. Die Anforderung 2.) setzt 3.) voraus und ist in den meisten Fällen ohnehin zu erfüllen, um einen sicheren Rechnerbetrieb zu gewährleisten.		* Die Anforderung 1. kann zumindest halbwegs mit abgeschlossenen Gehäusen in Poolräumen, oder Onboard-Netzwerkkarten, oder bei Servern mit schlicht und einfach nicht zugänglichen Räumen umgesetzt werden. Die Anforderung 2. setzt 3. voraus und ist in den meisten Fällen ohnehin zu erfüllen, um einen sicheren Rechnerbetrieb zu gewährleisten. Anforderung 3. kann über das setzen der Bootorder, Abschalten externer Laufwerke zum Booten mit dem BIOS-Passwort abgesichert werden.

			=== Weitere Ideen ... ===
			* Um z.B. Poolrechner mit individuellen Konfigurationen, privaten Schlüsseln, oder Scripten aus dem Netz zu booten, kann benutzt werden, dass mehrere INITRD-Einträge in iPXE benutzt werden können. Man könnte also etwa durch den Webserver für alle Poolrechner KERNEL und INITRD gemeinsam vorhalten und die individuellen (kleinen) Zusätze in eine extra INITRDX auslagern, die dann der Webserver statisch vorhält oder dynamisch erzeugt und gemäß der durch das jeweilige Clientzertifikat bewiesenen Identität des bootenden Rechners ausgeliefert wird.
			#!ipxe # Shebang
			dhcp # Netzwerkkonfiguration über DHCP bekommen
			kernel https://192.168.5.22/vmlinuz # lade Kernel über HTTPS von URL
			initrd https://192.168.5.22/initrd # lade initrd über HTTPS von URL
			initrd https://192.168.5.22/initrdx # lade individualisierte initrdx
			boot # Bootvorgang
			</source>

Wolfm: /* Bemerkungen, Probleme, Ideen */

2019-11-15T10:01:06Z

Bemerkungen, Probleme, Ideen

← Older revision		Revision as of 10:01, 15 November 2019
Line 247:		Line 247:
	# Angreifer dürfen nicht Root-Rechten im gebooteten Betriebssystem bekommen!		# Angreifer dürfen nicht Root-Rechten im gebooteten Betriebssystem bekommen!
	# Angreifern darf es nicht möglich sein, ein andres OS zu booten!		# Angreifern darf es nicht möglich sein, ein andres OS zu booten!
			Die Anforderung 1.) kann zumindest halbwegs mit abgeschlossenen Gehäusen in Poolräumen, oder Onboard-Netzwerkkarten, oder bei Servern mit schlicht und einfach nicht zugänglichen Räumen umgesetzt werden. Die Anforderung 2.) setzt 3.) voraus und ist in den meisten Fällen ohnehin zu erfüllen, um einen sicheren Rechnerbetrieb zu gewährleisten.

Wolfm: /* Bemerkungen, Probleme, Ideen */

2019-11-15T09:06:09Z

Bemerkungen, Probleme, Ideen

← Older revision		Revision as of 09:06, 15 November 2019
Line 241:		Line 241:
	=== Bemerkungen, Probleme, Ideen ===		=== Bemerkungen, Probleme, Ideen ===
	* iPXE unterstützt als stärkste <code>Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)</code> und bietet diese zur Aushandlung im ClientHello auch an. Der Apache sollte so konfiguriert werden, dass diese auch gewählt wird. "forward secure" Cipher Suites sind nicht möglich. Dies ist für unser Szenario aber hinnehmbar.		* iPXE unterstützt als stärkste <code>Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)</code> und bietet diese zur Aushandlung im ClientHello auch an. Der Apache sollte so konfiguriert werden, dass diese auch gewählt wird. "forward secure" Cipher Suites sind nicht möglich. Dies ist für unser Szenario aber hinnehmbar.
	* Es ist zumindest überlegenswert, 3072 Bit oder gar 4096 Bit RSA ~~schlüssel~~ zu verwenden, um eine dauerhaft sicherere Authentifizierungsmethode zu verwenden, da das ~~Flaschen~~ relativ langwierig ist. Entsprechend könnten auch die Laufzeiten der CA sowie der im ROM enthaltenen Clientzertifikate erhöht werden (orientiert an: BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen).		* Es ist zumindest überlegenswert, 3072 Bit oder gar 4096 Bit RSA-Schlüssel zu verwenden, um eine dauerhaft sicherere Authentifizierungsmethode zu verwenden, da das Flashen relativ langwierig ist. Entsprechend könnten auch die Laufzeiten der CA sowie der im ROM enthaltenen Clientzertifikate erhöht werden (orientiert an: BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen).
	* Wenn das System produktiv eingesetzt werden soll, ist es aus unser Sicht unbedingt kompromittiere oder nicht mehr genutzte Zertifikate revoziert werden und die CRL auch vom [[Safer_netboot#apache.conf\|Webserver (bislang auskommentiert)]] geprüft werden.		* Wenn das System produktiv eingesetzt werden soll, ist es aus unser Sicht unbedingt kompromittiere oder nicht mehr genutzte Zertifikate revoziert werden und die CRL auch vom [[Safer_netboot#apache.conf\|Webserver (bislang auskommentiert)]] geprüft werden.
	* Man sollte sich bewusst sein, dass der '''private Schlüssel''' zum Clientzertifikat in der Firmware auf der Netzkarte gespeichert ist. Wie wir beim erstellen gesehen haben, kann man das ROM von dort auch wieder auslesen, wenn man Zugriff mit Root-Rechten auf die Netzwerkarte hat. Daraus ergeben sich die folgenden Anforderungen, um den '''Schlüssel zu schützen''':		* Man sollte sich bewusst sein, dass der '''private Schlüssel''' zum Clientzertifikat in der Firmware auf der Netzkarte gespeichert ist. Wie wir beim erstellen gesehen haben, kann man das ROM von dort auch wieder auslesen, wenn man Zugriff mit Root-Rechten auf die Netzwerkarte hat. Daraus ergeben sich die folgenden Anforderungen, um den '''Schlüssel zu schützen''':

Wolfm: /* Bemerkungen, Probleme, Ideen */

2019-11-07T07:19:30Z

Bemerkungen, Probleme, Ideen

← Older revision		Revision as of 07:19, 7 November 2019
Line 244:		Line 244:
	* Wenn das System produktiv eingesetzt werden soll, ist es aus unser Sicht unbedingt kompromittiere oder nicht mehr genutzte Zertifikate revoziert werden und die CRL auch vom [[Safer_netboot#apache.conf\|Webserver (bislang auskommentiert)]] geprüft werden.		* Wenn das System produktiv eingesetzt werden soll, ist es aus unser Sicht unbedingt kompromittiere oder nicht mehr genutzte Zertifikate revoziert werden und die CRL auch vom [[Safer_netboot#apache.conf\|Webserver (bislang auskommentiert)]] geprüft werden.
	* Man sollte sich bewusst sein, dass der '''private Schlüssel''' zum Clientzertifikat in der Firmware auf der Netzkarte gespeichert ist. Wie wir beim erstellen gesehen haben, kann man das ROM von dort auch wieder auslesen, wenn man Zugriff mit Root-Rechten auf die Netzwerkarte hat. Daraus ergeben sich die folgenden Anforderungen, um den '''Schlüssel zu schützen''':		* Man sollte sich bewusst sein, dass der '''private Schlüssel''' zum Clientzertifikat in der Firmware auf der Netzkarte gespeichert ist. Wie wir beim erstellen gesehen haben, kann man das ROM von dort auch wieder auslesen, wenn man Zugriff mit Root-Rechten auf die Netzwerkarte hat. Daraus ergeben sich die folgenden Anforderungen, um den '''Schlüssel zu schützen''':
	** Angreifer dürfen keinen physischen Zugriff zu der Netzwerkkarte bekommen!		# Angreifer dürfen keinen physischen Zugriff zu der Netzwerkkarte bekommen!
	** Angreifer dürfen nicht Root-Rechten im gebooteten Betriebssystem bekommen!		# Angreifer dürfen nicht Root-Rechten im gebooteten Betriebssystem bekommen!
	** Angreifern darf es nicht möglich sein, ein andres OS zu booten!		# Angreifern darf es nicht möglich sein, ein andres OS zu booten!