iPhone Passcode setzen und entfernen

Noch eine Handvoll Tipps zum iPhone-Passcode:iphoneistdeaktiviert

Ist kein Passcode gesetzt, und das Gerät geht verloren, lässt er sich nachträglich via iCloud / Find my iPhone setzen.

Ist ein Passcode gesetzt, wurde vergessen und soll entfernt werden, gibt es laut dem Supportdokument drei Möglichkeiten:

  • Gerät hat ein iTunes-Backup: Unter Umständen (wann genau?) ist eine Wiederherstellung möglich
  • Gerät hat kein iTunes-Backup: iPhone in den Recovery-Mode versetzen und wiederherstellen, die Daten gehen verloren
  • Kein iTunes: Fernlöschung durch Find My iPhone, oder Selbstlöschung nach 10 Fehlversuchen, falls aktiviert.

Wie hier der Einfluss von Activation Lock auf iOS 7 ist, ist noch nicht öffentlich bekannt.

Es gibt aber noch eine angenehmere Möglichkeit, den Passcode zurückzusetzen, die bisher über iCloud oder iTunes nicht angeboten wird:

Ist das iPhone in einer Enterprise-Umgebung, z.B. dem MDM von OS X Server angemeldet, kann der Passcode von diesem MDM-Server aus zurückgesetzt werden. Ohne Wiederherstellung, Backups und Datenverlust. Eventuell ist das eine Option, sich für einmalig 18 Euro von diesem Risiko freizukaufen. Die Einrichtung ist nicht völlig trivial, aber durchaus machbar, wenn man die Dokumentation befolgt.

iOS Data Protection

Das Thema Data Protection kann noch einige Details zusätzlich zur Diskussion in Bits und so #340 vertragen:

Geräte ab dem iPhone 3GS verschlüsseln immer den physikalischen Massenspeicher. Darüber ist z.B. die schnelle Fernlöschung realisiert. Das Gerät kann den Schlüssel aus einem speziellen Bereich, genannt Effaceable Storage (auslöschbarer Speicher), entfernen und damit die gespeicherten Inhalte unzugänglich machen.

Zusätzlich dazu existieren Data Protection Classes. Beim Anlegen von Dateien kann die App die Daten einer Klasse zuordnen, die darüber entscheidet, wann die Daten der App wieder zum Lesen zugänglich sind. Die Klassen sind:

  • No Protection – Datei ist immer zugänglich
  • Complete – Datei ist nicht zugänglich, außer das Gerät ist entsperrt
  • Complete unless already open – Geöffnete Dateien bleiben lesbar, auch wenn das Gerät wieder gesperrt wird
  • Complete until first login – Datei ist nicht zugänglich, bis das Gerät nach dem Booten einmal entsperrt wurde

Diese Zuordnung der Datei zu einer Klasse kann auch wieder abgefragt werden. Außerdem kann abgefragt werden, wie die aktuelle Lesebereitschaft von geschützten Dateien ist. Diese Abfrage ist allerdings nur im gesperrten Zustand negativ.

Die App kann also nicht unterscheiden, ob die eigenen Daten zugänglich sind, weil der Nutzer seinen Passcode eingegeben hat, oder weil er keinen hat.

findmyfriendsApples eigene Apps, z.B. Find My Friends, haben Zugriff auf diese Information und nutzen diese auch sinnvoll. Hat der Nutzer einen Passcode, muss das Passwort zur Apple ID nicht eingegeben werden. Fehlt der Passcode, wird das Passwort verlangt.

Im Enterprise-Umfeld kann in Konfigurationsprofilen ein Passcode erzwungen werden. Dann kann auch die zugehörige Enterprise-App davon ausgehen, dass der Nutzer seinen Passcode eingegeben hat, wenn die Daten zugänglich sind. Für App Store-Apps fehlt diese Sicherheit.

Neben den Data Protection Classes für Dateien gibt es analog dazu Klassen für Keychain-Einträge, mit zusätzlichen Spezialfällen. Mit den “ThisDeviceOnly” Klassen bleibt ein Eintrag nur dann nach einem Backup und Restore zugänglich, wenn er auf dem selben Gerät passiert. Die Dokumentation unterscheidet zusätzlich zwischen einer Wiederherstellung auf einem anderen Gerät und einer neuen Installation auf dem selben Gerät.

Diese Bindung an ein einzelnes Gerät geschieht über die UID, einen 256-Bit AES-Schlüssel, der während der Herstellung in die CPU gebrannt wird. Laut Apple wird keine Kopie dieses Schlüssels von Apple oder seinen Zulieferern gespeichert.

Für iTunes- und iCloud-Backups werden Keybags angelegt, die die Schlüssel enthalten, um Backups auch ohne die Eingabe des Passcodes im Hintergrund zu erlauben. Außerdem kann im Enterprise-Umfeld ein vergessener Passcode damit auch wieder zurückgesetzt werden.

Threema – Klartext via USB und iCloud-Backup

Threema ist ein Messenger für iOS, ähnlich zum allseits beliebten Whatsapp, mit dem entscheidenden Unterschied, dass die Datenübertragung verschlüsselt geschieht und die Schlüssel in der Hand der Nutzer liegen. Der Anbieter hat also keine Möglichkeit, die Nachrichten zu entschlüsseln, und die Nutzer haben nach einem Abgleich der Key Fingerprints die Sicherheit, dass niemand auf der Leitung mithorcht.

Der Schlüssel wird in der Keychain abgelegt und augenscheinlich auch nicht mit in das iOS Backup aufgenommen.

Die entschlüsselten Nachrichten selbst allerdings liegen laut der FAQ direkt im Dateisystem und werden ins Backup mit aufgenommen.

Das Dateisystem kann unter iOS von der “Data Protection” geschützt sein, wenn das Gerät mit einem Sperrcode versehen ist. Fehlt der Passcode, fehlt auch die Sperre.

Fehlt die Sperre, lassen sich alle Nachrichten im Klartext über USB auslesen, z.B. mit iExplorer, ohne Jailbreak.

Und zu guter letzt werden die Nachrichten im Klartext auch in das iTunes-Backup aufgenommen und, wenn das aktiviert ist, auch in das iCloud-Backup hochgeladen.

threema

Das lässt sich einfach nachvollziehen:

  1. Threema einrichten und einige Nachrichten verschicken.
  2. iCloud-Backup durchführen.
  3. Gerät komplett löschen.
  4. iCloud Restore durchführen.
  5. Nachrichten im Klartext per USB auslesen.

Ich habe den Entwickler um eine Stellungnahme dazu gebeten – ich finde trotz der verschlüsselten Übertragung die Handhabung des entschlüsselte Nachrichtentexts doch relativ lax.

Update 13.8.2013: Threema-Entwickler Manuel Kasper hat sich bei mir gemeldet. Aus seiner Sicht sind die Daten durch die iOS Data Protection gut geschützt.

Die lokal gehaltenen Daten könnten durch einen weiteren Schlüssel, z.B. ein langes Passwort, verschlüsselt werden, was aber die Nutzerfreundlichkeit stark einschränken würde.

Mein Vorschlag war dann, die lokalen Daten mit dem gleichen Schlüssel zu verschlüsseln, der auch für die Übertragung über das Netzwerk genutzt wird.

Dieser Vorschlag löse zwar nicht das Grundproblem, dass der Schlüssel am selben Ort wie die Daten, also auf dem Gerät gehalten werde, Manuel Kasper hält es aber für eine grundsätzlich gute Idee, die vielleicht in einem Update als zusätzliche Option umgesetzt werden könnte.

Ein guter Hinweis zur Keychain (mehr dazu hier): Einträge können mittels des Attributs kSecAttrAccessibleWhenUnlockedThisDeviceOnly an den gerätespezifischen UID-Schlüssel gebunden werden. Backups enthalten also immer den verschlüsselten Threema-Schlüssel, können aber nur auf dem gleichen Gerät genutzt werden. Ob Apple keine Kopie dieses Schlüssels hat, sei nicht bekannt.

Speichermedien grundieren mit f3write / f3read

sdhc-32

Ein alter Pick aus der Bits und so #294, aber hier eine Wiederholung wert.

Frisch gekaufte SD-Karten/USB-Sticks/etc. sollte man, auch wenn sie aus einer vermeintlich seriösen Quelle stammen, auf ihre tatsächliche Kapazität und Funktionsfähigkeit überprüfen, bevor man darauf unwiederherstellbare Daten aufzeichnet. Es sind wohl immer wieder gerne Betrüger unterwegs, die falsche Größenangaben auf der Packung und in der Konfiguration des Speichermediums angeben. Die Kamera schreibt also fröhlich 32GB auf eine Karte, die tatsächlich nur 1GB fasst. Die Daten sind dann hinüber. Außerdem kann die Karte auch einfach nur defekt sein, oder die versprochene Schreibgeschwindigkeit nicht halten.

Für Randgruppensysteme tut es dafür h2testw vom Heise-Verlag, auf dem Mac kann man f3write / f3read benutzen. Der Datenträger wird mit einem verifizierbaren Muster beschrieben und dieses wird im Anschluss wieder gelesen.

$./f3write /Volumes/NO\ NAME/
Free space: 29.49 GB
Creating file 1.fff ... OK!                        
Creating file 2.fff ... OK!                        
Creating file 3.fff ... OK!  
...
Free space: 0.00 Byte
Average writing speed: 7.78 MB/s

$./f3read /Volumes/NO\ NAME/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.fff ... 2097152/        0/      0/      0
Validating file 2.fff ... 2097152/        0/      0/      0
Validating file 3.fff ... 2097152/        0/      0/      0
...
  Data OK: 29.49 GB (61835072 sectors)
Data LOST: 0.00 Byte (0 sectors)
           Corrupted: 0.00 Byte (0 sectors)
    Slightly changed: 0.00 Byte (0 sectors)
         Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 17.99 MB/s

Google Translator Toolkit

google-translator-toolkit

In den Tiefen der YouTube-Untertitelfunktion versteckt sich der Google Translator Toolkit. Damit ist folgendes möglich:

  • Deutsches Transkript ohne Timing-Information zu YouTube hochladen
  • YouTube synct die einzelnen Zeilen zum Audio
  • Google Translator Toolkit übersetzt diese einzelnen Zeilen mit Google Translate
  • Spielt dazu synchron das deutsche Video ab, und ermöglicht Bearbeitungen

Und: das funktioniert auch kollaborativ bei größeren Projekten, und lässt sich gegen Bezahlung (ca 10$/Minute) direkt von der YouTube-Adminseite aus outsourcen.

Am Ende kommt dabei ein srt-File heraus, das man zurück zu YouTube schieben kann oder extern weiterverwenden kann.

Außerdem geht das auch für

  • HTML (.HTML)
  • Microsoft Word (.doc/.docx)
  • OpenDocument-Text (.ODT)
  • Nur Text (.TXT)
  • Rich Text (.RTF)
  • Wikipedia-URLs

  • AdWords Editor-Archiv (.AEA)

  • AdWords Editor Share (.aes)

  • YouTube-Untertitel

  • SubRip (.SRT)
  • SubViewer (.SUB)

  • GNU gettext (.PO)

  • Java-Anwendung (.PROPERTIES)
  • Application Resource Bundle (.ARB)
  • Chrome-Erweiterung (.JSON)
  • Apple iOS-App (.STRINGS)