Start using IV in AES encryption?

[Anticimex]

And if it is static, it can just be done during an init phase, right? So it should then not steal any more payload after that. Or does it have to be part of every message, and unique for every message?

[mfalkvidd]

I think it can be done in the init phase. (See https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29 - the IV is only used for the first block.)
However, the gateway would then need to remember the state for all nodes. If a packet is lost, the encryption/decryption get of of sync. If the gateway or a node is restated without saving+loading the state to/from reliable storage, the encryption/decryption gets out of sync. I think it can be done, but it will require some thinking.

The current implementation avoids having to keep state by starting from zero for each packet. That's also what's lowering the security.

[Anticimex]

Hm. Wonder how rf69 solves that. By always including IV in the payload?

[mfalkvidd]

I think so. I don't see any other reason why they are limiting the message size when using AES (compared to sending without encryption).

[Anticimex]

Well, I was not even aware that message size decresed for rf69 in that case. But is it still >=32B? Else things would probably break for signing as it claims all area up to MAX_MESSAGE_LENGTH (unless that value also adapts)

[mfalkvidd]

From the rfm69 datasheet section 5.5.2. Packet Format:

The length of the payload is limited to 255 bytes if AES is not enabled else the message is limited to 64 bytes

[Anticimex]

Ok, good. I wonder if they just randomize the IV then and send it as part of the message. I don't see that improves security by much since anyone can listen in and obtain the same IV.
It also makes the solution stateless, but I think there should be a handshaking anyway then. But I don't really know how it should be handled without causing too much trouble.

[mfalkvidd]

It does provide security. Since the IV is XORed with the plaintext before encryption, two different IVs applied to the same plaintext message will result in very different ciphertext. One bit change in the IV should flip half the bits in the ciphertext, on average. Since the attacker doesn't know the plaintext, knowing the IV is useless. That's why the IV is designed to be be sent in the clear.

[Anticimex]

Yes and no. Yes, it does add security. But plaintext can be predictable. Especially during node startup. So an attacker can figure out both IV and plaintext. It is the AES key that is secret and it takes some work to derive it.

[mfalkvidd]

The attacker doesn't need to figure out the IV, it is always available in plaintext in the radio message.

Yes, timing analysis at startup and other sidechannel attacks can help the attacker figure out what the plaintext is anyway. That's one of the reasons I don't care that much about encryption.

[Anticimex]

Same here. The only usable use for encryption I see is audio/video streams, and the mysensors protocol is suitable for neither.

[mfalkvidd]

I suggest that, unless someone else chips in in this discussion, we'll just note that the encryption has a (/one more) weakness. I might pick this up later on (it is definitely an interesting exercise), but I have projects that are more fun and useful that I prefer spending time on at the moment.

[Anticimex]

I share your view.

[mfalkvidd]

Oh, and thanks a lot for the feedback @Anticimex :star:
Having someone asking the right questions makes a big difference.

[Anticimex]

Well thanks for identifying the issue and a good explanation on why it is an issue.
Having read through your initial posts once more, however, I think I found a minor detail that you may have gotten wrong.
The message header also contain sender, so although you would be able to recognize ON command from a particular bode, you would not automatically know the command from other nodes as the header would differ.

[mfalkvidd]

Oh. I thought the sender was part of the unencrypted header.

[Anticimex]

I believe the entire message is encrypted. As far as I know the physical parts of both radio are multicast, and all data transfered, that is visible in the MySensors library, is MySensors specific and used for MySensors specific routing and such.

[mfalkvidd]

Alright. Then the zero IV becomes even less of a problem yes.

[ahmedadelhosni]

I am not an expert in encryption but I really like your discussion.

I believe as you have said, signing is the most critical issue to focus on now, and also we can't neglect encryption in the future.

Thanks for your effort.

[sundberg84]

No knowledge in this but i appreciate you guys (which know more) are having this discussion.

Not Mysensors, but it could be i guess - yesterday my RFLink (433mhz) told me it found a new device, a code for a on command. A quick search on the internet revealed it belong to a home alarm manufacturer which has 2 items sending 433mhz, their wireless motion detectors and a on/off remote for the alarm...

I guess I could do some damage with this...