Here's How They Built The Most Secure Phone On The Planet
This is a ransomware. It’s a malicious encryption tool that once loaded onto a computer, it infects all of the files the malware has access to. Criminals use ransomware to extort money out of unsuspecting victims. In 2017, the biggest ransomware worm spread through Europe like wildfire, infecting 70,000 Windows computers in just the first few hours. Within half a day, the ransomware spread to six continents. Wannacry was using a vulnerability inside a Windows SMB port to spread itself from network to network.
The ransomware used the vulnerability to infect new machines, but it didn’t need the vulnerability to encrypt an infected computer. Any execution of the ransomware file would result in a successful attack. Even on an offline device. And that is because the security model of a traditional operating system like Windows, Mac or Linux, runs in a default permissive mode. Generally, all execution and access is based on the permission of the logged in user.
Which means if you have access to all of your files, so does every app you install on your system. Windows was just unlucky in this particular instance. Because just a few months ago, a malicious hacker group called Shadow Brokers publicly revealed the Windows SMB vulnerability the Wannacry hackers later used for their exploit. The Windows vulnerability was just a vector for the ransomware to spread like a worm. If a ransomware attack was written for Mac or Linux, it would be just as successful at encrypting all of the files on infected machines. Malware on computer operating systems often times doesn’t need to exploit vulnerabilities or bypass the system’s security model.
In contrast, if the same ransomware was written for a mobile operating system like iOS or Android, it would only be able to encrypt itself. The rest of your files and app data would be completely safe. In order for a ransomware attack to achieve its goal on your phone, it would have to bypass the security model of the whole operating system. On an up-to-date modern Android or iOS, such a vulnerability would cost the attacker several millions of dollars.
This is because modern mobile operating systems are running in a strict enforcing mode at default-deny. Which means all actions that aren’t explicitly granted by the system’s policy, will be denied. [3] That was Gabe, a mobile security researcher and a developer at GrapheneOS. I sat down with Gabe to talk about how GrapheneOS essentially develops the most secure mobile operating system in the world. GrapheneOS is a non-profit security research project that focuses on hardening privacy and security features of the operating system while maintaining usability at the same time.
GrapheneOS is a big project that no one video would ever be able to cover in one go. What follows is a high-level non-exhaustive birds-eye view of the security model of Android and improvements to it made by GrapheneOS. The project does a lot more than is explained be covered here. Exhaustive coverage can be found in the official documentation, which you will find linked in the description. Nonetheless, if you want to better protect your private data and make the most of a secure setup, you should be introduced to these concepts and that’s what this video aims to help out with.
A secure mobile operating system is built on top of a complicated software stack whose every single building block is isolated to enforce the strict security policy. All system components and processes, third party apps and services are separated from one another in a multi-party consent of developers, users and the platform itself. This is known as an Application Sandbox and it is how Android designed its architecture. As a free and open source software, Android allowed for some of the best security researchers in the world to analyze every threat model known to architect the most secure hardware and software platform for a mobile phone. It took decades of experience and independent research, but the end result is that the most secure phone you can get has been built on top of Android. The openness of the Android ecosystem allows for an unlimited array of devices, but there is only one hardware platform that stands out from the crowd.
And that platform is the Titan M security chip. Enforcing the Android security model necessitates that the most sensitive device secrets are secure. These device secrets are cryptographic keys that are used for payments, passwords, biometrics or for unlocking the device itself. Android assumes that users could lose their phones to an adversary or execute malicious code that would give an attacker full control over the system by compromising the Linux kernel.
But even in case of such a low-level compromise or physical access to your phone, adversaries would still not be able to extract your device secrets. That’s because the secrets are generated and stored in Android Strongbox, a secure key store implementation that isolates on-device encryption keys in a dedicated tamper resistant hardware. Android bounds your secret keys to this hardware, so that they are unusable without proper authentication. The Titan M security chip became the first implementation of Android Strongbox with a dedicated tamper resistant hardware.
Titan M communicates with the main application processor, but it never releases or exposes the keys to it. It is tamper resistant, because no known manipulation of the chip will result in a successful extraction of its secrets. The Weaver’s rate limit feature Gabe mentioned hard codes delay periods into unlock attempts to make brute force attacks unfeasible. On the 5th failed attempt, there is the first 30 second delay. Next 30 second delays come from attempts 10 to 29.
Then the delay period doubles every ten failed attempts until the 139th failed attempt. From then on, there is a full day delay between each new attempt. In the San Bernandino case, Apple rejected the FBI’s request to create a software upgrade that would have removed one of the iPhone’s features to erase its data after 10 failed unlock attempts. However, Apple could have recovered the iPhone’s data for the FBI through the iCloud backups which they would have access to in their data centers. However, an employee at the San Bernandino’s County remotely reset the suspect’s iCloud password, which prompted for the iPhone’s lockscreen PIN code. The FBI eventually did get access to the iPhone through a third-party research team.
The hackers were able to chain together multiple exploits to gain full control of the iPhone’s processor and disable the erasure feature. This allowed them to brute force the iPhone’s PIN with an unlimited number of attempts. If the researchers attempted to do such a software upgrade to the Android Strongbox or Weaver on the Titan M, the Insider Attack Resistance feature would have wiped all the cryptographic secrets used for on-device encryption.
Insider Attack Resistance enforces that only user authentication can unlock the device, but the secrets will never be revealed. While Titan M’s implementation of Android Strongbox provides strong security against advanced adversaries, a secure device has to address another equally common threat – remote code execution. Android’s security model assumes that users will connect their devices to hostile networks and may run malicious code they download from the Internet. On a traditional operating system, a single infection will lead to a permanent exploitation of a target’s machine.
On Android, this is not the case. Every time you reboot your phone, Android has a built in feature to verify the authenticity of your operating system using strong cryptographic operations. This feature, called Verified Boot, establishes a full chain of trust to guarantee that your phone’s operating system has not been compromised. This verification starts from when your phone is built in the factory. The vendor’s cryptographic key is embedded into the phone’s hardware as an immutable root of trust.
This root of trust is encoded in a read-only storage so that malicious code cannot corrupt it. Verified Boot then uses encryption algorithms to verify the integrity of all of the following partitions all the way up to the operating system. As your phone boots up, the Verified Boot will communicate the state of integrity on the screen and will inform you of any issues that might arise. Verified Boot has a strict flow it follows to communicate four different states of integrity. The green state indicates no issues were found and the system fully boots. YELLOW state means the boot loader has been locked and signed with a user-defined key, which is what allows people to install custom versions of Android onto their phones while preserving the full security model of Verified Boot.
Changing the singing keys requires that the boot loader is unlocked. To protect against an adversary with physical access to your device, the process of unlocking and relocking the boot loader wipes all of the data on the phone. The ORANGE state indicates the boot loader has been unlocked, which means the system’s security model is compromised and the phone should not be trusted with sensitive data.
The RED state can indicate no valid system was found or that the device has been corrupted by attackers. GrapheneOS attestation service GrapheneOS takes advantage of the YELLOW state of Verified Boot. That is using its custom signing key while keeping the boot loader locked and maintaining full verified boot. Verifying authenticity of the system and communicating the state of integrity to the user are only two of many other important threats Verified Boot has been designed to defend against. Another major threat Verified Boot deals with is persistence. GrapheneOS hardens the security of Verified Boot by considering another attack in the threat model.
An extremely advanced adversary could modify the operating system on a compromised machine during installation. Or a malicious reseller could make modifications to the system that would allow them to bypass the security model and use their own signing keys to prevent the boot loader from communicating the compromised state to the user. GrapheneOS uses hardware-based attestation service that validates the identity of a device and verifies the authenticity and integrity of the operating system. If the operating system was tampered with or downgraded by an adversary, the GrapheneOS Attestation service would detect it even if Verified Boot would find no issues.
GrapheneOS implements the Attestation service in the Auditor app, which requires two devices to complete. Auditor stores the attestation keys in the tamper resistant Titan M chip to reduce the attack surface of the main processor. Operating systems are complex. Android acknowledges this reality and so it designs its security model with a clear goal: to render individual software vulnerabilities more difficult or impossible to exploit and raising the bar for the number of vulnerabilities required for adversaries to bypass the defenses. This is known as defense in depth.
GrapheneOS adds to Android’s defense in depth by protecting against exploits abusing unknown vulnerabilities, so called 0day exploits. These exploits are being sold legally by malware brokers for millions of dollars because crafting them requires a high set of skills and experience. Hackers are looking for these vulnerabilities inside Android operating system in an effort to escape the application sandbox. Android’s application sandbox is paramount to enforce consent between users, apps and the platform. Application sandbox is a mechanism of access control that limits what different components and processes can do on the device.
Android has three distinct permission mechanisms to enforce this sandbox. The first mechanism introduced into Android was Discretionary Access Control. DAC uses Unix-style permissions that are enforced by the Linux kernel to restrict how applications can communicate with one another.
Every app is assigned a Unix user ID, that allows the system to identify and separate apps into isolated processes. Apps run their own instance in Dalvik virtual machine embedded in Android Runtime, and are granted a dedicated space to store their data that other apps cannot access by default. Developers can write permissions for secure inter-process communication, but if an app A wants to communicate with an B, both apps have to consent to the action.
The Linux kernel enforces this consent. The second sandboxing mechanism is Mandatory Access Control. On Android, this is implemented using Security-Enhanced Linux, which enforces MAC policies across all processes, even those running with root privileges. SELinux has a policy of default denial: anything not explicitly granted is denied. In Android, SELinux operates in an enforcing mode – where denials are mandated and all attempted violations are logged. Mandatory Access Control protects system components by enforcing the same sandbox isolation as is used for isolating user apps.
That means remote exploits can’t take advantage of system processes to access user data. They would still have to compromise the Linux Kernel to bypass the security model. Before Android 6, apps would be automatically granted all manifested permissions upon first install. But this revealed to be insufficient to give users enough time to give meaningful consent. Android Permissions were introduce to protect access to sensitive data and services, and the restrictions have been tightening with every new release of Android.
Android permissions are now split into five different categories of consent: 1. Install time permissions exist for access that doesn’t pose much privacy or security risk. These are granted at first install and are removed at uninstall. 2. Runtime permissions are user-facing permission dialogues that users grant or deny on first use or only when in use. New iterations of Android expanded the permission context to include onetime permission prompts where an app’s access is revoked after first use.
3. Special Access permissions: Some permissions with higher risk than runtime permissions can only be given through higher granting friction mechanism. The most common example is when an app requests permission to install an application. It requires that a user goes to the settings and manually toggles the switch which is off by default. 4. Privileged permissions: Some pre-installed applications have access to privileged actions such as modifying secure settings or carrier billing.
They don’t show permission dialogues and only apply to OEM apps, also known as bloatware. 5. Signature permissions are intended to guard internal or highly privileged actions, such as configuring the network interfaces.
GrapheneOS builds up on top of Android’s permission mechanisms, and substantially hardens the permission model on all three levels of access control. [ First of all, GrapheneOS makes all apps submit to the same sandbox policy. That means that privileged apps that would normally run with extensive access on Android, would be completely restricted on GrapheneOS. For instance, you can install Google Apps on GrapheneOS and they would not have access to any device identifiers or other app data on your phone.
This implementation makes GrapheneOS essentially anonymous, since no device identifiable information is revealed to any third party apps and services. GrapheneOS also introduced new toggles that aren’t available on any other operating system. The network permission toggle disables direct and indirect access to all available cellular and WiFi networks. The sensor permission toggle only available on GrapheneOS zeros out the values for all device sensors, including gyroscope, accelerator, compass and others. These are only some out of many substantial improvements GrapheneOS has made over the years.
But GrapheneOS hardening doesn’t revolve just around the application sandbox. The effort to mitigate 0day exploits requires significant mitigation and attack surface reduction. Historically, 85% of Android vulnerabilities stem from memory unsafety issues. These are mainly caused by memory-unsafe languages, which Android uses in Native C/C++ libraries. Most of the Android framework and apps are written in memory-safe languages such as Java or Kotlin.
For GrapheneOS, this wasn’t enough. And so they decided to mitigate entire classes of vulnerabilities with the project’s signature hardened memory allocator. Understanding the full scope of memory allocator issues and the GrapheneOS hardened malloc would lead to an immediate depletion of the world’s adderall supplies.
However, here’s a brief rundown to help you understand how significant this is. GrapheneOS has made such a vast number of improvements it would be impossible to cover them in one video. Many of GrapheneOS’s enhancements have been adopted by the mainstream Android itself.
The research project maintains an extensive documentation on all the important features many of which were missed out by this video. Learning more about these concepts from the official documentation is the best way to advance your understanding of privacy and security. So follow the links in the description listed in the “Sources” section to advance your knowledge of mobile security.
2022-07-04 01:36
