3

I just took over two radio systems (using 433Mhz) - one communicates with 6 bit messages, one with 14 bit messages. Both have a lots of transmitters and one receiver (and, yes bits not bytes).

For the first, 4 bits are used for the ID of the device, and 2 bits for other info. For the second, 10 bits are used for the ID of the device, and 4 bits for other info.

They work completely independent - all they have in common is that the messages are very small and are sent in CLEAR.

Now I have to implement authenticity/confidentiality/integrity for these messages - but I have to keep them short (as for the second system far less than the max 2^10 devices are already jamming each other)

I haven't decided yet, if it is better to use one key for the entire system, or one key for each transmitter. (for both situations, the keys will be considered known for both transmitter/receiver)

I agree with "don't implement your own security", so I have read about different standard solutions, but the end message gets monstrously big and I cannot use them.

What algorithms/combinations would give me the smallest size for the resulting message but with also a reasonable security?

P.S. I was thinking about a solution using umac, as you can get away with non cryptographic hashes which are smaller.

Edit: To be more clear - I don't want for a third party to:

  • read the info part of the message (the ID part can be public)
  • emit messages and the receiver not to detect that are not from his system transmitters
  • replay a previously valid message and the receiver not to detect that

Edit2: There is no time for either of the devices.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
Victor Iorinescu
  • 71
  • 3
  • 2
    Define your threat model, and in particular what the adversary knows. In particular, can s/he extract any secret a receiver may hold? That might limit what you can achieve in term of confidentiality, and complicates authenticity/integrity. Also, are communications two-way? Do you need to protect against replay?.. – fgrieu Apr 26 '18 at 16:31
  • 1
    @fgrieu - I specified that there are many transmitters and one receiver - so one way communication. At this point an attacker not only can read the value that a transmitter sends, but also it can transmit his own messages with no way for the receiver to know that it is a fake message. Also a replay attack must be prevented. – Victor Iorinescu Apr 26 '18 at 17:06
  • 1
    What does the memory for the Systems look like? Is it possible for the radio systems to store a Message Digest for each previously seen message? And without a time stamp, it seems quite to differentiate a previously valid message with a new message of the same message content. (A timestamp would be at least 16 bits) – Haris Nadeem Apr 26 '18 at 18:31
  • The receiver can store 3 bytes for each transmitter - which means that a 3 byte incremental nonce could be used. – Victor Iorinescu Apr 26 '18 at 18:52
  • 2
    You realise that you've clicked the AES & HMAC tags? That's a couple hundred bits per message already. Is that what you're thinking? – Paul Uszak Apr 26 '18 at 20:46
  • Edit 2: there is no real time clock (RTC) for either of the devices? – Maarten Bodewes Apr 26 '18 at 22:23
  • Yes, no RTC for either of the devices. – Victor Iorinescu Apr 26 '18 at 22:40
  • @paul-uszak about AES - not sure; about HMAC - most likely UMAC, but there was no tag for it and I was not allowed to create a new one. – Victor Iorinescu Apr 26 '18 at 22:45
  • 1
    There is just not enough room in the info part to implement any kind of security, except possibly some kind of confidentiality by directly encrypting with a stream cipher. But maybe you could group a lot of messages together to give yourself some lean-way. Because you can forget cryptographic message integrity / authenticity in just a few bits. If I knew how to do that I'd be very rich! – Maarten Bodewes Apr 26 '18 at 22:48
  • 1
    Just joking about the UMAC tag, I just added it of course. Feel free to propose a UMAC tag wiki! – Maarten Bodewes Apr 26 '18 at 22:59
  • @maarten-bodewes The size of the message is not fixed - if necessary I can increase it with random data. I am aware that the secure message needs to be much larger, but I was hoping to stay at the minimum possible - maybe 64 or 96bits - max 128 bits. – Victor Iorinescu Apr 26 '18 at 23:27
  • @VictorIorinescu How much traffic is there going to be? Secondly, you are aware that it is illegal to send encrypted radio messages in certain countries? – Patriot Jul 28 '19 at 02:01
  • @VictorIorinescu If your threat model is extremely high, you have significant cost restrains, and the amount of traffic is very low, I will answer your question. – Patriot Jul 28 '19 at 02:04

0 Answers0