Media Encryption

Navigation:  Pandoras Box > User Interface - Master > Tabs Overview >

Media Encryption

prev main next

Navigation:  Pandoras Box > User Interface - Master > Tabs Overview >

Media Encryption

prev main next


Pandoras Box Media Encryption is a technology that encrypts media in order to protect content from being played back by unauthorized persons or systems without permission.
Please note, that the optional Media Dongle, that adds extra security to the encryption feature, is discontinued until further notice.


With a Pandoras Box Master you can choose to encrypt media by generating two ASCII strings. The Media Encryption is based on AES 256-bit technology similar to the DCI Digital Cinema Standard, which means you will get the same powerful level of encryption that most governments use for secret documents.
Currently, MPG (including MXL, M2V, ...) and WAV files are supported. Encrypted media obtains the ending ".mpx" or ".wax".

Please note, that the 64bit version of Pandoras Box introduced with version 6.4, uses another encryption algorithm. Hence, those encrypted media files can only be decrypted with another 6.4 (or higher) PB system. In return, media files encrypted earlier can only be decrypted with a version below 6.4.


Any Pandoras Box system, either Master or Client, is able to decrypt the media with the correct ASCII strings while playing it back:

The content gets decrypted on the fly when being played back on the timeline or as an active value. There is no decryption period beforehand, thus there is no decrypted version of the content on your hard drive. Each frame needs to be decrypted (except the thumbnail). Only PB systems are able to understand the ASCII string and decrypt the media !

Of course, encrypted content cannot be exported using the Video Export feature. In return it is possible to encrypt an exported video itself.

Policies, Keys and the Media Dongle

The encryption is based on two different ASCII strings - the key string and the policy string. At all times, the end customer needs both to decrypt media.
The key itself encrypts the content. The media "remembers" which key can unlock it. If you encrypt the same content with two different keys you will get two different encrypted files.
The policy holds meta information regarding the validity of a key. A key without meta information cannot be used, in return, meta information without the key is useless as well. Currently the only meta information is the time stamp. You can either decide to have no time restriction or to create a string that can only validate the key for a certain time.
As described later on, it is possible to modify a policy, e.g. if you need to extend the validity. That means that the customer keeps the same encrypted media file and the same key, only the policy will be updated.


In case of a time-based encryption, you can save and transfer the policy as a "digital policy" or as a "dongle policy" meaning that it is written onto a Media Dongle. Until further notice, the Media Dongle is discontinued and cannot be purchased.
Working with a Media Dongle will give you the safest encryption solution possible. The Media Dongle holds the definite time reference itself and does not refer to the system time. The Media Dongle is more secure in other terms as well. As seen in the image above, you can transfer the strings (key string and policy string) in different ways to the customer, including the possibility to send both via email. In that case you have no chance to control whether he sends them to somebody else as well. If you choose to export the policy to a Media Dongle and send it via mail, the customer needs to have that special hardware. You have created the necessity of a physical key which cannot be copied.

It is possible to create content, encrypt it once with a key and create two different policies, both being allocated to the same key. Let´s say the unlimited policy is written onto a Media Dongle and a time-based policy is a more simple "digital policy". You will then have one encrypted file, one key string but two policy strings.
You may then send one media file, one key and one Media Dongle to the show operator. He will be only able to play the content on a PB system if the Media Dongle is inserted. The other media file, key and (time-based) digital policy goes to the customers in the event agency. They will be only able to play the content on a PB system within a given time limit. They may as well send the key and policy to another person.
Of course you can encrypt as many files as you wish with the same key. In this scenario it has the following advantage: Now, as soon as the agency or the operator want some changes to be done, you can encrypt new content with the key and send only the media files to the two parties, both being in possession of the key and being restricted to their policy version.

Please note that currently only one Media Dongle per system is read and each dongle can hold only one policy. Likewise only one digital policy can be assigned to each PB system. As a result,one dongle policy plus one digital policy can validate two keys per PB system.

In the future it might be possible to create meta information such as a fixed MAC addresses etc. If you want to contribute your feedback to this new feature please contact the support team.

The difference between a creator key / policy and an user key / policy is described in the following chapter.

Media Dongle hardware specifications:
- Battery Life Warranty: 4 Years
- Real Time Clock Accuracy (@ 25°C  +/- 5°C)  < 12.8 minutes/year
Consequentially, we recommend to factor 13 minutes per year into your time limits.