search

pki-bot / pki-issues-final

0 stars 0 forks source link

CA throws exception while processing SCEP PKCSReq message when cert DB is in FIPS mode #441

Open pki-bot opened 4 years ago

pki-bot commented 4 years ago

This issue was migrated from Pagure Issue #442. Originally filed by nkinder (@nkinder) on 2012-12-10 22:31:35:

https://bugzilla.redhat.com/show_bug.cgi?id=825887 (Dogtag Certificate System)

Description of problem: SCEP enrollment fails when cert/key database in
/var/lib/pki-ca/alias is set to FIPS mode.

Version-Release number of selected component (if applicable): Found in pki-core
9.0.17 and 9.0.19.  NSS version is 3.13.4, JSS is 4.2.6-24, NSPR is 4.9-2

How reproducible: Can reproduce every time.

Steps to Reproduce:
1. Create CA and RA using pkicreate commands
2. Before configuring the CA, place CA database in FIPS mode, change password
to meet FIPS 140-2 guidelines.  Change password in /etc/CS.cfg to match.
3. Configure CA.  Note: Need to rename "Server-Cert cert-pki-ca" to some other
cert nickname as it fails overwriting when DB is in FIPS mode.

Actual results:
When SCEP enrollment takes place the debug logs for the CA throw the following
exception and stack trace:
[20/May/2012:22:23:30][http-9444-1]: failed to unwrap PKCS10
org.mozilla.jss.crypto.SymmetricKey$NotExtractableException
[20/May/2012:22:23:30][http-9444-1]: handlePKIMessage exception
com.netscape.cms.servlet.cert.scep.CRSEnrollment$CRSFailureException: Could not
unwrap PKCS10 blob: null
com.netscape.cms.servlet.cert.scep.CRSEnrollment$CRSFailureException: Could not
unwrap PKCS10 blob: null
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.unwrapPKCS10(CRSEnr
ollment.java:1109)
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.decodePKIMessage(CR
SEnrollment.java:564)
        at com.netscape.cms.servlet.cert.scep.CRSEnrollment.service(CRSEnrollme
nt.java:307)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
licationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
FilterChain.java:206)
        at com.netscape.cms.servlet.filter.EERequestFilter.doFilter(EERequestFi
lter.java:176)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App
licationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application
FilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapper
Valve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContext
Valve.java:191)
        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVa
lve.java:109)
        at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
        at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proc
ess(Http11Protocol.java:588)
        at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
        at java.lang.Thread.run(Thread.java:679)
[20/May/2012:22:23:30][http-9444-1]: ServletException
javax.servlet.ServletException: Failed to process message in CEP servlet: Could
not unwrap PKCS10 blob: null

Expected results:
Would normally expect the messageData portion of the PKCSReq message to be
decrypted (as it does in non-FIPS mode), and the certificate issued.

Additional info:
With Jack and Deon's help, I was able to get the NSS database to do enhanced
logging when run from the CA.  The following C_UnwrapKey is logged at the time
the SCEP message is processed:
-1874453648[9c75930]: C_UnwrapKey
-1874453648[9c75930]:   hSession = 0x80000033
-1874453648[9c75930]:   pMechanism = 0x90460534
-1874453648[9c75930]:   hUnwrappingKey = 0xcf692af0
-1874453648[9c75930]:   pWrappedKey = 0x9cc4df0
-1874453648[9c75930]:   ulWrappedKeyLen = 256
-1874453648[9c75930]:   pTemplate = 0x90460444
-1874453648[9c75930]:   ulAttributeCount = 3
-1874453648[9c75930]:   phKey = 0x9b3383c
-1874453648[9c75930]:     CKA_CLASS = CKO_SECRET_KEY [4]
-1874453648[9c75930]:     CKA_KEY_TYPE = CKK_DES3 [4]
-1874453648[9c75930]:     CKA_DECRYPT = CK_TRUE [1]
-1874453648[9c75930]:       mechanism = CKM_RSA_PKCS
-1874453648[9c75930]:   *phKey = 0x1f
-1874453648[9c75930]:   rv = CKR_OK

The values for CKA_SENSITIVE and CKA_EXTRACTABLE are not set, so I assume the
token gets to set the defaults.  For a database in FIPS 140-2 mode, it must
assume that CKO_SECRET_KEY objects are default sensitive (or something like
that).  When the unwrap finishes, unwrapPKCS10's implementation calls
getDESKeyGenerator().clone() which according to the comments in the
implementation is designed to get a key replicated on another token.

Not 100% sure but from looking at modutil output it looks like maybe 3DES isn't
an advertised mechanism on the "NSS Certificate DB" token in the default,
non-FIPS case.  So the clone is required in order to copy the 3DES key to the
"NSS Generic Crypto Services" PKCS11 token and do the decryption from there.

This breaks down however when the database is running in FIPS-140 mode.  In
that case, there's only one PKCS11 token and it handles key storage and crypto
services.  What's more the key appears to be marked sensitive.

The clone() method appears to do C_GetAttributeValue, which is the next PKCS11
call following the C_UnwrapKey:

-1874453648[9c75930]: C_GetAttributeValue
-1874453648[9c75930]:   hSession = 0x80000001
-1874453648[9c75930]:   hObject = 0x1f
-1874453648[9c75930]:   pTemplate = 0x904605c4
-1874453648[9c75930]:   ulCount = 1
-1874453648[9c75930]:     CKA_VALUE = [0x0] [-1]
-1874453648[9c75930]:   rv = CKR_ATTRIBUTE_SENSITIVE

...Which is a no-go because the key is sensitive in the FIPS mode database.  It
may well be sensitive with other HSMs though I have no external PKCS11 token I
could attach to my CA to test that hypothesis.
pki-bot commented 4 years ago

Comment from nkinder (@nkinder) at 2017-02-27 14:03:59

Metadata Update from @nkinder: