Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

38C3: Blinkencity, radio controlling street lamps and power plants [video]

media.ccc.de

Post reply on HN
Print view View original

21–30 of 54 posts

Re: 38C3: Blinkencity, radio controlling street lamps and power plants [video]

#21

Post by __jonas »

Hikikomori wrote: post #17
__jonas wrote: post #16

That was an interesting talk! I'm not very familiar with security stuff, but I didn't really get the responsible disclosure thing – is it really unreasonable for this company to ask them not to go public just three months after their initial disclosure? I understand the 'it was known since 2013' thing, but they did also say the company was actively making improvements after the initial disclosure so they were not exa…

They got letter from their lawyers no?

Yeah? I’m saying I don’t get why the letter from the lawyer is unreasonable.

Sure, ideally it would have not been done via a lawyer but rather just asking them to delay going public directly since they were communicating before, but still it’s just three months after initial disclosure and they were actively making improvements and informing customers that they need to switch out hardware which I assume takes time, I think not wanting the researchers to go public just yet is pretty reasonable no? Am I missing something?

As I said I’m not very familiar with security research stuff, maybe anything goes three months after disclosure, it just surprises me.

Also just to be clear: the work by the researchers here is super impressive, and it’s fantastic that they are doing it, I was just wondering about this disclosure process.

Re: 38C3: Blinkencity, radio controlling street lamps and power plants [video]

#22

Post by H8crilA »

pantalaimon wrote: post #3

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…

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? :)

Re: 38C3: Blinkencity, radio controlling street lamps and power plants [video]

#23

Post by semi-extrinsic »

jdiez17 wrote: post #9
Eduard wrote: post #5

TL;DR: by law, German power stations are required to "turn off" (taken off the energy grid) when they receive specific radio messages. This is intended for energy grid load balancing. Unfortunately, the message protocol is completely flawed security-wise, which allows malicious actors to control the power station. It would require only a handful of strategically placed senders to control an estimated 20 gigawatt of l…

Just read the SPIEGEL article and I think it’s a pretty balanced report on the positions of both sides. Basically, it comes down to the assertion that you can’t reach a large number of electricity generation plants with “simple radio equipment”. That is the position of EFR, and sadly, the Bundesnetzagentur (the radio communications regulator in Germany). I haven’t watched the talk yet but I think it’s pretty clear to…

IANAL, and didn't watch the full recording yet. But if the EFR lawyers are threatening the hackers with "leaking business secrets", they have to be wildly incompetent. I won't give those guys any ideas, but I'm certain there are much more scary parts of DE/EU law that you could threaten with.

Re: 38C3: Blinkencity, radio controlling street lamps and power plants [video]

#24

Post by tialaramex »

H8crilA wrote: post #22
pantalaimon wrote: post #3

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…

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 en…

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.

Re: 38C3: Blinkencity, radio controlling street lamps and power plants [video]

#25

Post by pantalaimon »

happosai wrote: post #19
gorgoiler wrote: post #14

Earlier quoted context omitted.

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.)

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.

As I understood it, that's likely weather data from a 3rd party (Meteocast) that they encrypt to protect their IP/subscription.

Re: 38C3: Blinkencity, radio controlling street lamps and power plants [video]

#26

Post by aunderscored »

__jonas wrote: post #21
Hikikomori wrote: post #17

Earlier quoted context omitted.

They got letter from their lawyers no?

Yeah? I’m saying I don’t get why the letter from the lawyer is unreasonable. Sure, ideally it would have not been done via a lawyer but rather just asking them to delay going public directly since they were communicating before, but still it’s just three months after initial disclosure and they were actively making improvements and informing customers that they need to switch out hardware which I assume takes time, I…

If you always allow a company to say "wait no don't" with issues, it gives them a tool to quiet problems without solving them. Responsible disclosure is a tool , and part of that tool is the understanding that this will be public

Re: 38C3: Blinkencity, radio controlling street lamps and power plants [video]

#27

Post by trebligdivad »

jdiez17 wrote: post #9
Eduard wrote: post #5

TL;DR: by law, German power stations are required to "turn off" (taken off the energy grid) when they receive specific radio messages. This is intended for energy grid load balancing. Unfortunately, the message protocol is completely flawed security-wise, which allows malicious actors to control the power station. It would require only a handful of strategically placed senders to control an estimated 20 gigawatt of l…

Just read the SPIEGEL article and I think it’s a pretty balanced report on the positions of both sides. Basically, it comes down to the assertion that you can’t reach a large number of electricity generation plants with “simple radio equipment”. That is the position of EFR, and sadly, the Bundesnetzagentur (the radio communications regulator in Germany). I haven’t watched the talk yet but I think it’s pretty clear to…

I think they kind of have a point; they were talking about needing a 10kW transmitter - that's a heck of a lot of power for a transmitter, not easy to make at all. And at those frequencies, the antenna is a challenge. Having said that, a bunch of few-hundred W transmitters in convenient places would be a lot easier, and there are probably easy but inefficient antenna hacks (drop a wire down a cliff/across a park/out of the top floor of a tower block?)

Re: 38C3: Blinkencity, radio controlling street lamps and power plants [video]

#28

Post by grumpy-de-sre »

trebligdivad wrote: post #27
jdiez17 wrote: post #9

Earlier quoted context omitted.

Just read the SPIEGEL article and I think it’s a pretty balanced report on the positions of both sides. Basically, it comes down to the assertion that you can’t reach a large number of electricity generation plants with “simple radio equipment”. That is the position of EFR, and sadly, the Bundesnetzagentur (the radio communications regulator in Germany). I haven’t watched the talk yet but I think it’s pretty clear to…

I think they kind of have a point; they were talking about needing a 10kW transmitter - that's a heck of a lot of power for a transmitter, not easy to make at all. And at those frequencies, the antenna is a challenge. Having said that, a bunch of few-hundred W transmitters in convenient places would be a lot easier, and there are probably easy but inefficient antenna hacks (drop a wire down a cliff/across a park/out…

I beg to disagree, 10kW at ~140khz is actually relatively straight forward with modern semiconductors and LiPo's. Eg. the inverters in a Tesla Plaid can do up-to 750kW, so I think two orders of magnitude more power is theoretically possible.

And then they left out that at such long wavelengths there are some unconventional antenna topologies available. Some of which are a lot more feasible than anything that was discussed in the talk.

The dismissal is quite concerning IMO.

Re: 38C3: Blinkencity, radio controlling street lamps and power plants [video]

#29

Post by H8crilA »

tialaramex wrote: post #24
H8crilA wrote: post #22

Earlier quoted context omitted.

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 en…

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 i…

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.

Post reply on HN