-
21 days ago •
0 comments
I've enhanced my Motion-OLED Moteino project and added a few more features to the already existing ones:
- a general purpose button which is wired to interrupt 1 (pin D3) of the Moteino. This is useful to wake it up from sleep and respond to whatever command you have it do. For instance, I've programmed it to browse through past received messages from the wireless network, or it can be used to access a user menu where you can choose different modes of operation.
- The OLED can display anything you want. I like to keep the OLED mote in the kitchen area where it provides a hands-free alternative method to check the "snail mail". The periodic messages received from across the street (thanks to the powerful and very small RFM69 transceiver) are displayed on the OLED with the last time the mailbox was opened, very convenient.
- The ON-OFF slide switch can cut power from the LiPo battery, which in my case is a 1300mAh which lasts about 3 days with the OLED kept ON and the transceiver in RX mode all the time to listen for messages.
- The USB port allows easy programming from the Arduino IDE and also charges the battery in about 2.5 hours when fully discharged.
- A buzzer allows you to hear when a messages is received, or to alert you when mail is delivered, a garage door opens, a light turns on, etc.
- And of course, the same PCB/kit can be used as a low power motion detector by inserting a PIR sensor instead of the OLED display, quite versatile.
- I've discovered thinner acrylic makes for very nice cases that are easier to assemble and I might switch from thicker 3mm acrylic for such enclosures. Acrylic is found in many colors and shades which means these enclosures can be of many colors. Just look at a variety here.
- this kit will replace the current MotionMote kit and will also be usable as a mailbox notifier and standalone receiver for those who just need a motion or mailbox sensor and are not interested in the whole automation framework.
As of today I am still waiting for production PCBs to be delivered and tested, and once everything is confirmed ready to go I will post the details and sample source code for the OLED display shield. For now here's a sneak peek of what's coming:
-
21 days ago •
0 comments
HTTP(S) and Websockets Security
There are a lot of open source home automation attempts out there. Many are missing some essential security that leaves them vulnerable. Those that actually allow the user to control physical things in their home are especially vulnerable. An attacker could gain control and cause an appliance to turn on-off repeatedly causing a hazard, could gain access to the home by opening a garage or door, or could just watch for human activity for other evil purposes.
I knew that getting ahead of the crowd meant imposing some strict requirements including physical and virtual security to restrict access only to those authorized and minimize the chance of an attack.
Sure, anyone can add some authentication, not a big deal. And it's not too hard to add SSL. I had thrown web sockets in the mix for real time updates (cf polling as a method of "updating" on end clients). So web sockets had to be secured as well. Since the node.js websocket server runs on a different port than the webserver, rather than securing two channels of communication (webserver and websockets) I implemented what I believe is the first OSHW home automation interface with real realtime two-way communication between the webserver and the clients, by marshalling the websockets through the webserver itself, and thus obfuscating the internal websocket port. Hence both the webserver and websockets traffic run on the same SSL port 433. The websocket server is obscured and any non localhost requests to it are blocked. The details of this implementation are extensively documented in this article on my blog. HTTP-Auth authentication blocks any intruders from accessing the web interface. Below is a diagram of this whole scheme.
Wireless Security
Another important aspect of security is obfuscating the wireless requests and making it harder or impossible to decode. This is achieved with hardware AES128 encryption on the wireless transceivers such that any wireless packets to and from the end nodes cannot be decrypted by an attacker.
A more sophisticated attacker armed with a $20 RTL-SDR dongle and laptop could listen for more extended periods of time and record messages and then replay them in hope to cause a door to open for instance. Such a simple portable SDR solution (cf. portableSDR project) is elegantly explained by w2aew in this video:
Hence the remaining gap to fill is implementing an algorithm to thwart any replay attacks for those critical commands that control physical things like appliances, lights, garage, doors, etc. This is essentially a way to salt each wireless packet with a sliding window type signature such that if it's replayed it would be obsolete. Until this is implemented, one can tune their end node transceivers output power to only be powerful enough to reach the home gateway, which would be recommended anyway to avoid polluting the RF traffic in your neighborhood. So unless you have a curious close-by neighbor with radio knowledge who might eaves drop on your RF traffic, it would make it harder for an external intruder to get physically close to your home/location to record your traffic and try to mess with it via replay attacks.
Rolling code vulnerabilities
It seems a lot of key fob entry systems like auto locks and garage openers are using rolling code to secure their wireless communication. The transmitter increments a number in the packet with each subsequent transmission. The receiver remembers the last received token and knows what token or series of tokens are expected next. This attack involves blocking/jamming legitimate signal, then replaying the intercepted legitimate signal. Because of the jam, the receiver never receives the legitimate signal with the expected new token and thus the replayed message will appear legitimate.
I found ...
Read more »
-
a month ago •
0 comments
My vision for Moteino Framework was to create an affordable/open/ideal/easy hardware platform that would fuel a new generation of wireless internet-of-things, and I think it came out pretty decent. My Hackaday Prize entry even made it in the top 50 semifinalists (out of 800+). More devices are being added to the Moteino Framework and existing ones are being improved to make it fun for those makers who like to DIY and solder their internet-of-things from easy to assemble kits. The end users have maximum freedom as far as using/building stuff with Moteino. They can build absoltely everything from scratch, as some have done, but some prefer to just save time and buy building blocks. Hence I funded my way through this adventure by selling ready made Moteinos and kits in my online webshop.
People have asked many times why the Moteino was designed the way it was, and why not use this and that and the other type of MCU, transceiver type, radio band, or wireless technology. The number one reason why Moteinos are what they are today is because in the end they need to be designed to manufacture, work well, be reliable, license free, easy and fun to use in a friendly board format, cheap to buy or make, achieve long open air range or excellent indoor obstacle penetration when used with transceivers, etc. Here is my reasoning behind all these decisions and the answers to some frequently asked questions.
MCU choice – Why not ATTiny/ARM chips? They are cheaper!
Because it makes little sense, economically and practically, for what I had in mind. ATtinys are very memory challenged (typically FLASH not more than 8KB and SRAM not more than 512b), are somewhat supported in the Arduino IDE with some tweaks, don’t generally have real dedicated SPI/i2c/serial hardware support (some have SPI or serial). The bootloaders typically take a big chunk of the already limited FLASH. They cost less than an ATMega328 but the savings would never justify the features tradeoff unless for projects where all you need is a few I/O and you program it once and never have to touch it again. In fact some of the “larger” ATTinys are getting close in price to the popular ATMega328. ARM is a steep learning curve, the chains are not very easy to get going and the large fine pitch SMD chips are harder to get started with unless you get ready made development boards. Tools are also costly and the general public has an easier time with Arduino/AVR.
Could be much smaller with ATTiny or with other board layouts/set of hardware
Really? I could shrink the Moteino to the size of a fingernail (I actually did a project where the diameter of the circular board was 10mm with a QFN-28 ATMega328 on it, no kidding, the ICSP was on a header that would snap off after programming, leaving the circular 10mm finished board). You can do almost anything you can put your mind to. The big question is are they designed for manufacturability? Are they easy to use to the average electronic hobbyist as well as for the experienced maker? Are they a building block for greater things or are they a stumbling block? I am personally willing to invest a few bucks more to get the luxury of a tool that is not a pain to get started with and just works.
Why not CC1101 / NRF24L01 / other cheap ebay transmitters?
I really wanted to like these and I’ve done my own open air range testing with these NRF radios before I moved on to settling on RFM69. They are simply hopeless in terms of range. They have higher power versions (the PA+LNA) but those are hopeless in terms of size and power consumption and cost several times more than a RFM69. Most versions I’ve seen have a 2×4 header that was a challenge to fit flat/tight anywhere.
Why not use “inexpensive off the shelf” transmitter and receiver pairs? After all, they are just $1 on ebay!
Wow, I’m not impressed. They are inexpensive and you get what you pay for, a leg or an arm. I want a full set. You...
Read more »
