Re: End-to-end encrypting US GSM phones?
I'm unclear why Lucky dislikes the Sectra Tiger (www.sectra.se); the key management is not what I'd like, but seems designed specifically for hierarchical military or corporate organizations, which is the only viable market for a EUR 2500 encrypting cellphone. I think the most cost-effective voice crypto solution today is a bluetooth-enabled cellphone, a bluetooth-enabled PocketPC (ipaq) with fast ARM, and then conventional encrypted-voice software (such as speak-freely) running over PPP over bluetooth. It would be fairly easy to develop a belt or briefcase cellphone, handheld PDA with audio I/O via headset worn on the belt or held in the hand (or, using an Ericsson headset, stored in a briefcase as well), . System cost USD 1000 or less, entirely COTS consumer hardware and open-source software, and you get a free normal GSM cellphone, high-spec PDA (==ecash terminal), and equivalent ease of use to the very best cellphone (as you would be using a headset, carrying the phone and processor separately). If you're concerned about rf monitoring on the local bluetooth side, you could substitute a wired headset/microphone; if you're concerned about the general unavailability of bluetooth-enabled fast PDAs, you could with an ease of use penalty use IrDA. I don't believe a dragonball could do viable voice crypto (especially compression), at least without a coprocessor card, but perhaps it could, and it certainly could support encrypted SMS. You could possibly use your own non-standard link protocol, vs. PPP, if you are concerned about latency, but it should be relatively easy to achieve 100-200ms latency on cell to cell communications. The benefit of using software which exists on general purpose machines and TCP/IP over the link is of course that normal desktops could be used as secure phone terminals as well, and I think there really isn't much demand for voice crypto in the marketplace, outside the military and defense-mandated commercial contractor use. When audio I/O-enabled PDAs, bluetooth cellphones, etc. are widely deployed, perhaps this will change (plus, bluetooth or 802.11b PDAs could serve as cordless phones with IP-IP or VoIP calling when in range of a legitimate or borrowed network). I've used speak-freely on a unix laptop for years, using IP transport of opportunity, and with a good headset/microphone, it seems to meet my needs for secure voice. The other reason for using PPP-Voice is to abuse cell providers; in the UK, for instance, I have a GBP 75/month unlimited-calling phone (UK numbers); I could easily use this to dial in to a UK-based phone with HSCSD and a fast IP connection at 14.4kbps, and then use IP-IP or a VoIP bridge to get cheaper or free international calling; encrypted by default to the gateway, and possibly to the other end if supported. -- Ryan Lackey [RL7618 RL5931-RIPE] ryan@havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F
On Sat, 29 Dec 2001, Ryan Lackey wrote:
I'm unclear why Lucky dislikes the Sectra Tiger (www.sectra.se); the key management is not what I'd like, but seems designed specifically for hierarchical military or corporate organizations, which is the only viable market for a EUR 2500 encrypting cellphone.
The reason why I have little faith in the Sectra Tiger is because I talked with one of Sectra's head cryptographers. Below is a brief recap of the conversation: Lucky: How did Secrta solve the key distribution problem in the military version of your product adopted by the Swedish army? Sectra: We are using a central key server. Lucky: How does the system respond to a failure of the central key server? Secrta: The hansets revert to a system-wide default key installed in the handset at time of manufacture. The key is idential for all handsets. Lucky: [Pause]. I see... Do you believe that a communication system that depends for its security on the enemy ignoring your central key server to be suitable for military applications? What if somebody destroys the key server? Secrta: [Visibly surprised by the question]. But we live in times of peace! Why would anybody wish to destroy the key server? Lucky: Right..... [I guess they no longer shoot military suppliers who's products endanger the armed forces for treason]. -- Lucky Green <shamrock@cypherpunks.to> PGP encrypted email preferred.
At 09:19 PM 12/30/2001 +0100, you wrote:
On Sat, 29 Dec 2001, Ryan Lackey wrote:
I'm unclear why Lucky dislikes the Sectra Tiger (www.sectra.se); the key management is not what I'd like, but seems designed specifically for hierarchical military or corporate organizations, which is the only viable market for a EUR 2500 encrypting cellphone.
The reason why I have little faith in the Sectra Tiger is because I talked with one of Sectra's head cryptographers. Below is a brief recap of the conversation:
<recap with clueless crypto engineer deleted> OK, so why don't we pool our funds to encourage the reverse engineering and release of source code to a popular PCS/GSM phone which can be readily re-flashed and with sufficient resources (or easily augmented) to handle this app? I'll donate $100 e-gold to get the fund going. I'll establish a publicly viewable e-gold account to hold other contributions. The account access key can be secret shared among a few fellow CPs. steve
What about the possibility of doing encrypted telephony stuff in Java? As many have pointed out, sound programming is highly non-portable among Unices and Windows. However, Java has standard ways of doing that, so maybe it is an option. I know that Java isn't fast, but hardware is getting faster every day. Also, the heavy-lifting stuff (the compression and encryption) could all be written in C, which would be completely portable, and linked in using JNI, right? Java also has all the powerful network libs already built in. If there were an app like SpeakFreely in Java, it would run on a lot of different systems.
participants (4)
-
Dr. Evil -
Lucky Green -
Ryan Lackey -
Steve Schear