I'm working on creating a proximity door lock that opens when you get within a few feet (looking at ultrasonic range finder/infrared), and authenticates that it's you from your phones MAC address via bluetooth. I don't want to have to do anything when opening the door.
Are there any security solutions to prevent MAC spoofing?
I've never used an arduino, or done diy electronics too much, so I have a few questions. Which arduino device would be best suitable for this application? I want it to be as compact as possible.
The devices I'm looking at so far are:
Arduino (not sure which model)
Paralax Ping Ultrasonic Range Finder (I chose ultrasonic because I read that infrared does not work well in direct sunlight, and this lock will be outside.)
Bluetooth Modem (Are there models that work better with the arduino than others?)
I'm using an Android phone
Electric Door Strike
Something to power it all (Haven't look into this yet)
Okay.. I 'm thinking then I could make an app that has an encrypted field that needs to authenticate along with the MAC address.
I forgot to mention I want this doorlock to also have an RFID reader, in case the phone is off. I was looking at the ID-12 reader from sparkfun. I was reading this tutorial http://www.instructables.com/id/Arduino-RFID-Door-Lock/?ALLSTEPS, and it uses an ATmega168 instead of an arduino board. I'm interested in this because of it's compactness. Is there something like this that would suit all the needs (bluetooth, rfid, ultrasonic)?
For the prototype, I was thinking of using a Mega2560 board, because it looks like it has everything I need, and more. I may want to add more features in the future anyway. Is there anything the Mega2560 can't do that I've said?
LightxMind:
Okay.. I 'm thinking then I could make an app that has an encrypted field that needs to authenticate along with the MAC address.
Yeah. That's not any better. I guess you don't realize that a long list of people much smarter than you and I have already solved the problem. This is a reasonable place to start...
Paralax Ping Ultrasonic Range Finder (I chose ultrasonic because I read that infrared does not work well in direct sunlight, and this lock will be outside.)
Ultrasonic sensors are somewhat unreliable against clothing / people. Either of these can make a person "blind" to the sensor: a heavy sweatshirt or sweater; approaching at an oblique angle. Having it at chest height seems to help.
Any reason you don't want to use a simple motion sensor? I suspect you can find one specifically designed to work outside.
From what I had read, I had assumed that all infrared sensors do not work well in sunlight. A google search appears to tell me otherwise though, so thanks for the help. Or were you implying that there are other types of sensors that can be used as a motion detector? For the short time I've been searching the only two I've found are ultrasonic and infrared sensors.
Include "arduino" and/or "avr" in your searching. I vaguely recall a rolling-code implementation for the Arduino. The key is to have a "cryptographically secure" random number generator.
From what I had read, I had assumed that all infrared sensors do not work well in sunlight.
There are four ways to interpret "infrared sensor": a device that bounces a light beam off of objects to measure distance (called an "infrared proximity sensor"), a device that senses motion (called a "motion detector" or a "PIR"), a device that measures heat without contact (called lots of things), and a device that measures intensity of light in the infrared spectrum (which does not appear to have any particular name). You will be interested in an infrared proximity sensor (Sharp is a popular vendor) or a motion detector (Parallax is a popular vendor). I have no idea if infrared proximity sensors work well outside. I know for a fact that motion detectors work well outside (but I don't know if Parallax ones do; if you ask I will test one).
Okay, thanks for the advice. It looks like the infrared proximity sensors are the ones that have the most problems outside. I only read a few accounts of problems with PIRs. I think all were false triggers, which shouldn't really be a problem I think, only if it doesn't trigger when there actually is someone there.
if you ask I will test one
That would so helpful if you can, thanks. Can you link me which sensor it is you're testing?
RFID cards are typically not rolling-code. Just a raw string of data that is the same every time it's read. The implication here is this: If you go to great lengths to ensure you can generate "truly random" numbers, and provide a rolling code mechanism so that your Bluetooth exchange is absolutely secure against replay attacks and spoofed MAC addresses, I as an attacker would find it preferable to read your RFID card and just use that simple, repeatable key instead.
In other words, if you're going to unlock the door with RFID, MAC spoofing is not the obvious security hole. Not that I advise security-by-obscurity, but you could weigh the potential likelihood that your one-off solution is going to be desirable enough to crack that someone would take the time to figure it out. If I were a common burglar, I would probably not bother figuring out your electronic access control. I would just brick your windows. shrug
Entrance to commercial property would be another matter. Or, in a hospitality or private-access scenario (where customers/members get their own keys), you have yet another set of concerns. For instance, I'm looking at providing RFID-based access control to our local makerspace. If someone drops their card in the parking lot, the building is as good as unlocked. In my case, I'm adding a PIN to the equation. Both the card's code and their PIN together must be able to generate a hash that matches their account in the DB for the door to unlock. Two-factor authentication: Something you have, plus something you know. Doesn't work so well for automatic entry (like you want), but that's the trade-off you make... security is often at odds with convenience.
SirNickity:
RFID cards are typically not rolling-code. Just a raw string of data that is the same every time it's read. The implication here is this: If you go to great lengths to ensure you can generate "truly random" numbers, and provide a rolling code mechanism so that your Bluetooth exchange is absolutely secure against replay attacks and spoofed MAC addresses, I as an attacker would find it preferable to read your RFID card and just use that simple, repeatable key instead.
Thanks for the advice, I had not thought about this problem. I was reading about some implementations of RFID with rolling code. Is there any reason this couldn't work on the arduino?
In my case, I'm adding a PIN to the equation. Both the card's code and their PIN together must be able to generate a hash that matches their account in the DB for the door to unlock. Two-factor authentication: Something you have, plus something you know. Doesn't work so well for automatic entry (like you want), but that's the trade-off you make... security is often at odds with convenience.
I think this is an acceptable trade off for when the phone is dead or unable to connect. I would rather have rolling code as a security measure if possible though. However, I haven't been able to find too much information on rolling code examples using the arduino, especially with bluetooth.
LightxMind:
Thanks for the advice, I had not thought about this problem. I was reading about some implementations of RFID with rolling code. Is there any reason this couldn't work on the arduino?
It's not an Arduino problem, it's that RFID tags are usually passive devices. They have an inbuilt serial number that is transmitted when the coil is activated by the RFID reader. They can't do rolling code, because they don't have the necessary intelligence to self-modify the data they send. So-called "Active" RFID cards can, but price goes way, way up for that functionality.
LightxMind:
I think this is an acceptable trade off for when the phone is dead or unable to connect. I would rather have rolling code as a security measure if possible though. However, I haven't been able to find too much information on rolling code examples using the arduino, especially with bluetooth.
You don't need to be that specific. If you research the concept of rolling code, then find (or write) an implementation, it can be adapted for use with Bluetooth and Arduino. The primary concern is that you can generate a sequence that is always changing, depends on prior state, and can be predicted by authorized (synchronized) devices, but is essentially random to unauthorized devices. Whether that code is transmitted via Bluetooth, RFID, IR, serial, or TCP/IP is inconsequential. As is the device it runs on -- be that a dumb key fob, Arduino, or PC. If you find a C code fragment anywhere, chances are good you can port it to your application.
SirNickity:
It's not an Arduino problem, it's that RFID tags are usually passive devices. They have an inbuilt serial number that is transmitted when the coil is activated by the RFID reader. They can't do rolling code, because they don't have the necessary intelligence to self-modify the data they send. So-called "Active" RFID cards can, but price goes way, way up for that functionality.
Alright thanks, I didn't know that. I just did a search for active rfid tags, and they look bigger than what I was hoping for. Along with not being able to find the prices on almost any of them, I think the pin code solution is a better choice.
You don't need to be that specific. If you research the concept of rolling code, then find (or write) an implementation, it can be adapted for use with Bluetooth and Arduino. The primary concern is that you can generate a sequence that is always changing, depends on prior state, and can be predicted by authorized (synchronized) devices, but is essentially random to unauthorized devices. Whether that code is transmitted via Bluetooth, RFID, IR, serial, or TCP/IP is inconsequential. As is the device it runs on -- be that a dumb key fob, Arduino, or PC. If you find a C code fragment anywhere, chances are good you can port it to your application.
Alright, that makes sense. I think I'm going to work on getting the hardware together before working on the security elements if it's just software.
That's entirely reasonable. Once you can transmit anything from one device to another, increasing security and authentication of that message is indeed purely code.
Just wanted to update everyone on my progress. The parts (most of them) came in today. I was able to get the PIR sensor working with an led. I hooked up the bluetooth modem, and was able to connect to it on my phone. For some reason when it's plugged in, the led stays on/flickers. I'm not sure why.
I'm having trouble with a small part of this project. For a reason I can't figure out, the LED that represents when motion is detected flashes when my bluetooth modem is not connected to a device. It also comes on when any input from my android phone occurs via bluetooth. The only place I have the LED set to light up is when the PIR sensor is 'LOW'. I've tried it on multiple pins, so I think the problem is in the code. Here's what I have:
//Passive Proximity Door Lock
//#include <SoftwareSerial.h
#include <Password.h>
#include <Keypad.h>
Password password = Password( "1234" );
const byte ROWS = 4; // Four rows
const byte COLS = 3; // columns
// Define the Keymap
char keys[ROWS][COLS] = {
{'1','2','3'},
{'4','5','6'},
{'7','8','9'},
{'*','0','#'}
};
// Connect keypad ROW0, ROW1, ROW2 and ROW3 to these Arduino pins.
byte rowPins[ROWS] = { 2, 3, 4, 5 };// Connect keypad COL0, COL1 and COL2 to these Arduino pins.
byte colPins[COLS] = { 6, 7, 8 };
// Create the Keypad
Keypad keypad = Keypad( makeKeymap(keys), rowPins, colPins, ROWS, COLS );
int pirPin = 12; //Motion Sensor
int led = 10; //red LED
int led2 = 11; //green LED
int ledBlue = 9; //blue LED
//SoftwareSerial mySerial(1, 2);
void setup(){
Serial.begin(9600);
//mySerial.begin(9600);
pinMode(pirPin, INPUT);
pinMode(led, OUTPUT);
pinMode(led2, OUTPUT);
pinMode(ledBlue, OUTPUT);
keypad.addEventListener(keypadEvent); //add an event listener for this keypad
}
void loop(){
if (Serial.available() > 0) {
int inByte = Serial.read();
switch (inByte) {
case '1':
digitalWrite(ledBlue, HIGH);
break;
case '2':
digitalWrite(ledBlue, LOW);
default: digitalWrite(ledBlue, LOW);
}
}
int pirVal = digitalRead(pirPin);
if(pirVal == LOW){ //was motion detected
digitalWrite(led, HIGH);
}
if(digitalRead(led)){ //only accept key if red LED is on
keypad.getKey();
}
}
//take care of some special events
void keypadEvent(KeypadEvent eKey){
switch (keypad.getState()){
case PRESSED:
Serial.println(eKey);
switch (eKey){
case '*': checkPassword(); break;
case '#': password.reset(); break;
default: password.append(eKey);
}
}
}
void checkPassword(){
if (password.evaluate()){
//red LED turns off, green LED turns on/off
digitalWrite(led, LOW);
digitalWrite(led2, HIGH);
delay(3000);
password.reset();
digitalWrite(led2, LOW);
}else{
//red LED stays on
}
}
Hey, I found that the bluetooth module wasn't interacting directly with the led, it's interacting with my PIR sensor. My PIR is connected to 5V, GND, and Digital Pin 42. The Bluetooth Module is connected to 3.3V, a different GND, and my rx/tx pins (0,1). Whenever the bluetooth module is plugged in, my PIR sensor immediately starts going off, as well as the led that is supposed to when motion is detected. This also occurs when any data is transferred via bluetooth from my android phone to the bluetooth module ( like turning on/off an led). All data sent via bluetooth is recevied fine, but the PIR sensor goes off too.
Has anyone had any experience with an issue like this? Please excuse me if it's an obvious answer. I've researched for a while, and haven't found a solution that fixes it yet. Thanks!
What's the output of your PIR sensor? Does it drive its output HIGH/LOW, or is it an open drain? You might need a pull-up resistor (or internal pull-up enabled) to keep the line HIGH when the PIR isn't pulling it LOW. The RF noise from the BT module might be enough to set it off otherwise.
