Re: "SSL stops credit card sniffing" is a correlation/causality myth
Ian G <[EMAIL PROTECTED]> writes: >> Perhaps you are unaware of it because no one has chosen to make you >> aware of it. However, sniffing is used quite frequently in cases where >> information is not properly protected. I've personally dealt with >> several such situations. > > This leads to a big issue. If there are no reliable reports, > what are we to believe in? Are we to believe that the > problem doesn't exist because there is no scientific data, > or are we to believe those that say "I assure you it is a > big problem?" [...] > The only way we can overcome this issue is data. You aren't going to get it. The companies that get victimized have a very strong incentive not to share incident information very widely. However, those of us who actually make our living in the field generally have a pretty strong sense of what is going wrong out there. > It can't be the latter; not because I don't believe you in > particular, but because the industry as a whole has not > the credibility to make such a statement. Everyone who > makes such a statement is likely to be selling some > service designed to benefit from that statement, which > makes it very difficult to simply believe on the face of it. Those who work as consultants to large organizations, or as internal security personnel at them, tend to be fairly independent of particular vendors. I don't have any financial reason to recommend particular firms over others, and customers generally are in a position to judge for themselves whether what gets recommended is a good idea or not. > If you have seen such situations, document them and report them - on > forums like these. Anonymise them suitably if you have to. Many of us actually take our contract obligations not to talk about our customers quite seriously, and in any case, anonymous anecdotal reports about unnamed organizations aren't really "data" in the traditional sense. You worry about vendors spreading FUD -- well, why do you assume you can trust anonymous comments not to be FUD from vendors? You don't really need to hear much from me or others on this sort of thing, though. Pretty much common sense and reasoning will tell you things like "the bad guys attack the weak points" etc. Experience says if you leave a vulnerability, it will be exploited eventually, so you try not to leave any. All the data in the world isn't going to help you anyway. We're not talking about what percentage of patients with melanoma respond positively to what drug. Melanomas aren't intelligent and don't change strategy based on what other melanomas are doing. Attack strategies change. Attackers actively alter their behavior to match conditions. The way real security professionals have to work is analysis and conservatism. We assume we're dumb, we assume we'll make mistakes, we try to put in as many checks as possible to prevent single points of failure from causing trouble. We assume machines will be broken in to and try to minimize the impact of that. We assume some employees will turn bad at some point and try to have things work anyway in spite of that. > Another way of looking at this is to look at Choicepoint. > For years, we all suspected that the real problem was > the insider / node problem. The company was where > the leaks occurred, traditionally. > > But nobody had any data. Until Choicepoint. Now we > have data. No you don't. 1) You have one anecdote. You really have no idea how frequently this happens, etc. 2) It doesn't matter how frequently it happens, because no two companies are identical. You can't run 100 choicepoints and see what percentage have problems. 3) If you're deciding on how to set up your firm's security, you can't say "95% of the time no one attacks you so we won't bother", for the same reason that you can't say "if I drive my car while slightly drunk 95% of the time I'll arrive safe", because the 95% of the time that nothing happens doesn't matter if the cost of the 5% is so painful (like, say, death) that you can't recover from it. In particular, you don't want to be someone on who's watch a major breech happens. Your career is over even if it never happens to anyone else in the industry. 3) Most of what you have to worry about is obvious anyway. There's nothing really new here. We've understood that people were the main problem in security systems since before computer security. Ever wonder why accounting controls are set up the way they are? How long were people separating the various roles in an accounting system to prevent internal collusion? That goes back long before computers. > So we need to see a "Choicepoint" for listening and sniffing and so > forth. No, we really don't. > And we need that before we can consider the listening threat to be > economically validated. Spoken like someone who hasn't actually worked inside the field. Statistics and the sort of economic analysis you speak of depends on assumpti
Re: Citibank discloses private information to improve security
Ed Gerck wrote: Also, in an effort to make their certs more valuable, CAs have made digitally signed messages imply too much -- much more than they warrant or can even represent. There are now all sorts of legal implications tied to PKI signatures, in my opinion largely exagerated and casuistic. as discussed in numerous non-repudiation posts, dual-use threat posts, and posts about human signatures where the human signature implies that the person has read, understood, authorizes, approves, and/or agrees with what is read and understood .,... the validation of a digital signature with a public key implies that the message hasn't been altered since transmission and there is "something you have" authentication (the originator has access and use of the corresponding private key). the simple validation of a digital signature doesn't carry with it any of the sense of a human signature and/or non-repudiation. in most business scenarios ... the relying party has previous knowledge and contact with the entity that they are dealing with (making the introduction of PKI digital certificates redundant and superfluous). Furthermore, x.509 identity certificates possibly horribly overloaded with personal information would reprensent significant privacy issues. i've claimed that in the aads effort http://www.garlic.com/~lynn/index.html#aads not having to be pre-occupied with trying to interest relying parties in digital certificates containing information they already had we were more free to concentrate on general threat, risk and vulnerability analysis. for instance, one of the things that a relying party might be really interested in is the integrity of the environment housing a subject's private key (is it in a software file or a hardware token, if a hardware token, what are the characteristics of the hardware token, etc) and the integrity of the environment in which a digital signature was generated. one possible scenario is that CAs wanted to convince relying parties in the value of the certificates and not distract them with fundamental business integrity issues ... which might have resulted in businesses diverting money to fundamental business integrity items ... rather than spending on redundant and superfluous digital certificates likely containing information that they already had (i.e. having digital certificates would result in magical fu-fu dust being sprinkled over the rest of the infrastructure automagically precluding any such integrity problems?). furthermore they could spread semantic confusion ... somehow implying that because the term "digital signature" contained the word "signature" ... it was somehow related to a human signature. lots of collected past postings related to fraud, exploits. vulernabilities, etc http://www.garlic.com/~lynn/subpubkey.html#fraud some number of posts on account number harvesting http://www.garlic.com/~lynn/subpubkey.html#harvest - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "SSL stops credit card sniffing" is a correlation/causality myth
On Tuesday 31 May 2005 21:03, Perry E. Metzger wrote: > Ian G <[EMAIL PROTECTED]> writes: > > On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote: > >> The next part of this is circular reasoning. We don't see network > >> sniffing for credit card numbers *because* we have SSL. > > > > I think you meant to write that James' reasoning is > > circular, but strangely, your reasoning is at least as > > unfounded - correlation not causality. And I think > > the evidence is pretty much against any causality, > > although this will be something that is hard to show, > > in the absence. > > > > * AFAICS, a non-trivial proportion of credit > > card traffic occurs over totally unprotected > > traffic, and that has never been sniffed as far as > > anyone has ever reported. > > Perhaps you are unaware of it because no one has chosen to make you > aware of it. However, sniffing is used quite frequently in cases where > information is not properly protected. I've personally dealt with > several such situations. This leads to a big issue. If there are no reliable reports, what are we to believe in? Are we to believe that the problem doesn't exist because there is no scientific data, or are we to believe those that say "I assure you it is a big problem?" It can't be the latter; not because I don't believe you in particular, but because the industry as a whole has not the credibility to make such a statement. Everyone who makes such a statement is likely to be selling some service designed to benefit from that statement, which makes it very difficult to simply believe on the face of it. The only way we can overcome this issue is data. If you have seen such situations, document them and report them - on forums like these. Anonymise them suitably if you have to. Another way of looking at this is to look at Choicepoint. For years, we all suspected that the real problem was the insider / node problem. The company was where the leaks occurred, traditionally. But nobody had any data. Until Choicepoint. Now we have data. We know how big a problem the node is. We now know that the problem inside the company is massive. So we need to see a "Choicepoint" for listening and sniffing and so forth. And we need that before we can consider the listening threat to be economically validated. > Bluntly, it is obvious that SSL has been very successful in thwarting > certain kinds of interception attacks. I would expect that without it, > we'd see mass harvesting of credit card numbers at particularly > vulnerable parts of the network, such as in front of important > merchants. The fact that phishing and other attacks designed to force > people to disgorge authentication information has become popular is a > tribute to the fact that sniffing is not practical. And I'd expect to see massive email scanning by now of say lawyer's email at ISPs. But, no, very little has occurred. > The bogus PKI infrastructure that SSL generally plugs in to is, of > course, a serious problem. Phishing attacks, pharming attacks and > other such stuff would be much harder if SSL weren't mostly used with > an unworkable fake PKI. (Indeed, I'd argue that PKI as envisioned is > unworkable.) However, that doesn't make SSL any sort of failure -- it > has been an amazing success. In this we agree. Indeed, my thrust all along in "attacking PKI" has been to get people to realise that the PKI doesn't do nearly as much as people think, and therefore it is OK to consider improving it. Especially, where it is weak and where attackers are attacking. Unfortunately, PKI and SSL are considered to be sacrosanct and perfect by the community. As these two things working together are what protects people from phishing (site spoofing) fixing them requires people to recognise that the PKI isn't doing the job. The cryptography community especially should get out there and tell developers and browser implementors that the reason phishing is taking place is that the browser security model is being bypassed, and that some tweaks are needed. > > * We know that from our experiences > > of the wireless 802.11 crypto - even though we've > > got repeated breaks and the FBI even demonstrating > > how to break it, and the majority of people don't even > > bother to turn on the crypto, there remains practically > > zero evidence that anyone is listening. > > Where do you get that idea? Break-ins to firms over their unprotected > 802.11 networks are not infrequent occurrences. Perhaps you're unaware > of whether anyone is listening in to your home network, but I suspect > there is very little that is interesting to listen in to on your home > network, so there is little incentive for anyone to break it. Can you distinguish between break-ins and sniffing and listening attacks? Break-ins, sure, I've seen a few cases of that. In each case the hackers tried to break into an unprotected site that was accessible over an unprotected 802.11. My point though is that th
Re: Citibank discloses private information to improve security
oops, sorry, forgot to include this one Hong Kong banks to introduce two-factor authentication for online transactions http://www.finextra.com/fullstory.asp?id=13744 Banks in Hong Kong are set to introduce two-factor authentication services to the country's 2.7 million Internet banking customers next month. ... snip ... and lots of collected posts on 3-factor authentication paradigm http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
just for the heck of it ... something today more from the physical world ATM scams added to GASA’s fraud library http://www.atmmarketplace.com/news_story_23307.htm CAPE TOWN, South Africa and BROOKINGS, S.D. — The ATM Industry Association's Global ATM Security Alliance launched its online library of ATM fraud, according to a news release. The library is part of Cognito, GASA’s global ATM crime data management system. ... snip ... ... and http://www.globalasa.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
Steven M. Bellovin wrote: Bank of America is adopting some new schemes that might help. First, they're asking users to select a picture the user selected at registration time. The theory is presumably that a phishing site won't have the right image for you. Second, you can "register" your computer; if your account is accessed from another computer, additional authentication is demanded, thus rendering a compromised password much less useful. I think both schemes will help; I doubt that either will stop the problems. a couple more BofA rolls out authentication tools after data breach incident http://eyeonit.itmanagersjournal.com/article.pl?sid=05/05/27/1816200 Bank of America looks to protect Online users with SiteKey http://tech.monstersandcritics.com/news/article_1002765.php/Bank_of_America_looks_to_protect_Online_users_with_SiteKey Payments News: Bank of America Launches SiteKey http://www.paymentsnews.com/2005/05/bank_of_america.html Bank of America | Sign up for the SiteKey Service http://www.bankofamerica.com/privacy/passmark/ Bank of America takes on cyberscams http://news.com.com/Bank+of+America+takes+on+cyberscams/2100-1029_3-5722035.html Bank Of America Fights Phishing With New Authentication http://informationweek.smallbizpipeline.com/news/163701500 Bank of America Announces Industry-Leading Security Feature ... http://money.cnn.com/services/tickerheadlines/prn/200505261000PR_NEWS_USPR_CLTH009.htm Bank of America's SiteKey scrutinized http://news.com.com/2061-10789_3-5723556.html?part=rss&tag=5723556&subj=news - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
Steven M. Bellovin wrote: Bank of America is adopting some new schemes that might help. First, they're asking users to select a picture the user selected at registration time. The theory is presumably that a phishing site won't have the right image for you. Second, you can "register" your computer; if your account is accessed from another computer, additional authentication is demanded, thus rendering a compromised password much less useful. I think both schemes will help; I doubt that either will stop the problems. http://www.bankofamerica.com/newsroom/press/press.cfm?PressID=press.20050526.03.htm but they appear to be vulnerable to MITM-attacks a recent thread http://seclists.org/lists/fulldisclosure/2005/May/0629.html http://seclists.org/lists/fulldisclosure/2005/May/0637.html http://seclists.org/lists/fulldisclosure/2005/May/0639.html http://seclists.org/lists/fulldisclosure/2005/May/0644.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
Bank of America is adopting some new schemes that might help. First, they're asking users to select a picture the user selected at registration time. The theory is presumably that a phishing site won't have the right image for you. Second, you can "register" your computer; if your account is accessed from another computer, additional authentication is demanded, thus rendering a compromised password much less useful. I think both schemes will help; I doubt that either will stop the problems. http://www.bankofamerica.com/newsroom/press/press.cfm?PressID=press.20050526.03.htm --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "SSL stops credit card sniffing" is a correlation/causality myth
Steven M. Bellovin wrote: Given the prevalance of password sniffers as early as 1993, and given that credit card number sniffing is technically easier -- credit card numbers will tend to be in a single packet, and comprise a self-checking string, I stand by my statement. the major exploits have involved data-at-rest ... not data-in-flight. internet credit card sniffing can be easier than password sniffing but that doesn't mean that the fraud cost/benefit ratio is better than harvesting large transaction database files. you could possibly conjecture password sniffing enabling compromise/exploits of data-at-rest ... quick in&out and may have months worth of transaction information all nicely organized. to large extent SSL was used to show that internet/e-commerce wouldn't result in the theoritical sniffing making things worse (as opposed to addressing the major fraud vulnerability & treat). internet/e-commerce did increase the threats & vulnerabilities to the transaction database files (data-at-rest) ... which is were the major threat has been. There has been a proliferation of internet merchants with electronic transaction database files ... where there may be various kinds of internet access to the databases. Even when the prevalent risk to these files has been from insiders ... the possibility of outsider compromise can still obfuscate tracking down who is actually responsible. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "SSL stops credit card sniffing" is a correlation/causality myth
Ian G <[EMAIL PROTECTED]> writes: > On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote: >> The next part of this is circular reasoning. We don't see network >> sniffing for credit card numbers *because* we have SSL. > > I think you meant to write that James' reasoning is > circular, but strangely, your reasoning is at least as > unfounded - correlation not causality. And I think > the evidence is pretty much against any causality, > although this will be something that is hard to show, > in the absence. > > * AFAICS, a non-trivial proportion of credit > card traffic occurs over totally unprotected > traffic, and that has never been sniffed as far as > anyone has ever reported. Perhaps you are unaware of it because no one has chosen to make you aware of it. However, sniffing is used quite frequently in cases where information is not properly protected. I've personally dealt with several such situations. Bluntly, it is obvious that SSL has been very successful in thwarting certain kinds of interception attacks. I would expect that without it, we'd see mass harvesting of credit card numbers at particularly vulnerable parts of the network, such as in front of important merchants. The fact that phishing and other attacks designed to force people to disgorge authentication information has become popular is a tribute to the fact that sniffing is not practical. The bogus PKI infrastructure that SSL generally plugs in to is, of course, a serious problem. Phishing attacks, pharming attacks and other such stuff would be much harder if SSL weren't mostly used with an unworkable fake PKI. (Indeed, I'd argue that PKI as envisioned is unworkable.) However, that doesn't make SSL any sort of failure -- it has been an amazing success. > * We know that from our experiences > of the wireless 802.11 crypto - even though we've > got repeated breaks and the FBI even demonstrating > how to break it, and the majority of people don't even > bother to turn on the crypto, there remains practically > zero evidence that anyone is listening. Where do you get that idea? Break-ins to firms over their unprotected 802.11 networks are not infrequent occurrences. Perhaps you're unaware of whether anyone is listening in to your home network, but I suspect there is very little that is interesting to listen in to on your home network, so there is little incentive for anyone to break it. >> As for DNS hijacking -- that's what's behind "pharming" attacks. In >> other words, it's a real threat, too. > > Yes, that's being tried now too. This is I suspect the > one area where the SSL model correctly predicted > a minor threat. But from what I can tell, server-based > DNS hijacking isn't that successful for the obvious > reasons You are wrong there again. Where are you getting your information from? Whomever your informant is, they're not giving you accurate information. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
Adam Fields wrote: Moreover, in my experience (as I've mentioned before on this list), noticing an invalid certificate is absolutely useless if the banks won't verify via another channel a) that it changed, b) what the new value is or c) what the old value is. I've tried. They won't/can't. one might claim then that a solution is to go to a PGP-like repository of trusted public keys (in addition to and/or in conjunction of typical browser repostiory of trusted certification authority public keys). the URL & public key are loaded into the repository and some out-of-band process is used to establish the "trust" level of the information ... and you are involving the end-user in the trust establishment process. For convenience ... enable this from bookmark and end-user clicks on trusted URLs. then rather than browser using webserver supplied certificate as part of SSL process, the browser uses the onfile trusted public key for that URL. http://www.garlic.com/~lynn/subpubkey.html#certless a threat is social-engineering can convince some number of naive users to do just about anything ... including things like updating a trusted public key repository ... and clicking on email obfuscated URLs (what the email claims to be the URL ... in unrelated to what the URL actually is). a major problem is that a large percentage of the population seems to be extremely naive about trust. some large amount of the skimming and harvesting related fraud is because of existing authentication paradigms that make extensive use of static data and shared-secrets http://www.garlic.com/~lynn/subpubkey.html#secrets a countermeasure could be public key and digital signature verification based authentication. extensive use of file-based private keys make them vulnerable to harvesting by viruses ... but also vulnerable to social engineering attacks getting naive users to divulge contents of private key files. a countermeasure might be hardware tokens where the private key can't be divulged ... even by the token owner. however, social engineering attacks can still get naive users to perform fraudulent transactions on behalf of crooks (even in hardware token based infrastructures). however, the percentage of the population vulnerabile to such attacks might go down as complexity of the social engineering and/or the awareness of the user population goes up. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Trojan horse attack involving many major Israeli companies, executives
> John Saylor wrote: > > hi > > > > ( 05.05.30 15:34 +0200 ) Amir Herzberg: > > > >>See more info e.g. at http://www.haaretz.com/hasen/spages/581790.html > > > > > > an excellent tale [still unfolding]- no doubt coming to a bookstore or > > movie theatre near you real soon. > > > > of course, it was never mentioned in the article, but they *had* to be > > running windows. So, how long before someone, possibly even me, points out that all Checkpoint software is built in Israel? -- Yours, J.A. Terranson [EMAIL PROTECTED] 0xBD4A95BF "Never belong to any party, always oppose privileged classes and public plunderers, never lack sympathy with the poor, always remain devoted to the public welfare, never be satisfied with merely printing news, always be drastically independent, never be afraid to attack wrong, whether by predatory plutocracy or predatory poverty." Joseph Pulitzer 1907 Speech - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "SSL stops credit card sniffing" is a correlation/causality myth
In message <[EMAIL PROTECTED]>, Ian G writes: >On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote: >> In message <[EMAIL PROTECTED]>, "James A. Donald" writes: >> >-- >> >PKI was designed to defeat man in the middle attacks >> >based on network sniffing, or DNS hijacking, which >> >turned out to be less of a threat than expected. >> >> First, you mean "the Web PKI", not PKI in general. >> >> The next part of this is circular reasoning. We don't see network >> sniffing for credit card numbers *because* we have SSL. > >I think you meant to write that James' reasoning is >circular, but strangely, your reasoning is at least as >unfounded - correlation not causality. And I think >the evidence is pretty much against any causality, >although this will be something that is hard to show, >in the absence. Given the prevalance of password sniffers as early as 1993, and given that credit card number sniffing is technically easier -- credit card numbers will tend to be in a single packet, and comprise a self-checking string, I stand by my statement. > > * AFAICS, a non-trivial proportion of credit >card traffic occurs over totally unprotected >traffic, and that has never been sniffed as far as >anyone has ever reported. (By this I mean lots of >small merchants with MOTO accounts that don't >bother to set up "proper" SSL servers.) Given what a small percentage of ecommerce goes to those sites, I don't think it's really noticeable. > > * We know that from our experiences >of the wireless 802.11 crypto - even though we've >got repeated breaks and the FBI even demonstrating >how to break it, and the majority of people don't even >bother to turn on the crypto, there remains practically >zero evidence that anyone is listening. > > FBI tells you how to do it: > https://www.financialcryptography.com/mt/archives/000476. Sure -- but setting up WEP is a nuisance. SSL (mostly) just works. As for your assertion that no one is listening, I'm not sure what kind of evidence you'd seek. There's plenty of evidence that people abuse unprotected access points to gain connectivity. > >As an alternate hypothesis, credit cards are not >sniffed and never will be sniffed simply because >that is not economic. If you can hack a database >and lift 10,000++ credit card numbers, or simply >buy the info from some insider, why would an >attacker ever bother to try and sniff the wire to >pick up one credit card number at a time? Sure -- that's certainly the easy way to do it. > >And if they did, why would we care? Better to >let a stupid thief find a way to remove himself from >a life of crime than to channel him into a really >dangerous and expensive crime like phishing, >box cracking, and purchasing identity info from >insiders. > >> Since many of >> the worm-spread pieces of spyware incorporate sniffers, I'd say that >> part of the threat model is correct. > >But this is totally incorrect! The spyware installs on the >users' machines, and thus does not need to sniff the >wire. The assumption of SSL is (as written up in Eric's >fine book) that the wire is insecure and the node is >secure, and if the node is insecure then we are sunk. I meant precisely what I said and I stand by my statement. I'm quite well aware of the difference between network sniffers and keystroke loggers. > > Eric's book and "1.2 The Internet Threat Model" > http://iang.org/ssl/rescorla_1.html > >Presence of keyboard sniffing does not give us any >evidence at all towards wire sniffing and only serves >to further embarrass the SSL threat model. > >> As for DNS hijacking -- that's what's behind "pharming" attacks. In >> other words, it's a real threat, too. > >Yes, that's being tried now too. This is I suspect the >one area where the SSL model correctly predicted >a minor threat. But from what I can tell, server-based >DNS hijacking isn't that successful for the obvious >reasons (attacking the ISP to get to the user is a >higher risk strategy than makes sense in phishing). They're using cache contamination attacks, among other things. ... > >As perhaps further evidence of the black mark against >so-called secure browsing, phishers still have not >bothered to acquire control-of-domain certs for $30 >and use them to spoof websites over SSL. > >Now, that's either evidence that $30 is too much to >pay, or that users just ignore the certs and padlocks >so it is no big deal anyway. Either way, a model >that is bypassed so disparagingly without even a >direct attack on the PKI is not exactly recommending >itself. I agre completely that virtually no one checks certificates (or even knows what they are). --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
Ed Gerck wrote: Suppose you choose "A4RT" as your codeword. The codeword has no privacy concern (it does not identify you) and is dynamic -- you can change it at will, if you suspect someone else got it. Compare with the other two identifiers that Citibank is using. Your full name is private and static. The ATM's last-four is private and static too (unless you want the burden to change your card often). I agree on the privacy issue, your point is well taken there. Lance James wrote: But from your point, the codeword would be in the clear as well. Respectively speaking, I don't see how either solution would solve this. Ed Gerck wrote: List, In an effort to stop phishing emails, Citibank is including in a plaintext email the full name of the account holder and the last four digits of the ATM card. -- Best Regards, Lance James Secure Science Corporation www.securescience.com Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Have Phishers stolen your customers' logins? Find out with DIA https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: What happened with the session fixation bug?
James A. Donald wrote: PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. asymmetric cryptography has a pair of keys ... the other of the key-pair decodes what has been encoding by one of them. a business process was defined using this technology where one of the key-pair is designated as public ... and freely distributed and the other of the key-pair is designated as confidential and never divulaged. an authentication business process was defined using public/private business process called digital signature where a hash of a message is taken and encoded with the private key. the recipient can recompute the hash of the received message and compare it to the digital signature that has been decoded with the corresponding public key. this catches whether the message has been altered and from 3-factor authentication http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are implies "something you have" authentication ... i.e. the originator has access and use of the corresponding private key. PKI was somewhat targeted at the offline email model of the early 80s; the relying party dials up their (electronic) post office, exchanges email, and hangs up. They then may be dealing with first time correspondance from a total stranger with no (offline or online) recourse for determining information about the sender. Relying parties could be seeded with trusted public key repository of trusted third party certification authorities. Stangers could be issued "certificates" (digitally signed by one of these certification authorities) containing informoation about themselves bound to their public key. Email recipients in the offline email days of the early 80s ... could now of source of information regarding first time communication from total strangers (sort of the "letters of credit" model from the sailing ship days). we were asked to work this small client/server startup in menlo park http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 that wanted to do payments on something they called a commerce server. In the year we worked with them ... they moved from menlo park to mountain view and changed their name (trivia question ... who previously had the rights to their new name? also what large corporate entity was providing most of the funding for the commerce sever?). some topic drift ... recent postings referencing this original e-commerce work as an example of service oriented architecture (SOA): http://www.garlic.com/~lynn/2005i.html#42 http://www.garlic.com/~lynn/2005i.html#43 they had this technology called SSL which was configured at addressing two issues: a) is the webserver that the user had indicated to the browser ... the actual webserver the browser was talking to and b) encryption of the transmitted information. SSL digital certificates would be issued http://www.garlic.com/~lynn/subpubkey.html#sslcert which would contain the domain name of the webserver bound to their public key. the browsers would have trusted public key repository seeded with the public keys of some number of trusted third party certification authorities. the browser SSL process would compare the domain name indicated by the user to the domain name in the digital certificate (after validating the certificate). (at least) two (other) kinds of vulnerabilities/exploits have shown up. 1) in the name of convenience, the browsers have significantly obfuscated the certificate operation from the end-user. attackers have devised ways for the end-users to indicate incorrect webservers ... which the browser SSL process (if it is even invoked) will then gladly validate as the webserver the user indicated. 2) a perceived issue (with knowing that the webserver that a browser is talking to is the webserver the user indicated) were integrity issues in the domain name infrastructure. however, as part of doing this consulting with this small client/server startup ... we also had to do detailed end-to-end business process due dilligence on some number of these certification authorities. it turns out that a certification authority typically has to check with the authoritative agency for the information they are certifying. the authoritative agency for domain name ownership is the domain name infrastructure ... the very institution that there are integrity questions giving rise to the requirement for SSL domain name server certificates. In the second vulnerability, the certification authority industry is somewhat backing a proposal that when somebody registers a domain name with the domain name infrastructure ... they also register their public key. then in future communication with the domain name infrastructure, they digitally sign the communication. the domain name infrastructure the
"SSL stops credit card sniffing" is a correlation/causality myth
On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote: > In message <[EMAIL PROTECTED]>, "James A. Donald" writes: > >-- > >PKI was designed to defeat man in the middle attacks > >based on network sniffing, or DNS hijacking, which > >turned out to be less of a threat than expected. > > First, you mean "the Web PKI", not PKI in general. > > The next part of this is circular reasoning. We don't see network > sniffing for credit card numbers *because* we have SSL. I think you meant to write that James' reasoning is circular, but strangely, your reasoning is at least as unfounded - correlation not causality. And I think the evidence is pretty much against any causality, although this will be something that is hard to show, in the absence. * AFAICS, a non-trivial proportion of credit card traffic occurs over totally unprotected traffic, and that has never been sniffed as far as anyone has ever reported. (By this I mean lots of small merchants with MOTO accounts that don't bother to set up "proper" SSL servers.) * We know that from our experiences of the wireless 802.11 crypto - even though we've got repeated breaks and the FBI even demonstrating how to break it, and the majority of people don't even bother to turn on the crypto, there remains practically zero evidence that anyone is listening. FBI tells you how to do it: https://www.financialcryptography.com/mt/archives/000476.html As an alternate hypothesis, credit cards are not sniffed and never will be sniffed simply because that is not economic. If you can hack a database and lift 10,000++ credit card numbers, or simply buy the info from some insider, why would an attacker ever bother to try and sniff the wire to pick up one credit card number at a time? And if they did, why would we care? Better to let a stupid thief find a way to remove himself from a life of crime than to channel him into a really dangerous and expensive crime like phishing, box cracking, and purchasing identity info from insiders. > Since many of > the worm-spread pieces of spyware incorporate sniffers, I'd say that > part of the threat model is correct. But this is totally incorrect! The spyware installs on the users' machines, and thus does not need to sniff the wire. The assumption of SSL is (as written up in Eric's fine book) that the wire is insecure and the node is secure, and if the node is insecure then we are sunk. Eric's book and "1.2 The Internet Threat Model" http://iang.org/ssl/rescorla_1.html Presence of keyboard sniffing does not give us any evidence at all towards wire sniffing and only serves to further embarrass the SSL threat model. > As for DNS hijacking -- that's what's behind "pharming" attacks. In > other words, it's a real threat, too. Yes, that's being tried now too. This is I suspect the one area where the SSL model correctly predicted a minor threat. But from what I can tell, server-based DNS hijacking isn't that successful for the obvious reasons (attacking the ISP to get to the user is a higher risk strategy than makes sense in phishing). User node-based hijacking might be more successful. Again, that's on the node, so it can totally bypass any PKI based protections anyway. I say "minor threat" because you have to look at the big picture: attackers have figured out a way to breach the secure browsing model so well and so economically that they now have lots and lots of investment money, and are gradually working their way through the various lesser ways of attacking secure browsing. As perhaps further evidence of the black mark against so-called secure browsing, phishers still have not bothered to acquire control-of-domain certs for $30 and use them to spoof websites over SSL. Now, that's either evidence that $30 is too much to pay, or that users just ignore the certs and padlocks so it is no big deal anyway. Either way, a model that is bypassed so disparagingly without even a direct attack on the PKI is not exactly recommending itself. iang -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Citibank discloses private information to improve security
"Heyman, Michael" <[EMAIL PROTECTED]> writes: >In this situation, I believe that the users, through hard won experience with >computers, _correctly_ assumed this was a false positive. Probably not. This issue was discussed at some length on the hcisec list, (security usability, http://groups.yahoo.com/group/hcisec/), e.g: -- Snip -- In my experience with helping out non-technical users, certificates are treated as a purely boolean option, either they're valid or they're not. In fact usually the validity of certificates isn't even an option, either you get a warning dialog or you don't, the actual text may as well be written in Swahili. People don't understand (or maybe don't want to understand) the technical explanations that browsers throw up for them. So an expired cert would have the same status as one for the wrong site or a dozen other reasons why the browser would throw up a warning. I did some even less rigorous checking (i.e. asked a few users who were handy) why they would have done something like this if they'd been one of the 300 and their response was that since it was a known site that they'd dealt with before, they'd assume it was some config error and continue anyway. Several of them had had similar problems with things like hotmail (that is, not SSL- related but just general "it didn't work when I tried it" problems), where clicking OK to get rid of warnings or waiting half an hour and trying again had fixed things. This was just another random site error that they would have navigated around. -- Snip -- For more discussion, see the list archives. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
On Tue, May 31, 2005 at 02:45:56PM +0100, Ian G wrote: > On Saturday 28 May 2005 18:47, James A. Donald wrote: > > > Do we have any comparable experience on SSH logins? > > Existing SSH uses tend to be geek oriented, and do not > > secure stuff that is under heavy attack. Does anyone > > have any examples of SSH securing something that was > > valuable to the user, under attack, and then the key > > changed without warning? How then did the users react? > > I've heard an anecdote on 2 out of 3 of those criteria: > > In a bank that makes heavy use of SSH, the users have > to phone the help desk to get the key reset when the > warning pops up. The users of course blame the tool. > > I suspect in time the addition of certificate based > checking into SSH or the centralised management > of keys will overcome this. > The solution for intramural use of SSH is to use Kerberos for mutual authentication, this obviates the need for per-user known hosts files. Though it took some time for the code that correctly integrates Kerberos into OpenSSH to be adopted, AFAIK this is now done. If it is not (please apply suitable prods to maintainers, as the code has been available for some time). The key obstacle was to allow Kerberos mutual auth to not only log the user in, but to also authenticate the server despite any mismatch in the (now ephemeral) RSA keys. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Papers about "Algorithm hiding" ?
On Thursday 26 May 2005 22:51, Hadmut Danisch wrote: > Hi, > > you most probably have heard about the court case where the presence > of encryption software on a computer was viewed as evidence of > criminal intent. > > http://www.lawlibrary.state.mn.us/archive/ctappub/0505/opa040381-0503.htm > http://news.com.com/Minnesota+court+takes+dim+view+of+encryption/2100-1030_ >3-5718978.html > > > > Plenty of research has been done about information hiding. > But this special court case requires "algorithm hiding" as a kind of > response. Do you know where to look for papers about this subject? > > What about designing an algorithm good for encryption which someone > can not prove to be an encryption algorithm? I don't agree with your conclusion that hiding algorithms is a requirement. I think there is a much better direction: spread more algorithms. If everyone is using crypto then how can that be "relevant" to the case? I would suggest that the best way to overcome this flawed view of cryptography by the judges is to have the operating systems install with GPG installed by default. Some of the better ones already install SSH by default. (In fact the thrust of the argument was flawed as the user's PC almost certainly had a browser with SSL installed. As HTTPS can be used to access webmail privately and as we have seen this was an El Qaeda means of secret communication, the presence of one more crypto tool as "relevent" is a stretch.) iang -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
With bank web sites, experience has shown that only 0.3% of users are deterred by an invalid certificate, probably because very few users have any idea what a certificate authority is, what it does, or why they should care. (And if you have seen the experts debating what a certificate authority is and what it certifies, chances are that those few who think they know are wrong) Well, I have some usability tests that seem to prove your intuitive claim that most users don't know what's a CA. I don't know about arguments between experts on this. I think however that even naive users understand quite the TrustBar UI for SSL protected sites. We display something like identified by . I'll appreciate your thoughts/feedback, try it at http://TrustBar.MozDev.org. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
On Saturday 28 May 2005 18:47, James A. Donald wrote: > Do we have any comparable experience on SSH logins? > Existing SSH uses tend to be geek oriented, and do not > secure stuff that is under heavy attack. Does anyone > have any examples of SSH securing something that was > valuable to the user, under attack, and then the key > changed without warning? How then did the users react? I've heard an anecdote on 2 out of 3 of those criteria: In a bank that makes heavy use of SSH, the users have to phone the help desk to get the key reset when the warning pops up. The users of course blame the tool. I suspect in time the addition of certificate based checking into SSH or the centralised management of keys will overcome this. iang -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Trojan horse attack involving many major Israeli companies, executives
John, yes, I believe the Trojan ran on Windows. In fact, I just met my kids schoolmaster, and turns out she was also a victim of that person - already 3-4 years ago!!! Her daughter learned with his in the same school, and apparently he got mad at them and started abusing them in the most crazy ways - for instance, he intercepted family pictures sent to them, and _disfigured_the_pictures!! She went to the police but I guess was less lucky and they didn't find him, she changed computers, dial-up connection, etc. etc... As you say - movie stuff. Amir John Saylor wrote: hi ( 05.05.30 15:34 +0200 ) Amir Herzberg: See more info e.g. at http://www.haaretz.com/hasen/spages/581790.html an excellent tale [still unfolding]- no doubt coming to a bookstore or movie theatre near you real soon. of course, it was never mentioned in the article, but they *had* to be running windows. -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com New: see my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Papers about "Algorithm hiding" ?
| Hi, | | you most probably have heard about the court case where the presence | of encryption software on a computer was viewed as evidence of | criminal intent. | | http://www.lawlibrary.state.mn.us/archive/ctappub/0505/opa040381-0503.htm | http://news.com.com/Minnesota+court+takes+dim+view+of+encryption/2100-1030_3-5718978.html | | | | Plenty of research has been done about information hiding. | But this special court case requires "algorithm hiding" as a kind of | response. Do you know where to look for papers about this subject? There was a paper published on this a while back. The question was posed as essentially: Can one produce a "one-way trapdoor compiler"? That is, just as an encryption algorithm takes plaintext and converts it to cryptotext, with the property that the inverse transformation is computationally intractable without the key, we want something that takes an algorithm and a key and produces a different but equivalent algorithm, such that asking some set of questions (like, perhaps, whether the output really *is* equivalent to the input) without the key is computationally intractable. The result of the paper was that no such compiler can exist. | What about designing an algorithm good for encryption which someone | can not prove to be an encryption algorithm? Can prove *any* algorithm is an "encryption algorithm"? If so, I think there are some big prizes coming your way. On a more general note: This court case is being blown out of proportion. Screwdrivers, hammers, and a variety of other implements are "burglar's tools". If you are caught in certain circumstances carrying burglar's tools, not only will they be introduced into evidence against you, but the fact you have them will be a criminal violation in and of itself. The way the law deals with all kinds of ambiguities like this is to look at intent: If I carry a screwdriver to repair a broken door on my own house, it's not a burglar's tool. If I carry it to break the lock on my neighbor's house, it is. Determining intent is up to a jury (or judge or judge's panel, depending on the legal system and the defendent's choices). It's outside the realm of mathematics, proof in the mathematical sense, or much other than human judgement. If an expert witness testifies something is an encryption algorithm, and the jury believes him more than the defense's expert witness who testifies it's a digital controller for a secret ice cream maker ... that's what it is. If the jury further believes that encryption algorithm was used in the furtherance of a crime ... the defendent is in trouble. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
[EMAIL PROTECTED]: [IP] Intel quietly embeds DRM in it's 945 chips firmware]
- Forwarded message from David Farber <[EMAIL PROTECTED]> - From: David Farber <[EMAIL PROTECTED]> Date: Tue, 31 May 2005 08:17:59 -0400 To: Ip ip Subject: [IP] Intel quietly embeds DRM in it's 945 chips firmware X-Mailer: Apple Mail (2.730) Reply-To: [EMAIL PROTECTED] Begin forwarded message: From: Date: May 31, 2005 1:15:49 AM EDT To: [EMAIL PROTECTED] Subject: Re: [IP] Intel quietly embeds DRM in it's 945 chips firmware Dave Farber: Please remove my name and identity from this mailing, due to fear of reprisal. (I still work in the entetainment business from time to time.) I do not know all about Intel's DRM, but I do know more, perhaps, than I should. What I do know is that Intel has been working very closely with the entertainment industry on a DRM that, I've been told, seeks to satisfy EVERYONE'S wishes. Of course, such a system would mean, by definition, that it will satisfy either no one, or only the studios. But I do know that the Intel "dream" DRM system would allow content to be moved from one platform to another on a network, presumably through a check-in/check-out procedure, to make sure only a limited number of (legitimate) copies would be made and in service at any one time. Intel's system also acknowledges, for example, that a high- resolution (e.g. high definition video) copy of a film could be used to create low-res (like Quicktime, Real or Windows Media) versions that could be used in portable video players. Users might even be able to "loan" time-limited copies or be allowed to make a small number of copies, like Apple's Fair Play DRM permits. You can check out Intel's ideas for such a system, and the participation of an entertainment and consumer electronics industry panel called the Digital Home Working Group, on which Intel sits, which has been addressing such a system in this article from February, 2004: http://www.infoworld.com/article/04/02/24/HNbarrettdrm_1.html (Note: The Japanese system for hard disk and DVD recorders that Barrett alludes to is called CPRM. It is neither new nor flexible, and there has already been some consumer backlash against it in Japan, where it is used for the transmission of digital TV b'casts -- sort of their "broadcast flag.") At the root of the problem, of course, is the personal computer that's used as a media player platform. This is also, not coincidentally, Intel's cash cow. Such a DRM system, with the PC playing a pivotal role, would also mean that IBM or other chip vendors would not be allowed to play without building in the same chip-level protection. Without these important security pieces, Apple, for example, would be cut out of the picture for playing content protected by the Intel-endorsed DRM, as would (most likely) Linux-based devices. This is a GRAND PLAN that relies on it being either almost completely transparent to consumers (like Apple's Fair Play) or simple to understand. Unfortunately, almost no DRM is easily understood by consumers. Even most of the customer's for Apple's iTunes Music Store only become familiar with the terms under which they've purchased their music when they bump up against the limitations that have been set. The real nightmare scenario, in my opinion, is a world in which several such DRMs co-exist, creating a chaotic environment in which you never know whether content will play on one plaform but not another. This is a potentially really sticky mess. - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl __ ICBM: 48.07100, 11.36820http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE signature.asc Description: Digital signature
RE: Citibank discloses private information to improve security
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of James A. Donald
> Sent: Saturday, May 28, 2005 1:48 PM
>
> With bank web sites, experience has shown that only 0.3% of
> users are deterred by an invalid certificate, probably
> because very few users have any idea what a certificate
> authority is, what it does, or why they should care.
>
I assume you refer to the BankDirect case with the accidentally invalid
certificate.
In this situation, I believe that the users, through hard won experience
with computers, _correctly_ assumed this was a false positive. If an
attack had actually occurred, the users would have been wrong. Luckily
for them, they were correct and did not let the mistake interfere with
their commerce. The one in 300 users that did let the mistake interfere
wasted their time and, perhaps, money if they lost money due to the
delay in access.
As it stands, the system works reasonably well (of course it still has
its share of problems). If 300 out of 300 users wasted time and money
because of the mistake (say if the system were designed so users could
not bypass the possibly bad certificate warning), the security folks in
ivory towers may pat themselves on the back saying, "look, the system
works great!" - the actual users of the technology would be more then a
little ticked. A brittle system that cannot accept failures will always
have trouble dealing with us fallible types.
I'm not familiar with the BankDirect site, but if it like banking sites
I am used to, it is fairly impersonal and easy to spoof. One way to
reduce the ease-of-spoof factor is to add many ways to identify the bank
web site. If one or two of them fail, the web site is probably still
valid. Ways to identify a site include certificates, personalized
greetings ("Hello Michael, Welcome back, you haven't been here in 4 days
and we've missed you"), code words, the PetName tool, green light by
anti-phishing software, even the URL and overall look-and-feel. So what
if a couple of them fail? That happens all the time and we have to
expect that and design our systems to work in spite of it.
-Michael Heyman
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Papers about "Algorithm hiding" ?
HD> What about designing an algorithm good for encryption which someone HD> can not prove to be an encryption algorithm? Hmmm, but to do that one needs to have a good definition of 'encryption algorithm' and perhaps also some other apparently fundamental terms. But we have none, I am afraid ... at least it seems it is hard to give precise definition even of the cryptography alone (the old one relating that to 'secure communication over insecure channel' seems not to be consistent with quantum crypto...) Regards, Jozef - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
"James A. Donald" <[EMAIL PROTECTED]> writes: >With bank web sites, experience has shown that only 0.3% of users are >deterred by an invalid certificate, probably because very few users have any >idea what a certificate authority is, what it does, or why they should care. James (and others): I really wouldn't cite the BankDirect figure as a hard value, since it represents just a single user, who may in turn have clicked on the wrong button (i.e. the real figure could have been 0%). It'd be better to say "statistically insignificant" or "negligible" or some other close-to-or- equal-to-zero synonym. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Papers about "Algorithm hiding" ?
> -Original Message- > Hadmut Danisch wrote: > > ... > Plenty of research has been done about information hiding. > But this special court case requires "algorithm hiding" as a kind of > response. Do you know where to look for papers about this subject? > ... Here is the list that you can start with: [1] Boaz Barak, Oded Goldreich, Russell Impagliazzo, Steven Rudich, Amit Sahai, Sali Vadhan, Ke Yang. On the (im)possibility of obfuscating programs. In Proceedings of CRYPTO 2001. [2] Benjamin Lynn, Manoj Prabhakaran, Amit Sahai. Positive Results and Techniques for Obfuscation. In Proceedings of Eurocrypt 2004. [3] Hoeteck Wee. On Obfuscating Point Functions. Computer Science Division University of California, Berkeley. Jan 2005 [4] Christian Collberg, Clark Thomborson. Watermarking, tamper-proofing and obfuscation - tools for software protection. IEEE Transactions on software engineering, vol.28, No.8, August 2002. [5] Christian Collberg, Clark Thomborson. Watermarking, tamper-proofing and obfuscation - tools for software protection. Technical Report TR00-03, The Department of Computer Science, University of Arizona, February 2000. [6] Christian Collberg, Clark Thomborson, Douglas Low. Breaking Abstractions and Unstructuring Data Structures. IEEE International Conference on Computer Languages, May 1998. [7] Christian Collberg, Clark Thoborson, Douglas Low. Manufacturing Cheap, Resilient, and Stealthy Opaque Constructs. Principles of Programming Languages 1998, POPL'98, January 1988. [8] Christian Collberg, Clark Thomborson, Douglas Low. A Taxonomy of Obfuscating Transformations. Technical Report 148, Department of Computer Science, The University of Auckland. July 1997. [9] Chenxi Wang, Jonathan Hill, John Knight, Jack Davidson. Protection of Software-based Survivability Mechanisms. International Conference of Dependable Systems and Networks. July 2001. [10] Chenxi Wang. A Security Architecture for Survivability Mechanisms. PhD Dissertation, Department of Computer Science, University of Virginia, October 2000. [11] Chenxi Wang, Jonathan Hill, John Knight, Jack Davidson. Software Tamper Resistance: Obstructing Static Analysis of Programs. Technical Report CS-2000-12, Department of Computer Science, University of Virginia. May 2000. [12] Cullen Linn, Saumya Debray. Obfuscation of Executable Code to Improve Resistance to Static Disassembly. ACM Conference on Computer and Communications Security (CCS 2003), October 2003, pp. 290-299 [13] Fritz Hohl. A Framework to Protect Mobile Agents by Using Reference States. Proceedings of the 20th International Conference on Distributed Computing Systems (ICDCS 2000), pp. 410-417, 2000. [14] Gregory Wroblewski. General Method of Program Code Obfuscation. PhD Dissertation, Wroclaw. 2002. [15] S. Chow, H. Johnson, P.C. van Oorschot, P Eisen. A White-Box DES implementation for DRM applications. In Proceedings of ACM CCS-9 Workshop DRM. 2002 [16] Matthias Jacom, Dan Boneh, Edard Feltin. Attacking an obfuscated cipher by injecting faults. In Proceedings of ACM CCS-9 Workshop DRM. 2002. [17] Yuval Ishai, Amit Sahai, David Wagner. Private Circuits: Securing Hardware against Probing Attacks. In Proceedings of CRYPTO 2003. [18] Markus Kuhn, Oliver Kommerling. Design Principles for Tamper-Resistant Smartcard Processors. USENIX Workshop on Smartcard Technology proceedings, Chicago, Illinois, USA, May 10-11, 1999. [19] Ross Anderson, Markus Kuhn. Tamper resistance - a Cautionary Note. The Second USENIX Workshop on Electronic Commerce Proceedings, Oakland , California, November 18-21 1996, pp 1-11. [20] Gael Hachez. A Comparative Study of Software Protection Tools Suited for E-Commerce with Contributions to Software Watermarking and Smart Cards. PhD thesis, Faculte des Sciences Appliquees Laboratoire de Microelectronique. Universite Catholique de Louvain. March 2003. [21] T.-C. Lin, M. Hsiang Hsu, F.-Y. Kuo, and P.-C. Sun. An Intention Model-based Study of Software Piracy. In 32nd Annual Hawaii International Conference on System Sciences (HICSS-32). IEEE Computer Society, January 1999. [22] Amit Sethi. Digital Rights Management and Code Obfuscation. Thesis in fulfillment of degree of Master of Mathematics. University of Waterloo, Ontario, Canada. 2003. [23] M. Kunin. Why do Software Manufactures Tolerate Piracy in Transition and Less Developed Countries? A theoretical model. Discussion Paper Series 2001-75, JEL classification: O34;L20. Center for Economic Research, Charles University and the Academy of Sciences, Czech Republic, October 2001. [24] Christian Collberg. SandMark Algorithms. January 28, 2003 [25] Christian Collberg, Ginger Myles, Michael Stepp. Cheating Cheating Detectors. Department Computer Science University of Arizona. Technical Report TR04-05. March 3, 2004 [26] James R. Gosler. Software Protection: Myth or Reality? Sandia National Laboratory. Advances in Cryptology - CRYPTO'85. 1985. [27] Kelly Heffner, Christian Collberg. The Obfuscation Executive.
Re: Citibank discloses private information to improve security
On Sat, May 28, 2005 at 10:47:56AM -0700, James A. Donald wrote: [..] > With bank web sites, experience has shown that only 0.3% > of users are deterred by an invalid certificate, > probably because very few users have any idea what a > certificate authority is, what it does, or why they > should care. (And if you have seen the experts debating > what a certificate authority is and what it certifies, > chances are that those few who think they know are > wrong) Moreover, in my experience (as I've mentioned before on this list), noticing an invalid certificate is absolutely useless if the banks won't verify via another channel a) that it changed, b) what the new value is or c) what the old value is. I've tried. They won't/can't. > Do we have any comparable experience on SSH logins? > Existing SSH uses tend to be geek oriented, and do not > secure stuff that is under heavy attack. Does anyone > have any examples of SSH securing something that was > valuable to the user, under attack, and then the key > changed without warning? How then did the users react? Every time this has happened to someone I know who uses SSH, it's been immediate cause for alarm, causing a phone call to the person who administers the box asking "what the? did you reinstall the OS again?". -- - Adam ** I can fix your database problems: http://www.everylastounce.com/mysql.html ** Blog... [ http://www.aquick.org/blog ] Links.. [ http://del.icio.us/fields ] Photos. [ http://www.aquick.org/photoblog ] Experience. [ http://www.adamfields.com/resume.html ] Product Reviews: .. [ http://www.buyadam.com/blog ] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: What happened with the session fixation bug?
In message <[EMAIL PROTECTED]>, "James A. Donald" writes: >-- >PKI was designed to defeat man in the middle attacks >based on network sniffing, or DNS hijacking, which >turned out to be less of a threat than expected. > First, you mean "the Web PKI", not PKI in general. The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL. Since many of the worm-spread pieces of spyware incorporate sniffers, I'd say that part of the threat model is correct. As for DNS hijacking -- that's what's behind "pharming" attacks. In other words, it's a real threat, too. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Papers about "Algorithm hiding" ?
Isn't this what Rivest's "Chaffing and Winnowing" is all about? http://theory.lcs.mit.edu/~rivest/chaffing.txt Cheers, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hadmut Danisch Sent: Thursday, May 26, 2005 5:51 PM To: cryptography@metzdowd.com Subject: Papers about "Algorithm hiding" ? Hi, you most probably have heard about the court case where the presence of encryption software on a computer was viewed as evidence of criminal intent. http://www.lawlibrary.state.mn.us/archive/ctappub/0505/opa040381-0503.ht m http://news.com.com/Minnesota+court+takes+dim+view+of+encryption/2100-10 30_3-5718978.html Plenty of research has been done about information hiding. But this special court case requires "algorithm hiding" as a kind of response. Do you know where to look for papers about this subject? What about designing an algorithm good for encryption which someone can not prove to be an encryption algorithm? regards Hadmut - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
