[Pki-devel] lightweight sub-CAs; updated design

Fri Oct 17 17:01:33 UTC 2014

Hi Fraser,

This response is for the "Key generation and storage" part of the design.

First of all, Dogtag does provide symkey retrieval via a JNI package 
which provides interface to NSS called "symkey".  There had been talks 
of merging symkey functionalities into JSS (which is also a JNI package 
that provides interface to NSS) in the future.

In fact, for years, Dogtag has been doing what's similar to what Petr^2 
Spacek described with DNSSEC, the wrapping/unwrapping of keys on both 
NSS softtoken as well as supported HSMs for distribution without ever 
disclosing any private keys in memory.
This is the most basic requirement for Common Criteria for RHCS.
This is just to assure you that whatever you need, it's most likely 
already there and more.

BTW, I'm not familiar with "SoftHSM".  The name itself sounds like an 
oxymoron, but we don't have to get into that ;-).

As far as HSMs go, once keys are generated, you are not going to be able 
to export any private keys out of it unless they are temporary and 
non-sensitive keys, which should not be the case for CA signing keys.
In practice, since HSMs are expensive, people use net HSM so servers can 
share the same hardware unit as long as they are within the same secured 
network, which means that you don't have to try to distribute the certs 
and keys, as long as you have the right permission/privileges and enough 
info to access such network shared HSM.
In cases when sharing of an HSM is not possible, HSM vendors provide 
assistance to "copy" keys from one HSM to another.  When our customers 
run into that, we ask our customers to contact their vendor(s).
In some situations, process can be taken to generate keys on soft token 
in a secure and isolated location and manually import to individual HSMs.
What you do not want to do, is to put your CA signing keys anywhere 
other than an isolated backup facility or in the token itself, no matter 
how many times you wrap it.  Ciphers get cracked every few years, and 
when your CA private keys are compromised, the consequences are 
insurmountable.
You might ask, why then KRA keeps the wrapped user private keys on the 
ldap server for archival/recovery?  The answer is very simple. Those are 
user keys.  It would be bad if they are compromised, but not as bad or 
widespread.  Also, those user private keys are wrapped with individual 
session keys (every key is different), unlike what DNSSEC is doing with 
one single "master key", if I read it correctly (I apologize I did not 
have time to look into DNSSEC at all).
Anyway, Dogtag has a long history of serving facilities that require 
high security, so that's why it is what it is today.

Hope this helps.
Christina

On 10/16/2014 12:05 AM, Fraser Tweedale wrote:
> On Wed, Oct 15, 2014 at 03:58:51PM +0200, Petr Spacek wrote:
>> On 15.10.2014 14:48, Simo Sorce wrote:
>>> On Wed, 15 Oct 2014 17:48:35 +1000
>>> Fraser Tweedale <ftweedal at redhat.com> wrote:
>>>
>>>> On Wed, Oct 15, 2014 at 01:38:09AM -0400, Ade Lee wrote:
>>>>> On Wed, 2014-10-15 at 01:15 -0400, Ade Lee wrote:
>>>>>> On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Just landed a big update to the lightweight sub-CAs design
>>>>>>> proposal: http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs.
>>>>>>>
>>>>>>> I plan to start the implementing next week.  Aside from general
>>>>>>> design review, specific things I need input on are:
>>>>>>>
>>>>>>> 1)
>>>>>>>
>>>>>>> How to propagate newly-generated sub-CA private keys to clones
>>>>>>> in an automated way, and how to store them.
>>>>>>>
>>>>>> I'll comment about that in the IPA thread.  I had thought that the
>>>>>> keys etc. would reside in the primary CA certdb.
>>>>>>
>>>>> Actually, I'll respond here because the IPA thread has moved
>>>>> slightly away from this.  In the IPA thread, there is discussion of
>>>>> storing the keys in ldap encrypted by some master key - which
>>>>> presumably would be stored in the certdb.
>>>>>
>>>>> Decrypting the signing key and keeping it in memory is absolutely a
>>>>> no-no.  The CA signing key material should only be present in the
>>>>> HSM/softoken - and should never be exposed unencryted outside the
>>>>> token. All crypto operations must be done there.  That most likely
>>>>> means storing the data in the NSS certdb.
>>>>>
>>>> The design of key distribution could follow the DNSSEC design; see
>>>> Petr Spacek's comments in this thread:
>>>> https://www.redhat.com/archives/freeipa-devel/2014-October/msg00080.html
>>>> Presumably this design for key distribution has received some
>>>> thorough attention.  Perhaps some of the assumption for DNSSEC do
>>>> not hold for Dogtag. I have copied Petr and Simo for their input.
>>> We use a softHSM for the DNSSEC stuff (in theory can be replaced by a
>>> hw HSM too), and keys are handed within it only.
>> We are finishing DNSSEC right so I don't have time to study sub-CA design
>> right now. For this reason I'm replying only with general statements:
>>
>> - SoftHSM can be used as generic purpose token with PKCS#11 interface.
>> - It supports multiple "PKCS#11 slots" in single SoftHSM installation so
>> data can be separated as necessary: Each "slot" stores data in separate
>> directory (with potentially different filesystem permissions, PINs etc.)
>> - Upstream is responsive and accepts patches with new features (i.e.
>> unimplemented pieces of PKCS#11 standard) without problems.
>> - SoftHSM v2 code could use some cleanup but it has clear design and
>> structure and I don't see extensibility problems.
>> - Storage & crypto backends have clearly defined API so it should be
>> possible to implement own back-ends (LDAP & NSS, if necessary).
>>
>> Generally I don't see a reason why it couldn't not be used for as key
>> storage mechanism for replicas (sub-CA keys, KDC master key, etc.) or even
>> for clients (GNOME keyring backed with SSSD-SoftHSM tandem).
>>
>> -- 
>> Petr^2 Spacek
> Thanks Simo and Petr for your input.
>
> After some more investigation it looks like all the crypto in
> Dogtag, including for KRA etc, is performed within the
> ``CryptoManager`` facility.  With that in mind, I've got a more
> concrete implementation proposal that also uses ``CryptoManager``.
> If it proves insufficient I will embark on a more detailed analysis
> of feasibility/implications of bringing SoftHSM as a Dogtag
> dependency (and remain open to other key distribution ideas).
>
> One difference between the DNSSEC/SoftHSM design is that the master
> key has to be unwrapped each time a sub-CA key needs to be
> installed.  This was because I couldn't see a way to store and
> retrieve a specific SymmetricKey in CryptoManager/CryptoToken.  If
> there's a way to do this and I've just overlooked it, let me know.
> But I don't think the security of the scheme is impacted ; it just
> means that there's a bit of repeated work when we import sub-CA keys
> from the database.
>
> Direct link to key distribution implementation detail in the design proposal:
> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#CryptoManager_based_implementation
>
> Cheers,
>
> Fraser
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel