Hacker News new | ask | show | jobs
by remram 1293 days ago
> For devices, direct attestation could authenticate the device making the request (e.g. as a legitimate MacBook Pro, or something).

The attacker may well be using a MacBook Pro, a real one. With a TPM.

2 comments

I think the only MacBook Pros with real TPMs were the 1, and 2, series from 2006/2007. Right now Apple don't allow you to do device identity attestation with the secure element. But in the world where you take this approach you don't just tie issuance to "I have a hardware keystore", you tie it to "This hardware keystore has an identity that I know belongs to a computer I own"
But the entire thread is about delegating the authentication, granting access to another machine or process. You want to give access to one device (e.g. TV) from the trusted one (e.g. iPhone).

Both devices might be very pricey, real, up-to-date machines with TPM and keys and everything you want. The problem is that you can't tell whether the TV is the one TV that the iPhone's owner means to sign in.

Yes, but the idea is that you'd enroll the device (and its TPM), and thence wouldn't be phishable like this. Granted, there might still be a problem at device enrollment time.
See sibling thread, we're being duplicated; the point of this OAuth flow is to sign in on a different device, using the trusted one. That different device might be a legitimate TV with a TPM and cryptographic attestations that it truly belong to John Doe, there is still no way for your iPhone and Apple to check whether you meant to sign in to John Doe's TV or if they are a scammer and sent you the (legitimate) sign-up link over email.
It's essentially an enrollment workflow using an existing enrolled device, yes?
This submission's title mentions "2FA". The first post in this thread is about OAuth. Nothing in here is about anything but the "enrollment".