Technology Fuels Cyberbullying and Cheating in Teens

McAfee’s study “The Digital Divide: How the Online Behavior of Teens is Getting Past Parents” shows an alarming 70% of teens have hidden their online behavior from their parents, up from 45% in 2010. And yet half of parents live under the assumption that their teen tells them everything he/she does online.

The school year is now upon us. If you haven’t already, you will soon start packing up the kids to send them off to school. Outfitting your kids with new clothes are new technologies is often a big part of back to school preparations.

However, these technologies can have drawbacks and even some dangers that parents need to address: cyberbullying and cheating.

Here are some startling facts that we as parents need to be aware of:

 

 

Cyberbullying

  • Almost 25% of teens claimed to be targets of cyber bullying and 2/3 of all teens have witnessed cruel behavior online
  • Only 10% of parents are aware of their teens are targets of cyber bullying
  • Facebook has become the new school yard for bullies with 92.6% of teens saying that cruel behavior takes place on Facebook, and 23.8% on Twitter, 17.7% on MySpace and 15.2% via Instant Messenger
  • When witnessing others being attacked, 40% of teens have told the person to stop, 21% have told an adult and 6% joined in
  • When being attacked themselves, 66% of teens responded to the attacker (with 35% responding in person), 15.4% avoided school, and an alarming 4.5% have been in a physical fight with their attacker

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Cheating

  • Only 23% of parents express concern about their teen going online to cheat in school, yet nearly half of all teens (48%) admit they’ve looked up answers to a test or assignment online
  • 22% cheated specifically on a test via online or mobile phone; while only 5% of parents believed their children did this.
  • 15.8% of teens have admitted to cheating on a test by looking up answers on their phone yet only 3.2% of parents thought their teens cheated this way
  • 14.1% of teens admitted to looking up how to cheat on a test online
  • Overall, 77.2% of parents said they were not worried about their teens cheating online

Parents, you must stay in-the-know. Since your teens have grown up in an online world, they may be more online savvy than you, but you can’t give up. You must challenge yourself to become familiar with the complexities of the teen online universe and stay educated on the various devices your teens are using to go online.

As a parent, I proactively participate in my kids’ online activities and talk to them about the “rules of the road” for the Internet. I’m hoping that this report opens other parent’s eyes so they’ll become more involved in educating their teens with advice and tools

 

Robert Siciliano is an Online Security Evangelist to McAfee. See him discussing identity theft on YouTube. (Disclosures)

The post Technology Fuels Cyberbullying and Cheating in Teens appeared first on McAfee Blogs.

Exploring Google Wallet using the secure element interface

In the first post of this series we showed how to use the embedded secure element interface Android 4.x offers. Next, we used some GlobalPlatform commands to find out more about the SE execution environment in the Galaxy Nexus. We also showed that there is currently no way for third parties to install applets on the SE. Since installing our own applets is not an option, we will now find some pre-installed applets to explore. Currently the only generally available Android application that is known to install applets on the SE is Google’s own Google Wallet. In this last post, we’ll say a few words about how it works and then try to find out what publicly available information its applets host.

Google Wallet and the SE

To quote the Google Play description, ‘Google Wallet holds your credit and debit cards, offers, and rewards cards’. How does it do this in practice though? The short answer: it’s slightly complicated. The longer answer: only Google knows all the details, but we can observe a few things. After you install the Google Wallet app on your phone and select an account to use with it, it will contact the online Google Wallet service (previously known as Google Checkout), create or verify your account and then provision your phone. The provisioning process will, among other things, use First Data‘s Trusted Service Manager (TSM) infrastructure to download, install and personalize a bunch of applets on your phone. This is all done via the Card Manager and the payload of the commands is, of course, encrypted. However, the GP Secure Channel only encrypts the data part of APDUs, so it is fairly easy to map the install sequence on a device modified to log all SE communication. There are three types of applets installed: a Wallet controller applet, a MIFARE manager applet, and of course payment applets that enable your phone to interact with NFC-enabled PayPass terminals.

The controller applet securely stores Google Wallet state and event log data, but most importantly, it enables or disables contactless payment functionality when you unlock the Wallet app by entering your PIN. The latest version seems to have the ability to store and verify a PIN securely (inside the SE), however it does not appear it is actually used by the app yet, since the Wallet Cracker can still recover the PIN on a rooted phone. This implies that the PIN hash is still stored in the app’s local database.

The MIFARE manager applet works in conjunction with the offers and reward/loyalty cards features of Wallet. When you save an offer or add a loyalty card, the MIFARE manager applet will write block(s) to the emulated MIFARE 4K Classic card to mirror the offer or card on the SE, letting you redeem it by tapping your phone at a NFC-enabled POS terminal. It also keeps an application directory (similar to the standard MIFARE MAD) in the last sectors, which is updated each time you add or remove a card. The emulated MIFARE card uses custom sector protection keys, which are most probably initialized during the initial provisioning process. Therefore you cannot currently read the contents of the MIFARE card with an external reader. However, the encryption and authentication scheme used by MIFARE Classic has been broken and proven insecure, and the keys can be recovered easily with readily available tools. It would be interesting to see if the emulated card is susceptible to the same attacks.

Finally, there should be one or more EMV-compatible payment applets that enable you to pay with your phone at compatible POS terminals. EMV is an interoperability standard for payments using chip cards, and while each credit card company has their proprietary extensions, the common specifications are publicly available. The EMV standard specifies how to find out what payment applications are installed on a contactless card, and we will use that information to explore Google Wallet further later.

Armed with that basic information we can now extend our program to check if Google Wallet applets are installed. Google Wallet has been around for a while, so by now the controller and MIFARE manager applets’ AIDs are widely known. However, we don’t need to look further than latest AOSP code, since the system NFC service has those hardcoded. This clearly shows that while SE access code is being gradually made more open, its main purpose for now is to support Google Wallet. The controller AID is A0000004762010 and the MIFARE manager AID is A0000004763030. As you can see, they start with the same prefix (A000000476), which we can assume is the Google RID (there doesn’t appear to be a public RID registry). Next step is, of course, trying to select those. The MIFARE manager applet responds with a boring 0x9000 status which only shows that it’s indeed there, but selecting the controller applet returns something more interesting:

6f 0f -- File Control Information (FCI) Template
84 07 -- Dedicated File (DF) Name
a0 00 00 04 76 20 10 (BINARY)
a5 04 -- File Control Information (FCI) Proprietary Template
80 02 -- Response Message Template Format 1
01 02 (BINARY)

The ‘File Control Information’ and ‘Dedicated File’ names are file system-based card legacy terms, but the DF (equivalent to a directory) is the AID of the controller applet (which we already know), and the last piece of data is something new. Two bytes looks very much like a short value, and if we convert this to decimal we get ‘258’, which happens to be the controller applet version displayed in the ‘About’ screen of the current Wallet app (‘v258’).

Now that we have an app that can check for wallet applets (see sample code, screenshot above), we can verify if those are indeed managed by the Wallet app. It has a ‘Reset Wallet’ action on the Settings screen, which claims to delete ‘payment information, card data and transaction history’, but how does it affect the controller applets? Trying to select them after resetting Wallet shows that the controller applet has been removed, while the MIFARE manager applet is still selectable. We can assume that any payment applets have also been removed, but we still have no way to check. This leads us to the topic of our next section:

Exploring Google Wallet EMV applets

Google Wallet is compatible with PayPass terminals, and as such should follow relevant specifications. For contactless cards those are defined in the EMV Contactless Specifications for Payment Systems series of ‘books’. Book A defines the overall architecture, Book B — how to find and select a payment application, Book C — the rules of the actual transaction processing for each ‘kernel’ (card company-specific processing rules), and Book D — the underlying contactless communication protocol. We want to find out what payment applets are installed by Google Wallet, so we are most interested in Book B and the relevant parts of Book C.
Credit cards can host multiple payment applications, for example for domestic and international payment. Naturally, not all POS terminals know of or are compatible with all applications, so cards keep a public EMV app registry at a well known location. This practice is optional for contact cards, but is mandatory for contactless cards. The application is called ‘Proximity Payment System Environment’ (PPSE) and selecting it will be our first step. The application’s AID is derived from the name: ‘2PAY.SYS.DDF01’, which translates to '325041592E5359532E444446303131' in hex. Upon successful selection it returns a TLV data structure that contains the AIDs, labels and priority indicators of available applications (see Book B, 3.3.1 PPSE Data for Application Selection). To process it, we will use and slightly extend the Java EMV Reader library, which does similar processing for contact cards. The library uses the standard Java Smart Card I/O API to communicate with cards, but as we pointed out in the first article, this API is not available on Android. Card communication interfaces are nicely abstracted, so we only need to implement them using Android’s native NfcExecutionEnvironment. The main classes we need are SETerminal, which creates a connection to the card, SEConnection to handle the actual APDU exchange, and SECardResponse to parse the card response into status word and data bytes. As an added bonus, this takes care of encapsulating our uglish reflected code. We also create a PPSE class to parse the PPSE selection response into its components. With all those in place all we need to do is follow the EMV specification. Selecting the PPSE with the following command works at first try, but produces a response with 0 applications:

--> 00A404000E325041592E5359532E4444463031
<-- 6F10840E325041592E5359532E4444463031 9000
response hex :
6f 10 84 0e 32 50 41 59 2e 53 59 53 2e 44 44 46
30 31
response SW1SW2 : 90 00 (Success)
response ascii : o...2PAY.SYS.DDF01
response parsed :
6f 10 -- File Control Information (FCI) Template
84 0e -- Dedicated File (DF) Name
32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 (BINARY)

We have initialized the $10 prepaid card available when first installing Wallet, so something must be there. We know that the controller applet manages payment state, so after starting up and unlocking Wallet we finally get more interesting results (shown parsed and with some bits masked below). It turns out that locking the Wallet up effectively hides payment applications by deleting them from the PPSE. This, in addition to the fact that card emulation is available only when the phone’s screen is on, provides better card security than physical contactless cards, some of which can easily be read by simply using a NFC-equipped mobile phone, as has been demonstrated.

Applications (2 found):
Application
AID: a0 00 00 00 04 10 10 AA XX XX XX XX XX XX XX XX
RID: a0 00 00 00 04 (Mastercard International [US])
PIX: 10 10 AA XX XX XX XX XX XX XX XX
Application Priority Indicator
Application may be selected without confirmation of cardholder
Selection Priority: 1 (1 is highest)
Application
AID: a0 00 00 00 04 10 10
RID: a0 00 00 00 04 (Mastercard International [US])
PIX: 10 10
Application Priority Indicator
Application may be selected without confirmation of cardholder
Selection Priority: 2 (1 is highest)

One of the applications is the well known MasterCard credit or debit application, and there is another MasterCard app with a longer AID and higher priority (1, the highest). The recently announced update to Google Wallet allows you to link practically any card to your Wallet account, but transactions are processed by a single ‘virtual’ MasterCard and then billed back to your actual credit card(s). It is our guess that the first application in the list above represents this virtual card. The next step in the EMV transaction flow is selecting the preferred payment app, but here we hit a snag: selecting each of the apps always fails with the 0x6999 (‘Applet selection failed’) status. It has been reported that this was possible in previous versions of Google Wallet, but has been blocked to prevent relay attacks and stop Android apps from extracting credit card information from the SE. This leaves us with using the NFC interface if we want to find out more.

Most open-source tools for card analysis, such as cardpeek and Java EMV Reader were initially developed for contact cards, and therefore need a connection to a PC/SC-compliant reader to operate. If you have a dual interface reader that provides PC/SC drivers you get this for free, but for a standalone NFC reader we need libnfc, ifdnfc and PCSC lite to complete the PC/SC stack on Linux. Getting those to play nicely together can be a bit tricky, but once it’s done card tools work seamlessly. Fortunately, selection via the NFC interface is successful and we can proceed with the next steps in the EMV flow: initiating processing by sending the GET PROCESSING OPTIONS and reading relevant application data using the READ RECORD command. For compatibility reasons, EMV payment applications contain data equivalent to that found on the magnetic stripe of physical cards. This includes account number (PAN), expiry date, service code and card holder name. EMV-compatible POS terminals are required to support transactions based on this data only (‘Mag-stripe mode’), so some of it could be available on Google Wallet as well. Executing the needed READ RECORD commands shows that it is indeed found on the SE, and both MasterCard applications are linked to the same mag-stripe data. The data is as usual in TLV format, and relevant tags and format are defined in EMV Book C-2. When parsed it looks like this for the Google prepaid card (slightly masked):

Track 2 Equivalent Data:
Primary Account Number (PAN) - 5430320XXXXXXXX0
Major Industry Identifier = 5 (Banking and financial)
Issuer Identifier Number: 543032 (Mastercard, UNITED STATES OF AMERICA)
Account Number: XXXXXXXX
Check Digit: 0 (Valid)
Expiration Date: Sun Apr 30 00:00:00 GMT+09:00 2017
Service Code - 101:
1 : Interchange Rule - International interchange OK
0 : Authorisation Processing - Normal
1 : Range of Services - No restrictions
Discretionary Data: 0060000000000

As you can see, it does not include the card holder name, but all the other information is available, as per the EMV standard. We even get the ‘transaction in progress’ animation on screen while our reader is communicating with Google Wallet. We can also get the PIN try counter (set to 0, in this case meaning disabled), and a transaction log in the format shown below. We can’t verify if the transaction log is used though, since Google Wallet, like a lot of the newer Google services, happens to be limited to the US .

Transaction Log:
Log Format:
Cryptogram Information Data (1 byte)
Amount, Authorised (Numeric) (6 bytes)
Transaction Currency Code (2 bytes)
Transaction Date (3 bytes)
Application Transaction Counter (ATC) (2 bytes)

This was fun, but it doesn’t really show much besides the fact that Google Wallet’s virtual card(s) comply with the EMV specifications. What is more interesting is that the controller applet APDU commands that toggle contactless payment and modify the PPSE don’t require additional application authentication and can be issued by any app that is whitelisted to use the secure element. The controller applet most probably doesn’t store any really sensitive information, but while it allows its state to be modified by third party applications, we are unlikely to see any other app besides Google Wallet whitelsited on production devices. Unless of course more fine-grained SE access control is implemented in Android.

Fine-grained SE access control

This fact that Google Wallet state can be modified by third party apps (granted access to the SE, of course) leads us to another major complication with SE access on mobile devices. While the data on the SE is securely stored and access is controlled by the applets that host it, once an app is allowed access, it can easily perform a denial of service attack against the SE or specific SE applications. Attacks can range from locking the whole SE by repeatedly executing failed authentication attempts until the Card Manager is blocked (a GP-compliant card goes into the TERMINATED state usually after 10 unsuccessful tries), to application-specific attacks such as blocking a cardholder verification PIN or otherwise changing a third party applet state. Another more sophisticated, but harder to achieve and possible only on connected devices, attack is a relay attack. In this attack, the phone’s Internet connection is used to receive and execute commands sent by another remote phone, enabling the remote device to emulate the SE of the target device without physical proximity. The way to mitigate those attacks is to exercise finer control on what apps that access the SE can do by mandating that they can only select specific applets or only send a pre-approved list of APDUs. This is supported by JSR-177 Security and Trust Servcies API which only allows connection to one specific applet and only grants those to applications with trusted signature (currently implemented in BlackBerry 7 API). JSR-177 also  provides the ability to restrict APDUs by matching them against an APDU mask to determine whether they should be allowed or not. SEEK for Android goes on step further than BlackBerry by supporting fine-grained access control with access policy stored on the SE. The actual format of ACL rules and protocols for managing them are defined in GlobalPlatform Secure Element Access Control standard, which is relatively new (v.1.0 released on May 2012). As we have seen, the current (4.0 and 4.1) stock Android versions do restrict access to the SE to trusted applications by whitlisting their certificates (a hash of those would have probably sufficed) in /etc/nfcee_access.xml, but once an app is granted access it can select any applet and send any APDU to the SE. If third party apps that use the SE are to be allowed in Android, more fine-grained control needs to be implemented by at least limiting the applets SE-whitelisted Android apps can select.

Because for most applications the SE is used in conjunction with NFC, and SE app needs to be notified of relevant NFC events such as RF field detection or applet selection via the NFC interface. Disclosure of such events to malicious applications can also potentially lead to denial of service attacks, that is why access to them needs to be controlled as well. The GP SE access control specification allows rules for controlling access to NFC events to be managed along with applet access rules by saving them on the SE. In Android, global events are implemented by using  broadcasts and interested applications can create and register a broadcast receiver component that will receive such broadcasts. Broadcast access can be controlled with standard Android signature-based permissions, but that has the disadvantage that only apps signed with the system certificate would be able to receive NFC events, effectively limiting SE apps to those created by the device manufacturer or MNO. Android 4.x therefore uses the same mechanism employed to control SE access — whitelisting application certificates. Any application registered in nfcee_access.xml can receive the broadcasts listed below. As you can see, besides RF field detection and applet selection, Android offers notifications for higher-level events such as EMV card removal or MIFARE sector access. By adding a broadcast receiver to our test application as shown below, we were able to receive AID_SELECTED and RF field-related broadcasts. AID_SELECTED carries an extra with the AID of the selected applet, which allows us to start a related activity when an applet we support is selected. APDU_RECEIVED is also interesting because it carriers an extra with the received APDU, but that doesn’t seem to be sent, at least not in our tests.

<receiver android:name="org.myapp.nfc.SEReceiver" >
<intent-filter>
<action android:name="com.android.nfc_extras.action.AID_SELECTED" />
<action android:name="com.android.nfc_extras.action.APDU_RECEIVED" />
<action android:name="com.android.nfc_extras.action.MIFARE_ACCESS_DETECTED" />
<action android:name="android.intent.action.MASTER_CLEAR_NOTIFICATION" />
<action android:name="com.android.nfc_extras.action.RF_FIELD_ON_DETECTED" />
<action android:name="com.android.nfc_extras.action.RF_FIELD_OFF_DETECTED" />
<action android:name="com.android.nfc_extras.action.EMV_CARD_REMOVAL" />
<action android:name="com.android.nfc.action.INTERNAL_TARGET_DESELECTED" />
</intent-filter>
</receiver>

Summary

We showed that Google Wallet installs a few applets on the SE when first initialized. Besides the expected EMV payment applets, if makes use of a controller applet for securely storing Wallet state and a MIFARE manager applet for reading/writing emulated card sectors from the app. While we can get some information about the EMV environment by sending commands to the SE from an app, payment applets cannot be selected via the wired SE interface, but only via the contactless NFC interface. Controller applet access is however available to third party apps, as long as they know the relevant APDU commands, which can easily be traced by logging. This might be one of the reasons why third party SE apps are not supported on Android yet. To make third party SE apps possible (besides offering a TSM solution),  Android needs to implement more-fined grained access control to the SE, for example by restricting what applets can be selected or limiting the range of allowed APDUs for whitelisted apps.

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.

Are Your Mobile Apps Up To No Good?

Most of us have heard the saying “It’s 2am, what are your kids doing?” and you may know, but do you know what your mobile apps are doing? I know before I started working in the industry, I would not have given a second thought to this, but consider this.

Why would an app designed to monitor your mobile’s battery need to know your location via your GPS? How come some gaming applications ask users for their phone numbers? Mobile applications, especially free ones, require some level of your personal data in order to supplement development costs. This means “free” isn’t exactly free.

Unsurprisingly 97% of users don’t understand how permissions correspond to the risk of an app. The consequences of not knowing is once you share your personal data, it now can be use and sometimes abused and is out of your control forever. Check out this infographic…

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

If it’s digital then that means it’s also “repeatable” and can be copied, pasted, duplicated and sent an infinite amount of times. For example 18.3 million US adult Smartphone owners have looked up medical information.  32.5 million US adult Smartphone owners access banking information. Using applications that don’t care much about your privacy can expose this data.

Android applications can ask for 124 types of permissions and with these permissions someone can turn on your camera, monitor or modify or even kill outgoing calls, record images of your screen while you enter personal information, monitor and view texts or pictures and even scarier capture conversations in the room when no call is active!!

What’s troubling is 33% of apps ask for more permissions than they need, 42% of users don’t know what these permissions are and 83% of users don’t pay attention to permissions when installing an app. This all adds up to needing to know what your apps are doing.

To help you protect your privacy and identity when using apps you should:

  • Research apps by checking their ratings and reviews before you download
  • Only download apps from reputable apps stores
  • Read the Terms of Service (TOS) to determine what data the app is going to access on your mobile device.
  • Use comprehensive  mobile security app with app privacy features, such as McAfee Mobile Security, that will provide insight into the activity and safety of your apps

 

Robert Siciliano is an Online Security Evangelist to McAfee. Watch him discussing information he found on used electronic devices YouTube. (Disclosures)

The post Are Your Mobile Apps Up To No Good? appeared first on McAfee Blogs.