Transport encryption

[andrew-ws]

What is the chance of having transport encryption implemented in this firmware? I looked at implementing it myself but from what I could tell it seems a bit difficult to do anything more complex than ECB the way that things are currently implemented. I'm not very experienced writing firmware, though, so maybe I'm wrong.

[rossica]

I have a fork with transport encryption implemented using the Gazelle encryption library, however, I'm stuck as I can't see any of my debug statements and it's not working. I'm rather new to embedded programming, so any pointers on how to debug it and I'd happily make a pull-request once I fix what's broken.

[Detegr]

I got encryption working based on @rossica's code. I haven't been able to actually test it as I'm still missing a couple of components from the receiver. With debugger+logic analyzer it seems to be working. You can find the code from my fork.

[andrew-ws]

I can give it a test later today, but just to be clear this is still just ECB at this point, correct? Definitely much more secure than before but I'd like to know if replay attacks are still viable (although an attacker would still need to be physically close to the receiver and keyboard so it's a pretty far-fetched risk).

[Detegr]

The library uses dynamic key exchange and session tokens to prevent replay attacks. However, the code does not update the dynamic key after paired. I think this is not a problem as long as the dynamic key is not compromised because of the session tokens making every packet different from others.

[andrew-ws]

That sounds great! I'm having a bit of trouble testing, though, would you mind adding a bit of extra detail about the compiling and pairing processes? Since there's no info on the compilation process I'm worried I'm making a mistake there. Also, it looks like you need to hold down the pair button on the receiver while holding a key combination on the boards to start the pairing, but I can't figure out what that key combination is.

[Detegr]

The compilation should have no differences now (I just updated my fork). Have you been able to compile this repo?

I'm using Chimera Ergo as the keyboard for this firmware, and the key combo is the two function keys in that keyboard. Unfortunately I'm not sure which keys it maps to for Mitosis. If you have a multimeter, you can check that with a pinout picture. The pins are defined in config/mitosis.h.

[andrew-ws]

I found the keys, it's the outside (left for left board, right for right board) two on the bottom row of the command cluster. From the code it seems like the pairing process is: bring the receiver and one side of the board close together, hold the pairing button, hold down the two pairing keys on that board, and from that point on it should just work. I seem to be able to flash without any problem, and the receiver at least is recognized, but that's about it. No way to tell if it's successfully paired or not, etc. Confirmed that everything I'm doing compilation-wise works for the reverse-bias version, so I don't think that's the issue. Seems like it's not possible to flash the LED in this code, but is there any other particularly good way of debugging? Started looking into connecting GDB to the OCD, but I don't want to put in the work figuring that out if there's an easier way.

[Detegr]

You're right, there's no way to know whether the pairing was successful or not. Unfortunately there's no way to control the led on the 51822 side. In my opinion using gdb with openocd is the best way to go.

I finished my receiver yesterday and I got it working with the transport encryption, so I'm not sure why yours did not work.

[Detegr]

After testing more I found out that the pairing is indeed quite unreliable. Sometimes it works, sometimes it does not. I'll need to debug this more.

[Detegr]

Unfortunately, according to this, there is no way to connect two dongles simultaneously when both are using the pairing library for encryption.

[rossica]

Aww, that's unfortunate. I've been working on designing a cryptosystem that doesn't depend on pairing. I'll have a PR for that in the next month or two.

…

On Tue, Jun 5, 2018, 10:11 AM Antti Keränen ***@***.***> wrote: Unfortunately, according to this <https://devzone.nordicsemi.com/f/nordic-q-a/18344/how-to-use-gzp-for-one-nrf24-dongle-to-pair-two-nrf52>, there is no way to connect two dongles simultaneously when both are using the pairing library for encryption. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIJcYmLpHws9Jfc096XEDL86M3ol52Dkks5t5rvAgaJpZM4SRvxM> .

[Detegr]

Any updates?
I am thinking about building an extra receiver and using one receiver per keyboard half to be able to use the pairing library.

[rossica]

I've been swamped with work and haven't had time yet to code up the new encryption. I'll have time in December to do it. I'll update then.

…

On Thu, Nov 15, 2018, 11:07 AM Antti Keränen ***@***.*** wrote: Any updates? I am thinking about building an extra receiver and using one receiver per keyboard half to be able to use the pairing library. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIJcYmzs-CgLfddDYsylOj2FnCcKjU0_ks5uvbtUgaJpZM4SRvxM> .

[Detegr]

I did some tests, and it seems that using two receiver dongles, one for each half, works and the GZP pairing library can be used to pair the devices and secure the communication.

Edit: Further testing shows that using two dongles is not actually going to work. Running two QMK's at the same time leads to all kind of synchronization issues.

[sigboe]

Yay great to see this, I just started a new job and wanted to start ordering parts this Christmas. But we got a (soft) ban on wireless keyboards, and I spoke to the security officer and he said I could go ahead as long as it has proper encryption.

Is this close to being merged? Could someone draw up a diagram how and why this is secure?