- 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.
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? :)
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.
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.
Doing proper authorization without cryptography is difficult. Mixing it up with authentication is unnecessary but popular.
The authn/authz distinction is more impactful than encryption/cryptography nitting. Signatures are just encryption with a public key, yknow?
luckily there isn't a state actor actively sabotaging all kinds of infrastructure in Europe right now with explicit interest to sabotage renewables
But yeah, insecure time is a underrated attack vector.
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.
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 load Germany-wide, causing havoc on the European energy grid (brown-out, cascading effects, etc.).
The security researchers followed a responsible disclosure towards the vendor, EFR, who reacted with sending letters from their lawyers.
Today's SPIEGEL online news magazine pre-talk report ( https://archive.is/p66as ) on this topic cites EFR that the proposed attack vector is not possible.
The security researchers therefore made the last minute decision to go full disclosure with today's talk to press on the urgency of the topic.
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.
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 exactly just shoving it under the rug were they?
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.
It seems that they did create an app but it’s nowhere to be found on the flipper “app store”.
So at design time, the threat is just that people can turn off street lamps, which you can do with a BB gun. Then you expand to home solar. Also not so interesting.
But then you expand to be a significant fraction of the grid supply and load. Now there is a substantial target that actually needs security, but which requires a full redesign.
I haven’t watched the talk yet but I think it’s pretty clear to all of us on this website, that sending a specific short radio transmission to a large area is not an insurmountable challenge for our favorite terrorist state.
What I don’t understand is why there is such a reluctance to admit that these problems exist and work towards fixing them. Instead we pull the Ostrich maneuver every time. One day it’s going to really bite us in the ass.
EDIT: after watching the talk, the funny thing is that all of the “business secrets” that EFR is accusing our fellow hackers of leaking, are actually mostly DIN standards. In other words, they are just upset that someone is talking about the fact that no efforts have been made to proactively secure these receivers. Peinlich.
Nothing there for Blinkencity yet.
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.
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.
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
> Second, it's very hard to imagine authorization on an open channel like radio, without any sort of encryption.
It's easy: you add digital signatures to sign plaintext packets/messages. And now you know they are authentic, and not generated by some random guy that bought a HackRF last week, and is now testing all firmwares that he can find.
It's trivial to implement on an open channel, HMAC being a common form. This is how old APIs using HTTP (Flickr, S3) handled authorization despite all communication being cleartext.
Confidentiality and integrity can be achieved with a single authenticated encryption primitive, or done separately with encryption and a hash-based authentication primitive, or exist as one without the other.
Eric could allow those initial three messages to pass unmolested. In this case Alice and Bob now have an authenticated connection and Eric is unable to read or modify their messages. So I suppose you don't mean that.
What if Eric just substitutes his own message for Alice's in step 1? He provides his own parameters. Since these were not Alice's parameters, Alice will not provide an acceptable Digest for the conversation, the parameters Eric sent to Bob are different and do not match the transcript, the connection is terminated.
What if Eric substitutes Bob's only message in step 2? He provides his own parameters, and he can respond with a transcript digest for this alternate conversation. Now in fact the TLS 1.3 connection exists as normal, but it is between Alice and Eric. We're actually fine! We have a properly authenticated connection, with unidentified participants (we know they're Alice and Eric but Alice and Eric don't know that). Bob's connection fails, or he is unaware that Alice tried to connect.
Finally if Eric waits until Alice's second message in step 3, no message Eric knows how to construct is satisfactory. Only Alice's original message will work, other messages cause the connection to fail because Bob will not accept them.
Or, imagine that there isn't even one legitimate Bob in the world. But Alice is still talking to someone who follows the protocol, and is indistinguishable from a real Bob. Is that possible?
For Alice there's no difference between a Bob whose identity you don't know and an Eric whose identity you don't know, they're each just another anonymous party.
Eric can't fool Alice and Bob into believing they're talking to each other, because they're using separate channels and identity systems will bind to the channel. Suppose Bob provides his identity, that's bound to the Eric-Bob channel, when Eric copies it to the Eric-Alice channel it's just obviously fraudulent, he could have made his own fraudulent claim of Bob's identity just as easily.