Category Archives: Android

Happy 5th Birthday Android!

From Cupcake to Jelly Bean, the last five years have brought many different flavors of smart phones to Android users. People can’t seem to get enough of these delicious digital treats, grossing over 500 million active Android devices worldwide and expecting to reach one billion at some point in 2013.

With its increasing popularity, it’s no surprise that the Android OS is the most attractive target for writers of mobile malware. From April to June 2012, McAfee Labs found that practically all new mobile malware was directed at the Android platform. The attacks included SMS-sending malware, mobile botnets, spyware and destructive Trojans.

Mobile threats continue to evolve as writers of mobile malware become more advanced in their practice. They are looking to steal consumer and business data from unprotected devices ranging from customer lists to personal financial information. These threats are growing in their sophistication and continue to find vulnerabilities through users’ pictures and social media applications.

In the last few months McAfee Labs has uncovered the latest emerging threats that Android users should be watchful for:

“Drive by downloads:” From April to June 2012 there was an emergence of mobile Android “drive by downloads.” These mobile drive by downloads drop dangerous malware on your phone when a user visit a malicious site. Once the user tricked into running the app it steals the personal data stored on your phone.

Twikabot.A: A new botnet client, Android/Twikabot.A, uses Twitter as a means of controlling and executing attacks. The user unexpectedly downloads the malware onto their phone after clicking on a Twitter picture link or message. Once downloaded the attacker can, tweet infected links to followers, install additional malware, delete files and leave the back door open for other attackers.

Stamper. A: Malware authors have evolved the Android/Moghava.A into a new Trojan threat known as Android/Stamper.A by simply changing a few lines of the original malicious code. This damages photos by photo-bombing the user’s pictures with an image of a baby. Users looking for a voting app for the Japanese female pop band, AKB48, unknowingly download the Trojan. The baby picture is from an ad campaign originally targeted at male fans of the band, posing the question “if you and a member of AKB48 had a kid, what would it look like?” The ad campaign put together a sumo wrestler and band member and featured an image of what that ensuing baby would look like. While the Trojan doesn’t change anything except the image and a few strings in the image stamping, users expecting to get results from the pop group’s fan site instead have all their pictures damaged with a photo-bombing baby.

McAfee Labs recommends that all Android users take appropriate precautions to safeguard their devices and personal information. For more information on how Android users can protect their devices visit mcafee.com/us/mms/. You can also download a free guide on mobile security from our Security Advice Center.

The post Happy 5th Birthday Android! appeared first on McAfee Blogs.

Android online account management

Our recent posts covered NFC and the secure element as supported in recent Android versions, including community ones. In this two-part series we will take a completely different direction: managing online user accounts and accessing Web services. We will briefly discuss how Android manages user credentials and then show how to use cached authentication details to log in to most Google sites without requiring additional user input. Most of the functionality we shall discuss is hardly new — it has been available at least since Android 2.0. But while there is ample documentation on how to use it, there doesn’t see to be a ‘bigger picture’ overview of how the pieces are tied together. This somewhat detailed investigation was prompted by trying to develop an app for a widely used Google service that unfortunately doesn’t have an official API and struggling to find a way to login to it using cached Google credentials. More on this in the second part, let’s first see how Android manages accounts for online services.

Android account management

Android 2.0 (API Level 5, largely non-existent, because it was quickly succeeded by 2.0.1, Level 6), introduced the concept of centralized account management with a public API. The central piece in the API is the AccountManager class which, quote: ‘provides access to a centralized registry of the user’s online accounts. The user enters credentials (user name and password) once per account, granting applications access to online resources with “one-click” approval.’ You should definitely read the full documentation of the class, which is quite extensive, for more details. Another major feature of the class is that it lets you get an authentication token for supported accounts, allowing third party applications to authenticate to online services without needing to handle the actual user password (more on this later). It also has a whole of 5 methods that allow you to get an authentication token, all but one with at least 4 parameters, so finding the one you need might take some time, with yet some more to get the parameters right. It might be a good idea to start with the synchronous blockingGetAuthToken() and work your way from there once you have a basic working flow. On some older Android versions, the AccountManager would also monitor your SIM card and wipe cached credentials if you swapped cards, but fortunately this ‘feature’ has been removed in Android 2.3.4.

The AccountManager, as most Android system API’s, is just a facade for the AccountManagerService which does the actual work. The service doesn’t provide an implementation for any particular form of authentication though. It only acts as a coordinator for a number of pluggable authenticator modules for different account types (Google, Twitter, Exchange, etc.). The best part is that any application can register an authentication module by implementing an account authenticator and related classes, if needed. Android Training has a tutorial on the subject that covers the implementation details, so we will not discuss them here. Registering a new account type with the system lets you take advantage of a number of Android infrastructure services:

  • centralized credential storage in a system database
  • ability to issue tokens to third party apps
  • ability to take advantage of Android’s automatic background synchronization

One thing to note is that while credentials (usually user names and passwords) are stored in a central database (/data/system/accounts.db or /data/system/user/0/accounts.db on Jelly Bean and later for the first system user), that is only accessible to system applications, credentials are in no way encrypted — that is left to the authentication module to implement as necessary. If you have a rooted device (or use the emulator) listing the contents of the accounts table might be quite instructive: some of your passwords, especially for the stock Email application, will show up in clear text. While the AccountManger has a getPassword() method, it can only be used by apps with the same UID as the account’s authenticator, i.e., only by classes in the same app (unless you are using sharedUserId, which is not recommended for non-system apps). If you want to allow third party applications to authenticate using your custom accounts, you have to issue some sort of authentication token, accessible via one of the many getAuthToken() methods. Once your account is registered with Android, if you implement an additional sync adapter, you can register to have it called at a specified interval and do background syncing for you app (one- or two-way), without needing to manage scheduling yourself. This is a very powerful feature that you get practically for free, and probably merits its own post. As we now have a basic understanding of authentication modules, let’s see how they are used by the system.

As we mentioned above, account management is coordinated by the AccountManagerService. It is a fairly complex piece of code (about 2500 lines in JB), most of the complexity stemming from the fact that it needs to communicate with services and apps that span multiple processes and threads within each process, and needs to take care of synchronization and delivering results to the right thread. If we abstract out the boilerplate code, what it does on a higher level is actually fairly straightforward:

  • on startup it queries the PackageManager to find out all registered authenticators, and stores references to them in a map, keyed by account type
  • when you add an account of a particular type, it saves its type, username and password to the accounts table
  • if you get, set or reset the password for an account, it accesses or updates the accounts table accordingly
  • if you get or set user data for the account, it is fetched from or saves to the extras table
  • when you request a token for a particular account, things become a bit more interesting:
    • if a token with the specified type has never been issued before, it shows a confirmation activity asking (see screenshot below) the user to approve access for the requesting application. If they accept, the UID of the requesting app and the token type are saved to the grants table.
    • if a grant already exits, it checks the authtoken table for tokens matching the request. If a valid one exists, it is returned.
    • if a matching token is not found, it finds the authenticator for the specified account type in the map and calls its getAuthToken() method to request a token. This usually involves the authenticator fetching the username and password from the accounts table (via the getPassword() method) and calling its respective online service to get a fresh token. When one is returned, it gets cached in the authtokens table and then returned to the requesting app (usually asynchronously via a callback).
  • if you invalidate a token, it gets deleted from the authtokens table
Now that we know how Android’s account management system works, let’s see how it is implemented for the most widely used account type.

Google account management

    Usually the first thing you do when you turn on your brand new (or freshly wiped) ‘Google Experience’ Android device is to add a Google account. Once you authenticate successfully, you are offered to sync data from associated online services (GMail, Calendar, Docs, etc.) to your device. What happens behinds the scenes is that an account of type ‘com.google’ is added via the AccountManager, and a bunch of Google apps start getting tokens for the services they represent. Of course, all of this works with the help of an authentication provider for Google accounts. Since it plugs in the standard account management framework, it works by registering an authenticator implementation and using it involves the sequence outlined above. However, it is also a little bit special. Three main things make it different:

    • it is not part of any particular app you can install, but is bundled with the system
    • a lot of the actual functionality is implemented on the server side
    • it does not store passwords in plain text on the device

    If you have ever installed a community ROM built off AOSP code, you know that in order to get GMail and other Google apps to work on your device, you need a few bits not found in AOSP. Two of the required pieces are the Google Services Framework (GSF) and the Google Login Service (GLS). The former provides common services to all Google apps such as centralized settings and feature toggle management, while the latter implements the authentication provider for Google accounts and will be the topic of this section.

    Google provides a multitude of online services (not all of which survive for long), and consequently a bunch of different methods to authenticate to those. Android’s Google Login Service, however doesn’t call those public authentication API’s directly, but via a dedicated online service, which lives at android.clients.google.com. It has endpoints both for authentication and authorization token issuing, as well as data feed (mail, calendar, etc.) synchronization, and more. As we shall see, the supported methods of authentication are somewhat different from those available via other public Google authentication API’s. Additionally, it supports a few ‘special’ token types that greatly simplify some complex authentication flows.

    All of the above is hardly surprising: when you are dealing with online services it is only natural to have as much as possible of the authentication logic on the server side, both for ease of maintenance and to keep it secure. Still, to kick start it you need to store some sort of credentials on the device, especially when you support background syncing for practically everything and you cannot expect people to enter them manually. On-device credential management is one of the services GLS provides, so let’s see how it is implemented. As mentioned above, GLS plugs into the system account framework, so cached credentials, tokens and associated extra data are stored in the system’s accounts.db database, just as for other account types. Inspecting it reveals that Google accounts have a bunch of Base64-encoded strings associated with them. One of the user data entries (in the extras table) is helpfully labeled sha1hash (but does not exist on all Android versions) and the password (in the accounts table) is a long string that takes different formats on different Android versions. Additionally, the GSF database has a google_login_public_key entry, which when decoded suspiciously resembles a 1024-bit RSA public key. Some more experimentation reveals that credential management works differently on pre-ICS and post-ICS devices. On pre-ICS devices, GLS stores an encrypted version of your password and posts it to the server side endpoints both when authenticating for the first time (when you add the account) and when it needs to have a token for a particular service issued. On post-ICS devices, it only posts the encrypted password the first time, and gets a ‘master token’ in exchange, which is then stored on the device (in the password column of the accounts database). Each subsequent token request uses that master token instead of a password.

    Let’s look into the cached credential strings a bit more. The encrypted password is 133 bytes long, and thus it is a fair bet that it is encrypted with the 1024-bit (128 bytes) RSA public key mentioned above, with some extra data appended. Adding multiple accounts that use the same password produces different password strings (which is a good thing), but the first few bytes are always the same, even on different devices. It turns out those identify the encryption key and are derived by hashing its raw value and taking the leading bytes of the resulting hash. At least from our limited sample of Android devices, it would seem that the RSA public key used is constant both across Android versions and accounts. We can safely assume that its private counterpart lives on the server side and is used to decrypt sent passwords before performing the actual authentication. The padding used is OAEP (with SHA1 and MGF1), which produces random-looking messages and is currently considered secure (at least when used in combination with RSA) against most advanced cryptanalysis techniques. It also has quite a bit of overhead, which in practice means that the GLS encryption scheme can encrypt at most 86 bytes of data. The outlined encryption scheme is not exactly military-grade and there is the issue of millions of devices most probably using the same key, but recovering the original password should be sufficiently hard to discourage most attackers. However, let’s not forget that we also have a somewhat friendlier SHA1 hash available. It turns out it can be easily reproduced by ‘salting’ the Google account password with the account name (typically GMail address) and doing a single round of SHA1. This is considerably easier to do and it wouldn’t be too hard to precompute a bunch of hashes based on commonly used or potential passwords if you knew the target account name.

    Fortunately, newer version of Android (4.0 and later) no longer store this hash on the device. Instead of the encrypted password+SHA1 hash combination they store an opaque ‘master token’ (most probably some form of OAuth token) in the password column and exchange it for authentication tokens for different Google services. It is not clear whether this token ever expires or if it is updated automatically. You can, however, revoke it manually by going to the security settings of your Google account and revoking access for the ‘Android Login Service’ (and a bunch of other stuff you never use while you are at it). This will force the user to re-authenticate on the device next time it tries to get a Google auth token, so it is also somewhat helpful if you ever lose your device and don’t want people accessing your email, etc. if they manage to unlock it. The service authorization token issuing protocol uses some device-specific data in addition to the master token, so obtaining only the master token should not be enough to authenticate and impersonate a device (it can however be used to login into your Google account on the Web, see the second part for details).

    Google Play Services

    Google Play Services (we’ll abbreviate it to GPS, although the actual package is com.google.android.gms, guess where the ‘M’ came from) was announced at this year’s Google I/O as an easy to use platform that offers integration with Google products for third-party Android apps. It was actually rolled out only a month ago, so it’s probably not very widely used yet. Currently it provides support for OAuth 2.0 authorization to Google API’s ‘with a good user experience and security’, as well some Google+ plus integration (sign-in and +1 button). Getting OAuth 2.0 tokens via the standard AccountManager interface has been supported for quite some time (though support was considered ‘experimental’) by using the special 'oauth2:scope' token type syntax. However, it didn’t work reliably across different Android builds, which have different GLS versions bundled and this results in slightly different behaviour. Additionally, the permission grant dialog shown when requesting a token was not particularly user friendly, because it showed the raw OAuth 2.0 scope in some cases, which probably means little to most users (see screenshot in the first section). While some human-readable aliases for certain scopes where introduced (e.g., ‘Manage your taks’ for ‘oauth2:https://www.googleapis.com/auth/tasks’), that solution was neither ideal, nor universally available. GPS solves this by making token issuing a two-step process (newer GLS versions also use this process):
    1. the first request is much like before: it includes the account name, master token (or encrypted password pre-ICS) and requested service, in the 'oauth2:scope' format. GPS adds two new parameters: requesting app package name and app signing certificate SHA1 hash (more on this later). The response includes some human readable details about the requested scope and requesting application, which GPS shows in a permission grant dialog like the one shown below.
    2. if the users grants the permission, this decision is recorded in the extras table in a proprietary format which includes the requesting app’s package name, signing certificate hash, OAuth 2.0 scope and grant time (note that it is not using the grants table). GPS then resends the authorization request setting the has_permission parameter to 1. On success this results in an OAuth 2.0 token and its expiry date in the response. Those are cached in the authtokens table in a similar format.
    To be able to actually use a Google API, you need to register your app’s package name and signing key in Google’s API console. The registration lets services validating the token query Google what app the token was issued for, and thus identify the calling app. This has one subtle, but important side-effect: you don’t have to embed an API key in your app and send it with every request. Of course, for a third party published app you can easily find out both the package name and the signing certificate so it is not particularly hard to get a token issued in the name of some other app (not possible via the official API, of course). We can assume that there are some additional checks on the server side that prevent this, but theoretically, if you used such a token you could, for example, exhaust a third-party app’s API request quota by issuing a bunch of requests over a short period of time. 
    The actual GPS implementation seems to reuse much of the original Google Login Service authentication logic, including the password encryption method, which is still used on pre-ICS devices (the protocol is, after all, mostly the same and it needs to be able to use pre-existing accounts). On top of that it adds better OAuth 2.0 support, a version-specific account selection dialog and some prettier and more user friendly permission grant UIs. The GPS app has the Google apps shared UID, so it can directly interact with other proprietary Google services, including GLS and GSF. This allows it, among other things, to directly get and write Google account credentials and tokens to the accounts database. As can be expected, GPS runs in a remote service that the client library you link into your app accesses. The major selling point against the legacy AccountManager API is that while its underlying authenticator modules (GLS and GSF) are part of the system, and as such cannot be updated without an OTA, GPS is an user-installable app that can be easily updated via Google Play. Indeed, it is advertised as auto-updating (much like the Google Play Store client), so app developers presumably won’t have to rely on users to update it if they want to use newer features (unless GPS is disabled altogether, of course). This update mechanism is to provide ‘agility in rolling out new platform capabilities’, but considering how much time the initial roll-out took, it is to be seen how agile the whole thing will turn out to be. Another thing to watch out for is feature bloat: besides OAuth 2.0 support, GPS currently includes G+ and AdMob related features, and while both are indeed Google-provided services, they are totally unrelated. Hopefully, GPS won’t turn into a ‘everything Google plus the kitchen sink’ type of library, delaying releases even more. With all that said, if your app uses OAuth 2.0 tokens to authenticate to Google API’s, which is currently the preferred method (ClientLogin, OAuth 1.0 and AuthSub have been officially deprecated), definitely consider using GPS over ‘raw’ AccountManager access.

    Summary

    Android provides a centralized registry of user online accounts via the AccountManager class. It lets you both get tokens for existing accounts without having to handle the actual credentials and register your own account type, if needed. Registering an account type gives you access to powerful system features, such as authentication token caching and automatic background synchronization. ‘Google experience’ devices come with built-in support for Google accounts, which lets third party apps access Google online services without needing to directly request authentication information from the user. The latest addition to this infrastructure is the recently released Google Play Services app and companion client library, which aim to make it easy to use OAuth 2.0 from third party applications. 
    We’ve now presented an overview of how the account management system works, and the next step is to show how to actually use it to access a real online service. That will be the topic of the second article in the series. 

    Android secure element execution environment

    In the previous post we gave a brief introduction of secure element (SE) support in mobile devices and showed how to communicate with the embedded SE in Android 4.x We’ll now proceed to sending some actual command to the SE in order to find out more information about its OS and installed applications. Finally, we will discuss options for installing custom applets on the SE.

    SE execution environments

    The Android SE is essentially a smart card in a different package, so most standards and protocols originally developed for smart cards apply. Let’s briefly review the relevant ones.

    Smart cards have traditionally been file system-oriented and the main role of the OS was to handle file access and enforce access permissions. Newer cards support a VM running on top of the native OS that allows for the execution of ‘platform independent’ applications called applets, which make use of a well defined runtime library to implement their functionality. While different implementations of this paradigm exists, by far the most popular one is the Java Card runtime environment (JCRE). Applets are implemented in a restricted version of the Java language and use a subset of the runtime library, which offers basic classes for I/O, message parsing and cryptographic operations. While the JCRE specification fully defines the applet runtime environment, it does not specify how to load, initialize and delete applets on actual physical cards (tools are only provided for the JCRE emulator). Since one of the main applications of smart cards are various payment services, the application loading and initialization (often referred to as ‘card personalization’) process needs to be controlled and only authorized entities should be able to alter the card’s and installed applications’ state. A specification for securely managing applets was originally developed by Visa under the name Open Platform, and is now being maintained and developed by the GlobalPlatform (GP) organization under the name ‘GlobalPlatform Card Specification‘ (GPCS). 
    The Card Specification, as anything developed by a committee, is quite extensive and spans multiple documents. Those are quite abstract at times and make for a fun read, but the gist is that the card has a mandatory Card Manager component (also referred to as the ‘Issuer Security Domain’) that offers a well defined interface for card and individual application life cycle management. Executing Card Manager operations requires authentication using cryptographic keys saved on the card, and thus only an entity that knows those keys can change the state of the card (one of OP_READY, INITIALIZED, SECURED, CARD_LOCKED or TERMINATED) or manage applets. Additionally the GPCS defines secure communication protocols (called Secure Channel, SC) that besides authentication offer confidentiality and message integrity when communicating with the card.

    SE communication protocols

    As we showed in the previous post, Android’s interface for communicating with the SE is the byte[] transceive(byte[] command) method of the NfcExecutionEnvironment class. The structure of the exchanged messages, called APDUs  (Application Protocol Data Unit) is defined in the ISO/IEC 7816-4: Organization, security and commands for interchange standard. The reader (also known as a Card Acceptance Device, CAD) sends command APDUs (sometimes referred to as C-APDUs) to the card, comprised of a mandatory 4-byte header with a command class (CLA), instruction (INS) and two parameters (P1 and P2). This is followed by the optional command data length (Lc), the actual data and finally the maximum number of response bytes expected, if any (Le). The card returns a response APDU (R-APDU) with a mandatory status word (SW1 and SW2) and optional response data. Historically, command APDU data has been limited to 255 bytes and response APDU data to 256 bytes. Recent cards and readers support extended APDUs with data length up to 65536 bytes, but those are not always usable, mostly for various compatibility reasons. The lower level  communication between the reader and the card is carried out by one of several transmission protocols, the most widely used ones being T=0 (byte-oriented) and T=1 (block-oriented). Both are defined in ISO 7816-3: Cards with contacts — Electrical interface and transmission protocols. The APDU exchange is not completely protocol-agnostic, because T=0 cannot directly send response data, but only notify the reader of the number of available bytes. Additional command APDUs (GET RESPONSE) need to be sent in order to retrieve the response data.

    The original ISO 7816 standards were developed for contact cards, but the same APDU-based communication model is used for contactless cards as well. It is layered on top of the wireless transmission protocol defined by ISO/IEC 14443-4 which behaves much like T=1 for contact cards.

    Exploring the Galaxy Nexus SE execution environment

    With most of the theory out of the way, it is time to get our hands dirty and finally try to  communicate with the SE. As mentioned in the previous post, the SE in the Galaxy Nexus is a chip from NXP’s SmartMX series. It runs a Java Card-compatible operating system and comes with a GlobalPlatform-compliant Card Manager. Additionally, it offers MIFARE Classic 4K emulation and a MIFARE4Mobile manager applet that allows for personalization of the emulated MIFARE tag. The MIFARE4Mobile specification is available for free, but comes with a non-disclosure, no-open-source, keep-it-shut agreement, so we will skip that and focus on the GlobalPlatform implementation. 
    As we already pointed out, authentication is required for most of the Card Manager operations. The required keys are, naturally, not available and controlled by Google and their partners. Additionally, a number of subsequent failed authentication attempts (usually 10) will lock the Card Manager and make it impossible to install or remove applets, so trying out different keys is also not an option (and this is a good thing). However, the Card Manager does provide some information about itself and the runtime environment on the card in order to make it possible for clients to adjust their behaviour dynamically and be compatible with different cards. 
    Since Java Card/GP is a multi-application environment, each application is identified by an AID (Application Identifier), consisting of a 5-byte RID (Registered Application Provider Identifier or Resource Identifier) and up to 11-byte PIX (Proprietary Identifier eXtension). Thus an AID can be from 5 to 16 bytes long. Before being able to send commands to particular applet it needs to be made active by issuing the SELECT (CLA=’00’, INS=’A4′) command with its AID. As all applications, the Card Manager is also identified by an AID, so our first step is to find this out. This can be achieved by issuing an empty SELECT which both selects the Card Manager and returns information about the card and the Issuer Security Domain. An empty select is simply a select without an AID specified, so the command becomes: 00 A4 04 00 00. Let’s see what this produces:

    --> 00A4040000
    <-- 6F658408A000000003000000A5599F6501FF9F6E06479100783300734A06072A86488
    6FC6B01600C060A2A864886FC6B02020101630906072A864886FC6B03640B06092A86488
    6FC6B040215650B06092B8510864864020103660C060A2B060104012A026E0102 9000

    A successful status (0x9000) and a long string of bytes. The format of this data is defined in Chapter 9. APDU Command Reference of the GPCS, and as most things in the smart card world is in TLV (Tag-Length-Value) format. In TLV each unit of data is described by a unique tag, followed by its length in bytes, and finally the actual data. Most structures are recursive, so the data can host another TLV structure, which in turns wraps another, and so on. Parsing this is not terribly hard, but it is not fun either, so we’ll borrow some classes from the Java EMV Reader project to make our job a bit easier. You can see the full code in the sample project, but parsing the response produces something like this on a Galaxy Nexus:

    SD FCI: Security Domain FCI
    AID: AID: a0 00 00 00 03 00 00 00
    RID: a0 00 00 00 03 (Visa International [US])
    PIX: 00 00 00

    Data field max length: 255
    Application prod. life cycle data: 479100783300
    Tag allocation authority (OID): globalPlatform 01
    Card management type and version (OID): globalPlatform 02020101
    Card identification scheme (OID): globalPlatform 03
    Global Platform version: 2.1.1
    Secure channel version: SC02 (options: 15)
    Card config details: 06092B8510864864020103
    Card/chip details: 060A2B060104012A026E0102

    This shows as the AID of the Card Manager (A0 00 00 00 03 00 00 00), the version of the GP implementation (2.1.1) and the supported Secure Channel protocol (SC02, implementation option ’15’, which translates to: ‘Initiation mode explicit, C-MAC on modified APDU, ICV set to zero, ICV encryption for CMAC session, 3 Secure Channel Keys’) along with some proprietary data about the card configuration. Using the other GP command that don’t require authentication, GET DATA, we can also get some information about the number and type of keys the Card Manager uses. The Key Information Template is marked by tag ‘E0’, so the command becomes 80 CA 00 E0 00. Executing it produces another TLV structure which when parsed spells this out:

    Key: ID: 1, version: 1, type: DES (EBC/CBC), length: 128 bits
    Key: ID: 2, version: 1, type: DES (EBC/CBC), length: 128 bits
    Key: ID: 3, version: 1, type: DES (EBC/CBC), length: 128 bits
    Key: ID: 1, version: 2, type: DES (EBC/CBC), length: 128 bits
    Key: ID: 2, version: 2, type: DES (EBC/CBC), length: 128 bits
    Key: ID: 3, version: 2, type: DES (EBC/CBC), length: 128 bits

    This means that the Card Manager is configured with two versions of one key set, consisting of 3 double length DES keys (3DES where K3 = K1, aka DESede). The keys are used for authentication/encryption (S-ENC), data integrity (S-MAC) and data encryption (DEK), respectively. It is those keys we need to know in order to be able to install our own applets on the SE.

    There is other information we can get from the Card Manager, such as the card issuer ID and the card image number, but it is of less interest. It is also possible to obtain information about the card manufacturer, card operating system version and release date by getting the Card Production Life Cycle Data (CPLC). This is done by issuing the GET DATA command with the ‘9F7F’ tag: 80 CA 9F 7F 00. However, most of the CPLC data is encoded using proprietary tags and IDs so it is not very easy to read anything but the card serial number. Here’s the output from a Galaxy Nexus:

    CPLC
    IC Fabricator: 4790
    IC Type: 5044
    Operating System Provider Identifier: 4791
    Operating System Release Date: 0078
    Operating System Release Level: 3300
    IC Fabrication Date: 1017
    IC Serial Number: 082445XX
    IC Batch Identifier: 4645
    IC ModuleFabricator: 0000
    IC ModulePackaging Date: 0000
    ICC Manufacturer: 0000
    IC Embedding Date: 0000
    Prepersonalizer Identifier: 1726
    Prepersonalization Date: 3638
    Prepersonalization Equipment: 32343435
    Personalizer Identifier: 0000
    Personalization Date: 0000
    Personalization Equipment: 00000000

    Getting an applet installed on the SE

    No, this section doesn’t tell you how to recover the Card Manager keys, so if that’s what you are looking for, you can skip it. This is mostly speculation about different applet distribution models Google or carriers may (or may not) choose to use to allow third-party applets on their phones.

    It should be clear by now that the only way to install an applet on the SE is to have access to the Card Manager keys. Since Google will obviously not give up the keys to production devices (unless they decide to scrap Google Wallet), there are two main alternatives for third parties that want to use the SE: ‘development’ devices with known keys, or some sort of an agreement with Google to have their applets approved and installed via Google’s infrastructure. With Nexus-branded devices with an unlockable bootloader available on multiple carriers, as well directly from Google (at least in the US), it is unlikely that dedicated development devices will be sold again. That leaves delegated installation by Google or authorized partners. Let’s see how this can be achieved.

    The need to support multiple applications and load SE applets on mobile devices dynamically has been recognized by GlobalPlatform, and they have come up with, you guessed it, a standard that defines how this can be implemented. It is called Secure Element Remote Application Management and specifies an administration protocol for performing remote management of SE applets on a mobile device. Essentially, it involves securely downloading an applet and necessary provisioning scripts (created by a Service Provider) from an Admin Server, which are then forwarded by an Admin Agent running on the mobile device to the SE. The standard doesn’t mandate a particular implementation, but in practice the process is carried out by downloading APDU scripts over HTTPS, which are then sent to the SE using one of the compatible GP secure channel protocols, such as SC02. As we shall see in the next article, a similar, though non-general and proprietary, scheme is already implemented in Google Wallet. If it were generalized to allow the installation of any (approved) applet, it could be used by applications that want to take advantage of the secure element: on first run they could check if the applet is installed, and if not, send a SE provisioning request to the Admin Server. It would then determine the proper Card Manager keys for the target device and prepare the necessary installation scripts. The role of the Admin Agent can be taken by the Google Play app which already has the necessary system permissions to install applications, and would only need to be extended to support SE access and Card Manager communication. As demonstrated by Google Wallet, this is already technologically possible. The difficulties for making it generally available are mostly contractual and/or political.

    Since not all NFC-enabled phones with an embedded SE are produced or sold by Google, different vendors will control their respective Card Manager keys, and thus the Admin Server will need to know all of those in order to allow applet installation on all compatible devices. If UICCs are supported as a SE, this would be further complicated by the addition of new players: MNOs. Furthermore, service providers that deal with personal and/or financial information (pretty much all of the ones that matter do) require compliance with their own security standards, and that makes the job of the entity providing the Admin Server that much harder. The proposed solution to this is a neutral broker entity, called a Trusted Service Manager (TSM), that sets up both the required contractual agreements with all parties involved and takes care of securely distributing SE applications to supported mobile devices. The idea was originally introduced by the GSM Association a few years ago, and companies that offer TSM services exist today (most of those were already in the credit card provisioning business). RIM also provides a TSM service for their BlackBerries, but they have the benefit of being the manufacturer of all supported devices.

    To sum this up: the only viable way of installing applets on the SE on commercial devices is by having them submitted to and delivered by a distribution service controlled by the device vendor or provided by a third-party TSM. Such a (general purpose) service is not yet available for Android, but is entirely technologically possible. If NFC payments and ticketing using Android do take off, more companies will want to jump on the bandwagon and contactless application distribution services will naturally follow, but this is sort of a chicken-and-egg problem. Even after they do become available, they will most likely deal only with major service providers such as credit card or transportation companies. Update: It seems Google’s plan is to let third parties install their transport cards, loyalty cards, etc on the SE, but all under the Google Wallet umbrella, so a general purpose TSM might not be an option, at least for a while.

    A more practical alternative for third-party developers is software card emulation. In this mode, the emulated card is not on a SE, but is actually implemented as a regular Android app. Once the NFC chip senses an external reader, it forwards communication to a registered app, which processes it and returns a response which the NFC chip simply relays. This obviously doesn’t offer the same security as an SE, but comes with the advantage of not having to deal with MNOs, vendors or TSMs. This mode is not available in stock Android (and is unlikely to make it in the mainstream), but has been integrated into CyanogenMod and there are already commercial services that use it. For more info on the security implications of software card emulation, see this excellent paper.

    Summary

    We showed that the SE in recent Android phones offers a Java Card-compatible execution environment and implements GlobalPlatform specifications for card and applet management. Those require authentication using secret keys for all operations that change the card state. Because the keys for Android’s SE are only available to Google and their partners, it is currently impossible for third parties to install applets on the SE, but that could change if general purpose TSM services targeting Android devices become available.

    The final part of the series will look into the current Google Wallet implementation and explore how it makes use of the SE.

    Accessing the embedded secure element in Android 4.x

    After discussing credential storage and Android’s disk encryption, we’ll now look at another way to protect your secrets: the embedded secure element (SE) found in recent devices. In the first post of this three part series we’ll give some background info about the SE and show how to use the SE communication interfaces Android 4.x offers. In the second part we’ll try sending some actual commands in order to find out more about the SE execution environment. Finally we will discuss Google Wallet and how it makes use of the SE.

    What is a Secure Element and why do you want one? 

    A Secure Element (SE) is a tamper resistant smart card chip capable of running smart card applications (called applets or cardlets) with a certain level of security and features. A smart card is essentially a minimalistic computing environment on single chip, complete with a CPU, ROM, EEPROM, RAM and I/O port. Recent cards also come equipped with cryptographic co-processors implementing common algorithms such as DES, AES and RSA. Smart cards use various techniques to implement tamper resistance, making it quite hard to extract data by disassembling or analyzing the chip. They come pre-programmed with a  multi-application OS that takes advantage of the hardware’s memory protection features to ensure that each application’s data is only available to itself. Application installation and (optionally) access is controlled by requiring the use of cryptographic keys for each operation.

    The SE can be integrated in mobile devices in various form factors: UICC (commonly known as a SIM card), embedded in the handset or connected to a SD card slot. If the device supports  NFC the SE is usually connected to the NFC chip, making it possible to communicate with the SE wirelessly. 
    Smart cards have been around for a while and are now used in applications ranging from pre-paid phone calls and transit ticketing to credit cards and VPN credential storage. Since an SE installed in a mobile device has equivalent or superior capabilities to that of a smart card, it can theoretically be used for any application physical smart cards are currently used for. Additionally, since an SE can host multiple applications, it has the potential to replace the bunch of cards people use daily with a single device. Furthermore, because the SE can be controlled by the device’s OS, access to it can be restricted by requiring additional authentication (PIN or passphrase) to enable it. 
    So a SE is obviously a very useful thing to have and with a lot of potential, but why would you want to access one from your apps? Aside from the obvious payment applications, which you couldn’t realistically build unless you own a bank and have a contract with Visa and friends, there is the possibility of storing other cards you already have (access cards, loyalty cards, etc.) on your phone, but that too is somewhat of a gray area and may requiring contracting the relevant issuing entities. The main application for third party apps would be implementing and running a critical part of the app, such as credential storage or license verification inside the SE to guarantee that it is impervious to reversing and cracking. Other apps that can benefit from being implemented in the SE are One Time Password (OTP) generators and, of course PKI credential (i.e., private keys) storage. While implementing those apps is possible today with standard tools and technologies, using them in practice on current commercial Android devices is not that straightforward. We’ll discuss this in detail the second part of the series, but let’s first explore the types of SEs available on mobile devices, and the level of support they have in Android. 

    Secure Element form factors in mobile devices

    As mentioned in the previous section, SEs come integrated in different flavours: as an UICC, embedded or as plug-in cards for an SD card slot. This post is obviously about the embedded SE, but let’s briefly review the rest as well. 
    Pretty much any mobile device nowadays has an UICC (aka SIM card, although it is technically a SIM only when used on GSM networks) of some form or another. UICCs are actually smart cards that can host applications, and as such are one form of a SE. However, since the UICC is only connected to the basedband processor, which is separate from the application processor that runs the main device OS, they cannot be accessed directly from Android. All communication needs to go through the Radio Interface Layer (RIL) which is essentially a proprietary IPC interface to the baseband. Communication to the UICC SE is carried out using special extended AT commands (AT+CCHO, AT+CCHC, AT+CGLA as defined by 3GPP TS 27.007), which the current Android telephony manager does not support. The SEEK for Android project provides patches that do implement the needed commands, allowing for communicating with the UICC via their standard SmartCard API, which is a reference implementation of the SIMalliance Open Mobile API specification. However, as most components that talk directly to the hardware in Android, the RIL consists of an open source part (rild), and a proprietary library (libXXX-ril.so). In order to support communication with the UICC secure element, support for this needs to be added to both to rild and to the underlying proprietary library, which is of course up to hardware vendors. The SEEK project does provide a patch that lets the emulator talk directly to a UICC in an external PC/SC reader, but that is only usable for experiments. While there is some talk of integrating this functionality into stock Android (there is even an empty packages/apps/SmartCardService directory in the AOSP tree), there is currently no standard way to communicate with the UICC SE through the RIL (some commercial devices with custom firmware are reported to support it though).

    An alternative way to use the UICC as a SE is using the Single Wire Protocol (SWP) when the UICC is connected to a NFC controller that supports it. This is the case in the Nexus S, as well as the Galaxy Nexus, and while this functionality is supported by the NFC controller drivers, it is disabled by default. This is however a software limitation, and people have managed to patch AOSP source to get around it and successfully communicate with UICC. This has the greatest potential to become part of stock Android, however, as of the current release (4.1.1), it is still not available. 

    Another form factor for an SE is an Advanced Security SD card (ASSD), which is basically an SD card with an embedded SE chip. When connected to an Android device with and SD card slot, running a SEEK-patched Android version, the SE can be accessed via the SmartCard API. However, Android devices with an SD card slot are becoming the exceptions rather than the norm, so it is unlikely that ASSD Android support will make it to the mainstream.

    And finally, there is the embedded SE. As the name implies, an embedded SE is part of the device’s mainboard, either as a dedicated chip or integrated with the NFC one, and is not removable. The first Android device to feature an embedded SE was the Nexus S, which also introduced NFC support to Android. Subsequent Nexus-branded devices, as well as other popular handsets have continued this trend. The device we’ll use in our experiments, the Galaxy Nexus, is built with NXP’s PN65N chip, which bundles a NFC radio controller and an SE (P5CN072, part of NXP’s SmartMX series) in a single package (a diagram can be found here).

    NFC and the Secure Element

    NFC and the SE are tightly integrated in Android, and not only because they share the same silicon, so let’s say a few words about NFC. NFC has three standard modes of operation: 
    • reader/writer (R/W) mode, allowing for accessing external NFC tags 
    • peer-to-peer (P2P) mode, allowing for data exchange between two NFC devices 
    • card emulation (CE) mode, which allows the device to emulate a traditional contactless smart card 
    What can Android do in each of these modes? The R/W mode allows you to read NDEF tags and  contactless cards, such as some transport cards. While this is, of course, useful, it essential turns your phone into a glorified card reader. P2P mode has been the most demoed and marketed one, in the form of Android Beam. This is only cool the first couple of times though, and since the API only gives you higher-level access to the underlying P2P communication protocol, its applications are currently limited. CE was not available in the initial Gingerbread release, and was introduced later in order to support Google Wallet. This is the NFC mode with the greatest potential for real-life applications. It allows your phone to be programmed to emulate pretty much any physical contactless card, considerably slimming down your physical wallet in the process.

    The embedded SE is connected to the NFC controller through a SignalIn/SignalOut Connection (S2C, standardized as NFC-WI) and has three modes of operation: off, wired and virtual mode. In off mode there is no communication with the SE. In wired mode the SE is visible to the Android OS as if it were a contactless smartcard connected to the RF reader. In virtual mode the SE is visible to external readers as if the phone were a contactless smartcard. These modes are naturally mutually exclusive, so we can communicate with the SE either via the contactless interface (e.g., from an external reader), or through the wired interface (e.g., from an Android app). This post will focus on using the wired mode to communicate with the SE from an app. Communicating via NFC is no different than reading a physical contactless card and we’ll touch on it briefly in the last post of the series.

    Accessing the embedded Secure Element

    This is a lot of (useful?) information, but we still haven’t answered the main question of this entry: how can we access the embedded SE? The bad news is that there is no public Android SDK API for this (yet). The good news is that accessing it in a standard and (somewhat) officially supported way is possible in current Android versions.
    Card emulation, and consequently, internal APIs for accessing the embedded SE were introduced in Android 2.3.4, and that is the version Google Wallet launched on. Those APIs were, and remain, hidden from SDK applications. Additionally using them required system-level permissions (WRITE_SECURE_SETTINGS or NFCEE_ADMIN) in 2.3.4 and subsequent Gingerbread releases, as well as in the initial Ice Cream Sandwich release (4.0, API Level 14). What this means is that only Google (for Nexus) devices, and mobile vendors (for everything else) could distribute apps that use the SE, because they need to either be part of the core OS, or be signed with the platform keys, controlled by the respective vendor. Since the only app that made use of the SE was Google Wallet, which ran only on Nexus S (and initially on a single carrier), this was good enough. However, it made it impossible to develop and distribute an SE app without having it signed by the platform vendor. Android 4.0.4 (API Level 15) changed that by replacing the system-level permission requirement with signing certificate (aka, ‘signature’ in Android framework terms) whitelisting at the OS level. While this still requires modifying core OS files, and thus vendor cooperation, there is no need to sign SE applications with the vendor key, which greatly simplifies distribution. Additionally, since the whiltelist is maintained in a file, it can easily be updated using an OTA to add support for more SE applications.

    In practice this is implemented by the NfceeAccessControl class and enforced by the system NfcService. NfceeAccessControl reads the whilelist from /etc/nfcee_access.xml which is an XML file that stores a list of signing certificates and package names that are allowed to access the SE. Access can be granted both to all apps signed by a particular certificate’s private key (if no package is specified), or to a single package (app) only. Here’s how the file looks like:

    <?xml version="1.0" encoding="utf-8"?>
    <resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
    <signer android:signature="30820...90">
    <package android:name="org.foo.nfc.app">
    </package></signer>
    </resources>

    This would allow SE access to the ‘org.foo.nfc.app’ package, if it is signed by the specified signer. So the first step to getting our app to access the SE is adding its signing certificate and package name to the nfcee_access.xml file. This file resides on the system partition (/etc is symlinked to /system/etc), so we need root access in order to remount it read-write and modify the file. The stock file already has the Google Wallet certificate in it, so it is a good idea to start with that and add our own package, otherwise Google Wallet SE access would be disabled. The ‘signature’ attribute is a hex encoding of the signing certificate in DER format, which is a pity since that results in an excessively long string (a hash of the certificate would have sufficed) . We can either add a <debug/> element to the file, install it, try to access the SE and get the string we need to add from the access denied exception, or simplify the process a bit by preparing the string in advance. We can get the certificate bytes in hex format with a command like this:

    $ keytool -exportcert -v -keystore my.keystore -alias my_signing_key 
    -storepass password|xxd -p -|tr -d 'n'

    This will print the hex string on a single line, so you might want to redirect it to a file for easier copying. Add a new <signer> element to the stock file, add your app’s package name and the certificate hex string, and replace the original file in /etc/ (backups are always a good idea). You will also need to reboot the device for the changes to take effect, since file is only read when the NfcService starts.

    As we said, there are no special permissions required to access the SE in ICS (4.0.3 and above) and Jelly Bean (4.1), so we only need to add the standard NFC permission to our app’s manifest. However, the library that implements SE access is marked as optional, and to get it loaded for our app, we need to mark it as required in the manifest with the <uses-library> tag. The AndroidManifest.xml for the app should look something like this:

    <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="org.foo.nfc.app"
    android:versionCode="1"
    android:versionName="1.0" >
    <uses-sdk
    android:minSdkVersion="15"
    android:targetSdkVersion="16" />

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

    <application
    android:icon="@drawable/ic_launcher"
    android:label="@string/app_name"
    android:theme="@style/AppTheme" >
    <activity
    android:name=".MainActivity"
    android:label="@string/title_activity_main" >
    <intent-filter>
    <action android:name="android.intent.action.MAIN" />
    <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
    </activity>

    <uses-library
    android:name="com.android.nfc_extras"
    android:required="true" />
    </application>
    </manifest>

    With the boilerplate out of the way it is finally time to actually access the SE API. Android doesn’t currently implement a standard smart card communication API such as JSR 177 or the Open Mobile API, but instead offers a very basic communication interface in the NfcExecutionEnvironment (NFC-EE) class. It has only three public methods:

    public class NfcExecutionEnvironment {
    public void open() throws IOException {...}

    public void close() throws IOException {...}

    public byte[] transceive(byte[] in) throws IOException {...}
    }

    This simple interface is sufficient to communicate with the SE, so now we just need to get access to an instance. This is available via a static method of the NfcAdapterExtras class which controls both card emulation route (currently only to the SE, since UICC support is not available) and NFC-EE management. So the full code to send a command to the SE becomes:

    NfcAdapterExtras adapterExtras = NfcAdapterExtras.get(NfcAdapter.getDefaultAdapter(context));
    NfcExecutionEnvironment nfceEe = adapterExtras.getEmbeddedExecutionEnvironment();
    nfcEe.open();
    byte[] response = nfcEe.transceive(command);
    nfcEe.close();

    As we mentioned earlier however, com.android.nfc_extras is an optional package and thus not part of the SDK. We can’t import it directly, so we have to either build our app as part of the full Android source (by placing it in /packages/apps/), or resort to reflection. Since the SE interface is quite small, we opt for ease of building and testing, and will use reflection. The code to get, open and use an NFC-EE instance now degenerates to something like this:

    Class nfcExtrasClazz = Class.forName("com.android.nfc_extras.NfcAdapterExtras");
    Method getMethod = nfcExtrasClazz .getMethod("get", Class.forName("android.nfc.NfcAdapter"));
    NfcAdapter adapter = NfcAdapter.getDefaultAdapter(context);
    Object nfcExtras = getMethod .invoke(nfcExtrasClazz, adapter);

    Method getEEMethod = nfcExtras.getClass().getMethod("getEmbeddedExecutionEnvironment",
    (Class[]) null);
    Object ee = getEEMethod.invoke(nfcExtras , (Object[]) null);
    Class eeClazz = se.getClass();
    Method openMethod = eeClazz.getMethod("open", (Class[]) null);
    Method transceiveMethod = ee.getClass().getMethod("transceive",
    new Class[] { byte[].class });
    Method closeMethod = eeClazz.getMethod("close", (Class[]) null);

    openMethod.invoke(se, (Object[]) null);
    Object response = transceiveMethod.invoke(se, command);
    closeMethod.invoke(se, (Object[]) null);

    We can of course wrap this up in a prettier package, and we will in the second part of the series. What is important to remember is to call close() when done, because wired access to the SE blocks contactless access while the NFC-EE is open. We should now have a working connection to the embedded SE and sending some bytes should produce a (error) response. Here’s a first try:

    D/SEConnection(27318): --> 00000000
    D/SEConnection(27318): <-- 6E00

    We’ll explain what the response means and show how to send some actually meaningful commands in the second part of the article.

    Summary

    A secure element is a tamper resistant execution environment on a chip that can execute applications and store data in a secure manner. An SE is found on the UICC of every Android phone, but the platform currently doesn’t allow access to it. Recent devices come with NFC support, which is often combined with an embedded secure element chip, usually in the same package. The embedded secure element can be accessed both externally via a NFC reader/writer (virtual mode) or internally via the NfcExecutionEnvironment API (wired mode). Access to the API is currently controlled by a system level whitelist of signing certificates and package names. Once an application is whitelisted, it can communicate with the SE without any other special permissions or restrictions.