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.

Dyre Recruiting CareerBuilder.com Users

Job seekers beware. A login-credential-stealing Trojan is trying to steal your email address and password when you access CareerBuilder.com.

We recently reported on the evolution of Dyre as observed by ThreatTrack Security Labs. The latest developments to this data-stealing Trojan, also known as Dyreza, is an expanded list of targeted sites, including the addition of several more financial institutions and CareerBuilder.com, a leading job search site.Dyre CareerBuilder.com

Users with infected PCs logging on to CareerBuilder.com are at risk of having their email addresses and associated passwords stolen. Cybercriminals deploying Dyre can potentially use this information to either access users’ accounts to collect additional personal information or use email addresses and associated passwords in attempts to break into other online accounts – assuming that many users continue to re-use the same password for multiple accounts and online services. Moreover, the personal information available through a resume (address, phone numbers, previous employment, etc.) can be packaged and leveraged for convincing phishing schemes.

The latest list of sites targeted by Dyre is available here.

Click here for a dynamic malware analysis of a recent Dyre sample.

Defend Yourself Against Dyre

Ensure your antivirus is up-to-date to protect yourself from malicious threats. VIPRE detects Dyre as Win32!MalwareDrop.

Make sure you know how Dyre is being distributed, most commonly by malicious spam as reported here. Consumers should always be cautious about what they click in email, and if there is any doubt about a warning, special offer or request for private information, contact the bank, retailer or service provider directly by phone to confirm.

Credit: Matthew Mesa, Malware Researcher, ThreatTrack Security Labs

Share via email Share

ThreatTrack Security Labs
About Author

ThreatTrack Security Labs is the power behind the malware analysis, detection and remediation technologies developed by ThreatTrack Security. From facilities in the United States and the Philippines, our team of cybersecurity professionals, malware researchers, engineers and software developers work around the clock to discover and combat Advanced Persistent Threats, targeted attacks, Zero-days and other sophisticated malware. The company develops advanced cybersecurity solutions that Expose, Analyze and Eliminate the latest malicious threats, including its ThreatSecure advanced threat detection and remediation platform, ThreatAnalyzer malware behavioral analysis sandbox, ThreatIQ real-time threat intelligence service, and VIPRE business antivirus endpoint protection. Learn more about ThreatTrack Security.