Project Logs

Collapse

• Summer Update (7/1/2016)

  Int-Mosfet • 07/02/2016 at 03:14 • 0 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... Read more »

• Future Plans?

  Int-Mosfet • 05/21/2016 at 03:49 • 0 comments

  Future plans is to upgrade the crypto. I wanted a more "spread spectrum" like feature but have channel incrementing happening now on each transmission. Will have LCD screen supported for receiver if you just want this at your desk/workbench and track who's coming up driveway. As many Arduino sensors as I can do, will get supported too. That would aid security too since an attacker would need an attack on all those to avoid getting logged. I'm going to have a case for the modules, just a simple box. I wanted to do a shield for it but we'll see, if I'm up for it. I also want a chat program for this too, it'll just be a mini-add-on called "nRF-Chat" where you could talk back and forth end-to-end encrypted with the Arduino Serial Monitor.

• Any Encryption?

  Int-Mosfet • 05/21/2016 at 03:44 • 0 comments

  Yes, yes there's encryption. Right now I support XTEA encryption. As of now, it's best to encrypt 32 bit chunks (4 bytes), so I do a microsecond timer value (32 bit timer) and an entropy sample which I'm not 100% sure if it's suitable entropy but I'm using it for now.

  This is because I'm not supplying an IV to what's being encrypted, so if I sent the same thing with the same key, it's the same traffic again and again.

  I believe (you really have to knock on wood or be careful speaking before you've done it in engineering) I should have Keyloq encryption (which is just another option) and AES-128 encryption in future. I can also encrypt with XTEA multiple times, to make it pretty unlikely it'll get cracked.
  

• RF vs. WIRE

  Int-Mosfet • 05/21/2016 at 03:37 • 0 comments

  So you may be wondering why I chose to use an RF module instead of just using a wire to connect the "transmitter" and "receiver". My thinking is that, if you had a break-in, the intruder would see this wire and follow it to your receiver and tamper with your evidence of their break-in. You could hide the wire here I suppose, but there's still going to be spots where it may be visible.

  So with RF you can hide the receiver lots of places (generally need a power outlet now, if you want to leave it for extended periods of time) and an intruder would really need to search out your residence to find it.

  If the intruder has sophisticated equipment that makes finding RF modules easy, well you need other ways to protect and defend against these intrusions. This module won't help much besides making the attacker work more.
  

• Why Arduino, and not 555?

  Int-Mosfet • 05/21/2016 at 03:13 • 0 comments

  This is a bit of a not-so-inside joke at Hackaday. If you use a device that is seemingly overpowered for the application, you always have someone chime in they could do it with less. In the real-world, sometimes you have products that are really successful and eventually you run out of code space on your chip from accumulated features or they go EOL (end of life) and you have to migrate to another chip. More often then not, the commenters can't link to their project where they actually do this (if they do, it most likely has considerably less features), and we all get on with our lives.

  But seriously, why Arduino here?

  I'm using Arduino because I want to increase security for those that can't otherwise make their own homebrew security products in the easiest way I see fit. That's the main reason. Also why I'm using the Uno board, it's the most popular Arduino board. There's a big community around the Arduino too so it's fun to make stuff to add to all the contributions others have made. To be clear, connecting an NRF module to an Arduino is not novel whatsoever, but I haven't seen anyone make exactly what I'm doing, otherwise I'd just build their project.
  

  I wanted to make a small security device that can log evidence of physical break-ins to homes, labs, offices, etc.; that the user can program (because otherwise you're trusting a blackbox, backdoors are a constant worry in security and sometimes they can go so deep even most engineers can't mitigate them).

  So I was planning this out for a while, and when I had a few spare moments over winter break (January 2016) I put together the first working version.

  This website was a big help in getting started, especially pinouts. I will list the pinouts I'm using in future logs (may happen after May 30th). They're all the same except for CE and CSN (which is 9 and 10 for me).

  https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo?responseToken=6904163c70a8b3f9c7e714cfec52eab3

  The next site is linked on my github (where most of my technical changes will be, since this project is more code than hardware changes). This library is the main code behind interfacing the NRF module and the Arduino. It was a huge help and is a great library. I modified a starting example as a starting point for the project.

  https://github.com/tmrh20/RF24/

View all 5 project logs