6 ms·

Requiring authorized silicon (and software) isn't even the biggest problem here. They do not use zero knowledge proof systems or blind signatures. So every tim

Requiring authorized silicon (and software) isn't even the biggest problem here. They do not use zero knowledge proof systems or blind signatures. So every time you use your device to attest you leave behind something (the attestation packet) that can be used to link the action to your device. They put on a show about how much they care about your privacy by introducing indirection into the process (static device 'ID' is used to acquire an ephemeral 'ID' from an intermediate server) but it's just a show because you don't know what those intermediary severs are doing: You should assume they log everything. And this just the remote attestation vector, the DRM 'ID' vector is even worse (no meaningful indirection, every license server has access to your burned-in-silicon static identity). And the Google account vector is what it is. Using blind signatures for remote attestation has actually been proposed, but no one notable is currently using it: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation> There are several possible reasons for this, the obvious one is that they want to be able to violate your privacy at will or are mandated to have the capability. The other is that because it's not possible to link an attestation to a particular device the only mitigation to abuse that is feasible is rate limiting which may not be good enough for them - an adversary could set up a farm where every device generates $/hour from providing remote attestations to 'malicious' actors.

Hoodedcrow 5mo ago
Would like to read a writeup on this, I was certain it was going to be something like this from the app's announcement. Also I recall a discussion on Graphene's forums that DRM ID is not only retained there, but stays the same across profiles.
- coppsilgold 5mo ago
  I simplified the process in my description. The DRM ID Android has is not what I was referring to. I was referring to the static private key that is stored in the silicon. At any time an application can initiate a license request process using DRM APIs which will elicit an unchangeable HWID from your device. The only protection is that it will be encrypted for an authorized license server private key so collusion may be required (intel agencies almost certainly sourced 'authorized' private keys for themselves). Google or Apple also has the option to authorize keys for themselves. In 'theory' all such keys should be stored in "trusted execution environments" on license servers and not divulge client identities for whatever that's worth: <https://tee.fail https://tee.fail>.
  - comex 5mo ago
    Citation?
    - coppsilgold 5mo ago
      Content Decryption Module (CDM) in your browser or Mobile SDK generates the license challenge <https://go.buydrm.com/thedrmblog/the-anatomy-of-a-multi-drm-license-request https://go.buydrm.com/thedrmblog/the-anatomy-of-a-multi-drm-...> The "license challenge" (it might be a mistake I think it's supposed to be a license request) is just a packet (that can be saved and later sent to anywhere) and it contains the encrypted certificate which doubles as your HWID. An adversary needs to control the private key of the license "server" the challenge is for (this is a privacy measure introduced to prevent the CDM from offering the HWID to anyone who wants it). Now if you want the HWID you need to work for it (one time) by stealing a private key, bribing/blackmailing employees or issuing secret edicts ("here is a new license server we need a certificate for"). Working for Hollywood is also an option I suppose. Pirates sacrifice devices when they publish ripped content due to the certificate being revoked after Hollywood downloads the torrent and by doing things like this: For large-scale per-viewer, implement a content identification strategy that allows you to trace back to specific clients, such as per-user session-based watermarking. With this approach, media is conditioned during transcoding and the origin serves a uniquely identifiable pattern of media segments to the end user. <https://docs.aws.amazon.com/wellarchitected/latest/streaming-media-lens/detective-controls.html https://docs.aws.amazon.com/wellarchitected/latest/streaming...>
willis936 5mo ago
Are these the kinds of issues privacy pass intends to fix? If so, what carrot and/or stick will get it adopted?
xinayder 5mo ago
Can we stop normalizing being surveilled online and on our devices? Saying something like "the problem is not hardware attestation, but that they don't use ZKP". You are normalizing the new behavior. You shouldn't. It doesn't matter if they use ZKP or the latest, secure technology for hardware attestation. The issue is hardware attestation. It's the same with age ID. The issue is not that Age ID is prone to data leaks, the problem itself is called Age ID.
- userbinator 5mo ago
  Hell yes. I was going to post the same comment. I don't give a flying fuck how it's implemented. Remote attestation is inherently evil. I remember the WEI apologists trying to do the same thing to derail the argument. The problem is the goal, not the details. Just say no: DO NOT WANT!
  - lxgr 5mo ago
    Remote attestation is a technology, not a policy or a political effort, so it can't be inherently evil. You can disagree with all its known or proposed uses, but then I think it makes more sense to name these.
    - userbinator 5mo ago
      Then explain why RA was invented? It is inherently against user freedom, just like "secure" boot and the rest of the corporate-authoritarian crap. People have woken up to the truth as the pieces come together. This article from 2022 is fun to look at and see how prescient it was: https://news.ycombinator.com/item?id=29859106 https://news.ycombinator.com/item?id=29859106
      - MadnessASAP 5mo ago
        I have 2 servers, Alice and Bob, Bob has a secret, I want Bob to be able to share that secret with Alice. However, I want Alice to be able to prove to Bob that it is actually Alice, that it is running the correct AliceOS, and that AliceOS was loaded on bare metal Alice without nefarious pre-book or virtualization hooks. A TPM with measured boot (SecureBoot) does exactly this, remote attestation is how Alice proves to Bob that it is in a trusted configuration and wasn't tampered with.
AnthonyMouse 5mo ago
> The other is that because it's not possible to link an attestation to a particular device the only mitigation to abuse that is feasible is rate limiting I still don't see how you can keep something anonymous and still rate limit it. If a service can tell that two requests came from the same party in order to count them then two services can tell that two requests came from the same party (by both pretending to be the same service) and therefore correlate them.
- coppsilgold 5mo ago
  The way it would work with blind signatures is that the server will know the device that comes to it to request a blinded signature and will be able to rate limit how often that device asks it. But once you get the response you can unblind the signed signature and obtain the token (which is just the unblinded signature). This token can then be used once either because its blacklisted after use (and it expires before the next day starts for example). The desired property of blind signatures is that given a token it's information theoretically impossible to determine which blinded signature it came from (because it could have come from any of them) even if the cryptographic primitive is broken by a mathematical breakthrough or a quantum computer. There is technically the danger that if the anonymity set is too small and all the other participants collude you can be singled out. Correlating times is a threat vector that needs to be managed either by delaying actions (not tolerable by normal users) or by acquiring tokens automatically and storing them in expectation. Or something other I haven't thought of probably. There is also a networking aspect to this, you will need a decentralized relay server network that masks origin of requests.
  - AnthonyMouse 5mo ago
    > But once you get the response you can unblind the signed signature and obtain the token (which is just the unblinded signature). The premise of this is to keep the person issuing the tokens and the person accepting them from correlating you. The issue is when you have more than one service accepting them. You go to use Facebook and WhatsApp but they're both Meta so you present the same unblinded signature to both services and now your Facebook and WhatsApp accounts are correlated against your will. And they have a network that does the same thing, so you go to use a third party service and they require you to submit your unblinded signature to Meta which allows them to correlate you everywhere.
zx8080 5mo ago
> Requiring authorized silicon (and software) isn't even the biggest problem here. It is indeed the biggest issue. It prevents be from owning and using the hardware I pay for, own, or make myself. It's switching the personal computers as we know it from being open to proprietary and owned by 2 large US corporations. I don't agree that it's not a problem.
- brabel 5mo ago
  Did you just read “not even the biggest problem” as “not a problem”?
  - zx8080 5mo ago
    I mean it's THE biggest one.
vbezhenar 5mo ago
Can you revoke certificate for a specific device using privacy schemes? Like imagine that someone managed to extract key from the specific device and distributed that key in a software implementation to fake attestation. Now Google needs to revoke that particular key to disallow its usage. This is obvious requirement.
- rapidaneurism 5mo ago
  Especially if the device in question is linked to an enemy of the state and the people.
- coppsilgold 5mo ago
  Yes, with blind signatures you still have a central authority which voluntarily 'launders' tokens for you. When you present it your certificate and ask it to give you a blind signature it can reject the certificate. However if someone extracts a key and keeps it private, and instead gives out unblinded tokens there is nothing you can do other than rate limit - realistically, an adversary is going to trial different rates anyway to figure out which don't make them an outlier.
to11mtm 5mo ago
> Requiring authorized silicon (and software) isn't even the biggest problem here. I agree, except I worry it's a bigger concern than we realize. I still remember what CableCard (and the hoops needed for HW manufacturers to get certified) did to the DIY DVR Market...
miki123211 5mo ago
Ultimately, the point of hardware attestation isn't to ensure that your device is trusted, but that the action you're trying to perform was done by a human, not a bot doing millions of them per second. It's just another CAPTCHA mechanism in disguise, required because bots have gotten so good at solving the existing ones. With a secure device, the only way to get an attestation for an account signup is to do the signup on that device, with real fingers clicking real buttons on a real screen. There's no way to short-circuit the process by automatically sending a JSON request and bypassing the actual signup flow from a Python script, like you can do with an insecure endpoint. With blind signatures, a single compromised device destroys the value of the entire scheme, as it can be used to issue an infinite number of attestations with 0 human oversight. What we need is a blind signature construction where the verifier can revoke a signature, each signature carries proof that none of the revoked signatures comes from the same signer, and where it is impossible for one signer to issue more than n distinct signatures during one time window. Not sure if this would be possible with ZKPs; my cryptography knowledge doesn't extend that far.
- derefr 5mo ago
  > Ultimately, the point of hardware attestation isn't to ensure that your device is trusted, but that the action you're trying to perform was done by a human, not a bot doing millions of them per second. It's just another CAPTCHA mechanism in disguise, required because bots have gotten so good at solving the existing ones. ...no? Maybe this is true of end-user device attestation. But there are other use-cases for attestation. Server device attestation is an entirely different thing. It's used in e.g. IaaS "Confidential VM" offerings, where the audience for the attestation information is the customer, rather than the server host. It's a very pro-privacy / pro-data-sovereignty feature. And while embedded device attestation is sometimes about preventing customers from tampering with IoT stuff you "sold" them, more often it's about being able to trust and confidently assert that e.g. the climate sensors you've deployed all over a forest as part of a research project haven't been fucked with to report false data by someone with an agenda. (Or to "apply denial" to your unmanned military satellite downlink station the moment you detect that there's some unknown person out there futzing with it.)

Hoodedcrow 5mo ago

Would like to read a writeup on this, I was certain it was going to be something like this from the app's announcement. Also I recall a discussion on Graphene's forums that DRM ID is not only retained there, but stays the same across profiles.

coppsilgold 5mo ago
I simplified the process in my description. The DRM ID Android has is not what I was referring to. I was referring to the static private key that is stored in the silicon. At any time an application can initiate a license request process using DRM APIs which will elicit an unchangeable HWID from your device. The only protection is that it will be encrypted for an authorized license server private key so collusion may be required (intel agencies almost certainly sourced 'authorized' private keys for themselves). Google or Apple also has the option to authorize keys for themselves. In 'theory' all such keys should be stored in "trusted execution environments" on license servers and not divulge client identities for whatever that's worth: <https://tee.fail https://tee.fail>.
- comex 5mo ago
  Citation?
  - coppsilgold 5mo ago
    Content Decryption Module (CDM) in your browser or Mobile SDK generates the license challenge <https://go.buydrm.com/thedrmblog/the-anatomy-of-a-multi-drm-license-request https://go.buydrm.com/thedrmblog/the-anatomy-of-a-multi-drm-...> The "license challenge" (it might be a mistake I think it's supposed to be a license request) is just a packet (that can be saved and later sent to anywhere) and it contains the encrypted certificate which doubles as your HWID. An adversary needs to control the private key of the license "server" the challenge is for (this is a privacy measure introduced to prevent the CDM from offering the HWID to anyone who wants it). Now if you want the HWID you need to work for it (one time) by stealing a private key, bribing/blackmailing employees or issuing secret edicts ("here is a new license server we need a certificate for"). Working for Hollywood is also an option I suppose. Pirates sacrifice devices when they publish ripped content due to the certificate being revoked after Hollywood downloads the torrent and by doing things like this: For large-scale per-viewer, implement a content identification strategy that allows you to trace back to specific clients, such as per-user session-based watermarking. With this approach, media is conditioned during transcoding and the origin serves a uniquely identifiable pattern of media segments to the end user. <https://docs.aws.amazon.com/wellarchitected/latest/streaming-media-lens/detective-controls.html https://docs.aws.amazon.com/wellarchitected/latest/streaming...>

willis936 5mo ago

Are these the kinds of issues privacy pass intends to fix? If so, what carrot and/or stick will get it adopted?

xinayder 5mo ago

Can we stop normalizing being surveilled online and on our devices? Saying something like "the problem is not hardware attestation, but that they don't use ZKP". You are normalizing the new behavior. You shouldn't. It doesn't matter if they use ZKP or the latest, secure technology for hardware attestation. The issue is hardware attestation. It's the same with age ID. The issue is not that Age ID is prone to data leaks, the problem itself is called Age ID.

userbinator 5mo ago
Hell yes. I was going to post the same comment. I don't give a flying fuck how it's implemented. Remote attestation is inherently evil. I remember the WEI apologists trying to do the same thing to derail the argument. The problem is the goal, not the details. Just say no: DO NOT WANT!
- lxgr 5mo ago
  Remote attestation is a technology, not a policy or a political effort, so it can't be inherently evil. You can disagree with all its known or proposed uses, but then I think it makes more sense to name these.
  - userbinator 5mo ago
    Then explain why RA was invented? It is inherently against user freedom, just like "secure" boot and the rest of the corporate-authoritarian crap. People have woken up to the truth as the pieces come together. This article from 2022 is fun to look at and see how prescient it was: https://news.ycombinator.com/item?id=29859106 https://news.ycombinator.com/item?id=29859106
    - MadnessASAP 5mo ago
      I have 2 servers, Alice and Bob, Bob has a secret, I want Bob to be able to share that secret with Alice. However, I want Alice to be able to prove to Bob that it is actually Alice, that it is running the correct AliceOS, and that AliceOS was loaded on bare metal Alice without nefarious pre-book or virtualization hooks. A TPM with measured boot (SecureBoot) does exactly this, remote attestation is how Alice proves to Bob that it is in a trusted configuration and wasn't tampered with.

AnthonyMouse 5mo ago

> The other is that because it's not possible to link an attestation to a particular device the only mitigation to abuse that is feasible is rate limiting I still don't see how you can keep something anonymous and still rate limit it. If a service can tell that two requests came from the same party in order to count them then two services can tell that two requests came from the same party (by both pretending to be the same service) and therefore correlate them.

coppsilgold 5mo ago
The way it would work with blind signatures is that the server will know the device that comes to it to request a blinded signature and will be able to rate limit how often that device asks it. But once you get the response you can unblind the signed signature and obtain the token (which is just the unblinded signature). This token can then be used once either because its blacklisted after use (and it expires before the next day starts for example). The desired property of blind signatures is that given a token it's information theoretically impossible to determine which blinded signature it came from (because it could have come from any of them) even if the cryptographic primitive is broken by a mathematical breakthrough or a quantum computer. There is technically the danger that if the anonymity set is too small and all the other participants collude you can be singled out. Correlating times is a threat vector that needs to be managed either by delaying actions (not tolerable by normal users) or by acquiring tokens automatically and storing them in expectation. Or something other I haven't thought of probably. There is also a networking aspect to this, you will need a decentralized relay server network that masks origin of requests.
- AnthonyMouse 5mo ago
  > But once you get the response you can unblind the signed signature and obtain the token (which is just the unblinded signature). The premise of this is to keep the person issuing the tokens and the person accepting them from correlating you. The issue is when you have more than one service accepting them. You go to use Facebook and WhatsApp but they're both Meta so you present the same unblinded signature to both services and now your Facebook and WhatsApp accounts are correlated against your will. And they have a network that does the same thing, so you go to use a third party service and they require you to submit your unblinded signature to Meta which allows them to correlate you everywhere.

zx8080 5mo ago

> Requiring authorized silicon (and software) isn't even the biggest problem here. It is indeed the biggest issue. It prevents be from owning and using the hardware I pay for, own, or make myself. It's switching the personal computers as we know it from being open to proprietary and owned by 2 large US corporations. I don't agree that it's not a problem.

brabel 5mo ago
Did you just read “not even the biggest problem” as “not a problem”?
- zx8080 5mo ago
  I mean it's THE biggest one.

vbezhenar 5mo ago

Can you revoke certificate for a specific device using privacy schemes? Like imagine that someone managed to extract key from the specific device and distributed that key in a software implementation to fake attestation. Now Google needs to revoke that particular key to disallow its usage. This is obvious requirement.

rapidaneurism 5mo ago
Especially if the device in question is linked to an enemy of the state and the people.
coppsilgold 5mo ago
Yes, with blind signatures you still have a central authority which voluntarily 'launders' tokens for you. When you present it your certificate and ask it to give you a blind signature it can reject the certificate. However if someone extracts a key and keeps it private, and instead gives out unblinded tokens there is nothing you can do other than rate limit - realistically, an adversary is going to trial different rates anyway to figure out which don't make them an outlier.

to11mtm 5mo ago

> Requiring authorized silicon (and software) isn't even the biggest problem here. I agree, except I worry it's a bigger concern than we realize. I still remember what CableCard (and the hoops needed for HW manufacturers to get certified) did to the DIY DVR Market...

miki123211 5mo ago

Ultimately, the point of hardware attestation isn't to ensure that your device is trusted, but that the action you're trying to perform was done by a human, not a bot doing millions of them per second. It's just another CAPTCHA mechanism in disguise, required because bots have gotten so good at solving the existing ones. With a secure device, the only way to get an attestation for an account signup is to do the signup on that device, with real fingers clicking real buttons on a real screen. There's no way to short-circuit the process by automatically sending a JSON request and bypassing the actual signup flow from a Python script, like you can do with an insecure endpoint. With blind signatures, a single compromised device destroys the value of the entire scheme, as it can be used to issue an infinite number of attestations with 0 human oversight. What we need is a blind signature construction where the verifier can revoke a signature, each signature carries proof that none of the revoked signatures comes from the same signer, and where it is impossible for one signer to issue more than n distinct signatures during one time window. Not sure if this would be possible with ZKPs; my cryptography knowledge doesn't extend that far.

derefr 5mo ago
> Ultimately, the point of hardware attestation isn't to ensure that your device is trusted, but that the action you're trying to perform was done by a human, not a bot doing millions of them per second. It's just another CAPTCHA mechanism in disguise, required because bots have gotten so good at solving the existing ones. ...no? Maybe this is true of end-user device attestation. But there are other use-cases for attestation. Server device attestation is an entirely different thing. It's used in e.g. IaaS "Confidential VM" offerings, where the audience for the attestation information is the customer, rather than the server host. It's a very pro-privacy / pro-data-sovereignty feature. And while embedded device attestation is sometimes about preventing customers from tampering with IoT stuff you "sold" them, more often it's about being able to trust and confidently assert that e.g. the climate sensors you've deployed all over a forest as part of a research project haven't been fucked with to report false data by someone with an agenda. (Or to "apply denial" to your unmanned military satellite downlink station the moment you detect that there's some unknown person out there futzing with it.)