Open the pod bay doors, HAL

I am pleased to say I finally have the locks sorted at home.

The underlying system is in use at the office and a number of other places, including a hackspace (whose feedback has been great), but as anyone that does software knows it really helps to actually be a user as well. I had the previous system at my previous house in Bracknell. But now in Wales, I wanted the new system as well. I like the system I have made, and using means I can more easily spot the improvements that are needed.

Several small tweaks over the last couple of months as installed. The locksmith has managed a reasonable job of this and coped with my wiring in the door quite well. The controller boards have got smaller and better over time.

It is a very different set up for domestic than for office, and that has been a challenge. The Abloy EL560 work well for this. We don't want "break glass" boxes and exit buttons, so needed some creative solutions to make it "wife approved" and secure at the same time.

My daughter, who is visiting this week, is the first person to have her door access card set up using multiple separate AIDs to allow use at the house here and the office in Bracknell, along with my grandson. The 8k DESFire cards allow this to work well with separate AIDs for each site to work independently.

Of course, said grandson, being far too inquisitive, especially near a hot soldering iron, is why my office door at home is currently default locked. Strangely enough this has led to an improvement today on reporting unauthorised access attempts. It reports all sorts of failures, bad fobs, even access outside time period, but straight up valid card that is "these are not the doors to which you have access, [waves hand]" was not flagged as obviously, and is now. Obviously he did not get access, but now, if he tries again, I get emails, and the teletype will go mental, and so on. LOL.

I should be doing another office soon as well, as a prototype. I really hope to be selling these soon - once component shortages are over (ha!). We'll put the modules on Amazon I expect.

Never quite finished?!

The good news is I now have the "proper" PCBs for my door controller and NFC reader...

I have to say they look good - proper boards, and using solder paste and oven means a very professional result.

PCB Train do a nice job, but these were on a three week lead time. Both boards work. However, in the three weeks since I ordered I have made a few design changes.

The door controller changes are very minor - instead of 3 inputs with 3 GND on the 6 pin connector I have all 6 pins connected to GPIO, where you drive some pins to GND if you want. This allows a lot more options if needed, etc. The pins all have BAV99S and 100Ω for some ESP protection, and 33pF to help reduce noise. It is a small change, and so the existing boards are more than usable. The only snag is I mis-ordered as 1.6mm not 0.8mm boards, and I have designed cases to be as small as I can to fit in a back box. I think 1.6mm will still fit, but it is annoying.

The bigger issue is the NFC board. As I say, they work. But the tuning is perhaps not spot on. The newer design boards have a loop both sides, allowing the board to be 40mm x 40mm not 42mm x 42mm. However, the newest boards are better - the main thing is they do not get hot which is a big clue (i.e. the antenna is clearly better and easier to tune), and I have them working with more range. So I would rather use the new boards. They too are also 0.8mm which saves space.

So, all in all, I decided to order some new boards - two week lead time. However I have a few dozen of these boards. As I say, they work, and I am testing with them, and may well use some, but once I get the replacements I will end up throwing these away, I am sure, which is a shame.

So, if a hackspace, or other good cause, wants either of these bare boards, to play with. The schematics and code are all on GitHub. Note, need hot air gun at least for the PN532, and fine tipped soldering iron. Let me know. Email me at pcb1@revk.uk

Long term?

These, and some other related modules, should be able to make a WiFi mesh with (not having to be always on-line) "cloud" control and management (on or off site) to work as an alarm and access system.

ESP32 progress

I am, of course, reinventing wheels, yet again with my move to ESP32 for IoT and access control stuff.

It is going well - I am actually on holiday in Greece, but whilst my wife and daughter sit on sun beds, I have been messing with code. Yes, I took a laptop, programming cable, some ESP32 boards, and even a hand held oscilloscope on holiday with me. Sorry. I spent 4 hours on the plane reading the data sheet on my iPad!

My plan is to get my ESP32 development environment and toolkit working like I had on the ESP8266, and build up my "Solar System" alarm and door control module code.

In some ways this is a nice project - it is often good to rework and redesign something for the second time as you have learned lessons and can do things better. It is also nice that my code effectively has a specification to work to. The previous code was being specified, designed, and coded all at once. But now I have a system which works with the ESP8266 modules and should work just the same with the ESP32 modules.

Progress

I am making good progress. I have the build environment on Mac and linux working. The instructions were very clear. I am actually ssh'd to my linux box to develop now. I have the basic support system which allows me to connect to the WiFi, and MQTT server, and do over the air s/w updates, and store settings in non volatile storage. These are all based on the ESP-IDF tools, which seem quite good.

I have hit a few snags - for example I cannot do certificate pinning on the TLS using the SHA1 hash of the certificate, it seems. I have to include the PEM format certificate itself. This seems needlessly complicated, but not a big change.

I have a snag with MQTT that it seems not to pass on messages with zero length data for some reason. I may have to work that out and do a pull request to the library.

I also have to restructure the design in some case - for example, previously I did the settings in a block of memory that was flashed. Now I am using the provided NVS library for settings. It seems good as it does not have to re-flash a block on every change - it incrementally updates a log of settings in flash as it goes. Quite sensible really. However, it seems to lack a means to enumerate the settings that are there - I have to ask for a setting by name. As a result I have changed my code structure to register settings from the application with my library. This has meant a redesign, but as always it makes it much better in the long run.

Update: As redesigns go - I ended up re-doing it yet again, and pretty slick now.

I should be able to sort the basic GPIO (inputs and outputs) really easily, and hence use almost all of my existing door control code with that. It looks like I can compile my linux version of DESFire stuff for NFC too, so no need for an ESP specific version (if needs ESP specific AES calls).

There will be some challenges with the PN532 library and VL53L0X library I expect. But they are not rocket science, thankfully. The Honeywell Galaxy RS485 bus should just work if I can work out the timer interrupt logic. Saldy each of these is simple in theory but getting my head around the specific way of working for the ESP32 takes an unknown amount of time. Interrupts were a challenge on the ESP8266!

PCB design

This had me kicking myself the night before we left on holiday. I have made up several ESP32 based PCBs. A general break out board; a door controller board; and several Galaxy keypad boards. I had checked I could load code on the door controller. It worked.

But I realised, on reading more of the data sheet, that 6 of the pins on the bottom of the module (ESP32-WROOM-32) are connected to the internal flash and so unusable. Why even have them come out of the module then? They are literally in the way of tracking the usable pins out of the chip. I had the same issue on the ESP-12F and taped over the pads. The ESP-12S sensibly does not have them, but then has a GND pad you have to tape over if you have tracks under it. The ESP32-WROOM-32 has both unusable pins on the end and a GND pad in the way. Arrrg! Even worse, it is only 6 pins of 10 at the end that you cannot use, so not actually easy to tape over just the 6 and still sensibly solder to others. I had read a web site on "safe" GPIO pins, but that documented the ESP32 chip not the ESP32-WROOM-32 module, and for that the pins 6-11 are "safe" to use as GPIO. There are other pins that are iffy - i.e. needs to be high or low at boot. Those I knew about.

The end result is that the keypad boards I made would simply not work! So I was left with three boards in total to take on holiday. The door controller would not "work" for the GPIO pins, but they are not connected to anything that would stop the chip actually working. So usable for developing code. I have managed to trash one board already with a flash / secure boot mix up!

The first thing I did when I got here was re-work my designs on the basis of taping all 10 connectors on the end of the chip. If I had not, it would have been bugging me all holiday. I had to be a bit creative in some cases, but I managed to redesign both boards. I'll mill them when I get back (I don't think my wife would have let me bring the milling machine on holiday for some reason).

Door controller PCB

Update: The RS485 is a challenge. I made a low level bit bashed solution for ESP8266, which I could use. It uses two pins, a Tx/Rx and a DE/RE pin. But the UARTs in the ESP32 have hardware support for RS485 as do the drivers, and are better done with separate Tx, Rx, and DE (RE permanently enabled). So I may re-track the PCB and make a driver using the UART. Again, a redesign of both PCB and code. Overall this is dragging on longer than expected.

Security

Security with any IoT stuff is important, and reading the data sheets on the ESP32 and using the build environment, I can see that Espressif have done their homework. Nothing is 100% secure, but they are really trying hard here - which is good news as a lot of IoT stuff is totally crap!

The chip has a secure boot mode. This means the first stage bootloader in ROM checks the signature on the bootloader in flash before running it. The second stage bootloader checks the signature on the application. Doing an OTA (over the air) s/w update also checks the signature, even. This means you cannot load wrong code on the chip!

It also supports encrypted flash. This means that I can have the code, and all my settings (like login details to the MQTT server, and WiFi) securely stored in the flash. Even pulling it off the board won't get you the data.

It has a set of eFuses, which are built in to the chip. They can only be "blown", so are bits you cannot unset once set. These include bits that stop you reading the eFuses, but they are wired internally in the chip hardware allowing it to encrypt and decrypt the flash. You can even set a fuse to disable the JTAG debug port. This means you can really lock it down so that you cannot get credentials out of the chip or the flash. It might not stop someone de-capping the chip package and using a microscope to read the fuses, but it will stop most conceivable attacks.

They have built in AES, SHA, BIGNUM (RSA) and TRNG hardware as well, and the API makes using https and TLS simple and encouraged.

In short, security seems to have been done very well, and thought about at the outset in the hardware and software design. This is almost unheard of in the IoT world, which is generally pretty shit at security. Well done Espressif.

Update: I said nothing is 100% and a recent tweet suggests hackers have managed to crack it using clock or power glitching, but Espressif have replied saying they are adding hardware changes in the next release out soon! So they do seem to be trying, which is way better than most IoT stuff.

Opportunities

Once I have this starting point - code and PCBs - and it is working, then (apart from updating my existing door controllers), I have to think of other uses for these chips. They are packed with stuff - included a dedicated separate ultra low power processor. The opportunities for very low power devices are interesting. Even just the bluetooth looks fun - I could make it that door entry using a key fob needs to be able to see my phone in range, for example. I am sure there are a lot of opportunities!

They have some interesting direct AP-less WiFi modes in the API as well, and some low rate long range (e.g. 1km) WiFi functions too. There is even a MESH WiFi system. This all makes for some very interesting possibilities to make systems that do not rely on infrastructure such as access points.

I still have not made my environmental monitoring device yet, so that may well be the next project after this.

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.

Relays

In doing a door entry / alarm system, one thing you need is outputs that control things, like a door lock. Whilst we have nice motorised locks for external doors, we also have mag locks for internal doors, but either way you need 12V and some reasonable current (around 0.5A). You cannot do that from a 3.3V output pin that can sink 20mA max.

So you use a relay, obviously.

Mk1: ILS relay board

First off, I found a nice, and reasonably small relay board. It works off 12V and designed to take an ESP-01. It even comes with one.

All I need to do is add my own firmware and I have a 12V powered relay on the WiFi. Simple.

There are a lot of advantages, obviously :-

• Simple single complete module for relay control
• Comes with ESP-01
• Runs off the voltage we are using (be careful, there are 5V versions too)
• No wiring, no PCBs, just load my own firmware
• Also available in 2 and 4 relay modules

 

Mk2: More connectors

Unfortunately I don't just want a relay output, I want a door control. So I made a PCB that allowed an ESP-12F and hence more connectors. With some careful design I made it fit on top of the relay board!

This works. But is starting to get quite bulky. Bear in mind these usually have to fit in the back of a electrical outlet box, e.g. with an "Exit" button or similar. I was also not happy at how warm the main relay board got - it uses a simple linear regulator.

Mk3: Separate 3.3V relay

Time to try using the nice Pololu regulator boards. With a regulator I don't need to use the 12V relay board, I can have a stand alone board. But I still need a relay. So time to use an off the shelf 3.3V relay.

Mk4: Solid state relay

That worked, but really it is still rather chunky. After a bit of hunting around I found some nice solid state relays by Omron. I have always seen solid state relays as quite chunky, but it seems they can come in quite a small package, more than adequate for 12V at a few amps even...

The result, as you see, is a relatively small PCB, with regulator, and header to connect to the NFC reader (it does just fit passed the regulator, honest), and contacts for 12V in, exit button, door closed reed, and lock engaged contacts, as well as a relay output.

Now I just need the sort the right NFC reader and change over one of my doors :-)

Mk5: A remote I/O board (RIO)

WiFi for an alarm system?

I'll post more details later I am sure, but I have again been working on my "Solar System" door entry and alarm system.

The existing system works using Galaxy RS485 peripherals like a "Max Reader". This works, but is there a better way.

Well, WiFi, maybe...

This is a tricky matter to consider. We know WiFi is not as "contained" as wires, meaning more vulnerable to attack and disruption, to say the least.

So, let's consider some pros and cons.

RS485

• Generally very reliable as wires usually are - that said, it has limitations - notably number of devices on the bus (both in terms of physical aspects of RS485, and polling time constraints).
• Hard to access if in the walls, inside the building, but things like Max Readers expose the bus externally (albeit at cost of tripping tamper).
• With any access (e.g. Max Reader) very easy to disrupt (albeit with tripping tamper).
• Very insecure - I have done a proof of concept with access to the bus that can inject messages to open doors, etc, without the slightest hint of a tamper alert from the Galaxy panel.
• Slow
• Needs wiring back to the panel.
• Vulnerable to snooping if you get physical access to bus
• Hard to do redundancy

WiFi

• Vulnerable to RF level attacks (albeit tripping tamper)
• Vulnerable to protocol level disruption (if you get in to WiFi) such as WiFi disconnects or IP flooding or TSP RST flooding.
• Secure if using TLS. Cannot be snooped or faked.
• Fast
• No need to wire back to the panel
• Easy to add a lot of devices (subject to access points that allow lots of associations)
• Harder to do battery backup, but possible - need 12V access points - can be done.
• Possible to do multiple AP fallback and redundancy

So I am making my SolarSystem GitHub project handle WiFi connected devices as an option.

• ESP8266 code for modules
• PCB layouts for modules
• 3D printed cases for modules
• TLS MQTT over WiFi with certificate pinning and checking
• SolarSystem code allows mix and match of RS485 and WiFi connected modules

Not finished yet, but most of the device code in place. I even have a way to use a Galaxy keypad on WiFi!

The door control logic is a relay board with NFC reader, and I am working on proper AES secured cards. The 125kHz proxy cards are stupidly easy to copy!