How to protect the content of captures?

Some use cases have data protection issues were require confidential information to be captured. However in this scenario GrabzIt would become a potential security liability as the capture would be cached on our servers for a period of time.

To keep this information safe you can specify an encryption key, that GrabzIt doesn't store. This key be used to encrypt the capture protecting the information. As we don't store the key we can't help you recover encrypted captures. Once you receive the capture use the key you generated earlier to decrypt it.

To keep the encryption key safe when sending it to GrabzIt ensure that SSL is enabled. If you feel your captures need further protection you can also reduce the amount of time they are cached for down to a minimum of fifteen minutes, by specifying the desired cache length on your account page.

In the example below a cryptographically secure key is created and sent to GrabzIt, this is then used to encrypt the capture. This same encryption key is then used to decrypt the result.

In order to use encrypted captures with Java 6, 7 and 8 please install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files into all of the /jre/lib/security/ folders of the Java installation folders.

In the example below a cryptographically secure key is automatically created and sent to GrabzIt, this is then used to encrypt the capture. This same encryption key is then used to decrypt the result automatically by passing true to the DataURI method, which can then be read in the callback method.

How GrabzIt's capture encryption works

This guide is very technical and aims to help developers understand how our encryption works. It should be of particular use to Perl developers, as the language doesn't have a open source Perl package that doesn't require completion or installation of third party tools like Open SSL.

For GrabzIt to encrypt a capture a base 64 encryption key that 44 characters long needs to be passed to the option object. To create this encryption key you should choose 32 random cryptographically secure bytes. These should then be encoded to base 64. As they are cryptographically secure bytes they will be difficult to predict and therefore harder to crack.

When GrabzIt receives a capture request with a encryption key, the capture is encrypted and the initialization vector (IV) is inserted at the beginning of the file. This IV is 16 bytes long and needs to be removed from the front of the file before decryption. The IV must also be passed to the AES algorithm to enable decrypting. When a capture is encrypted no padding is added to the file so when decrypting padding needs to be disabled.

Remember if you have created an improvement to one of our existing client API’s or for a entirely new language you can share it with the community through github.