Security about keyplus HOT 4 CLOSED

you mentioned that the firmware can be updated wirelessly

Actually the firmware and layout can only be update over USB. I don't allow wireless updates because, as you suggest, it opens up potential security holes. What I meant to imply in that post, is that applying security updates would be difficult for most people if they had to recompile the firmware themselves. So I wanted to separate the layout from the firmware to make security updates easier for the end user.

What is the wireless protocol currently doing for security?

The wireless protocol uses AES128 for encryption and should be resistant to eavesdroppeing, replay attacks, and key stroke injection. For the AES block mode, I use ECB block mode with a unique packet ID (UID) inside each block (similar to CTR block mode, except the counter is a part of the plaintext). The UID is implemented as the device ID + a packet counter.

1. Prevent eavesdropping: Usually ECB is not used in most encryption protocols as it is vulnerable to frequency analysis attacks because the same plaintext block will always encrypt to the same ciphertext block. However, since the plain text of each block contains a UID, this means that the cipher text will also be unique. Thus it is not possible for a passive eavesdropper to use ferquency analysis to infer typed keys from observed encrypted messages.
2. Replay attacks: Whenever a message is received from a device, the UID in the block is checked. If the counter part of the UID is smaller the most recently seen UID form that device, the packet is rejected as the device will never send the same UID in a packet twice. When a receiver is first turned on, it will request the current UID value of slave before accepting any communications. To insure that the UID value received form this request is authentic, a challenge-response aunthentication is used that relies on both device's using their pre-shared AES key to prove authenticity.
3. Key stroke injection: Using the ECB block mode with UID, it is possible to detect if messages have been tampered with. If an attacker where to try modify some bits in an intercepted cipher text, then according to the properties of AES, on average half the bits in the plain text would be flipped. This means that the UID will be changed to a random value. However, the code only accepts small increments in the UID's counter, so it will reject the packet as corrupt. If too many corrupt packets are received, the receiver will require the device to pass the challenge-resoponse authentication again before more packets are accepted.

If you have any questions or concerns about the protocol feel free to ask.

from keyplus.

I'll probably revisit this post someday after I read Cryptography Engineering, but this looks solid to me. You're clearly putting security first, which is so great to see!

Two more questions, and I'll close the issue.

• How is the AES key distributed?
• Do you have any protections in the bootloader against an attacker rewriting the firmware via USB?

from keyplus.

How is the AES key distributed?

The AES key is saved in the RF settings file (example) and the user will upload this to each device in their wireless configuration, over a USB connection using the GUI flasher/loader.

The RF settings file only needs to be loaded once. Afterwards the user can update their layout without it. I'd suggest you keep it in a password manager vault or similar safe location because it contains the AES key.

After the AES key is initially programmed, there is no way to retrieve it from the device. If the user loses there RF settings file, then they will have to generate a new one.

Do you have any protections in the bootloader against an attacker rewriting the firmware via USB?

The bootloader I wrote for the ATxmega will only allow reads/writes to flash after it has erased the entire application section (where the encryption key is stored). Also, when the bootloader starts, it will erase the entire contents of RAM before allowing the application code to start. This prevents newly loaded programs from trying to extract the encryption keys from RAM.

I have not finialized the nRF24LU1+ bootloader.

Also, I have to worry about the behaviour of the logitech bootloader when running from unifying receivers. The unifying receiver bootloader does not erase the entire contents of flash, but it does clear the first half of the flash (it divides the flash into a data and code section and it only clears the code section). So when using it, the settings block must be stored in the code section of flash, which is not much of an issue since there is nothing preventing the firmware from reading/writing to that section.

from keyplus.

Your answers here, and everything else about keyplus and the keyplus mini just look really, really amazing. Keep up the great work!

from keyplus.