0

Specifically talking about walkie talkie radio networks. Suppose there is a group of up to 16 persons, each equipped with such a unit. Typically, one person will be talking with one another (one-to-one), or one person will be broadcasting to all the others members (one-to-all). The goal is to secure and authenticate all the communication between them.

I thought about the following:

1) Each user will have a predefined public/private key (e.g. RSA). 2) There will be a predefined symmetric key (e.g. AES-128 bit).

Voice streams will be divided into 128-bit segments. Each segment will first be encrypted using AES 128, then hashed using SHA-256, and the hash will be encrypted using user's private key, and this signature will be sent along with the encrypted message. The reciever will first hash the message, and then decrypt the signature using any of the 16-1 public keys he have. Ideally, one of them will 'work', authenticating the message. Then he proceed to decrypt the message.

Is there any "clear" vulnerability in this protocol?

P.S. I am aware of other used protocols, e.g. P25, but will prefer to implement my own.

4

First thing to do is define what you mean by "secure and authenticate". You need to put into words who the attackers are, what they can do, and what they should be prevented from doing.

On example of such an attack model is the following:

  • Attackers are outsiders. They eavesdrop on the common channel (the radio waves). They want to obtain the confidential data that the group members exchange with each other. The group members trust each other.

If that is the attack model, then it suffices to come up with a shared secret K, that all group members but no attacker knows, and then encrypt packets with some symmetric encryption algorithm (say, AES in a suitable mode) using K as key. Initial distribution of K can be done by having each group member own a RSA key pair; one group member generates K randomly, encrypts it with the public key of each group member, and broadcasts that.

Now let's extend that attack model into another one:

  • Attackers are outsiders. They eavesdrop on the common channel, but will also attempt to send fake messages, sometimes replaying previous messages, with or without alterations. Such fake/replayed message instances shall be reliably detected and dropped by group members.

Now you also need a MAC for each packet (so that the attackers can only replay previous packets, not create new ones or alter existing packets), and some sort of connection context so that replay attacks are detected. This can be done by embedding a sort of time stamp or counter in each packet: each participant remembers the counter values for the last packets received, rejecting packets which have already been seen or which have a "too old" counter value. Such mechanisms are often called window-based and there is some balance to strike between replay attack prevention, memory requirements (to remember past packets), and tolerance to packet loss due to the unreliable nature of the transport medium. Peruse DTLS as an illustration of how the SSL/TLS protocol can be adapted to packet-based unreliable mediums.

If the attacker is allowed to try to send fake messages, then he might also be able to advertise a fake RSA public key. Distribution of public keys is a matter of Public Key Infrastructure, with certificates being the usual solution.

Maybe we want more ? E.g., what about the following:

  • Group members are attackers too. Each group member will try to eavesdrop on and/or interfere with one-to-one communications between other group members.

In that case, you will need pairwise key exchanges. For any pair of group members A and B, there must be a shared secret KA,B that other group members and outsiders do not know. This can still be leveraged from pre-distributed RSA Key pairs: when A wants to talk to B and they don't already have a shared secret (or they forgot a previously shared secret, e.g. B rebooted his computer and that shared secret was in RAM only), then A generates a new random key KA,B and encrypts it with B's public key.

There again, read up the complete TLS and DTLS standards: they are quite readable, and that will show you what you have to think about.

0
  1. Signing each block of ciphertext will create a massive overhead and after all result in a slow transmission of the voice recorded.

  2. Your protocol does not involve correct authentication. The use of a fixed AES key and no IV (appearently) leaves very much room for an attacker to forge messages or to evasdrop the plaintext. Make sure to authenticate before sending (and verify the signature of one entire message, e.g. 1/2 second of audio), use a protocol such as Diffie-Hellman to agree on a shared key and use a sufficient Block-Chaining as well as an IV.


If you plan to use this protocol with acutal walkie talkies you have to consider that fixed private/public keys can only be used for one set of units and that this set of units is not expandable (since crypto walkie talkies that require the customer to read/write the keys would not be used somewhere else than in e.g. the army).

  • I am authenticating each received 128 bit of encrypted data. OK, I can change that to, e.g., 1/2 sec of encrypted data. But "Make sure to authenticate before sending" ?? what do you mean? – student1 Jul 19 '14 at 16:44
  • You do not really authenticate each block. You check 16 different private keys to match. If one of them leaks the attacker can forge messages. Exchange a key between two units and authenticate that key (see Diffie-Hellman with authentication) and check the signatures against the one and only key of the other unit. That is way more secure and allows to "disable" a lost/stolen unit. – marstato Jul 19 '14 at 17:07
  • OK, so the sender will randomly generate a symmetric key. Then she'll use it to encrypt (AES-256) her message. She'll also encrypt (RSA) the key using her private key, and append this to the encrypted message, and broadcast it. Still, the receiver has no idea who (among the 16-1 other users) send the message, and need to decrypt the key up to 15 times (in worst case). – student1 Jul 19 '14 at 17:48
  • I think there's something wrong in my comment above. Actually the sender needs to encrypt the symmetric key using the reciever's public key. But if you have multiple receivers then...? – student1 Jul 19 '14 at 19:07
  • For Multiple receivers it becomes complicated. You can either think up a way to derive session keys so that all units know the same key (but that key changes over time). Or you can use identity based encryption: computerworld.com/s/article/328729/Identity_Based_Encryption – marstato Jul 19 '14 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.