Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

They want the authority to search phones incident to arrest. Before you form an opinion about this --- I'm not sure what mine is --- you should know that the police have always had broad authority to conduct warrantless, intrusive searches at the time of an actual arrest. That's one of the things that makes arrest very different from mere detention.

If you're arrested by the police, they will not generally need to obtain a warrant to search your person, your pockets, your bag, or the passenger compartment of your car. Thoroughly.

People confuse "search incident to arrest" with "Terry stops", which are light, supposedly unintrusive searches that can be conducted without individualized suspicion for purposes of officer safety (ie, for weapons). Terry stops are the ones where, supposedly, the police aren't supposed to be reaching into your pocket. Search incident to arrest, going back over 100 years, has always had a purpose of discovering and preserving evidence; they aren't simply about officer safety.

That said: a modern smart phone is more than just a container you carry on your person. It can provide access to much of the same personal information that a search of your most personal possessions would. It's a totally reasonable question as to whether an intrusive search of the data on a smartphone falls into the rubrick of what search incident to arrest was meant to cover.

Either way: make sure your phone is encrypted.

>the police have always had broad authority to conduct warrantless, intrusive searches at the time of an actual arrest.

Only insofar as needed to protect the arresting officer from harm or to prevent the destruction of evidence.[1]

[1] http://en.wikipedia.org/wiki/Arizona_v._Gant

This case pertains only to the search of vehicles, and, as you can see, "to prevent the destruction of evidence" is essentially carte blanche.

Interestingly, search incident to arrest might not allow the police to search a vehicle's trunk.

You generally cannot search a vehicle's trunk under search incident to arrest. However, you can impound the vehicle during the arrest, at which point it is subject to an inventory search, without violating the Fourth Amendment.

And the police have (overly) broad discretion in conducting inventory searches, which are also practically carte blanche. However, there are limits; for instance, evidence from a video tape viewed by police during one such search was thrown out.

Very interesting. I'd love to read the case on the video tape admissibility. Do you remember the name, or have any information about it?

Edit: Can't find the case, but the rationale according to a secondary source is "The search was invalid because the viewing of the tape was unnecessary to ensure its return to the defendant and it did not further any valid objective of an inventory search."

So the rationale hangs on the definition of the "valid objectives" of an inventory search. The "objectives [of an inventory search are] preserving the property of the defendant, shielding the police against claims of lost property, and protecting the police and others from any dangerous objects.

Either way: make sure your phone is encrypted

> What is to stop them from compelling your PW?

> Is the 5th amendment sufficiently broad to invoke here for blanket protection?

The current precedent seems to indicate that no one can make you reveal your passwords. ASFAIK, the EFF was fighting a similar case on these grounds.

IANAL, but the "search incident to arrest," for all its broad powers, still doesn't reach the strength of what a court can compel you to do.

During arrest, you have the right to remain silent.

It's a good question, but legalisms aside, having your phone securely encrypted with a strong passcode gives you much more control over whether your phone is going to be decrypted.

Even if there's a circumstance in which the police can compel you to decrypt your phone, you're virtually certain to be able to have your attorney present when that happens.

How do you encrypt your phone?

On iOS, it is by default (actually, you can't turn it off). The random key used is protected by your passcode. A good 80% solution is to use an 8+ character numeric passcode, or a 6+ character alpha passcode.

Apple can turn off the "try ten times and erase phone" feature, but it still can't brute force faster than ~8 tries per second on a 5S. You might also want to turn off the "apple key escrow" feature.

> but it still can't brute force faster than ~8 tries per second on a 5S

Yes you can. You image the phone and brute force in parallel.

Edit: thanks for letting me know this information is wrong!

If that works, then something is incredibly broken...

The encryption key, just some random 256-bits, is protected by the rate-limited HSM, which can be unlocked by the passcode. Imaging the flash of another phone with the ciphertext is futile, because that other phone has neither the same key or passcode hash in it's HSM. A different HSM wouldn't be able to decrypt the ciphertext even given the correct passcode.

The whole point of the HSM is that pulling the key or the passcode hash out of it should be quite difficult... certainly not as easy as imaging the phone!

Right; that's the difference between Apple's hardware and (almost all) Android phones right now -- a dedicated hardware security element. Blackberry has this, too. Old Windows Phone didn't; I'm not sure if WP8 does. It was broken pre-iPad 2/iPhone 4S, though.

Apple claims that the KDF uses salt fabricated into secure conclave in the CPU. You cannot realistically bruteforce password outside the device since you don't know high-entropy salt. So you have to type in pin code by hand and have your phone erased after N times.

The Apple encryption specification claims to use a combination of:

A)The encryption key burned into the chip's internal HSM

B)A randomly generated encryption key in effaceable storage

C)The user's passcode

Each passcode attempt is protected by 250,000 rounds of some key stretching function (can't remember what exactly) using the device's internal crypto acceleration hardware.

To successfully parallelize an attack on an iPhone's passcode, you would have to A) get the key out of effaceable storage (can probably be done with a root 0day) and B) extract the HSM's burned-in crypto key (would require a decapping or maybe differential power analysis).

And even then, you're still stuck with a few hundred thousand rounds of hashing per try, which is pretty brutal.

A link to said spec / whitepaper (it's quite informative!): http://images.apple.com/ipad/business/docs/iOS_Security_Feb1...

Stock android: settings - security - encrypt phone (or encrypt device)

http://www.makeuseof.com/tag/how-to-encrypt-data-on-your-sma...

That article doesn‘t provide the proper caveat to enabling the erase data option for passcode lock on iphone. It's obviously dangerous if your phone data isn't continuously backed up.

Reply on news.ycombinator.com