Delete Encryption Key from TSM-Database

dcz01

ADSM.ORG Senior Member
Joined
Feb 18, 2014
Messages
58
Reaction score
3
Points
0
Location
Germany
PREDATAR Control23

Hello together,

is there a way to delete an saved encryption key from the tsm database (saved on the client and the server with the dsm.opt option encryptkey generate)?
the client was restored by bmr complete and has now the option encryptkey save set.
but old files which are encrypted can be restored without passwort prompt.
 
PREDATAR Control23

If the encryption was enabled when data is backed up, you need the encryption key in order to retrieve or restore the data.

In other words, you cannot delete. Deleting the key also requires the original key for the procedure to be processed.
 
Last edited:
PREDATAR Control23

i know that.
but the problem is that the tsm server knows about an password which it shouldn't know...
therefore i must delete this password for the old encryption from the db.
because if i want to restore some individual-related data which noone else should be able to restore, the tsm server decrypts it automatically for me with the password stored in the db (by the old option encryptkey generate).
 
PREDATAR Control23

i know that.
but the problem is that the tsm server knows about an password which it shouldn't know...
therefore i must delete this password for the old encryption from the db.
because if i want to restore some individual-related data which noone else should be able to restore, the tsm server decrypts it automatically for me with the password stored in the db (by the old option encryptkey generate).

If you don't want encryption anymore, then remove the encryption option on the dsm.opt file so encryption is not applied.

If you use the default setting, the TSM DB should know the key for it to work properly. If you need only some files to be encrypted, then apply encryption only to those files.

If you need to be prompted for the key then say 'prompted' instead of 'generate'.
 
PREDATAR Control23

yes, we changed it already from generate to save so that the client only saves the password for encryption every time.
but if i restore some old data, and i don't know the password, the server decrypts the data for me without promting for an password...
so now anyone can/could restore that data which shouldn't be. so the question was how can i remove the old key from the server?
the server also exports the encryption key with an export node command...
 
PREDATAR Control23

the server also exports the encryption key with an export node command...
The TSM server does not encrypt or decrypt data, that's all handled by the client. When the client encrypts a file, the file is encrypted before it is sent (think of a password protected zip). So when restoring an encrypted file, in order to decrypt the file, the client needs the key, which if it's stored in the registry will use or will prompt if it is not.

When you use save the encryption key, it is saved in the registry during the backup. If you do a BMR, you would restore systemstate, which inlcudes the registry, which includes the saved encryption key.

You can delete the encryption key saved in the registry so that you are prompted instead. DO THIS AT YOUR OWN RISK, I CAN'T HELP YOU IF YOU DELETE THE WRONG THING.

Go to this key in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes\{Nodename}\{TSMServer_name}
Delete the value "Encrypt"

the server also exports the encryption key with an export node command...
No it does not, but any data that is encrypted will remain encrypted during an export. And if a client tries to restore that data and has the encryption key already, it will be able to decrypt it.

And are you 100% sure the data is encrypted? Go in the GUI, click on Restore, find one of the files, right-click on it and select File Details. The encryption type will NOT be blank if encrypted:
upload_2016-2-29_11-11-43.png
 
PREDATAR Control23

here i have the difference for you:
save
The encryption key password is saved in the Tivoli Storage Manager client's password file. A prompt is issued for an initial encryption key password, and after the initial prompt, the saved encryption key password in the password file is used for the backups and archives of files matching the include.encrypt specification. The password can be up to 63 bytes in length. The key is retrieved from the password file on restore and retrieve operations.
generate
An encryption key password is dynamically generated when the Tivoli Storage Manager client begins a backup or archive. This generated key password is used for the backups of files matching the include.encrypt specification. The generated key password, in an encrypted form, is kept on the Tivoli Storage Manager server. The key password is returned to the Tivoli Storage Manager client to enable the file to be decrypted on restore and retrieve operations.
http://www-01.ibm.com/support/knowl..._opt_encryptkey.html#r_opt_encryptkey?lang=en
 
PREDATAR Control23

The generated key password, in an encrypted form, is kept on the Tivoli Storage Manager server.
My mistake, you are right, it's also stored on the server. However, it's not stored to give it to the client to decrypt, but rather for the client to use to confirm that it has the right encryption. So if the saved key matched the key passed by the server, the restore works. If not it fails and will prompt you.
 
PREDATAR Control23

no it doesn't fail and i can restore anything... i tested it and therefore i want to delete it from the tsm db.
 
PREDATAR Control23

for testing i'm on another client which has no encrypt password stored in registry.
i'm using the dsm -virtualnode command for logging on the server.
and here is an file which is encrypted but i where able to restore it without entering an password:

1.jpg
 
PREDATAR Control23

It's possible that with "encryptkey generate" the protection of the encryptkey relies on node authentication. So if you restore from the same node that it does the backup, it decrypts the data. If that is the case, you may want to use password prompt for the client if that client is not using a scheduler to prevent restores.

In the future, sounds like "encrypkey save" would be closer to what you want.
 
PREDATAR Control23

It's possible that with "encryptkey generate" the protection of the encryptkey relies on node authentication. So if you restore from the same node that it does the backup, it decrypts the data. If that is the case, you may want to use password prompt for the client if that client is not using a scheduler to prevent restores.

In the future, sounds like "encrypkey save" would be closer to what you want.

I would say that this is a bug.

This is not suppose to be the way it should work. Encryption is intended to be a one-to-one relationship and should not be available to any node 'pretending' to be like the original. If a virtual node tries, then TSM should default to 'prompt' for the key.

yes, we changed it already from generate to save so that the client only saves the password for encryption every time.
but if i restore some old data, and i don't know the password, the server decrypts the data for me without promting for an password...
so now anyone can/could restore that data which shouldn't be. so the question was how can i remove the old key from the server?
the server also exports the encryption key with an export node command...

The only way I could think of on how to resolve this is to restore the data, remove encryption, backup (FULL), restore, enable encryption with 'prompt' and backup.
 
PREDATAR Control23

Based on the explanation given in this APAR http://www-01.ibm.com/support/docview.wss?uid=swg1IC59705, looks like it's working the way it's intended.

BTW, the APAR doesn't apply to this problem, I'm just referring to the first paragraph of the problem description that explains how encryptkey generate works

If this is working as designed, then where does security come in?

If a system has been hacked, and node credential stolen, one could restore data anywhere. Being a Security professional I find this odd and scary.
 
PREDATAR Control23

Isn't client data encryption there so that the data being transmitted during the backup and restore is encrypted, plus when stored on media? In the case of encrypt generate, the encryption key is generated and stored, nobody has access to it. Node authentication is the only thing that can be used to validate if the data can be restored and decrypted or not. So if the correct node connects, then the data can be restored.

I can't think of any way to prompt for the key when the key is not known of anybody. It would be a different story with encryptkey=save, because in the case a person has to enter the key, so therefore that person knows it. So if you choose encryptkey=save, it's saved in the password file or the registry depending on the platform, and it only valid for that machine because it's only stored there. So if you go to a different machine using the same nodename, you will be prompted for both the node password and the encryption key during a restore.
 
PREDATAR Control23

So if you go to a different machine using the same nodename, you will be prompted for both the node password and the encryption key during a restore.

However, this seems to contradict what dcz01 is observing. With -virtualnode=xxxx, he managed to restore data from the original node to the new node.

What I am saying is that this should not be allowed. Nodes have unique IDs and this should be a guide to determine if a node is the original or not. So encryptkey=save should only be bounded to the original and NOT work for any other.
 
PREDATAR Control23

However, this seems to contradict what dcz01 is observing.
That last bit you quoted for me, I was referring to "save", not "generate".


With -virtualnode=xxxx, he managed to restore data from the original node to the new node.

What I am saying is that this should not be allowed. Nodes have unique IDs and this should be a guide to determine if a node is the original or not. So encryptkey=save should only be bounded to the original and NOT work for any other.
Still need to authenticate as the node though. So the only people that can restore data are the people that know the node password, or the people that are able to login to a machine that already has the password stored and also have sufficient access. So in most cases, limited to administrators.

Also, if this was not allowed, what happens if the original machine is destroyed and you have to restore the data to an alternate machine?
 
PREDATAR Control23

well yes, that is my problem...
i log in and restore any node in our company with my tsm-administrator id...
so i have full access to all nodes... but the client should me ask for the password with encryption then or not?
because if someone can steal our export with the node with encrypted data, he only must import it to another tsm server and then he can restore any encrypted data without entering an password only by entering an tsm admin id.
that the problem with the encryptkey=generate. with encryptkey=save its all ok.
 
PREDATAR Control23

the client should me ask for the password with encryption then or not?
The key is generated and only known to the TSM Server and Client. If you were prompted for an encryption key, what would you enter?

Generally, client-side encryption is primarily intended to encrypt the data before it is sent to the TSM Server. So if you were to backup a computer over the internet, the data traveling on the would be encrypted. It's not really meant to control who can restore the data, the node/admin authentication is there for that. And typically in a company, the people that already have access to restore are the same people that probably already have access to the machine to see the data.

I see your point about stolen export tapes. What is the risk of that? And if you feel the risk is high enough, then you should probably look first as ways to better securing your physical tapes and second look at tape encryption.
 
PREDATAR Control23

well then i think we need to encrypt our export tapes and your right here internal the access to that data is only by the node itself and the tsm administrator so its ok i think.
thank you two for that long and complicated discussion.
 
Top