Gazell Encryption

[barneycg]

Since this seems to be more active than the Mitosis code base that this is based on I'll add this here :)

As things stand there is no encryption on the gazell code being used here. Using the in built Gazell pairing isn't suitable in this use case as it only provides a single encrypted pipe (as in one side would be encrypted while the other would have to be un encrypted). This means that some code will be needed to handle adding encryption/decryption onto both pipes being used here.

The counter argument I made on the Mitosis issue tracker is that you are not transmitting "The H key has been pressed" but a matrix of the state of the keys, and it is the Pro Micro that is turning that into a specific character. Given this how much extra security are you gaining by encrypting this transport ?

[mattdibi]

I'm no security expert but I'll try to answer the question.

Depending on the encryption algorithm it should be pretty safe. My biggest concern would be battery life, any encryption algorithm that isn't trivial would take a heavy toll on power consumption.

Furthermore, given the fact that the keyboard range is ~2m, is the encryption really needed?

[barneycg]

nrf51822 has built in hardware aes encryption when using the pairing extension of the Gazell protocol but the provided SDK only encrypts PIPE 1. I've looked at the SDK and I reckon it it could be modified to allow multiple Pipe Encryption but not sure if it also needs the pairing part modified too. No idea of the battery cost though, would need to see if it could be implemented first to do some testing :)

[rschrader]

Is this ticket closed because its not wanted to have such a feature? I am also interested in AES encrypted communication. Maybe i can implement it starting with a pre shared key so that we dont need to adapt a handshake but only encrypting the payload. This would at least give a hint how much energy is needed for encryption.

[mattdibi]

Hi, I closed this for inactivity since I hadn't the time nor the knowledge to implement it. If you want to implement such a feature, feel free to do it :) any contribution is welcome.

I would suggest to keep the code featuring encryption separated from the vanilla one until we have some figures for power consumption. A new branch should do. What do you think?

[rschrader]

Sounds great! Do i have permissions to create a branch in the repository? Otherwise i could also create a fork to start coding and create a pull request as soon as i have some serious data about latency and power consumption.

I still wait for the parts for my redox-w. As soon as i have all the stuff i will start working :).

[mattdibi]

I created the new branch, you can make a pull request on that once you have something. :)

[LucidityCrash]

take a look here https://github.com/rossica/mitosis/tree/feature-crypto

Rossica has implemented some encryption functions ... might help some ?

[LucidityCrash]

Been looking at the NRF5 SDK this morning ... looking at v15 there are some nrf_crypto functions now ... could the code be updated to work with the new SDK and utilise the built in crypto functions ?

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.2.0%2Flib_crypto_config.html

[mattdibi]

The only way to know is to try. If I find the time I'll give it a shot. Thank you for the informations! :D

[LucidityCrash]

trying to contribute something other than chatter :) v15 of the SDK doesn't look like it supports the 51288. It looks like v12.3 is the latest one showing in the supported downloads section. But v12 still seems to have Cryptography library so hopefully it will be enough to help with enabling crypto. I'm not really understanding too much about what I'm doing :) but I've taken the Makefile from one of the new examples and the new sdk_config.h (which replaces the nrf_drv_config.h by the looks of it) and make a new branch in my fork of your code. Just done the keyboard code for the moment and I think the crystal settings are not correct but it at least compiles :) Reciever code is next - that needs the uart configured but I don't think it needs the GPIO set up.

Code is https://github.com/LucidityCrash/redox-w-firmware/tree/SDKv12

[mattdibi]

Reciever code is next - that needs the uart configured but I don't think it needs the GPIO set up.

That's correct.

Anyway nice job! Updating the SDK is an achivement by itself: none of the Mitosis clones I know of did that. Thanks for contributing! ;)

[LucidityCrash]

Update ... ported the Receiver code too ... well it compiles anyway ... not actually tested it on real hardware yet.

[LucidityCrash]

Update2 ... not working as yet. New Keyboard code (using original Receiver code)

• Layer 1 light goes on after pressing it then stays on. Pressing the Layer key turns it off while held down (this is the reverse of normal
• Key presses sometimes register or at least some of them do they also get stuck on sometimes.

New Receiver code (using original Keyboard code)

• getting repeated key events for each keypress
• when pressing multiple keys in quick succession (as in typing) the repeated key events can interleave with each other

[LucidityCrash]

So close, The receiver works when running built against the v12 SDK and the keyboards running firmware build against the v11 SDK ... not sure what I changed over my last test except making the changes for the interleaved frequency channel table. But when I put the v12 keyboard firmware on a board problems start, though I've identified the behaviour. When you press a key it is like you have held that key down for 4 seconds, even if it is just a tap. Not sure where to go next in debugging this ?

[sjdrc]

@LucidityCrash did you get any further on your work with this?

rossica's PR looks like it's been completed but hasn't seen any activity this year https://github.com/reversebias/mitosis/pull/18.

[LucidityCrash]

I was trying to update the nRF5 code to 12.3 but failed to get it to work ... it would compile but the keyboard would not function correctly. The reason I was trying to do this was there is some built in encryption methods in the newer version, however on re investigating I actually don't think they would be of use anyway. I've not got round to trying to port Rossica's code into Redox ... to be honest I'd kinda forgotten about it. Feel free if you have the time and skills ... if not I may try and pick it up again at some point :)

[sjdrc]

I ordered my Redox from Falbatech a couple of weeks ago, when it arrives I'll have a crack at it. Will post any results on this issue when I find the time.

[dbrgn]

@sjdrc did you give it a try? 🙂

[sjdrc]

Hey, I never got round to testing this and I no longer use the keyboard, sorry!