Difference between revisions of "Opendoor Project"
|Line 2:||Line 2:|
== OpenDoor Project Page ==
== OpenDoor Project Page ==
Revision as of 12:15, 24 February 2011
Property "ProjectImage" (as page type) with input value "4377802647" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
|Start Date: 12/08/2010|
|End Date: 12/12/2010|
OpenDoor Project Page
This page contains info in regards to the Opendoor hack-a-thon project. This project is on Dec, 11th 2010. Blurb below:
The OpenDoor Hackathon is a hackathon to benefit the members of hacker/maker/artist/co-working spaces by creating a standardized, Open Source access and membership management system that can be used by everyone. At the end of the hackathon, the systems (or subsystems) created by each space will be voted upon, and the best system (or combination of systems) will be chosen. Implementing the system afterward is, of course, optional.
Why are we doing this? I know, the word “standardized” sends chills down my spine too, but I assure you that this is a good thing! Deciding upon a common system would enable the following things:
- The ability to share membership between spaces
- Crowd-sourced security enhancements and feature additions
- Easier membership management
- A warm fuzzy feeling of being connected with other spaces
What we’re envisioning (and what many of you already have) is a sort of Reciprocikey or Space Passport system. We believe that the only way to create such an awesome system is to work together on it!
- Software for access control (reads from memory stored users and network user databases)
- Create a functional specification for how authentication can be done securely.
- Software that manages membership rights (grants rights/features to users based on conditions specified by managers
- Standardize an interface specification for how custom software can talk to the access control software interface.
- example: 3rd party space has a member visiting, presents auth token.
- example: someone wants to create a custom trusted UI (web, phone, etc.) for talking to the auth daemon
- Web, phone, etc UI for membership management and access control software
- Involve user interface management. See what tools people are using today to manage membership and build hooks in the software to manage access control, or build your own.
- Hardware for reading identity (RFID reader, USB stick, etc.)
- Build plug-ins to support common hardware (don't get stuck on any given vendor).
Our proposed solution
Use rfid MIFARE buttons to provide both an identity as well as an authentication source. The buttons we are using support 1k of storage and are often used as secure payment systems. An additional benefit to this method allows for the button to be "stamped" by the space. A user can have a history of spaces they have visited stored right on their button!
The way this works is a reader is attached to a door system. This can be added to an existing security system or could be the only security on the door. When a user approaches with an rfid badge the system scans it and checks to see if it is a passport button. If so it then reads the authentication URL off of the button.
This URL is then checked against a policy list. This is a simple list of known hackerspaces and how to treat the request. For instance if you have a sewing club down the street and you have an agreement with them to share space, then their members can use your space and your members can use theirs anytime they want. That is the easiest of access rules and is a simple accept policy (white list). A more common rule would be to have an allowed hackerspace access but ONLY if a member is already in the space (grey list). More details on how that is accomplished later. And finally if the hackerspace URL is not in the list or if it is not a valid passport button or if it a rival hackerspace that you do not trust (tsk tsk) then reject it (black list).
The system then uses the URL and passes in your ID from the button. The URL either returns a 1 or a 0. 1 means the user is still an active member and 0 means the user is no longer a member. If the user is still an active member of that hackerspace they will get a "stamp". A stamp is just a small unique ID given to each hackerspace. The user can later bring his badge to a reader to view all of their stamps. Note: A stamp does not actually mean you went inside, it simply means you are a member of a hackerspace and you physically visited another hackerspace (or at least their door ;)
If all is good the door unlocks for a brief period of time.
Here are the basic parts we used:
- RFID Module - SM130 Mifare - Complete Read/Write Module (~$30)
- RFID Tags - We got one of each of the 1k transponders from sparkfun (~$3)
- Computer to handle the door access controls
- Public Webserver for authentication (PHP Script)
Mifare Classic is a secure memory (1Kbyte, 4KByte) chip/card often called contactless smart card. The reason it is called smartcard is because it has increment and decrement functions designed for especially payment systems. Mifare Classic family of tags is being used in RFID applications where very high security and fast data collection systems are required. This family of tags has contactless communication speed up to 106 KHz and uses very strong encryption techniques.
These offer encryption to prevent cloning but for a generic passport system I'm not sure that can be deployed.
The plan is to have a simple PHP script that can check MySQL, LDAP or a text file for a list of valid button IDs.