NFC card-emulation and Android 4.4 (part III)

[continued from part II]

Opening the platform to third-parties

eSE nd UICC provide a high-level of security and physical tamper resistance. But the locked-down environment also presents a challenge for enabling a third-party ecosystem of developers. As previous posts explored, installing applications on the embedded secure element or UICC is not a free-for-all. Card “content management” in Global Platform terminology requires knowledge of the unique card manager keys for each particular unit. (This is a simplification; for more details see earlier post.) End users and application developers do not have direct possession of these keys. Instead they are wielded by a trusted third-party dubbed Trusted Services Manager or TSM who is called on to perform the privileged operations of installing, configuring and deleting applications. On paper Global Platform envisions many complex business models where an application provider can contract with TSM to install applets on its behalf. The latest iteration GP2.2 permits supplementary security domains to perform content management. TSM could inject an SSD for each third-party and delegate application management to individual providers.

Making such arrangements work in reality has been a different story. At least for Android, with the exception of proofs-of-concept and internal demos, embedded secure element has been used only for contactless payments with Google Wallet. Similarly UICC/SIM is being used only for enabling the same scenario with a competing product called the ISIS Wallet. If secure elements had been deployed in μSD form-factor, chances are they would not fare any better in supporting an ecosystem of third-party developers. While μSD is a removable component  decoupled from handset manufacturer and carrier, there is still some entity wielding the card manager keys.

Another level of indirection

Compared to the tricky machinations required for third-parties to get their application on Global Platform-compliant secure elements, HCE greatly lowers the bar for adoption. Installing a vanilla Android app is sufficient, accessible to many developers unlike the more stringent criteria of earning the good graces of a wireless carrier. There is no need to coordinate with TSM or get permission from the handset manufacturer. Developers simply declare NFC services implemented by their code. When the phone is interacting with an external NFC reader and receives traffic, the operating system picks the intended destination by using the same trick NFC controller uses to juggle applets spread across two secure elements: AID-based routing.

As far as the NFC controller is concerned, all “host card emulation” traffic is delivered to a single endpoint represented by the Android NFC stack. There is no notion of different wallet applications or other user-level distinctions made. It is up to Android to handle that multiplexing by selectively delivering APDUs to the intended application.

AID routing in Android

Android relies on application manifests to work out this association. Every application interested in acting as a card-emulation target declares the application ID (“AID”) for which it can respond to commands. Much like the NFC controller or card manager, Android looks at the payload of incoming SELECT commands and picks an application for routing based on the AID specified in the command. This is a stateful decision. It affects not just that initial SELECT command but all subsequent APDUs. Traffic is delivered to that application until another SELECT command arrives to switch context to a different applet.

Conflict resolution

This model faces a couple of additional complications at Android level: multiple applications can claim the same AID. This can not arise on an ordinary GP-compliant smart-card. Only one applet can be installed with a given AID and the card manager will error-out on attempting to install a duplicate. Since there is no such thing as a “global-platform card manager” on Android, the system does not detect/stop such collisions. Instead they are handled by the familiar Android pattern of ranking user preference. Nothing prevents the installation of multiple “web-browser” applications claiming to handle http:// URLs but Android will resolve the ambiguity by prompting users. AID conflicts are resolved by a similar system although the user-interface is not well-defined at this point, with the curious exception of payment applications which are given their own real-estate in system settings. All other applications make do with an API to check if they are the preferred application and another API to be prompted to that spot.

AID grouping

Closely related to the problem multiple applications registering for an AID, Android allows “bundling” multiple AIDs such that an application will handle all of them or none of them. This avoids getting into a mix-and-match situation where commands associated with one AID is routed to Android application A, while commands for another one are routed to B due to conflict resolution. Such a mix-up can prevent both A & B from working correctly in scenarios when multiple card applications are involved for a particular scenario.

EMV is a very relevant example of what can go wrong if different AIDs are split across multiple Android applications. During a transaction, the point-of-sale readers first selects the PPSE (Proximity Payment System Environment) application to enumerate the available cards. Then it selects an application corresponding to one of the listed cards to carry out the payment, such as MasterCard Paypass. Consider two mobile wallets installed on the same Android device, each managing its own set of payment instruments. If PPSE implementation from wallet A is used to choose preferred credit card, but then Android switches to wallet B when Paypass AID is selected, the POS will be working with an inconsistent transaction state. (In fact the second wallet may not even have a payment instrument available corresponding to that AID, in which case the transaction will fail.)

[continued]

CP

NFC card-emulation and Android 4.4 (part II)

[continued from part I]

Choosing between multiple routes

To complicate matters, an NFC controller can support multiple connections and switch between them. For example the PN544 was capable of supporting both the UICC and embedded-SE link. The currently active path is called the “card emulation route.” Until ISIS most Android devices hard-coded this to point to the embedded SE. In principle the setting can be toggled at any time; it is not baked into the controller firmware. But until recently Android NFC stack always issued the command to set the route to eSE during boot and did not provide a way to change that later. (Not that it mattered; on most devices there is no physical wire from UICC to NFC controller. Switching the route would have no effect. More recently the presence of that extra wiring is required for ISIS compatibility.) Conversely an early prototype ISIS device this blogger examined  hard-wired the connection to the UICC, guaranteeing that Google Wallet could not run on the device even if the user managed to work around carrier restrictions.

Supporting multiple routes

The preceding discussion makes a simplifying assumption: while multiple secure elements may exist on the phone and attach to the NFC controller, only one of them will ever be used at a time. For example if the user has a payment application residing on the embedded SE and an identity application on the UICC, exactly one of them is externally accessible to an NFC reader at any given time. At best the user has access to some switch in the mobile operating system to toggle between these two options ahead of time, before the tap event.

Luckily one need not rely on such advance planning from the user. Modern NFC controllers have additional smarts to allow multiple card-emulation targets to coexist at the same time. The trick involves implementing the equivalent of content-inspection on incoming ISO7816 commands. Earlier we mentioned that the controller functions as a router, merely shuttling NFC traffic from another nearby peer to its ultimate destination. In reality modern controllers are not passive conduits; they peek at the messages flowing through and make decisions based on the payload.

Deep-packet-inspection, NFC style

That functionality is useful even when there is a single secure element in the picture. Here is a basic user-experience problem for tap-and-pay: when the user taps their device against a point-of-sale terminal and starts a payment event, it is often necessary for an Android application to intervene. For example the user may need to be prompted to enter their PIN if the operation was declined. After the transaction goes through, the application may want to display a confirmation. Minor problem: in card-emulation mode the host does not have any visibility into traffic being sent to the secure element. Incoming requests are delivered directly to the SE, where the responses also originate without ever bubbling up to the host. The user-interface for our hypothetical wallet application would have no idea that the user just tried to make a purchase.

Getting a handle on SE events

Luckily system designers anticipated that problem and introduced some notifications, which are in turn incorporate to the Android NFC stack in the form of notifications delivered to associated applications. Specific triggers include:

The first two notifications may look promising, without requiring any traffic inspection. RF field presence is about registering the existence of a change in physical environment. If payments were the only application, that would have been sufficient signal to conclude that the user attempted a transaction. (Of course in retrospect that is exactly the only scenario Android eSE was used for on any large scale.) Imagine a more ambitious vision when the SE serves both payment and public-transit scenarios, each of with a corresponding Android user-mode application. Depending on whether the user tapped a cash register or turnstile in the subway, the system needs to wake up the correct app to present additional UI.

That calls for looking at the contents of incoming traffic. Per ISO7816 SELECT commands are used to activate applications. By looking at the application identifier or “AID” specified in that APDU we can determine what type of transaction an external reader attempted. That is effectively the third notification above: it contains the AID for the specific applet selected. (As an aside, on Android only privileged applications whitelisted for NFC-extras receive these intents.) This allows applications to bring up UI– for example PIN entry in the case of Google Wallet– only when they can be certain their own SE applets have been invoked, as opposed to just any random applet.

That was an example where the NFC controller is parsing the contents of a request APDU coming over NFC and bubbling-up a notification to the host. It is also one of the exceptions to a principle described in the first blog post: host does not have visibility into external NFC traffic addressed to the SE in card-emulation mode. (Incidentally Android source code has references to another notification called “APDU received” which promises to return the full contents of an incoming NFC request. It is not implemented, and in fact can not be implemented because most NFC controllers do not have such a capability.)

The next post will describe how this capability in the NFC controlled enables supporting multiple SE simultaneous, as well as allowing SE applications to coexist with host-card emulation.

[continued]

CP

NFC card-emulation and Android 4.4 (part I)

[Full disclosure: This blogger worked on Google Wallet 2011-2013.]

Android version 4.4 dubbed Kitkat has recently introduced a new (at least “new” for the official Android distribution) NFC feature called host-based card emulation or HCE for short. HCE is  the basis for a different approach to contactless payments, a pivot away from the original strategy based on the embedded secure element. The first signs of that shift arrived earlier this summer with a curious change in the Nexus 7 hardware specs. Previous Nexus devices starting with Nexus S all contained an embedded secure element, a critical feature leveraged by Google Wallet for NFC payments. While the tablet form-factor is arguably less convenient for tapping against a point-of-sale terminal– and Wallet even ran on the larger Nexus 10 tablet– the SE was also present in the original Nexus 7 in 2012. Fast forward one year, it was conspicuously absent from the update released in July. Similarly the flagship Nexus 5 launched without an embedded secure element, becoming the first pure Google-experience phone to shed the SE.

This is unfortunate for mobile device security in general; an embedded secure element has many applications beyond NFC payments. There is a fascinating lesson in market-dynamics here: how a consortium of US wireless carriers invested in a rival payment project called ISIS successfully thwarted the deployment of an important security technology. But that is a discussion for a different time. This post will focus on the mechanics of HCE and subtle interactions from trying to coexist with embedded SE or SIM-based applications on the same device.

Card-emulation options

In card-emulation mode an NFC controller simulates the behavior of an ISO-14443 smartcard. This allows mobile devices to substitute for standalone plastic cards and dongles used in traditional security applications such as EMV payments, US government PIV card, public-transit, physical access with badge-readers and logging into a personal computer. Grossly oversimplified, that involves tunneling ISO7816 commands over NFC  to some application sitting behind the controller. This is where the different hardware options come into play. An NFC controller is just a gateway; it is not a general-purpose computing environment where applications get installed. The actual “card application” lives on some other piece of hardware that is wired to the controller. For example:

  1. Embedded secure-element or eSE for short, typically part of the same hardware as NFC controller. This was the original approach taken with Android devices. For example Nexus S and Galaxy Nexus feature a PN65N chip from NXP Semiconductors, combining the PN544 controller coupled to a SmartMX secure execution environment.
  2. UICC or glorified SIM card with additional  features. Single Wire Protocol (SWP) is the standard for connecting connect UICC & NFC controllers. This is the approach taken by ISIS for its mobile payment application.
  3. Special micro-SD cards containing a secure element. No production Android device operates in this configuration, but µSD cards such as Tyfone SideTap have certain advantages. They are easily moved between devices and they are not tied to the mobile carrier or handset manufacturer.
  4. Host-based card emulation. Originally implemented by SimplyTapp as a patch on top of Cyanogenmod 9, and now independently implemented by Google for Android 4.4. Incoming NFC traffic from external reader is delivered to the host operating-system which generates the response.

Direct connection and security implications

One important detail about the first three options above stands in sharp contrast to host-based card emulation. In these modes data sent/received does not travel through the host operating system. In other words, it is not the case that eSE outputs data to Android which in turn forwards that packet over to NFC controller for transmission over the air. Links to/from  eSE/UICC/µSD are direct. Android never sees that traffic. This is an important security feature. Consider a payment application implemented on the eSE. Such an application communicates sensitive financial information to a point-of-sale terminal during payment transactions, including credit card numbers. If that data was routed through the host OS, malware running on the host could observe it. This property is enforced by the firmware of the NFC controller itself; it is independent of any Android-side behavior. Not even malware running with Android kernel privileges can change that.

Interestingly the converse property for incoming traffic does not hold. Before the user taps their phone against an NFC reader, host malware could have switched the NFC controller into HCE mode to gobble up data intended for the eSE. But even in this scenario a weaker guarantee holds: a given command is delivered either to the eSE or the host operating system, but not both.

Another subtlety: there is also a connection from the host the embedded secure element that allows host OS to speak ISO7816 and exchange APDUs with the SE directly. At first this appears to enable a man-in-the-middle attack executed by host applications: malware receives traffic from external reader in HCE mode, accesses the SE directly over the host-interface and forwards same command as if it were received directly over NFC radio. Incidentally this hypothetical example assumes malware has already breached Android security, and is executing with root privileges. Ordinary apps on non-rooted device are limited to the subset of operations exposed by the NFC stack. There is no permission defined to allow privileged operations such as switching controller state. Even under these generous assumptions, the attack fails for a different reason. Applications running on SE can determine whether any given command is received over the “wired” interface– connected to the host– or “contactless” interface attached to the NFC antenna. So-called interface detection logic is an integral aspect of many standards including EMV. It is critical for keeping the host operating system out of the threat model. (There is also the incidental fact that changing NFC controller mode on PN65N/O will reset the secure element, losing application state and further frustrating attempts to relay commands. But it is unwise to rely on such hardware idiosyncrasies.)

[continued]

CP

Privacy and HTTP Referer header (2/2)

First part of this post left off with the question of whether blocking Referer header with client-side tweaks is a useful feature. There is a long history of vilifying Referer header in the name of security. Some personal firewall suites implemented this pseudo-mitigation, as does one experimental web-browser, a Firefox add-on and one Chrome extension. In the standards realm, an Origin response header was proposed to convey a subset of the same information, leaving out file and query-string parts of the URL. HTML5 working group also jumped into the fray with a new noreferer attribute to allow website authors to designate when Referer is suppressed.

Getting by without Referer

Paradoxically as referrer information became more valuable to advertising-based business models, the Referer header itself became less critical. It turns out same information can be conveyed in alternative ways provided the originating website cooperates. For example the identity of the website containing the link can be appended to the URL as query-string parameter. This parameter could be the verbatim representation of Referer or some shortened representation both sides agree on. In the case of a banner ad, the advertising network is crafting the final URL that users will be taken to after clicking on the link. Depending on arrangement, the advertiser paying for this service can receive additional information about the user– including current page where they encountered the display ad– incorporated into the query-string at the end of that URL.

Standard header vs home-brew alternatives

Referer header provides this functionality for free, without either site having to do any extra work to stuff more information into query strings. There are certain advantages to relying on that built-in functionality. For example if affiliate websites are getting paid based on amount traffic they drove to the destination, there is an incentive to fraudulently inflate those figures. Tweaking the query-string to create the impression that a particular visit originated from any desired origin is trivial. Referer by contrast is chosen by the visitor’s  web browser and can not be influenced by the originating page. (Note this assumes the affiliate is counting on real users to inflate the statistics, who are running unmodified “honest” web browsers getting bounced off to the real target. Of course the affiliate could maintain its own bot army of modified web-browsers that forge requests with bogus Referer headers. But such artificial streams are easier to detect due to lack of IP diversity, among other anomalies.)

Omitted by design

Referer header is also omitted in certain situations, such as going from an HTTPS page using encryption to plain HTTP page in the clear. This is an intentional security measure, to protect personal information from a secure connection leaking out on a subsequent request in the clear. Similarly Referer is not modified during redirection chains, which can have surprising effects: if page A redirects to page B using an HTTP response status code 302 and page B in turn directs to C, the final Referer observed by C will be A instead of B. In these situations it is critical to use a different mechanism for conveying information about the path a particular user traveled. (Incidentally this is also why cross-site request forgery can not rely solely on checking the Referer header. The header does serve as a reliable indicator of whether a request originated externally when present— modulo client-side bugs that allow forging the header as in this Flash example. But there are legitimate cases when the header is missing by design. Rejecting these would be a false negative.)

Partial solutions

Combining the previous two observations, Referer header is neither necessary nor sufficient for contemporary web tracking scenarios. Returning to the question of whether vilifying the Referer and stripping it out is doing any good: there is a marginal benefit for stopping accidental leaks. These are security vulnerabilities where sensitive information intended only for one website is unintentionally divulged to a third-party by sourcing embedded content or clicking on links. Diligently suppressing the header from every request will defend against these oversights. But it does nothing to prevent deliberate information sharing, when the websites in question are colluding to track users. That happens to be exactly the arrangement between a publisher offering advertising space on its pages and the advertising network providing the content for that slot. Since there is an incentive to provide necessary information to the advertiser, the publisher can do that by using the link, avoiding any dependence on the unreliable Referer header.

HTTP cookies and equivalent functionality which can be used to emulate cookies– DOM storage, Flash cookies etc.– are far more critical for tracking. This is why the advertising industry panics whenever a major browser considers mucking with cookie settings in the name of privacy. Referer header on the other hand is largely historic, incidental behavior in web browsers which has been superseded by improved proprietary designs to achieve the same purpose.

CP

Privacy and HTTP Referer header (1/2)

HTTP Referer [sic] header has become something of a favorite villain in web privacy controversies. Misspelled with a single “r” due to historical reasons, the evolution of this header is an interesting example of how features can have unintended side-effects. Introduced in  HTTP/1.0, the first version standardized by IETF, it was intended as a diagnostics mechanism:

This allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance.

When a user clicks on a link from one site to visit another, her web browser transmits a hint to the effect that “I followed a link from this other page to arrive here.” In the early vision of the web as a small, friendly place populated by academic researchers, one could imagine a web administrator reaching out to another to thank them for bringing new users to their site. Or they could politely inform their counterpart that a page they linked to has been moved or deleted, to suggest that the outdated link be corrected. (As an aside this is also the solution to an imagined problem that troubles Jaron Lanier in Who owns the future? In his critique of the web as a platform for enabling exploitation of content creators, the author cites the unidirectional nature of hyperlinks as root cause of an imbalance of power. Google profits by sending users to other websites where the real content of interest is located, but the authors who painstakingly created that content in the first place do not share in the economic gains. Lanier incorrectly assumed this is because sites can not identify the “source” to be credited for bringing users. But this is exactly what the Referer header does. Incidentally Tim-Berners Lee originally envisioned hyperlinks as bidirectional, and Referer can be viewed as a way to approximate that approach.)

The web today is not exactly the collegiate, friendly community from 1993. Trying to fix every broken incoming link by tracking down the authors would be a lost cause. Yet there are still benefits to knowing where traffic has originated from. Contemporary business models for websites depend heavily on monetizing traffic indirectly, for example by advertising or mining user-data. Scaling that effort in turn involves running various campaigns to generate traffic and bring in more “eyeballs” in industry parlance. Knowing where that traffic originated can help the website better optimize its customer acquisition plans. For example they can distinguish between users clicking on simple text ads on Google, verses rich banner ads or social media mentions. The same argument applies for embedded content. When one page includes an image, video or other web content provided by another page, the latter gets to learn about the identity of that first-party using its content.

Intentional leakage

As is often the case in policy issues, one person’s brilliant marketing idea is another’s privacy nightmare. What made the Referer seem like a good idea in 1993 is exactly the same reason it poses a privacy problem: it allows sites to learn users’ navigation patterns. To be clear, this header alone is not enough for tracking. It takes cookies and reuse of the same third-party content from multiple sites that allows building up such a profile. Much to the dismay of privacy advocates, that scenario arises quite frequently in the context of advertising networks. For example DoubleClick— acquired by Google in 2008– provides banner ads for tens of thousands of websites. These ads are included by the publisher— the original website the user visited– embedding third-party content on their pages hosted by DoubleClick servers. When a web browser is rendering that publisher page, requests are made to DoubleClick with Referer header bearing the address of the publisher. (As we will see in the second half of this post, this is not the only way for DoubleClick to find out the originating party.) DoubleClick maintains a long-lived third-party cookie for identifying visitors across different sessions. Each time a new Referer is encountered for an ad impression associated with that particular cookie, the advertiser can make a note of the website the user happened to be visiting. Multiply this by thousands of websites embedding banner ads, you get a comprehensive picture of one user’s web surfing behavior, indexed by the unique identifier in that cookie.

Accidental leakage

There is a different type of information disclosure that the referer header can introduce, which is not intended by the origin or destination websites. This happens when secret information used for  access-control are encoded in the query-string portion of the URL. For example it could be an authentication token, password-reset code or other secret used for access control. Consider what happens when such a page embeds content from a third-party website such as an image. When fetching that resource, browser sends a Referer header containing the complete URL (minus fragment identifier) of the current page. Because that includes sensitive data carried in the query-string, the third-party website is now able to impersonate the user or otherwise access private user information stored at the originating site. This type of vulnerability is called a referrer leak. Same outcome happens with a delay if the user were to click on a link from that page to navigate to an external site. There are a couple ways to mitigate this risk. Using a POST instead of GET will keep sensitive form parameters in the content of the form, instead of as part of the URL. Another option is to diligently perform another redirect back to the current page, minus any sensitive query-string parameters. This only works if these parameters can be stashed someplace else such as in a cookie, since they are typically an integral part of the flow.

But given broader privacy concerns with Referer, does it make sense to deprecate this header altogether? In the second part of this post, we will look at some attempts at doing that and argue they are fundamentally incapable of addressing the privacy problem.

[continued]

CP

NFC payments on personal machines: PCI versus innovation (part III)

[continued from part II]

Previous post in this series left off with a discussion of card-present versus card-not-present transaction models for accepting contactless payments directly from end-user machines. That becomes a segue into the broader problem of how exactly the payment network (in other words MasterCard, Visa, American Express) would treat such transactions. Assuming payment processors and websites are willing to make necessary changes to enable this scenario end-to-end– itself an uncertain prospect– should such transactions be treated the same as other Internet purchases? There are at least three scenarios.

1. Optimistic

View these as card-present transactions. Earlier we pointed out the backwards compatibility of some EMV payment protocols. Specifically they produce an emulated “track data” complete with CVC3 (dynamic CVC) that is compatible with the format obtained by swiping a plain magnetic-stripe card. Naively that would suggest one could implement contactless payments  by forwarding this track 1 & 2 data to the payment processor and run it as ordinary card-present transaction conducted at point-of-sale terminal.

But the distinction between card-present and card-not-present goes beyond protocol minutia. It has fundamental implications for the economics of the transaction: CNP typically incurs higher interchange fees, faces greater fraud risks (consequently subject to different thresholds from fraud-detection systems operated by the issuer) and places burden of proof on the merchant in case of consumers disputing a transaction. In this case the card-holder is not physically “present” on any merchant premises. They may well be carrying out the transaction from anywhere around the world on their NFC-equipped laptop. Conferring CP status just because the protocol happens to be compatible seems unwarranted.

2. Status quo

A more cautious approach is to continue treating these transactions as standard CNP, leaving intact the existing distribution of risk skewed towards the merchant. This allows for a more cautious transition on a schedule decided by merchants. Since the economics and liability are identical to credit card numbers typed into an old-fashioned HTML form, it is up to each merchant to determine if there is an advantage to accepting NFC.

Strictly speaking EMV protocols– even the backwards compatible variants– are safer than the status quo for Internet transactions. Instead of typing in the same fixed payment information for each transaction (credit card number, expiration date and CVC2) a unique CVC3 value and sequence-counter are returned from the card. Even if one of these falls into the wrong hands due to a breach of merchant website or malware running on the machine used by the customer, it is not possible for miscreants to reuse the same values to perform another purchase. More importantly that CVC3 is computed as a function of a challenge from the “point-of-sale” terminal. By choosing the challenge the website (or payment processor, depending on design) can achieve higher degree of assurance that the response is indeed generated in real-time by the card, instead of being replayed from a past transaction.

Still there is a cost to accepting NFC payments, especially initially when few customers will be in a position to take advantage of them. Not only do they need laptops or phones equipped with NFC readers, they need to have credit cards with contactless payment capability– something that is entirely under control of the issuer. It is unclear if reduction in risk would justify the extra cost for such niche functionality. (On the other hand offering card-present treatment does create a far more compelling value proposition for merchants, especially online where profit margins are very tight. Even small reductions in interchange fee can translate into significant savings.)

3. Pessimistic

Under the most strict interpretation, payment networks could outright forbid such transactions, declaring that contactless payments are only intended to be carried out at a retail location against “approved” point-of-sale hardware that has been certified by the network. This is where PCI requirements come in. PCI council has published a series of guidelines and recommendations on when mobile devices can serve as point-of-sale terminals. If the end-user hardware is interpreted as “point-of-sale terminal” then a specific PCI mandates apply, as well as individual recommendations from different payment networks. For example MasterCard best-practices require that PIN entry take place on approved external PIN-entry devices only, specifically ruling out commodity mobile devices.

There is a good argument that end-user devices should not be subject to POS criteria. This is not a case where the merchant is buying dedicated equipment for processing transactions. POS rules exist because such equipment concentrates and re-distributes risk. Cash-registers are produced by a manufacturer, installed at a merchant location and then used by thousands of individual customers who stand to lose from a security breach. By contrast the security of an end-user machine user for online purchases affects a small number of people using that particular machine.

It will come down to interpretation and partially, enforcement. Strictly speaking the original incarnation of Square would have been disallowed by these rules. The plastic dongles the company is known for used to pass track-data   read from the card straight to an application running on iPhone or iPad, without any encryption. This design was obvious susceptible to malware running on the host machine. Later incarnations adopted encryption, reducing dependence on host security while still running on off-the-shelf iOS devices. But even before that particular improvement, it was arguably too late to cry foul over alleged PCI infractions– and in this case there is no question that the device qualifies as dedicated POS system. Square created a new market by capturing the long-tail of small merchants who had never accepted credit cards before. This new segment generated significant interchange revenues for payment networks. As long as observed fraud remained manageable, it would have been quite unwise for networks to shutter the system by nitpicking over PCI requirements intended to mitigate hypothetical future attacks.

CP

Intro to trouble: LinkedIn and trusting the cloud (part II)

[continued from part I]

Expanding attack surface

In terms of risk, Intro amounts to expanding the attack surface, the universe of ways a system can be targeted by adversaries. It’s not that email was absolutely safe before Intro and somehow became intolerably dangerous afterwards. Instead users incur additional risks– their messages can be compromised in transit to or during processing at LinkedIn datacenters.

LinkedIn response outlines mitigations in place to manage that risk. But discussing defenses is getting ahead of ourselves. The critical question is not whether Intro design is taking necessary steps at the technology level to manage the delta. Before going down the path of evaluating countermeasures, there is a more basic question: does the value proposition make sense? Is the service provided by LinkedIn valuable enough to justify the risk? That question can not be answered in isolation without looking at both benefits and risks side of the equation. Much like deciding whether an investment is appropriate, we need to compare its expected returns to the incremental addition of attack surface.

Weighing risks and benefits

In this case the expected reward from installing Intro is that email messages are  annotated with profile information about the sender, drawn from their LinkedIn profile. The potential risks are also clear: email flowing through LinkedIn systems is susceptible to attacks both in transit to/from LinkedIn as well during the brief time it is being processed by LinkedIn systems. (This is a best-case generous interpretation; we taking the designers at their word that messages are not stored. That statement can not be verified without access to LinkedIn operational environment.) What could possibly go wrong? Here is a sampling of potential risks:

  • State-sponsored attackers can break into LinkedIn systems to capture email as it is routed through this system.
  • Interception of messages in transit by breaking SSL, via using fraudulent digital certificates from incompetent/dishonest CA on behalf of LinkedIn.
  • LinkedIn insiders can modify the system to divert certain messages
  • Law-enforcement and surveillance requests can compel LinkedIn to start storing messages, against the stated design intent.

Again these are all incremental risks. It’s not that SSL was absolutely safe when used only for connecting to the original email provider or that provider was somehow immune from getting 0wned by China. The point is that all of those risks are increased by having one more participant attackers can target. How much depends on the relative security of LinkedIn compared to the email provider already entrusted by the user with access to their messages. If a Gmail user started routing their traffic via Intro, chances are the risks have drastically increased: given its past experience of responding to APT attacks and investments in SSL such as certificate pinning, Google is likely a much harder target than LinkedIn.

Reasonable people may disagree

Is it worth it? The answer may well vary between individuals or in managed IT environments, between different enterprise philosophies. At least for this blogger, there is no conceivable universe where scribbling profile information in email messages– information that can be obtained in other ways, if a little less conveniently by visiting the LinkedIn website to run a manual search– is worth the risk of exposing raw email messages to a third-party. Simply put LinkedIn is not an appropriate “trusted third-party” for access to user email. This is not a reflection on LinkedIn or the quality of its internal security practices. The same concept implemented by Facebook or Twitter would be equally inappropriate and dubious in value proposition.

Also worth pointing out: this is not an automatic rejection of relying on cloud services or affording special treatment to email. Enterprises often contract with third-party for security services to screen all incoming email for that company.  This is accomplished by routing the messages to servers run by that third-party to be scanned for malware and spam. A decade ago commentators were asking  whether it is appropriate to outsource such services. Two key differences from Intro make it easier to answer  that question:

  • Clear security benefits to counter-balance risks. Blocking malware and phishing attacks arriving via email is a security feature. On the one hand, routing messages to third-party systems increases attack surface in ways similar to Intro. On the other hand, the enterprise expects reduced malware prevalence and corresponding improvement in host security.
  • Alternatives are significantly more costly or less effective. While email screening can be done on-premises as installed software, such designs face the problem of keeping up-to-date with new attack mitigations. By contrast outsourced systems benefit from having visibility into attacks across multiple customers and can respond to new threats faster by aggregating this information.

This is why it is not completely gratuitous for an outsourced security provider to have access to email traffic.  Screening email is the raison d’etre for these services; they could not provide any value otherwise. There is no similar urgency or necessity for a social network such as LinkedIn to access user email. As the existence of Facebook and any number of other successful specialized social networking sites demonstrates, access to user emails is not in anyway a prerequisite to operating a viable business in that space.

CP

Intro to trouble: LinkedIn and trusting the cloud (part I)

It has been a tough start for LinkedIn’s Intro feature, designed to add contact information from the social networking site to email messages. The project was announced on the company engineering blog with much fanfare, chronicling the challenges faced in implementing the concept on iOS. Whatever the technical complexity and virtuosity involved in pulling this together, the main reaction was one of skepticism and outright hostility from the security research community. In particular Bishop Fox eviscerated the concept in a detailed point-by-point critique and LinkedIn responded with another blog addressing technicalities while dancing around the fundamental question of trust.

Non-issues

Before discussing the problem with Intro, let’s dispense with one non-reason that appears to be dredged up in every article covering the feature. LinkedIn suffered a massive password breach in 2012, netting the company a Pwnie award nomination for Most Epic Fail. Incidents or lack thereof is not a good metric for evaluating the security of a service. While a data breach usually implies the existence of weaknesses and defects in the defenses, whether or not someone gets around to exploiting an existing weakness is influenced as much by sheer luck. Granted there were disturbing signs in this episode indicating that suboptimal design played a significant role in amplifying the damage: the way LinkedIn stored passwords violated industry best practices. There was no salt applied to diversify passwords before hashing. Just 1 iteration of the hash function was used instead of iterating thousands of times to slow down guessing.

That was not an isolated instance when it comes to questionable decisions on the security front. As noted earlier the service continues to use the password anti-pattern, phishing users for their passwords on other sites instead of adopting the industry standard Oauth protocol for constrained access to user data at those sites.

Still, there is a statute of limitations for incidents. It is not rational risk-management to reject every new offering from a company on the basis of one incident or for that matter, failure to follow optimal security design in one feature to color judgments about every other one. This post will give LinkedIn a free pass for such transgressions and evaluate Intro on its own terms.

Fundamental problem with Intro

Key observation about Intro is that the functionality is not implemented locally. In order for this email rewriting to take place, the message is sent out to LinkedIn servers, modified there in the cloud and then returned to the user. This means that LinkedIn servers get access to every single message sent to that particular email account. The difference is best explained by contrasting it with two other common systems that operate on email messages.

Gmail keyword advertising

Since 2004, GMail has been controversial for offering targeted advertising based on keywords in email. Strictly speaking GMail does not tamper with messages unlike LInkedIn Intro. Sponsored advertising appears off to the side, in a clearly demarcated area. Still the experience of the user– something Microsoft repeatedly capitalized on in the Scroogled series of TV commercials– is that their messages are being “read.” Why is Gmail keyword scanning not a security risk? (Even though it may well be construed a significant privacy infringement.) Because Google servers already have access to the email message. There is no new user data being made available to Google in order for their servers to decide which advertisements will be displayed alongside the message. This stands in sharp contrast with LinkedIn situation: before using Intro, LinkedIn did not have access to emails sent/received. It is the act of installing Intro that causes otherwise private messages to start flowing through LinkedIn servers.

PGP and S/MIME

Another example of software which does in fact modify email messages are PGP and S/MIME extensions for email. Both are standards for adding encryption and digital signatures to messages. Sometimes the functionality is built into an email client: MSFT Outlook has S/MIME. In other cases it is a third-party extension that integrates with an existing email application. For example GPGtools hooks into the standard Apple mail client on OS X.

So what is the difference between installing Intro on iOS versus installing a GPG client for OS X integrates with the built-in mail application? GPG clients operate locally. No data is ever shipped to a third-party in the cloud. (Incidentally the reason LinkedIn implemented Intro as a remote service is that iOS mail application lacks the necessary extensibility mechanism for other local applications to hook into the email processing pipeline.)

Local vs cloud

Having a local application does not completely eliminate the trust question. Users still have to trust the author of the software. After all that code could secretly leak a copy of every message to a server in China or rootkit the machine. But such properties can be verified locally. A complete copy of the implementation is available for direct observation. It can be debugged, audited, reverse-engineered if necessary– many versions are open-source so they can be audited directly. It can be tweaked to run with reduced privileges in a sandboxed environment. More importantly for the purpose of future-proofing trust decision, there are strong assurances in place that these properties will not change magically. Users retain visibility and control over changes to the application going forward. If the software publisher decides to go rogue or is compelled by law enforcement to start installing spyware on user machines, they will be going through a public process of pushing out malicious updates. This is conceivable but much harder to hide compared to making equivalent changes behind closed doors inside a datacenter.

Leaps of faith

By definition, critical parts of the Intro implementation belong in the cloud inside LinkedIn data centers. Regardless of how much LinkedIn swears up and down that this environment has necessary safeguard (the blog cites an iSEC audit but it is telling that iSEC Partners itself has not come forward to defend the design) that aspect remains a blackbox for anyone who is not directly affiliated with the company. A significant leap of faith is required to accept that all is well inside that blackbox not just in the present moment, but indefinitely into the future.

Granted such leaps of faith are made all the time when adopting cloud computing. Gmail users have made a decision (perhaps implicitly and without spelling out the full consequences) that it is acceptable level of risk for Google to have access to their written communications. Ascertaining whether the same risk can be justified for Intro calls for stepping back to examine the broader question of how trust decisions are made.

[continued]

CP

NFC payments on personal machines: PCI versus innovation (part II)

[continued from part I]

In this follow-up we look at the missing pieces for enabling ecommerce with tap-and-pay  from end-user devices.

Integration with web-browsers

The first problem is that neither the NFC reader hardware or higher-level APIs leveraging that (such as PC/SC for smart cards) are directly exposed to web sites. This is good for security– it is dangerous to give websites access to smart cards that happen to be attached to the system, considering those cards may contain valuable credentials. “Directly exposed” in this case refers to being accessible from the standard web platform of HTML5 and JavaScript. It is certainly possible to execute arbitrary code and go direct to operating system APIs via various extension mechanisms such as ActiveX and NPAPI. But these are not portable, strongly discouraged for security reasons, not to mention impractical for each website to rewrite from scratch.

Not to worry: from their humble beginnings, web browsers have been getting increasingly bloated with random APIs over time. W3C recently standardized a basic cryptography API. (There is even a proposal for  secure element API in the same vein being promoted by Gemalto. But that proposal operates at too low a level, exposing raw APDU communications to cards instead of encapsulating a payment transaction.) It is not too much of a stretch to imagine some payments API can be introduced either by industry consensus or by one of the players such as Google or MSFT deciding to field their proprietary design. Such an API could abstract away the logistics of stepping through the payment protocol and communicating with the card. It would function identically for contact-based chip & PIN as well as contactless cards with NFC readers. Implementation of the API would also handle critical user-interface elements such as collecting PIN from the user, which can not be entrusted to websites.

Integration with payment processors

After the protocol is executed, the online merchant ends up with some “proof” of authorization generated by the card and conveyed by the web browser. The contents of this proof  are partially dependent on inputs chosen by the website itself. For example in certain EMV protocols, the amount being charged is itself an input authenticated by the card. The next challenge is for the website to use that proof and somehow get paid.

This is an interoperability concern. Typically websites are working with a payment processor which expects to receive specific inputs to pass upstream: credit card number, expiration date, cardholder name and optionally CVC2. Depending on the exact protocol variant used, a contactless transaction will not produce all of these. For example the card-holder name is redacted from the emulated “magnetic stripe” for Paypass transactions. That problem is  easily solved by asking the user– chances are the merchant is interested in customer name for other reasons already. But others are more difficult to work around. Contactless payments use a dynamic CVC, also known as CVC3. (By the way: that applies only for the simplest case of EMV protocols run in backwards compatible-mode with swipe-transactions. This is the “mag-stripe profile” intentionally designed to produce output that looks like track data coming from a plain plastic card. Pure EMV has far more elaborate schemes for authorizing transactions with nothing resembling a CVC in sight.) That value is not static; it is computed as a function of challenge from the reader and incrementing sequence counter maintained by the card. On the surface CVC3 has the same format as CVC2: typically three digits, although this is a configurable parameter. However they are not interchangeable; CVC3 values can not be used to make a card-not-present transaction.

At this point one can fallback to the strategy of simply asking the user for other fields.  The problem is that defeats the point of using a contactless payment protocol such as NFC: having a stronger assurance that the card is indeed present, and resisting some class of attacks that involve copying cardholder data. Receiving a fresh CVC3 response based on a challenge chosen by the website provides guarantees that are not present in using a static CVC2, which could have been captured from the user in a different context. Put another way, retrieving only the card number and other static data from the card is only “tap-and-pay” in spirit; it amounts to using NFC as glorified numeric keypad, without leveraging the higher security level possible for contactless payments.

Better solution is to allow the upstream payment processor to accept output format generated by EMV protocols. Luckily the mag-stripe profiles provide an easy transition path for this, since they were designed for backwards compatibility with “legacy” swipe-transactions using CVC1. While POS transactions are card-present (as opposed to card-not-present mode used in online purchases) processors typically have capability for processing these if they are also facilitating in-store transactions. In other words, one approach to interop is treating tap-and-pay transaction from end-user as a card-present transaction conducted at POS terminal, returning track data with CVC3. This emulated track-data will be relayed to the merchant and passed through to the payment processor, who in turn forwards it to the network.

[continued]

CP

NFC payments on personal machines: PCI versus innovation (part I)

Nearly six-months ago Engadget reported that NFC payments may be coming to Lenovo laptops equipped with built-in NFC readers. Digging deeper, the headline proves somewhat misleading– Lenovo only announced that these models have an integrated NFC reader. The author appears to have optimistically jumped to the conclusion that they could be used to enable payments. (HP already beat them to the punch with the Spectre Envy over a year ago but the story neglects to mention that.) Humoring this line of speculation, it is a fair question what exactly stops users from completing an ecommerce transaction by tapping their contactless credit card to their laptop. This is an interesting case where technology is running well ahead of self-imposed certification rules.

Accepting payments vs. making payments

First one clarification: the Engadget story refers to using off-the-shelf devices as payment terminals (point-of-sale or POS in industry parlance.) This is not to be confused– which the article does– with using the device as a payment card, as in the case of making in-store payments with Google Wallet running on an Android device.

At a superficial level, both scenarios use the same technology and follow the same EMV suite of payment protocols. But the roles are reversed. In the first case the device is in card-emulation mode, behaving like an ISO-14443 compatible smart card. It is acting as the source of payment instruments. By contrast when a device is accepting payments, it operates in reader-mode and behaves like a point-of-sale terminal. The device communicates with the card over NFC to drive the transaction, ultimately obtaining necessary information to authorize a charge against the card over some payment network. (Somewhat confusingly both can be combined: tap Android phone running Google Wallet against NFC-enabled laptop. Earlier we described a proof-of-concept along those lines but it was used for authentication rather than payments.)

The scenario Lenova is supposedly piloting would fall into the second case: visit an ecommerce site and during checkout tap NFC-enabled credit card to pay.

Easy enough

Playing the role of an NFC-enabled credit card requires having cryptographic keys associated with that card. The information is not printed or encoded on the plastic card itself. It is not possible to collect this from the user and somehow convert an ordinary magnetic-stripe card into one that can successfully interoperate with compliant POS terminals. It is up to the issuer to decide what type of hardware they are willing to entrust with these keys. Due to the high security concerns around safety of payment information, that usually means special tamper-resistant hardware. In the case of mobile devices, this is  either an embedded secure element that is part of the phone hardware (used by Google Wallet) or hardened SIM cards with additional capabilities, as Google’s ill-fated competitor ISIS plans to leverage.

By contrast the reader side is not authenticated at all. Anyone can write reader software that will walk any EMV-compliant card through the transaction protocol. There is no “permission” required at the technology level for this. Of course there is a very stringent certification process for anyone one planning to manufacture and sell credit card readers for use in commercial settings. But such criteria  exist above the application protocol layer. The wire protocol has no provisions for recognizing when a particular reader is “EMV-approved” and declining to proceed with payment. From a strict compatibility perspective, there is no reason why any laptop, tablet or smartphone equipped with an NFC reader could not function as point-of-sale terminal for accepting payments.

Proof-of-concept, no assembly required

MasterCard provides a Paypass emulator— Paypass being the MasterCard variant of EMV contactless payment protocols. This emulator runs on a Windows, executing a “payment” complete with a trace of messages exchanged with the card. Running the emulator typically requires an external smart-card reader attached to the system, compatible with the PC/SC standard used by Windows for reader hardware. But as we pointed out, many laptops are already shipping with integrated NFC readers. Given appropriate PC/SC device drivers, these can function as smart card readers. In fact we demonstrated this earlier by using an NXP provided PC/SC driver for the PN533 in HP Envy laptops for a proof-of-concept.

The only part of this simulation requiring quotes around “payment” is that no money changes hands. The emulator is not connected to any payment processor or issuer that will act on the information obtained by the card. But the card itself has no idea whether funds were actually moved. All of the bits exchanged over NFC are identical in both cases.

(Caution: the Paypass protocol includes an “application transaction counter” or ATC. Each completed tap– even when the reader is not connected to an actual cash register and no money is exchanging hands– will increment the ATC. If the ATC on the phone gets too far ahead of the ATC stored by the card issuer, future payments may be declined. Luckily in the case of Google Wallet, performing a full wallet-reset from Settings menu will provision a brand-new card with ATC reset to zero.)

Missing pieces

The proof-of-concept covers the first hop– from the card to the NFC-equipped laptop. But that is not quite the full picture, since transaction data must eventually make its way to the remote website or service and from there into the payment rails associated with a network such as MasterCard or Visa. So what are the missing pieces?

  • Browser integration
  • Differences in payment authorization between what websites use today and data generated by an NFC transaction
  • Compliance with payment network regulations

[continued]

CP