25
votes
Nvidia confirms they accidentally released a driver that removed the Ethereum-mining limitations on RTX 3060 GPUs, undermining their attempt to make the cards unappealing to cryptominers
https://www.theverge.com/2021/3/16/22333544/nvidia-rtx-3060-ethereum-mining-rate-limit-unlock-driver
I can imagine how the engineers at NVidia felt reading the press releases stating that these locks were unhackable. Anyone looking at the driver source code could probably see the config flag "RTX-3060/mining_limiter=true". Hell, anyone implementing this would have a hard time looking at their screen long enough between eye rolls.
Drivers must be cryptographically signed in order to be used. (Well, they have to be cryptographically signed to change the clock speed from its lowest setting; at which setting the cards would be useless for mining anyway.)
So it doesn't matter how hard it is to modify the driver, because the modified driver won't have been signed by nvidia and so won't be usable. The cryptographic signature algorithm itself is unhackable (modulo a major breakthrough, in which case we have bigger things to worry about; or a leak of nvidia's key, which is unlikely).
Oh, interesting. So this is a much bigger blunder than I thought.
It is also unlikely that they leave the barn doors wide open on crypto mining when they marketed these cards on not being able to.
Out of curiosity, how do projects like these dodge the signing requirements? Do they only patch the userspace applications rather than the signed firmware or something?
And what about FOSS drivers?
That's one I do know: they don't. FOSS drivers are just stuck on the lowest power setting like Moonchild describes, at least on all devices that require the firmware to be signed. They're fine for booting and accelerating basic desktop use, but if you have a device with an Nvidia card you're probably not satisfied with just that, so AFAIK pretty much all Linux users either use the proprietary drivers or don't use Nvidia hardware.
That's a cheap attack imo. Yes, with source code access, a lot of things are easy. If you have source code access to any program, all DRM for that program is null and void. If you have source code access to google's SSO service, all of google is now hacked. Well, in this case you need google to deploy your code, but Moonchild points out how that's essentially the same for NVidia, i.e. they have to sign the drivers.
"Access to source code" is actually a pretty fair assumption for security. It's known as Shannon's (or Kerckhoff's) maxim:
Ehh, depends on the kind of application. Google's SSO? Yeah, gotta have a few keys in place. DRM? No point bothering with Kerckhoff's principle: Any leak of the game's source code and you're done. Which means you have to walk back your security guarantees in the case of DRM.
Cryptographically secure DRM can have its implementation be open-source as long as the keys are protected. DRM doesn't need to be cracked, sometimes keys are just discovered and shared.
Oh yeah, the DRM can be open-source. But what about the underlying software? How do you protect a game from "theft" if said game's source code is known? That's what I was talking about.
I don't think this is true:
Just because the source code is available to you does not mean you can trivially bypass security measures. If that was the case all open source projects would be compromised. DRM can be implemented in a way that even if you have the source it remains secure.
Au contraire: DRM cannot be implemented securely in any context, regardless of whether a would-be attacker has its source code.
That being said, however, authentication is not a form of DRM.
Sure you can. Make an online game that you stream to ppl where the "client" consist of sending keystrokes and mouse movements to the server and just renders whatever the server sends. Even if you have the source for the client you can't copy the game, since all game logic and stuff is on the server.
That said you do have a point that DRM is notorious for being cracked eventually. I'd argue it's more of a continuum of how "secure" you want your content to be.