Target breach, credit card security and NFC (part V)

[continued from part IV]

Damage control

First problem is that attackers are still limited in the number of purchases they can make with captured data. Each simulated track-data contains a counter known as ATC which is unique to a transaction, limiting this scam by the number of “extra” transaction performed at the malicious POS. Given that a full transaction requires on the order of ~100 milliseconds minimum– due to limited processing capabilities of smart card hardware, particularly for contactless transactions when all power required for computing must be drawn from the induction field– we are looking at not more than a dozen spurious protocol executions before either the checkout delays become suspicious or customers tire of holding their cards against the reader. Granted this may not be too much of a problem for the crooks interested in perpetrating fraud. Between issuer back-ends searching for anomalous spending patterns and card-holders noticing strange charges on their card, even old-school plastic card fraud may not get much far farther than a handful of unauthorized uses before it is caught.

When counters jump around

But the same transaction counter presents a different problem for attackers. To pick a concrete example, suppose that the card starts out with ATC at 10. The compromised POS carries out 5 NFC transactions, receiving track-data with ATC=11, 12, 13, 14, 15. One of these must be used to authorize the current purchase, with others saved for future fraudulent transactions.

Suppose the attacker submits ATC=15 to the issuer. The issuer will notice a gap, a sudden jump in ATC from the last seen value of 10 without any intervening values observed. This is often explained by incomplete or failed transactions where the card/terminal only complete some of the protocol steps. (ATC is incremented fairly on, typically during the execution of GET PROCESSING OPTIONS command) But when the remaining track-data samples are used in fraudulent transaction, the issuer will observe something even more strange: ATC out-of-order, with lower values of the counter such as 11 and 12 appearing at a later date than higher values. By itself this is not sufficient to deem the transaction fraudulent. Occasionally transactions get submitted in one large “batch” after a delay, instead of being submitted incrementally in real-time, especially when charge amounts are small. That could explain isolated instances of ATC appearing to jump back-and-forth over short periods, until missing values in the sequence are finally submitted to the payment processor. But the same pattern repeated over a longer stretch, with low ATC values continuing to appear after higher ones have been observed could be either a signal for flagging the transaction as suspicious or outright rejecting it as a processing error. In other words, the useful lifetime of information captured by the malicious POS has been bounded.

Race conditions

Exact same pattern occurs if the attacker chooses to submit ATC=10 to complete the original purchase at the compromised POS. In this case, remaining track-data can be used for fraudulent transactions in correct order, as strictly monotone increasing counter 11, 12 etc. But there is a catch: if the card-holder herself starts making additional purchases, the issuer will receive higher ATC values starting at 16, giving rise to the same out-of-sequence ATC signal. This creates a race-condition between the crooks and legitimate user: they need to quickly monetize the stolen information before actions by the card-holder renders that information useless because the ATC has advanced too far for the issuer to honor lower values. That does not render the attack impossible per se, but like all good mitigations, it raises costs for the attacker and blocks certain avenues for exploit. Much like a stolen OTP in attacks against two-factor authentication systems, captured track-data from NFC must be cashed in quickly or it may become worthless. Squirreling it away to resell on the black-market days or weeks later is no longer a viable strategy. (Note the extreme case of trying to win the race is a real-time relay attack. The attacker can have an accomplice stand in front of another NFC reader with a mobile device and simply relay APDUs to the victim card via the compromised POS. The unauthorized transaction takes place almost simultaneously or even before the intended one.)

CP

Target breach, credit card security and NFC (part IV)

Part III in this series sketched a picture of how the most basic EMV protocol over NFC– backwards compatible with the ubiquitous magnetic stripes– can resist passive attacks taking place at the point-of-sale. If the miscreants’ strategy involves capturing transaction data as it is passing through a compromised POS and trying to stash it away for future use, card issuers can combat such fraud by checking for replay indicators. What about more sophisticated attacks when the POS attempts to influence the exchange between NFC reader and card, or try to monetize the stolen data immediately?

The price is always right

Looking back at how track-data and CVC3 are computed during NFC payments, there are two inputs conspicuously absent from the exchange: price and merchant identifier. That means the emulated magnetic stripe is not in any way bound to a particular purchase or even a specific merchant. In fact it is relatively easy to verify the first part experimentally. When paying with Google Wallet in-store for a purchase having multiple items, you can initiate the tap & pay before the cashier has finished ringing up all of them– exactly as one could with traditional plastic cards. The POS will typically display an interim message indicating that it is still waiting for the final amount, but the buyers will not have to tap again or otherwise confirm the details of the transaction.

Repeated transactions

That suggests a new avenue of attack:

  1. Trick the cardholder into performing multiple NFC transactions.
  2. Use one of the resulting track-data to complete the intended purchase at the specific merchant whose POS devices have been compromised
  3. Stash track-data from others, encode them on plain magnetic-stripe cards and rely on backwards compatibility to monetize them via swipe transactions at other merchants. There is nothing in the track-data per se limiting its use to the original merchant or identical transaction amount.
  4. Profit. Granted, fraud detection by the issuer can still flag transactions as suspicious based on merchant/amount patterns but that is based on statistical models of cardholder behavior. There is nothing in the track-data itself that indicates an attempt to divert captured track-data from a different merchant.

Keeping count

What is the feasibility of carrying out such an attack? First note that the multiple transactions are required for this plan. As noted earlier, each emulated track-data contains an incrementing counter, the ATC which is authenticated by the CVC3 and allows the issuer to detect replay attempts. At least one transaction is required for the cardholder to complete the legitimate purchase and that can not be reused by the miscreants. Racing the merchant to using that data first requires that attackers already have a purchase lined up, greatly limiting their options– good for our defensive position. More significantly it means that the card-holder gets a declined transaction and the issuer sees a repeated ATC value  raising suspicion about what is going on. With full control over POS, the bad guys can try more subtle options where the compromised POS pretends that an authorization succeeded and prints out a receipt, without submitting anything to the payment processor. But such an attack equally risks being found-out quickly, due to accounting discrepancies; the merchant does not get paid.

Step #1 turns out not to be a major obstacle. As long as the card is in the induction field of the NFC reader, the reader can likely repeat payment protocol without additional user action required. Plastic-cards with NFC have no built-in clock or other means of detecting that a terminal is requesting multiple transactions in quick succession. Once the field is removed– powering off the chip inside the card which draws its current from that external field– and reintroduced, the card has no way to know whether it has been days or milliseconds since last activation.

Smartphone-based implementations do have access to an actual clock and could in principle detect such rapid-burst attempts.**  Yet they are typically configured to only require PIN or other user explicit user confirmation based on time intervals, rather than transaction count. As long as the user has “primed” the application in the last 15 minutes or other interval configured, there is no additional confirmation required for individual transactions to proceed. This is partially driven by a desire to optimize for usability and handle flaky readers: in case a transaction failed, consumers can try again by holding the phone against the reader, without fiddling with the screen yet again.

Instead what stops this attack from working is the way ATC (application-transaction counter) frustrates steps #2 and #3.

[continued]

CP

** Even this part is tricky when a mobile wallet operates in NFC card-emulation mode with a secure element directly talking to the reader, by-passing the host operating system. SE has no concept of wall-clock either and can only limit transactions based on a signal received from the host device. Mobile versions of NFC payment protocols such as Paypass make provisions for host to grant single-shot approval to the SE, instead of the more common model of allowing them indefinitely until the host revokes such permission.

Target breach, credit card security and NFC (part III)

[continued from part II]

Armed with the background from previous posts on NFC payment protocols and how the magnetic-stripe profiles for EMV protocols achieve backwards compatibility, we can now look at what would happen in a hypothetical Target-type attack. The threat model assumes that point-of-sale (POS) terminals at the retailer stores have been compromised by attackers. Consumers will be making payments at these registers using their contactless cards, using NFC instead of swiping.

NFC at point-of-sale

One important distinction: we have spoken of POS devices having NFC as an integrated capability. In practice these can be distinct pieces of hardware. For example tap-and-pay capability can be added to legacy terminals via an external accessory, connected to the POS over a serial link. This peripheral contains the NFC reader and has knowledge of the payment protocols. It is responsible for abstracting away differences and quirks between different card networks and emitting familiar track-data to the POS. This is part of the interoperability benefit of mag-stripe profile; the POS may not have been designed for NFC but the output from the attached peripheral is still looks indistinguishable from an old-school swipe reader.

One corollary is that the POS does not micro-manage the NFC protocol or specify what bits to transmit. Instead there is a higher-level command structure, with the POS signaling that is ready for payment and NFC reader handling all exchange with the card, returning track-data after completion. Compromising the POS software– as in the case of Target breach— does not automatically translate to running arbitrary code on the NFC reader or otherwise controlling NFC traffic. For the purposes of this discussion, we will assume the worst-case scenario and still consider attacks where NFC reader is behaving maliciously instead of following the expected protocol.

Preventing replay

Simplest attack involves capturing the emulated magnetic stripe and trying to reuse this for another transaction. There are two reasons this is unlikely to work. As noted earlier, that track data incorporates a challenge issued by the NFC reader, the so-called “unpredictable number” generated randomly. Captured data from compromised POS contains a CVC3 corresponding to the choice of UN dictated by the attached reader for that particular transaction. Trying to reuse the same information at another reader will fail unless the exact same UN is chosen, which is unlikely when these are generated randomly. Granted there have been reports in the literature of catastrophic failures of the random number generator in EMV hardware [Anderson et al.] in the context of ATMs.  Since attackers can choose which retailers to target as well as the where they will monetize the stolen information, they could carefully pick stores employing such flawed hardware in their NFC terminals, to maximize the chances that UN values involved  will be repeated with high-probability.

But there is a secondary mechanism to prevent such misuse: the application transaction counter or ATC. This value also appears in track-data and can be optionally incorporated into the CVC3 calculation. If ATC were not included in CVC3, then a repeated UN would permit replay. Attackers could even try to repeat the protocol multiple times with the card and sample multiple CVC3 values corresponding to different values of the UN. Fortunately “sane” configurations include ATC in the CVC3 computation. But there is another security check that is left up to the issuer: enforcing that ATC is indeed acting as a unique counter.

Keeping count

Suppose that our enterprising crooks also observed that NFC track-data can be encoded on a plain magnetic-stripe and swiped, due to the lenient behavior of payment processors and issuers. Could they create a new credit-card using the data captured from compromised POS and use it repeatedly for purchases?

If the issuer is not paying attention to the payment mode and willing to apply CVC3 validation logic to a swipe transaction, the cryptographic check will be satisfied. But the issuer will observe something strange: a repeated ATC value. When the consumer made a purchase at Target, suppose their ATC was at 10. Since it is supposed to increment for each transaction, the next time the issuer receives an authorization request containing NFC track-data, they would expect to see a value greater than 10. It could be 11 but it could also be 12 or higher due to incomplete transactions which caused ATC to be incremented without ever resulting in an authorization request sent to the card issuer. But observing the same ATC twice for two different transactions? There is no legitimate scenario for that. Provided the issuer declines a second transaction using the same counter, attackers can not monetize track-data passively captured at the POS.

Active attacks

Passive being the operative word in the previous statement. So far we have focused on attacks where the adversary watches an ordinary tap-and-pay transaction taking place, waits for the simulated NFC “track-data” to arrive at the POS, copies this information and exfiltrates it for future use. But it is not useful to to hypothesize new defenses without also allowing for the presumed attackers to adopt their strategy in response. Knowing that they are dealing with contactless cards, the adversary could also adopt a different strategy such as sampling multiple transactions. For example they could program their POS malware to instruct the NFC reader to repeat the transaction five times, ending up with not just one but five samples of track-data with different UN/ATC/CVC3 combinations. The final post in this series will discuss how such attacks can be frustrated by proper issuer configuration.

[continued]

CP

Target breach, credit card security and NFC (part II)

[continued from part I]

Mutatis mutandis

The key difference in the simulated magnetic-stripe from NFC payment protocols such as Paypass is that track-data artificially constructed this way is not completely static. It changes slightly for each transaction, based on the state of the card and inputs dictated by the reader. Security against compromised point-of-sale terminals– what happened at Target– depends partly on the protocol and partly on issuer-specific policies decided by individual banks.

Here is what does not change between transactions:

  • Credit-card number: These protocols do not implement one-time-use card numbers or any other scheme designed to hide the “real” card number from the merchant.
  • Expiration date: Ditto.
  • Card-holder name: This is the field used to print the customer name on receipts. For contactless payments often it is a requirement that issuers redact the field to a generic label such as “customer,” possibly as reluctant PR response to the hysteria around NFC skimming stories.  (Redaction has an unexpected interaction with certain retailers’ practice of asking for ID during check-out. If there is no name displayed by the register, what would you compare the name on the driver’s license against?)

Instead the variable fields are:

  • ATC (Application Transaction Counter): Incremented for each transaction, regardless of whether the payment was successfully authorized. The protocol defines exactly what point in a transaction ATC will be incremented. Usually it is not automatically done when the payment application is selected but
  • UN (Unpredictable Number): This is effectively a challenge issued from the NFC reader to the card. It is picked unilaterally by the reader.
  • CVC3, also known as dynamic CVC: This is the response generated by the card in response to the reader challenge, serving as an integrity check over the data. CVC3 is of variable length based on provisioning parameters, typically from three to five digits similar to the CVC1/2 format. It is a function of a fixed IV representing card data, UN, secret cryptographic keys provisioned on the card and optionally the ATC, depending on card configuration. (More precisely ATC is always included in the computation but it is set  to all zeroes when not in use.)

Armed with this outline and without going into the details of how CVC3 is computed– suspending disbelief for now that the cryptography is sound, never-mind that a 3-5 digit “integrity check” is subject to brute-forcing– we can begin to speculate on what would happen to a hypothetical customer paying via NFC at a compromised Target point-of-sale terminal.

Fungible payment modes

First surprise is that paying via NFC by itself does not confer immunity against attacks using other payment modes. One might assume that whatever attacks are carried out against a contactless card will at best allow making fraudulent payments at other NFC terminals, but not for plain swipe or card-not-present transactions on the Internet. (This would be a “reduction” of risk only to the extent that NFC deployment remains relatively rare, which is realistically true today.) But the premise is false. As explained in earlier posts, there is by-design interchangeability between simulated track data from NFC and ordinary magnetic stripes. It is possible to copy track-data containing ATC/UN/CVC3, encode it on a plain plastic card and use that in a swipe-transaction. This will look correct through the reader, terminal, payment processor, all the way to the issuer responsible for  authorizing the charge.

Whether or not the charge is accepted depends on issuer configuration. In addition to receiving track data, the issuer also receives additional meta-data about the payment indicating payment mode such as swipe, NFC tap or manually keyed-in (when the stripe is damaged for example) On top of that track-data includes a service code which is typically different between physical magnetic stripes and their NFC incarnation. Neither of these can be influenced by the customer doing the swiping. Payment mode is determined by the terminal, while tampering with the service code will invalidate the CVC. At least in theory, issuers can cross-check payment mode against specific fields of track-data, rejecting attempts to replay NFC transactions on plain plastic cards, even if they carry valid CVC3 codes.

But attacks dating back to 2012 demonstrated in the field that many issuers are not performing that check.** This is possibly because many terminals are incorrectly configured, reporting the wrong mode even under normal operation. This makes issuers highly reluctant to reject transactions unless the probability of fraud is high. (Keeping in mind that false negatives– rejecting valid transactions as fraudulent– has a tangible revenue impact for the issuer because they earn interchange fees from each payment.)

In summary we have to consider attack strategies which attempt to monetize captured data in any possible payment mode: other NFC terminals, plain swipe transactions and even online purchases.

[continued]

CP

** Interestingly the converse is also possible, as demonstrated by a former colleague of this blogger. That engineer scanned the static track-data out from a plastic card and programmed an NFC application to use that as a template, with clever tricks to prevent the CVC3 from overwriting any part of the static data. Surprisingly it worked for some combinations of card issuers and payment terminals.

Target breach, credit card security and NFC (part I)

This holiday season has not been kind to retailers. First Target experienced one of the worst data breaches in recent memory, with the damage toll continuing to rise and the scope threatening to expand. From 40 million initial estimates and only in-store purchases, the retailer added another 70 million online shoppers, also including email, phone numbers and email addresses in the compromised data. Then the upscale retailer Neimann Marcus jumped into the fray, announcing that it too had experienced an intrusion resulting in the loss of credit card data. Not to be outdone, the crafts supplier Michaels announced that it had detected a successful attack resulting in loss of credit cards.

The great chip & PIN diversion

In a subtle attempt to shift blame back to the credit-card networks, the Target CEO went on the record to praise the virtues of chip & PIN cards. Kim Zetter of Wired quickly pointed out a slightly inconvenient fact: Target rejected a program back in 2004 to upgrade point-of-sale terminals for accepting chip & PIN technology. It turns out there is even more recent evidence of how little Target cared about supporting new payment technologies: very few of their stores accept NFC payments. Contrast this with Walgreens, CVS and Whole Foods which accept contactless payments at most locations. This state of affairs casts some doubt on Target’s avowed commitment to chip & PIN; NFC is a bridge technology to full chip & PIN.  NFC-enabled debit/credit cards as well as their mobile incarnations such as Google Wallet implement simplified versions (“profiles” more accurately) of the same EMV protocols.

Would NFC have protected Target customers?

Answering this question requires a closer look at the protocol. At first blush it seems that one can achieve much better security with contactless payments, at least against the specific risk Target customers faced: compromised point-of-sale terminals. A plastic card is a passive, inert object encoding static data. By contrast NFC payments involve smart cards with embedded chips– in other words miniature computers– or even full-scale mobile devices such as phones. Being programmable environments, they can support elaborate payment protocols leveraging strong cryptography. The question is how far that promise is realized in current deployments.

Protocols on paper and in the field

EMV defines the umbrella standard for contactless payments, while each particular payment network has slight tweaks and a proprietary brand for their variant: Mastercard PayPass, Visa payWave, American Express ExpressPay and Discover Zip. These protocols are not exactly interchangeable, but they are designed for coexistence: it is possible to have a single card/phone contain both Mastercard and Visa payment instruments, with the POS selecting one based on some combination of user and merchant preference. For our purposes, the critical detail is that commonly fielded NFC systems in the US use a “mild” version of the full chip & PIN protocol, walking a fine line between remaining compatible with existing infrastructure and providing additional security features.

It’s all magnetic-stripes

Specifically these systems implement the magnetic-stripe profile of EMV protocols. They do not use the heavy-weight cryptography in full chip & PIN, such as static-data authentication or even more robust dynamic-data authentication using unique RSA keys. Instead they emulate an old-school magnetic stripe at the logical level. Emphasis on logical; not to be confused with programmable/dynamic stripe technology such as Coin, which does feature a physical incarnation of a magnetic stripe driven by chips embedded into the card. By contrast an NFC payment does not involve any object resembling a stripe being magnetically read. Physical characteristics of the communication between NFC reader and card look nothing like the act of swiping a plastic card: the induction field used for powering the circuitry embedded in the card, the specific frequency for transmission over the air (13.56Mhz) and data encoding.

Instead of low-level hardware characteristics, it is the data-format associated with magnetic-stripes being simulated. At the end of the exchange between card and reader, the reader constructs a result that looks similar to what a plain magnetic stripe reader might output after processing an old-school plastic card. For example there are two tracks of data, the first one contains  credit card number and expiration date, while the second track has a field reserved for the card-holder name, all of this specified by ISO/IEC 7813.

[continued]

CP

Meaningful choice: AppOps, Android permissions and clashing interests (part IV)

Picking up on the question raised in the previous post: users and software publishers often have conflicting interests– as in the case of Android permissions requested by applications for the purpose of monetizing user data. How does the platform owner arbitrate and who are they likely to side with? Do they enhance the platform with functionality such as AppOps that allow users to protect their privacy at the expense of developer revenue? The answer depends on the balance of power between these actors.

Market power: platform vs developers

One red herring we can rule out immediately: direct revenue for the platform provider does not enter into the picture. Google provides the application market Play Store for Android and takes a 30% commission from each install for paid software. But paid applications rarely have to request excessive permissions and spy on users; they already have a revenue source from distribution. The most egregious offenders when it comes to user tracking tend to be “free” applications trying to make money after the fact, by giving away the application and targeting advertising. Frustrating that model has no immediate impact on the bottom line; that revenue stream is not shared anyway.

Here are three scenarios, with different trade-offs faced by the platform provider.

New entrant

If the platform is late to the game as in the case of Windows Phone or otherwise struggling to gain traction or defend an eroding market position as with Blackberry, it is in desperate need of applications. In this scenario the OS provider will be doing everything it can to court developers, trying to entice them with incentives. Witness how Microsoft offered  cash incentives and heavy technical assistance for startups to port popular mobile apps to Windows Phone.

In this situation the platform owner needs developers more than they need the platform. Why waste time writing a Windows application– which will likely require C# and entirely new development environment that few people are familiar with– when there is a proven market for iPhone and Android apps? Given such tall odds of attracting developers in the first place, it is very unlikely that the platform owner is going to risk alienating them by building functionality that interferes with monetization to advance the higher cause of  user privacy.

Near-monopoly position

This is the direct opposite of the first case. In this hypothetical case, the platform is close to being the only game in town for developers. It may enjoy complete market domination– the way Windows held sway on PCs during the 1990s– or it could be that alternative platforms offer no viable path for monetization even if they have sizable market share. (To the extent that Linux was a viable alternative OS, it did not boast a healthy commercial software ecosystem comparable to Windows and Mac.)

This time around the tables are turned: software publishers need the platform more than the platform needs any one application. In this case the platform owner can afford to take a strategic, forward-looking approach to improving the platform, free from competitive pressure that developers might flee to an alternative market. “Doing right” by users and cracking down on questionable developer practices is a luxury that companies can afford. In this scenario one would expect to see stronger safeguards for privacy, willingness to crack down on deceptive practices and technical features that empower users to defend their own privacy interests against over-zealous developers.

Interestingly regulatory intervention tends to contribute to such initiatives. Regulators often scrutinize companies with dominant market positions, and make demands for improving the platform in ways that represent their policy initiatives. In some cases these demands arguably make the platform worse– as in the drive for stronger copyright enforcement. Other times such demands, often presented as veiled threats for direct legal action, improve user privacy or security by bringing these agendas to the table in ways that ordinary consumers can not and which the platform owner can not ignore.

Competitive market

At least in the world of mobile operating systems, the near-monopoly situation has not been observed for any sustainable period. While Apple had a significant head-start with the iPhone, Android quickly closed the gap and has since surpassed iOS in market share globally. Today most popular mobile applications target both iPhone and Android as practical requirement for adoption. (Granted there can be significant quality differences, with the Android version often appearing to be an afterthought or summer internship project.)

Such competition benefits users as the different platform duke it out over design, performance, features and hardware choices. But it also means that neither company has the liberty of instituting policies that prove popular with consumers while alienating developers. Google in particular faces a particular vulnerability: iPhone users have proved more willing to pay for applications, as well as generate more revenue per user. Android may dwarf the iPhone in sheer number of unit shipments, but it falls far short of the Apple alternative when it comes to supporting a healthy commercial ecosystem for mobile developers.

AppOps: siding with developers over users

Given the competitive dynamics of mobile operating systems, it is not too difficult to see why AppOps was yanked out of Android in a hurry, before it caused any confusion and fear with the  developer community. (It also suggests fancier alternatives to AppOps with fewer side-effects are unlikely to become part of official Android.) In choosing to side with developers over user privacy, the Android team proved they know all too well which side of their bread is buttered.

CP

Meaningful choice: AppOps, Android permissions and clashing interests (part III)

[continued from part II]

Monetization

Here is a scenario when users and application developers have directly opposed interests, and the platform owner is put into a position of having to arbitrate between these two actors.

Suppose our hypothetical consumer comes across a new mobile application they consider useful. It could boost their work productivity, help connect with friends or provide some entertainment. This person wants to install and user the application on their phone to extract that “utility.” Meanwhile the company who authored that application is interested in deriving revenue from providing that useful application. In an ideal market, consumers can always negotiate and choose between:

  1. “Paid” version where the consumer pays upfront for installing the application and/or pays over time for continued access to the cloud service associated with that app. This is the more customary notion of payment where money exchanges hands.
  2. “Free” version funded by targeted advertising and user-data mining. As with other examples of seemingly “free” lunch, consumers pay dearly in privacy and attention, while avoiding monetary costs. This could involve collecting location information to display advertising based on geographic proximity to stores for example.

Developer’s ultimatum: take it or leave it

Indeed many application have this dual cost structure. Often there is even an upsell within the free version, giving users the opportunity to upgrade to paid version and get rid of advertising  nuisances. But sometimes the decision is made unilaterally by the application developer committing to one of the two models. There is no version of Facebook or Twitter where users can buy their privacy outright, paying to opt-out of data collection and behavioral advertising. For whatever reason Facebook and Twitter have decided that the optimal business strategy is to not charge users for accessing the service, but instead monetize their eyeballs indirectly via advertising. From a transactional perspective, there is nothing wrong or unfair per se about this, as long there is transparency into the terms of the arrangement. Most reputable software publishers will describe in painstaking terms exactly what nefarious data collection practices are implemented in their terms-of-use and privacy policies– which everyone clicks through without reading. Still all that legalese counts as notice, and clicking “I agree” constitutes informed consent on the part of the consumer.

Is there another option available to users dissatisfied with the status quo? There are two ways to interpret that question.

  • Capability, or “can it be done?” Can users continue to enjoy the “useful” functionality provided by an application while opting out of its harmful data-collection practices? This is a clear-cut question of facts, which depends on the nitty-gritty implementation details of  the platform/hardware where the app runs.
  • Ethics, or “should it be done?” Assuming we answer the first question in the affirmative, is it fair game for users to take such measures in the name of privacy “self-defense”? Many people would frown upon exploiting some trick to get paid applications for free. What about interfering with the business model of the developer by installing the application while disabling its ability to be monetized? Here we quickly get into gray areas. There is a  vocal group arguing that no one is hurt by pirating commercial software; surely blocking monetization can not be worse than outright stealing a copy of free (in the beer sense) software to begin with?

Off with their permissions

Android permissions and AppOps-type functionality goes to the heart of the first question. If users could start selectively disabling permissions, instead of having to agree wholesale to take-it-or-leave-it ultimatum from the application developer, they could have the best of both worlds. They can install and use it to get the benefit of the features without having to pay for the privacy harms caused by unwanted data collection.

As the second post pointed out, AppOps is not necessarily the ideal solution here. Bluntly taking away privileges can be disruptive, introducing new error cases into an application that were not  anticipated by its developers. The only way this could work is if the revoked privilege is rarely used or only used under user direction. For example an application may never resort to recording audio or taking pictures unless the user presses a particular button to invoke some specific feature. In that case removing its microphone and camera permissions will not interfere with ordinary usage, while guaranteeing that the application will not be snooping on conversations and scenes in its vicinity. Of course if the application is so predictable and well-behaved , there is no need for AppOps in the first place. Same improved privacy outcome can be obtained by not pressing that button. Meanwhile the more unruly applications that attempt to capture  audio/video randomly and never expect to get an access-denied error (because the developer declared upfront in the application manifest they need those permissions) will quickly run into trouble and crash.

Luckily there are more subtle ways to revoke access without breaking applications. Part I described one approach that creates the illusion of access granted– no unexpected “access-denied” errors to confuse the application– while returning either no data or completely fabricated bogus data which bears no relationship to the user. For Google it would be fairly straightforward to implement some variant of this as an improvement over AppOps. But would it be a wise move? The answer depends on which side one takes.

[continued]

CP

Meaningful choice: AppOps, Android permissions and clashing interests (part II)

Compatibility vs accuracy

Preceding post sketched a hypothetical solution to the AppOps compatibility problem by fabricating bogus data to appease an application when the user has declined permission. This approach does not complicate life for our (hypothetical) beleaguered developer: there are no security exceptions or bizarre error conditions introduced. All of the regular code paths in the application continue to work, only the data returned is “incorrect” in the sense that it does not correspond to the actual state of the world. This model is not entirely transparent; an application could discover that it is in fact in being lied to, depending on the model for generating the fake data. As the saying goes, liars need a good memory. If GPS is reporting a bogus location, this has to be self-consistent over time– no sudden teleportation across the globe– and also consistent with other signals such as IP address of wireless networks the device connects to. Skeptical applications could try to cross-check the reported location against such external indications and user behavior to detect fabrications– looking for restaurant recommendations in San Francisco when the location “reported” by the system is New York.

Still, the design subtly takes away the burden  from developers worried about missing permissions and shifts the balance of power back to users. They are now empowered to reject inappropriate permission requests– just like they could with the more blunt instrument of AppOps– without fear that tweaking permissions may break applications.

Business perspective

Why does Android not implement such a model where permissions can be declined without the unpleasant side-effects of AppOps? That question can not be answered at the technology level. It is more a function of competitive dynamics, of the delicate dance between platform providers vying for expanded market share (in other words Google) on the one hand, and software publishers writing applications that will make that platform more appealing.

Put bluntly, the interests of different actors are not always aligned.

  • Users: Users want to derive maximum benefit from their devices at lowest cost. “Cost” in this context includes not only direct monetary impact– upfront purchase price of phone, ongoing purchases for apps, services and content– but also intangibles such as privacy and quality of experience. For example maintaining control over personal information and not being subjected to intrusive advertising are equally relevant concerns.
  • Developers: Commercial developers are typically driven by profit maximization motives. In the short-term that could entail seemingly contradictory actions such as giving away content without generating any revenue. But these are best viewed as tactical steps supporting a long-term strategy focused on monetizing the user base. That monetization could take place directly by charging for the application and associated services (such as in-game purchases) or it could be indirect, when free content is subsidized by advertising.
    It should also be pointed out that this is not the only type of developer publishing mobile applications. Hobbyists and researchers can be far more interested in building reputation or releasing software out of altruistic motives.
  • Platform owner: Google for Android, but exact same calculus applies to Apple for iOS and MSFT on Windows Phone. Seeks maximum market share for its platform that is consistent with the licensing strategy. For example Android is given away for free to OEMs but there is a compatibility certification to qualify for using the trademark, as well as getting access to Google Play store. Apple by contrast uses an autocratic walled-garden model, where third-party hardware manufacturers can not build handsets using iOS. Microsoft used to charge for Windows Phone– inexplicable for an upstart OS trying to get traction– but that strategy may be changing.

Divided loyalties

Looking more closely at how mobile platforms gain market share, we find the platform owner with divided loyalties, trying to appease multiple constituencies. On the one hand it helps to do right by users. On the other hand, privacy and security considerations are only one of the factors contributing to such decisions. (In particular, it is an often lamented fact of life in the security community that better privacy does not help sell products the same way shiny features can. It remains to be seen to what extent the rude-awakenings inspired by Edward Snowden can change that.) There is an even bigger market distortion caused by the fact that users do not directly pick a platform. That decision is often made by other participants in the ecosystem, such as handset manufacturers who pick what OS to install on their phones– a decision the user can not easily override– and wireless carriers who wield influence by cherry-picking devices to run on their network and subsidizing/promoting the favored ones.

For all participants with a say on whether they will be using Android, iOS, Windows Phone or Blackberry, one important criteria is availability of applications. The greater the selection of apps available on that platform, the more attractive it becomes for users/carriers/handset-manufacturers. This in turn breeds a positive feedback loop: developers want to maximize their audience, so they will primarily target their applications at popular platforms.

In the next post we will argue that Android permissions– specifically ones allowing developers to monetize apps in ways users find objectionable– creates a textbook example of clashing interests between software publishers and users, forcing the platform owner to pick sides.

[continued]

CP

Meaningful choice: AppOps, Android permissions and clashing interests (part I)

The recent furor over Android 4.2.2. removing AppOps is a great example of Lawrence Lessig’s idea of regulation-by-code, when design decisions in technology are used to promote the interests of one particular group– in this case application developers– over another disfavored group, namely users.

First some background on this debacle. Android implements a relatively coarse-grained permission model, controlling what can be done by applications installed on the device. For example an app can be prevented from reading address book, making phone calls, sending text messages, accessing the camera/microphone or using Bluetooth. When this model debuted circa 2007, it represented a significant advance in terms of security models implemented for an off-the-shelf consumer device.

Sure, the academic literature did not lack for examples of elaborate fine-grained sandboxing schemes to control not only whether an application could access local storage but specify exactly which files it could read/write. Yet the state-of-the-art for  PCs and Macs continued to rely on user accounts as the fundamental security boundary. The assumption was any application user runs automatically inherits all access rights available to that user. For example when a Windows application is installed and run, that application executes with the full privileges associated with that account. (In fact since installers typically required administrator privileges, at least for a limited period of time the application had full reign over the machine.) User-account control in Vista, the first attempt to challenge that assumption, ended in disaster with its often ridiculed elevation prompt constantly asking users to make security decisions.

Luckily Android took a different route: applications declare the permissions they require to function, the user only gets to review & approve that once at the time of installation. There are very few situations beyond that when consumers were confronted with security prompts otherwise. (Authenticating with user credentials saved on the device being the primary exception.)

Meaningful choice

But there is a difference between mechanism and policy. While Android allowed specifying permissions at a granular level, it did not allow users to assign permissions at will. There was a very simple negotiation model. The author of the application specified exactly which permissions were required. The user either agreed and installed that application, or they disagreed and walked away. In other words: take it or leave it. This was clearly not a case of “meaningful choice,” in the same way that passengers can opt out of TSA security screening if they agree not to board the airplane. (Strictly speaking if one does not board the flight, they are not a passenger.)

Many people– both inside and outside Google– wandered out loud why Android did not give users more control. For example, why not allow an application to be installed but also remove some egregious privilege requested by the developer? This provides the best of both worlds for the user: she gets the benefit of running the application and avoids the potential privacy harms caused by granting the dangerous permission..

AppOps

And that is exactly what AppOps offered. A hidden feature inside the familiar Android Settings application, it allowed users to view and edit permissions granted to each application.

Too powerful for its own good apparently. Not long after EFF wrote a glowing review calling it “awesome privacy tools” and guiding Android users to third-party applications for unleashing this hidden functionality, a minor system update to Android quietly removed the feature completely. Before the functionality was present but hidden: not exposed to users directly through the standard Android user interface, suggesting that perhaps Google did not consider it ready for prime-time or only intended it for internal experiments. After installing the update it was gone for good, with work-arounds only available on rooted devices.

So what was the problem with AppOps? This question can be answered on two levels: technology and business.

Technology view

Privacy-infringement apologists may point out that allowing applications to be installed with a subset of requested permissions would greatly increase the complexity of writing applications. Instead of a simple model where the application either never gets to run or runs with all requested permissions, the developer has to worry about in-between states where some operation may fail because the user decided to deny that permission. At an implementation level, that translates into added complexity. Permission errors translate into an exception in code, so now the developer is stuck writing additional code to catch this error condition and respond appropriately. (Typically one of: exit the application in disgust, shame the user into granting missing permission or move on without the requested information.)

Why not fabricate data?

There is a simple counter-argument to that objection: if the user declined permission, let’s not trigger a fatal error but instead return bogus or empty data. The application wants to learn the current location but the user does not want to be tracked? Have “GPS” report a random location around the globe. Developer wants a list of all the contacts in the address book? Fabricate “John Doe” friends or report that this user has no contacts. Developer is asking for Bluetooth access? Appear to grant access, but pretend there are no other Bluetooth devices paired to connect to.

[continued]

CP

NFC card emulation and Android 4.4 (part IV)

Part III sketched the mechanics for host-based card emulation (HCE) in Android and how AID routing is used to create an open ecosystem for user-mode applications to offer NFC services. This post will look at some edge-cases of HCE and some differences from the embedded secure element.

Feature parity

A natural question is whether HCE is “equivalent” to embedded SE or UICC from a functional perspective. (It is clearly weaker in terms of security guarantees, a subject for the next post in this series.) There are two different interpretations of that criteria:

  1. Can any application implemented with hardware SE also work with HCE?
  2. Is it possible to distinguish externally whether HCE or hardware SE is in use?

In the first scenario we assume external NFC readers interacting with the device remain fixed. No changes are envisioned to the deployed readers while we switch the phone from using eSE to HCE. This is the model relevant for compatibility. In the second case the NFC reader is going out of its way to try to distinguish between hardware and software-backed implementations.

Edge-cases

Short answer to #1 is yes in principle, but not the way it is currently implemented in Android due to some edge-cases. SELECT semantics in Android HCE are subtly incompatible with the way a Global Platform compliant card-manager behaves.

  • If an application with given AID exists, card manager switches the active context to that one. This is outside the control of the currently selected application.
  • If such an application does not exist, the SELECT command in its entirety is delivered to the currently active application. This is required  because ISO7816 “overloads” SELECT command for simulating a file-system on smart cards. The command corresponds to “directory” traversal (eg change directory) as well as opening a “file” for reading, depending on the currently selected “file.”

The second part does not work with HCE in Android. SELECT routing is handled by the OS and for unknown AIDs a simple error is returned instead of giving the current application an opportunity to respond.

Another difference is that in Global Platform, an application can be installed as “default-selected” meaning that it is automatically activated when the chip is powered on. There is no SELECT required, readers can start sending application-specific commands right away. Several smart card standards including PIV mandate that cards are configured in this manner. Android HCE does not support this. Trying to interact with the phone in HCE mode as if the intended application was already activated (without an explicit SELECT containing the AID as hint to Android) is an error.

Neither of these are fundamental limitations. SELECT behavior can be changed and NFC stack can also define a notion of “default selected application,” along with conflict-resolution rules.

Distinguishing externally

By similar reasoning, distinguishing HCE from hardware SE is trivial in the current Android incarnation: try to select the card manager, either by using its explicit AID (slightly different for each manufacturer such as NXP vs Oberthur) or with empty SELECT per Global Platform. Hardware SE will return the response from the card manager describing its functionality, HCE mode will return an error.

But as noted above this is not a hard limitation. A “card manager” replacement complete with cryptographic keys, secure channels and lifecycle management (so it will appear to be bricked after too many failed authentication attempts) can be implemented at Android level, set as default selected application. To an observer looking only at the content of messages flowing over NFC, this emulation will behave identical to hardware SE.

Of course there are side-channels such as the timing of request/response pairs and other meta-data that can give away the source. For example if eSE supports extended-length APDUs (HCE in Kitkat does not) that discrepancy can be used, or the buffering behavior when reading large APDUs can be different since the host has lots of memory and won’t exhibit a sharp discontinuity when the data suddenly exceeds the size of the limited buffer in eSE.

Coexisting with hardware SE

Interesting enough, Kitkat still allows using the embedded-secure element alongside HCE, perhaps in a nod to backwards compatibility. This mode leverages the AID-routing feature built into the NFC controller, which allows picking a card-emulation route on-the-fly based on AIDs at the hardware level. (Same mechanism used to support applets on both UICC and eSE when multiple chips are connected to the controller.)

All AIDs for applications residing on the secure element need to be declared in the  manifest. Android passes this information straight to the NFC controller; the routing decision is made at hardware level. SELECT commands for these applications will not make it to host operating system. NFC controller internally maintains a table of AIDs and associated routes. It is the responsibility of Android to populate that table based on information collected across all manifests. Any application not explicitly listed is sent up the default route.

There is a catch. NFC controllers have a limited amount of space available for maintaining such tables. The ideal scenario has most applications residing at the default route and not requiring a table-entry, with only a few exceptions listed for redirection. Seen in this light,  decision to use HCE as default and embedded SE as the exception reaffirms the change in emphasis from relying on hardware SE towards host-based designs.

CP