Guten Tag allerseits, wenn ich mein Wissen mit Bezug zu Fritz-Boxen preisgebe, so weiß ich, dass es unterschiedliche Flash-Bereiche gibt, die vermutlich auf einem zentralen Chip sitzen oder ein zentraler Chip verschiedene Speicher-Chips benutzt diese ansteuert darauf zugreift. Dementsprechend weiß ich, dass es z.B. einen Bereich für den Kernel, einen für die Nutzerdaten und ggf. noch einen für das Image des Routers gibt; alles in einer Linux Verzeichnisstruktur gemountet. Wenn ich das auf ein Smartphone übertrage und die KNOX-Struktur, also den Sicherheitschip in modernen Samsung Galaxy Smartphones mit einbeziehe und mein Wissen über die Fritzbox auf dieses Gerät übertrage, so stelle ich mir vor, dass, nebst dem Bootloader, der auch in einem beschreibbaren Bereich des Chips sitzen muss, auch hier verschiedene Flash-Bereiche existieren müssen, auf die dann z.B. der aktive Kernel und die Basis-Programme für den Kernel des Android Systems geschrieben werden. Lediglich der Speicherplatz für Passwörter und Sicherheitsschlüssel wird sich auf dem KNOX Chip befinden, der, wenn man ihn falsch ansteuert, eine FUSE (Sicherung) zerstört, wodurch das Smartphone quasi Schrott ist. Bei einer Fritzbox konnte ich, damals zumindest, ein neues Image aufspielen, dass dann nicht von der Firma AVM war, sondern durch ein OpenSource Projekt, mit umfangreicher Konfiguration in der SHELL, zur Verfügung stand, sodass man seinen Router flashen konnte. Wenn ich das auf ein Samsung Smartphone übertrage, so ist mir bewusst, dass es ebensolche Lösungen gibt, das Verständnis der CHIP - Topologie ist mir jedoch hier noch schleierhaft, auch wie der KNOX Chip da mit rein spielt und was genau die FUSE zerstört - was kann ich machen, was nicht? Wird beim Flashen eines Samsung Galaxy Smartphones automatisch die Fuse (Sicherung) zerstört, wenn man ein anderes Image aufspielt / vgl. auch anderen Bootloader? Darum dreht sich dieser Thread - die Topologie von modernen Smartphones, am Beispiel von Samsung Galaxy Smartphones und wo man hierzu genauere Informationen für Entwickler bekommt. Ein Grundverständnis der Topologie und des Zusammenspiels fehlt mir, weshalb ich mir hier Hilfe erhoffe. Zahlreiche Mails an Samsung hierzu blieben leider unbeantwortet. Beste Grüße, Freewarehookie
Schau dir eventuell mal die Projekte an, die Alternative OS für Smartphones realisieren: - https://fsfe.org/activities/android/liberate.de.html#OS - z.B.: https://wiki.lineageos.org/devices/#samsung
Kai S. schrieb: > Speicher-Chips benutzt diese ansteuert darauf zugreift. Was soll das denn werden? Es gibt einige OS-projekte um Androiden zu bespielen. Das erwähnte Lineage, Graphene und und und.
Das Flash eines Smartphone ist ungefähr wie die Disk eines PCs und in der Hardware recht einfach strukturiert. Da wird nichts von Flash weg ausgeführt, sondern ins RAM geladen und dort ausgeführt. Aufgeteilt wird der Inhalt über Filesysteme. Abgesichert über Verschlüsselung. Der interessante Teil liegt in der Aufbewahrung von Schlüsseln.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Das Flash eines Smartphone ist ungefähr wie die Disk eines PCs und in > der Hardware recht einfach strukturiert. Da wird nichts von Flash weg > ausgeführt, sondern ins RAM geladen und dort ausgeführt. Aufgeteilt wird > der Inhalt über Filesysteme. Abgesichert über Verschlüsselung. Der > interessante Teil liegt in der Aufbewahrung von Schlüsseln. Also sind die div. "Flash-Bereiche" bei der Fritzbox, wie auch beim Smartphone, wahrscheinlich ein Speicherbereich, der, wie beim PC, in Partitionen aufgeteilt wird und eben div. Funktionen erfüllen; davon gehe ich mal aus. Wenn ich im BIOS (Bootmanager) eines Smartphones (ist der auch auf einer Partition oder gibt es da einen anderen Speicherbereich im Chip für - PC: Früher MBR, erstes Bit der Festplatte, ggf. Extra-Partition LILOboot, etc.) eine Neuinstallation starte, so muss ja auf einer extra-Partition dieser vorliegen, um ggf. neu eingespielt zu werden. (Wie funktioniert das überhaupt bei Updates zu einer neuen Software-Version? Wird dann auf dieser Partition die neue Android Version abgelegt?) Wenn diese Installationsdateien also auf einer extra Partition vorliegen, so sind sie auch manipulierbar, also ein Sicherheitsrisiko? Welcher Schutzmaßnahmen werden dort getroffen? Um aber auf das eigentliche Thema zurück zu kommen: Wie hängt jetzt der Knox Chip (ist ein externer Chip) da mit drin und dran? Wie wird dieser angesteuert und welche Funktionen schaltet er frei? Oder ist er ein reiner Passwort Speicher? Wenn ich das Bios überschreibe und mein eigenes Installiere, so habe ich einmal gelesen, dann wird die "Fuse" dieses Knox Chips geblowt und die Sicherheitsfunktionen sind nicht mehr nutzbar und die gespeicherten Passwörter werden dann zerstört, was Sinn des blowens der Fuse ist. Es muss aber ja auch für Samsung eine Möglichkeit geben ein Bios aufzuspielen OHNE die Fuse zu blowen. Hat irgendein Crack dort Kenntnis drüber, ob es da schon Infos zu gibt wie man das macht? Ich vermute es geht über irgendwelche Checksums und wenn die nicht stimmen, dann blowt der Chip die Fuse?! Darum geht es eigentlich in diesem Thread - ein Grundverständnis von Aufbau und Struktur der Topologie der Chips eines Smartphones zu bekommen; am Beispiel eines Android Geräts. Und natürlich, rein hypothetisch, ob es möglich ist ein Betriebssystem wie Linux from Scratch mit eigenem Bootmanager auf einem Smartphone Knox-Chip konform zu installieren. (fehlende Treiber einmal außen vor gelassen). 1000 Dank für die Antworten im Voraus. Liebe Grüße, Freewarehookie
Also das gesuchte Stichwort scheint "multi stage boot process" zu sein: * https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/The-Android-Booting-process/ta-p/1129182 Aber da in der Beschreibung des TO nirgends der Begriff Custom-ROM auftaucht, gehe ich mal von einem komplett Fachfremden aus ...
Bradward B. schrieb: > Also das gesuchte Stichwort scheint "multi stage boot process" zu sein: > > * > https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/The-Android-Booting-process/ta-p/1129182 > > Aber da in der Beschreibung des TO nirgends der Begriff Custom-ROM > auftaucht, gehe ich mal von einem komplett Fachfremden aus ... Ist der Bootloader denn Teil des Android OS? Multi Stage Boot Process - Also liegt der Bootloader in ausführbaren Dateien vor und dieser lädt dann den Kernel. Wie hängt der Bootloader, als Programm, denn dann mit der Fuse im Knox Chip zusammen und wie kann es sein, dass die Fuse beim Überspielen zerstört wird? Multi Stage Boot Process in Verbindung mit Neuinstallation von Android - werden dann also nur die vorhandenen Kerneldateien und Programme, in der Bootstruktur unter deinem Link zu sehen, gelöscht und neu aus einer anderen Partition oder Datei neu eingespielt?
:
Bearbeitet durch User
Kai S. schrieb: > Wie funktioniert das überhaupt bei Updates zu einer neuen > Software-Version? Je nach Hersteller. Die Pixels haben zwei Systeme drauf. Das neue System wird in den gerade inaktiven Teil geschrieben, dann wird umgeschaltet. Führt dazu, dass der Update vor dem Reboot ewig im Hintergrund ackert, aber nicht behindert. während der Reboot schnell geht. War nicht immer so, aber mittlerweile hat man den Platz dazu.
Verstehe ich, denn ein gerade aktives System kann nicht überschrieben werden. Bei Windows 11 wird daher wahrscheinlich auch div. Male neu gebootet und es startet, im vgl. zu der vorherigen Antwort, nur eine "niedere Stufe im multi boot process", vor dem eigentlichen Kernel. Wie ist das aber, wenn ich ein Handy "auf Werkseinstellungen zurück setze"? Wird dann nur eine Datei kopiert und wie ist es nach einem Telefon-Update mit einer grundlegend neuen Software-Version - wird die ursprüngliche, bei einem Zurücksetzen zu benutzende Datei, dann überschrieben - oder update ich immer auf die erste Software-Version, die das Gerät hatte? (Habe ich nie drauf geachtet)
Bei solchen Fragen kannst du dich auch an eine KI wenden. Die sind bei sachlichen Fakten, die sich nicht dauernd ändern, recht gut.
:
Bearbeitet durch User
Beitrag #8010140 wurde vom Autor gelöscht.
Einfache Windows-Updates und mittlerweile auch die Halbjahres-Updates arbeiten über eine Liste von Änderungen im System, die beim Reboot teils im Shutdown, teils im Start abgearbeitet wird. Früher gab es Halbjahres-Updates, die wie ein OS-Upgrade arbeiteten und ein neues System neben dem alten installierten, entfernt vergleichbar mit Android. Davon kam MS später aber ab. Evtl lief Win10=>Win11 so, daran erinnere ich mich aber nicht mehr. In solchem Zusammenhang gilt es aber zu beachten, dass Windows/NTFS keine aktiv genutzte Files ersetzt. Linux hingegen tut dies.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Einfache Windows-Updates und mittlerweile auch die > Halbjahres-Updates > arbeiten über eine Liste von Änderungen im System, die beim Reboot teils > im Shutdown, teils im Start abgearbeitet wird. Früher gab es > Halbjahres-Updates, die wie ein OS-Upgrade arbeiteten und ein neues > System neben dem alten installierten, entfernt vergleichbar mit Android. > Davon kam MS später aber ab. Evtl lief Win10=>Win11 so, daran erinnere > ich mich aber nicht mehr. > > In solchem Zusammenhang gilt es aber zu beachten, dass Windows/NTFS > keine aktiv genutzte Files ersetzt. Linux hingegen tut dies. Ok, verstehe ich. Also wird auch Android diese Änderungen bei Updates ähnlich durchführen. Was aber wenn ein wesentliches Update für Android bereitgestellt wird. Die Version, die ggf. auf einer extra-Partition vorhanden ist, ist sagen wir mal hypothetisch 1.2, die aktuelle Version dann aber 2.2, wobei die vorherige Version von 1 auf 2, vor dem Punkt, ein vollständiges System Update beinhaltet. Die Installations-Datei von der Installations-Partition müsste nun aber auch geupdated werden, was man durch eine sichere, verschlüsselte Verbindung in Verbindung mit einer Verifikation und Quersummen sicherstellen kann, also, dass die heruntergeladene, neue Betriebssystem-Version auch nicht manipuliert ist. Dann wird diese in die Installations-Partition geschrieben und ab sofort beim Zurücksetzen des Smartphones aus dem Boot-Menü zum Zurücksetzen benutzt. Läuft das so? Ist die Version zum Zurücksetzen des Smartphones aus dem Boot-Menü updatebar - oder aus Sicherheitsgründen nicht?
(prx) A. K. schrieb: > Bei solchen Fragen kannst du dich auch an eine KI wenden. Die sind > bei > sachlichen Fakten, die sich nicht dauernd ändern, recht gut. Ich kann es nochmal versuchen. Meine vergangenen Versuche waren jedoch nicht wirklich von Erfolg gekrönt - vor allem was die Knox - Sicherheits - Architektur von Samsung Smartphones anging und ein grundlegendes Verständnis dieser. Es ist mir nicht gelungen zu erfahren wie der Knox Chip ins Android Betriebssystem integriert ist, wann und wie er angesprochen wird ohne die Fuse zu blowen und was er genau absichert und ohne ihn nicht geht.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Bei solchen Fragen kannst du dich auch an eine KI wenden. Die sind > bei > sachlichen Fakten, die sich nicht dauernd ändern, recht gut. Ich habe bei ChatGPT "Erkläre mir, wie der Knox Chip in Samsung Smartphones ins Android Betriebssystem integriert ist" eingegeben; die Antwort war diesmal recht ordentlich. Leider darf ich es hier wohl nicht posten.
Kai S. schrieb: > Leider darf ich es hier wohl nicht posten. Einrn Link dorthin können wir wohl gerade noch verkraften.
Kai S. schrieb: > Leider darf ich es hier wohl nicht posten. Du kannst deinen Dialog mit ChatGPT als Link freigeben.
Moin, Kai S. schrieb: > Leider darf ich es hier wohl nicht posten. Ja, und selbst wenn das so waere - glaubst du, dass alle anderen, ausser dir keinesfalls in der Lage waeren, wuerde es sie interessieren, auch entsprechende Antworten einer KI ihrer Wahl entlocken koennten? gruss WK
Dergute W. schrieb: > Ja, und selbst wenn das so waere - glaubst du, dass alle anderen, ausser > dir keinesfalls in der Lage waeren, wuerde es sie interessieren, auch > entsprechende Antworten einer KI ihrer Wahl entlocken koennten? Aus dir Spricht die pure Wut "nicht in der Lage wären" - meine Antwort: Es gehört sich einen Beitrag (diesen hier) so zu gestalten, dass möglichst alle relevanten Informationen möglichst schnell und einfach zu begreifen, zugänglich und lesbar sind, um die Qualität des Beitrags für andere Lesende zu erhalten. Da ich bei ChatGPT kein Konto habe und das auch nicht ändern möchte, geht es nicht. Ich danke für alle konstruktiven Antworten und Hinweise. Ich konnte meine Wissenslücken schließen und das war Sinn und Zweck dieses Beitrags. Vielen Dank.
:
Bearbeitet durch User
Knox ist für Samsung Smartphones etwa das, was TPM, Secure Boot und die Intel ME bzw. AMD PSP für PCs ist.
Samsung Knox ist ein weiterer Sicherheitscontainer on Top auf Android. Braucht man nicht, außer Du bist Ursula von der Leyen und handelst einen milliardenschweren Impfstoff-Deal mit Pfizer per Handy aus. Die e-Fuse ist einfach ein Flag dass das Gerät kompromitiert wurde, die Knox Apps verweigern ihren Dienst. Richtig ist, dass es irreversibel ist. Falsch ist, das Gerät würde davon zerstört. Was genau hast Du für ein Modell, ist es überhaupt möglich den Bootloader zu entsperren, und was genau hast Du mit dem Gerät vor?
Alexander schrieb: > Samsung Knox ist ein weiterer Sicherheitscontainer on Top auf Android. > Braucht man nicht, außer Du bist Ursula von der Leyen und handelst einen > milliardenschweren Impfstoff-Deal mit Pfizer per Handy aus. > > Die e-Fuse ist einfach ein Flag dass das Gerät kompromitiert wurde, die > Knox Apps verweigern ihren Dienst. Richtig ist, dass es irreversibel > ist. Falsch ist, das Gerät würde davon zerstört. > > Was genau hast Du für ein Modell, ist es überhaupt möglich den > Bootloader zu entsperren, und was genau hast Du mit dem Gerät vor? Am liebsten würde ich selbst ein Linux System aufbauen, meinetwegen auch mit Komponenten von Android (ist ja Open Source) aber einem eigenen Kernel und dann Knox vollständig integrieren. Nur zum Lernen und Verstehen.
Moin, Kai S. schrieb: > Am liebsten würde ich selbst ein Linux System aufbauen, Dann mach hinne: https://www.linuxfromscratch.org/ Uebermorgen wird wahrscheinlich LFS-13.0 rauskommen, wenn nix dazwischen kommt. Gruss WK
Das kannste vergessen, Du kannst keine Linux Distro auf ein Embedded Linux Gerät installieren. Und bevor Du mit Knox ankommst beschäftige Dich erstmal mit Android. https://source.android.com/docs/security/features/keystore
Kai S. schrieb: >> Was genau hast Du für ein Modell, ist es überhaupt möglich den >> Bootloader zu entsperren, und was genau hast Du mit dem Gerät vor? Wovon das Entsperren abhängig ist, das würde ich gerne erfahren. Es geht generell um Samsung Knox Produkte. Eine Skizze, vielleicht auch aus einer vorhandenen Dokumentation der Platine in einem, sagen wir: S23, also mit der Architektur, so wie man es auch in Datasheets von Microchip Systems sieht, nur auf die gesamte Platine bezogen, wäre wünschenswert. Ich weiß, dass auf einigen Handys ein Qualcomm Atheros-Chip sitzt, aber laut meinem Verständnis hat er keine Knox Funktionen. Demnach müsste es ein eigener Chip sein, der ggf. direkt (Frage: wie?) mit dem Atheros Chip verbunden ist?
Alexander schrieb: > außer Du bist Ursula von der Leyen und handelst einen > milliardenschweren Impfstoff-Deal mit Pfizer per Handy aus. Ja, ich bin Ursula von der Leyen und möchte Pfizer anrufen gg
Kai S. schrieb: > Dergute W. schrieb: >> Dann mach hinne: > > Keine Eile. Janee, ist mir irgendwie schon klar. Dann schwaller halt weiter vor dich hin. scnr, WK
> Dann schwaller halt weiter vor dich hin. > scnr, > WK Was meinst du? Wie ich etwas angehe, dass musst du doch wohl bitteschön mir überlassen!
:
Bearbeitet durch User
Angehängte Dateien:
-
knox-vault.png
15 KB
Okay sieht wohl so aus als entwickele Samsung tatsächlich eine(n) eigene(n) (SPU) Secure Processing Unit (eigener physisch separater Hardware‑Block im SoC‑Package; nicht als Teil der Qualcomm‑SPU) zum Qualcomm-SPU Hardwaredesign hatte ich mal was verlinkt: Alexander schrieb: > https://www.bsi.bund.de/SharedDocs/Zertifikate_CC/CC/System_on_a_Chip_SOC/1045.html Laut Beschreibung ist **Knox Vault** aber ein eigenes Die innerhalb des SoC‑Packages (mit eigener CPU, eigenem RAM und eigenem Speicher). https://docs.samsungknox.com/admin/fundamentals/whitepaper/samsung-knox-mobile-security/system-security/knox-vault Physisch isoliert durch Silizium‑Layout und Metall‑Layer, ist also nicht sichtbar als separater SoC, aber auch nicht Teil des Qualcomm‑Dies (KI-Wissen). Muss aber relativ neu sein, das **Warranty Bit** (deine e-Fuse) gab es unabhängig davon schon vorher, quasi schon immer. Ob das nun eine physische Sicherung ist die tatsächlich durchbrennt, oder nur ein Flag das im Speicher gesetzt wird, daran scheiden sich die Geister. Es gibt immer mal Gerüchte jemandem sei es gelungen das zurückzusetzen. https://docs.samsungknox.com/admin/fundamentals/whitepaper/samsung-knox-mobile-security/system-security/hw-backed-security/#knox-warranty-bit Der ganze andere Kram ist aber Standard. Trusted Boot, Keystore usw. ist Teil von der Android Sicherheitsarchitektur, TrustZone läuft im TEE (meist proprietäres RTOS), Hardwarekey usw. stellt Qualcomm (oder welcher Hersteller auch immer) bereit und ist auch weiterhin nutzbar, das ist nichts KNOX spezifisches.
:
Bearbeitet durch User
Hier hat einer mal mit der MDM Sperre für den Download Mode experimentiert. Hilft vielleicht den Bootloader zu verstehen. https://ge0n0sis.github.io grundlegender Aufbau des Bootloaders https://alephsecurity.com/2018/01/22/qualcomm-edl-2 Man kann am Alter der Links erahnen dass es bei einem Samsung Galaxy S23 wohl noch komplizierter sein muss. Es wird keinen anderen Weg hinein geben als den offiziellen den Bootloader zu entsperren. Der ist grundlegend einfach. - Du brauchst ein Europa Modell (kein US/Canada) - SIM Karte mit mobilen Daten - mindestens 7 Tage in Nutzung - Developer Options aktiviert (7x auf Buildnummer tippen) - OEM unlock aktiviert - einmal neu starten - mit Internet verbinden lassen damit Vaultkeeper den OEM unlock freigibt - in Download Mode starten - flashen mit Odin3 möglich Flashen von unsignierten Kernel führt dann zum Triggern des Warranty Bits, Samsung Pass, Samsung Pay, Secure Folder usw. funktionieren dann nicht mehr. Für US/Canada Modell benötigt man die DID (wird im Download Mode angezeigt) und kann damit einen Unlock Token käuflich erwerben. P.S: Da dabei ein Werksreset erfolgt, den ursprünglich mit dem Gerät verknüpften Google Account und Samsung Account bereithalten, wird sehr wahrscheinlich benötigt um hinterher die FRP Sperre aufzuheben (zumindest bei Xiaomi ist das so)
:
Bearbeitet durch User
Moin, Alexander schrieb: > - Du brauchst ein Europa Modell (kein US/Canada) > - SIM Karte mit mobilen Daten > - mindestens 7 Tage in Nutzung > - Developer Options aktiviert (7x auf Buildnummer tippen) > - OEM unlock aktiviert > - einmal neu starten > - mit Internet verbinden lassen damit Vaultkeeper den OEM unlock > freigibt > - in Download Mode starten > - flashen mit Odin3 möglich Das erinnert mich doch stark an die Zeiten, wo's wahnsinnig hip war, auf die dbox2 andere Software zu bringen. Wen's wirklich qualifiziert interessiert, guckt doch auf die embedded World, aufn Stand 5-161. Da hockt Qualcomm... Gruss WK
Alexander schrieb: > Es gibt immer mal Gerüchte jemandem sei es gelungen das zurückzusetzen. Kannst du dich an die Quelle der Gerüchte erinnern? Denn nach dem, was ich jetzt gelesen habe, korrigiert mich wenn ich falsch bin, ist der Knox Chip eigenständig (wohl auch nicht im Atheros Prozessor enthalten, wie auch) und wenn man dort eine Fuse resetten konnte, so bedeutet das, dass man mit dem Chip kommunizieren konnte und Speicherbereiche ändern konnte. Das ist natürlich sehr interessant, denn dann kann man auch aboot, was auch aus dem Knox chip geladen werden soll, in einer eigenen Version neu aufspielen und einfach die Fuse zurücksetzen. Denn ohne den Privatekey wird man wohl kaum einen Bootloader verifizierbar machen können und die Fuse und die Funktionen des Knox Chip sind wech.
:
Bearbeitet durch User
Kai S. schrieb: > Kannst du dich an die Quelle der Gerüchte erinnern? Nein, Samsung hat mich nie so wirklich interessiert. War jedenfalls die Rede von einem Software-Flag, also altes Gerät ohne Knox Vault Chip. Aber es hält sich hartnäckig bis heute.. https://forum.xda-developers.com/t/knox-reset.4556729 Um das abzukürzen: Entscheide Dich gegen KNOX wie jeder normale Mensch, oder lass das Gerät wie es ist. Wenn Du andere ROMs testen willst, nimm ein GSI über den DSU Sideloader, das geht virtuell ohne Bootloader entsperren. Für Linux ohne Desktop kannst Du Linux Deploy oder ähnliche Apps testen. Die meisten lassen sich auch über VNC anbinden. Wenn Du bloß bissl mit den Coreutils rumspielen willst reicht auch Termux, damit laufen dann Shell und Python Scripte.
Alexander schrieb: > Nein, Samsung hat mich nie so wirklich interessiert. War jedenfalls die > Rede von einem Software-Flag, also altes Gerät ohne Knox Vault Chip. > Aber es hält sich hartnäckig bis heute.. > https://forum.xda-developers.com/t/knox-reset.4556729 > Um das abzukürzen: Entscheide Dich gegen KNOX wie jeder normale Mensch, > oder lass das Gerät wie es ist. > Wenn Du andere ROMs testen willst, nimm ein GSI über den DSU Sideloader, > das geht virtuell ohne Bootloader entsperren. > Für Linux ohne Desktop kannst Du Linux Deploy oder ähnliche Apps testen. > Die meisten lassen sich auch über VNC anbinden. > Wenn Du bloß bissl mit den Coreutils rumspielen willst reicht auch > Termux, damit laufen dann Shell und Python Scripte. Na, die Frage ist halt, wie man ein Smartphone wirklich sicher bekommt, mit "eigener" Software, ohne den dafür entwickelten Sicherheitschip zu nutzen - Stichwort: "Ursula von der Leyen ruft bei Pfizer an". Und weitere Stichworte: zero-day-exploit, vernetzte Hacker, NSO Group - Pegasus Software
:
Bearbeitet durch User
Sicher ist jedes Gerät welches Verschlüsselung nutzt. Die Daten kann niemand extrahieren der Dein Passwort nicht kennt. Die Samsung Verschlüsselung ist noch mal speziell, dafür existieren bis heute keine Custom ROMs oder Recovery die das verstehen. Einziger Angriffspunkt ist der entsperrte Bootloader, der unterbricht die Chain of Trust (Android verified boot) AVB/dm-verity. Ein Angreifer mit physischem Zugriff könnte init Skripte installieren. Trotzdem muss der Angreifer Dir das Ding zurückgeben damit Du es entsperren kannst, ohne Dein Passwort bleiben Deine Daten sicher. Benedikt L. schrieb: > Es gibt einige OS-projekte um Androiden zu bespielen. > Das erwähnte Lineage, Graphene und und und. Genannte Custom ROMs bieten die Möglichkeit den Bootloader zu sperren (user-settable root of trust) damit lässt sich AVB/dm-verity wieder nutzen und das Gerät ist genauso manipulationssicher wie mit dem Standard ROM. https://source.android.com/docs/security/features/verifiedboot/device-state#user-settable-root-of-trust
Alexander schrieb: > Sicher ist jedes Gerät welches Verschlüsselung nutzt. Die Daten kann > niemand extrahieren der Dein Passwort nicht kennt. Sobald das Gerät eingeschaltet ist und ich auf die Daten Zugriff habe, kann ein Angreifer, der das Gerät kompromittiert hat, doch auf alles zugreifen - so funktioniert das doch auch mit Pegasus oder nicht? Die sind doch im laufenden, von mir durch Eingabe meines Passworts, Musters oder Ähnlichem entsperrten Gerät aktiv drin und dabei. Sie müssen garnichts entschlüsseln, weil es ja bereits für mich entschlüsselt ist. Alexander schrieb: > Genannte Custom ROMs bieten die Möglichkeit den Bootloader zu sperren > (user-settable root of trust) damit lässt sich AVB/dm-verity wieder > nutzen und das Gerät ist genauso manipulationssicher wie mit dem > Standard ROM. Und die Programme, die vorher ihre Daten im Knox-Chip abgelegt haben, funktionieren mit dieser Lösung auch wieder?
>Der vom Nutzer festlegbare Root >of Trust wird in einem >manipulationssicheren Speicher >abgelegt. Manipulationssicher >bedeutet, dass es möglich ist, >festzustellen, ob Android die >Daten manipuliert hat, z. B. ob >sie überschrieben oder geändert >wurden. steht da. Also ist das ein spezieller Speicherbereich im Qualcomm Atheros Chip, wo ein derartiger Root of trust Nutzer Schlüssel abgelegt wird, um dann die Partition mit diesem zu verschlüsseln? Die Daten sind jetzt insofern sicher, als dass das Smartphone aus ist und ein Angreifer kann keine Init Scripte zum Aufrufen der eigenen Spy Software mehr installieren; das habe ich verstanden.
Kai S. schrieb: > ein Angreifer, der das Gerät kompromittiert hat Das ist der Zweck vom gesperrten Bootloader - es gibt keine Möglichkeit das Gerät zu kompromittieren / tamper-resistant. (Israel ausgenommen, die arbeiten mutmaßlich mit dem Hersteller zusammen) Kai S. schrieb: > Und die Programme, die vorher ihre Daten im Knox-Chip abgelegt haben, > funktionieren mit dieser Lösung auch wieder? "Die Programme" welches Programm konkret möchtest Du nutzen? Pauschale Antwort Nein. Knox ist tot. Zur Erinnerung, das ist was samsungspezifisches - kein anderes Android Smartphone mit Qualcomm-SPU braucht das. Kai S. schrieb: > wo ein derartiger Root of trust Nutzer Schlüssel abgelegt wird, um dann > die Partition mit diesem zu verschlüsseln? Hat mit der Verschlüsselung nichts zu tun, die funktioniert auch bei entsperrtem Bootloader. Es geht nur um das "erste" Glied in der Kette von AVB/dm-verity - ob ein Gerät einen Kernel überhaupt bootet. Die OEM Schlüssel womit die Hersteller den Kernel signieren sind geheim. Bei gesperrtem Bootloader werden keine unsignierten Kernel ausgeführt. (Anm.: Mit "Kernel" meine ich das Binary auf der boot Partition das den Kernel enthält, also lange nach dem Bootloader. Früher war da alles in einem, also Kernel und Ramdisk, heute ist das komplizierter gesplittet und auf Partitionen verteilt, da sieht kein Schwein mehr durch. https://source.android.com/docs/core/architecture/partitions/generic-boot )
:
Bearbeitet durch User
Alexander schrieb: > "Die Programme" welches Programm konkret möchtest Du nutzen? Pauschale > Antwort Nein. Knox ist tot. Zur Erinnerung, das ist was > samsungspezifisches - kein anderes Android Smartphone mit Qualcomm-SPU > braucht das. Z.B. meine Banking App, die ja mit totem Knox wohl kaum noch funktionieren wird. Alexander schrieb: > Die OEM Schlüssel womit die Hersteller den Kernel signieren sind geheim. > Bei gesperrtem Bootloader werden keine unsignierten Kernel ausgeführt. Mit einem user settable root of trust kann ich also meinen Kernel selbst signieren und so tun als wäre ich der Hersteller und es gibt keine Sicherheitsbedenken? Nehmen wir an ich wähle einen anderen Hersteller als Samsung, wo es keinen knox chip gibt und der Hersteller das von Haus aus schon ebenso macht, steht der user settable root of trust dem Ganzen also sicherheitstechnisch in nichts nach?
Also ich habe ein Xiaomi mit Qualcomm SM7350-AB (ohne Knox) es ist bootloader entsperrt, gerootet, unverschlüsselt, das (Samsung) F2FS-Dateisystem durch EXT4-Dateisystem ersetzt, mit TWRP recovery. Meine Banking Apps (Sparkasse, Norisbank, N26, PayPal) funktionieren einwandfrei.
Alexander schrieb: > Also ich habe ein Xiaomi mit Qualcomm SM7350-AB (ohne Knox) es ist > bootloader entsperrt, gerootet, unverschlüsselt, das (Samsung) > F2FS-Dateisystem durch EXT4-Dateisystem ersetzt, mit TWRP recovery. > Meine Banking Apps (Sparkasse, Norisbank, N26, PayPal) funktionieren > einwandfrei. Na dann. Und sicherheitstechnisch bist du auch auf dem Standpunkt, dass es sicher ist?
Die Sicherheit besteht bei mir darin dass jeder der das Gerät in die Finger bekommt vollen Zugriff auf alle auf dem Gerät gespeicherten Daten hat.
Alexander schrieb: > Die Sicherheit besteht bei mir darin dass jeder der das Gerät in > die > Finger bekommt vollen Zugriff auf alle auf dem Gerät gespeicherten Daten > hat. Also sorgst du dafür, dass es nicht in falsche Hände gerät? Naja, dein Bank Passwort wird ja außer dir auch sonst niemand kennen. Deine Antwort kann natürlich auch gewollt sein; beschränken wir uns also auf die Technik - Verschwörungstheorien á la Querdenker & Co., sowie Youtube Müll möchte ich hier auch nicht unterstützen - meine Intentionen, die Sicherheit betreffend, werde ich aber auch nicht preisgeben. Wie ich bereits erwähnte und es der Thread ja auch besagt, geht es um die Architektur moderner Smartphones und was das angeht habe ich eine Menge erfahren und sinnzusammenhängend einordnen können und dafür möchte ich mich noch einmal außerordentlich bedanken! Wenn man den Thread schließen kann, dann würde ich das an dieser Stelle tun. MfG Freewarehookie
:
Bearbeitet durch User
Kai schrieb: > Also sorgst du dafür, dass es nicht in falsche Hände gerät? Ich sorge dafür dass erst gar keine sensiblen privaten Daten auf dem Gerät (oder einer Cloud) gespeichert werden. Außerdem braucht man ja heut sowieso für jeden Scheiß 2FA, selbst bei GitHub kann man sich ohne Authentifikator nicht mehr einloggen. Kai schrieb: > was das angeht habe ich eine Menge erfahren und sinnzusammenhängend > einordnen können Und ich habe von **Knox Vault** als Ersatz für TEE erfahren. War komplett an mir vorbeigegangen. https://www.xda-developers.com/samsung-knox-vault Ich kannte bisher nur **Samsung Knox** 1.0 als Virtualisierung/Container. https://www.samsung.com/de/mobile-phone-buying-guide/what-is-samsung-knox
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.