Subject: Re: Private Key Cloning

From: Juergen Brauckmann <[email-masked]>
Date: Mon, 19 Jun 2000 16:37:39 +0200

At 10:11 19.06.00 -0400, you wrote: 

<flushright>><smaller>If a private key generated within a hardware
cryptographic module is securely wrapped within that 

>same module, is then exported to another similar hardware cryptographic
module through an 

>authenticated key exchange where it is unwrapped and both of these
private keys are then used to 

>perform electronic signatures in a load balancing situation (e.g. OCSP
or TSA server), do you mean 

>this would not be legal in Germany?

</smaller>It is of course legal if you don't want to conform to the
German Digital Signature Act.

It is not legal if you operate according to that Act. In fact it's a
requirement to the equipment that it's not possible to duplicate the
key.

It makes some sense to forbid a single user to duplicate it's key if that
key is to be used for "valuable" signatures (this minimizes the risk that
the key may be stolen or lost unnoticed). The problem is that the current
German Signature Act does not take into account that the scenario you
described above is necessary for servers.

Regards,

  Juergen 

-- 

Juergen Brauckmann             Tel.:  040 / 8080 26 311

TC TrustCenter GmbH            Fax.:  040 / 8080 26 126

Sonninstraße 24-28   	    mailto:[email-masked]

20097 Hamburg 		    http://www.trustcenter.de

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 19 Jun 2000 14:21:34 -0400 (EDT)

> From: Paul Koning <[email-masked]>
> Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT)
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: Re: Private Key Cloning
> 
> >>>>> "FRousseau" == FRousseau  <[email-masked]> writes:
> 
>  FRousseau> Juergen, If a private key generated within a hardware
>  FRousseau> cryptographic module is securely wrapped within that same
>  FRousseau> module, is then exported to another similar hardware
>  FRousseau> cryptographic module through an authenticated key exchange
>  FRousseau> where it is unwrapped and both of these private keys are
>  FRousseau> then used to perform electronic signatures in a load
>  FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean
>  FRousseau> this would not be legal in Germany?
> 
> How would you guarantee that there's no man in the middle?  The only
> way would be to have a prior out of band secure setup of
> authenticating data, such as a shared secret or public keys used for
> this key exchange process.  While the user of such a device can ensure
> that this is done right, the manufacturer of the devices cannot.
> 
> It doesn't surprise me at all to see devices that don't allow this.
> It makes good security sense to omit such a capability.
> 
>    paul

And it doesn't seem to present insurmountable obstacles to load
balancing ... why shouldn't each server have its own signature key?
Is there a reason not to use N certificates with identical
distinguished names and different public keys?

---

From: Volker Hammer <[email-masked]>
Date: Mon, 19 Jun 2000 17:44:17 +0200

Hi,

>Juergen, 
>
>If a private key generated within a hardware cryptographic module is securely wrapped within that same module, is then exported to another similar hardware cryptographic module through an authenticated key exchange where it is unwrapped and both of these private keys are then used to perform electronic signatures in a load balancing situation (e.g. OCSP or TSA server), do you mean this would not be legal in Germany?

why you don't want to use two (or more) different key-pairs for different / fallback servers? For every key a similar certificate can be issued. This should not be a problem except for root certificates.  For TSA or OCSP servers key cloning seems not to be necessary from my point of view.

Regards
Volker Hammer.
--------------------------------------------------------
Dr.-Ing. Volker Hammer
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-458, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
--------------------------------------------------------
PGP-Fingerprint    3C9C AD64 AC6B 64CC  FA6B AE8D 2A5D 462D

---

From: [email-masked]
Date: Mon, 19 Jun 2000 15:24:05 -0400

The issue is relevant only for for a very basic PKI.  The wish is to have a
single trust anchor of one public key, no sub-CAs, yet assure availability and
load balance the CA service by cloned copies of the CA server (and its key).
This scenario pre-empts by definition each server having its own key.  However,
it also conflicts with the no-copy rule.
-Gene Hilborn

[email-masked] on 06/19/2000 02:21:34 PM

Please respond to [email-masked]

To:   [email-masked]
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: Private Key Cloning

---

From: [email-masked]
Date: Tue, 20 Jun 2000 10:24:54 -0400

I agree on what you said.  We had done it different for the load balance, the
design is to us sub-CAs for the load balance, this may be more complex.  The
result should be cleaner and for better management for long term, since the
serial number and the DN will need special care after service for a while.

And as the sub-CA method do no need to clone the CA key at all.

Mcken Mak

[email-masked] on 06/19/2000 03:24:05 PM

To:   [email-masked]
cc:    (bcc: Mcken Mak/Technology/Equifax)

To:   [email-masked]

---

From: "Jeff Davis" <[email-masked]>
Date: Wed, 21 Jun 2000 15:25:29 +0100

Hi,

Being new to this group I would just like to add my 0.00001c ( or
pennies in my case ) worth to this discussion.

The whole idea of having a private key is just that, it is private to a
single entity and not shared across many other "clones" of that entity.

IMHO, and it is very "H" in this case, cloning a private key, of any
nature, is opening yourselves up to all sorts of repudiation claims.  If
you clone once what stops you cloning "n" times without  anyone knowing
( regardless of what procedures you have in place ).  Part of the basis
of "trust" is that a private key only exists in one place under the
strict control of the owner of that key.

I support the views put forward that maybe the TSA root should sign
certificates  for level 1 TSA Agents, of which there could be as many as
required, but all of whom have a different DN ( very closely associated
with the parent TSA ).  The trust of the Time Stamp would then be
through a normal certificate chain and that only being 1 level.  Maybe
the TSA root could then go offline leaving the "work horses" to perform
the stamping.  Re-issuing of new TSA signing keys would then be quite
easy for each Agent, with only 1 out of "n" Agents being offline at any
one time, update the hardware signing module and get back online
a.s.a.p.

I may be well off the mark here, if so, just tell me to shut up and get
back in the cupboard.  However, as I am trying to learn this stuff, a
little help with my waywardness would go a long way.

Jeff