Alaric Dailey wrote: > ATMs would be infeasible if they were not a 2 factor authentication > system, and every day we see more cracks in the way that system is > implemented. Starting with the way the PSKs are shared. > > http://news.bbc.co.uk/1/hi/technology/4183330.stm
ATMs use "something you have" authentication ... a card with a magstripe that is sent out. There is a 2nd factor, PIN, that is also distributed ... as a countermeasure to lost/stolen cards. note that both credit cards and many debit cards can be used in non-PIN, signature mode (i.e. if the card is lost/stolen, crook may still be able to use it w/o PIN). multi-factor authentication presumes that the different factors are subject to different kinds of vulnerabilities and exploits. PINs are a form of shared-secrets ... security requirements typically mean that there is a unique shared-secret for every environment. the result is vast proliferation of PINs and passwords leading to people writting down their pins & passwords (there was some study that claimed 30percent of atm cards have pins written on them). As a result, multi-factor infrastructure is undermined because of shared-secret based environments has led to scores of shared-secrets that people are required to keep track of. http://www.garlic.com/~lynn/subpubkey.html#secrets the short-coming of shared-secret environment, is that a shared-secret can be used for both origination as well as verification (the same value used for authentication can also be used for impersonation), which has led to requirement that there are large number of unique shared-secrets, which has led to the huge proliferation in the number of shared-secrets ... which has also led to underminning principle of multi-factor authentication ... having unique failure modes .... sorry for that ... I spent some large amount of time producing high availability systems ... where security exploit/vulnerabilities were just another kind of system failure. http://www.garlic.com/~lynn/subtopic.html#hacmp it isn't so much that the key distribution/sharing mechanism is flawed ... it is that there are flaws in shared-secret based infrastructures (including swamping nominal human factors with an impossible number of different things to memorize). The other short-coming in current ATM environment is skimming that can go on at the POS or ATM terminal ... where the attackers can record the card and pin information. This results in both 1) common vulnerability for two factor authentication ... defeating purpose of having multi-factor authentication and 2) that existing technology is quite vulnerable to replay attacks (aka creating copy of magstripe in counterfeit card and being able to reproduce the pin). So fundamental public key operation can address a number of these short-comings w/o resorting to PKI infrastructure and/or changing the key and card distribution operation. 1) upgrade magstripe to hardware token that does digital signature authentication. the digital signature is unique each time and is therefor resistant to existing replay vulnerability, threats and attacks 2) since public key is not a shared-secret based infrastructure ... it is practical to record the same public key in multiple different environments, in theory transitioning to a person-centric environment (from the existing institutional-centric environment). this also is more resistant to data breaches ... since any exposure of the recorded public key can't be used for impersonation. 3) there is still the issue of using a PIN as countermeasure to lost/stolen token ... which is a significantly lower threat compared to crooks being able to harvest tens of thousands or millions of pieces of information for purposes of account fraud (skimming recording devices at ATM & POS terminals or data breaches). 4) with hardware token, the PIN can be used directly with the token for token operation ... as opposed to be transmitted and recorded in the infrastructure. That eliminates the PIN as a shared-secret. In theory a person-centric environment can use the same PIN/token with multitude of different infrastructures and/or use the same PIN with multitude of different tokens. This last becomes a trade-off between remembering lots of PINs (and threat of having them written down) vis-a-vis compromise of single PIN can expose several tokens. However, in person-centric environment, it is possible to leave such a threat trade-off decision to the individual. The issue of PKI, certificatin authorities, and digital certificates were that the original digital certificate design point was for first time communication between strangers where the relying party also had not timely, direct (possibly online) access to a trusted party. The digital certificates filled this trust void in a manner siumilar to letters of credit from the sailing ship days. In an environment where relying parties have long-standing and extensive relationship management operations keeping track of large number of bits of information ... it is trivial to show that digital certificates are redundant and superfluous. Furthermore, even in the first time communication between strangers ... where the relying party has no prior interaction with the subject ... digital certificates may still be redundant and superfluous standin for the real information if the relying party is able to directly contact some authoritative agency responsible for the information (aka real-time communication obtaining the real current information in lieu of a redundant and superfluous, stale, staic digital certificate). misc. past person-centric related postings: http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA) http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb??? http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards http://www.garlic.com/~lynn/2005g.html#57 Security via hardware? http://www.garlic.com/~lynn/2005m.html#37 public key authentication http://www.garlic.com/~lynn/2005p.html#6 Innovative password security --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]