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

31–40 of 54 posts

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

#31

Post by Eduard »

grumpy-de-sre wrote: post #28
trebligdivad wrote: post #27

Earlier quoted context omitted.

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

Also, IMHO instead of a few strong senders, an attacker could use more low-powered senders placed in proximity to power stations.

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

#32

Post by tialaramex »

H8crilA wrote: post #29
tialaramex wrote: post #24

Earlier quoted context omitted.

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

> then proceeding using the shared key with even the best of schemes

Unlike with your "spy" scenario, this situation is in fact what TLS 1.3 builds initially and it's not useless at all, nor is the resulting link unauthenticated.

1. First Alice sends her fresh parameters to Bob

2a. Then Bob sends his fresh parameters to Alice

2b. Alice and Bob now have all the DH parameters and they now have a shared secret X

2c. Bob calculates a Digest of a transcript of the entire conversation so far and sends this Digest, encrypted with X to Alice, he can send this alongside the parameters if he wants

3. Alice also likewise calculates a Digest and sends the encrypted digest to Bob

Both Alice and Bob now have a shared secret and have an authenticated (because they've seen the other party's view of the conversation in the digest and confirmed it matches their expectation) communication channel which they can use. They don't learn each others' identity but, of course, it is easy to additionally offer this as part of the same protocol and HTTPS does so in one direction in the typical case.

Edited: Renumbered to clarify that only three messages are sent, parts 2a, 2b and 2c are actually a single message from Bob to Alice

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

#33

Post by [deleted] »

tialaramex wrote: post #32
H8crilA wrote: post #29

Earlier quoted context omitted.

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

> then proceeding using the shared key with even the best of schemes Unlike with your "spy" scenario, this situation is in fact what TLS 1.3 builds initially and it's not useless at all, nor is the resulting link unauthenticated. 1. First Alice sends her fresh parameters to Bob 2a. Then Bob sends his fresh parameters to Alice 2b. Alice and Bob now have all the DH parameters and they now have a shared secret X 2c. Bob…

[deleted]

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

#34

Post by H8crilA »

tialaramex wrote: post #32
H8crilA wrote: post #29

Earlier quoted context omitted.

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

> then proceeding using the shared key with even the best of schemes Unlike with your "spy" scenario, this situation is in fact what TLS 1.3 builds initially and it's not useless at all, nor is the resulting link unauthenticated. 1. First Alice sends her fresh parameters to Bob 2a. Then Bob sends his fresh parameters to Alice 2b. Alice and Bob now have all the DH parameters and they now have a shared secret X 2c. Bob…

I meant that man in the middle attacks make this effectively unauthenticated.

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

#36

Post by npteljes »

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…

This is very nitpicky, and not even valid at that.

First, I think authorization is even more valid than authentication. In this context, it's the authority is what is important, so that only the designated entities can assert control over the system, and not others.

Second, it's very hard to imagine authorization on an open channel like radio, without any sort of encryption. In fact, only the one-time pad comes to mind, although I'm far from being a proper security person. What I see is that authority is usually demonstrated through some encrypted means - even if the message itself is unencrypted, its digital signature is.

>another non authentic but encrypted HTTPS is one such channel. The weakest guarantee of HTTPS is that the comms between the client and the HTTPS terminating server is encrypted, nothing more. HTTPS security can be upgraded to include authenticity information, but it's not mandatory, and it's still very useful even in this weaker form.

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

#37

Post by ugjka »

Towaway69 wrote: post #35

Are there any pointers to the software they built for the flipper? It seems that they did create an app but it’s nowhere to be found on the flipper “app store”.

this seems their website https://positive.security/ not sure where they host their code

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

#38

Post by ElectRabbit »

BonoboIO wrote: post #30

What a great way for a state to cause havoc in all of Europe. Russia definitely has the capabilities to send such signals in a coordinated attack and deny an wrong doing. And this is just one example we know of, there must be hundreds.

They have low-kHz transmitters for reaching submarines. So, for many decades already.

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

#39

Post by Towaway69 »

ugjka wrote: post #37
Towaway69 wrote: post #35

Are there any pointers to the software they built for the flipper? It seems that they did create an app but it’s nowhere to be found on the flipper “app store”.

this seems their website https://positive.security/ not sure where they host their code

Thanks but from there I got nowhere, unfortunately no links to git*.com.

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

#40

Post by oger »

The researchers did a great job in pointing out the failures in what basically is an old DIN standard that should not be used in this century. I congratulated them after the talk as I did similar research and didn’t get it finished for 38C8. Their presentation is spot on. The attack vector is definitely feasible and publicly known for a while. I honestly don’t understand why nobody in the industry wanted to switch to a safer alternative. The reaction by EFR will create an unnecessary Streisand effect and after all they will be able to upsell their customers to a (soon to be legacy) 450 MHz LTE system.
Post reply on HN