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