Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

"Erstmals Secure Enclave des iPhones gehackt" - ein Blick auf die Behauptung und eine Analyse

Wenn es einen besonders geschützten Hochsicherheitstrakt auf dem iPhone gibt, dann die sogenannte "Secure Enclave". Diese wurde angeblich nun erstmals gehackt - eine Behauptung, die näherer Überprüfung aber nicht standhält. Ein Blick auf die Faktenlage.

Funktionsweise der Secure Enclave
Sensible Daten wie beispielsweise Code- und Fingerabdruckdaten liegen in diesem speziellen Bereich, von außen ist durch das System kein Zugriff darauf möglich. Lediglich der Secure Enclave selbst ist der Schlüssel bekannt, um mit den Daten umzugehen. Der Schlüssel wird unabhängig davon immer mit PBKDF2-AES erzeugt, welches das Erraten von Kennwörtern erschwert. Da nur dem Gerät seine UID bekannt ist, können verschlüsselte Daten zwar kopiert, aber nur auf dem Gerät effektiv entschlüsselt werden. Auf dem Gerät benötigt ein Entschlüsselungsversuch mit PBKDF2-AES laut Apple stolze 80 Millisekunden, was in der Minute maximal 750 Versuche gestattet. Bei der unvorstellbaren großen Zahl an Möglichkeiten (eine Zahl mit 39 Stellen) ist das Erraten des Schlüssels damit extrem aufwändig.

Secure Enclave kam mit 64-Bit-Chips
Apple führte die Sicherheitsfunktion zusammen mit Touch ID und dem iPhone 5s (September 2013) ein. Aus diesem Grund lässt sich der Vorgänger des iPhone 5s auch erheblich einfacher knacken, da der Code zwar verschlüsselt abgelegt, allerdings (mit großem Aufwand) auszulesen ist. Mit der Secure Enclave kann das System hingegen noch so kompromittiert sein, der Prozessorbereich bleibt unangetastet. Das Maximum an Informationen ist die Rückmeldung, ob ein Code (oder Fingerabdruck) den gespeicherten Informationen entspricht. Touch ID und Secure Enclave sind so konzipiert, dass ein Sensor auch nur auf einem iPhone funktioniert - das werkseitig aufeinander geeichte Gespann kann nicht einfach durch andere Bauteile ersetzt werden. Dies ist auch der Grund, warum der Wechsel des Touch-Sensors so komplex ist und eine Reprogrammierung erforderlich macht.


Geknackt: Der Entschlüsselungscode
Nach vier Jahren ist es Hackern jetzt aber wohl gelungen, den Dechiffriercode der Secure Enclave zu knacken. Damit es möglich, die Firmware zu entschlüsseln - diese besteht aus einem eigenen Kernel, Treibern sowie Systemdiensten, um die Kommunikation bereitzustellen. Der Hacker veröffentlichte ein Tool bzw. eine Library (img4lib), diese dechiffriert Apples am stärksten abgeschottete Sektion. Apple wird die Angelegenheit sicherlich sehr genau beobachten, allerdings gibt es auch keinen Grund für Panik.

Was der Hack nicht bedeutet - was nun aber möglich ist
Selbst wenn der Key für das iPhone 5s geknackt werden konnte, so wäre immer noch ein sehr weiter Weg bis zu potenziellen Hackerangriffen auf Nutzer zu gehen. Die Folgerung, erstmals sei die Secure Enclave gehackt worden, ist grundlegend falsch. Sicherlich kam noch kein Hacker so weit wie jetzt und es ist durchaus als große Leistung anzusehen. Momentan steht aber gerade einmal der Weg offen, die Firmware genauer zu verstehen, erstmals die innere Funktionsweise zu analysieren und dann nach weiteren Sicherheitslücken zu suchen.

Selbst wenn es diese gäbe und selbst wenn daraus Exploits resultierten, sind diese lediglich auf anderen iPhone 5s anzuwenden - und dies auch nur bei physikalischem Zugang, denn der erforderliche Betriebszustand des Prozessors ist nicht von außen zu steuern. Apples Sicherheitskonzept der Secure Enclave geht sehr viel weiter, als einfach nur lange Schlüssel zu verwenden - die Einbindung des separierten Hardware-Bereichs ist weitaus bedeutender als die eigentliche Verschlüsselung. Man darf nun aber sehr gespannt sein, was die Firmware-Analyse ergibt, denn Apple dokumentierte den Sicherheitsbereich verständlicherweise bislang gar nicht öffentlich.

Kommentare

Dirk!18.08.17 12:14
MTN: „... denn Apple dokumentierte den Sicherheitsbereich verständlicherweise bislang gar nicht öffentlich.”

Verständlich ist das gar nicht: "security by obscurity" war noch nie eine gute Idee.
-13
cy2u518.08.17 12:42
Fehlt nur noch das Programmieren von austauschbaren TouchID Homebuttons 😊
-2
aMacUser
aMacUser18.08.17 12:45
Dirk!
"security by obscurity" war noch nie eine gute Idee.
Das halte ich für Unsinn. Das beste Beispiel dafür ist schließlich dieser Artikel. Es hat geschlagene 4 Jahre(!) benötigt, um die Firmware "zu knacken", jetzt erst können die Hacker anfangen, nach Sicherheitslücken im (4 Jahre alten!) Code zu suchen. Die Wahrscheinlichkeit, dass Apple diese in aktuellen Versionen schon lange behoben hat, ist auch nicht sonderlich gering.

"security by obscurity" ist vielleicht dann dämlich, wenn es die einzige Sicherheitsmaßnahme ist, aber hier scheint es ja eine zusätzliche Maßnahme zu sein, und dann ist es durchaus praktikabel.

Außerdem gehört Quellcode bei den meisten Unternehmen in der Regel zu den Firmengeheimnissen, und da wird dann natürlich nichts veröffentlicht.
+15
sierkb18.08.17 12:47
heise (18.08.2017): Apples Secure Enclave: Hacker veröffentlicht Entschlüsselungs-Key
Der Schlüssel soll es erstmals erlauben, einen Blick auf die Firmware des Koprozessors von älteren iPhones zu werfen. Die Secure Enclave schützt Fingerabdruckdaten und Passwörter.

BlackHat 2017, 04.08.2017: Demystifying the Secure Enclave Processor
Speaker: David Wang, Mathew Solnik, Tarjei Mandt , (PDF)

mikeash.com (19.02.2016): Friday Q&A 2016-02-19: What Is the Secure Enclave?

-4
Fenvarien
Fenvarien18.08.17 13:11
aMacUser Mit einer Einschränkung: Die Secure Enclave ist nicht patchbar, auch nicht von Apple. Während der Fertigung erfolgt die Programmierung, anschließend ist Feierabend.
Up the Villa!
+2
Walter Plinge18.08.17 14:00
Fenvarien
aMacUser Mit einer Einschränkung: Die Secure Enclave ist nicht patchbar, auch nicht von Apple. Während der Fertigung erfolgt die Programmierung, anschließend ist Feierabend.

Sicher? Laut Apples "iOS Security Guide" Seite 7 (Abschnitt: Secure Enclave) ist sie sehr wohl aktualisierbar. Zitat: "The Secure Enclave utilizes its own secure boot and can be updated using a personalized software update process that is separate from the application processor."

Nachtrag: Ich vermute mal, dass dem A7 einfach ein paar HW-Fähigkeiten fehlen, die später nachgerüstet wurden - was im oben genannten Abschnitt explitzit erwähnt wird:
* ab A8: Authentifizierung zum Zugriff auf den lokalen Secure-Enclave-Speicher
* ab A9: Generierung einer lokalen eindeutigen UID als Schlüssel
+3
aMacUser
aMacUser18.08.17 14:01
Fenvarien
aMacUser Mit einer Einschränkung: Die Secure Enclave ist nicht patchbar, auch nicht von Apple. Während der Fertigung erfolgt die Programmierung, anschließend ist Feierabend.
Das habe ich mir schon gedacht. Ich meinte, dass eventuelle Sicherheitslücken in neueren iPhone-Versionen bereits behoben sind.
0
sierkb18.08.17 14:15
aMacUser
jetzt erst können die Hacker anfangen, nach Sicherheitslücken im (4 Jahre alten!) Code zu suchen.

Nö, das tun sie schon die ganze Zeit und sammeln.
Die Wahrscheinlichkeit, dass Apple diese in aktuellen Versionen schon lange behoben hat, ist auch nicht sonderlich gering.

Ich glaube, hier irrst Du leider. Apple behebt derlei Lücken leider nicht ordentlich, schludert dabei, behebt sie lange Zeit entweder gar nicht oder nur dann nur teilweise, sodass sie teilweise immer noch offen sind und ausgenutzt werden können und das auch werden, selbst wenn und nachdem Apple die betreffende Lücke angeblich gepatcht hat. Absicht oder einfach nur Unvermögen?

Sicherheitsexperten sind verwundert, warum Apple da de facto nicht ordentlich und oft nur halbherzig patcht, die ursprünglichen Lücken teilweise und regelmäßig immer noch offen lässt statt sie komplett und zweifelsfrei dicht zu machen, wenn sie sie schon anfassen, in der Außenkommunikation aber behaupten, die betreffende Lücke sei nun dicht.

Sicherheits- uund Jailbreak-Experte Stefan Esser, reicht es nun, und er benennt nun seit wenigen Wochen genau diese Lücken, von denen Apple selber sagt, dass sie sie sauber geschlossen hätten, weist in einer derzeit größer werdenden Auflistung hin darauf hin, dass da eine Diskrepanz ist zwischen von Apple propagiertem Soll- und tatsächlichem Ist-Zustand und Apple da doch bitte nochmal nachbessern und diese Löcher richtig fixen sollte statt nur so halb oder stümperhaft (weil genau da Schadprogramme nämlich gerne reingreifen und das ausnutzen):

GitHub: bad-bad-apple: A curated list of not properly fixed apple security bugs and attempts to influence disclosure. This list will be filled over the next weeks with instances that we know of. Insufficiently patched iOS vulnerabilities – The following table is work in progress. It shows for every iOS versions (since iOS 6.0) what vulnerabilities they were still vulnerable to because previous patches were incomplete (MacOS and OSX table will follow).

Außerdem gehört Quellcode bei den meisten Unternehmen in der Regel zu den Firmengeheimnissen, und da wird dann natürlich nichts veröffentlicht.

Der L4-Mikrokernel , , , Herzstück der Secure Enclave, ist Open-Source und seit Jahren hinreichend bekannt wie er arbeitet und angesteuert wird. Apples Sicherheitschef Ivan Krstić höchstselbst hat darüber letztes Jahr auf der BlackHat 2016 Auskunft gegeben bzw. die Info taucht in einem Nebensatz in Apples im Zuge dessen veröffentlichten Dokuments "iOS Security Guide", Seite 7 (Abschnitt: Secure Enclave) dazu auf.

Und ja, Walter Plinge hat völlig Recht mit seinem Hinweis, dass Apple den L4-Kernel und die Secure Enclave jederzeit umprogrammieren kann, z.B. für Firmware-Updates für die Secure Enclave, das geschieht über einen eigenen gesicherten Kanal, der völlig unabhängig ist vom restlichen iOS-Betriebssystem, mit dem die Secure Enclave über eigene und speziell ausgewählte Kanäle sich mit dem sie umgebenden iOS austauscht. Steht auch in dem genannten von Apple letztes Jahr veröffentlichten Dokument drin. Ähnlich arbeitet auch der in die Touchbar integrierte ID-Sensor/Fingerabdrucksensor in aktuellen MacBookPros, da kommt ebenfalls die Secure Enclave auf Basis eines eigenen L4-Kernels zum Einsatz.
-6
Walter Plinge18.08.17 14:48
Nun ja:
1. Wer noch nie eine Bug durch einen Bugfix eingebaut hat, werfe den ersten Stein (mir persönlich zumindest passiert das durchaus öfter).
2. Das ein Bugfix unvollständig sein kann, kommt ebenfalls regelmäßig vor.

Das heißt nicht, dass das die Mehrzahl der Bugbehebungen betreffen sollte, aber das ist doch wohl auch eher nicht der Fall. Auch die oben verlinkte Liste ist ja eher mager im Vergleich, zu den vielen Bugs, die regelmäßig von Apple gefixt werden. Und um mal ein Beispiel zu bringen, dass der oben erwähnte Stefan Esser selbst annmahnt (der PEGASUS Bug):

Man beachte insbesondere den letzten Absatz. Einen Fehler zu fixen, der noch nicht bekannt ist, ist immer ganz besonders schwer.
+5
sierkb18.08.17 14:55
Walter Plinge:

Apple reißt aber beim Patchen teilweise wieder alte Löcher auf, die schon als gefixt galten bzw. sagt: "haben wir gefixt", dabei haben sie da nur ein vorübergehendes Plasterchen zur Beruhigung draufgeklebt und es in Wirklichkeit nicht wirklich sauber gefixt, sodass die betreffende Lücke dann wirklich geschlossen ist. Das ist nicht sauber, das ist unsaubere Arbeit. Sowas kreidet man sonst üblicherweise stets bei der Konkurrenz an – zurecht.
Und: hast Du auch seine diesbzgl. Conclusion ganz am Schluss gelesen und auch passend dazu seine sonstigen Bemerkungen auf Twitter und auf seinen und Vorträgen und den seiner Kollegen? Der Fehler war Apple durchaus frühzeitig bekannt, und sie waren da schon dran. Viel früher als sie zugegeben hatten, von dem Fehler zu wissen. Aber sie hatten ihn unsauber gefixt. Sodass er ihnen Monate später erneut um die Ohren flog und da dann von sich Reden machte. Und die betreffende Problemstelle offenbar inzwischen immer noch nicht richtig gefixt ist und immer noch ausgenutzt werden kann (und im Stillen garantiert auch wird).
-7
PaulMuadDib18.08.17 15:43
Geht das schon wieder los …
+1
sierkb18.08.17 15:45
Dirk!
"security by obscurity" war noch nie eine gute Idee.

threatpost (18.08.2017): Hacker Publishes iOS Secure Enclave Firmware Decryption Key :
A hacker Thursday afternoon published what he says is the decryption key for Apple iOS’ Secure Enclave Processor (SEP) firmware.

The hacker, identified only as xerub, told Threatpost that the key unlocks only the SEP firmware, and that this would not impact user data.

“Everybody can look and poke at SEP now,” xerub said.

Apple did confirm to Threatpost that if the key was legitimate, that user data would not be at risk from this leak. Apple has reportedly yet to confirm the validity of the key.

The Secure Enclave, as explained in the iOS Security Guide, is a coprocessor onto itself inside the mobile operating system. Its job is to handle cryptographic operations for data protection key management; its separation from the rest of iOS maintains its integrity even if the kernel is compromised, Apple said in the guide.

Primarily, the Secure Enclave processes Touch ID fingerprint data, signs off on purchases authorized through the sensor, or unlocks the phone by verifying the user’s fingerprint.

Publishing of the key now exposes the Secure Enclave to researchers and attackers alike, both of which will be able to examine the previously walled-off processor for vulnerabilities and gain insight into how it operates.

“Hopefully Apple will work harder now that they can’t hide SEP, resulting in improved security for users,” xerub said.

Xerub would not provide any details on how he decrypted the key, nor would he comment on whether he looked for, or found any, vulnerabilities in the Secure Enclave once he had access. He also would not comment on whether he privately disclosed his finding to Apple in advance.

“This isn’t really bad in my opinion,” said Patrick Wardle, chief security researcher at Synack and founder of Objective-See. “[This] just means the security researchers, and yes hackers, can now look at the firmware for bugs. Before, it was encrypted so they couldn’t audit and analyze it. Is a system less secure if people can’t audit it? I think, yes.”

The question that’s left out in the open is whether xerub was able to leverage a vulnerability or weakness in Secure Enclave to decrypt the key, and whether Apple will be able to implement a new encryption key for Secure Enclave, should it choose to do so.
-9

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.