encrypting assets (video files) in Adobe AIR

I am trying to create a video player in Adobe AIR. I want to encrypt the video files so that they are not sharable outside the player. I don't want to jump through hoops to create a rock-solid system but something simple that just prevents 90-95% of the users from sharing the content.

I have been through a related question on SO at File Protection in Adobe AIR (Flex)

However since the Video file size would definitely exceed 10 MB, the above does not seem to be the solution.

There are a number of solutions to encrypt text strings but I have not found any that encrypt files. Any help or pointers will be appreciated.

Many thanks.

Update: We are trying to achieve this in the following manner:

1. encrypt/jumble the first 50 binary characters of the video file and store on the hard drive. this makes the file unplayable.
2. on runtime decrypt the first 50 characters to get the original file and copy it in a temp folder on the hard drive.
3. on exit, delete the decrypted file and empty the temp folder.

this solves most of our problems. It does 开发者_开发技巧not allow sharing by simple copy and paste. Is a simple solution, though maybe not very elegant.

The problem we are facing now is that the temporary folder is not getting emptied. The file lands up in the recycle bin and can be easily recovered from there!

---

I solved this for a DVD application encrypting all the assets in the DVD and executing a HTTP Server inside the AIR application that decrypts it.

It works in this way:

1 - The images, videos, or assets are encrypted and saved anywhere, in our case the DVD assets folder with a master key.

2 - The Air application contains inside a very simple HTTP server who reads the file decrypts it and send it only to the same Air application using a simple Flash Video Player or using a tag like <img src="localhost:5050/assetcode.jpg">

The code used inside the air application to serve the file is like:

import com.hurlant.crypto.prng.ARC4;
            import com.hurlant.util.Hex;
            import com.hurlant.crypto.Crypto;
            import com.hurlant.crypto.symmetric.ICipher;
            
            var key:ByteArray = Hex.toArray(Hex.fromString("masterkey"));
            var rc4:ARC4 = new ARC4(key);
            
            var fs:FileStream = new FileStream();
            fs.open( content, FileMode.READ );
            var ba:ByteArray = new ByteArray();
            
            
            fs.readBytes( ba, 0, fs.bytesAvailable );
            ba.position = 0;
            fs.close();
            
            
            
            rc4.decrypt(ba);
            //cipher.decrypt(ba);
            
            innerSendHTML(s, ext2mime[content.extension], ba );
            
            ba.length = 0;

We use the RC4 algorithm because it's the faster in our tests.

For the HTTP Server we used a sample http application from the Flash Camp 2010, you could find it in google.

Regards

--

www.imaginacolombia.com

---

What you're describing is 'Digital Rights Management', and AIR does support this kind of thing, which you can read more about here:

http://help.adobe.com/en_US/AIR/1.5/devappsflex/WS5b3ccc516d4fbf351e63e3d118676a5be7-8000.html

DRM is a thorny issue these days, so it might be worth considering whether you really need DRM or whether you can do without it.

---

Can you authenticate the files when the files are downloaded in PHP or some other scripting language? You could force the SWFs to require a parameter to be passed in via post or something (untested however), which most other players wouldn't do .....

You could then reduce the server load on the server pushing the file using the http header X-sendfile or a similar equivalent ...

---

What you could do is:

(1) Read the first 1000 bytes of the file.
(2) Store those 1000 bytes in an encrypted sqlite database, or the Encrypted LocalStore.
(3) write 1000 empty bytes to the beginning of the file.

By now, the file will not open if you double click it. Although most of the data is still there, most people will have given up.

When you need the file:

(4) Retrieve the stored 1000 bytes and
(5) Write them back to the beginning of the file.

When finished, repeat steps 1-3.