Re: key recovery vs data backup

On Wed, May 07, 1997 at 09:56:21PM -0700, Lucky Green wrote:
> At 11:47 PM 5/7/97 -0400, Carl Ellison wrote:
> >I was saying that if Sam needs to read my encrypted file/mail, then I should 
> >list Sam as a crypto-recipient.  If Acme,Inc. needs to read my encrypted 
> >file/mail, then I should list Acme,Inc. as a crypto-recipient.
> >
> >There's no safe of keys.  It's even simpler to explain to an executive.
> 
> Several people on this list asked me to elaborate on my claim that KR is
> not required. I doubt that I could put it more succinctly than Carl has in
> his post.

Unfortunately, it doesn't solve the problem at all.  In fact it
doesn't even address the problem.  So much so that reading these
replies makes me think that I am looking at different problem than
you. 

So perhaps backing up to discuss the problem a bit would be helpful. 
I hope you will forgive me if this is old ground.  

The problem is key management for an organization.  

The keys are used to protect and authenticate data owned, not by any
individual, but by an organization.  Keys are generated for the
organization's purposes, not the purposes of any individual. 
Furthermore, the individual privacy of an individual who works for an
organization is not a necessary priority for the organization. 

Organizations are composed of many individuals, some of which may not
share the goals of the organization, or who may indeed be inimical to
the organization.  And the members of an organization may vary widely
in competence, personal responsibility, and so on.  Thus, the members
of an organization cannot be trusted to do the "right thing".  [I am
using "organization" in a loose sense, so that we can consider a
business an organization, and an employee as a member of that
organization.]

In fact, in most cases, only a small fraction of the members of an
organization care more about the welfare of the organization than
about their personal welfare.  So people will almost always be more
concerned about their own personal data security than they will for
that of an organization.  This, coupled with difficulties of
coordination and control, and the above conditions, means that in a
global sense information security for an organization will always be
difficult, regardless of the security of the crypto they use. 

For a moment consider the analogy with physical keys.  Consider the
key management problem of a moderate sized corporation that occupies a
large office building.  There are office keys, storeroom keys, supply
room keys, conference room keys, bathroom keys, keys to filing
cabinets -- there are *lots* of keys, lots of different delegations of
authority involved.  In many cases there is a "key czar", a "building
coordinator" that hands out keys, and gets them back when someone
changes offices or jobs.  It *has* to be this way -- you can't rekey
the entire building when a janitor quites.  So, occasionally it is
necessary to rekey a lock, but typically keys are just reused.  Many
office keys are designed to be difficult to casually duplicate, for 
this reason.

Of course any key *can* be duplicated, but that's not really that
important -- the building is full of employees during the day, and 
the night watchman checks each person that enters after normal 
hours.  

All these physical keys all fit locks that can be broken quite easily
-- there is essentially *no* possibility of something valuable being
lost behind a lock that cannot be broken.  This is vastly different
from cryptographic keys -- for all systems of interest, encryption
represents locks that cannot be broken.  Data behind a lost 
cryptographic key is gone forever.  You can't call a locksmith or a 
safe cracker.  It's really just gone.

With this background, perhaps now you can see why I say that Carl's 
solution doesn't even address the problem.  The problem is management 
of complexity.  Carl says "encrypt to Acme Corp".  Who in Acme Corp?  
What part of the organization that is Acme Corp is authorized to know 
this particular bit of information?  Because some of the employees 
are idiots you want this built automatically into the application 
they are using for encryption/email/whatever.  How does this software 
know what policy is appropriate for which employee?  How is that 
policy distributed?  What is the interface that allows a policy to be 
defined?   How do you protect the policy definition from subversion?

Contrast that with a key-safe model, where a copy of every encryption
key is kept in a secure database.  The encryption client software only
talks to the key-safe when a new key is generated, over a
cryptographically secure channel, of course.  There is no policy the
client has to know.  The user encrypts freely without concern about
who else should get copies.  The organization knows that there is very
little chance of data loss because of lost keys, and can use any
policy it chooses to recover keys, from the company president's ad hoc
whim to a carefully specified organization al security policy. 

Access to the key-safe is critical, of course, but it can be made 
very secure -- a special-purpose piece of hardware that requires 
passwords from n out of m key czars before access is granted, for 
example.  Or the contents of the key safe can be encrypted via keys 
escrowed through a secret sharing mechanism

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Kent Crispin <kent@songbird.com> writes:
> > At 11:47 PM 5/7/97 -0400, Carl Ellison wrote:
> > >I was saying that if Sam needs to read my encrypted file/mail, then
> > >I should list Sam as a crypto-recipient.  If Acme,Inc. needs to read
> > >my encrypted file/mail, then I should list Acme,Inc. as a
> > >crypto-recipient.
> > >
> > >There's no safe of keys.  It's even simpler to explain to an executive.
> 
> Unfortunately, it doesn't solve the problem at all.  In fact it
> doesn't even address the problem.  So much so that reading these
> replies makes me think that I am looking at different problem than
> you. 

It seems to me that it is you Kent who is scrambling to find plausible
reasons why key escrow is the best or only technology to use in
corporate email systems.

> [long analogy to physical locks and keys on company premises]
>
> With this background, perhaps now you can see why I say that Carl's 
> solution doesn't even address the problem.  The problem is management 
> of complexity.  Carl says "encrypt to Acme Corp".  Who in Acme Corp?  
> What part of the organization that is Acme Corp is authorized to know 
> this particular bit of information?  Because some of the employees 
> are idiots you want this built automatically into the application 
> they are using for encryption/email/whatever.  How does this software 
> know what policy is appropriate for which employee?  How is that 
> policy distributed?  What is the interface that allows a policy to be 
> defined?   How do you protect the policy definition from subversion?

Ah I see you do acknowledge what Carl Ellison and Matt Blaze have been
saying on cryptography@c2, that key escrow has complexity problems,
contrary to what you have previously been arguing :-)

> Contrast that with a key-safe model, where a copy of every encryption
> key is kept in a secure database.  The encryption client software only
> talks to the key-safe when a new key is generated, over a
> cryptographically secure channel, of course.  There is no policy the
> client has to know.  The user encrypts freely without concern about
> who else should get copies.  The organization knows that there is very
> little chance of data loss because of lost keys, and can use any
> policy it chooses to recover keys, from the company president's ad hoc
> whim to a carefully specified organization al security policy. 
> 
> Access to the key-safe is critical, of course, but it can be made 
> very secure -- a special-purpose piece of hardware that requires 
> passwords from n out of m key czars before access is granted, for 
> example.  Or the contents of the key safe can be encrypted via keys 
> escrowed through a secret sharing mechanism

I don't see the difference.  With the encrypt to multiple recipients
approach where the second crypto-recipient is the company key you can
store the private half of the corporate key using the same techniques
you discussed above.

Access to the data requires access to the master key in both cases.

You fix the second crypto-recipient in the MUA if you wish to.  The
fire-wall can reject posts without the second crypto-recipient.  You
can use binding cryptography to ensure the fire-wall can tell that it
is an encrypted copy of the same document without the firewall needing
access to the master key.  You can't do this company has all keys in
the safe model, without givin the firewall automatic access to the
safe, which is a huge security risk.

So, I suppose you would argue that oh no, the user can by pass this
feature of the MUA, they can use a different MUA, or telnet to the
SMTP port manually.

Well, you know, people can bypass keys which are stored in the company
safe also: don't use them!

They can also walk out of the building with a floppy, store info in
their heads, or use any number of subliminal channels that abound in
crypto and internet protocols.

The advantage of the multiple recipient model is that doesn't commit
the cardinal sin/design flaw of sharing private crypto keys.

Some people have argued that multiple recipient is less suited to GAK,
and therefore it would be better to use multiple recipient, I'm not
sure that it makes that much difference.  If we get forced to put the
government as the second crypto-recipient recipient, the government
still gets to read all your mail.

The main argument against company generates all keys, company holds
all keys, to me is that it's bad crypto design.

The `it's easier to explain a safe full of all employee keys' to
management argument is nonsense also.  It's a master key either way
and just as easy to explain either way: a master key is a key that
lets you decrypt all mail.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

I'm not "scrambling", Adam. If there is anything you need to
understand here, it is that I am *not* in favor of GAK. Chisel that
in stone and think about it a bit -- your misunderstanding of my
motives causes you to gloss over my arguments and not think about
them. I am sympathetic to your concerns, and I am trying to explain
something I truly think people are missing. Think of me as
intelligent, Adam, and I will do the same for you.
> > [long analogy to physical locks and keys on company premises]
> >
> > With this background, perhaps now you can see why I say that Carl's 
> > solution doesn't even address the problem. The problem is management
> > of complexity. Carl says "encrypt to Acme Corp". Who in Acme Corp?
> > What part of the organization that is Acme Corp is authorized to know
> > this particular bit of information? Because some of the employees
> > are idiots you want this built automatically into the application
> > they are using for encryption/email/whatever. How does this software
> > know what policy is appropriate for which employee? How is that
> > policy distributed? What is the interface that allows a policy to be
> > defined? How do you protect the policy definition from subversion?
>
> Ah I see you do acknowledge what Carl Ellison and Matt Blaze have been
> saying on cryptography@c2, that key escrow has complexity problems,
> contrary to what you have previously been arguing :-)
You completely missed the point of the above paragraph -- all those
questions apply to the "encrypt to policy-specified local recipients"
model, and *don't* apply to the key-safe model.  The key-safe model 
has no significant policy issues that need to be embedded in 
software -- the only policy is "when data encryption keys are 
generated a copy is sent to the key-safe (using an encrypted channel, 
of course)."

> > Contrast that with a key-safe model, where a copy of every encryption
> > key is kept in a secure database.  The encryption client software only
> > talks to the key-safe when a new key is generated, over a
> > cryptographically secure channel, of course.  There is no policy the
> > client has to know.  The user encrypts freely without concern about
> > who else should get copies.  The organization knows that there is very
> > little chance of data loss because of lost keys, and can use any
> > policy it chooses to recover keys, from the company president's ad hoc
> > whim to a carefully specified organization al security policy.
> >
> > Access to the key-safe is critical, of course, but it can be made
> > very secure -- a special-purpose piece of hardware that requires
> > passwords from n out of m key czars before access is granted, for
> > example. Or the contents of the key safe can be encrypted via keys
> > escrowed through a secret sharing mechanism
>
> I don't see the difference.  With the encrypt to multiple recipients
> approach where the second crypto-recipient is the company key you can
> store the private half of the corporate key using the same techniques
> you discussed above.
> 
> Access to the data requires access to the master key in both cases.

It follows, therefore, that if the master key is compromised in both
systems, all data is compromised.  From that perspective, the systems
are equally secure. 

> You fix the second crypto-recipient in the MUA if you wish to.

This is precisely the point I was alluding to in the policy discussion
above.  In an organizational content, *of course* you will put all the
complexity in the MUA.  The question is, how do you change the 
"master key" indicator that is in each MUA?  Suppose that the 
organization wants different keys for different departments -- how do 
you keep track of which master key goes where?  How do all those 
MUA's get their key policy module updated?
> The
> fire-wall can reject posts without the second crypto-recipient.
How does the key policy module in the firewall get updated?
> You
> can use binding cryptography to ensure the fire-wall can tell that it
> is an encrypted copy of the same document without the firewall needing
> access to the master key. You can't do this company has all keys in
> the safe model, without givin the firewall automatic access to the
> safe, which is a huge security risk.

???
With the key-safe model the firewall never enters into the picture.

> So, I suppose you would argue that oh no, the user can by pass this
> feature of the MUA, they can use a different MUA, or telnet to the
> SMTP port manually.

No, I wouldn't argue that -- I know perfectly well that that neither
model does any good at all against a determined, competent insider.
[...]
> The advantage of the multiple recipient model is that doesn't commit
> the cardinal sin/design flaw of sharing private crypto keys.

Two things:  First, any crypto system that doesn't deal with
protection/recovery/secure-use of private keys is incomplete.
Second, keep in mind that we are talking about encryption for an
*organization's* purposes.  The whole meaning of "private" is altered
in that context. 

> Some people have argued that multiple recipient is less suited to GAK,
> and therefore it would be better to use multiple recipient, I'm not
> sure that it makes that much difference. If we get forced to put the
> government as the second crypto-recipient recipient, the government
> still gets to read all your mail.
>
> The main argument against company generates all keys, company holds
> all keys, to me is that it's bad crypto design.

You say "tumato"...

> The `it's easier to explain a safe full of all employee keys' to
> management argument is nonsense also.  It's a master key either way
> and just as easy to explain either way: a master key is a key that
> lets you decrypt all mail.
At that level of generality both these systems are identical, and
equally easy to explain. It's when you get down to the details that 
things become more interesting.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Kent Crispin <kent@songbird.com> writes:
> On Sat, May 10, 1997 at 07:19:40PM +0100, Adam Back wrote:
> > It seems to me that it is you Kent who is scrambling to find plausible
> > reasons why key escrow is the best or only technology to use in
> > corporate email systems.
> 
> Not "best".  "Easiest".  Look at it this way, Adam -- if it was easy 
> to implement Carl's model, it would already have happened, given the 
> dislike of key-escrow in the cryptographic community.  

Firstly: have you done a comprehensive survey of corporate access
systems available to commerce.

Secondly: there are a number of other forces "encouraging" the GAK
model.  Government incentives: Europe companies and research groups
get given research funding to experiment with GAK/TTP architectures.
Either the architecture is stipulated as part of the call for
proposals, or proposals involving GAK are going to get funding more
easily.

Third: people involved with key recovery at all have tended to be
defense contractor types, who are more likely to go with government
"standards" (such as TTPs/clipper/tessera/etc).

> But, when examined in detail, in light of real requirements from
> organizations, it is not easy at all.

I was under the impression that PGP Inc had done it, or is working on
it.  It's not very hard at all, all you need is PGP's existing
multiple crypto-recipient feature.

The storage of your company master key needs some thought, but that's
a common problem with either your crypto key safe model or multiple
recipient model.

> I'm not "scrambling", Adam.  If there is anything you need to
> understand here, it is that I am *not* in favor of GAK.  

I have a memory.  I recall you made several posts where-in you said
you were against GAK.  Your line of argument seems to be that the rest
of us are misguided, or are allowing are dislike of GAK to cloud our
judgement on what a good crypto architecture GAK would be applied to
corporate key escrow.  Right?

> Chisel that in stone and think about it a bit -- your
> misunderstanding of my motives causes you to gloss over my arguments
> and not think about them.  I am sympathetic to your concerns, and I
> am trying to explain something I truly think people are missing.
> Think of me as intelligent, Adam, and I will do the same for you.

I have no doubts as to your intelligence.  I understand what you are
trying to explain, and understood the first time you tried to explain;
I just disagree!  If you want to discuss your motives, the thing that
puzzles me is that your tone, overall apparent statist tendencies, and
zest on this topic are at odds with your stance on GAK.  Did you ever
come across a guy called David Sternlight?  (Clearly an intelligent
guy, but having a tendency to hang on to arguments, and stir up flame
wars, in his case I'm sure this was intentional.)  Not equating you to
Sternlight, though there are some similarities in style.

Perhaps it is just that some of us reacted negatively when you first
bought this topic up, and you are still acting in retaliatorily
hostile manner as a result of this.  Remember it was you who called
for rational calm discussion.  People impute from your apparent
statist leanings, and your arguments against people who are against
the key-safe model because of the possibility of helping build a GAK
infrastructure that you are pro-GAK.  Perhaps you need to disclaim
this more clearly.

If I believed GAK architecture was superior to multiple-recipient, and
was arguing this I don't think I'd come across in the same way.

I'm not sure that multiple recipient is that much less useful to GAK
than the safe model, buf if it is at all less useful, and the systems
otherwise basically equivalent I would argue against the safe model
for that reason alone.  However I consider the safe model inferior in
several areas neglecting this issue anyway.

> > > [claimed unique and fatally complex problems with multiple 
> > > recipient approach]
> > 
> > Ah I see you do acknowledge what Carl Ellison and Matt Blaze have been
> > saying on cryptography@c2, that key escrow has complexity problems,
> > contrary to what you have previously been arguing :-)
> 
> You completely missed the point of the above paragraph -- all those
> questions apply to the "encrypt to policy-specified local recipients"
> model, and *don't* apply to the key-safe model.  

I contend that there are similar and mostly comparable problems with
the safe model.  Lets take a look at a few:

> > > With this background, perhaps now you can see why I say that Carl's 
> > > solution doesn't even address the problem.  The problem is management 
> > > of complexity.  Carl says "encrypt to Acme Corp".  Who in Acme Corp?  

Kent says give all the keys to Acme corp, or let Acme corp generate
the keys.  Who is Acme Corp?

The next bit is as a result of multiple recipient being more flexible
than the safe model as stated.  We now have freedom to allow different
elements in the company to audit and access different departments
communications.  Naturally this extra flexibility results in policy
decisions.

> > > What part of the organization that is Acme Corp is authorized to know 
> > > this particular bit of information?  Because some of the employees 
> > > are idiots you want this built automatically into the application 
> > > they are using for encryption/email/whatever.  How does this software 
> > > know what policy is appropriate for which employee?  How is that 
> > > policy distributed?  What is the interface that allows a policy to be 
> > > defined?   How do you protect the policy definition from subversion?

If making policy decisions is too complex in your view for
implementation or practicality, well just substitute a policy dumbed
down to the level of the safe model.  Ie there is one crypto
recipient, all company communications _must_ be encrytped to it as a
second crypto recipient.

Policy distribution is something Netscape has been doing; apparently
the difference between it's browsers is largely a signed policy file
with a mildly obfuscated public verification key check in the code.

I'm sure you can arrange this same flexibility and bring in the
baggage of the policy decisions that come with it for the safe model
also if you want it.  Store keys for different departments in
different safes.  Give the master keys for the department to the
department head, etc.,etc.  Same problem, similar policy decisions,
right?

> The key-safe model has no significant policy issues that need to be
> embedded in software -- the only policy is "when data encryption
> keys are generated a copy is sent to the key-safe (using an
> encrypted channel, of course)."

As stated above, this is because you have chosen a single master key
to go with the safe model.  If you choose a single crypto-recipient,
and master key encrypting the private half of that key, you largely
have equivalence.

> > I don't see the difference.  With the encrypt to multiple recipients
> > approach where the second crypto-recipient is the company key you can
> > store the private half of the corporate key using the same techniques
> > you discussed above.
> > 
> > Access to the data requires access to the master key in both cases.
> 
> It follows, therefore, that if the master key is compromised in both
> systems, all data is compromised.  From that perspective, the systems
> are equally secure. 

Or similarly insecure.  They are quite similar, I think multiple
recipient offers more flexibility, and security advantages, as well as
avoiding the sharing of private keys.

> > You fix the second crypto-recipient in the MUA if you wish to.
> 
> This is precisely the point I was alluding to in the policy discussion
> above.  In an organizational content, *of course* you will put all the
> complexity in the MUA.  The question is, how do you change the 
> "master key" indicator that is in each MUA?  Suppose that the 
> organization wants different keys for different departments -- how do 
> you keep track of which master key goes where?  How do all those 
> MUA's get their key policy module updated?

Sign the policy file.  Certify the signing key(s).  You're going to
have this anway for authentication of email content.

> >  The
> > fire-wall can reject posts without the second crypto-recipient.
> 
> How does the key policy module in the firewall get updated?

Sign it too.

> >  You
> > can use binding cryptography to ensure the fire-wall can tell that it
> > is an encrypted copy of the same document without the firewall needing
> > access to the master key.  You can't do this company has all keys in
> > the safe model, without givin the firewall automatic access to the
> > safe, which is a huge security risk.
> 
> ???
> With the key-safe model the firewall never enters into the picture.

It does for the same functionality.  With the key-safe model how do
you know that the ciphertexts flowing out of the building are
encrypted with a key that is in your safe at all?

You don't have to do the binding cryptography stuff with multiple
recipients if you don't want to.  With the safe model you can't do it
even if you do want to.

> > The advantage of the multiple recipient model is that doesn't commit
> > the cardinal sin/design flaw of sharing private crypto keys.
> 
> Two things:  First, any crypto system that doesn't deal with 
> protection/recovery/secure-use of private keys is incomplete.

For storage encryption keys where backups are not plaintext, I agree.
For communication keys, you do not need to backup.  Doing so weakens
security.  Communications keys should be transient, forward secret
even.  Authentication keys should be persistent, back up not required,
just generate new key, and new certificates if lost.  Storage keys
should be backed up where necessary.

> > The `it's easier to explain a safe full of all employee keys' to
> > management argument is nonsense also.  It's a master key either way
> > and just as easy to explain either way: a master key is a key that
> > lets you decrypt all mail.
> 
> At that level of generality both these systems are identical, and 
> equally easy to explain.  It's when you get down to the details that 
> things become more interesting.

With the safe model, to allow access to outgoing mail, you'll have to
encrypt to a company key as second crypto-recipient, or to yourself,
thereby allowing company access through access to your key.  Quite
similar to multiple recipient.  Similar explanation.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

No.  I personally have not.  People I know have, though -- the survey 
was completed about -- um -- a year and a half ago, I guess.  So it 
is somewhat out of date.

> Secondly: there are a number of other forces "encouraging" the GAK
> model.  Government incentives: Europe companies and research groups
> get given research funding to experiment with GAK/TTP architectures.
> Either the architecture is stipulated as part of the call for
> proposals, or proposals involving GAK are going to get funding more
> easily.

That's a good point.
> Third: people involved with key recovery at all have tended to be
> defense contractor types, who are more likely to go with government
> "standards" (such as TTPs/clipper/tessera/etc).
I'm not so sure about this.

> > But, when examined in detail, in light of real requirements from
> > organizations, it is not easy at all.
> 
> I was under the impression that PGP Inc had done it, or is working on
> it.

This is one reason I'm not so sure -- PGP Inc is not a defense contractor.
> It's not very hard at all, all you need is PGP's existing
> multiple crypto-recipient feature.
If you believe all your employees will correctly use the proper PGP
incantation each and every time, even when they are tired and haven't
had coffee for 4 hours, and their kid is sick, and their wife is mad
about something, then yes, it is simple.  But of course, that is not
realistic.  Employees are forgetful, the organizations goals are not
their goals, and the PGP UI is -- well, I find it a little awkward, 
at times.

So PGP's multiple recipient feature is a fundamental building block,
but you need something more in a crypto-client to be sure that
company policy is followed. It's that "somthing more" that is the 
hard part.

And lest we get into the macho programmer argument -- of course it's
just a mere matter of design and programming.
> The storage of your company master key needs some thought, but that's
> a common problem with either your crypto key safe model or multiple
> recipient model.
[...]
> I'm not sure that multiple recipient is that much less useful to GAK
> than the safe model, buf if it is at all less useful, and the systems
> otherwise basically equivalent I would argue against the safe model
> for that reason alone. However I consider the safe model inferior in
> several areas neglecting this issue anyway.
[...]
> I contend that there are similar and mostly comparable problems with
> the safe model. Lets take a look at a few:
>
> > > > With this background, perhaps now you can see why I say that Carl's 
> > > > solution doesn't even address the problem. The problem is management
> > > > of complexity. Carl says "encrypt to Acme Corp". Who in Acme Corp?
>
> Kent says give all the keys to Acme corp, or let Acme corp generate
> the keys. Who is Acme Corp?
The company that bought the crypto software for the protection of
company secrets. I think I said "who *in* Acme Corp", though, as a
prelude to the following points, because with the multiple recipient
model there is a policy decision as to which key in Acme is the
master.
> The next bit is as a result of multiple recipient being more flexible
> than the safe model as stated. We now have freedom to allow different
> elements in the company to audit and access different departments
> communications. Naturally this extra flexibility results in policy
> decisions.
Yes. To make use of this flexibility you now need a piece of software
that allows you to produce policy decisions, sign them, and make them
visible to all the crypto clients. Another mere matter of design and
programming. And this bit of sortware needs to operate securely --
you can't just any joe blow subverting it.  

> 
> > > > What part of the organization that is Acme Corp is authorized to know 
> > > > this particular bit of information?  Because some of the employees 
> > > > are idiots you want this built automatically into the application 
> > > > they are using for encryption/email/whatever.  How does this software 
> > > > know what policy is appropriate for which employee?  How is that 
> > > > policy distributed?  What is the interface that allows a policy to be 
> > > > defined?   How do you protect the policy definition from subversion?
> 
> If making policy decisions is too complex in your view for
> implementation or practicality, well just substitute a policy dumbed
> down to the level of the safe model.  Ie there is one crypto
> recipient, all company communications _must_ be encrytped to it as a
> second crypto recipient.


You are right -- there is the degenerate case where the master key is
fixed.  However, I would contend that is *very* bad crypto design.  So
thus you have the problem of distributing information about a revoked
master key.  (Your solution, below, was that you have a signed policy
statement.  If you have a security breach, and are revoking a master
key, how do you know what signature to trust?)

Furthermore, by encrypting every document to the same master key you
have actually vastly increased your exposure -- a key-safe can have a
lot of special-purpose physical and cryptographic security, but the
master key in the multiple recipient model is almost certainly treated
the same as all other keys.  For example, in the key-safe model I can
just hand someone the master key on a floppy, and it doesn't do them
any good, because they can't get to the key-safe -- it is physically
secure.  Next I walk into the physically secure facility (I, as keeper
of the keys, have legitimate access), and change the master key.  No
security problem, no documents have been compromised, regardless of
their physical location or access.  With the multiple recipient model
if I hand out the master key, every visible encrypted document is
immediately and irrevocably compromised.  So the key-safe model 
allows you a far greater security for your data than the multiple 
recipient model.

> Policy distribution is something Netscape has been doing; apparently
> the difference between it's browsers is largely a signed policy file
> with a mildly obfuscated public verification key check in the code.
Completely different environment, of course -- I saw some traffic
where they admitted that probably without too much effort
the policy could be subverted. But I don't deny that it would be 
possible to build a policy distribution scheme -- but it is a 
non-trivial problem.

> I'm sure you can arrange this same flexibility and bring in the
> baggage of the policy decisions that come with it for the safe model
> also if you want it. Store keys for different departments in
> different safes. Give the master keys for the department to the
> department head, etc.,etc. Same problem, similar policy decisions,
> right?
Nope. Not at all. The policy for multiple recipients needs to be
interpreted by the crypto clients. But in the key-safe model policy
is almost entirely in human hands. It doesn't even have to be written
down.  

Modestly secure example: The keysafe runs on a single workstation,
hardened similar to a firewall.  The only network connections are to a
single port, which does the cryptographically secure key storing
protocol.  When a key needs to be recovered, three trusted employees
troop into the room (three passwords are required, these passwords are
essentially the master key), and retrieve the needed key on a floppy. 
Other than the authentication protocol, there is *no* policy embedded
in the key-safe, which is to say, *any* policy the company wants to
use is ok.  It may take the personal presence of the company
president, it may take a signed statement from operations staff,
whatever.  No policy is embedded in software, and no software to
support software needs to be written. 

> > The key-safe model has no significant policy issues that need to be
> > embedded in software -- the only policy is "when data encryption
> > keys are generated a copy is sent to the key-safe (using an
> > encrypted channel, of course)."
> 
> As stated above, this is because you have chosen a single master key
> to go with the safe model.  If you choose a single crypto-recipient,
> and master key encrypting the private half of that key, you largely
> have equivalence.

Not so, as I hopefully explained above, the key-safe can have enhance 
security, so that the danger of a compromise is lessened.

> > > I don't see the difference. With the encrypt to multiple recipients
> > > approach where the second crypto-recipient is the company key you can
> > > store the private half of the corporate key using the same techniques
> > > you discussed above.
> > >
> > > Access to the data requires access to the master key in both cases.
> >
> > It follows, therefore, that if the master key is compromised in both
> > systems, all data is compromised. From that perspective, the systems
> > are equally secure.
>
> Or similarly insecure. They are quite similar, I think multiple
> recipient offers more flexibility, and security advantages, as well as
> avoiding the sharing of private keys.
I spoke too soon here. The key-safe model is intrinsically more
secure.
>
> > > You fix the second crypto-recipient in the MUA if you wish to.
> >
> > This is precisely the point I was alluding to in the policy discussion
> > above. In an organizational content, *of course* you will put all the
> > complexity in the MUA. The question is, how do you change the
> > "master key" indicator that is in each MUA? Suppose that the
> > organization wants different keys for different departments -- how do
> > you keep track of which master key goes where? How do all those
> > MUA's get their key policy module updated?
> 
> Sign the policy file.  Certify the signing key(s).  You're going to
> have this anway for authentication of email content.
You may not be able to trust the signature.
[...]
> > > You
> > > can use binding cryptography to ensure the fire-wall can tell that it
> > > is an encrypted copy of the same document without the firewall needing
> > > access to the master key. You can't do this company has all keys in
> > > the safe model, without givin the firewall automatic access to the
> > > safe, which is a huge security risk.
> > 
> > ???
> > With the key-safe model the firewall never enters into the picture.
> 
> It does for the same functionality.  With the key-safe model how do
> you know that the ciphertexts flowing out of the building are
> encrypted with a key that is in your safe at all?

Oh -- I'm sorry. I didn't think through what you were saying.  You
were attempting to guard against an insider threat.  A waste of time,
probably.  He could frisbee a floppy out the window to his honey in
the red sports car. 

> You don't have to do the binding cryptography stuff with multiple
> recipients if you don't want to.  With the safe model you can't do it
> even if you do want to.
How does the firewall know what is encrypted? Just a bunch of gifs
of the family? Just the first 5000 lines of "Paradise Lost", slightly
altered?
Anyway, if the employee uses the "approved" MUA, and it isn't 
compromised, then it can store a copy of all outgoing mail, encrypted 
with the employee's key. If he doesn't use the approved MUA, or the 
MUA is compromised, then of course the firewall protections are 
useless.  So, in the keysafe model, the firewall never enters the 
picture -- it is all handled in the MUA, anyway.

> > > The advantage of the multiple recipient model is that doesn't commit
> > > the cardinal sin/design flaw of sharing private crypto keys.
> >
> > Two things: First, any crypto system that doesn't deal with 
> > protection/recovery/secure-use of private keys is incomplete.
> 
> For storage encryption keys where backups are not plaintext, I agree.
> For communication keys, you do not need to backup.  Doing so weakens
> security.  Communications keys should be transient, forward secret
> even.  Authentication keys should be persistent, back up not required,
> just generate new key, and new certificates if lost.  Storage keys
> should be backed up where necessary.

I agree with all this.  Only storage keys need to be in the keysafe.

[...]

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

On Sat, 10 May 1997, Kent Crispin wrote:
> So PGP's multiple recipient feature is a fundamental building block,
> but you need something more in a crypto-client to be sure that company
> policy is followed.  It's that "somthing more" that is the hard part.
>
> And lest we get into the macho programmer argument -- of course it's
> just a mere matter of design and programming.

Yes.  And probably a lot less design and programming than the key-safe
mechanism.  (For example, PGP already has an "encrypt-to-self" option
that makes it add the user's own key as an additional crypto recipient
of all messages; changing that to the more general "encrypt to this list
of extra keys" should be quite easy.  But designing and building a key
safe sounds like a lot of work to me.)

Of coure, you trust the users not to use versions of PGP that do not
make the corporate key a recipient of all communications, right?  If
not, then you also don't trust them not to use keys that have not been
sent to the key safe in the CAK model.

> > If making policy decisions is too complex in your view for
> > implementation or practicality, well just substitute a policy
> > dumbed down to the level of the safe model.  Ie there is one crypto
> > recipient, all company communications _must_ be encrytped to it as a
> > second crypto recipient.
>
> You are right -- there is the degenerate case where the master key is
> fixed.  However, I would contend that is *very* bad crypto design.  So
> thus you have the problem of distributing information about a revoked
> master key.  (Your solution, below, was that you have a signed policy
> statement.  If you have a security breach, and are revoking a master
> key, how do you know what signature to trust?)

In the key-safe model, you have the problem o distributing information
about a change in location (network address) of the key safe, or a
change in the keys used to authenticate access to the key safe --
similar complexity in both models.

> Furthermore, by encrypting every document to the same master key you
> have actually vastly increased your exposure -- a key-safe can have a
> lot of special-purpose physical and cryptographic security, but the
> master key in the multiple recipient model is almost certainly treated
> the same as all other keys.

You can use special hardware to generate the key pair and to store the
private key -- again, similar issues and similar solutions in both
models.

> > I'm sure you can arrange this same flexibility and bring in the
> > baggage of the policy decisions that come with it for the safe
> > model also if you want it.  Store keys for different departments in
> > different safes.  Give the master keys for the department to the
> > department head, etc.,etc.  Same problem, similar policy decisions,
> > right?
>
> Nope.  Not at all.  The policy for multiple recipients needs to be
> interpreted by the crypto clients.  But in the key-safe model policy
> is almost entirely in human hands.  It doesn't even have to be written
> down.

In either model, you can have the users' software do the same thing
every time (talk to teh same key safe, or encrypt to the same additional
key every time); and in either model you can have the users' software
do different things depending on policies (talk to different key safes,
encrypt to different additional recipients).

It's unfair to say "but I choose to do the same thing every time, and
you choose to do different things every time, therefore my model is
simpler than yours".  In fact, both models are almost equally capable of
being used in either the simple way or teh complex way.

> Modestly secure example: The keysafe runs on a single workstation,
> hardened similar to a firewall.  The only network connections are to
> a single port, which does the cryptographically secure key storing
> protocol.  When a key needs to be recovered, three trusted employees
> troop into the room (three passwords are required, these passwords
> are essentially the master key), and retrieve the needed key on a
> floppy.  Other than the authentication protocol, there is *no* policy
> embedded in the key-safe, which is to say, *any* policy the company
> wants to use is ok.  It may take the personal presence of the company
> president, it may take a signed statement from operations staff,
> whatever.  No policy is embedded in software, and no software to
> support software needs to be written.

Again, the same scenario plays equally well in the
extra-crypto-recipient model.

> I spoke too soon here.  The key-safe model is intrinsically more
> secure.

I don't see how.

--apb (Alan Barrett)

On Thu, 8 May 1997, Kent Crispin wrote:
> Unfortunately, it doesn't solve the problem at all.  In fact it
> doesn't even address the problem.  So much so that reading these
> replies makes me think that I am looking at different problem than
> you.

There are many similarities between your idea of a "key safe" for CAK
(corporate access to keys), and the idea espoused by Carl and others
of encrypting everything to a corporate key as well as to the other
recipients.


If the corporation expects to be successful at forcing it's staff to run
special software that talks to the CAK key safe, then the corporation
should also expect to be successful at forcing its staff to run special
software that adds the special coprorate key as a recipient of all
encrypted messages.

If the corporation expects to be successful at keeping the keys to the
CAK key safe secure, while still allowing an appropriate coalition of
high level managers to get access to the contents of the key safe,
then the corporation should also expect to be successful at keeping
the private part of the corporate key secure, while still allowing
an appropriate coalition of high level managers to use the special
corporate private key to decrypt messages.

If the coproration trusts those with access to the CAK key safe not to
abuse their access, then the corporation should also trust those with
access to the special corporate key not to abuse it.

> With this background, perhaps now you can see why I say that Carl's
> solution doesn't even address the problem.  The problem is management
> of complexity.  Carl says "encrypt to Acme Corp".  Who in Acme Corp?
> What part of the organization that is Acme Corp is authorized to know
> this particular bit of information?

Whatever the answer to the latter question is, it's the same in the CAK
case as it is in the "encrypt to a special coprorate key" case.

> Because some of the employees are idiots you want this
> built automatically into the application they are using for
> encryption/email/whatever.  How does this software know what policy
> is appropriate for which employee?  How is that policy distributed?
> What is the interface that allows a policy to be defined?  How do you
> protect the policy definition from subversion?

The same problems arise in the CAK case.  And the same solution: you
make the user's software do the same thing every time, and implement the
policy elsewhere.

> Access to the key-safe is critical, of course, but it can be made very
> secure -- a special-purpose piece of hardware that requires passwords
> from n out of m key czars before access is granted, for example.
> Or the contents of the key safe can be encrypted via keys escrowed
> through a secret sharing mechanism

The same problems and solutions apply in both the CAK case and in the
"corporate key as extra crypto recipient" case.


Now, having spent some time attempting to show that the two cases are
almost identical in many respects, let me point out a few ways in which
I think encrypting to a special corporate key is better than CAK.

  - With CAK, the key safe contains at least a copy of every key used by
    every staff member.  All that needs to be kept secure.  This storage
    problem does not arise in the non-CAK case.

  - With CAK, every time a user creates a new key, the user's software
    needs to talk to teh key safe.  This needs a secure channel, which
    raises further authentication problems (how does the user know that
    he's not talking to a fake key safe).  These don't arise in the
    non-CAK case.

  - Once a CAK infrastructure is in place, it is likely to be easier
    for a government to impose GAK.  It's better not to set up the CAK
    infrastructure in the first place.

    To be fair, similar arguments apply to the "add an extra crypto
    recipient" case: just add two extra crypto recipients (corporate key
    and big-brother key).  But I think that the general public is more
    likely to understand what the government wants and to reject the
    idea in this case than in the GAK case.

--apb (Alan Barrett)

I addressed many of your issues in another post, so I will be 
relatively brief...
On Sun, May 11, 1997 at 10:24:46AM +0200, Alan Barrett wrote:
[...]
> There are many similarities between your idea of a "key safe" for CAK
> (corporate access to keys), and the idea espoused by Carl and others
> of encrypting everything to a corporate key as well as to the other
> recipients.
> 
> If the corporation expects to be successful at forcing it's staff to run
> special software that talks to the CAK key safe, then the corporation
> should also expect to be successful at forcing its staff to run special
> software that adds the special coprorate key as a recipient of all
> encrypted messages.

True.

> If the corporation expects to be successful at keeping the keys to the
> CAK key safe secure, while still allowing an appropriate coalition of
> high level managers to get access to the contents of the key safe,
> then the corporation should also expect to be successful at keeping
> the private part of the corporate key secure, while still allowing
> an appropriate coalition of high level managers to use the special
> corporate private key to decrypt messages.
>
> If the coproration trusts those with access to the CAK key safe not to
> abuse their access, then the corporation should also trust those with
> access to the special corporate key not to abuse it.

Not true.  The activities are quite different in detail.  In the 
multiple recipients (MR) case the coalition keymeisters get together to 
decrypt a single document; in the key safe (KS) case the keymeisters get 
together to decrypt a key, which can then be used to decrypt many 
documents.   In the multiple recipient case, therefore, the master 
key is potentially used quite frequently, and hence much more 
exposed.  There are many other differences: I won't try to go into 
detail here.

The frequent use of the master key is a major problem, because in the 
MR case, when a master key is compromised every document in the 
company is exposed; whereas in the KS case, given appropriate 
security around the keysafe, it is not anywhere as much of a problem.

> > With this background, perhaps now you can see why I say that Carl's
> > solution doesn't even address the problem.  The problem is management
> > of complexity.  Carl says "encrypt to Acme Corp".  Who in Acme Corp?
> > What part of the organization that is Acme Corp is authorized to know
> > this particular bit of information?
> 
> Whatever the answer to the latter question is, it's the same in the CAK
> case as it is in the "encrypt to a special coprorate key" case.

Not if the encryption client encrypts to different company recipients
depending on a policy (which one might want if one tries to limit the 
compromised master key problem described above.)  Then the policy, 
contrary to what you state below, must be reflected in the client.

> > Because some of the employees are idiots you want this
> > built automatically into the application they are using for
> > encryption/email/whatever.  How does this software know what policy
> > is appropriate for which employee?  How is that policy distributed?
> > What is the interface that allows a policy to be defined?  How do you
> > protect the policy definition from subversion?
> 
> The same problems arise in the CAK case.  And the same solution: you
> make the user's software do the same thing every time, and implement the
> policy elsewhere.

Sigh.  The situations are really quite different.  In the KS
case the policy never impacts the software; in the MR case I don't 
think you can avoid it.

> > Access to the key-safe is critical, of course, but it can be made very
> > secure -- a special-purpose piece of hardware that requires passwords
> > from n out of m key czars before access is granted, for example.
> > Or the contents of the key safe can be encrypted via keys escrowed
> > through a secret sharing mechanism
> 
> The same problems and solutions apply in both the CAK case and in the
> "corporate key as extra crypto recipient" case.

Not at all.  The corporate master key is used to decrypt documents in the 
MR case; in the KS case the master key is used to get to the key 
database.  Two totally different functions, two totally different 
security paradigms.  The old saw -- you can either hide your eggs all 
over the case, and hope not too many of them get found, or you can 
put them all in one basket and guard the basket.

> Now, having spent some time attempting to show that the two cases are
> almost identical in many respects, let me point out a few ways in which
> I think encrypting to a special corporate key is better than CAK.
> 
>   - With CAK, the key safe contains at least a copy of every key used by
>     every staff member.  All that needs to be kept secure.  This storage
>     problem does not arise in the non-CAK case.

But a relatively straightforward storage problem, really.

>   - With CAK, every time a user creates a new key, the user's software
>     needs to talk to teh key safe.  This needs a secure channel, which
>     raises further authentication problems (how does the user know that
>     he's not talking to a fake key safe).  These don't arise in the
>     non-CAK case.

Not so.  You have to exactly the same issue -- how does the user find 
out the master key to encrypt to?

>   - Once a CAK infrastructure is in place, it is likely to be easier
>     for a government to impose GAK.  It's better not to set up the CAK
>     infrastructure in the first place.
> 
>     To be fair, similar arguments apply to the "add an extra crypto
>     recipient" case: just add two extra crypto recipients (corporate key
>     and big-brother key).  But I think that the general public is more
>     likely to understand what the government wants and to reject the
>     idea in this case than in the GAK case.

Arguable.  Guv won't say "everybody has encrypt every file to the
government key".  Instead they will insist that the corporate master
key be escrowed.  Any master key is an easy target.  And they will
have very good excuses for it -- corporations are public entities, tax
records, etc, so I don't think the public will get worked up about 
it.  Corporations won't, either.

Note that the keysafe model doesn't really need a master key -- it 
will work with just good physical security.  In that case the Gov 
would just issue a subpoena, I guess.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

On Sun, 11 May 1997, Kent Crispin wrote:
> In the multiple recipient case, therefore, the master 
> key is potentially used quite frequently, and hence much more 
> exposed.  There are many other differences: I won't try to go into 
> detail here.

Good point.

I happen to think that using the master key to decrypt documents is better
practice than using the master key to obtain copies of other keys, but I
can see both sides of this argument.

> > > What part of the organization that is Acme Corp is authorized to know
> > > this particular bit of information?
> > 
> > Whatever the answer to the latter question is, it's the same in the CAK
> > case as it is in the "encrypt to a special coprorate key" case.
> 
> Not if the encryption client encrypts to different company recipients
> depending on a policy (which one might want if one tries to limit the 
> compromised master key problem described above.)  Then the policy, 
> contrary to what you state below, must be reflected in the client.

You are repeating your fallacy of assuming that the key safe (KS) case has
one policy for all users and the multiple recipients (MR) case has
different policies for different users.  The truth is that the two issues
(which model to use, and how many different policies to make visible to
the users' software) are orthogonal.  You can have KS with a different key
safe for each user, and you can have MR with the same extra recipients for
each user.

> > > Because some of the employees are idiots you want this
> > > built automatically into the application they are using for
> > > encryption/email/whatever.  How does this software know what policy
> > > is appropriate for which employee?  How is that policy distributed?
> > > What is the interface that allows a policy to be defined?  How do you
> > > protect the policy definition from subversion?
> > 
> > The same problems arise in the CAK case.  And the same solution: you
> > make the user's software do the same thing every time, and implement the
> > policy elsewhere.
> 
> Sigh.  The situations are really quite different.  In the KS
> case the policy never impacts the software; in the MR case I don't 
> think you can avoid it.

Sigh.  The same fallacy again.

In the KS case, the software must know which key safe to use and how to
secure and authenticate access to the key safe.

In the MR case, the software must know which extra recipients to add, and
the corresponding public keys.

In both cases, the software is affected to some minimum extent.  In both
cases, you can choose to make the software more complex by adding more
policy knowledge.  In neither case are you forced to add more than the
minimum amount of policy information to the software.

> > > Access to the key-safe is critical, of course, but it can be made very
> > > secure -- a special-purpose piece of hardware that requires passwords
> > > from n out of m key czars before access is granted, for example.
> > > Or the contents of the key safe can be encrypted via keys escrowed
> > > through a secret sharing mechanism
> > 
> > The same problems and solutions apply in both the CAK case and in the
> > "corporate key as extra crypto recipient" case.
> 
> Not at all. The corporate master key is used to decrypt documents in the 
> MR case; in the KS case the master key is used to get to the key 
> database.

What I meant was, you can make n-of-m hardware stuff for both cases.
Surely you don't disagree with that?

> >   - With CAK, every time a user creates a new key, the user's software
> >     needs to talk to teh key safe.  This needs a secure channel, which
> >     raises further authentication problems (how does the user know that
> >     he's not talking to a fake key safe).  These don't arise in the
> >     non-CAK case.
> 
> Not so.  You have to exactly the same issue -- how does the user find 
> out the master key to encrypt to?

Finding out which key to encrypt to in the MR case is analagous to finding
out which key safe to talk to in the KS case.  Securing and authenticating
the channel to the key safe in the KS case is an extra issue that does not
have a counterpart in the MR case.

--apb (Alan Barrett)

On Mon, May 12, 1997 at 11:28:19AM +0200, Alan Barrett wrote:
> On Sun, 11 May 1997, Kent Crispin wrote:
> > In the multiple recipient case, therefore, the master 
> > key is potentially used quite frequently, and hence much more 
> > exposed.  There are many other differences: I won't try to go into 
> > detail here.
> 
> Good point.
> 
> I happen to think that using the master key to decrypt documents is better
> practice than using the master key to obtain copies of other keys, but I
> can see both sides of this argument.

Your secretary of many years changes her passphrase, then forgets it. 
She has literally thousands of documents encrypted under that key. 
You tell her "There was a memo I put out two years ago -- we
formulated a quote for them, and *I need that number*." So you call in
the company security officer to decrypt all those documents, which 
are filed in several different places?  Contrast this with just 
restoring the key.

[...]

> You are repeating your fallacy of assuming that the key safe (KS) case has
> one policy for all users and the multiple recipients (MR) case has
> different policies for different users.  The truth is that the two issues
> (which model to use, and how many different policies to make visible to
> the users' software) are orthogonal.  You can have KS with a different key
> safe for each user, and you can have MR with the same extra recipients for
> each user.

The models I have assumed are: KS -- a single keysafe and multiple 
clients; MR -- a single master key generating point, and multiple 
clients.  In the KS model all the clients talk to a single server, 
and there is no policy issue.  In the MR case, if there is a single 
master key there is no policy issue that impacts the clients, but if 
there are multiple master keys then different clients are configured 
differently, according to the policy, and that configuration is 
controlled centrally.

I confess that I hadn't considered the case of multiple keysafes in
the same organization -- and for very large organizations you might
want to do that.  But the whole point of a keysafe is that you
concentrate expense protecting the keysafe, and, in practice, it seems
to me, the boundaries between keysafe domains (to coin a term) would
be pretty well defined.  And, the only policy issue for KS clients is 
which keysafe to talk to.  This is pretty much fixed at installation 
time. 

> > Sigh.  The situations are really quite different.  In the KS
> > case the policy never impacts the software; in the MR case I don't 
> > think you can avoid it.
> 
> Sigh.  The same fallacy again.
> 
> In the KS case, the software must know which key safe to use and how to
> secure and authenticate access to the key safe.
> 
> In the MR case, the software must know which extra recipients to add, and
> the corresponding public keys.
> 
> In both cases, the software is affected to some minimum extent.  In both
> cases, you can choose to make the software more complex by adding more
> policy knowledge.  In neither case are you forced to add more than the
> minimum amount of policy information to the software.

You *could* design a system with multiple distributed keysafes, 
perhaps in an effort to minimize exposure, but I think this would be 
the worst of both worlds.

> > > > Access to the key-safe is critical, of course, but it can be made very
> > > > secure -- a special-purpose piece of hardware that requires passwords
> > > > from n out of m key czars before access is granted, for example.
> > > > Or the contents of the key safe can be encrypted via keys escrowed
> > > > through a secret sharing mechanism
> > > 
> > > The same problems and solutions apply in both the CAK case and in the
> > > "corporate key as extra crypto recipient" case.
> > 
> > Not at all. The corporate master key is used to decrypt documents in the 
> > MR case; in the KS case the master key is used to get to the key 
> > database.
> 
> What I meant was, you can make n-of-m hardware stuff for both cases.
> Surely you don't disagree with that?

I don't disagree that you *could* do it.  I think it unlikely that you
would do it for the multiple recipient case.  I believe that in the MR
case the master key(s) (especially if there are multiple master keys)
would use exactly the same encryption algorithm as the normal
encryption case.  That is the obvious, straightforward way to do it. 
If you use another encryption algorithm for the master then you have a
whole raft of other problems to deal with.

And it would be crazy to require the presence of N people to decrypt 
any file with the master key -- consider the case of your secretary...

> > >   - With CAK, every time a user creates a new key, the user's software
> > >     needs to talk to teh key safe.  This needs a secure channel, which
> > >     raises further authentication problems (how does the user know that
> > >     he's not talking to a fake key safe).  These don't arise in the
> > >     non-CAK case.
> > 
> > Not so.  You have to exactly the same issue -- how does the user find 
> > out the master key to encrypt to?
> 
> Finding out which key to encrypt to in the MR case is analagous to finding
> out which key safe to talk to in the KS case.  Securing and authenticating
> the channel to the key safe in the KS case is an extra issue that does not
> have a counterpart in the MR case.

??  How do you know that the channel through which you get the master 
key in the MR case is secure?  You surely don't just pull it off the 
net.  It's signed?  Then the problem just recurses -- how do you know 
the signature is good?  This is exactly the problem you have 
contacting the keysafe.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

On Mon, 12 May 1997, Kent Crispin wrote:
> > What I meant was, you can make n-of-m hardware stuff for both cases.
> > Surely you don't disagree with that?
>
> I don't disagree that you *could* do it.  I think it unlikely that you
> would do it for the multiple recipient case.  I believe that in the
> MR case the master key(s) (especially if there are multiple master
> keys) would use exactly the same encryption algorithm as the normal
> encryption case.  That is the obvious, straightforward way to do it.
> If you use another encryption algorithm for the master then you have a
> whole raft of other problems to deal with.

You can have the same algorithm (visible at the user side) whether or
not you have special hardware for protecting the private half of the key
pair from exposure.

> > Finding out which key to encrypt to in the MR case is analagous to
> > finding out which key safe to talk to in the KS case.  Securing and
> > authenticating the channel to the key safe in the KS case is an
> > extra issue that does not have a counterpart in the MR case.
>
> ?? How do you know that the channel through which you get the master
> key in the MR case is secure?  You surely don't just pull it off the
> net.  It's signed?  Then the problem just recurses -- how do you
> know the signature is good?  This is exactly the problem you have
> contacting the keysafe.

Knowing the right key in the MR case is static information, analagous
to knowing the network address of the key safe in the KS case.  For
example, in the MR case, the key could be distributed on a floppy disk
along with the special software, while in the KS case the location
of the key safe could be so distributed.  OK, you also need a way of
changing the (MR) key or of moving the (KS) key safe, but that doesn't
happen often and similar issues would appear to arise in either case.

But in the KS case, there would also need to be a mechanism to protect
the channel between the user and the key safe every time the channel is
used, and that extra mechanism does not appear to have a counterpart in
the MR case.  Not really a big deal, but it is a whole extra protocol to
be designed.

--apb (Alan Barrett)