Apple's response to the US Government

so first, Bill Gates utters the opinion that Apple should unlock the phone.

But now, Microsoft stands "wholeheartedly" behind Apple.

http://www.seattletimes.com/business/technology/microsoft-takes-apples-side-in-iphone-dispute-with-fbi/

 

also, if you wanna see Tim Cook pissed:

http://abcnews.go.com/Technology/exclusive-apple-ceo-tim-cook-iphone-cracking-software/story?id=37173343

https://youtu.be/MG0bAaK7p9s

  On 3/1/2016 at 4:40 PM, Nebraska said:

https://youtu.be/MG0bAaK7p9s

 

Something seems off here..

Is he suggesting that the data is not encrypted on the phone, only the password for entry? Because once I shut down my LUKS/dm-crypt drive on this machine anything in RAM empties I think it would be very difficult for this to work. At this point the entire block on my drive is just one big stream of randomness..

Good luck picking apart that mess John. You can clone my drive and throw a thousand supercomputers at it but are not going to make sense of anything without the (very long) key in my brain..

 

Granted I have very little knowledge of the complex scheme Apple uses on their IOS devices. Maybe they fucked it up

  On 3/1/2016 at 5:03 PM, maitake said:

 

Something seems off here..

Is he suggesting that the data is not encrypted on the phone, only the password for entry?

 

 

he's suggesting there is a simple key loader that holds the code to unlock any encrypted message assuming the message was loaded onto the skl. the fbi wants this code because it wants to be able to remotely hack any iphone without physically having the iphone

Edited March 1, 2016 by Nebraska

Reading this thread makes me realize I know absolutely nothing about computers

this entire encryption stuff is pretty convoluted though & even most programmers don't know jack shit about it (I know I don't)

  On 3/1/2016 at 6:45 PM, phling said:

this entire encryption stuff is pretty convoluted though & even most programmers don't know jack shit about it (I know I don't)

Yeah having a quick look it seems pretty strong - A unique (to each iphone) AES-256 decryption key combined with SHA-1 hash (presumably that hash is generated from the user passcode), and that key is called *every* time a file is accessed. So even getting hold of a phone and somehow just bypassing the log in screen and dumping all the data to another device would still result in completely encrypted/unreadable data

  On 3/1/2016 at 6:54 PM, mcbpete said:

Yeah having a quick look it seems pretty strong - A unique (to each iphone) AES-256 decryption key combined with SHA-1 hash (presumably that hash is generated from the user passcode), and that key is called *every* time a file is accessed. So even getting hold of a phone and somehow just bypassing the log in screen and dumping all the data to another device would still result in completely encrypted/unreadable data

Just a quick note on SHA-1 from the year 2005 by Mr. Schneier:

 

https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

Yeah I'm not 100% up on cryptography shenanigans (cryptonanigans ?) though knew SHA wasn't seen as super strong. Was thinking though that SHA together with AES made the AES bit of it even harder to crack - As I say I'm not very knowledgeable about what happens when you combine two encryption types together !

AES 256 with a strong passphrase should be sufficient on it's own. That the passphrase is hashed by SHA 1 and combined with a unique AES 256 key is just icing on the cake. SHA 1 itself is only a one-way hashing algorithm.

 

Reading through here is pretty fascinating: https://www.apple.com/business/docs/iOS_Security_Guide.pdf

They definitely went far beyond just simple AES 256 with hardware baked key and a hashed pass. There's two random number generators, one in a software layer and another actually baked into the Secure Enclave (part of the processor that handles the hardware encryption).

 

Don't have the time to study it much but there's more keys than just a per-file AES256 key and the SHA1 hash. Files are also assigned "class keys" and the metadata itself also receives randomly generated unique per-file key that combines with a filesystem key and other keys to decrypt user data.

 

 

SO! In essence:
The hardware key and password are needed with a class key and the filesystem key, which decrypts a file's metadata and unlocks it's file key. Every aforementioned key combined is required to be correct in order for any single file to be decrypted. The class key serves as a switch that tells iOS how to handle the encryption of different kinds of files.. (???)

 

When a user wipes their data and settings, it's actually yet another random key is required to decrypt the entire filesystem's metadata. This key isn't used to secure the data, but itself is critical for opening the data. Once it's gone it renders anything previously readable non-existent. I believe this key is the one that the FBI were worried would render the device useless if they were to attempt brute force cracking.

 

I probably just murdered the process in my description.. Hopefully it helps even if not entirely accurate.

The consensus i'm getting is that the iphone is now a fucking nightmare to crack by any conventional means, and honestly i'm starting to question whether John knows wtf he's talking about. Apple engineers put the sensitive bits 3,000 feet deep in the enclave and the ONLY means of getting anything tangible out of there is through it's hardware AES engine.

 

I have not looked at the SKL that nebraska posted yet. Probably will in the morning

Edited March 2, 2016 by maitake

Secure enclave not part of the encryption process in the iPhone 5c (the phone in question).

Oops! Total misfire, my bad.

Need to find another paper I guess.. lol

Hmm... Without secure enclave all crypto algorithms are implemented in the software layers. Same applies: the pass is hashed and combined with the hardware key to create an file encryption key.

 

Even without secure enclave this is still a big problem because you can only test against the hardware key every 80 ms (fact check me here??), and it must take place on the physical device and not in the software layer. Considering the hardware key itself is AES 256 generated, good luck cracking that bad boy. Best chance would be to parallelize the operation somehow and even then you're looking at lifetimes..

 

Electron microscopes, pcb xray.. there's a lot of suggestions floating around on the net. Really grasping at straws here.

 

It appears that the FBI could get in with Apple's help.. on the 5c anyway.

Edited March 2, 2016 by maitake

  On 3/1/2016 at 8:31 PM, Psychotronic said:

 

  On 3/1/2016 at 6:54 PM, mcbpete said:

Yeah having a quick look it seems pretty strong - A unique (to each iphone) AES-256 decryption key combined with SHA-1 hash (presumably that hash is generated from the user passcode), and that key is called *every* time a file is accessed. So even getting hold of a phone and somehow just bypassing the log in screen and dumping all the data to another device would still result in completely encrypted/unreadable data

Just a quick note on SHA-1 from the year 2005 by Mr. Schneier:

 

https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

 

 

Nice source, good info. Thanks!

seems to me that everyone is maybe being a bit dishonest here.

a) apple claims the gov wants them to install backdoors which would allow them to break into all phones

b) apple claims that if they could have cracked this one phone, they would have

c) apple says that if they do install back doors allowing the gov to get into this phone, it would allow them to get into all phones and the gov would abuse that

 

maybe i'm misrepresenting one of those points? seems like i've seen these statements made. seems to me that b and c contradict each other. how do you install a back door after the fact? and if you could do that, wouldn't that fall under the heading of cracking the phone you said you couldn't crack? my understand is that the backdoor only works because it was put in place before the encryption was used. i don't see how you can even call it a back door if it's something used to crack encryption that was made without that back door there in the first place. seems to me like at that point youre just cracking it somehow. the fact that apple's statements seem to suggest that they could in fact do that, make me trust them about as much as i do the fbi.

You are correct E. It is not possible to implement a backdoor in the pre-existing phones.

The FBI is asking for revision to iOS firmware that will be installed on future phones, with a backdoor.

Apple can not (sortof, see ahead...) decrypt this phone themselves either. The only thing they can do is replace the firmware with a custom image. This will allow you to boot the phone into iOS (by bypassing the lockscreen mechanism) and all will be fine and dandy EXCEPT: to actually read any user data you need both the passphrase AND the baked-in hardware key. This is very difficult, if not impossible to crack by brute forcing the passphrase over and over. The difficulty depends on whether Sayeed was using a longer passphrase or the bullshit 4 and 6 digit pins. If it's the latter, and Apple is willing to cooperate with the FBI by implementing features in the software that make it easier for the FBI to test pins/passwords, they have a good shot at decrypting the phone. A strong passphrase will defeat their efforts though.

Edited March 2, 2016 by maitake

  On 3/1/2016 at 5:14 PM, Nebraska said:

 

  On 3/1/2016 at 5:03 PM, maitake said:

 

Something seems off here..

Is he suggesting that the data is not encrypted on the phone, only the password for entry?

 

 

he's suggesting there is a simple key loader that holds the code to unlock any encrypted message assuming the message was loaded onto the skl. the fbi wants this code because it wants to be able to remotely hack any iphone without physically having the iphone

 

 

I can't find any evidence of a simple key loader on the iphone hardware nor one that would work without having the hardware key found in the A6 processor. Of course, the encryption engine itself is analogous to a key loader. It uses a key(s) to decrypt and encrypt, just a like a key loader. I guess in theory if the hardware key was known it could be placed on the keyloader and then suddenly that device could decrypt remotely. The military uses the SKL to encrypt and decrypt information, but they already have/know the key that will be placed on the SKL to begin with. What makes iOS security strong is that NO ONE has access to that damned hardware key.

 

Apple engineers were not playing around with this stuff and if you read more into it you will find out that John has absolutely no idea what he's talking about in that video. John thinks a software engineer is going to sit down in a half hour, dissemble the machine language, then read it's million+ lines of code to find where pins are entered? Even if this did work (and didn't take 2 years), you're not going to find the passphrase in any form that's worth something. Devices do not store the pass in storage, they only store the hash. It's one way for a reason.. ;)

Edited March 2, 2016 by maitake

In short: this is not a pr stunt. Imo.

  On 3/2/2016 at 6:43 AM, goDel said:

In short: this is not a pr stunt. Imo.

 

Exactly. The FBI genuinely needs Apple's help to brute force (the only viable option besides decapping with acid and lasers) the phone. Apple isn't lying when they say that facilitating this process is difficult and will take effort of their own to rewrite iOS firmware. Otherwise the FBI is stuck testing passes every 80 ms.

 

Also (I know I won't shut up, sorry) I want to clear up a misconception i keep seeing over and over and over and over and over again in comments and on sites discussing this:

 

To bypass the lockscreen pin/passphrase mechanism is completely beside the point. Even if they could clone the iphone hardware (can't) and rewrote the firmware to just skip the shit altogether, the user data is still complete gibberish without the passphrase hash and -> the very very, unique hardware key <-.

O, it's very ok to not shut up and fill the thread with technical chinese about encryption and all that. If John McAffee can prove he doesn't know what he's talking about on national TV, you're very much entitled to put your cents in this thread. And welcome, imo.

 

Besides the technical aspects, I think neither party is served with bringing this discussion into the media and into court. I understand people's cynicism, but either party risks loosing way more than they could possibly win by having this discussion in the public eye.

  On 3/2/2016 at 7:21 AM, goDel said:

If John McAffee can prove he doesn't know what he's talking about on national TV, you're very much entitled to put your cents in this thread.

It could well be he *does* know what he's talking about, it's just the way he described it on the video above was the same way that pirates circumvented the simple password protection scheme you got in games in the late 80s/early 90s basically -

 

If the disassembler shows the code being this:

 

  Quote

Start: Boot game

Password: Request password

If (password correct) jmp Game:

Else (error screen)

jmp Password:

Game: Game code executes....

Then just insert an instruction:

 

  Quote

Start: Boot game

jmp Game: (therefore bypassing all the passwordy bits)

// (gets ignored) Password: Request password

// (gets ignored) If (password correct) jmp Game:

// (gets ignored) Else (error screen)

// (gets ignored) jmp Password:

Game: Game code executes....

Unfortunately (or fortunately depending on whether you're the cracker or author!) it's been considerably more complex since those days

yeah i think its relevant that he is running for president mainly on a vehicle of him being good for cybersecurity, while going on tv saying he could hack this phone in a half hour

  On 3/2/2016 at 6:17 AM, maitake said:

I can't find any evidence of a simple key loader on the iphone hardware nor one that would work without having the hardware key found in the A6 processor. Of course, the encryption engine itself is analogous to a key loader.

 

 

perhaps you're right. according to this technical autopsy, the encryption key for the iphone 5c is stored between the flash memory and system area. either way, a new york judge ruled that the government can't force apple to unlock the iphone.

  On 3/3/2016 at 2:02 AM, Nebraska said:

 

  On 3/2/2016 at 6:17 AM, maitake said:

I can't find any evidence of a simple key loader on the iphone hardware nor one that would work without having the hardware key found in the A6 processor. Of course, the encryption engine itself is analogous to a key loader.

 

 

perhaps you're right. according to this technical autopsy, the encryption key for the iphone 5c is stored between the flash memory and system area. either way, a new york judge ruled that the government can't force apple to unlock the iphone.

 

 

Yeah, that damn hardware key is the hangup. It did occur to me last night though that it is VERY likely that this man (like the vast majority of people with these phones) is NOT using a strong passphrase, and instead only had the 4 or 6 digit pin entry active. Brute forcing the phone with Apple's help would have been quite easy for them.

 

Thanks for the link. That write up is much better than anything I was able to dig up besides the iOS security guide. My knowledge of cryptography and especially hardware encryption is fairly limited, so i was hoping that my summary didn't turn into bullshit.

Edited March 3, 2016 by maitake