Bug 1452347 - CC: Replacing Random with SecureRandom.
Summary: CC: Replacing Random with SecureRandom.
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core   
(Show other bugs)
Version: 7.4
Hardware: All Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Endi Sukma Dewata
QA Contact: Asha Akkiangady
Marc Muehlfeld
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-18 18:13 UTC by Matthew Harmsen
Modified: 2018-04-10 16:59 UTC (History)
6 users (show)

Fixed In Version: pki-core-10.5.1-1.el7
Doc Type: Enhancement
Doc Text:
Certificate System now uses the Mozilla NSS secure random number generator With this update, Certificate System uses a secure random number generator provided by the Mozilla Network Security Services (NSS). This enables Red Hat Certificate System to synchronize its Deterministic Random Bit Generator (DRBG) with Red Hat Enterprise Linux as required by the Federal Information Processing Standard (FIPS) standard.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 16:58:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0925 None None None 2018-04-10 16:59 UTC

Description Matthew Harmsen 2017-05-18 18:13:35 UTC
This bug is created as a clone of upstream ticket:
https://pagure.io/dogtagpki/issue/2695

Some parts of the current code are using Java's Random class to generate random numbers for various purposes. It should be changed into SecureRandom using CSPRNG.

The main priority should be the random serial number (see https://github.com/dogtagpki/pki/blob/master/base/server/cmscore/src/com/netscape/cmscore/dbs/CertificateRepository.java).

Note that other parts of the code are already using SecureRandom but not very consistently. Some do not specify the algorithm, some are using SHA1PRNG, and some others are using PK11SecureRandom.

The current web application session ID is already generated using pkcs11prng (see https://github.com/dogtagpki/pki/blob/master/base/ca/tomcat8/conf/Catalina/localhost/ca.xml).

    <Valve className="com.netscape.cms.tomcat.SSLAuthenticatorWithFallback"
        alwaysUseSession="true"
        secureRandomProvider="Mozilla-JSS"
        secureRandomAlgorithm="pkcs11prng"/>

See also ticket #2023 about Randomizing IVParameterSpec.

See also http://stackoverflow.com/questions/15307127/using-seed-in-prng.

Comment 2 Christina Fu 2017-06-09 23:08:24 UTC
This is the result from what I concluded from talking to our CC lab. At the very minimum, there should be two bugs (no telling if there would be more, but at this time, it seems like two as far as I can tell):
1. random number serial change to use JSS/NSS
2. memory overwrite of secure/private data (passwords, keys) after use.  This is especially important since we are going to do KRA encrypt/decrypt with HSM.  In addition to the kra as mentioned, we should identify all area and proceed to do memory wipe with random bits.

Comment 3 Christina Fu 2017-06-15 21:51:47 UTC
(In reply to Christina Fu from comment #2)
> This is the result from what I concluded from talking to our CC lab. At the
> very minimum, there should be two bugs (no telling if there would be more,
> but at this time, it seems like two as far as I can tell):
> 1. random number serial change to use JSS/NSS
> 2. memory overwrite of secure/private data (passwords, keys) after use. 
> This is especially important since we are going to do KRA encrypt/decrypt
> with HSM.  In addition to the kra as mentioned, we should identify all area
> and proceed to do memory wipe with random bits.

From today's meeting, for "2", the lab responded that we could just zero-out instead of writing random bits in case of memory overwrite.

Comment 4 Christina Fu 2017-06-15 21:58:30 UTC
one more thing:
On the CS side, we just need to make sure whatever is deemed as PII needs to be zeroed out in memory after use.

Comment 6 Jack Magne 2017-10-23 18:27:21 UTC
Checkin:

commit b42b58024b801e5c9874e11dfb52de2b45c3a285
Author: Jack Magne <jmagne@redhat.com>
Date:   Thu Oct 5 11:55:12 2017 -0700

    Fix: #2695 Replacing Random with SecureRandom.
    
    This is addressed by creating one centralized method to get
    the SecureRandom number generator in JssSubsytem, which alread exists.
    
    Another fix by edewata allowed us to be able to access the
    JssSubsystem from most other server code. Thus only one method
    required.
    
    In a future ticket we can centralize the method calls TO the secure
    random object to allows us to easily log when they are called.
    
    Added a centralized method to CryptoUtil, which can be used by java clients.
    
    Change-Id: I092a6c16b43ddc6bb33ff0b6084ece1f34285844

Comment 8 Amol K 2017-12-21 11:47:05 UTC
I tested this bug on 10.5.1-5.el7. 

As per Endi's suggestions, there should be two log events for RANDOM_GENERATION.

One for secure random generation and one for the nonce.

Here I saw two RANDOM_GENERATION events. But both of them are identical.


- [AuditEvent=RANDOM_GENERATION][SubjectID=caadmin][Outcome=Success][Info=Caller;;com.netscape.cms.servlet.cert.CertRequestDAO.reviewRequest(CertRequestDAO.java:151)+Size;;4] Random number generation

- [AuditEvent=RANDOM_GENERATION][SubjectID=caadmin][Outcome=Success][Info=Caller;;com.netscape.cms.servlet.cert.CertRequestDAO.reviewRequest(CertRequestDAO.java:151)+Size;;4] Random number generation

Marking this bug as FailedQA.

Comment 9 Endi Sukma Dewata 2018-01-02 19:54:38 UTC
Amol,

Actually, the RANDOM_GENERATION event was added in this ticket:
https://pagure.io/dogtagpki/issue/2653

and there's already a separate bug for the above problem:
https://bugzilla.redhat.com/show_bug.cgi?id=1520517

For bug #1452347, the change from Random to SecureRandom was done in a number of places in comment #6, and due to the low-level nature of the changes it's rather difficult to determine the test scenarios for each of the changes and their expected results. I'd suggest that we only do sanity test only for this bug.

Comment 10 Amol K 2018-01-05 14:58:56 UTC
I tested this bug on the 10.5.1-5.el7 version. 

I able to see the RANDOM_GENERATION event while approving the certificate request.

Verifying this bug.

Comment 18 errata-xmlrpc 2018-04-10 16:58:29 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0925


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