Here are some off-the-cuff thoughts on security features that are
available, and which I would like to see.
We need a superset of a subset of the union of the security features of
“mobile” platforms and “desktop” platforms. Although these are not
clearly-defined terms, I’ll try to roughly characterize them by naming
examples. Desktop platforms as of 2015 include:
Mac OS X
Desktop and server Linux and BSD distributions, e.g. FreeBSD,
The key differentiators between the 2 classes of platform are security
features and userland APIs. (And the hardware they run on.) Obviously, I’ll
focus on security features, and touch on userland APIs only insofar as they
Here are the security features of mobile platforms that I think we need
in all platforms going forward:
A 2-part principal: (user, source of code); the code source must be
cryptographically authenticated. For example, Android gives each package (or,
package signing key) its own Linux user ID, isolating it from other packages.
details.) iOS puts each app in a sandbox and isolates its storage; again all
code is signed. The open web uses the origin model, with optional
cryptographic code authentication (HTTPS).
Usable ways to share resources between 2-part principals (strongest on
Android; OK on iOS; rather ad hoc on the web). This is mostly a consequence
of the userland APIs that the platform makes available to applications;
Android is rich here.
Tamper-evident storage, verified at least on boot (“secure boot”, e.g. dm-verity).
Encrypted storage, preferably on by default, preferably
The integrity checking and the encryption should both be backed by hardware,
e.g. a TPM.
Privilege reduction, a way for userland programs to reduce their own access
to the kernel. ChromeOS, Mac OS X, iOS, and someday soon Android, have such
By contrast, there are security features desktop platforms have that
mobile platforms lack:
Considerably greater owner control over the device — debuggers, root and
ring 0 access, et c. “Digital rights management” seems to have caught on more
strongly on mobile platforms. ChromeOS
has a Developer Mode; I wish more closed platforms would follow suit.
Memory and CPU powerful enough to rebut the (usually, but not always,
mistaken) arguments against using type-safe or at least memory-safe code. Current
mobile devices are as powerful or moreso as desktop computers of a decade ago,
so we do technically have the horsepower to run e.g. Java, C#, F#, Haskell, et
c. in these devices. In fact, Android, iOS, and the web all make heavy use of
languages with expensive features like late binding, object orientation,
run-time type checking, interpreted non-native code, and so on. Yet it has
proven hard to actually use those expensive features for safety — people always
want to call into C/C++ code for “efficiency”, and then find out the hard way
how easy it is to write unsafe C/C++. Developers seem happy to traverse many
pointers to finally get to a callable method but are not happy to check the
bounds on arrays. Although unsafe code will always seem marginally faster than
safe code, at some point we have to draw the line: this is fast enough,
that is not safe enough.
Things we still need on both classes of platform, or which I’m not sure
we have yet:
attention sequence. iOS’ Home button might actually be one; I don’t know the
implementation. I am not certain if Control-Alt-Delete still is a SAS on Windows — please email me if you know more. SAS is a simple and powerful idea but it
depends crucially on implementation details that are hard to keep robust as
products change over time.
UI isolation: each application should only be able to “see” its own windows,
should be able to reliably know when they have the highest z-order, and should
be able to reliably know when input events are really coming from the user (via
the kernel). (See Design
Of The EROS Trusted Window System.) Android almost has this, at least last
time I looked. Windows are accessible only through a capability, but as of
Honeycomb (?) there can be windows that overlap and the active application is
not necessarily the highest in z-order. I could be wrong about that. I also
don’t know the iOS implementation; it may provide some or all of this. (Please
email me if you know more!)
A kernel with high (...or any) unit test coverage.
Safe, sane firmware written to semi-modern standards of code quality,
including open source solutions. There is CoreBoot, but as far as I know only ChromeOS
uses it and successors. Unfortunately I know nothing of iOS firmware.