Professor: Apple kan versleutelde iPhone niet ontsleutelen
Met de lancering van iOS 8 heeft Apple een belangrijke beveiligingsmaatregel toegevoegd waardoor bestanden op iOS-toestellen automatisch worden versleuteld als gebruikers een passcode instellen en een bekende professor op het gebied van encryptie heeft nu in technisch detail uitgelegd waarom Apple versleutelde iPhones niet kan ontsleutelen.
Hoewel encryptie ook al in iOS 7 aanwezig was, worden via de nieuwe maatregel nu veel meer gegevens versleuteld en kan Apple de versleutelde gegevens niet ontsleutelen, tot onvrede van de FBI en Europol. De sleutel voor de encryptie wordt afgeleid van de passcode van de gebruiker gecombineerd met een unieke geheime 256-bit sleutel genaamd UID, die in de hardware van de telefoon wordt opgeslagen, waar die lastig te achterhalen is. Apple stelt dat het deze sleutels niet opslaat of kan benaderen.
Secure Enclave
Bij nieuwere iOS-apparaten, die over een A7 of nieuwere A-processor beschikken, wordt de sleutel en het "mixproces' nog eens extra beveiligd middels een cryptrografische co-processor genaamd Secure Enclave. De Secure Enclave is ontworpen om het uitlezen van de UID-sleutel te voorkomen. Op oudere Apple-apparaten bevond deze sleutel zich in de applicatieprocessor zelf.
Secure Enclave biedt een extra beveiligingslaag die zelf blijft werken als de applicatieprocessor is gecompromitteerd, bijvoorbeeld via een jailbreak. Dat stelt Mathew Green, cryptograaf en onderzoeksprofessor aan de John Hopkins Universiteit. Aangezien alleen het apparaat het UID kent, en het UID niet uit de Secure Enclave kan worden gehaald, houdt dit in dat alle pogingen om het wachtwoord te kraken op het apparaat zelf moeten worden gedaan.
Apple stelt dat het kraken van een willekeurig wachtwoord van zes karakters bestaande uit kleine letters en cijfers 5,5 jaar in beslag neemt. Een pincode kan echter al binnen een half uur worden gekraakt, aldus Green. Hij merkt op dat het dus belangrijk voor iOS-gebruikers is om een sterke passphrase te kiezen.
Volgens mij berekening zou Apple dan 1 poging doen per 12,5 seconden.
36(6) is het aantal mogelijkheden (2176782336)
5,5 jaar is ongeveer 173563087,5 seconden
2176782336\173563087,5 = 12.54 sec per poging (ongeveer)
Als deze materie je interesseert lees dan ook http://www.zdziarski.com/blog/?p=3820 en bekijk http://www.strozfriedberg.com/wp-content/uploads/2014/08/SFWP_MitigatingPairingRecordRisks_08112014.pdf waar Jonathan naar verwijst.
Bron: http://www.theregister.co.uk/2014/10/04/why_law_enforcement_is_kicking_up_a_stink_about_smartphone_encryption/
Volgens mij berekening zou Apple dan 1 poging doen per 12,5 seconden.
36(6) is het aantal mogelijkheden (2176782336)
5,5 jaar is ongeveer 173563087,5 seconden
2176782336\173563087,5 = 12.54 sec per poging (ongeveer)
Je rekent verkeerd (nou ja, interpreteert het resultaat verkeerd). Het resultaat is 12.54 pogingen per seconde.
"A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds (=12,5 pogingen per seconde). This means it would take more than 51?2 years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers."
"A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds (=12,5 pogingen per seconde). This means it would take more than 51?2 years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers."
Maar ik neem aan dat er bij deze berekening vanuit wordt gegaan dat je onbeperkt wachtwoorden mag proberen? Want als je na 5 keer proberen het toestel blokkeert gaat dit toch al mank?
Volgens mij berekening zou Apple dan 1 poging doen per 12,5 seconden.
36(6) is het aantal mogelijkheden (2176782336)
5,5 jaar is ongeveer 173563087,5 seconden
2176782336\173563087,5 = 12.54 sec per poging (ongeveer)
Ik vind het niet echt geweldig om het op de volgende manier te bekijken:
per x aantal seconden een poging, er zijn y aantal combinaties mogelijk dus duurt het xy aantal seconden (daarna nog even omzetten in jaren) om het wachtwoord te kraken. Want dan zou dus de laatste poging (combinatie) pas het correcte wachtwoord zijn, die kans is natuurlijk aanwezig maar lijkt me wel klein.
ik bekijk het dan liever op de volgende manier:
er zijn x combinaties mogelijk dus is er bij een poging x procent kans dat het correcte wachtwoord wordt ingevuld. Naarmate er meer pogingen zij geprobeerd en wordt bijgehouden welke combinaties al zijn geprobeerd neemt de kans in procenten dat bij de volgende poging het correcte wachtwoord wordt ingevuld toe (immers neemt het combinaties dat het correcte wachtwoord zou kunnen zijn, naar elke poging af tot de juiste combinatie gevonden is).
tijdens het schrijven van deze post werd de post van Anoniem 06-10-2014 18:30 uur geplaats.
wijziging 07-10-2014 13:26 uur: verbeteringen spelling fout en verbetering formulering
"A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds (=12,5 pogingen per seconde). This means it would take more than 51?2 years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers."
Maar ik neem aan dat er bij deze berekening vanuit wordt gegaan dat je onbeperkt wachtwoorden mag proberen? Want als je na 5 keer proberen het toestel blokkeert gaat dit toch al mank?
proberen, maar dan loop je dus tegen de uitgerekende limiet van 12,5 pogingen per seconde aan.
20 seconden (en gemiddeld slechts 6 minuten en 40 seconden...) Vandaar de laatste zin: "Hij (Green) merkt op dat het dus belangrijk voor iOS-gebruikers is om een sterke passphrase te kiezen."
Ok, maar ik neem aan dat als je je toestel zelf niet gejailbreakt hebt, dat dit dan dus alsnog niet opgaat? Want ik neem aan dat iemand die je toestel dan 'steelt' het ook niet zomaar kan jailbreaken?
Bedoelt de 'prof' dan ook niet dat vooral mensen die hun iPhone hebben gejailbreakt een sterk wachtwoord moeten kiezen?
Ok, maar ik neem aan dat als je je toestel zelf niet gejailbreakt hebt, dat dit dan dus alsnog niet opgaat? Want ik neem aan dat iemand die je toestel dan 'steelt' het ook niet zomaar kan jailbreaken?
Weet ik niet precies. Waarschijnlijk niet "zomaar", maar met bepaalde kennis/hulpmiddelen wel. (forensische instituten die de boel soms openhalen en in de hardware zitten te peaken en te poken weten vast meer). En misschien kun je ook niet helemaal uitsluiten dat een kwaadwillende op afstand de applicatieprocessor eens kan compromitteren via bijv. een onbedoelde security hole, en zo de jailbreak installeert??? Tegenwoordig moet je overal maar rekening mee houden.
Er worden altijd weer nieuwe wegen gevonden. Sterk wachtwoord en encryptie zijn dan je laatste redmiddelen. (-; of juist niet, als hierdoor bijv. een forensisch instituut geen informatie kan verkrijgen over waar je mogelijk gegijzeld bent... ;-)
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
