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

Fri Oct 17 17:04:32 UTC 2014

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 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
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel