- AFAICT, HID doesn't like to talk about their actual protocols. That rules them out for serious use in my book.
IMO the right way to do keyless entry is to use SIA OSDP Transparent Mode [1] readers and some very simple software to authenticate something like a Yubikey NEO or a Mifare DESfire at the other end. (The high-end DESfire devices are cheap and use real crypto.)
(Of course, big customers still use HID and RSA, because no one ever got fired for using an expensive product from a well-known big-name supplier.)
[1] A fancy name for an open protocol that lets you gasp exchange plain ol' APDUs with a card via a reader that speaks the protocol. Of course, this is so amazingly brilliant that HID's parent company claims to have patented it. Someone should file for ex parte review. (The patents are, AFAICT, https://www.google.com/patents/US6575360 and https://www.google.com/patents/US7853789. These are IMO about as obvious as patents get.)
HID Prox keys don't use any kind of challenge-response crypto and so can readily be duplicated. I would say there are two meaningful mitigations here though:
1) HID Prox is quite old, and while still in common use it shouldn't be used in any new installations for a number of years now.
2) The situation was the same for other digital lock systems of the period, such as the now largely forgotten Marlok and the Secur-a-key. HID Prox basically just predates a challenge-response scheme being technologically feasible. Unfortunately, the intersection of Prox with later RFID technology makes it easier to duplicate Prox keys than these other types (the other types would just require specialized jigs to duplicate)
Today, HID sells a number of systems using different protocols. However, they have both DESFire and SIA compliant products - in fact, as you hint at, HID was one of the original developers of the OSDP protocol and (along with their collaborators) assigned it to SIA.
I'm not necessarily defending HID, as the company has made a huge number of missteps over the years and it looks like that's not stopping now. However, most of the old complaints about HID products are no longer true and they sometimes get an unfairly hard rap - for example, HID's decision not to change the physical case design of their keys over the years (which is useful to their customers who have invested in tooling) has lead a lot of people to believe that all HID systems are Prox systems, which is not true. Of course, I would argue that selling new Prox systems at all at this point is a huge mistake - and you can still buy new Prox systems from HID, although I'm sure they'll try to upsell you to their OSDP-compliant iCLASS system.
EDIT: As a further note in HID's defense, one of the big problems with HID products is that their catalog line-up is really, really confusing to interact with from a security perspective. If you buy an iCLASS system, for example, there's still a half-dozen different actual protocols that could be used to do the card authentication. It can get very frustrating very quickly. There are two big reasons for this, though. The first is that HID tries very hard, perhaps too hard, to allow customers to upgrade without having to replace all of their equipment at once, so most HID systems are designed to interoperate with many older systems. The bigger reason though is that many HID systems are designed to very specific requirements from the federal government and other parties, and these requirements are often confusing and contradictory. That's a problem you'll see a lot in the enterprise security space: systems that are really confusing because they are exactly FISMA, FICAM, F-whatever compliant.
> Lawshae says the attacks, which can open every door in a building, are possible because of a command injection vulnerability in a LED blinking lights service.
> "A command injection vulnerability exists in this function due to a lack of any sanitisation on the user-supplied input that is fed to the system() call," Lawshae says.
This looks like the latest in "internet of things" idiocy. Things that were once simple, but which now inexplicably run Linux.
This is how you get critical security failures from an "LED blinking lights service" or a home thermostat that bricks itself one morning after an auto update.
Its also how you get cars that can be crashed by a 4chan troll 1000 miles away, over the network, because of a bug in the entertainment system.
Except for those of us who drive hybrid eCVTs or electric. Owning an automatic was one of the most expensive decisions of my life... One I wouldn't repeat if I could avoid it.
I just bought myself a motor cycle a week or two back which runs just fine with a completely dead battery (I need to roll start it, but its a 125cc two stroke so that's _super_ easy...). The indicators don't blink with the dead battery (they just sort of light up), and the headlights are very dim, but it ran just fine for ~450km like that last Sunday...
I think they're saying that it's silly to use any complete operating system for a task that could be entirely handled by a few kilobytes of embedded code running on an 8088.
Are there best practices for designing connected, secure-by-default embedded devices? If you want to give your fridge an IP address, I feel like there should be an easy way to do that without additional security worries.
I guess I'm thinking that, for a simple hardware system with a handful of inputs and a handful of outputs, there's no need for it to be able to support a full command line, various ports and protocols, etc, etc. There should be a setup where it is completely closed off by default, and the developer enables a few specific I/O channels that only interact with the logic the dev programmed in.
I may be oversimplifying things. Or maybe I've just reinvented old-fashioned embedded circuits, which still work fine but are out of fashion because devs want to work with their familiar tools.
And because you can only prove software to be correct given some specific conditions, your provably correct system will eventually get pwned through a side channel anyway.
There's a surprisingly simple way to leave yourself a "backdoor" with almost any these electronically controlled magnetic locks: tape a paperclip to the magnet.
The paperclip creates enough of a gap to weaken the magnetic hold such that if you put your shoulder into it, you can pop the door open.
This backdoor is virtually undetectable, because the door still operates normally, and no one thinks to look directly at the magnet (except for me, which is how I discovered this trick).
The maglocks we installed had a field sensor that measured the bond strength. The LED on the maglock would turn red when powered and then turn green when the bond strenght was correct.
Even a tiny piece of paper would keep the LED from going green. Same with a slightly misaligned plate on the door. Pain in the ass since our controllers would not show the door secure until it was perfect.
This is a routinely done thing at the university residence when I lived there (each floor has a lock like this at the elevator room and the staircase doors). Other common items are like a small stack of paper in a folder, or whatever.
People did this so they don't have to get their friends by going from their room to the elevator or stairs.
I've done that before to get in to the server room during an outage in the middle of the night. For some reason my keycard wasn't working. Servers were on battery backup but the door locks weren't. Killed power via the master switch to the building long enough to get in the door, fix the outage and get out.
This is getting just like in Star Trek. A door is locked and you really want to get in? Pop in the panel on the wall and use the door override console. No power on the whole deck? The override console has a handy magnetic hook that will let you open the door by brute force.
So you need to be on the door controller network to exploit it... and the network is behind the door.
As opposed to paying a pickpocket $50 to swipe a HID card from any of a thousand employees. Or, I dunno, using a passive reader to clone any of them from across the parking lot. Both of which are less traceable than, say, a spear-phishing malware attack.
The trick is to follow someone in and have your wallet out to slide against the reader. Beyond that, have a little device in your wallet that goes "bip!" when you push it against the reader.
The door refused to open. It said, "Five cents, please."
He searched his pockets. No more coins; nothing. "I'll pay you tomorrow," he told the door. Again it remained locked tight. "What I pay you," he informed it, "is in the nature of a gratuity; I don't have to pay you."
"I think otherwise," the door said. "Look in the purchase contract you signed when you bought this conapt."
...he found the contract. Sure enough; payment to his door for opening and shutting constituted a mandatory fee. Not a tip.
"You discover I'm right," the door said. It sounded smug.
Let's see.
- IIRC, many (most? half? not really sure) HID devices use no crypto whatsoever. The tags simply tell the reader their serial number.
- A bunch that do use crypto use a homebrewed algorithm that's entirely broken. (See, for example, http://www.openpcd.org/HID_iClass_demystified).
- AFAICT, HID doesn't like to talk about their actual protocols. That rules them out for serious use in my book.
IMO the right way to do keyless entry is to use SIA OSDP Transparent Mode [1] readers and some very simple software to authenticate something like a Yubikey NEO or a Mifare DESfire at the other end. (The high-end DESfire devices are cheap and use real crypto.)
(Of course, big customers still use HID and RSA, because no one ever got fired for using an expensive product from a well-known big-name supplier.)
[1] A fancy name for an open protocol that lets you gasp exchange plain ol' APDUs with a card via a reader that speaks the protocol. Of course, this is so amazingly brilliant that HID's parent company claims to have patented it. Someone should file for ex parte review. (The patents are, AFAICT, https://www.google.com/patents/US6575360 and https://www.google.com/patents/US7853789. These are IMO about as obvious as patents get.)