I haven’t looked at TSM backup encryption before, even though it’s been in TSM since version 5.4 (maybe earlier). But, if you think about it, there isn’t any data MORE important than your backup data. Data that is usually encrypted on the wire, is most likely sent in the clear by the TSM client. There are a couple of ways to slice this, but I started with the SSL encryption feature. There is a client encryption option in TSM 6.1 (possibly earlier) that encrypts the data with an encryption passphrase, but that has more issues and isn’t very compatible with server-side de-duplication.

Enabling the SSL features in the server is as simple as adding the following line to the dsmserv.opt and restarting:

SSLTCPPORT xxxx

When the server sees this option, it checks to see if there is a SSL key already generated. If there isn’t one, it creates it automatically. You can specify any port you like, as long as it’s not already being used by something else. If you don’t run the admin client on the same TCP port as the clients, you’ll also need to add:

SSLTCPADMINPORT xxxx

Now, on the client side, you need to copy the newly generated key from the server. It’s named cert.arm, and should be located in the server home directory (that’s the home directory for the instance owner in 6.1 and above). Once you have that, you just have to create an empty keyring and add the server key to it:

gsk7capicmd -keydb -create -db dsmcert.kdb -pw  -stash
gsk7capicmd -cert -add -db dsmcert.kdb -pw  -label "TSM server  self-signed key" -file cert.arm -format ascii -trust enable

The password can be anything and you can add more than 1 keys to your client keyring if you have more than one server as long as the labels are unique.

After that, you have to change the TCPPort option in the client option file (dsm.sys on Unix), and add the option “SSL yes”. Un-encrypted clients can’t talk to the SSL enable server port, and vise-versa. Just restart your client, and you should be in business.

There is a new feature in 6.2 where you can use a well-known certificate, if you want to pay Verisign or Thawt for a SSL certificate. Those certificates are included with the 6.2 clients, so you don’t need to hassle with copying the certificates. I haven’t tried that, because it’s easy enough to copy the self-signed key from the server and setup the keychain on the clients and save the money for a yearly SSL certificate renewal.

Now, I haven’t been able to verify this, but it appears to me that this DOES NOT interfere with de-duplication. The way I read it is the data isn’t stored in an encrypted format on the server, it’s de-crypted on the server before it hits the storage pools. The performance seems pretty good. You will spend some extra CPU cycles, but SSL is pretty light-weight and I haven’t seen a noticeable impact.

Note: this doesn’t encrypt the Webclient, GUI, client-to-client backups, or server-to-server backups. This only encrypts the actual data transfer from the client to the server.

I haven’t looked at TSM backup encryption before, even though it’s been in TSM since version 5.4 (maybe earlier). But, if you think about it, there isn’t any data MORE important than your backup data. Data that is usually encrypted on the wire, is most likely sent in the clear by the TSM client. There are a couple of ways to slice this, but I started with the SSL encryption feature. There is a client encryption option in TSM 6.1 (possibly earlier) that encrypts the data with an encryption passphrase, but that has more issues and isn’t very compatible with server-side de-duplication.<\/p>\n

Enabling the SSL features in the server is as simple as adding the following line to the dsmserv.opt and restarting:<\/p>\n

SSLTCPPORT xxxx<\/code><\/pre>\n
When the server sees this option, it checks to see if there is a SSL key already generated.  If there isn’t one, it creates it automatically.  You can specify any port you like, as long as it’s not already being used by something else.  If you don’t run the admin client on the same TCP port as the clients, you’ll also need to add:<\/p>\n
SSLTCPADMINPORT xxxx<\/code><\/pre>\n
Now, on the client side, you need to copy the newly generated key from the server. It’s named cert.arm, and should be located in the server home directory (that’s the home directory for the instance owner in 6.1 and above).  Once you have that, you just have to create an empty keyring and add the server key to it:<\/p>\n
gsk7capicmd -keydb -create -db dsmcert.kdb -pw  -stash\ngsk7capicmd -cert -add -db dsmcert.kdb -pw  -label \"TSM server  self-signed key\" -file cert.arm -format ascii -trust enable<\/code><\/pre>\n
The password can be anything and you can add more than 1 keys to your client keyring if you have more than one server as long as the labels are  unique.  <\/p>\n
After that, you have to change the TCPPort option in the client option file (dsm.sys on Unix), and add the option “SSL yes”.  Un-encrypted clients can’t talk to the SSL enable server port, and vise-versa.  Just restart your client, and you should be in business.<\/p>\n
There is a new feature in 6.2 where you can use a well-known certificate, if you want to pay Verisign or Thawt for a SSL certificate.  Those certificates are included with the 6.2 clients, so you don’t need to hassle with copying the certificates.  I haven’t tried that, because it’s easy enough to copy the self-signed key from the server and setup the keychain on the clients and save the money for a yearly SSL certificate renewal.<\/p>\n
Now, I haven’t been able to verify this, but it appears to me that this DOES NOT interfere with de-duplication.  The way I read it is the data isn’t stored in an encrypted format on the server, it’s de-crypted on the server before it hits the storage pools.  The performance seems pretty good.  You will spend some extra CPU cycles, but SSL is pretty light-weight and I haven’t seen a noticeable impact.<\/p>\n
Note: this doesn’t encrypt the Webclient, GUI, client-to-client backups, or server-to-server backups.  This only encrypts the actual data transfer from the client to the server.<\/p>\n","protected":false},"excerpt":{"rendered":null,"protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,1],"tags":[],"class_list":["post-500","post","type-post","status-publish","format-standard","hentry","category-tsm-notes","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/posts\/500","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/comments?post=500"}],"version-history":[{"count":0,"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/posts\/500\/revisions"}],"wp:attachment":[{"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/media?parent=500"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/categories?post=500"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rootuser.ninja\/index.php\/wp-json\/wp\/v2\/tags?post=500"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}