LTO Encryption

The LTO-4 specification added hardware encryption to LTO. Supporting encryption is optional, but drives must recognise encrypted tapes (i.e. an LTO-4 drive that doesn't support encryption might just spit out encrypted tapes). Although it is optional, Wikipedia states that all drive manufacturers have added encryption support. This optional part of the specification can therefore be assumed to be universally implemented on all drives.

LTO encryption is done at the hardware (tape drive) level, and my HP 6250 has an encryption LED on the front. Looking at the manual, this LED in combination with the Ready LED conveys 6 states:

• ON: At power ON
• OFF: The drive is idle and there is no encryption key
• OFF with Ready flashing green: The tape drive is reading/writing unencrypted data or unloading a cartridge
• ON (Solid blue):
  • The drive is idle but the encryption key is loaded
  • The drive is ready to read/write encrypted data
• ON (Solid blue) with Ready flashing green: The drive is reading/writing encrypted data
• Alternate flashing, blue and amber:
  • There is an encryption related error
  • This is cleared after unload executes or successful encryption/decryption resumes

It is probably worth noting that the encryption LED is not included in any of the diagnostic/flash codes which only use the other four LEDs. If the encryption LED is blue and not flashing, an encryption key is loaded into the drive.

LTO uses AES-256 symmetric encryption in AES256-GCM mode. Virtually all of the drive/tape management software makes key management (and therefore encryption) a paid option. To me this doesn't make sense as proper offsite storage would almost certainly entail encrypting the data before even thinking about taking it offsite.

STENC (GPL-2.0 License) is a Linux tool for LTO encryption, with a Windows derivative called LTOEnc (AGPL-3.0 License) also available.

STENC doesn't appear to have an option to use a key directly, requiring the key to be stored in a file. I will have to look into that as I don't intend to have keys stored in files. What I am instead thinking of doing in terms of key management is using something from the world of cryptocurrencies: hierarchical deterministic wallets.

I am going to cover encryption in the page LTO-Encryption-Keys as it will need some thinking through, working out how to correctly implement some Bitcoin/SatoshiLabs Improvement Protocols (BIPs/SLIPs), a number of tests (I will effectively be creating a specification), and a new GitHub project implementing the specification.

The issue I have with LTOEnc is the licence: creating a derivative work would require my work using the AGPL licence, as would anything derived from my work. I'm not a fan of using such licences on my code unless I have no choice, and I do have a choice that doesn't involve paying for a single machine API licence or using an infectious licence.