RFID Access

From Hive13 Wiki
Revision as of 17:40, 11 July 2017 by Greg J Arnold (talk | contribs) (Update wiring colors)
Jump to navigation Jump to search



Hive13 Project
RFID Access System
Arduino-RFID-Door-Lock.jpg
Status: Active
Start Date: 1/12/2012


Overview

Summary

The purpose of this project is to build a modular RFID Access System that can be productized. It will be open source and open hardware. It is hopeful that other hackerspaces will adopt this so it can become fairly standardized. Right now pretty much every hackerspace has rolled their own device.

  • Requirements
    • Accepts NFC tags and phones with NFC for access and tracking control
    • Central database (Postgres, accessed via HTTP, served by a Perl Catalyst app)

Project Manager

Contributors

What needs to be done

Main Door RFID

  • Battery backup somehow?

Annex Door RFID

  • Refuses to accept badges intermittently?
  • Finish drawing schematic, post it here, get circuit board made, remove mess above door.
  • Battery backup somehow?

Vending Machine RFID

  • Send sold out messages to the server - the machine knows the state of the switches currently.

The Snack Vending Machine has been gutted, its coin validator removed, and RFID card mounted to the machine, however, no work has been done to bring that machine to vending status.

Catalyst App

  • Actually do something with the temperatures presented to it.
  • Add in OpenID Support
    • Facebook/Foursquare Checkins to the hive on entry
    • Twitter updates on entry
  • IRC Notifications

Places it'd be nice to have badge readers

  • Doors out to annex hallway
  • Outside door by the Dumpster
  • Certification-only tools

Notes

GitHub link for Arduino Code: [1]

GitHub link for intweb Server code: [2]

Github link for RFID hardware: Hah, it hasn't made it up there yet. :(

Enrollment Station

One of the goals of this project is to build a case where cash payments to the hive can be recorded (and membership automatically extended), and cash payments can be automatically made to the card for the purposes of purchasing sodas, vending machine items, or laser minutes.

This project is in the planning phase right now -- however, if you want to help, I would appreciate the time and can provide my guidance for this project.

Hardware

Jon has created a board the has some processing power and can provide 3.3v, 5v, and 12v rails via power over ethernet and another board that can do 13.56MHz NFC/RFID. The boards have been built and tested, but need firmware to be written for them. Code and progress can be seen on [[3]].

Wiring Diagrams

Scanner to MCU wiring

  • This is correct for the annex door
  • The main door needs to have its wiring changed to match.
Function Scanner Wire Color Ethernet cable wire color
Wiegand D0 Green Green
Wiegand D1 White White/Green
Light Grey Orange
Beeper Purple White/Orange
+12V Red Both blues
Ground Black Both browns


Requirements

  • standardized rest api
  • Very modular (shields)
  • NFC and RFID so phones and smaller cards/tags are supported
  • Basic board cost under $50
  • Fairly small footprint and power consumption


nice to have

  • standard case?
  • screen to display information
  • current measurement device (current transformer) to measure how long a tool is on.
  • esp8266 support for wireless

current use cases

Doors

  • "tool" that everyone has access to for main doors?
  • Some spaces want a bit more security by way of PINs and cards.
  • lockers are tools that only an individual person has access to.

Tools

  • Some spaces want a timeout
  • Least controversial method so far is tap card to enable tool, push a button to disable tool when finished. No timeout.

Vending machines

  • Need to deduct credits/dollars from a stored value securely.

Member registration/payment terminal

  • Need to securely add credits/dollars to a stored value.
  • Need to also be able to associate a card ID with an account. Maybe multiple card/phone IDs? PIN as well

Protocol and Database Info

Server <-> RFID reader protocol

  • Each request is sent from the RFID to the server as a POST with a JSON body.
  • Each device has a key pre-shared with the server to mutually authenticate w/o SSL, which some of our MCUs have no hope of doing.
  • The data object contains a "device" key with the name of the device requesting access - if the server doesn't know about this device, it'll fail.
  • The data object also contains an operation - if not', 'access' is assumed. Other options are 'vend' and 'log'. Currently, 'log' does nothing but return a success.
  • Finally, for "vend" or "access", the data object contains a "badge" key, containing the presented badge number.
  • The checksum is computed like this: (Here's where it's done on the server.)
    1. Sort all of the keys recursively on the data object.
    2. Remove all unnecessary whitespace.
    3. Prepend the device's shared key.
    4. Take the SHA-512 checksum of that string - encode as a hex string using uppercase letters (It shouldn't matter, but I can't remember if the RFID MCUs do a strcasecmp() or not)
    5. Create an object with keys of data and checksum - that object is the body of the request or response.
  • Each data object has a "random" field - this is random per-packet data to stop replay attacks
  • Each request should contain a "random_response" field - this must be copied from the request to the response if present; this solves a different subset of replay attacks.

Current protocol weaknesses and notes

  • You can capture a packet going to the server and replay it again and again and the server will accept it and process it.
    • This could add junk log entries to the access log
    • This could also drain someone's soda credits.
    • Solution is the server tells the client what nonce it expects back in the next packet, and stores that in the DB. We'd also need an operation to get that nonce if the MCU lost it.
  • You CANNOT replay the response to a successful badge swipe, because
    1. The MCU only listens after a badge is presented
    2. The MCU generates a new "random_response" field
    3. The MCU verifies that the response packet's field matches what it sent.

Database Layout

  • Conventions
    • All tables have a ${table_name}_id column that's a UUID as the primary key
    • Many-to-many tables have the two tables they connect in alpha order
      • They do not have their own, separate ID field
      • They have the primary key as the two tables in alpha order
      • There is a second key of the two columns reversed (this way is needed for the other foreign key)
    • Table names are singular
    • Catalyst convention is to use Pascal case for table names.
    • Postgres convention is to use Snake case for table names.
  • "members" stores member information. It needs renamed to "member" for consistency, though the app calls it "Member" with a name override.
  • "badge" stores a badge number and which member it belongs to - you can have multiple badges per account
  • "mgroup" stores the names and IDs of various groups, such as members, leadership, laser certified, &c. It's called mgroup because "group" is an SQL reserved word.
  • "member_mgroup" is a many-to-many association table to join members to groups.
  • "device" stores information about a device - its shared key and name right now.
  • "item" stores information about items that can be accessed - doors, tools, and so on.
  • "device_item" is a many-to-many showing which devices can service which items.
  • "item_mgroup" is a many-to-many granting access to an item to a group.