Keyless Entry

Threat model: 5–5–5

Our system should be secure against a talented hacker who is willing to spend:

• 5 minutes
• $5 (excluding any items that can be found in the space)
• 5 google searches

Access tokens

iButton

iButtons are small 1-wire devices that have a unique 7-byte serial number and often also an EEPROM. The iButton component of our system will use DS1961S iButtons that have a SHA-1 engine. An 8-byte secret is stored in the button's EEPROM on setup. We can then issue 3-byte challenges, and the button will respond with a SHA-1 hash of the challenge, its serial number, and other data. This is more secure than anything else affordable that we have considered.

Every button will have a unique 8-byte secret. These secrets are stored on a server. The server issues challenges and verifies hashes. We need connectivity to the server to verify hashes.

As a backup, we could have a list of serial numbers of buttons that have access. When there is no connection to the server, we can fall back to verifying serial numbers only. This is vulnerable to an attacker who purposefully disrupts the connection to the server.

iButton via BodyCom

BodyCom is a method of sending data through a capacitive coupled connection to the human body.

I intend to make a system consisting of 2- LR44's, a vibration motor, a uC, the MCP2035 front-end, and an iButton socket as to use the same credentials of the iButton but in a more user-friendly manner. By keeping the system on yourself, it should be possible to unlock the door by touching any part of your body to the reader. For improved coupling it will be recommended to keep the system inside your underwear. The vibration motor will be used to notify the user that the iButton is being accessed. This should alert the user that someone is trying to take their credentials if they are not touching the reader.

MIFARE Classic 1K RFID

MIFARE Classic 1K are cheap and easy to obtain. Unfortunately they are not compatible with common NYC area RFID tokens such as NYU student IDs and Citi Bike keys. Charlie Cards from Boston do use MIFARE Classic, but few members commute in from Boston.

The crypto for MIFARE Classic is thoroughly broken. The cards are also easily cloned. The security amounts to being able to write data to the card, and reading it again, without any guarantees of uniqueness or secrecy.

We can mitigate this by writing a new 48-byte authenticator token every time a card is used, and require a card with the new authenticator for the next access attempt. This way a card can be cloned, but only one of the clones is useful in the future. We can also write a public key signature issued by the server, so cards can be verified by an offline device even when that card has never been seen before.

Out of band

It will also be possible to log on to a website and order unlocks remotely.

Mechanical

Electric strike

This is less mechanically secure, but much easier to deal with and to troubleshoot if something goes wrong.

Gears

Nickolai will be taking the lead on the mechanical portion, please send any and all comments, concerns, feedback to him.

Options:

1) Scrap existing lock and buy an electronic lock designed for keyless entry (kinda boring, we are a hackerspace after all)

2) Fit a part of the existing lock, and connect it to a servo, which would of course be connected to an arduino-like device which is itself connected to an RFID reader that scans member's keyless entry cards. See photos below

My only concern with #2 is that the best way to attached the gear to the current lock, in my view, is epoxy. If the gear wears out sufficiently it may be difficult, although certainly not impossible, to replace.

rmd: This one should be able to turn even a fairly tough deadbolt: https://www.sparkfun.com/products/11881 I wouldn't use epoxy to connect it, I'd lathe something out of aluminum to fit the deadbolt knob, and bolt the servo frame securely to the inside of the door.

Nickolai: I ordered this one: https://www.sparkfun.com/products/9347, if it's not strong enough I'll order that one, thanks for the link.

Here's a CAD image of what I think the system design will look like:

It simply fits over the existing lock and is held in place by set screws. Dave and I (Nickolai) printed out a test piece and found that it works best with the two set screws on top and bottom (along the major axis of the ellipse), otherwise the screws tend to impinge upon the knob and force the assembly to bite into the lock, significantly increasing the torque required to move it.

The few holes on the smaller gear are how it mounts to the servo. The gears were designed using a gear design toolbox in Autodesk Inventor, so they shouldn't have any problems meshing. Just need to print and put in place.

Last edited by: Nickolai

Electrical

Front door

We are using an AQV252G solid state relay to short the two wires in the intercom that need to be shorted to operate the buzzer.

The line to the solid state relay is connected to pin 14 on the WRTnode, which can be configured as GPIO 37. We suspect that it is currently still operational as the SPI slave select pin, which is idle high. We can operate the buzzer by cycling pin mode between output and input.

(Note: It should be moved to GPIO 0, but this requires the ladder.)

Space door

There is now a beautiful electric strike installed by User:Stove. It is connected to another AQV252G solid state relay connected to a WRTnode, on GPIO 0.

Here is the wiring:

Interface

Both front door and space door strikeplates are controlled by WRTnodes. They will mainly be managed by separate server software, which will SSH into the WRTnodes to control them.

Transition

Goals for the transition:

• Both old and new systems work for a period of time
• Minimize disruption to members who do not show up very often

Current space door lock

Once we transition to the electric strike, the top deadbolt lock will not be used a lot and needs to be effectively disabled. It would still be useful to have it around as a backup. One solution could be to remove the pin that currently locks it in place, and put it back if we ever need a backup. We could also rekey the lock.

Mail tokens

Members who come in regularly can mail can obtain a token easily. Members who are not around so often could be mailed a new RFID or iButton.

Web based email authenticated system

We have the email addresses of all the members, but not necessarily an account with username/password anywhere.

For members who do not come in frequently, we could ask them to use a smartphone or similar to enter their email into a box. The system would then email them a special link, which will open the door for the next 15 minutes.

Lock box

We could get a new cylinder keyed to the same key as the current top space door lock. This cylinder would not be attached to an actual lock, but would be mounted in a box with a switch inside. Members could then insert their key and rotate the cylinder, to prove that they are authorized. That would send an electronic signal to actuate the electric strikeplate.

• One possibility would be to remove the mating plate for the deadbolt, and install a simple limit switch/other sensor where the bolt passes. When someone needs to open the door using the key, if they successfully turn the lock, the strike plate gets triggered for a moment. It would work for UNLOCKING, but since locking is automatic via the strike plate, it wouldn't matter. It's a kluge, but it would work (I think!) -Matt
• This would be great if it works. All we need is a transitional solution. Eventually every member will have the Final Solution. --Guan (talk) 14:45, 28 May 2015 (UTC)

Database

The backend will handle authenticating incoming RFID requests, as well as database administration.

Frontends

Frontends may be accessible over the Internet, but should be restricted to https only connections. It may also be worthwhile to limit administrative commands over the Internet to minimize hacking risk.

Photos

Prototype for a keyless entry system that would fit over the existing lock.

Left: SD card placeholder, for size comparison. Right, a prototype of a part of a system that would fit over the existing lock. The part would be geared in the final version.

The part would fit over the lock like this:

Then a servo could be attached to the door to the left of the lock.

Protocol specifications

iButton

Communication is over a serial port. We use NMEA style framing, where all messages start with $, and end in an asterisk, a two-nibble (1 byte) zero padded upper case hex representing the XOR of all the bytes between $ and *, and CRLF. Unlike NMEA, the maximum line length is not 82 characters. Instead, it is defined by the longest message in use, and currently 135 characters. Most long byte sequences, such as ID numbers and hashes, are sent least significant or lowest memory address first. See special scheme for SHA-1 hashes.

Peripheral to host

PBUTN

Used to indicate that a new button has been detected. One argument, the address of the button detected.

$PBUTN,33E9FC6E01000045*7B

PSTAT

Used to indicate the result of the previous operation. Arguments are ID, operation type and status code (0 for success).

$PSTAT,33E9FC6E01000045,WRITESECRET,0*1F

PPAGE

Result of an authenticated page read. Arguments are ID, page address (2-byte 0-padded hex), and page contents.

$PPAGE,33E9FC6E0100004,0000,0000000000000000000000000000000000000000000000000000000000000000,02E0F65CBC7277C358352C19B1138CE95DBF185D*70

Host to peripheral

HWRSC

Store a secret. Arguments are ID and secret (8 bytes). On the peripheral, this combines write scratchpad and load first secret operations.

$HWRSC,33E9FC6E01000045,0000000000000000*57

HVRFY

Issue 3-byte challenge (write to scratchpad 5th, 6th and 7th byte) and read authenticated page. Arguments are ID, challenge (3 bytes).

$HVRFY,33E9FC6E01000045,000000*59

This is a convenience method to carry out common verify operations. It is left to the controller which page to read on and what else to write to the scratchpad.

SHA-1 sequence

The output state of the SHA-1 algorithm is communicated using the scheme described in Table 2 of the DS1961S datasheet. The words are sent in the order E, D, C, B, A. Within each word, bytes are sent least significant byte first.

Forget

People forget things. It's normal. Not everyone is expected to have everything with them. However, if enough members forget their RFIDs, maybe it is time to re-evaluate what we use to authenticate.

Access Methods

Method	Equipment Cost	Pros	Cons	Links
Fingerprint	$16.99	Can't forget your fingers...		https://www.microcenter.com/product/635840/adafruit-industries-ultra-slim-round-fingerprint-sensor-and-6-pin-cable
NFC	Example	Example
Facial Recognition	Example	Example
n/a	n/a	n/a	n/a