3 ms·

It's really a shame that "IoT" locks are destroying the reputation of electronic locks. A well constructed electronic lock can be considerably more secure agai

by nullc 6y ago

It's really a shame that "IoT" locks are destroying the reputation of electronic locks. A well constructed electronic lock can be considerably more secure against non-destructive attack than any mechanical lock. Yet IoT locks continually have gross vulnerabilities that allow undetectable bypass-- and issue that even moderately good mechanicals locks don't really have (even picking usually leaves evidence).

flyinghamster 6y ago
Often, as LockPickingLawyer on YouTube has demonstrated, one can simply place a magnet in just the right location to pop a relay and bypass all the high-tech gimmickry.
bsder 6y ago
> It's really a shame that "IoT" locks are destroying the reputation of electronic locks. Original funding from IndieGogo. LOL. Yeah, that's a bunch of folks who know lots about security. And as soon as I see MQTT (or any other abstraction layer above UDP or TCP/IP) I know that doom follows. The worst part about this is that making secure locks when cloud connectivity is available just isn't that hard. Use a Curve25519 library. Everybody (lock, phone, cloud) generates their own keys and exchanges public keys facilitated by an originator set of keys from the cloud installed at manufacture time (this prevents getting man-in-the-middled at configure time without having to go through complicated public-key exchange algorithms that might get cracked). Commands are always encrypted using public keys and always involve the cloud. Return no ACK (your ACK is that the lock unlocked) so you can't brute force. Done. If you really want to be paranoid, the lock and phone should exchange a separate set of public keys that encrypt the commands uploaded to the cloud that get forwarded to the lock. Now, even compromising the cloud doesn't let you unlock the door. A secure lock without Internet connectivity is quite a bit harder because you have no unimpeachable "oracle" to present a point of "truth" that can be relied on.
- CorrectHorseBat 6y ago
  It's not that easy: Now the lock doesn't work when either your phone or your lock has no internet connection, or the cloud is down. Also, when the manufacturer gets hacked they can remotely open any lock. (And you need to use a phone that is manufactured by the same company as the lock?). I'd say there are better ways to prevent man-in-the-middle attacks during set-up, which are IMO not really a problem anyway. You have bigger problems if that is a part of your threat model. >If you really want to be paranoid, the lock and phone should exchange a separate set of public keys that encrypt the commands uploaded to the cloud that get forwarded to the lock. Now, even compromising the cloud doesn't let you unlock the door. But now you're doing public key exchange which you wanted to avoid, why then involve the cloud at all?
  - bsder 6y ago
    The point is that you break the process into two pieces: 1) Key exchange is mediated, encrypted and authenticated by the cloud. 2) Command exchange is always encrypted and uses the already exchanged keys between the phone and lock. The commands may or may not go through the cloud as an intermediary. > It's not that easy: Now the lock doesn't work when either your phone or your lock has no internet connection, or the cloud is down. I don't find the requirement for the pairing process to be cloud mediated to be very onerous. After the pairing process, you can decide if the reliability requires the lock to operate if the cloud is offline. And you probably need at least intermittent internet connectivity or you can never revoke access. > And you need to use a phone that is manufactured by the same company as the lock? It's called an app. And generally, yes, the manufacturer makes you use their app to open the lock. > I'd say there are better ways to prevent man-in-the-middle attacks during set-up, which are IMO not really a problem anyway. I don't agree. The problem is that pairing is ALWAYS annoying and nobody wants to put a button on the lock to change its mode (or want to be able to automate the addition of people to the lock control). An attacker being able to arbitrarily activate the pairing process locally gives a much bigger attack surface--forcing this process to involve the cloud cuts that surface down significantly. > But now you're doing public key exchange which you wanted to avoid, why then involve the cloud at all? It's not a public key exchange. It's a private, encrypted key exchange with keys that got mediated by the cloud. That's a much harder system to attack from the point of view of an attacker.
- jonquark 6y ago
  > as soon as I see MQTT (or any other abstraction layer above UDP or TCP/IP) I know that doom follows. As someone who works on MQTT server technology, this opinion surprised me - it's a lot easier to get the security right using an MQTT server - user credentials are part of the protocol where as you have to build it yourself if you start at the TCP/UDP layer. The problem in this example wasn't that they were using MQTT it's that there was no authentication/authorisation checking done - normally achieved by configuration - that would be possible in TCP as well - by not implementing it ;)
  - bsder 6y ago
    > As someone who works on MQTT server technology, this opinion surprised me Why? It's practically tautological. The technology is irrelevant--it's all about the users. The set of people using MQTT is: 1) The clueless (those who don't know better or the buzzword-driven) 2) The clueful with no power or cost constraints (to first, second and third approximation--a null set) because if you add constraints to someone with clue, they will dump everything above UDP or TCP/IP. Thus, MQTT == DOOM. (If I'm being less uncharitable, an MQTT broker is a service I don't control and have no visibility into. It only takes being on the receiving end of one bitchfest because an MQTT message didn't get delivered because "reasons" before you pull the plug on it and do it yourself. Given that I can predict with 100% certainty that this will happen, why even start with MQTT?)
- nullc 6y ago
  I think the developers of stuff like this come in two primary flavours: people who know enough to realize that it's not totally trivial, who rapidly fall down a security rabbit hole once they get going... and people who just churn out the minimum that meets the superficial description of the product ASAP. Because of the aformentioned rabbit hole, the fomer group doesn't tend to ship many products compared to the latter. The latter group's design gets compromised by a magnet or a magic packet because the description didn't say anything about those. :) I think if you think hard about it for a while and do some research you'll find that it's actually more complicated than you might think. ... two way communications between the 'key' and the lock, non-volatile counters in each to prevent replay, secure crypto that is too slow and power hungry when run on the 8-bit microcontroller that fits in the space/power/cost budget... etc. Of course, you can work around these challenges-- but that's the rabbit hole. :) There are various kinds of pretty secure electronic locks. Because of the extremely poor track record of cryptography in embedded devices I'd be inclined to find designs that rely less on crypto more trustworthy. I'm fond of the kaba mas x-10. :)

by nullc 6y ago

flyinghamster 6y ago

Often, as LockPickingLawyer on YouTube has demonstrated, one can simply place a magnet in just the right location to pop a relay and bypass all the high-tech gimmickry.

bsder 6y ago

> It's really a shame that "IoT" locks are destroying the reputation of electronic locks. Original funding from IndieGogo. LOL. Yeah, that's a bunch of folks who know lots about security. And as soon as I see MQTT (or any other abstraction layer above UDP or TCP/IP) I know that doom follows. The worst part about this is that making secure locks when cloud connectivity is available just isn't that hard. Use a Curve25519 library. Everybody (lock, phone, cloud) generates their own keys and exchanges public keys facilitated by an originator set of keys from the cloud installed at manufacture time (this prevents getting man-in-the-middled at configure time without having to go through complicated public-key exchange algorithms that might get cracked). Commands are always encrypted using public keys and always involve the cloud. Return no ACK (your ACK is that the lock unlocked) so you can't brute force. Done. If you really want to be paranoid, the lock and phone should exchange a separate set of public keys that encrypt the commands uploaded to the cloud that get forwarded to the lock. Now, even compromising the cloud doesn't let you unlock the door. A secure lock without Internet connectivity is quite a bit harder because you have no unimpeachable "oracle" to present a point of "truth" that can be relied on.

CorrectHorseBat 6y ago
It's not that easy: Now the lock doesn't work when either your phone or your lock has no internet connection, or the cloud is down. Also, when the manufacturer gets hacked they can remotely open any lock. (And you need to use a phone that is manufactured by the same company as the lock?). I'd say there are better ways to prevent man-in-the-middle attacks during set-up, which are IMO not really a problem anyway. You have bigger problems if that is a part of your threat model. >If you really want to be paranoid, the lock and phone should exchange a separate set of public keys that encrypt the commands uploaded to the cloud that get forwarded to the lock. Now, even compromising the cloud doesn't let you unlock the door. But now you're doing public key exchange which you wanted to avoid, why then involve the cloud at all?
- bsder 6y ago
  The point is that you break the process into two pieces: 1) Key exchange is mediated, encrypted and authenticated by the cloud. 2) Command exchange is always encrypted and uses the already exchanged keys between the phone and lock. The commands may or may not go through the cloud as an intermediary. > It's not that easy: Now the lock doesn't work when either your phone or your lock has no internet connection, or the cloud is down. I don't find the requirement for the pairing process to be cloud mediated to be very onerous. After the pairing process, you can decide if the reliability requires the lock to operate if the cloud is offline. And you probably need at least intermittent internet connectivity or you can never revoke access. > And you need to use a phone that is manufactured by the same company as the lock? It's called an app. And generally, yes, the manufacturer makes you use their app to open the lock. > I'd say there are better ways to prevent man-in-the-middle attacks during set-up, which are IMO not really a problem anyway. I don't agree. The problem is that pairing is ALWAYS annoying and nobody wants to put a button on the lock to change its mode (or want to be able to automate the addition of people to the lock control). An attacker being able to arbitrarily activate the pairing process locally gives a much bigger attack surface--forcing this process to involve the cloud cuts that surface down significantly. > But now you're doing public key exchange which you wanted to avoid, why then involve the cloud at all? It's not a public key exchange. It's a private, encrypted key exchange with keys that got mediated by the cloud. That's a much harder system to attack from the point of view of an attacker.
jonquark 6y ago
> as soon as I see MQTT (or any other abstraction layer above UDP or TCP/IP) I know that doom follows. As someone who works on MQTT server technology, this opinion surprised me - it's a lot easier to get the security right using an MQTT server - user credentials are part of the protocol where as you have to build it yourself if you start at the TCP/UDP layer. The problem in this example wasn't that they were using MQTT it's that there was no authentication/authorisation checking done - normally achieved by configuration - that would be possible in TCP as well - by not implementing it ;)
- bsder 6y ago
  > As someone who works on MQTT server technology, this opinion surprised me Why? It's practically tautological. The technology is irrelevant--it's all about the users. The set of people using MQTT is: 1) The clueless (those who don't know better or the buzzword-driven) 2) The clueful with no power or cost constraints (to first, second and third approximation--a null set) because if you add constraints to someone with clue, they will dump everything above UDP or TCP/IP. Thus, MQTT == DOOM. (If I'm being less uncharitable, an MQTT broker is a service I don't control and have no visibility into. It only takes being on the receiving end of one bitchfest because an MQTT message didn't get delivered because "reasons" before you pull the plug on it and do it yourself. Given that I can predict with 100% certainty that this will happen, why even start with MQTT?)
nullc 6y ago
I think the developers of stuff like this come in two primary flavours: people who know enough to realize that it's not totally trivial, who rapidly fall down a security rabbit hole once they get going... and people who just churn out the minimum that meets the superficial description of the product ASAP. Because of the aformentioned rabbit hole, the fomer group doesn't tend to ship many products compared to the latter. The latter group's design gets compromised by a magnet or a magic packet because the description didn't say anything about those. :) I think if you think hard about it for a while and do some research you'll find that it's actually more complicated than you might think. ... two way communications between the 'key' and the lock, non-volatile counters in each to prevent replay, secure crypto that is too slow and power hungry when run on the 8-bit microcontroller that fits in the space/power/cost budget... etc. Of course, you can work around these challenges-- but that's the rabbit hole. :) There are various kinds of pretty secure electronic locks. Because of the extremely poor track record of cryptography in embedded devices I'd be inclined to find designs that rely less on crypto more trustworthy. I'm fond of the kaba mas x-10. :)