Blog 4 - MQTT Encryption

 Intro

For this sprint I volunteered to figure out an encryption solution for our binbot project. I have some experience with cryptography and network security but it's not my area of expertise so I thought this could be a fun and good way to improve my understanding.

I began by researching different options, starting with enabling TLS on the cloud board. This option caught my eye because of it's seeming ease of implementation and it's reputation as a security standard. Initially I assumed it would just be a case of setting the port to 8883 in makecode but upon further inspection I realised the port is set in the microIoT library that the broker uses. I managed to find the repository for this libary on GitHub.

I confirmed this was the right repo as it was DFRobot, the same brand as the broker board. I delved into the repository to try and see how I would go about setting the TLS port but I couldn't figure it. I decided to park that for the moment and looked at other encryption solutions. Next I looked into AES for the microbit boards. 

Off the bat AES didn't look promising. I spent a while looking around and asking Claud about the feasibility but despite this I wasn't able to find any examples of people online having successfully implemented AES encryption on a microbit. The closest I came was a GitHub repository that attempted to implement AES-ECB on microbit but failed.

Apparently one of the major constraints that impedes the use of AES on our microbits is us using radio signals. This is because The radio.sendValue() function in MakeCode sends a name/value pair, and the name field has a strict character limit. AES encryption produces a long hex string as output, and looking around in MakeCode, I couldn't find an AES library.

While AES didn't seem possible on the radio leg, Node-RED has a crypto function library that supports AES-128. I tinkered with this for a while but ultimately I was having a bit of trouble figuring out how it would fit into our architecture. I parked it for the moment and looked at a simple encryption function as I really wanted to just make some headway with this.

I settled with using a XOR function. XOR (exclusive OR) is a basic logic operation that works on the binary representation of characters. How this works is by taking what needs to be encrypted (e.g input1) and the key (let's say MySecretKey123), taking the first character of each (i and M), converting them to their ascii values which are 105 and 77 respectively, then applying XOR to their binary value, bit by bit. So 105 XOR 77 would be 36. Then if you get 36 and convert it back to a character you get $. This repeats for every character in the message and cycles through the key if it is shorter than the message.

XOR produces an output the same length as the input, fitting perfectly within the radio name field limit. By the time messages reach Beebotte they are already decrypted. The XOR cipher protects against someone physically nearby intercepting the radio signals between the micro:bits and the master board.

On the slave code the XOR function encrypts before sending and on the master code it decrypts on arrival before sending to the beebotte.

I plan to test this by having another microbit that sits in the same radio group and intercepts the raw messages without decrypting and display this on the MakeCode serial monitor for the listener, and then open up a serial monitor for the master board and show the decrypted message.

XOR is not considered strong encryption by modern standards. If an attacker intercepts enough messages they can potentially figure out the key through pattern analysis. I knew this going in but again I just wanted to make headway in any way possible, and I plan to return to TLS and AES with the hopes of successful implementation if we deem it worth the time.