HN's Daeken will expose security flaw in 4m hotel room keycard locks

All due respect to the work you're doing – I'm a former member of the security industry myself (worked on the IPS engine at TippingPoint).

Are these guys "buying up" security flaws in locks similar to others who sell these kinds of things for software?

Thanks from all us who spend our weekdays living in hotels.

This is a long shot, but I was in a chain hotel in midtown recently and heard someone tampering with the lock, and found the door ajar in the morning. I realize you probably can't name specific hotels, but was one by any chance a chain hotel in midtown around the 11th?

Given that, I felt that they would delay, delay, delay, and delay some more before finally going silent, at which point I would be forced to do this anyway. Simply put, I have zero confidence in their ability to mitigate this properly, and I believe that the only proper course of action is to make this public and let the hotels make themselves secure by whatever means possible.

I know that's a bit of a strange answer, but this is a strange situation; it's taken me a while to figure out the correct course of action, and I feel that this really is the best way for the safety of the public.

Edit: Toned down some of the wording; unnecessary.

As for Ving, I think they're going to be next up; spent years honing my skills in reversing this sort of thing, seems like a shame to stop now.

Anecdotally, I was asked for ID each time my wife or I lost hotel room cards on 4 occasions (3 for me, once for my wife).

I believe they were 2 Courtyard Marriotts, 1 Residence Inn (Marriott), and a Sheraton (don't remember the hotel class).

EDIT: Grammar

This reminds me of growing up in Eastern Europe. Story time: Under the Romanian communist regime, there was only one car factory (Dacia[1]) making cars for personal use. Their main model was essentially the same from the '70s until 2004. For the first 10 years or so after the '89 revolution, Dacia dominated the local car market (because their cars were cheap and really easy to fix).

Now that we have the oh-so-important context, your comment reminded me that when I was a kid, my parents bought a Dacia. What confused me at a time was that random people would periodically ask to borrow the key.

It turns out that for 30-something years, Dacia only used a few models of keys. In fact there were so few that if you locked your keys inside (doors were unlocked by key and they locked automatically) it was feasible to try keys from random cars until one worked.

To be fair, the engine key was different from the door key, and it didn't have this problem. But, getting back to your comment, if you're talking about a recent card model then that's just crazy.

Also, I would have thought that keyless entry systems use correctly implemented public key cryptography. Is that not the case?

[1]: http://en.wikipedia.org/wiki/Automobile_Dacia [2]: http://en.wikipedia.org/wiki/Romanian_Revolution_of_1989

A microcontroller in sleep state (or similar) draws extremely low power, micro or nano Amps. It only wakes up when it sees data on the card reader, reads the card reader data, and decides if it should open the lock. The motor that unlocks the door only runs for less than a second. Then the whole thing goes back into sleep state.

Hotel doors are only opened 10s of times per day, at most. A pair of couple Amp-hour batteries will last quite a while. Maybe replace them once a year. Tech with an electric screw driver maybe takes 1 minute per door, even a 600 room hotel only costs 2 days of labor once per year (max 1 week, if the tech is slow). That's not that expensive. And the tech's time is 10x the cost of the batteries, coin cells in bulk are dirt cheap.

(Note: This is all specific to Onity locks)

My stack now is a Lenovo W520 running Ubuntu and KDE, and Sublime Text as my editor. Over the years when I did this, I was running everything from a cheapo, hacked-together box to a 13" Macbook Pro, all running Windows Vista/7.

Upon discovering the vulnerability, the only real action he could take which would be universally considered unacceptable would be to use that research to go around breaking into hotel rooms (which is illegal).

If he decided to go into business selling devices to bypass hotel room locks, there would also probably be a majority opinion that that isn't really "above-board". Even that isn't necessarily universally agreed on though (as there are a lot of people who argue that providing access to tools isn't criminal)

But he didn't do that either.

He decided that this was a pretty severe vulnerability (made worse by the fact that remediating it isn't trivial), and that he wanted people to know about it.

Hoping that the vendor will sue him to prevent that information from being disseminated is about the worst possible outcome from research of any kind; ignoring the fact that you don't seem to posit any rationale for what exactly they'd be suing about (protected trade secrets? violation of a license agreement?)

The thing about "responsible disclosure" is that it isn't something that exists by fiat. It's an intentional reframing of disclosure policies by vendors to attempt to steer the research community towards doing what's in the vendors best interests.

I understand their desire to reframe that policy, but that doesn't make it "the only ethically responsible way to conduct vulnerability disclosures".

Recently, there's been a lot of news about BMW's being able to be stolen trivially through access to the OBD port on certain models. There's an OSVDB entry for it and everything‡.

That's another example where providing information to the public was considered to be very important (like the issue Cody discovered, it's also not something that can be easily fixed. It's also been ignored by the vendor).

In virtually all other regards, making research public is considered the responsible thing to do.

While I'm not a card-carrying member of the full-disclosure sentiment, I strongly disagree that releasing research publicly is boolean irresponsible.

‡ http://osvdb.org/83707

In terms of reversing the actual lock protocol, that was a bit more tricky. First step was tapping the line between the portable programmer and lock with an o-scope (a 70s-era HP scope; only thing I could afford at the time, haha) to figure out the voltage levels involved and the basic properties of the communication. From there, I hit it with the Saleae Logic to see what the communication actually looked like.

From there, I wrote some Python scripts to walk over the data from the logic analyzer and attempt to decode the data. With some tweaking, I managed to finally see some data that I knew, specifically the site code (which I knew from other parts of the system).

After I knew all that, it was a matter of figuring out the actual hardware level. Given that I have effectively no experience with this level of things, this was a lot of asking questions, googling, and experimenting. I knew that it was a one-wire protocol, so by reading up on other one-wire protocols I managed to figure out a lot. Once that was done, everything just fell into place; making the opening device work initially took maybe a day given all the info I had.