iOS Verschlüsselung von heise durchleuchtet
mr.nice. 18.12.2013 - 12:09 2102 7
mr.nice.
differential image maker
|
Eine kurze Zusammenfassung von mir: Die zweistufige Verschlüsselung leistet generell gute Dienste und selbst Schadcode der auf der CPU des Geräts ausgeführt wird, hat Schwierigkeiten die zweite Verschlüsselung auf Dateiebene zu überwinden, sofern sie vorhanden ist. Wie bereits angesprochen gesellt sich zur ersten Stufe, der Hardwareverschlüsselung zwischen Flash-Speicher und CPU, seit iOS 4 eine AES-256 Verschlüsselung auf Dateiebene hinzu, in die ebenfalls der Passcode des Benutzers eingearbeitet wird, Keychain im Apple-Jargon genannt. Lange Zeit war dies optional und ist erst seit iOS 7 verpflichtend. Apps die vor iOS 7 installiert wurden, werden nicht nachträglich verschlüsselt. Hier hilft nur eine Neuinstallation der Anwendung. Auch gönnt sich Apple selbst großzügige Ausnahmen, so liegen Adressbuch, Bookmarks, Notizen, Kalender, SMS, MMS, iMessages und der Cache der Bildschirmtastatur nach wie vor unverschlüsselt auf dem Gerät vor. Besser funktioniert die lokale Verschlüsselung bei Diensten wie ActiveSync, Skype, Facebook und WhatsApp. Für mich liest sich das so, als "wollte" Apple damit gewissen Leuten ihren Job nicht allzu schwer machen. Quellen: Kurzmeldung: http://www.heise.de/security/meldun...se-2066775.htmlAuführlicher Artikel: http://www.heise.de/security/artike...et-2066500.html
|
pinkey
Here to stay
|
Naja wenn ich mich jetzt nicht total verlesen hab (nur drüber geflogen) funktioniert das nur wenn das Handy vorher einen JB drauf hatte oder nachträglich ein Bootrom JB wie bei den alten Geräten möglich ist.
Einen Public JB für neue Geräte gibts ja schon länger nicht mehr ... soll natürlich nicht heißen das sich gewisse Leute sowas nicht kaufen könnten/haben.
|
Smut
takeover&ether
|
Auch gönnt sich Apple selbst großzügige Ausnahmen, so liegen Adressbuch, Bookmarks, Notizen, Kalender, SMS, MMS, iMessages und der Cache der Bildschirmtastatur nach wie vor unverschlüsselt auf dem Gerät vor. Besser funktioniert die lokale Verschlüsselung bei Diensten wie ActiveSync, Skype, Facebook und WhatsApp.
Für mich liest sich das so, als "wollte" Apple damit gewissen Leuten ihren Job nicht allzu schwer machen.
[/url] apple wird es nicht verschlüsseln, da sie zumindest auf adressbuch, kalender etc. zugriff aus anderen apps zulassen. zumindest bei iOS6 gab es dafür keine lösung. ein weiteres problem war bei der verschlüsselung auf dateiebene: apps die im hintergrund waren haben sobald das device locked ist keinen zugriff mehr auf den schlüssel -> das heißt sobald der sperrbildschirm aktiviert wurde konnten die apps im hintergrund nicht mehr weiterlaufen. die aussage, dass imessages & co unverschlüsselt am device liegen stimmt so auch nicht. auf block ebene ist das FS ja verschlüsselt, die datei selbst nicht. das heißt dass man z.b. über einen jailbreak dran kommt. aber gut, in diesem zustand ist es ohnehin sehr schwer für sicherheit zu sorgen - auch an die keychain kommst ran wenn das device gejailbreaked ist. imho ist es kritik auf hohem niveau.
Bearbeitet von Smut am 18.12.2013, 16:16
|
mr.nice.
differential image maker
|
Ich stimme dir zu, dass es Kritik auf hohem Niveau ist, aber man muss sich meiner Meinung nach schon fragen, warum Apple einerseits diesen großen Aufwand betreibt für die Anwender ein hohes Maß an Sicherheit zu gewährleisten und andererseits das Konzept nicht vollständig implementiert.
Apps im Hintergrund könnte man z.B. mit Handshakes beschränkten bzw. temporären Zugriff auf die benötigten Informationen gewähren, aber so bleibt bei mir zumindest ein Gefühl von "das hätte man besser machen können." und ich frage mich, warum sie das eigentlich nicht getan haben.
|
Smut
takeover&ether
|
Weil sie nach aktuellem hardware design keine nachrichten mehr abspeichern könnten sobald das device locked ist?
zumindest war das meine erklärung. Dass sie mit ios7 die dateiverschlüsselung für alle apps erzwungen haben war mir neu - hat aber einen vorteil: selbst wenn eine app in den folder einer anderen app Schreiben könnte, kann es Von anderen apps nicht gelesen werden.
aber wie gesagt: sobald jemand root ist am device kann er eh alles - die verschlüsselung machts halt etwas aufwendiger.
|
Smut
takeover&ether
|
Ich habe mir den Artikel noch mal durchgelesen:
zwei Sachen zur Anmerkung:
1. ob der verwendete AES256 Key wirklich zu zufällig ist, bin ich mir nicht sicher. Laut dem Apple Dokument ios Security Oktober 2012, wird der key ja Von der UDID und der GID (iOS Modell) abgeleitet. gleichzeitig schreibt aber dass sie keine Aufzeichnungen über die UDID führen - ev meinen sie eine andere ID.
2. zumindest iMessage hat meiner Beobachtung nach ein Problem wenn sie auf dateiebene verschlüsselt werden. Emails sind serverseitig gespeichert - deshalb ist es hier kein Problem die Notifikation vorzuschalten und dann beim öffnen der app die eigentliche Message zu laden (so auch bei whats app etc).
iMessage ist mehr ein datenstream der nur kurzzeitig in der iCloud vorgehalten wird.
wird ein idevice per Push verständigt so könnte die Nachricht nicht abgespeichert werden solange das Gerät locked ist. Wird das iPhone jetzt ausgeschalten bzw, Akku geht aus, ist die Nachricht verloren. Bzw. Zwei weitere Probleme die dadurch aufpoppen: ab wann gilt die Nachricht delivered? Wenn das phone locked ist würde die Nachricht erneut per SMS zugestellt werden. Und wie verhält sich die Notifikation-Synchronisation über mehre iOS devices?
sind alles lösbare Probleme, dafür hätten sie iMessage halt ordentlich umbauen müssen.
|
Nico
former person of interest
|
|
Smut
takeover&ether
|
sie haben sich einfach viele Gedanken gemacht und sind damit der Konkurrenz um einiges voraus. Man bedenke dass das Konzept mit iOS 4/5 gekommen ist. Some files may need to be written while the device is locked. A good example of this is a mail attachment downloading in the background. This behavior is achieved by using asymmetric elliptic curve cryptography (ECDH over Curve25519). Along with the usual per-file key, Data Protection generates
a file public/private key pair. A shared secret is computed using the file’s private key and the Protected Unless Open class public key, whose corresponding private key is protected with the user’s passcode and the device UID. The per-file key is wrapped with the hash of this shared secret and stored in the file’s metadata along with the file’s public key; the corresponding private key is then wiped from memory. As soon as the file is closed, the per-file key is also wiped from memory. To open the file again, the shared secret is re-created using the Protected Unless Open class’s private key and the file’s ephemeral public key; its hash is used to unwrap the per-file key, which is then used to decrypt the file. Page10: http://www.apple.com/ipad/business/...urity_Oct12.pdf
|
Anmeldung