Re: EZ Pass and the fast lane ....
Date: Fri, 2 Jul 2004 21:34:20 -0400 From: Dave Emery [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: EZ Pass and the fast lane No mention is made of encryption or challenge response authentication but I guess that may or may not be part of the design (one would think it had better be, as picking off the ESN should be duck soup with suitable gear if not encrypted). From a business perspective, it makes no sense to spend any money on crypto for this application. If it is free, sure use it, but if not, then worry about the 0.01% of users who fiddle the system later on. It would be relatively easy to catch someone doing this - just cross-correlate with other information (address of home and work) and then photograph the car at the on-ramp. If the end result isn't as shown through other means, then you have the evidence. One high profile court case later, and the chances of anyone copying this to escape a toll fare shrink into the ignorable. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Can crypto help against Phishing, Spoofing and Spamming...
Reminder: following lots of discussion on this list, I wrote proposals on how crypto can help solve phishing, spoofing and spamming problems. Apparently few had problems downloading the PDF files from our (BIU) site. so I've put both papers in ecrypt (which I believe is more reliable), and also, I've put HTML version in our site. So, I apologize for the inconvenience if you tried before and got nothing, but these links should work fine, and I am very interested in your feedback: # Protecting (even) Naïve Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites, at http://eprint.iacr.org/2004/155/ and http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/Spam.htm # Controlling Spam by Secure Internet Content Selection, at http://eprint.iacr.org/2004/154/ and http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/Spam.htm -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com version:2.1 end:vcard
Re: Question on the state of the security industry (second half not necessarily on topic)
On Jul 3, 2004, at 14:22, Dave Howe wrote: Well if nothing else, it is impossible for my bank to send me anything I would believe via email now To take this even slightly more on-topic - does anyone here have a bank capable of authenticating themselves to you when they ring you? I have had four phone calls from my bank this year, all of which start out by asking me to identify myself to them. When I point out that they must know who I am - as they just phoned me - and that I have no way of knowing who they are, they are completely lost (probably takes them away from the little paper script pinned to their desk) Last month I had a rather good experience with American Express in this regard. I recently moved and had ordered something to be shipped to my new address (this was before I changed my billing address with AMEX). Apparently the merchant had Amex verify the transaction, and so AMEX called me. Naturally, I asked how I was supposed to know it was really them calling. Without missing a beat, the caller invited me to hang up and call back the number on the back of my card, which I did. After the usual exchange of information to establish my identity, I was transferred to the right department, and ended up speaking with the same person who had originally called me(!). After confirming the validity of the transaction in question, I asked how many people are as suspicious as I was in asking for confirmation that it's really AMEX calling. He said not many, but a significant enough number that they're ready to handle it routinely when it happens (he also congratulated me for my diligence). It's nice that they have a procedure for this, but it's still a mixed success for security against the theft of sensitive personal information. People like me (us?) remain the exception rather than the rule, and while it's comforting that the standard procedures accommodate us, the vast majority of people appear to happily give any information requested to whoever calls them. And when banks and credit card issuers make calls requesting sensitive information as part of their routine operations, they're training their customers to engage in exactly the same behavior that they should be trying to discourage. Perhaps a better procedure would be to always simply ask the customer to call back the known, trusted contact number (e.g., as printed on the card), and never ask for any personal or sensitive information in an unsolicited call. They could widely advertise that this is always the procedure and ask customers to be alert for any caller who deviates from it. -matt - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
At 10:40 AM 7/7/2004, Hal Finney wrote: SET failed due to the complexity of distributing the software and setting up the credentials. I think another reason was the go-fast atmosphere of the late 90s, where no one wanted to slow down the growth of ecommerce. The path of least resistance was simply to bring across the old way of authorizing transactions by card number. both SET SSL encrypted data in transit. an issue is that SET is significantly more complex and provided no additional countermeasure (vis-a-vis SSL) against major remaining exploits like harvesting the merchant transaction file while at rest. there was some issue that SSL was the incumbent ... so SET had to demonstrate significant better ROI to displace it ... rather than significantly higher I with little or no additional R. some SSL: http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 the security proportional to risk reference (using merchant transaction file as example) http://www.garlic.com/~lynn/2001h.html#61 couple minor past refs related to SET business operations http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards another SET issue was that it took a typical ISO 8583 transaction of 60-80 bytes and added a RSA 128 digital signature and issuing certificate of 4k-12k bytes effectively increasing the payload size by a factor of two orders of magnitude. it stripped all the SET overhead off at the internet boundary and transmitted a traditional 8583 message (in part because it was difficult to justify a 100-fold increase in payload size for no obvious benefit) with a flag indicating whether the signature had verified. There was some presentation at an ISO meeting by one of the association business people about the number of 8583 messages with the signature-verified flag turned on and they absolutely knew that there was no SET technology involved (some justification was association was proposing rules that transactions with the flag on would have lower merchant fees). missing is that typical authorization includes a lot of dynamic and aggregation factors (like credit limit) that are totally missing in a simple certificate-based (offline) authentication model. In fact, most infrastructures that involve transactions of any value have migrated and/or are migrating to online infrastructures that involve timely and/or aggregated information something that is missing from a purely offline, certificate-based, static, stale data infrastructure. misc. implications 1) given an online transaction environment, it is then trivial to show that certificates are redundant and superfluous ... because it is possible to access the timely updated copy of the information rather than having to rely on the stale, static copy of the certificate information (designed to satisfy an offline environment requirement) 2) certificate market then becomes relegated to both offline and no/low value (as infrastructures of value migrate to online paradigms) ... there is little/no justification for paying money for certificates if only no/low value infrastructures are involved. 3) w/o significant funding for certificate-based infrastructure, there is little money to underwrite high-integrity certificate-based operations 4) with no high-integrity certificate-based operations, it is difficult to justify using certificates for high-value operations 5) go to #2 as has past frequently noted, the requirement given the x9a10 retail payments working group for the x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payment environments. one of the considerations was being able to accommodate end-to-end integrity ... aka the financial responsible entity for authorizing the transaction also performs the authentication. another issue x9a10 had to address was to address other kinds of risks like the merchant transaction file where the information traditionally has to occur in the clear to support normal business operations (offer something more than the encryption of data in-flight). http://www.garlic.com/~lynn/index.html#x959 lots of posts about certificate infrastructures http://www.garlic.com/~lynn/subpubkey.html#sslcerts misc. stuff on x9.59, identity, authentication, and privacy http://www.garlic.com/~lynn/subpubkey.html#x959 -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Mark Shuttleworth On Open Source
Security Theatre: From the man who made hundreds of millions selling signatures on your keys: -- It is your data, why do you have to pay a licence fee for the application needed to access the data? -- Mark Shuttleworth http://www.tectonic.co.za/default.php?action=viewid=309topic=Open%20Source http://www.go-opensource.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: identification + Re: authentication and authorization
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gerck Sent: 7 juillet 2004 14:46 To: [EMAIL PROTECTED] Subject: identification + Re: authentication and authorization I believe that a significant part of the problems discussed here is that the three concepts named in the subject line are not well-defined. This is not a question of semantics, it's a question of logical conditions that are at present overlapping and inconsistent. For example, much of what is called identity theft is actually authentication theft -- the stolen credentials (SSN, driver's license number, address, etc) are used to falsely *authenticate* a fraudster (much like a stolen password), not to identify. Yes and no. The problem is that most authentication and authorisation schemes today are actually identification and authentication and authorisation schemes. Even when you read CISSP study guides, they always describe it in 3 steps, identification, authentication and authorisation. The thing is that we can do without identification. Identification is not necessary, even if you want accountability. In Identification-authentication-authorisation schemes, identification is the process of pin-pointing an exact individual from a set of individuals (e.g. SSN allows you to define a unique united-states citizen), authentication is the process of verifying that the individual claiming to be who he identified himself as, is really that individual. But most systems don't really need identification, all they need is a proof that the individual possesses a certain attribute. It is possible to do authentication and authorisation, without doing the identification part! For example, it is possible to prove that you are a united-states citizen that has a valid SSN number, without actually giving out information about SSN. Why is identity theft a bad thing? Usually, you don't want your identity to be stolen because you could be accused of something due to accountability that is associated with your identity. The problem is not that someone can authenticate himself to a system he is not suppose to have access to, the problem is that a thief can identify himself as you and authenticate himself as you, and than do bad things (like transfer your money). The problem is not really authentication theft, its identity theft, or if you want to put it even more precisely, it's identity theft and authenticating as the individual to whom the identity belongs to. But the latte doesn't make for a good buz-word :) Here is another way of seeing it. Consider a system where you need to authenticate yourself as a citizen, of some region, that is 18 years of age or older, in order to participate in some gambling thing say. One way to implement the authentication and authorisation in the system is to have each individual identify themselves, and then authenticate themselves. If the individual is part of a set of individuals that are known to be over 18, then the individual is given access. Another way to implement it is to have each individual prove that they are over 18 without identifying themselves, using Stefan Brands digital credentials say. If the authentication is successful, the un-identified individual is given access. In the latter case, you don't really care about authentication theft unless there is some sort of accountability (with Stefan's digital credentials, you can embed the identity in the tokens that are presented for authentication, the identity can only be revealed under certain circumstances, for example excessive use or if require by a law, it could be revealed by a third party). I do agree that stronger authentication does help, preferably authentication based on zero-knowledge protocols, since these reveal less information about the individual's identity that can be used to impersonate the individual. --Anton Once we understand this, a solution, thus, to what is called identity theft is to improve the *authentication mechanisms*, for example by using two-factor authentication. Which has nothing to do with identification, impersonation, or even the security of identification data. In further clarifying the issue, it seems that what we need first is a non-circular definition for identity. And, of course, we need a definition that can be applied on the Internet. Another important goal is to permit a safe automatic processing of identification, authentication and authorization [1]. Let me share with you my conclusion on this, in revisiting the concept of identification some time ago. I found it useful to ask the meta question -- what is identification, that we can identify it? In short, a useful definition of identification should also work reflexively and self-consistently [2]. In this context, what is to identify? I think that to identify is to look for connections. Thus, in identification we should look for logical and/or natural connections. For example: - between a
Re: identification + Re: authentication and authorization
Hi Ed and others, Like usual, you present some very interesting ideas and thoughts. The problem is that while we techies can discuss the identity theft definition until we are blue in the face, the general public doesn't understand all the fine subtleties. Witness the (quite amusing) TV ads by CitiBank. With high regards, Aram Perez [snip] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
At 10:40 AM 7/7/2004, Hal Finney wrote: SET failed due to the complexity of distributing the software and setting up the credentials. I think another reason was the go-fast atmosphere of the late 90s, where no one wanted to slow down the growth of ecommerce. The path of least resistance was simply to bring across the old way of authorizing transactions by card number. the other issue was rsa public key op overhead (besides extreme payload bloat, extreme additional complexity, and no significant countermeasures for prime exploits compared to e-commerce incumbent SSL). when the initial set specification was published, i did a business profile and a performance profile (including public key operations profile). somebody i knew was playing with bsafe library and tweaked it to run four times faster. I got him to run the set public key op profile on a number of processors. i mentioned the numbers at some set get together and the response from the set people was that it was 100 times too slow (if they had ever run any bsafe they should have realized that it was four times too fast). anyway ... sometime later when they actual set implementations running ... the earlier profile numbers were within a couple percent of measured on actual implementations. i also observed that given nominal extended peak avgs. of 1000/transactions per sec that if SET ever actually became mainstream operational (rather than just toy pilots) ... processing would need something like 100,000 to 250,000 extra processors to handle the RSA op processing load. the counter argument was that SET would take so long to became mainstream ... that by then CPUs might be ten to 100 times faster and it might only require 10,000 to 25,000 (or 1,000 to 2,500) extra processors. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EZ Pass and the fast lane ....
It would be relatively easy to catch someone doing this - just cross-correlate with other information (address of home and work) and then photograph the car at the on-ramp. Am I missing something? It seems to me that EZ Pass spoofing should become as popular as cellphone cloning, until they change the protocol. You pick up a tracking number by listening to other peoples' transmissions, then impersonate them once so that their account gets charged for your toll (or so that it looks like their car is traveling down a monitored stretch of road). It should be easy to automate picking up dozens or hundreds of tracking numbers while just driving around; and this can foil both track-the-whole-populace surveillance, AND toll collection. Miscreants would appear to be other cars; tracking them would not be feasible. The rewriteable parts of the chip (for recording the entry gate to charge variable tolls) would also allow one miscreant to reprogram the transponders on hundreds or thousands of cars, mischarging them when they exit. Of course, the miscreant's misprogrammed transponder would just look like one of the innocents who got munged. [I believe, by the way, that the EZ Pass system works just like many other chip-sized RFID systems. It seems like a good student project to build some totally reprogrammable RFID chips that will respond to a ping with any info statically or dynamically programmed into them by the owner. That would allow these hypotheses to be experimentally tested.] John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EZ Pass and the fast lane ....
John Gilmore wrote: It would be relatively easy to catch someone doing this - just cross-correlate with other information (address of home and work) and then photograph the car at the on-ramp. Am I missing something? It seems to me that EZ Pass spoofing should become as popular as cellphone cloning, until they change the protocol. You pick up a tracking number by listening to other peoples' transmissions, then impersonate them once so that their account gets charged for your toll (or so that it looks like their car is traveling down a monitored stretch of road). It should be easy to automate picking up dozens or hundreds of tracking numbers while just driving around; and this can foil both track-the-whole-populace surveillance, AND toll collection. Miscreants would appear to be other cars; tracking them would not be feasible. Well, I am presuming that ... the EZ Pass does have an account number, right? And then, the car does have a licence place? So, just correlate the account numbers with the licence plates as they go through the gates. The thing about phones is that they have no licence plates and no toll gates. Oh, and no cars. The rewriteable parts of the chip (for recording the entry gate to charge variable tolls) would also allow one miscreant to reprogram the transponders on hundreds or thousands of cars, mischarging them when they exit. Of course, the miscreant's misprogrammed transponder would just look like one of the innocents who got munged. What incentive does a miscreant have to reprogram hundreds or thousands of other cars??? [I believe, by the way, that the EZ Pass system works just like many other chip-sized RFID systems. It seems like a good student project to build some totally reprogrammable RFID chips that will respond to a ping with any info statically or dynamically programmed into them by the owner. That would allow these hypotheses to be experimentally tested.] Phones are great for spoofing because the value can be high. And, the risk of being physically apprehended is low. Cars and toll ways are a different matter. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: EZ Pass and the fast lane ....
[By the way, [EMAIL PROTECTED] is being left out of this conversation, by his own configuration, because his site censors all emails from me. --gnu] Well, I am presuming that ... the EZ Pass does have an account number, right? And then, the car does have a licence place? So, just correlate the account numbers with the licence plates as they go through the gates. If they could read the license plates reliably, then they wouldn't need the EZ Pass at all. They can't. It takes human effort, which is in short supply. The thing about phones is that they have no licence plates and no toll gates. Oh, and no cars. Actually, cellphones DO have other identifying information in them, akin to license plates. And their toll gates are cell sites. It's not clear what your remark about phones having no cars has to do with the issue of whether EZ Pass is likely to be widely spoofed. What incentive does a miscreant have to reprogram hundreds or thousands of other cars??? (1) Same one they have for releasing viruses or breaking into thousands of networked systems. Because they can; it's a fun way to learn. Like John Draper calling the adjacent phone booth via operators in seven countries. (2) The miscreant gets a cheap toll along with hundreds of other people who get altered tolls. [Cory Doctorow's latest novel (Eastern Standard Tribe, available free online, or in bookstores) hypothesizes MP3-trading networks among moving cars, swapping automatically with whoever they pass near enough for a short range WiFi connection. Sounds plausible to me; there are already MP3 players with built-in short range FM transmitters, so nearby cars can hear your current selection. Extending that to faster WiFi transfers based on listening preferences would just require a simple matter of software. An iPod built by a non-DRM company might well offer such a firmware option -- at least in countries where networking is not a crime. Much of the music I have is freely tradeable.] John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: identification + Re: authentication and authorization
Aram Perez wrote: Hi Ed and others, Like usual, you present some very interesting ideas and thoughts. The problem is that while we techies can discuss the identity theft definition until we are blue in the face, the general public doesn't understand all the fine subtleties. Witness the (quite amusing) TV ads by CitiBank. Thanks. That's why my suggestion is that techies should solve the real problem (authentication theft) that is allowing identity theft to create damage to the general public. What's the use of stolen identity data if that data cannot be used to impersonate the victim? At most, it would be a breach of privacy... but not a breach of access and data protected by the access. Furthermore, if identity data is not used as authenticators, they would not be so much available (and valuable!) to be stolen in the first place. BTW, the confusion between identification and authentication begins in our circle. Just check, for example, The Handbook of Cryptography by Menezes et. al.: 10.2 Remark (identification terminology) The terms identification and entity authentication are used synonymously throughout this book. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
