Re: Who needs secure wireless / tappable wireless infrastructure
And this says nothing at all about the need for tactical military wiretaps on GSM systems under battlefield conditions when soldiers lives may depend on determining what the enemy is saying over cellphones used to direct attacks against friendly forces. Or when innocent civilians need secure wireless infrastructures, to be able to coordinate to avoid murderous US military forces. See, for example: http://electroniciraq.net/news/1014.shtml which I found via SF writer James P. Hogan's blog: http://www.jamesphogan.com/bb/bb.shtml Prudent citizens should now know that before stepping into the street to hail a taxi, they should use a secure phone to determine whether any American tanks are in the area. But beware of American direction-finding equipment -- make those calls short! John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Code breakers crack GSM cellphone encryption
See their paper at CRYPTO 2003 for more details. I am disappointed that you seem to be criticizing their work before even reading their paper. I encourage you to read the paper -- it really is interesting. OK, then, where is it? I looked on: www.iacr.org under Crypto 2003 -- no papers there. The title of the paper, presented in Session 15, is: Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communication Elad Barkan, Eli Biham, Nathan Keller www.iacr.org under Conference Proceedings -- Crypto 2003 not there. www.iacr.org under Cryptology ePrint archive -- no Biham or GSM papers there. www.cs.technion.ac.il/~biham/ -- latest paper is from 2000. www.cs.technion.ac.il/~barkan/ -- access denied www.cs.technion.ac.il -- a news item about the GSM crack, but no paper. I'm even a dues-paying IACR member, but I don't seem to have online access to the papers from recent conferences. I'm sure a copy will show up in the mail a few months from now. Let me guess -- the devils at Springer-Verlag have stolen IACR's copyrights and the researchers were dumb enough to hand their copyright to IACR... John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
Rich Salz [EMAIL PROTECTED] writes: Sure, that's why it's *the first.* They have never done this before, and it is very different to how they (or their Ft Meade experts) have done things before. I suppose one could argue that they're doing this for Level 1 to increase the industry demand for Level 2, but I'm not that paranoid. I think they finally get it. I think this uniquely broad certification, if permitted, would be mostly a sign that the politicians have finally won out over the certification purists. Let me explain... it's been known for a long time (at least from talking to evaluators, I don't know if NIST will admit to it) that there's large-scale use of unevaluated crypto going on, with the FIPS eval requirement being ignored by USG agencies, contractors, etc etc whenever it gets in the way of them getting their job done. If NIST allow this extremely broad certification, it'd be a sign that they're following the Calvin and Hobbes recipe for success: The secret to [success] is to lower your expectations to the point where they're already met. In other words the unevaluated crypto problem (or a major part of it) suddenly goes away, and it's possible to report that the certification effort has been wonderfully successful, because a large portion of the noncompliant usage is (at least on paper) magically made compliant overnight. The only potential downside to this is that a pile of vendors who previously got a very narrowly-interpreted certification will presumably be queueing up to do the I'll have what she's having thing as soon as an open-ended certification is issued. As with others who have commented on this, I'm going to believe this when I see it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: fyi: bear/enforcer open-source TCPA project
How can you verify that a remote computer is the real thing, doing the right thing? You cannot. Using a high-end secure coprocessor (such as the 4758, but not with a flawed application) will raise the threshold for the adversary significantly. No, there are no absolutes. But there are things you can do. The correct security approach is to never give a remote machine any data that you don't want an untrusted machine to have. So you never buy anything online, or use a medical facility that uses computers? -- Sean W. Smith, Ph.D. [EMAIL PROTECTED] http://www.cs.dartmouth.edu/~sws/ (has ssl link to pgp key) Department of Computer Science, Dartmouth College, Hanover NH USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 04:25 PM 9/8/2003 -0700, Joseph Ashwood wrote: Actually they do target very different aspects. SET, 3D-Secure, and any other similar have a different target then SSL. To understand this it is important to realize that instead of the usual view of two-party transactions, credit card transactions actually take 3 parties; Issuer, Seller, and Buyer. SSL covers the Seller-Buyer communication, and can also be applied to the Seller-Issuer communication, but on a transaction basis it offers nothing for the Issuer-Buyer (the important one for minimizing costs for the Issuer). actually, physical credit card ... is a number of pair-wise communications card-holder to merchant terminal ... merchant terminal to merchant acquirer, merchant acquirer to interchange, interchange to issuer (credit card model is sometimes referred to as the 4-corner box with interchange trying to be transparent in the acquirer to issuer communication). original electronic commerce with the netscape commerce server ... had SSL for the shopping experience ... with the credit card done at the end. Depending on the mall version of the commerce server had dedicated leased line directly to merchant acquirer. The wider userd commerce server had a SSL connection from the commerce server to the payment gateway (which then interfaced to the merchant acquirer) ... effectively emulating the real world (two pair-wise communcations). http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 In the real-world SSL use got cut-back to only handling the credit card part of the transaction ... and not being used for the rest of the shopping experience. In any case, the SSL flows exactly emulate the physical world (effectively the front side of the virtual POS running at the merchant website ... and the backside of the virtual POS to the acquirer) . ... modulo previous comment that the merchant transaction file in the physical world wasn't accessable via the internet (even tho it directly doesn't show up in the flows). The major exploits haven't been in the transaction flow part of the operation but in the business mechanics the major exploits have been harvesting the merchant transaction file. Neither SSL, nor SET have counter-measure against the major exploit (harvesting the merchant transaction file). Both SSL and SET hid the credit card number while in transit. SET had all this other certificates and PKI gorp ... that significantly increased the crypto-related burden ( much more so than SSL). In theory, SET had an opportunity for end-to-end authentication but even a single certificate represented on the order of two-orders of magnitude bloat increase for the payload in the standard payment network (aka a single PKI certificate tends to be one hundred times larger than the typical, base payment transaction). The SET burden was orders of magnitude worse than the SSL burden. This, in part is what gave way to the SET payment gateway all the PKI gorp would occur at the SET payment gateway then all SET related information would be thown away, a standard 8583/x9.15 transaction created with an additional flag indicating that digital signature authentication had been correctly performed ...and off it goes. One of the VISA business people later gave a presentation at an ISO meeting about the number of 8583 transactions flowing thru the payment network with the SET-authenticated flag set but they could prove that no PKI technology was even remotely possible for the transaction aka a slight issue of end-to-end security was violated. The important issue here was that the vision for SET ... was that if SET-authenticated transaction were involved ... the merchant eventually would be eligible for card-holder present discount rates ... rather than MOTO discount rates (aka having SET authentication was proposed as being as safe as a) card-holder present, b) card-preset, and c) track 12 readable). It was therefor in the interest of the merchant side of the business to tell the issuing side of the business that transactions were SET authenticated and the mrechant could get a much better discount rate). The claim was that SET enormously increased the complexity, overhead, and payload processing ... while having little practical impact on the major vulnerabilities. Out of all this ... the X9A10 standards working group was giving the requirement to preserve the integrity of the financial infrastructure for all retail payments. The result is X9.59 which addresses all the major exploits at both POS as well as internet (and not just credit, but debit, stored-value, ACH, etc ... as well). http://www.garlic.com/~lynn/index.html#x959 One of the things addressed by X9.59 was not the elimination of the ability to harvest the merchant transaction file ... but to make the account numbers in the merchant transaction file useless for fraud.
X9.59 where is it?
On Tue, 9 Sep 2003, Anne Lynn Wheeler wrote: http://www.garlic.com/~lynn/index.html#x959 One of the things addressed by X9.59 was not the elimination of the ability to harvest the merchant transaction file ... but to make the account numbers in the merchant transaction file useless for fraud. slightly related discussion of the security proportional to risk and the vulnerability represented by the merchant transaction file Is X9.59 actually in use for consumer retail transactions anywhere? -- Victor Duchovni IT Security, Morgan Stanley - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Code breakers crack GSM cellphone encryption
Vin McLellan wrote: A5/2 was the equivalent of 40-bit DES, presumed to be relatively weak and developed as an export standard. Yeah. Except it would be more accurate to place A5/2's strength as roughly equivalent to 17-bit DES. A5/1's strength is roughly equivalent to that of 40-bit DES. Of course, the GSM folks didn't exactly do a great job of disclosing these facts. They did disclose that A5/2 was the exportable version. However, when A5/2 was first designed, SAGE put out a report that claimed years of security analysis on A5/2 had been done and no mathematical weaknesses had been found. Now that we've seen A5/2, that report suffers from a certain credibility gap, to put it mildly... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
x9.59
Anne Lynn Wheeler wrote: The result is X9.59 which addresses all the major exploits at both POS as well as internet (and not just credit, but debit, stored-value, ACH, etc ... as well). http://www.garlic.com/~lynn/index.html#x959 Lynn, Whatever happened to x9.59? Also, is there a single short summary description of what x9.59 does? I don't mean a bucket full of links to plough through, I mean some sort of technical overview that wasn't approved by the marketing department. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
OT: Swiss ATM Bancomat 5.0 BM5.0
The September/October 2003 edition of the German magazine Objektspektrum contains an article about the development of an ATM system to be used in Switzerland. (Alexander Rietsch: Die Neuentwicklung des Raiffeisen-Bankomaten, p.30-34. In passing it mentions that they use Windows 2000, an MS Access database for resources, MSDE for money transfer data, MSVS remote debugging, C++ for speed reasons, COM, IE, and have everything connected via TCP/IP networks. Unfortunately the focus of the article is not on security, so all the obvious question are unanswered. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Code breakers crack GSM cellphone encryption
One point your analysis misses is that there are public policy implications to deploying a phone system that enemy countries can routinely intercept. Not all attacks are financially motivated. Is it a good thing for our infrastructure to be so insecure? Do we want other countries listening to our GSM calls? Do other countries want us listening to their GSM calls? Is it a good thing if such interception is made easier? Sure, it may be in the SIGINT agencies' interests for GSM to be crackable, but is it in the public interest? It's not clear. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 05:19 PM 9/7/2003 -0600, Anne Lynn Wheeler wrote: Out of all this, there is somewhat a request from the CA/PKI industry that a public key be registered as part of domain name registration (no certificate, just a public key registration). Then SSL domain name certificate requests coming into a CA/PKI can be digitally signed, the CA/PKI can retrieve the authoritative authentication public key (for the domain name ownership) from the domain name infrastructure and authenticate the request eliminating all the identification gorp (and also done w/o the use of certificates). misc. additional recent musings: http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new) The Database gaps make ID fraud easier, GAO says http://www.gcn.com/vol1_no1/daily-updates/23446-1.html is somewhat analogous to the SSL domain name certificate problem ... a primary purpose for existing is to authenticate that the website you think you are talking to is the website you are talking to. The problem is that the domain name infrastructure has a database of domain name owners but no real good infrastructure ... and the CA/PKI operations doing SSL domain name certifications are disjoint from the domain name infrastructure operations. As a result effectively the CA/PKI industry has to treat requests for SSL domain name certificates effectively as if it was a random person walking in from the street ... and then they have to try and match up such seemingly random requests ... with what little bit of information that they can extract from the domain name infrastructure (seeing if they can establish an identity in the real world based on the DNS database information ... and see if that identity then can be matched against the identity of the entity requesting the certificate). Adding a public key to the domain name infrastructure database as part of the domain name registration process then eliminates the requirement of trying to establishing corresponding identities in the real world ... and it just reduces to a question of authentication. Of course, the bottom line is if the domain name infrastructure has a real-time database of public keys for authentication purposes in part for use by the CA/PKI industry for authenticating SSL domain name certificate requests for use in authentication operations the use of the domain name infrastructure's authentication public keys don't have to just be restricted to authentication use by the CA/PKI industry. In fact, domain name infrastructure authentication public keys could be used to effectively for authentication operations that actually subsume the SSL domain name certificates authentication operations. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
GSM Crack Paper
Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communications, by Elad Barkan, Eli Biham, Nathan Keller http://cryptome.org/gsm-crack-bbk.pdf (18 Pages, 234KB) Abstract. In this paper we present a very practical cipher-text only cryptanalysis of GSM encrypted communications, and various active attacks on the GSM protocols. These attacks can even break into GSM networks that use unbreakable ciphers. We describe a ciphertext-only attack on A5/2 that requires a few dozen milliseconds of encrypted off-the-air cellular conversation and finds the correct key in less than a second on a personal computer. We then extend this attack to a (more complex) ciphertext-only attack on A5/1. We describe new attacks on the protocols of networks that use A5/1, A5/3, or even GPRS. These attacks are based on security flaws of the GSM protocols, and work whenever the mobile phone supports A5/2. We emphasize that these attacks are on the protocols, and are thus applicable whenever the cellular phone supports a weak cipher, for instance they are also applicable using the cryptanalysis of A5/1. Unlike previous attacks on GSM that require unrealistic information, like long known plaintext periods, our attacks are very practical and do not require any knowledge of the content of the conversation. These attacks allow attackers to tap conversations and decrypt them either in real-time, or at any later time. We also show active attacks, such as call hijacking, altering data messages and call theft. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital cash and campaign finance reform
- Original Message - From: Steve Schear [EMAIL PROTECTED] Subject: Re: Digital cash and campaign finance reform At 04:51 PM 9/8/2003 -0700, Joseph Ashwood wrote: - Original Message - From: Steve Schear [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] [anonymous funding of politicians] Comments? Simple attack: Bob talks to soon to be bought politician. Tomorrow you'll recieve a donation of $50k, you'll know where it came from. Next day, buyer makes 500 $100 donations (remember you can't link him to any transaction), 50k arrives through the mix. Politician knows where it came from, but no one can prove it. Not so fast. I said the mix would delay and randomize the arrival of payments. So, some of the contributions would arrive almost immediately others/many might take weeks to arrive. You act like they aren't already used to addressing that problem. I'll go back to the Bustamante, simply because it is convenient right now. Bustamante recieved a multi-million dollar donation from the Native Americans, this was not done through a single check, that would be illegal, instead it was done through multiple smaller checks, each of which ends up randomized and delayed in processing (USPS is wonderful source of randomness), so the actual occurance of the donations is scattered acros several days, from several accounts, by several people, and I'm sure Bustamante never even looked to see who the donations were actually from, just that the full amount arrived. The problem that you found, is already addressed, and already not a problem. Joe Trust Laboratories Changing Software Development http://www.trustlaboratories.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 05:07 PM 9/9/2003 -0700, Joseph Ashwood wrote: Now that the waters have been muddied (by several of us). My point was that 3D-Secure (and SET and whatever else comes along) covers a different position in the system than SSL does (or can). As such they do have a purpose, even though they may be horribly bloated and nearly non-functional. Visa at least seems to be supporting the 3D-Secure concept (they should, they developed it), and looks like anyone can grab the spec from ... while SET, 3d-secure, etc may have been designed for all sorts of reasons I guess my point was that w/o a adequately specified threat model for the primary vulnerabilities ... there turned out to be little effective difference between the use of SET and the use of SSL (regardless of what the designers may have original thot). Also technology adoption/uptake typically requires the transition to be less painful than the problem it is fixing. SSL was already in the market space ... so SET had to demonstrate that it was incrementally better (not effectively the same as for the major vulnerabilities) in order to justify its significantly more difficult and costly deployment. The other issue that has been the bane of major PKI/certificate deployments (and I've repeatedly raised the issue) ... is that certificate-based operations typically have the key owner paying for the certificate while the major benefit accrues to the relying-party ... the the key/certificate owner. In the case of SET ... there was the consumer payng for their certificate and the merchant not only receiving a better than MOTO-discount (making interchange transactions with the SET flag turned on ... somewhat suspecious) ... but also the possibility that the transaction would be treated as authenticated and potentially shifting the burden of proof in a dispute from the merchant to the consumer. There was the possibility that not only would the consumer be footing the bill (buying their own certificate) for the sole benefit of reducing what the merchant paid on the transaction but there was also speculation that it might also be used to make it more difficult for the consumer (there was sporadic mention of shifting the burden of proof from the merchant to the consumer in a dispute). At least in the SSL domain name certificate, the merchant pays because of some belief that it will help attracted (internet) consumers/business. In the SET/PKI scenario ... it was nearly impossible to figure out a value proposition for the consumer where the consumer is footing the (certificate) bill ... that turns out to be totally for the benefit of the merchant. It wasn't so much that cryptography took a wrong branch ... but many of the PKI business models don't conform to any sane business operation with the entity (key-owner) footing the bill not getting any benefit ... and all the benefit going to the relying-party. The other generalized PKI issue (again not just SET) ... is any contract tends to be between the CA?PKI and the consumer aka the entity in a contract that purchases something. Frequently is no contractual relationship between the relying-parties who effectively the sole reason that the certificates exist ... and the CA/PKI. As mentioned elsewhere, the GSA PKI has attempted to somewhat address this by having all relying-parties sign contracts with the GSA and all the CA/PKI certificate issuing entities have a contract with the GSA where they are effectively issuing certificates on behalf of the GSA. Those set of contracts then preovide the legal foundation for some generic reason for relying-parties to do anything with certificates (since the relying-parties and the CA/PKI agency, aka GSA ... have contractual relationship and therefor a legal reason to deal with certificates). The slightly different SET scenario ... the associations just told the merchants that they would be charged less per transaction ... aka instead of MOTO (mail order, telephone order) discount, they could get something closer to card present discount. -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
