Hacker News new | ask | show | jobs
by yaantc 4420 days ago
That's an exaggeration. The carrier cannot get access to the application processor memory, even if the baseband processor itself has access. There is no such standard interface for that, and no baseband maker would do it. Why take the responsibility for a backdoor that you don't even control? There were no such things on the BB I've worked on. Of course if the BB CPU has access to the whole system memory then a bug in the protocol stack can be exploited to get its content. But that's not specific to a carrier. And all peripherals embedding a CPU have the same weakness, it's hardly specific to cellular BB.

Also, limiting the access of the BB CPU (or CPUs nowadays) to the system memory is perfectly possible: put the BB IP behind an IOMMU (SMU in the ARM world). Then just like a MMU can restrict a process access to the system physical memory, the IOMMU can be used to sandbox the BB and limit its access to the memory to its own dedicated range and nothing else. This makes sense even when the same company does the AP and BB part, for robustness. Just like complex applications are split into independent processes for fault isolation and security.

Instead of making exaggerated claims, it seems to me it would be more productive to put pressure on AP vendors for such SMUs to become standard. It's not that common yet in the ARM world (each additional IP adds some cost), but it should and all master capable IPs should be behind one IMHO.

That won't provide perfect security --- there could always be some backdoor. But in practice it would be good enough. And if there's a backdoor the BB is nothing special: better to make the backdoor accessible through any external interfaces.

Sorry if I'm a bit blunt there, but as a person working in cellular I'm a bit fed up by all the (misplaced) paranoia. If you don't like the telcos, fine, but no need to go all tinfoil hat. To spy on you there is no need for any backdoor in the device: the network can and even must, per the law, be able to intercept everything. And that's part of the standard.

1 comments

>To spy on you there is no need for any backdoor in the device: the network can and even must, per the law, be able to intercept everything. And that's part of the standard.

CALEA/LI are irrelevant; you should always assume the network is tapped. Lawful intercept does not give the same kind of access at all as a baseband processor exploit.

There is definitely a need for a backdoor in the device, otherwise all an attacker will get is encrypted data.

Lawful intercept gives access to all communications going through the BB in clear, as well as position. On top of that a BB exploit could in theory (with no IOMMU protection) provide access to the full system memory, and I agree with this. But my point remains: there is no need to single out the BB there. And putting a backdoor in the BB doesn't make sense to me from an engineering point of view (and doesn't match my experience in the area either).

We're talking about integrated BB where the BB is on the same die as the rest of the system. Just put the backdoor function at the system level, accessible from any interface. Why do a special case for the BB? There's no point in that, as there's no gain. If anyone goes to the trouble to insert such a backdoor, isn't it better to make it accessible remotely thought any interface, and through all local interfaces?

Even better, call it a secure remote management function, with remotely upgradable firmware, and make it usable for professional use cases. And still being usable as a backdoor. What's better than hiding in plain sight?

So I don't dispute the notion that there could be backdoors in chips. What I find illogical is to single out the BB for this. Any interface with bus master ability and a local CPU (WiFi, BT, cellular...) can on principle be exploited in the same way, on a SoC with no IOMMU protection. So instead of making juicy story with backdoored BBs and nasty telcos, why not address the general case and insist on having systems with an IOMMU controlled by the main CPU? Then an open source system can protect the main CPU and system memory against bugs in any peripheral behind the IOMMU.

That won't protect against a "security/management function" designed to bypass the IOMMU of course. At some point there is no substitute for trusting (or not...) the chip maker. But at least that would protect against a whole class of bugs, which is a win IMHO.