Forgot your password?
typodupeerror

Company Makes Inconspicuous Secure Cellphone 328

Posted by ScuttleMonkey
from the price-tags-that-probably-cause-physical-pain dept.
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."
This discussion has been archived. No new comments can be posted.

Company Makes Inconspicuous Secure Cellphone

Comments Filter:
  • Re:unbreakable? (Score:5, Informative)

    by Bromskloss (750445) <auxiliary DOT ad ... privacy AT gmail> on Tuesday May 23, 2006 @04:51AM (#15385596)
    isn't WEP also 128 bit?
    WEP isn't insecure due to its 128 bits, but due to other problems [wikipedia.org]. As I understand it, anyway.
  • by fe105 (146603) on Tuesday May 23, 2006 @05:09AM (#15385660)
    Cryptophone is a company that has been making phones like this for some time already.

    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)

    by Kaptain_Korolev (848551) on Tuesday May 23, 2006 @05:13AM (#15385674)
    Reading the comments made me cringe, so here goes....

    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.

  • by bananaendian (928499) on Tuesday May 23, 2006 @05:22AM (#15385703) Homepage Journal
    The pin number is something you input on the phoneset to get physical access to the crypto software. It has nothing to do with the over-the-air encryption.
  • by Stellian (673475) on Tuesday May 23, 2006 @05:24AM (#15385714)
    First, you can recognize your peer's voice. As for the man in the middle, for real time, voice conversation, the delay would be too big to go undetected.

    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.
  • by ajs318 (655362) <sd_resp2@@@earthshod...co...uk> on Tuesday May 23, 2006 @06:08AM (#15385818)
    Not quite. The 900 and 1800MHz bands are used by different service providers. In the UK, 900MHz is used by Vodafone and O2, and 1800MHz is used by Orange and T-Mobile. Before the advent of the venerable Nokia 3210, most phones were single-band and were built using two PCBs: one for the main processor, audio circuitry, keypad and display, and one for the RF stuff {which would be made in 900 and 1800 versions and the phone assembled accordingly}. The 3210 used a single PCB capable of doing both RF bands. The cost saving associated with the single-board design {no expensive multiway connectors, and a better process hit rate} outweighed the cost of the extra components.

    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)

    by martingunnarsson (590268) <martin&snarl-up,com> on Tuesday May 23, 2006 @06:13AM (#15385831) Homepage
    A Swedsh company called Sectra has made secure cellphones for years. Their latest model is the only cellphone certified to the security level NATO SECRET by NATO.

    http://www.army-technology.com/contractors/navigat ion/sectra/ [army-technology.com]
  • by ajs318 (655362) <sd_resp2@@@earthshod...co...uk> on Tuesday May 23, 2006 @06:26AM (#15385854)
    This is how it's supposed to work: Alice calls Bob. Bob answers. Alice generates a key pair and sends one of the keys to Bob, keeping the inverse. Bob also generates a key pair and sends one to Alice, keeping the inverse. Alice encrypts everything she sends against the key she received from Bob. Bob decrypts it using the inverse key he generated. Bob sends everything to Alice encrypted against the key Alice sent him. She has the inverse key and can decrypt everything Bob sends.

    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.
  • by jthill (303417) on Tuesday May 23, 2006 @11:24AM (#15387273)
    Fortunately, you're wrong.

    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.

  • by Anonymous Coward on Tuesday May 23, 2006 @12:36PM (#15387881)
    "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."

    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.

"When it comes to humility, I'm the greatest." -- Bullwinkle Moose

Working...