convert from DES to AES

[Vince Elliott]

Converting client database from DES to AES.   what is backout process incase have to revert back to DES?​

[Joseph Porto]

Vince,

Before you start the conversion from DES to AES, you should backup the TSS primary security file just in case something accidental happens to it.

The process would be:

1. Update the TSS proc to point your DDs back to the old security file using DES.
2. Bring down TSS started task that points to the version of the security file using AES.
3. Start the TSS proc whose DDs point to the old security file using DES.

Please let me know if you have any questions.

Regards,

Joseph Porto - Broadcom Level 1 Support



​

[Josef Thaler]

Joseph, Vince,

remark and question: keep the VSAMFILE in mind. Does VSAMFILE also has to be "fallen back" or is it handled independently? Or is "security file" for you anyway a synonym for SECFILE+VSAMFILE?

Regards
Josef

[Joseph Porto]

Josef,

Yes that includes the VSAMFILE.

A little history. In the older release of Top Secret pre 8.0, there was just the BDAM Security File and no VSAM companion file.

In 8.0, they introduced the VSAM companion file. All the security records that were once in the BDAM file is now spit between the BDAM security file and the VSAM companion file. The SDT type security records like calendars/time restriction, digital certificate, record level protection...etc...were now being kept in the VSAM companion file.

Why did we move them? Because of digital certificate.....clients wanted support for more than 1 million digital certificates. To support it and have faster access to them, the VSAM companion file was the solution.

The BDAM security file and VSAM companion file are a 'married' pair. You cannot mix and match BDAM security files and VSAM security files. There are markers in the files that help Top Secret determine if the are the matching pair. If not, Top Secret will not initialize. The markers are created when they are both initialized during installation time.

So even though they are physically two separate file.....you should always treat them as one.....they cannot exist or be used without the other.

If you update the DD for your security file in your TSS proc, that means you are updating the DDs for the BDAM security file and VSAM companion file. Same goes for the backup BDAM security file and backup VSAM companion file.

Please let me know if you have any further questions.

Regards,

Joseph Porto - Broadcom Level 1 Support
 

​

[Josef Thaler]

Joseph,

well, as you offer so pleasantly :-) and just to go for sure:

RECFILE (and also AUDIT and CPFFILE) are not "involved" at such a DES<->AES conversion-flip, neither forward nor backward, are they? Just out of curiosity: Why? ... I anticipate from a possible answer, that it would absolutely make sense to execute a BACKUP after restart of TSS with the converted security database (SECFILE+VSAMFILE)

(question added afterwards) Is an IPL necessary after the conversion or is a restart of the TSS started task sufficient? 

Thanks and kind regards, 
Josef

[Joseph Porto]

Josef,

RECFILE and CPFFILE contains TSS commands. Passwords are encrypted for the TSS related password commands in these files. Not the TSS commands.

The AUDIT file contains audit events and nothing is encrypted in the file.

Encryption is not free. It comes at cost of overhead. Encrypting everything would bring your system to a crawl. Also the cost of encryption hardware and electricity needed to power their increased usage.

Imagine thousands of AUDIT entries being written per minute being encrypted, then decrypted later. Hundreds of TSS commands being transferred back an for between systems being encypted in the RECFILE and CPFFILE. 

As you can imagine, encrypting everything is costly not just in CPU but also electricity to power the CPU and/or encryption co-processors that will be working overtime.

Maybe sometime in the future when CPU's and encryption processors will no longer be a bottle neck.

For now, we have to pick and choose what is important to encrypt.

Please let me know if you have any questions.


Regards,

Joseph Porto - Broadcom Level 1 Support
​

[Josef Thaler]

Thanks Joseph, for your detailed explanations,

well, as you noted, commands in RECFILE and CPF-Files contain passwords, encrypted passwords. I noticed, that TSS can handle those commands also beyond a "DES-AES-encryption flip" of the SECFILE.

Or, in other words/scenario: you take a TSS-BACKUP (SECFILE_DES_encrypted) allocate an SECFILE_AES_encrypted, populate it based on the BACKUP_DES and finally flip TSS to use the new SECFILE_AES. Then, a TSSRECVR from the time of the BACKUP until restart with the flipped SECFILE is able to be "applied", even during this period of time the operating SECFILE was DES and the new target SECFILE is AES. I tested this in the meantime and it works! 

Kind regards,
Josef