'Just because it was intentional, doesn't make it not a vulnerability.' I guffawed. Reminds me of all the 'it is working as intended' arguments I have with our devs. Thank you for the great talk.

Would def win a best slides award

I love the thing about the two feet wire "reasonably likely not have a listening device on it".

Considering the fact that these devices are literally designed to read hardware security tokens, you'd think it would be obvious to use one of those to transfer the setup key for the server.

*aggressively reduces overhead* *polls everything constantly*

When he gets into that undisclosed location in Santa Fe NM I need a copy of whatever book he happens to find lying around.

*Me in my secure hand drawn building in Santa Fe, New Mexico*😮

This is like DECT phones - everybody thought they were encrypted and then people realised they weren't. Pretty much overnight, DECT PCMCIA cards became worth more than their weight in gold.

The intention of the master key (MK) would be to have it installed at manufacture, of clients and servers. This would ensure that pairing could only occur between devices sharing the MK. However were that MK compromised (by either a production facility leak or a poor physical security on the encryption modules) then it becomes a worthless appendage to a now broken security scheme. Unfortunately throwing away the MK doesn't fix the scheme. - if you are designing a protocol with symmetric key scheme, DUKPT is always worth a look. With a touch of salt and pepper is covers a lot of practical bases. As soon as the slide with "polling" came up I felt a bit queasy. "But it works" is not a defence. Neither is "it follows the letter of the specification". I suspect the project was hurried and on an unrealistic budget. It has the feel of a PoC put into production. Note: RS485 is an electrical rather than protocol standard, and is largely chosen for range as well as multi-drop - which is great if you are running cable around a building! Tried, tested, off-the-shelf; good choice).

Havent went to DefCon in years, but discources like these were my favorite thing about the convention. ❤

I wonder if you could influence the data+/- to remove the current data, like having 4 current clamps, 2 per wire, hooked up in some transformer cancelling fashion, and you could influence those with the esp32. You'd then be able to control that to add data back on the wire. Surely it must be possible to flatten the data on a differential pair through noise or retardation (think transformer/inductor) if you have enough length / separation and influence/power.

I wonder how much of this is down to the spec writers not knowing about crypto or security, how much is down to the priorities being wrong (e.g. wanting smaller packet sizes at the expense of security, wanting something that is simpler to implement or wanting something that requires less hardware to pull off) and how much is intentional (i.e. deliberate back doors for some reason)

For that last question, MiM wouldn't be much harder, tap each wire twice and cut the piece in the middle...

One of the best talks

Cool. Nice presentation!

the OSDP security systems we have run their RS485 bus at only 9600 baud as that allows them to get much greater cable run distances which would make the brute force even worse.

great talk, but i guess you have missed the most important countermeasures from the conclusion: - don't use the same wiring (bus) to connect high-critical and not-so-critical access devices - get rid of old-fashined insecure RFID stuff and use modern chip technologies (supporting asymmetric cryptography etc.)

The password being "default" is a punchline in a point and click adventure game, not a suitable cryptographic key.

You could artificially 'kill' a reader if you're on a multidrop bus by corrupting the bus every time it transmits

Yeah, people really don't realize that "encryption" isn't a magic bullet. Throw all the encryption at me that you want, if you do a dumb and leave an obvious vulnerability I'll breeze right past it.

The fun thing is the 10 Mbit one could use a decent sized package, a 1kHz polling frequency (allowing for a couple of hundred doors to be polled several times per second) and despite allowing for more attack per seconds, you'd still be waiting way more than 35 days (on average).

SSH is not nesecarily insecure, it allows and in fact highly recommends to actually verify the key sent by the server.

It'd be interesting to see a card reader with a programmable certificate authority, cards that hold certificates, and the ability to push signed CRLs to the readers. Then, you wouldn't need a controller.

Sadly all known problems and many 101. Optional encryption pretty often means no encryption in practice as you can never be sure it is used and even if you want to use it, an attacker may find a way to convince a component to deny encryption and everything is unencrypted again (Downgrade Attack, as shown in the video). Even if this can be avoided by a policy, users will forget to set it. Just don't make encryption optional. If encryption is too slow, which rarely ever is the case today, settle for a weaker one which provides only moderate security but at least make that one mandatory. Replay attacks? Come on, that's 101. 32 bits would have been fine, IPsec uses 32 bits by default. Sure, it can use 64 bits but that's an optional extension rarely used in practice and only really required on super high speed links where the 32 bits would overflow too quickly and you'd otherwise constantly have to renegotiate session keys (which can be pretty expensive if PFS is used). BTW, even when IPsec sequence numbers are 64 bits, only the last 32 bits of them are actually transmitted over the line, so there's not more protocol overhead, but the full 64 bit are used when calculating the HMAC. Reducing HMAC size? Sure, IPsec does that as well but it reduced 128 or 160 bits to 96 bits, which is still decent. Since SHA2, the reduction is 50% and thus at least 128 bits are sent. Not reusing IVs? Again, 101. Not so critical with CBC encryption, as long as the first few bytes of data are always different, but deadly in many other cases (e.g. CTR/GCM). One device sending a nonce? That's bad per se. A session key should always be derived by two nonces. Why? If an attacker has full control over the generation of the nonce on one side, e.g. because he controls the random number source that is used to generate it, it won't help him unless he can also control the nonce at the other side (very, very unlikely). Setup keys exchanged over the same line as encrypted data later on? Also 101. Even in case of SSH you'd first use a password to access the server, then install your public key there and from this moment on, you can use public key auth. How do you get the inital password? Well, certainly not over the same connection that SSH uses. Not encrypt everything? Encryption should always been treated as if it was an afterthought, yet it should never be an afterthought, of course. Think of TLS. To make HTTP secure, TLS was imposed on it. There are no parts of HTTP exposed as HTTP doesn't even know that it is encrypted and TLS doesn't even know that it is encrypting HTTP. Use a hardcoded default key? LOL!

Quick note on the cost of the OSDP standard document: it's cheaper if you buy it from the Estonian standards body, EVS, where it is called EVS-EN IEC 60839-11-5:2020. If you buy 1 license you have to use a stupid DRM'd web reader thing, but if you buy a 2 seat multi-user license to the spec (which costs about €50 total) you get it as a PDF (with your name and iirc IP address burnt into every page to discourage sharing it) you can download, look at with normal PDF software, print out etc. Hope that helps!

I dont consider my self an expert in any of this, in any way, but I was able to make to 3:00 mark without being completely lost! well done presenter

Cheap rfid locks where the keypad and controller is outside the door are unsafe and hackable "just connect red and yellow" or even by a strong magnet triggering the relay.

Can a rough reader clone or record the badges? (I.e. are the challenges safe enough?)

what what about that default key SCBK-D, if that is set to a fixed value by the protocol, how do you get rid of that weakness additionally couldnt the key exchange by secured by having the key on a card that can be read into that reader, e.g. having an "admin" card to config the reader and then tapping another card which has the key, which sets the key?

Watching this, and comparing it to when I replaced the controller server at a client's location. The RS422 box at the controller end was just a USB dongle plugged into a Windows XP machine. The software was just a program on the server that track and log the provisioned cards. A third party had to come in and actually "backup" the old server's install, and then install the new version on the new server. The real weakness in this, is when nobody monitors the access, because every time a door is tapped, it CAN send an email to somewhere. So even if you cloned a card, you really only have one or two attempts before whoever gets the notifications should be contacting the card owner and asking if they are having trouble getting in the building, and when they say "what? I'm not at the office" send security out to that door. So that Install mode, is likely always turned on, because the underlying server, when rebooted for software updates or it just BSOD's for whatever reason, has to start up again, because if the server turns off, all the readers also lose power.

Why wouldn't they just do Diffy-Helmann key exchange as is what's done with HTTPS? I can understand the need for a root public key, but that should merely need to require basic setup in install mode, which could be provided as a one time key via a flash drive / sd card. Could be susceptible to man-in-the-middle if you can reset the reader, provide your own key, and then pretend to be another "controller" in the middle, but that seems difficult. Then just encrypt everything with the public key.... and only the controller can read the valid data. Plus, you can then request a nonce, and use the public key of the reader to encrypt that, so the reader is the only one who can read the nonce. This seems "solved".....Why are modern companies still cutting these corners?

When will they make badges that provide a proof with asymmetric encryption? The way they're done now is like writing your password on a sticky note and pasting it on your forehead in line at the coffee shop.

Cryptography is hard, security is shard, cryptographical security is doubly hard.

In regards to establishing a man-in-the-middle attack while on site, would it not be sufficient if you were wanting to not interrupt the service to essentially have the device tap it twice with a gap between them, then to cut the wire between the taps?

I love these "The emperor#s new clothes" type talks that just try to shame people into doing it right.

Also, don’t put PII or CII on the rfid cards Imagine finding a card saying bill smith and company X, now you have a card and the user deets

Defcon presenter using windows!

11:44 💀

Nothing but "dizayn".

echo chamber audio horror

dude's logo is VERY similar to the Faze Clan logo and its extremely distracting. i would change that asap lol