File encryption techniques

we implement a file encryption scheme where you encrypt a file (aes 256 cbc pkcs#7) and sign it (aes 256 cmac) by using unique keys per file the keys, along with information about the encrypted file contents, are stored in a header at the beginning of the file the file is encrypted and signed in 48 kilobyte chunks that are chained together by using sha 512 hashes each chunk contains a header with a unique initialization vector currently, we support two versions of the file encryption algorithm the main difference between the versions is how the keys that encrypt and sign the file are protected and used version 1 uses keys that the hsm protects directly as x9 24 keys (referred to as hsm trusted keys in the 6 3 1 x nomenclature) to decrypt and verify the file, you must stream the whole file to the hsm because the value of these keys is only accessible on the hsm version 6 1 4 x handles all keys in this way version 2 uses keys that the hsm data encryption keys protect the data encryption keys are x9 24 keys, but you can decrypt the keys they protect into clear values outside of the hsm (known as hsm protected keys in 6 3 1 x nomenclature) this enables you to perform encryption and decryption without streaming the file to the hsm these files are commonly encrypted or decrypted on the client side for performance you must have appropriate access to the hsm to retrieve the clear values of the keys from the encrypted file header, and any client should destroy the clear key values immediately after the encryption or decryption finishes version 1 the version 1 encrypted file uses two aes 256 hsm trusted (x9 24) keys protected as an aes kwp keyblock by an aes 256 hsm trusted key stored on the application server one key is tagged with decryption usage, and the other key is tagged with verification usage the hsm can use these keys only for those specific usages the key stored on the application server is protected as an aes kwp keyblock by the aes 256 platform master key (pmk), tagged with key wrapping and unwrapping usage key management the hsm generates two new random aes 256 keys protected by the pmk one key has encrypt and decrypt usage, and the other key has signing and verification usage the hsm translates both keys to be protected by the key wrapping key associated with the file encryption profile after the translation, the new key blocks contain only the decrypt or verify usage these translated keys are put into the header along with additional information such as the file name, size, hash, and the application identity role performing the encryption operation the pmk wrapped version of these keys encrypts and signs the file and then discards it translating the versions from the file header back to pmk keys and using them to decrypt and verify the file requires proper authorization on the application server version 2 the version 2 encrypted file uses two aes 256 hsm protected keys protected by an aes 256 hsm trusted key stored on the application server the key block format for the keys in the header, a proprietary format ( fxgcm ), uses aes gcm one key is tagged with decryption usage, and the other key is tagged with verification usage the {{futurex}} application server and client libraries respect these usages, but they are meaningless otherwise the aes 256 platform master key (pmk) tagged with data encryption and decryption usage protects the key stored on the application server as an aes kwp key block key management the hsm generates 64 bytes of random data 32 bytes of this data serve as the aes 256 file encryption key, and 32 bytes of this data serve as the aes 256 file signing key the data is encrypted with the hsm trusted data encryption key associated with the file encryption profile by using the {{futurex}} proprietary aes gcm keyblock format, fxgcm we call this key format hsm protected keys these key blocks are put into the header along with additional information like the file name, size, hash, and the application identity role performing the encryption operation the system communicates the plaintext version of these keys with whichever entity performs the file encryption and signing you should destroy the plaintext version of these keys immediately after the file has been protected retrieval of the plaintext keys for decryption and verification requires proper authorization on the application server {{futurex}} file protection format the system encodes the header in excrypt format and computes a 16 byte cmac value over the header, appending it in excrypt format for each 48 kilobyte chunk of the file, a new 16 byte initialization vector is randomly generated for the cbc encryption the block number (monotonically incremented starting at zero), the sha 512 hash of the previous header concatenated with the cmac value, the size of the chunk in bytes, as well as the new iv are encoded in excrypt format as the new block header the next 48 kilobytes of the file data (or however much data remains) are then encrypted with cbc using iv and pkcs #7 padding a 16 byte cmac value is generated over the previous header concatenated with the cleartext value and appended to the end of the block ciphertext if more data exists, then the next block header is generated, and the same encryption and signing scheme repeats until no more data remains