3 ms·

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

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.
- CorrectHorseBat 6y ago
  > 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. If the cloud is gone you're still stuck. Companies do go bankrupt or get hacked. Anything that requires an app or cloud access is a big no for me. I'm trying to make my life more secure and comfortable. Relying on a zillion different companies and their (buggy) apps is the opposite of that. > 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). You're still going to need that button for pairing with the bridge and/or your local Wi-Fi. If someone has local access to the buttons inside the lock they don't need to crack my lock, they are already inside. I consider the risk that someone spends the time figuring out my lock system, somehow gets access to the pairing button and breaks in on another point in time lower than that the cloud gets hacked with the access to all their locks with a list of the addresses sold to a bunch of burglars.

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.

CorrectHorseBat 6y ago
> 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. If the cloud is gone you're still stuck. Companies do go bankrupt or get hacked. Anything that requires an app or cloud access is a big no for me. I'm trying to make my life more secure and comfortable. Relying on a zillion different companies and their (buggy) apps is the opposite of that. > 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). You're still going to need that button for pairing with the bridge and/or your local Wi-Fi. If someone has local access to the buttons inside the lock they don't need to crack my lock, they are already inside. I consider the risk that someone spends the time figuring out my lock system, somehow gets access to the pairing button and breaks in on another point in time lower than that the cloud gets hacked with the access to all their locks with a list of the addresses sold to a bunch of burglars.