#Marvin Man kann es hinbekommen, dass man gar keine Warnung erhält (so ist es bei /e/OS). Dafür müssen nur alle Systemkomponenten komplett vom CustomOS-Hersteller kommen (was da der Fall ist). /e/OS liefert nämlich einen CustomBootloader aus.
Die Kurzvariante?
Nein, es ist nicht möglich diese Warnung einfach zu deaktivieren.
Im
offiziellen AVB‑Modell ist es
nicht vorgesehen, die Warnung zu entfernen, sobald ein nicht‑OEM‑Key im Spiel ist.
Diese ist fest in der AVB Key Prüfung implementiert.
Die Warnung ist fester Bestandteil des Designs für
user‑settable root of trust /
Custom‑OS:
Wenn ein Custom‑Key verwendet wird, schreibt Google ausdrücklich vor, dass ein Warnscreen angezeigt werden
muß.
Diese Warnung
muß & soll so sein wenn ein OS mit
Nicht-OEM Keys installiert ist.
Der Bootloader von /e/ ist irrelevant, genauso wie alle anderen Bootloader eines jedes OS das installiert ist.
Zu dem Zeitpunkt wo diese Prüfung stattfindet ist dieser Bootloader noch gar nicht aktiv.
Der wird erst später aktiviert. Der OS Bootloader dient nur dazu den Kernel mit dem Userspace zu laden, sprich es steht drinnen von wo / wie etc gebootet wird.
Und ja, korrekterweise ist dieser Signiert, aber maximal mit den Public Keys des OEM, und das wiederum dient ausschließlich dazu das der Bootloader wieder gesperrt werden kann ohne das dies das Gerät brickt.
Dies wiederum dient dazu das es keine Möglichkeit gibt das Betriebssystem / Firmware des Gerätes von außen, zB via USB etc zu manipulieren.
Das ist der Hauptzwecke eines gesperrten Bootloaders.
Und jetzt die ernüchternde Wahrheit.
Wenn es nun tatsächlich so ist das mehrere Geräte durch die Bank hier bei Custom ROMs keine Warnung anzeigen, dann ist DAS der Bug und nicht das die Warnung angezeigt wird.
Hier könnte zB:
- AVB‑Kette nicht vollständig oder nicht korrekt implementiert sein
- Keys/Key‑Klassifizierung im Bootloader nicht sauber umgesetzt
- Warnscreen für den „Locked + Custom Key“-State fehlt oder ist deaktiviert
Das wären alles OEM Implementierungs-Fehler
Das gehört so nicht! Das darf so nicht sein! Es widerspricht den Technischen Spezifikationen.
Und nun die Lange Variante.
Ja. Es ginge tatsächlich.
Nur ist es mit großen Risiken verbunden und man brickt sich eventuell OTA Updates oder andere Funktionen.
Weiters gäbe es Möglichkeiten, die ich hier nicht erwähne, die SHIFT tun könnte.
Dies müßte aber von SHIFT kommen UND Nicht von /e/, Calyx, etc.
Diese Firmware Patches müßten nachträglich ausgerollt werden.
Dies kann Ausschließlich SHIFT: Es ist NICHT möglich dies von /e/ oder Calyx machen zu lassen.
Das ist aber genau der Punkt, an dem man das Standard‑Sicherheitsmodell verlässt und sich potentiell OTA‑Updates oder andere Funktionen zerschießt.
Für normale Nutzer ist der Weg klar:
– Stock‑OEM‑Key → kein Custom‑Warnscreen
– Custom‑ROM mit user‑settable / Custom‑Key (avb_custom_key) → verifizierter Boot, aber mit expliziter Custom‑OS‑Warnung.
Wenn mehrere Geräte mit Custom‑ROM und gelocktem Bootloader
keine solche Warnung zeigen, spricht das eher für eine spezielle oder fehlerhafte OEM‑Implementierung der AVB‑States als für „das ist so gedacht“.
Somit bleibt meine Aussage bestehen: Das Nicht-Anzeigen der Warnung bei /e/ ist der Bug bzw. eine sehr spezielle Konfiguration.
Sofern SHIFT sich an die Technischen Spezifikationen gehalten hat. Falls nein, ist es zwar kein Bug aber sehr Fragwürdig.
Wenn sie, SHIFT, die Trennung zwischen OEM‑Key und Custom‑Key bewusst verwischen, ist das aus meiner Sicht zumindest erklärungsbedürftig und ich würde mir nun sehr gut überlegen ob ich mein Gerät behalten würde.
Um es nocheinmal zu verdeutlichen:
Es ist NICHT vorgesehen, dass ein Custom‑ROM mit eigenen Keys einfach „unsichtbar grün“ wie OEM‑Stock bootet.
Das was mit /e/ passiert kann ich nicht beantworten warum es dort keine Warnung gibt.
Dafür bräuchte ich entweder Zugriff auf das Gerät oder Ferndiagnosse-Debugging. Es sollte / dürfte nicht sein.
Außerdem zum Abschluß:
Die Warnung ist rein kosmetisch.
Solange das Gesamte OS nicht mit OEM-Private Keys durchgehend signiert ist, ist die vollständige OEM-Root-of-Trust so oder so nicht aktiv.
Das kann man am gebooteten Gerät mit div. Apps prüfen. Es spielt dabei keine Rolle ob die Warnung da war oder nicht.
Soll heißen:
Ein jedes Custom ROM, selbst Graphene, ist nicht voll in der OEM-Root-of-Trust.
Dem Gerät wird von diversen Sicherheitsprüfungen nicht voll vertraut werden.
Da ist nur zu umgehen wenn man selber OEM ist.
Das
ist, war und wird immer das Risiko bei Custom ROMs sein, das gewisse Apps / Funktionen nicht funkt. werden, da dem OS nicht vollständig vertraut wird.Und das ist sicherheitstechnisch auch durchaus sinnvoll.
Um nun klären zu können was es mit den /e/ Geräten auf sich hat. müßte uns das ein Dev von /e/ und/oder SHIFT beantworten.
Oder jmd läßt sich auf ein Ferndiagnose-Debugging ein. Wäre aber eventuell bedeuten würde das dass Gerät gewipet wird.
