Specification and proposal for keypad entry to the hackerspace.

Specification and proposal for keypad entry to the hackerspace.

At a recent members meeting it was agreed entry to the space via a keypad would be useful. Therefore the aim of this project is to add a secure way for access codes to be set, which can be entered via an external keypad in order to get in.

This will benefit:

  • Users who forget their fobs or prefer using a code
  • Contractors who aren’t members but are doing work at the space
  • Admin team, who can set codes for the landlord or other “one off” situations. These codes can eventually become “single use” or “gift vouchers” should the desire arise.
  • New members, who won’t have to wait to set up a fob

Brief overview of current setup

An RFID reader is connected to an FTDI board, which communicates with a Pi over serial. The Pi also has an input from the big exit button and an output to the lock circuitry which releases the door. The Pi fetches a list of valid fob IDs regularly, and when a fob is presented it checks if there’s a match.

Proposed setup

The only visible change will be the addition of a keypad.

In the new system, a “code” is some user input from outside the space, and can either be a “key code” (from a keypad) or a “fob code” (from an RFID reader).

System overview

code = entered code
fdbk = feedback (for a green light, for example)

Setting codes

A code is set in the member system in the same way as a fob is set. This means we can treat entry codes as just that and won’t need to distinguish between fob codes or key codes. We can also add some nice UI bits to help users differentiate between key codes and fob codes as well as a “wizard” for setting key codes.

Entering codes

Each code entry device will be connected to its own Arduino which will handle the many input wires and present a unified interface to the master controller which is the Rapsberry Pi. I2C will be used for communication between the master and input boards. A program will run on the Pi and will be written in Python.

The separate Arduino boards aim to separate concerns (and code), and will interpret data from their connected input device, provide any feedback to the user such as beeps to indicate a key press, and, if a valid input is received (which will also act as a degree of sanitisation), send it to the Pi. The Pi, reading from the input boards, checks the information against a list of valid codes. Voltage shifters will be used between the Pi and Arduinos. All components are generic and modular allowing easy replacement, reprogramming, or removal when an updated and custom access system is implemented.

The only valid data from the fob reader will be a-f and 0-9, and the only valid data from the keypad will be 0-9, clear(*) and enter(#). The keypad will only send key codes to the Pi once the enter key has been pressed - this allows codes of many lengths to be used. There will be a reasonable (say, 50) maximum length to prevent anyone being overly smart trying to crash the system.

To prevent brute forcing of codes, which is more likely to happen from the keypad, the keypad will “lock out” for some time after three incorrect codes are entered (proposing 30s increasing to 120s). If this proves problematic from misuse, we can enforce a “code entry mode”, where two zeros must be entered first to enable the keypad. This reduces the chance dramatically of someone entering invalid codes and causing lockouts.

Security considerations

The main security risks we face are:

  • Insecure codes set by users that are easy to guess
  • Forced entry
  • Damage to equipment

Each of these is considered in turn.

Insecure codes that are easy to guess

To prevent users setting easy to guess codes which would undo any other security measures, there will be both encouragement to set secure codes and enforcement against insecure codes.


When setting codes, users are encouraged to set a date, such as their birthday, and then two random characters, e.g. ddmmyyyyab - this 10 character code will offer good security. This can be done by a “wizard” which asks for a memorable date and then generates random numbers as a suggested code.


When codes are set and entered, a check will be done to deny insecure codes. This prevents insecure codes from being set and in the event that fails, prevents an insecure code from being accepted.
This will forbid codes that are:

  • too short (1234)
  • too many proceeding occurances of the same number (11111111)
  • too many incrementing or decrementing numbers (123456, 987654)
  • obvious codes (80085)
  • codes with repeating patterns (1010101010).
  • codes that match the keypad layout (741 852 963)

Forced entry

For physical security, the only thing on the insecure (outside) side will be the RFID reader, and keypad. Everything else will be on the secure side. They keypad will be placed such that it will not weaken the door - so no holes will be made in the door itself. The keypad will be mounted by the door on the brick, with no large holes into the space to prevent someone using tools to get in. Additionally, security screws could be used to deter someone from unscrewing the keypad.

Additionally delays are added for incorrect codes. These won’t hinder correct code entries but will delay someone outside trying random codes. The aim is to slow, frustrate and bore them. The fob reader doesn’t have any delay built in, the age old joke being “if they’re using spoofed IDs to get in, then they probably belong inside anyway”.

Damage to equipment

If someone forces off the fob reader or keypad, it should just expose low voltage wires that do not activate the lock directly. A tamper switch could be implemented to isolated the keypad until reset inside.


The code mustn’t:

  • store any secrets in the code (which will be managed via environment variables.)
  • have any “testing codes” in it when in production

The code must:

  • be able to handle unreasonable inputs
  • Maintain a list of logs that go back a reasonable number of days
  • be resilient to power downs
  • fail secure
  • be super simple and understandable so as many people can understand it (and improve/critique it)

The code should:

  • Indicate to users the state of the system
  • Push activity to the membership system API
  • Be extendable such as allowing “One Time Access” codes

Not a current member but noticed this - be aware in your threat model of people attacking the cable using a punchdown tool and building a store / replay bug.

The BLEKey does this easily for wiegand and something similar could probably be built for the system below relatively easily. https://hackerwarehouse.com/product/blekey/

I am not sure there is a way to sensibly mitigate for this short of buying modern commercial hardware (HID / Saito / an ATM EPP) off of ebay and using challenge response though.

Other options include a way of releasing the door from your web account using a random code valid for 5 minutes, or Google authenticator / freeOTP style TOTP codes, if someone fancies a coding challenge.

It may be that it is not worth addressing this issue due to cost / benefit / risk and likelihood of someone doing that unless getting in was part of their job…

1 Like

Thanks for the feedback - I’m not actually sure what protections the current system has against this.

Sadly the specifics of RFID tech isn’t my field, hopefully someone who has a better knowledge of the current system can chime in.

I also like the authenticator idea a lot. Would be fun to implement!

I would suggest that if we introduce a keypad that we purchase 1 that has a built it rfid scanner that is compatible with the existing system. This would simplify the entire system and reduce the holes required in the door.

Not sure what the purpose of the Arduinos but would suggest they are dropped in favour of directly interfacing with the pi.

Also for added security could we add a 5 second delay after a failed code is enter and before a new code will be accepted. This will hopefully prevent a brute force attempt or make it painfully slow.

Happy to help

This is better than most requirements I get from clients. Really great breakdown.

a keypad does unfortunately override the useful tracking of who has been into the space, which I think may be currently being used to track for COVID usages.
I was thinking would it be easier to have a option from the member login to access a page which has a “let me in” button which calls to the door lock to open.
If that isn’t great, then how about a page in the member system which generates a per-day/per-user code that can be got from there to enter.

of smart bus that allows the blocking of replay attacks. Our current reader users the Weigand34 which goes to the pi “hat” I made which takes the
Weigand34 and makes a serial to the Pi for the ID sent. I think we have the eagle and firmware files somewhere…

I would make sure you do not buy the cheapest RC522 module off china, they are very picky about what they will
read, the red ones from the original manufaturere are the best and will read MIFARE and other cards.

the logging of those who have been into the space won’t be lost as everyone has their own keycode we can still track entry through the log and conor’s plan is to ensure that this is in accessible format for the board to use for COVID Track & Trace without the need to ssh into the door find the logs and export them etc.

Rossy beat me to it regarding the tracking issue.

Not sure what you mean when you say of “smart bus that allows the blocking of replay attacks”.


I think the RFID reader we use at the moment is one of the expensive good ones
that reads lots of different types of tags and is weatherproofed, so I would be careful about using a cheapo one, as Ben has said they tend to be picky over the types of card they’ll read and range.

One idea might be a custom metal box that contains a keypad and one of the same types of rfid reader mounted on the front. And have that box mounted on the front door over the top of the hole.
Perhaps with a button for the door bell.

  • Try and avoid any exposed cable, to prevent someone cutting the cable for example.
  • Try and put any kind of logic such as pausing if someone tries a brute force on the inside of the door not in the box on the outside of the door.
  • Illuminated keypad for when it gets dark / and to make it look cooler, bonus points if you can make it flash different colors for correct / incorrect combinations. (maybe Green for when not used, Red for denied, Blue for Accepted.
  • Have any mounting bolts originating from the inside out to avoid someone having a go with a screwdriver / torx bit.

If you want to get really paranoid then mount some glass ampules with something in around the outer edge of the box

With some teargas or if you want to be really nasty phosgene


Many Thanks

Thanks all for the feedback, it’s really appreciated.

To address the questions which others have also raised offline (which are good points):

  • the arduinos serve purely to reduce the number of cables going into the Pi and to enable the code to be split up as much as possible. I’m not committed to this approach though, if we can cleanly code and wire in the keypad (7 wires, matrix formation) and RFID module (5? Wires) then I’m up for that.

  • will be reusing the existing fob reader, as mentioned, it’s good quality. Keypad is bought and is nice and metal and heavy duty.

  • help is absolutely appreciated! I’m struggling with general life at the moment, so a plan and team working will be great.

  • all logic and so on is inside :slight_smile:

  • I was told outside this thread that I2C won’t be compatible with future systems due to length of the bus. Planned to keep circuit boards physically together in an enclosure, but am happy to investigate having two serial connections into the pi instead of I2C if we think this will improve reliability

this might be an idea

for arduino to rpi maybe
or perhaps just raw serial
1 Like

Bit of an update, and sorry for the delay!

Following a demand to get an accurate idea of how busy the space is due to the covid (without cameras), a few people asked me to get the hackscreen and telegram bot back. The main problem with this is that it doesn’t show who is currently in, it just shows when someone scanned in, and only if they set an announce name. It also kind of reached the end of its life, the TV uses too much power so isn’t very useful, and then I had an idea :bulb:

What meets the needs and fits in nicely with the above plan, at least temporaily, is allowing and encouraging people to tap in and tap out.

The two arduinos exist in the updated plan still, and while one handles the exterior RFID reader as before, the other now handles an internal one instead of the external keypad. People can then tap in and optionally tap out. The exit buttons will still work if people don’t want to or are just popping out. The Pi will keep a tally of ins and outs, and report, when requested, the number of people who are in at that time, without revealing who they are.

This means from telegram you could soon be able to go /howbusy and be told “There are 4 people reported to be in”. At say 4am each day, the list of tap ins/outs resets so forgetting to tap out won’t have a huge effect over time. We could even look into allowing a remote tap out through telegram, such as /tapout fobid - if people think that would be useful.

Turns out the reader on the outside of the door uses the Wiegand interface, which is super easy to interface with and it’s designed to work over 100s of meters. Therefore, having the wiegand readers wherever they need to be, connected to a control box which has the Pi and Arduinos together seems like a good implementation. That way, when a keypad needs to be introduced, we can just get a Wiegand keypad for cheap and add it in without any modifications. Even better, the Arduinos just plug into the Pi via USB so it’s all very simple and straightforward.

I’ve been putting together a test system and once it’s in an enclosure with the everything installed I’ll add it alongside the current system. If and when we’re wanting to move over to the new system, it’ll simply be a case of connecting the external reader to the new system, leaving the current system turned off but in situ. That way there’s a fallback and no hardware from the old system will have been touched.

The new box has a clear front so members can see inside and get to understand how it works. There’s LED indications (of course) which show if the reader is present for easy debugging. I also intend to document this both online and also labelling things on the enclosure, so that people can get to understand how it works and reduces maintenance burden in the future.

The logs are comprehensive - both debug logs and error logs. Any error logs makes an error LED illuminate for someone authorised to look into. Like at the moment, we’d want to restrict who can get to the logs. Currently it’s done by SSH keys. This can continue with the new system, or eventually the logs can be sent somewhere such as email or the member system.

Currently logs exist until deleted but I intend to get the logs rotating daily, and then auto deleting after a few months or so. The logs store no personal information but they would store RFID numbers that appear on any of the readers.

All items are modular, cheap, and replacable/upgradeable

  • Arduino nano * 2
  • Mini USB->USB cable * 2
  • Raspberry Pi
  • 12v-5v converter - this takes the 12v coming from the UPS and powers the Pi and the Arduinos over USB. The 12v is also needed for the Wiegand readers.
  • Cable and connectors - currently trialling DIN connectorswith alarm cable, but can upgrade to aviation connectors which feature locks if somehow the cables get unplugged.

I’ll take some photos when it’s in a box and not sprawled out.

It handles special characters too, so emojis will soon be back! :tada:

Edit: I recorded a brief overview of it