search

nRF24 / RF24

OSI Layer 2 driver for nRF24L01 on Arduino & Raspberry Pi/Linux Devices
https://nrf24.github.io/RF24
GNU General Public License v2.0
2.22k stars 1.02k forks source link

encryption framework for nRF24 (question) #434

Closed spaniakos closed 4 years ago

spaniakos commented 6 years ago

I was inactive for a lot of time (personal issues), but i am to the task to form a unified library of my encryption libraries/forks into a single framework that would be easily used from nRF24 code.

@Avamander @TMRh20 , would you be interested in testing the implementation of the library when it will be ready. i have a framework i made back then, but i have to get it up to date with the changes of the nRF24 library and match the supported boards that was added, especially esp8622. i am planning for the framework to handle sha1-sha256, AES, 3DES, MD5. Simple key exchange function for the nodes to share the master keys. and a compromise mechanism for the nodes in order for the master node to be able to kick a compromised node out.

the one i have ready (from back then) was for arduino and some arduino like boards, raspberry pi 2 but i havent made a python wrapper yet.

The roadmap of this framework will be to support deffie-helman key exchange and a python wrapper but this wont be ready for the version 1.

The framework as it was back then was tested using nRF24/nRF24Network/nRF24Mesh.

Avamander commented 5 years ago

I created a version that signs packets, works on AVR as well: https://github.com/Avamander/RF24Signing It's a proof of concept though, but it worked nicely when I first wrote it. Adding encryption would be doable.

spaniakos commented 5 years ago

actually i have an encryption framework ready. it works, has AES and 3DES and SHA-1 / SHA-256 i haven't tested it with the new upgraded library of RF since i developed it with an old one. needs some testing and some code refinement and should be good to go. as soon as i finish some project that i have @ my work, i will start updating the framework again.

spaniakos commented 5 years ago

@Avamander your implementation seems interesting, along with the Nonce parts. Mine is build with mind that will be used on top of native RF24Mesh library. It extends the Library in a way that with a single command the packet is encrypted and signed, and in the reciever, checked and decrypted. it has AES with PKCS #7 padding and HMAC SHA256 for signing (as yours) Basically its like an encryption wrapper on top of RF24Mesh that can be used with a single command. Moreover, it handles a basic key exchange mechanism (I haven't made diffie - helman yet) and has the ability to identify compromised nodes (Basic one) and exclude the nodes from the Mesh. You just have to compile each node with the correct key, and then there is a key generator that the Master is using and is assigning a key for each node so every node has a unique encryption key. The library is not ready to be published for use as it had bugs and i am concerned that is has 96% successful messages relay (98% would super!!), But i can for sure be uploaded in a closed circle as an alpha build and then be published as beta.

The main problem my encryption libraries have, is a bug with ESP8266 devices, and i really need to fix that, as ESP8266 devices are being used extensively. The problem is with the printf library (i think) that is used (i am sure RF24 has the same problem????) i will check the RF config files for the increased devices support that you have, as i am using a similar config file for device support.

The encryption libraries are Doxygen ready and published but the framework is partially Doxygen ready. Tell me if you or someone from the team is interested in seeing an partially outdated framework, else i will make the effort and publish it once it's updated.

Avamander commented 5 years ago

I found proper encryption way too slow and big for my devices, making sure packets are from the intended source and haven't been replayed was worth a bit more for me. In addition to that, good encryption is seriously difficult to do, I did not want to include a full TLS stack on an Arduino.

In order to avoid problems with insecure key exchange I made the keys preshared per-node, configured by a specific file. In order to forbid a node to send any messages all the nodes would have to be updated, but the chances of that happening were too small for me to bother implementing KEX.

About printf, I've long wished for a separate library that could always either mock or provide serial for ARM/PIC/AVR/tinyAVR along with optional debugging configurations, maybe one day I'll get to writing one.

spaniakos commented 5 years ago

my AES encryption performs slightly slower than openssl framework. Top values are RaspPi, bottom are openssl. The ENC/DEC are with AES-CBC Its measured at milliseconds and i have taken 10.000 measurements

            MIN.                MAX.                Avarage.                MEDIAN.

AES-CBC ENC | 0,0300 0,0180 | 0,4420 0,2690 | 0,0344 0,0206 | 0,0330 0,0200 AES-CBC DEC | 0,0340 0,0250 | 0,1740 0,1870 | 0,0386 0,0286 | 0,0370 0,0270

Bottom comparisons are for: top: RaspPi // Bottom Intel gallileo (which i fried one week ago and my interl gallileo now is broken..)

            MIN.                MAX.                Avarage.                MEDIAN.

AES-CBC ENC | 0,0300 0,0410 | 0,4420 1,8930 | 0,0344 0,0501 | 0,0330 0,0440 AES-CBC DEC | 0,0340 0,0520 | 0,1740 1,9080 | 0,0386 0,0613 | 0,0370 0,0550