5 ms·
Cool stuff, sure. But, in my opinion, IoT will be slow to take off until the security aspect is solved - and it is a tough one.
by jazzyk 11y ago
Cool stuff, sure. But, in my opinion, IoT will be slow to take off until the security aspect is solved - and it is a tough one.
- dconrad 11y agoSecurity in the LoRaWAN standard is well thought-through, you might be surprised.
- StavrosK 11y agoThat's exactly my problem too, and I decided to develop a prototype protocol for it. I wrote a reference implementation in python, feedback very much desired: http://stringphone.readthedocs.org/ http://stringphone.readthedocs.org/
- bdamm 11y ago* The weaknesses you outline in the introduction are pretty serious. * How to exchange the topic key is described as out of scope, but totally critical since you also propose renewing the topic key as a way of attaining forward secrecy. * You totally hand-waved away the exchange of participant keys. * I'm pretty sure you've exposed some cryptographic weaknesses in the core protocol but I'm not going to spend the time to keep analyzing. So in short, your protocol is not very useful. Sorry. The biggest problems in IoT space are key agreement and machine trust among a hugely heterogeneous population. Solutions will come in the form of standards adoption, hegemony, government regulation, and probably a combination of all three. Multicast security is somewhat of a solved problem (e.g. wifi.) Communications security between actual people is an entirely different and more easily solved problem.
- StavrosK 11y ago> The weaknesses you outline in the introduction are pretty serious. There's no weakness there that's not fixable. Replay protection can be easily added in the layer above, and rolling the topic key can also be done. The nonce problem can go away with using the wider Salsa variant. > How to exchange the topic key is described as out of scope, but totally critical since you also propose renewing the topic key as a way of attaining forward secrecy. Where did you see that? I go into a lot of detail here: https://stringphone.readthedocs.org/en/latest/protocol.html#discovery https://stringphone.readthedocs.org/en/latest/protocol.html#... > You totally hand-waved away the exchange of participant keys. See the previous point. > I'm pretty sure you've exposed some cryptographic weaknesses in the core protocol but I'm not going to spend the time to keep analyzing. Hmm. > Solutions will come in the form of standards adoption, hegemony, government regulation, and probably a combination of all three. "Don't bother working on it" doesn't sound like very useful advice...
- bdamm 11y agoAre you going after people or machines as your target? It matters which, because machines can't do human trust, so then the issue of how you exchange keys and establish trust is forced. What's the stop a MITM between a client and any other client from intercepting the conversation? In your protocol, nothing, except that if the MITM isn't there at the start, they can't join in right away. This is not a very useful assurance. So please, keep working on it, but I think your challenges are pretty serious. If the problems are fixable, then go ahead and fix them. I'd be happy to take another look - after that.
- CamperBob2 11y agoI can't think of any other technologies that have waited for the security aspect to be solved, can you?
- TeMPOraL 11y agoSolving security aspect will mean much less hackability, which means slowing down its development.
- Natanael_L 11y agoLink encryption and authentication is pretty much "solved" in that we have the components we need already. Then there's the issue of code bugs and lack of updates - I think this should be solved in most cases by devices exclusively talking over a filtered API via a trusted gateway to prevent exploit attempts from succeeding.