[Cryptography] FBI: Don't trust IoT devices

[Jeremy Stanley]

On 2019-12-11 15:57:48 -0800 (-0800), Henry Baker wrote:
> At 08:13 AM 12/11/2019, Jeremy Stanley wrote:
[...]
> > For wired LANs, the most common solution is referred to as "port
> > isolation" or "Private VLAN"
[...]
> > For IEEE 802.11 wireless, many WAPs implement something called
> > "wireless client isolation" or "AP isolation"
[...]
> What about achieving this isolation goal via encrypted
> tunnels/encrypted VPN's, etc?  Yes, I know, one could still do
> traffic analysis, but they could probably do that (with additional
> effort) even with Cisco's mechanisms.

Are you talking about between your client and your gateway? Why
bother with a VPN, you can just do IPSec in transport mode instead,
no need for tunnel mode in such cases.

> I don't know if I would trust Cisco "port isolation" to devices
> that can run tcpdump/wireshark/snort/etc. 24x7, even if I had
> Cisco routers.

Well, the specific technologies I described are more about securing
things at the Ethernet frame switching layer (not at the IP packet
routing layer), disallowing flows between clients so that they can
only send frames to and receive frames from the port where your
gateway (or other shared devices you want them to reach) is
connected but cannot reach or "see" each other at all. And it's not
*just* Cisco routers which do these sorts of things, for example
I've seen discussions about using filtering rules in ebtables on
OpenWRT to similar ends. The implementations are not standardized
mainly due to the situation with RFC 5517, but as PHB pointed out,
US6741592B1 is expiring early next year so maybe this will improve.

Keep in mind that a compromised client device running a packet
sniffer to eavesdrop on traffic from other client devices would need
to overcome basic switching optimizations on any modern (that is
produced in the past two decades) switched network to begin with,
for example by spoofing the victim's address on frames sourced from
the attacker's interface or flooding the switch with frames from
lots of bogus spoofed addresses so as to overload its bridge table
and cause it to fall back to forwarding all frames to all ports. To
mitigate this, such isolation schemes are usually coupled with "port
security" measures which tell the switch to shut down a port as soon
as it sees frames from a different hardware address than the one
which was previously communicating through it (also good for
blocking rogue bridges). Switching gear which supports port
isolation invariably includes port security features as well,
because you can't really trust isolation unless you have control
over what you're isolating. And for 802.11 wireless, this isn't
really even needed as far as I'm aware, because client-to-client
communication requires either being forwarded through the AP or
explicitly creating a separate ad hoc network between them.

I can't tell if your concern is strictly with rogue clients (such as
IoT devices) connected to your network, or with the forwarding
infrastructure for your network. Ethernet layer isolation
technologies are useful for preventing the problems you describe
with the former, but honestly if the concern is for the latter it's
already game over. Unless you move to end-to-end encryption between
sensitive devices and whatever they communicate with on the
Internet, at some point you have to trust a forwarding device,
whether it's your switching and routing gear or your VPN gateway,
and in many cases they may all be the same device. Adding more
network equipment to deal with a lack of trust in your network
equipment is also a questionable approach, because with more devices
comes more complexity and an increased risk you'll introduce more
vectors for attack.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20191215/2891ae94/attachment.sig>