You'll find the modem on most smartphones is connected via USB - or rather its chip-to-chip version, HSIC. For SoCs where it's on-die - on the same bus/fabric - they will (if it's not an idiotic design) use an IOMMU of some sort, to prevent DMA from having access outside of its sandbox.

Even if it's a modem on the other end of USB - which will almost certainly be using DMA, but at least host-programmed DMA - that's no guarantee. Google "Evil USB". USB is a overly complex stack which has and will continue to result in countless vulnerabilities, regardless of what you do with it.

OTOH, on the device like Neo900 it is well-known what kind of device is connected to the internal bus and software stack (at least on Linux) can easily be advised to not accept anything that doesn't look and behave like the included modem should.

In a properly configured user OS, the modem would need to use some software vulnerability to exploit the USB stack, so the same principles apply there as with, say, OpenSSL, browser or the kernel. Secret zero-days aside, when some bug is found, it is patched and you upgrade the vulnerable component, just like on PC.

An easy way to see this is recompile the USB keyboard driver to ignore keyboard descriptors with a particular address or vendor ID. If you do this, the pendrive can't do anything because USB is host-controlled, as implemented by the OS. Without the OS initiating a conversation with the pendrive and saying "ok, I'll configure you as a keyboard and interpret responses from you as keystrokes", it can't happen.

As you point out, the main CPU on a phone does not implement HID autoconfig on the internal baseband bus.

Any USB link requires the host to maintain some persistent state in data structures mirroring what it thinks the state of the device is. There's no "DMA" in the sense that the device has direct access to the host - but that doesn't preclude something as mundane as a buffer overflow, use-after-free and so on.

"DMA", with appropriate IOMMU, is just fancy shared memory communication. You're just as likely to mess that up as a serial link. It's happened. A lot.

Sure it can. Just pop up a dialogue on the screen displaying a random character string and ask the user to type the string. The dialogue could simply instruct the user to unplug and cast suspicion upon a device that is pretending to be a keyboard.

There's an easy way to tell. Does the bus carry memory addresses? Then it supports DMA. Does it just send messages? No DMA to protect against.

The USB controller on a PC does support DMA. The OS device driver allocates buffers and passes them to the controller to fill. If it's properly programmed, it will only store data into those buffers. An IOMMU is there to prevent malicious kernel privileged code from bouncing through peripherals that support DMA to compromise other privileged code.

Messages on the USB bus side have no addresses in them and there is no DMA involved.

"DMA" as the parent puts it implies a core in the same SoC, rather than external. It would be hair brained to let this have unfiltered access to the fabric. However, that's exactly how older SoCs used to do it - in fact it used to be in charge and the AP shoved behind the IOMMU.

These days nobody I know of is stupid enough to have that arrangement. So it's not really a choice of "DMA" vs USB. External isn't buying much, unless you distrust the fabric filter (IOMMU), which isn't necessarily paranoid... but a level beyond this kind of system decision.

Do you happen to know whether this is the case for the latest generation of Qualcomm SoCs such as the Snapdragon 810 / MSM8994?

I have been "Mr. Cry About Baseband Ownage From The Rooftops" for years around here, and even I have to admit that a lot of baseband implementation in modern smartphones uses this same USB connected model.

It's not universal, but a lot of USB-connected baseband is out in the world...

Still closed source and owned by the provider. I would love to see an open source baseband with a hard switch to disable it.

The closest way I can see to get something to be trusted is to start from a GNU approved laptop like [2] and add to it whichever modem you had on the neo9000 via usb... just as you said, but then you have this situation...

For something to be secure... there has to be a secure chain of trust...

-who creates the cpu? which kind of microcode has on it?

-video controllers? blobs? drivers?

-anything with DMA, who created your memory controller?

-are you sure about the media you are using to install?

-who creates the hdd? did someone "touch it" before you?

--what about the controllers on the hdd? ram? take a look on the latest technology and you'll see there is no way you can trust anything [0][1].

--anything with a controller... this is a cpu... this is something not being driven by the main cpu it's an attack vector.

"The potential of reprogrammable computers that, at a low level, run the code you ask them to doesn't seem to get through to most of the HN crowd" Do not generalize, different people, interests and approaches are part of how nature works, and remember we are as a friend said the "nature virtual machines".

[0] http://bgr.com/2015/02/17/nsa-hard-drive-firmware-virus/

[1] http://recode.net/2015/02/17/nsa-can-hide-spyware-in-hard-di...

[2] https://www.fsf.org/news/libreboot-x200-laptop-now-fsf-certi...

edit: format

From the perspective of trying to guarantee security when you don't trust manufacturers, there are system-level invariants dictated by the laws of physics: you can be sure, to within measurement precision, that different chips from different manufacturers are not colluding wirelessly, and you can use signal analyzers on the bus to see what is being transmitted in typical operation. This won't save you from timebombs, but it gives you some idea of what's going on at least, and practically you can expect that unrelated corporations do not have the spare time/money/engineering smarts to invest to collaborate to spy on the users of heterogeneous devices far down the line. So you may not quite be able to trust your CPU, or your modem, or your RAM (well... maybe RAM is regular enough that you could sample and decap and borrow a microscope and see if things look fishy), but you can at least make sure they are behaving generally as CPUs or modems or RAM might at the boundaries between them. If you build a system with enough small chips doing simple tasks, though you'll end up with a slow, inefficient thing (think naïve implementations of a microkernel), you no longer need to trust the individual components much as there's little room for them to screw you over at a high level.

And of course it's not true that all of HN is the way I described--it's just a distressingly large, or distressingly vocal proportion. I know it's at least enough people that projects like OsmocomBB are tragically underfunded, underhyped, and under-hacked-on.

I'm not sure how readily available are this kind of tools for the average joe, correct me if I'm wrong I do also thing is a destructive process, taking as a basis the Core 2 Duo P8400 that the X200 on the libreboot laptop which as per intel page is built on 45nm fabrication[0] and as Wikipedia mention (I know wikipedia could not be a trusted source of information for this) "This attack is not very common because it requires a large investment in effort and special equipment that is generally only available to large chip manufacturers. " [1] which still sounds logical.

about " but you can at least make sure they are behaving generally as CPUs or modems or RAM might at the boundaries between them" you know this is close to impossible, check for example how the RAM tests are performed where a set of patterns are tested and you have some degree of certainty [2] and for which they last concludes "It should be obvious that this strategy requires an exact knowledge of how the memory cells are laid out on the chip. In addition there is a never ending number of possible chip layouts for different chip types and manufacturers making this strategy impractical. However, there are testing algorithms that can approximate this ideal. " notice approximate to ideal.

"If you build a system with enough small chips doing simple tasks" and this is the path to take, a new set of trust-able cpus... but it's not one of the current options.

[0] http://ark.intel.com/products/35569/Intel-Core2-Duo-Processo... [1] https://en.wikipedia.org/wiki/Reverse_engineering#Reverse_en... [2] http://www.memtest86.com/technical.htm

Is it possible to build a chip that only executes instructions encrypted by your key? I'm not talking about just decoding to L1 and executing plaintext there, but having a full pipeline that can only work on your encrypted instructions.

e.x. https://en.wikipedia.org/wiki/Amber_(processor_core)

Of course it would be orders of magnitude slower than a modern CPU.

"His approach is clever and is known as a “glitching attack“. This kind of hardware attack involves sending a carefully-timed voltage pulse in order to cause the hardware to misbehave in some useful way" from http://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-...

edit: typos

I like RockChip ChromeBooks, with no microcode and libreboot support. You can buy them brand new, unlike x200.

As a result, we just recently got cheap, widely accessible SDRs, and even they only came about through more or less an accident. And their performance renders them pretty much useless for even just GSM. Now serious SDRs like USRPs have been available for a long time, and their specs make it possible to run GSM and other advanced RF protocols. So if you pay the 2k+ required to get one of these functional SDRs and have the knowledge that is predominantly still only found in dead trees or lectures in fields quite unrelated to CS, you still won't be able to get anything resembling a GSM phone.

There are the obvious legal hurdles, you are not allowed to transmit willy-nilly, not even to just talk to a public GSM network. If you make sure no RF gets out the real world, you can pickup horribly outdated, discarded GSM test equipment from eBay for more big bucks and use that. In related news, they usually have a GSM(+) test network at the CCC congress, but they won't in 2016 because the regulatory agency just auctioned off the last bit of available test spectrum in the right band you could acquire through a lengthy, convoluted petition.

And the list just goes on and on and on.. remember you'll need to first communicate with a SIM (really, Java!) card that is your key into any network. They pretty much mandated the equivalent of a DRM dongle!

All the interfaces to this are open: the wire protocol to the SIM and the over-the-air protocols for authentication and security (what a phone needs to do) are specified completely by freely available 3GPP/ETSI specs.

The details of how the SIM computes the derived keys and authentication response are a black box. 3GPP suggests a couple of sample algorithm sets, but there's no way to know whether the card did that unless you have the secret key (shared between the card and a box deep inside the carrier's network).

However, the phone just passes the authentication-request parameters in an authenticate command to the card, passes the result of that in an authentication-response message back to the network, and obtains integrity and ciphering keys (for GSM) from a couple of files on the card (UMTS/LTE use some keys derived from these, but again, it's documented).

An alternative, used in some older US specs like late AMPS, CDMA, and (EIA-136) TDMA is to store the secrets in the phone, generally at manufacturing time. This means that there's no real boundary between the carrier's authentication widget and "your" phone.

Much better to have the identity contained in a SIM that belongs to the carrier, that your phone talks to at arm's length.

Java seems to be for applications other than plain (U)SIM like prepaid account management. The card can ask the phone to add a menu to its interface, show messages, collect inputs, and other things. Maybe all plain USIM apps are written in java these days instead of having a masked ROM like they probably used to.

The most interesting thing your SIM card does is run arbitrary programs that can be uploaded to them, without your knowledge, by the carrier:

https://www.defcon.org/images/defcon-21/dc-21-presentations/...

The SIM card is a full computer, with its own CPU and memory, that lives inside your phone and that you have no control over.

How many opportunities are there to work on secure communications software full time and still put food on the table?

http://bb.osmocom.org/trac/wiki/LegalAspects#Usingmodifiedph...

But the FCC isn't overly concerned if you're doing WiFi or Bluetooth, their area are the broad analog strokes, correct bandwidth and correct power. As such, if you use something that has the correct filters in hardware, you'll be just fine though technically breaking the law.

Their mailing list is fairly active.