Wednesday, February 3, 2016

nRF_Detekt

I've been working on what I call a "homebrewed security add-on".  What I envisioned is a RF module that took a signal from an externally powered sensor and then sent on that info to another storage point.  This could be an open-source programmable security product compared to most proprietary products that you can't reprogram at least.

Version 1.1 is available on my Github account, which explains most of what I'm doing.  I'm going to add better information and more full documentation on the project most likely during the summer as I'm too busy for the time-being.  Documentation is scattered between 3 places:  here, my github, and my hackaday.io account.

https://hackaday.io/project/11751-nrfdetekt

https://github.com/Int-Mosfet/nRF_Detekt

The "architecture" of the project has changed quite a bit, especially when I could encrypt more than 8 bytes lol. I can encrypt basically any block size that can fit in the ATMEGA328p with this encryption algorithm, CPU-wise and with flash ROM and RAM.

Right now I have XTEA and then AES-128-ECB (I know ECB ECB ECB!! It'll get complicated real quick (AKA subject to crazy failures that get too hard to debug) if I send out the IV generated on the TX node to RX node (after at least encrypting with XTEA with a separate key) then encrypt with the more secure mode of AES-CBC. Still, who can crack AES-ECB after chaining with other ciphers? No one as of now. Don't fall for the FUD, I'm taking care of using ECB mode, not like an idiot encrypting same string like IP address or something like that.) encryption of a 32-byte struct working well. I can chain on more ciphers but I think max I'm going to do now is Keeloq (which I am doing now), and just repeat the chain. I want this to be easy, adding in some of these other ciphers so they're ready for showtime, it's going to take a bit of work crafting them. Advanced users could do that easy, non-advanced users that want to just flash what I have, don't worry this default can repel basically all cryptanalysis as of right now. To break the crypto, you need an end-run attack as of now. Meaning stealing the key as you flash it in, or it leaks somehow during operation.

I worked pretty hard, thinking thinking thinking how to do a channel-changing feature that was robust and above all SIMPLE (simple was my overriding design goal). I can do it, it works in my room, but it's not *ULTRA* reliable which is what I want. So, if power fails (or that node gets jammed/attacked) on RX in the microseconds that the receiver has acknowledged back to TX that it has received, BEFORE I INCREMENT THE CHANNEL NUMBER, then the units will be out of sync with my simple algorithm. What I want is, to "randomly" change channels to throw off an eavesdropper, make it pretty annoying trying to lock on. If a fail mode happens in the TX, then to keep transmitting on every channel until it finds RX. RX would then have to stay on a channel so TX could find it or they may keep searching for each other indefinitely... So this channel changing feature gets murky real quick. For now I'm settling on statically setting one, by choosing some of my researched channels (you have to research channels that work in your area yourself) and other countermeasures will be needed to deal w/ active eavesdroppers. Which is expected with this project anyway. Much more is needed to repel and defeat these attackers.

I store this channel, and an "activation number" in the EEPROM. So it remains thru powercycles. I'm displaying this on a LCD attached to the receiver, which will be on my desk as a cool little device telling me if something is entering somewhere. The amount of writes I can do to EEPROM worry me (~100,000), so I may add in a little feature where I increment where I'm writing, then store address too (since on a powercycle it would just go to first set address). Or I may just say use that address up, then move on. Or to swap out chips if the EEPROM starts failing. This should, if you have 100 activations a day, take you around a 1000 days to happen, or 2.7 years. I set the speed of the radio comms to minimum (250kbps), CRC to max (16 bits), power to max; all my settings are to maximize RELIABILITY now instead of STEALTH.

***POWER*** Power to the nRF24 was not sufficient. I can solve this multiple ways. I did manage to get my hands on a LM317T voltage regulator. If you google "lm317 3.3 volt power supply" you'll get a schematic for a very nice and easy to build step-down regulator. Here's all you need: http://3.bp.blogspot.com/-N8fWdFhlouc/TnRG85acliI/AAAAAAAAA5k/dPA56ZxMfQ0/s1600/3.3V+regulated.jpg Get those parts, and you can use the 5V output pin of the Arduino, and this will step that down for you and provide plenty of current for the nRF24 with a PA and LNA (we need around 130mA, while the 3.3V pin of the Arduino can provide max of 50mA). That was too many components though, I don't want that (even though it's nice and works). Next thing you could do is use a transistor as an amplifier, and that will work. An NPN transistor (2N3904) would work with a resistor connected to the base I belive. But I was a little nervous since I'm not a EE, I can hook it up (I've use an NPN transistor as a switch for my radio, and it worked like a charm), but don't want to take any chances with my Arduino boards. What I think will work best for me (since I want minimal soldering and parts on the proto board, since I'm going to be putting this in a box), is a AMS1117 5V-3.3V buck converter. I believe it will work well. I'm going to be ordering one very shortly. I can power it via the 5V output pin, which will supply plenty current (400-500mA on USB and 800-1000mA on DC power), then it will be able to supply the nRF24 radio w/ upto 800mA current (which is way beyond what it needs). I will probably have to add some shielding to the radio, and maybe another filter on the input (a low pass filter, just a capacitor from VCC to GND).

So...those are the main changes right now to the project. After this code update and I get the power supply providing enough power to the radio for max power, I'm going to move on to other projects. BUT, I will keep revisiting this project, because like I said, I know it can be much better and it will get better. I'm going to be working on it for some years until I get it where I can finally say "I'm done". 

Some pictures, the final product will look a little different.  I'll be working on mostly software off and on until summer, when I want to crank out final versions of it.






Soldering nRF24L01+ to Arduino proto-board

Finished Prototypes

How I connect to units, I'm blanking out the sensor for NDA reasons, recommend 2 PC's if developing.