5 ms·

I can imagine how this went: - We have this protocol to switch the streetlights remotely by modulating a signal on the main - but that's needing expensive hard

I can imagine how this went: - We have this protocol to switch the streetlights remotely by modulating a signal on the main - but that's needing expensive hardware and it's cumbersome. Can't we just sent that over radio instead? - There is all this decentralized renewable energy generation, we need a way to switch that off remotely if there is an overload in the grid - hey, we already have that hardware for swtiching streetlamps, let's just use that! Of course encrption was never a concern and now anyone could remotely turn off / on power generation. But for that to cause real trouble, you'd need coordinated action that would require something like a state level actor.

gorgoiler 2y ago
I really enjoyed how the payloads are encrypted, but the implementation leaves time synchronization in plaintext. With the street lamps that work to a fixed schedule, all you have to do is reset the time between 12pm and 12am to turn them on and off (the “lamplighter” attack, in the talk.)
- happosai 2y ago
  Listening to the talk, I don't think it was encrypted. They just said in early in the talk that it seemed encrypted due to high entropy. But later in the talk they decoded the payloads after they figured out the format. But yeah, insecure time is a underrated attack vector.
  - pantalaimon 2y ago
    As I understood it, that's likely weather data from a 3rd party (Meteocast) that they encrypt to protect their IP/subscription.
mindcrime 2y ago
But for that to cause real trouble, you'd need coordinated action that would require something like a state level actor. Or thousands of individuals using relatively inexpensive HackRF One SDR's, or home-brew radio transmitters which can be built even more cheaply. Of course all those people would need a way to communicate with each other over large distances... perhaps some kind of packet switching network running over a series of tubes (or avian carriers). Hmmm.
Muromec 2y ago
>But for that to cause real trouble, you'd need coordinated action that would require something like a state level actor. luckily there isn't a state actor actively sabotaging all kinds of infrastructure in Europe right now with explicit interest to sabotage renewables
- ForOldHack 2y ago
  They could drag a boat anchor across it?
H8crilA 2y ago
Authentication, not necessarily encryption. It's a common misconception to think that you need the latter while you actually need the former. And no, encryption does not mean authentication, not at all, usually you can meaningfully modify the ciphertext if a given protocol has no authentication. Also, here's a fun thought experiment: consider two channels, one authentic but not encrypted, another non authentic but encrypted. Can you actually find a use for the second one? Can you find a use for securely talking to an unknown entity, other than running Omgele? :)
- tialaramex 2y ago
  We should distinguish whether we want everybody to be able to authenticate the messages or only our intended recipient. This is separate from the question of whether the message should be encrypted. It may be reasonable for infrastructure to work only with messages everybody may authenticate since there is nothing to hide. For this purpose a Signature Scheme is ideal - simply sign your messages. Whereas for example in Signal two people could have made an Alice->Bob message. Both Alice and Bob have the keys to make such a message. Alice might have made it, and sent it to Bob, or, Bob might have just made it seem as though Alice sent him a message. Bob presumably knows if he's lying, but he can't prove it either way. The unauthenticated link is basically useless. You aren't "securely talking to an unknown entity" because if you were that would be an authenticated link. TLS 1.3 can do "securely talking to an unknown entity" - but it's an authenticated link, the unknown entity is the authenticated remote party. You don't know who they are, but you do know they're your remote party whoever that is.
  - H8crilA 2y ago
    Maybe I should have added what an encrypted, but not authenticated link looks like, because I meant it in both directions. An example would be doing unauthenticated Diffie-Hellman (without any signatures, or proving knowledge of a secret, or anything of this sort), then proceeding using the shared key with even the best of schemes. Another example would be a spy sending and receiving one-time-pad encrypted data via an untrusted, malleable channel - the only authenticity is in hoping that adversarial modifications will cause one of the endpoints to fail at "parsing" the message. It is indeed useless. Also, this property of Signal is called repudiation (or non-non-repudiation :) ), meaning that you as a party in the communication can repudiate the origin of the message, i.e. say that you didn't write it. It is a nice extra feature, on top of authenticity and secrecy.
gunian 2y ago
[dead]
unbelauscht 2y ago
Like the one who's been messing with our deep sea cables?

gorgoiler 2y ago

I really enjoyed how the payloads are encrypted, but the implementation leaves time synchronization in plaintext. With the street lamps that work to a fixed schedule, all you have to do is reset the time between 12pm and 12am to turn them on and off (the “lamplighter” attack, in the talk.)

happosai 2y ago
Listening to the talk, I don't think it was encrypted. They just said in early in the talk that it seemed encrypted due to high entropy. But later in the talk they decoded the payloads after they figured out the format. But yeah, insecure time is a underrated attack vector.
- pantalaimon 2y ago
  As I understood it, that's likely weather data from a 3rd party (Meteocast) that they encrypt to protect their IP/subscription.

mindcrime 2y ago

But for that to cause real trouble, you'd need coordinated action that would require something like a state level actor. Or thousands of individuals using relatively inexpensive HackRF One SDR's, or home-brew radio transmitters which can be built even more cheaply. Of course all those people would need a way to communicate with each other over large distances... perhaps some kind of packet switching network running over a series of tubes (or avian carriers). Hmmm.

Muromec 2y ago

>But for that to cause real trouble, you'd need coordinated action that would require something like a state level actor. luckily there isn't a state actor actively sabotaging all kinds of infrastructure in Europe right now with explicit interest to sabotage renewables

ForOldHack 2y ago
They could drag a boat anchor across it?

H8crilA 2y ago

Authentication, not necessarily encryption. It's a common misconception to think that you need the latter while you actually need the former. And no, encryption does not mean authentication, not at all, usually you can meaningfully modify the ciphertext if a given protocol has no authentication. Also, here's a fun thought experiment: consider two channels, one authentic but not encrypted, another non authentic but encrypted. Can you actually find a use for the second one? Can you find a use for securely talking to an unknown entity, other than running Omgele? :)

tialaramex 2y ago
We should distinguish whether we want everybody to be able to authenticate the messages or only our intended recipient. This is separate from the question of whether the message should be encrypted. It may be reasonable for infrastructure to work only with messages everybody may authenticate since there is nothing to hide. For this purpose a Signature Scheme is ideal - simply sign your messages. Whereas for example in Signal two people could have made an Alice->Bob message. Both Alice and Bob have the keys to make such a message. Alice might have made it, and sent it to Bob, or, Bob might have just made it seem as though Alice sent him a message. Bob presumably knows if he's lying, but he can't prove it either way. The unauthenticated link is basically useless. You aren't "securely talking to an unknown entity" because if you were that would be an authenticated link. TLS 1.3 can do "securely talking to an unknown entity" - but it's an authenticated link, the unknown entity is the authenticated remote party. You don't know who they are, but you do know they're your remote party whoever that is.
- H8crilA 2y ago
  Maybe I should have added what an encrypted, but not authenticated link looks like, because I meant it in both directions. An example would be doing unauthenticated Diffie-Hellman (without any signatures, or proving knowledge of a secret, or anything of this sort), then proceeding using the shared key with even the best of schemes. Another example would be a spy sending and receiving one-time-pad encrypted data via an untrusted, malleable channel - the only authenticity is in hoping that adversarial modifications will cause one of the endpoints to fail at "parsing" the message. It is indeed useless. Also, this property of Signal is called repudiation (or non-non-repudiation :) ), meaning that you as a party in the communication can repudiate the origin of the message, i.e. say that you didn't write it. It is a nice extra feature, on top of authenticity and secrecy.

gunian 2y ago

[dead]

unbelauscht 2y ago

Like the one who's been messing with our deep sea cables?