Company Makes Inconspicuous Secure Cellphone 328
dponce80 writes "With concerns over privacy at an all-time high, it's refreshing to hear that Swiss company VectroTel is making a secure mobile phone. The X8 encrypts secure calls (the unit is also able to make regular calls) with a virtually unbreakable 128-bit key, itself generated through a Diffie-Hellman exchange. While transmission does get somewhat delayed, communication is secure."
Re:unbreakable? (Score:5, Informative)
Why not get one from cryptophone.de? (Score:5, Informative)
They employ some of the smartest crypto people, use well-known algorithms and publish their sources so you can check them yourself.
Some points... (Score:5, Informative)
Some points;
- 128 bit keys are probably good enough, depending on the nature of the conversation. Diffiehellman generates a per-session master secret. To this you would then apply a KDF ( Key Derivation Function ) in order to produce your session key for use with your symmetric cipher, most likely AES or 3DES, maybe even TwoFish. A new master secret is generated every time you make a call, hence the session key changes per call, this is UNLIKE your WEP key, which is constant or one value selected from a set. The consequence of this is that although it is practical to break an 128 bit symmetric key, it is NOT practical to do so in the time interval in which the call is taking place. Hence the encryption applied is strong enough for protecting calls in the short term, although if someone captured the call they could possibly decrypt it at a later date.
- GSM does feature limited cryptography. Unfortunately, and rather amusingly this encrypting is only carried out on radio traffic. Once the data reaches the base station / cell, it is sent in the clear around the cable cellular netork's backbone infrastructure.
Re:need to ask Bruce on this one.. (Score:3, Informative)
Re:What about authentication? (Score:3, Informative)
Funny guy.
Just in case you were serious, a MIM attack against this phone would tap in the data path with 0 delay, there is no need for an actual "man" in the middle. Eve makes the key agreement with both Alice and Bob (different keys), and then decrypts and re-encrypts the data stream on the fly.
Re:Feasibility for US Market? (Score:5, Informative)
A phone connected to a base station will always us one or the other band. But within each band there are several channels; the phone and base station automatically select the best channel continuously throughout a call {if another subscriber disconnects and the channel they were using is better, your conversation will switch to that channel}. The whole process is kept seamless because both phone and base station change at the same time, between data packets.
Sectra Tiger (Score:5, Informative)
http://www.army-technology.com/contractors/naviga
Re:What about authentication? (Score:5, Informative)
All clear now? Well, this is how it might work in practice, with a malicious interloper we'll call Mallory:
Alice tries to call Bob. Mallory intercepts the call, pretending to be Bob; gets the key Alice sends, and in return sends her a key {which Alice thinks is from Bob}. A fraction of a split second later Mallory places a call to Bob, pretending to be Alice, and sends Bob a key. Bob thinks Mallory's key is really Alice's key and sends a key to "Alice". Whatever Alice says is encrypted against the key sent to her by Mallory, who -- having the opposite key -- can decrypt it, re-encrypt it against the key which Bob has, and send it on to Bob. Mallory has a nice, fast computer that can do decryption and re-encryption in real time; in reality, it only has to be twice as fast as the processor in either of their telephones. Whatever Bob says is encrypted against a key sent to him by Mallory, who can decrypt it and re-encrypt it against Alice's key. Mallory has both sides of the conversation, in the clear, and neither Alice nor Bob are any the wiser.
Re:What about authentication? (Score:3, Informative)
The crucial requirement is that you can verify your partner's identity regardless of the security (or lack thereof) of the current conversation. Recognizing something unforgeable about them will do it: their voice, in this case.
This works because, in order to establish communications at all, each party has to split a secret:
AB' <—> A'B
A' being the public part of Alice's one-time key, B' Bob's. AB' can be used to generate the same key as A'B: each end is using the other's public part to share the key being used over that channel. Here's the thing: B' is already public. So, Alice's phone simply shows it to her, and she reads it aloud over the supposedly secure channel.
Now: if there's a man in the middle, Alice is really using AM', and Bob is really using BM'. Which means that when Alice reads it, Bob can tell that it's her voice, and she's not using what he sent her. So the man in the middle's screwed: if he doesn't pass along B' to be used in the conversation, he'll be detected. If he does pass it along, he won't be able to eavesdrop.
There are simplifications in this description, and they leave vulnerabilities that you can spot if you think hard enough. But if you're thinking hard enough to spot the vulnerabilities, extending the idea to cover them will be easy.
Re:What about authentication? (Score:1, Informative)
This is the purpose of the key hash displayed to the user. This hash is simply a number generated by hashing the session keys being used. Since it is a hash and not the actual key, it is safe to read out loud to each other. If the numbers are the same on both ends then there is no man-in-the-middle (because a man-in-the-middle has different session keys with each of the two users). It is also virtually impossible to detect when the users are reading their hash digits to each other, so the man-in-the-middle would have a very difficult time impersonating each users voice and reading the same hash back to the other user. I doubt it is possible to do this sort of speech recognition and impersonation, but maybe with a powerful enough computer it could be done.