Summer Update (7/1/2016)

A project log for nRF_Detekt

This project is meant as a security add-on to an individual's physical security. Will warn of intruders in real-time and while you are away.

int-mosfetInt-Mosfet 07/02/2016 at 03:140 Comments
So....I didn't place in the Hackaday prize. No one likes my project :( Excuse me while I go cry in a corner...not. It's ok, I only posted this here to add another project to support what HaD is doing. Hopefully they take it as support and not just another crummy project for judges to slog thru lol. I think it's cool and useful (and can be so much better, the basic concept can be expanded, contracted, modified in all kinds of ways, etc.). Version 1.1 of nRF_Detekt_Receiver and nRF_Detekt_Transmitter on my github is coming soon. I'm just making final touches and cleaning up. It should be posted by July 5th. I'm going to try and cover the big things in this project log. 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, 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: 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".