Karthikeyan Bhargavan <karthik.bharga...@gmail.com> writes:
>If every message IoT device sends is a 16 bytes message consisting of one 8
>byte secret and one 8 byte known plaintext, then with a 64-bit cipher, we
>only need roughly 64GB in order to get a meaningful collision (50% chance of
>recovering the secret). The 768GB value we gave was for recovering cookies
>from realistic web browser traffic that could be triggered from JavaScript.
Sure, and I picked the 768GB value because it looks especially unrealistic
:-). However, for typical SCADA/IoT even a value of 100MB is probably
unrealistic in practice, for the combined reasons that the device just isn't
interesting to attack, it doesn't send enough data to collect lots of it
unless you're prepared to wait a really long time, and, most importantly,
there are a thousand easier ways to get in if you really want to.
Has anyone every seen a SCADA device that stood up to even the smallest amount
of analysis/pen-testing? I've currently got a rather pricey security
monitoring box sitting here awaiting investigation, and I can pretty much
guarantee I'll find something like unencrypted C&C, calling home to random
addresses overseas, unauthenticated firmware updates, and who knows what else,
just from simple Pineapple or Ettercap check, let alone any kind of active
pen-testing.
So I think it's important to distinguish between a cool demo in the lab and
something an attacker would actually do. Of all the talks and demos I've seen
of people compromising SCADA and IoT devices, precisely zero even looked at
the crypto, let alone tried to attack it [0]. So if it's something that no-
one bothers attacking because there's always an easier way, it doesn't matter
how strong or weak it is.
As Ian Grigg recently put it:
The problem we have is not how to get stronger crypto in place, it's how to
get more crypto in place.
Securing something like MQTT would be a good start...
Peter.
[0] Alongside simply ignoring the fact that crypto may or may not be present,
I'm also taking things like "fails to check cert issuers" and "allows
unauthenticated remote firmware updates" as "not looking at the crypto".
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
