Understanding Client Side Encryption - ISP 8.1.2

[ILCattivo]

So I believe things have changed recently with the way Spectrum Protect 8.1.2 now handles client side encryption.

I have read various IBM KB's on the subject but still need to get my head around a few points..

If these are the settings within a client opt file... (Windows)

ENCRYPTKEY SAVE
ENCRYPTIONTYPE AES256
INCLUDE.ENCRYPT *:\...\*

1. Does the encryption key file change each time a backup session is initiated (scheduled)?
2. If I wanted to protect this encryption key file, what is it called (assuming it sits in the 'baclient' directory) and how often do I need to copy it off of the server where it currently resides? Am fully aware that losing an encryption key file due to a downed server can be catastrophic in terms of data recovery.

Thanks

 

[marclant]

Does the encryption key file change each time a backup session is initiated (scheduled)?

No because it's set to save, you are prompted the first time and it's saved in TSM.sth.

If I wanted to protect this encryption key file, what is it called (assuming it sits in the 'baclient' directory) and...

https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.2/client/c_secure_pwd.html

how often do I need to copy it off of the server where it currently resides?

If you lose the file, but know the encryption key, you can still restore without the file.

 

[ILCattivo]

No because it's set to save, you are prompted the first time and it's saved in TSM.sth.

https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.2/client/c_secure_pwd.html

If you lose the file, but know the encryption key, you can still restore without the file.

Thanks marclant, exactly the info I was after.
Helpful as ever.

 

[Trident]

Just a small commecnt.

.sth is a stashed password file that unlocks a .kdb file, while .idx is a index file.

 

[ILCattivo]

Just a small commecnt.

.sth is a stashed password file that unlocks a .kdb file, while .idx is a index file.

While the 'IBM 8.1.2' link provided by marclant specifies these files named as 'TSM.' having tested this today these files are nowhere to be found within the 'baclient' directory?

Instead all 3 are located here 'C:\ProgramData\Tivoli\TSM\baclient\Nodes\DEMO\ISPServer' <--- Protected by the OS & hidden.

Having applied the key password today, this morning - 10/11/2017 (British date format), only TSM.IDX & TSM.KDB have a modification date of the time I applied the key password. TSM.STH has a modification date of 2 days ago?

So consider the following scenario based on what I found above.. If the user who set the original key password forgets or mislays it. Will he\she require all 3 of these files within the above location in order to get to the encrypted data to restore it, in the event that a particular client server had to be rebuilt from scratch and the ISP 8.1.2 BA Client re-installed a fresh?

 

[marclant]

Unless they remember the encryption key they typed and the node password, the latter can be reset.

Also, not sure it will work to just copy the file of restoring from a different machine, ie different hostname which may be needed in some DR scenarios.

Worth testing

 

[ILCattivo]

Unless they remember the encryption key they typed and the node password, the latter can be reset.

Also, not sure it will work to just copy the file of restoring from a different machine, ie different hostname which may be needed in some DR scenarios.

Worth testing

And these are exactly the questions I am being asked. These DR scenarios can be a bit of a faff to test when the actual production client server is still LIVE and thus changing NODE passwords restoring from a different host to test it will result in a mismatch of node passwords between the ISP Server and original prod client server.

Best probably to do this kind of testing in an isolated lab, doesn't help when a paranoid customer wants to test the scenario himself though.

Thanks marclant

 

[droach]

ILCattivo, just wondering if you did any more testing...

Ok, so let's say I have "ENCRYPTKEY generate" in my client's dsm.opt file along with the other requisite encrypt statements. I perform encrypted client backups and restores and I never know the encryption key password. Life is good. Then one day the client fails to boot and we need to perform a bare metal restore. How will this be possible?

 

[Trident]

The encryption password is stored within your Spectrum Protect server when using 'generate'

https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.4/client/r_opt_encryptkey.html

 

[droach]

Trident, thanks for the reply. I was under the impression that the encryption/decryption process required a sharing of keys/passwords between the client and the server. I guess that is only if I use 'save' or 'prompt' with encryption.

So if I am using 'generate' for a client, and a hacker gains access to my TSM server (and TSM) they can easily setup a client and impersonate my encrypted client, then restore all of the encrypted files to his imposter client. I am trying to prevent this without having to save/store passwords for clients.