Apple already shipped attestation on the web, and we barely noticed

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?

On Intel & similar platforms, some forms of attestation are bidirectional. There is both a remote server attesting to the code's validity and the local device is able to attest that the code is ran in a manner that doesn't permit the user to modify or inspect it. This is the basis of almost all practical DRM methods and is provided under the guise of the Trusted Platform Module.

One interesting application of this kind of technology was to remove the 'analog hole'. When playing protected content, even the video stream from your PC to your monitor is actually encrypted in a manner that ostensibly prevents anyone from interecepting it.

Maybe not impossible but my understanding is the TPM and the closed source nature of the system level code will make it difficult enough that 99% of users will not be able to do it, which is what industry wants. They're never worried about diehards and hermits. Those people will be confined to their caves & made irrelevant.

Keys sealed in hardware from the factory. SafetyNet already does this on Android from boot up to apps (that use it, which includes shit like McDonalds...). This would extend it potentially up until a website itself.

Really powerful and useful if you need strong integrity. Really really painful if you want full(er) control over your device.

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.

> Why can't you fake remote attestation?

I don't know. There have been farms of iPhones overseas, connected over residential-exiting VPNs in the USA, with warm iCloud accounts, for ages. There is nothing magical about having to own an iPhone in order to bot farm.

Giant social media companies are reacting to slowing growth & customer concerns in the ad market, they don't have a secret forward-looking agenda but a backward looking one that has a lot of diffuse agitations. This can reduce the perception of click fraud, even if it doesn't do much about it in reality.

That's backwards. It's the diehards (i.e. determined adversaries) they are thinking about. 99% of users are already not doing this stuff. They want a way to continue servicing that 99% and shut out the remainder. That's the whole point.

Sorry for the nitpick, but that isn't the analog hole. The analog hole occurs when your monitor displays the video. At that point, you can point a camera at it and record the video, albeit with a loss in quality. Removing the analog hole would require pushing the attestation and encryption one layer further, into your brain or eyes.

> One interesting application of this kind of technology was to remove the 'analog hole'. When playing protected content, even the video stream from your PC to your monitor is actually encrypted in a manner that ostensibly prevents anyone from interecepting it.

And yet, despite these fucking morons in the standard committees wasting (probably) millions of dollars in implementing CSS, HDCP and whatnot, and often enough bricked existing devices by revoking keys, HDCP strippers remain available for a dozen dollars or so on ebay, or AnyDVD so you don't have to bother with any copy protection at all.

I don't think HDCP was ever meant to actually stop this sort of thing. Just to make it difficult and criminal.

This makes sense for iPhones but if attestation is possible on macs, as I believe it is, as well does that not sidestep most of the “equivalent to jailbreak” requirements?

Macs have alternate mechanisms that achieve the same thing. SIP de-privileges the root user, the boot filesystems are cryptographically sealed, and the kernel will prevent apps tampering with each other to at least some extent.

So whilst you can "jailbreak" a Mac you can only do it by following Apple's procedures, which leaves a trace that can detected in the remote attestation. At least I assume that's what's going on from their docs.

My perspective is the analog hole is all of the above: your eyes, the display, and the composite video connection (for an old standard definition TV)

Closing 1 is better than closing none

> 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.

>HDCP strippers remain available for a dozen dollars or so on ebay

These don't work on the latest HDCP.

TPM chips. They became a hard requirement for Windows recently, and I don't believe this is a coincidence.

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.