12:04 p.m.
sorry I missed a few folks in my reply ...
On 10/17/2014 10:01 AM, Christina Fu wrote:
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
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel