HCE vs embedded secure element: taking Android out of the TCB (part IV)

Continuing the security comparison between HCE and secure-element based NFC applications, this post expands on an earlier theme around attack-surface, focusing on one massive piece of vulnerable code: the Android operating system itself.

When root means game-over

Consider the following hypothetical: is it possible to build an EMV payment application that runs on Android and yet can resist attacks from a remote adversary who is running arbitrary code with root privileges? At first this seems theoretically impossible. Payments are authorized based on the possession of a cryptographic key only known to the legitimate card holder. The assumption is if you have possession of the key, by executing a protocol specified by EMV that calls for proving possession of that key without revealing it– you are authorized to spend the funds associated with that account. If our hypothetical adversary has achieved root privileges on the device, they have full access to memory and storage of every application running on that device. That includes the payment application wielding this secret. Even if that secret was protected by a PIN/passphrase (let’s suspend disbelief and assume users pick high-entropy secrets immune to guessing) that PIN/passphrase will be input via phone UI such as an on-screen keyboard at some point. Since we posit that our adversary is running with root privileges, she can watch this interaction and learn the passphrase. Alternatively she can simply wait until after the secret has been fully decrypted locally– necessary for the device to be able to perform the type of computations envisioned by EMV payment protocols– and capture it at that point. No secret managed completely by an Android application can be immune from an attacker with root privileges on that Android device. It’s only a matter of knowing when/where to look for that secret in the target application’s address space; this is security through obscurity at best.

SE difference

Unless of course, the secret is not directly available to the mobile application either. Enter hardware secure elements. If  secrets such as cryptographic keys are stored in the secure element and never available in the clear to the mobile application, even root-level compromise of Android does not help our adversary. The embedded secure element is its own mini-computer, with separate RAM, storage and embedded operating system with its own concept of access control. Being root on Android is meaningless to SE: it grants no special privileges. In much the same way that an HSM can isolate cryptographic keys by offering an interface to perform operations with the key without revealing the raw bits of the key, SE keeps Android at arms-length from secret material.

Safe provisioning

The astute reader might ask how these cryptographic secrets that enable payments reached the secure element in the first place. It is common for provisioning to take place over-the-air, as opposed to the much more impractical alternative of requiring physical presence, where the user must walk into a bank branch and present their phone. That implies that some bits are pushed over the network to the mobile application which relays them to the secure element. (Recall that the only direct network interface SE has access to is NFC which is only good over short distances. All other communication such as accessing the card-issuer API endpoint over the Internet must be pass through the host device.)

Does that create an opportunity for malware running with root privileges to capture the secret, for ever so briefly when it is passing through the Android application? Not if the provisioning system is properly designed. Recall that secure elements compliant with Global Platform standard are “personalized” with unique keys (colloquially known as card-manager keys) required to perform administrative operations. These keys are not known to the owner of the phone or even the operating system on the mobile device; they are managed by a third-party called “trusted services-manager” or TSM. When TSM is installing a payment application and configuring that application with its own set of secrets, the commands sent to the SE for performing those steps are encrypted. Global Platform specification defines a “secure messaging” protocol describing the exact steps for establishing an authenticated & encrypted link between TSM and secure element. This protocol, or more accurately series of protocols since there are multiple variants, is designed to ensure that even when TSM and SE are not in physical proximity, as in the case of provisioning a payment application over the Internet– the issuer can be assured that sensitive information such as payment keys are delivered only to the designated SE and not recoverable by anyone else. While it is true that the commands sent by TSM are visible to the host operating system, where they can be intercepted or even modified by our hypothetical adversary who has attained root privileges, the secure messaging protocol ensures that no useful information is learned by mounting such an attack.

Threat models: ideal vs as-implemented

So this is another fundamental difference between applications implemented in SE versus those relying on host-card emulation. For HCE applications, Android operating system is part of the trusted computing-base by necessity. Any vulnerability that allows defeating the isolation between different apps– such as local privilege escalation to root– is  game-over for scenarios using host-card emulation without a hardware secure element. By contrast, SE based applications can in principle survive attacks in this very stringent threat model, where we posit a remote adversary (eg one who does not have physical possession of the phone but is running her choice of code on the device) has attained root privileges.

“In principle” is the operative phrase. While Global Platform protects secrets en route the secure element, there is a preceding step not covered by GP: authenticating the card-holder. Suppose the consumer is asked to enter the username and password for their online bank account into the Android application to verify their identity and request provisioning from that bank. That design is blatantly  vulnerable to local malware on the device. Those bank account details could be captured and relayed to a remote attacker, who proceeds to repeat the exact same process on a device she controls, with the payment credentials being delivered to her secure element. She could even preempt the legitimate user, by provisioning first and instructing the malware to prevent the original card-holder from completing the task, lest the bank notice the anomaly of two different devices requesting cards in quick succession. Some form of out-of-band authentication is required to thwart this attack, such as logging into the bank website from a different machine to initiate the request. (Ironically calling the bank and answering questions will not work since the audio-stream from the phone is also available to the attacker.) But even in the basic scenario with weak provisioning, SE provides a useful guarantee: if the device is compromised by malware after payment credentials are provisioned, the credentials are safe.

There is one more subtle attack that does not rely on trying to extract secrets from the local device. Suppose the remote attacker with root privileges abandons their effort to extract secrets from SE but instead attempts to use the SE, exactly as it would have been invoked for a payment transaction? The next and final post in this series will look at how the integration of SE with NFC controller can frustrate such relay attacks, in stark contract from HCE applications which are necessarily vulnerable.

[continued]

CP

 

 

 


Lessons from LinkedIn Intro for product security teams

That was quick: the controversial LinkedIn Intro feature– which effectively performed a man-in-the-middle attack against user email on iOS devices– has been scrapped unceremoniously less than three months after its introduction. It was a quiet farewell to a feature announced with great fanfare in a blog-post trumpeting the impressive engineering feats involved: install LinkedIn as email proxy to intercept and capture user email, route all incoming messages to LinkedIn servers in the cloud all for the purpose of annotating them with LinkedIn profile information about recipients and deliver it back into the inbox. Amidst the predictable chorus of I-told-you-so and schadenfreude is a question that is rarely raised: Why did this feature ship at all in the first place? More importantly from the perspective of security professionals: what was the involvement of LinkedIn security team in its conception, design and implementation? What lessons can we draw from this debacle for avoiding reputational risk with ill-conceived features damaging user trust?

Much of what follows is qualified by the caveat that this blogger is not privy to the internal deliberations that may have taken place at LinkedIn around Intro. For that reason we can not distinguish between whether this is a failure in the process for security assurance (as such, entirely avoidable) or simply well thought-out business decision that simply proved incorrect hindsight.

Moving security upstream

In companies with an immature approach to information security, the bulk of the activity around managing risks appear towards the end of the product cycle. At that stage the product requirements have been already cast in stone, technical architecture well-defined, specifications written– to the extent that anyone writes specs in this day and age of agile methodologies– and even the bulk of the implementation is completed. Into this scene steps in our security engineer at the eleventh hour to conduct some type of sanity-check. It may range from a cursory high-level threat model to low-level code review or black-box testing. That work can be extremely valuable depending on the amount of time/skills invested in uncovering vulnerabilities. Yet the bigger problem remains: much of the security battle has already been won or lost based on decisions made long before a single line of code is written.  Such decisions are not expressed in localized code chunks that can be spotted by the security reviewer scrutinizing the final implementation of a finished product. Their implications cut across feature lines.

Beyond whack-a-mole

Consider the way web browsers were designed before IE7 and Chrome: massively complicated functionality– HTML rendering and JavaScript execution– subject to attacks by any website the user cared to visit, contained in a single process running with the full privileges of the user. If there was a memory corruption vulnerability anywhere in those millions of lines of code (guaranteed to be present statistically speaking), the attacker exploiting that gets full control of the user’s account– and often the entire machine, since everyone was running with administrator privileges anyway. There are two approaches to solving this problem. First one is what MSFT historically tried: throwing more security review time at the problem, trying to find one more buffer-overrun. While this is not entirely a game of playing whack-a-mole– a downward trend in bugs introduced vs. found can be achieves with enough resources– it does not solve the fundamental problem: memory corruption bugs are very likely to exist in complex software implemented in low-level languages. At some point diminishing returns kicks-in.

The major security innovation in IE8 and Chrome was the introduction of sandboxing: fundamentally changing the design of the web-browser to run the dangerous code in low-privileged processes, adding defense-in-depth to contain the fallout from successful exploitation of a vulnerability that somehow eluded all attempts to uncover it before shipping. This is a fundamental change to the design and architecture of the web browser. Unlike fixing the yet-another-buffer-overrun problem, it was not “discovered” by a security researcher staring at the code or running an automated fuzzer. Nor is it implemented by making a small, local change in the code base. It calls for significant modifications across the board– pieces of functionality that used to be reside locally in memory, now are managed by another process, subject to security restrictions around access. Because of far-reaching consequences, security features such as sandboxing must be carefully accounted for in the product plans from the beginning, as part of a fundamental design criteria (or even more difficult re-design exercise, in case of Internet Explorer, saddled with a legacy 10-year old architecture.)

Security and development lifecycle

Introduction of sandboxing in web browsers is one example of the more general pattern that security assurance has greater impact as it moves upstream in the development life-cycle. Instead of coming into evaluate and find flaws in an almost-finished product, security professionals participate in architecture and design phases. This also reduces costs for fixing issues: not only are some flaws easier to spot at the design level, they are also much cheaper to fix before any time has been wasted on writing code. There is no reason to stop at product design either: even before a project is formally kicked-off, security team can provide ad hoc consulting, give presentations on common security defects or develop reference implementations of core functionality such as authentication libraries to be incorporated into upcoming products. But the ultimate sign of maturity in risk-management is when security professional have a voice at the table when deciding what to ship. Incidentally having a vote is not the same as having veto power; risk management for information security is one of many perspectives for the business.  A healthy organization provides an avenue for the security team to flag dubious product ideas early in the process before they gain momentum and acquire the psychological attachment of sunk-costs.

Whither LinkedIn?

Returning to the problem of LinkedIn Intro, the two questions are:

  • Does LinkedIn culture give the security team an opportunity for voicing objections to reckless product ideas before they are fully baked?
  • Assuming the answer is yes, did the team try– if unsuccessfully– to kill Intro in an effort to save the company from much public ridicule and embarrassment down the line? If yes, the security assurance process has worked, the team has done its job and the failure rests with decision-makers who overruled their objections and green-lighted this boondoggle.

We do not know the answer. The public record only reflects that the LinkedIn security team attempted to defend Intro, even going so far as to point out that it was reviewed by iSEC Partners. (Curiously, iSec itself did not step forward to defend their client and their brilliant product idea.) But that does not necessarily imply unequivocal support. This would not be the first time that a security team is put in the awkward position of publicly trying to defend a questionable design they unsuccessfully lobbied to change before.

CP


HCE vs embedded secure element: attack surface (part III)

In this post we continue the security comparison of mobile NFC scenarios using dedicated hardware  (such as UICC or embedded SE on Android) against the same use-case implemented on vanilla Android application with host card-emulation. In both cases, there is sensitive information entrusted to the application such as credentials required to complete an EMV transaction. This time we will focus on  attack surface and amount of code exposure these sensitive secrets have against software attacks. Borrowing the definition from MSDN:

The attack surface of an app is the union of code, interfaces, services, protocols, and practices available to all users, with a strong focus on what is accessible to unauthenticated users.

Here again it is clear that a mobile application is at a distinct disadvantage because the application and the platform it is built on-top is feature rich with connectivity and sharing functionality. Looking at the typical inputs an Android application may process:

  • Inputs from the UI– relevant when the phone lands into the hands of an attacker who can now press any button or otherwise try to bypass some access control
  • Network connectivity. At a minimum the application will need Internet access to provision payment instruments and interface with a back-end system for retrieving activity data.
  • Inter-process communication mechanisms from other applications installed on the same device. In Android this means intents, listeners etc. that the application responds to.
  • Filesystem. If the application relies on any data stored on disk, it must
  • NFC, inevitably for an application relying on NFC as transport.

By contrast the typical secure element has only 2 interfaces:

  • Wired or contact. For an ordinary smart card or SIM, this would be the physical connection attached to the brass plate on the surface, which receives power and signals form the reader. In the case of secure elements on mobile devices, these are typically hard-wired to the host device. When the SE is removable– for example with UICC or micro-SD based designs– it is possible  to use an external card-reader to access this interface.
  • Contactless or NFC, same as before.

While these are the only direct input paths, in many cases there is indirect exposure to other channels. For example there is often a companion user-mode application running on the host Android OS, helping load new application on the SE and configuring them. Such provisioning is often done over-the-air with the Android app simply shuttling data back-and-forth between its network connection and the contact interface of the SE.  This could be  straight through the base-band processor, bypassing the main Android OS or a standard TCP/IP connection. Either way an indirect channel exists where inputs from a potentially hostile network reach the secure element.

This is where a different property of the SE comes in: it is a locked-down environment, where routine operations– such as installing applications or even listing the existing ones– requires authentication with keys that are commonly not available to the owner of the phone. (They are instead held by the trusted-services manager or TSM entity responsible for card management.) This stands in contrast with an ordinary iPhone or Android where the user is free to install applications. Just in case the user makes a bad decision, each app has to worry about other malicious apps trying to subvert their security model and access private data associated with that application. By contrast code running on SE is tightly controlled and much of the complex functionality for managing the introduction of new code is not even accessible to ordinary attackers without possession of diversified keys unique to that particular SE.

Similarly in common secure element designs based on Global Platform, there is no concept of an all-powerful root/administrator with full access to the system. For example even the TSM armed with necessary keys can not read out the contents of EEPROM at will. This means that once an application is installed and secret material provisioned to that application (such as cryptographic keys for EMV chip & PIN payments) even the TSM has no way to read back those secrets from the card if the application does not allow it. One could imagine that TSM can try a different tactic: replace the legitimate application with a back-doored version designed to extract the secrets previously provisioned. But there is no concept of  “upgrade” in Global Platform: one can only delete an existing application instance– which also removes all of its associated data including the secrets– and install a new one. Barring vulnerabilities in the platform responsible for isolating multiple apps from each other (eg Java Card applet firewall) provisioned secrets are forward-secure. By contrast the author of ordinary mobile apps always have the option of upgrading their code in-place without losing data, creating another attack vector when code-signing process is subverted.

A similar risk applies on larger scale for the mobile operating system. Google effectively has root on Android devices, similarly for Apple on iOS and MSFT on Windows Phone. Often times the handset manufacturer and even wireless carrier subsidizing the device add their own apps running with system privileges, including remote update capabilities. These parties are the closest to a TSM incarnation (minus the “trusted” part) except they can snoop on any secret managed by any application on the device. Again the threat here is not that Google, Samsung or Verizon might go rogue, shipping malicious updates designed to steal information. The risk is that the platform includes this capability by-design, creating additional attack surface that others can attempt to exploit.

Finally there is the matter of sheer code-size: SE resources are highly limited, with EEPROM/flash storage on the order of 100KB– that includes code and data for all applications. That does not leave a lot of room for frivolous functionality, rarely used options or speculative features. This is a case where resource constraints help security by reducing total amount of code, and indirectly, opportunities for introducing bugs.

[continued]

CP

 


HCE vs embedded secure element: tamper resistance (part II)

Tamper-resistance

Tamper resistance refers to the ability of a system to resist attacks against its physical incarnation when in the hands of an attacker. From the perspective of the threat model, a key point is that we assume an adversary has gained physical access to the gadget. Duration of access and final condition of the device may vary depending on attack scenario:

  • Temporary vs. permanent. In the first case, the user may have temporarily left their device unattended in a hotel room, giving the attacker an opportunity to extract cryptographic keys or implant a backdoor. But the time allotted for accomplishing that task is limited. The adversary must ultimately return the device– or its functional clone– to avoid raising suspicion. In the second case, the device may have been lost or otherwise captured with no intention of being returned to its rightful owner, granting the attacker unlimited time to work.
  • Destructive vs. stealthy: This is mainly a concern for attackers who want to avoid detection, when returning the device in a completely mangled or damaged state will not do. This may either limit the range of attacks possible or it may require an elaborate substitution scheme following a successful attack. For example, if the goal is extracting secret keys from a smart-card, it may be acceptable to destroy the card in the process, as long as an identical-looking card can be created to behave functionally when it is provisioned with  same secret keys extracted out of the original. The user will not be any wiser.

Lasers and spectrometers

Attacks are commonly grouped into three categories, using the terminology from Tunstall et al:

  1. Non-invasive. These approaches attempt to extract information without modifying the card. For example simply measuring the time taken to complete various operations with a high-precision timer or introducing faults by varying the power-supply (without frying the chip) do not cause permanent damage to the card but may result in disclosure of information that was supposed to be contained in the card.
  2. Semi-invasive. Moving one step closer to the hardware, in this category are attacks that require the surface of the chip to be exposed. This includes passively monitoring electro-magnetic emanations from the chip as well as introducing temporary glitches, for example using precisely aimed laser pulses.
  3. Invasive. In the final group are attacks directly targeting the internal architecture of the chip, using sophisticated lab equipment. For example it may involve placing probes to monitor bus lines or even creating new wiring that alters the logic.

Comparison to off-the-shelf mobile hardware

Standard mobile device architecture does not even attempt at resisting physical attacks. For example reading any secrets in storage is as easy as removing the flash and using a standard connector to mount the same disk from another device. (Incidentally, disk encryption does little to hinder data recovery: Android disk encryption keys are derived from a user-chosen secret subject to brute-forcing.**) By contrast extracting data stored in the EEPROM or flash storage of a modern secure element– while not impossible by any means– requires significantly more work and dedicated laboratory equipment.

Similarly there is no attempt to reduce side-channel emissions on a standard ARM CPU such as shielding to reduce emanations or hide power consumption patterns. As simple experiments demonstrate, there is no reason to zap anything with lasers or carry out elaborate attacks to reverse engineer the circuitry: an ARM processor radiates so much in the way of EF radiation that meaningful signals can be picked up without even opening the case to reveal information about cryptographic operations. By contrast resistance to physical attacks are core part of the Common Criteria (CC) and FIPS 140-2 verification standards around cryptographic hardware. For example the SmartMX embedded secure element present in most NFC-enabled Android devices is part of a family of processors with EAL5+ level assurance according to CC.

Bottom line: for the purposes of resisting hardware attacks when the device lands in the hands of an attacker, there is no contest between an application implemented storing secrets on the main Android systems– such as a payment application using HCE– versus one implemented on dedicated cryptographic hardware such as the embedded secure element.

[continued]

CP

**  Android made matters worse with a design blunder: it forces the disk-encryption secret to be identical to the screen-unlock one. In other words that pattern/PIN/passphrase used to unlock the screen is the only secret input to a “slow” key-generation scheme that outputs the disk encryption key. Because unlocking the screen is a very common operation, this all but guarantees that a low-entropy, easily brute-forced secret will be used. This may have been a usability trade-off based on the assumption that asking users to juggle two different secrets– one only entered during boot and one used frequently for screen unlock– is too much.


Goto fail and more subtle ways to mismanage vulnerability response

As security professionals we are often guilty of focusing single-mindedly mindedly on one aspect of risk management, namely preventing vulnerabilities, to the exclusion of others: detection and response. This bias seems to have dominated discussion of the recent “goto fail” debacle in iOS/OS X and its wildly improbable close-cousin in GnuTLS. Apple has been roundly criticized and mocked for this self-explanatory flaw in SecureTransport, its homebrew SSL/TLS implementation. The bug voided all security guarantees the SSL/TLS protocol provides, rendering supposedly “protected” communications vulnerable to eavesdropping.

But much of the conversation and unofficial attempts at post-mortems (true to its secretive nature, Apple never published an official explanation, but conveniently created a well-timed distraction in the form of a whitepaper touting iOS security) focused on the low-level implementation details as root cause. Why is anyone using goto statements in this day-and-age, when the venerable Edsger Dijsktra declared way back in 1968 that they ought to be considered harmful? Why did they not adopt a coding convention requiring braces around all if/else conditionals? How could any intelligent compiler not flag the remainder of the function as unreachable code when the spurious goto statement was causing?** Why was the duplicate line missed in code reviews when it stands out blatantly in the delta? Did Apple not have a good change-control system for introducing code changes? Speaking of sane software engineering practices, how is it possible that code-flow jumps to a point labelled “fail” and yet still returns  success, misleading callers into believing that the function completed successfully? To step back one more level, why did Apple decide to maintain its own SSL/TLS implementation instead of leveraging open-source libraries such as NSS or openssl which have benefited from years of collective improvement and cryptographic expertise that Apple does not have in-house?

All good questions, partly motivated by a righteous indignation that such a catastrophic bug could be hiding in plain sight. But what about the aftermath? Once we accept the premise that a critical vulnerability exists, the focus shifts to response. Putting aside questions around why the flaw existed in the first place, let’s ask how well Apple handled its resolution.

  • There was no prior announcement that an important update was about to be released. Compare this to the advance warning MSFT provides for upcoming bulletins.
  • A passing mention in the release notes about the vulnerability, with an ominous statement to the effect that “an attacker with a privileged network position may capture or modify data in sessions protected by SSL/TLS.” Not a word about the critical nature of the flaw or a pleas for users to upgrade urgently. One would imagine that an implementation error that defeats SSL– the most widely deployed protocol for protecting communications on the Internet– and allows eavesdropping on millions of users’ traffic would hit a raw nerve in this post-Snowden world of  global surveillance. Compare Apple’s nonchalance and brevity to the level of detail in a past critical security update from Debian or even routine MSFT bulletins released every month.
  • The update was released on a Friday afternoon Pacific-time. This is the end of the work-week in Northern America, and well into the weekend in Europe. Due to lack of upfront disclosure by Apple, the exact nature of the vulnerability was not reverse-engineered publicly until several hours later. That is suboptimal timing to say the least for dropping a critical fix, especially in a managed enterprise IT environment with a large Mac fleet and security team tasked with trying to ensure that all employees upgrade their devices. (Granted, Apple never seems to have cared much for the enterprise market, as evidenced by weak support for centralized management compared to Windows or even Linux with third-party solutions.)
  • The update addressed the vulnerability only for iOS, leaving Mavericks, the latest and greatest desktop operating system vulnerable. In other words, Apple 0-dayed its own desktop/laptop users with an incomplete update aimed at mobile users. Why? At least three possibilities come to mind.
    1. Internal disconnect: Apple may not have realized the exact same bug existed in the OS X code base– but this is a stretch, given the extent of code sharing between them.
    2. Optimism/naiveté: Perhaps they were aware of the cross-platform nature of the vulnerability but assumed nobody would figure out exactly what had been fixed, giving Apple a leisurely time-frame to prepare an OS X update before the issue poses a risk to users. To anyone familiar with shrinking time-windows between patch release and exploit development, this is delusional thinking. There is 10 years worth of research on reverse-engineering vulnerabilities from patches, even when the vendor remains silent on details of the vulnerability or even existence of any vulnerabilities in the first place.
    3. Deliberate risk-taking / cost-minimization: The final possibility is Apple did not care or prioritized mobile platforms over traditional laptop & desktops. Some speculated that Apple was already planning to release an update to Mavericks incorporating this fix and saw no reason to rush an out-of-band patch. (Compare this to approach MSFT has taken towards critical vulnerabilities. When there is evidence of ongoing or imminent exploitation in the wild, the company has departed from the monthly cycle to deliver updates immediately as with MS13-008.)
  • No explanation after the fact about the root-cause of the vulnerability or steps taken to reduce chances of similar mistakes in the future. This is perhaps the most damning part. The improbable nature of the bug– one line of code mysteriously duplicated, looking so obviously incorrect on even the most cursory review– fueled much speculation and conspiracy theories around whether it had been a deliberate attempt to introduce a backdoor into Apple products. Companies are understandably reluctant to release internal postmortem out of fear that they may reveal proprietary information or portray individual employees in an unflattering light. But in this case even an official blog post summarizing the results of an investigation could have sufficed to quell  wild theories.

Coincidentally the same Friday this bug was exposed, this blogger gave a presentation at Airbnb arguing that OS X is a mediocre platform for enterprise security, citing lack of TPM, compatibility issues with smart-cards and dubious track record in delivering security updates. For the next four days of goto-fail fiasco, Apple piled on the evidence supporting that last point. In some ways the continuing silence out of Cupertino represents an even bigger failure to comprehend what it takes to maintain trust when vulnerabilities, even critical ones, are inevitable.

CP

** It turns out in this case the blame goes to gcc. By contrast MSVC does correctly flag the code as unreachable.


HCE vs embedded secure element: comparing risks (part I)

As described in earlier posts, Android 4.4 “Kitkat” has introduced host-based card emulation or HCE for NFC as a platform feature, opening this functionality up to third-party developers in ways that were not quite possible with the embedded secure element. In tandem with the platform API change, Nexus 5 launched without an embedded secure element, ending a run going back to the Nexus S where the hardware spec included that chip coupled to the NFC controller. Google Wallet was one of the first applications to migrate from using the eSE to HCE for its NFC use case, namely contactless payments.

An earlier four-part series compared HCE and hardware secure elements from a functional perspective, concluding that the current Android implementation is close (but not 100%) to feature parity with previous architecture when card-emulation route points to the eSE. The next set of posts will focus on security, looking at what additional risks are introduced by using HCE instead of dedicated hardware coupled to the NFC controller.

Another way to phrase this question: what did embedded SE buy in terms of security and what was lost when Android gave up on the SE due to opposition from wireless carriers? Can HCE achieve similar level of security assurance or are there scenarios inherently depending on special hardware incorporated into the device, regardless of its form factor as eSE, UICC or micro-SD?

Broadly speaking, there are 4 significant benefits ranging from the obvious to more subtle:

  1. Physical tamper resistance
  2. Reduced attack surface
  3. Taking Android out of the trusted computing base (TCB)
  4. Interface separation

Each of the following posts will tackle one of these aspects.

[continued]

CP


Chip & PIN, liability shift and the game of chicken (part II)

[continued from part I]

In a WSJ article, a representative from MasterCard describes the plan for incentivizing EMV adoption:

When the liability shift happens, what will change is that if there is an incidence of card fraud, whichever party has the lesser technology will bear the liability. [...] So if a merchant is still using the old system, they can still run a transaction with a swipe and a signature. But they will be liable for any fraudulent transactions if the customer has a chip card. And the same goes the other way – if the merchant has a new terminal, but the bank hasn’t issued a chip and PIN card to the customer, the bank would be liable.

This is an interesting approach. It leaves the card-holder out of the equation– no pesky consumer protection agencies to worry about. Instead banks and merchants square-off against each other in a race to adopt EMV before the other party does, lest they be left holding the bag for losses.

While MasterCard representative quoted in the article disclaims any attempt to move liability around, there is no question that the proposed scheme amounts to disrupting the current equilibrium temporarily. The way dispute resolution for charge-backs is handled today, typically the merchant gets the benefit of the doubt for card-present transactions– in other words in-store payments when there is a signed receipt proving that the merchant performed due diligence to confirm the transaction. Conversely for card-not-present transactions, benefit of the doubt goes to the issuer and the merchant eats the fraud loss, which explains many of the misguided schemes such as Verified-by-Visa desperately trying to make a dent in the incidence of such fraud. For now CNP is unlikely to play much of a role in EMV adoption. From a technology stance, all of the elements are in place to enable NFC payments over the web using mobile devices/tablets. Yet business/regulatory hurdles remain before such systems can be deployed broadly.

With the new incentive structure proposed by the card networks, merchants may find themselves on the losing side of an unauthorized transaction dispute even for card-present transactions, if they are dealing with chip & PIN cards. (One amusing consequence may be that such customers become persona non grata; merchants may decline to accept cards with chip & PIN, although such discrimination would almost certainly run afoul of network regulations.) In theory this gives merchants incentives to upgrade their POS and payment processing systems, in order to maintain the status quo vis-à-vis issuers. Dangling before issuers on the other side is the lure of a temporary reprieve from card-present fraud. Any bank that issues chip & PIN cards may enjoy an advantage against merchants if the merchant still processed the transaction the old-fashioned way.

The problem is all such gains are temporary. In equilibrium, after both issuers upgraded all of their customers to carrying chip & PIN cards and all merchants terminals process payments via EMV protocols, the exact same liability regime from today is restored.

This leads to a bizarre state of affairs. In game theoretical terms, either merchants or issuers can benefit in the short run by adopting EMV first, before the other actor does. (This assumes that savings from fraud exceeds the capital investments required for upgrading, whether that means the cost of buying new POS hardware or reissuing new cards to existing customers.) Such benefits need not correspond to an actual decrease in fraud as experience by consumers. After all chip & PIN cards still have magnetic stripes, so they can be cloned for fraudulent transactions at merchants still relying on swipe technology. The operative question for the merchant/issuer is not whether fraud exists but who is picking up the tab. From that perspective, preemptive EMV adoption pays-off, leaving the “other” side on the hook. But once both sides have upgraded, that advantages vanishes.

Put another way, the card networks have almost set up a text-book experiment in behavioral economics. Crash upgrade to chip & PIN pays off unilaterally for each player as long as the other one has not upgraded but such benefits disappear once the opponent also upgrades. What is the rational choice in this situation? Racing to upgrade is no doubt the outcome the card networks are hoping for. In the short-term, merchants could pass on the capital investment to consumers in the form of higher prices. (It would be particularly amusing, and a certain measure of poetic justice, if a special surcharge applied to chip & PIN card payments only. But card networks would likely crack down on such blatant attempts to single-out EMV mandate for higher prices.) Curiously there is another equilibrium point: status quo. Both sides can delaying upgrades, betting that no one else is deploying EMV, and consequently there is no additional liability incurred from the redistribution mandate. Another wild-card here is how international transactions are treated. Even if US banks move slowly on issuing EMV cards, merchants can still be exposed to a significant downside from transactions involving cards from other countries. Card fraud is very much a global business. To the extent chip & PIN frustrates certain types of fraud in Europe, it has also served to redirect the criminals’ attention to the US market where it is easier to  monetize stolen EMV cards using traditional magnetic stripes. Cracking down on that by shifting liability to US merchants alone could be enough to tip the scales. Time will tell.

CP


Follow

Get every new post delivered to your Inbox.

Join 34 other followers