PowerVR encrypted texture data?

[Ailuros]

http://l2.espacenet.com/espacenet/viewer?PN=GB2379299&CY=gb&LG=en&DB=EPD

Any comments Senior Fenney?

PS: No I don't search the ESP on a daily basis. I just saw it in the 3dcenter forums heh.

 

[MfA]

So will programs for this device be prevented from reading back the framebuffer?

 

[rotten]

i dont get it Ail...
where would that b used

 

[tb]

Maybe it has something to do with MS's Microsoft Next-Generation Secure Computing Base (NGSCB) http://www.microsoft.com/resources/ngscb/productinfo.mspx which is very similar to TCPA http://www.trustedcomputing.org ....


Thomas

 

[Basic]

Interesting reading.

I can't comment on the cryptographical strength of the system. But I can say one consequence:
Bye bye to compressed textures (other than DXTC and other methods that is local and stay completely within the chip). So you can't have lots of jpeg textures that is decompressed when a level loads.

 

[Malo]

forgive my naivity but what do compresed textures have to do with encryption? why would compressed textures not be viable anymore?

 

[Xmas]

forgive my naivity but what do compresed textures have to do with encryption? why would compressed textures not be viable anymore?

Basic means lossy compression on disk. Obviously you can't use lossy compression on data that is to be decrypted by the GPU.

 

[Malo]

ah ok thanks for clarification.

 

[Basic]

Yes, Xmas got what I meant.
You can't use lossy compression on encrypted data, beacuse it will destroy the data completely.
Furthermore, if the encryption is worth anything, you can't use lossless compression on the encrypted data either. Well you can, but the data won't be smaller after the compression.

A good encryption will convert the data to what looks like white noise, and white noise doesn't compress.

So the important part is that the compression/decompression is done on the plain text side of the encryption (inside the chip).

 

[tb]

Yes, Xmas got what I meant.
You can't use lossy compression on encrypted data, beacuse it will destroy the data completely.
Furthermore, if the encryption is worth anything, you can't use lossless compression on the encrypted data either. Well you can, but the data won't be smaller after the compression.

A good encryption will convert the data to what looks like white noise, and white noise doesn't compress.

So the important part is that the compression/decompression is done on the plain text side of the encryption (inside the chip).

Don't get it yet. Why not compress a texture at load time or load a compressed texture, encrypt it and send it to the vpu. It decrypts the texture and then decompress it.

Thomas

 

[KimB]

Basic means lossy compression on disk. Obviously you can't use lossy compression on data that is to be decrypted by the GPU.

I'm not sure why not. Just encrypt the already-compressed data.

Anyway, I would just like to state that encryption of textures makes a lot of sense, when one considers that Windows will soon go all-3D. For high-security applications, the video card interface would be entirely too easy for an invader to tap for data (imagine that every window will be its own texture...even text documents).

Of course, there are other, easier ways to get to the data, but those can also be more easily hidden by encryption.

 

[Xmas]

Don't get it yet. Why not compress a texture at load time or load a compressed texture, encrypt it and send it to the vpu. It decrypts the texture and then decompress it.

Thomas

And which GPU does JPEG decompression?
Yes, it would be possible to DXTx-compress a texture, encrypt it and store it on disk. But you cannot use any non-hardware supported compression scheme for storage.

 

[Ailuros]

i dont get it Ail...
where would that b used

That's why I posted it here, in order to get -if it's possible- an answer from SimonF himself.

Until he or someone else from the company replies though, I can only rely on my own lucky guestimates.

One good candidate in my mind would be the MBX chips for PDA/mobiles. I don't know what companies exactly intend to do with it, but since it has strong 3D capabilities for it's size, I'd think of cases like let's say downloadable applications/games from the Internet for those devices (game ports to be exact). There it makes even more sense to attempt to build in an effective copy protection scheme.

Could be completely wrong though, so don't count on it.

 

[Ailuros]

But you cannot use any non-hardware supported compression scheme for storage.

Might be a dumb question, but does that apply for PVR-TC too?

 

[Arun]

IMO, this is a very good concept.

I think a very interesting quote recently was one of David Kirk - stating that a certain company managed to use their GeForce FX GPU ( 5800 one, that is, or maybe Quadro equivalent ) to reorder a database - and that it was *5* times faster than on a Pentium 4!

But if you're beggining to use that type of applications with GPUs, you obviously may want more security - Chalnoth's "imagine that even text documents are a texture" seems a little strange, I doubt MS will go that way - but I'm sure there could be security issues.


Uttar

 

[Simon F]

http://l2.espacenet.com/espacenet/viewer?PN=GB2379299&CY=gb&LG=en&DB=EPD

Any comments Senior Fenney?

PS: No I don't search the ESP on a daily basis. I just saw it in the 3dcenter forums heh.

Well I was going to say "haven't you got anything better to do?" but you pre-empted me

So will programs for this device be prevented from reading back the framebuffer?

Preferably, yes, since that could reduce the strength of the scheme, but it would not be mandatory. Of course, since each application effectively has it's own key, the developer could trade security for flexibility.

Interesting reading.

I can't comment on the cryptographical strength of the system. But I can say one consequence:
Bye bye to compressed textures (other than DXTC and other methods that is local and stay completely within the chip). So you can't have lots of jpeg textures that is decompressed when a level loads.

Not at all. It's the raw data that is encrypted, not actual pixels. I simulated it with PVR-TC textures and decompressed random noise looks 'quite odd'.

One good candidate in my mind would be the MBX chips for PDA/mobiles. I don't know what companies exactly intend to do with it, but since it has strong 3D capabilities for it's size, I'd think of cases like let's say downloadable applications/games from the Internet for those devices (game ports to be exact). There it makes even more sense to attempt to build in an effective copy protection scheme.

Could be completely wrong though, so don't count on it.

That's pretty much the idea - as the patent says, there may be no physical medium for the application/game (not that that's stopped hackers in the past) and so electronic-only versions may be very easy to copy otherwise.

 

[PrzemKo]

Hmm... maybe it's for military or something. When the chopper crashes, for example, and is not completely destroyed, someone from the 'other side' could extract data from it's nav systems. Crypted textures used in maps would add another bit of security in such situations.

 

[Simon F]

Hmm... maybe it's for military or something. When the chopper crashes, for example, and is not completely destroyed, someone from the 'other side' could extract data from it's nav systems. Crypted textures used in maps would add another bit of security in such situations.

You guys must read far too many conspiracy theories!

 

[PrzemKo]

Do you think? It's quite common to scoop parts of enemy weapons and reverse-engineer them, but in this case it's more about short-time tactical info. If you have access to a nav system of your enemy, you could find some very useful stuff, like what they know about you, how good their maps are, etc. Crypted textures and coordinates will make that job pretty hard...

 

[DemoCoder]

The purpose is quite obvious: it's for digital rights management. The media industry is attempting to encrypt everything from the time it comes from the hard drive all the way to the moment it goes to your video screen, they want the data encrypted to stop digital piracy.

To stop future DVD formats from being ripped, the content will be encrypted on DVD as before, but will be decrypted only by a hardwired chip (e.g. GPU or dedicated chip) for decoding and display. However, the output from the display will be reencrypted and only your monitor can decrypt it. This prevents digital capture and thus the only way to pirate is to point a video camera at the screen.

Already HDTV displays are shipping with DVI HDCP connectors and there are DVD players that have HDCP out, so that the DVD and HDTV have a private encrypted channel for data.