Month: July 2014

Dual-interface smart-cards and problem of user intent (part II)

[continued from part I]

Simulating a gesture

To demonstrate how multiple interfaces, specifically contact and NFC, on one smart card can help provide greater certainty about user intent against malicious hosts, let’s start with a simple example: emulating the presence of an external physical “button” on the card that the user must press before an action can be completed. The goal is to come up with some gesture the card-holder must perform, such that it is not possible for malware on local PC to emulate it via software alone. Key property is that an application running on the smart-card must be able to ascertain independently whether the gesture was performed, without relying in any way on the host PC since the latter can be malicious. This check will gate sensitive operations such as digitally signing a message or authenticating the user to a remote website.

Strawman

Asking user to insert the card is not sufficient, since any number of unauthorized actions can follow after that. At first a more promising approach is to require that the user remove and replace the card. A card application can detect this indirectly: removal cuts off power to the card, resulting in a hard-reset and loss off data stored in transient memory. Unfortunately this does not work because it can be simulated by malware on PC, which can reset the card or even shut-off USB power to the reader hardware, while the card is sitting still. That situation looks indistinguishable from the physical remove/return sequence as far the on-card application is concerned.

Switching interfaces

With a dual-interface card and dual-interface reader (or less elegantly two distinct readers, one for contact and one for NFC) we can ask the user to perform a slightly different ritual: start with the card in contact slot and switch to NFC, or vice-verse. Card application can detect which interface it has been activated from, make a note of this and wait until it is called again from the complementary interface before proceeding with the requested operation. Because activation areas on the reader are different, no amount of software trickery from the malicious host can magically move the card into a different physical spot required to access it using a different interface.**

Establishing intent

This is certainly a great deal of user annoyance for relatively little gain. It also suffers from the same problem as pressing a button built into the card: the user can not be sure exactly what operation resulted from the gesture, only that something was done. The good news is the sequence can be augmented to inspect exactly what was requested from the card, by enlisting the help of another device equipped with its own reader. Here is a scenario combining traditional PC with an NFC-capable mobile device used to double-check the operation:

  1. PC application streams a message to the card over contact interface and asks the card-application to sign it. (We assume that signature requests and responses are only exchanged over this interface and never over NFC, as enforced by the on-card application.)
  2. Card application caches the message in non-volatile memory, but returns an error indicating that user confirmation is required
  3. Host PC conveys this error message to the user.
  4. User takes the card out of the reader, and taps it against the NFC reader built into her Android phone
  5. Some Android application communicates with the card over NFC to retrieve the cached message, parse and format it for inspection by the user
  6. User reviews the message to confirm that it does indeed correspond to the intended operation. If everything looks correct, she informs the mobile app to authorize the action.
  7. That confirmation is relayed to the card application over NFC, which notes this
  8. User inserts the card back into the contact slot
  9. PC application requests signature again
  10. This time the operation succeeds, because of user confirmation received in step #7

Neither the PC or mobile device acting in isolation can sign an unauthorized message the user did not intend to sign. PC can submit any message but no signature is produced until it is independently confirmed. Meanwhile the mobile device can only confirm operations, but it can not originate new requests or even receive responses. This system can still be subverted if both the PC driving the signature operation and the mobile device used for confirming it are compromised by the same adversary. In that case an attacker can present one message to the card while displaying another one to the user for confirmation. But that is a decidedly higher bar than compromising either side in isolation.

Dual-interface requirement is critical here: asking for confirmation from another PC over same interface would not work for the same reason that card removal is not a reliable signal. There is no way for the on-card application to detect that it has been moved to another device, as opposed to simply power-cycled while sitting in the same reader.

Example: NFC payments with mobile secure element

The flow described in the previous section is already implemented in a familiar context: NFC payments from a mobile device with a secure element.

This video features the Visa NFC payments demonstration for 2012 London Olympics. Specifically around the 1:50 mark, there is a transaction with an explicit confirmation step. The phone is tapped against an NFC reader which communicates with the payWave application on the secure element to complete a purchase. Unlike the preceding transaction in the video, this time the protocol does not run to completion. Instead transaction details are displayed on the phone UI for confirmation. Once the user is satisfied that this is indeed the purchase they intended to make, a second tap against the reader completes the transaction.

To see how this is exploiting dual-interface capability to verify user intent, recall earlier posts describing how secure-elements in current generation of Android phones are effectively dual-interface cards, with the “contact” interface permanently wired to the host operating system and NFC side only accessible to external readers via built-in antenna. In this case the “PC” is replaced by a point-of-sale terminal asking the user to authorize a transaction. The “message” to sign is typically a step in the EMV payment protocol, although the card response is not exactly a signature in the cryptographic sense. The roles of contact/contactless interface are inverted: primary transaction flows over NFC, while out-of-band confirmation is obtained from the user over the contact interface hooked up to the mobile device. Because the secure element can not be taken out and moved independently, the act of bringing the phone into/away-from point-of-sale serves as the equivalent of moving between readers. (We are deliberately glancing over some implementation questions that depend on hardware configuration. For example, if the SE can be used simultaneously on both interfaces, some type of polling mechanism is required to determine when transaction is confirmed. Alternative is that only a single interface can be active, in which case the host controls whether SE is attached to NFC or contact-interface. It also means the user must pull their phone out of the NFC field for confirmation and bring it back, giving rise to a “double-tap” experience. This is how the Android eSE was configured for Google Wallet in its original design.)

CP

** Note there is one subtlety here related to the physical construction of dual-interface readers: we assume the hardware is properly shielded to isolate the contact-slot from NFC field, or include hard-coded logic to suppress NFC when contact is detected to prevent double-activation. Otherwise it is possible for a card sitting in the contact slot to be simultaneously accessed over NFC. The opposite case however goes against physics: when the brass contact-plate is not touching corresponding metal points in the reader, that interface can not be activated. Similar concerns apply when the card is being moved into position because it may be passing through the NFC field temporarily.

Dual-interface smart-cards and problem of user intent (part I)

Comparing the security of NFC applications implemented with host-card emulation (HCE) against those using an embedded secure element, we noted that SE hardware architecture allows for interface detection, a critical mitigation against remote relay attacks.  This post expands on another application of the same feature: recognizing user intent in traditional smart card scenarios when they are used in conjunction with an untrusted PC.

Smart-cards and malicious hosts

First a few words on the problem. Consider a standard use-case for smart cards: accessing a remote resource, such as SSH or remote-desktop into another machine in the cloud. In a high-assurance environment that would call for strong authentication– in other words,bg not passwords– using cryptographic keys managed on the card. A typical flow might be:

  • User initiates the action
  • Local machine prompts the user for their smart-card.
  • User inserts their card into the reader (or in the case of NFC, brings it into the field of the reader)
  • PIN prompt is displayed
  • User enters their PIN
  • PIN is relayed to the card to authenticate the user to the card.
  • Once the card application is convinced it is dealing with the legitimate card-holder, it performs a cryptographic operation (such as signing a challenge) to authenticate the user to the remote resource.

When preventing key recovery is not enough

Consider the problem of malware resident on the host PC. Card applications and communication interface are designed to prevent the extraction of secret key material via pure software attacks, such as trying to exploit a memory corruption vulnerability. Let’s posit this is working correctly. Let’s further grant that cryptographic primitives are not vulnerable to side-channel leaks (such as timing differences or padding oracles) that can be used to recover keys using pure software attacks.

Smart-card meets hostile PC

Smart-card interacting with a hostile PC controller by adversary

That rules out the obvious avenue for malware to permanently exfiltrate cryptographic secrets out of the card and ship-them off for future use. But the host can ask the card to perform any operation using those secrets while the card is attached. This is because at the card level there is no concept of “user intent.” Looking at a typical architecture as pictured above, there is a compromised PC running malware controlled by the adversary. A card-reader is attached typically via USB or serial link, and the card is introduced to the reader, allowing the PC to issue commands to the card and receive responses in a standardized format known as APDU. Neither the card reader or card have any indication about the provenance of those APDUs, beyond the obvious fact that they originated from the host. There is no other verifiable indication about which particular application sent those commands, whether that application is acting on behalf of the legitimate card-holder or carrying out its own agenda. In effect, the card is just a passenger along for the ride, with PC software calling the shots on exactly what messages are being signed, decrypted or otherwise processed using the card. After card is attached to the system and the user has authenticate, there is an implicit channel (red-dashes above) available to the malware for issuing arbitrary requests to the card.

Just to drive home the point that this is not a hypothetical scenario– and choice of a US government PIV card for illustrative purposes above is not entirely coincidental: in 2012 AlienVault reported that the Sykipot malware was targeting smart cards  by using a key-logger to capture PINs and later issuing its own set of commands to the card.

Working around PIN checks

Requiring PIN entry, as many card applications do before performing sensitive operations, does not solve this problem.  In the most  common scenario, PIN is entered locally on the compromised PC. This input can be intercepted by malware running at sufficiently high privilege and replayed any time later to authenticate to the card to perform some other private-key operations desired by the attacker.

Consider the more advanced case observed in defense and banking scenarios where an external PIN entry device is used. This is a distinct piece of hardware with its own numeric key-pad. Individual keystrokes are not shipped to the PC but instead the entire PIN is delivered to the card as part of a PIN verification command. (Since the format of that command varies by card application, this must be decided upon in advance and programmed into the PIN-pad firmware.) While this will hide the PIN from  malware resident on the host, it does not stop the malware from free-riding on the authenticated channel after PIN verficiation is done. After all PIN entry is being done at the behest of some application the user started– for example it could be their email client trying to decrypt an encrypted message. There is no social engineering required here; malware can simply wait until the user has legitimate reason to enter their PIN on external device because some other application requested card usage. As long as attacker can take control of that application– which is often doable without special privileges– or more directly, take control of the PC/SC interface controlling all card communication, additional commands can be injected for processing by on-card application.

Towards establishing user intent

Some “card”-like devices in the form of USB tokens have a button or similar input device on the card itself to establish user intent. (In fact there are also cards with their own PIN pad to avoid the untrusted entry path problem; the one button for confirming a transaction is effectively a special case of that design.) This is effectively creating a user nuisance in the name of marginal security. It does prevent the card from being commandeered by malware on host, since sensitive operations requires the user to take action. On the other hand, the user still has no idea what operation is about to be performed when they press the button. For example is the token going to sign the document they submitted or another message chosen by malware? Suppose there is an error message saying the operation did not succeed and needs to be repeated; is there a way to distinguish an “honest” error from malware having hijacked the click for its own purpose?

Interface detection on dual-interface cards can emulate these button presses, but they can do one better by allowing the user to verify exactly what is being requested of the card.

[continue to part II]

CP

Is NFC host card-emulation safe for payments? (part II)

[continued from part I]

(Full disclosure: This blogger worked on Google Wallet security)

Card security in perspective: curious case of chip & PIN

Not disturbing the precarious optimal risk equilibrium is one reason EMV adoption has been on a leisurely place in the US. For what seems like a decade, every year has been the year of chip & PIN, when the vaunted technology would finally hit the inflection point. (It may finally be happening in 2015 if the card networks do not blink and stick to their ultimatum for liability switch.) Target and similar large-scale data breaches deserve much of the credit for accelerating the schedule, thanks to negative publicity and decline in consumer confidence– so much that consumers have reported favoring cash in the aftermath of Target breach, a counterproductive reaction that may aggravate risks via theft and loss.

If one focuses on technology alone, it seems puzzling at first why card networks have not embarked on a crash-program to upgrade point-of-sale terminals and cards across the board. After all there is really no comparison in terms of security between swipe and chip transactions. Granted EMV payment protocols are far from perfect: several design flaws have been identified and published in the literature. But even with known (and difficult to fix) defects, chip & PIN represents a major improvement  over swipe transactions, mitigating entire classes of vulnerabilities. But that “puzzle” goes away once the full business impact of  taken into account. Rolling out EMV in a setting that has been used to swipe transactions has been a difficult task. Whatever gains are made locally in reducing fraud may be more than offset by the global cost of the massive undertaking required to upgrade merchants and reissue cards, not to mention user confusion caused by unfamiliar technology– which is another reason why the expected model in the US will involve chip & signature  as opposed to PIN entry, in keeping with the familiar ritual of signing pieces of paper.

HCE and risk management

The parallel with the interminable saga of US chip & PIN adoption is not entirely accurate for HCE/SE. In the first case, chip cards had the formidable problem of displacing a “good enough” installed base. By contrast NFC payments very much remain a green-field, and in principle there is no backwards compatibility problem holding back SE deployment. While merchants have to upgrade to NFC terminals and consumers need to purchase handsets equipped with NFC, once they have made that investment there is no reason to prefer HCE over SE.

In fact the technologically superior solution involving hardware secure elements was first on the scene. It even enjoyed a natural head-start: SE inside a phone represents an incremental evolution of existing standards, leveraging same tried-and-true hardware already deployed in chip & PIN cards, repackaging in slightly different configuration. (Of course reality is not quite that simple: surrounding that secure chip with an always-on, always-connected and highly exposed general purpose computer introduces all sorts of new risk such as remote relay attacks.) By contrast using host-card emulation payments calls for new tokenization standards, designed to compensate for lower security-assurance level of a mobile OS by leaning heavily on online connectivity instead.

So why the frenzy over HCE? Because for the first time it makes contactless payments broadly accessible to enterprising upstarts who were previously marginalized by the “cabal” of secure element manufacturers, TSM operators and wireless carriers. Barrier to entry is lowered to writing an ordinary Android app, along with meeting basic requirements from Visa/MasterCard/AmEx etc. That means more mobile applications developed to run on more mobile devices, carrying credit cards from a wide spectrum of issuers, all adding up to many more transactions by volume and frequency. In other words more interchange fees to go around for all participants in the ecosystem. By contrast the deployment of secure element solutions has been stalled by wireless carriers’ intransigence against Google Wallet, coupled with challenges at executing on their own rival project ISIS– now getting rebranded to avoid confusion with the Iraqi Al-Qaeda faction. (Jury is out on whether the Iraqi terrorist group should be more ashamed of sharing the same name.) As for Google Wallet, its install counts and user-ratings have sky-rocketed after switching to host card emulation. After all, an app that users can not run because of their wireless carrier has precious little utility, no matter how impressed the lucky few are.

What of the alleged decrease in security? By looking at the big picture, we can place the HCE risks in better perspective. First any fraud in question is constrained to card-present in-person transactions, which is quite a bit more difficult to scale than card-not-present transactions that can be conducted from anywhere around the world. (If issuers are careful, they can further constrain potential fraud to NFC transactions only, by blocking the by-design ability to replay NFC track data on a plain magnetic stripe.)  Second, attacks targeting the physical manifestation of the payment instrument– eg magnetic stripe, chip & PIN or mobile device– are only one subset of risks in the system. For example, HCE versus secure-element has no bearing on the safety of merchant terminals. Finally payment networks have defense-in-depth, additional security features designed to detect and prevent attacks that succeed in subverting card security. Most visibly each issuer operates a “back-end” risk engine capable of vetoing transactions even if all of the authorization data from the card looks correct. Defeating the security of the physical payment instrument– be it old-school magnetic stripe or mobile device with NFC– is only the first step: the enterprising fraudster also needs to run the gauntlet of statistical models optimized to detect anomalous spending.

So the argument over HCE amounts to splitting hairs over one very specific attack vector. Gemalto is getting wrapped around the axle over what will be at-worst a negligible increase in fraud. It may even result in a a net decrease by driving adoption of NFC, increasing the percentage of transactions not involving magnetic stripes. To the extent that any one can predict which of these scenarios is more likely to play out, it is the card networks.

CP

Is NFC host card-emulation safe for payments? (part I)

An earlier series of posts compared the security properties of NFC applications implemented using host card-emulation against the same scenario backed by a dedicated hardware secure element. It was not much of a contest; hardware SE easily wins on raw security considerations:

  1. Much stronger tamper-resistance against attacks involving physical access
  2. Greatly reduced attack surface, due to stripped down operating system and locked-down application ecosystem, unlike the anything-goes approach to third-party applications on the average phone
  3. Possible to protect against attacks originating from the host operating system itself
  4. Defense against remote relay attacks using interface detection on the NFC controller

It’s natural to ask: does this mean HCE is not suitable for payments? There have been vocal critics making precisely that claim. NFC Times quotes the Gemalto CEO pursuing this line of argument. Of course Gemalto has a significant business in providing UICC chips– a type of hardware secure element in SIM form factor– to wireless carriers, who are currently making a desperate push for land-grab in the payments space. Having cast its lot with carriers and already reeling from MasterCard/Visa support for HCE, it is not surprising the company does not look kindly on HCE displacing extra hardware. But Gemalto is not alone in trying to “rescue” the world from NFC payments without SE. Whether it is Trustzone or some other snake-oil solution, every vendor seems to have latched on the market failure of secure elements to gain traction as an opportunity to trumpet an alternative to “save” payments from the perils of HCE.

Risk-management versus risk-elimination

First observation is that keeping the fraud level in payments down is a problem of risk management. It is about keeping the frequency and total losses from fraud down to an “optimal level” and distributing the liability appropriately within the system.  More surprising is that optimal level need not be zero, and consumers may be just fine with that arrangement as long as the consequences are not reflected directly on the individual card holder. That second property is important because “optimal” risk can be very different for each participant in the system:

  • Issuing bank who underwrites the card, for example Citibank issuing a MasterCard.
  • Card network facilitating the transactions eg MasterCard.
  • Merchants that accept a particular brand of payment cards
  • Acquiring banks and payment processors helping that merchant accept card transactions
  • Individual card holders

Optimization problem

With the exception of the card-holder, all of these participants are effectively trying to maximize profit. (Strictly speaking, some  issuing banks can be non-profit institutions such as credit unions.) Minimizing fraud is only relevant to the extent that it furthers that objective. This is an important distinction. Earning $100 but losing $10 to fraud may be preferable to earning $50 while only suffering $1 in losses. Granted absolute amounts are not the only concern; increased fraud rates may have second-order effects such as discouraging consumers or merchants from using credit cards. But all of these effects can be quantified. All else being equal, increasing number and dollar-amount of transactions is in the interests of all participants except possibly the card-holder. Security measures designed to combat fraud can end up being counter-productive if they introduce friction, cause transactions to become less reliable or otherwise decrease the revenue stream for the participants. Conversely a technology that is less “safe” in the absolute sense may be preferable for these participants if it boosts overall activity in the ecosystem, provided the attendant fraud can be managed.

Consumer view

Card holders however face a different problem since they can not “average” away profit and loss across many cards. One incident of fraud maxing out a single credit card is a drop in the bucket for Citibank. That same amount can be very significant for the customer involved, enough to wipe out their savings. It doesn’t help that there is great information asymmetry: card networks know a lot about the incidence and impact of fraud while this information is generally not available to consumers, making it difficult to estimate risks. (Is it safe to pay with a credit card online? What about at a street fair?) Worse they have little negotiating power to set terms, other than a rudimentary version of “voting with the wallet” by choosing from offerings from different banks on take-it-leave-it terms.

Fortunately this is where regulation comes in. Consumer protection laws can compensate for the information asymmetry and lack of bargaining power by creating a baseline of  fraud protection that all issuers must adhere to. Such regulations can limit the downside, indemnifying users from losses. The prevailing arrangement in the US via Fair Credit Billing Act (FCBA)  leads to exactly this outcome. Consumers are not liable for fraudulent transactions, a fact that is repeatedly drilled in many an advertisement harping on “zero liability.” Of course what this means more precisely is that we are not directly responsible for reimbursing the issuing bank, merchant or whoever ended up absorbing the loss. Instead those losses are “diffused” across  the system and reflected back to consumers in the form of higher prices at stores (which reflect the expected incidence of charge-backs), higher interest rates on balances carried or greater cut taken by middlemen to offset expected losses.

With consumers effectively neutralized in this manner, card networks have great leverage to move risk around the system, squeezing either banks (unlikely) or more commonly merchants. Similarly they are free to set standards on the design and operation of payment technologies without having to face significant consumer backlash. The average card-holder has little at stake directly to care whether that PIN pad is really living up to its tamper-resistance promise or that point-of-sale terminal is not compromised by malware waiting to skim cards. If there is a security problem anywhere in this chain, it is someone else’s problem to make the consumer whole.

[continued]

CP