←back to thread

596 points pimterry | 1 comments | | HN request time: 0s | source
Show context
willcipriano ◴[] No.36862717[source]
Why can't you fake remote attestation? I imagine it's a bit more involved than swapping a user agent but is there some magic mechanism that makes it impossible to spoof?
replies(6): >>36862781 #>>36862809 #>>36862813 #>>36863035 #>>36863106 #>>36871239 #
mike_hearn ◴[] No.36863035[source]
The token received by the server contains information about your platform albeit not very much beyond "it's an Apple device and we think it's enforcing normal security rules".

Why can't you forge the token? Because it's digitally signed.

Why can't you generate a token for your own website, and then "replay it" to another? Because the token embeds the "challenge" which is random numbers selected by the server. The server compares the challenge in the token with the one it generated, usually it will statelessly hash something about the client connection like a cookie. So you can't just substitute a token from one site for another.

Why can't you generate a token for the real intended site but then grab it out of a real iPhone? Because the iPhone has good security which will stop you from doing that (equivalent to jailbreaking it).

How is the token digitally signed? By (in this scheme) Apple, so we can assume you will find it hard to steal their server side keys.

When do Apple digitally sign such a token? When you present a pile of data to their servers.

What's in that data? Unknown as it's (probably) encrypted, but most likely it is various version numbers and device IDs. At the very least it can change at will. Also, it's going to be signed by a device specific key pair. The device generates the private key on first boot at the factory and that key never leaves the device. Apple record the matching public key. So, now they can identify when a the data pile comes from a real device. Also if someone successfully steals the private key from a device, it can be revoked by Apple server side.

Real RA schemes are more complicated than that usually for privacy and anti-tracking reasons. What's outlined above is a generic, textbook implementation.

So to recap: you can't steal a token because the device's security won't let you, you can't steal the private key you need to get a token because there's no way to extract it from the hardware at all (short of putting the chips under a SEM), and you can't swap one token for another because of the challenge.

replies(3): >>36863183 #>>36865188 #>>36868313 #
Steltek ◴[] No.36868313[source]
> Why can't you generate a token for your own website, and then "replay it" to another? Because the token embeds the "challenge" which is random numbers selected by the server. The server compares the challenge in the token with the one it generated, usually it will statelessly hash something about the client connection like a cookie. So you can't just substitute a token from one site for another.

Your fake iPhone could talk to a cooperating server which presents the same challenge to a real iPhone. In fact, a service could accept challenges, instruct a friendly iPhone to request `/?code=$foo`, then return the friendly's iPhone token to the original client.

replies(1): >>36874203 #
1. mike_hearn ◴[] No.36874203[source]
The challenge includes the origin and all communication is protected by TLS. I don't know what happens if you add extra trusted root certificates to do MITM attacks, but in principle nothing stops the root store being a part of the remote attestation.