[English]Microsoft forciert für Windows 10-Systeme ja UEFI und den Secure Boot zur Absicherung. Möglicherweise sind einige Insides zum Secure-Boot auf UEFI-Systemen unter Windows 10 (64 Bit) von Interesse.
Anzeige
Ich bin die Tage zufällig auf den Tweet von Ex-Microsoft-Mitarbeiter Michael Niehaus gestoßen, der in seinem privaten Blog über diverse Themen im Umfeld von Windows bloggt.
In seinem Blog-Beitrag UEFI Secure Boot: Who controls what can run? hat Niehaus einen Blick auf die Frage geworfen, wer kontrolliert, was gestartet werden darf. In der Secure Boot db sollten auf jeden Fall zwei Einträge für Zertifikatsschlüssel sein:
- Microsoft Windows Production PCA 2011. Der Windows-Bootloader (bootmgr.efi) ist damit signiert, so dass Windows (und Windows PE) damit ausgeführt werden kann.
- Microsoft Corporation UEFI CA 2011. Dieser Key wird von Microsoft verwendet, um Nicht-Microsoft-UEFI-Bootloader zu signieren, z. B. solche, die zum Laden von Linux oder anderen Betriebssystemen verwendet werden.
Technisch gesehen ist das CA 2011 als "optional" beschrieben, aber es wäre ungewöhnlich, wenn ein Gerät den Eintrag nicht enthält. Die weiteren Ausführungen im Blog-Beitrag sind vielleicht ganz hilfreich, wenn man wissen möchte, welche Einträge in der db enthalten sein sollen.
Anzeige
In einem zweiten Blog-Beitrag UEFI Secure Boot: Yes, again, der in obigem Tweet verlinkt ist, geht Niehaus auf weitere Details der Secure Boot "db" auf UEFI-Geräten ein. Es gibt vier UEFI-Variablen:
- db, die "signature database" (Signaturdatenbank). Einträge hier (typischerweise Zertifikate) bestimmen, welche EFI-Executables auf dem Gerät ausgeführt werden dürfen. Dies ist also eine "erlaubte" Liste.
- dbx, die "forbidden signatures database". Einträge hier sind typischerweise SHA256-Hashes von bestimmten UEFI-Binärdateien, d.h. von Dingen, die mit einem Zertifikat in der "db"-Liste signiert wurden, sich aber später als schlecht herausstellten (z.B. eine Sicherheitslücke aufwiesen, die die Firmware kompromittiert). Dies ist also eine "Block"-Liste.
- kek, der "key exchange key" (Schlüsselaustauschschlüssel). Damit wird festgelegt, wer die Signaturdatenbank aktualisieren darf (die "db"- und "dbx"-Schlüssel). Interessanterweise können alle mit dem "kek"-Schlüssel signierten UEFI-Binärdateien auch auf dem Gerät booten.
- pk, der "platform key" (Plattformschlüssel). Die Variable "pk" enthält ein einzelnes Zertifikat, das den Zugriff auf die Variablen "kek" und "db" steuert. Wenn dieser Wert gelöscht wird, wird Secure Boot effektiv ausgeschaltet (das Gerät wird in den Setup-Modus versetzt).
UEFI erlaubt die Ausführung einer UEFI-Binärdatei, wenn folgende Bedingungen erfüllt sind:
- diese ist mit einem Schlüssel in der "db" signiert oder hat seinen Hash explizit in der "db"
- diese ist mit einem Schlüssel im "kek" signiert (scheint ungewöhnlich zu sein)
- der Hash der UEFI-Binärdatei befindet sich nicht in der "dbx"-Liste.
Niehaus zeigt in seinem Blog-Beitrag die Auflistung der betreffenden Einträge für ein UEFI-System und gibt weitere Erklärungen rund um dieses Thema. Gegebenenfalls Lesefutter für Administratoren, die näheres zu diesem Thema wissen möchten.
Anzeige
Vor der Auslieferung eines Mainboards mit UEFI flasht der OEM mit der UEFI-Firmware auch die Secure-Boot-Datenbank auf das Gerät. Diese enthält die autorisierte Datenbank (db), die nicht autorisierte Datenbank (dbx), den Key Exchange Key (KEK) und den Platform Key (PK). Diese werden wie die Firmware in nicht-flüchtigem Speicher abgelegt.
Die autorisierte Datenbank (db) enthält Zertifikate und Hashes von vertrauenswürdigen Bootloadern, die nicht autorisierte Datenbank (dbx) mehrere Zertifikate oder Hashes zur Identifizierung von kompromittiertem Code. Um die beiden Datenbanken zu ändern, wird der private Teil des Key Exchange Key (KEK) benötigt, dessen öffentlicher Teil in der KEK-Datenbank des UEFI liegt. Microsoft schreibt vor, dass ihr eigener KEK in dieser Datenbank liegen muss, um neue Bootloader oder Hashes hinzufügen zu können.
Quelle: https://trustedwindows.wordpress.com/hauptseite/trusted-computing-in-windows/secure-boot/
Ich kann mir nicht helfen, aber je mehr ich mich mit dem Thema befasse, um so weniger komme ich zu dem Schluß, daß es sich hier um einen Sicherheitszugewinn handelt, sondern viel mehr um eine Option, im Falle eines Falles, unbemerkt durch die Hintertür in das System eindringen zu können.
Für dieses "Feature" hätte ich gerne eine neutrale Drittpartei, die nicht einem PatriotAct! unterliegt und eigene Interessen verfolgt.
Ein ganz großes Problem von Secure Boot ist auch, dass man Konkurrenz damit ausschließen kann. Hat diese keine Signatur, kann sie einfach nicht gestartet werden. Und das kann bereits eine nützliche Boot CD wie ein Partitionierer oder Antimalwarescanner sein. Daher ist eine neutrale Drittpartei, die keine (kommerzielle) Interessen verfolgt, zwingend erforderlich. Irgendwann ist sonst soweit, dass der OEM nur booten von Windows erlaubt und den Rest verbietet.
Auch ein sehr gewichtiges Argument Deinerseits, dem ich absolut zustimme.
Jedes UEFI hat die Option Secure boot zu deaktivieren.
Dieses Gesetz USA Patriot Act ist schon seit 2015 nicht mehr in Kraft.
Dieses Gesetz war die Antwort auf 9/11 und die Milzbrandanschläge und sollte die Gefahr möglicher Terroranschläge eindämmen bzw. verhindern.
Abgelöst hat es der sog. USA Freedom Act.
Wer die US-Amerikanische Mentalität kennt, der weiß, dass die Amis auf extreme Situationen mit extremen Gegenmaßnahmen reagieren zu pflegen. Die tun halt alles, dass sich diese schrecklichen Ereignisse von damals nicht wiederholen.
Dass die US-Unternehmen per Gesetz verpflichtet sind, bei Verdachtsfällen und auch ohne richterlichen Beschluss Kundendaten herauszugeben, entspricht der Tatsache.
Offiziell also nur bei Verdachtsfällen, was da inoffiziell und geheim abläuft, kann man nicht wissen, sondern nur vermuten.
Die US-Unternehmen haben keine Wahl und müssen sich an das Gesetz halten. Apple hatte sich mal geweigert, die von einer der Sicherheitsbehörden angeforderten Daten herauszugeben. Wie das Ganze dann letztendlich ausging, weiß man nicht.
Auch Microsoft sieht dieses Gesetz kritisch und hatte das auch schon öffentlich so kundgetan. Den amerikanischen IT-Unternehmen zu unterstellen, dass sie mit Absicht Lücken in ihre Soft- und Hardwareprodukte einbauen würden, nur damit die Geheimdienste leichteres Spiel haben, glaube ich persönlich nicht.
Um in die Systeme zu gelangen, brauchen die keinen Türöffner.
"Dieses Gesetz USA Patriot Act ist schon seit 2015 nicht mehr in Kraft."
***Teile*** des Gesetzes sind am 1. Juni 2015 abgelaufen und wurden tags darauf am 2. Juni 2015 durch die Bestimmungen des USA Freedom Act ersetzt.
Quellen:
https://edition.cnn.com/2015/05/30/politics/what-happens-if-the-patriot-act-provisions-expire
https://www.nbcnews.com/storyline/nsa-snooping/senate-vote-measure-reform-nsa-surveillance-n368341
https://de.wikipedia.org/wiki/USA_PATRIOT_Act
Die Quellenangaben am Ende sind sehr nett.
"Den amerikanischen IT-Unternehmen zu unterstellen, dass sie mit Absicht Lücken in ihre Soft- und Hardwareprodukte einbauen würden, nur damit die Geheimdienste leichteres Spiel haben, glaube ich persönlich nicht."
Das wurde bereits mehrfach nachgewiesen. Zumal sie Kraft Gesetzes auch dazu verpflichtet sind. Dies hat mit Glauben nichts mehr zu tun.
Nachgewiesen wurde es meines Wissens nach bisher nur den beiden chinesischen Staatsunternehmen Huawei und Xiaomi, die das auf den Smartphones installierte OS mit Sicherheitslücken versehen hat. Für die Geräte auf dem europäischen Markt mussten sie diese Lücken wieder schließen.
Auch russischen Softwareentwicklern, wie z.B. Kaspersky, hat man solche Praktiken schon mal nachgewiesen.
Mehr ist mir nicht bekannt und ich finde dazu auch nichts im Netz.
Vielleicht suche ich ja auch falsch und würde mich über seriöse Bezugsquellen, aus denen hervorgeht, dass US-Unternehmen per Gesetz dazu verpflichtet sein sollen, vorsätzlich Sicherheitslücken in ihre Produkte einpflegen zu müssen und dass dies auch bereits nachgewiesen wurde, freuen.
Was diese Sicherheitsaspekte bezüglich UEFI und Secure Boot, sowie dieser Ruf nach Lösungen von "neutralen" Drittanbietern angeht.
Microsoft signiert die Treiber der Drittanbieter bei Bedarf sogar automatisch. Zum Beispiel die für Linux-Distris, damit die in einem Dualsystem mit Windows 10 reibungslos und möglichst sicher betrieben werden können.
Das müsste MS nicht machen, sie tun es aber.
Juniper.
"Das müsste MS nicht machen, sie tun es aber."
Ne, müssten sie nicht. Weil jeder PC der letzten Jahre Secure Boot unterstützt und es bei Fertigrechnern sogar standardmäßig aktiviert sein dürfte, drohen natürlich keinerlei Konsequenzen durch Monopolausnutzung…
Zertifikate haben doch eine begrenzte Lebenszeit? Kann es nicht passieren, das ich meinen Rechner, gekauft 2020, im Jahre 2051 nicht mehr booten kann, weil alle Certs abgelaufen sind, der Board-hersteller schon längst zugemacht hat, und es die Firma Mikrosoft nicht gibt oder weigert, das zu reparieren?
:)
Ja. Die begrenzte Haltbarkeit ist gewollt und keine Notwendigkeit. Geplante Obsoleszenz gibt es somit kostenfrei obendrein.
Man muss ja Secure-Boot nicht einschalten.
Noch nicht. Dürfte alles nur eine Frage der Zeit sein.
*Das* ist das Problem. Es war schon einmal geplant, Secure Boot verpflichtend nutzen zu müssen – das wurde eigentlich nur durch Nutzer alternativer Betriebssysteme verhindert.
Letztlich ist es nur eine Frage der Zeit…
Code Signatur kann mit einem Zeitstempel versehen werden. Damit reicht es dass das Zertifikat zum Zeitpunkt der Signatur gültig war. Da läuft nix ab.
Keine Sorge es gibt doch bald noch den Pluton-Chip. ;)
Zitat:"Microsoft hat den Pluton-Sicherheitsprozessor in Zusammenarbeit mit AMD, Intel und Qualcomm Technologies entwickelt. Der Sicherheitschip soll irgendwann in zukünftigen Windows-PCs eingebaut werden."
Quelle: https://www.borncity.com/blog/2021/01/31/windows-10-windows-feature-experience-pack-das-steckt-dahinter/
Alles wird gut…
Zitat:"Yeah, you can think of it that way, except [Pluton] is not a discrete chip — it's on die and in the CPU complex, which means the attack surface is smaller…"
Quelle: https://redmondmag.com/articles/2020/11/17/microsoft-pluton-processors.aspx
Die erste Quelle habe ich falsch angegeben. Sollte diese Meldung sein.
Microsofts Pluton-Prozessor für künftige Windows-PCs
https://www.borncity.com/blog/2020/11/17/microsofts-pluton-prozessor-fr-knftige-windows-pcs/