Apple Is Said to Be Working on an iPhone Even It Can’t Hack • Hacker News Board

Re: Apple Is Said to Be Working on an iPhone Even It Can’t Hack

#251

Post by cheepin » Thu, Feb 25, 2016, 7:45 AM UTC

frankacter wrote: post #213

drewcrawford wrote: post #201

Earlier quoted context omitted.

The real lynchpin here is not hardware, but iCloud. Apple can pull data out of an iCloud backup, and the only reason the San Bernadino case even got off the ground is because somebody at the county screwed up and effectively prevented the backup from occurring. iCloud backups can be secured so not even Apple can get in them, but it is fundamentally much harder to secure (can't be hareware-entangled and still restore…

> Farook disabled the iCloud backup six weeks prior to the attack http://6abc.com/news/senior-official-stresses-feds-need-to-u...

They did not even attempt to get it to send a fresh backup to iCloud before they reset it making it impossible.

[0] http://daringfireball.net/2016/02/san_bernardino_password_re...

Re: Apple Is Said to Be Working on an iPhone Even It Can’t Hack

#252

Post by tajen » Thu, Feb 25, 2016, 7:50 AM UTC

tptacek wrote: post #2

They're presumably already 99% of the way there. If the Secure Enclave can be updated on a locked phone, all they need to do is stop allowing that, right? To me, the more profound consideration is this: if you use a strong alphanumeric password to unlock your phone, there is nothing Apple has been able to do for many years to unlock your phone. The AES-XTS key that protects data on the device is derived from your pas…

I don't understand the whole debate about Apple security:

- Apple is required to have backdoors, at least on iPhones sold in foreign countries, isn't it?

- Even if the SE were completely secure, a rogue update of iOS could intercept the fingerprint or passcode whenever it is typed, and replay it to unlock the SE when spies ask for it. As far as I know, the on-screen keyboard is controlled by software which isn't in the SE.

- Even if iCloud is supposed to be encrypted, they didn't open up that part to public scutinity.

- Therefore a perfect security around the SE only solves the problem of accessing a phone that wasn't backdoored yet. There are all reasons for, say, Europe and CIA, to require phones to be backdoored by default for LE and economic intelligence purposes.

Re: Apple Is Said to Be Working on an iPhone Even It Can’t Hack

#253

Post by rimantas » Thu, Feb 25, 2016, 8:02 AM UTC

teacup50 wrote: post #103

TazeTSchnitzel wrote: post #90

Earlier quoted context omitted.

> Good. Congress shall pass no law abridging freedom of speech, and code has been ruled free speech. Unless it breaks DRM!

Which, ironically, is exactly what Apple is protecting here. DRM.

DRM for your own data is called privacy.

Re: Apple Is Said to Be Working on an iPhone Even It Can’t Hack

#254

Post by amatix » Thu, Feb 25, 2016, 8:03 AM UTC

skeptic123123 wrote: post #245

drewcrawford wrote: post #201

Earlier quoted context omitted.

The real lynchpin here is not hardware, but iCloud. Apple can pull data out of an iCloud backup, and the only reason the San Bernadino case even got off the ground is because somebody at the county screwed up and effectively prevented the backup from occurring. iCloud backups can be secured so not even Apple can get in them, but it is fundamentally much harder to secure (can't be hareware-entangled and still restore…

call me a cynic, but I'm not buying "somebody at the county screwed up"

Indeed, "The County was working cooperatively with the FBI when it reset the iCloud password at the FBI's request." https://twitter.com/CountyWire/status/700887823482630144

Re: Apple Is Said to Be Working on an iPhone Even It Can’t Hack

#255

Post by lololomg » Thu, Feb 25, 2016, 8:04 AM UTC

tajen wrote: post #252

tptacek wrote: post #2

They're presumably already 99% of the way there. If the Secure Enclave can be updated on a locked phone, all they need to do is stop allowing that, right? To me, the more profound consideration is this: if you use a strong alphanumeric password to unlock your phone, there is nothing Apple has been able to do for many years to unlock your phone. The AES-XTS key that protects data on the device is derived from your pas…

I don't understand the whole debate about Apple security: - Apple is required to have backdoors, at least on iPhones sold in foreign countries, isn't it? - Even if the SE were completely secure, a rogue update of iOS could intercept the fingerprint or passcode whenever it is typed, and replay it to unlock the SE when spies ask for it. As far as I know, the on-screen keyboard is controlled by software which isn't in t…

Apple is not required by any country to have a backdoor and I am not aware of any agreement from Apple to install such a back door for anyone

Re: Apple Is Said to Be Working on an iPhone Even It Can’t Hack

#256

Post by MertsA » Thu, Feb 25, 2016, 8:06 AM UTC

thomaspurchas wrote: post #124

cromwellian wrote: post #64

Earlier quoted context omitted.

No, the chief protection against the PIN code hacking comes from the retry counter. The FBI doesn't need the crypto keys, it just needs the PIN code. So it needs to brute force about 10,000 PIN codes. Any mechanism that prevents the application processor from either a) remembering it incremented the count b) corrupts the count or c) patches the logic that handles a retry count of 10, is sufficient to attack the phone…

You seem to make the assumption that corrupting the secure enclave firmware is easy, or that its RAM is exposed of chip. The entire point of an secure enclave is to completely enclose all the hardware and software needed to generate encryption keys in a single lump of silicon. This means that all of its processing requirements (it's a complete co-processor) are on chip, it's RAM is on chip (not shared with it the mai…

>it's RAM is on chip (not shared with it the main CPU, and probably has ECC)

Apple's security guide would indicate otherwise, look on page 7. The secure enclave encrypts its portion of memory, but it isn't built into the secure enclave itself.

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Re: Apple Is Said to Be Working on an iPhone Even It Can’t Hack

#257

Post by amatix » Thu, Feb 25, 2016, 8:09 AM UTC

schoen wrote: post #200

ghshephard wrote: post #184

Earlier quoted context omitted.

" they don't obviously get to impose penal sanctions on people for saying no" I wonder if there is any negative effects associated with being refused entry by a CBP? Could it be the case that if you are refused entry once, that in the future they will be more likely to refuse you entry? If so, that's a fairly significant penalty/power that the CBP person has.

> I wonder if there is any negative effects associated with being refused entry by a CBP? Could it be the case that if you are refused entry once, that in the future they will be more likely to refuse you entry? If so, that's a fairly significant penalty/power that the CBP person has. Yes, some categories of non-citizen visitors (I don't remember which) are asked on the form if they have ever been refused entry to th…

Plenty of countries will ask if you've ever been refused entry to any country. And you're also generally automatically excluded from any Visa Waiver Programme from then on too. So it's a major issue.

Re: Apple Is Said to Be Working on an iPhone Even It Can’t Hack

#258

Post by MertsA » Thu, Feb 25, 2016, 8:11 AM UTC

jfoster wrote: post #250

tptacek wrote: post #180

Earlier quoted context omitted.

It's encrypted against an effectively random 128 bit AES key. Unlimited time is not enough.

The method I'm thinking of is: 1. Get a dump of the encrypted data. 2. Try to probe the hardware, potentially destroying it. 3. If the probe works, we're done. If not, put the encrypted data dump onto a fresh iPhone and repeat from step 2. This way, you effectively get unlimited shots at an otherwise risky hardware probe.

If the encryption key didn't depend on the hardware this would work. Even the iPhone 5C that the recent court case is about relies on the hardware keeping a key secret and it doesn't contain the secure enclave. For an iPhone 5C, the encryption key is derived from the pin and a unique ID for the phone that the CPU itself can't read. The only thing that the application processor can do is perform some crypto instructions using the key, there isn't an operation that would just put the key into memory or a register that you can read from. Even if you have root and the phone in front of you with the password, there's nothing you can do short of decapping it to try to identify that key.

Re: Apple Is Said to Be Working on an iPhone Even It Can’t Hack

#259

Post by [deleted] » Thu, Feb 25, 2016, 8:19 AM UTC

[deleted]

Re: Apple Is Said to Be Working on an iPhone Even It Can’t Hack

#260

Post by Piskvorrr » Thu, Feb 25, 2016, 8:22 AM UTC

cromwellian wrote: post #196

gruez wrote: post #120

Earlier quoted context omitted.

>You may not need to crack the OS, or even upload a new firmware. You just need to disable the mechanism that wipes the device and delays how many wrong tries you get. So for example, if you can manage to corrupt, or patch the part of the system that does that, then you can try thousands of PINs without worrying about triggering the timer or wipe, and without needing to upload a whole new firmware. I disagree. The pi…

The state representing the number of attempts must be stored somewhere, and thus a determined adversary could eventually corrupt it. Look, there's a big difference between trusting known ciphers that have been well studied by the world's top cryptographers, and a proprietary TPM chip that relies on security-through-obscurity. The history of embedding secrets into black boxes is a history of them being broken. This is…

Kerckhoff's principle should be adhered to if truly secure encryption is desired; alas, then all sorts of hard obstacles pop up (UX becomes a SPOF, most commonly - a secret always needs to be stored somewhere, if only in the user's head).

OTOH, the practical purpose of encryption is to remain unbroken for long enough, not to be completely unbreakable. As seen here, security-through-obscurity is practical enough in cases where user-obtained key material is too weak to provide enough protection using strong publicized crypto. In other words, it's a two-part key: one is in user's wetware, the other in phone's hardware (as per obXKCD, it's usually easier to attack the former).