Subject: RE: Private Key Cloning (TSA keys)

From: Michael Zolotarev <[email-masked]>
Date: Wed, 21 Jun 2000 14:53:14 +1000

Simon,
(I'm taking luxury of being in the same time zone with you, so I can answer
the first :)

What you are saying is absolutely right, and technically I believe we all
know that it is more practical to clone the keys, than to come up with the
solution around it. But the argument has started as a result of the fact
that some legislations, namely German Digital Signature Law, prohibit key
cloning. So we've been discussing just one of the possible solutions to get
around the restrictions of the law.

I'm still not convinced, though, that the interpretation of the law is
correct. Taking your example with accelerator - would it be regarded as a
breach of the law? If not, and the accelerator is all right, what makes it
dramatically different from cloning the key in the environment which can be
formally certified as a security-equivalent to the accelerator's?

The law is written for general use, and each particular scenario requires
specific peruse. I'm wondering if we are trying to scare ourselves away even
before the law has a chance to "speak out". Would really like to hear from
anybody who has legal expertise and can provide an interpretation of the
German Law for that specific case.

Regards
Michael

> -----Original Message-----
> From: Simon McMahon [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2000 2:39 PM
> To: Michael Zolotarev; [email-masked]; Paul Koning
> Cc: David P. Kemp; [email-masked]; [email-masked]
> Subject: Re: Private Key Cloning (TSA keys)
> 
> 
> Hi All,
> 
> I've been considering load balancing and Private Key cloning 
> for another
> project (not TSA) but a lot of the issues are the same. I 
> think the problems
> of messing with the client software to fix what looks to me 
> like a server
> problem is a bad idea. Anyway, here is my 2c worth.
> 
> Performance / availablilty is a problem that the TSA server 
> has and load
> balancing is one solution to address that problem. In my 
> opinion any load
> balancing scheme that impacts on the clients will not be very 
> scalable or
> interoperable and should be avoided. In other words cloning 
> the private key
> is necessary to do load balancing transparently to the client base.
> 
> The problem is legislation which boils down to "dont copy 
> that private key".
> 
> However, if the cloned private keys were controlled in such a 
> way that they
> could not be seperated and used independantly outside a well defined
> boundary, e.g. the TSA, couldn't they still be considered as 
> one instance of
> the private key since externally (to the TSA) there would be no way of
> knowing that more than one copy exists within the TSA. The 
> TSA would also
> have to show that any loss or theft of any copy of the 
> private key, for any
> amount of time, is detectable and would result in revocation 
> of that key.
> 
> As an extreme example - consider a hardware accelerator with 
> two modular
> exponentiation processors on board. The TSA application loads 
> up one private
> key but the accelerator splits it into two copies one loaded 
> into each of
> the processors. The TSA application then pumps signature 
> requests at the
> accelerator and has no control over which processor inside 
> the device does
> the operation. The accelerator offers no other services which 
> would allow
> either copy of the private key to be messed around with. If 
> the accelerator
> was evaluated to Fips 140, ITSEC, CC or whatever, then surely 
> there would be
> no problem with the legislation here.
> 
> Scaling that example up to physically seperate devices within 
> a TSA might
> require a security evaluation of the TSA, or at least that 
> physical part tha
> t includes the devices and management processes for them but 
> wont TSAs need
> to be evaluated anyway ?
> 
> Simon McMahon
> ERACOM Pty. Ltd.
> 
> ----- Original Message -----
> From: Michael Zolotarev <[email-masked]>
> To: <[email-masked]>; Paul Koning <[email-masked]>
> Cc: Michael Zolotarev <[email-masked]>; David P. Kemp
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Sent: Wednesday, 21 June 2000 13:21
> Subject: RE: Private Key Cloning (TSA keys)
> 
> 
> > Guys,
> >
> > Let's talk about one issue at a time.
> >
> > 1. Using self-signed TSA certs.
> > The specifics of timestamping framework, in my opinion, 
> make it perfectly
> > normal and acceptable that a client would trust a TSA 
> directly. A TSA can
> be
> > generally considered a TTP, with no pressing need to have a TSA cert
> issued
> > by other TTP (a CA). Consequently, there should be nothing  wrong in
> having
> > a self-signed TSA certificate. If the current draft 
> precludes from doing
> it,
> > or makes the possibility of it confusing, I believe it 
> should be fixed.
> > (This is why I cc-ed Denis on this).
> >
> > 2. Assuming that using self-signed TSA certs is Ok, then we 
> do have an
> issue
> > of handling an array of crypto boxes. The solutions for simplifying
> client's
> > side trust configuration proposed in the recent traffic 
> were all about the
> > same: making the TSA to allocate a dedicated "signing key", 
> and to sign
> the
> > 'real operational' TSA certs with that key.
> > I agree that this 'redirection' would simplify the client's 
> side. The rule
> > of trust for the client would be something like "Trust any TSA
> certificate,
> > signed by THAT key-signing cert".
> >
> > Note that this makes a TSA operating more like a mini-CA, 
> signing the
> certs
> > for the keys it generates itself with yet another key it has [just]
> > generated. This creates extra inconvenience for the TSA 
> management - they
> > would have to maintain a separate [and potentially secure]
> > procedure/facility. Probably even having to allocate a 
> different DN for
> each
> > of the 'operational' certificate as well? But this is not a 
> huge issue -
> who
> > cares about poor system administrators :)?
> >
> > As a conclusion, I personally do not see any problems with 
> that approach,
> > and tend to agree that the problem of key cloning for TSA 
> can be solved
> with
> > the 'redirection'.
> >
> > Regards
> > Michael
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, June 21, 2000 3:07 AM
> > > To: Paul Koning
> > > Cc: [email-masked]; David P. Kemp; [email-masked]
> > > Subject: Re: Private Key Cloning
> > >
> > >
> > > Paul Koning wrote:
> > >
> > > >
> > > >  Michael> I can see a problem with it with self-signed TSA
> > > >  Michael> certificates. Normally, a client would be 
> configured to
> > > >  Michael> directly trust THAT [self-signed] TSA cert.
> > > Having a set of
> > > >  Michael> self-signed TSA certificates would be a configuration
> > > >  Michael> nightmare for the clients. And then you add 
> another crypto
> > > >  Michael> box to your load balancing array on TSS, and 
> then another
> > > >  Michael> one...
> > > >
> > > > So have one of the copies self-sign its own key and in 
> addition sign
> > > > each of the other keys.  Is there a problem with that?
> > > >
> > >
> > > I suspect that this would not be acceptable.  The draft
> > > indicates that TSA
> > > keys should only be used for signing timestamps.  Your 
> proposal allows
> > > signing other keys (creating certificates) as well.
> > >
> > > The best solution is to create a separate key that is trusted
> > > to create TSA
> > > certificates and is used only for that purpose, or to get
> > > another (trusted)
> > > CA to sign each of the TSA keys.
> > >
> > > Terry
> > >
> > >
> >
>

---

From: "Simon McMahon" <[email-masked]>
Date: Wed, 21 Jun 2000 16:08:45 +1000

> ... But the argument has started as a result of the fact
Is that the SigG / SigV German signature law ?
I thought that was more for personal private keys where authentication data
(e.g. the PIN) is provided for EVERY signature generated by the private key
as well as "no copying the private key". Surely that is not relevant to TSA
servers where no one is there to enter a PIN.

> formally certified as a security-equivalent to the accelerator's?
Yes, its a question of whether it is within the law, and within which
relevant law. The german signature law that I have indirectly worked with
was very specific but in my opinion not relevant to private keys used by
unattended servers.

> German Law for that specific case.
That would be good but I'll be surprised if you get any. What good is legal
advice that is not based on actual case law anyway ? There are no TSA's yet
(are there ?) let alone cases regarding them ?

Using a time-stamping key to self sign TSA certificates looks a bit like a
kludge to me to fix a problem that TSA's may not even have. Surely well
defined key usage, particularly single key usage, is a good security goal to
achieve that this approach undermines.

Simon McMahon
ERACOM Pty. Ltd.

---

From: Juergen Brauckmann <[email-masked]>
Date: Wed, 21 Jun 2000 09:20:12 +0200

>servers where no one is there to enter a PIN.

Funnily it is relevant. CAs that want to operate according to SigG/SigV
have to offer a timestamping service. This is a requirement of the law.
They have to sign the timestamps with signatures that comply with that law.
The current SigG does not recognize the necessity to have server
keys/certificate, and so all restrictions to personal private keys apply to
CA/TSA operating keys. With some tricks (mostly not technical) we can get
around entering a PIN for every timestamp issued, but the "no copying a
private key" issue still applies.

>was very specific but in my opinion not relevant to private keys used by

As all servers that want to operate according to the German Digital
Signature Law must issue signatures that comply with this law, it is
relevant. 

We hope that a revision of the law will contain a notion of "server
keys/certificates", so that all the things that are not appliable for
CAs/TSAs will disappear... .

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: "Simon McMahon" <[email-masked]>
Date: Wed, 21 Jun 2000 19:12:10 +1000

> CAs/TSAs will disappear... .
So perhaps SigG/SigV compliant TSAs should not attempt load balancing until
the revision to the law is released. If the revision is really likely then
wont this problem just go away ?

> ... With some tricks (mostly not technical) we can get
Surely this is a better approach, to use tricks to get around the
deficiencies in the law, rather than trying to accomidate it in the standard
when it gets too messy. Especially if the law is likely to be changed to
accomidate CA/TSA servers anyway.

I guess the analogy with an accelerater with controlled private key copies
within the secure perimeter was not tricky enough to convince you :-).

I know of an ITSEC evaluation with SigG/SigV compiance which argued that
copies of private keys was OK because they were made in order to move the
private key from one module to another within the secure perimieter. It
wasn't a TSA, of course, and the existance of two copies was only for an
instant before the previous copy was destroyed. We are talking about long
term persistance of multiple copies of the private key and doing signatures
with them, but as long as they stay within the target of evaluation's secure
perimeter ...

Regards,

Simon.