I suspect this will just lead to crowdsourcing PATs or whatever mechanism is used to issue these things, just like it happens with proxies. In the beginning, God created IPs and the Earth. Then people figured that IPs could be "borrowed". Trust in IPs went down this really absurd path of people being pissed when they get blocked, subnet blocks, residential proxies and etc.
Can Private Access Tokens be used to track a user/device?
If not, what stops someone from setting up a system which generates lots of PAT’s from a small number of devices and sending those as fake PAT’s from other devices?
If it’s private, it shouldn’t allow anyone to associate my PAT with my device. If it’s private, how does the server know a PAT was generated by the device that is sending it?
It seems like you shouldn't be able to use a PAT from another device (thus creating a PAT fountain), as attestations are used, which chain back to a trusted issuer (device maker). This should be possible to do, through a simple thought experiment -
In essence, the PAT doesn't need to be tied to your device identifiably, but it could be considered as a certificate saying "I, the device maker, know that the holder of this public key is a real device". If the private key corresponding to that public key is held in a trustzone or other similar keystore, it can be used to sign an attestation containing a challenge/response, without revealing the private key.
If you can't liberate the private key, you can't reuse the PAT, as you can't include the challenge in your signature.
Presumably devices can generate (and get attested) multiple PATs and cycle through them, removing old ones.
Blind RSA signatures could also be used to do this, so that the device maker signing the attestation doesn't know what public key is being signed, just that it's a valid one generated on a protected key store.
The standard seems to confirm this [1]:
"Privacy Pass tokens are unlinkable authenticators that can be used to anonymously authorize a client. A client possessing such a token is able to prove that it was able to get a token issued by a token issuer -- based on some check from a token issuer, such as authentication or solving a CAPTCHA -- without allowing the relying party redeeming the client's token (the origin) to link it with issuance flow"
asdadsdad|3 years ago
runnerup|3 years ago
If not, what stops someone from setting up a system which generates lots of PAT’s from a small number of devices and sending those as fake PAT’s from other devices?
If it’s private, it shouldn’t allow anyone to associate my PAT with my device. If it’s private, how does the server know a PAT was generated by the device that is sending it?
g_p|3 years ago
In essence, the PAT doesn't need to be tied to your device identifiably, but it could be considered as a certificate saying "I, the device maker, know that the holder of this public key is a real device". If the private key corresponding to that public key is held in a trustzone or other similar keystore, it can be used to sign an attestation containing a challenge/response, without revealing the private key.
If you can't liberate the private key, you can't reuse the PAT, as you can't include the challenge in your signature.
Presumably devices can generate (and get attested) multiple PATs and cycle through them, removing old ones.
Blind RSA signatures could also be used to do this, so that the device maker signing the attestation doesn't know what public key is being signed, just that it's a valid one generated on a protected key store.
The standard seems to confirm this [1]:
"Privacy Pass tokens are unlinkable authenticators that can be used to anonymously authorize a client. A client possessing such a token is able to prove that it was able to get a token issued by a token issuer -- based on some check from a token issuer, such as authentication or solving a CAPTCHA -- without allowing the relying party redeeming the client's token (the origin) to link it with issuance flow"
[0] https://blog.cloudflare.com/eliminating-captchas-on-iphones-...
[1] https://www.ietf.org/archive/id/draft-ietf-privacypass-auth-...
unknown|3 years ago
[deleted]
Havoc|3 years ago