Re: Multi-layered PKI implementation
On (04/05/06 10:37), Paul E Condon wrote:
> On Thu, May 04, 2006 at 05:28:18AM +0100, James Westby wrote:
> > On (03/05/06 20:29), Grant Thomas wrote:
> > > When large buildings are keyed for locks, locks can be keyed for
> > > different layers of security.
> > >
> > > So, there might be the highest key, or skeleton key's used in old
> > > houses that opened all the doors, and multiple levels of sub keys,
> > > down to a key that opens only one lock.
> > >
> > > I think I have a grasp on the basics of PKI as it relates to X.509
> > > certificates, but I'm wondering if there is a PKI implementation that
> > > allows for multiple layers of access built into the keys themselves.
> >
> > PKI is for authentication, not for access control.
> >
I think there is some misunderstanding here, so I'm going say what I
understand by (X.509) PKI. I'll start with X.509 in it's most common
usage (I think), SSL. SSL uses public keys to exchange bulk transport
keys to encrypt the session, but it also provides authentication using
X.509 certificates.
Below Alice is a customer, Bob is an online retailer and Eve is a nasty
evil scammer.
Without PKI:
Alice -> Bob: I want to by a shiny wotsit from you for 500 monkeys. Can
we encrypt the transaction so I can send you my credit card details?
Bob -> Alice: Sure, my public key is 12345.
Alice -> Bob, thanks, here's our shared secret encrypted with your
private key.
Bob and Alice complete their transaction in secret, and Alice get's her
shiny wotsit. Everybody is happy.
Now try again, but this time Eve has tricked Alice in to going to her
website instead (using phishing, DNS poisining etc.) and she has done a
very good job of making it look the same.
Alice -> Eve: This time I fancy one of those big woompas. Can we encrypt
our session again?
Eve -> Alice: (doing her best Bob impression) Sure, my public key is
6789.
Alice -> Eve, thanks ...
And Alice is none the wiser.
Now let's try it again with X.509 PKI. Bob now has a valid certificate
from Tony, and Alice has already obtained Tony's public key *over a
secure channel*. (From now on I will omit the request from Alice along
with the useless tat she insists on buying)
...
Bob -> Alice: Sure, my public key is 12345, and here is my certificate
from Tony.
Alice whips out her calcuator and verifies the signature on the
certificate using Tony's public key. She then checks the certificate
contains Bob's name, Public key, that it hasn't expired etc.
Alice -> Bob: Thanks...
So that's how it works most of the time. Now Eve tries again
...
Eve -> Alice: Sure, my public key is 6789, and here is my certificate
signed by Tony.
Now, assuming Tony has been doing his job properly one of two things
will happen
1) Eve has a valid certificate, but it won't have Bob's name on it.
2) Eve has a fake certificate and Tony's signature will not verify.
Either way Alice knows that Eve is trying to trick her.
Now to get some idea of how access control might come in to it change it
a bit to use the little used other feature of SSL (on the general
Internet at least), client certificates.
A company sets up an agreement with their supplier when they move to
Internet based ordering that the supplier will check that when a member
of staff places an order they will check a list that they have provided
to see if they are authorised to spend that much money. This is a kind
of access control.
To implement this the company sets up their own CA, and provides the
public key to the supplier. They then issue each memeber of staff with a
public key, and associated certificate.
When an employee makes a transaction they enter their name
(Identification), and the supplier then looks up the amount they are
allowed to spend in the list provided by the company, and checks that
this transaction qualifies.
Instead of a password when placing the order the employee will use their
public key (probably in some kind of challenge-response protocol to
check they have the corresponding private key. Without the certificates
an employee can just generate a key pair themselevs and use this, but
with the inclusion of the PKI they cannot.
So, I hope this explains why I think that X.509 PKI as explained above
deals with the authentication of entities, rather that the access
control.
However thinking about it more, SPKI does can give the hierarchical
structure the OP was suggesting. It can actually produce more complex
structures, and also do pretty much the same thing as X.509.
>
> This statement may be true, but only in a very narrow sense that
> escapes me.
I hope I have explained above why I consider it to be true.
> PKI stands for Public Key Infrastructure.
Yes.
> It has to do with *public* keys, which are used for encrypting
> information.
Yes.
> Encryption is commonly believed to be a way to control
> access to information.
Yes.
> One may have access to an encrypted document
> but, without the key for decrypting it, one does not have access to
> the information.
Yes.
However PKI is not normally taken to mean public keys and how they are
used, but instead the infrastrucure that supports them (at least in my
estimation). This is key distribution, authenticity, CAs, RAs, escrow,
CRLs etc.
> OTOH, I think that OP's question does reveal a
> misunderstanding of dual key cryptography. Suppose a business wants to
> have an information 'czar' who has access to all business documents
> generated by employees of the business in the conduct of their work.
> For this, dual key encryption has little to offer over more
> traditional single key encryption in which the same key is used to
> both encrypt and decrypt. For the 'czar' to fulfil his duties, he
> needs to have under his control a private database of company
> keys. Unlike real physical keys to doors, he does not have to carry
> these keys around in a pants pocket. He can't use them unless he is
> sitting at a computer that has access to company documents in digital
> form. For him, there is no particular benefit in having just one key
> for his personal use, and, in any case, it is easy for him to encrypt
> his database and keep in his posession only the decryption key of his
> database.
Yes, but this appears to be a two level hierarchy, not the most
interesting.
>
> So it seems to me that a layered structure for public keys has no
> target audience of potential users, and therefore may very well not
> have been invented.
Does SPKI meet your definition? I'm not sure.
It is certainly very elegant in my opinion. Both in the design and the
idea. It can be used to do some very interesting things that are not
possible with X.509.
>
> But there are lots of useless inventions in this world, so there may
> be proposals for layered dual key systems.
>
> The whole business of certificates and certificate authorities has to
> do with publishing reliable information about who has *access* to the
> private key that matches a published public key. Here layering seems
> to be already implemented,
Why do you say this? (I'm genuinely interested)
Are you refering to the hierarchy of CAs that exists?
You could do something where if a cert was issued by a CA higher in the
chain it had more access. However I wouldn't consider this very
practical. And cross certificates might make it difficult by causing the
strucure to have loops and other trickeries.
> but has little similarity to the layer
> structure of physical keys to doors in a building.
Agreed.
> PKI is a tricky
> business with lots of nasty little problems for which solutions must
> be invented and implemented.
Nasty nasty nasty.
> An analogy to the keying of a building
> only hides its real difficulties.
>
Yeah, I would say so.
And we haven't even touched on the other major PKI system, used
frequently on this list. Could that be said to have some form of
hierarchical structure? Probably not one that could be put to much use.
Apologies for the long email, but I felt the need for clarity, and for
me clarity equals verbosity, but it probably doesn't from your end.
Cheers,
James
--
James Westby
jw+debian@jameswestby.net
http://jameswestby.net/
Reply to: