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

41–50 of 54 posts

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

#41

Post by tialaramex »

H8crilA wrote: post #34
tialaramex wrote: post #32

Earlier quoted context omitted.

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

Suppose that Eric is in the middle.

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.

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

#42

Post by Scaevolus »

npteljes wrote: post #36
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…

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

Authorization can be achieved by authentication with either a preshared key or a key derived using public key cryptography and some PKI.

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.

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

#43

Post by H8crilA »

tialaramex wrote: post #41
H8crilA wrote: post #34

Earlier quoted context omitted.

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

Suppose that Eric is in the middle. 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…

I'm sorry, are you trolling? You pretend to be Bob to Alice, and Alice to Bob, at the same time. Real Alice and Bob never compute the same transcript digests, but it doesn't matter. As post handshake data is flowing you decrypt it and reencrypt, modifying what you want.

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?

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

#44

Post by H8crilA »

npteljes wrote: post #36
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…

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

Authentic channel is a channel typically uses digital signatures, or MACs, or something like the Dragonfly protocol used for example in WPA3. As you may know the padlock and alerts in browsers are exactly for that reason, to show that a channel is authentic. The client doesn't authenticate by default, we use passwords/API keys/oauth/etc for that. Though the client actually can, and some services use that.

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

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

#45

Post by baobun »

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…

You are confusing authentication (even less relevant in context than encryption actually) with authorization.

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?

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

#46

Post by gunian »

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…

[dead]

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

#47

Post by tialaramex »

H8crilA wrote: post #43
tialaramex wrote: post #41

Earlier quoted context omitted.

Suppose that Eric is in the middle. 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…

I'm sorry, are you trolling? You pretend to be Bob to Alice, and Alice to Bob, at the same time. Real Alice and Bob never compute the same transcript digests, but it doesn't matter. As post handshake data is flowing you decrypt it and reencrypt, modifying what you want. 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 indistingui…

I'm not trolling, I just don't think you've really thought about what "authentic" could mean if you don't have identity, which is a distinct problem.

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.

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

#48

Post by pabs3 »

Towaway69 wrote: post #39
ugjka wrote: post #37

Earlier quoted context omitted.

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.

https://github.com/positive-security/

Nothing there for Blinkencity yet.

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

#49

Post by radicality »

npteljes wrote: post #36
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…

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

Didn’t the parent talk about authentication vs encryption, and not authentication vs authorization ?

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

#50

Post by nextaccountic »

H8crilA wrote: post #44
npteljes wrote: post #36

Earlier quoted context omitted.

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

Authentic channel is a channel typically uses digital signatures, or MACs, or something like the Dragonfly protocol used for example in WPA3. As you may know the padlock and alerts in browsers are exactly for that reason, to show that a channel is authentic. The client doesn't authenticate by default, we use passwords/API keys/oauth/etc for that. Though the client actually can, and some services use that. > Second, i…

I think the point made is that digital signatures are encrypted messages (eg. you may encrypt a hash of the message using your private key)
Post reply on HN