Android: dm-verity: Locked system

[schorsch_76]

Hallo,
ich schreibe das in Smalltalk, da es ja nicht Debian an sich betrifft, wohl aber auch möglich ist.

Vor vielen Jahren war ja die Befürchtung bei TPM [1] das das System total geschlossen werden kann und nur noch vom Hersteller zugelassener Code zur Ausführung kommen kann. Unter Linux war ja dann die Befürchtung, das nur noch MS Windows gebootet werden kann. Sprich Secure Boot immer aktiv. Bei den x86 Devices gibt es ja die Forderung das es immer abschaltbar sein muss.

Die Arm Geräte die viele von uns rumtragen nutzen ja unser Linux. Nur: Es gibt auch hier SecureBoot. Qualcom SecureBoot was den Platformschlüssel in der Hardware hat und wohl nicht austauschbar ist. Es kann dann nicht mehr ein anderer Bootloader genutzt werden. Kein anderer Kernel obwohl der Code veröffentlicht worden ist.
Bei SecureBoot ist es ja so, wer den Platform Schlüssel besitzt, kontrolliert das Gerät.

Mit dm-verity [2] wird dann auf Linux Ebene die ganze /system Partition des Gerätes gegen Hashes gecheckt.

Als Beispiel sei hier mal die BEschreibung bei den xda-developers und dem S7 verlinkt [4].

Was mich hier irgendwie so stört, ist das exakt das, was bei TPM befürchtet wurde, exakt mit Open Source auf Arm umgesetzt ist.

Wie sind eure Gedanken dazu?
Ist es nicht so, das ich das boot Image des Kernels nachbauen können muss. Dazu gehört doch auch die Signatur. Hier ist aber der Private Key nicht verfügbar. Oder ist das nicht mehr Teil der GPL?

[1] https://de.wikipedia.org/wiki/Trusted_Platform_Module
[2] http://lxr.free-electrons.com/source/Do ... verity.txt
[3] https://nelenkov.blogspot.de/2014/05/us ... -boot.html
[4] https://www.xda-developers.com/galaxy-s ... after-all/

[hikaru]

Der Kernel steht unter GPLv2. Diese Lizenz ist machtlos gegen Tivoisierung.

Um abzuschätzen ob das Zurückhalten eines Secure-Boot-Schlüssels die GPL verletzt fehlt mir das technische Wissen bezüglich der Einbindung des Schlüssels (von der juristischen Kompetenz ganz zu schweigen). Fragen die mir dazu spontan einfallen:
1. Wird überhaupt gegen den Schlüssel gelinkt?
2. Falls ja bei 1., was wird gegen den Schlüsel gelinkt (z.B. Kernel oder Bootloader)?
3. Falls nicht Kernel bei 2., steht dieses andere Etwas unter einer GPLv2-vergleichbaren Lizenz oder wird es durch Linken gegen den Kernel infiziert?

btw:
Dass Secure Boot für MS-Kompatibilität auf x86 optional sein muss, auf arm aber genauso zwingend sein muss, fand ich schon immer reichlich fischig.

[breakthewall]

Vor vielen Jahren war ja die Befürchtung bei TPM [1] das das System total geschlossen werden kann und nur noch vom Hersteller zugelassener Code zur Ausführung kommen kann. Unter Linux war ja dann die Befürchtung, das nur noch MS Windows gebootet werden kann. Sprich Secure Boot immer aktiv. Bei den x86 Devices gibt es ja die Forderung das es immer abschaltbar sein muss.

Generell ist ein TPM-Modul nichts Schlechtes. Und ja es kann hinsichtlich Komplettsystemen, zum Nachteil des Nutzers eingerichtet werden. Betrifft also nur potenziell Laptops, Fertig-PCs und ohnehin unsichere Smartphones. Baust dir dein System dagegen selbst, kann schon aus Prinzip nichts ab Werk verdongelt sein, womit es in deiner Hand liegt wie das TPM-Modul genutzt wird. Nur bezüglich Smartphones, wo schon die Hardware die reinste proprietäre Blackbox, mit inhärent widerlichen Lücken ist, ist erst gar nicht an Sicherheiten zu denken. Beim besten Willen nicht.

Bei SecureBoot ist es ja so, wer den Platform Schlüssel besitzt, kontrolliert das Gerät.

Was dann wohl Microsoft wäre. Denen man sich ebenso unterordnen muss um eine valide Signatur für Secure-Boot zu bekommen, was kurz gesagt eine Todgeburt ist. Und da Microsoft den Golden-Masterkey davon schon 2016 versehentlich entblößte, und ebenso auch schon etliche Linux -oder gar Windows-Installationen aussperrte, hat das jeden realen Wert verloren. Nimmt man dann noch die ganzen Implementierungslücken, wodurch Secure-Boot schon mehrfach ausgehebelt werden konnte, dann hinterlässt das ein ziemlich schlechtes Bild. Ich würde die ARM-Plattform ja komplett abschreiben, da die Entwicklungen hier kaum Open-Source feindlicher sein könnten. Und was einem ein verifizierter Bootprozess nutzt, auf inhärent unsicherer Soft -und Hardware, ist auch so eine Sache.

[hikaru]

Generell ist ein TPM-Modul nichts Schlechtes.

In Anbetracht dessen, dass es immer eine Black Box ist sehe ich das anders.
Du kannst als Nutzer nur hoffen, dass es nur das tut, was der Hersteller als Funktionalität bewirbt.

Baust dir dein System dagegen selbst, kann schon aus Prinzip nichts ab Werk verdongelt sein, womit es in deiner Hand liegt wie das TPM-Modul genutzt wird.

Wenn man sich ein System "von Grund auf" selbst baut, dann hat man für gewöhnlich ein Mainboard mit proprietärem BIOS/UEFI, steckt darauf eine CPU mit Intel ME oder AMD TrustZone und holt seine Daten von einem Massenspeicher auf dem eine Firmware mit unbekannter Funktionalität läuft. Und ich habe bestimmt ein halbes Dutzend weiterer Black Boxes übersehen die in einem rudimentären "selbstgebauten" PC stecken.
Das ist sicher immer noch besser als wenn zusätzlich ein TPM-Modul sein Unwesen treibt, aber die Situation ist trotzdem alles andere als befriedigend.

[schorsch_76]

Ich hab letztens gelesen das es bsp. für das S7 (weil ich das verlinkt habe) wohl doch ROMs gibt.

Da mich das ganze so stört, hab ich mir jetzt am langen WE den Android Source geholt und mal für den Emulator gebaut. Ich will hier verstehen was wie verdongelt wird indem ich mal so einen Emulator "absichere".

Es scheint so zu sein das im fertigen Linux Kernel Image, ein Text ersetzt wird mit der Checksumme des dm-verity trees.

[Teddybear]

Das Problem ist doch:
Der Hersteller der Geräte möchte verhindern, das die Geräte außerhalb der Spezifikation genutzt werden.
In wie weit man in der Open Source Gemeinde dafür Verständnis haben soll, steht doch auf einem anderen Blatt.