Wenn dein Thread-Modell staatliche Zugriffe mit einschließen soll, unbedingt. Wobei es da schnell schwierig wird sich zu entziehen fürchte ich. Ist auch die Frage für den einzelnen, wie realistisch das Risiko von staatlichem Handeln gegen einen selbst ist. Für die meisten eher zu vernachlässigen denke ich. Aber auch sonst evtl. keine ganz schlechte Idee, im Hinblick auf Einbruch zb, wenn es um mögliche Geschäftsgeheimnisse gehen könnte. Oder auch die eifersüchtige Ex, oft und vermutlich viel wahrscheinlicher kommen ja Angriffe aus Ecken, die man zunächst nicht vermutet
Ich führe ein ehrliches Leben, das mal vorweg. Aber ich habe in der Verwandschaft schon erlebt, dass frühmorgens mit schlafenden kleinen Kindern im Haus ein „Zugriff“ erfolgte, nur weil die Familie Patienten einer Ärztin waren, gegen die ermittelt wurde. Ich las den Rat „don’t talk to the police“ vor vielen Jahren auf amerikanischen Seiten und glaubte nicht, dass es in Deutschland auch mal so weit käme, wird aber auch von deutschen Anwälten so empfohlen.
PS: Jetzt kommen wir leider vom Thema ab, sorry.
Es war ein Kopfschuss, aber das Gesicht war heil
Bezgl. des leaks das Cellebrite nun scheinbar doch auf das iphone 15 und bis auf die aktuellen pixel geräte alle android smartphones entsperren kann stellt sich mir die frage ob dies auch für den sicheren bereich wie bspw. Samsung knox gilt. Also Ich vermute mal wenn knox ausreichend gesichert ist (8stellige pin oder höher) es nicht möglich ist. Ergo wenn man alle Sicherheitsrelevanten dienste innerhalb des geschützten bereichs ausführt sollte die Daten doch sicher sein?
Ich springe mal auf die ursprüngliche Frage zurück „Wie sicher sind die auf einem iPhone gespeicherten vor missbräuchlichen Zugriff bei einem Diebstahl des Gerätes“.
Die folgenden Parameter solltest Du aus meiner Sicht gesetzt haben:
„Einstellungen“ > „FaceID & Code“ > „Sperrcode“ idalerweise alphanummerisch
„Einstellungen“ > „FaceID & Code“ > „Code anfordern“ = sofort
„Einstellungen“ > „FaceID & Code“ > „Daten löschen“ = aktiviert
Die biometrische Authentisierung solltest Du aus meiner Sicht aktivieren, da Sie das Mitfilmen der Zugangscode-Eingabe in der Öffentlichkeit verhindert.
„Einstellungen“ > „FaceID & Code“ > „FaceID“ = aktiviert
Dieses ist die Basis dafür, dass Apples Sicherheitsmaßnahmen vor unberechtigten Zugriff scharf sind. Der Dieb hat bei diesen Einstellungen nun 10 Versuche den Sperrcode zu Deinem Telefon zu erraten. Danach wird der „Device Key“ (ich meine 128 bit AES) der Systeminstallation gelöscht und Deine Daten nicht mehr entschlüsselt werden können.
Als Schutz vor einem destruktiven Löschens des iPhones sind ab der 6 Passcode-Eingabe Verzögerungen eingebaut die mit jedem Versuch länger werden. Insgesamt dauert es bei 10 Fehlversuchen mindestens 90 Minuten bis das Geräte sich löscht.
Gegen Angriffe auf das Betriebssystem (Jailbreaks usw.) schützt das iOS keine USB-Verbindungen mehr aufbaut, ohne dass dieses vom Benutzer des entsperrten Geräts bestätigt wird. Jailbreaks wurden meines Wissens nach bisher immer über USB oder in einem Fall über einen Drive-by-Download durchgeführt. Für beides muss das iPhone entsperrt werden.
Über den DFU-Modus zur Wiederherstellung des Betriebssystems können zwar noch Betriebssysteme neu über USB eingespielt werden. Hierbei wird aber auch der Datenbereich der Nutzerdaten gelöscht.
Insofern ist ein Zugriff auf Deine Daten ohne Kenntnis des Sperrcodes / einem nachgemachten biometrischen Merkmal eigentlich nur noch bei passenden Schwachstellen möglich, die die oben beschriebenen Schutzmaßnahmen außer Kraft setzen. Als Anwender spielst Du als Gegenmaßnahme die iOS Updates ein.
Als letztes würde ich Dir noch empfehlen Siri im Sperrzustand zu deaktivieren.
„Einstellungen“ > „Siri & Suchen“ > „Siri im Sperrzustand erlauben“ = deaktiviert
Über Siri kannst Du ansonsten einige Deiner privaten Daten nutzen oder abfragen wie Kalendertermine einsehen oder Telefonanrufe durchführen.
Ich würde sagen, dass ein iPhone mit den oben genannten Maßnahmen seine Daten sehr gut gegen missbräuchliche Zugriffe durch Dieben schützt.
Wenn Du mehr zu den Sicherheitsmaßnahmen des iPhones oder anderen Apple Plattformen und Diensten wissen möchtest, empfehle ich Apples Plattform Security Webseite
https://support.apple.com/de-de/guide/security/welcome/web
Einiges wie z. B. das recht komplexe Konzept der Dateiverschlüsselung ist sehr interessant zu lesen. Leider mischt die Webseite verschieden Apple Betriebssysteme, sodass man immer ein wenig schauen muss, welche Aussage für welches Gerät gilt. Früher gab es das Dokument iOS Security was in diesem Punkt übersichtlicher war.
Auch noch nützlich (und erst vor einiger Zeit eingeführt – Heise berichtete breit über die mögliche Schwachstelle):
„Einstellungen“ > „FaceID & Code“ > „Schutz für gestohlene Geräte“ = ein und im Untermenü „Sicherheitsverzögerung erforderlich“ = immer
Die Option
Einstellungen“ > „FaceID & Code“ > „Schutz für gestohlene Geräte“ = ein und im Untermenü „Sicherheitsverzögerung erforderlich“ = immer
ist wichtig und empfehlenswert zum Schutz Deiner Apple ID damit Du nicht vom Dieb aus dieser ausgesperrt wirst und Zugriff auf Deine iCloud-Daten / App-Käufe verlierst.
Allerdings läuft der Angriff gegen die mit dieser Option begegnet wird meine ich erst, wenn ein Angreifer ein mit der Apple ID verbundenes Gerät plus den Sperrcode des Gerätes hat. Hierüber konnte man wohl vor dieser Option das Passwort der Apple ID zurücksetzen. Dieses wird durch die Option über die zusätzliche Biometrisches Authentiserung des Benutzers verhindert.
Aber in jedem Fall empfehlenswert.
Danke nochmal für die zahlreichen Beiträge.
Zusammenfassend besteht also weitgehend Einigkeit darüber, dass bei korrekter Anwendung der von Apple angebotenen Schutzmechanismen zumindest bei aktuellen iPhones mit aktueller Software hinreichender Schutz vor Entschlüsselung gestohlener oder verlorener Geräte besteht. Selbes gilt für aktuelle Pixel mit Graphene.
Falls das jemand noch anders sieht oder sich über die Zeit daran etwas ändert, gerne hier posten!
FaceID u d Touch zur Entsperrung habe ich ebenfalls immer deaktiviert. Falls das Phone beschlagnahmt wird, dann kann damit keine rechtswidrige erzwungene Entsperrung durchgeführt werden. Ist nicht die Regel, aber leider schon vorgekommen…
Doch klar: Gibt es (ist nur selten sinnvoll): Da die meisten Geräte zwei Bootslots haben, kannst du in beide unterschiedliche OS (z.B. Android und postmarketOS) laden und mit dem Bootloader wechseln. Klar, dann hebelt man wichtige Sytemreperaturfunktionen aus und Updates kann man nur noch manuell über die Recovery installieren, aber geht: https://forum.shiftphones.com/threads/postmarketos-als-dualboot.4832/#post-45256
Streng genommen ist das dann kein Android mehr. Wenn überhaupt geht es mit speziellen AOSP-basierten Systemen und gravierenden Nachteilen. Dass sich ein OS Android nennen darf, ist an verschiedene Bedingungen geknüpft. GrapheneOS vermeidet es deshalb, sich auf der Homepage so zu nennen, weil sie es rechtlich nicht dürfen. Mir passiert die Vermischung der Begrifflichkeiten allerdings auch öfter.
Ich würde ja sagen, dass es eindeutig schon ein Android ist. Aber eben nicht das Android; und so darf es eben nicht Android genannt werden.
Android ist durch Kompatibilitätsanforderungen definiert. In meinem Kommentar meinte ich dieses Android.
Ich kenne kein Custom-OS, das alle Anforderungen erfüllt. Von daher müssten wir hier von AOSP-Forks reden.
Das wissen aber die meisten nicht und es ist auch ein umständlicher Begriff, also ist in Foren und Blogs doch meist von Android die Rede. Zudem wüsste niemand mehr, welche technischen Dinge noch als geltend anzunehmen sind und welche nicht, wenn von AOSP-Forks die Rede ist, da dieser beliebige Änderungen vornehmen könnte, und so beispielsweise das Sicherheitsmodell von Android nicht mehr intakt sein könnte. Von daher verstehe ich die andere Deutung meines Kommentars schon.
Eigentlich ist die Definition ganz einfach:
Android™ = AOSP inkl. GMS (Google Mobile Services).
Äh, nein, so einfach ist es nicht.
Wie ist es dann? Also laut Google selbst ist es genau das, was ich geschrieben habe:
https://source.android.com/docs/setup/start/faqs?hl=de#what-does-compatibility-mean