Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: Smart card proposal
From: Rishi Pande (rishi.pandegmail.com)
Date: Mon Jan 24 2005 - 11:42:03 CST
I like Rogan's solution. But, I think by putting these card-readers at
internet cafes (a rarity in my town - and I stay about an hour away
from NYC) you are basically circumventing the solution that online
banking offers- ease of use - it's 4 am let me go and check my bank
account. What you are proposing is no different from installing more
and more ATM centers where you are sure of the security of the
hardware. Also imagine the help desk calls that the banks will get if
this does go into place. Not sure about the banks at your end but most
banks in the US are not too much into the business of becoming
I do like the direction that this discussion is taking though. We may
just hit upon something that will turn out to be the best.
On another note, is anyone following this discussion going to the
OWASP meet in NY tomorrow? IT may be worth our while to sit and talk
about it for a bit.
Just my $0.02
On Jan 24, 2005, at 3:00 AM, Rogan Dawes wrote:
> Hi Michael,
> My responses to your comments are inline.
> Michael Silk wrote:
>> I like it :)
>> But let me make some comments.
>> Assuming this does happen, home users would need a smart-carder reader
>> there, right ? (And at any location they wish to access the
>> banking...). Also, it wouldn't take place immediately, so for a while
>> (a long time...?) the current system would need to continue working,
>> unless the banks decided to provide these things (readers+cards) for
>> So we can note that there may be a very long period in which this
>> system is practically useless (from the p.o.v of a phisher - as they
>> target the silly and lazy anyway...).
> True. One thing that the banks might decide to do is sponsor "branded"
> smart card readers at internet cafes in various locations, maybe just
> one per cafe, so that their customers would be able to perform their
> banking with confidence.
> And you are right. Banks will have to support both options for a
> while, while the transition is happening. But one option might be to
> support certificates on a floppy disk, for those users who do not want
> to purchase a card-reader, and who do not travel that much. The
> implementation of the certificate import process might still be a
> problem, though. IIRC, IE cannot use certificates that are in a file,
> they must be imported into the certificate store before they can be
> used. Not sure about Mozilla/FireFox, either. This becomes a problem
> if the user tries to travel with his certificate.
> The risk of phishing is still significantly reduced, though.
> (Note that some sites that use certificates on a disk have tried to
> get around the certificate import problem by supplying their own
> classes that perform digital signatures, etc, and provide a form where
> you specify the certificate location (using a File Upload Input
> field), and the certificate password. This is still vulnerable to
> phishing, as the attacker could simply upload the certificate to their
> site, and with the associated password, would be able to masquerade as
> the user without difficulty.)
>> We can note that the smart-card data is "locked" with the PIN, but how
>> does this _actually_ work? Is it possible to bypass it with some
>> software? (i really don't know...) or does it require hardware?
> The smart-card itself refuses to perform any crypto operations until
> the correct PIN has been supplied. Any crypto operations involving the
> private key are performed by the smart card CPU - the private key
> NEVER leaves the smart-card.
>> Also, when the user is at home, how do they enter the PIN? Has the
>> bank provided software to facilitate it? If so, why bother with the
>> cert on the credit card at all ? When not just install it on their
>> computer? (after all, it's alot of cost for the bank to do so ...)
> The PIN is typically entered using the computer keyboard, which does
> leave an opportunity for the PIN to be compromised by a keyboard
> sniffer, but the PIN is useless by itself, without the smart card.
> Nonetheless, this could put a spanner in the works with regards to
> idle timeouts - if the computer has a record of the PIN, it can simply
> resupply it to the smart-card, and the smart-card would not known any
>> How do the ATM's generate the certificates? Can they become
>> predictable? Could you predict the numbers "new" atms generate ?
> The ATM does not generate the certificate. The smart-card generates
> the private key inside the smart-card itself. As mentioned above, the
> private key never leaves the smart-card's control. Alternatively, the
> ATM could generate a private key based on a strong random number
> generator, if the bank decides that the smart card takes too long to
> perform this process.
> The ATM then generates a Certificate Signing Request based on the
> corresponding public key, submits it to the bank's CA (at a central
> location) for signature, and then uploads the signed certificate into
> the smart-card.
>> Merchant Access:
>> I think this problem would be resolved by having a seperate PIN for
>> the website certificate.
> Yes, I think so too.
>> Alternatively, the new and improved merchant reading systems could be
>> fitted to provide extra services to you. "Yes, I'll buy that suit, and
>> transfer $100 to my mother while you are at it!".
> That's an alternative.
>> Single Point of Failure:
>> (we discussed this before, but) What about the poor fool that writes
>> his PIN(s) down inside his wallet, and then proceeds to lose it. But I
>> suppose this would be a problem with any physical system...
> Exactly. The bank's have been telling people for years not to do that.
> And ATM's are becoming as sophisticated as Internet Banking is anyway.
> Self-service terminals are effectively Internet Banking as it is.
>> -- Michael
> Rogan Dawes
> *ALL* messages to discarddawes.za.net will be dropped, and added
> to my blacklist. Please respond to "lists AT dawes DOT za DOT net"