Hacker News Reader

Comment by LeoPanthera | Hacker News Reader

Apparently I don't understand how hotel card keys work. I always assumed that keys were manufactured with a random UUID inside them, and then when you checked in, a random card was attached to your room and given to you.

When you try to open a door, it compares your card's ID to the room database to see if the door should open.

Is that... not how it works? Because that seems simpler than anything that involves encryption, or actually writing shit to the card.

View on HN

The card machine at the front desk writes a message onto the card, which says: Hey, lock #301, this card is authorised to open you as of timestamp X, and all cards before timestamp X are now invalid. Most older e-locks are powered by a 9V battery and are not wired to a central server.

The locks don't have network connectivity, so they have no way to check. Access has to be managed by key expiry and replacement.

There are network-connected systems but they can be considerably more expensive to install.

Having doors not work because the network is unavailable or the database is corrupted sounds neither simpler nor better.

Well, valid key IDs could be pushed to the locks, and remembered for a short time.

UUID can be cloned (with modified cards). This could make a clone attack even easier since you don't need Key A/B to read the contents.

I just imagined that cloning would not be a big deal considering the short life of a typical hotel stay.

You still need to tell the door somehow that the UUID you have now is valid for X days.

Encrypting this information on the card itself is essier

I wonder if it's possible to answer pubkey challenges without electricity

High-end JavaCards can do this. A few have RFID/NFC interfaces, but they are expensive.

https://www.cardlogix.com/product-tag/ecdsa/

It would mean that the door's reader is connected to the network. Is it?

Reply on news.ycombinator.com