Month: March 2015

What is wrong with Apple Pay? NFC and cross-channel fraud (1/2)

Several news stories have “discovered” that Apple Pay has not, in fact, spelled the end of credit card fraud and may even have created new opportunities. That seems surprising considering that NFC payments were supposed to be an improvement over magnetic-stripe swipes in terms of security, using a cryptographic protocol that prevents reusing information stolen from one merchant to make additional fraudulent transactions at another one. Much of the problem turns out to be usual sad state of technology journalism. It is not that NFC or EMV have a new vulnerability that is being exploited against hapless iPhone users. (To be fair, EMV does have its fair share of security weaknesses and mobile payments have introduced some incremental risks, but those subtleties are not what has the press riled up.) Apple has not created a new way to steal credit-cards. But it has created a more effective avenue for monetizing already stolen cards. Apple Pay is not the vulnerability— it is just one particular technique for exploiting an ancient one.

Online vs in-store transactions

Going back to our summary of how credit-card payments operate, we differentiated between two types of transactions:

  • Card-present, or more colloquially “in-store.” The customer walks up to a cash registers and hands over their card to the merchant. That card can be “read” in different ways. At the low-tech end of the spectrum is old-school mechanical imprinting, creates an actual carbon-copy of the front of the card bearing embossed numbers. More common is the “swipe” where information encoded in the magnetic-stripe at the back of the card is scanned by moving the card through a magnetic field. Finally if the card has a smart chip, there is the EMV option of executing a complex cryptographic protocols between card/terminal. In these cases each interaction is unique and the data observed by the terminal different, unlike a magnetic-stripe which has the same information every time.
  • “Online,” or what used to be called phone-order/mail-order back when picking up a telephone or sending pieces of paper via USPS did not seem such an antiquated concepts. Generically this class is known as “card-not-present” transaction, because the merchant does not have the actual piece of plastic in hand when placing the charge. (We will avoid the term “online” because in payments it is also used to describe when a point-of-sale terminal is communicating in real-time with card network, as opposed to batching up transactions for later submission.)

Containing fraud

From a fraud perspective, the key observation is that each modality exchanges slightly different information with the terminal. All of them share the same basic data such as credit-card number and expiration. But each one also introduces a unique twist. Track-data on magnetic stripe has a 3-5 digit “card validation code” commonly called CVV1. Online transactions use a different value called CVV2, printed on the card itself but not encoded in the magnetic-stripe. Meanwhile the basic version of EMV simulates the action of swiping for “track-data” for backwards compatibility, but substitutes a dynamic CVV or CVV3 which changes each time in a manner unpredictable without knowing the cryptographic secret stored in the chip.

A corollary of this difference is that it acts as a natural “firewall” between channels. Fraud remains largely contained to its original channel. Consider the criminals who popped Target or HomeDepot point-of-sale terminals in the past. This attack allowed to them amass a cache of raw track-data from magnetic-stripes swiped at those cash registers. That information can be used to create convincing replicas of cards that will behave exactly like the original card when swiped through a reader. But there is no CVV2 encoded in the magnetic-stripe.** That is a limiting factor if our criminals wanted to monetize those cards online, instead of walking into a store. Most websites these days will collect and validate CVV2 for online orders. (As an aside, there trade-offs in both avenue for monetization. In-store fraud is harder to scale because it requires recruiting mules to run the risk of walking into a store with fake cards, with their faces captured on camera. Online fraud scales better; there is no limit to how many websites you can drive to or how many big-box items can fit into the trunk. Downside is delivery involves a shipping address that can be traced- notice how many ecommerce sites flat out refuse shipping to PO boxes.)

[continued]

CP

** Some merchants have started asking for or keying in CVV2 by looking at the card during retail transactions. That is a dangerous pattern. It may help that particular merchant reduce fraud temporarily by doing additional verification on the card, but it weakens the overall ecosystem by putting card-not-present at greater risk against compromised terminals.

Second-guessing Satoshi: ECDSA and Bitcoin (part II)

[continued from part I]

There are ways to improve confidence in the correct operation of a blackbox ECDSA implementation that has bee tasked with signing transactions with our private key. One approach suggested in the original paper is choosing the jointly between blackbox and external client requesting signatures. There is an inherent asymmetry here, because the two sides can not complete such a protocol on equal terms. Because knowledge of the nonce used to a particular signature allows private-key recovery, the client can not learn the final value that will be used to compute the signature. But we can still defeat a kleptographic system by guaranteeing that the blackbox can not fully control choice of nonce either.

  • Blackbox chooses its own nonce k and commits to it, for example by outputting a hash of the curve point that would have resulted from using that nonce eg P = k∗G
    where G is the generator of the group. (Recap: first half of an ECDSA signature is the x-coordinate of the point on the elliptic-curve that is obtained by “multiplying” the generator with the nonce.)
  • Client returns a random scalar value r.
  • Blackbox opens the commitment to reveal its chosen point P— but not the scalar k— and then proceeds to compute the signature using Q = r ∗ (k∗G).
  • Before accepting the signature, client verifies that the final point Q and original choice P are related as Q = r∗P.

This guarantees that even if a kleptopgraphic implementation chose “cooked” k values to leak information, that signal is washed away when those choices are multiplied by random factors. In fact  multiplication is not the only option. The protocol is equally effective with addition and using (r+k) ∗ P as final value. But an extra point-multiplication for both sides can not be avoided because each side still has to compute r∗P on its own. They can not accept a result precomputed by the other side.  (It does make it easier to for the client to verify expected result by a simple point addition instead of the more expensive multiplication.)

Main challenge for this protocol is the interactivity— it changes the interface between the ECDSA implementation and client invoking a signature operation by requiring two round-trips. But it need not require changes to the client software. For cryptographic hardware such as HSMs, there is already a middleware layer such as PKCS#11 that translates higher-level abstractions such as signing into low-level commands specific to the device. This abstraction layer could hide the extra round-trip. Alternatively the round-trip can be eliminated by a stateful client. Suppose that after every signature the HSM outputs a commitment to the nonce it will use for the next signature and client caches this value. Then each signature request can be accompanied by client’s own random contribution and each signature response can be verified against the commitment cached from previous operation.

We can extend that further to come up with a different mitigation: suppose that the blackbox ECDSA implementation is asked to commit to thousands of nonces ahead of time. The client can in turn specify a single seed value that will be used to influence every nonce in the list according to a pseudo-random function of that random seed. (We can’t simply add/multiply every nonce with the same random value. That would fail to mask patterns across multiple nonces chosen by a kleptographic implementation.) In this case no interactivity is required for signature operations, since both blackbox and client contributions to the final nonce are determined ahead of time. One caveat: a kleptographic implementation can try to cheat by faking a malfunction and outputting invalid responses in order to skip some values in the sequence, leaking information based on which ones were omitted. Meanwhile the client can’t insist that blackbox sign with previous nonce, because reusing nonces across different messages also results in private-key disclosure.

As a side-note: precomputing and caching nonces can also serve as a performance optimization, by leveraging the online/offline nature of ECDSA. Such signature schemes have the unusual property that a significant chunk of the required computation can be done without seeing the message that is being signed. For ECDSA the generation of the first half of the signature fits the bill: multiply a fixed point of the elliptic-curve by a random nonce that is chosen independent of the message. That point multiplication is by far the most expensive part of the signature. Front-loading that and computing nonces ahead of time reduces perceived latency when it is time to actually emit a signature.

One problem not addressed in the original paper is that of key generation. If the objective is guarding against a kleptographic blackbox ECDSA implementation, then it can not be trusted to generate keys either. Otherwise it is much simpler to “leak” private keys directly by using a subverted RNG whose output is known to the adversary. Ensuring randomness of nonces used when signing will not help in that situation; the private key is already compromised without signing a single message. But the same techniques used to randomize the nonce can be applied here, since an ECDSA public-key is also computed as a point-product of the secret private key and fixed generator point. The blackbox can commit to its choice of private-key by outputting a hash of the public-key, and the client can provide additional random input that causes final chosen key to be distributed randomly even if the blackbox was dishonest.

All of this complexity raises a different question: why is Bitcoin using ECDSA in the first place? As pointed out, RSA signing does not suffer from this problem of requiring “honest” randomness for each signature. But that is simply one criteria among many considerations. A future post will compare RSA and ECDSA side-by-side for use in a cryptocurrency such as Bitcoin.

[continued]

CP