Re: How the Greek cellphone network was tapped.
| Crypto has been an IP minefield for some years. With the expiry of | certain patents, and the availability of other unencumbered crypto | primitives (eg. AES), we may see this change. But John's other | points are well made, and still valid. Downloadable MP3 ring tones | are a selling point. E2E security isn't (although I've got to | wonder about certain teenage demographics... :) | | It's also an open question whether network operators subject to | interception requirements can legally offer built-in E2E encryption | capabilities without backdoors. It's going to be interesting to see the effect of the iPhone in this area. While nominally a closed system like all the handsets that preceded it, in practice it's clear that people will find ways to load their own code into the things. (As of yesterday - less than two weeks after the units shipped - people have already teased out how to get to the debugging/code patching interface and have extracted the internal passwords. The community doing this would make a fascinating study in and of itself - an international group coordinating through an open IM line, tossing around ideas.) There's plenty of CPU power available, and a fairly standard environment. (In fact, recent reports hint that the chip contains a hardware accelerator for Java.) Between encrypted VOIP over WIFI and eventually over broadband cell - keeping people from running voice over their broadband connections is a battle the telco's can't win in the long run - and just plain encrypted cell phone calls, I think in a couple of years anyone who wants secure phone connections will have them. There will be tons of moaning about it from governments - not to mention the telco's, though for them that will be a triviality compared to all the other things they will lose control over - but no one is going to be able to put this genie back in the bottle. Also, right now, the technology to build a cell phone is still specialized and capital-intensive. But today's leading-edge chip and manufacturing technology is tomorrow's commodity. Ten, twenty years from now, anyone will be able to put together the equivalent of today's iPhone, just as anyone can go down to Fry's today and build themselves what was a high-end PC a couple of years ago. You can't quite build your own laptop yet, but can that be far off? A gray box cellphone might not compete with what you'll be able to buy from the leading-edge guys of the day, but it will be easily capable of what's needed to do secure calling. So - who's going to write the first RFC for secure voice over cell, thus circumventing the entire government/telco/PTT standards process? We're not quite ready for it to take off, but we're getting close. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Historical one-way hash functions
So, you want to be able to prove in the future that you have some piece of information today - without revealing that piece of information. We all know how to do that: Widely publish today the one-way hash of the information. Well ... it turns out this idea is old. Very old. In the 17th century, scientists were very concerned about establishing priority; but they also often wanted to delay publication so that they could continue to work on the implications of their ideas without giving anyone else the opportunity to do it. Thus, in 1678, Robert Hooke published an idea he had first developed in 1660. Even then, he only published the following: ceiiinosssttuu. Two years later, he revealed that this was an anagram of the Latin phrase Ut tensio sic uis - as the tension so the power - what we today call Hooke's Law of elastic deformation. (This story appears in Henry Petroski's The Evolution of Useful Things.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
How the Chinese internet is tapped.
on a similar topic as Greek. i was in Shinsen and DongAng, mainland china (right next to HongKong). i was able to experience GSM/GPRS Internet as well as hotel wired Internet (both are IPv4, sigh). in both cases, TCP port 80 (http) was sucked into transparent web proxy (squid). i was careful enough not to type offensive words, but zh.wikipedia.org was invisible (squid raises some kind of connection error, always). ja.wikipedia.org and en.wikipedia.org were visible. luckily TCP port 22 was open. the hotel net was behind NAT so i could not use IPsec VPN. i did not have enough time to configure NAT traversal stuff. from my past experience with chinese academic network operated in some university in Beijing (i forgot the name of the network/ university), i know that every connectivity from china goes out of Beijing. at least in year 2000-2002 timeframe. so if it is still true (inject me some clue if you know about the current situation), all the traffic that go out of china are tapped in Beijing. i'm wondering what kind of server farm they are operating which are able to suck all TCP port 80 traffic from the entire china... i forgot to run nmap OS fingerprint :-( also, my friend in china was using Skype from Tom Online on top of Windows. i did not believe it until i see it, but ContentFilter.exe was really there. it is the backdoor process for Tom Online Skype which transmits cleartext content to somewhere, which is likely to be some law enforcement or government organization. otherwise, Skype traffic is totally encrypted - see silver needle in skype paper. i was informed that it is a common practice for south east asian nations to run censorship on the internet. for instance, in thai www.youtube.com is not accessible. they have never seen dodolook, very cute taiwanese girl from canada (IIRC) i guess. for more info, the following URL would be useful. Japanese content and English content are a bit different so if possible be sure to check both of them (and other languages if possible). the email is encoded in iso-2022-jp (Japanese standard encoding for email) but when you click it please click it Japanese URL in utf-8. http://en.wikipedia.org/wiki/Golden_Shield_Project http://ja.wikipedia.org/wiki/
Re: How the Greek cellphone network was tapped.
On 07/10/2007 01:59 AM, Florian Weimer wrote: It's also an open question whether network operators subject to interception requirements can legally offer built-in E2E encryption capabilities without backdoors. I agree. It's a tricky question; see below JI responded: You probably meant device vendors, not network operators. We all agree we can make a distinction between telcos and phone HW manufacturers. But that may not be the relevant distinction. I know in the US, and I imagine elsewhere, telcos buy phones from the OEMs and then retail them to customers. That makes them, in the eyes of the law, both telecommunication carriers *and* device vendors, even if they are not device OEMs. The whole *point* of E2E security is that network operators are not involved. If they were, it wouldn't be end-to-end! Well, that's logical, but who said the law has to be logical? IANAL but AFAICT the most sweeping parts of the CALEA law apply to telecommunication carriers as defined in section 1001: http://www4.law.cornell.edu/uscode/html/uscode47/usc_sec_47_1001000-.html Customer encryption is explicitly not included by the terms of section 1002: http://www4.law.cornell.edu/uscode/html/uscode47/usc_sec_47_1002000-.html ... unless the encryption was provided by the carrier and the carrier possesses the information necessary to decrypt the communication. I repeat: ... unless the encryption was provided by the carrier and the carrier possesses the information necessary to decrypt the communication. Following this line of thought leads to all sorts of illogical conclusions, including: a) Arguably it might be OK to buy a backdoor-free crypto phone from the grocery store, but not OK to buy or lease it from the phone company. b) Arguably you could buy a phone from the telco with no crypto at all, and then take it to Orange County Choppers and have them install backdoor-free crypto. c) Arguably the OEM could have two product lines, one without backdoors, to be sold via telcos, and one without backdoors, to be sold otherwise. d) Arguably everybody is OK provided the telco doesn't have the keys. Maybe you can use a crypto phone provided by a US telco if you have a high-assurance way of changing the keys to the back door as well as the front door. e) We all know the laws differ wildly from one jurisdiction to another ... and the laws can be changed at any time. The cost of the second product line (item b) might not be too much higher than the first product line (item a), since it could be considered a /byproduct/, such that all the big development costs are attributed to line (a) ... assuming there is a market for crypto phones of any kind. As to whether any such market will develop in the near future is another interesting question. The fact that only a tiny fraction of present-day email is E2E encrypted is not an encouraging sign. (Email is easier to encrypt than voice.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: FIPS 140-2, PRNGs, and entropy sources
On 9 Jul 2007 16:08:33 -0600, Darren Lasko wrote: 2) Does FIPS 140-2 have any requirements regarding the quality of the entropy source that is used for seeding a PRNG? Yes. The requirement imposed by FIPS 140-2 (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf) are in section 4.7.2: Compromising the security of the key generation method (e.g., guessing the seed value to initialize the deterministic RNG) shall require as least as many operations as determining the value of the generated key. (which would apply to any RNG output that became a key) and in section 4.7.3: Compromising the security of the key establishment method (e.g., compromising the security of the algorithm used for key establishment) shall require at least as many operations as determining the value of the cryptographic key being transported or agreed upon. (which would apply to any RNG output that is used in a security relevant way in a key establishment scheme) For whatever reason, I get asked FIPS 140 questions and this one about FIPS 140-2 comes up on occasion. It is good someone finally asked in public and received a public reply. A bit convoluted, and this says nothing about seeding requirements for a PRNG not used for key generation/agreement, but it is the logic of FIPS 140-2 with regards to PRNG seeding. Again, good information. However, it seems pretty nebulous about how they expect you to measure the number of operations required to compromise the security of the key generation method. Do you know what kind of documentation the labs require? SP 800-90, Appendix C.3, states that the min-entropy method shall be used for estimating entropy, but this method only uses the probabilities assigned to each possible sample value. I'm guessing that measuring ONLY the probabilities associated with each sample is insufficient for assessing your entropy source. For example, if I obtain 1 bit per sample and I measure 50% 0's and 50% 1's, I have full entropy by that measure, even if my entropy source always produces 1010101010101010. Is the NIST Statistical Test Suite sufficient for evaluating your entropy source, and will the certification labs accept results from the STS as an assessment of the entropy source? From what I have seen, the labs understand what will pass muster with NIST/CSE for FIPS 140-2 based on their experience with the many FIPS 140-2 validation efforts performed to this point, so they are a good gauge of what NIST/CSE will smile upon here, even though there has been little formal guidance. Most labs are fine with standard techniques for gathering entropy from a system, such as polling various timings for things like disk access, plus whitening, such as running the results of the polling through a FIPS-approved hashing algorithm. Hardware RNGs, such as a noise source, which can be used either as just another source in the polling, or as the only source. When using a hardware RNG, most vendors focus on this as the primary source of entropy, and labs will often require many details about the hardware RNG as a result. As far as what to provide, well, you need to describe how the PRNG is seeded, give code pointers to the seeding and any entropy gathering routines, include details on any hardware RNGs, and construct a general rationale for why all this adds up to meeting the requirements. The labs can take it from there and ask for more information as needed, such as sample output from the entropy gathering routines to examine. If you are concerned about not meeting the requirements, chatting with a lab or consultant about what is required is not out of the question - it might even provide some metric as to how friendly and responsive the team you are considering working with for your validation will be. FWIW, up to this point in time, I have rarely seen formal calculations of entropy by vendors in the rationale for meeting these requirements (those few times were mostly with vendors that built their own hardware RNGs), and I have seen statistical tests used by vendors a little bit as a part of the rationale behind meeting these requirements. -Andrew - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
At 10:59 PM 7/9/2007, Florian Weimer wrote: Uh-oh, no. The protocol characteristics don't change depending on who is selling you the device. Of course they do, at least in the US, where the mobile phones are generally carrier-specific, often locked, and generally don't have open designs. In particular, they're not usually designed to let the data applications get at the voice compression ASICs, but they usually don't have enough CPU to compress voice in Java if they can get at the voice stream at all. Some of the PDA phones are more flexible, and I'd expect OpenMoko to be much more flexible. Many telcos have an aversion to end-to-end protocols. They're getting better about it, but the transmission characteristics from most of the data protocols aren't designed for voice, unless you're willing to do push-to-talk or equivalent. So ironically, if you want to get good latency for 5.3kbps voice, you'll want the fastest data protocols. HSDPA's latency is 100-200ms, and upstream is 100+ kbps - you could probably run uncompressed voice which is about 80kbps, since latency's less of a problem. (EDGE has upstream of 40-60kbps, but latency is 350+ so the more compressed protocols aren't going to behave. I don't have the 1xRTT numbers handy, but I think they're similar.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
On 7/9/07, alan [EMAIL PROTECTED] wrote: Makes me wonder how this will effect the OpenMoko phone if someone builds an encryption layer for it. (OpenMoko is a totally open sourced phone.) Leigh Honeywell and Paul Wouters presented a 'crypto-phone' effort they have been working on at CCC in Germany last December. They later presented an update at a meeting in Toronto: http://www.task.to/events/presentations/securephone-task.pdf They are building on OpenMoko and the Neo1973 phone (http://wiki.openmoko.org/wiki/Neo1973), because it is the only phone they could find that allows OS modifications without breaking code signing. As I understand it, it's not true end-to-end. It makes a 'VPN' connection to an Asterisk PBX that you have configured somewhere in the world, presumably on a phone network trusted more than the wireless one you are currently on. If the PBX has to route the call back into public infrastructure to the other endpoint, then there is cleartext exposure again. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
On Jul 6, 2007, at 6:20 PM, John Ioannidis wrote: Unfortunately, it's not so easy to roll your own on top of a 3G- enabled smartphone. The broadband channel does not have the tight jitter and throughput guarantees that voice needs, and some providers (Verizon in the USA for example) consider running voice traffic over their broadband network a violation of the usage agreement (no need to blame the government for that, their own greed is adequate explanation). There are lots of other technical and human-factors issues that have been covered to great extent in this and other fora. /ji The Cryptophone project in Europe http://www.cryptophone.de/ has been trying to tackle the QoS issues for four or five years now. I haven't looked at their implementation closely in several years, but back in 2002 or so they were using CSD (modem-modem calls) instead of the broadband channel, trading bandwidth for low jitter... With current CPUs and audio codecs you can get decent voice quality over 9600bps. Thanks, Eric PGP.sig Description: This is a digitally signed message part
ACM CCS Industry Track CFP
My apologies if this is considered spam; however, it may be of interest to a number of list subscribers. We are soliciting proposals for presentations in the Industry track at the ACM Conference on Computer and Communications Security, which will be held October 29th to November 2nd in Alexandria, VA. For more information, see below, or visit the ACM CCS website, http://www.acm.org/sigs/sigsac/ccs/CCS2007/cfp-industry.html Thanks, -Will - Call for Proposals (http://www.acm.org/sigs/sigsac/ccs/CCS2007/cfp-industry.html) Industry Track Submission Deadline: August 3, 2007 The Industry and Government Track of the 14th ACM Computer and Communications Conference seeks novel and innovative reports of experiences in security product development and deployment of products to meet system security goals. In addition, reports on the scope and content of current sponsored research programs in information security are of interest. The track will foster active discussion of practical experiences in the imaginative or large scale deployment of security solutions in organizational contexts and the relationship of these experiences to current research initiatives. Particularly of interest are lessons learned and deficiencies in existing products or systems that might identify areas in which research is needed. Government or commercial requirements for future systems are also relevant. Technical characteristics of novel products may be of interest, but marketing pitches are verboten! As one of the most influential conferences in the area, CCS affords industry and government the opportunity to gain the attention of a capable and energetic set of researchers. Topics of interest include (but are not limited to): Access control Accounting and auditing Applied cryptography Authentication Case studies of computer and systems security design Commercial and industry security Cryptographic protocols Data/system integrity Database and system security Digital rights management DoS detection and mitigation e-business/e-commerce Embedded systems security Enterprise security policies Experimental studies of impact of tools and processes Information warfare Intellectual-property protection Intrusion detection Key management Mobile code security Physical security Privacy and anonymity Secure networking Security issues in administration of large computer systems Security management Security measurement and modeling Security verification Smart cards and secure PDAs For this track, we are soliciting panel and presentation proposals. Proposals accepted for the program will be made accessible prior to the conference. The track may include invited speakers as space and interest permit. Submission format and other instructions are available soon. Presentation Proposals A position paper or full presentation is appropriate. The paper should include sufficient motivation and detail to focus and depth of presentation. Detailed proposals or presentations are highly recommended and will receive preferential treatment. Expected speakers should be identified. All submissions should be received by August 3rd, 2007 and sent to [EMAIL PROTECTED] Word, .pdf, and powerpoint submissions will be accepted. Panel Proposals A panel proposal should be no longer than three (3) pages in length. It should include possible panelists and an indication of which panelists have confirmed their participation. Submissions: Information will be posted soon. Organizers: Program Co-chairs (Research Track): - Sabrina De Capitani di Vimercati, University of Milan, Italy - Paul Syverson, Naval Research Laboratory, USA Program Chair (Industry and Government Track): - Patrick McDaniel, Penn State University, USA General Chair: Peng Ning, NC State University, USA Publicity Chairs: Radha Poovendran, University of Washington, USA Publication Chair: David Evans, University of Virginia, USA Tutorials Chair: Wenliang (Kevin) Du, Syracuse University, USA Treasurer: Sencun Zhu, Penn State University, USA Workshops Chair: Vijay Atluri, Rutgers University, USA Steering Committee: Sushil Jajodia (Chairman), George Mason University, USA Carl A. Gunter, University of Illinois, USA Pierangela Samarati, University of Milan, Italy Ravi Sandhu, George Mason University, USA Program Committee: Dave Dorenbos, Motorola, USA David Du, National Science Foundation, USA Yong Guan, Iowa State University, USA Trevor Jim, ATT Research, USA Hugh Harney, SPARTA, USA Brian LaMachia, Microsoft, USA Gary McGraw, Cigital, USA Shubho Sen, ATT Research, USA Patrick Traynor, Pennsylvania State University, USA Brian Wies, CISCO, USA - - The
improving ssh
List, SSH (OpenSSH) is routinely used in secure access for remote server maintenance. However, as I see it, SSH has a number of security issues that have not been addressed (as far I know), which create unnecessary vulnerabilities. Some issues could be minimized by turning off password authentication, which is not practical in many cases. Other issues can be addressed by additional means, for example: 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) 3. pre- and post-filtering to prevent SSH from advertising itself and server OS 4. block empty authentication requests 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username I believe it would be better to solve them in SSH itself, as one would not have to change the environment in order to further secure SSH. Changing firewall rules, for example, is not always portable and may have unintended consequences. So, I'd like to get list input (also by personal email if you think your comment might be out of scope here), on issues #1-6 above and if you have other SSH security issues that you would like to see solved /in SSH/. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
