Start using IV in AES encryption?
-
Hi.
I was browsing through the MySensors code and stumbled on something.
To my knowledge, and according to some sources (see below), using a predictable IV for AES CBC is bad.MySensors uses 0 for all IVs. Always. See
https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/core/MyTransportNRF24.cpp#L91I know getting randomness on an Arduino is a bit hard (see the whitepapers referenced here), but maybe we could at least use the same mechanism used by the soft signing implementation? Maybe add continuous re-seeding since one analogRead doesn't provide that much entropy?
A change would break compatibility with the current implementation though, so it would need to be communicated clearly and done in a release where backwards compatibility isn't guaranteed (1.6? 2.0?). Maybe it should be done in two steps, where the first step adds support for de-crypting with IV and the next step adds support for encrypting with IV?
We'd also need to transmit the IV, which will be hard I guess due to the relatively small packet size of the nrf.
Sources:
https://defuse.ca/cbcmodeiv.htm
http://crypto.stackexchange.com/a/5191
http://stackoverflow.com/a/2648345/603901
http://crypto.stackexchange.com/a/18401
-
Does that affect the AES encryption in the RFM69 radio as well?
-
Rfm69 encryption is done in hardware. The rfm69 datasheet does not explain the encryption in detail, but the max message length for encrypted packets is shorter than if encryption is not used, which suggest that the IV is included so rfm69 could be doing the right thing.
The rfm69 and the nrf24 encryption are not compatible, so changing nrf24 won't affect rfm69.
-
I thought I'd explain a bit more what the problem is. The reason for encryption is that the user doesn't want an unauthorized user (example: neighbor) to be able to get the contents of the messages.
Since the IV is always zero, if the first 16 bytes of plaintext message is the same for two messages, their ciphertext will be identical. So the neighbor doesn't know the contents, but they do know that they have seen that message before. If the neighbor can observe your light going on when one node sends "ON", they know what an ON message looks like and now know that all other ON messages, form any node in the system, will look exactly the same. So now the neighbor knows when things are turned on, which is exactly what we wanted to prevent by using encryption.
(Note that spoofing messages isn't discussed, as signing and encryption are different things. This has already been explained in length by Anticimex in the signing thread)
However, signing might help. If signing is used, and the message is short enough, the signature will occupy part of the first 16 bytes. Since the signature is different for each message, the first 16 bytes of the message will vary. So using the same IV is less of a problem.
This means that, if signing is used, we only have a problem for payloads larger than 16 bytes (or slightly less, since there will be more variation in the first 16 bytes for every bit of signature that is included in the first 16 bytes). How common are these payloads?
-
@mfalkvidd This is a great find! I am not too well educated on AES and it's initialization vectors (and after all, I have not dabbled with encryption in the library at all). Since you (I suppose) have the setup to test, would it be possible for you to file a PR with a suggested fix?
-
@Anticimex said:
@mfalkvidd This is a great find! I am not too well educated on AES and it's initialization vectors (and after all, I have not dabbled with encryption in the library at all). Since you (I suppose) have the setup to test, would it be possible for you to file a PR with a suggested fix?
I don't have a setup to test unfortunately. I just found this when browsing the code (strange habit, I know
). I don't even use signing yet, which is fare more important than encryption I think.I can probably code the necessary changes, but since using nonzero IVs would break compatibility with the current encryption implementation I'd like a discussion on how to proceed first. How do we break compatibility and when? The nrf message size is already limiting the length of the signature so adding an IV as well will be problematic. Should we re-order the field order so the signature always straddles the 16 byte block boundary, to provide entropy to both blocks? That would break compatibility for signing as well, which is bad, but would not add to the payload size.
-
As for compatibility, there is no worries. Any development is done on the development branch which is currently so volatile that the next major release will be 2.0.0.
As for the IV, is this something that needs to be handshaked, or is it just part of the encrypted payload?
Code should use the MAX_PAYLOAD to determine the permitted size of a payload (signing backend also uses MAX_MESSAGE_LENGTH as it claims all available message space).
If encryption (RF24 variant that is) is used, I think it should just adjust these definitions accordingly to accommodate for the IV. However, in doing so, IV will be put last in the RF payload and will not be signature covered (if signing is used) so some more logic will be needed in the signing backends to handle that. But as there is a preprocessor definition indicating if RF24 encryption is used, I see no big technical challenge in handling it.
I don't unfortunately have the time to do that myself at the moment however. But I will gladly review any code in due course and give feedback. I try to limit my focus to signing and leave encryption up to others
-
The IV is sent in clear text. No handshake needed. However, the IV is supposed to be 64 bits and stealing 8 bytes from the signature would weaken the signature significantly, wouldn't it?
If signing isn't enabled, sending the IV isn't much of a problem I think. There should be enough headroom to just add it as you suggest.
If signing is enabled, maybe we ca re-use the nonce as IV. The nonce is already there, and it is authenticated, so we might as well re-use it. I'd have to read up on the signing protocol first though.
I totally agree with prioritizing signing higher than encryption. Encryption isn't on top of my priority list either. I just thought I'd start the discussion since I found a problem. In the end, we might very well agree to leave encryption as it is until someone is interested enough to dig further.
-
Using the nonce is an option then. But it should then only be used if a message is successfully validated using that nonce. And I suppose after that be cached for encryption use since not all messages are signed, but all are encrypted.
-
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?
-
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.
-
Hm. Wonder how rf69 solves that. By always including IV in the payload?
-
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).
-
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)
-
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
-
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.
-
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.
-
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.
-
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.
-
Same here. The only usable use for encryption I see is audio/video streams, and the mysensors protocol is suitable for neither.
-
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.
-
I share your view.
-
Oh, and thanks a lot for the feedback @Anticimex
Having someone asking the right questions makes a big difference.
-
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.
-
Oh. I thought the sender was part of the unencrypted header.
-
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.
-
Alright. Then the zero IV becomes even less of a problem yes.
-
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.
-
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...
-
@sundberg84 yet another example of the incompetence of security providers for private homes. They are useless.
-
@ahmedadelhosni signing just underwent a major overhaul recently on development branch. We are also looking into a node locking mechanism when the node suspects it is under attack from someone trying to brute force a signed message or trying to predict nonces calculated from a bad rng implementation. So security is very much being looked at. And even with missing IV, AES encryption would add some obfuscation to the messages and will in combination with signing still deter a lot of potential attackers.
