Re: SSL stops credit card sniffing is a correlation/causality myth
Ian G wrote: But don't get me wrong - I am not saying that we should carry out a world wide pogrom on SSL/PKI. What I am saying is that once we accept that listening right now is not an issue - not a threat that is being actively dedended against - this allows us the wiggle room to deploy that infrastructure against phishing. Does that make sense? No, not really. Until you can show me an Internet Draft for a solution to phishing that requires that we give up SSL, I don't see any reason to do so. As a consumer, I'd be very reluctant to give up SSL for credit card transactions because I use it all the time and it makes me feel safer. What matters is now: what attacks are happening now. Does phishing exist, and does it take a lot of money? What can we do about it? If you don't know what we can do about phishing, why do you think that getting rid of SSL is a necessary first step? You seem to be putting the cart in front of the horse. -- Give a man a fire and he's warm for a day, but set | Tom Weinstein him on fire and he's warm for the rest of his life.| [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL stops credit card sniffing is a correlation/causality myth
On Tue, May 31, 2005 at 06:43:56PM -0400, Perry E. Metzger wrote: | | 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. I believe that this is changing, and that Choicepoint is the wedge. Organizations that are under no legal obligation to report breaches are doing so, some quite rapidly, to avoid the PR disaster that hit Choicepoint. That shift may lead to a change in public perceptions from breaches are rare to the reality, which is that breaches are common. If that shift takes place, then companies may be more willing to share data, and thats a good. [...] much deleted | Statistics and the sort of economic analysis you speak of depends on | assumptions like statistical independence and the ability to do | calculations. If you have no basis for calculation and statistical | independence doesn't hold because your actors are not random processes | but intelligent actors, the method is worthless. | | In most cases, by the way, the raw cost of attempting a cost benefit | analysis will cost far more than just implementing a safeguard. A | couple thou for encrypting a link or buying an SSL card is a lot | cheaper than the consulting hours, and the output of the hours would | be an utterly worthless analysis anyway. So, that may be the case when you're dealing with an SSL accelerator, but there are lots of other cases, say, implementing daabase security rules, or ensuring that non-transactional lookups are logged, which are harder to argue for, take more time and energy to implement, and may well entail not implementing customer-visible features to get them in on budget. Choicepoint and Lexis Nexis seemingly, had neither. Nor are they representational. We lack good data, and while there are a few hundred folks who have the experience, chops, and savvy to help their customers make good decisions, there are tens of thousands of companies, many of whom choose not to pay rates for that sort of advice, and hire an MCSE, instead. People who slap the label best practice on log truncation. I think that we need to promulgate the idea that Choicepoint is creating a shift, that it will be ok to talk about breaches, with the intent of getting better data over time. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
analysis of the Witty worm
Readers of this list may be interested in an analysis of the Witty worm's spread by Kumark, Paxson, and Weaver. An article summarizing the paper is at http://www.zdnet.co.uk/print/?TYPE=storyAT=39200183-39020375t-1025c A tentative conclusion is that the worm was probably written by an insider at ISS The paper itself (there's a link in the article) has several more items of interest to this list. Especially interesting is the effective cryptanalysis of the PRNG used by the worm. Implicit in many of the analyses, though not a focus of the paper, is the amount of information that the authors could gather about network configurations at different sites: as we all know, traffic analysis is a powerful technique. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
On Wednesday 01 June 2005 15:07, [EMAIL PROTECTED] wrote: Ian G writes: | In the end, the digital signature was just crypto | candy... On the one hand a digital signature should matter more the bigger the transaction that it protects. On the other hand, the bigger the transaction the lower the probability that it is between strangers who have no other leverage for recourse. Yes, indeed! The thing about a signature is that *it* itself - the mark on paper or the digital result of some formula - isn't the essence of signing. The essence of the process is something that lawyers call intent (I'm definately not clear on these words so if there are any real lawyers in the house...). And, when the dispute comes to court, the process is not one of proving the signature but of showing intent. And as the transaction gets bigger, the process of making and showing intent gets more involved, more complex. So it is naturally ramped up to the transaction, in a way that digsigs just totally miss out on. Which means that the digital signature school got it completely wrong. A digital signature is only just one more element in a process that is quite complex, involved, and goes back into history more years than we can count. It is therefore completely unlikely that a digsig will ever replace all that; however it is quite possible that a digsig could comfortably add a new element to that process. (Speaking here of common law, which is not universally applicable...) And, of course, proving anything by way of dueling experts doesn't provide much predictability in a jury system, e.g., OJ Simpson. And this is where we found for example the OpenPGP cleartext digital signature to be the only one that has any merit. Because it can be printed on paper, and that piece of paper can be presented to the jury of an O.J.Simpson style case, or even a Homer Simpson style case, this carries weight. An OpenPGP clear text signature carries weight because it is there, in black and white, and no side would dare to deny that because they know it would be a simple matter to go to the next level. But any other form of non-printable digital signature is not presentable to a jury. What are you going to do? Throw a number in front of a jury and say its a signature on another number? It's a mental leap of orders of magnitude more effort, and there are many ways the other side could sidestep that. iang PS: To get this in x.509, we coded up cleartext sigs into the x.509 format. -- 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
Amir Herzberg wrote: Nicely put, but I think not quite fair. From friends in financial and other companies in the states and otherwise, I hear that Trojans are very common there as well. In fact, based on my biased judgement and limited exposure, my impression is that security practice is much better in Israeli companies - both providers and users of IT - than in comparable companies in most countries. For example, in my `hall of shame` (link below) you'll find many US and multinational companies which don't protect their login pages properly with SSL (PayPal, Chase, MS, ...). I've found very few Israeli companies, and of the few I've found, two actually acted quickly to fix the problem - which is rare! Most ignored my warning, and few sent me coupons :-) [seriously] Could it be that such problems are more often covered-up in other countries? Or maybe that the stronger awareness in Israel also implies more attackers? I think both conclusions are likely. I also think that this exposure will further increase awareness among Israeli IT managers and developers, and hence improve the security of their systems. there is the story of the (state side) financial institution that was outsourcing some of its y2k remediation and failed to perform due diligence on the (state side) lowest bidder ... until it was too late and they were faced with having to deploy the software anyway. one of the spoofs of SSL ... was originally it was supposed to be used for the whole shopping experience from the URL the enduser entered, thru shopping, checkout and payment. webservers found that with SSL they took a 80-90% performance hit on their thruput ... so they saved the use of SSL until checkout and payment. the SSL countermeasure to MITM-attack is that the URL the user entered is checked against the URL in the webserver certificate. However, the URL the users were entering weren't SSL/HTTPS ... they were just standard stuff ... and so there wasn't any countermeasure to MITM-attack. If the user had gotten to a spoofed MITM site ... they could have done all their shopping and then clicked the checkout button ... which might provide HTTPS/SSL. however, if it was a spoofed site, it is highly probable that the HTTPS URL provided by the (spoofed site) checkout button was going to match the URL in any transmitted digital certificate. So for all, intents and purposes .. most sites make very little use of https/ssl as countermeasure for MITM-attacks ... simply encryption as countermeasure for skimming/harvesting (evesdropping). in general, if the naive user is clicking on something that obfuscates the real URL (in some case they don't even have to obfuscate the real URL) ... then the crooks can still utilize https/ssl ... making sure that they have a valid digital certificate that matches the URL that they are providing. the low-hanging fruit of fraud ROI ... says that the crooks are going to go after the easiest target, with the lowest risk, and the biggest bang-for-the buck. that has mostly been the data-at-rest transaction files. then it is other attacks on either of the end-points. attacking generalized internet channels for harvesting/skimming appears to be one of the lowest paybacks for the effort. in other domains, there have been harvesting/skimming attacks ... but again mostly on end-points ... and these are dedicated/concentrated environments where the only traffic ... is traffic of interest (any extraneous/uninteresting stuff has already been filtered out). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
[EMAIL PROTECTED] wrote: On the one hand a digital signature should matter more the bigger the transaction that it protects. On the other hand, the bigger the transaction the lower the probability that it is between strangers who have no other leverage for recourse. And, of course, proving anything by way of dueling experts doesn't provide much predictability in a jury system, e.g., OJ Simpson. the bigger the transaction that the digital signature verifies the more the relying party is going to be interested in fundamental integrity issues surrounding the digital signature generation from 3-factor authentication paradigm * something you have * something you know * something you are simple digital signature verification is basically something you have authentication ... implying that the originator has access to and use of the corresponding private key (in addition to the transaction not having been modified in transit). fundamental issues surrounding digital signature can be the integrity level of the infrastructure preventing compromise of the private key aka is the private key protected in a software file, is the private key in a hardware token, was the private key generated in a hardware token and can never leave the hardare token. also if it is a hardware token, is a pin/password also required to make the token operate correctly i.e. knowing characteristics of the hardware token, the relying party might be able to infer two-factor authentication and assess the risk/threats involved. also what is the integrity level of the infrastructure in which the digital signature was generated ... for instance some of the EU finread standard http://www.garlic.com/~lynn/subpubkey.html#finread which try and specify the minimum constraints for generation of a digital signature on a financial transaction. this isn't so much proving anything ... this is risk management ... what is the likelyhood/exposure of a compromise for the relying party ... or security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 standard types of things that you would find at financial institutions and/or insurance institutions. part of the confusion possibly is because of the extensive deployment of PKI literature ... which tends to focus the attention on the certification process ... as opposed to the integrity of the authentication process. the issue is that for the majority of business operations ... the PKI certificate process tends to be duplication of extensive relationship management business process that they already have in use (and therefor is redundant and superfluous) ... and there is much less focus on the basic risk, threat and vulnerability issues related directly to the authentcation. and as i've frequently postulated ... that same may have an interest in creating semantic confusion ... implying that because the term digital signature includes the word signature ... that it somehow bears some relationship to human signatures. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
Heyman, Michael wrote: Defense in depth can help against spoofing - this includes valid certificates, personalization (even if it is the less-than-optimal Citibank-like solution), PetName, etc. Man-in-the-middle is harder given that we have such a high false positive rate on our best weapon. i would claim that SSL-like protocol with both countermeasure for MITM-attack and eavesdropping attacks should be adequate. many of the current problems is that browsers and email clients have tended to added multiple layers of obfuscation around the URL process ... so it may be difficult for even experience users to realize what is happening a semi-counter argument for defense-in-depth is KISS ... lots of complex layers tend to create all sorts of cracks for the attackers to get thru. in theory, the KISS part of SSL's countermeasure for MITM-attack ... is does the URL you entered match the URL in the provided certificate. An attack is inducing a fraudulent URL to be entered for which the attackers have a valid certificates. so some of the recent internet phishing countermeasures are trying to rely on clear, un-obfuscated indications recognizable by even naive users. however, the tend to be add-ons, non-integrated with existing countermeasures (like SSL MITM-attack countermeasures) and leave existing systemic vulnerabilities in place. When purely static data un-obfuscated recognizable indications are used independently of MITM countermeasures a MITM can create active channels between themselves and the end-user and themselves and the website and transparently pass information between the two end-points. Rather than complex defense in depth ... all with cracks and vulnerabilities that attackers can wiggle around ... a better approach would be KISS solution that had integrated approach to existing systemic vulnerabilities. For instance, some sort of clear, un-obfuscated indications integrated with URL selection that can leverage the existing SSL MITM-attack countermeasures. The downside of a KISS integrated solution that eliminates existing systemic problems (and avoids creating complex layers, each with their individual cracks that the attackers can wiggle thru) ... is that the only current special interest for such a solution seems to be the victims. Some sort of fix that allows naive users to relate and enter specific trusted URLs associated with specific tasks could fix many of the existing infrastructure vulnerabilities. The issue is what institutions have financial interest in designing, implementing, and marketing such a likely free add-on to existing mostly free based infrastructure. It appears to be much easier justify the design, implementation and marketing of a totally new feature that can be separately charge for. some some topic drift ... one person's history of priced software: http://www.garlic.com/~lynn/2005g.html#51 http://www.garlic.com/~lynn/2005g.html#53 http://www.garlic.com/~lynn/2005g.html#54 http://www.garlic.com/~lynn/2005g.html#57 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
On the one hand a digital signature should matter more the bigger the transaction that it protects. On the other hand, the bigger the transaction the lower the probability that it is between strangers who have no other leverage for recourse. I think signatures are increasingly being used for technical reasons, not legal. That is, sign and verify just to prove that all the layers of middleware and Internet and general bugaboos didn't screw with it. People seem to be building systems that assume proper operation, and use signatures as an application-level way to check, and also as a line of defense to screen out outsiders, rather than hold insiders liable. Loosly coupled, tightly contracted. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL stops credit card sniffing is a correlation/causality myth
Ahh-oops! That particular reply was scrappily written late at night and wasn't meant to be sent! Apologies belatedly, I'd since actually come to the conclusion that Steve's statement was strictly correct, in that we won't ever *see* sniffing because SSL is in place, whereas I interpreted this incorrectly perhaps as SSL *stopped* sniffing. Subtle distinctions can sometimes matter. So please ignore the previous email, unless a cruel and unusual punishment is demanded... iang On Wednesday 01 June 2005 16:24, Ian G wrote: On Tuesday 31 May 2005 19:38, Steven M. Bellovin wrote: 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. Well, I'm not arguing it is technically hard. It's just un-economic. In the same sense that it is not technically difficult for us to get in a car and go run someone over; but we still don't do it. And we don't ban the roads nor insist on our butlers walking with a red flag in front of the car, either. Well, not any more. So I stand by my statement - correlation is not causality. * 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. Exactly my point. Sniffing isn't noticeable. Neither in the cases we know it could happen, nor in the areas. The one place where it has been noticed is with passwords and what we know from that experience is that even the slightest security works to overcome that threat. SSH is overkill, compared to the passwords mailouts that successfully protect online password sites. * 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. SSH just works - and it worked directly against the threat you listed above (password sniffing). But it has no PKI to speak of, and this discussion is about whether PKI protects people, because it is PKI that is supposed to protect against spoofing - a.k.a. phishing. And it is PKI that makes SSL just doesn't set up. Anyone who's ever had to set up an Apache web server for SSL has to have asked themselves the question ... why doesn't this just work ? 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. Simply, evidence that people are listening. Sniffing by means of the wire. Evidence that people abuse to gain unprotected access is nothing to do with sniffing traffic to steal information. That's theft of access, which is a fairly minor issue, especially as it doesn't have any economic damages worth speaking of. In fact, many cases seem to be more accidental access where neighbours end up using each other's access points because the software doesn't know where the property lines are. 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
ANNOUNCE: PureTLS 0.9b5
ANNOUNCE: PureTLS version 0.9b5 Copyright (C) 1999-2005 Claymore Systems, Inc. http://www.rtfm.com/puretls DESCRIPTION PureTLS is a free Java-only implementation of the SSLv3 and TLSv1 (RFC2246) protocols. PureTLS was developed by Eric Rescorla for Claymore Systems, Inc, but is being distributed for free because we believe that basic network security is a public good and should be a commodity. PureTLS is licensed under a Berkeley-style license, which basically means that you can do anything you want with it, provided that you give us credit. This is a beta release of PureTLS. Although it has undergone a fair amount of testing and is believed to operate correctly, it no doubt contains significant bugs, which this release is intended to shake out. Please send any bug reports to the author at [EMAIL PROTECTED]. CHANGES FROM B4 * SECURITY: Zero OPTIONAL values before parsing. This prevents bleedthrough of those values from previously parsed certificates into certificates where they are missing. This is a workaround for a bug in the Cryptix ASN.1 kit. The only relevant values are Extensions and Algorithm.Parameters. In practice this should not be a problem with Algorithm.Parameters Since they're NULL in RSA certificates and always present in real DSA certificates. If you rely on Extensions you should upgrade as soon as possible. Note: extensions processing is still only partially tested (see below). * Trim all leading zeros from DH shared keys. This fixes a rare compatibility problem. * Fix handling of pathLen constraints. We were off by one, causing some valid certificates to be rejected. We believe that this is the best version of PureTLS available. Users are advised to upgrade as soon as possible. In particular, if you rely on X.509 extension processing you should upgrade as soon as possible. This will most likely be the last release of PureTLS distributed as a standalone package by Claymore Systems. We have given the BouncyCastle (http://www.bouncycastle.org) permission to integrate the PureTLS source code with their library and we expect them to deliver an integrated system in the future. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL stops credit card sniffing is a correlation/causality myth
On Thursday 02 June 2005 11:33, Birger Tödtmann wrote: Am Mittwoch, den 01.06.2005, 15:23 +0100 schrieb Ian G: [...] For an example of the latter, look at Netcraft. This is quite serious - they are putting out a tool that totally bypasses PKI/SSL in securing browsing. Is it insecure? Yes of course, and it leaks my data like a seive as one PKI guy said. [...] What I currently fail see is the link to SSL. Or, to its PKI model. That's the point. There is no link to SSL or PKI. The only thing in common is the objective - to protect the user when browsing. Secure browsing is now being offered by centralised database sans crypto. Netcraft bypasses it, but I won't use Netcraft exclusively because I'm happy to use the crypto in SSL. Netcraft and Trustbar are really nice add-ons to improve my security *with SSL*. So where is the point? Sure, I think it is a piece of junk, myself. But I am not important, I'm not an average user. The only thing that is important is what the user thinks and does. When Netcraft announced their plugin had been ported from IE to Firefox last week, they also revealed that they had 60,000 downloads in hours. That tells us a few things. Firstly, users want protection from phishing. Secondly, Netcraft have succeeded enough in the IE world in creating a user base for their solution that it easily jumped across to the Firefox userbase and scored impressive numbers straight away. Which tells us that it actually delivers something useful (which may or may not be security). So we cannot discount that the centralised database concept works well enough by some measure or other. So now we wait to see which model wins in protecting the user from spoofing. 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: Papers about Algorithm hiding ?
On 5/31/05, Ian G [EMAIL PROTECTED] wrote: 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? This is so, in the ideal. But if everyone would only... never seems to work out in practice. Better to rely on what you can on your own or with a small group. In response to Hadmut's question, for instance, I'd hide the crypto app by renaming the executable. This wouldn't work for a complex app like PGP Suite but would suffice for a simple app. Rename the encrypted files as well and you're fairly safe. (I've consulted with firms that do disk drive analysis. From what I've seen, unless the application name or the data file extensions are in a known list, they won't be seen. But my work has been in the realm of civil suits, contract disputes, SEC claims, and the like; the investigators might be more thorough when trying to nail someone for kiddie porn.) Or use another app which by the way has crypto. Winzip apparently has some implementation flaws (http://www.cse.ucsd.edu/users/tkohno/papers/WinZip/ ) but a quick google doesn't show anything but brute force and dictionary attacks against WinRar. -- There are no bad teachers, only defective children. - 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: The false positive I was referring to is the something is telling me something unimportant positive. I didn't mean to infer that the users likely went through a thought process centered around the possible causes of the certificate failure, specifically the likelihood of an active man-in-the- middle vs. software bug, vs. setup error, vs. etc.. Oh, I see. So we were actually in violent agreement :-). I've probably seen hundreds of signature validation warnings from various web-sites for certificates and Active-X and possibly other signed content. I can't recall needing to heed even one of the warnings. We are trying to detect man-in-the-middle or outright spoofing with signatures and our false positive rate is through the roof. The false positive rate must be zero or nearly zero to work as a useful detector in real world situations. It's not just passive false-positive acceptance, users are actively encouraged by software vendors to accept verification-failed content. For example every other hardware device you install, as part of it's connect-the-dots sequence of screen shots in the install guide, shows a shot of some sort of signature- warning dialog, along with an arrow pointing to the Ignore this warning button to click and text telling users to, well, do what the button says. Even things like WHQL-certified drivers, which should have all the correct credentials, end up being installed in non-certified ways because the vendors submit a safe-but-slow configuration to get certified and then ship the unsafe-but-fast one to be installed (this is standard practice for any hardware where performance is the main selling point, i.e. video drivers, RAID drivers, network drivers, etc etc). Alternatively, the latest bugfix drivers are several steps ahead of the certified WHQL'd ones, so you get the same thing. For non-Windows users who haven't seen this sort of user-conditioning in documentation, here's the first half-dozen online examples of this (to save me having to scan install guides to demonstrate it): http://www.msha.gov/TECHSUPP/ACC/shortcircuit/install.htm http://support.academic.com/knowbase/root/public/acdm9103.htm http://mail.regent-college.edu/wireless/printer/w98/ http://home.cfl.rr.com/dogone/Download.htm http://129.171.91.6/firewall/InstallConfig/msie_instruction.cfm http://www.rochester.edu/its/wireless/win_IE_certificate.html Note also that the warnings for valid and invalid signed content are extremely similar, and both contain lots of text, jargon, and incomprehensible (to the average user) information. Both in effect state Mumble mutter fnord fnord, do you want to go ahead, with the fnord-level for the valid-signature dialog being at least as high as the invalid-signature one. It'd be interesting to see if users can tell the difference between the two. This one is particularly cool: Don't get worried by the JPilot Security Warning! Just click YES to install run applet. If you don't, you can't chat!: http://mc2.vicnet.net.au/help/chathelp.html (Don't worry about those nasty warnings, just close your eyes and click your heels tog^H^H^H^Hclick OK). Just to show that it's not just ActiveX signing under Windows that's training users in this manner, here's a Unix one too: http://apps.cybersource.com/library/documentation/dev_guides/Microsoft_Commerce_Server_2002/html/install.htm Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Collisions for hash functions: how to exlain them to your boss
Magnus Daum and myself have generated MD5-collisons for PostScript files: http://th.informatik.uni-mannheim.de/people/lucks/HashCollisions/ This work is somewhat similar to the work from Mikle and Kaminsky, except that our colliding files are not executables, but real documents. We hope to demonstrate how serious hash function collisions should be taken -- even for people without much technical background. And to help you, to explain these issues - to your boss or your management, - to your customers, - to your children ... Have fun Stefan -- Stefan Lucks Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany e-mail: [EMAIL PROTECTED] home: http://th.informatik.uni-mannheim.de/people/lucks/ -- I love the taste of Cryptanalysis in the morning! -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
On Wednesday 01 June 2005 23:38, Anne Lynn Wheeler wrote: in theory, the KISS part of SSL's countermeasure for MITM-attack ... is does the URL you entered match the URL in the provided certificate. An attack is inducing a fraudulent URL to be entered for which the attackers have a valid certificates. Firefox have added a cert domain into the status bar on the bottom of the browser. This is part way to what you suggest and a very welcome improvement to browser security. It falls short for (IMHO) 3 reasons: 1. the domain that is shown isn't the certificate domain, but is something amalgamated from the URL and the cert; which then breaks the independent check you are hoping for above. 2., the CA should be listed so as to complete the security statement. Something like ThisCA signed the This.Domain.Com cert. This is done in the Mouseover, but not displayed all the time, and it is possible to get a Mouseover that shows a statement that is strictly false because of 1. above. (Bugs filed and all the rest...) 3. Another issue is that it is not big enough nor loud enough in the Trustbar sense to break through the current user teachings that they can ignore everything as its all safe. Rather than complex defense in depth ... all with cracks and vulnerabilities that attackers can wiggle around ... a better approach would be KISS solution that had integrated approach to existing systemic vulnerabilities. For instance, some sort of clear, un-obfuscated indications integrated with URL selection that can leverage the existing SSL MITM-attack countermeasures. Yes, this would be a much better way forward. Now, bear in mind that the people writing the plugins would give their left legs to get the attention and respect of the browser manufacturers so as to create this integrated solution. See various other rants... The downside of a KISS integrated solution that eliminates existing systemic problems (and avoids creating complex layers, each with their individual cracks that the attackers can wiggle thru) ... is that the only current special interest for such a solution seems to be the victims. Some sort of fix that allows naive users to relate and enter specific trusted URLs associated with specific tasks could fix many of the existing infrastructure vulnerabilities. The issue is what institutions have financial interest in designing, implementing, and marketing such a likely free add-on to existing mostly free based infrastructure. It appears to be much easier justify the design, implementation and marketing of a totally new feature that can be separately charge for. This will change,. I predict that the banks will end up with the liability for phishing, for good or for bad, and they will then find it in their hearts to finance the add-ons, which will battle it out, thus leading to the 'best practices' which will be incorporated into the browsers. (Seeing as this is prediction time, I'll stick my neck out another several kms and say it will be in about 6 months that the banks are asked to take on the liability.) 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: SSL stops credit card sniffing is a correlation/causality myth
Adam Shostack wrote: So, that may be the case when you're dealing with an SSL accelerator, but there are lots of other cases, say, implementing daabase security rules, or ensuring that non-transactional lookups are logged, which are harder to argue for, take more time and energy to implement, and may well entail not implementing customer-visible features to get them in on budget. Choicepoint and Lexis Nexis seemingly, had neither. Nor are they representational. We lack good data, and while there are a few hundred folks who have the experience, chops, and savvy to help their customers make good decisions, there are tens of thousands of companies, many of whom choose not to pay rates for that sort of advice, and hire an MCSE, instead. People who slap the label best practice on log truncation. I think that we need to promulgate the idea that Choicepoint is creating a shift, that it will be ok to talk about breaches, with the intent of getting better data over time. we got brought in to work on some word smithing for both the cal. state and the fed. digital signature legislation (we somewhat concentrated on the distinction between digital signature authentication and that human signature implies read, understands, agrees, approves, authorizes, etc which isn't present in simple authentication). one of the industry groups that was active in the effort had done some extensive surveys on driving factors behind various kinds of regulatory and legislative actions. with regard to privacy regulatory/legislative actions ... the two main driving factors were 1) identity theft and 2) effectively institutional (gov, commercial, etc) denial of service. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Clips] Storm Brews Over Encryption 'Safe Harbor' in Data Breach Bills
--- begin forwarded text Date: Thu, 2 Jun 2005 14:18:42 -0400 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: [Clips] Storm Brews Over Encryption 'Safe Harbor' in Data Breach Bills Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] http://www.eweek.com/print_article2/0,2533,a=153008,00.asp EWeek Storm Brews Over Encryption 'Safe Harbor' in Data Breach Bills May 31, 2005 By Caron Carlson Spurred by the ongoing flood of sensitive data breaches this spring, nearly a dozen states may have breach notification laws on their books by summer. In turn, makers of security software and companies in several other industries are pressuring Capitol Hill for a federal law pre-empting the states' measures. In Congress, more than a half-dozen bills requiring a range of data security measures and breach notification rules are pending, and at least two more are slated for introduction in coming months. These measures-including one under consideration by Rep. Cliff Stearns, R-Fla., and one in the draft stages by Rep. Deborah Pryce, R-Ohio-illustrate one of the most contentious questions in the debate: Should there be a notification exemption for businesses that encrypt their data? Not surprisingly, industries for the most part are pushing for an encryption exemption to notification, a safe harbor that is included in California SB (Senate Bill) 1386, a notification law that went into effect in July 2003. The growing security software industry, a major ally in this effort, is trying to convince lawmakers that when encrypted data is stolen, the theft poses no meaningful harm to consumers. If the data is encrypted, it's gibberish. They don't know what it is. They can't use it, said Dan Burton, vice president of government affairs for Entrust Inc. Read more here about the theft of MCI data and its effect on the debate over encryption. Some data security experts contend, however, that an encryption safe harbor could reduce data holders' incentives to implement strong protective measures in the first place. Criticizing the California notification law, Bruce Schneier, chief technology officer at Counterpane Internet Security Inc., of Mountain View, Calif., said it lets data holders bypass disclosure without necessarily protecting the data. You can encrypt the data with a trivial algorithm and get around [the law], Schneier said. If you can get around a law by doing something stupid, it's a badly written law. Entrust supports an encryption exemption to notification but not without other security requirements, said Chris Voice, CTO at the Addison, Texas, company. Like any technological approach, it's going to require more than just encrypting the data, Voice said. I think security controls will have to be in place regardless. Click here to read about anti-spyware bills moving to the Senate. Even strong encryption theoretically can be broken, but it requires resources and effort that thieves are highly unlikely to expend, advocates of the safe harbor argue. That argument does not appease consumer representatives. We may not be comfortable having our information out there, even in gibberish format, said Susanna Montezemolo, policy analyst at the Consumers Union, in Washington. Encryption shouldn't be the issue. We shouldn't have to define potential harm and risk. Acknowledging the political influence of the industries lobbying for the safe harbor, however, Montezemolo said that a breach notification law with a safe harbor is better than no law at all but that the safe harbor must be narrowly tailored so as not to be an excuse for shoddy security. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' ___ Clips mailing list [EMAIL PROTECTED] http://www.philodox.com/mailman/listinfo/clips --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Storm Brews Over Encryption 'Safe Harbor' in Data Breach Bills
On Thursday 02 June 2005 19:28, R.A. Hettinga wrote: http://www.eweek.com/print_article2/0,2533,a=153008,00.asp Storm Brews Over Encryption 'Safe Harbor' in Data Breach Bills May 31, 2005 Just to make it more interesting, the AG of New York, Elliot Spitzer has introduced a package of legislation intended to rein in identity theft including: Facilitating prosecutions against computer hackers by creating specific criminal penalties for the use of encryption to conceal a crime, to conceal the identity of another person who commits a crime, or to disrupt the normal operation of a computer; Full PR is here: https://www.financialcryptography.com/mt/archives/000449.html I'm hoping this was a trial balloon. 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]
Cell phone crypto aims to baffle eavesdroppers
Cell phone crypto aims to baffle eavesdroppers By Munir Kotadia, ZDNet Australia Published on ZDNet News: May 31, 2005, 4:10 PM PT An Australian company last week launched a security tool for GSM mobile phones that encrypts transmissions to avoid eavesdroppers. GSM, or Global System for Mobile Communications, is one of the most popular mobile phone standards and is built to provide a basic level of security. However, for more than five years the security has been cracked, and commercial scanners that can emulate GSM base stations are becoming more common. That prompted Melbourne-based SecureGSM to launch its encryption tool at the CeBit exhibition in Sydney last week. Roman Korolik, managing director of SecureGSM, said that because GSM security was cracked so long ago, there was a lot of information and equipment available that could be used for intercepting GSM calls. There are devices available for interception and decoding (GSM calls) in real time...Although they are, strictly speaking, illegal in most countries, you can buy them, said Korolik, who believes that these scanners are already being used to intercept sensitive calls. You can imagine that in places like the stock exchange, where the traders are on their mobile phones...there could be a few scanners there. As far back as 1999, the security used by GSM has been questioned. In a paper published by Lauri Pesonen from the Department of Computer Science and Engineering at Helsinki University of Technology, the GSM model was said to have been broken on many levels. The GSM security model is broken on many levels and is thus vulnerable to numerous attacks targeted at different parts of an operator's network...If somebody wants to intercept a GSM call, he can do so. It cannot be assumed that the GSM security model provides any kind of security against a dedicated attacker, Pesonen wrote in the paper. However, additional GSM security is unlikely to be used by the masses, according to Neil Campbell, national security manager of IT services company Dimension Data, who said companies are likely to have higher priorities. This is a security control like any other control--like a firewall or a policy. An organization needs to believe it is appropriate for their risks to implement this control. Obviously the military is one that you would expect to have a need for secure communications, but I wouldn't expect there to be too many organizations in this country that would think it necessary to encrypt their mobile phone conversations, said Campbell. SecureGSM requires Windows Mobile Phone Edition http://news.zdnet.com/2100-1040_22-5697127.html?tag=nl with an ARM or compatible processor running at 200MHz or better. It also requires 6Mb of RAM (random access memory) and 2MB of storage space. The SecureGSM application uses 256-bit, triple cipher, layered encryption based on AES, Twofish and Serpent ciphers. According to SecureGSM, all of these algorithms are considered unbreakable and the triple layer ensures that encrypted data is future proof. The product costs $188 (AU$249) for a single-user license, and each secure device requires a license. Dimension Data's Campbell said that companies thinking about implementing such a solution will need to calculate how much they could lose if their communications were intercepted. Share traders may need it, but this is for an organization that communicates by mobile telephone and understands that the risk of interception is generally extremely low, but that risk is completely unacceptable, Campbell said. Munir Kotadia of ZDNet Australia reported from Sydney Copyright ©2005 CNET Networks, Inc. All Rights Reserved. http://news.zdnet.com/2100-1009_22-5726814.html -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Clips] Paying Extra for Faster Airport Security
--- begin forwarded text Date: Thu, 2 Jun 2005 20:40:26 -0400 To: Philodox Clips List [EMAIL PROTECTED] From: R.A. Hettinga [EMAIL PROTECTED] Subject: [Clips] Paying Extra for Faster Airport Security Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Security needs identity like a fish needs... well, you get the idea... Cheers, RAH --- http://online.wsj.com/article_print/0,,SB111767537888648936,00.html The Wall Street Journal June 2, 2005 Paying Extra for Faster Airport Security Orlando Kicks Off Program Offering Quicker Screenings To Holders of Special Cards By AVERY JOHNSON Staff Reporter of THE WALL STREET JOURNAL June 2, 2005; Page D3 Starting this month, air travelers in Orlando, Fla., can pay for a high-tech card that promises to whisk them through the airport's security lines. Under the program, travelers who use Orlando International Airport and are willing to pay a $79.95 annual fee will be able to register for a government security screening, which includes fingerprints, iris scans, as well as an application that asks for basic identity information. Travelers who pass the screening -- and who will be subject to continuing checks against government watch lists -- will then receive a special card that permits them to use an express lane through airport security. That lane expedites the screening process and frees cardholders from secondary searches. The program will be operated by New York-based Verified Identity Pass Inc., a private company run by Steven Brill, whose former ventures included Court TV and The American Lawyer magazine. The program marks the first time a private company has teamed up with the government to speed up airport security lines. Yesterday, the Greater Orlando Aviation Authority board awarded the contract for its new system to Verified Identity Pass's system, opting for its prospectus over a proposal from Unisys Corp. Enrollment will start June 21, and the company hopes to open a lane for card holders as early as next month. The card will initially be good only at the Orlando airport. The proposal says that in the second and third years of the program, prices could climb by about $10 annually. Orlando International is Florida's busiest airport, handling more than 31 million passengers last year. Other airports and the Transportation Security Administration -- the government office in charge of safeguarding transportation -- are watching closely. After launching a similar, though smaller, test program for frequent fliers in five airports last summer, the TSA is evaluating future private-public partnerships depending on how the Orlando system works. Other airports say they are studying the system and could submit their own proposals to the TSA soon. In its initial phase, the program in Orlando will accept as many as 30,000 travelers. Membership is open to anyone who clears the government watch lists and is willing to pay. Most of the process of signing up takes place online at www.Flyclear.com, but travelers still need to come into the airport to get their iris images and fingerprints taken. The TSA's own expedited checkpoint system, called the Registered Traveler pilot program, is capped at 10,000 members and is available only to frequent fliers who are invited by participating airlines. Signing up requires thumb and index fingerprints, as well as paperwork and an iris scan at the airports in Minneapolis, Houston, Boston, Washington's Reagan airport and Los Angeles. The 10,000 people continue to be members for as long as the program runs, and the TSA says it hasn't any plans to expand the group of either passengers or participating airports in the near future. Mr. Brill's program, though, expects to be able to synch up with the five airports in the government's system in the fall. Programs like these, as well as the TSA's Registered Traveler plan, have been slow to get started. The Orlando program was initially expected to launch in May, but got greenlighted yesterday. The rival Unisys proposal had suggested linking up the card with a debit card for shopping, would cost about $100 a year and said it would offer immediate use in the five participating TSA airports. The fast-lane system has been hampered by concerns about privacy and the safety of personal information, as well as synchronized systems run by different companies at different airports. Tim Sparapani, the legislative counsel for privacy rights at the American Civil Liberties Union, says that at least the government screeners are held accountable to privacy laws -- he takes issue with outsourcing the management of sensitive data such as fingerprints to for-profit companies. Mr. Brill says his system won on its pricing and privacy policies. It gives customers guarantees about the safety of their personal information by issuing a warranty for any breaches. In addition, the card doesn't track movement -- it doesn't know where its members are at any given time, or what their final
