User Tools

Site Tools


Access System

Goal: Provide a 'keyless' entry mechanism to the side door, i.e via NFC or RFID.

Mailing list thread

Current developers: Mathew McBride, Geoff Lethbridge, Wes Black, Stuart Young, StefanL, Barbara, Lachlan, others.

A lot of the information below pertains to when the system was in planning stage. While this is cleaned up, here is the pages most relevant to the current state of the system:

Component overview

(source system_overview.odg)

Kent Lane Access System

The 5 Kent lane Hackerspace needs a better locking system to best accommodate the wonderful expansion of member numbers and times they wish to enter.

Problem is that 'old school' style keys can be copied a bit too easily, can be lost/stolen, tend to remain 'out there' with people that have left the group, and are expensive. If a key is lost and suspected stolen, it requires the lock(s) and all keys to be replaced very quickly lest the wrong people gain entry to the area.

Also, there's no log of who entered the area or when.

Better to have a more modern system that can delete that one key ID, such as a swipe card or RFID tag system.

There may be some 'off the shelf' solutions, but they can be tricky and do require some thought. I (Wes) have even wondered about a cheap, integrated, durable system for places such as schools for which problems with keys and users are a frequent nightmare, but no convenient solution exists.

It has already been suggested that:

Basically, the following components will be needed to set up this system.

a) The 'central' electronic controller unit that needs to sit on the secure side of the door. This would incorporate a method to store user IDs, and manage this list. Ideally, it would connect to a computer or even web server for conveniently editing the user ID list easily and from off-site via secure connection. Connection to a burglar/fire alarm and alerting us if an error state exists (or forced entry) would also be sweet.

b) The door strike and bolt which should ‘fail-closed’ in power-out situations, with following exceptions. A manual over-ride (i.e., a key/lock system) is always highly advised. It must be able to be fitted to the current frame/door combination, and must be resistant to wind/water/vandals/likely forced entry methods (e.g., kicks, crowbars), as also the most likely thing that would allow inapt. entry: forgetting to lock it. Such a door strike and lock must also have some means of emergency manual over-ride such as a push-bar in event of fire that can be easily and reliably operated even in zero visibility due to smoke with associated lack of coordination, etc., subject to exact building code for ‘limited place of assembly.’ (Turns out, no real requirements per se). Also, ideally a simple doorknob and latch just to stop the door banging in the breeze and to allow entry, but doesn’t compromise any of the above.

c) A power supply and power cabling, for example 240VAC to 12VDC with appropriate voltage and current to run both the controller and the strike solenoid. Ideally, a UPS backup.

d) The RFID tag 'reader' and/or access keypad that needs to sit on the non-secure side of the door, which must be robust, resistant to wind/water/vandals, and reliable.

e) Some data cabling to connect (a), (b) and © together, unless a wireless system .

f) If RFID is to be used, some number of RFID tags compatible with the RFID frequency used by the unit. Also, that these RFID tags are cheap/reliable/durable, and not easily 'hacked' or cloned. Issues 1) Door currently has an E-shaped pin style rimlock on it (similar to a Lockwood 303 - ). At the space, the door-frame part is mounted sideways to how it appears in the picture on that page. No one has yet suggested a strike that matches this design.

The door strike as at 19 Jun, 2012: On closer inspection (outside is to right of picture) it isn’t possible to kick or shoulder the door inwards given the outward opening door. The ‘E-type’ strike could be taken out in a few seconds via two screws. Putting in an electronic strike may require some grinding, but nothing too dramatic. Placement of a small metal plate on the door edge would prevent use of a crescent shaped tool (jemmy) to unlatch the spring loaded bolt. Ideally, the plate would use ‘hidden’ bolts accessible only when the door is open via L-shaped bent section extending in between door and frame.

Note: May be worth re-hinging the door on the opposite side (and/or replacing if cheap enough). Specifically, when outside, the door is currently Left hinged and outward opening. It may be better for the door to be Right hinged and outward opening. This would put any locking mechanism (and push-bar opening) far away from the window on the right side. Issues with this would be changing the pneumatic door closer, and possibly patching the existing door-lock hole in the door (may have to be done anyway if we actually replace the lock, rather than just installing a new one along side it). Door strike for controlling building access points. Reversible design suits left or right hand hinged doors. Slimline design makes it suitable for most metal door frames. Available in either fail-secure (power unlocking) or fail-safe (power locking) configurations. Designed to be powered momentarily ie: long enough to “buzz” somebody into a premises. Power must not be constantly applied to the strike. Operating current: 360mA @ 12V DC. Locked in power failure for access doors

Suits metal door frames.

2) The door opens outwards. As such, a standard frame-based strike would therefore be mounted with the strike on the outside of the door frame. To protect the strike (from being hot-wired or from the bolt being jimmied), we'd have to put a large sheet of steel on the door that extends from the door over the strike area. If anyone went to LCA2012 in Ballarat and stayed in the on-campus accommodation, this was the reason for those huge plates that stuck out sideways on the doors of each unit were for. Making this secure isn't the easiest thing, and will most likely require making a large hole in the brickwork, rather than just the door frame.

3) An option to have the door unlocked but closed would be preferred eg: with the use of a pneumatic door closer. Thanks, to Stuart / Cefair, this is well sorted! Wes put a kind of door handle thingy on the out side that was actually a bit of metal strap rescued from discarded downpipe and two screws, so now door can be opened without use of fingernails between door and frame.

4) The roller-door. Firstly there is no key-lock on the inside of the roller-door, meaning that it can’t be opened from the inside. Additionally, the roller-door is damaged (does not fully close unless downward force is placed on the bottom edge), which would compromise any electronic opening system placed on the door. The roller-door has a few cracks in it too, which is sub-optimal. �Controller The controller comes in many options:

1) Off the shelf ie: or the like


No real work to be done. Just set it up/install it and start using it.


Ties us down to a specific type of access mechanism (eg: keypad).
   Lots of garbage on the market - may not be as secure as expected due to vendor sloppiness.
   Internal documentation is sparse or nonexistent.
   Not easily customisable (aka open to being hacked on/improved).

2) New Bespoke design ie: we make our own


We know exactly how it works.
   Not tied down to any specific access mechanism.


Getting boards and the like made.
   Code still has to be written.
   Will probably go through a few iterations till we get it right.

3) Existing community design ie: Something like the SNARC (being developed by HSBNE).


We know exactly how it works.
   Little needed in designing boards, except for future expansion.
   While RFID supported OOTB, not tied down to a specific access mechanism.
   Usable for other items that need access control (lathe, mill, laser cutter).


Code still needs to be written (in development).
   Still early in the design phase, so it’s possible h/ware may still evolve.

Lock Side door Choices for lock/strike combinations for the:

a) A bolt based lock similar to: - installed in parallel with the existing lock. Existing lock will be left 'unlocked' by default, relying on the new lock unless absolutely required (eg: physical issue with new lock).


Should be compatible with existing door setup/design (can be mounted close enough to central door point to not require removal of existing lock).
   Openable during power out (requires lock barrel).
   Does not require external modifications to the door frame/brickwork.
   Very robust and resistant to intrusion (dead-bolt design).
   Fixed open/closed state (can be left in open state) so door can be left open (electronically or manually).
   Redundancy of second lock in door in case of physical damage to lock.


Possibly more expensive (TBD).
   Requires more current to drive.

b) A new lock and an edge strike such as: - Replacing the current lock.


Possibly cheaper (TBD).
   Requires less current to drive.
   Openable during power out.


Will most likely require total replacement of current lock.
   Not compatible with the current lock (would require the purchase of an additional lock mechanism & throwing away the new strike to be replaced with the electronic one).
   Will require extensive work to door frame/brickwork and door to install the strike and to make the setup resistant to entry.
   Door will only stay open while current is applied (temp open state - should not be driven continuously - as per specs) or if the lock is manually opened/closed. Depending on lock, to manually open/close it, this will either require:
       A key for the lock, possibly leading to theft/loss of the key (part of the problem we want to avoid).
       A lock that can be manually opened from the inside (ie: if someone can get into the space, they can then easily exit the space through the door with all our stuff, rather than through the way they got in).

Roller door No solution has yet been posited for the roller door.

This would most likely require some sort of automatic roller-door controller, and as mentioned under Issues, replacement of the actual roller-door so that it closes properly.

There can at least be sensors for roller door open / close position.

Other Regarding key codes vs RFID/NFC.


These may be easily copied (investigation needed). This brings us back to the issue of keys being lost/duplicated. There are ways around copying that should be investigated.
  • 'Front door reader'
    • Raspberri Pi or other embedded Linux system
    • An NFC reader compatible with libnfc
    • Speaker and LEDs for user feedback
    • Electronic door lock mechanism - can still be opened with a traditional key
  • Management system
    • Holds database of allowed and blacklisted keys, audit log
  • Notification system
    • Hope to find an existing solution. Want something that will notify relevant people of important events, as last resort (SMS based?)
  • Watchdog
    • Also hope to find an existing solution. Reset components as needed, report when they fail completely, or if we are running low on backup power
  • Security system
    • Want to be able to integrate one in the future - cameras, sensors etc.

Functionality Requirements

Tag/ Front door reader

  • Card security
    • Based on MiFare Classic 1K for now, provision for other NFC tag types in future
      • NFC phones especially - need to investigate
      • Using existing NFC cards from elsewhere (i.e myki) ruled out - security issues (see this mailing list post)
    • Check if card is lost or revoked from database
    • Check if card has been tampered/copied
      • Could be a 'nonce' written to the card on each contact, checked with server etc. MiFare 1K cards can be easily spoofed / copied if precautions are not taken! Assume plaintext of card contents will become available no matter how secure card is!
    • Check if card holder has permissions required
      • i.e Only certain people may be allowed to open/close outside of defined operating hours
      • Functionality could be expanded beyond just doors - i.e equipment could be locked out until the holder has been educated on safe use.
  • Physical security
    • There are door locking mechanisms available that report if the door is physically opened or closed , report if door gets opened when it shouldn't be
  • User interface
    • Want to be fast, ~1sec. If process slow, provide some visual acknowledgement via LEDs that the system is 'thinking' (5sec max time was discussed but still too long, IMO - Matt)
    • Have a speaker on board to play sounds
  • Events
    • Log all events - card presented, access granted to audit log on server
    • Door open event should generate an event to MQTT messaging server
  • Form factor
    • This part needs to live outside, want to be temperature and tamper proof

Management system

  • Have a list of cards in database
    • Interface for adding/formatting new cards
    • Interface for blocking/revoking existing cards
    • Interface for manipulating user groups - a user may be a member of multiple groups.
  • Allow time periods to be defined
    • i.e allow the door to remain opened during certain events
  • Statistics
    • Provide anonymous entry number statistics
  • View audit log

Current progress

  • Prototype installation of the Pi, NFC reader and door latch has been done. Functionally complete; about to commence “dogfood” phase.
  • New, less messy, break out board for the Pi I/O is being designed (Geoff).
  • Only NFC tags supported for now, NFC P2P (smartphone) requires substantial work.

Discussed Ideas

In progress…..

The current implementation ideas are as follows:

  1. The CMS software used by CCHS will be the authorative database for the card details. These will be manually updated for card changes.
  2. The card and necessary membership details will be 'sucked' out of the main CMS database for use in a database on the authorisation server.
  3. The card reader setup will check cards against the database on the authorisation server.
  4. Should the synchronisation between the main CMS database and the authorisation server fail for a certain period, the system will fall into a 'restricted' mode where only a certain number of people (eg: Committee and selected duty-members) can open the space.
  • Cards will be formatted/prepared on a (dedicated) PC at the hackerspace.
    • Hardware
      • Same reference hardware used in the reader, most likely interfaced over USB
    • Software
      • Will display what needs to be added to the main database, so that the card details can be updated manually.
      • Will NOT keep any history of what is put on the cards (eg: a log) to avoid the same credentials being re-used somehow.
  • Authorisation server
    • Isolation
      • Separate users will be used to run processes that update the authorisation database from the CMS and to run access control mechanisms, keeping them isolated from each other.
    • Database
      • Writeable only by the user that pulls information from the CMS.
      • Readable only by the user that talks to the NFC reader.
    • Hardware
      • At this stage, the assumption is to use a Raspberry Pi, however this may change.
  • CMS
    • NFC data
      • Extra fields will need to be created in the CMS to hold the necessary NFC data for authorisation/access.
      • Data will be manually entered into the CMS, as a means of access control.
      • Data will be either retrieved using the CMS API, or by directly accessing the data in the CMS database.
    • User data
      • Also to be stored is information regarding what groups the user will have access to with their card (for finer grained access control).
        • Groups such as: Door control, machine access, etc.
  • NFC cards
  • Notes
    • Update process will write a global “last update time” on the server, using the authorisation servers time-date, based on the successful completion of the update process.
    • The authorisation server will check the last update time. If the update more than a pre-defined amount of time in the past (eg: 3 hours), then the system will only allow a specific group access to the space.
project/cchs/access_system/start.txt · Last modified: 2015/04/16 19:58 by projectgus