Gemeinschaft
Whitepaper zu »Secure Boot« in UEFI-Firmware
Canonical und Red Hat haben gemeinsam ein Whitepaper veröffentlicht, das die Fakten zu »Secure Boot« in UEFI-Firmware zusammenstellt und die Hersteller auffordert, eine einfache Möglichkeit zum Ein- und Ausschalten der Sicherheitsfunktion vorzusehen.
Matthew Garrett von Red Hat hatte seit Juli in einer Serie von Blog-Beiträgen geschrieben, die sich mit der UEFI-Firmware befassen. Vor einem Monat wies er auf die neue »Secure Boot«-Funktionalität hin, die durch im BIOS hinterlegte Schlüssel garantieren soll, dass nur korrekt signierte Software gebootet werden kann. Wenn dabei die Hardware-Hersteller die Kontrolle über die Schlüssel behalten, dann verlieren umgekehrt die Benutzer die vollständige Kontrolle über das Gerät, insbesondere können sie keine alternativen oder modifizierten Betriebssysteme booten. Die Hersteller, die eine Windows-8-Zertifizierung erhalten wollen, müssen »Secure Boot« implementieren, wobei es ihnen allerdings überlassen bleibt, ob sie die Funktion abschaltbar machen und wie sie die Schlüssel verwalten.
Die technischen Details werden in dem jetzt veröffentlichten Whitepaper (PDF) noch einmal erläutert. Die Autoren, neben Garrett Jeremy Karr von Canonical und Kernel-Entwickler James Bottomley, stützen sich auf Garretts ursprüngliche Analysen und gehen davon aus, dass die Funktionalität in einigen Fällen erwünscht und sinnvoll ist. zu den eher fragwürdigen Vorteilen zählt, dass der Hersteller eine genau aufeinander abgestimmte Kombination von Hardware und Software anbieten kann, einschließlich erzwungener Updates, die, wie bei der Sony Playstation 3 gesehen, nicht immer zum Vorteil des Kunden sind. Ferner kann es dem Benutzer unmöglich gemacht werden, eigene Anwendungen zu installieren. Stattdessen muss er alle Anwendungen aus einem App-Store des Herstellers beziehen, der somit ein beständiges Einkommen generiert.
Zu den Nachteilen von »Secure Boot« zählt laut den Autoren, dass die Auswahl von Hardware sich nach der Verfügbarkeit signierter Treiber richtet, und die Verwaltung der entsprechenden Schlüssel je nachdem, wie sie organisiert ist, zeit- oder arbeitsaufwendig ist. Ebenso kann die Wahl des Betriebssystems eingeschränkt sein, wie bereits mehrfach dargelegt wurde. Ein kompromittierter Schlüssel könnte ernsthafte Konsequenzen haben. Die nötige Infrastruktur für die Schlüssel ist umfangreich. Sicherheitslücken in der Schlüsselverwaltung wären aus Sicht der Anwender kein Problem, sondern eher eine willkommene Möglichkeit, die Einschränkungen des Systems zu umgehen, wie man es beim Knacken der Sony Playstation 3 oder Apples iOS-Hardware erleben konnte.
Trotzdem sehen die Autoren »Secure Boot« grundsätzlich als nützlich an. Ihre Empfehlung an die Hardware-Hersteller lautet, den Benutzern einen Mechanismus anzubieten, der es erlaubt, die Schlüssel selbst zu konfigurieren. Nur so könne der Benutzer die volle Kontrolle über seine Hardware behalten. Standardmäßig sollte kein Schlüssel vorinstalliert sein, und das zu installierende Betriebssystem sollte die erstmalige Konfiguration der Schlüssel übernehmen. Die Methode hierfür sollte standardisiert sein. Da dies die weniger technischen Benutzer aber überfordern dürfte, fordern die Autoren ferner, dass die Hersteller eine einfache Möglichkeit zum Ein- und Ausschalten der Sicherheitsfunktion vorsehen.
