Archive for the ‘Android Security’ Category

Introducing Adiantum: Encryption for the Next Billion Users

February 7th, 2019


Storage encryption protects your data if your phone falls into someone else's hands. Adiantum is an innovation in cryptography designed to make storage encryption more efficient for devices without cryptographic acceleration, to ensure that all devices can be encrypted.
Today, Android offers storage encryption using the Advanced Encryption Standard (AES). Most new Android devices have hardware support for AES via the ARMv8 Cryptography Extensions. However, Android runs on a wide range of devices. This includes not just the latest flagship and mid-range phones, but also entry-level Android Go phones sold primarily in developing countries, along with smart watches and TVs. In order to offer low cost options, device manufacturers sometimes use low-end processors such as the ARM Cortex-A7, which does not have hardware support for AES. On these devices, AES is so slow that it would result in a poor user experience; apps would take much longer to launch, and the device would generally feel much slower. So while storage encryption has been required for most devices since Android 6.0 in 2015, devices with poor AES performance (50 MiB/s and below) are exempt. We've been working to change this because we believe that encryption is for everyone.
In HTTPS encryption, this is a solved problem. The ChaCha20 stream cipher is much faster than AES when hardware acceleration is unavailable, while also being extremely secure. It is fast because it exclusively relies on operations that all CPUs natively support: additions, rotations, and XORs. For this reason, in 2014 Google selected ChaCha20 along with the Poly1305 authenticator, which is also fast in software, for a new TLS cipher suite to secure HTTPS internet connections. ChaCha20-Poly1305 has been standardized as RFC7539, and it greatly improves HTTPS performance on devices that lack AES instructions.
However, disk and file encryption present a special challenge. Data on storage devices is organized into "sectors" which today are typically 4096 bytes. When the filesystem makes a request to the device to read or write a sector, the encryption layer intercepts that request and converts between plaintext and ciphertext. This means that we must convert between a 4096-byte plaintext and a 4096-byte ciphertext. But to use RFC7539, the ciphertext must be slightly larger than the plaintext; a little space is needed for the cryptographic nonce and message integrity information. There are software techniques for finding places to store this extra information, but they reduce efficiency and can impose significant complexity on filesystem design.
Where AES is used, the conventional solution for disk encryption is to use the XTS or CBC-ESSIV modes of operation, which are length-preserving. Currently Android supports AES-128-CBC-ESSIV for full-disk encryption and AES-256-XTS for file-based encryption. However, when AES performance is insufficient there is no widely accepted alternative that has sufficient performance on lower-end ARM processors.
To solve this problem, we have designed a new encryption mode called Adiantum. Adiantum allows us to use the ChaCha stream cipher in a length-preserving mode, by adapting ideas from AES-based proposals for length-preserving encryption such as HCTR and HCH. On ARM Cortex-A7, Adiantum encryption and decryption on 4096-byte sectors is about 10.6 cycles per byte, around 5x faster than AES-256-XTS.
Unlike modes such as XTS or CBC-ESSIV, Adiantum is a true wide-block mode: changing any bit anywhere in the plaintext will unrecognizably change all of the ciphertext, and vice versa. It works by first hashing almost the entire plaintext using a keyed hash based on Poly1305 and another very fast keyed hashing function called NH. We also hash a value called the "tweak" which is used to ensure that different sectors are encrypted differently. This hash is then used to generate a nonce for the ChaCha encryption. After encryption, we hash again, so that we have the same strength in the decryption direction as the encryption direction. This is arranged in a configuration known as a Feistel network, so that we can decrypt what we've encrypted. A single AES-256 invocation on a 16-byte block is also required, but for 4096-byte inputs this part is not performance-critical.
Cryptographic primitives like ChaCha are organized in "rounds", with each round increasing our confidence in security at a cost in speed. To make disk encryption fast enough on the widest range of devices, we've opted to use the 12-round variant of ChaCha rather than the more widely used 20-round variant. Each round vastly increases the difficulty of attack; the 7-round variant was broken in 2008, and though many papers have improved on this attack, no attack on 8 rounds is known today. This ratio of rounds used to rounds broken today is actually better for ChaCha12 than it is for AES-256.
Even though Adiantum is very new, we are in a position to have high confidence in its security. In our paper, we prove that it has good security properties, under the assumption that ChaCha12 and AES-256 are secure. This is standard practice in cryptography; from "primitives" like ChaCha and AES, we build "constructions" like XTS, GCM, or Adiantum. Very often we can offer strong arguments but not a proof that the primitives are secure, while we can prove that if the primitives are secure, the constructions we build from them are too. We don't have to make assumptions about NH or the Poly1305 hash function; these are proven to have the cryptographic property ("ε-almost-∆-universality") we rely on.
Adiantum is named after the genus of the maidenhair fern, which in the Victorian language of flowers (floriography) represents sincerity and discretion.

Additional resources

The full details of our design, and the proof of security, are in our paper Adiantum: length-preserving encryption for entry-level processors in IACR Transactions on Symmetric Cryptology; this will be presented at the Fast Software Encryption conference (FSE 2019) in March.
Generic and ARM-optimized implementations of Adiantum are available in the Android common kernels v4.9 and higher, and in the mainline Linux kernel v5.0 and higher. Reference code, test vectors, and a benchmarking suite are available at https://github.com/google/adiantum.
Android device manufacturers can enable Adiantum for either full-disk or file-based encryption on devices with AES performance <= 50 MiB/sec and launching with Android Pie. Where hardware support for AES exists, AES is faster than Adiantum; AES must still be used where its performance is above 50 MiB/s. In Android Q, Adiantum will be part of the Android platform, and we intend to update the Android Compatibility Definition Document (CDD) to require that all new Android devices be encrypted using one of the allowed encryption algorithms.

Acknowledgements: This post leveraged contributions from Greg Kaiser and Luke Haviland. Adiantum was designed by Paul Crowley and Eric Biggers, implemented in Android by Eric Biggers and Greg Kaiser, and named by Danielle Roberts.

Posted in Android Security | Comments (0)

PHA Family Highlights: Zen and its cousins

January 11th, 2019

Posted by Lukasz Siewierski, Android Security & Privacy Team
Google Play Protect detects Potentially Harmful Applications (PHAs) which Google Play Protect defines as any mobile app that poses a potential security risk to users or to user data—commonly referred to as "malware." in a variety of ways, such as static analysis, dynamic analysis, and machine learning. While our systems are great at automatically detecting and protecting against PHAs, we believe the best security comes from the combination of automated scanning and skilled human review.
With this blog series we will be sharing our research analysis with the research and broader security community, starting with the PHA family, Zen. Zen uses root permissions on a device to automatically enable a service that creates fake Google accounts. These accounts are created by abusing accessibility services. Zen apps gain access to root permissions from a rooting trojan in its infection chain. In this blog post, we do not differentiate between the rooting component and the component that abuses root: we refer to them interchangeably as Zen. We also describe apps that we think are coming from the same author or a group of authors. All of the PHAs that are mentioned in this blog post were detected and removed by Google Play Protect.

Background

Uncovering PHAs takes a lot of detective work and unraveling the mystery of how they're possibly connected to other apps takes even more. PHA authors usually try to hide their tracks, so attribution is difficult. Sometimes, we can attribute different apps to the same author based on a small, unique pieces of evidence that suggest similarity, such as a repetition of an exceptionally rare code snippet, asset, or a particular string in the debug logs. Every once in a while, authors leave behind a trace that allows us to attribute not only similar apps, but also multiple different PHA families to the same group or person.
However, the actual timeline of the creation of different variants is unclear. In April 2013, we saw the first sample, which made heavy use of dynamic code loading (i.e., fetching executable code from remote sources after the initial app is installed). Dynamic code loading makes it impossible to state what kind of PHA it was. This sample displayed ads from various sources. More recent variants blend rooting capabilities and click fraud. As rooting exploits on Android become less prevalent and lucrative, PHA authors adapt their abuse or monetization strategy to focus on tactics like click fraud.
This post doesn't follow the chronological evolution of Zen, but instead covers relevant samples from least to most complex.

Apps with a custom-made advertisement SDK

The simplest PHA from the author's portfolio used a specially crafted advertisement SDK to create a proxy for all ads-related network traffic. By proxying all requests through a custom server, the real source of ads is opaque. This example shows one possible implementation of this technique.

This approach allows the authors to combine ads from third-party advertising networks with ads they created for their own apps. It may even allow them to sell ad space directly to application developers. The advertisement SDK also collects statistics about clicks and impressions to make it easier to track revenue. Selling the ad traffic directly or displaying ads from other sources in a very large volume can provide direct profit to the app author from the advertisers.
We have seen two types of apps that use this custom-made SDK. The first are games of very low quality that mimic the experience of popular mobile games. While the counterfeit games claim to provide similar functionality to the popular apps, they are simply used to display ads through a custom advertisement SDK.
The second type of apps reveals an evolution in the author's tactics. Instead of implementing very basic gameplay, the authors pirated and repackaged the original game in their app and bundled with it their advertisement SDK. The only noticeable difference is the game has more ads, including ads on the very first screen.
In all cases, the ads are used to convince users to install other apps from different developer accounts, but written by the same group. Those apps use the same techniques to monetize their actions.

Click fraud apps

The authors' tactics evolved from advertisement spam to real PHA (Click Fraud). Click fraud PHAs simulate user clicks on ads instead of simply displaying ads and waiting for users to click them. This allows the PHA authors to monetize their apps more effectively than through regular advertising. This behavior negatively impacts advertisement networks and their clients because advertising budget is spent without acquiring real customers, and impacts user experience by consuming their data plan resources.
The click fraud PHA requests a URL to the advertising network directly instead of proxying it through an additional SDK. The command & control server (C&C server) returns the URL to click along with a very long list of additional parameters in JSON format. After rendering the ad on the screen, the app tries to identify the part of the advertisement website to click. If that part is found, the app loads Javascript snippets from the JSON parameters to click a button or other HTML element, simulating a real user click. Because a user interacting with an ad often leads to a higher chance of the user purchasing something, ad networks often "pay per click" to developers who host their ads. Therefore, by simulating fraudulent clicks, these developers are making money without requiring a user to click on an advertisement.
This example code shows a JSON reply returned by the C&C server. It has been shortened for brevity.
{
"data": [{
"id": "107",
"url": "<ayud_url>",
"click_type": "2",
"keywords_js": [{
"keyword": "<a class=\"show_hide btnnext\"",
"js": "javascript:window:document.getElementsByClassName(\"show_hide btnnext\")[0].click();",
{
"keyword": "value=\"Subscribe\" id=\"sub-click\"",
"js": "javascript:window:document.getElementById(\"sub-click\").click();"
Based on this JSON reply, the app looks for an HTML snippet that corresponds to the active element (show_hide btnnext) and, if found, the Javascript snippet tries to perform a click() method on it.

Rooting trojans

The Zen authors have also created a rooting trojan. Using a publicly available rooting framework, the PHA attempts to root devices and gain persistence on them by reinstalling itself on the system partition of rooted device. Installing apps on the system partition makes it harder for the user to remove the app.
This technique only works for unpatched devices running Android 4.3 or lower. Devices running Android 4.4 and higher are protected by Verified Boot.
Zen's rooting trojan apps target a specific device model with a very specific system image. After achieving root access the app tries to replace the framework.jar file on the system partition. Replicating framework.jar allows the app to intercept and modify the behavior of the Android standard API. In particular, these apps try to add an additional method called statistics() into the Activity class. When inserted, this method runs every time any Activity object in any Android app is created. This happens all the time in regular Android apps, as Activity is one of the fundamental Android UI elements. The only purpose of this method is to connect to the C&C server.

The Zen trojan

After achieving persistence, the trojan downloads additional payloads, including another trojan called Zen. Zen requires root to work correctly on the Android operating system.
The Zen trojan uses its root privileges to turn on accessibility service (a service used to allow Android users with disabilities to use their devices) for itself by writing to a system-wide setting value enabled_accessibility_services. Zen doesn't even check for the root privilege: it just assumes it has it. This leads us to believe that Zen is just part of a larger infection chain. The trojan implements three accessibility services directed at different Android API levels and uses these accessibility services, chosen by checking the operating system version, to create new Google accounts. This is done by opening the Google account creation process and parsing the current view. The app then clicks the appropriate buttons, scrollbars, and other UI elements to go through account sign-up without user intervention.
During the account sign-up process, Google may flag the account creation attempt as suspicious and prompt the app to solve a CAPTCHA. To get around this, the app then uses its root privilege to inject code into the Setup Wizard, extract the CAPTCHA image, and sends it to a remote server to try to solve the CAPTCHA. It is unclear if the remote server is capable of solving the CAPTCHA image automatically or if this is done manually by a human in the background. After the server returns the solution, the app enters it into the appropriate text field to complete the CAPTCHA challenge.
The Zen trojan does not implement any kind of obfuscation except for one string that is encoded using Base64 encoding. It's one of the strings - "How you'll sign in" - that it looks for during the account creation process. The code snippet below shows part of the screen parsing process.
if (!title.containsKey("Enter the code")) { 
if (!title.containsKey("Basic information")) {
if (!title.containsKey(new String(android.util.Base64.decode("SG93IHlvdeKAmWxsIHNpZ24gaW4=".getBytes(), 0)))) {
if (!title.containsKey("Create password")) {
if (!title.containsKey("Add phone number")) {

Apart from injecting code to read the CAPTCHA, the app also injects its own code into the system_server process, which requires root privileges. This indicates that the app tries to hide itself from any anti-PHA systems that look for a specific app process name or does not have the ability to scan the memory of the system_server process.
The app also creates hooks to prevent the phone from rebooting, going to sleep or allowing the user from pressing hardware buttons during the account creation process. These hooks are created using the root access and a custom native code called Lmt_INJECT, although the algorithm for this is well known.
First, the app has to turn off SELinux protection. Then the app finds a process id value for the process it wants to inject with code. This is done using a series of syscalls as outlined below. The "source process" refers to the Zen trojan running as root, while the "target process" refers to the process to which the code is injected and [pid] refers to the target process pid value.
  1. The source process checks the mapping between a process id and a process name. This is done by reading the /proc/[pid]/cmdline file.
    This very first step fails in Android 7.0 and higher, even with a root permission. The /proc filesystem is now mounted with a hidepid=2 parameter, which means that the process cannot access other process /proc/[pid] directory.
  2. A ptrace_attach syscall is called. This allows the source process to trace the target.
  3. The source process looks at its own memory to calculate the offset between the beginning of the libc library and the mmap address.
  4. The source process reads /proc/[pid]/maps to find where libc is located in the target process memory. By adding the previously calculated offset, it can get the address of the mmap function in the target process memory.
  5. The source process tries to determine the location of dlopen, dlsym, and dlclose functions in the target process. It uses the same technique as it used to determine the offset to the mmap function.
  6. The source process writes the native shellcode into the memory region allocated by mmap. Additionally, it also writes addresses of dlopen, dlsym, and dlclose into the same region, so that they can be used by the shellcode. Shellcode simply uses dlopen to open a .so file within the target process and then dlsym to find a symbol in that file and run it.
  7. The source process changes the registers in the target process so that PC register points directly to the shellcode. This is done using the ptrace syscall.
This diagram illustrates the whole process.

Summary

PHA authors go to great lengths to come up with increasingly clever ways to monetize their apps.
Zen family PHA authors exhibit a wide range of techniques, from simply inserting an advertising SDK to a sophisticated trojan. The app that resulted in the largest number of affected users was the click fraud version, which was installed over 170,000 times at its peak in February 2018. The most affected countries were India, Brazil, and Indonesia. In most cases, these click fraud apps were uninstalled by the users, probably due to the low quality of the apps.
If Google Play Protect detects one of these apps, Google Play Protect will show a warning to users.
We are constantly on the lookout for new threats and we are expanding our protections. Every device with Google Play includes Google Play Protect and all apps on Google Play are automatically and periodically scanned by our solutions.
You can check the status of Google Play Protect on your device:
  1. Open your Android device's Google Play Store app.
  2. Tap Menu>Play Protect.
  3. Look for information about the status of your device.

Hashes of samples

Type Package name SHA256 digest
Custom ads com.targetshoot.zombieapocalypse.sniper.zombieshootinggame 5d98d8a7a012a858f0fa4cf8d2ed3d5a82937b1a98ea2703d440307c63c6c928
Click fraud com.counterterrorist.cs.elite.combat.shootinggame 84672fb2f228ec749d3c3c1cb168a1c31f544970fd29136bea2a5b2cefac6d04
Rooting trojan com.android.world.news bd233c1f5c477b0cc15d7f84392dab3a7a598243efa3154304327ff4580ae213
Zen trojan com.lmt.register eb12cd65589cbc6f9d3563576c304273cb6a78072b0c20a155a0951370476d8d

Posted in Android Security | Comments (0)

Android Pie à la mode: Security & Privacy

December 20th, 2018
Posted by Vikrant Nanda and René Mayrhofer, Android Security & Privacy Team

[Cross-posted from the Android Developers Blog]


There is no better time to talk about Android dessert releases than the holidays because who doesn't love dessert? And what is one of our favorite desserts during the holiday season? Well, pie of course.

In all seriousness, pie is a great analogy because of how the various ingredients turn into multiple layers of goodness: right from the software crust on top to the hardware layer at the bottom. Read on for a summary of security and privacy features introduced in Android Pie this year.
Platform hardening
With Android Pie, we updated File-Based Encryption to support external storage media (such as, expandable storage cards). We also introduced support for metadata encryption where hardware support is present. With filesystem metadata encryption, a single key present at boot time encrypts whatever content is not encrypted by file-based encryption (such as, directory layouts, file sizes, permissions, and creation/modification times).

Android Pie also introduced a BiometricPrompt API that apps can use to provide biometric authentication dialogs (such as, fingerprint prompt) on a device in a modality-agnostic fashion. This functionality creates a standardized look, feel, and placement for the dialog. This kind of standardization gives users more confidence that they're authenticating against a trusted biometric credential checker.

New protections and test cases for the Application Sandbox help ensure all non-privileged apps targeting Android Pie (and all future releases of Android) run in stronger SELinux sandboxes. By providing per-app cryptographic authentication to the sandbox, this protection improves app separation, prevents overriding safe defaults, and (most significantly) prevents apps from making their data widely accessible.
Anti-exploitation improvements
With Android Pie, we expanded our compiler-based security mitigations, which instrument runtime operations to fail safely when undefined behavior occurs.

Control Flow Integrity (CFI) is a security mechanism that disallows changes to the original control flow graph of compiled code. In Android Pie, it has been enabled by default within the media frameworks and other security-critical components, such as for Near Field Communication (NFC) and Bluetooth protocols. We also implemented support for CFI in the Android common kernel, continuing our efforts to harden the kernel in previous Android releases.

Integer Overflow Sanitization is a security technique used to mitigate memory corruption and information disclosure vulnerabilities caused by integer operations. We've expanded our use of Integer Overflow sanitizers by enabling their use in libraries where complex untrusted input is processed or where security vulnerabilities have been reported.
Continued investment in hardware-backed security

One of the highlights of Android Pie is Android Protected Confirmation, the first major mobile OS API that leverages a hardware-protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system. Developers can use this API to display a trusted UI prompt to the user, requesting approval via a physical protected input (such as, a button on the device). The resulting cryptographically signed statement allows the relying party to reaffirm that the user would like to complete a sensitive transaction through their app.

We also introduced support for a new Keystore type that provides stronger protection for private keys by leveraging tamper-resistant hardware with dedicated CPU, RAM, and flash memory. StrongBox Keymaster is an implementation of the Keymaster hardware abstraction layer (HAL) that resides in a hardware security module. This module is designed and required to have its own processor, secure storage, True Random Number Generator (TRNG), side-channel resistance, and tamper-resistant packaging.

Other Keystore features (as part of Keymaster 4) include Keyguard-bound keys, Secure Key Import, 3DES support, and version binding. Keyguard-bound keys enable use restriction so as to protect sensitive information. Secure Key Import facilitates secure key use while protecting key material from the application or operating system. You can read more about these features in our recent blog post as well as the accompanying release notes.
Enhancing user privacy

User privacy has been boosted with several behavior changes, such as limiting the access background apps have to the camera, microphone, and device sensors. New permission rules and permission groups have been created for phone calls, phone state, and Wi-Fi scans, as well as restrictions around information retrieved from Wi-Fi scans. We have also added associated MAC address randomization, so that a device can use a different network address when connecting to a Wi-Fi network.

On top of that, Android Pie added support for encrypting Android backups with the user's screen lock secret (that is, PIN, pattern, or password). By design, this means that an attacker would not be able to access a user's backed-up application data without specifically knowing their passcode. Auto backup for apps has been enhanced by providing developers a way to specify conditions under which their app's data is excluded from auto backup. For example, Android Pie introduces a new flag to determine whether a user's backup is client-side encrypted.

As part of a larger effort to move all web traffic away from cleartext (unencrypted HTTP) and towards being secured with TLS (HTTPS), we changed the defaults for Network Security Configuration to block all cleartext traffic. We're protecting users with TLS by default, unless you explicitly opt-in to cleartext for specific domains. Android Pie also adds built-in support for DNS over TLS, automatically upgrading DNS queries to TLS if a network's DNS server supports it. This protects information about IP addresses visited from being sniffed or intercepted on the network level.


We believe that the features described in this post advance the security and privacy posture of Android, but you don't have to take our word for it. Year after year our continued efforts are demonstrably resulting in better protection as evidenced by increasing exploit difficulty and independent mobile security ratings. Now go and enjoy some actual pie while we get back to preparing the next Android dessert release!

Making Android more secure requires a combination of hardening the platform and advancing anti-exploitation techniques.


Acknowledgements: This post leveraged contributions from Chad Brubaker, Janis Danisevskis, Giles Hogben, Troy Kensinger, Ivan Lozano, Vishwath Mohan, Frank Salim, Sami Tolvanen, Lilian Young, and Shawn Willden.

Posted in Android Security | Comments (0)

New Keystore features keep your slice of Android Pie a little safer

December 12th, 2018

Posted by Lilian Young and Shawn Willden, Android Security; and Frank Salim, Google Pay

[Cross-posted from the Android Developers Blog]

New Android Pie Keystore Features

The Android Keystore provides application developers with a set of cryptographic tools that are designed to secure their users' data. Keystore moves the cryptographic primitives available in software libraries out of the Android OS and into secure hardware. Keys are protected and used only within the secure hardware to protect application secrets from various forms of attacks. Keystore gives applications the ability to specify restrictions on how and when the keys can be used.
Android Pie introduces new capabilities to Keystore. We will be discussing two of these new capabilities in this post. The first enables restrictions on key use so as to protect sensitive information. The second facilitates secure key use while protecting key material from the application or operating system.

Keyguard-bound keys

There are times when a mobile application receives data but doesn't need to immediately access it if the user is not currently using the device. Sensitive information sent to an application while the device screen is locked must remain secure until the user wants access to it. Android Pie addresses this by introducing keyguard-bound cryptographic keys. When the screen is locked, these keys can be used in encryption or verification operations, but are unavailable for decryption or signing. If the device is currently locked with a PIN, pattern, or password, any attempt to use these keys will result in an invalid operation. Keyguard-bound keys protect the user's data while the device is locked, and only available when the user needs it.
Keyguard binding and authentication binding both function in similar ways, except with one important difference. Keyguard binding ties the availability of keys directly to the screen lock state while authentication binding uses a constant timeout. With keyguard binding, the keys become unavailable as soon as the device is locked and are only made available again when the user unlocks the device.
It is worth noting that keyguard binding is enforced by the operating system, not the secure hardware. This is because the secure hardware has no way to know when the screen is locked. Hardware-enforced Android Keystore protection features like authentication binding, can be combined with keyguard binding for a higher level of security. Furthermore, since keyguard binding is an operating system feature, it's available to any device running Android Pie.
Keys for any algorithm supported by the device can be keyguard-bound. To generate or import a key as keyguard-bound, call setUnlockedDeviceRequired(true) on the KeyGenParameterSpec or KeyProtection builder object at key generation or import.

Secure Key Import

Secure Key Import is a new feature in Android Pie that allows applications to provision existing keys into Keystore in a more secure manner. The origin of the key, a remote server that could be sitting in an on-premise data center or in the cloud, encrypts the secure key using a public wrapping key from the user's device. The encrypted key in the SecureKeyWrapper format, which also contains a description of the ways the imported key is allowed to be used, can only be decrypted in the Keystore hardware belonging to the specific device that generated the wrapping key. Keys are encrypted in transit and remain opaque to the application and operating system, meaning they're only available inside the secure hardware into which they are imported.

Secure Key Import is useful in scenarios where an application intends to share a secret key with an Android device, but wants to prevent the key from being intercepted or from leaving the device. Google Pay uses Secure Key Import to provision some keys on Pixel 3 phones, to prevent the keys from being intercepted or extracted from memory. There are also a variety of enterprise use cases such as S/MIME encryption keys being recovered from a Certificate Authorities escrow so that the same key can be used to decrypt emails on multiple devices.
To take advantage of this feature, please review this training article. Please note that Secure Key Import is a secure hardware feature, and is therefore only available on select Android Pie devices. To find out if the device supports it, applications can generate a KeyPair with PURPOSE_WRAP_KEY.

Posted in Android Security | Comments (0)

ASPIRE to keep protecting billions of Android users

December 5th, 2018


Customization is one of Android's greatest strengths. Android's open source nature has enabled thousands of device types that cover a variety of use cases. In addition to adding features to the Android Open Source Project, researchers, developers, service providers, and device and chipset manufacturers can make updates to improve Android security. Investing and engaging in academic research advances the state-of-the-art security techniques, contributes to science, and delivers cutting edge security and privacy features into the hands of end users. To foster more cooperative applied research between the Android Security and Privacy team and the wider academic and industrial community, we're launching ASPIRE (Android Security and PrIvacy REsearch).

ASPIRE's goal is encouraging the development of new security and privacy technology that impacts the Android ecosystem in the next 2 to 5 years, but isn't planned for mainline Android development. This timeframe extends beyond the next annual Android release to allow adequate time to analyze, develop, and stabilize research into features before including in the platform. To collaborate with security researchers, we're hosting events and creating more channels to contribute research.

On October 25th 2018, we invited top security and privacy researchers from around the world to present at Android Security Local Research Day (ASLR-D). At this event, external researchers and Android Security and Privacy team members discussed current issues and strategies that impact the future direction of security research—for Android and the entire industry.

We can't always get everyone in the same room and good ideas come from everywhere. So we're inviting all academic researchers to help us protect billions of users. Research collaborations with Android should be as straightforward as collaborating with the research lab next door. To get involved you can:

  1. Submit an Android security / privacy research idea or proposal to the Google Faculty Research Awards (FRA) program.
  2. Apply for a research internship as a student pursuing an advanced degree.
  3. Apply to become a Visiting Researcher at Google.
  4. If you have any security or privacy questions that may help with your research, reach out to us.
  5. Co-author publications with Android team members, outside the terms of FRA.
  6. Collaborate with Android team members to make changes to the Android Open Source Project.

Let’s work together to make Android the most secure platform—now and in the future.

Posted in Android Security | Comments (0)

Combating Potentially Harmful Applications with Machine Learning at Google: Datasets and Models

November 15th, 2018


[Cross-posted from the Android Developers Blog]

In a previous blog post, we talked about using machine learning to combat Potentially Harmful Applications (PHAs). This blog post covers how Google uses machine learning techniques to detect and classify PHAs. We'll discuss the challenges in the PHA detection space, including the scale of data, the correct identification of PHA behaviors, and the evolution of PHA families. Next, we will introduce two of the datasets that make the training and implementation of machine learning models possible, such as app analysis data and Google Play data. Finally, we will present some of the approaches we use, including logistic regression and deep neural networks.

Using Machine Learning to Scale

Detecting PHAs is challenging and requires a lot of resources. Our security experts need to understand how apps interact with the system and the user, analyze complex signals to find PHA behavior, and evolve their tactics to stay ahead of PHA authors. Every day, Google Play Protect (GPP) analyzes over half a million apps, which makes a lot of new data for our security experts to process.

Leveraging machine learning helps us detect PHAs faster and at a larger scale. We can detect more PHAs just by adding additional computing resources. In many cases, machine learning can find PHA signals in the training data without human intervention. Sometimes, those signals are different than signals found by security experts. Machine learning can take better advantage of this data, and discover hidden relationships between signals more effectively.

There are two major parts of Google Play Protect's machine learning protections: the data and the machine learning models.

Data Sources

The quality and quantity of the data used to create a model are crucial to the success of the system. For the purpose of PHA detection and classification, our system mainly uses two anonymous data sources: data from analyzing apps and data from how users experience apps.

App Data

Google Play Protect analyzes every app that it can find on the internet. We created a dataset by decomposing each app's APK and extracting PHA signals with deep analysis. We execute various processes on each app to find particular features and behaviors that are relevant to the PHA categories in scope (for example, SMS fraud, phishing, privilege escalation). Static analysis examines the different resources inside an APK file while dynamic analysis checks the behavior of the app when it's actually running. These two approaches complement each other. For example, dynamic analysis requires the execution of the app regardless of how obfuscated its code is (obfuscation hinders static analysis), and static analysis can help detect cloaking attempts in the code that may in practice bypass dynamic analysis-based detection. In the end, this analysis produces information about the app's characteristics, which serve as a fundamental data source for machine learning algorithms.

Google Play Data

In addition to analyzing each app, we also try to understand how users perceive that app. User feedback (such as the number of installs, uninstalls, user ratings, and comments) collected from Google Play can help us identify problematic apps. Similarly, information about the developer (such as the certificates they use and their history of published apps) contribute valuable knowledge that can be used to identify PHAs. All these metrics are generated when developers submit a new app (or new version of an app) and by millions of Google Play users every day. This information helps us to understand the quality, behavior, and purpose of an app so that we can identify new PHA behaviors or identify similar apps.

In general, our data sources yield raw signals, which then need to be transformed into machine learning features for use by our algorithms. Some signals, such as the permissions that an app requests, have a clear semantic meaning and can be directly used. In other cases, we need to engineer our data to make new, more powerful features. For example, we can aggregate the ratings of all apps that a particular developer owns, so we can calculate a rating per developer and use it to validate future apps. We also employ several techniques to focus in on interesting data.To create compact representations for sparse data, we use embedding. To help streamline the data to make it more useful to models, we use feature selection. Depending on the target, feature selection helps us keep the most relevant signals and remove irrelevant ones.

By combining our different datasets and investing in feature engineering and feature selection, we improve the quality of the data that can be fed to various types of machine learning models.

Models

Building a good machine learning model is like building a skyscraper: quality materials are important, but a great design is also essential. Like the materials in a skyscraper, good datasets and features are important to machine learning, but a great algorithm is essential to identify PHA behaviors effectively and efficiently.

We train models to identify PHAs that belong to a specific category, such as SMS-fraud or phishing. Such categories are quite broad and contain a large number of samples given the number of PHA families that fit the definition. Alternatively, we also have models focusing on a much smaller scale, such as a family, which is composed of a group of apps that are part of the same PHA campaign and that share similar source code and behaviors. On the one hand, having a single model to tackle an entire PHA category may be attractive in terms of simplicity but precision may be an issue as the model will have to generalize the behaviors of a large number of PHAs believed to have something in common. On the other hand, developing multiple PHA models may require additional engineering efforts, but may result in better precision at the cost of reduced scope.

We use a variety of modeling techniques to modify our machine learning approach, including supervised and unsupervised ones.

One supervised technique we use is logistic regression, which has been widely adopted in the industry. These models have a simple structure and can be trained quickly. Logistic regression models can be analyzed to understand the importance of the different PHA and app features they are built with, allowing us to improve our feature engineering process. After a few cycles of training, evaluation, and improvement, we can launch the best models in production and monitor their performance.

For more complex cases, we employ deep learning. Compared to logistic regression, deep learning is good at capturing complicated interactions between different features and extracting hidden patterns. The millions of apps in Google Play provide a rich dataset, which is advantageous to deep learning.

In addition to our targeted feature engineering efforts, we experiment with many aspects of deep neural networks. For example, a deep neural network can have multiple layers and each layer has several neurons to process signals. We can experiment with the number of layers and neurons per layer to change model behaviors.

We also adopt unsupervised machine learning methods. Many PHAs use similar abuse techniques and tricks, so they look almost identical to each other. An unsupervised approach helps define clusters of apps that look or behave similarly, which allows us to mitigate and identify PHAs more effectively. We can automate the process of categorizing that type of app if we are confident in the model or can request help from a human expert to validate what the model found.

PHAs are constantly evolving, so our models need constant updating and monitoring. In production, models are fed with data from recent apps, which help them stay relevant. However, new abuse techniques and behaviors need to be continuously detected and fed into our machine learning models to be able to catch new PHAs and stay on top of recent trends. This is a continuous cycle of model creation and updating that also requires tuning to ensure that the precision and coverage of the system as a whole matches our detection goals.

Looking forward

As part of Google's AI-first strategy, our work leverages many machine learning resources across the company, such as tools and infrastructures developed by Google Brain and Google Research. In 2017, our machine learning models successfully detected 60.3% of PHAs identified by Google Play Protect, covering over 2 billion Android devices. We continue to research and invest in machine learning to scale and simplify the detection of PHAs in the Android ecosystem.

Acknowledgements

This work was developed in joint collaboration with Google Play Protect, Safe Browsing and Play Abuse teams with contributions from Andrew Ahn, Hrishikesh Aradhye, Daniel Bali, Hongji Bao, Yajie Hu, Arthur Kaiser, Elena Kovakina, Salvador Mandujano, Melinda Miller, Rahul Mishra, Sebastian Porst, Monirul Sharif, Sri Somanchi, Sai Deep Tetali, and Zhikun Wang.

Posted in Android Security | Comments (0)

Introducing the Android Ecosystem Security Transparency Report

November 8th, 2018


Update: We identified a bug that affected how we calculated data from Q3 2018 in the Transparency Report. This bug created inconsistencies between the data in the report and this blog post. The data points in this blog post have been corrected.

As shared during the What's new in Android security session at Google I/O 2018, transparency and openness are important parts of Android's ethos. We regularly blog about new features and enhancements and publish an annual Android Security Year in Review, which highlights Android ecosystem trends. To provide more frequent insights, we're introducing a quarterly Android Ecosystem Security Transparency Report. This report is the latest addition to our Transparency Report site, which began in 2010 to show how the policies and actions of governments and corporations affect privacy, security, and access to information online.

This Android Ecosystem Security Transparency Report covers how often a routine, full-device scan by Google Play Protect detects a device with PHAs installed. Google Play Protect is built-in protection on Android devices that scans over 50 billion apps daily from inside and outside of Google Play. These scans look for evidence of Potentially Harmful Applications (PHAs). If the scans find a PHA, Google Play Protect warns the user and can disable or remove PHAs. In Android's first annual Android Security Year in Review from 2014, fewer than 1% of devices had PHAs installed. The percentage has declined steadily over time and this downward trend continues through 2018. The transparency report covers PHA rates in three areas: market segment (whether a PHA came from Google Play or outside of Google Play), Android version, and country.

Devices with Potentially Harmful Applications installed by market segment

Google works hard to protect your Android device: no matter where your apps come from. Continuing the trend from previous years, Android devices that only download apps from Google Play are 9 times less likely to get a PHA than devices that download apps from other sources. Before applications become available in Google Play they undergo an application review to confirm they comply with Google Play policies. Google uses a risk scorer to analyze apps to detect potentially harmful behavior. When Google’s application risk analyzer discovers something suspicious, it flags the app and refers the PHA to a security analyst for manual review if needed. We also scan apps that users download to their device from outside of Google Play. If we find a suspicious app, we also protect users from that—even if it didn't come from Google Play.

In the Android Ecosystem Security Transparency Report, the Devices with Potentially Harmful Applications installed by market segment chart shows the percentage of Android devices that have one or more PHAs installed over time. The chart has two lines: PHA rate for devices that exclusively install from Google Play and PHA rate for devices that also install from outside of Google Play. In 2017, on average 0.09% of devices that exclusively used Google Play had one or more PHAs installed. The first three quarters in 2018 averaged a lower PHA rate of 0.08%.

The security of devices that installed apps from outside of Google Play also improved. In 2017, ~0.82% of devices that installed apps from outside of Google Play were affected by PHA; in the first three quarters of 2018, ~0.68% were affected. Since 2017, we've reduced this number by expanding the auto-disable feature which we covered on page 10 in the 2017 Year in Review. While malware rates fluctuate from quarter to quarter, our metrics continue to show a consistent downward trend over time. We'll share more details in our 2018 Android Security Year in Review in early 2019.

Devices with Potentially Harmful Applications installed by Android version

Newer versions of Android are less affected by PHAs. We attribute this to many factors, such as continued platform and API hardening, ongoing security updates and app security and developer training to reduce apps' access to sensitive data. In particular, newer Android versions—such as Nougat, Oreo, and Pie—are more resilient to privilege escalation attacks that had previously allowed PHAs to gain persistence on devices and protect themselves against removal attempts. The Devices with Potentially Harmful Applications installed by Android version chart shows the percentage of devices with a PHA installed, sorted by the Android version that the device is running.

Devices with Potentially Harmful Applications rate by top 10 countries

Overall, PHA rates in the ten largest Android markets have remained steady. While these numbers fluctuate on a quarterly basis due to the fluidity of the marketplace, we intend to provide more in depth coverage of what drove these changes in our annual Year in Review in Q1, 2019.

The Devices with Potentially Harmful Applications rate by top 10 countries chart shows the percentage of devices with at least one PHA in the ten countries with the highest volume of Android devices. India saw the most significant decline in PHAs present on devices, with the average rate of infection dropping by 34 percent. Indonesia, Mexico, and Turkey also saw a decline in the likelihood of PHAs being present on devices in the region. South Korea saw the lowest number of devices containing PHA, with only 0.1%.

Check out the report

Over time, we'll add more insights into the health of the ecosystem to the Android Ecosystem Security Transparency Report. If you have any questions about terminology or the products referred to in this report please review the FAQs section of the Transparency Report. In the meantime, check out our new blog post and video outlining Android’s performance in Gartner’s Mobile OSs and Device Security: A Comparison of Platforms report.

Posted in Android Security | Comments (0)

Google Makes 2 Years of Android Security Updates Mandatory for Device Makers

October 25th, 2018
When it comes to security updates, Android is a real mess. Even after Google timely rolls out security patches for its Android platform, a major part of the Android ecosystem remains exposed to hackers because device manufacturers do not deliver patches regularly and on a timely basis to their customers. To deal with this issue, Google at its I/O Developer Conference May 2018 revealed the

Posted in Android, Android hacking, android hacking software, Android Security, Android Security Updates, Android Vulnerability, cybersecurity, Google Android, how to hack android | Comments (0)

Android Protected Confirmation: Taking transaction security to the next level

October 19th, 2018


[Cross-posted from the Android Developers Blog]

In Android Pie, we introduced Android Protected Confirmation, the first major mobile OS API that leverages a hardware protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system. This Trusted UI protects the choices you make from fraudulent apps or a compromised operating system. When an app invokes Protected Confirmation, control is passed to the Trusted UI, where transaction data is displayed and user confirmation of that data's correctness is obtained.
Once confirmed, your intention is cryptographically authenticated and unforgeable when conveyed to the relying party, for example, your bank. Protected Confirmation increases the bank's confidence that it acts on your behalf, providing a higher level of protection for the transaction.
Protected Confirmation also adds additional security relative to other forms of secondary authentication, such as a One Time Password or Transaction Authentication Number. These mechanisms can be frustrating for mobile users and also fail to protect against a compromised device that can corrupt transaction data or intercept one-time confirmation text messages.
Once the user approves a transaction, Protected Confirmation digitally signs the confirmation message. Because the signing key never leaves the Trusted UI's hardware sandbox, neither app malware nor a compromised operating system can fool the user into authorizing anything. Protected Confirmation signing keys are created using Android's standard AndroidKeyStore API. Before it can start using Android Protected Confirmation for end-to-end secure transactions, the app must enroll the public KeyStore key and its Keystore Attestation certificate with the remote relying party. The attestation certificate certifies that the key can only be used to sign Protected Confirmations.
There are many possible use cases for Android Protected Confirmation. At Google I/O 2018, the What's new in Android security session showcased partners planning to leverage Android Protected Confirmation in a variety of ways, including Royal Bank of Canada person to person money transfers; Duo Security, Nok Nok Labs, and ProxToMe for user authentication; and Insulet Corporation and Bigfoot Biomedical, for medical device control.
Insulet, a global leading manufacturer of tubeless patch insulin pumps, has demonstrated how they can modify their FDA cleared Omnipod DASH TM Insulin management system in a test environment to leverage Protected Confirmation to confirm the amount of insulin to be injected. This technology holds the promise for improved quality of life and reduced cost by enabling a person with diabetes to leverage their convenient, familiar, and secure smartphone for control rather than having to rely on a secondary, obtrusive, and expensive remote control device. (Note: The Omnipod DASH™ System is not cleared for use with Pixel 3 mobile device or Protected Confirmation).

This work is fulfilling an important need in the industry. Since smartphones do not fit the mold of an FDA approved medical device, we've been working with FDA as part of DTMoSt, an industry-wide consortium, to define a standard for phones to safely control medical devices, such as insulinSince smartphones do not fit the mold of an FDA approved medical device, we've been working with FDA as part of DTMoSt, an industry-wide consortium, to define a standard for phones to safely control medical devices, such as insulin pumps. A technology like Protected Confirmation plays an important role in gaining higher assurance of user intent and medical safety.
To integrate Protected Confirmation into your app, check out the Android Protected Confirmation training article. Android Protected Confirmation is an optional feature in Android Pie. Because it has low-level hardware dependencies, Protected Confirmation may not be supported by all devices running Android Pie. Google Pixel 3 and 3XL devices are the first to support Protected Confirmation, and we are working closely with other manufacturers to adopt this market-leading security innovation on more devices.

Posted in Android Security | Comments (0)

Building a Titan: Better security through a tiny chip

October 17th, 2018

Posted by Nagendra Modadugu and Bill Richardson, Google Device Security Group

[Cross-posted from the Android Developers Blog]

At the Made by Google event last week, we talked about the combination of AI + Software + Hardware to help organize your information. To better protect that information at a hardware level, our new Pixel 3 and Pixel 3 XL devices include a Titan M chip.We briefly introduced Titan M and some of its benefits on our Keyword Blog, and with this post we dive into some of its technical details.
Titan M is a second-generation, low-power security module designed and manufactured by Google, and is a part of the Titan family. As described in the Keyword Blog post, Titan M performs several security sensitive functions, including:
  • Storing and enforcing the locks and rollback counters used by Android Verified Boot.
  • Securely storing secrets and rate-limiting invalid attempts at retrieving them using the Weaver API.
  • Providing backing for the Android Strongbox Keymaster module, including Trusted User Presence and Protected Confirmation. Titan M has direct electrical connections to the Pixel's side buttons, so a remote attacker can't fake button presses. These features are available to third-party apps, such as FIDO U2F Authentication.
  • Enforcing factory-reset policies, so that lost or stolen phones can only be restored to operation by the authorized owner.
  • Ensuring that even Google can't unlock a phone or install firmware updates without the owner's cooperation with Insider Attack Resistance.
Including Titan M in Pixel 3 devices substantially reduces the attack surface. Because Titan M is a separate chip, the physical isolation mitigates against entire classes of hardware-level exploits such as Rowhammer, Spectre, and Meltdown. Titan M's processor, caches, memory, and persistent storage are not shared with the rest of the phone's system, so side channel attacks like these—which rely on subtle, unplanned interactions between internal circuits of a single component—are nearly impossible. In addition to its physical isolation, the Titan M chip contains many defenses to protect against external attacks.
But Titan M is not just a hardened security microcontroller, but rather a full-lifecycle approach to security with Pixel devices in mind. Titan M's security takes into consideration all the features visible to Android down to the lowest level physical and electrical circuit design and extends beyond each physical device to our supply chain and manufacturing processes. At the physical level, we incorporated essential features optimized for the mobile experience: low power usage, low-latency, hardware crypto acceleration, tamper detection, and secure, timely firmware updates. We improved and invested in the supply chain for Titan M by creating a custom provisioning process, which provides us with transparency and control starting from the earliest silicon stages.
Finally, in the interest of transparency, the Titan M firmware source code will be publicly available soon. While Google holds the root keys necessary to sign Titan M firmware, it will be possible to reproduce binary builds based on the public source for the purpose of binary transparency.

A closer look at Titan M

Titan (left) and Titan M (right)

Titan M's CPU is an ARM Cortex-M3 microprocessor specially hardened against side-channel attacks and augmented with defensive features to detect and respond to abnormal conditions. The Titan M CPU core also exposes several control registers, which can be used to taper access to chip configuration settings and peripherals. Once powered on, Titan M verifies the signature of its flash-based firmware using a public key built into the chip's silicon. If the signature is valid, the flash is locked so it can't be modified, and then the firmware begins executing.
Titan M also features several hardware accelerators: AES, SHA, and a programmable big number coprocessor for public key algorithms. These accelerators are flexible and can either be initialized with keys provided by firmware or with chip-specific and hardware-bound keys generated by the Key Manager module. Chip-specific keys are generated internally based on entropy derived from the True Random Number Generator (TRNG), and thus such keys are never externally available outside the chip over its entire lifetime.
While implementing Titan M firmware, we had to take many system constraints into consideration. For example, packing as many security features into Titan M's 64 Kbytes of RAM required all firmware to execute exclusively off the stack. And to reduce flash-wear, RAM contents can be preserved even during low-power mode when most hardware modules are turned off.
The diagram below provides a high-level view of the chip components described here.

Better security through transparency and innovation

At the heart of our implementation of Titan M are two broader trends: transparency and building a platform for future innovation.
Transparency around every step of the design process — from logic gates to boot code to the applications — gives us confidence in the defenses we're providing for our users. We know what's inside, how it got there, how it works, and who can make changes.
Custom hardware allows us to provide new features, capabilities, and performance not readily available in off-the-shelf components. These changes allow higher assurance use cases like two-factor authentication, medical device control, P2P payments, and others that we will help develop down the road.
As more of our lives are bound up in our phones, keeping those phones secure and trustworthy is increasingly important. Google takes that responsibility seriously. Titan M is just the latest step in our continuing efforts to improve the privacy and security of all our users.

Posted in Android Security | Comments (0)