[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: On shared keys (was RE: SOI: identity protection and DOS)

Can anyone shed some light on why bank networks have not moved to Public Key
Cryptography based security in their ATMs?

I don't claim to know but I am beginning to wonder if it is because of the
implied use of a (potentially new) TTP who will need to issue certificates.
(I assume that for practical reasons, the use of Public Key Cryptography
implies the use of a PKI in some PKIXish fashion ) The political obstacles
of using a PKI in the world of Financial Institutions seem to pale in
comparison with the challenge of key management in a shared secret only
world.  Several projects that require trusted/encrypted communications chose
to use PKI but often ran aground amid heated debates of: Who be the root
authority? Should a new one be created? Who will control it? Can we use some
existing root? Who favors which? ...and so on.  Certainly I have watched
(and continue to watch) some of the (technologically) most elegant and
useful PKI projects hit the wrong political notes and wither on the vine.

The argument that Alex Alten makes is one I disagree with (despite his
having made it necessarily unpleasant to do so) for obvious technical
reasons.  That said, I wonder if those who continue to use shared secrets do
so more to avoid the aforementioned political strife.   I myself have taken
to making a much greater effort to watch for these political 'icebergs' when
designing a solution.

The other obstacle seems to be that for some reason it appears that people
get ambitious about issuing X.509 certificates as they do with nothing else.
No one seems content to issue a certificate for a single application and
make that application easy to deal with.  Hence the credit card certificate
wants to be used to secure email, establish VPN sessions, do client
authenticated SSL, sign purchases on the internet, draw cash, give access to
workplace, protect the cell phone and be accepted by the car wash.  I see
this desire to have multipurpose certificates as an obstacle to getting ANY
useful certificate out into the hands of the public.  These ambitions are
often the reason why otherwise straightforward and well bounded applications
fail.

Then there is a second obstacle in practical deployments and use of PKI.
The registration process!  For some reason, organizations seem to be
comfortable with and have a history of creating and registering shared
secrets between parties.  These same organizations seem to have a hard time
coping with the registration process for certificates.  Not quite sure why.
Insights into this issue will also be interesting.  I have my share of
bruises and opinions from attempting to tackle this in banking, but would
love to hear other's opinions.

I realize that this discussion belongs as much on the PKIX list as here but
because the scaling of IPsec depends on effective use of PKI, I thought it
would be important to bring these points up here.  A desktop VPN certificate
for a user is likely to get bogged down trying to be his email cert, his SSL
cert, his... you get the picture.

Khaja
PS: As Jaswant Sing, India's minister of External Affairs and Defense said
in a speech with Secretary Powell, "We disagree, but I don't see a reason to
be disagreeable about it."


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sandy Harris
> Sent: Friday, November 30, 2001 7:11 AM
> To: 'IPsec WG'
> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS)
>
>
> Alex Alten wrote:
>
> > I will re-iterate my position.  If a network security system is properly
> > designed then either Public Key or Symmetric/Private Key cryptography
> > will work fine in establishing trust.
>
> So far, so good.
>
> > I furthermore claim that Symmetric/Private Key cryptography
> > will scale to great numbers of users
>
> Sorry, but this is nonsense. The classic problem with symmetric crypto is
> key management. It neither scales well nor works well across
> administrative
> boundaries.
>
> Consider n sites which all want to communicate.
>
> For symmetric ciphers, you need n*(n-1)/2 unique keys, each of which is
> known to exactly two players and none of the others. Moreover, you have
> to communicate those keys securely to the second player in each case, and
> then keep it secure on both systems.
>
> With public key, you need only n key pairs. There is no need to
> communicate
> keys securely; the system is designed to work even if the enemy knows the
> public keys. Nor do you have to manage security for multiple keys, or keep
> track of who each key is shared with. You just need to keep your private
> key secure, not shared with anyone.
>
> Of course you can build a kerberos-like system using symmetric ciphers
> that has many of the advantages of public key. Using a central key server
> reduces the number of keys to n client-to-server keys and may simplify
> management. However, I doubt such a centralised model is appropriate for
> Internet infrastructure.
>
> > and I use the bank ATM secure network using DES as an excellent example.
> > ...
>
> I think that's an irrelevant example. A tightly controlled single purpose
> terminal-to-mainframe network under a single administrative authority
> bears no useful resemblanmce to the Internet. Someone gave a good detailed
> analysis earlier in the thread. You should re-read it.
>
> > As far as I'm concerned this should be the end of the discussion
>
> I agree, but for opposite reasons.
>
> > about whether or not Symmetric/Private Key cryptography can scale to
> > large numbers of users in
> > an efficient, easy to use by ordinary people, inexpensive to implement
> > manner and
> > interoperable between devices made by different manufacturers and
> > maintained by
> > different organizations.  It has been done for the past 20
> years by what is
> > probably the most successful world-wide commercial networked
> security system.
> >
> > Anyone who still claims that Public Key is superior to
> Symmetric/Private Key
> > cryptography, or that it is the only way to scale, is a *damn
> fool* and should
> > be treated as such.
>
> How about "obviously superior for some purposes, including most key
> distribution applications" and "almost always the best way to build
> scalable systems"?
>
> Methinks you'll consider me a fool. I heartily return the sentiment.
References: