Re: Crypto dongles to secure online transactions
we claimed we do something like two orders magnitude reduction in fully-loaded costs by going to no personalization (and other things) ... My concern with that would be that if everyone uses the the same signature scheme and token, the security of the entire industry becomes dependent on the least competent bank in the country not leaking the verification secret. For something like a chip+pin system it is my understanding that the signature algorithm is in the chip and different chips can use different secrets and different algorithms, so a breach at one bank need not compromise all the others. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Nov 18, 2009, at 6:16 PM, Anne Lynn Wheeler wrote: ... we could moved to a person-centric paradigm ... where a person could use the same token for potentially all their interactions ... we claimed we do something like two orders magnitude reduction in fully-loaded costs by going to no personalization (and other things) ... and then another two orders magnitude reduction in number of tokens by transitioning from institutional-centric paradigm to person-centric paradigm (compared to proposed smartcard/ dongle replacing every pin/password). we then came up against that the bank marketing departments have taken advantage of the requirement for institutional personalization ... to put their brand and other stuff on every token It goes deeper than that. Oh, sure, marketing loves having a presence - but their desire fits into corporate cultural biases. When I go to work, I have to carry two key cards - one for the building, one for my employer. They use the same technology - if you use the wrong one, the reader beeps in recognition but of course won't unlock the door. In fact, they interfere with each other - you have to make sure to keep the wrong one a couple of inches away from the reader or it will usually be confused. It's a pain, actually. Now, it's certainly possible that there's something proprietary on one card or the other - though as we've discussed here before, that's only true on badly designed systems: It's no big deal to read these cards, and from many times the inch or so that the standard readers require. So all that should be on the cards is an essentially random number which acts as a key into the lock systems database. It's just that the owners of each system insist on assigning that random number themselves. Does it give them any additional security? Hardly. If you think through the scenarios, you confirm that quickly - a direct consequence of the lack of any inherent value in the card or its contained number in and of themselves: The real value is in the database entry, and both institutions retain control of their own databases. What's needed is some simple cooperation and agreement on how to assign unique numbers to each card. There already has to be cooperation on the issuance and invalidation of building cards. But institutions insist on their sense of control and independence, even when it has no real payoffs for them (and, in fact, raises their costs). -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 11/21/2009 04:56 PM, John Levine wrote: we claimed we do something like two orders magnitude reduction in fully-loaded costs by going to no personalization (and other things) ... My concern with that would be that if everyone uses the the same signature scheme and token, the security of the entire industry becomes dependent on the least competent bank in the country not leaking the verification secret. For something like a chip+pin system it is my understanding that the signature algorithm is in the chip and different chips can use different secrets and different algorithms, so a breach at one bank need not compromise all the others. R's, John there is no shared secret ... there is unique chip private/public key generated at power-on/test and the public key was included/transmitted with the test result data as part of the initial power-on/test cycle (this is process that occurs while the chips are still in wafer ... before being sliced diced). the silicon is designed to never (volunteerly) divulge the private key (modulo some extremely heavy duty physical attacks). the patent stuff was all done for employer as assigned patents quite awhile ago (we've been gone for several yrs and the patent stuff keeps going on). initially there was a large number of claims and had gotten to packaged as over 60 patents and looked to be 100 before we were done. about that point, the employer looks at filing costs in the US and international ... and directs that all the claims be packaged as nine patents. Later, the patent office comes back and makes some comment about getting tired of huge patents where the filing fee doesn't even cover the cost of reading all the claims ... and directed that the claims be packaged as larger number of claims. http://www.garlic.com/~lynn/aadssummary.htm while there are claims related to unique devices with unique digital signatures in other applications ... there was a patent application (in our name ... years after we are gone) this year http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220090158029%22.PGNR.OS=DN/20090158029RS=DN/20090158029 all the initial chips were ec/dsa (each chip with its own unique public/private key) ... all done in fab that had security certified by US, EU other gov. institutions and also financial institutions (no compromised chips substituted for real ones) ... I even got to walk the fab in bunny suit doing my own certification. if you want different algorithms (or key lengths) ... you have to cut a new mask and make different wafer runs. if the number of wafers in wafer runs are too small ... you would start to drive the cost/chip above a few cents. There is no single-point-of-compromise. Compromising a single chip is equivalent to skimming a single magstripe ... can do fraudulent transactions against the accounts for that chip/token (and chip compromise significantly more difficult than magstripe skimming). In theory there might be weakness found in specific chip or specific algorithm ... but design allows for a large number of different chips and algorithms to interoperate in the same environment. For the initial chips ... I got a EAL4+ common criteria certification (by accredited lab in germany). I wanted a higher certification ... but had a problem that EC/DSA verification suite had been withdrawn. There were some higher certifications on similar chips by others ...but their design involved loading the crypto after the certification (they got certification done on chip before any software loaded). My chip had everything in silicon (all feature/functions) ... and so the certification was done on everything that would be in actual use. in the person-centric scenario ... each chip's private key becomes somewhat akin to fingerprint or iris pattern ... a unique something you have ... as opposed to unique something you are (and much easier to replace/change if there is a specific compromise). some of the patents cover not only recording public key for each account the corresponding token is authorized for (and multiple different tokens might be authorized for same account) ... but also knowledge about the assurance level of the related chip. Real-time updates are then available about chip assurance level ... and real-time authorizations can not only take into account whether the transaction is within the account balance ... but potentially is the assurance level of the chip is high enough for authorizing the transaction. X9.59 financial standard transaction protocol also allows for the environment that the transaction is performed in to also sign the transaction (in addition to the person's chip). Real-time authorization then may take into account both the assurance level (potentially updated in real-time) of the user's chips as well as the assurance level of the transaction environment (in determining if there is sufficient
Re: Crypto dongles to secure online transactions
On 11/21/2009 05:56 PM, Jerry Leichter wrote: On Nov 18, 2009, at 6:16 PM, Anne Lynn Wheeler wrote: ... we could moved to a person-centric paradigm ... where a person could use the same token for potentially all their interactions ... we claimed we do something like two orders magnitude reduction in fully-loaded costs by going to no personalization (and other things) ... and then another two orders magnitude reduction in number of tokens by transitioning from institutional-centric paradigm to person-centric paradigm (compared to proposed smartcard/dongle replacing every pin/password). we then came up against that the bank marketing departments have taken advantage of the requirement for institutional personalization ... to put their brand and other stuff on every token It goes deeper than that. Oh, sure, marketing loves having a presence - but their desire fits into corporate cultural biases. When I go to work, I have to carry two key cards - one for the building, one for my employer. They use the same technology - if you use the wrong one, the reader beeps in recognition but of course won't unlock the door. In fact, they interfere with each other - you have to make sure to keep the wrong one a couple of inches away from the reader or it will usually be confused. It's a pain, actually. Now, it's certainly possible that there's something proprietary on one card or the other - though as we've discussed here before, that's only true on badly designed systems: It's no big deal to read these cards, and from many times the inch or so that the standard readers require. So all that should be on the cards is an essentially random number which acts as a key into the lock systems database. It's just that the owners of each system insist on assigning that random number themselves. Does it give them any additional security? Hardly. If you think through the scenarios, you confirm that quickly - a direct consequence of the lack of any inherent value in the card or its contained number in and of themselves: The real value is in the database entry, and both institutions retain control of their own databases. What's needed is some simple cooperation and agreement on how to assign unique numbers to each card. There already has to be cooperation on the issuance and invalidation of building cards. But institutions insist on their sense of control and independence, even when it has no real payoffs for them (and, in fact, raises their costs). -- Jerry We went thru all the scenarios with the objections on why they wanted institutional-centric paradigm ... part of the scenario was putting the assurance level of the chip on level with assurance level of your fingerprint or iris pattern ... and asking when institutions were going to start issuing individual, institutional-specific fingers for people to use. this is various person-centric claims here and there (assigned and still having activity after we've been gone for yrs) http://www.garlic.com/~lynn/aadssummary.htm there is specific granted patent here: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmr=1f=Gl=50S1=6978369.PN.OS=PN/6978369RS=PN/6978369 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
leich...@lrw.com (Jerry Leichter) on Saturday, November 21, 2009 wrote: It's no big deal to read these cards, and from many times the inch or so that the standard readers require. So surely someone has built a portable reader for counterfeiting the cards they read in restaurants near big target companies... Cheers - Bill --- Bill Frantz|After all, if the conventional wisdom was working, the 408-356-8506 | rate of systems being compromised would be going down, www.periwinkle.com | wouldn't it? -- Marcus Ranum - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Nov 21, 2009, at 6:12 PM, Bill Frantz wrote: leich...@lrw.com (Jerry Leichter) on Saturday, November 21, 2009 wrote: It's no big deal to read these cards, and from many times the inch or so that the standard readers require. So surely someone has built a portable reader for counterfeiting the cards they read in restaurants near big target companies... Well, my building card is plain white. If anyone duplicated it, there'd be nothing stopping them from going in. But then the actual security offered by those cards - and the building controls - is more for show (and I suppose to keep the riffraff out - than anything else. My work card has my photo and name on it, but there's nothing to correlate name with underlying ID in normal operation. Snap a photo of the card while you clone it, make up a reasonable simulacrum with your own picture and name, and walk right in. Not really more or less secure than the old days when you flashed you (easily copied) badge to a card who probably only noticed that it was about the right size and had roughly the right color. But it's higher tech, so an improvement. :-) Physical security for most institutions has never been very good, and fortunately has never *needed* to be very good. Convenience wins out, and technology gives a nice warm feeling. A favorite example: My wife's parents live in a secured retirement community. The main entrance has a guard who checks if you're on a list of known visitors, or calls the people you're visiting if not. Residents used to have a magnetic card, but that's a bit of pain to use. So it was replaced by a system probably adapted from railroad freight card ID systems: You stick big barcode in your passenger side window, and a laser scanner on a post reads it and opens the door. Of course, it's trivial to duplicate the sticker using a simple photo, and since the system has to work from varying distances, at varying angles, on moving cars, in all light and weather conditions, it can't possibly be highly discriminating - almost certainly just a simple Manchester-style decoder. -- Jerry Cheers - Bill --- Bill Frantz|After all, if the conventional wisdom was working, the 408-356-8506 | rate of systems being compromised would be going down, www.periwinkle.com | wouldn't it? -- Marcus Ranum - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Crypto dongles to secure online transactions
The FINREAD smart card reader was a European run at moving trust-bearing transactions to an outboard device. It was a full Java VM in a tamper-resistant box with a modest GUI, biometrics, lots of security on the I/O ports and much attention to application isolation. FINREAD readers were produced and an attempt was made to make its specifications into an ISO/IEC standard. I don't know why it didn't get any traction but suspect that it was more on business grounds than on technical grounds. Telling folks they had to buy a $100 card reader that was controlled and monetized by one particular bank wasn't exactly a compelling offer. Recently GlobalPlatform has reinvigorated the STIP reader effort which is from 35K feet the same thing. GP took over STIP in 2004. Google or Bing for details. As Dan Geer as observed over the years, reducing bank risk is not a consumer benefit. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Fri, 2009-11-20 at 20:13 +1300, Peter Gutmann wrote: Because (apart from the reasons given above) with business use specifically you run into insurmountable PC - device communications problems. Many companies who handle large financial transactions are also ones who, due to concern over legal liability, block all access to USB ports to prevent external data from finding its way onto their corporate networks (they are really, *really* concerned about this). If you wanted this to work, you'd need to build a device with a small CMOS video sensor to read data from the browser via QR codes and return little more than a 4-6 digit code that the user can type in (a MAC of the transaction details or something). It's feasible, but not quite what you were thinking of. So the model of interaction is: Software displays transaction on the screen (in some predetermined form) Device reads the screen, MACs the transaction, and displays MAC to user User enters MAC to confirm transaction Transaction, with MAC, is submitted to user's bank. Bank checks MAC to make sure it matches transaction and performs transaction if there's a match. Malware that finds the user account details lying around on the hard drive cannot form valid MACs for the transactions it wants to use those details for, so the user and the bank are protected from credit card harvesting by botnets. Malware that attempts to get a user authorization by displaying a different transaction on the screen is foiled by not being able to MAC the transaction it's really trying to do. etc. But a four or six digit MAC isn't nearly enough. You see, there's still the problem of how you handle fraudulent transactions. If the black hats start submitting transactions with random MACs in the certain knowledge that one out of ten thousand four-digit MACs will be right, all that happens is that they have to invest some bandwidth when they want to drain your account. They will do it, because it's more profitable than sending spam. If there is some reasonable control like freezing an account after a thousand attempts to make fraudulent transactions or not accepting transaction requests within twenty seconds after an attempt to make a fraudulent transaction on the same account, then you have created an easy denial-of-service attack that can be used to deny a particular person access to his or her bank account at a particular time of the attacker's choosing. Denying someone access to their money makes them vulnerable at an unexpected time - they can't get a hotel room, they can't get a cab, they can't get a plane home, they can't buy gas for their car and get stranded somewhere, and they become easy pickings for physical crimes like assault, rape, theft of vehicle, etc. That's not acceptable. In order to be effective the MAC has to make success so unlikely that submitting a fraudulent transaction has a higher cost than its amortized benefit. Since the botnets are stealing their electricity and bandwidth anyway, the absolute cost to black hats of submitting a fraudulent transaction is very very close to zero. What we have to look at then is their opportunity cost. Consider the things a botted machine could do with a couple kilobytes of bandwidth and a couple milliseconds of compute time. It could send a spam or it could send a fraudulent transaction to a bank with a random MAC. It will do whichever is considered most profitable by the operator of the botnet. Note: with spamming there's almost no chance of arrest. Receiving money via a fraudulent transaction submitted to a bank *MIGHT* be made more risky, so if that actually happens then there's an additional risk or cost associated with successful fraud attempts, which I don't account for here. But ignoring that because I don't know how to quantify it: In late 2008, ITwire estimated that 7.8 billion spam emails were generated per hour. (http://www.itwire.com/content/view/19992/53/) Consumer reports estimates consumer losses due to phishing at a quarter-billion dollars per year. (http://www.consumerreports.org/cro/magazine-archive/june-2009/ electronics-computers/state-of-the-net/phishing-costs-millions/ state-of-the-net-phishing-costs-millions.htm) Check my math, but If we believe those sources, then that puts the return on sending one spam email at 1/546624 of a dollar, or about one point eight ten-thousandths of a penny. If we can make submitting a fraudulent transaction return less than that, then the botnets go on sending spams instead of submitting fraudulent transactions and our banking infrastructure is relatively safe. For now. (Just don't think about our email infrastructure - it's depressing). If a fraud attack seeks to drain the account, it'll go for about the maximum amount it expects the bank to honor, which means, maybe, a couple thousand dollars (most checking accounts have overdraft
Re: Crypto dongles to secure online transactions
Peter Gutmann wrote: external data from finding its way onto their corporate networks (they are really, *really* concerned about this). If you wanted this to work, you'd need to build a device with a small CMOS video sensor to read data from the browser via QR codes and return little more than a 4-6 digit code that the user can type in (a MAC of the transaction details or something). It's feasible, but not quite what you were thinking of. That reminds me of the Lenslok copy protection device on the Elite (and others) game from the '80s[1] [1] http://www.birdsanctuary.co.uk/sanct/s_lenslok.php -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 11/21/2009 06:31 PM, Jerry Leichter wrote: Well, my building card is plain white. If anyone duplicated it, there'd be nothing stopping them from going in. But then the actual security offered by those cards - and the building controls - is more for show (and I suppose to keep the riffraff out - than anything else. My work card has my photo and name on it, but there's nothing to correlate name with underlying ID in normal operation. Snap a photo of the card while you clone it, make up a reasonable simulacrum with your own picture and name, and walk right in. Not really more or less secure than the old days when you flashed you (easily copied) badge to a card who probably only noticed that it was about the right size and had roughly the right color. But it's higher tech, so an improvement. :-) Physical security for most institutions has never been very good, and fortunately has never *needed* to be very good. Convenience wins out, and technology gives a nice warm feeling. A favorite example: My wife's parents live in a secured retirement community. The main entrance has a guard who checks if you're on a list of known visitors, or calls the people you're visiting if not. Residents used to have a magnetic card, but that's a bit of pain to use. So it was replaced by a system probably adapted from railroad freight card ID systems: You stick big barcode in your passenger side window, and a laser scanner on a post reads it and opens the door. Simplest card/token is basically (single-factor) something you have authentication the cheapest RFID proximity card is just some static data ... that can be trivially copied and reproduced ... think of it somewhat akin to a wireless magstripe. that has also the YES CARD point-of-sale contact card vulnerability. Compromised POS terminal that recorded the static data from card transaction and trivially used to produce a counterfeit card (little or no difference from compromised POS terminal that records magstripe data). What made it worse than magstripe was that POS terminals were programmed to ask a validated chip three questions 1) was the entered PIN correct, 2) should the transaction be done offline, and 3) is the transaction within the account credit limit. A counterfeit YES CARD would answer YES to all three questions (it wasn't necessary to even know the correct pin with counterfeit YES CARD ... and deactivating the account ... as in magstripe ... wasn't sufficient to stop the fraud). A counterfeit YES CARD was also some other counterme asures that had been built into the infrastructure: http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html a little more secure is two-factor token that requires both the token and possibly something you know. However, two-factor authentication is assumed more secure is based on single factor authentication is based on the different factors having independent compromises. In the case of the YES CARD (supposedly two-factor) ... it was only necessary to compromise the token's static data ... and it wasn't even necessary to know the correct PIN. In the case of pin-debit cards ... skimming compromises of ATMs or point-of-sale terminals can collect both the PIN and the magstripe data at the same time (invalidating assumption about independent compromises). we had somewhat been asked in the mid-90s to participate in the x9a10 financial standard group (which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments) because of having worked on this stuff now frequently called electronic commerce. This was *ALL* as in debit, credit, ACH, internet, point-of-sale, low-value, high-value, face-to-face, unattended, and/or transit. Transit-turnstyle has similar requirements to building access ... although the contactless power limitations and contactless elapsed time requirements can be more stringent than building access. Somewhat as a result ... the related work on the AADS chip strawman, had all sorts of requirements ... form factor agnostic, very-very fast, very-very low-power, contactless capable ... but for high-value ... had to no have *NO* static data and very difficult to counterfeit ... but at the same time ... for low-value ... had to have as close to zero cost as possible. Most of the alternatives from the period ... tended to only consider a very small subset of those requirements ... and therefor created a solution that had a single, specific operation and were ill-suited for a general purpose use. A simple issue was having the same token that was multi-factor authentication agile ... operate with single-factor (something you have) at a transit turnstyle (no time to enter PIN) ... but works the same way at a high-security building access turnstyle that requires multi-factor authentication (something you have token in conjunction with PIN something-you-know or palm finger
Re: Crypto dongles to secure online transactions
On 11/18/2009 12:22 PM, Bill Frantz wrote: Perhaps I'm missing something, but my multiple banks will all accept my signature when made with the same pen. Why wouldn't they not accept my signature when made with the same, well protected, signing/user verifying device. I might have to take it to the bank to give them its public key in person, but that seems a minor inconvenience. This kind of device sounds like a fine device for a banking industry committee to specify. we ran into that with doing chip that required to post-fab personalization ... eliminating lots of the costs thruout the whole infrastructure (eliminating personalization actually makes the delivered cost to the user less than the current infrastructure). we then looked at the current institutional-centric paradigm ... where each institution wants to deliver token/card to user ... with having eliminating any personalization requirement ... then we claimed we could moved to a person-centric paradigm ... where a person could use the same token for potentially all their interactions ... having to wade through all the institutional arguments ... and addressing each one that stood in the way of moving from an institutional-centric paradigm to person-centric paradigm. the smartcard industry was looking at possibly replacing every pin/password with a unique smartcard/dongle. we claimed we do something like two orders magnitude reduction in fully-loaded costs by going to no personalization (and other things) ... and then another two orders magnitude reduction in number of tokens by transitioning from institutional-centric paradigm to person-centric paradigm (compared to proposed smartcard/dongle replacing every pin/password). we then came up against that the bank marketing departments have taken advantage of the requirement for institutional personalization ... to put their brand and other stuff on every token. They started out saying they didn't want to do chip because it increased costs ... and when we showed we can come very close to driving costs to zero ... it turns out the marketing departments like the current infrastructure (despite the costs) ... because they feel it is important to have their brand on the token in each person's wallet. There were various sorts of distractions/obfuscations ... like what happens if the only token fails ... there is nothing that prevents a person from having two person-centric tokens (or personally choosing to have a their own unique token per institution). Then it was ... what happens if the only token is stolen. It turns out that the standard threat is the wallet/purse is stolen with all the cards (eliminating any different between there being single token or multiple tokens). In any case ... with a paradigm that has been in place for this long ... there are quite a large number of people that don't want to change ... some for no other real reason than its different ... for others they have leveraged current paradigm for things that couldn't have been independently justified on its own. Early on uptake in various standards organization was good ... until some of the change implications started percolating thru the infrastructure. It was analogous to what we did with secure x9.59 financial transaction standard ... and then the implications of eliminating all the associated fraud started to sink in. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Wed, 18 Nov 2009, Bill Frantz wrote: Perhaps I'm missing something, but my multiple banks will all accept my signature when made with the same pen. Why wouldn't they not accept my signature when made with the same, well protected, signing/user verifying device. I might have to take it to the bank to give them its public key in person, but that seems a minor inconvenience. The reasons can sound crazy from the technical person's point of view, like they may want to have a card with their name on it in your wallet. There are rumors that this is what ruined the idea that a single smartcard (e.g., JavaCard) can replace all cards in your wallet. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
John Levine jo...@iecc.com writes: I told him about an approach to use a security dongle that puts the display and confirmation outside the range of the malware, and although I thought it was fairly obvious, he'd apparently never heard it before. Some general thoughts on this, there have been attempts going back at least ten years to bring devices like this to market (for example I have a nice device that does exactly this built in the late 90s sitting in a drawer somewhere), but they always die for the same reason, lack of interest and, for the few who are interested, lack of interest in paying the cost. I've made it an entry in my blog at http://weblog.johnlevine.com/Money/securetrans.html [...] I don't understand why banks aren't using this approach already. Because (apart from the reasons given above) with business use specifically you run into insurmountable PC - device communications problems. Many companies who handle large financial transactions are also ones who, due to concern over legal liability, block all access to USB ports to prevent external data from finding its way onto their corporate networks (they are really, *really* concerned about this). If you wanted this to work, you'd need to build a device with a small CMOS video sensor to read data from the browser via QR codes and return little more than a 4-6 digit code that the user can type in (a MAC of the transaction details or something). It's feasible, but not quite what you were thinking of. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
In this case, heck, no. The whole point of this thing is that it is NOT remotely programmable to keep malware out. Which is perhaps why it is not a good idea to embed an SSL engine in such a device. Agreed. A display and signing engine would be quite adequate. Such a device does however need to be able to suppor multiple mutually distrusting verifiers, thus the destination public key is managed by the untrusted PC + browser, only the device signing key is inside the trust boundary. A user should be able to enroll the same device with another bank, ... If you really need the ability to do that, I'd think it would be better to make an expandable version into which you could plug each bank's chip+pin cards, not try to invent a super-protocol for downloading a bank's preferred keys. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
jo...@iecc.com (John Levine) on Wednesday, November 18, 2009 wrote: Such a device does however need to be able to suppor multiple mutually distrusting verifiers, thus the destination public key is managed by the untrusted PC + browser, only the device signing key is inside the trust boundary. A user should be able to enroll the same device with another bank, ... If you really need the ability to do that, I'd think it would be better to make an expandable version into which you could plug each bank's chip+pin cards, not try to invent a super-protocol for downloading a bank's preferred keys. Perhaps I'm missing something, but my multiple banks will all accept my signature when made with the same pen. Why wouldn't they not accept my signature when made with the same, well protected, signing/user verifying device. I might have to take it to the bank to give them its public key in person, but that seems a minor inconvenience. This kind of device sounds like a fine device for a banking industry committee to specify. Cheers - Bill - Bill Frantz| Airline peanut bag: Produced | Periwinkle (408)356-8506 | in a facility that processes | 16345 Englewood Ave www.pwpconsult.com | peanuts and other nuts. - Duh | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
So should or should not an embedded system have a remote management interface? In this case, heck, no. The whole point of this thing is that it is NOT remotely programmable to keep malware out. If you have a modest and well-defined spec, it is well within our abilities to produce reliable code. People write software for medical devices and vehicle control which is not remotely updated, and both our pacemakers and are cars are adequately reliable. If you define the spec carefully enough that you can expect to make a million devices, the cost of even very expensive software is lost in the noise. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Nov 16, 2009, at 12:30 PM, Jeremy Stanley wrote: If one organization distributes the dongles, they could accept only updates signed by that organization. We have pretty good methods for keeping private keys secret at the enterprise level, so the risks should be manageable. But even then, poor planning for things like key size (a la the recent Texas Instruments signing key brute-forcing) are going to be an issue. I'm not sure that's the right lesson to learn. A system has to be designed to work with available technology. The TI83 dates back to 1996, and used technology that was old even at the time: The CPU is a 6MHz Z80. A 512-bit RSA was probably near the outer limits of what one could expect to use in practice on such a machine, and at the time, that was quite secure. Nothing lasts forever, though, and an effective 13 year lifetime for cryptography in such a low-end product is pretty good. (The *official* lifetime of DES was about 28 years, though it was seriously compromised well before it was officially withdrawn in 2005.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Mon, Nov 16, 2009 at 11:20:27PM -0500, Jerry Leichter wrote:
I'm not sure that's the right lesson to learn.
I might have, perhaps, phrased it a little better. Regardless of
initial planning, TI continued selling devices relying on this
particular code signing implementation well past what the original
design engineers hopefully expected would be its maximum lifespan.
A system has to be designed to work with available technology. The
TI83 dates back to 1996, and used technology that was old even at
the time: The CPU is a 6MHz Z80. A 512-bit RSA was probably near
the outer limits of what one could expect to use in practice on such
a machine, and at the time, that was quite secure.
If this is true, then it makes an interesting case study for the
topic of this thread...
Nothing lasts forever, though, and an effective 13 year lifetime
for cryptography in such a low-end product is pretty good.
[...]
Not such a low-end product, when compared to the bank transaction
authenticating crypto we're discussing (I had a TI-83 back when they
first came out, and it was far from cheap on a starving student
budget). Assume what TI had built was one of these banking crypto
devices... they implemented a code signing mechanism so it could be
updated in a secure fashion, since they didn't want it to be so
disposable... the best code signing mechanism the processor could
handle... in 13 years a hobbyist with a few months and basically no
budget is able to trojan these devices.
This speaks to an inherent lifespan for low-end devices anyway,
since a time will come when they need better code signing than their
processors can handle. If the hobbyist can do it 13 years later for
a relatively low-value target (programmable calculators), how about
something which has a lot more potential for profit? A decade ago I
was working on (relatively) low-budget beowulf distributed compute
clusters which easily rivalled the speed of the machine used to
crack TI's code signing keys. This was well within the budget of a
criminal organization--probably a tiny fraction of what they could
have made selling the code signing keys for widely-deployed bank
transaction authenticator devices.
Maybe calculators are a bad example, but if 3-4 years is all it
takes to put the code signing key for an inexpensive device in the
hands of criminals, then is it worth the risk (or even expense) to
make dedicated banking crypto hardware updateable?
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Tue, Nov 17, 2009 at 01:35:12AM -, John Levine wrote: So should or should not an embedded system have a remote management interface? In this case, heck, no. The whole point of this thing is that it is NOT remotely programmable to keep malware out. Which is perhaps why it is not a good idea to embed an SSL engine in such a device. Its external interface should be as simple as possible, which suggests a message-signing device, rather than a device that participates in complex, evolving, interactive protocols with remote network services. The integration of the message signing device with a complete system (computer with browser + device) should include most of the complex and likely to change software. The device itself, is just a display + encrypt then sign black-box for suitably simple (to unambiguously display) messages, and the transmission of the signed message to the appropriate destination can be left to the untrusted PC. Such a device does however need to be able to suppor multiple mutually distrusting verifiers, thus the destination public key is managed by the untrusted PC + browser, only the device signing key is inside the trust boundary. A user should be able to enroll the same device with another bank, ... The proliferation multiple of SecurId tokens per user in B2B financial services has led to a search for greater than drawer-full of SecurId cards (with PIN glued to the back of each) usability. The alternatives are not always very strong, but a would be more-secure solution needs to keep usability in mind for the case when the user needs to conduct secure transactions with multiple parties. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
Matt Crawford writes: -+--- | Imagine a couple of hundred million devices with updatable | firmware on them, and one or more rogue updates in the wild. So should or should not an embedded system have a remote management interface? If it does not, then a late discovered flaw cannot be fixed without visiting all the embedded systems which is likely to be infeasible both because some will be where you cannot again go and there will be too many of them anyway. If it does have a remote management interface, the opponent of skill focuses on that and, once a break is achieved, will use those self-same management functions to ensure that not only does he retain control over the long interval but, as well, you will be unlikely to know that he is there. This leads to a proposal on what to do about the future: Embedded systems, if having no remote management interface and thus out of reach, are a life form and as the purpose of life is to end, an embedded system without a remote management interface must be so designed as to be certain to die no later than some fixed time. Conversely, an embedded system with a remote management interface must be sufficiently self-protecting that it is capable of refusing a command. Long live HAL, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 11/10/2009 09:44 AM, Jerry Leichter wrote: Not that this should block the use of devices like the ZTIC! They're still much more secure than the alternatives. But it's important to keep in mind the vulnerabilities we engineer *into* systems at the same time we engineer others *out*. vulnerabilities tend to be proportional to complexity. we had been asked in to consult with small client/server startup that wanted to do payment transactions on their server ... they had also invented this technology called SSL applied to the process. The result is frequently called electronic commerce. The major use/purpose of that SSL in the world today is hiding the account number and other transaction details. somewhat as a result, in the mid-90s we were invited to to participate in the x9a10 financial standard working group which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. Part of that was detailed threatvulnerability studies of different payment methods and environments. One of the biggest problems was vulnerability of leaking account number ... since it was trivial for crooks to use it for originating fraudulent transactions ... and at the same time required by millions of business processes around the world. So part of the resulting standard was slightly tweaking the paradigm and eliminating the account number (and transaction details) as a vulnerability (which then also eliminates the major use of SSL in the world today). along the way, i also made semi-facetious comment that i would take a $500 milspec item and aggressively cost reduce it by 2-3 orders of magnitude while making it more secure. Part of the effort effectively worked out getting it close to the EPC RFID technology process (items targeted at replacing UPC barcodes on grocery items at a few cents or less) w/o reducing security. Basically it is all silicon ... which not only reduces a lot of after-FAB vulnerabilities ... but also eliminates the costs of a lot of the post-FAB processing steps (as silicon cost goes to zero, post-FAB processing costs started to dominate). Along with it is the concept of security proportional to risk ... at the issuing authorization end of a transaction ... the security characteristics of the originating components can be evaluated ... in the case of the chip ... the security level of the chip can even be updated in real time as vulnerabilities are identified. This can help decide like a when a few cent item might be needed to be replaced for higher value transactions -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Nov 11, 2009, at 10:36 AM, Matt Crawford wrote: On Nov 10, 2009, at 8:44 AM, Jerry Leichter wrote: Whether or not it can, it demonstrates the hazards of freezing implementations of crypto protocols into ROM: Imagine a world in which there are a couple of hundred million ZTIC's or similar devices fielded - and a significant vulnerability is found in the protocol they speak. Imagine a couple of hundred million devices with updatable firmware on them, and one or more rogue updates in the wild. That's the flip side of the vulnerability - and it's exactly why I did *not* suggest that the fix for vulnerable algorithms frozen into silicon was to make them updatable. Of course, there *are* situations in which that makes sense. If one organization distributes the dongles, they could accept only updates signed by that organization. We have pretty good methods for keeping private keys secret at the enterprise level, so the risks should be manageable. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
Ben Laurie benl google.com writes: Anyway, I should mention my own paper on this subject (with Abe Singer) from NSPW 2008, Take The Red Pill _and_ The Blue Pill: http://www.links.org/files/nspw36.pdf In writing on page 2 that you do not need to secure what you put in an Amazon shopping basket until you come to arrange payment and delivery you may be overlooking some things. Amazon's future recommendations are affected by what has been put in your basket; even if removed later. A compromised browser could show false prices and availability so causing you to choose expensive used goods from a crook and not discover cheaper sources. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Wed, Nov 11, 2009 at 09:42:21PM -0500, Jerry Leichter wrote:
[...]
If one organization distributes the dongles, they could accept
only updates signed by that organization. We have pretty good
methods for keeping private keys secret at the enterprise level,
so the risks should be manageable.
But even then, poor planning for things like key size (a la the
recent Texas Instruments signing key brute-forcing) are going to be
an issue.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Wed, Nov 11, 2009 at 9:53 AM, d...@geer.org wrote: Matt Crawford writes: -+--- | Imagine a couple of hundred million devices with updatable | firmware on them, and one or more rogue updates in the wild. So should or should not an embedded system have a remote management interface? If it does not, then a late discovered flaw cannot be fixed without visiting all the embedded systems which is likely to be infeasible both because some will be where you cannot again go and there will be too many of them anyway. If it does have a remote management interface, the opponent of skill focuses on that and, once a break is achieved, will use those self-same management functions to ensure that not only does he retain control over the long interval but, as well, you will be unlikely to know that he is there. This leads to a proposal on what to do about the future: Embedded systems, if having no remote management interface and thus out of reach, are a life form and as the purpose of life is to end, an embedded system without a remote management interface must be so designed as to be certain to die no later than some fixed time. Conversely, an embedded system with a remote management interface must be sufficiently self-protecting that it is capable of refusing a command. Almost every U.S.A. based bank that i have used own several physical branch locations. Maybe your country is different. Disable the service until the customer physically brings in the old hardware to be replaced with a new one to eliminate need for remote management. Our planet has too much electronic garbage to build permanent preprogrammed death. Long live HAL, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Nov 10, 2009, at 8:44 AM, Jerry Leichter wrote: Whether or not it can, it demonstrates the hazards of freezing implementations of crypto protocols into ROM: Imagine a world in which there are a couple of hundred million ZTIC's or similar devices fielded - and a significant vulnerability is found in the protocol they speak. Imagine a couple of hundred million devices with updatable firmware on them, and one or more rogue updates in the wild. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 11/08/2009 02:07 AM, John Levine wrote: At a meeting a few weeks ago I was talking to a guy from BITS, the e-commerce part of the Financial Services Roundtable, about the way that malware infected PCs break all banks' fancy multi-password logins since no matter how complex the login process, a botted PC can wait until you login, then send fake transactions during your legitimate session. This is apparently a big problem in Europe. I told him about an approach to use a security dongle that puts the display and confirmation outside the range of the malware, and although I thought it was fairly obvious, he'd apparently never heard it before. When I said I'd been thinking about it for a while, he asked if I could write it up so we could discuss it further. So before I send it off, if people have a moment could you look at it and tell me if I'm missing something egregiously obvious? Tnx. I've made it an entry in my blog at http://weblog.johnlevine.com/Money/securetrans.html Ignore the 2008 date, a temporary fake to keep it from showing up on the home page and RSS feed. R's, John deja vu 1999 this should be covered in enormous detail in the EU finread standards documents from the late 90s. note that the EU finread standard from late 90s (over decade ago) was countermeasure to most every kind of PC compromise that you can think of. Basically it moved the end point out to independent hardware device with its own display and pin-pad. The transaction was still composed on the PC ... but had to be sent to the hardware finread device for approval/authentication. transaction to be approved/executed would be displayed on finread device for approval. It then required physical PIN entry to execute the approval process ... typically assumed to be a digital signature ... which was returned to the PC. compromised PC could still do a denial of service ... but the independent finread device effectively moved the end-point from the PC out to the finread. the independent display pin-pad ... was countermeasures to various kinds of exploits ... including * keylogging ... trojan horse or other could execute transactions w/o users actual knowledge * is the transaction that the user sees the actual transaction being executed bad design might have used the finread for session authentication in lieu of separately authentication/approval for every transaction (which would allow trojans on compromised pcs to execute fraudulent transactions within the boundaries of the session. infrastructure would still be vulnerable to various kinds of social engineering ... convincing end-user to execute valid transactions for the benefit of the attacker. There was some conjecture (again more than decade ago) that if finread deployment eliminated all the other kinds of compromises ... that user education programs could purely concentrate on social engineering exploits (sort of like the stuff for little kids to have nothing to do with strangers). EU finread program got caught up in the disastrous deployment of serial-port card acceptor device at the start of the decade (many versions had the appearance of card acceptor device with its own independent display and pin-pad ... slightly akin to small POS terminals that might appear at point-of-sale). The disastrous serial-port acceptor device deployment resulted in rapidly spreading opinion in the financial industry that smartcards and card readers weren't practical in the consumer market ... resulting in nearly all such programs quickly evaporating w/o hardly a trace. As i've mentioned before ... it wasn't actually a problem with smartcards and/or card readers but with the serial-port interface. In the 1995 time-frame there were a number of presentations about moving the dial-up home banking programs to the internet ... in large part motivated by the significant customer support costs associated with supporting serial-port modems (one such bank program claimed to have a library of over 60 serial port modem software drivers to try and cover some reasonable set of their customers. Problems with the whole serial-port gorp was also big motivator behind development of USB. In any case, i've commented before about the financial industry institutional knowledge and experience apparently rapidly evaporated between the migration of dial-up home banking (migration to the internet) and 2000. A partial/possible explanation might be that the vendor, knowing that everything was moving to USB, saw a really great chance to unload their stock of obsolete serial-port devices on a client that didn't really know what they were doing. lots of past EU finread standard posts: http://www.garlic.com/~lynn/subintegrity.html#finread random trivia ... i was at an eu finread standard meeting in brussels not long before the whole thing with serial-port resulted in all such programs imploding (even those not using serial-port ... radiation from the event
Re: Crypto dongles to secure online transactions
Jerry Leichter wrote: On Nov 8, 2009, at 2:07 AM, John Levine wrote: At a meeting a few weeks ago I was talking to a guy from BITS, the e-commerce part of the Financial Services Roundtable, about the way that malware infected PCs break all banks' fancy multi-password logins since no matter how complex the login process, a botted PC can wait until you login, then send fake transactions during your legitimate session. This is apparently a big problem in Europe. I told him about an approach to use a security dongle that puts the display and confirmation outside the range of the malware, and although I thought it was fairly obvious, he'd apparently never heard it before. Wow. *That's* scary. http://www.zurich.ibm.com/ztic/ IBM Zone Trusted Information Channel (ZTIC) A multi line display and two buttons (approve/disapprove) http://www.zurich.ibm.com/pdf/csc/ZTIC-Trust-2008-final.pdf More and more attacks to online banking applications target the user's home PC, changing what is displayed to the user, while logging and altering key strokes. ... In order to foil these threats, IBM has introduced the Zone Trusted Information Channel (ZTIC), a hardware device that can counter these attacks in an easy-to-use way. The ZTIC is a USB-attached device containing a display and minimal I/O capabilities that runs the full TLS/SSL protocol, thus entirely bypassing the PC's software for all security functionality. The ZTIC achieves this by registering itself as a USB Mass Storage Device (thus requiring no driver installation) and starting a pass-through proxy configured to connect with pre-configured (banking) Websites. After starting the ZTIC proxy, the user opens a Web browser to establish a connection with the bank's Website via the ZTIC. From that moment on, all data transmitted between browser and server pass through the ZTIC; the SSL session is protected by keys maintained only on the ZTIC and, hence, is inaccessible to malware on the PC (see usage and technical operation animations, which illustrate how the ZTIC works). ... -- There's a video clip. http://www.youtube.com/watch?v=mPZrkeHMDJ8 (HD and low res) It puts the onus on the user for approval of malware driven transactions. http://www.zurich.ibm.com/ztic/operation.html (animated illustration) Our Land Transport New Zealand agency (www.ltsa.govt.nz, like the DMV) uses POLi for making on line transactions. Apparently POLi uses the very same techniques to provide transaction confirmation to a third party, as are used by malware to interject data into transactions or steal information. There should be no reason a ZTIC like device couldn't be used to provide authentication to a third party as well, the idea being your car license renewal etc. transaction isn't confirmed until the bank completes the payment transaction. Browsers compartmentalizing connections in the equivalent of sandboxes like as done by Chrome would while defending against malware attacks make POLi impossible without something like ZTIC. POLi currently has other dependencies on Windows. It strikes me as insecure today, using the same features exploited by malware. http://www.centricom.com/ (POLi, centricom used to do routers and the like) The POLi service now operates in three countries around the world: Australia, New Zealand and the UK. You'd think the solution would be cost sensitive. Internet banking is big here too. As is phone banking and cell phone message based transactions. You have to subscribe (thankfully). We get our share of fake ATM fronts and the like. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Nov 8, 2009, at 7:45 PM, Thorsten Holz wrote: ...There are several approaches to stop (or at least make it more difficult) this attack vector. A prototype of a system that implements the techniques described in your blog posting was presented by IBM Zurich about a year ago, see http://www-03.ibm.com/press/us/en/pressrelease/25828.wss for details. Bring two threads together: The ZTIC is designed to work with unmodified servers, hence implements SSL/TLS internally. Could the recently discovered SSL injection attack be used against it? (I haven't thought it through and have no idea.) Whether or not it can, it demonstrates the hazards of freezing implementations of crypto protocols into ROM: Imagine a world in which there are a couple of hundred million ZTIC's or similar devices fielded - and a significant vulnerability is found in the protocol they speak. (Since we're talking about a *protocol* vulnerability, having multiple competing implementations doesn't help.) Now, you could make the same argument about the encryption mechanisms - AES, RSA, whatever else is frozen in that silicon - as well. We're reasonably sure of our ability to build strong block and public key ciphers - there have been no significant (publicly known!) breaks in any fielded system in years. The problems with hash functions show that our abilities there aren't as good as we thought. But this recent attack against SSL/TLS, studied by so many people for so many years, should make us really humble about the state of the art in secure protocol development. Not that this should block the use of devices like the ZTIC! They're still much more secure than the alternatives. But it's important to keep in mind the vulnerabilities we engineer *into* systems at the same time we engineer others *out*. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
* John Levine: At a meeting a few weeks ago I was talking to a guy from BITS, the e-commerce part of the Financial Services Roundtable, about the way that malware infected PCs break all banks' fancy multi-password logins since no matter how complex the login process, a botted PC can wait until you login, then send fake transactions during your legitimate session. This is apparently a big problem in Europe. There are some countries which use per-transactions one-time passwords. These methods has been broken as well. So before I send it off, if people have a moment could you look at it and tell me if I'm missing something egregiously obvious? Tnx. There are already some commercial implementations (e.g. those following ZKA's Secoder standard). IBM apparently has something in the works called ZTIC. There used to be the FINREAD standard. Attacks which would break these authentication schemes have already been observed in the wild. There are various means to trick people into providing authorization for fraudulent transactions. Tell them that they have the opportunity to buy an expensive car at a fraction of the price, or offer them a very attractive financial investment, for instance. $50 per device doesn't seem to be much, but you actually need a huge amount of fraud that's actually prevented until it's cost-effective to roll this out. I don't think banks which offer real electronic banking (that is, something pretty much like Paypal, but with consumer rights) can legally tell high-risk from low-risk customers, so you're basically stuck with general rollout. While $50 per device may seem a bit on the high side, I think it's not unrealistic if you consider costs associated with personalization, branding, etc. There's also the issue that a large amount of online banking happens from work during the lunch hour. USB dongles with software installation requirements are problematic for those users. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 08.11.2009, at 01:07, John Levine wrote: I've made it an entry in my blog at http://weblog.johnlevine.com/Money/securetrans.html Actually this type of problem is pretty common in Europe, most banks have to deal with malware that threatens their customers. One of the most advanced keyloggers out there is currently URLZone, which can also perform MitM attacks and transparently re-routes money transfers, defeating iTan (index transaction number) systems (see http://www.finjan.com/MCRCblog.aspx?EntryId=2345 ). There are several approaches to stop (or at least make it more difficult) this attack vector. A prototype of a system that implements the techniques described in your blog posting was presented by IBM Zurich about a year ago, see http://www-03.ibm.com/press/us/en/pressrelease/25828.wss for details. Other manufacturers implemented similar approaches, where some kind of trusted device is attached to the machine and also the banking card of the customer is used to verify transactions. Regards, Thorsten - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Nov 8, 2009, at 2:07 AM, John Levine wrote: At a meeting a few weeks ago I was talking to a guy from BITS, the e-commerce part of the Financial Services Roundtable, about the way that malware infected PCs break all banks' fancy multi-password logins since no matter how complex the login process, a botted PC can wait until you login, then send fake transactions during your legitimate session. This is apparently a big problem in Europe. I told him about an approach to use a security dongle that puts the display and confirmation outside the range of the malware, and although I thought it was fairly obvious, he'd apparently never heard it before. Wow. *That's* scary. When I said I'd been thinking about it for a while, he asked if I could write it up so we could discuss it further. So before I send it off, if people have a moment could you look at it and tell me if I'm missing something egregiously obvious? Tnx. I've made it an entry in my blog at http://weblog.johnlevine.com/Money/securetrans.html Technical content is fine, with one comment: You don't need a big keyboard to allow for a secure user login: Even a single one will do. You'd have a list of, say, 5 key words that you memorize. When the device turns on, it flashes a set of 10 words across the screen, one at a time for 1 second a piece (times/numbers subject to usability testing). Exactly one is from your list of 5; you need to press the button while your word is on the screen. Repeat this process 3 times and the chance of guessing the right words is 1 in a thousand. (Yes, someone can watch you using the device, but if it continues to the end of the set of 10 even after you press the button, it's a bit of a challenge to know which one you picked - and of course they could watch you type your password.) It does need another pass for typos and such - e.g., to defeat attacks that steal credentials and reuse *it* to set up another session later. I think $50 is a very high estimate. (Lynn Wheeler has described a design for a more powerful version of such a device that, as I recall, came in well under this figure a couple of years back.) Note that if the bank supplies the device - so that it necessarily knows any secret contained in it, and it's designed to be resistant to attempts to determine the secrets in it - then you don't need to use public key crypto; symmetric algorithms are just fine. These require very little compute power and memory. Once you assume that the secure endpoints are the device and the bank, the connection between the device and the PC is something you don't need to worry about. For somewhat higher cost than USB, you can use Bluetooth. Then the device can be anything. Look at the iPod shuffle and imagine how Apple might build such a thing. It could easily become a fashion accessory - a bank could get a lot of marketing mileage out of providing a fob with some famous designer's name on it. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Sun, Nov 8, 2009 at 7:07 AM, John Levine jo...@iecc.com wrote: So before I send it off, if people have a moment could you look at it and tell me if I'm missing something egregiously obvious? Tnx. I've made it an entry in my blog at http://weblog.johnlevine.com/Money/securetrans.html Haven't read this thoroughly yet, though I think I disagree with the idea that the display should be minimal - imagine checking out of amazon on a 2-line display. Tedious. Anyway, I should mention my own paper on this subject (with Abe Singer) from NSPW 2008, Take The Red Pill _and_ The Blue Pill: http://www.links.org/files/nspw36.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
