RE: Proposal to anti-phishing

["Lyal Collins" <lyal.collins () key2it com au>]

> -----Original Message-----
> From: Rogan Dawes [mailto:discard () dawes za net] 
> Sent: Monday, 24 January 2005 11:22 PM
> To: Lyal Collins
> Cc: 'Florian Weimer'; 'Rafael San Miguel'; 
> webappsec () securityfocus com; Enrique.Diez () dvc es
> Subject: Re: Proposal to anti-phishing
>
>
> > > > And then there are other issues, like which smartcard + pki 
> > > > + message format must be supported by the PC, OS, and 
> > > > user's software.  And do all these factors interoperate 
> > > > smoothly with all the other software a banking customer
> > > > may have.
> > > > Finally, there is the need to re-authenicate ever customer 
> > > > in order to issue a new identifier in the form of the card.
> > >
> > > So long as the smartcard supports PKCS#11, there should be 
> no problem 
> > > interacting with it.

PKCS11 is about the cert format.  PKCS is about one way to access a cert
store.
Fields, CPS etc all make certs 'proprietary' to some level or in some
manner.  For example CA#1 has a CPS that bank_Z doesn't like.  So, Bank_Z
doesn't accept/rely upon certs from CA#1, excluding anyone who has such a
cert, making those custoemr re-enrol with another CA than bank_Z does
accept.

> > > The PKI software chosen by the bank should be irrelevant, 
> as it still 
> > > produces certificates in the standard X.509 formats.

True, that's software is only small part of the X.509 story...

> > The selected CA, cert issuing process, extensions and or 
> cert constrainst
> > fields, CA policy statement and the fields/structure in the messages
> > generally give all the PKCS 11 and X.509 a strong flavour 
> of 'proprietary'
> > implmentations.
>
> PKCS#11 is not subject to proprietary flavours, to the best of my 
> knowledge. This means that a customer that has a card reader that 
> supports PKCS#11 can interact with standards supporting 
> browsers such as 
> IE and Firefox to access the certificates stored on their smart cards.

Lets expand this scenario to a having a smartcard, smart card reader and
driver software that IE and Firefox support.  What about Opera? Lynx?
Mozilla? Netscape?   Providing the browser can access the cert, fine.  If
the reder driver is not PCSC, then there's little chance of that happening
easily with needed user setup activity, and possibly never being achieved.

> Sure X.509 has a number of optional fields that may or may 
> not be used 
> by a particular implementation of PKI. But please see below for an 
> explanation of why this doesn't matter.
>
> > Worse, many CA approachs will provide an assertion about a 
> person (lyal
> > collins) not theat person's accounts, or conversely, with 
> accounts.  In the
> > former case, I have to register my cert with each account I 
> have with each
> > (so the banks can update their account profiles with my 
> cert details) while
> > the latter case means a new cert for each account I have.  
> >
> > If this isn't a case of inplementing new 1:1 security 
> relationships just to
> > replaice existing solutions with new technology, without 
> saving costs, I
> > don't know what is.
>
> There are a couple of ways of approaching this: Either have different 
> smart-cards per bank, and the bank manages their own cards/certs 
> entirely, or let the user have a smart card, and the bank 
> only manages a 
> private/public key pair on the smart card.

So I'm still faced with having to re-enrol for a new cert for every banking
realtionship I have.  I've already spent 30mins - 1 hour to get each
account, now I'm expected to spend 30+ minutes at a post office/RA location
in order to get electronic access to these accounts!  Where is the customer
service in that?

> Either way, the bank is still in control of the issuing process. Note 
> that I have never suggested that you should have only a 
> single private 
> key and certificate, that all banks use to identify you. Absolutely, 
> each bank will want to control the certificates that they 
> recognise, and 
> allow to access their systems.
>
> The main thing that I think you missed here is that you CAN store 
> multiple key pairs on a single smart card. But I think that 

True.  The commercial liability over who issues the card, and who issues the
other certs on the smart card/device have yet to be well resolved, as far as
I know.  Who fixes the card when one cert or chip-side application fails?
I think its Singapore (or Hong Kong) where the government is fully liable
for the smart card security, even though multiple commercial entities place
certs on the chips.

> more likely, 
> and more feasible from a management perspective, is that banks will 
> issue their own smart card. That way, if you lose a single 
> card, you do 
> not lose all your identities at once.

Adding $20-$50 cost per customer.  At 6 million customers, that's a cost of
up to $300m every 2/3 years or so.

> In another email sent to this list, I proposed that banks make use of 
> the smart card facilities available on many credit and debit cards 
> already in the field, by allowing customers to use those to 
> authenticate 
> to their internet banking services. Maybe you should read 
> that email for 
> a better understanding of how I am thinking . . .

I understand the principle -it's a good idea.  In some cases, CPS et al
don't permit such use of those certs (proprietary-ness is sneaky), or
require the bank to change their business process and liability to that
required by the CA or schema (EMV, visa, mastercard et al), creating lock in
and diminished flexibility for the bank in question.  Where's the sense in
doing that?  Few banks have found any sense so far - maybe they will on day.


> > > Message format can be specified by the online application, 
> as it does 
> > > not have to interact with anyone else, other than that 
> single online 
> > > application.
> >
> > This = proprietary solutuion., What about my other financial/bank
> > relationships?
>
> Why should they have to interact with each other via the 
> Internet? They 
> already have existing relationships set up via SWIFT, etc . . .
>
> If each bank has their own certificate, they are at complete 
> liberty to 
> use them as they choose . . .
>
> > > > Technically, a good idea.  Practically, and commercially, 
> > >
> > > very hard and
> > >
> > > > expensive to do.  Requiring every on-line banking customer 
> > >
> > > to buy a new
> > >
> > > > computer in order to use on-line banking is probably worse 
> > >
> > > than giving
> > >
> > > > customers a new computer, something that does happen for high worth
> > > > individuals in a few rare cases.
> > >
> > > I'm not suggesting for a second that people will HAVE to buy a new 
> > > computer. You can buy a smart-card reader for les than 
> USD30. No need 
> > > for a new computer, if you already have one.
> >
> >
> > Smartcard readers are like sterilising bullets - the 
> benefit (germ free) is
> > far outweighed by other effects (the bullet kills you).
>
> I call bull on this. A number of banks already offer customers the 
> option of using smart cards. I fail to see how adding a smart card 
> reader to an existing PC has negative side effects?
>
> Old PC's can use serial or parallel readers, more recent PC's can use 
> USB readers. Still NEWER machines can use integrated card readers. 
> Where's the downside?
>
> > > My point was that IF manufacturers start shipping computers with a 
> > > smart-card reader already part of the PC, and with drivers already 
> > > installed as part of the OS installation, then we start 
> > > approaching the 
> > > "zero-setup" that was originally posited as the "Holy Grail".
> >
> > We can but hope - one day, Oh one day
>
> Indeed. That's what this discussion is about. Trying to get (just a 
> little) closer to that day . . .
> > Lyal
>
> Rogan
> -- 
> Rogan Dawes
>
> *ALL* messages to discard () dawes za net will be dropped, and added
> to my blacklist. Please respond to "lists AT dawes DOT za DOT net"