Introduction
Overview
SecureLED is an optical access control device which replaces current RFID or Magnetic Strip technologies with a cryptographically secure, contact-less device which communicates over commodity Light Emitting Diodes (LEDs).
Project Summary
This project started with one central premise: current physical access control systems are insecure in fundamental ways. We sought a way to remedy this problem, and came accross recent work which demonstrated the potential of communicating over cheap commodity LEDs. We used these as the basis of our system, building on top of it devices which use a cryptographically secure challenge-response protocol to authenciate a user.
As such, we built both a reader and a small key device (which we had originally planned to implement on an ATTiny2313, but did not for reasons listed below). The reader outputs the industry-standard Weigand protocol, so it is interoperable with current systems. All in all, we believe that this solution presents a powerful alternative to current technology.
High Level Design
Rationale
The reader may ask: what advantage does this system present over existing systems based on swipe-cards or RFID tags? First, magnetic swipe-cards are rapidly being removed from service because of the ease with which they can be copied. Both swipe-cards and RFID systems are susceptible to replay attacks: that is, if you can determine the key that the card contains, you can merely “replay” that key to a reader. With both technologies this can be done easily. In the case of magnetic cards, one simply needs to duplicate them using an inexpensive mag-stripe reader/writer. In the case of RFID, hardware designs are available online to allow for the spoofing of RFID signals. We believe that widespread RFID “spoofing” is merely an inevitability.
Existing smart-card systems avoid this problem, and are self-powered; however, they require mechanical contact with the reader. This may be undesirable for a variety of circumstances, including concerns with having outdoor readers exposed to the elements, the speed at which such mechanical contact decays the cards, and the ability to effectively block all authentication (effectively preventing anyone from entering) by simply fouling up the contacts. The ease of such a denial-of-service attack is troubling.
While the LED-key system requires line-of-sight in order to communicate, we see this as an advantage, rather than a disadvantage. RFID devices may be read without the user’s consent or even without the user’s knowledge; the LED-key has a much more intuitive interface where a user must point it at a reader for it to be read. An RFID device would have to be encased in something like tinfoil to prevent unwanted reads. We believe that the LED-key proposes a viable alternative to technologies such as RFID, while adding the line-of-sight-required advantage.
Inspiration
The idea for this project largely grew out of the work of the Mitsubishi Electronics Research Lab (MERL) researchers (see bibliography) which outlines how they first employed LEDs for bidirectional communication. We are consistently surprised by the complexity of access control schemes (this complexity is of course often necessary to ensure security), and we believed that an LED communications scheme could fix many of the security defects present in many modern systems.
Background Math
There is no terribly relevant background math germane to this project. The cryptographic algorithm we selected, TEA, is a Feistel cipher, which means that a function is repeatedly applied to the input and the key for a certain number of rounds. Output from earlier rounds is fed into later rounds. The goal is to build a function that is easy to invert with the key, but difficult to invert without it. The advantage of a Feistel structure in constructing a cipher is that the round function need not be invertible, but can be any arbitrary combination of the input.
There has been no successful cryptanalysis of TEA to date that we are aware of.
The cryptography that is used in our system is quite simple: first the key is sent a one-time-random number (a nonce, or number used once) which is encrypted with the key that they both share. The key decrypts this nonce, adds its key ID to the nonce, and then re-encrypts this new value to be sent back to the reader (a diagram which demonstrates this can be found in the “highlevel system state diagram” section under “logical structure”)
This system ensures that the shared secret key is never transmitted over the air. It also ensures that the actual reader contains something which is not easily duplicated: simply overhearing the conversation does not allow you to present a valid key, as it would in the case of a magnetic stripe reader or RFID tag.
Furthermore, because the key_id is combined into the actual encrypted message, the system is free from man-in-the-middle attacks in some sense. One cannot intercept a message, change the key-id in the message and then send it back to the reader. However, it is still susceptible to a man-in-the-middle attack in the general case, where the entire challenge is passed on to a key and relayed back to the reader.
The line-of-sight restriction addresses this issue: the attacker would have have to place a counterfeit reader unit between the actual wall-mounted reader and the user, and negotiate both sides of the SecureLED exchange. Such a counterfeit device should arouse considerable suspicion in the user.
Logical Structure
access control system topology
A traditional access control system consists of three parts: an access control device such as a magnetic card or RFID tag, a device reader, and an access control server. In access control systems utilizing the Wiegand protocol (which we have implemented for interoperability), the device reader has a unidirectional connection with the access control server, so the reader is simply responsible for sending the data that it read off of the access control device. Because of the unidirectional communication, the server is responsible for actually opening the door (generally via a magnetic striker), and even changing LEDs or a beeper present on the access control reader. The reader only ever sends the data that it has read off a card.
highlevel system state diagram
Our system is divided into two separate units: a key reader, and the actual key. They each have on them an identical shared secret which allows them to communicate securely. A breakdown of the system is demonstrated below.
When the reader comes up, it initializes the LED Communications subsystem (LEDComm), and waits for a key to come into range. When the key comes into view, it attempts to perform a clock synchronization. If the two devices can sync, then we have a channel over which data can be sent serially. The reader then issues a challenge by sending an encrypted random number for the key to process, and waits for the key to return a response to the challenge. The key computes the response by decrypting the encrypted random number, adding its key-id to the number, and then re-encrypting the modified number. This encrypted reply is then sent to the reader unit.
In this way the secret key is never transmitted, but it can be ensured that the key actually knows the key (by simply performing the same computation on the reader and comparing the reply from the key). If they match, then the key is considered to be valid, and the key ID that is provided is sent over the Wiegand protocol to an authenticating server which can then choose to open the door with this information.
Hardware/Software Tradeoffs
The main tradeoff that we made was actually performing the cryptography in software. We used the TEA algorithm, mostly because it was one of the only algorithms that we could fit in the 128 bytes of RAM on the ATTiny2313. There are numerous hardware cryptography chips that could be used to use different cryptographic algorithms; however, we wished to keep extra hardware to a minimum and do all we could in software. Additionally, TEA as implemented is cryptographically secure, so this is not a concern. Moreover, the amount of code necessary to integrate these chips would likely have outweighed their benefits (the Tiny only has 2K of program memory, and does not provide native support for I2C or SPI, so we would likely have had to implement these in software). We believe that choosing a cryptographic algorithm in software is an acceptable solution in this case.
Another point worth nothing is that we do not make any special provision for key storage in this application, we simply rely on the Atmel’s EEPROM. In a real application, we would likely want to use a tamper-resistant memory, so that if anyone attempted to extract the shared secret from the device, the memory would be destroyed and the key rendered unreadable. Currently, if one simply reads back the EEPROM, the shared secret can be obtained. Some protection against this can be obtained by setting the appropriate ATmega memory lock bits.
Standards Compliance
LEDcomm protocol
We did not find any standards directly related to the implementation of communication over the LED; however, the scheme that we used was identical to that described by the MERL researchers. It is essentially highly similar to 8-N-1 RS232; however it is half-duplex (each unit takes a turn to send one bit), and MARK and SPACE symbols are sent as pulse-width-modulated light pulses instead of as voltage levels.
Wiegand protocol
To implement communications with an access control system, we implemented the industry-standard Wiegand protocol. The protocol is quite simple, and provides two data lines, one for 1 and one for 0. Both lines are held high by default. The message is sent bitwise by holding the appropriate line low for 5 micro-seconds, followed by holding both lines high for 2ms. The end of a message is indicated by holding both lines up for more than 50ms. A timing diagram is provided below:
This information was taken from a Circuit Cellar article from 2004. We re-implemented this project in C (we did not take anything from the original implementation at all except their description of the Wiegand protocol description), in order to demonstrate that our Wiegand output will be interoperable with current systems. We also tested our reader with existing Wiegand hardware, again to ensure that the output that we produce is 100% compatible with industry standards.
The Wiegand protocol also specifies certain open formats that can be used for interoperability. We chose to implement the 26-bit payload, which is supported by many access control systems. The packet payload looks like:
It should be noted that bits in the packet are sent MSB first, so b2 (the first sent bit in the facility code), actually corresponds to the highest bit in that code. This was one of the important pieces of information that we took away from actually experimenting with Wiegand hardware, as we were unable to ascertain this fact from any of the online documentation that we could find.
For our application we always send a facility code of 1. Each key supports a 16-bit card number.
The Wiegand-Reader hardware that we had to experiment with the Wiegand protocol read original Wiegand-effect cards. It reads 26-bit cards, and also 30-bit cards from Corby, Inc. Marked as “High Security”. We were unable to find any documentation online about the format of this card, however we were able to determine the format experimentally. The layout was as follows:
Here F represents a facility code, S represents a “card serial-number” and C represents the card number. The meaning of the serial-number is unknown. The C bits represent the actual card number, however for some reason they seem to be stored (bitwise) inverted on the card, which is curious because the facility bits are stored uninverted. E and O represent even and odd parity bits respectively which, as with the 26-bit payload each are parity for half the message.
In any case, we did everything that we could to ensure that we were in compliance with the Wiegand standard so that our reader was interoperable with current access-control systems.
Intellectual Property Concerns
The research done by Dietz, Yerazunis, and Midgal (the authors of the MERL paper from which we took our inspiration) was awarded U.S. Patent 6,870,148 (“LED with controlled capacitive discharge for photo sensing”) on March 22, 2005. If our project was productized, this work would have to be licensed under some terms.
We do not know of any other concerns that would apply to this project. The Wiegand protocol is an open industry standard and has no IP protection that we can find, despite an extensive search. The cryptographic algorithm that we have utilized (Wheeler and Needham’s TEA algorithm) is unencumbered.
Hardware Design
The system consists of a reader unit and a key unit. We also built a Wiegand protocol decoder, but this was only to demonstrate that our system is functioning correctly, so it is not factored into our budget (Professor Land said this was fine). We had originally planned to implement the key on an ATTiny2313 (and a custom board, pictured below); however, we were forced to change our plans at the last minute when we discovered that we could not get the final revision of our code down to below 2K (the size of the program flash memory on the Tiny2313). Up until the day before the project was due, our code was below 2K, but the final day we had to make changes that made the code-size go up to 2150 bytes, and we were unable to reclaim any space to make the key run on the Tiny. Unfortunately we were unable to order a small micro-controller which would have satisfied our needs (the ATTiny44, 84 or 85 would have been quite sufficient) in time for the project deadline. Luckily, our budget had plenty of slack, so we simply chose to use another Bruce-Land-board with an ATMega32 on it for demonstration purposes.