Originally posted by M@GOid
View Post
Announcement
Collapse
No announcement yet.
Nouveau Gallium3D Moves Closer Towards OpenGL 4.5 Compliance
Collapse
X
-
Originally posted by anth View Post
That used to be possible, but as of the 900 series Nvidia require encryption which prevents that.
Comment
-
Originally posted by smitty3268 View PostCan't they just copy the encrypted firmware out of the binary drivers though?
They can't do that this time as they need to load a signed firmware, and afaik the blobs they can extract from the driver are not signed.
Comment
-
Originally posted by starshipeleven View PostThey have been extracting firmwares from NVIDIA blobs for a long time by doing the same trick NVIDIA does to avoid GPL issues (i.e. have a script do the leg work in the user PC) https://nouveau.freedesktop.org/wiki/VideoAcceleration/
They can't do that this time as they need to load a signed firmware, and afaik the blobs they can extract from the driver are not signed.
Comment
-
Originally posted by smitty3268 View PostI guess my question is why they can't just record the blob that the proprietary driver sends to the hardware which is presumably signed at that point, rather than trying to dig it directly out of the binary.
Really, they can't win this fight through brute force.
Comment
-
Originally posted by starshipeleven View PostBecause it's either already encrypted when travelling between the driver and the hardware
I'm clearly missing something, just not sure why it's not that simple.
Comment
-
Originally posted by smitty3268 View PostBut that's my point. It seems like they should be able to copy the encrypted firmware - it's not like they need to decrypt it, that's what the hardware does.
I'm clearly missing something, just not sure why it's not that simple.
Since the "salt" they are using is time-dependant, the encryption key used for the transfer will be different each time, so whatever you intercept is useless.
And note that "time-dependant" does not mean that it is using the system clock, it can use whatever it wants just to count time somehow, be it some loops in the code, or whatever.
The GPU can count the noise on its voltage rails or something, like the chaos key (true hardware RNG) does.
Only one of the two should salt its own the key, if both salt it then it's reading garbage.
Really it's not terribly hard to lock everything down.
Comment
-
Originally posted by starshipeleven View PostThat's a long-solved problem by public key crypto. The hardware has its own key (each GPU has its own), the blob has its public key, and they salt it with something time-dependent so that it's not the same all the time, then do a Diffie-hellman key exchange to create the encryption key they will then use to encrypt the firmware.
Since the "salt" they are using is time-dependant, the encryption key used for the transfer will be different each time, so whatever you intercept is useless.
Comment
-
Originally posted by starshipeleven View PostThat's a long-solved problem by public key crypto. The hardware has its own key (each GPU has its own), the blob has its public key, and they salt it with something time-dependent so that it's not the same all the time, then do a Diffie-hellman key exchange to create the encryption key they will then use to encrypt the firmware.
Since the "salt" they are using is time-dependant, the encryption key used for the transfer will be different each time, so whatever you intercept is useless.
And note that "time-dependant" does not mean that it is using the system clock, it can use whatever it wants just to count time somehow, be it some loops in the code, or whatever.
The GPU can count the noise on its voltage rails or something, like the chaos key (true hardware RNG) does.
Only one of the two should salt its own the key, if both salt it then it's reading garbage.
Really it's not terribly hard to lock everything down.
I'm not a crypto expert but I think, in general, MITM attack is feasible as long as we can control one end of the two communicating ends (just like malicious root certificate injection to a web browser). And the binary driver should be considered under our control if we reverse engineered enough bits of it. Isn't that right?
Or could you be more kind to describe the communication process in more detail?
Comment
Comment