Conversation

Lance R. Vick ( @lrvick@mastodon.social )

dropping CCs at request Anyway, all said I agree with you. But the concerns you mention here are also true of Android devices. I would rather have physically replaceable radio modules and then work on reveng or memory isolating the drivers. twitter.com/DanielMicay/st

This Tweet is unavailable.

1

1

Replying to

Big difference between a device with components that are strongly hardened, highly audited and have good ongoing security support vs. the complete opposite. Also, portraying it backwards by misinterpreting how DMA / IOMMUs work is just wrong.

1

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

You can't claim hardware is secure you can't see the firmware for. Tomorrow's update could be hostile. You present a fair argument though. We either design to distrust the radios, or we might as well blindly trust their updates. I am convinced here.

2

2

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

and

I just take the other side of this. I want to understand what it will truly take to have the OS distrust the radios. There is no real security until that is true. This will likely cause some interesting research for me, so thanks for helping point me that direction.

1

Replying to

The radios have persistent state, hardware identifiers and the ability to track location. If an attacker exploits them or they are malicious, then you're having your location tracked and there is a local attacker able to target the kernel driver and other components through that.

2

Replying to

and

It's not even just the kernel driver exposed from the OS as attack service. It's the software stack using the kernel driver to talk to the radio too. It's all the kernel infrastructure exposed by that kernel driver as attack surface. In general, people don't write drivers with

2

Replying to

and

the hardware explicitly treated as an adversary. You actually do get a lot from using an SoC platform with a huge amount of resources put into hardening components, isolating them, hardening drivers and also a whole lot of security researchers targeting it and improving it.

1

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

Well as you yourself state, security researchers can never -assure- it is not malicious when the stack is so large and complex, so I would rather have a clean firewall between the radios and the OS for starters. Keep making the zone that needs to be safe smaller.

2

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

and

At this point we have a long history of sophisticated attack demonstrates that give us good reason as a community to start advocating for drivers, especially for complex stacks like radios, to treat every hardware component as malicious.

1

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

and

I want a device where the radios in it are no more trusted than the ISP modem in the corner. I want to assume it is backdoored and malicious at all times, so when it is, I am covered.

1

Replying to

A radio that's compromised is a tracking device that you're carrying around with you and that includes Bluetooth, Wi-Fi, etc. Not to mention that things like Wi-Fi pose a greater threat than you probably realize. They can actually gain info on the environment beyond location.

6:18 PM · Sep 11, 2020Twitter Web App

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

Job #1 is assume they are malicious so they can't get into the OS. Job #2 is making sure they themselves are not compromised Physical switches to turn them off when not needed is short term damage control until they can be assured trusted.

1

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

and

Job #1 is much easier than Job #2 IMO. You imply you trust radio hardware will be totally secure as long as all firmware updates are blindly applied as they come out. I don't trust that. I want them quarantined for damage control.

2

Show replies