Resources/Access System

From Noisebridge
(Redirected from Access System)
Jump to navigation Jump to search
Noisebridge | About | Visit | 272 | Manual | Contact | Guilds | Resources | Events | Projects | WGs | 5MoF | Meetings | Donate V · T · E
272 Capp St. | Layout | Parking | Fence | Access | Patio | Entrance | Front | Hackitorium | Stage | Lockers | Stairs | Upstairs | Classrooms | Exits | Roll up door | Bathrooms | Network | Roof | Audio | AV | Construction | Electrical | Print Shop | Elevator | Back hall | Back patio | Fire escape | Plants | Sustenance | Housekeeping V · T · E


Oldcomputer.png
Note: This page is for historic purposes only. It does not apply to modern Noisebridge. | Edit

Overview[edit | edit source]

This page discusses possibilities for future access control systems. The system being built at 2169 Mission is just a prox card reader.

Disclaimer[edit | edit source]

The subject of access systems for Noisebridge has turned into great _pain_ a number of times in our history since we turned into a physical static space. Here's a summery of points everyone eventually gets to during these discussions, listed here so newcomers can get a general idea of why some folks tend to get a little defensive about the subject...

General notes:

  • All access systems have problems. Nothing is actually secure, even with physical keys.
  • All access systems could potential be a mouth watering target for a hacker, electronic systems more so then physical systems.
  • All electronic authentication systems to gain access to a space could potential be used to log traffic, even with "anonymous keys".
  • Physical systems (such as with a key) give the greatest amount of anonymity, but isn't 100% anonymous if someone wanted to log traffic.
  • RFID systems, no matter how secure and "key change" prone still have the possibility of tracking a user with a system independent of its intended access system (like a high power RFID scanner setup across the street).
  • Electronic access systems give the greatest ability to deny access to a target user or group of users.

Access systems and Noisebridge:

  • The building at 2169 Mission has other tenants, and is owned by someone other than Noisebridge. Have courtesy and respect for their needs and rights with regard to building access (and of course generally).
  • There are a number of members that would like their access traffic to Noisebridge not to be logged, ever.
  • There are a number of members who have stated that if an electronic system (no matter how secure) was to be setup and forced onto all users of Noisebridge, it'll be removed and possibly destroyed or disabled.
  • Many members do not appreciate the idea of access "control" and the potential to deny a user or group of users access to Noisebridge.
  • There is no official "access control" group at Noisebridge to act as a policing body to enforce any particular type of authentication system or to reprimand anyone for hacking into a system.
  • No one has objected to setting up an opt in access system, and so one has been setup using either SSH or HTTP and the Noisebridge network.

So it comes down to this, if you'd like to setup an access system at Noisebridge, make it so it's opt in without affecting anything else that's been previously setup. Keeping the physical key system constant and functional makes pretty much most members happy, as well as the owner and the other tenants. Also asking users for creative input on making a opt in system functional and fairly sure via the list is a good idea, but don't expect to only get positive input about something.

Possibilities[edit | edit source]

(Copied and formatted from a mail from David Molnar --steen)

Here's what I see needs to be done right now:

1) Identify choices for the overall system architecture Each choice should tell us at a minimum

  • what kind of key cards do we need?
  • what kind of physical lock do we need?
  • what back end hardware do we need to issue new cards, revoke old ones, and do logging?

The choices so far:

  • A) das Labor's AnonAccess system

http://events.ccc.de/congress/2007/Fahrplan/attachments/989_anonaccess.pdf

  • B) Something that uses DESFire cards from NXP (formerly Philips)
  • C) Something that uses IBM's Caernarvon system, as mentioned for example here:

http://cups.cs.cmu.edu/soups/2006/proceedings/p114_karger.pdf

  • D) iButton locks - while the basic iButton is roughly like a prox card, there are NVRAM iButtons that could be used with an AnonAccess system.

2) Find suppliers, prices for each choice

  • For example, the code for the AnonAccess backend is in a public SVN repository, can be browsed here:

https://roulette.das-labor.org/trac/browser/microcontroller-2/AnonAccess?rev=2278

  • This is a site that sells several types of smart cards, including the DESFire cards:

http://www.smartcardworld.com/mifaredesfire.htm

  • I've seen that some knowledgeable Dutch hackers use a 'Salto' DESFire system rather than a mechanical lock.

The key point of uncertainty for me is the actual door lock assembly. What exactly do we need here, and how do we install it into the actual door? What does the lock cost?

For example, this data sheet specifically mentions DESFire compatibility, but it does not state a price. We need someone to call these people up and find out the price, figure out if it can fit on our current door, etc. http://www.saltosystems.com/index.php?option=com_content&task=view&id=45&Itemid=44


What you can do:

  • Contact the das Labor people and ask them who their suppliers are. We would probably be happy just copying their setup outright. Also ask about their door lock setup.
  • Contact the people with the data sheet above and find out if that lock will work with our door and how much it costs. If it doesn't work, find out if they have a lock that works.
  • Find out what back end software we need or special equipment we need if we go the DESFire route.
  • I have contacted Paul Karger at IBM to ask about Caernarvon. If you happen to find a supplier that can work with us on that option, that'd be cool too.

Physical cylinders and other lock mechanisms[edit | edit source]

  1. The Brute is a popular magnetic lock using in high security settings. It can be purchased for around $390 [1].
  2. iButton reader plus lock. Default firmware appears to use the iButton as just a prox card, though. http://www.ibuttonlock.com/product/e3-rf.htm
  3. Electric strikes and electric locks. Card reader not included. http://www.nokey.com/elstrikandma.html

We probably want to have more than one locking mechanism to ensure that it's hard to break down the door.

Multi-factor authentication[edit | edit source]

It seems reasonable that if we use an access card system that we make ourselves, we should consider adding a secondary authentication step using a PIN. This would be a nice addition to AnonAccess (but perhaps they've already considered it). We should consider acquiring a pin pad with several specific properties. One of the important properties is the ability to withstand the possibly harsh street weather (read: people messing with the door lock system). Another would be to prevent shoulder surfing of pin entry codes. It would be nice if we could find a pin entry system that had a fixed key pad but where the keys changed their meaning at each run. In such a system, rather than a simple 1-9 on a key pad, the 1-9 key space would shuffle the numbers around. The Schlage Model SERIII Scramble Keypad seems like it would do the job just perfectly. The Hirsch ScramblePad (pdf) also includes a proxcard reader.

Door reinforcements[edit | edit source]

We should ensure that we have a strike plate on the outside of the door. It should be laser or watercut 3 or 4mm sheet steel of high quality.


Extending AnonAccess[edit | edit source]

If we (and it looks like we will) implement AnonAccess, we should consider a number of modifications. It would be nice to add in some element of tamper resistance. We should be able to detect and react to temperature related issues (such as these temperature sensors ). It would also be nice to have some kind of light sensitive circuit to detect when the cases have been opened (such as these IR sensors).

Adding in a secondary mode of authentication such as the ScramblePad would also be nice. However, for $1000, we could design and build a new project (OpenScramblePad).

Transparent Door[edit | edit source]

The door currently has a peephole. It would be nice if we put a small camera on the door or in the peephole (like this one). This would allow us to broadcast the video from the front door to screens on the back of the door or in other areas of the space.

The CCC Lock[edit | edit source]

Some people in the CCC are creating an open source lock ( code can be found on their svn system ). It's based on the burgwächter TSE3000 cylinder, externally driven by their own custom electronics. It uses the Sputnik air interface for a simple crypto protocol. Hopefully the lock is in a state where we can replicate it in the near future.

Cerberus-prox[edit | edit source]

http://code.google.com/p/cerberus-prox/ is from http://hacklab.to/, our friendly friends to the north. Just prox card et cetera but it is working and done by friendly people.

Resources[edit | edit source]