Re: Metaswitch cleared by FBI for spying
Well, a secure H.323 is certainly better than nothing, but as of right now the world looks like its going to remain circuit switched for a long time. That means most standard telephone calls will potentially be under scrutiny, unless encryption is used at the end points. And I guess that's where one would ultimately want to do that anyway... -TD
_________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
On Fri, 11 Apr 2003, Tyler Durden wrote:
Which leads me to a different idea. (Or, more accurately, a n-th rehash of the many-times-discussed-already idea.) Something like an embedded computer, dedicated to PGPfone-like device, using a cellphone as its communication unit. Basically, an embedded computer, with audio I/O on one side and audio I/O and serial port on the other one. The unit would connect between the phone and either a hands-free or a handset/headset, acting either as an encryption/decryption device (and using the phone in data-call mode), or as just a passthrough (for nonencrypted ("plainsound"?) calls)). The unit would manage everything from contacts to ringing to encryption of calls and text messages, the phone would act as just a dumb wireless device, without carrying any data (nor contact lists) in itself. The unit would also have to guard the contact lists, stored messages, and other data against retrieval by unauthorized personnel (thieves, investigators...) - phone lists from intercepted phones are important intelligence source on its own. This will also allow us to set the individual phone numbers to specify if the calls/messages to that number are plaintext by default, auto-negotiated, or forced-encrypted, and the certificates or public keys of the other party, allowing checking of the other party's identity. That all is fairly obvious, and isn't difficult with standalone, desktop-class PCs, even with the older ones. A suitable platform for rapid development and deployment seems to be some flavor of embedded Linux (eg, Midori?). This gives us the advantage of having most of the code already available, having to just glue it together. The question is, how much the available technology changed from when these things were being actively developed, what of already-existing devices we can use, if there aren't already enough-powerful devices allowing this mode of operation without having to develop our own hardware, either as PDAs, or as some already-existing embedded control systems. (I was looking around for PC104 boards, but the ones I seen tend to be rather expensive.) There are already whole computers on a single chip. I seen a full-featured 386 capable of running standard Linux kernel, which would fit both the power consumption and size requirements, but is too weak for the required compression and encryption. The technology marches on and the Moore's Law still applies. So it is just the matter of time when suitable components hit the market. My question to anyone who comes into closer contact with this kind of computers is if it by chance already hadn't happened - and if so, details about the available devices. This could be even a decent business opportunity. Make the unit generic enough, make its function dependent only on its software, sell it anywhere without any legal restrictions - and make the secure-phone software available for download, together with eg. GPS car locator software and remote control/telemetry software. This could drive demand high enough to benefit from volume production, which could drive the costs low enough to stimulate demand for secure telephones even between less wealthy people than the market segment for the overpriced Siemens TopSec units. -- ...The best lawyers are Mr. Smith and Mr. Wesson.
At 04:53 AM 4/12/03 +0200, Thomas Shaddack wrote: ...
I wonder how hard it will be to just implement encryption in software on the phone. Does anyone know if these relatively new PDA-phones have the ability to process the packets they receive from digital calls before feeding them into the codec, and the codec outputs before they send them out over the air? Or just to set up a data-only call where you're just sending bits to/from Nautilus or some similar program? I keep thinking that the only way we're going to get strong encryption on cellphones is to make it something that individuals can do themselves. The cellphone providers have little incentive to do this well. Maybe we could put the dedicated computer you're talking about at home, with two phone lines available to it. People trying to reach you call into the box, and it is the only thing that ever legitimately calls your cellphone. These calls can just always be encrypted, or can use Nautilus or some such thing, and set up a connection for data instead. When the cellphone calls out, it always calls to the box first. Ideally, the software for both the box and the phone would be open source, and no harder to set up than a VCR. In fact, this could double as a secure cordless phone, using an 802.11b card; the box chooses the cheapest method to reach your handset. For extra credit, if two such boxes ever talk to each other, they could do end-to-end encryption. But honestly, it's a lot more critical to get the stuff going out over the air encrypted (since that can be intercepted with very little risk of anyone noticing). I wonder if such a box could become a kind of communications hub, handling (secure) voice mail, cellphone, and multiple cordless phones. Someone who wants one probably wants all three, and might be willing to pay a couple hundred dollars for it, making the whole thing reasonable to sell. Even just getting the over-the-air part encrypted means someone has to leave a paper trail or physical evidence lying around to eavesdrop on phone calls, which probably implies actually getting a warrant, rather than just getting a hacked scanner and using it to troll for interesting cellphone or cordless conversations. And if the boxes became widespread, we'd start seeing "transparent" use of end-to-end encryption. (The only way we're ever likely to see normal, non-paranoid non-criminals using voice encryption very often is if it's just something that happens automatically and painlessly.) --John Kelsey, kelsey.j@ix.netcom.com PGP: FA48 3237 9AD5 30AC EEDD BBC8 2A80 6948 4CAA F259
On Sat, 12 Apr 2003, John Kelsey wrote:
The telcos are often legally required to NOT do this well. We should keep in mind that the Adversary keeps the infrastructure compromised.
Ideally, it would be a plug-and-play thingy, a box with just a connector and the antenna.
In "auto" mode, the box should ask the other side if it is a compatible box, and if yes, do a key handshake.
I wonder if such a box could become a kind of communications hub, handling (secure) voice mail, cellphone, and multiple cordless phones.
There is no reason why it couldn't. :)
The Adversary won't like this. This is another reason why the design has to be completely open and widely published. I can imagine a government shutting down a corporation or an individual enterpreneur. I can't imagine a government successfully shutting down eg. Linux movement, DeCSS, pr PGP. Asymmetrical warfare in its best :)
On Sat, 12 Apr 2003 10:59:19 -0400 John Kelsey <kelsey.j@ix.netcom.com> wrote:
I doubt you can get at the raw packets coming out of the GSM codec and going to the modem without some serious mangling of the phone's firmware. Initiating data-calls which then carry the encrypted voice packets seem like a much more feasible idea. From what I've heard, some of the recent crop of PDA phones, notably the Nokia 7650 and the Sony-Ericsson P-800, contain an ARM-9 core with a clock speed above 100 MHz, which might just be sufficient for getting encrypted voice communications on these gadgets of the ground. This of highly course depends on how much cycles your voice codec chews. Seeing that both phones run under Symbian OS 6 and 7 respectively you might even get portability for your application. Easier still might be porting Nautilus or Speak Freely to the Zaurus or just using ZMeeting over an IPsec tunnel over a GPRS connection. Cheers, Ralf -- Ralf-Philipp Weinmann <ralf@fimaluka.org> PGP key info: 1024D/57B6E7DB, 40EACFD75032981B8B11E80EB8CEB11057B6E7DB
participants (4)
-
John Kelsey -
Ralf-Philipp Weinmann -
Thomas Shaddack -
Tyler Durden