Bug 1466066 - CC: Secure removal of secret data storage
CC: Secure removal of secret data storage
Status: ON_QA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jack Magne
Asha Akkiangady
Depends On:
  Show dependency treegraph
Reported: 2017-06-28 19:18 EDT by Matthew Harmsen
Modified: 2018-01-19 14:45 EST (History)
6 users (show)

See Also:
Fixed In Version: pki-core-10.5.1-5.el7
Doc Type: No Doc Update
Doc Text:
User will never see or care about this. No need for doc text.
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
phase 1 test results (135.61 KB, text/plain)
2018-01-05 03:32 EST, Sumedh Sidhaye
no flags Details

  None (edit)
Description Matthew Harmsen 2017-06-28 19:18:33 EDT
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.
Comment 3 Matthew Harmsen 2017-09-25 19:48:38 EDT
Per CS/DS Meeting 09/25/2017: 10.5 blocker
Comment 4 Jack Magne 2017-12-08 20:17:47 EST
Closing this one. If we feel we need to add more, will create a new one later.
Comment 5 Matthew Harmsen 2017-12-11 11:39:02 EST
jmagne wrote:

commit 1467340ef3c0a7aede4e264aff93bb6a7e7eb6ee
Author: Jack Magne <jmagne@redhat.com>
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.
    Change-Id: I276e3a9b678cb6b34b6c6b6a78ba2968b84f74d8

Testing instructions for phase one of this where, we work on the most crucial kra first:

Testing instructions:

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 jmagne@redhat.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.
Change-Id: I1a14daabcad72e531572d1be8bc255e2e501b70a

We still need to address the many String based password type cases.

commit daff3951340246d97a9877d5dde4782c8c675974
Author: Jack Magne <jmagne@redhat.com>
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.
    Change-Id: I898814000353978f403f19f679083474548edc5e

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.
Comment 9 Sumedh Sidhaye 2018-01-05 03:32 EST
Created attachment 1377373 [details]
phase 1 test results
Comment 10 Sumedh Sidhaye 2018-01-05 03:33:17 EST
I have performed tests for phase 1 (please refer attachment for drmtest.py output) also legacy KRA functionality is working as expected.
Comment 12 Roshni 2018-01-19 10:37:28 EST
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.

Note You need to log in before you can comment on or make changes to this bug.