Privacy is the ability of an individual or group to seclude themselves, or information about themselves, and thereby express themselves selectively. — Wikipedia
Privacy depends on controlling access to sensitive information. And anonymity plays a central role. It hinders information discovery, and reduces your exposure to coercion. You can express yourself more freely, with less concern about consequences. And it’s essential when you’re far weaker than your adversaries.
In the online context, privacy requires limiting communication to known and controllable channels. And it requires the compartmentalization of sensitive information. There are three key aspects:
- keeping information where it’s most readily protected
- keeping information where leaks would do the least damage
- segregating information that’s most dangerous when combined
However, sometimes information just can’t be protected. Devices can’t connect to networks without revealing something about their identity, and at least their approximate location. And when you’re online, you can’t do anything without revealing some information, even if it’s just the Tor exit that you’re using, or some resource that you’re accessing.
So consider an arguably perilous situation. You’ve become interesting in meatspace to local adversaries, and they are intercepting local traffic. And independently, your online activities have also become interesting to remote adversaries, and they are intercepting remote traffic. And while no association has been established, those adversaries do cooperate.
But even if you’re a target, you’ll be far safer if local adversaries can’t see communication content or metadata, and remote adversaries can’t see information about your identity or location. Indeed, in the absence of other evidence, and if all traffic is securely encrypted, the only things that connect local and remote events are when they occur, and what traffic patterns look like.
Given that, finding and confirming associations would require global scale traffic analysis. That is, adversaries would need to analyze all traffic data that they had intercepted, and look for matches based only on pattern and time. While that’s not impossible, it’s arguably a substantial investment for even such adversaries as the NSA. And so they wouldn’t do it for just anyone.
The saga of Ross Ulbricht, Silk Road’s DPR, is a sad counterexample. Although Silk Road was a Tor onion service, a web server misconfiguration leaked error messages through its public IPv4 address. Investigators more or less accidentally discovered that, and tracked down the server. And it wasn’t full-disk encrypted. Looking at log files, they discovered that he had managed the server from an IPv4 address in San Francisco. It was a coffee shop. And agents observed that he was often there, working online, when DPR was active on Silk Road. That wasn’t their only clue, but it did help focus their investigation on him.
It’s not hard to compartmentalize content and metadata from connection information. The first step is securing your Internet uplink. Basically, you just use separate devices, which are connected through a well-secured link. One device runs your apps and stores data. The other simply provides network connectivity. It’s typically a network router, and may contain a modem for translating (that is, modulating and demodulating) analog signals. It also helps to interpose a hardware firewall between the modem/router and your devices.
That’s not enough, however. Your ISP and other local adversaries can still see communication content and metadata, and remote adversaries can still see your ISP-assigned IP address. And while it’s true that end-to-end encryption will hide content, and some metadata, it won’t hide your IP address. For that, the options are VPNs, Tor and/or I2P. I’ll get into that in the next post.
But here, I’ll focus on uplink security. It’s a longstanding problem. The Internet developed in an environment where people trusted each other. So they didn’t bother securing computers and networks from each other. As the Internet went public, the foolishness of that assumption became increasingly clear.
For example, consider this amusing historical anecdote. In the early 00s, Windows PCs were often infected with malware soon after going online. On average, infection occurred within 20 minutes. And given low dial-up bandwidth, that wasn’t long enough to download and install updates and antivirus apps.
The immediate solution was Windows XP with SP2, which included Windows Firewall. But longer term, the decisive solution was switching from dial-up to broadband. Dial-up modems behaved much like network interfaces. So Windows resources (open ports) were readily discoverable and exploitable. But broadband routers do network address translation (NAT). So Windows resources were hidden from the Internet, unless open ports had been intentionally exposed (forwarded) through the router.
OK, now fast forward to 2015. In the process of exploring the vulnerability of modern motor vehicles to remote exploitation, Charlie Miller and Chris Valasek discovered something shocking:
It turns out that any Sprint device anywhere in the country can communicate with any other Sprint device anywhere in the country.
And no, they don’t mean by placing calls. They used a femtocell (miniature cell tower) that had been exploited to allow console (command line) access. In particular, a Sprint Airave. That gave them direct access to Sprint’s WAN. So then, just as with Windows PCs in the early 00s:
To find vulnerable vehicles you just need to scan on port 6667 from a Sprint device on the IP addresses 126.96.36.199/8 and 188.8.131.52/8.
But this isn’t likely limited to baseband radios of motor vehicles. If that’s so, adversaries could find open ports on smartphones and other devices with cellular connectivity. And they could likely exploit them, given that cellular baseband radios are reportedly not well secured. Also, given that baseband firmware is a closed-source blob, it’s basically impossible to fully assess the risks.
Just as with early Windows PCs, it seems that remote adversaries could compromise smartphones through the network. And so smartphones also ought to have external cellular modem/routers. As I’ll discuss below, that’s doable, but not easy.
In other words, there’s a boundary between what’s trusted and what’s untrusted. For old Windows or current smartphones, not even userland can be trusted. Having a separate modem moves the boundary out to the modem. And adding a firewall/router puts the boundary there, creating a DMZ between it and the modem.
Anyway, all common communication channels are at least somewhat vulnerable in one way or another:
- PCIe ports
- Ultra-Wideband (UWB)
Video and Audio
Using computers without video (or audio, if you’re blind) is problematic. And even if you’re not blind, listening to music, videos, podcasts, etc is pleasant and/or useful.
But there are risks. If you use VoIP and video chat, there’s the risk of voice and facial recognition. And there’s also the risk of surveillance, even when you’re not using the device. Indeed, audio can be exploited as a side channel to associate nearby devices, such as smart TVs, smartphones and other computers. And determined adversaries can even use outdoor video for geolocation.
So it’s crucial to manage the availability and activity of microphones, speakers and cameras. Most devices have software controls for them. But that’s not good enough, because apps can mess with them, especially in smartphones and tablets. And resourceful adversaries can turn on microphones and cameras remotely.
Various high-speed I/O ports connect through the PCI/PCIe bus. And the fastest ones can directly access RAM. While that’s often convenient, direct memory access (DMA) permits all sorts of exploits, such as reading cryptographic keys and executing arbitrary code.
You can’t just disable DMA, because so much depends on it. Modern CPUs do have an In/Out Memory Management Unit (IOMMU), such as Intel VT-d and AMD-Vi. But that doesn’t prevent DMA attacks, unless you’re running Qubes or other requisite software. Modern smartphones also have IOMMU, and it’s perhaps implemented more securely. However, there’s no guarantee that IOMMU on any platform can’t be hacked.
Most vulnerable are FireWire, ExpressCard, Thunderbolt and USB 3.1, which explicitly allow DMA. But older USB versions are also at least somewhat vulnerable:
In terms of paranoid security, 1.0 is not good, 2.0 is bad, and 3.0 is a nightmare.
To mitigate DMA risk, the best option is disabling all PCI/PCIe ports except USB, by disconnecting them internally and/or or filling sockets with non-conductive epoxy. And then lock down USB:
You can disable [USB 3.0] it in many BIOSes, usually under a name like “xHCI controller”. Doing this will effectively turn all 3.0 ports into 2.0 ports which decreases their speed, but it improves security a good bit.
Bluetooth and UWB
Bluetooth has long been used for short-range networking with peripherals. And it’s ubiquitous in modern vehicles. Although Ultra-Wideband (UWB) has been common for years in industrial environments, Apple recently introduced a version in the iPhone 11 for short-range data transfers.
It seems like magic for sure. But Bluetooth and UWB are both widely used for indoor tracking. That’s at least creepy, and potentially dangerous. So if you don’t need them, it’s best to turn them off.
Ethernet and WiFi
To network with each other, devices need connections. The safest option relies on physical connections, such as Ethernet or fiber. There is some risk of radio leakage from Ethernet switches, routers and wiring. However, that can be mitigated through shielding and grounding.
Conversely, WiFi is a mess.
Perhaps a decade or two ago, anonymously using open WiFi routers and access points (collectively “APs”) was edgy (as in “wardriving”). But it’s arguably become both pointless and extremely dangerous. It’s pointless because most APs are now encrypted. And even for public ones, it’s hard to obtain passwords anonymously. Also, using public APs is inconvenient, and it may attract attention. Especially if you use a given AP regularly. And if adversaries become interested in a given AP, they may surveil people who use it.
But now, using WiFi at all is extremely dangerous, because devices can geolocate themselves at GPS-level accuracy. This is an issue for all devices with WiFi, and not just smartphones and tablets. WiFi radios constantly scan for APs, and log what they find, in case the AP being used craps out. That happens automatically, and it’s hard to disable without totally disabling WiFi connectivity. And it happens even if all reachable APs are securely encrypted, with no actual connection possible. All it takes is scanning.
Various geolocation services maintain databases of WiFi APs, identified by their IDs, which have been geolocated by GPS/GNSS-capable devices that have scanned them. Google Street View vehicles do industrial scale passive wardriving, which is legal in the US. And now smartphone apps commonly report APs that they scan.
So even if a WiFi-capable device lacks GPS/GNSS, or that’s been turned off or disabled, it can geolocate itself at GPS accuracy, based on the WiFi APs that it scans. Most tablets and phones query remote databases for AP locations, and estimate their location. Although there are typically settings to restrict access to location data, those typically don’t apply to service providers (such as Google, Apple and wireless networks). And rogue apps may ignore those settings, obtain access, and share location data with their providers.
Just to be clear, this is about devices geolocating themselves, and not about malicious or compromised APs being used to track and geolocate devices. MAC spoofing can protect against malicious or compromised APs. But it won’t prevent devices from geolocating themselves, based on geolocated APs that have been scanned.
It’s extremely difficult to ensure that WiFi devices won’t geolocate themselves precisely. Even a laptop/notebook or desktop at home can do that, if necessary software has been installed, and there are geolocated APs nearby. And it’s not sufficient to use a well-secured and trusted WiFi router, with no other APs in range. That’s because your router can be geolocated if a GPS/GNSS-capable smartphone comes close enough to scan it. And if your router appears in an online database that your devices use, they can geolocate themselves precisely. It also doesn’t matter if the router is secured, and untrusted devices can’t actually connect to it. All it takes is scanning, which all WiFi devices do automatically.
But sometimes, WiFi is the only workable option. In that case, the safest option is to disable a device’s onboard WiFi, and use an external WiFi router. Both the Librem 5 and PinePhone have a hardware kill switch for WiFi. The router connects with APs, and provides Internet access to the device. That way, it’s the WiFi router that will geolocate itself, and you have a decent chance of preventing your device from learning its location.
It’s arguably safest to tether the WiFi router via Ethernet. But I’ll say more below about tethering, and interposing a hardware firewall. In order to configure the router and firewall properly, you’ll likely want to be running an open-source OS. And don’t just use a USB WiFi dongle. That merely adds an external WiFi network interface to the device. And it wouldn’t prevent the device from geolocating itself.
For additional protection, you could access public APs remotely, using a more powerful WiFi router and a parabolic antenna. And so even the WiFi router couldn’t geolocate itself (or be geolocated by APs) accurately. That could give you a few kilometers of location uncertainty. However, such setups are discoverable using radio direction finders, if that AP is flagged as interesting. And parabolic antennas are not so easy to hide.
To use the Internet, devices need uplinks through service providers (ISPs). Broadband uplinks commonly use ADSL, cable or fiber. ISPs can see all traffic, so privacy depends on end-to-end encryption. Also, without an intervening NAT router that you control, it’s possible that ISPs can access your LAN.
But even with just the ISP’s modem/router, you’re decently protected against remote adversaries. Routers can be hacked, of course, but at least remote adversaries don’t have direct access to your devices. And you can use hardware firewalls that are much harder to compromise.
Just about everyone who’s been paying attention knows that cellular voice and data are dangerous. That’s because devices can be located (albeit approximately) by triangulation from cell towers. I mean, it’s been a trope in fiction for decades. And it’s indeed unavoidable, if you want cellular connectivity. However, there’s no uncertainty about your location using broadband. So in either case, you just need to control remote access to that information.
Bottom line, cellular uplinks could potentially be no less secure than broadband via ADSL, cable or fiber. Currently, however, they’re almost certainly not, at least by default. It’s hard to be definitive, because the technology is complex, changing rapidly, and highly proprietary. And that fosters both complacency about security, and FUD about vulnerability.
OK, so radio links between devices and cell towers can be securely encrypted. That’s handled by the cellular baseband radio/modem. But with backward compatibility for old infrastructure, there’s no guarantee. And in any case, traffic on cellular WLANs is not encrypted by default. So adversaries with WLAN access can see all traffic, and privacy depends on end-to-end encryption. Bottom line, though, the situation isn’t hugely worse than with broadband.
It’s true that adversaries can access cellular WLAN using femtocells, or use StingRays to intercept cellular access by devices. But adversaries can also access broadband networks. So even there, it’s dangerous to trust anything outside the perimeter router.
What’s different with cellular connections is that the baseband radio/modem is part of the device, and there’s no intervening router. Also, baseband firmware is closed-source, and so its security is hard to assess. And given what we know, the baseband is likely vulnerable to attacks through cellular WLAN.
Given that, there’s the risk that an adversary will compromise the baseband, and then pivot from there to compromise the device’s main application processor (AP). And once the AP has been compromised, privacy and security are entirely toast. The adversary has full access, and end-to-end encryption is irrelevant.
But here’s where it really gets confusing. Perhaps a decade ago, cellular devices were totally insecure. The baseband and AP weren’t isolated, and the baseband was privileged over the AP.
Cellular devices are now more secure. But it’s complicated.
For Android devices, baseband and AP have become physically more integrated in large system on chip (SoC) integrated circuits, to reduce size and increase battery life. However, the new Snapdragon 865 SoC has a separate baseband chip, and it will likely dominate in the high-end Android market. But that apparently reflects problems with 5G integration. Recent iOS devices have had separate baseband chips, and that apparently reflects a licensing dispute with Qualcomm.
Given physical proximity of AP and baseband, crucial information (such as cryptographic keys) can passively leak through radio transmissions. But from what I’ve seen, that and other security issues apparently didn’t drive decisions to physically isolate the baseband.
However, both the Librem 5 and PinePhone have separate baseband chips. And there the driver was clearly increased security. Both have hardware kill switches for the cellular baseband, WiFi, GPS/GNSS, camera and microphone. And that wouldn’t be possible without physical isolation.
Anyway, regardless of physical layout, baseband and AP have become functionally more isolated. They’re now connected through a chip-to-chip version of USB (HSIC or the newer SSIC). And as with PCI/PCIe ports, IOMMU protects the AP from baseband. And to be clear, the AP now controls the IOMMU. In older SoCs, baseband controlled the IOMMU, and so was privileged over the AP.
So bottom line, the AP is now arguably much less vulnerable to pivoting through a compromised baseband. Indeed, the AP is perhaps as well isolated from baseband as it is from external PCI/PCIe ports. And it’s arguable that IOMMU is better implemented in modern mobile SoCs than typically in Intel and AMD CPUs. But the baseband remains vulnerable.
Also, there’s no guarantee that IOMMU can’t be compromised. And even if you trust IOMMU enough to use PCI/PCIe ports with DMA, the baseband is arguably far more exploitable. It’s still likely an insecure mess, and it’s clearly far more exposed. Only local adversaries with physical access can hack PCI/PCIe ports. But even remote adversaries can hack the baseband through the cellular network.
But here’s the bind. Even if you disable onboard baseband, and use a USB-tethered LTE modem for cellular connectivity, it’s still just IOMMU that isolates its baseband from the AP. IOMMU might protect device-to-device USB better than chip-to-chip USB, but I haven’t found any claims about that.
It would arguably be more secure to use an LTE modem that’s tethered via Ethernet. And given that, you could interpose a hardware firewall, such as a Raspberry Pi, just as for broadband. Although smartphones and tablets don’t have Ethernet ports, but there are USB-C to Ethernet dongles.
And just to be clear, using an Ethernet-tethered LTE modem, even with a hardware firewall, would not prevent adversaries from snooping unencrypted voice and SMS traffic on the cellular network. However, that’s no worse than the situation with broadband. In either case, privacy depends on using end-to-end encryption. The advantage would be isolation of the baseband and AP that’s comparable to well-secured broadband. That reduces the risk of compromise, and also of passive information leakage.
Virtually all smartphones and tablets now have GPS/GNSS. Devices geolocate themselves, based on radio transmissions from GPS/GNSS satellites. It’s entirely passive, relatively slow, and works best outdoors. But it works pretty much anywhere, as long as satellite transmissions aren’t blocked.
Mobile devices typically supplement GPS/GNSS using WiFi-based geolocation, through triangulation relative to geolocated APs. That depends on remote services, which collect data and make it available. They typically also rely on Bluetooth, UWB and RFID tags to further refine location. Altogether, devices may geolocate themselves with centimeter accuracy.
Both the Librem 5 and PinePhone have a hardware kill switch for GPS/GNSS. Many LTE modems include GPS/GNSS. However, if you tether via Ethernet, your device can’t access GPS/GNSS-based geolocation information from the modem. The IP address does convey some locational information, but that can be kept private.
Websites and apps can fingerprint Android and iOS devices using “data gathered from the accelerometer, gyroscope and magnetometer sensors”. To prevent that, it would be necessary to disable those sensors.
The Librem 5 has hardware kill switches for cellular modem, Wi-Fi, and microphones and cameras. And setting all three kill switches to “off” triggers “Lockdown Mode”, which cuts power to GPS/GNSS and all sensors. Although the PinePhone has hardware kill switches for cellular baseband and GPS/GNSS, Wi-Fi, microphones and cameras, I haven’t seen that there’s an option to disable sensors. However, given that it’s running some flavor of Linux, that’s likely doable (albeit not at hardware level).
No matter how your devices access the Internet, information about your identity and location is associated with the connection. The uplink (modem or router) and whatever it’s connecting to know something about each other. Also, adversaries can hack at the uplink. And if they compromise it, they can pivot to hacking at your devices.
It’s safest to use an external uplink, and interpose a hardware firewall between the uplink and your devices. Otherwise, there’s the risk that information about your identity and location will leak to remote adversaries. And without effective isolation, adversaries are less hindered from compromising your devices.
For those who care about security and privacy, that’s long been the standard setup for computers with broadband uplinks. But for whatever reason, cellular devices and networks are far less secure by default.
Even so, some seriously sophisticated stuff has been developed for smartphones. For example, there’s Signal. Its message encryption protocol is arguably entirely secure against any intervening adversary. However, by default it uses the phone’s number as account ID, for better reachability, and simpler phone upgrades.
For some, that’s a privacy vulnerability. But there’s an easy workaround. You can register any phone number with Signal, and all messages and calls will apparently come from that number. It needn’t be a mobile number, because Signal offers a voice call option for verification. And it can even be a payphone, although in that case you’d definitely want to set a 20-digit registration lock PIN to protect the account.
There’s also the long-awaited Orchid. It’s a P2P VPN network, where users buy bandwidth with supposedly anonymous Etherium-based cryptocurrency. And it enables dynamic multi-hop connectivity, somewhat analogous to Tor, with increased security through reputation-based route selection.
But the problem is that seeking anonymity on the smartphones and mobile devices that virtually everyone currently uses is arguably pointless, because they’re by default so insecure. At best, you have conditional anonymity, with faceless megacorps looking over your shoulder. The risk model is that third parties may know everything, but users can trust them, so there’s no problem.
Even so, it’s finally becoming possible to secure smartphones and mobile devices, using basically the standard setup for computers with broadband uplinks. And that’s good, because smartphones now account for well over half of Internet usage.
The best smartphone option at this point is running a mobile Linux distro on the Librem 5 or the PinePhone. Otherwise, you’re stuck with trusting iOS and Apple, or attempting to lock down an Android device. And it wouldn’t be enough to just root the device, and flash a secure version of Android. You’d need to dig into the hardware, and disable radios and sensors.
With either the Librem 5 or PinePhone, it would be safest to kill cellular baseband, WiFi, GPS/GNSS, microphones and cameras. You should also disable sensors, to avoid fingerprinting. Then you’d use either an external LTE modem or WiFi router, tethered via Ethernet. And just as with wired broadband, it’d be best to interpose a hardware router/firewall, to better secure the Ethernet link.
However, as mentioned above, that’s not enough. You must hide communication content and metadata from your ISP and other local adversaries. And you must also hide your ISP-assigned IP address from remote adversaries. For that, you can use some of the standard approaches for strong Internet anonymity, such as VPNs, Tor and/or I2P. I’ll cover that in the next post.
This post is part of the ongoing Advanced Privacy Guides series.