In July 2012 at a Black Hat conference, Cody Brocious demonstrated how he could hack the keycard system used in hotels by spoofing the “portable programmer” device meant to be used for designating master keys and opening Onity brand locks whose batteries had died. With his $50 homemade device (consisting of a Arduino Mega microcontroller board, a 5.6k resistor, and a coaxial barrel connector), he could insert the plug of the device into the port located at the bottom of Onity locks, read the digital key, and instantly unlock the lock. Now the device seems to have slipped into the wild as a spate of hotels in Texas are reporting breakins that they assume were conducted using the Brocious keycard device. After the breakins, hotel management checked security records and confirmed that cleaning personnel had not used their keycards to enter the rooms. In fact, the records showed nobody had entered the room. Still, travelers reported items stolen from their room including purses and electronic gear. Hotel management soon confirmed that the hotel room locks had been hacked.
After Brocious demonstrated the device at the Black Hat conference, other hackers and researchers refined the device, ironed out bugs, and worked to disguise the device (one disguised it as an iPhone while another fit the contraption inside a dry eraser body). YouTube videos of the device in action began popping up online soon thereafter. Hotels began blocking the Onity port with epoxy putty until a more permanent fix can be implemented. Still, it is estimated that many hotels have yet to block access to the port.
Todd Seiders of Petra Risk Solutions told Forbes magazine:
“We’re expecting incidents in which these devices are used to explode nationally. As crooks find success with it, they’re going to go back to the Internet and say ‘hey, it works. I was able to break into ten rooms.’ And then others build it and try it. We’re going to get hit hard over the next year.”
The presentation slides from the Black Hat conference may be viewed here (PDF).
For the hardcore geeks, here’s a bit of technical detail from the presentation regarding the hardware, vulnerabilities, locks and communication protocol.
When a guest checks into a hotel, the first step in the Onity system is to create one or more keycards. The room name/number is entered into the encoder, followed by the number of nights of the stay (for expiration purposes) and the number of cards to make. Cards are inserted in order and encoded with the proper data for the room.
Once the guest inserts their card in the lock for the first time, several things happen:
- The padding bits on the card are validated and the lock immediately rejects it if these are malformed
- The card is decrypted using the sitecode (32-bit identifier that uniquely identifies a hotel property and is the key to the security of the entire system) on the lock
- The checksum on the card is validated and the lock rejects the card if it does not match
- The expiration date is checked along with flags and the shift that the card is for, rejecting the card if it’s not within the valid times
- Finally, the code key value is checked and the lock opens if it is within the lookahead range
What is on a hotel keycard
While some pieces of the keycard have been discussed previously, the following is a complete breakdown of its structure:
- 16-bit ident value
- 8-bit flags byte
- 16-bit expiration date
- 8-bit authorizations byte (not relevant to this discussion)
- 24-bit unknown (zeros)
- 24-bit code key value
This is then encrypted with the property’s sitecode and stored in track 3 of a standard magstripe card.
Communications with the lock take place over a bidirectional single-wire protocol. On the bottom of the lock, on the outside of the door, there is a DC barrel connector, more commonly used for power. This carries data on one wire and ground on the other. On top of this is the high-level protocol enabling the reading of memory and opening the lock.
- Arduino Mega 128 (a microcontroller board based on the ATmega128)
- 5.6k resistor
- DC (coaxial) barrel connector, 5mm outer diameter, 2.1mm inner diameter
Attach the resistor from 3.3v power on the Arduino to digital IO pin 3. Attach digital IO pin 3 to the inner contact on the DC connector. Attach ground from the Arduino to the outer contact on the DC connector.
Given the ability to read the memory of the lock, and knowledge of the location of the sitecode in memory, it’s trivial to read the sitecode and then send that in the opening command. This gives instant access to the door and will merely show in the audit log as the opening function of the PP having been used.
This can be done in under a quarter of a second, and a device implementing such an attack is detailed in appendix A.
Master card creation
Because of the ability to read the memory of the lock, we can likewise read the master code key values out of the lock and then produce our own master keycards. These will behave identically to those given to staff members, and will gain entry to any door containing that master code. This does not mean necessarily that a single card will work for every door, of course, because masters could be split among a property. For instance, a hotel may configure the masters such that there are three master types, with a housekeeping group each assigned to one of these. In such a configuration, gaining access to one of these master keys will only get you access to a third of the property.
Programming card creation
With access to the memory, we are able to get the sitecode and programming card code for the property. With these, we are able to create a programming card which will work for every lock. Creating a spare card requires no knowledge of the property or locks whatsoever and can be done ahead of time. After using the programming card on the door, simply introduce the spare card and the lock will open. In the future, it’s possible to simply use that spare card again and gain access perpetually, at least until a new guest card is introduced.
Spare card manipulation
Due to the lack of crypto and the fact that spare cards are created incrementally, it’s possible to manipulate spare card values to gain access to another room. Take the case of a hotel where the encoder is out of service and guests are being checked in manually by staff, using spare cards. If you are given a spare card with the value 1234, you could change this to 1233 or 1235 and attempt to access doors. Due to the incremental nature of the card, it’s highly likely that this will allow entry to a door at the property, though determining which door it will open would be roughly impossible without other knowledge.
Basic cryptography breaks
Given the small keyspace and the lack of real cryptography on the keycards, there are a couple of simple attacks that can be performed. As a consequence of the way cards are encrypted, only a small part of the sitecode is used for each byte and this can be used in conjunction with known relationships to determine the sitecode. For instance, if you check into a hotel room and get two keycards, the only thing that will differ between these are a single bit of the ident field. Likewise, if you know the expiration dates for multiple cards, you can use the differences between those as a guide.