Onderzoeker publiceert decryptiesleutel voor SEP-firmware van iPhone 5s

Een beveiligingsonderzoeker, die bekendstaat onder de naam xerub, heeft de decryptiesleutel voor de firmware van de secure enclave coprocessor van de iPhone 5s gepubliceerd. Daardoor is het mogelijk de firmware verder te onderzoeken, maar ontstaat er geen direct risico voor gebruikers.

Apple heeft de echtheid van de sleutel nog niet bevestigd, maar zegt tegen Threatpost dat als het om een echte sleutel gaat er geen gevaar voor het uitlekken van gegevens van gebruikers bestaat. De onderzoeker heeft geen details gegeven over de manier waarop hij de sleutel heeft verkregen en zei ook niet of hij zijn bevindingen aan Apple heeft gemeld. Hij kondigde zijn ontdekking recentelijk aan in een tweet, waarbij hij verwees naar de sleutel en tools om de firmware te ontsleutelen en te verwerken.

Zowel xerub en een anonieme Apple-medewerker zeggen tegen TechRepublic dat de vondst meer onderzoek naar de coprocessor, oftewel SEP, mogelijk maakt. De onderzoeker stelt: "Decryptie van de firmware staat niet gelijk aan het ontsleutelen van gebruikersdata." Hij voegt daaraan toe dat hij ervan uitgaat dat zijn publicatie uiteindelijk zal bijdragen aan verbeterde beveiliging van Apples secure enclave. De ceo van de Sudo Security Group zegt tegen The Register dat de decryptiesleutel dan ook voornamelijk interessant is voor beveiligingsonderzoekers, die bijvoorbeeld de firmware kunnen onderzoeken.

Hij zegt verder: "De publicatie van de sleutel tast de veiligheid van de secure enclave niet aan. De coprocessor heeft als taak om gevoelige informatie te beschermen, maar de encryptie heeft meer te maken met het onleesbaar maken van de code dan het beschermen van de eigenlijke inhoud." Apple introduceerde de secure enclave als een aparte coprocessor in de iPhone 5s en volgende toestellen met een A7- of latere chip. De processor draait op een eigen OS en is verantwoordelijk voor het uitvoeren van cryptografische processen en het verwerken van vingerafdrukken via Touch ID.

Er bestaat niet veel publieke informatie over de SEP, behalve wat door Apple naar buiten is gebracht. Beveiligingsonderzoekers presenteerden vorig jaar hun bevindingen over de processor op de Black Hat-conferentie in Las Vegas.

Reacties (30)

Waarom zit er encryptie op iets, wat volgens Apple uiteindelijk niet tot een beveiligingsprobleem voor de gebruiker kan leiden?

Waarschijnlijk om de werking geheim te houden, en te zorgen dat de firmware niet geupdate kan worden.

Nu kunnen concurrenten de werking proberen te repliceren, en hackers een lek proberen te vinden. Ook is het mogelijk (maar waarschijnlijk zeer lastig) om de firmware te overschrijven, en zo een evil maid attack uit te voeren. Dit soort aanvallen zijn gebaseerd op het kunnen overschrijven van het opstartgedrag.

Dus geen direct risico, maar waarschijnlijk indirect wel enigzins, en zeker jammer voor Apple.

Dat is dus precies waar mijn gedachten heen gingen, zie ook bovenstaande reactie over de Tweakers website. Het komt imo erg laks over van Apple, ik ben absoluut geen encryptie expert dus ik kan er ook gigantisch naast zitten natuurlijk.

Eenmaal in de hal gekomen kun je rustig zoeken naar een weak spot naar de woonkamer..

Om een erg gangbare stelling over cryptografische systemen te citeren,
namelijk Kerckhoff's principle:
2: [The system] should not require secrecy, and it should not be a problem if it falls into enemy hands;

Dit is de algemeen geaccepteerde stelling, die impliceert dat security by obscurity niet werkt. De decryptie van de firmware van een secure co-processor zou het niet minder veilig minder maken.

Daarnaast hoeft decryptie niets, en heeft het in gangbare implementaties zeer weinig, weinig te maken met het namaken van signatures van firmwares. In het algemeen gebruik je voor signatures een hash-based message authentication code en daarna voor encryptie van de data zelf een block cipher.

Als de key van de block cipher lekt (gangbaar: AES) kan je de firmware decrypten. Maar om een signature na te maken heb je de (gangbaar: public key, RSA. ECDSA ongeschikt, zie PS3) crypto key van Apple nodig.

(Draai je dat om dan gaat het vaak mis, zie Cryptographic Doom principle/Moxie Marlinspike)

Dit is de algemeen geaccepteerde stelling, die impliceert dat security by obscurity niet werkt.

Één kleine nuance, hoewel het de veiligheid van je syteem er niet vanaf mag hangen kun je het wel gebruiken om een extra barrière op te werpen.

Apple heeft geen enkele reden om je een handje te helpen door je alvast van de (leesbare) firmware te voorzien; maar ze gaan er ongetwijfeld vanuit dat een competente onderzoek die wel weet te bemachtigen.

In het algemeen gebruik je voor signatures een hash-based message authentication code

Je bedoelt 'message digest' ipv. 'authentication code'. Een HMAC is een geheel andere constructie tbv. authentication.

n het algemeen gebruik je voor signatures een hash-based message authentication code en daarna voor encryptie van de data zelf een block cipher.

Je draait hem hier om. Je moet de ciphertext signen. Encrypt-then-sign en verify-then-decrypt.

(gangbaar: public key, RSA. ECDSA ongeschikt, zie PS3)

Met ECDSA is niets mis. Met onjuiste implementaties (Sony) wel.

[Reactie gewijzigd door Thralas op 18 augustus 2017 20:13]

Één kleine nuance, hoewel het de veiligheid van je syteem er niet vanaf mag hangen kun je het wel gebruiken om een extra barrière op te werpen.

Dat klopt volledig en je zegt het precies goed. Je maakt het systeem er niet veiliger mee maar maakt de drempel hoger.

Je bedoelt 'message digest' ipv. 'authentication code'. Een HMAC is een geheel andere constructie tbv. authentication.

Mijn terminologie was/is niet zo precies. Voor signatures [om authenticiteit te controleren] is het gebruikelijk om een HMAC constructie te gebruiken?

Je draait hem hier om. Je moet de ciphertext signen. Encrypt-then-sign en verify-then-decrypt.

En dan inderdaad de goede kant op (goed gezien). Ik refereerde zelf naar deze volgorde en mijn tekst sloot daar niet bij aan, auw. Meestal wil je een veilig cryptosysteem bouwen, geen orakel

Met ECDSA is niets mis. Met onjuiste implementaties (Sony) wel.

Ja/nee. ECDSA is een mijnenveld doordat random nonces essentieel zijn voor de veiligheid van het systeem. Her-gebruikte nonces of bias in randomness (in mindere mate/academische aanval) zijn fataal. Ik vind dat een ontwerpfout die het een twijfelachtige/ongeschikte keuze maakt (t.o.v. bijvoorbeeld ed25519 of voor authenticatie op korte termijn/pre-Quantum: RSA)

Eenmaal in de hal gekomen kun je rustig zoeken naar een weak spot naar de woonkamer..

Encryptie van de firmware zorgt voor security through obscurity. Als er veiligheidslekken zijn, dan zijn die er met en zonder encryptie van de firmware. Men kan zeggen dat met encryptie het moeilijker is om kwetsbaarheden te vinden en te misbruiken, maar het omkeerargument is dan ook geldig: zonder encryptie kunnen kwetsbaarheden sneller gevonden en opgelost worden.

zonder encryptie kunnen kwetsbaarheden sneller gevonden en opgelost worden

Dat gaat natuurlijk alleen op als als fabrikant zelf die lekken vindt of ze netjes geraporteert krijgt. Omdat je over derden geen controle hebt mag je niet op hen vertrouwen en moet er dus vanuit dat een gevonden lek niet geraporteert zal worden. En dan is encryptie op firmware oppeens wel zinvol en effectief om mogelijke lekken die je zelf nog niet gevonden hebt (en dus nog niet hebt kunnen verhelpen) voor derden lastiger te vinden te maken. Conclusie: encryptie van firmware is wel zinvol.

Apple wilt dat externen niet onderzoek kunnen verrichtten naar de werking van de co-processor. Eventuele zwaktes zijn nu op te sporen. Apple zal er niet blij mee zijn. Ze zeggen dat het niet tot een beveiligingsprobleem leidt omdat ze een PR debacle willen voorkomen. De toekomst moet uitwijzen of er nou wel of niet informatie kan worden misbruikt hierdoor.

Hoe zit het met beveiliging/encryptie op Android gebaseerde toestellen? Is hiervoor ook een aparte processor die onze data veilig houdt? Of wordt dit op een andere manier (even goed?) beveiligd?

Nee, bij Android wordt zover ik weet dat niet door een aparte processor geregeld.
De enige die wel iets met eigen hardware doet, maar of dat een speciale processor is of dat dat alleen de security keys zijn in een apart stukje hardware, is BlackBerry. En ja, dat doen ze ook bij de nieuwe Android toestellen gefabriceerd door o.a. TCL.

[Reactie gewijzigd door William_H op 18 augustus 2017 18:21]

Onjuist. De meerderheid van de toestellen die NFC ondersteunt (denk: NFC betalen) heeft een secure element.

In eerste instantie in de NXP (ook: NFC) chips die in Android toestellen gebruikelijk waren. Tegenwoordig in Snapdragon CPU's

Ik doelde niet op NFC gerelateerde beveiliging, maar op de algemene beveiliging van gegevens op smartphones en de (kernel)beveiligingstechnieken van, specifiek, BlackBerry.

Qualcomm toestellen hebben QSEE, andere SoC vendors hebben vergelijkbare technieken.
Deze aparte SecurCore processor beheert de Android keystore.

Gelaagde beveiliging?

Met een dump van de firmware zou men vulnerabilities kunnen vinden om zo misschien wel toegang te kunnen krijgen tot andere delen van de iPhone. Om deze reden zit er een encryptie op.

In de opvolgers van de Apple 5S is die encryptie dan ook weggelaten.

Waarom zit er encryptie op Tweakers.net nieuwspagina's?

Waarom niet.

Omdat je er transacties met geld kan doen, en acties kan winnen en mee kan doen aan bijvoorbeeld een sollicitatie voor een open functie etc. Tweakers is alang al niet meer alleen een nieuwssite. Het is ook een platform geworden waar gebruikers terecht kunnen voor hulp met hardware problemen of advies voor welke hardware genomen moet worden voor x gebruikers etc..

En heel eenvoudig: de betrouwbaarheid van de inhoud.
Als er staat, Bitcoins stijgen 100% wil je zeker weten dat het legitiem is en niet een nep bericht om de markt op te jagen.

Daar heeft HTTPS echt niets mee te maken, want als een nieuwsposter dit plaatst als nieuwsbericht (niet waarschijnlijk, maar he: het kan) dan staat het er toch echt op.

HTTPS garandeert alleen dat je communiceert met wie jij denkt te communiceren. Dat je met de duivel zelf kan communiceren staat daar los van 😊 Oftewel, als Tweakers besluit je accountgegevens en IP data te verkopen aan de hoogste bieder helpt HTTPS daar inderdaad niks bij.

Dus inderdaad, je hebt gelijk. Dit is ook meer een aanvulling en geen kritiek 😜

Dat zal vast als reden hebben zodat je niet via de onbeveiligde paginas rustig uit kunt zoeken hoe je de rest kunt kraken?

Dat staat toch gewoon in het artikel:
de encryptie heeft meer te maken met het onleesbaar maken van de code dan het beschermen van de eigenlijke inhoud.

Toevallig poste "EverythingApplePro" vandaag een filmpje waarin hij een apparaat toont dat ongelimiteerd pascodes kan uitproberen op de iPhone 7(plus): https://youtu.be/IXglwbyMydM

Daarom altijd de instelling activeren welke na 15 verkeerde pascodes je toestel wist!

Edit: Ooh deze tool maakt gebruik van een tijdelijk lek in de 10.3.3. Update en werkt alleen met een iPhone 7 Dat zal wel snel gepatched worden.

[Reactie gewijzigd door Donstil op 18 augustus 2017 18:49]

10x, maar inderdaad, dat zou eigenlijk, wat mij betreft, ook standaard aan mogen staan.

Hartstikke leuk, dat wissen na 10x. Dat toont aan dat je geen kinderen hebt

Ik heb geen kinderen idd maar als ik die wel zou hebben dan wordt het alsnog geen multi user device. Daar koop ik dan wel een oude iPod Touch voor ofz.

Scheelt ook weer kinder zooi in mijn YouTube algoritme

[Reactie gewijzigd door Donstil op 18 augustus 2017 21:55]

Geen multi user device, snap ik, maar het gaat om kinderen. Die zullen ook op momenten dat jij niet bij je telefoon bent (bijvoorbeeld als je slaapt) best wel een keer een wachtwoord proberen, vaak meer dan één poging... en ja de grens van 10 wordt dan krap.

Door hoeveel accounts je device gebruikt wordt, maakt dan niet uit.