Re: Maybe It's Snake Oil All the Way Down
I thought the 3G (UMTS) cellphones at least were going to use reasonably good crypto; don't know about the overall security architecture though. Jaap-Henk On Fri, 06 Jun 2003 14:30:04 -0400 Ian Grigg <[EMAIL PROTECTED]> writes: > John Kelsey wrote: > >> So, what can I do about it, as an individual? Make the cellphone companies >> build good crypto into their systems? Any ideas how to do that? > > Nope. Cellphone companies are big slow moving > targets. They get their franchise from the > government. If the NSA wants weak crypto, they > do weak crypto. -- Jaap-Henk Hoepman | I've got sunshine in my pockets Dept. of Computer Science | Brought it back to spray the day University of Nijmegen |Gry "Rocket" (w) www.cs.kun.nl/~jhh | (m) [EMAIL PROTECTED] (t) +31 24 36 52710/531532 | (f) +31 24 3653137
Re: An attack on paypal
At 11:43 PM 6/8/2003 +0100, Dave Howe wrote: >HTTPS works just fine. >The problem is - people are broken. >At the very least, verisign should say "ok so '..go1d..' is a valid server >address, but doesn't it look suspiously similar to this '..gold..' site over >here?" for https://pseudo-gold-site/ - but really, if users are going to >fill in random webforms sent by email, they aren't going to be safe under >any circumstances; the thing could send by unsecured http to any site on the >planet, then redirect to the real gold site for a generic "transaction >completed" or even "failed" screen >A world where a random paypal hack like this one doesn't work is the same as >the world where there is no point sending out a Nigerian as you will never >make a penny on it - and yet, Nigerian is still profitable for the con >artists. in a world where there are repeated human mistakes/failures at some point it is recognized that people aren't perfect and the design is changed to accommodate peoples foibles. in some respects that is what helmets, seat belts, and air bags have been about. in the past systems have designed long, complicated passwords that are hard to remember and must be changed every month. that almost worked when i person had to deal with a single shared-secret. when it became a fact of life that a person might have tens of such different interfaces it became impossible. It wasn't the fault of any specific institution, it was a failure of humans being able to deal with large numbers of extremely complex, frequently changing passwords. Because of known human foibles, it might be a good idea to start shifting from an infrastructure with large numbers of shared-secrets to a non-shared-secret paradigm. at a recent cybersecurity conference, somebody made the statement that (of the current outsider, internet exploits, approximately 1/3rd are buffer overflows, 1/3rd are network traffic containing virus that infects a machine because of automatic scripting, and 1/3 are social engineering (convince somebody to divulge information). As far as I know, evesdropping on network traffic doesn't even show as a blip on the radar screen. In the following thread on a financial authentication white paper: http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper there is point made that X9.59 standard doesn't directly address the Privacy aspect of security (i.e. no encryption or hiding of data). However, the point is made that it changes the paradigm so that the financial account number no longer represents a shared-secret and that it can be supported with two-factor authentication i.e. "something you have" token and "something you know" PIN. The "something you know" PIN is used to enable the token, but is not a shared secret. Furthermore, strong authentication can be justification for eliminating the need for name or other identification information in the transaction. However, if X9.59 strong authentication is used with two-factor authentication and no identification information is necessary then it would make people more suspicious if privacy information was requested. Also, since privacy information is no longer sufficient for performing a fraudulent transaction, it might mitigate that kind of social engineering attack. The types of social engineering attacks then become convincing people to insert their hardware token and do really questionable things or mailing somebody their existing hardware token along with the valid pin (possibly as part of an exchange for replacement). The cost/benefit ratio does start to change since there is now much more work on the crooks part for the same or less gain. One could also claim that such activities are just part of child-proofing the environment (even for adults). On the other hand, it could be taken as analogous to designing systems to handle observed failure modes (even when the failures are human and not hardware or software). Misc. identify theft and credit card fraud reference: http://www.consumer.gov/idtheft/cases.htm http://www.usdoj.gov/criminal/fraud/idtheft.html http://www.garlic.com/~lynn/aadsm14.htm#22 Identity Theft Losses Expect to hit $2 trillion http://www.garlic.com/~lynn/subpubkey.html#fraud Slightly related in recent thread that brought up buffer overflow exploits http://www.garlic.com/~lynn/2003j.html#4 A Dark Day and the report that multics hasn't ever had a buffer overflow exploit http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation somebody (else) commented (in the thread) that anybody that
Re: An attack on paypal
James A. Donald wrote: > Attached is a spam mail that constitutes an attack on paypal similar > in effect and method to man in the middle. > > The bottom line is that https just is not working. Its broken. HTTPS works just fine. The problem is - people are broken. At the very least, verisign should say "ok so '..go1d..' is a valid server address, but doesn't it look suspiously similar to this '..gold..' site over here?" for https://pseudo-gold-site/ - but really, if users are going to fill in random webforms sent by email, they aren't going to be safe under any circumstances; the thing could send by unsecured http to any site on the planet, then redirect to the real gold site for a generic "transaction completed" or even "failed" screen A world where a random paypal hack like this one doesn't work is the same as the world where there is no point sending out a Nigerian as you will never make a penny on it - and yet, Nigerian is still profitable for the con artists.
You bought it, Who controls it? [TR Article]
article by Edward Tenner, Technology review, June 2003 p61-64 Also an article on "deceipt detector" p67-69 about using IR reflectivity of your frontal lobes to detect deceipt. Sort of a polygraph on steroids. (sorry, only cites, not URLs this time)
CIA spies shun computers
Old technology dominates at the CIA In the movies, spies and intelligence agents are the ones with the cool gadgets and state-of-the-art equipment, but their real life counterparts are far behind. http://news.bbc.co.uk/2/hi/technology/2965620.stm "A Jobless Recovery is like a Breadless Sandwich." -- Steve Schear
The real problem that https has conspicuously failed to fix
I keep posting "you cannot do this using https", and people keep = replying "yes you can" No you cannot, cause if you could, paypal, e-gold, e-bay, and the rest = would not be suffering from the problem illustrated by scam mails such = as the following (When you hit the submit button, guess what happens) =20 =20 =20 Dear PayPal Customer=20 This e-mail is the notification of recent innovations taken by = PayPal to detect inactive customers and non-functioning mailboxes. The inactive customers are subject to restriction and removal in = the next 3 months. Please confirm your email address and Credit or Check Card = information using the form below: =20 Email Address: =20 Password: =20 First Name: =20 Last Name: =20 ZIP: =20 Credit or Check Card #: =20 Expiration Date: Month 01 02 03 04 05 06 07 08 09 10 11 12 / Year 2003 = 2004 2005 2006 2007 2008 2009 2010 2011 2012 =20 ATM PIN: =20 =20 Information transmitted using 128bit SSL encryption.=20 =20 =20 Thanks for using PayPal!=20 =20 =20 This PayPal notification was sent to this email address because = you are a Web Accept user and chose to receive the PayPal Periodical = newsletter and Product Updates. To modify your notification preferences, = go to https://www.paypal.com/PREFS-NOTI and log in to your account. = Changes may take several days to be reflected in our mailings. Replies = to this email will not be processed. =20 Copyright=A9 2003 PayPal Inc. All rights reserved. Designated = trademarks and brands are the property of their respective owners. =20 [demime 0.97c removed an attachment of type image/gif which had a name of paypal_logo.gif] [demime 0.97c removed an attachment of type image/gif which had a name of pixel.gif] [demime 0.97c removed an attachment of type image/gif which had a name of dot_row_long.gif]
Re: Maybe It's Snake Oil All the Way Down
Rich Salz wrote: Perhaps a few "best practices" papers are in order. They might help the secure (distributed) computing field a great deal. /r$ -- The new book, Practical Cryptography, by Niels Ferguson and Bruce Schneier is useful. regards, Frederick
Re: An attack on paypal
At 02:55 PM 6/8/2003, James A. Donald wrote: Attached is a spam mail that constitutes an attack on paypal similar in effect and method to man in the middle. The bottom line is that https just is not working. Its broken. The fact that people keep using shared secrets is a symptom of https not working. The flaw in https is that you cannot operate the business and trust model using https that you can with shared secrets. I don't think it's https that's broken, since https wasn't intended to solve the customer authentication / authorization problem (you could try to use SSL's client certificates for that, but no one ever intended client certificate authentication to be a generalized transaction problem). When I responded to this before, I thought you were talking about the server auth problem, not the password problem. I continue to feel that the server authentication problem is a very hard problem to solve, since there's few hints to the browser as to what the user's intent is. The password problem does need to be solved, but complaining that HTTPS or SSL doesn't solve it isn't any more relevant than complaining that it's not solved by HTML, HTTP, and/or browser or server implementations, since any and all of these are needed in producing a new solution which can function with real businesses and real users. Let's face it, passwords are so deeply ingrained into people's lives that nothing which is more complex in any way than passwords is going to have broad acceptance, and any consumer-driven company is going to consider "easy" to be more important that "secure". Right now, my best idea for solving this problem is to: - Standardize an HTML input method for which does an SPEKE (or similar) mutual authentication. - Get browser makers to design better ways to communicate to users that UI elements can be trusted. For example, a proposal I saw recently which would have the OS decorate the borders of "trusted" windows with facts or images that an attacker wouldn't be able to predict: the name of your dog, or whatever. (Sorry, can't locate a link right now, but I'd appreciate one.) - Combine the two to allow sites to provide a user-trustable UI to enter a password which cannot be sucked down. - Evangelize to users that this is better and that they should be suspicious of any situation where they used such interface once, but now it's gone. I agree that the overall architecture is broken; the problem is that it's broken in more ways than can just be fixed with any change to TLS/SSL or HTTPS. - Tim
Re: Maybe It's Snake Oil All the Way Down
At 04:42 PM 6/4/2003 -0700, Eric Rescorla wrote: >Nonsense. One can simply cache the certificate, exactly as >one does with SSH. In fact, Mozilla at least does exactly >this if you tell it to. The reason that this is uncommon >is because the environments where HTTPS is used >are generally spontaneous and therefore certificate caching >is less useful. there are actually two scenarios one is to pre-cache it (so that its transmission never actually has to happen) and the other is to compress it to zero bytes. detailed discussion of certificate pre-caching and certificate zero byte compression: http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 the typical use for HTTPS for e-commerce is to hide the account number on its way to the financial institution. for the most part the merchant is primarily interested in the response from the consumer's financial institution on whether or not the merchant gets paid. If it weren't for the associated business processes, the merchant could get by with never knowing anything at all about the consumer (the merchant just passes the account number on ... and gets back what they are really interested in the notification from the bank that they will get paid). So a HTTPS type solution is that the consumer pre-caches their bank's certificate (when they establish a bank account). and they transmit the account number "hidden" using the bank's public key. This happens to pass thru the merchants processing but for purposes of the authorization, the merchant never really has to see it. The protocol would require minor issues of replay attacks and be able to be done in a single round trip w/o all the SSL protocol chatter. Actually, is isn't so much pre-caching their bank's certificate as loading their bank's public key into a table analogous to the way CA public keys are loading into tables (aka using out-of-band processing the convention that they may be self-signed and encoded in a certificate format is an anomoly of available software and in no way implies a PKI). The primary purpose of HTTPS hasn't been to have a secure channel with the merchant, the primary purpose of the HTTPS is to try and hide the consumer's account number as it makes its way to the consumer's financial institution. The other solution is the X9.59 standard (preserve the integrity of the financial infrastructure for all electronic retail payments, not just internet, not just POS, not just credit, ALL; credit, debit, stored value, etc) that creates authenticated transactions and account numbers that can only be used in authenticated transaction. The consumer's public key is registered in their bank account (out of band process, again no PKI). X9.59 transactions are signed and transmitted. Since the account number can only be used in authenticated transactions it changes from needing encryption to hide the value as part of a shared-secret paradigm to purely a paradigm that supports integrity and authentication. As in the above, scenario, the merchant passes the value thru on its way to the consumer's financial institution; and is focused on getting the approved/disapproved answer back about whether they will be paid. As in the bank HTTPS scenario where the bank's pubilc key is pre-cached at the consumer, the pre-caching of the consumer's public key is pre-cached at the bank involves no PKI business processes (although their may be some similarities that the transport of the public key involves encoding in a certificate defined format). misc. x9.59 refs: http://www.garlic.com/~lynn/index.html#x959 Both pre-caching solutions are between the business entities that are directly involved; the consumer and the consumer's financial institution based on having an established business relationship. The invention of PKI was primarily to address the issue of an event between two parties that had no prior business relationship and possibly weren't going to have any future business relationship and that they would conclude their business relying on some mutual trust in the integrity of a 3rd party w/o actually having to resort to an online environment. The e-commerce scenario is that there is real-time, online transaction with the trusted 3rd party (the consumer's financial institution) involving prior business relationship. This negates the basic original assumptions about the environment that PKIs are targeted at addressing. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Re: SIGINT planes vs. radioisotope mapping
From: "Tim May" <[EMAIL PROTECTED]> > I certainly never implied in any way that a simple G-M tube would be > useful for this. Implicit in my radioistope mapping comment was that a > gamma ray spectrometer would be used. > The rest of the assembly, even 20 years ago, was mostly portable: the > germanium detector head, some preamps and pulse-height analyzers, and a > multichannel analyzer. Most of this stuff is now done on laptops, the > MCA and analysis software part. Without researching this on the Net, I > would thus conjecture the entire gamma ray spectrometer could fit in a > small carry-on case, using a small dewar. http://www.giscogeo.com/pages/radgf260.html DIMENSIONS AND WEIGHT: 27x13x18 cm, 2.8 kg There's a bunch more http://www.alltheweb.com/search?cat=web&cs=utf-8&type=phrase&q=portable%20gamma%20ray%20spectrometer%20
Re: Maybe It's Snake Oil All the Way Down
John Kelsey wrote: > So, what can I do about it, as an individual? Make the cellphone companies > build good crypto into their systems? Any ideas how to do that? Nope. Cellphone companies are big slow moving targets. They get their franchise from the government. If the NSA wants weak crypto, they do weak crypto. There is literally no point in hoping the cell phone company - or any large franchise holder - will help you in your fight against big brother. OTOH, what you can do is argue for reasonable crypto. (Similar to GSM's. That is hard to attack, there is AFAIR no 'trival' attack, you have to get access to the SIM or you have to probe the phone with another phone over a period of hours. I.e., the attacker leaves tracks, and he does so in a way that will move him on to another mode of tapping, such as purchasing a straight listening device.) Now, it seems that the US standards didn't get even that. There's definately a case for arguing for better crypto in the US. And, market forces and all that, one would think that this would happen in due course. But arguing for strong crypto end-to-end - save your breath. John Kelsey (paraphrased): > The only way I can see getting decent security [in any application] is to do > something that doesn't require the rest of the world's permission or > assistance. (I edited the above to broaden the assert!) Opportunistic crypto - that which uses the tools immediately available and delivers crypto that is the best available right now - is the only crypto that will work for *you* the user in any application. Anything that defers security off to some external party has a result of slowing or killing the application, or delivering less or no security than if you'd gone ahead in the first place. This isn't saying anything new. It's the Internet, after all. On the Internet, one doesn't ask for permission to participate. That's no accident, it's a core reason for its arisal. Any protocol that has a step of "now ask for permission" is, IMHO, breaking one of the major principles of the Internet. > ... I > have an old Comsec 3DES phone at home. It's nice technology. I think I've > used it twice. If you're not a cryptographer or a cocaine smuggler, you > probably don't know anyone who owns an encrypting phone or would > particularly want to. Even if you'd like to improve your own privacy, you > can't buy an end-to-end encrypting phone and improve it much. That's what > I'd like to see change. I guess there's no reason why you couldn't load up speakfreely on a custom Unix box with a flashed OS, put in the USB headset, and sell it as an end to end encrypting phone. The software's all free, a cheap machine is $300 at Walmart, some enterprising crypto guy could ship out a network appliance for $500. (Or, put it in a PDA that's got the right hooks?) Half the price of your old Comsec, wasn't it selling for $1000? -- iang
Re: Maybe It's Snake Oil All the Way Down
At 10:09 PM 6/4/2003, James A. Donald wrote: Eric Rescorla > Nonsense. One can simply cache the certificate, exactly as > one does with SSH. In fact, Mozilla at least does exactly > this if you tell it to. The reason that this is uncommon is > because the environments where HTTPS is used are generally > spontaneous and therefore certificate caching is less useful. Certificate caching is not the problem that needs solving. The problem is all this spam attempting to fool people into logging in to fake BofA websites and fake e-gold websites, to steal their passwords or credit card numbers I don't think this problem is easier to solve (or at least I sure don't know how to solve it). It seems to me that you could tell a user every time they go to a new site that it's a new site, and hope that users would recognize that e-g0ld.com shouldn't be "new", since they've been there before. However, people go to a large enough number of sites that they'd be seeing the "new" alert all the time, which leads me to believe that it wouldn't be taken seriously. Fundamentally, making sure that people's perception of the identity of a web site matches the true identity of the web site has a technical component that is, at most, a small fraction of the problem and solution. Most of it is the social question of what it means for the identity to match and the UI problem of determining the user's intent (hard one, that), and/or allowing the user to easily and reliably match their intent against the "reality" of the true "identity". Any problem that has as a component the fact that the glyphs for "lower-case L" and "one" look pretty similar isn't going to be easy to solve technologically. - Tim
Re: Maybe It's Snake Oil All the Way Down
[EMAIL PROTECTED] (Peter Gutmann) writes: > Bodo Moeller <[EMAIL PROTECTED]> writes: > > >Using an explicit state machine helps to get code suitable for multiplexing > >within a single thread various connections using non-blocking I/O. > > Is there some specific advantage here, or is it an academic exercise? Some > quirk of supporting certain types of hardware like nCipher boxes that do async > crypto/scatter-gather? I've had to do this on environments where threads weren't a viable option. See, for instance, my paper from USENIX Security 2002. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/
