5 ms·
In case it's not obvious, here is how the attack works: 1. The attacker manufactures a device, such as a smartphone, generates a keypair for it, stores it on a
by devit 3y ago
In case it's not obvious, here is how the attack works:
1. The attacker manufactures a device, such as a smartphone, generates a keypair for it, stores it on an HSM on the device (generally called a "trusted enclave"), and signs the public key of the keypair with a master key
2. The device runs the attacker's software and is designed so that whenever non-attacker software is run with elevated privileges, the HSM is informed of that fact in a way that can't be reset without rebooting (and starting again with the attacker's software). For instance, the device might use a verified boot scheme, send the key the OS is signed with to the HSM in a way that is unchangeable until reboot, and it might employ hardening like having the CPU encrypt RAM or apply an HMAC to RAM
3. The HSM produces signatures of messages that contain statements that the device is running the attacker's software, plus whatever the attacker's software wants to communicate and it won't produce them if it's running software of the user's choice as opposed to the attacker's software as established above. It also includes the signature of its public key with the master keypair, allowing accomplices to check that the device is indeed not under the user's control, but rather under the control of someone they trust to effectively limit the user's freedom
4. Optionally, that attestation is passed through the attacker's servers, which check it and return another attestation signed by themselves, allowing to anonymize the device and apply arbitrary other criteria
5. Conniving third parties can thus use this scheme to ensure that they are interacting with a device running the attacker's software, and thus that the device is restricting the user behavior as the attacker specifies. For instance, it can ensure that the device is running the accomplice's code unmodified, preventing the user from being able to run software of their choice, and it can ensure that the user is using device as desired by the attacker and their accomplices.
This attack is already running against Android smartphone users (orchestrated by Google, in the form of SafetyNet and the Play Integrity API) and iOS smartphone users (orchestrated by Apple) and this extends the attack to the web.
- Doxin 3y agoCan I just say I appreciate the framing of this as an attack? Somehow I hadn't yet mentally filed Google and friends under "Man in the middle" but that's pretty much exactly what's going on. This Web Integrity API is just a means to cement themselves as obligatory man in the middle, as opposed to an optional one.
- notpushkin 3y agoAgreed. GP comment was extremely weird to read, but I agree with the sentiment 100%.
- chii 3y agoit's not weird, but it's just that you're not used to seeing google as an attacker. But they definitely are in this spec.
- relaunched 3y agoIt might be my security hat speaking, but I see it as insecure, regardless of who is man in the middling the connection. I'm not a tinfoil hat, but security can't hang it's hat on the kindness of strangers.
- insanitybit 3y ago> I'm not a tinfoil hat, but security can't hang it's hat on the kindness of strangers. Given that SSO is a massive security win and has been a game changer for removing passwords, I think it's been shown that delegation is extremely effective.
- gunapologist99 3y agoWhy is removing passwords a massive security win? You're just moving the centralization from a password manager to SSO.
- insanitybit 3y agoA few reasons. 1. Instead of needing 100 passwords, which increases the chance of users just choosing something and repeating it, you have 1 password. 2. Similarly, instead of needing 2FA on 100 sites they can just have 2FA on their SSO. In fact, the other sites don't even need to support 2FA - you get that "for free" with SSO. 3. SSO providers implement auth really well. They make it smooth, as in "I don't have to reauth when it's obviously me" and safe, as in "that might not be a valid auth, let's get them to 2fa again". Of course, if you have a password manager then (1) is not a problem. But SSO is a lot simpler for users.
- CalRobert 3y agoIs there an option to have a smartphone and avoid this attack? The moribund Ubuntu phone comes to mind.
- danielheath 3y agoYes, but accomplices can, in this case, refuse to serve the phone in question - receiving sufficient traffic from infected devices to meet their needs.
- ragnese 3y agoAt some point we just have to be okay with that. Threats and protests and complaints don't matter unless we back it up with something. If that means upgrading/repairing older devices instead of new ones, or not using web services that require DRM nonsense, then so be it. I remember in the long, long ago, when I actually visited a BUILDING to do some of my banking tasks. And when I bought physical media that took up actual 3D space in my house to watch movies. I suspect we aren't incapable of going back.
- sp332 3y agoWe don’t, and TFA is Mozilla rejecting this.
- ragnese 3y agoFor now. I'm not a Mozilla hater like many people here seem to be, but they caved on EME, and I'm honestly very skeptical that they won't eventually cave here.
- CalRobert 3y agoBanks have been closing branches by the hundreds (at least where I live), and buildings where you can rent physical media are dying out (see Blockbuster, though the local library is fighting a valiant rearguard action). If 96% of people will use the bank app on their Approved by Alphabet phone (or browser) then the bank can ignore the few weirdos like us.
- benterix 3y agoActually it would be useful to present the problem using your framing - in the press, blogs, everywhere. The other side is already bending over backwards to stretch the meaning of words (their introduction about DRM being "the backbone of the open Internet" made me me sick).
- devn0ll 3y agoAlso make DRM the abbreviation of "Digital Restrictions Management", which from the users perspective it is.
- kijin 3y agoThe framing would work just as well if we substituted for Google a certain not-exactly-friendly-with-the-U.S. regime that also happens to produce a shitload of smartphones. Whatever we don't want them to be able to do to our smartphones, we don't want Google to be able to do, either.
- benterix 3y agoIn theory - yes, but in practice TikTok gets a lot of bashing while its American equivalents manage to get away with basically the same behavior. Meta and Google aside, Uber created Greyball to avoid regulations, they even had (still have?) a special "Ripley" button to use when facing audit, so how can we expect a foreign regime to abide by our laws if we give our own companies a free pass? And when local governments try to limit Uber's unlawful[0] actions, we threaten them with freezing our investments in other sectors? [1] [0] https://us.boell.org/en/2019/10/17/web-partner-companies-keeps-uber-out-trouble-poland https://us.boell.org/en/2019/10/17/web-partner-companies-kee... [1] https://tvpworld.com/40781592/another-letter-from-us-ambassador-leaks-out https://tvpworld.com/40781592/another-letter-from-us-ambassa...
- appplication 3y agoI don’t think they mean TikTok. Huawei has been banned in the US for years for basically being permanently backdoored hardware for the Chinese government. The precedent, history, and motivations are clear. American companies trying to avoid regulation is scummy, but it’s basically the exact opposite of acting as an corporate extension of the government.
- o11c 3y agoAnd of course the unfixable side-effect of the fact that we're ultimately sending electricity over wires: 6. Any additional party with sufficient ability to modify hardware can still attack the attacker and their accomplices. So such parties only benefit from this, at the cost of typical users.
- insanitybit 3y agoSo the attacker in this scenario is producing my hardware? That sounds ridiculous, if that were the case they could do anything they want anyways, I see no way in which the scenario you've discussed is materially different from "attacker can literally do anything anyway, they own the hardware". And this "attacker" gets... what? Nothing. Because this isn't an attacker... it's a device manufacturer. You've described how attestation works except you've described the TPM as an attacker, which is silly.
- bri3d 3y agoThat's the point of this framing - it's pitching the device manufacturer as an attacker and Secure Enclave as their sinister fortress inside your device. This is an age-old argument against these systems, but to your point the conspiracy theory crumbles at the edges once you start trying to turn it into a threat model.
- insanitybit 3y agoYeah, I get the point, it's just a terrible framing because, as you said, this threat model is nonsensical. It's just that this description is describing an "attack" that is just how attestation works. If you have a problem with attestation, talk about that problem, calling it "an attack" does nothing. I'm actually against the proposal, too - although I see the merits. The ability to have servers authenticate clients based on the context of that client is amazing - it would seriously improve security if done right. But I personally believe that this should be done through the Device Policy extension exclusively, as it is already done there today, and that the extension should be opened and standardized. In fact, I believe Google should be forced to do so.
- BSEdlMMldESB 3y agoit is becoming impossible to own your hardware. go cloud!
- insanitybit 3y ago> it is becoming impossible to own your hardware It sure is not. But I do believe we should have a legal right to own our own hardware, in every sense.