Re: Encrypting control channel
- From: Don Y <this@xxxxxxxxxxx>
- Date: Wed, 08 Feb 2012 00:05:54 -0700
Hi Ben,
On 2/7/2012 4:19 PM, Ben Livengood wrote:
On Jan 26, 3:02 pm, Don Y<t...@xxxxxxxxxxx> wrote:E.g., if I encrypt M1 with the key -- and send it to "somebody" -- and
independently use the same key to authenticate some *other* message
to "somebodyelse", does this attack still apply? (even if an attacker
can see both transmisions)
In this case I suppose the attack doesn't apply, but generally in most
protocols (maybe not yours, but in most) you want to both encrypt and
integrity-protect all messages.
Yes. In my case, I don't worry about protecting "content". (This,
technically, exposes some vulnerabilities but I have covered them
elsewhere in the implementation.)
What if the attacker happens to be one of the somebody's or
somebody else's you are sending encrypted messages to?
If the attacker is one of the intended recipients, the system
has already been compromised. I.e., that device could start
playing Myron Floren music. Or displaying videos of carnal
relations between dogs and cats. Or, "whatever".
Is there any restriction on which devices can be recipients
of the stream from a given source device and therefore have
access to the secret key used for authentication?
How do you propose that restriction? Filtering MAC addresses
(which could be spoofed)? The stream is available to anyone who
connects to the network.
The *secret(s)*, however, are only distributed to clients
intended to receive them!
From one of your earlier posts:I can embed secrets in the devices on each end of the
process. Though the design of those devices itself
is entirely open (the resulting devices will be released
as open source hardware/software so *anyone* could
design something to coexist -- peacefully or otherwise - on
the same wire.
I'm kind of late to this discussion but after reading over the
thread it looks like you want to prevent attackers
from forging the data stream from a source to its recipients.
The protocol just acts as a virtual wire. Aside from DoS
attacks (which would have to be protected in the switch),
I don't want an attacker to be able to alter the content
or presentation of the material distributed over that
virtual wire.
E.g., I don't want to hear Myron Floren when I expect to
be listening to The Doors (*ever*, for that matter! :> ).
I don't want to rattle the windows when listening to Bach. I
don't want to see "Max Headroom" style stutter effects when
watching _Buckaroo Banzai_. Etc.
All that an attacker needs to know in order to forge the stream
is the secret key used for authenticating the stream. When using
Yes. And all you need to steal my car is my car keys! :>
an HMAC or any other symmetric cryptographic primitive any of
the recipients who can verify the stream can also forge it.
Correct.
Maybe I'm missing something, but to me it seems like you would
need to use a public key algorithm for signing the stream so
that each source can keep its signing key secret. This doesn't
Why? Who is going to disclose the key to an "unwanted client"?
[Don't think in terms of distributing content to PC's -- who
could misuse and redistribute the information you've given them.
Instead, think more along the lines of your TV "leaking" that
information to your *toaster*! :-/ ]
mean you have to sign each packet; a HMAC hash chain could
be formed over a sequence of packets and signed at regular
intervals appropriate to the hardware requirements.
The problem there is that the yet-to-be-verified sequence of
packets has a short length (in terms of bytes *and* time).
You're not pushing megabytes of data to a client that it can
verify and reproduce at its leisure.
Instead, you are pushing short packets to a client with severely
limited (and FIXED!) resources and expecting that content to be
reproduced "real soon, now" (there are hard deadlines involved).
Phone rings. Music is attenuated as you answer the incoming call.
Caller's voice is routed through audio distribution system. How
much latency do you add to the "sequence of packets" to be signed
before you allow the client to reproduce the caller's voice?
Additionally, if you want to be able to securely update devices
you will either need a database of every device's unique secret
key that no attacker could obtain (except for his or her own
The server already knows all of this. Remember, this isn't
an "open" system that anyone can "subscribe to" (see the
original boombox analogy). Bring one of these devices over
from *your* house and connect it to the network. And it will
just "get warm" (i.e., dissipate power) -- since it doesn't
"belong" here.
OTOH, *gift* that device to me and I will *make* it "belong"!
You can freely design a device that will *play* the content
that it "snoops" off the network -- since the content isn't
encrypted and the design is fully disclosed. (though *you*
are not afforded the protection from interference that the
legitimate clients have)
[I.e., take the code and port it to a laptop. Plug the
laptop into the network and pull the plaintext content
onto a disk drive. Port the decoder to that same laptop
and you can reproduce the content at will!]
device) or else sign your firmware updates with your private.
key and make your public key trusted by all the devices. To
do otherwise is presenting a ready-made botnet to the first
attacker to find the secret key used to remotely update the
firmware on all the devices.
- References:
- Re: Encrypting control channel
- From: Ben Livengood
- Re: Encrypting control channel
- Prev by Date: Re: Is this a side-channel attack?
- Next by Date: Re: Is this a side-channel attack?
- Previous by thread: Re: Encrypting control channel
- Next by thread: Re: Encrypting control channel
- Index(es):
Relevant Pages
|
