Re: Multi-layered PKI implementation
On Thu, May 04, 2006 at 08:15:05PM +0100, James Westby wrote:
>
> 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.
>
I had thought that my reply was already rather verbose. I have no
quarrel with being verbose, and I think OP has gotten the idea that an
accurate answer to his quick question will not be terse. IMHO, any
answer shorter than your present one is surely inadequate, as was mine.
Cheers.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: