PowerVR encrypted texture data?
- Thread starter Ailuros
- Start date
Captain Chickenpants
Regular
Why not Brits?
Maybe: why US and Japan? Behind most of DRM lobbying and "initiatives" stands RIAA, and similar thing can be told about japanese Sony. The later is well known for "protecting" people form doing too much stuff with their hardware. How do you think, why after all these years of producing mini-disc players and recorders you can't record any digital data on this medium? After all, they are relatively cheap discs with around 100 MB capacity (5 times cheaper than LS or ZIP), and... well, only way to record on them something from the computer is to use some strange USB-analogue converter. Sony fears that digital copies on MDs would hurt their CD sales, that's all.
Other parts of the world seems to just follow the trend, so I'm surprised about that move from the UK company (and I'm looking for other explanations).
Other parts of the world seems to just follow the trend, so I'm surprised about that move from the UK company (and I'm looking for other explanations).
Captain Chickenpants
Regular
Just because these things are being pushed by Us and Japanese companies, does not mean that they should be the ones to implement them.
To stay competitive you need to be bringing techonologies to market quickly (first if you can).
I don't think it is (I may be wrong though).
All an ecryption scheme needs to do is to encrypt the compressed data.
The decryption should give a bit perfect duplicate of the compressed data, you then decompress it as normal.
As a test:
Take a jpeg image.
Encrypt with PGP.
Decrypt,
Compare decrypted image with original, it should be identical.
CC[/quote]
To stay competitive you need to be bringing techonologies to market quickly (first if you can).
I don't think it is (I may be wrong though).
All an ecryption scheme needs to do is to encrypt the compressed data.
The decryption should give a bit perfect duplicate of the compressed data, you then decompress it as normal.
As a test:
Take a jpeg image.
Encrypt with PGP.
Decrypt,
Compare decrypted image with original, it should be identical.
CC[/quote]
Hmm... on the other hand, maybe PowerVR wants people to use their chips for general cryptography? Creative is marketing versions of P10 with "photo-stitching accelerator" banner, so maybe this one would be crypto-accelerator, "perfect for all your secure needs"... 
Simon: It simply looks that way (military or MPAA stuff). Maybe it's about disabling screen capture, maybe it would be harder to break DVD or other protection when you have both Palladium and this, who knows? Protecting downloadable games can be done with other measures, and I'm not sure if integrating that into the GPU would be the best solution.
Simon: It simply looks that way (military or MPAA stuff). Maybe it's about disabling screen capture, maybe it would be harder to break DVD or other protection when you have both Palladium and this, who knows? Protecting downloadable games can be done with other measures, and I'm not sure if integrating that into the GPU would be the best solution.
Basic said:
I had my suspicions that it's actually targeted for MBX mostly, hence the immediate question about PVR-TC. Why would games ported for the MBX, even more those using MGL use anything else than PVR-TC?
AFAIK PVR-TC will be present in other future products too, yet I'm not so sure that the copy-protection/encrypting texture scheme would make as much sense YET for other markets.
*keeps notes for future goals* try to find a way how to read framebuffers
PrzemKo said:
General purpose cryptography can be done adequately fast with a CPU.
Did you read the patent at all? Putting it into the accelerator could mean that protection is independent of the CPU - it would even allow the ISVs to allow the 'Mod community' to do customisations, since they could protect a certain number of base textures and let the enthusiasts tweak other textures. It seems to me that it would me more difficult to do with an encrypted CPU <shrug>
Cheers but it was over 18months ago so who knows what my addled brain can remember.JohnH said:
The protection of the FB was to try to make 'known plaintext' attacks more difficult.Ailuros said:
Doing the decrypt on the GPU is more tamper resistant than on the CPU. Even a CPU with special trusted-code execution hardware has too many avenues to attack from, especially if the decrypt code has a bug.
There is less chance someone can upload code to the GPU or to attack with HW like ICE, because GPU architectures aren't published and are far more constrained.
Now I could see someone hacking PowerVR's driver on the CPU, getting the chip to decrypt, and then having the texture rendered somewhere for capture. They'd have to "tag" the decrypted data so any decrypted pixel remains "tainted" and any attempt to read it back to the CPU is prevented. Of course, anything that reads tainted data becomes tainted itself. They could also just disallow any screen capture of any kind, period.
But I think they would have to stop people from putting probes on the video memory bus and picking up the data as it is written to the FB, probably by reencryption.
Which algorithm you using? DES? 3DES? AES? RC4? With DES in ECB mode you could even do random access.
There is less chance someone can upload code to the GPU or to attack with HW like ICE, because GPU architectures aren't published and are far more constrained.
Now I could see someone hacking PowerVR's driver on the CPU, getting the chip to decrypt, and then having the texture rendered somewhere for capture. They'd have to "tag" the decrypted data so any decrypted pixel remains "tainted" and any attempt to read it back to the CPU is prevented. Of course, anything that reads tainted data becomes tainted itself. They could also just disallow any screen capture of any kind, period.
But I think they would have to stop people from putting probes on the video memory bus and picking up the data as it is written to the FB, probably by reencryption.
Which algorithm you using? DES? 3DES? AES? RC4? With DES in ECB mode you could even do random access.
From the first diagram it looks like the data on memory bus is already encrypted, so probing wouldn't help that much.
Im still under impression, that such measures aren't too friendly. I'd accept only using it against game cheaters, bechmark cheaters, etc. On the other hand, if someone would manage to use on-chip crypto engine with advanced PS, possibly with minimal CPU assistance, he could create quite powerful code-breaker... Err... latest PS and PowerVR, on silicon? Sounds like a distant future...
Im still under impression, that such measures aren't too friendly. I'd accept only using it against game cheaters, bechmark cheaters, etc. On the other hand, if someone would manage to use on-chip crypto engine with advanced PS, possibly with minimal CPU assistance, he could create quite powerful code-breaker... Err... latest PS and PowerVR, on silicon? Sounds like a distant future...
DemoCoder:
Random access is a must for textures, so they have to go for the lesser mode (ECB).
The patent didn't explicitly detail what cipher to use (other than an ECB mode salted with position), but it did mention TwoFish as an example. That's an AES candidate that didn't make it. I assume the patent was filed before AES was settled, and now they would use Rijndael instead (the final AES).
Random access is a must for textures, so they have to go for the lesser mode (ECB).
The patent didn't explicitly detail what cipher to use (other than an ECB mode salted with position), but it did mention TwoFish as an example. That's an AES candidate that didn't make it. I assume the patent was filed before AES was settled, and now they would use Rijndael instead (the final AES).
Before I realized they left textures encrypted in video memory, I thought perhaps they decrypted as the textures loaded. Of course, if they stay encrypted, ECB is the only mode possible, or some variation of (say, "partial CBC", chain every N blocks. If your cipher is 64 or 128-bit, you're already dealing with something that is the same as granularity of your bus (e.g. if you have a LMA style 256-bit split into four) so partial CBC gains you nothing.
Rijndael is actually way more efficient to implement in hardware than TwoFish and the other candidates. It's only slightly more complex than DES and it's critical path latency is much lower.
Rijndael is actually way more efficient to implement in hardware than TwoFish and the other candidates. It's only slightly more complex than DES and it's critical path latency is much lower.
Yes - it would help stop known-plaintext attacks. Of course, a good modern cipher still resists that sort of attack.DemoCoder said:
The algorithm wasn't specified but DES or AES would be recommended. I would think that 3DES would introduce too much latency, and isn't RC4 a stream cipher? That would make random access difficult.
ECB on its own would be much weaker as groups of the same texels (quite likely in textures) would stand out in the cipher text.
The patent points out that you can individually salt each block.Basic said:
It'd probably be recomended, but an IHV might want a different algorithm <shrug>.