
There are no secure smartphones - moehm
https://www.devever.net/~hl/nosecuresmartphone
======
gue5t
The folks at [http://neo900.org/](http://neo900.org/) are well aware of this
and that phone is designed accordingly (details at
[http://neo900.org/faq#privacy](http://neo900.org/faq#privacy)). Hype-driven
products like BlackPhone misrepresent their devices as being perfectly secure
when this significant attack vector is completely unmitigated.

On the Neo900, the modem is connected via USB (bus; there is no physical
connector) which means it doesn't have DMA. There is no feasible open-source
baseband. OsmocomBB
([http://bb.osmocom.org/trac/](http://bb.osmocom.org/trac/)) is the closest
thing to one, and it is relatively incomplete and works on a very limited
range of mostly badly outdated hardware, none of which would not really be
reasonable to use in a phone to be manufactured today.

It's incredibly difficult to get people to care and help with the lack of
software for tasks like GSM communication. Somehow even among people who
describe themselves as "hackers", most just want to run Android or iOS and
buy/run closed-source apps, and are more interested in Javascript and
employment than reverse-engineering and doing things that have never been done
before. 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.

~~~
pslam
> On the Neo900, the modem is connected via USB (bus; there is no physical
> connector) which means it doesn't have DMA.

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.

~~~
seba_dos1
"Evil USB" (or "bad USB") is possible thanks to the U part of USB - universal.
If you connect a pendrive to your computer, it can easily say that it's a
keyboard, because your computer cannot easily verify that you haven't just
connected a keyboard. It would need to ask you in some trustworthy way to be
sure, which sometimes can be problematic.

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.

~~~
NateLawson
This is correct. The problem in this example is not the pendrive, but the
automatic selection of device drivers based on the PC OS 100% trusting
physical access.

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.

~~~
pslam
I picked a terrible example which doesn't demonstrate what I intended to.

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.

~~~
NateLawson
Yes, parsing of untrusted data, race conditions, etc. are still a problem in
general. My complaint was with the uninformed article, not your analysis.

------
tptacek
It's good to draw attention on baseband processors, but there are technical
assertions in this post that are probably not accurate (lack of auditing and
the notion that you can assess the security of a whole phone system by whether
or not there's an IOMMU).

The systems security of modern phones is surprisingly complex. Google and
Apple both care very deeply about these problems, and both have extremely
capable engineers working on them. Without getting too far into the weeds:
they haven't ignored the baseband.

~~~
chc4
The team behind Replicant reported that they found a baseband backdoor in
Samsung Galaxies[0][1]. I think it's perfectly fine to extrapolate from that
that you probably shouldn't trust the baseband, even if Google and Apple are
looking into it. Until they have a concrete solution shipped, all the in-the-
closet work on the problem is meaningless.

0: [https://www.fsf.org/blogs/community/replicant-developers-
fin...](https://www.fsf.org/blogs/community/replicant-developers-find-and-
close-samsung-galaxy-backdoor) 1:
[http://redmine.replicant.us/projects/replicant/wiki/SamsungG...](http://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor)

~~~
tptacek
I don't think you should trust the baseband.

My objection is with the idea that you can look at a design, not see an IOMMU,
and extrapolate from that the notion that the baseband has full access to the
memory of the other chips in the design.

That's a reasonable assumption in a PC design. There may have been a point,
for some phones, where it was a valid assumption for phones. It's not with a
modern phone design.

~~~
jwise0
In my research on phones from the Unrevoked project (admittedly, 4+ years
ago), this was the case: the baseband and the CPU shared the same memory. The
baseband memory was carved out from the CPU such that the CPU could not access
it, but the microcontrollers serving the baseband had CPU access, as I recall
from the Qualcomm boot documentation: the chain of trust from CPU boot was
established by the baseband processor, not the other way around.

I would imagine that things have changed a little bit, but the baseband back
then, and I imagine still now, is considered to be the ultimately trusted
element of the system. I'd be surprised to hear that they've changed so much
that the baseband doesn't still have full control over its host system.

~~~
tptacek
The baseband doesn't have full control over phone systems.

~~~
throwaway7767
You should qualify which specific phone designs you are referring to (or if
it's "all new phones", when the cutoff date was). After all, you are
responding to someone who has researched this and found (like others) that
indeed, the baseband in older phones _did_ have full control.

Your statement is general to the point of misinformation.

------
verusfossa
Semi-related: I feel like there should be an open source dumbphone project.
Smartphones have a lot of bells and whistles with a large attack area but many
people just want to make calls. Sure this wouldn't fix the baseband issue, but
it seems the safest way to ensure isolation between personal information and
potentially hostile cellular blobs is to never put the information on the
device in the first place. A small, open, dialer-only yet potentially
extensible cellular platform would be really welcome, I think. Maybe something
like this [1] using the rpi zero as a base with some 3d printed cases, reverse
engineer what you can otherwise. Replicant is a noble project, but chasing
android versions, screen sizes, video codecs, proprietary hardware locks etc
is an uphill battle and kind of a distraction IMHO.

[1] [https://www.raspberrypi.org/blog/piphone-home-made-
raspberry...](https://www.raspberrypi.org/blog/piphone-home-made-raspberry-pi-
smartphone/)

edit: typo

~~~
nickpsecurity
[http://web.media.mit.edu/~mellis/cellphone/index.html](http://web.media.mit.edu/~mellis/cellphone/index.html)

------
hardwaresofton
Would really love to see this upvoted more. This basic truth should be common
knowledge for privacy-minded or security-minded technologists/developers.

There are lots of reasons GSM won't/is hard to make work. What are the
options? As more and more carriers in the USA provide wifi-dongles that are
connected to 3G, maybe it's better to just do that, and move off making calls
directly from your phone completely?

For example, it might make sense to buy some phone, connect it to a device (or
flash it with some software) that makes it essentially a portal for phone
calls of sorts, and give it sandboxed access to your network. It's
significantly harder for GSM backdoors to be effective if the entire device is
sandboxed right? Maybe this way, as you roam around, you can somewhat securely
communicate over IP to your call-making device, and make/receive calls?

[EDIT] - Thinking about it, the suggestion is moot, since all someone would
have to do is write some software to replay messages, or leak messages or some
other nefarious thing, and stick it on the baseband of the device -- even if
it can't damage your network it's still quite insecure.

Maybe we should just give GSM up altogether, and start trying to move
ourselves (and the world) to only communicating over IP (which we have a shot
at securing, assuming modern crypto isn't completely broken)? What is the
situation like with completley open source wifi connectivity?

~~~
seba_dos1
LTE is basically VoIP, a 180° change from the monstrosity of 3G, although the
providers still manage to fail spectacularly at it.

[https://media.ccc.de/v/32c3-7502-dissecting_volte](https://media.ccc.de/v/32c3-7502-dissecting_volte)

~~~
hardwaresofton
LTE is a protocol/standard with more efficient methodology/tech right? -- my
main issue was the involvement that certain agencies have with the basebands
put into mobile phones and the resistance that people trying to develop
completely open-source basebands encounter.

LTE doesn't seem like a solution to this problem, it sounds like just a more
efficient baseband. Even if it's easier to reverse engineer, use of it might
still be outlawed (as is an issue with the neo9000).

Does LTE use some publicly accessible/modifiable spectrum that I don't know
about or something?

~~~
seba_dos1
LTE, when compared to 3G, drops a lot of complexity and basically defines a
data link for IP to flow in. Telephony services are then implemented via IP.

Of course the transmission itself is still as proprietary and filled with
regulations as all GSM standards; I just noted that it should be easier to
somehow "sandbox" the communication via LTE now than with older technologies.

It's still not the solution and I'm fully aware of it.

------
peteretep
The article asserts:

    
    
        > It would, in my view, be abject insanity not to
        > assume that half a dozen or more nation-states (or
        > their associated contractors) have code execution
        > exploits against popular basebands in stock.
    

To me this ignores the flip-side of the argument. If US intelligence services
really thought the Chinese and Russians could remotely and invisibly hack
all/most smartphones then no-one with access to sensitive information would be
allowed to do work on one, unless they're very confident that they've managed
to secure their devices without leaving a stone unturned.

Soz Hilz[0].

[0]
[http://media4.s-nbcnews.com/i/newscms/2015_10/913276/150303-...](http://media4.s-nbcnews.com/i/newscms/2015_10/913276/150303-hillary-
clinton-text-mn-1100_c4f740ee15e6224bb75a5f58fecc072a.jpg)

~~~
reirob
Following your logic, then any other sovereign non-US states must forbid their
their citizens and companies to use US technology in order to avoid US
stealing the data. At least they should forbid it to those organisations and
citizens who as you say access sensitive information.

Still, even after Snowden, the whole world uses Microsoft, Apple, Intel,
Google technology everyday.

This is not a prove that your logic is wrong, but I am wondering how much
today's intelligence services are interested in protecting their own companies
and citizens from data breaches. It might be that they are more interested
into stealing as much data as possible themselves in order to be able to
negotiate with foreign states/services.

------
shmerl
_> Modern smartphones have a CPU chip, and a baseband chip which handles radio
network communications (GSM/UMTS/LTE/etc.) This chip is connected to the CPU
via DMA. Thus, unless an IOMMU is used, the baseband has full access to main
memory, and can compromise it arbitrarily._

Indeed. Such design coupled with very obscure and closed baseband firmware is
a security nightmare. One should ask, who was pushing for such an approach.

------
matt_wulfeck
> For devices with cellular access, the baseband subsystem also utilizes its
> own similar process of secure booting with signed software and keys verified
> by the baseband processor.

According to the iOS security white paper, the baseband firmware is part of
the secure boot chain, and has its own secure boot chain.

This allows me to assume it's very hard to inject or replace the the firmware
with a malicious code. Whether or not the firmware itself has a backdoor or
whatever I don't know, but at least one major phone manufacture knows this
firmware is very important for security.

~~~
revelation
That's just iOS being iOS, on Android the baseband firmware can usually be
flashed using fastboot. However, there will presumably still be a bootloader
on the baseband processor that checks the authenticity of what you just
flashed to it.

It's very interesting to just download a baseband firmware (usually called
radio.img) from a random Android forum, unpack it and run _strings_ on the
code you get. It'll usually be an ARM processor running a homebrew RTOS, which
is concerning enough. When you search for _NMEA_ and realize the baseband
processor is running the GPS chip, that's when you are starting to get doubts.
And when you finally realize theres a bunch of audio codecs and the baseband
is controlling the microphones, that's when the full force of despair hits
you. You don't own it, you don't control any part of it. Your Android doesn't
either, it begs the baseband for a slice of its information.

~~~
zanny
> Testing DDR Read/Write.

> _Testing DDR Read /Write: Memory map.

> Testing DDR Read/Write: Data lines.

> Testing DDR Read/Write: Address lines.

> Testing DDR Read/Write: Own-address algorithm.

> Testing DDR Read/Write: Walking-ones algorithm.

> Testing DDR Deep Power Down.

> Testing DDR Deep Power Down: Entering deep power down.

> Testing DDR Deep Power Down: In deep power down.

> Testing DDR Deep Power Down: Exiting deep power down.

> Testing DDR Deep Power Down: Read/write pass.

> Testing DDR Self Refresh.

> _Testing DDR Self Refresh: Write pass.

> Testing DDR Self Refresh: Read pass.

> Testing DDR Self Refresh: Entering self refresh.

> Testing DDR Self Refresh: In self refresh.

> Testing DDR Self Refresh: Exiting self refresh.

Yes Galaxy s4 modem, please provide unlimited access to all government
agencies of all my phones content and communications.

> Samsung Root CA cert1%0#

Fantastic, you also inject your own root certificate. Thanks.

------
jrockway
Don't modern ARM chips encrypt memory (for DRM reasons)? If that's in use
(modulo the area the the baseband needs to read/write), it doesn't matter. An
adversary can read the memory, but can't read the encryption key out of the
CPU.

If it could, anyone with a logic probe could grab un-DRM'd video data out of
the RAM, which would make many people very unhappy.

------
mindslight
The Samsung i9300/i9500/etc use separate Exynos application processors coupled
with stand-alone communication chipsets from Intel (originally Infineon).
Check out the Replicant wiki for more info. The Replicant devices are
unfortunately quite old (i9300 being the latest), but newer models do continue
the trend (SM-G920H for the S6 international Exynos, I believe). You'll just
be stuck on their proprietary OS, or need to fund a bunch of CM/Replicant
development.

Of course the same branded (eg "Galaxy S6") has many different models for
across the world, most using integrated Qualcomm chips. Honestly looking at
the list of variants and thinking about the conservatism of RF and telecom
regulatory regimes, you'd have to be naive to think the whole ecosystem
doesn't simply exist under the control of major intelligence agencies.
Communications have always been regarded as dangerous.

------
95014_refugee
The article author is not well-informed. You can verify this yourself by
physical inspection, via leaked schematics, by paying a teardown analyst or
via examination of available documentation for the components used in modern
smartphone designs.

------
brandmeyer
There is something in between nothing and a full IOMMU. I've been working with
a TMS570 processor lately whose DMA engine supports an IOMPU. This hardware is
equivalent to the Cortex-R/M Memory protection unit.

An MPU has all of the same protection domains that an MMU does, except for a
few major differences:

\- The total number of protected regions is very small (12 or so), such that
the hardware cost is somewhat smaller than a TLB cache.

\- To offset the small number of regions, the size of each region can be
almost any power of two.

\- The MPU does not perform address translation, again reducing the hardware
cost.

Thus, the kernel can configure the peripheral's DMA engine to only allow
access to a page or few.

------
hackuser
Based on what I've read from more authoritative sources (or is the author an
authority in this area?), this information is outdated:

> It can be safely assumed that this baseband is highly insecure. It is closed
> source and probably not audited at all. My understanding is that the genesis
> of modern baseband firmware is a development effort for GSM basebands dating
> back to the 1990s during which the importance of secure software development
> practices were not apparent. In other words, and my understanding is that
> this is borne out by research, this firmware tends to be extremely insecure
> and probably has numerous remote code execution vulnerabilities.

I've read in several places that basebands now widely use the OKL4
microvisor,[1] based on the formally verified (fwiw) seL4 microkernel, and are
much more secure than before. Does anyone know more about this?

[1] [https://gdmissionsystems.com/cyber/products/trusted-
computin...](https://gdmissionsystems.com/cyber/products/trusted-computing-
cross-domain/microvisor-products/)

~~~
wolfgke
> I've read in several places that basebands now widely use the OKL4
> microvisor,[1] based on the formally verified (fwiw) seL4 microkernel, and
> are much more secure than before. Does anyone know more about this? > > [1]
> [https://gdmissionsystems.com/cyber/products/trusted-
> computin...](https://gdmissionsystems.com/cyber/products/trusted-computing-
> cross-domain/microvisor-products/)

Surely baseband processors are _not_ based on seL4, since it currently has no
realtime support (though it is in development:
[https://wiki.sel4.systems/seL4%200.0.1-rt-
dev](https://wiki.sel4.systems/seL4%200.0.1-rt-dev)).

OKL4 is based on a kernel of the L4 family (source:
[https://en.wikipedia.org/wiki/L4_microkernel_family#Commerci...](https://en.wikipedia.org/wiki/L4_microkernel_family#Commercial_deployment)):

>
> [https://en.wikipedia.org/wiki/L4_microkernel_family](https://en.wikipedia.org/wiki/L4_microkernel_family)

seL4 is another kernel of this family that has been formally verified.

------
xlayn
I have address as a response to gue5t how creating a chain of trust may not be
a doable goal as probably every part of the system is not trust-able.

However I'm thinking a different approach can be taken, suppose we abstract
the different ways for communication a device has and use them as sockets or
layers and then create an algorithm that distributes the communication through
several channels.

For example two cellphones

-one against another using the light on one screen against the camera of the other

-the vibrator motor captured by the microphone

-introducing certain pattern of noise in Bluetooth communication by the other radios

-communication through stenography

-sending huge amounts of information (the more information the more power needed to discriminate, understand)

-abuse how things are not supposed to work (instead of sending packets in the correct order, use ping as a way of sending data by crafting the requests).

-Custom network stack

-use of a customized version of encryption with extra large keys (think 20480 bits instead of 2048)

-and last but not least use an algorithm that mutates the distribution logic based on certain algorithm dependent on time (in the same fashion virus mutate themselves)... using as key for example your voice

edit: explanation

~~~
drdaeman
> extra large keys (think 20480 bits instead of 2048)

Don't think it's a wise idea. This was briefly discussed recently:
[https://news.ycombinator.com/item?id=10794991](https://news.ycombinator.com/item?id=10794991)

~~~
xlayn
Thank you for the comment, I learned something new today.

Resume: "if you could break a 4096-bit RSA key, you've probably found a
fundamental weakness in RSA that means you should move to a different
algorithm entirely"

------
shyn3
Would this device be protected?
[http://www.gsmarena.com/blackberry_priv-7587.php](http://www.gsmarena.com/blackberry_priv-7587.php)

------
InclinedPlane
This is just a special case of the fact that there's no secure anything.

In 2016 that's just the price you pay for using computers. You just have to
live with it. Mitigate it the best you can, rely on the ol' "mossad or not
mossad" strategy now and then, hope for the best, etc. If you have a strong
need for increased security, well, god help you (spoilers: you will receive no
help), you're going to pump a lot of effort into building something that will
still have tons of vulnerabilities.

~~~
zanny
Just get an FSF laptop for security. You can even trust the hard drive if you
use software encryption of all your data. I'm not sure what remains insecure
on that class of hardware?

~~~
schoen
They have a better story about firmware than other devices, but they're still
running Linux and GNU software, which often has remotely exploitable
vulnerabilities. Just today OpenSSH (which is neither Linux nor GNU but which
you would obviously use on your FSF laptop) announced an extraordinarily
serious remotely exploitable vulnerability. That's presumably not the last
vulnerability of that severity in an operating system you install today onto
your FSF laptop.

It's not obvious that FDE will totally mitigate hard drive firmware attacks
because your boot loader and kernel are likely running from an unauthenticated
partition (for instance, most Linux-based systems with LUKS today have all of
/boot on a separate non-LUKS partition, and something like a GRUB boot sector
too). If the hard drive understood how to recognize the kernel in /boot, it
could inject a vulnerability into it. In a few presentations a couple of years
ago, I walked through a real example of how a single bit flip in a binary can
introduce (or re-introduce) a fencepost error that can compromise security,
because the opcodes for extremely similar yet different conditional branches
often differ by a single bit. One form of the conditional branch like jump-if-
less may be the correct invariant, while another form like jump-if-less-or-
equal may be the exploitable erroneous form of the same loop.

I'm not knocking people's work on trying to get a handle on what firmware is
running on their devices; I think that work is great. The trouble is that
attackers are looking for exploits and persistence in every layer of the
system, so you won't get a silver bullet against all attacks by shoring up one
aspect.

Good stuff on this: Halvar Flake's "Why Johnny Can't Tell if He is
Compromised", and Joanna Rutkowska's recent CCC presentation on persistent
state.

------
scientes
Or you can just use WIFI and turn the baseband off like I do. The cell
companies are all crooks anyways (in the US), and I don't want to do business
with them.

~~~
raarts
Problem is, when you use VoIP over WiFi, you loose echo-cancellation, because
the echo cancel hardware resides in the baseband and is not used in WiFi
calls.

~~~
Jude2711990
You may also consider echo cancellation software that is capable of doing
server side echo cancellation that can handle the long echo tail. For example,
take a look at the options provided by SoliCall.

------
delinka
"...no secure smartphones." There's always a weakness somewhere. Makes me
wonder why governments want backdoors. Just in case we manage to make a
perfectly secure device? It's too onerous to ask a judge for permission to
"hack" a phone through weaknesses rather than asking permission for an
escrowed key?

------
elchief
How about those [http://www.cryptophone.de/en/company/news/gsmk-introduces-
ne...](http://www.cryptophone.de/en/company/news/gsmk-introduces-new-
groundbreaking-secure-mobile-phone/) phones? Is a "baseband firewall" just a
gimmick?

~~~
pakled_engineer
It's basically (the older Samsung models) a Stingray detector, plus will shut
down the device if activity is detected in the baseband CPU while the
application CPU is dormant meaning shenanigans like SMS 'stealth' spamming is
going on or evil OTA update.

You can always walk around with a portable hotspot and leave the phone on
airplane mode. Only use textsecure/signal and download a free software
reversed clone of Google services app to use GCM. If going to all this trouble
to avoid targeted spying probably easier to just buy a chromebook with
RockChip instead and use OTR or Signal whenever it comes out with desktop
client (if not already, I haven't kept up with their current status of
porting).

------
walterbell
Tor has a discussion (2014) of Android security, including baseband
processors, [https://blog.torproject.org/blog/mission-impossible-
hardenin...](https://blog.torproject.org/blog/mission-impossible-hardening-
android-security-and-privacy#MicrophoneRemoval)

------
wbl
When I spoke to John Callas he said there was a serial link to the baseband on
the Blackphone. I might be misremembering, but it certainly is an issue that
designers are working on solving.

------
nickpsecurity
That's right. Focus on the baseband is kind of the new fad in mainstream
ITSEC. These problems are long-known in high-assurance as the cert requires
_all things that can compute, store, or do I /O_ to be assessed. The reason is
that, historically, these were all where attacks came in. I'm pretty tired but
I can do at least a few points here.

1\. Software. The phones run complex, low-assurance software in unsafe
language and inherently-insecure architecture. A stream of attacks and leaks
came out of these. The model for high-assurance was either physical separation
with trusted chip mediating or separation kernels + user-mode virtualization
of Android, etc so security-critical stuff ran outside that. There was strong
mediation of inter-partition communications.

2\. Firmware of any chip in the system, esp boot firmware. These were
privileged, often thrown together even more, and might survive reinstall of
other components.

3\. Baseband standards. Security engineer Clive Robinson detailed many times
of Schneier's blog the long history between intelligence services (mainly
British) and carriers, with the former wielding influence on standards. Some
aspects of cellular stacks were straight designed to facilitate their
activities. On top of that, the baseband would have to be certified against
such requirements and this allowed extra leverage given lost sales if no
certification.

4\. Baseband software. This is the one you hear about most. They hack baseband
software, then hack your phone with it.

5\. Baseband hardware. One can disguise a flaw here as debugging stuff left
over or whatever. Additionally, baseband has RF capabilities that we predicted
could be used in TEMPEST-style attacks on other chips. Not sure if that has
happened yet.

6\. Main SOC is complex without much security. It might be subverted or
attacked. With subversion, it might just be a low-quality counterfeit.
Additionally, MMU or IOMMU might fail due to errata. Old MULTICS evaluation
showed sometimes one can just keep accessing stuff all day waiting for a logic
or timing-related failure to allow access. They got in. More complex stuff
might have similar weaknesses. I know Intel does and fights efforts to get
specifics.

7\. Mixed-signal design ends up in a lot of modern stuff, including mobile
SOC's. Another hardware guru that taught me ASIC issues said he'd split his
security functions (or trade secrets) between digital and analog so the analog
effects were critical for operation. Slowed reverse engineering because their
digital customers didn't even see the analog circuits with digital tools nor
could understand them. He regularly encountered malicious or at least
deceptive behavior in 3rd party I.P. that similarly used mixed-signal tricks.
I've speculated before on putting a backdoor in the analog circuits modulating
the power that enhances power analysis attacks. Lots of potential for mixed-
signal attacks that are little explored.

8\. Peripheral hardware is subverted, counterfeit, or has similar problems as
above. Look at a smartphone breakdown sometime to be amazed at how many chips
are in it. Analog circuitry and RF schemes as well.

9\. EMSEC. The phone itself is often an antenna from my understanding. There's
passive and active EMSEC attacks that can extract keys, etc. Now, you might
say "Might as well record audio if they're that close." Nah, they get the
master secret and they have everything in many designs. EMSEC issues here were
serious in the past: old STU-III's were considered compromised (master leaked)
if certain cellphones got within like 20 ft of them because cell signals
forced secrets to leak. Can't know how much of this problem has gotten better
or worse with modern designs.

10\. Remote update. If your stack supports it, then this is an obvious attack
vector if carrier is malicious or compelled to be.

11\. Apps themselves if store review, permission model, and/or architecture is
weak. Debatable how so except for architecture: definitely weak. Again, better
designs in niche markets used separation kernels with apps split between
untrusted stuff (incl GUI) in OS and security part outside OS. Would require
extra infrastructure and tooling for mainstream stuff, though, plus adoption
by providers. I'm not really seeing either in mainstream providers. ;)

That's just off the top of my head from prior work trying to secure mobile or
in hardware. My mobile solution, developed quite some time ago, fit in a
suitcase due to the physical separation and interface requirements. My last
attempt to put it in a phone still needed a trusted keyboard & enough chips
that I designed (not implemented) it based on Nokia 9000 Communicator.
Something w/ modern functions, form-factor, _and_ deals with above? Good
luck...

All smartphones are insecure. Even the secure ones. I've seen good ideas and
proposals but no secure[ish] design is implemented outside _maybe_ Type 1
stuff like Sectera Edge. Even it cheats that I can tell with physical
separation and robust firmware. It's also huge thanks to EMSEC & milspec. A
secure phone will look more like that or the Nokia. You see a slim little
Blackphone, iPhone, or whatever offered to you? Point at a random stranger and
suggest they might be the sucker the sales rep was looking for.

Don't trust any of them. Ditch your mobile or make sure battery is removable.
Don't have anything mobile-enabled in your PC. Just avoid wireless in general
unless its infrared. Even then it needs to be off by default.

------
aninteger
So what are the tools and knowledge required for one to tinker hardware enough
to understand and build security for smart phones?

------
miguelrochefort
What does one need a secure smartphone for?

------
digi_owl
Between -sec, cloudcuckoolander designers, and architecture astronauts it
feels like all the fun has vanished from tech.

------
monochromatic
Why is it that the baseband has full access to main memory?

~~~
Sanddancer
Because most chips and peripherals that work at a decently high speed on any
computer use DMA. A parallel port on a computer, a thunderbolt connector,
Ethernet cards, etc all use DMA for similar desires to speed up communication,
and all can have the potential to be attacked. In order for a phone to give
decent performance, DMA becomes more and more of a necessity.

