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.

LTO-Encryption-SPTI

Using SCSI Pass Through Interface (SPTI), I can talk to the drive using Win32 APIs. As the WDK sample driver is licensed MS-PL, any derivative source code also has to be licensed MS-PL but any object code or executables compiled from that code can be licensed using a compatible licence such as the MIT licence. It will require more work, but the result won't be constrained by the GPL/AGPL licensing terms.

I have started work on LTO-Encryption-SPTI, although the current stage of development is working out how to communicate with the drive, how to read SCSI CDB definitions/descriptions in the manual (and elsewhere), and how to implement specific CDBs.

At the time of writing I have got SCSI_IOCTL_DATA_IN SRBs working to read pages (i.e. SECURITY_PROTOCOL_IN CDBs), and am trying to decode the manual for SECURITY_PROTOCOL_OUT CDBs such as setting the encryption key.

LTO-5 introduced RFC 3394 (RSA-2048 wrapped AES keys) support so I am trying to work out how to use wrapped keys first. By using wrapped keys, the tool handing encryption keys to the drive via SPTI won't actually see the AES key, so I can put off thinking about secure inter-process communication (IPC).

This needs some work, but my current thinking of the process for enabling encryption:

1. Does the drive know about encryption? SCSIOP_SECURITY_PROTOCOL_IN
2. What encryption does the drive know about? SCSIOP_SECURITY_PROTOCOL_IN/SECURITY_PROTOCOL_INFO
3. Does the drive know about tape encryption? SCSIOP_SECURITY_PROTOCOL_IN/SECURITY_PROTOCOL_INFO/SPIN_PROTOCOL_LIST
4. What tape encryption algorithms does the drive know about? SECURITY_PROTOCOL_TAPE/SPIN_TAPE_ENCRYPTION_CAPABILITIES
5. Does the drive support plaintext keys? Wrapped keys? SECURITY_PROTOCOL_TAPE/SPIN_TAPE_SUPPORTED_KEY_FORMATS
6. If the drive supports wrapped keys, what is its RSA-2048 public key? SECURITY_PROTOCOL_TAPE/SPIN_TAPE_WRAPPED_PUBKEY
7. TODO: Enable encryption.