Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

techdirt.com

Post reply on HN
Print view View original

11–20 of 364 posts

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#11

Post by tptacek »

ars wrote: post #2

> Apple ... will probably have little time to debug or test it overall, meaning that this feature it is being ordered to build will almost certainly put more users at risk. Eh? They are not being asked to install it to the public at large, just one phone. Of all reasons to object, this reason makes little sense.

That's true. In fact, if it's possible for Apple to accomplish what DOJ is demanding of it, the best outcome would be for DOJ to succeed, and do so publicly:

* There is an authentic need to get at the data on that phone

* There's no likelihood at all that other users will be impacted by the backdoor

* We'll all be on the same page about how secure these phones are versus the USG.

It's possible that they can prevail against the 5C but not against the 5S or later, since the security architecture of the 5S is very different from that of the 5C.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#12

Post by randyrand »

tptacek wrote: post #4

Remember, this is an iPhone 5C, which doesn't have Touch ID or the Secure Enclave; the security model for this phone is significantly different from that of more recent iPhones. On phones with a Secure Enclave, the wipe-on-failures state is managed in the coprocessor (which runs L4), and is not straightforwardly backdoor-able. If you're worried about the police brute-forcing your phone, enable Touch ID and set a pass…

Even if touch id, it would be of no use. TouchID requires a password after 48 hours. or after the device resets.

Which is interesting. If you happen to use TouchID, is your best bet to hope a court will not be able to compel you to unlock it within 48 hours of arrest? That sounds very probable.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#13

Post by ggreer »

randyrand wrote: post #12
tptacek wrote: post #4

Remember, this is an iPhone 5C, which doesn't have Touch ID or the Secure Enclave; the security model for this phone is significantly different from that of more recent iPhones. On phones with a Secure Enclave, the wipe-on-failures state is managed in the coprocessor (which runs L4), and is not straightforwardly backdoor-able. If you're worried about the police brute-forcing your phone, enable Touch ID and set a pass…

Even if touch id, it would be of no use. TouchID requires a password after 48 hours. or after the device resets. Which is interesting. If you happen to use TouchID, is your best bet to hope a court will not be able to compel you to unlock it within 48 hours of arrest? That sounds very probable.

After five failed fingerprint attempts, your password is required to unlock the phone. That seems pretty safe to me. If you're ever ordered to unlock the phone, just touch an unregistered finger to it. Fingerprint sensors aren't foolproof. It'd be hard to prove you deliberately sabotaged the effort.

Though, one feature I'd like would be to register a distress fingerprint. Then I could touch say... my left index finger to require a password unlock.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#14

Post by some_guy_there »

ggreer wrote: post #8
some_guy_there wrote: post #6

Earlier quoted context omitted.

Wouldn't Apple (or the manufacturer) know the key of the security enclave?

No. From Apple's iOS security guide[1]: > The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor and Secure Enclave during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed by dedicated AES engines implemented in silicon using the UID or GID as…

Thanks. So only recourse for highly resourced adversary will be to decode key via hardware imaging (not sure if any research has been done on this), and after that they will still have to bruteforce the passphrase used to secure the phone, the effectiveness of which depends on the entropy of passphrase.

I wonder what how Apple can help the law enforcement here.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#15

Post by akiselev »

some_guy_there wrote: post #14
ggreer wrote: post #8

Earlier quoted context omitted.

No. From Apple's iOS security guide[1]: > The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor and Secure Enclave during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed by dedicated AES engines implemented in silicon using the UID or GID as…

Thanks. So only recourse for highly resourced adversary will be to decode key via hardware imaging (not sure if any research has been done on this), and after that they will still have to bruteforce the passphrase used to secure the phone, the effectiveness of which depends on the entropy of passphrase. I wonder what how Apple can help the law enforcement here.

A lot of research has gone into information recovery from silicon inspection since it's tied closely to reverse engineering ICs. It's not the most trivial of pursuits but widely done.

There are some hardware HMACs (Atmel's in particular IIRC) where the process of opening the chip package destroys the area of silicon that encodes the private keys. I don't know if Apple used the same tech but if they did, any attempt to look at the private key storage would destroy it.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#17

Post by stephentmcm »

randyrand wrote: post #12
tptacek wrote: post #4

Remember, this is an iPhone 5C, which doesn't have Touch ID or the Secure Enclave; the security model for this phone is significantly different from that of more recent iPhones. On phones with a Secure Enclave, the wipe-on-failures state is managed in the coprocessor (which runs L4), and is not straightforwardly backdoor-able. If you're worried about the police brute-forcing your phone, enable Touch ID and set a pass…

Even if touch id, it would be of no use. TouchID requires a password after 48 hours. or after the device resets. Which is interesting. If you happen to use TouchID, is your best bet to hope a court will not be able to compel you to unlock it within 48 hours of arrest? That sounds very probable.

I don't know about that but I'd be fairly certain a court would just order you to unlock the phone regardless of whether it's your finger locking it or a password.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#18

Post by yarou »

They're effectively asking for a backdoor, plain and simple. I'd be highly surprised if Apple complied with this court order.

Even if they removed said feature, the only way to decrypt the FS would be if and only if the owner had a weak strength passcode.

Can somebody explain to me how this warrant is not a direct violation of this individual's 4th amendment rights?

This seems like yet another case where the rights guaranteed by the Constitution are selectively applied based on your skin color.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#19

Post by Mandatum »

kevinastone wrote: post #16

Why wouldn't the FBI just clone the phone disk contents and crack the encryption on more dedicated systems?

Are there tools to dump and resume iPhone/Android states? Could easily dump state, null "tryCounter++", and resume cracking?

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#20

Post by jack9 »

yarou wrote: post #18

They're effectively asking for a backdoor, plain and simple. I'd be highly surprised if Apple complied with this court order. Even if they removed said feature, the only way to decrypt the FS would be if and only if the owner had a weak strength passcode. Can somebody explain to me how this warrant is not a direct violation of this individual's 4th amendment rights? This seems like yet another case where the rights g…

> Can somebody explain to me how this warrant is not a direct violation of this individual's 4th amendment rights?

The person is dead and it's reasonable and the 4th isn't even applicable (depending on the interpretation of "make a backdoor in a product" as opposed to "we're looking at someone's data they own on a device they own"). Even the very liberal interpretation of the 4th doesn't apply here, when the right violation would be the act of accessing the data, not just asking to have a way to look at it.

Techdirt is full of fiction by design, so I'm not surprised by the confusion.

Post reply on HN