17 Oct 2018

feedAndroid Developers Blog

Building a Titan: Better security through a tiny chip

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

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:

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.

17 Oct 2018 5:52pm GMT

16 Oct 2018

feedAndroid Developers Blog

Modern background execution in Android

Posted by Luiz Gustavo Martins, Partner Developer Advocate, Partner DevRel

This is the third in a series of blog posts in which outline strategies and guidance in Android with regard to power.

Over the years, executing background tasks on Android has evolved. To write modern apps, it's important to learn how to run your background tasks in modern fashion.

When is an app in the background?

Before understanding what background execution is, we need to have a clear view of when Android understands an app to be in the foreground. An app is considered to be in the foreground if any of the following is true:

If none of those conditions is true, the app is considered to be in the background.

Background execution changes

Running tasks in the background consumes a device's limited resources, like RAM and battery. This might result in a bad user experience. For example, background tasks may degrade the battery life of the device or the user may experience poor device performance at times such as watching a video, playing a game, using the camera.

To improve battery life and give a better user experience, Android has evolved over several releases to establish limits on background execution. These limits include:

Use cases and solutions

Deciding which tools to use to implement background execution requires the developer to have a clear understanding of what they want to accomplish, and under which restrictions. This flowchart can help you make a decision:

In Summary:

Use Case Examples Solution
Guaranteed execution of deferrable work
  • Upload logs to your server
  • Encrypt/Decrypt content to upload/download
WorkManager
A task initiated in response to an external event
  • Syncing new online content like email
FCM + WorkManager
Continue user-initiated work that needs to run immediately even if the user leaves the app
  • Music player
  • Tracking activity
  • Transit navigation
Foreground Service
Trigger actions that involve user interactions, like notifications at an exact time.
  • Alarm clock
  • Medicine reminder
  • Notification about a TV show that is about to start
AlarmManager

Use background execution judiciously so that you can build cool apps that delight users while saving their battery. If you need more information on executing background tasks on Android, there's great content at the Android developer site.

Note: WorkManager is still in public preview. If you need an alternative solution right now, you should use JobScheduler, although it has limitations that don't apply to WorkManager. JobScheduler is part of the Android Framework, and only available for Android API 21 and above; WorkManager works on API 14 and above.

Acknowledgements: This series of blog posts is produced in collaboration between the Android Framework and DevRel teams

16 Oct 2018 5:01pm GMT

12 Oct 2018

feedAndroid Developers Blog

Get ready for #AndroidDevSummit, kicking off November 7!

In less than a month, we'll be kicking off Android Dev Summit 2018, broadcasting live from the Computer History Museum in Mountain View, CA on November 7 and 8. We'll have two days of deep technical sessions from the Android engineering team, with over 30 sessions livestreamed. The first wave of sessions were just posted to the website: check them out and start planning.

The summit kicks off on November 7 at 10AM PST with the keynote, where you'll hear directly from Dave Burke and others on the present and future of Android development. From there, we'll dive into two tracks (and two days!) of deep technical content from the Google engineering team, on topics such as Android Pie, Android Studio, Kotlin, Android Jetpack, Google Play and more. We'll also have demos and office hours for those attending in person; more on that in the coming weeks!

We received a ton of interest from developers looking to attend in person; if you were one of those who expressed interest but didn't receive a ticket, we've already reached out to you and shared this news, but we want to apologize again that we weren't able to find you a spot. Rest assured, though, that we're still doing all that we can to free up more tickets, and we'll be reaching out to folks we're able to accommodate in the lead-up to the show. And if you did receive a ticket but your plans have changed and you're no longer able to attend, please let us know by sending an email to android-dev-summit@google.com, and we'll free up your spot for others on the waitlist.

If you can't join in person, you can always join us online: we'll be livestreaming all of the sessions on the Android Dev Summit website and making them available on YouTube throughout the conference to watch at your own pace. Plus, we'll be sharing updates directly from the Computer History Museum to our social channels, so be sure to follow along!

12 Oct 2018 8:15pm GMT