Vuvuzela - Revision history

Emptyset: /* Hacking */

2013-01-29T04:21:02Z

‎Hacking

Emptyset: /* Hacking */

2013-01-29T04:17:26Z

‎Hacking

Emptyset at 03:02, 29 January 2013

2013-01-29T03:02:03Z

Emptyset: /* System Overview */

2013-01-29T02:48:04Z

‎System Overview

Emptyset at 02:46, 29 January 2013

2013-01-29T02:46:21Z

Emptyset: /* Vuvuzela, Open Source Access Control */

2013-01-29T02:30:55Z

‎Vuvuzela, Open Source Access Control

Emptyset: /* Vuvuzela, Open Source Access Control */

2013-01-29T02:26:32Z

‎Vuvuzela, Open Source Access Control

Emptyset at 02:21, 29 January 2013

2013-01-29T02:21:55Z

Emptyset: Created page with "=== Vuvuzela, Open Source Access Control === The Vuvuzela project was originally meant to recreate our member welcome noise: whenever a member would strike their RFID badge, ..."

2013-01-29T02:21:35Z

Created page with "=== Vuvuzela, Open Source Access Control === The Vuvuzela project was originally meant to recreate our member welcome noise: whenever a member would strike their RFID badge, ..."

New page

=== Vuvuzela, 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.

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 (very difficult to hack)

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 over SSH
* 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 [[User:Emptyset Alan]] about participating, or follow the project at:

* [https://github.com/emptyset/vuvuzela/tree/batman Github]
* [https://trello.com/board/vuvuzela/4f2e969c73c9e4eb24380692 Trello]

@@ Line 45: / Line 45: @@
 Failure to sync just means that any new users won't be allowed to open a lock, so anyone in the existing group can still get in.
-The next obvious point of attack is the central server.  A user that obtains root on our central server could reset the MySQL root password and then alter the MySQL tables to include the attacker's RFID token ID into the target ACL.  Physical access to the central server is restricted by the server room door.  A service could be exploited on the server.  However, the server would be on a dedicated subnet for administration machines, and traffic limited to it.  There would be no reason for the central server to be exposed to the internet.  An attacker would have to VPN into the Freeside members-only subnet as an administrator in order to be allowed to ssh into machines in the administration subnet.
+The next obvious point of attack is the central server.  A user that obtains root on our central server could reset the MySQL root password and then alter the MySQL tables to include the attacker's RFID token ID into the target ACL.  Physical access to the central server is restricted by the server room door.
 Because the node will be on battery backup, the next 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 attacker would have to cut off the internet access 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.

@@ Line 41: / Line 41: @@
 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.
+Another attack would be to perform [https://en.wikipedia.org/wiki/Man-in-the-middle_attack 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.  So, the attacker would have to get onto our protected members-only LAN, and then bypass the firewall and routing tables to initiate MITM.  Of course, by passing StrictHostKeyChecking=yes as an argument to rsync, then the transfer isn't initiated.
-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.
+Failure to sync just means that any new users won't be allowed to open a lock, so anyone in the existing group can still get in.
 === Future Work ===

@@ Line 9: / Line 9: @@
 * Centralized management of groups and access rights
 * 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 ===
@@ 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]
 === Future Work ===

← Older revision		Revision as of 02:26, 29 January 2013
Line 2:		Line 2:

	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 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.
		+
		+	[[File:raspi-circuit-fixed.jpg\|framed\|right\|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:		It then grew into a larger effort to create an access control solution for Freeside that would have the following characteristics:

@@ Line 15: / Line 15: @@
 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
+* The central server [https://www.mysql.com 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 over SSH
+* These ACLs are pulled from the central server by each node, using [http://linux.die.net/man/1/rsync rsync]
-* Each ACL is specific to a node and relay pair, and is just a table in a SQLite file
+* Each ACL is specific to a node and relay pair, and is just a table in a [https://www.sqlite.org SQLite] file
 * A node is a [http://www.raspberrypi.org 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

@@ Line 1: / Line 1: @@
-=== Vuvuzela, Open Source Access Control ===
+=== 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.
@@ Line 10: / Line 10: @@
 * Platform for easily programming actions not limited to sounds on RFID swipe
 * Secure access control nodes (very difficult to hack)
 So far, we've assembled a prototype system that works like this:
@@ Line 28: / Line 30: @@
 * [https://github.com/emptyset/vuvuzela/tree/batman Github]
 * [https://trello.com/board/vuvuzela/4f2e969c73c9e4eb24380692 Trello]

@@ Line 22: / Line 22: @@
 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 [[User:Emptyset Alan]] about participating, or follow the project at:
+If you're interested in helping out with this project, contact [[User:Emptyset| Alan]] about participating, or follow the project at:
 * [https://github.com/emptyset/vuvuzela/tree/batman Github]
 * [https://trello.com/board/vuvuzela/4f2e969c73c9e4eb24380692 Trello]