Alarm system: rotating code between control panel and master

[system]

Ok, I was thinking, for my security alarm system that I keep annoying people with, that simple serial (RS485, via four MAX485 chips for full duplex communication) may be a little insecure for arming and disarming the alarm. it passes the RFID key and the password key in plain text.

Now, if I could figure out some sort of rolling code...

currently, the protocol between the control panel and master is as follows.
to arm:
0*
1*
2*arm

to disarm:
0*
1*
2*disarm

The code (PDF) for the control panel is attached. if need be, I can attach the code for the master controller.

but as can be seen in the protocol, it would be easy to "sniff" the arm and disarm protocol. but if the commands were some sort of rolling code, it would be harder to "sniff".

Now, I have been perusing a Enigma/Arduino clone, from HERE, and I think it may be a little too complicated for what I want to do.

I suppose if I send an init code to increment the key at the start of a packet, then I can use a simple transposition cipher.

another option might be a time based rolling code. I use a GPS pod for a time base, and it doesn't currently send to the control panel, but it could be.

then, every hour, on the hour, the code would roll to the next predefined code.
My brain is a bit frazzled from pouring through ideas in my head, and Google.

Any ideas? I'm still searching, but maybe several heads are better than mine. well, that is actually a guarantee, but anyway.

~Travis

AlarmMaster002_bv4243_001.pdf (86.4 KB)

[Rupert909]

Seems to me you're on the right track.

The usual way of handling sensitive values like passwords is using a one-way hash function, like md5 or sha1, and compare the output of that. Now, I don't know what libraries may exist for Arduino for such functions, and they may also be computationally expensive.

The layout here is roughly having a front-end and a back-end. The back-end is put in a safe place, but the front-end and the comm lines may be vulnerable.

To make the data to be sent rotating randomly, the back-end needs to communicate a key (say 4 bytes) to the front-end at a regular basis. When the front-end reads data from keypad and rfid, these are combined with that key from the back-end, producing a hash that is sent to the back-end.

The back-end creates its own hash, using the key value that was sent to the front-end, and the correct password and rfid-value, and compares received hash with that.

If someone compromises the system and are able to eavesdrop on the line when you, the rightful owner, enters, they can still not fake access by sending those data later, since by then the key will have changed, and the old hash will not match any longer.

They are of course also able to read the incoming keys from back-end to front-end, but not knowing the actual password and rfid data, they are not able to produce a hash that matches what the back-end expects. Their only chance is to hope that the key matches that which they saw when you logged in.

But letting the key be a simple 4 byte counter, for example, the back-end guarantees that the same value will not be reused in about 50.000 years, if you're sending a new key to the front-end every second.

The predictability of the keys is not an issue, since the hash functions protect the original values. In other words, hash functions can not be calculated in reverse. That's the beauty of hash functions. Their input may not be random, but as long as it changes, even by just one bit, the output varies wildly, and totally unpredictably.

[Edit]

One important detail! The back-end should regularly save a status in non-volatile memory about how far it has counted. For example, every time it ticks past a hundred thousand, it updates the EEPROM. When the program starts to run, it reads out that value from EEPROM and continues counting from a value that is guaranteed not to have been used before, by starting at the value that would have been written to EEPROM next. If EEPROM contains notifications that the counter had passed 200000, then we start to count from 300000, immediately updating EEPROM as to this value.

This is to ensure that trespassers can not gain an advantage from restarting the back-end, for example by tampering with electric power to your house.

To reset the counter, the back-end must be restarted some 42949 times, which is a lot.

Perhaps a bit much, all this, but security is always theorethically interesting even if one goes for a simpler solution in practice!

[Rupert909]

travis_farmer:
here is a "working" prototype of the code (attached PDF).
I went with MD5.

the RFID and Pass code are both an MD5 hash, and the master sends two codes to this module, as MD5 hashes of a rolling number, and the code is hashed again to hide it's origin, and sent back. the two codes are for arm and disarm.

I haven't attached it to my alarm prototype yet, but I will save that for either later tonight, or early next morning, before work.

~Travis

I don't think you need to double-hash with MD5. There is no way of reversing a hash back to its original content.

Anyway, happy to hear that you have a more or less working prototype!

[DVDdoug]

This reminds me of something from many years ago... I put an alarm in my car, but I didn't have a warning sticker or a blinking LED because I was afraid they would bypass the alarm, and I wanted to surprise them. It worked.

They smashed the window and they got the knobs off the stereo before the alarm went off and they ran away. I realized that idiots who break into a cars by smashing the window aren't sophisticated enough to bypass an alarm. ...So I added an blinking LED to deter them and luckily I never had another car break-in.

Most burglars will find another target if they know you have an alarm, or they will just work fast and run away before the cops come.

...I'm NOT trying to discourage you from making a "secure" alarm system... It sounds like a fun & challenging project, but most-likely nobody will ever try to bypass it.

[Rupert909]

travis_farmer:
Mainly I am doing this project to challenge myself, and further my self-taught education. so far, the crime rate is not very high where I am.

Besides, if anybody broke in and actually could disable my alarm, they would probably just take the alarm.

All, and all, it is a fun and educating process.

~Travis

Stealing the alarm? There's irony!!

I agree completely with your approach of challenging yourself, learning as much as possible. Most devices we create as a hobby, will be a one-off. Should mass production become an issue, or even just making something for someone else, then it's time to use the skills learned while tinkering with complex solutions, to make something robust and simple.

[Rupert909]

"I'm not crazy, I'm Autistic! (Asperger's)"

Does one exclude the other??