NFC reader and alarm/door entry system

A long time ago I made a door entry and alarm system. Actually my first was approx 1989 using a mag head from a Sony walkman on a block of wood on the door and a wire wrap 6502. My latest attempt a few years ago is a lot more sophisticated.

It is good, indeed, I would say it is very good. It has a lot of off line working built in but backed by internet management/control system, so designed for power and internet failure, for hours, or even days.

The NFC door control uses AES on DESFire cards, so no plain text even on RF, and challenge both ways, so super secure. It even has different keys for each card. But it scales to any number of cards, with different access levels encoded in the card so as to work off line if needed (for a configurable time).

Like I say, it is good, and we use it, and a hack spare uses it (maybe two) and several small offices.

But it is tricky to sell.

Insurance and alarm companies have stuff tied up

Perhaps the biggest issue is that insurance companies and alarm companies have some industry standards and something of a private club. Yes, we could join, I am sure, but only if I wanted to be come an alarm company. Open source stuff is not going to get in to the club no matter how good it is. This is a shame as proper (Galaxy) alarm systems can be crap by comparison, as we know because we had one, installed by a certified installer, and were robbed!

My understanding is that one of the rules (I heard from an installer) was you can't have some external indication of armed or not. This ment staff did not understand they failed to arm. It beeps in various incomprehensible ways, and shows stuff on the keypad (which you cannot read from outside when using the fob to arm), so they assumed armed when not.

My system can show such, but we go for subtle - internal lights go off when armed. I mean you would turn off anyway, but staff can tell instantly that the lobby light not going off means not alarmed. The light switch does not allow manual turn off. Simple steps but has meant that on the odd occasion of not arming (e.g. fire exit open) staff knew. This is what caused the problem on Galaxy.

I also allow a forced alarm for such cases as a last resort - where the open fire exit becomes a sensor - someone closing it would set off the alarm. This means I can set forced alarm on timer, and be alarmed if staff have missed the problem somehow and still have a working alarm (all PIRs, etc). The Galaxy, when it does not arm, does not arm, end of story. It is a compromise I suspect an official system would not allow.

So basically you need to check (and record the call) insurance are happy with no proper alarm system, etc. Seems many are, and may not even charge more, but having it on record should mean you are covered.

Monitoring

Another issue is monitoring of the alarm. We had that once at an office, and it was such a pain. And one time when we did not know then code word, they said the police would be called. The police did not turn up so I was stuck there for 4 hours on a Sunday waiting for police. Also police won't come if you have too many false alarms.

My system monitors, but messages people, several people, like me, people with access to the CCTV who can confirm it is a false alarm, and if not call the police explaining they can see the burglary in progress on CCTV. That will, I expect, get a way better response than an alarm company calling.

Also much easier to integrate to external systems - staff in office logging for fire list, etc.

Locks

Another issue is locks, and the typical internal door lock is a mag lock, which is really easy to defeat. I have found much better locks and would recommend using them - Abloy locks. These work without the alarm and use a proper euro profile lock, and can be set to open from inside regardless, but also have a load of sensors (key used, handle used, lock in/out, etc).

Opening from inside also avoids the messy "break glass" and "exit button" you typically need.

So my system has to handle everything from a simple maglock and exit button, to the Abloy with something like 5 inputs - which it does nicely now.

It costs more, but in the end it is worth it.

Professional kit

With all of the above, an alarm or door entry system can work, with insurance confirming OK, etc.

But the kit is not as professional, or is it.

When I started I had single sided copper clad boards milled and hand soldered. I have moved on to proper PCBs made in China. I have moved on through a load of connector types to WAGO PCB connectors which are just simple to use for an installer. I have added per input/output LED status on the PCB.

But still, the case is a messy 3D print on my printer. Well, now we moved on finally with high resolution, smooth, clean, 3D resin prints from China.

The wiring and connector to the NFC reader was also a concern, but ironically the leads I got made in China for Faikin boards are perfect for this, and again, professional, so making it all easy to install and just more professional.

I finally feel like I have stuff that is professional looking.

The NFC sensor on a door. It looks proper now.

I have even now designed one for a 1 gang UK pattress box.

So now I plan to list these boards and cases on Tindie soon. The NFC reader is ideal for a hobbyist working on any NFC stuff.

Door entry system

I have been playing with a door entry system, as you will have seen, and there are several steps like choosing processor, and voltage regulators, and relays, and so on. All good fun, but it gets a bit more interesting when you actually want to create some security.

But first, a couple of updates.

The Elechouse PN532 V4 cards really just work, they are excellent, talk to bank cards and MIFARE cards and fobs at a usable distance with no problem. Really impressed. I cannot stress this enough, buy these from Elechouse directly in China - they can ship in a few days - they work. But one extra bit, as I am using these on the "outside" part of the door system - I wanted an LED. It seems the PN532 has some GPIO pins, so a simple bi-colour LED and resistor directly on two of the pins (which the elechouse bring out to pad/holes) gives me a nice red/green LED (with various combinations of blinking as I like). On top of that the WiFi has been really reliable, but it seems that can improve when the next ESP8266 libraries are released soon. I have been using on one of my doors at home for a couple of weeks now, and it is working well.

On-line, and off-line operation

Even though the WiFi is working well, it remains an area of concern in terms of reliability and fallback for power failure, and vulnerability. The system is using TLS everywhere, so makes it pretty secure against infiltration, but not against disruptive attacks - a weakness of any RF based systems.

The simplest fallback is a system where one, or more, cards are configured in door(s) to be allowed to open the door off-line when no WiFi. Overall this is a good safety net, and the one or two cards with such an ID can be kept safe. As they would be my cards, and there is no door of which I should be locked out, this does not make this a work around of security. Even so, it is a bodge.

A better solution may be to allow off-line working of the doors. This is possible, of course. In fact, cards like the NXP MIFARE DESFire EV1 cards are ideal for this. Ideally you want a system that is at least mostly on-line allowing off-line but with logging, and controls - which suites WiFi well.

How would off-line work?

The trick with off-line is you need to somehow encode the rules for access in a way that does not need live access to a control system. This is complicated - it could be a large database, and what if you have a lot of people - do you literally have to sync a whole user access database in to every small door controller CPU/Flash? That would work, but is not that scaleable.

So code details in the card. Well, that is tricky if the card can be changed. Of course you want secure cards, and the DESFire cards allow this. They allow for a card you cannot copy or change, but allow lots of fields and "files" on the card which could encode details of times of day and day of week and expiry dates and which doors are allowed or barred.

Using details on a card, which can only be changed using a key, means that an off-line system can work with unlimited numbers of users - checking the credentials from the card for each door access, and ensuring very quick response and instant operation without waiting on an on-line system.

From a reliability point of view this is excellent. As long as the door has power (which is easy with 12V and battery boxes) it works! Of course you need a way to blacklist cards from a central control, but this is for exceptions only, and short expiry on cards can keep this to a minimum.

Partly on-line

Of course you can make things a tad more secure by having some things on-line. E.g. if a card has not been used for a few days - this allows for cards to need extra checking if someone has been on holiday, etc. You could also make some doors on-line for most users (except for me!) for added security. You could make doors on-line when "locked", i.e. alarm set, so first use of the day could have a lag if WiFi is iffy. All of these are good compromises for ensuring most, or all, doors are fast response and very reliable all day which few exceptions. Users get upset walking in to a door that did not open when expected - you really only have a few hundred ms to play with here :-)

Of course one trick is "normally on-line" only falling back to off-line working (where allowed) if response takes more than X milliseconds.

Keys

It is not as simple as one would like. Making all of this work at a technical level, making PCBs, making readers, and 3D printed cases, and firmware - all pretty straight forward. Even the low level comms to the DESFire cards is not that hard (with help from datasheets and some internet blogs).

However, the bigger issue is how you manage the cards.

The DESFire cards do not use public/private key logic, which is a shame. If they did, all readers could have public keys with no concern on these leaking, whilst the cards have embedded secret keys used to answer a challenge from the reader. Unfortunately the DESFire authentication is mutual / symmetric, so the same key is needed in the card and the reader.

• Do you have a per card master key, or a common master key? (I'd say per card), but where do you store that?
• Do you have per card keys per application for updating permissions?
• What of a key that can write to a counter and a log?
• What of the key just to validate the application/card.
• How do you handle multiple applications on a card?

The validation is perhaps the most annoying - as you want to avoid a complete database of all cards in every lock with the key for that card. Indeed, that means more keys in more places that could be compromised (physically steal a door control board and re-flash to dump keys). It does not help over having a common key.

So in practice, for each application, you need an authentication key that is stored in the locks if they are to work off line at all. You could have different doors/locks on different applications where there are different levels of security or sensitivity in an organisation. That helps.

That also means communicating the key to the locks (let's use TLS shall we). Does it mean storing in the lock? We could put in flash, or maybe we deliberately store only in RAM and need to be on-line once after any reboot before we can work off line. Remember, if someone gets a key, they can make cards, so no level of fallback key is any good if it could be compromised.

And then the whole access control rights are more complex - not just which doors and what times, but also who has controls to change access on people's cards. The NP532 has a nice feature where you can talk to two cards in RF field at once, so you can make it that programming any card means applying that target card and the card of the HR person that has authority to make changes at the same time on a reader on a desk. Not sure if that is more than a gimmick though. Even so, you can use the cards as part of login processes for management of cards, and should do as at least two factor auth.

A lot of the work on this project will be the management system for cards, and logging, and security (and GDPR).

You also need to consider compromises - what if someone did steal a reader off a door - can you re-issue TLS/MQTT credentials to all readers? Can you update keys? How does that process work. The simple case of a lost card is easy by comparison (blacklist on all readers for X days). Do you roll over keys anyway and have a system to update on next use? All good fun.

Alternative on-line?

There is a way to be on-line and not WiFi - I could install an RS485 driver and have the reader look like a normal Max reader to a Galaxy alarm system - doing the off-line control (all set up over wifi) and reporting a simple "key fob" number to the alarm / door system if all OK. Viable and quick.

Is there a product in this?

It would be easy to make a product - an external reader based on PN532 with LEDs, perhaps a beeper, and an internal unit with contact inputs, solid state really output, RS485 for talking to Galaxy panel, WiFi, 12V power, and even a programming header for hobbyist market.

It would be massively more secure than Max readers, as using proper DESFire cards and keys, and the external unit not housing the relay even. Isolate its power and control lines and you cannot "break" the door control from outside. Nice.

It would cost (mainly in the CE marking, safety and EMC testing). It could be neat, and a drop in high security system for an existing RS485 based door/alarm system, or a WiFi based system. Whilst we spend a lot on R&D, this would be perhaps a tad too speculative for now. Of course if you are a large company with many offices and staff and interested in a serious bespoke entry control system - let me know - we have the technology now.

For now, I expect this is for my home, and maybe office later, not a product. But still, a big step forward in terms of security.

All of this, including manuals, PCB layouts, pictures, and code, are being kept up on GitHub... All part of A&A giving back to open source.