Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › UEFI Secure Boot: Eigene Schlüssel…

Secure Boot = null Sicherheitsgewinn?

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Secure Boot = null Sicherheitsgewinn?

    Autor: Schnarchnase 08.10.12 - 17:55

    Wo ist der Sicherheitsgewinn, wenn auch Loader signiert werden, die beliebige andere Loader starten können? Warum können nicht gleich alle ihre Signaturen einreichen?

    Ich sehe hier nur erhöhte Komplexität, keine erhöhte Sicherheit.

  2. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: kazhar 08.10.12 - 18:22

    Was mir bei der ganzen Geschichte nicht klar ist...

    MUSS der Bootloader einen signierten Kernel nachladen? Gibt es eine Hardware/Firmware Funktion, die das das verhindert?

    Ansonsten könnte z.b. ein bösartiges Rootkit einen signierten Bootloader verwenden, um einen unsignierten - weil gepatchten - Kernel nachzuladen.
    Wie "schwer" es ist, an eine Signatur zu kommen liest man ja ab und zu...

  3. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: nautsch 08.10.12 - 18:52

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > Wo ist der Sicherheitsgewinn, wenn auch Loader signiert werden, die
    > beliebige andere Loader starten können? Warum können nicht gleich alle ihre
    > Signaturen einreichen?
    >
    > Ich sehe hier nur erhöhte Komplexität, keine erhöhte Sicherheit.

    Das ganze basiert auf Vertrauen. Du musst demjenigen, der den Bootloader signiert vertrauen, dass er nur bootloader signiert, die nur signierte Kernel laden. Das heißt, wenn du dein BIOS/UEFI so konfigurierst, dass es nur von MS/Fedora signierte Bootloader lädt (indem du den MS/Fedora Key in deinem BIOS hinterlegst/nicht löschst), vertraust du MS/Fedora, dass sie sicherstellen, dass der Bootloader in Ordnung ist. Das gleiche gilt für Bootloader, die von irgendwem anders signiert sind.

    MS/Fedora darf eigentlich keinen Bootloader signieren, der die die Kette nicht aufrechterhält. Der Bootloader prüft also deinen Kernel und der Kernel jeden Treiber, den du lädst. Wenn ein Teil in der Kette einen Fehler hat, ist die Sicherheit futsch. Wenn jemand zu freigiebig mit Signaturen ist, ist die Sicherheit futsch. Wenn du dem Signierer nicht vertraust, war nie Sicherheit gegeben.



    2 mal bearbeitet, zuletzt am 08.10.12 18:55 durch nautsch.

  4. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: Casandro 08.10.12 - 19:16

    Selbst wenn Du die Kette aufrecht erhalten würdest, was verfassungswidrig ist und gegen das Grundrecht auf Integrität datenverarbeitender Systeme verstößt, so würde das keinen Sicherheitsgewinn bringen, da alle Angriffe die Du sonst machen könntest, physikalischen Zugriff erfordern. So bald zu physikalischen Zugriff hast, kannst Du alles machen.

    Secure Boot dient ausschließlich dazu das Starten von nicht Windows auf Windows ARM-Geräten zu verhindern. Es hat keinerlei Sicherheitsgewinn.

  5. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: chrulri 08.10.12 - 19:32

    Verfassungswidrig?! Ihr habt ja nicht einmal eine Verfassung... Grundrecht auf Integrität datenverarbeitender Systeme.. Grundrecht ?! ... Ich glaub ein Schwein pfeift die 32. Beethoven Sonate.

  6. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: Schnarchnase 08.10.12 - 20:24

    chrulri schrieb:
    --------------------------------------------------------------------------------
    > Verfassungswidrig?! Ihr habt ja nicht einmal eine Verfassung...

    Das Grundgesetz ist eine Verfassung.

    > Grundrecht auf Integrität datenverarbeitender Systeme.. Grundrecht ?!

    Ein solches Grundrecht gibt es in der Tat:
    [de.wikipedia.org]

    Ich bin mir allerdings nicht sicher inwiefern das hier anwendbar ist.

  7. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: Casandro 08.10.12 - 21:03

    Naja, durch die Codesignierung kann ich nicht mehr darüber bestimmen, welche Programme auf meinem Rechner laufen. Ich kann somit nicht davon ausgehen, dass mein Rechner das macht was ich will.

    Zwangsweise Codesignierung nimmt einem nunmal die Kontrolle über seien eigenen Rechner.

  8. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: F4yt 08.10.12 - 23:00

    Das ganze erinnert mich halt an den "Wirbel" um DNT. Ist beides mehr Placebo, als dass es wirklich was bringt.

    Zumindest war es in den vergangenen Jahren verdächtig ruhig um das Thema "Kernel spioniert Benutzer aus".

    Oder gibt's einen anderen Grund für SecureBoot abgesehen von "Ich starte nurnoch Windows"?

  9. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: robinx999 09.10.12 - 07:22

    Schnarchnase schrieb:
    --------------------------------------------------------------------------------
    > Wo ist der Sicherheitsgewinn, wenn auch Loader signiert werden, die
    > beliebige andere Loader starten können? Warum können nicht gleich alle ihre
    > Signaturen einreichen?
    >
    > Ich sehe hier nur erhöhte Komplexität, keine erhöhte Sicherheit.

    Ich glaube der Sicherheitsgewinn ist, dass ein rootkit sich nicht unbemerkt vorbei schleichen kann. Denn wenn eines installiert wird, dann fragt shim nach ob der neue Key hinzugefügt werden soll. Aber da sehr viele Menschen bei alles ja sagen wird es nur Menschen schützen, die etwas nachdenken. Und die sind im Computer bereich immer seltener (sieht man ja an den leuten die alle möglichen Android Maleware installieren und das obwohl genau die rechte angezeigt werden und man software installationen außerhalb des Markets erlauben muss)
    Für den Privat Nutzer bedeutet es halt einen weiteren Schritt bei der Installation und für "Advance" Nutzer, die auch Bootloader / kernel selber compilieren kommt halt noch hinzu, dass sie Schlüssel erzeugen müssen und damit alles signieren.
    Interessant sieht es natürlich bei Firmen aus, die alles mittels Netzwerk boot installieren, wie bekommen die den Key rein, muss da zu jedem Computer einer hinlaufen und den Key bestätigen?

  10. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: Casandro 09.10.12 - 07:34

    Wozu dann ein Rootkit benutzen? Wenn Du ein Rootkit drin hast, so kommt das erst nach Secure Boot, sprich Du was etwas das danach kommt, schon ausgehebelt.

    Secure Boot schützt nur den Bootprozess, und wenn Du in den eingreifen kannst, kannst Du auch zusätzliche Hardwareeinbauen, oder andere Software auf dem Service Controller starten. Du könntest sogar das komplett Mainboard austauschen, oder unauffällig einen kleinen HDMI-Sender installieren und den Bildschirminhalt abgreifen... etc.

    Secure Boot wurde nur dazu geschaffen, um das Starten von nicht-Windows Betriebssystemen zu erschweren, bzw. zu verhindern.

  11. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: robinx999 09.10.12 - 07:41

    Casandro schrieb:
    --------------------------------------------------------------------------------
    > Wozu dann ein Rootkit benutzen? Wenn Du ein Rootkit drin hast, so kommt das
    > erst nach Secure Boot, sprich Du was etwas das danach kommt, schon
    > ausgehebelt.
    >
    ja sobald es installiert ist, kann es alles machen, es ist halt eine zusätzliche ebene die verhindert, dass es installiert wird. Da die Kette ja ist bei Linux UEFI -> SHIM -> Grub -> Kernel bzw. UEFI -> Windows Bootloader -> Windows Kernel und wenn alles signiert ist, kann sich das Rootkit da schwer einschleichen. Denn im Idealfall kommt das Rootkit sehr früh, so dass es sich auch gut verstecken kann (wenn das Rootkit vor Grub bzw. dem Windows Blootloader kommt währe es sehr schwer zu verstecken)

    > Secure Boot schützt nur den Bootprozess, und wenn Du in den eingreifen
    > kannst, kannst Du auch zusätzliche Hardwareeinbauen, oder andere Software
    > auf dem Service Controller starten. Du könntest sogar das komplett
    > Mainboard austauschen, oder unauffällig einen kleinen HDMI-Sender
    > installieren und den Bildschirminhalt abgreifen... etc.
    >
    > Secure Boot wurde nur dazu geschaffen, um das Starten von nicht-Windows
    > Betriebssystemen zu erschweren, bzw. zu verhindern.

    Tut es in der jetzigen ausführung nicht. Es ist abschaltbar (bei x86er Systemen sogar Pflicht) und offensichtlich wird es mit Shim relativ leicht auch Linux systeme zu starten. Wobei ich ehrlich dachte der Hauptgrund war zu verhindern, dass sich systeme über ein Modifizierten Grub als OEM Systeme ausgeben, die keine Aktivierung brauchen und so eine kopierte Windows Installation erlauben

  12. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: Casandro 09.10.12 - 08:01

    OK, nehmen wir mal einen üblichen Angriff:
    Der Virenscanner hat eine Sicherheitslücke, und führt mit Systemrechten Code aus, der sich im Autostart installiert. Was genau bringt es da, wenn der Kernel signiert ist?
    Und selbst wenn Du irgendwie magisch das Ausführen von unsignierten Code verhindern könntest, worauf basiert Deine Annahme, dass die Malwarefirmen ihren Code nicht auch signiert kriegen? (Ist in der Vergangenheit schon passiert!)

    Mit dem ganzen Geld das man da jetzt in Secure Boot reinsteckt, könnte man die echte Sicherheit wirklich weiter bringen. Man könnte beispielsweise typsichere Sprachen und Hardware bauen, auf der zum Beispiel einfach ausgeschlossen ist, dass eine Ganzzahl die mit "Privat darf nicht durch die Netzwerkkarte gehen" gekennzeichnet ist, durch die Netzwerkkarte geht. Das geht halt nicht mit x86 und C.

  13. Re: Secure Boot = null Sicherheitsgewinn?

    Autor: robinx999 09.10.12 - 08:07

    Wirklich effektiv verstecken kann sich ein echtes Rootkit nur wenn es vor dem Kernel gestartet wird (und im schlimmsten fall sogar das Windows Virtualisiert). Ja es gibt sicherlich auch malware die vieles mit Systemrechten anrichten könnte (man sieht es sogar bei android dort reichen ja schon nutzer rechte, das dort malware teure sms verschickt)
    Aber die Signierung läuft doch so. UEFI erkennt nur das Microsoft zertifikat, Shim erkennt nur das Fedora zertifikat. Also besteht nur gefahr wenn eines der 2 Zertifikate abhanden kommt. In jedem anderen fall forder Shim den Benutzer auf das Zertifikat hinzuzufügen und das wird ein Rootkit nicht verhindern können.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. Deutsche Bundesbank, Düsseldorf
  2. DEKRA SE, Stuttgart
  3. heroal - Johann Henkenjohann GmbH & Co. KG, Verl
  4. Robert Bosch GmbH, Stuttgart-Feuerbach

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 47,99€
  2. ab 59,99€ (Vorbesteller-Preisgarantie)
  3. (-50%) 19,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Calliope Mini im Test: Neuland lernt programmieren
Calliope Mini im Test
Neuland lernt programmieren
  1. Arduino Cinque RISC-V-Prozessor und ESP32 auf einem Board vereint
  2. MKRFOX1200 Neues Arduino-Board erscheint mit kostenlosem Datentarif
  3. Creoqode 2048 Tragbare Spielekonsole zum Basteln erhältlich

Tado im Langzeittest: Am Ende der Heizperiode
Tado im Langzeittest
Am Ende der Heizperiode
  1. Wemo Belkin erweitert Smart-Home-System um Homekit-Bridge
  2. Speedport Smart Telekom bringt Smart-Home-Funktionen auf den Speedport
  3. Tapdo Das Smart Home mit Fingerabdrücken steuern

Blackberry Keyone im Test: Tolles Tastatur-Smartphone hat zu kurze Akkulaufzeit
Blackberry Keyone im Test
Tolles Tastatur-Smartphone hat zu kurze Akkulaufzeit
  1. Blackberry Keyone kommt Mitte Mai
  2. Keyone Blackberrys neues Tastatur-Smartphone kommt später

  1. Experten fordern Grenzen: Smartphones können Kinder krank machen
    Experten fordern Grenzen
    Smartphones können Kinder krank machen

    Kicken statt Klicken, Paddeln statt Daddeln: Geht es nach Experten, sollten Smartphones für Kinder weniger wichtig sein als Sport und Spiel im Freien. Die Realität sieht oft anders aus - mit gravierenden Folgen.

  2. Wifi4EU: EU will kostenlose WLAN-Hotspots fördern
    Wifi4EU
    EU will kostenlose WLAN-Hotspots fördern

    Die EU schreitet bei der Förderung kostenloser WLAN-Hotspots weiter voran. Die zuständigen Gremien haben sich auf weitere Details dazu verständigt. Bis zu 8.000 Gemeinden sollen beim Aufbau kostenloser WLAN-Hotspots unterstützt werden.

  3. In eigener Sache: Studentenrabatt für die große Quantenkonferenz von Golem.de
    In eigener Sache
    Studentenrabatt für die große Quantenkonferenz von Golem.de

    Quantenkonferenz Zugang zu Topexperten und allen wichtigen Informationen zum aktuellen Stand der Quantenforschung: Das ermöglicht Golem.de jetzt auch dem wissenschaftlichen Nachwuchs mit einem Sonderrabatt für die große Konferenz am 23. Juni in Berlin.


  1. 09:08

  2. 08:30

  3. 08:21

  4. 07:17

  5. 18:08

  6. 17:37

  7. 16:55

  8. 16:46