12:01 p.m.
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(a)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...
Cheers,
Fraser
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel