-
Notifications
You must be signed in to change notification settings - Fork 75
Encryption Handling in LTFS (Experimental)
You need manage a KEY
as a pair of an encryption key (base64 encoded 256-bit binary, DK[DataKey]) and an key index (3 alphabets + 18digits-hexadecimal text, DKi[DataKeyIndex]) in LTFS.
For example,
- DKi:
IBM0123456789abcdef01
- DK:
YAwK8AGgc/Q6vHt6LoMwz9wlI0wTOLsPsmqxWmLygek=
LTFS store KEY
information to memory at start time and use them when it is required.
In the mount sequence, LTFS tries to read tape without keys at first. And the tape drive will return error with used DKi to LTFS. So LTFS sets back correct DK (searched from returned DKi) to the tape drive and retry read.
In the format process, mkltfs
may check contents of tape before format to avoid unexpected format. So old KEY
information to decrypt current contents and new KEY
information to create new format is required.
Please be careful ! You can't use the tape created in this way in the following scenario. Because you don't have a way to import a key (using this method) to a key server.
- Create a tape with LTFS and simple plugin
- Import the tape created in the step1 a library that is connected to a key server (like IBM TS4500 and IBM Tivoli Key Lifecycle Manager)
- Add the tape into a library supported LTFS (like IBM spectrum archive LE)
- Try to read the tape on the library supported LTFS
Case1 [the tape is not encrypted]:
mkltfs -d /dev/sgx --kmi-backend=simple -o kmi_dki_for_format=IBM0123456789abcdef01 -o kmi_dk_for_format=YAwK8AGgc/Q6vHt6LoMwz9wlI0wTOLsPsmqxWmLygek=
Case2 [the tape is encrypted by IBM10fedcba9876543210]:
mkltfs -d /dev/sgx --kmi-backend=simple -o kmi_dki=IBM10fedcba9876543210 -o kmi_dk=k0I1gsz9Vm3kHOPeTx02AuOGAwfWZFfvK7U76CNTGwg= -o kmi_dki_for_format=IBM0123456789abcdef01 -o kmi_dk_for_format=YAwK8AGgc/Q6vHt6LoMwz9wlI0wTOLsPsmqxWmLygek=
ltfs -o devname=/dev/sgx -o kmi_backend=simple -o kmi_dki=IBM0123456789abcdef01 -o kmi_dk=YAwK8AGgc/Q6vHt6LoMwz9wlI0wTOLsPsmqxWmLygek= [mount_point]
Please be careful ! You can't use the tape created in this way in the following scenario. Because you don't have a way to import a key (using this method) to a key server.
- Create a tape with LTFS and simple plugin
- Import the tape created in the step1 a library that is connected to a key server (like IBM TS4500 and IBM Tivoli Key Lifecycle Manager)
- Add the tape into a library supported LTFS (like IBM spectrum archive LE)
- Try to read the tape on the library supported LTFS
- You can have multiple
KEY
information in it. - LF is the only valid return character
DK=YAwK8AGgc/Q6vHt6LoMwz9wlI0wTOLsPsmqxWmLygek=
DKi=IBM0123456789abcdef01
DK=k0I1gsz9Vm3kHOPeTx02AuOGAwfWZFfvK7U76CNTGwg=
DKi=IBM10fedcba9876543210
Case1 [the tape is not encrypted]:
mkltfs -d /dev/sgx --kmi-backend=flatfile -o kmi_dk_list=[path_to_key_file] -o kmi_dki_for_format=IBM0123456789abcdef01
Case2 [the tape is encrypted by IBM10fedcba9876543210]:
mkltfs -d /dev/sgx --kmi-backend=flatfile -o kmi_dk_list=[path_to_key_file] -o kmi_dki=IBM10fedcba9876543210 -o kmi_dki_for_format=IBM0123456789abcdef01
ltfs -o devname=/dev/sgx -o kmi_backend=flatfile -o kmi_dk_list=[path_to_key_file] -o kmi_dki=IBM0123456789abcdef01 [mount_point]
You can use any ways to convert 256-bit binary to base64. But an example is
dd if=/dev/random bs=32 count=1 2> /dev/null | base64
or
dd if=/dev/urandom bs=32 count=1 2> /dev/null | base64
You can have a random key from /dev/[u]random
Linear Tape File System (LTFS) --> Cool footer image wanted !!
- Quick Start
- Command References
- Logging configuration
- Crash dump setting
- HBA info
- IBM lin_tape driver support
- No item at this time