File Security Code Snippet
Two separate security features are combined:
- Encryption so nobody without the secret key can read the data
- Authentication to protect files from data modification.
EncryptionThis uses the Venom encrypter object. The encryption key is derived from a shared secret embedded in the code and an 8 byte file header, which is generated in a way that minimises the possibility of two values ever being the same. The encrypter's built-in key derivation algorithm is used: this uses the SHA256 hash algorithm to ensure the encryption key is decorrelated from both the shared secret and the 8 byte file header, and by applying 1000 iterations of the hashing process (the default in the encrypter's
Keymessage) helps to make a brute-force attack impossibly time-consuming.
AuthenticationA weakness of any stream cipher like that used in the Venom encrypter object is that it gives no protection against modification of the data by blindly modifying the ciphertext: a simple bit-flip anywhere in the ciphertext maps to a corresponding bit-flip in the plaintext.
To detect tampering with the file, a authentication signature must be generated from a combination of the file and some secret data. A simple checksum or CRC protects against accidental corruption, but is too easy to recreate by an interceptor who has modified the data.
In this example we have created, in a separate file hmac.vnm, an HMAC generator class. HMAC stands for Hash-based Message Authentication Code, and is a standard method for applying a chosen hash algorithm and shared secret to a message in a way that has been shown by extensive cryptographical analysis to make tampering impossible. It is much more secure than simply hashing the concatenated data and secret, and is fully explained in Wikipedia on HMAC.
hmacgen class can be used by itself for any data
Putting it All togetherIn the demonstration program, the encrypted file has the following structure:
|8 bytes||Header (different for every instance generated)|
|Any length||Encrypted file data|
|32 bytes||HMAC - digest of header and encrypted data|
Generating the headerThe object of the exercise is to produce a different value every time the code is run. In the example, we try to use the real time clock-calendar to get a time/data value; failing that, we try to get time information from the internet, and if that also fails, we use the system microsecond timer (
system.time(0)). This provides 4 bytes; the next 4 bytes are generated by a randomnumbergen object which is set to be seeded with as much unpredictable system information as possible. In some systems a simple counter might suffice to generate a sequence of unique numbers.
Generating the SecretThe secret data is not stored directly in a constant global array; this would be too easy to find by analysing the compiled venom code. Instead a function combines two arbitrary strings of text and returns a freshly created array of 32 x 8 bit integers containing the secret data. The program stores the array in a local variable and destroys it as soon as it has been used, so any kind of direct hardware access to the VM2 would have a very limited window of opportunity to see the data in memory.
ApplicationsFile encryption could be used to send out firmware updates to VM2 installations; the program would decrypt the file to a .VFU (Venom Firmware Update) file containing the new program. This way your code cannot be stolen by competitors.
File encryption could also be used to encrypt configuration files. This would enable a configuration file to contain sensitive data such as identifiers, passwords etc which could not be read from the file or changed by third parties.
The same encryption and authentication methods can be used for data communicated over a serial or TCP link in other applications.