Red Hat Bugzilla – Bug 1466066
CC: Secure removal of secret data storage
Last modified: 2018-01-19 14:45:41 EST
When a secret data (e.g. password, private key) is no longer needed, the storage which held the data should be wiped out to ensure it cannot be read again. This applies to arrays in memory and files on disk.
There are several methods:
fill with zeroes
fill with random data
The first one is faster, but the second one is more secure, especially on disk.
Per CS/DS Meeting 09/25/2017: 10.5 blocker
Closing this one. If we feel we need to add more, will create a new one later.
Author: Jack Magne <firstname.lastname@example.org>
Date: Wed Oct 18 10:18:37 2017 -0700
Fix #2735 Secure removal of secret data storage.
This phase provides a method to clear memory using a configurable method, ei
The configuration for this is:
This fix consists of a new method in JssSubsystem and examples of the callin
The next phase will consist of the rest of the servers that do this kind of
Also: I had to fix drmtest.py to complete the test run. The problem is whe
Fixed confusing comment in the obscureBytes method.
Testing instructions for phase one of this where, we work on the most crucial kra first:
With this fix, we have decided to clear security data only in the kra, to act as a proof of concept.
To test the integrity of this fix, we want to make sure that the kra still functions normally and that the log messages created when we clear memory are showing up when expected. The following is what can be done at this point to test this all out.
Stand up a kra along with a CA.
Configure the kra to allow encryption and decryption when archiving and recovering keys. This is because the fix lies in this area heavily:
We can also configure the desired obscuring method, with "zeroes" being the default:
Restart the kra:
We want to run the test program called "drmtest.py", because this exercises the SecurityData / rest functionality we have added to the kra. This functionality archives and recovers things like sym keys, asym keys, and passphrases or security strings.
The test program is located in a source tree here:
Help to run this test is located in a text file in the same area:
This file will show how to configure and run the test.
Run drmtest.py and observer that all the tests succeed. This can be observed by simply watching the output in the console. Note that there are several tests that are designed to fail, so make sure that continues.
After running the drmtest, look in the kra debug log to make sure there are places where the function to clear memory is being called.
Finally, in order to test general legacy kra functionality, preform the usual standard / legacy key archival and recovery testing procedures and make sure everything works and that the logs reflect the memory being cleared out.
Subsequent checkin: This handles some more byte array cases:
commit f5ec7c2af4a1fb44d5731c74672bf789e9240499 (HEAD -> master, origin/master, origin/HEAD, obscure-memory)
Author: Jack Magne email@example.com
Date: Tue Nov 7 11:05:55 2017 -0800
Fix #2735 Secure removal of secret data storage (phase 2)
This portion of the fix attempts to take care of the remaining secret data
storage issues that could be practically taken care of with respect to
servers and clients.
A new method was placed in CryptoUtil to server the needs of clients.
We still need to address the many String based password type cases.
Author: Jack Magne <firstname.lastname@example.org>
Date: Fri Nov 10 10:57:36 2017 -0800
Fix #2735 Secure removal of secret data storage (phase 3)
Add more secure data removal with respect to passwords.
Concentrate on the CMC Shared Token area. Done by changing
String based passwords to char based password, which then can be cleaned.
Cleaned up a couple of minor review suggestions.
Testing instructions for phase 2 and 3:
We added 2 more phases of the checkins to this bug.
Once again, we made some changes to try to secure some more memory data and password data.
The changes are not server wide but we wanted to cover some more important sections of the code. Those sections being all the new CMC client and server code and some more changes to the KRA to support password data cleanup. As for passwords, the framework code for cleaning all passwords has been put in place and exercised in the CMS and KRA area. The following are the areas to test for correctness and sanity. There is no way QE can actually tell if the data is being obscured correctly, but we want to make sure we have not broken anything .Therefore the following tests would be useful:
Test all of the new CC CMC client and server code, with emphasis on the new SHARED TOKEN pathway. The code had to be moved a bit to support cleaning the passoword, thus we want to make sure the shared token authentication still works, and to perform sanity on the rest of the CMC functionality of interest to CC.
Re-test all the kra stuff talked about in phase 1. This is because we added some password functionality to the KRA security data archival and recovery routines.
Make sure configuration works along with pk#12 processing. There were some minor changes to some of the code that creates and processes pk#12 files. This is where sanity should suffice, since I"m sure all this stuff is tested anyway.
A small bit of TKS /TMS code was enhanced for security data removal. Just observe that the standard TMS stuff still works as usual.
Some but not all of the server changes will have messages placed in the debug logs, indicating that a piece of data is being obscured or clean. Simple inspection of some of that can at least show the idea that this kind of thing is going on. Not all will be recorded since some of the cleaning is taking place in client code.
Created attachment 1377373 [details]
phase 1 test results
I have performed tests for phase 1 (please refer attachment for drmtest.py output) also legacy KRA functionality is working as expected.
Seeing the issue in comment 11 using the latest copr builds pki-ca-10.5.1-5.1.el7.noarch, so marking this bug to ASSIGNED.