12:06 a.m.
On Tue, 2014-10-21 at 16:49 -0700, Christina Fu wrote:
The following response is only for soft tokens for obvious reasons I
stated earlier.
First of all, it is okay to make exceptions for the duration of
installation. This is to give people a choice of doing things in
secured/isolated environment for installation purpose. So, yes, it is
much better than having a design where sensitive data is placed and kept
on ldap in normal operation.
Here I'm just throwing out some questions/ideas for you to think about.
About transmission of keys. A couple questions for Ade's design in the
email thread:
a. If you split the key (or generate 1/2 a key separately...same thing)
and use the exact same key to wrap the shares then I am not sure I see
the benefit (apology if I am not reading it right... I'm spread very
thin at this point). I will talk about key splitting in the later part
of this email...
b. I might have missed something, but if you take the effort to manually
transport the p12 of subsystem keys/certs, why not do the CA as well?
What you are missing, Christina, is that this operation can be done
during normal operation.
The feature that is being developed here is a lightweight subCA. This
is a subCA that exists in the same webapp as a "primary" CA, and that
will be subordinate to it. It will share config files, profiles, logs,
audit signing, server and subsystem certs and certdb. It will have
different signing and ocsp signing certs - which will be stored in the
certdb. It will also share the same DB instance, although likely under
some different DNs.
The subCA will probably be created through a REST API call, likely
invoked through the pki CLI tool (as an enterprise admin). There may be
many subCAs, but they will all be created after the primary CA is
operational.
I could imagine the following flow:
1. Admin installs primary CA (CA0)
2. Admin uses CLI to install subCA1 in CA0.
3. Admin clones CA0 to CA1. Any system certs in the certdb are
transported using the p12 mechanism - including the subsystem cert and
the signing certs for CA0 and subCA1. The result is a clone that
contains a clone of CA0 and subCA1.
4. Admin uses CLI to install subCA2 on CA0.
5. At this point, the clone CA1 detects that a new subCA has been
created (through watching LDAP modifications) and needs to automatically
make any required configuration changes and get the new signing keys for
subCA2.
The key point is that operation (5) needs to be done automatically with
no operator intervention. That means that there are no credentials to
get an installation token from the security domain.
But because we are in a working clone, we already have the credentials
we need. Both clones already have the same subsystem cert/keys - and
this should be true only for clones. We can therefore use the subsystem
cert to both authenticate and wrap the subCA2 signing private key for
transport.
Now, as I recall, you can't wrap an asymmetric key (the signing private
key) with another asymmetric key (the subsystem public key) directly, so
you need to do it using a symmetric key.
The mechanism I proposed is very similar to the mechanism used to set up
SSL, and the splitting of transport key is crucial to prevent forgery.
Let me propose a similar but slightly more complicated mechanism using
passphrases. This mechanism is probably more similar to SSL setup, and
is more secure because parts of the transport key are not sent over.
1. clone generates half of a passphrase and wraps that with the
subsystem public key.
2. master generates the other half of the passphrase, combines the two
and derives a symmetric key. The master sends back
a) the other half of the passphrase wrapped with the subsystem public
key
b) the subCA signing private key wrapped with the symmetric key.
3. clone decrypts the other half of the passphrase, combines its half
with the master half and derives the same symmetric key. Then uses the
symmetric key to unwrap the subCA signing private key.
Also, why do you need to manually transport the p12 of the subsystem
keys/certs? Each clone could very well get a different "transport" cert
(maybe double as ssl client cert -- what we call the subsystem cert)
from the orig CA to kickstart. They can just generate CSR locally, send
request, and get issuance, and then publish their public key then they
can start wrapping and transmitting secrets with each other, isn't it?
To save time, I'm leaving out details such as initial authentication
(the current token/session key mechanism should do) in the discussion.
Also, these transport certs need to belong to a special "agent" group or
some privileged group on the CA to be allowed to get wrapped keys,etc.
So, potentially it can go like (I'm only roughly laying this out...you
need to fill in the detail for design):
1. a clone is created, talks to orig CA to get started (session key, etc).
2. clone generates csr for transport certs. sends csr to orig CA to approve
3. orig CA authenticated the above request, and issues the cert, sends
the cert back to clone; meanwhile, orig CA keeps record of these
transport certs for later look up (maybe using session keys as look up
keys).
4. clone sends orig CA request to retrieve CA signing key
5. orig CA looks up and finds the clone's transport cert, generates a
cryptographically equal or better strength'd session (sym) key to wrap
it's own priv key, wrap the sym key with the transport public key (and
maybe a few other things), then sends them back to the requesting clone.
(that means the transport certs need to be of same or higher strength)
6. clone unwraps the session (sym) key, unwraps the Ca priv key and
injects into its own soft token.
I wrote all of the above and then reread this -- and I really like this
mechanism. This will allow us to avoid the whole p12 creation and
transport business altogether.
What you described here will work for setting up the clone initially.
In that case, the authentication will be via login to a security domain
and obtaining an installation token. We need to decide however, whether
the installation token is sufficient protection for this operation.
We will need another type of authentication for a subCA being created
post-install ie. scenario (5) I mentioned above. This could be the
subsystem cert which would need to point to a user on the master CA -
that would be set up when the clone is initially set up.
Also, remind me again, why do all subsystem certs of the clones have
to
be the same?
Its the way things are implemented now. We manually copy over all pk12
certs (except the ssl server cert). Remember also that the subsystem
cert is issued by the security domain CA.
About key splitting. The benefit of splitting a key includes
1. takes more effort to crack
2. no single entity (e.g. person) can have access to the whole private
key (this is very important to prevent forgery)
If key splitting is desired (note: I am not saying I encourage this, as
in most cases, this might be a bit much. I am just throwing out info),
you might want to consider looking into the following. In fact, RHCS
code might still have the Bloom/Shamir m of n secret-sharing code from
the older implementation of KRA lying around (not sure if still in
current Dogtag source).
Of course I'm not sure how much of these is automatable.
Also I'm sure the crypto used in the old code could use some update
(code is at least 17 years old)... but the logic is there.
Oh, and there was also a RecoverPinKey tool that can be converted to use
on the clone side to do reconstruction.
Finally, one word of caution, please make sure the wrapping key is at
least as strong cryptographically as the CA private key.
hope I wasn't verging on rambling...
Christina
On 10/20/2014 06:28 AM, Ade Lee wrote:
> On Mon, 2014-10-20 at 08:01 -0400, Dmitri Pal wrote:
>> On 10/20/2014 12:18 AM, Fraser Tweedale wrote:
>>> On Fri, Oct 17, 2014 at 10:04:32AM -0700, Christina Fu wrote:
>>>> 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
>>>>>
>>>>>
>>> Christina, thanks for your detailed reply. OK, so if wrapped
>>> private keys in LDAP is unacceptable, what are the other options. I
>>> will just enumerate some ideas below; we can start discussion of
>>> these alternatives or maybe they will spark other ideas.
>>>
>>> - Push private keys directly to clones. The database contains the
>>> list of clones (cn=<host>,cn=CAList,ou=Security
Domain,<basedn>)
>>> and their SecureAdminPort. Could we have an API for sending the
>>> private keys to each clone, where the keys would only be present
>>> on the wire in a secure channel, once for each clone?
>>>
>>> Drawbacks: additional logic needed to handle situations where a
>>> clone is offline at sub-CA creation time.
>>>
>>> - Pull private keys directly from generating clone to other clones.
>>> In a way, this is the dual of the previous suggestion. Clones can
>>> notice when a new sub-CA has been created in the database. The
>>> entry can contain a reference to the clone that created it, and
>>> other clones can contact that clone and request the private key
>>> over a secure channel.
>>>
>>> Drawbacks: additional logic needed to handle situations where the
>>> generating clone is offline; additional failure modes (e.g. if no
>>> clone with keys is online).
>>>
>>> - Do not automatically distribute private keys to clones. Focus
>>> effort on a good UX for administrators to distribute keys to
>>> clones.
>>>
>>> Drawbacks: seems to violate an important requirements - namely,
>>> that sub-CAs be ready to use across clones automatically (no
>>> administrator action required).
>>>
>>>
>>> I have ignored the HSM dimension above because it seems that
>>> customers using HSM are in one of two situations: 1) customer has a
>>> net-HSM used by all clones, so the key distribution problem doesn't
>>> exist, or 2) we cannot get the keys out therefore cannot distribute
>>> them.
>>>
>>> I'm not sure where pki-symkey fits into all of this. I had a quick
>>> look at the code but couldn't make much sense of it. Where should I
>>> look for examples of its intended use and capabilities, or to whom
>>> should I talk?
>>>
>>> Thanks all for your time and ongoing patience as I work out the
>>> design for this important feature.
> The feature that Christina is probably referring to was a mechanism I
> put in place a little while back to distribute a shared symmetric key
> from the TKS to the TPS during installation.
>
> I am also wary about storing wrapped CA signing keys in LDAP. These
> aren't just the keys for a user, but rather CA signing keys -- literally
> the keys to the kingdom (or at least little fiefdom).
>
> Now, I still think though that it is possible to possible to transport
> the subCA keys between clones safely. Here is one suggestion:
>
> 1. We create a new service on the CA for the distribution of subCA
> signing keys. This service may be disabled by a configuration setting
> on the CA. Whether it should be disabled by default is open to debate.
>
> 2. SubCA detects (through ldap) that a subCA has been added. It sends a
> request for the CA signing key, including the identifier for the subCA
> and half of a session key (wrapped with the subsystem public key).
> Recall that the subsystem key is shared between clones and is the key
> used to inter-communicate between dogtag subsystems.
>
> 3. The service on the master CA generates the other half of a session
> key and wraps that with the subsystem public key. It also sends back
> the subCA signing key wrapped with the complete session key.
>
> There are lots of variations of the above, but they all rely on the fact
> that the master and clones share the same subsystem cert - which was
> originally transported to the clone manually via p12 file.
>
> The subsystem certificate is stored in the same cert DB as the signing
> cert, so if it is compromised, most likely the CA signing cert is
> compromised too.
>
>> I think the best would be to have manual distribution of the keys
>> assumed by default but have a way for admin to specify that he is OK
>> with replicating keys via LDAP in a wrapped blob.
>> Not all environments are the same. In many cases wrapped keys in LDAP
>> would be good enough but in some they would not so to fail safe the
>> manual option should be default.
>>
> Given that these are CA signing keys - even if the subdomain is smaller
> - I'd rather err on the side of caution and use a mechanism similar to
> the above.
>
>> 2c.
>>
>>> Fraser
>>>
>>>
>>>>> 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
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel