RE: Proposal to anti-phishing

["Adler Eliacin" <AEliacin () amicas com>]

-----Original Message-----
From: lists () dawes za net [mailto:lists () dawes za net]
Sent: Monday, January 24, 2005 3:05 PM
To: Lyal Collins
Cc: 'Florian Weimer'; 'Rafael San Miguel'; webappsec () securityfocus com; Enrique.Diez () dvc es
Subject: RE: Proposal to anti-phishing

Quoting 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.

No, PKCS#11 is about HOW to access a Hardware Security Module:

From: http://www.rsasecurity.com/rsalabs/node.asp?id=2133
PKCS #11: Cryptographic Token Interface Standard

This standard specifies an API, called Cryptoki, to devices which hold
cryptographic information and perform cryptographic functions. Cryptoki,
pronounced crypto-key and short for cryptographic token interface, follows a
simple object-based approach, addressing the goals of technology independence
(any kind of device) and resource sharing (multiple applications accessing
multiple devices), presenting to applications a common, logical view of the
device called a cryptographic token.

X.509 is about the CERT format. and as you say, various CA's may make the certs
proprietary by using or not using certain extensions.

> > > 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.

If the driver for the card reader provides a PKCS#11 interface to the hardware
device, any browser that is standards compliant (i.e. implements PKCS#11) will
be able to use it.

It does not necessarily have to be PC/SC compliant at a hardware level, so long
as the interface to the user space application is PKCS#11 compliant.


> > 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?

I think that the ATM scheme that I suggest in my other email should be able to
reduce that time to a much smaller period. And, in fact, the bank could create
the private key and cert prior to even sending the card to the user. No setup
time involved.

> > 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.

Not if you use the existing smart card capability already issued to the customer
in the form of credit or debit cards. Not sure what the cost per certificate is,
but the cost of the card could be covered already.

> > 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.

THAT I don't know about. That could put the kibosh on the whole plan :-(

Regards,

Rogan