Steps toward a privacy-preserving phone

October 5, 2017

This article was contributed by Andy Oram

What kind of cell phone would emerge from a concerted effort to design privacy in from the beginning, using free software as much as possible? Some answers are provided by a crowdfunding campaign launched in August by Purism SPC, which has used two such campaigns successfully in the past to build a business around secure laptops. The Librem 5, with a five-inch screen and radio chip for communicating with cell phone companies, represents Purism's hope to bring the same privacy-enhancing vision to the mobile space, which is much more demanding in its threats, technology components, and user experience.

The abuse of mobile phone data has become a matter of worldwide concern. The capture and sale of personal data by apps is so notorious that it has been covered in USA Today; concerns over snooping contribute to the appeal of WhatsApp (which has topped 1.3 billion users) and other encrypted and privacy-conscious apps. But apps are only one attack vector. I got in touch with Todd Weaver, founder and CEO of Purism, to find out what the company is doing to plug the leaks in mobile devices.

Many free operating systems have been developed for mobile devices; the best-known is probably the Ubuntu phone, which never really got off the ground. A combined approach with both hardware and software to maximize security, however, is a new idea. Purism is built on a philosophy of protecting its users, and has registered as a social purpose corporation to emphasize its commitment to benefiting customers. Although less than three weeks are left in the Librem 5 campaign, Weaver is confident that it will reach its goal. The company also recently announced that it will port the KDE Plasma framework to the phone, in addition to its support for GTK+ and GNOME.

The design principles for the Librem 5 provide a valuable model for building privacy by design into devices. This article looks at the various levels of privacy protection, from bottom to top.

Hardware protections

Weaver explained to me that the radio components with which current phones communicate to the baseband provider (AT&T, for instance) share a chip with the phone's CPU. This gives complete access to everything the user does on the phone to the mobile provider—and to anyone else who gets access to its chip, whether government agents with warrants or malicious intruders.

We don't know whether baseband providers exploit the unprecedented access they have over user's private data, but Weaver plans on offering more peace of mind by separating the CPU running apps from the CPU that communicates with the baseband provider. Thus, the provider has no access to app data unless the data is transmitted unencrypted. Interestingly, this architectural choice hearkens back to early cell phones, which also ran the apps and baseband on separate CPUs.

Numerous reports describe malware that secretly records user activity from the device's camera or GPS. There is little one can do to protect against such attacks on current devices. Some laptops contain physical, hardware switches that allow the user to turn off WiFi, but they are becoming less common. And even the laptops that offer such switches do a halfhearted job of disabling the device, simply setting a standard software bit that disables the connection between the WiFi device and the PCI bus. A malicious app might be able to turn access back on. In fact, a simple software bug can leave the hardware capabilities vulnerable.

Purism plans to add three or four physical kill switches to the side of the Librem 5 phone. The architecture envisioned by Weaver is simple: the switches will cut power to the devices, making it look as if the devices don't exist at all. No software can turn the device on once the user sets the switch. The user can verify this because the device disappears from the output of commands such as lspci and lsusb. There will be one switch to turn off WiFi and Bluetooth, another for the radio to the baseband provider, and a third for the camera. The camera switch is particularly useful on a mobile device because few people want to put tape over their cameras on such devices. A possible fourth switch will turn off GPS.

Purism will offer a high-resolution photo of the Librem 5 motherboard, so that a user can compare it to the motherboard in their device and catch attacks where someone substitutes a different motherboard. Although the Librem 5 is not open hardware, Purism may open the schematics of older models at some point.

Trusted systems are a double-edged sword, widely distrusted in the free software community because of their potential for heavy-handed copyright restrictions and disabling access to software that the manufacturer wants to suppress for any reason. Yet free software advocates understand that in the right hands, trusted systems offer protection from malicious apps. A Trusted Platform Module (TPM) is not part of Purism's current initiative, but it plans to support TPM in the future, while putting control over keys in the hands of the user.

Software protections

Purism's operating system, called PureOS, will be based on the Debian distribution. Purism staff (which contains several Debian developers) will keep PureOS in sync with future releases of Debian. If the company makes any enhancements to the Linux kernel or the Debian distribution that would be of value to the community, Purism will contribute them back upstream. Except for WiFi and Bluetooth, which may require a binary driver for the form factor of the Librem 5 phone, Purism plans to use free software for all the devices on the phone. The company may also be able to reverse-engineer and free some drivers or firmware, as it did for its laptops.

Purism handles data security by making sure to store data in an encrypted format. For all communications, including phone calls, it provides the popular free Matrix software. Any two correspondents who use Matrix-based applications, such as the Riot chat tool, have strong privacy guarantees. These applications can recognize when you are communicating with a correspondent who doesn't use Matrix, and fall back on communicating in the clear. So you can still call a friend or company who doesn't have a secure client; you just don't get the protection of encryption. The Librem 5 could also potentially join a mesh network of secure devices that communicate without the need for centralized, proprietary network providers.

Although operating systems enforce isolation between processes, graphical user interfaces (GUIs) tend to be more lax, including that artifact of the permissive 1980s, the X Window System. One X client can easily view data passed to others. The free-software community, including GNOME and KDE, is therefore moving to a more secure display manager called Wayland, which is more careful to check which window is meant to receive input and to ensure that the input goes only to that window. Practically speaking, app isolation means that an exploit in an app cannot compromise other apps. Thanks to Wayland, isolation is the default on the Librem 5.

Business model

Although Purism uses crowdfunding campaigns for major new ventures such as the Librem 5, it has developed a robust business plan that supports the continued maintenance and development of software through the sales of its hardware along with some angel investment (often from its own customers). The company is three years old and gives back money to important middleware components like GNOME as well as to app developers for apps requested by users.

Purism will set up its own software store, offering free software apps that have been vetted to ensure they uphold the company's commitment to privacy. Other app developers can offer apps outside the store, and users will still benefit from app isolation and the other protections in the Librem 5. There is a precedent for a secure app store in CopperheadOS, but it is based on Android, which does not contain the same protections that Purism plans to build into the Librem 5.

I asked Weaver whether he is worried about government interference. He pointed out that competing forces pull both governments and corporations in different directions: while some actors want to snoop on the public, others recognize the need to protect their own communications and the value of being part of a community that protects its data. It's worth remembering the role the Navy played, for instance, in the development of the Tor onion routing network—the Navy didn't create Tor, as is sometimes claimed, but did offer funding. Weaver is already working with sympathetic government agencies that want his equipment. We can expect a secure phone to be greeted enthusiastically from many quarters.

Index entries for this article
Security	Privacy
GuestArticles	Oram, Andy

to post comments

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 3:57 UTC (Fri) by eru (subscriber, #2753) [Link] (8 responses)

There will be one switch to turn off WiFi and Bluetooth,

Wouldn't it make sense to separate these? One might want to turn off Wifi, but still use a Bluetooth headset, for example.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 10:50 UTC (Fri) by danielthompson (subscriber, #97243) [Link] (6 responses)

In mobile BT and WiFi are often implemented by the same device. It would not normally be possible to remove power from one without the other.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 15:09 UTC (Fri) by jhoblitt (subscriber, #77733) [Link] (5 responses)

It seems like a kill switch for the mic would be useful. The camera is often obscured by a pants pocket, purse, or the surface the phone is resting on. The mic can almost always collect personal information.

Steps toward a privacy-preserving phone

Posted Oct 7, 2017 0:48 UTC (Sat) by rahvin (guest, #16953) [Link] (4 responses)

Even if it was in a pants pocket you have to wonder what a camera could still capture. Although in a camera we use them to capture visible light the full capabilities of the sensor if you can utilize raw sensor output might make the camera useful even if it's obscured from visible light.

It's kinda like the Microphone being able to be used for far more than just listening. It should be possible with a phone/laptop with more than one microphone to use the phone to actually map areas just like a bat uses sound waves to navigate. And software already exists to use a mic and speakers to transmit data outside the range of human hearing. Being able to cut power to these devices allows you to ensure the listening device in your pocket isn't actually listening and potentially doing far more than just listening. We have literally no idea how some of these sensors could be used by someone with the know how and backing to exploit them maliciously. Keep in mind just because sensor has ability X doesn't mean it doesn't have ability Y that no ones exploited.

IMO the ideal device with privacy in mind would allow you to sever power to all the sensors and data broadcast devices with a special hardware switch. Because the only way to be sure it to make sure they don't have power.

Steps toward a privacy-preserving phone

Posted Oct 7, 2017 0:58 UTC (Sat) by jhoblitt (subscriber, #77733) [Link]

Silicon is opaque above 1 micron and completely transparent below something like 300nm. CMOS/CCD detectors can not see through tight woven cloth made out of common textile materials.

Steps toward a privacy-preserving phone

Posted Oct 7, 2017 10:17 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

I guess the most similar concern is that cameras can capture IR light as well as visible light. Standard phone cameras have a physical IR filter to try to eliminate that, though they can still pick up IR LEDs in e.g. TV remote controls. Cameras designed for night vision remove the IR filter so they can see in an invisibly-illuminated room.

If there is no light, I suppose you could maybe still use the camera to detect its own temperature - you'll get a load of noise on the sensor, and the amplitude of that noise is related to temperature. But I don't see how it's physically possible for them to detect anything else significant. There's nothing particularly special in the raw sensor output that gets hidden in the visible JPEG output, it's just a slightly higher-precision (maybe 10-bit) RGB image with more noise and terrible distortion.

> IMO the ideal device with privacy in mind would allow you to sever power to all the sensors

What would be included in "all the sensors"? The accelerometer that lets it automatically switch between portrait and landscape mode (but could also be used to track your movement with dead reckoning)? The ambient light sensor that adjusts the screen brightness to be more comfortable (but could detect whether you're indoors, outdoors, driving through tunnels, etc)? The temperature sensors that are used to throttle the chips before they melt (but could detect the ambient temperatures of indoors, outdoors, etc)? It seems the only thorough privacy-minded way to use a phone is to turn it off entirely and take the battery out.

Steps toward a privacy-preserving phone

Posted Oct 9, 2017 11:24 UTC (Mon) by erwaelde (subscriber, #34976) [Link]

Hello,

> It seems the only thorough privacy-minded way to use a phone is to turn it off entirely and take the battery out.

This is exactly, what I do! I can afford to be offline, which is probably difficult for most. Good thing is the battery lasts for weeks. Bad thing is the cap for the RTC does not last that long, funny time stamps entail.

Cheers,
Erich

Steps toward a privacy-preserving phone

Posted Oct 8, 2017 3:18 UTC (Sun) by thestinger (guest, #91827) [Link]

> It's kinda like the Microphone being able to be used for far more than just listening.

There are also other components like the accelerometer/gyrometer usable as a microphone.

The accelerometer/gyrometer + magnetometer can be used for location tracking.

As you've described, anything able to receive communications from outside (microphone, WiFi, Bluetooth, NFC, Cellular) can potentially be used for location detection. In practice, WiFi, Bluetooth, Cellular and the microphone *are* used for location because GPS can take time to lock on and doesn't work well indoors. Those other mechanism are used to help get an initial location lock faster and for indoor location detection. Indoor location dtection already uses techniques like exactly what you're describing: broadcasting inaudible sound that devices are able to pick up to locate themselves indoors.

Steps toward a privacy-preserving phone

Posted Oct 8, 2017 3:12 UTC (Sun) by daurnimator (guest, #92358) [Link]

Wifi and bluetooth are often done by the same (closed source) chip.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 4:33 UTC (Fri) by pabs (subscriber, #43278) [Link] (1 responses)

Those baseband protections don't sound like they go far enough, what the Neo900 project has is far better.

https://neo900.org/

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 4:56 UTC (Fri) by jukk (guest, #90142) [Link]

What is the difference? Both are going to use an external modem. Besides, Neo900 is an old concept, still on paper.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 15:24 UTC (Fri) by jhoblitt (subscriber, #77733) [Link] (24 responses)

What reasons are there for believing an upstart will be successful with a new Linux based mobile OS? At least OpenMoko, Nokia/Intel, Samsung, Mozilla, and Canonical have tried to do this without any traction. Jolla/sailfish (from the ashes of Nokia/Intel/Samsung) seems to have had a small amount of success. Amazon has probably gotten the most traction but I believe it has stayed very close to AOSP. In the meantime, blackberry os / blackberry os 10, and windows phone have fadded away.

Even if you claim to only want a phone, and don't care about an app ecosystem, you probably want the vendor to be successful enough that you can buy replacement / upgraded hardware in the future.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 15:48 UTC (Fri) by halla (subscriber, #14185) [Link] (9 responses)

While it's of course very satisfying and especially easy to play the cassandra and predict doom, building a free and trusted phone is something we as a community just never, ever should give up on. If we fail, we must try again. If we fail again, we must try again. And if we fail once more, we must try once again. Because to stop trying is to accept being chained and exploited.

I've worked on Maemo, MeeGo, Sailfish and Plasma Phone. I'm using an Android phone now, but Purism has my support, and I've pledged my 600 dollars.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 16:05 UTC (Fri) by excors (subscriber, #95769) [Link] (2 responses)

> If we fail, we must try again. If we fail again, we must try again.

To avoid following the definition of insanity, it seems important to learn lessons from the failures so we can do better next time. What lessons has Purism learnt from all the earlier attempts?

(I don't mean to imply it hasn't; I just don't see a clear answer in this article or the crowdfunding page.)

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 19:54 UTC (Fri) by halla (subscriber, #14185) [Link]

I don't care about insanity, though, of course, it is clear to event the meanest intelligence that every attempt until now has been different, but in this case, the progenitors start out with the hardware, and go from there, while previously, Nokia et al started out from their well-known and important positions... I once trusted Nokia, and took Jolla's money, but this time I promised purism my money.

Steps toward a privacy-preserving phone

Posted Oct 18, 2017 13:39 UTC (Wed) by cyphar (subscriber, #110703) [Link]

> What lessons has Purism learnt from all the earlier attempts?

It will support a variety of stock GNU/Linux distributions, as first-class citizens. This is something that I believe no other such attempt has done. The benefit is that someone who doesn't like $DISTRO could still want to purchase Purism's phone. For example, I've backed the project, but I have no intention of running PureOS on the phone for an extended period of time. I also think they've done a pretty good job with picking hardware *specifically* for the freedom aspects, something they didn't do with their first set of laptops.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 16:10 UTC (Fri) by jhoblitt (subscriber, #77733) [Link] (4 responses)

When multiple previous projects have failed, it is completely rational to ask why a new project with the same goals is going too have a different result. What is materially different about this project or the market conditions that give it a high probability of success? Those are not questions that can be trivially dismissed as "defeatist thinking" just because someone hopes and dreams that a project will succeed. To do so "is doing the same thing over and over and expecting different results".

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 19:51 UTC (Fri) by halla (subscriber, #14185) [Link]

Nokia failed because it was internally divided; not because it did not have a chance in the market. I still remember sitting there in Helsinki, seeing the flabbergasted faces of my Nokia colleagues watching the Nokia N8 being released using _symbian_. Nokia's first meego phone was, in fact, a big success, but Nokia decided not to sell it. It then further failed because it was apparent it was divided, so Microsoft muscled in to save their stock value by removing an important competitor.

Canonical failed because, to be frank, the people managing Ubuntu Phone were idiots. From Mir to Unity 8, everything they did was ghastly. With the right people, they could have gone to market years earlier.

Plasma Phone hasn't failed, because it still exists, and wasn't dependent upon external adulation anyway.

Sailfish still exists, so it hasn't failed yet.

But, then, if you cannot perceive the difference in approach towards a free software phone between nokia, intel, canonical, jolla, plasma or purism, you're blind. Every contender has approached the issue from a different perspective. But outside the free software community you won't find the fixity of purpose behind Plasma, which has zeroed in on convergence since the oughties.

And then... If the purism campaign works, and they ship me a phone that works according to their specs, I'll be glad, even if they go broke after that. I'll have a device I can use without being a product, again.

Steps toward a privacy-preserving phone

Posted Oct 7, 2017 7:55 UTC (Sat) by jukk (guest, #90142) [Link] (2 responses)

What is materially different? It would be the first phone ever to run on the vanilla linux kernel and a GNU software stack, just like our PCs has done for 25 years. And someone doesn't see the difference or benefits?

Steps toward a privacy-preserving phone

Posted Oct 8, 2017 5:50 UTC (Sun) by pabs (subscriber, #43278) [Link] (1 responses)

There are other devices that can run Linux mainline, the Nokia N900 for example.

Steps toward a privacy-preserving phone

Posted Oct 8, 2017 13:10 UTC (Sun) by jukk (guest, #90142) [Link]

I do have an N900 that I don't use anymore. It wasn't designed as a GNU device with mainline kernel. It wasn't until recently when it was able to boot a vanilla kernel. It is already way too old to use. Open almost any web page and it is choking. But it is true that it was probably closest to a "free phone" so far.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 21:55 UTC (Fri) by drag (guest, #31333) [Link]

> building a free and trusted phone is something we as a community just never, ever should give up on.

The threat to privacy on phones is not the OS itself, but the various proprietary add-ons (Gapps) that extend the OS, proprietary Vendor-specific extensions, proprietary drivers, black box radio equipment with it's own embedded OS and other bits and pieces that can be embedded in proprietary hardware and firmware.

Thus the most critical problem to tackle at this point is the hardware. Having the phone itself be as open source as possible with the legally mandated (whether through IP or FCC/etc) black box portions being separated out with physical switches to disconnect them is a terrific step in the right direction.

The next most critical part is to get the OS up to the point were it can be a usable smart phone OS with open drivers and necessary application support. The replacement for proprietary extensions and drivers need to be improved/written and application stores and development support and documentation needs to be sorted out. If you start off with Android you are already 95% the way there. People could have a really viable and useful platform in a few months. If you start off with a custom OS based on Debian it's going to take a few years.

I am certainly not against people making their own custom OS. I think it's a worthy project and probably can be very rewarding. It just depends on what your goals are. That's all. The lessons people need to learn if they are aiming for something for a wider audience are the same ones that Microsoft, Nokia, Samsung, Blackberry, and many others have learned: If you try to compete against Android then you lose.

I will probably buy a Purism phone, but I'll be running Android on it. Google-free.

Steps toward a privacy-preserving phone

Posted Oct 7, 2017 14:33 UTC (Sat) by debacle (subscriber, #7114) [Link] (11 responses)

What I like about Purisms approach, is that they *not* try to build a new mobile operating system, but use an "universal operating system" (so Debian calls itself) plus GNOME and/or KDE and only change what is absolutely necessary for the mobile use case. That's why they got my support.

I used to have an Android phone (of course, CyanogenMod, only free apps from F-Droid.org, no proprietary stuff added), but it never convinced me much. The idea of "apps" without proper dependencies is just not my cup of coffee.

Steps toward a privacy-preserving phone

Posted Oct 7, 2017 23:12 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

In other words, they are trying to build a new mobile operating system.

A practical approach would be getting the existing popular mobile OS available as open source and just build a good hardware for it.

Steps toward a privacy-preserving phone

Posted Oct 8, 2017 1:11 UTC (Sun) by debacle (subscriber, #7114) [Link] (8 responses)

We will see, how much of a new OS this will be. I'm already happy, if I can "apt install" from a standard Debian repo. When I last used it, Android had only few apps, maybe around 2000 in F-Droid.org, compared to 40000 or so packages in Debian. (Not talking about non-free, where Android might have more, but that is not relevant to me.)

Yet another Android telephone does not make much sense, IMHO. If I were interested in using Android I would probably buy a Fairphone 2.

Steps toward a privacy-preserving phone

Posted Oct 8, 2017 1:15 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

Let's be honest, how many of those 40,000 Debian packages are usable with only a touch screen?

Don't underestimate the amount of work needed; by starting with Debian instead of AOSP (which is entirely Free Software!) they are forced to reinvent many unnecessary wheels.

AOSP technically free

Posted Oct 9, 2017 10:53 UTC (Mon) by gmatht (subscriber, #58961) [Link]

I understand that Google has made AOSP free, you aren't allowed to distribute both a fork of AOSP and Android, and manufacturers wouldn't want to lose the right to distribute Android.

I am not sure that they care about that though, because I am not sure the goal is to have major manufactures ship with Librum installed.

Steps toward a privacy-preserving phone

Posted Oct 8, 2017 3:13 UTC (Sun) by thestinger (guest, #91827) [Link] (5 responses)

Self-contained GUI applications aren't comparable to Debian packages. The number of apps available via F-Droid is comparable to the number of apps available via GNOME Software, not lower-level libraries and other packages. Those aren't listed separately in F-Droid since they're shipped with the apps. Android is also already a standalone user-facing operating system with most of the dependencies used by those apps included in the base OS. It's broken up into pieces but they're guaranteed to be there and are updated together.

There are also many popular open-source Android apps like Signal and maps.me not packaged by F-Droid too. It doesn't reflect the number of open source Android apps that are available because F-Droid isn't the primary distribution method for open source Android apps.

Termux is available via F-Droid and provides a command-line environment with apt and a package repository: https://github.com/termux/termux-packages/tree/master/pac.... Those packages along with all of the internal dependencies of Termux are a single app in F-Droid.

Steps toward a privacy-preserving phone

Posted Oct 11, 2017 14:58 UTC (Wed) by johan (guest, #112044) [Link] (4 responses)

Maybe Termux allows you to install packages on your phone, but nowadays you can do that on Windows as well.
Android isn't hacker friendly and without GApps you lose core functionality of the phone. It might be open source, but they definitely don't encourage external patches and work behind borders, that's the core issue.

Steps toward a privacy-preserving phone

Posted Oct 11, 2017 16:05 UTC (Wed) by thestinger (guest, #91827) [Link] (2 responses)

> without GApps you lose core functionality of the phone

Android works well without Google Play Services. Core functionality isn't missing. Google services are missing.

Even many popular proprietary apps like WhatsApp still work well. Some apps choose to have hard dependencies on Google services like Google Cloud Messaging which https://microg.org provides.

Steps toward a privacy-preserving phone

Posted Oct 13, 2017 14:02 UTC (Fri) by roblabla (guest, #117734) [Link] (1 responses)

You do lose core functionality, such as push messages. I understand that those are google services, but they're still seen as core functionality by most people.

Steps toward a privacy-preserving phone

Posted Oct 13, 2017 16:41 UTC (Fri) by thestinger (guest, #91827) [Link]

GCM doesn't do anything magical that can't be done by apps on their own or via another central push messaging app. Signal, Conversations, Wire, WhatsApp and other apps implement their own push messages when GCM isn't present. They keep open a TCP connection and push messages through it with occasional polling to make sure the connection hasn't died just like GCM. They just need to run a foreground service and request a battery optimization exception.

It's not as efficient as having a central app doing it but it does work and isn't a missing feature. It's true that there are many apps have a hard dependency on Play Services for push messaging via GCM but it's not true that the functionality is lost.

Steps toward a privacy-preserving phone

Posted Oct 11, 2017 16:15 UTC (Wed) by thestinger (guest, #91827) [Link]

> It might be open source, but they definitely don't encourage external patches and work behind borders, that's the core issue.

I've been much more successful at landing patches in AOSP than the Linux kernel mostly thanks to it using Gerrit which keeps patches from falling through the cracks as easily as mailing lists. Lots of AOSP is developed in the open which makes it easy to submit patches to those areas.

Some major application-layer portions of the code aren't developed in the open. It varies by project. For example, telephony and the dialer recently moved to development in the AOSP master branch: https://android.googlesource.com/platform/packages/apps/D... https://android.googlesource.com/platform/frameworks/opt/... https://android.googlesource.com/platform/packages/servic....

Projects being open source doesn't imply that the developers use public version control for their development branches. It's something that applies to a lot of the traditional software stack on Linux too, especially older projects. Releasing tarballs for each version is less open development than AOSP where at least the full version control history becomes public for every stable release.

Steps toward a privacy-preserving phone

Posted Oct 11, 2017 15:01 UTC (Wed) by johan (guest, #112044) [Link]

Saying that they are trying to build a new mobile operating system is excessive,
they are rather trying to extend a desktop operating system to mobile.

Steps toward a privacy-preserving phone

Posted Oct 9, 2017 8:03 UTC (Mon) by madhatter (subscriber, #4665) [Link]

> OpenMoko [...] tried to do this without any traction

I don't think that's entirely fair. I used a Neo FreeRunner as my main GSM phone for two years, during which time it did everything I wanted of it, and not a few things I didn't even know I wanted until I discovered I could do them. It didn't sell two billion units and take over half the mobile telephony world, it's true, but if that's your definition of success then nearly nothing will reach it.

> Even if you claim to only want a phone [...] you probably want the vendor to be successful enough that you can buy replacement / upgraded hardware in the future

It wouldn't hurt, but it's not my main criterion. Primarily, when I buy computer hardware of any kind, I want it to do what it says it will do for the period when I wish to use it to do those things; success is primarily measured not in global reputation or long-lasting effect on a marketplace but in reliable functionality. I accept your criteria may be different, but not everyone judges success the same way.

Steps toward a privacy-preserving phone

Posted Oct 11, 2017 6:51 UTC (Wed) by spaetz (guest, #32870) [Link]

> At least OpenMoko, Nokia/Intel, Samsung, Mozilla, and Canonical have tried to do this without any traction.

I agree that lessons learned and plans to do things better should.be taken into account.
I would not say those previous attempts were without traction. Nokia & OpenMoko have started something that culminated in Meego and improvements to Openembedded, it resulted in the creation of phone stacks ( e.g. ofono ) and allowed.developers to gain experience with all the elements of a mobile stack.
All this helped to prepare free software components to deal a bit better with the challenges. Will it ever get traction as in markets share? Heck no, I realize that. They still got my money.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 15:54 UTC (Fri) by excors (subscriber, #95769) [Link] (2 responses)

> Weaver explained to me that the radio components with which current phones communicate to the baseband provider (AT&T, for instance) share a chip with the phone's CPU.

I don't think that's generally true - e.g. the iPhone 8 has the main Apple-designed SoC and the Qualcomm LTE modem in completely separate chips (which is kind of necessary when they're manufactured by different companies), and plenty of Android phones do the same. Integrated is usually cheaper, though.

Being on the same physical chip doesn't inherently impact security. I think the problem is more when they share access to the same memory bus and RAM (which integrated ones usually do, because it's cheaper), often with no or inadequate memory protection, so code running on the modem's programmable processors can happily read and write any data that is owned by the Linux running on the main CPU. (As can any code running on the GPU, or on the power management core, or on any of the other tiny processors littered around the chip.)

You should be able to use some kind of IOMMU to enforce isolation between different parts of the chip, though you have to be very careful about trusting the software that configures the IOMMU and it's hard to detect if it's configured wrong.

I don't know how discrete modem chips are usually connected - I guess USB or PCIe or something, which isn't necessarily much more secure (PCIe devices can do DMA and will still need IOMMU protection, USB devices can pretend to be keyboards and type things in, etc). And there's a significant chance of vulnerabilities in the (complex, optimised-for-speed, written-by-people-for-whom-security-is-not-a-top-concern) drivers implementing the communication protocol between the CPU and modem. It seems a more complicated problem than simply integrated vs discrete.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 16:15 UTC (Fri) by jhoblitt (subscriber, #77733) [Link]

I don't think IOMMU configuration is sufficient as it doesn't prevent direct PCI<->PCI device communication. Hardware support for PCI ACS is needed (and requires configuration).

Separating the RF part also in Fairphones?

Posted Oct 12, 2017 9:35 UTC (Thu) by Herve5 (guest, #115399) [Link]

To my knowledge, the modularity of Fairphones model 2 also separates the RF part from the main chip.
And while their baseline version is with Android OS, there is an option to get Jolla's Sailfish OS on them (where the user is root of the system).
To me this means we get reasonable control, while the OS and hardware remain closed source. (and, probably, most of you will find Jolla apps are... very few)
I recognize I do look terrible to my friends that just want pure linux control on the phone, but if I was rich enough, I'd presently have a Fairphone 2, which is available now, and in Europe also directly through the (potentially subsidized) main GSM companies.
-disclaimer : I have the previous, Fairphone 1 model...
H.

Steps toward a privacy-preserving phone

Posted Oct 6, 2017 21:50 UTC (Fri) by thestinger (guest, #91827) [Link] (2 responses)

> Weaver explained to me that the radio components with which current phones communicate to the baseband provider (AT&T, for instance) share a chip with the phone's CPU.

Sharing a chip doesn't mean it has control over everything else, just as not sharing a chip doesn't mean it's properly isolated. This comes down to how the IOMMU and the rest of the hardware / firmware / software is implemented. Wi-Fi is still almost always on a separate chip and yet unlike the baseband it usually has full access to the system's memory. The baseband is usually contained. They're really getting it backwards from the current reality. SoC components are well isolated because Qualcomm does a good job on that front while non-SoC peripherals are generally poorly isolated because the peripheral and device vendors don't put in the same effort. Those peripherals like Wi-Fi are also usually many years behind on exploit mitigations and other basic security precautions.

> This gives complete access to everything the user does on the phone to the mobile provider—and to anyone else who gets access to its chip, whether government agents with warrants or malicious intruders.

This isn't true. The mobile provider doesn't have code execution on the baseband. It's not running their code but rather the signed firmware on the device.

A baseband separate from the CPU can easily be less secure against exploitation while having more control over the system. Both of those are likely if using a non-mainstream baseband from a vendor that isn't investing heavily in security. It could very well be a case where a weakness is being portrayed as a strength.

> There is a precedent for a secure app store in CopperheadOS, but it is based on Android, which does not contain the same protections that Purism plans to build into the Librem 5.

CopperheadOS will be able to run on the Librem 5 if it actually comes to fruition. Hardware security features are orthogonal to the operating system chosen to run on top of it. It doesn't make sense to treat them as exclusive things. The desktop Linux stack is a straggler when it comes to privacy and especially security. The Android Open Source project is very far ahead on those fronts even before any CopperheadOS changes are considered. If the desktop Linux stack used on Ubuntu Touch, etc. was a better starting point it would be the basis of CopperheadOS instead of starting from AOSP.

The Librem 5 would only be considered as a target for CopperheadOS if it provides comparable security to other devices which includes full verified boot, comparable firmware security and proper scanning MAC randomization support where probe sequence numbers and other identifiers are anonymized.

Hardware kill switches could be a nice step forward, but they need to be thought out well. For example, there's point in disabling the GPS while still having location tracking via many other means (Wi-Fi, cellular data, Bluetooth, microphone, accelerometer). A kill switch for the microphone also needs to be done alongside making sure the speaker and other components cannot be used to record audio. A radio kill switch needs to have a clear purpose / defined threat model and needs to actually kill all the radios to be useful.

Steps toward a privacy-preserving phone

Posted Oct 9, 2017 7:04 UTC (Mon) by mjthayer (guest, #39183) [Link] (1 responses)

> Those peripherals like Wi-Fi are also usually many years behind on exploit mitigations and other basic security precautions.

How realistic would software Wi-Fi and Bluetooth stacks be with a reasonably simple and generic emitter/receiver? I assume that it would also need some sort of hardware filtering for regulatory reasons.

Steps toward a privacy-preserving phone

Posted Oct 9, 2017 7:57 UTC (Mon) by smurf (subscriber, #17840) [Link]

You have to meet a couple of strict realtime requirements, so you'd need multi-core CPU with a dedicated processor, or a realtime kernel below Linux. Somebody more familiar with the actual specs can probably say whether that'd be sufficient.

Steps toward a privacy-preserving phone

Posted Oct 7, 2017 22:33 UTC (Sat) by wack (guest, #118741) [Link] (2 responses)

I wonder how realistic it would be to run a Qubes type operating system on a modern phone platform.

Steps toward a privacy-preserving phone

Posted Oct 8, 2017 3:25 UTC (Sun) by thestinger (guest, #91827) [Link]

Modern smartphone hardware supports virtualization and IOMMUs. However, QubesOS does a lot of work in terms of plumbing and user interfaces to tie everything together. It's a lot more than just Xen and some Linux distributions. It would a huge amount of work to support smartphones. There's less existing support for seamless virtualization to build upon.

There are smartphones shipping with virtualization in use. Samsung uses it for Knox kernel self-protection, i.e. not to run separate operating systems in virtual machines, but to supervise some aspects of the kernel as an exploit mitigation.

Steps toward a privacy-preserving phone

Posted Oct 8, 2017 5:43 UTC (Sun) by pabs (subscriber, #43278) [Link]

Seems unlikely you would have enough RAM to run Qubes, I hear it is quite demanding.

Steps toward a privacy-preserving phone

Posted Oct 10, 2017 15:30 UTC (Tue) by halla (subscriber, #14185) [Link]

And they made their target :-)