Dissecting Lollipop’s Smart Lock

Android 5.0 (Lollipop) has been out for a while now, and most of its new features have been introduced, benchmarked, or complained about extensively. The new release also includes a number of of security enhancements, of which disk encryption has gotten probably the most media attention. Smart Lock (originally announced at Google I/O 2014), which allows bypassing the device lockscreen when certain environmental conditions are met, is probably the most user-visible new security feature. As such, it has also been discussed and blogged about extensively. However, because Smart Lock is a proprietary feature incorporated in Google Play Services, not many details about its implementation or security level are available. This post will look into the Android framework extensions that Smart Lock is build upon, show how to use them to create your own unlock method, and finally briefly discuss its Play Services implementation.

Trust agents

Smart Lock is build upon a new Lollipop feature called trust agents. To quote from the framework documentation, a trust agent is a ‘service that notifies the system about whether it believes the environment of the device to be trusted.’  The exact meaning of ‘trusted’ is up to the trust agent to define. When a trust agent believes it can trust the current environment, it notifies the system via a callback, and the system decides how to relax the security configuration of the device.  In the current Android incarnation, being in a trusted environment grants the user the ability to bypass the lockscreen.

Trust is granted per user, so each user’s trust agents can be configured differently. Additionally, trust can be granted for a certain period of time, and the system automatically reverts to an untrusted state when that period expires. Device administrators can set the maximum trust period trust agents are allowed to set, or disable trust agents altogether. 

Trust agent API

Trust agents are Android services which extend the TrustAgentService base class (not available in the public SDK). The base class provides methods for enabling the trust agent (setManagingTrust()), granting and revoking trust (grant/revokeTrust()), as well as a number of callback methods, as shown below.

public class TrustAgentService extends Service {

public void onUnlockAttempt(boolean successful) {

public void onTrustTimeout() {

private void onError(String msg) {
Slog.v(TAG, "Remote exception while " + msg);

public boolean onSetTrustAgentFeaturesEnabled(Bundle options) {
return false;

public final void grantTrust(
final CharSequence message,
final long durationMs, final boolean initiatedByUser) {

public final void revokeTrust() {

public final void setManagingTrust(boolean managingTrust) {

public final IBinder onBind(Intent intent) {
return new TrustAgentServiceWrapper();


To be picked up by the system, a trust agent needs to be declared in AndroidManifest.xml with an intent filter for the android.service.trust.TrustAgentService action and require the BIND_TRUST_AGENT permission, as shown below. This ensures that only the system can bind to the trust agent, as the BIND_TRUST_AGENT permission requires the platform signature. A Binder API, which allows calling the agent from other processes, is provided by the TrustAgentService base class. 

<manifest ... >

<uses-permission android:name="android.permission.CONTROL_KEYGUARD" />
<uses-permission android:name="android.permission.PROVIDE_TRUST_AGENT" />

<application ...>
<service android:exported="true"
<action android:name="android.service.trust.TrustAgentService"/>
<category android:name="android.intent.category.DEFAULT"/>

<meta-data android:name="android.service.trust.trustagent"

The system Settings app scans app packages that match the intent filter shown above, checks if they hold the PROVIDE_TRUST_AGENT signature permission (defined in the android package) and shows them in the Trust agents screen (Settings->Security->Trust agents) if all required conditions are met. Currently only a single trust agent is supported, so only the first matched package is shown. Additionally, if the manifest declaration contains a <meta-data> tag that points to an XML resource that defines a settings activity (see below for an example), a menu entry that opens the settings activity is injected into the Security settings screen.

<trust-agent xmlns:android="http://schemas.android.com/apk/res/android"
android:title="Ghetto Unlock"
android:summary="A bunch of unlock triggers"
android:settingsActivity=".GhettoTrustAgentSettings" />

Here’s how the Trusted agents screen might look like when a system app that declares a trusted agent is installed.

Trust agents are inactive by default (unless part of the system image), and are activated when the user toggles the switch in the screen above. Active agents are ultimately managed by the system TrustManagerService which also keeps a log of trust-related events. You can get the current trust state and dump the even log using the dumpsys command as shown below.

$ adb shell dumpsys trust
Trust manager state:
User "Owner" (id=0, flags=0x13) (current): trusted=0, trustManaged=1
Enabled agents:
bound=1, connected=1, managingTrust=1, trusted=0
#0 12-24 10:42:01.915 TrustTimeout: agent=GhettoTrustAgent
#1 12-24 10:42:01.915 TrustTimeout: agent=GhettoTrustAgent
#2 12-24 10:42:01.915 TrustTimeout: agent=GhettoTrustAgent

Granting trust

Once a trust agent is installed, a trust grant can be triggered by any observable environment event, or directly by the user (for example, by via an authentication challenge). An often requested, but not particularly secure (unless using a WPA2 profile that authenticates WiFi access points), unlock trigger is connecting to a ‘home’ WiFi AP. This feature can be easily implemented using a broadcast receiver that reacts to android.net.wifi.STATE_CHANGE (see sample app; based on the sample in AOSP). Once a ‘trusted’ SSID is detected, the receiver only needs to call the grantTrust() method of the trust agent service. This can be achieved in a number of ways, but if both the service and the receiver are in the same package, a straightforward way is to use a LocalBroadcastManager (part of the support library) to send a local broadcast, as shown below.

static void sendGrantTrust(Context context,
String message,
long durationMs,
boolean initiatedByUser) {
Intent intent = new Intent(ACTION_GRANT_TRUST);
intent.putExtra(EXTRA_MESSAGE, message);
intent.putExtra(EXTRA_DURATION, durationMs);
intent.putExtra(EXTRA_INITIATED_BY_USER, initiatedByUser);

// in the receiver
public void onReceive(Context context, Intent intent) {
if (WifiManager.NETWORK_STATE_CHANGED_ACTION.equals(intent.getAction())) {
WifiInfo wifiInfo = (WifiInfo) intent

// ...
if (secureSsid.equals(wifiInfo.getSSID())) {
GhettoTrustAgent.sendGrantTrust(context, "GhettoTrustAgent::WiFi",

This will call the TrustAgentServiceCallback installed by the system lockscreen and effectively set a per-user trusted flag. If the flag is true, the lockscreen implementation allows the keyguard to be dismissed without authentication. Once the trust timeout expires, the user must enter their pattern, PIN or password in order to dismiss the keyguard. The current trust state is displayed at the bottom of the keyguard as a padlock icon: when unlocked, the current environment is trusted; when locked, explicit authentication is required. The user can also manually lock the device by pressing the padlock, even if an active trust agent currently has trust.

NFC unlock

As discussed in a previous post, implementing NFC unlock in previous Android versions was possible, but required some modifications to the system NFCService, because the NFC controller was not polled while the lockscreen is displayed. In order to make implementing NFC unlock possible, Lollipop introduces several hooks into the NFCService, which allow NFC polling on the lockscreen. If a matching tag is discovered, a reference to a live Tag object is passed to interested parties. Let’s look into the how this is implementation in a bit more detail.

The NFCAdapter class has a couple of new (hidden) methods that allow adding and removing an NFC unlock handler (addNfcUnlockHandler() and removeNfcUnlockHandler(), respectively). An NFC unlock handler is an implementation of the NfcUnlockHandler interface shown below.

interface NfcUnlockHandler {
public boolean onUnlockAttempted(Tag tag);

When registering an unlock handler you must specify not only the NfcUnlockHandler object, but also a list of NFC technologies that should be polled for at the lockscreen. Calling the addNfcUnlockHandler() method requires the WRITE_SECURE_SETTINGS signature permission.

Multiple unlock handlers can be registered and are tried in turn until one of them returns true from onUnlockAttempted(). This terminates the NFC unlock sequence, but doesn’t actually dismiss the keyguard. In order to unlock the device, an NFC unlock handler should work with a trust agent in order to grant trust. Judging from NFCService‘s commit log, this appears to be a fairly recent development: initially, the Settings app included functionality to register trusted tags, which would automatically unlock the device (based on the tag’s UID), but this functionality was removed in favour of trust agents.

Unlock handlers can authenticate the scanned NFC tag in a variety of ways, depending on the tag’s technology. For passive tags that contain fixed data, authentication typically relies either on the tag’s unique ID, or on some shared secret written to the tag. For active tags that can execute code, it can be anything from an OTP to full-blown multi-step mutual authentication. However, because NFC communication is not very fast, and most tags have limited processing power, a simple protocol with few roundtrips is preferable. A simple implementation that requires the tag to sign a random value with its RSA private key, and then verifies the signature using the corresponding public key is included in the sample application. For signature verification to work, the trust agent needs to be initialized with the tag’s public key, which in this case is imported via the trust agent’s settings activity shown below.

Smart Lock

‘Smart Lock’ is just the marketing name for the GoogleTrustAgent which is included in Google Play Services (com.google.android.gms package), as can be seen from the dumpsys output below.

$ adb shell dumpsys trust
Trust manager state:
User "Owner" (id=0, flags=0x13) (current): trusted=1, trustManaged=1
Enabled agents:
bound=1, connected=1, managingTrust=1, trusted=1

This trust agent offers several trust triggers: trusted devices, trusted places and a trusted face. Trusted face is just a rebranding of the face unlock method found in previous versions. It uses the same proprietary image recognition technology, but is significantly more usable, because, when enabled, the keyguard continuously scans for a matching face instead of requiring you to stay still while it takes and process your picture. The security level provided also remains the same — fairly low, as the trusted face setup screen warns. Trusted places is based on the geofencing technology, which has been available in Google Play services for a while. Trusted places use the ‘Home’ and ‘Work’ locations associated with your Google account to make setup easier, and also allows for registering a custom place based on the current location or any coordinates selectable via Google Maps. As a helpful popup warns, accuracy cannot be guaranteed, and the trusted place range can be up to 100 meters. In practice, the device can remain unlocked for a while even when this distance is exceeded.

Trusted devices supports two different types of devices at the time of this writing: Bluetooth and NFC. The Bluetooth option allows the Android device to remain unlocked while a paired Bluetooth device is in range. This features relies on Bluetooth’s built-in security mechanism, and as such its security depends on the paired device. Newer devices, such as Android Wear watches or the Pebble watch, support Secure Simple Pairing (Security Mode 4), which uses Elliptic Curve Diffie-Hellman (ECDH) in order to generate a shared link key. During the paring process, these devices display a 6-digit number based on a hash of both devices’ public keys in order to provide device authentication and protect against MiTM attacks (a feature called numeric comparison). However, older wearables (such as the Meta Watch), Bluetooth earphones, and others are also supported. These previous-generation devices only support Standard Pairing, which generates authentication keys based on the device’s physical address and a 4-digit PIN, which is usually fixed and set to a well-know value such as ‘0000’ or ‘1234’. Such devices can be easily impersonated.

Google’s Smart Lock implementation requires a persistent connection to a trusted device, and trust is revoked once this connection is broken (Update: apparently a trusted connection can be established without a key on Android < 5.1 ). However, as the introductory screen (see below) warns, Bluetooth range is highly variable and may extend up to 100 meters. Thus while the ‘keep device unlocked while connected to trusted watch on wrist’ use case makes a lot of sense, in practice the Android device may remain unlocked even when the trusted Bluetooth device (wearable, etc.) is in another room.

As discussed earlier, an NFC trusted device can be quite flexible, and has the advantage that, unlike Bluetooth, proximity is well defined (typically not more than 10 centimeters). While Google’s Smart Lock seems to support an active NFC device (internally referred to as the ‘Precious tag’), no such device has been publicly announced yet. If the Precious is not found, Google’s NFC-based trust agent falls back to UID-based authentication by saving the hash of the scanned tag’s UID (tag registration screen shown below). For the popular NFC-A tags (most MIFARE variants) this UID is 4 or 7 bytes long (10-byte UIDs are also theoretically supported). While using the UID for authentication is a fairly wide-spread practice, it was originally intended for anti-collision alone, and not for authentication. 4-byte UIDs are not necessarily unique and may collide even on ‘official’ NXP tags. While the specification requires 7-byte IDs to be both unique (even across different manufacturers) and read-only, cards with a rewritable UID do exists, so cloning a MIFARE trusted tag is quite possible. Tags can also be emulated with a programmable device such as the Proxmark III. Therefore, the security level provided by UID-based authentication is not that high.


Android 5.0 (Lollipop) introduces a new trust framework based on trust agents, which can notify the system when the device is in a trusted environment. As the system lockscreen now listens for trust events, it can change its behaviour based on the trust state of the current user. This makes it easy to augment or replace the traditional pattern/PIN/password user authentication methods by installing  trust agents. Trust agent functionality is currently only available to system applications, and Lollipop can only support a single active trust agent. Google Play Services provides several trust triggers (trustlets) under the name ‘Smart Lock’ via its trust agent. While they can greatly improve device usability, none of the currently available Smart Lock methods are particularly precise or secure, so they should be used with care.

What is Ransomware?

Imagine that you want to pull up a certain file on your computer. You click on the file and suddenly a notice flashes on your screen saying your computer has been compromised and in order to get your files back, you need to pay up some money. This, ladies and gentlemen, is ransomware, a nasty type of malware that, unfortunately, hackers love to use.

Ransomware is malicious software created by a hacker to restrict access to your device and demand a fee to be paid to the hacker in order to give you back access to your device. It can prevent you from using your computer or mobile device, opening your files, or running certain applications like your browser. Or it could lock down your photos, documents, videos on your mobile phone or PC and hold them hostage until you pay the ransom.

Users unknowingly download ransomware from malicious by clicking on email attachments or visiting infected websites, also known as drive-by downloads . There are several ways hackers use ransomware to extort money from users. One, the hackers pretend they are a law enforcement agency and claim that you have downloaded illegal content and demand a fine to pay for this violation. Another popular trick is a message that claims your Windows installation is counterfeit and requires activation or that your security software is out of date or not working.

If you download ransomware, you must remove it before you can access your device again. You can use security software or clean out your disk drive. If you have an Android phone, you can reboot your phone in Safe Mode. Whatever you do, don’t pay the ransom, as it doesn’t always guarantee you will get access to your device again.

It’s always better to prepare than repair. Here are a few tips for preventing ransomware from getting on your digital devices.

  • Backup your files. Then, if a ransomware attack occurs, you can wipe your disk drive clean and restore the data from the backup.
  • Think twice. Don’t open links or attachments from people you don’t know.
  • Use a web advisor. Hackers use malicious websites to spread ransomware. A web advisor, like McAfee® SiteAdvisor® will let you know what links are malicious or not.
  • Install comprehensive security software.  McAfee LiveSafe™ service includes a firewall and anti-spam filter to protect your computers, mobile phones and tablets from ransomware. If you already have your computers covered, make sure you still protect your mobile devices with our free McAfee® Mobile Security for Android or iOS.

Have a happy holiday!


RobertSicilianoRobert Siciliano is an Online Security Expert to McAfee. He is the author of 99 Things You Wish You Knew Before Your Mobile was Hacked!  Disclosures.


The post What is Ransomware? appeared first on McAfee Blogs.

Scammers Sell Free Mobile Flash Player Using YouTube Feeds

Scammers love to sell “Flash Player” for Android to careless users who are easily deceived. Although a series of these scam apps were deleted from the official Android app store after our recent report, malicious apps such as Android/Fladstep have reappeared in the store. This time scammers are promoting their sales tools using the RSS feeds from the world’s most popular movie distribution site, YouTube, to impersonate legitimate apps.


After being launched, the malicious app shows a playlist of video movies with titles related to Flash Player for Android devices.


This playlist of movies is actually retrieved from YouTube, from its published RSS feeds. We can bet that these movies do not belong to the attacker.


The playlist appears to start with advice about Flash Player. However, the scammer first replaces all the movie links with links to fraudulent sales websites, which require visitors to pay money for the fake Flash Player. (Adobe’s version is free.) We have seen these websites before.


If a user selects “Yes” on the download site, a familiar, suspicious page appears. Finally the user is redirected to a PayPal page. Unlike the previously reported case in which the scammer offered the free Flash Player for €5, this time the scammer has doubled the price, to €10.


Of course, you don’t need to pay for this bogus free version of Flash Player for Android; you should directly download and install it from Adobe. If it appears you have been tricked into buying a maliciously crafted version of Flash Player, you can simply close the app or browser if you see the preceding screen.

The post Scammers Sell Free Mobile Flash Player Using YouTube Feeds appeared first on McAfee Blogs.

WhatsApp with End-to-End Encryption?

Throughout the past year, many mobile messaging apps have come under fire for inherent security vulnerabilities. This month, WhatsApp (one of the largest globally used messaging apps) has gone to great lengths to ensure users’ personal data is protected. Their recent deployment of end-to-end encryption, one of the largest to date, poses the question: is the security of mobile messaging apps about to change?

Last year, we reported on a security flaw that had been plaguing WhatsApp users. At the time, researchers had discovered a weakness in the app’s encryption that made it possible for cybercriminals to read plain text communications sent through the app.

It was found that WhatsApp was using the same key to decode the encrypted message on both sides of a conversation. When the same key is used for both the sender and receiver’s messages, it makes it exponentially easier for someone to intercept messages sent via unsecured Wi-Fi networks and pull the actual text out of the encrypted data. Therefore, hackers could potentially see sensitive information such as addresses or personal photos, sent via WhatsApp.

WhatsApp has since taken measures to remedy this security flaw and is in the midst of rolling out increased privacy features for Android WhatsApp users.

This new security comes in the form of end-to-end encryption added by default for one-to-one text messages sent through the app. Although this feature is currently only available for Android users and does not yet apply to group messages, photos, or videos, WhatsApp Inc. plans to rollout end-to-end encryption across all platforms in the near future.

So why are privacy advocates rejoicing over end-to-end encryption, and why should users care?

End-to-end encryption provides an added level of security that makes it nearly impossible for anyone other than the intended recipients of the message(s) to read the contents of the message.

WhatsApp’s deployment of end-to-end encryption is one of the largest implementations across a mobile messaging platform to date. Android users can now breathe a little easier as it is highly unlikely that their text messages sent through WhatsApp will be seen by unwanted eyes.

If you plan to use WhatsApp for group messages, to send photos and videos, or are using it on a mobile device that is not yet protected by end-to-end encryption, it’s best to practice some key mobile security habits to ensure your information stays protected.

  • Avoid using unsecured Wi-Fi networks to send personal information. Free and open public Wi-Fi is great in theory, but this openness comes with a downside. Because these networks are used by a large number of people, they are often a hacker’s favorite target. Hackers can easily intercept data such as photos, messages, passwords and more, leaving unsuspected users in the lurch.
  • Don’t put sensitive information in the hands of a mobile messaging app. It’s a good rule of thumb to keep sensitive information, in general, off of your mobile devices and messaging apps. Phones can be lost or stolen and security flaws of apps exploited so you should never trust your mobile device to keep banking information, social security numbers or addresses secure.
  • Have comprehensive security software installed on your mobile device. McAfee® Mobile Security, free for Android and iOS, offers a variety of protections, including one that will alert you if you are about to connect to an unsecured Wi-Fi network from your Android device.

And as always, to keep up with the latest security threats, make sure to follow @IntelSec_Home on Twitter and like us on Facebook.


The post WhatsApp with End-to-End Encryption? appeared first on McAfee Blogs.

Should You Use Near-Field Communications?

Have you ever wondered what kind of superpower you’d have? I’ve always wanted to send messages and ideas with my mind to others. My dream can sort of come true with near-field communications (NFC).

You’ve might not have heard of NFC, but if you have a smartphone, there’s a good chance you’ve used it. If you have ever used Apple Pay or bumped your Galaxy smartphone with your buddy’s to send pictures, you have used NFC. By definition, NFC allows smartphones and similar devices to establish radio communication with each other by bringing them close together, usually no more than a few inches or centimeters. It’s an exciting technology that has a lot of promise, but there are a few concerns too. Let’s take a closer look at the pros and cons of NFC.


  • Convenient. In a busy digital world, people like transactions that are quick and easy. That is one of NFC’s greatest strengths. No more digging around a wallet or purse for a debit or credit card, all you need is your phone. The technology is intuitive—bring your phone close to the reader and a simple touch and bam! Transaction completed. Think about how much time that would save at coffee shops, grocery stores, etc.
  • Versatile. NFC can be used for many situations and in many different industries. In the future, NFC technology could allow you to use your phone to unlock your car, access public transportation, or launch applications depending on where you are (bedside table, work desk, etc.).
  • Safe. If your wallet is stolen, thieves immediately have access to your information. With a smartphone, your data can be protected by a password and/or PIN. But the biggest strength is that with NFC payment, retailers no longer have access to your credit card information.


  • Security. Although NFC technology is more secure than magnetic strip credit cards, there are still security concerns. As people use this technology to purchase items or access cars, there is more incentive for hackers to break into smartphones to steal financial and personal information.
  • Usability. NFC will only succeed if merchants and companies adopt it as the way of the mobile commerce future. Although the technology is consumer-friendly, it is expensive to purchase and install related equipment. And it still may take years before there are enough smartphone users for NFC to add enough value to merchants to implement.


NFC is a new and blossoming technology with lots of potential. Whether you decide to use it or not, there are always things you can do to keep your personal and financial information safe. For tips and ideas, check out Intel Security’s Facebook page and Twitter feed.

The post Should You Use Near-Field Communications? appeared first on McAfee Blogs.