Difference between revisions of "Vuvuzela"

From Freeside Atlanta
Jump to: navigation, search
(System Overview)
Line 9: Line 9:
 
* Centralized management of groups and access rights
 
* Centralized management of groups and access rights
 
* Platform for easily programming actions not limited to sounds on RFID swipe
 
* Platform for easily programming actions not limited to sounds on RFID swipe
* Secure access control nodes (very difficult to hack)
+
* "Secure" access control nodes
  
 
=== System Overview ===
 
=== System Overview ===
Line 34: Line 34:
  
 
* [http://raspberrypi.stackexchange.com/questions/4637/cannot-read-input-to-sda-scl-gpio-pins Stack Exchange Raspberry Pi Q&A - Cannot Read Input to SDA/SCL GPIO Pins]
 
* [http://raspberrypi.stackexchange.com/questions/4637/cannot-read-input-to-sda-scl-gpio-pins Stack Exchange Raspberry Pi Q&A - Cannot Read Input to SDA/SCL GPIO Pins]
 +
 +
=== Hacking ===
 +
 +
There are some possible ways to hack this system, and some counter-hacks.
 +
 +
One way is to swap out the SD card on the Raspi.  Our plan was to put the node into an enclosure, like the kind used to lock up a thermostat.  Even if the SD card is replaced, the attacker needs the right software installed plus the location of the SQLite file.  Plus, we'll be putting the nodes behind the secured door.
 +
 +
Another attack would be to perform man-in-the-middle on rsync.  We'll take a couple of measures to mitigate that, including putting the nodes on their own dedicated subnet, with firewall and routing tables that drive traffic and communication only to the centralized server.
 +
 +
Because the node will be on battery backup, the most viable attack is to cut-off the power and wait for the battery to die.  We would likely broadcast a power failure to IT, so we'd know to come down and wait for the power to come back up.  That means the internet needs to be cut-off as well.  Probably a polling script could notify IT of an internet outage, so it would be 1-2 hours maximum that we wouldn't know both services were down.  Since the Raspi is a low-power device, it would remain operational and keep the doors locked for several hours, at least 12+ hours.
  
 
=== Future Work ===
 
=== Future Work ===

Revision as of 03:02, 29 January 2013

Contents

Open Source Access Control

The Vuvuzela project was originally meant to recreate our member welcome noise: whenever a member would strike their RFID badge, a sound of their choice would play.

The prototype circuit from the RFID reader into the Pi Cobbler

It then grew into a larger effort to create an access control solution for Freeside that would have the following characteristics:

  • Centralized management of groups and access rights
  • Platform for easily programming actions not limited to sounds on RFID swipe
  • "Secure" access control nodes

System Overview

So far, we've assembled a prototype system that works like this:

  • The central server MySQL database puts our members into groups, like IT-Staff or Members
  • A central server daemon generates access control lists (ACLs) from tables in a MySQL database
  • These ACLs are pulled from the central server by each node, using rsync
  • Each ACL is specific to a node and relay pair, and is just a table in a SQLite file
  • A node is a Raspberry Pi, with an RFID reader fed into its GPIO, and a relay shield to operate up to four locks
  • Logging is sent back to the server via the SQLite file, and aggregated

For example, we could attach two door locks to one node: the server room door on relay 0, and the front door on relay 1. The node named "joker" would pull down the ACLs for joker-0.db and joker-1.db from the server's /srv directory. joker-0.db has a table called "access" which is just a list of acceptable 8-character token IDs, which correspond to the RFID token IDs that are assigned to each member in the "IT-Staff" group. Likewise, joker-1.db just has the token IDs for each member of "Members" group. So, any Freeside member can get in the front door, but only IT staff can get into the server room.

In addition, we could send notification emails to the head of IT every time the server room was accessed.

If you're interested in helping out with this project, contact Alan about participating, or follow the project at:

Some other related material:

Hacking

There are some possible ways to hack this system, and some counter-hacks.

One way is to swap out the SD card on the Raspi. Our plan was to put the node into an enclosure, like the kind used to lock up a thermostat. Even if the SD card is replaced, the attacker needs the right software installed plus the location of the SQLite file. Plus, we'll be putting the nodes behind the secured door.

Another attack would be to perform man-in-the-middle on rsync. We'll take a couple of measures to mitigate that, including putting the nodes on their own dedicated subnet, with firewall and routing tables that drive traffic and communication only to the centralized server.

Because the node will be on battery backup, the most viable attack is to cut-off the power and wait for the battery to die. We would likely broadcast a power failure to IT, so we'd know to come down and wait for the power to come back up. That means the internet needs to be cut-off as well. Probably a polling script could notify IT of an internet outage, so it would be 1-2 hours maximum that we wouldn't know both services were down. Since the Raspi is a low-power device, it would remain operational and keep the doors locked for several hours, at least 12+ hours.

Future Work

  • Group management via LDAP and not MySQL tables
  • Implement web API for managing user information
  • Design plug-in system for playing sounds, email, etc.
  • Manufacture integrated RFID reader and relay shield for Raspberry Pi
Personal tools
Namespaces

Variants
Actions
About Us
Support Us
Activities and Culture
Membership
Outreach
Leadership
Teams
Organization
Toolbox