[Pki-devel] patches for review - ECC key archival / recovery feature implementation - Bug 745278 - [RFE] ECC encryption keys cannot be archived

Christina cfu at redhat.com
Wed Mar 14 21:49:37 UTC 2012


This is the ECC phase 2 implementation (ECC key archival / recovery 
feature) in the JSS and DRM (KRA)

Bug: *Bug 745278* <https://bugzilla.redhat.com/show_bug.cgi?id=745278> 
-[RFE] ECC encryption keys cannot be archived

Please review the following patches (see "BEFORE you review" at later 
part of this email):

* 
https://bugzilla.redhat.com/attachment.cgi?id=570109&action=diff&context=patch&collapsed=&headers=1&format=raw
* 
https://bugzilla.redhat.com/attachment.cgi?id=570110&action=diff&context=patch&collapsed=&headers=1&format=raw
* 
https://bugzilla.redhat.com/attachment.cgi?id=570112&action=diff&context=patch&collapsed=&headers=1&format=raw

thanks,
Christina
==============
BEFORE you review:

For the ECC plan and design for the different phases, please refer to 
http://pki.fedoraproject.org/wiki/ECC_in_Dogtag

Note: the designs beyond phase 2 were more like a brain dump.  Although 
I said "Do Not Review," you are free to take a peak at what's intended 
down the road.  I will go back and take a closer look and refine/adjust 
the designs when I begin implementation for each new phase.

This patch contains code for the following packages:
JSS, pki-kra, pki-common, pki-util, and pki-kra-ui

What you need to know:

* Problem 1 - nethsm issue:
On the server side, if you turn on FIPS mode, in addition to nethsm, you 
need to attach certicom as well to have ECC SSL working on the server 
side. This problem has already been reported to Thales last year and 
they said they'd look into putting the item on their next release.  
Recently through a different contact, we learned there might be a way to 
"turn it on" (still waiting for their further instruction)

* Problem 2- Certicom issue:
   This is a show-stopper.  Initially, on the client side, I used Kai's 
special version of Xulrunner/Firefox, attached to Certicom token, so 
that the CRMF requests can be generated with key archival option.  
However, I encountered (or, re-encountered) an issue with certicom 
token.  Certicom generates ECC keys with the wrong format (not PKCS7 
conforming), which makes ECC key archival impossible on the server side 
if you use non-certicom token with DRM (but we expect an HSM in most 
product deployment).  I have contacted Certicom for this issue, and they 
confirmed that they indeed have such issue.  We are waiting for their fix.

But then you might ask, "I thought I saw some ECC enrollment 
profiles/javascripts being checked in?  How were the tests done?" The 
tests for those profiles were done against this ECC key 
archival/recovery DRM prototype I implemented last year (needs to be 
turned on manually in 8.1), where I "cheated" (yeah, that's why it's 
called a prototype) by decrypting the private key in the CRMF on DRM, 
and then manipulating the byte array to strip off the offending bytes 
before archival.
In the real, non-prototype implementation, which is what's in this 
patch, for security reasons, private keys are unwrapped directly onto 
the token during key archival, so there is no way to manipulate the keys 
in memory and bypass the Certicom issue.

A word about Kai's special version of Xulrunner/Firefox.  It is not yet 
publicly available.

* Problem 3- Firefox with nethsm issue:
Another option was to connect Kai's special version firefox with an HSM 
to test my DRM/JSS code.  However, for whatever reason, I could not get 
SSL going between such Firefox and ECC CA ( I did not try very hard 
though, as I have one other option -- writing my own ECC CRMF generation 
tool.  I might come back to try the nethsm Firefox idea later)

My solution (how I work on this official implementation):
* I hacked up a ECC CRMF tool by taking the CRMFPopClient (existing in 
current releases), gutting out the RSA part of the code, and replacing 
it with ECC code.  I call it CRMFPopClientEC.  Two types of ECC key 
pairs could be generated: ECDSA or ECDH (That's another benefit of 
writing my own tool -- I don't know if you can select which type to 
generate in the Javascript... maybe you can, I just don't know).  I'm in 
no way condoning archival of signing keys!!  This is just a test tool.
This tool takes a curve name as option (along with others), generates an 
ECC key pair, crafts up an CRMF request with key archival option, and 
sends request directly to the specified CA.  You will see a "Deferred" 
message in the HTML response (see attachment for example)
Once CA agent approves the request, the archival request goes to DRM and 
the user private key is archived.
For recovery, DRM agent selects key recovery, etc, and you get your pkcs12.

I did some sanity test with the pkcs12 recovered:
* Import the recovered pkcs12 into a certicom library:
pk12util -d . -h "Certicom FIPS Cert/Key Services" -i userEC.p12

I also tested by retrieving a p12, importing it into a browser, and 
adding the user as an agent and the user could act as agent via ssl 
client auth to the CA.

Finally, much of the RSA-centric code had been cleared out of the way at 
the time when I worked on the DRM ECC prototype, so you don't see much 
of that in this round.

About SELinux:
I have a set of rules generated on my system to run in enforcing mode.  
I do a writeup.

For QE:
How to set up the servers?  The internal wiki is at 
https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Working_with_ECC.  I 
might have given someone a copy of how to set up ECC CA to publish on 
fedora.org when I worked on phase1 back a couple years ago. I will put 
an updated copy to cover both CA and DRM when I am checking in to dogtag.

How do you test? Well, unless you want to use my CRMFPopClientEC tool 
hooked up with a nethsm (like I did), or write your own tool, you can't 
really test it until Certicom fixes their issue. (BTW CRMFPopClientEC 
can also be changed to work with ceriticom, although you would run into 
the same issue I mentioned above)
It is not on my schedule to work on this tool;  It is certainly not in 
production quality to be released as a regular tool.  However, if you 
are interested in it, if we get enough request maybe we can think about 
doing something with it.
Other test suggestion:  I did not try to clone the ECC DRM.  It's a good 
idea to test it out.

For techpub:
TBD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120314/230ea240/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cfuECCtest.txt
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120314/230ea240/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5130 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120314/230ea240/attachment.p7s>


More information about the Pki-devel mailing list