Getting by without passwords: web-authentication (part I)

There is a recurring theme in the previous series on replacing passwords by cryptographic hardware: all the scenarios were under unilateral control of the user. If you plan to use SSH private-keys for connecting to a remote service such as Github, it is transparent to that service whether those keys are stored locally on disc protected by a passphrase or stored on external tamper-resistant hardware. Same goes for disk-encryption and PGP email signing; the changes required to move from passwords to hardware tokens are localized to that device. In this post we look at a more difficult use-case: authentication on the web.

The fundamental problem is that one exercises very little control over the authentication choices offered by a website. That decision is made by the persons controlling the web server configuration. Until about 5 years ago in fact, there were no options at all: passwords were the only game in town. Only a handful of websites offered two-factor authentication of any type. It was not until Google first deployed the feature that going beyond passwords became an aspirational goal for other services hoping to compete on security. But the majority of 2FA designs did not in fact dispense with passwords; they were more accurately “password-plus” concepts, incremental in nature and trying to augment a user-selected password with an additional factor such as SMS message and one-time passcode generated by a mobile app.

Authentication integrated into SSL/TLS

Given the dearth of options, it may come across as a surprise that the fundamental security protocol that secures web traffic— SSL or TLS, Transport Layer Security in the modern terminology— supports a better alternative. Even more surprisingly, that feature has existed nearly since the inception of the protocol in the late 1990s. The official name for the feature is client-authentication. That terminology is derived from the roles defined in SSL/TLS protocols: a user with a web-browser (“client”) establishes a secure connection to a website (“server”.) 99.999% of the time, only one side of that connection is authenticated as far as TLS is concerned– the server. It is the server that must present a valid digital certificate, and manage corresponding cryptographic keys. Clients have no credentials at the TLS layer. User authentication, to the extent it happens, occurs at a higher application layer; for example with a password typed into a web page and submitted for verification. While that is very much of a legitimate type of authentication, it takes place outside the purview of TLS protocol, without leveraging any functionality built into TLS.

This functionality built into TLS for authenticating users is the exact mirror-image of how it authenticates servers: using public-key cryptography and X509 certificates. Just as websites must obtain server-certificates from a trusted certificate-authority, or CA for short, users obtain client-certificates from a trusted CA. (It could even be the same CA; while the commercial prospects for issuing client-certificates is dim compared to server certificates, a few intrepid CAs have ventured into personal certificate issuance.) But more importantly, users must now manage their own private-keys, the cryptographic secrets associated with those certificates.

Therein lies the first usability obstacle for TLS client-authentication: these credentials are difficult to manage. Consider that passwords are chosen by humans, with the full expectation that they will be typed by humans. They can be complex, random looking string of characters but more likely, they are simple, memorable phrases out of a dictionary. To “roam” a password from one computer to another, that person needs only her own memory and fingers. By comparison, cryptographic keys are not memorable. There is too much entropy, too many symbols to juggle for all but the few blessed with a photographic memory. (Meanwhile attempts to derive cryptographic keys from memorable phrases rarely have good outcomes- consider the BrainWallet debacle for Bitcoin.) It’s relatively easy to generate secret keys on one device and provision a certificate there. The real challenge lies in moving that secret to another device, or creating a backup such that one can recover from the loss/failure of the original. Imagine being locked out of every online account because your computer crashed.

Compounding that is a historical failure to converge on standards: while every piece of software can agree on using passwords the same way, there is great variety (read: inconsistency) in how they handle cryptographic secrets. If you can login to a website using Firefox with a given password, you can count on being able to type the exact same password into Chrome, Internet Explorer or for that matter, a mobile app to achieve same result. The same is not true of cryptographic keys. To pick a simple example: openssh, PGP and openssl all perform identical operations using private-keys (signing a message) in the abstract, from a mathematical perspective. But they differ in the format they expect to find those keys such that it is non-trivial to translate keys between different applications. Even different web browsers on the same machine can have their own notions of what certificates/keys are available. Firefox uses its own “key-store” regardless of operating system, while Chrome defers to the operating system (for example, leveraging CAPI on Windows and tokend on OSX) and Internet Explorer only recognizes keys defined through Windows cryptography API. It is entirely possible for a digital certificate to exist in one location while being completely invisible to the other applications that look for their credentials in another one.

It is no wonder then that TLS client authentication has been relegated to niche applications, typically associated with government/defense scenarios with UI that qualifies for the label “enterprise-quality” Browser vendors rightfully assume that only hapless employees of large organizations who are required to use that option by decree of their IT department will ever encounter that UI.

Server-side support

Assuming that one can control the configuration of a server, Apache, IIS and nginx can all be set up with client-authentication. At a high-level this involves:

  • Specifying a set of certificate authorities (CAs) trusted for issuing  client certificates. This is the counterpart of clients maintaining their own collection of trust-anchors to validate server certificates presented by websites. Getting this right is important because it influences client behavior. During the TLS handshake, the server will actually send the client this list to serve as hint for picking the correct certificates. The user-agent can show different UI depending on whether there is zero, one or multiple options for the user to choose from.
    • Unlike web-browsers who implicitly trust hundreds of public CAs in existence, trust-anchors for the server are bound to be very limited. Most public CAs do not issue client certificates to individuals, so there is no point to including them in the group. Typically TLS client authentication is deployed in closed-loop systems: members of an organization accessing internal resources, with exactly one CA also operated by the same entity to issue everyone their credentials.
    • There is also the degenerate case of trusting any issuer, which includes self-signed certificates. That is not useful for authentication by itself: it only establish a pseudonym, by proving continuity of identity. “This is the same person that authenticated last time with same public-key.” But it can be coupled with other, one-time verification mechanisms to implement strong authentication.
  • Deciding whether client-authentication is mandatory vs optional. In the first case, the server will simply drop the connection when the client lacks valid credentials. There is no opportunity for the application layer to present a user-friendly error message, or even redirect them to an error page. That requires exchanging HTTP traffic, which is not possible when the lower-layer TLS channel has not been setup. For that reason it is wiser to use the optional setting, and have application code handle errors by checking if a certificate has been presented.

Fine-grained control & renegotiation

One crucial difference between server capabilities is that Apache and IIS can apply client-authentication to specific paths such as only pages under /foo directory. By comparison nginx can only enable the feature for all URLs fielded by a given server. It is not possible to configure on a per-path basis.

At first blush, it is somewhat puzzling that Apache and IIS can distinguish between different pages and know when to prompt the user. Recall that TLS handshake takes place before any application level data- in this case HTTP- has been exchanged. Meanwhile the URL path requested is conveyed as part of the HTTP request. So how is it possible for a web server to decide when to request a client certificate? Let’s rule out one trick: this behavior is not implemented by always prompting for a client certificate and then ignoring authentication failures based on path. Requesting a client certificate can modify the user experience: some user-agents simply panic and rop the connection, others such as early version of IE might display a dialog box with an empty list of certificates that confuses  users.

The answer is a little-known and occasionally problematic feature of TLS: renegotiation. Most TLS connections involve a single handshake completed at the beginning, followed by exchanging application level data. But the protocol permits the server to request a new handshake from scratch, even after data has been exchanged. This is what allows Apache and IIS to provide fine-grained control: initially a TLS connection is negotiated with server authentication only. This allows the client to start sending HTTP traffic. Once the request is received, the server can inspect the URL and decide whether that particular page requires additional authentication for the client. In that case the exchange of application-level HTTP traffic is temporarily paused, and a lower-level TLS protocol message (namely ServerHello) is sent to trigger a second handshake. This time the server includes an additional message type (namely CertificateRequest) signaling the client to present its certificate.

Client-side support

Popular web browsers have also supported client-authentication since late 1990s, but the user-experience often leaves much to be desired. As an additional challenge, our objective is not just using public-key authentication but also using external cryptographic hardware to manage those keys. That introduces the added complexity of making sure the web browser can interface with such devices.

Chrome

Here is Chrome on OSX displaying a modal dialog that asks the user to choose from a list of three certificates:

Chrome_3certs

TLS Client Authentication prompt in Google Chrome 51, expanded view

This dialog appears when accessing a simple demo web-server that requested client authentication. (It is an expanded version of the original abridged dialog, which starts out with only the list at the top, without detailed certificate information below.) All available certificates are displayed, including those that are stored locally on the machine, and those which are  associated with a hardware token- in this case a PIV token- currently connected. Note that the UI does not visually distinguish; but hardware credentials only appear in the listing when the token is connected.

Choosing one of the certificates on the PIV token leads to a PIN prompt:

Chrome_PIN_entry

Chrome PIN prompt for hardware token

Chrome turns out to be something of a best-case scenario:

  • It is integrated with the OSX key-chain and tokend layer for interfacing with cryptographic hardware (In theory tokend has been deprecated since 10.7, but in practice remains fully functional and supported via third-party stacks.)
  • Credentials do not need  to be explicitly “registered” with Chrome, as long as there is a tokend module which supports them. This example uses the same OpenSC tokend that makes possible previous scenarios such as smart-card login on OSX. Connecting the PIV token is enough.
  • The dialogs themselves are part of OSX, which creates uniform visuals. For example here is the same UI from Safari- note the icon overlaid on the padlock is now the Safari logo:
Safari_client_auth_prompt.png

TLS client authentication prompt in Safari 9.1, compact view

For an example of a more tricky setup, we next turn to Firefox and getting the same scenario working there.

[continued]

CP

Box enterprise key-management: in cloud we (still) trust

Notions of privacy in cloud-computing

Private computation in the cloud has been around—in concept, if not in actual implementation— for almost as long cloud computing or “grid computing” as its early predecessors were known by a distinctly industrial sounding moniker. From the outset, concerns about data security has been one of the primary obstacles to outsourcing computing infrastructure to third-parties. What happens to proprietary company information when it is sitting on servers owned by somebody else? Can this cloud-provider be trusted to not peek at customer data or tamper with the operation of services that tenants run inside the virtual environment? Can the IaaS provider guarantee that some rogue employee can not help themselves to the confidential data uploaded there? What protections exist if government agencies with creative interpretations of the fourth-amendment show up at the door? Initially cloud providers were quick to brush aside these concerns, or at best respond with appeals to brand authority and credentials (ISO 27001 certified, PCI-compliant etc.) Once customers  proved skeptical and demanded actual evidence of operational security, special cases were crafted: Amazon provides a dedicated cloud for its government customers, presumably with improved controls and isolated from the unwashed masses with their own VMs running less sensitive applications.

Meanwhile the research community has welcomed the emerging questions as the starting point for a research agenda around computing on encrypted data. These schemes take a drastic step by placing no trust in cloud providers, positing that they will only receive encrypted data which they can not decrypt- not even temporarily, an important distinction that critically fails for many of the existing systems, as we will see. The question becomes whether cloud services can still  perform meaningful operations on encrypted data, such as searching for keywords or number-crunching, producing results which can only be decrypted by the original owner. That approach holds a lot of promise, provided it can be implemented efficiently. It preserves the advantage of cloud computing (lease CPU cycles, RAM and disk space from someone else on demand) while maintaining confidentiality of the data processed.

Status quo

Between these ends of the spectrums, private-computation in the cloud appears to be caught in a chasm between a rock and a hard place:

  • Stuff that can not possibly work: impassioned self-declarations of honesty/competence by the vendor
  • Stuff that does not yet work: promising research in academic literature around special-cases without a feasible solution for the general case

Solutions in the first category effectively boil down to the premise: “trust us, we will not peek at your data.” Some of these are transparently non-technical in nature: for example warrant canaries are an attempt to work-around the gag-orders accompanying national security letters (NSLs) by using the absence of a statement to hint at some incursion by law enforcement. Others attempt to bury those critical trust assumptions in layers of complex technology.

Box & enterprise key-management

Take for instance Box’s enterprise key-management. On paper this is attempting to address a legitimate scenario discussed in earlier posts: storing data in the cloud encrypted such that the cloud-provider can not read the data even if it wanted to. This is a far-cry from how popular cloud storage providers operate today: by default Google Drive, Microsoft One Drive and Dropbox have full access to customer data. Sure, they may store that data encrypted within their own data-center– a capability hilariously touted as some ground-breaking privacy feature or competitive advantage. In reality such encryption is only there to protect against risks internal to the cloud service provider: rogue employees, theft of hardware from data-centers etc. At the end of the day that layer of encryption is fully reversible by the hosting service, without any cooperation required by the original custodian.

Far more robust are designs which guarantee that the storage provider can not recover user data, even if they were compelled or employees were hit with the evil stick. Until a few years ago, that level of security would have seemed a quixotic requirement out of paranoid minds. Along came Snowden and a sea-change happened: cloud-providers started trying to build actual cryptographic protections instead of vouching for their  good intentions.

The solution Box has announced with much fanfare decidedly fails to achieve that objective. To see, why let’s review the outline of that design to the extent that can be gleamed from public sources:

  • There is a master-key for each “customer” (defined as an enterprise, rather than end-user; recall that Box distinguishes itself from Dropbox and similar services by focusing on managed IT environments.)
  • As before, individual files uploaded are encrypted with a key that Box generates.
  • The new twist is that those individual bulk-encryption keys are in turn encrypted by the master-key
  • So far, this is only adding a hierarchical aspect to key management. Where EKM is different is transferring custody of the master-key back to the customer, specifically to HSMs hosted at AWS (via CloudHSM) and backed up by additional HSMs hosted in the customer data-center carrying replicas of the same secrets. (It is unclear whether this is a symmetric key or asymmetric key-pair but the latter design would make far more sense. It would allow encryption to proceed locally without involving remote HSMs and only decryption to require interaction.)

Box implies that this last step is sufficient to provide “Exclusive key control – Box can’t see the customer’s key, can’t read it or copy it.”

Is that sufficient? Let’s ask what could go wrong.

Trust by any other name

First observe that the bulk-data encryption keys are generated by Box. These keys need to be generated “randomly” and discarded afterwards, keeping only the version wrapped by the master-key. A trivial way for Box to retain access to customer data— for example, if ordered by law enforcement— is to generate keys using a predictable scheme or simply stash aside the original key.

Second, note that Box can still decrypt data anytime, as long as the HSM interface is up. Consider what happens when employee Alice uploads a file and shares it with employee Bob. At some future instant, Bob will need to get a decrypted copy of this file on his machine. By virtue of the fact Box must be given access to HSMs, there must exist at least one path where that decryption takes place within Box environment, with Box making an authenticated call to the HSM. (Tangent: Box has a smart-client and mobile app so in theory decryption could also be taking place on the end-user PC. In that model HSM access is granted to customer devices instead of Box service itself, keeping the trust boundary internal to the organization. But that model faces practical difficulties in implementation. Among other things, HSM access involves some shared credentials- for example in the case of Safenet Luna SA7000s used by CloudHSM, there is a partition passphrase that would need to be distributed to all clients. There is also the problem that user Alice could decrypt any document, even those she did not have access to by permission. Working around such issues would require additional infrastructure, such as placing another service in front of HSMs to authenticates users based on their own enterprise identity, rather than  Box account. Even then there is the scenario for files from a web-browser when no such intelligence exists to perform on the fly decryption client-side.)
 That raises two problems. Most obvious one is that the call does not capture user intent. As Box notes, any requests to HSM will create an audit-trail but that is not sufficient to distinguish between the cases:

  • Employee Bob is really trying to download the file Alice uploaded
  • Some Box insider went rogue and wants to read that document

While there is an authentication step required to access HSMs, those protocols can not express whether Box is acting autonomously versus acting on behalf of a user at the other side of the transaction requesting a document.

The second problem applies even if Box refrains from making additional HSM calls in order to avoid arousing suspicion (Just to be on the safe side, in case the enterprise is checking HSM requests against records of what documents its own employees accessed, even though the latter is provided by Box and presumably subject to falsification.) During routine use of Box, in the very act of sharing content between users, plaintext of the document is exposed. If Box wanted to start logging documents— because it has gone rogue or is being compelled by law enforcement— it could simply wait until another user tries to download the same document, in which case decryption will happen. No spurious HSM calls are required. For that matter Box could wait until Alice makes some revisions to the document and uploads a new version in plaintext.

Point-in-time trust vs ongoing trust

Stepping back from these specific objections, there is an even more fundamental flaw in this concept: customers still have to trust that Box has in fact implemented a system that works as advertised. This is not one-time trust at the outset, but ongoing trust for the lifetime of the service. The first case would have been easy to accept. It is the type of optimistic assumption one makes all the time: when purchasing hardware from a manufacturer, one hopes the units were not back-doored. If the manufacturer decides to go rogue after the units are shipped, it is too late; they can not go back and compromise existing inventory in the field. (Barring auto-update or remote-access mechanisms, of course.) Here the problem is much worse: Box can go “rogue” anytime to start logging cleartext data, silently escrow keys to another party or simply use weak keys that can be recovered later. Now current Box employees will no doubt swear upon a stack of post-IPO shares that no such shenanigans are taking place. This is the same refrain: “trust us, we are honest.” They are almost certainly right. But to outsiders their cloud service is an opaque black-box: there is no way to verify that such claims are accurate. At best an independent audit may confirm the claims made by the service provider, corroborating one pledge of good-intentions with another ( “trust Ernst & Young, they are honest too”) without altering the core dynamic: this design critically relies on competent and faithful execution by cloud provider to guarantee privacy.

A miss is as good as a mile

Why single out Box when this is the modus operandi for most popular cloud-storage services? Because of all cloud scenarios, storage is most amenable to end-to-end privacy. Unlike searching encrypted documents or  computing complex functions over a spreadsheet of encrypted columns, there is no cutting-edge research problem here. There are no breakthroughs required in efficient homomorphic encryption, no waiting for more iterations of Moore’s law to get hardware fast enough. It is already possible to implement remote storage in the cloud with nearly zero trust. In the same way that one does not have to worry about whether the disk-drive on their laptop is selling out their, one can design systems such that service providers are truly glorified disk-drives in the cloud with no visibility into the bits they are storing. (It is of course a different question whether such services can be as those that “add value” by actively processing stored data and trying to offer additional services around it.) Such providers compete on availability– providing service without having outages or losing data. They never have to compete on privacy by making heart-felt statements about their good intentions. Cryptography properly employed already solves that problem.

CP

Looking back on the Google Wallet plastic card

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

Google recently announced that its Wallet Card launched in 2013 will be discontinued this summer:

“After careful consideration, we’ve decided that we’ll no longer support the Wallet Card as of June 30. Moving forward, we want to focus on making it easier than ever to send and receive money with the Google Wallet app.”

This is the latest in a series of changes starting with the rebranding of original Google Wallet into Android Pay. It is also a good time to look back on the Wallet Card experiment in the context of the overall consumer-payments ecosystem.

Early example of Google Wallet card

Early iteration of the Wallet card

 

Boot-strapping NFC payments

The original Google Wallet launched in 2011 was a mobile application focused on contactless payments or colloquially tap-and-pay: making purchases at bricks-and-mortar stores using the emerging Near Field Communication wireless interface on Android phones. NFC already enjoyed support from payment industry, having been anointed as the next generation payment interface combining the security of chip & PIN protocols with a modern form factor suitable for smartphones. (Despite impressive advances in manufacturing every-thinner phones, it’s still not possible to squeeze one into a credit-card slot, although LoopPay had an interesting solution to that problem.) There were already pilot projects with cards supporting NFC, typically launched without much marketing fanfare. At one point Chase and American Express shipped NFC-enabled cards. That is remarkable considering that on the whole, banks have been slow to jump on the more established contact-based chip & PIN technology. NFC involves even more moving parts.  Not only must the card contain a similar chip to execute more secure payment protocols, but it requires an antenna and additional circuitry to draw power wirelessly from the field generated by a point-of-sale terminal. In engineering terms, that translates into more opportunities for a transaction to fail and leave a card-holder frustrated.

Uphill battle for NFC adoption

Payment instruments have multiple moving pieces controlled by different entities: banks issue the cards, merchants accept them as a form of payment with help from payment-processors and ultimately consumers make payments. Boot-strapping a new technology can be either an accelerating virtuous-cycle or stuck in a chicken-and-egg circularity.

  • Issuers: It’s one thing for banks to be issuing NFC-enabled plastic cards on their own, quite another for those cards to be usable through Google Wallet. After all the whole point of having a card with chip is that one can not make a functioning “copy” of that card by typing in the number, expiration-date and CVC into a form. Instead the bank must cooperate with the mobile-wallet provider (in other words, Google) to provision cryptographic keys over the air into special hardware on the phone. Such integrations were far from standardized in 2011 when Wallet launched, leaving customers with only two choices: a Citibank MasterCard and a white-label prepaid card from Metabank. Not surprisingly, this was a significant limitation for consumers who were not existing Citibank customers or interested in the hassle of maintaining a prepaid card. It would have been a hard slog to scale up one issuer at a time but an even better option presented itself with the TxVia acquisition: virtual cards for relaying transactions transparently via the cloud to any existing major credit-card held by the customer. That model wasn’t without its own challenges, including unfavorable economics and fraud-risk concentration at Google. But it did solve the problem of issuer support for users.
  • Merchants: Upgrading point-of-sale equipment is an upfront expense for merchants, who are reluctant to spend that money without a value proposition. For some being on the cutting edge is sufficient. When mobile wallets were new (and Google enjoyed ~3 year lead before ApplePay arrived on the scene) it was an opportunity to attract a savvy audience of early-adopters. But PR benefits only extend so far. Card networks did not help the case either: NFC transactions still incurred same costs in credit-card processing fees, even though expected fraud rates are lower for when using NFC compared to magnetic stripes which are trivially cloned.
  • Users: For all the challenges of merchant adoption, there was still a decent cross-section of merchants accepting NFC payments in 2011: organic grocery-chain Whole Foods, Peet’s coffee, clothing retailer Gap, Walgreens pharmacies, even taxicabs in NYC. But merchants were far from being the only limiting factor for Google. In the US wireless carriers represented an even more formidable obstacle. With Verizon, AT&T and T-Mobile having thrown in their lot with a competing mobile payments consortium called ISIS (later renamed Softcard to avoid confusion with the terrorist group) they lobbied to block their own subscribers from installing Google Wallet on their phones.

 

 

From virtual to physical: evolution of the proxy-card

Shut out of its own customers’ devices and locked in an uneasy alliance with wireless carriers over the future of Android, Google turned to an alternative strategy to deliver a payment product with broader reach, accessible to customers who either did not have an NFC-enabled phone or could not run Google Wallet for any reason. This was going to be a regular plastic card, powered by the same virtual card technology used in NFC payments.

For all intents and purposes, it was an ordinary MasterCard that could be swiped anywhere MasterCard was accepted. It could also be used online for card-not-present purchases with CVC2 code. Under the covers, it was a prepaid-card. Consumers could only spend existing balances loaded ahead of time. There was no credit extended, no interests accruing on balances, no late fees. It did not show up on credit history or influence FICO scores.

There would still be a Google Wallet app for these users; it would show  transactions and managing funding sources. But it could not be used for tap-and-pay. NFC payments— once the defining feature of this product— had been factored out from the mobile application, becoming an optional feature available to a minority of users when the stars aligned.

Prepaid vs “prepaid”

But there was one crucial difference from the NFC virtual-card: users had to fund their card ahead of time with a prepaid balance. That might seem obvious given the “prepaid” moniker, yet it was precisely a clever run-around that limitation which had made the Google Wallet NFC offering a compelling product. When users paid tapped their phone, the request to authorize that transaction was routed to Google. But before returning a thumbs up or down, Google in turn attempted to place a charge for the exact same amount on the credit-card the customer had setup in the cloud. The original payment was authorized only after this secondary transaction cleared. In effect, the consumer has just funded their virtual-card by transferring $43.98 from an existing debit/credit card, and immediately turned around to spend that balance to make a purchase which coincidentally was exactly $43.98.

Not for the plastic card: there was an explicit stored-value account to keep track of. This time around that account must “prepaid” for real, with an explicit step taken by the consumer to transfer funds from an existing bank-account or debit/credit card associated with the Google account. Not only that but using a credit card as funding source involves explicit fees to the tune of 2.9% to cover payment processing. (If the same logic applied to NFC scenario, $97 purchase at the cash-register would have been reflected as $100 charge against the original funding source.)

The economics of the plastic card necessitate this. Unlike its NFC incarnation, this product could be used at ATMs to withdraw money. If there were no fees for funding from a credit-card, it would have effectively created a loop-hole for free cash-advances: tapping into available credit on a card without generating any of the interchange fees associated with credit transactions. While having to fund in advance was a distinct disadvantage, in principle existing balance could be spent through alternative channels such as purchases from Google Store or peer-to-peer payments to other users. But none of those other use-cases involve swiping— which raises the question: what is the value proposition of a plastic card in the first place?

 

End of the road, or NFC reaches critical mass

In retrospect the plastic card was stuck in no man’s land. From the outset it was a temporary work-around, a bridge solution until mobile-wallets could run on every device and merchants accepted NFC consistently. That first problem was eventually solved by jettisoning the embedded secure-element chip at the heart of the controversy with wireless carriers, and falling back to a less-secure but more open alternative called host-card emulation. As for the second problem,  time eventually took care of that with a helping hand from ApplePay which gave NFC a significant boost. In the end, the plastic proxy-card lived out its shelf-life, which is the eventual fate for all technologies predicated on squeezing out a few more years out of swipe transactions, including dynamic/programmable stripes and LoopPay.

CP

Bitcoin’s meta problem: governance (part I)

Layer 9: you are here

Bitcoin has room for improvement. Putting aside regulatory uncertainty, there is the unsustainable waste of electricity consumed by mining operations, unclear profitability for miners as block rewards decrease and last but not least, difficulty scaling beyond its Lilluputian capacity of handling only a few transactions per second globally. (You want to pay for something using Bitcoin? Better hope not many other people have that same idea in the next 10 minutes or so.) In theory all of these problems can be solved. What stands in the way of a solution is not the hard reality of mathematics; this is not a case of trying to circle the square or solve the halting problem. Neither are they insurmountable engineering problems. Unlike calls for designing “secure” systems with built-in backdoors accessible only to good guys, there is plenty of academic research and some real-world experience building trusted, distributed systems to show the way. Instead Bitcoin the protocol is running into problems squarely at “layer 9:” politics and governance.

This last problem of scaling has occupied the public agenda recently and festered into a full-fledged PR crisis last year with predictions of the end of Bitcoin. Much of the conflict  focusing on the so-called “block-size”- the maximum size of each virtual page added to the global ledger of all transactions maintained by the system. More space in that page, more transactions can be squeezed in. That matters for throughput because the protocol also fixes the rate at which pages can be added, to roughly one every 10 minutes. But TANSTAAFL still holds: there are side-effects to increasing this limit, which was first put in place by Satoshi himself/herself/themselves to mitigate denial-of-service attacks against the protocol.

Game of chicken

Two former Bitcoin Core developers found this out the hard way last summer when they tried to force the issue. They created a fork of the popular open-source implementation  of bitcoin (Bitcoin Core) called BitcoinXT with support for expanded block size. The backlash came swift and loud. XT did not go anywhere, its supporters were banned from Reddit forums and the main developer rage-quit Bitcoin entirely with a scathing farewell. But that was not the end of the scaling experiment. Take #2 followed shortly afterwards as a new fork dubbed Bitcoin Classic, with more modest and incremental changes to block-size to address criticisms in XT. As of this writing, Classic has more traction than XT ever managed but remains far from reaching the 75% threshold required to trigger a permanent change in protocol dynamics.

Magic numbers and arbitrary decisions

This is a good time to step back and ask the obvious question: why is it so difficult to change the Bitcoin protocol? There are many arbitrary “magic numbers” and design choices hard-coded in the design:

  • Money supply is fixed at 21 million bitcoins.
  • Each block rewards the miner 50 bitcoins, but that reward halves periodically with the next decrease expected around June of this year
  • Mining uses a proof-of-work algorithm based on the SHA2 hash function
  • Proof-of-work construction encourages the creation of special-purpose ASIC chips, because they have significant efficiency advantages over using ordinary CPUs or GPUs that ship with off-the-shelf PCs/servers.
  • That same design is “pool-friendly:” its design permits the creation of mining pools, where a centralized pool operator coordinates work by thousands of independent contributors and distributes rewards based on share of work coordinated.
  • Difficulty level for that proof-of-work is adjusted roughly around ~2000 blocks, with the goal of making the interval between blocks 10 minutes
  • Transactions are signed using ECDSA algorithm over one specific elliptic-curve secp256k1
  • And of course, blocks are limited to 1MB in size

Where did all of these decisions come from? To what extent are they fundamental aspects of Bitcoin—it would not be “Bitcoin” as we understand it without that property— as opposed to arbitrary decisions made by Satoshi that could have gone a different way? What is sacred about the number 21 million? (It is half of 42, the answer to the meaning of life?) Each of the decisions can be questioned, and in fact many have been challenged. For example, proof-of-stake has been offered as an alternative to proof-of-work to halt runaway costs and CO2 emissions of electricity wasted on mining. Meanwhile later designs such as Ethereum tailor their proof-of-work system explicitly to discourage ASIC mining, by reducing the advantage such custom hardware would have over vanilla hardware. Other researchers proposed discouraging mining by making it possible for the participant who solves the PoW puzzle to keep the reward, instead of having it automatically returned to the pool operator for distribution. One core developer even proposed (and later withdrew) a special-case adjustment to block difficulty for upcoming change to block rewards. It was motivated by the observation that many mining operations will become unprofitable when rewards are cut in half, powering off their rigs and resulting in a significant drop in total mining power that will remain uncorrected for a significant time as blocks are mined at a slower rate.

Some of these numbers reflect limitations or trade-offs necessitated by current infrastructure. For example, one can imagine a version of Bitcoin that runs twice as fast, generating blocks every 5 minutes instead of 10. But that version would require each node running the software to exchange data twice as fast among themselves, because Bitcoin relies on a peer-to-peer network for distributing transactions and mined blocks. This goes back to the same objection levied against large-block proposals such as XT and Classic. Many miners are based in countries with high-latency, low-bandwidth connections such as China, a situation not helped by economics that drive mining operations to locate to the middle of nowhere, close to cheap source of power such as dams, but away from fiber. There is a legitimate concern that if bandwidth requirements escalate- either because blocks sizes go up or alternatively because blocks are minted more frequently- they will not be able to keep up But what happens when those limitations go away, when multi-gigabit pipes are available to even the most remote locations and the majority of mining power is no longer constrained by networking?

Planning for change

Once we acknowledged that change is necessary, the question becomes how such changes are made. This is as much a question of governance as it is of technology. Who gets to make the decision? Who gets veto power? Does everyone have to agree? What happens to participants who are not on board with the new plan?

Systems can be limited because of a failure in either domain. Some protocols were designed with insufficient versioning and forwards-compatibility; that means it is very difficult for them to operate in a heterogeneous environment consisting of “old” and “new” versions existing side-by-side. That makes it very difficult to introduce upgrades, because everyone must coordinate on a “flag-day” to upgrade everything at once. In other cases, the design is flexible enough to allow small, local improvements, but the incentives for upgrading are absent. Perhaps the benefits for upgrade are not compelling enough or there is no single entity in charge of the system capable of forcing all participants to go along.

For example, credit-card networks have long been aware of the vulnerabilities associated with magnetic-stripe cards. Yet it has been a slow uphill battle to get issuing-banks to replace existing cards and especially merchants to upgrade their point-of-sale terminals to support EMV. Incidentally that is a relatively centralized system: card-networks such as Visa and MasterCard sit in the middle of every transaction, mediating the movement of funds from the bank that issued the credit-card to the merchant. Visa/MC call the shots around who gets to participate in this network and under what conditions, with some limits defined by regulatory watch-dogs worried about concentration in this space. In fact it was their considerable leverage over banks/merchants which allowed card networks to push for EMV upgrade in the US, by dangling economic incentives/penalties in front of both sides. Capitalizing on the climate of panic in the aftermath of Target data-breach, these networks were able to move forward with their upgrade objectives.

[continued in part II]

CP

Future-proofing software updates: Global Platform and lessons from FBiOS (part III)

[continued from part II]

(Full disclosure: this blogger worked on Google Wallet 2011-2013)

Caveats

Global Platform constrains the power of manufacturers and system operators to insert back-doors into a deployed system after the fact. But there are some caveats to cover before we jump to any conclusion about how that could have altered the dynamics of FBI/Apple skirmish. There are still some things that a rogue card-manager— or more precisely “someone who knows one of the issuer security-domain keys” in GP terminology, a role often outsourced to trusted third-parties after deployment— can try to subvert security policy. These are not universal attacks. Instead they depend on implementation details outside the scope of GP.

Card OS vulnerabilities

Global Platform is agnostic about what operating system is running on the hardware, and for that matter the isolation guarantees provided by the OS for restricting each application to its own space. If that isolation boundary is flawed and application A can steal or modify data owned by application B, there is room for the issuer to work around GP protections. While there is no way to directly tamper with the internal state of that application B, one can install a brand-new application B that exploits the weak isolation to steal private data from A. Luckily most modern card OSes in fact do provide isolation between mutually distrustful applications, along with limited facilities for interaction provided both sides opt-in to exchanging messages with another application. For example JavaCard-based systems apply standard JVM restrictions around access to memory, type-safety and automatic memory management.

Granted, implementation bugs in these mechanisms can be exploited to breach containment. For example early JavaCard implementations did not even implement the full-range of bytecode checks expected of a typical JVM. Instead they call for a trusted off-card verifier to weed out malformed byte-code prior to installing the application. This is a departure from the security guarantees provided by a standard desktop implementation of JVM. In theory the JVM can handle hostile byte-code by performing necessary static and run-time checks to maintain integrity of the sandbox. (In reality JVM implementations have been far from perfect in living up to that expectation.) The standard excuse for the much weaker guarantees in JavaCard goes back to hardware limitations. Performing these additional checks on-card adds to complexity of the JVM implementation which must run on the limited CPU/memory/storage environment of the card. The problem is, off-card verification is useless against a malicious issuer seeking to install deliberately malformed Java bytecode with the explicit goal of breaking out of the VM.

It’s worth pointing out that this is not a generic problem with card operating systems, but a specific case of cutting-corners in some versions of a common environment. Later generations of JavaCard OS have increasingly hardened their JVM and reduced dependence on off-card verification, to the point that at least some manufacturers claim installing applets with invalid byte-code will not permit breaking out of the JVM sandbox.

Global state shared between applications

Another pitfall is shared state across applications. For example, GP defines a card global PIN object that any application on the card can use for authenticating users. This makes sense from a usability perspective. It would be confusing if every application on the card had its own PIN and users have to remember whether they are authenticating to the SSH app vs GPG app for instance. But the downside of the global PIN is that applications installed with the right privilege can change it. That means a rogue issuer can install a malicious app designed to reset that PIN, undermining an existing application which relied on that PIN to distinguish authorized access.

There is a straight-forward mitigation for this: each application can instead use its own, private PIN object for authorization checks, at the expense of usability.  (Factoring out PIN checks into an independent application accessed via inter-process communication is not  trivial. A malicious issuer could replace that applet by a back-doored version that always returns “yes” in response to any submitted PIN, while keeping the same application identifier. Some type of authenticated channel is required.) In many scenarios this is already inevitable due to the limited semantics of the global PIN object, including mobile payments such as Apple Pay and Google Wallet which support multiple interfaces and retain PIN verification state during a reset of the card.

Hardware vulnerabilities

There is another way OS isolation can be defeated: by exploiting the underlying hardware. Some of these involve painstakingly going after the persistent storage, scraping data while the card is powered off and all software checks out of the picture. Others are more subtle, relying on fault-injection to trigger controlled errors in the implementation of security checks such as by using a focused laser-beam to induce bit flips. Interestingly enough, these exploits can be aided by installing new, colluding applications on the card designed to create a very specific condition (such as specific memory layout) susceptible to that fault. For example, this 2003 paper describes an attack involving Java byte-code deliberately crafted to take advantage of random bit-flip errors in memory. In other words, while issuer privileges do not directly translate into 0wning the device outright, they can facilitate exploitation of other vulnerabilities in hardware.

Defending against Apple-gone-rogue

Speaking of Apple, there is a corollary here for the FBiOS skirmish. Manufacturers, software vendors and cloud-service operators all present a clear danger to the safety of their own customers. These organizations can be unknowingly compromised by attackers interested in going after customer data; this is what happened to Google in 2009 when attackers connected to China breached the company. Or they can be compelled by law-enforcement as in the case of Apple, called on to attack their own customers.

“Secure enclave” despite the fancy name is home-brew proprietary technology from Apple without a proven track-record or anywhere near the level of adversarial security research aimed at smart-cards. While actual details of the exploit used by FBI to gain access to the phone are still unknown, one point remains beyond dispute: Apple could have complied with the order. Apple could have updated the software running in the secure enclave to weaken previously enforced security guarantees on any phone of that particular model. That was the whole reason this dispute went to court: Apple argued that the company is not required to deliver such an update, without ever challenging the FBI assertion that it was capable of doing that.

Global Platform mitigates against that scenario by offering a different model for managing multiple applications on a trusted execution environment. If disk-encryption and PIN verification were implemented in GP-compliant hardware, Apple would not face the dilemma of subverting that system after the fact. Nothing in Global Platform permits even the most-privileged “issuer” from arbitrarily taking control of an exiseting application already installed. Apple could even surrender card-manager keys for that particular device to the FBI and it would not help FBI defeat PIN verification, absent some other exploit against the card OS or hardware.

SE versus eSE

The strange part: there is already a Global Platform-compliant chip included in newer generation iPhones. It does not look like a “card.” That word evokes images plastic ID cards with specific dimensions and rounded corners, known by the standard ISO 7810 ID1.  While that may have been the predominant form-factor for secure execution environments when GP specifications emerged, these days such hardware comes in different shapes and incarnations. On mobile devices, it goes by the name embedded secure element—another “SE” that has no relationship to the proprietary Apple secure enclave. For all intents and purposes, eSE is the same type of hardware one would find on a chip & PIN enabled credit-card being issued by US banks today to improve security of payments. In fact mobile payments over NFC was the original driver for shipping phones equipped with an eSE, starting with Google Wallet. While Google Wallet (now Android Pay) later ditched eSE entirely, Apple picked up the same hardware infrastructure, even same manufacturer (NXP Semiconductors) for its own payments product.

The device at the heart of the FBI/Apple confrontation was an iPhone 5C, which lacks an eSE; Apple Pay is only supported on iPhone6 and later iterations. But even on these newer models, eSE hardware is not used for anything beyond payments. In other words, there is already hardware present to help deliver the result Apple is seeking— being in a position  where the company can not break into a device after the fact. But it sits on the sidelines. Will that change?

In fairness, Apple is not alone in under-utilizing the eSE. When this blogger worked on Google Wallet, general-purpose security applications of eSE were an obvious next step after mobile payments. For example, the original implementation of disk encryption in Android was susceptible to brute-force attacks. It used a key directly derived from a user-chosen PIN/password for encrypting the disk. (It did not help that the same PIN/password would be used for unlocking the screen all the time, all but guaranteeing that it had to be short.) Using eSE to verify the PIN and output a random key would greatly improve security, in the same way using TPM with PIN check improves the security of disk encryption compared to relying on user-chosen password directly.  But entrenched opposition from wireless carriers meant Android could not count on access to the eSE on any given device, much less a baseline of applications present on eSE. (Applications can be pre-installed or burnt into the ROM mask at the factory, but that would have involved waiting for a new generation of hardware to reach market.) In the end Google abandoned the secure element, settling instead for the much weaker TrustZone-backed solution for general purpose cryptography.

CP

Future-proofing software updates: Global Platform and lessons from FBiOS (part II)

[continued from part I]

Locked-down environments

Smart-cards as application platforms differ from ordinary consumer devices in one crucial way: they are locked down against the “user.” Unlike a PC or smart-phone which derives its value from its owner’s freedom to choose from a large ecosystem of applications, cards are optimized for security; the ability to run specific applications selected by the issuer with highest assurance level. While the operating system of modern cards is powerful enough to support multiple applications at once (and even have them running at the same time, although not in traditional multi-tasking fashion) it is not up to the user to decide which applications are installed.

Global Platform in a nutshell

Global Platform formalizes that notion by defining an access control model around card-management operations such as loading, running and uninstalling applications. It also defines a family of authentication protocols for appropriate entities to assert those privileges. At a high-level GP relies on the notion of security domains. Issuer security- domain or ISD is the most privileged one. In earlier versions of Global Platform only the issuer could install applications. Later iterations generalized this to allow for delegating such privileges to supplementary security-domains or SSDs.

In practice that means installing new apps requires authenticating to ISD, which in turn involves knowledge of a unique secret-key for each card. (As a historic note, when Global Platform was being developed, the types of hardware found in smart-cards were too anemic for public-key cryptography. This is why the standard is primarily based on symmetric-key primitives and often outdated ones at that, such as triple-DES. Recent updates to GP have been introducing public-key based variants to core protocols.) ISD keys or colloquially “card-manager keys” are tightly controlled by the organization distributing the hardware, or outsourced to a third-party specializing in card management at scale. With the exception of development samples, it is difficult to find hardware shipped with “default” keys known to the end-user.

This state of affairs can help simplify the security story; it’s difficult to subvert isolation between applications when you can’t install a malicious app to attack others in the first place. But it also complicates and distorts market dynamics around deployment. Google Wallet is an instructive example. The so called “embedded secure element” on Android devices happens to be GP-compliant smart-card hardware, permanently attached to the phone. It inspired an ugly skirmish between Google and wireless carriers over control of the issuer role. In fact GP has been struggling for years to expand this inflexible model and bootstrap a rich developer ecosystem where multiple vendors can coexist to offer applications on cards controlled by a different party.

But for our purposes, there is a more interesting security property of GP management model: even the all-powerful issuer role is greatly constrained in what it can do.

There is no “root” here

Here is a short list of what does not exist in Global Platform:

  • Reading out contents of card storage. All data associated with card applications is stored in permanent storage, which is traditionally EEPROM or flash-based in more recent devices. GP defines a specific set of structured information that can be retrieved from the card: list of applications installed, card unique ID etc. But there is no command to retrieve chunk of data from a specific EEPROM offset. There is not even a command to retrieve the executable code for an application after installation.
  • Making arbitrary modifications to card storage. Again GP defines specific structured operations that modify card contents (install new application, create a security domain, modify keys…) there is no provision in the protocol for writing arbitrary data at a specific offset.
  • Similar provisions apply to RAM. There is no equivalent to UNIX /dev/mem or /dev/kmem for freely reading and writing memory.
  • There are no debugging facilities for getting information about the internal state of card applications, much less “attaching a debugger” in the conventional sense to a running application to control its execution.

Future-proofing against malicious updates

These may be viewed as limitations on platform functionality, but looked another way they constitute an interesting defense against the “rogue issuer” threat. Suppose we have a card with a general-purpose encryption application already provisioned. This app is responsible for generating cryptographic keys within the secure card environment and leveraging them to unlock private user information (such as an encrypted disk) conditional on the user entering a correct PIN. Let’s posit that the card-issuer started out “honest:” they installed a legitimate copy of the application on the card when they first handed it over to the customer.

Later this issuer experiences a change of heart. Perhaps compelled by law enforcement or due to a change of business model, they now seek to undermine the security provided by the application and extract those secret keys without knowing the user PIN. If the platform in question is Global Platform compliant, they would be out-of-luck going through the standard mechanisms. There is no mechanism in Global Platform to scrape data associated with an application. Nor can the issuer selectively tamper with application logic, for example skipping the PIN check or sneaking in a new code path that causes the application to cough up secret keys. Whether or not the issuer is cooperating, they would have to find another avenue such as exploiting some weakness in the tamper-resistance of the hardware- expensive and time-consuming attack that have to be repeated for each device, as opposed to software attacks which scale with minimal effort to any number of devices.

There is no “update” either

A common question that comes up when threat-modelling rogue issuers is the question of software updates. That was the avenue FBI pursued with Apple: to update the operating system with a subverted version that allows unbounded number of incorrect PIN entries. Even if we grant the premise that GP does not allow the issuer to reach into the application state to read secrets or tamper with the code, why can’t issuer simply replace the legitimate application with a back-doored version designed to leak secrets or otherwise misbehave? Because Global Platform has no concept of “updating” an application. One can delete an application instance and launch a new one under the same ID, but that first step erases all data associated with that instance is also removed. For the chip & PIN example above, that means all of the private information associated with that credit-card is gone. It is not possible to replace only the code while retaining data.

That is why updating card applications in the field is rare, aside from the logistical challenges of delivering updates customized to each card from ISD. System that require “upgrading” in the conventional sense need to plan that out in advance by using a split design. Typically the functionality is split into two pieces: a very-small application holds secrets, cryptographic keys and internal state, while a much larger application contains business logic for leveraging that state. These two pieces communicate using a suitable IPC mechanism exposed by the environment (for example, JavaCard defines sharable-interface objects.) The second half can be “updated” by removing and reinstalling a new version, because it does not contain any state while the first half is not affected. Still any replacement is still bound by the same interface agreement between them. If the interface allows the business-logic app to request a message to be decrypted, the replacement app can invoke the same functionality. But it will not magically gain a new capability, such as asking the other application to spit out encryption keys.

That said, there are  limitations and edge-cases where having issuer privileges do grant an advantage in attacking a preexisting application, although far from guaranteeing success. These will be the topic of the next post.

[Continued: caveats & conclusion]

CP

Future-proofing software updates: Global Platform and lessons from FBiOS (part I)

It is no secret that software-update mechanisms controlled by vendors are also back-doors for delivering malicious payloads into a system. The recent FBiOS controversy raised awareness of this inconvenient fact beyond the security community, but it is far from being the first example when a service was effectively coerced into delivering malware to one of its own users. By far the most extreme and cavalier example of “software updating” is of course on the web: each time a user visits a website, the vendor has the option of delivering brand-new application code with JavaScript, Flash or any of the myriad other proprietary programming environments supported by web browsers. Hushmail was a “secure email” provider who learned this lesson the hard-way.

This raises the question of whether it is possible to design systems such that even the manufacturer can not deliver malicious updates after the fact. “After the fact” being the operative keyword- of course they always have the option of delivering a pre-compromised machine. So a more realistic line to hold is making sure if that a vendor that started out honest can not later changes its mind, regardless of reason. It could be that the vendor itself has gone rogue- the way SourceForge started injecting spyware into binaries after a “change of business model.” Perhaps the HR department hired a corrupt insider- more than a few developers were caught sneaking in Bitcoin mining software into their company applications. Or it could be the situation Apple faces: under a legal order to provide access to specific user data. Varied as the motivations are, from a security perspective they are equivalent. The question is properly framed as one of capability- can the vendor do this?- rather than one of intention (“we promise we would never do this to our users!”), political inclinations or creativity of legal department in pushing back against subpoenas.

From a technology perspective, this problem is non-trivial. Most systems have a “God mode” as part of their security design which gives  full control over the system. This role is exempt from the usual security checks that the system diligently applies to all actions. The answer to the access-control question “is this person allowed to read/write/modify this piece of data?” is an unqualified yes for that role. Unix has root, Windows has administrator. Over time changes to the operating system tried to limit the capabilities of these roles. For example 64-bit versions of Windows prevent even admin account from running arbitrary code in kernel-mode by requiring signed drivers. But admins with physical access can still override such restrictions. Meanwhile the introduction of software-update mechanisms introduced yet another cook into the kitchen: the operating system vendor. Taking the example of Windows, MSFT can remotely update operating system components including the kernel itself on modern versions of the OS. That was not always the case and users can still opt-out, but the history of Windows Update shows a very clear progression: what started out as a convenience feature for the minority of users who cared to pull updates morphed into a powerful large-scale distribution channel for pushing updates to everyone by default. Since MSFT can now silently update Windows with arbitrary code of its choice, it effectively has administrator access to all machines running recent versions of that OS. (Note that code-signing has no effect on this capability, although it creates a deterrent effect. Updates have to be signed but MSFT is capable of signing a malicious binary just as much as it is capable of signing a legitimate OS update intended for public consumption. But that signature provides compelling evidence of culpability if the system is later examined forensically.) In short, while modern OS designs attempt to tame old-school “root” account in the name of least-privilege, they have  introduced an even more powerful role with remote access. The situation is worse on mobile devices. Android does not give the user root access by default. You have to “root” your device, the equivalent of jail-breaking an iPhone, for earning that capability. Google on the other hand, retains the ability to push updates to the operating system running at root privilege. Power dynamics have been inverted: all-powerful remote entity, highly constrained local user.

To be clear, this notion of an anything-goes account exempt from usual access-control restrictions is very useful. Being able to tweak every knob and update every last component in the system is essential for improving functionality over time. Otherwise bugs could not be fixed and one would have to purchase brand new PC each time they ran into a critical bug deep in the operating system code itself. A platform shipped in permanently “fused” state stuck with its initial software and no ability to deliver future enhancements is a non-starter.* But when the OS itself is responsible for enforcing aspects of security policy— such as who gets to read data residing on an iPhone— unchecked update capability translates into an exemption from previously defined security restrictions.

So is there a middle-ground? The ideal design would allow delivering new functionality over time (so users are not stuck with the hardware as they purchased it on day one) minus the ability to use the update channel for subverting previously defined security policies. It’s easy to craft theoretical designs, but it is more instructive to look at deployed systems. It turns out that an architecture originally intended for managing smart-cards has exactly this characteristic. More surprisingly, the latest iPhone and some Android devices already include a separate piece of hardware called the embedded secure element which obeys that architecture. It’s called Global Platform.

[continued in part II]

CP

* Interestingly that describes the state of many Android devices, not for lack of an auto-update mechanism which certainly exists in Android, but inability/unwillingness of wireless carriers to leverage that channel for delivering updates.

Getting by without passwords: encrypted email

[Part of a series on getting by without passwords]

The final post in this series takes up the problem of securing email traffic without relying on the security of user-chosen passwords.  There are two aspects to protecting email:

  • Confidentiality: guaranteeing that only the intended recipients can read the contents of a message (Even when the message itself is transiting through untrusted networks, as email delivery is based on store-and-forward paradigm.)
  • Authenticity: for the recipient to be certain that an incoming message indeed originated with the purported sender.

Public-key cryptography is well suited to serving both of these objectives. At a high-level authenticity is provided by the sender digitally signing the message with their private-key, while confidentiality is assured by encrypting the message using the public-key of each recipient. But the devil is in the details, and over the years  many protocols/formats/standards have emerged around how exactly these operations are done, differing both in cosmetic ways- how the bits are laid out- and fundamental assumptions around key management. To keep the discussion tractable, we focus on two of the more popular formats in widespread use: S/MIME and PGP.

S/MIME and PGP

“The nice thing about standards is that you have so many to choose from.” — Andrew Tannenbaum

Not surprisingly there is more than one way to secure email, and each one has taken hold in different niche markets. PGP came first, S/MIME is the more enterprise-oriented format. Chronologically it arrived after PGP and was first codified by RFC 2633, building on formats. The differences between PGP and S/MIME can be grouped into two categories:

  • Superficial/cosmetic: PGP defines its own home-brew format for messages and keys. S/MIME uses the cryptographic message syntax (CMS) format for messages and X509 for carrying keys, which is in turn built on ASN1.
  • Philosophical/trust model: This is a more significant difference in approach to establishing trust in keys. Recall that sending an encrypted email to Alice requires having her public-key ahead of time. That boils down to the basic questions: where do you look up Alice’s public-key? When someone presents a key that purportedly belongs to Alice, how do you go about verifying that?
    S/MIME assumes a public-key infrastructure or PKI mediated by trusted third-parties. Everyone receives digital certificates from these parties and can verify other credentials by reference to the same. PGP relies on a more grass-roots web of trust, with users exchanging keys in person or leveraging social networks by trusting existing contacts to vouch for each other.

Easy case: S/MIME

Because S/MIME is associated with enterprise/managed IT scenarios- think Windows shop running an Exchange server in-house and users accessing their email via Outlook clients- there is already plenty of precedent for using smart-cards to protect email. Outlook itself has supported S/MIME for 15+ years and Windows cryptography architecture abstracts away key-management from applications. As far as the application is concerned, same code paths are executed to sign/decrypt when the private key resides on local-disk or when that key lives on a smart-card that must be invoked to perform the operation itself. The operating system and underlying layers take care of the difference: for example cryptographic hardware can appear/disappear based on user actions of connecting/disconnecting it, some cards may require a PIN to authorize user actions etc.

Hard case: PGP

To this day PGP decidedly remains an “enthusiast technology” (to put it politely) voluntarily used by individuals instead of mandated by enterprise IT settings. Because use of cryptographic hardware by consumers is exceedingly rare, PGP keys are almost always managed in software and migrated to new devices via awkward import/export mechanisms. But there was an attempt dating back to 2004 at standardizing support for hardware tokens with the OpenPGP card specification.

It sounds promising: while S/MIME is silent on low-level key management interface or exact behavior of cryptographic hardware to manager user keys, OpenPGP Card attempts to prescribe in exacting detail exactly how such devices shall operate and what features they must support.

In reality, that turns out to be a bad idea.

How to limit future options: pick a card-edge

With OpenPGP Card, the system has committed to low-level details of a card. It is not just expressing baseline requirements (such as “must support RSA up to 2048-bit keys”) or describing a high-level interface for invoking  functionality on the card. It prescribes low-level details about how the host and card communicate over the PC/SC interface as well as exact organization of data stored on card. Why is that too restrictive? For starters, let’s start with the concept of “card.”  While smart-cards and most USB tokens indeed go through PC/SC (after all it stands for “Personal-Computer-to-Smart-Card”) there are other types of cryptographic hardware such as HSMs or even TPM which are not “cards” as far as the operating-system is concerned.**

Even restricting our attention to cards, standardizing on the low-level interface to the card creates unnecessary incompatibility over superficial implementation details. By focusing on low-level wire protocol, GPG has limited itself to working with exactly one card application. Yet many standards have been introduced over the years for card-based applications: eID for electronic ID in the EU, CAC and later PIV for government employees in the US, GIDS for enterprise authentication, to name a handful. Many of them contain a superset of functionality required for PGP: generate key-pairs on board, perform private-key operations, store public-keys, use PIN for authorization etc. They exceed those requirements and improve on baseline by supporting  multiple key-sets and elliptic-curve algorithms not originally envisioned by OpenPGP. With the exception of GIDS, they are also far more popular compared to PGP cards, produced in higher-volume with multiple suppliers benefiting from economies of scales. Yet none of these are usable for PGP directly, because of cosmetic differences in how their functionality is packaged into low-level commands.

Compare this to how SSH authentication integrates cryptographic hardware. There is no such thing as “OpenSSH Card.” Instead the implementation uses an existing abstraction layer for cryptographic hardware, namely PKCS #11. Any vendor that manufactures cryptographic hardware with the right features can write a PKCS11 module to package those features into a standard interface and compete in the market for hardware-based SSH authentication. In practice they don’t even need to write that module, because volunteers have already solved that problem: OpenSC ships a module with support for an impressive variety of cards. Another open-source packages SimpleTPM-PK11 allows using the TPM for managing keys. On the proprietary side, HSM vendors such as Safenet and Thales ship their own PKCS11 module written in-house to work with their specific model. As a result SSH authentication for both client and server side can take advantage of a variety of hardware offerings. To pick two examples: this blog covered using PIV tokens for SSH, others explored leveraging the TPM.

Restoring the abstraction layer

Luckily there is a solution that allows bringing that diversity of hardware to PGP: gnupg-pkcs11. This project is dated and by all appearances unmaintained— generally a red-flag increasing the chances of incompatibility caused by software rot. (Hosting source-code on Sourceforge is another red-flag considering the company was found to tamper with binaries. Luckily packages are available in upstream repos for major distributions such as Ubuntu.)

gnupg-pkcs11 replaces the GPG smart-card deemon with a new implementation that makes no assumptions about the “card” but instead calls into an existing PKCS #11 module for cryptographic functionality. Specifying this module as well as which keys on the card to pick (since a “token” in PKCS #11 model can have multiple keys) is done with configuration files. This part can be tricky, so here is a walk through of steps outlined in the man page.

Configuration

1. Replacing the smart-card daemon

First step is instructing GnuPG to use a different smart-card agent and specifying the application to use when prompting for a PIN. These lines appear in gpg-agent.conf, typically located in “.gnupg” folder under the user home directory.

scdaemon-program /usr/bin/gnupg-pkcs11-scd
pinentry-program /usr/bin/pinentry-qt4

2. Configuring the new daemon

Next step is configuring gnupg-pkcs11-scd itself. This is best done in two stages because the file contains friendly key identifiers which are not available at this point. Easiest way to discover them is by asking gpg-agent, which in turn invokes the smart-card daemon. A minimal configuration file gnupg-pkcs11-scd.conf pointing at the PKCS #11 module is sufficient to bootstrap that process:

# List of providers
providers p1

# Provider attributes
provider-p1-library /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

With that in place we can query the card for key identifiers:

$ echo "SCD LEARN" |\
gpg-agent --server gpg-connect-agent |\
grep KEY-FRIEDNLY
S KEY-FRIEDNLY EB1391B66C49F44859D1CF81BB97882E32154A2B /C=US/ST=CA/L=\
San Francisco/O=Widgets Inc./OU=Randomization/CN=Cem Paya/emailA\
ddress=notcem@nothere.net on PIV_II (PIV Card Holder pin)

(Note the misspelling “friednly” [sic] for friendly identifier.)

The output contains the distinguished name from each certificate discovered on the card, along with SHA1 hash of the public-key highlighted in red above. In this example there is just one certificate present, although a PIV card will typically contain up to four active certificates. Now SHA1 hashes can be used to indicate which keys are used to secure email by adding another section to gnupg-pkcs11-scd.conf:

emulate-openpgp
openpgp-sign EB1391B66C49F44859D1CF81BB97882E32154A2B
openpgp-encr EB1391B66C49F44859D1CF81BB97882E32154A2B
openpgp-auth EB1391B66C49F44859D1CF81BB97882E32154A2B

This example is cutting corners by using the same key for signing and encryption which is suboptimal. A more realistic mapping would pick the PIV non-repudiation slot for signatures and PIV key-management slot for encryption.

3. Registering the keys with OpenGPG

The final step is making GPG aware of keys on the card. This involves going through the card-edit menu and invoking the “generate” option. The command name is misleading because new keys will not be generated on the card. (Similar to “ssh-keygen -D” retrieving existing keys from a hardware token, not generating new keys or otherwise altering state of the token.) Instead the replacement daemon returns existing public-keys on the card specified by SHA1 hashes above. GPG then combines those keys with additional information prompted from the user such as email address, expiration and proper name. In effect this step synthesizes “PGP keys” with their own meta-data out of existing key-pairs present on the hardware token.

Caveat: While the man page recommends disabling opengpg emulation after this step, in the experience of this blogger gnu-pkcs11 only works successfully in emulation mode.

User-experience

Putting it all together, here is sample of UX for private key operations.

Linux

Suppose we try signing a message from the command line:

echo "Hello world" | gpg2 -as

Assuming the token is connected, a system-modal dialog  appears:

Screen Shot 2016-02-21 at 08.34.55.png

Qt4 PIN collection prompt

If we instead specified pinentry-gtk-2 in the configuration file, that UI would look like:

Screen Shot 2016-02-21 at 08.42.26.png

GTK-2 PIN collection prompt

After entering PIN, the signature operation is performed by the hardware token. Remaining steps are identical to the flow for software keys- the signature is formatted by gpg and output to console.

OSX

Surprisingly gnupg-pkcs11-scd also runs on OSX. GPGTools is a user-friendly implementation of PGP (as judged by the low standards of open-source software) and provides keyboard shortcuts and context-menu for decrypting text highlighted in any application. For example, decrypting in a web browser can be initiated by selecting MacPGP from the Services menu:

Decrypt highlighted text in web mail

Decrypt highlighted text in web mail

That brings up a PIN collection UI slightly more polished than the Linux versions:

OSX MacPGP PIN collection UI

OSX MacPGP PIN collection UI

Handling multiple devices

Existing keys on the card need to be registered with PGP only once. In order to use the hardware token with another device, it is easier to “export the private-key” to a file, copy the file over and import it into the key-ring on the new machine. Export in quotes because in the case of hardware keys, there is no secret information being exported. Despite GPG dutifully prompting for a passphrase to encrypt sensitive data, the only relevant information written to file is a reference to the card serial number and key identifier. Private-keys never leave the hardware token itself. The resulting export file is not sensitive in the way actual private-keys would be, making the migration process straightforward.

CP

** While a TPM can be made to look like a smart-card (for example, using Windows virtual smart-cards) that involves an emulation layer, not sending raw APDUs to the TPM as if it were a CCID device.

Relics from the P2P file-sharing wars

This blogger was recently disconnected from a New York hotel  network with a cryptic error message:

P2P_false_positive.png

Nothing adds up here. p2pnetworking.exe? EXE extension indicates a Windows application—which is not the operating system running on the machine. Even more surprising was the reference to Kazaa (note the misspelling above,) which inspired a trip down memory lane.

The 2000s called; they want their file-sharing wars back.

After Napster

Kazaa was a popular peer-to-peer file sharing application which came to prominence as part of the second generation of P2P designs. It was Napster that kicked off the first-generation, putting MP3 and file-sharing in the limelight, exceeding 20M users at its peak. That success was short-lived. Napster became a lightning rod for litigation by a floundering recording industry, which found a convenient scapegoat for its declining revenue. (It would not be the first or last time that RIAA tilted at wind-mills.) Napster also had an intrinsic weakness: its design fell short of being truly 100% distributed. There was a point of centralization, a single-point-of-failure in Napster the company itself. While users downloaded files directly from each other, indexing and search of content was handled by servers operated by the corporate entity. That gave RIAA all leverage required in arguing that Napster can and should be held accountable for any infringing uses of its platform.

Future developers of file-sharing applications would not make that mistake again. First came Gnutella from the developers of WinAmp, which had been recently acquired by AOL. Its release lead to  awkward moments for the parent company, courting a merger with the content-rich Time Warner at the time. AOL tried putting the genie back in the bottle, but it was too late. Along came many more: Kazaa, Morpheus, eDonkey. These optimized the network topology by taking into account that not every user has the same bandwidth available. Instead of treating all nodes equally in democratic spirit, they deliberately capitalized on powerful machines on high-bandwidth connections, promoting them to “supernodes” responsible for coordination.

Users embraced the new generation of P2P applications— at least until the apps morphed into delivery vehicles for dubious adware and spyware bundled with the installers in some semblance of a business model. Network administrators on the other hand hated P2P with a vengeance because of the massive bandwidth consumption. At first it was colleges that started banning Napster. They claimed the prerogative of fairly distributing network capacity, although RIAA nastygrams no doubt also played a part in scaring the typically tech-illiterate and clueless administrations into policing their own student body. Later the crusade was taken up by ISPs on a much larger scale, with Comcast getting in trouble with FTC after it was caught manipulating BitTorrent traffic.

False positives

That brings us to this mysterious error message from the hotel network.

Kazaa has folded a long time ago. Its official client only ran on Windows. P2P moved on to third-generation designs best exemplified by BitTorrent. But somehow the network monitoring software used by this hotel retained the vestigial traces of the great War On File Sharing from early 2000s. Lying dormant all this time were heuristics on the watch for dreaded P2P traffic, ready to banish those users from the network for their transgressions. (That ban lasted approximately 24 hours in this case.)

As with all unmaintained software, these rules can go haywire when the world changes. It turns out that in this case the omniscient network monitor misidentified Google Hangouts video-conferencing for P2P file sharing. A quick search shows the offending traffic pattern cited in the error message— UDP traffic to port 19305— is among the documented ports associated with Hangouts application. Similarly a reverse DNS lookup for the destination IP points to “1e100.net” domain, which is a Google domain as expected.

Protecting users from themselves?

By itself a false-positive in a network monitoring application is not exactly news. Such heuristics are notoriously unreliable and subject to errors. For starters a given protocol is often implemented by multiple pieces of software written independently of each other. Some may be open-source, others proprietary, yet others “adware” supported by bundled applications. If they are implementing the protocol faithfully, they will look very similar to an external observer watching bits on the network. Just because a machine is emitting network packets that looks like the one emitted by Kazaa does not mean it is Kazaa running on that machine.

Putting aside that conceptual problem, what makes this example truly egregious is the alarmist language in the message and vindictive approach taken by the hotel against would be file-sharers. What is being achieved by singling out P2P applications? “Online activity flagged as malicious.” Malicious towards whom? Certainly not the owner of the laptop. If the hotel has taken on the paternalistic role of protecting customers from dubious software on their own device, where do we draw the line? Should they also start performing deep-packet inspection or blocking known malicious websites?

For that matter, the response after detecting P2P activity is disproportionate. If the network management system can identify file-sharing traffic (it obviously can not, but let’s grant the premise) why not specifically block those connections? Why retaliate by keeping users completely off the network for an extended period of time? Even if we grant the premise that hotels somehow owe it to their guests to protect them from their own malware- which, let’s be clear, file sharing software is not– quarantining the user completely does not further that objective. Redirecting users to a web page that explains risks involved or offers assistance with removing the offending malware is a more constructive approach.

Searching for a motive

Because the standard it’s-for-your-own-good excuse does not hold up to scrutiny, we need to look deeper for motives. There are two usual suspects.

“Network management”

This is a euphemism for allocating scarce bandwidth fairly between users with competing interests. This was the putative excuses colleges/universities initially offered for blocking Napster: with everyone downloading music, the application was consuming significant chunk of campus bandwidth. It is also the original excuse ISPs resorted to when explaining their throttling of BitTorrent. P2P was particularly embarrassing for ISPs because it revealed one of the worst-kept secrets of Internet service in the US: while an ISP may advertise 10Mbps speeds to subscribers for a given price, it does not have anywhere near the capacity to provide that speed to all subscribers at the same time. As long as few are maxing out their connection, customers may indeed attain speeds near that advertised upper-bound. But if everyone gets busy downloading music at once, no one gets close to seeing anything close to the effective bandwidth they were mislead to believe they were paying for.

A cafe or hotel providing wireless access to guests faces a similar problem of apportioning its outbound bandwidth, and here there is even less expectation of guaranteed service. Internet access is an incidental amenity not unlike a swimming pool; unlike an ISP selling broadband Internet, it is not the main line of business for the establishment. There is something to be said about fair allocation of scarce bandwidth and preventing one person from consuming a disproportionate share.

But such limits are by definition content-agnostic: a 5MB file occupies exact same number of bits whether it is downloaded off P2P network or streamed from iTunes. There is no justification for singling out a specific protocol, much less one specific application such as Kazaa for exclusion.

Contributory infringement

Avoiding legal headaches related to copyright infringement may be another  motivation to block file-sharing. This blogger is not a lawyer and will refrain from commenting on the creative theories of liability required to hold a hotel responsible for what guests download on the network.

Relics

There is another possibility of course: this “feature” of the hotel network is an ancient relic of a different era. In that less-enlightened time, organizations and businesses were cowed by RIAA/MPAA lawsuits into policing the activity of their own users, forking over for ineffective and blunt network management technologies to demonstrate their commitment to the higher cause of copyright enforcement. Times may have changed. Yet those “features” built into the network keep cropping up in unexpected ways.

CP

 

Scaling Bitcoin vs keeping-up-with-Visa

Continuing on theme of the previous post on Bitcoin scaling challenges, there is an implicit assumption driving the scaling controversy that requires a closer look. It is an article of faith that Bitcoin must scale by orders of magnitude process more transactions, and do so quickly. The benchmark for evaluating increased blocksize proposals (or features that effectively result in same outcome by shuffling bits around, such as segregated witness) remains one dimensional: the throughput of the network measured in transactions processed per second or TPS.

Given current limitations that metric peaks at a theoretical maximum of 7TPS although the jury is out on whether that upper bound can be attained in practice. This is often contrasted against the corresponding numbers for a standard payment network such as Visa. Statements published by Visa— attributed to a decidedly ancient 2010 IBM test—  put those figures at average of 150M per day with a maximum peak rate of 24000TPS.

Before questioning this “keeping-up-with-the-card-networks” mantra, it’s worth noting the paucity of attention paid to other statistics such as confirmation time. Imagine trying to buy coffee with Bitcoin. To be on the safe side, the merchant must wait for the transaction to appear on the Blockchain. Not just on the latest block freshly minted, but a few blocks deeper to rule out the possibility of being reversed by a rare reorganization event. Average 10 minute interval for mining blocks makes for an unpleasant retail experience. There are nascent proposals such as Lightning Network layered on top of the core Bitcoin protocol (as opposed to being modifications to the protocol) designed to facilitate near real-time settlement. They are far from seeing any traction. Meanwhile the 10 minute interval remains an inviolable constraint in the protocol.

Granted, this may not matter when buying coffee. Merchants can manage the risk from operating with zero-confirmation as long as the potential loss from the sale of that item is low-enough and the proportion of honest customers in the population high enough. It is similar to the risk-management decision Starbucks already makes when they swipe card  at checkout without demanding a signature from the card holder. That is a good idea. It keeps the line moving and customers caffeinated. Once in a while there is a stolen credit-card used or some customer disputes the charge. Starbucks is left holding the bag because they have no proof. A signed receipt could provide insurance by shifting liability to the issuer but those extra 20 seconds would translate into lost sales on a busy morning. Now multiply the dollar amounts involved by 100x, and waiting for the network to confirm the transaction starts to make more sense, just as merchants get more picky about receipts and checking ID for big-ticket purchases. (Not to mention that replace-by-fee proposal will make it much easier to double-spend unconfirmed transactions.)

Keeping up with the Visas

The narrative animating Bitcoin XT envisions a world with ubiquitous Bitcoin usage. Not only do consumers worldwide purchase their coffee at the corner store in cryptocurrency instead of swiping/inserting/tapping their credit-card, but they get to pay the rent, stream music online, access journalism behind a paywall, settle that debt to a friend who paid for dinner and wire money overseas to the cousin traveling in Timbuktu. In this expansive vision, it’s not only Visa and PayPal who are on the way to extinction. Check clearing and its automated cousin ACH, Federal Reserve Wire Network, the international SWIFT system, peer-to-peer payments such as Venmo, proprietary alternatives such as PayPal, Western Union etc. all face competition from Bitcoin eating into their market share. Naturally that one-network-to-rule-them-all must boast the combined capacity of all of the “deprecated” systems it replaces.

In case such a formidable list of incumbents being obsoleted at once has not already cast some doubts on the feasibility of this vision, let’s dive deeper into one scenario: replacing card networks. We can ask what incentives would drive mass-adoption of Bitcoin as an alternative to using payment cards. This can quickly become a complicated comparison with multiple categories: PIN-debit vs credit vs charge-card vs prepaid, retail vs online payments etc. Here we pick one representative case that today accounts for the bulk of such transactions by volume.

Case study: how (not) to disrupt in-store payments

There are multiple participants involved in a transaction when a consumer buys a TV  from a big-box retail store using their credit card: cardholder, merchant, payment network, issuing bank, not to mention all of the invisible middlemen behind the scenes facilitating that transaction such as the payment processor or the vendors who manufactured the point-of-sale terminal. [Quick refresher] In order to switch over to using Bitcoins, one or more parties must see a compelling benefit.

It’s certainly not the card network or the issuer. They would be out of the picture, disintermediated by an open system where anyone can pay anyone else without going through gate-keepers for access to the network. Despite initial forays into exploring crypto-currency, they have little to gain from watching their consumer credit business evaporate overnight. Issuing banks are already earning money hand over fist from interchange-fees and interest on balances carried by consumers.

Could it be the consumer? The privacy afforded by Bitcoin is not exactly much of a help when walking into a store dotted with surveillance cameras, or for that matter using a smart-phone that requires an Internet connection to broadcast the bitcoin transaction. It’s even worse when considering the economics. One can only spend existing funds with Bitcoin; a credit card allows deferring payments, to handle fluctuations in cash flow by carrying a balance. Worse, consumers receive an effective discount (albeit small one) from credit-card transactions. In the face of increasing competition, issuers are increasingly splitting their profits with customers in the form of airline miles, fungible points exchangeable for gifts or straight cash-back rewards. For a card averaging 1% rewards, paying for a $1000 TV in BTC amounts to leaving $10 on the table.

Merchant perspective

Merchants are the prime candidate to agitate for bitcoin. Frustrated by high card-processing fees, perennially on the lookout for cheaper alternatives (so much that several large US retailers banded together to create their own) they are seemingly the ideal cheerleaders for cryptocurrency. The economic pressure is particularly strong for segments with low profit margins: grocery-chains and large department stores often boast net profits in the single-digit percents. Forking over 2% of the gross sale for the privilege of accepting Visa/MC/Amex starts to sting. Irreversibility of Bitcoin transactions is another selling point. There is no longer the dreaded problems of charge-backs caused by fraudulent transactions. (That’s a bug from the consumer perspective: it is a safety feature to be able to call someone and complain when a card is stolen, and not be on the hook for unauthorized charges— or at least maintain that illusion of zero liability. But merchants greatly appreciate not having to worry about a sale getting reversed.)

Yet in-store payments are exactly the scenario where adoption is challenging because of the long settlement time, coupled with 0-confirmation being unsustainable long term. Let’s assume merchants will eat the cost of upgrading their point-of-sale equipment to accept Bitcoin. Realistically, they were far from enthusiastic about chip-and-PIN or NFC adoption, until card networks threatened a liability-shift pitting them against issuers, but in this case the lure of drastically lower processing fees could alter the equation. It would still require widespread adoption of Lightning or equivalent solution for instant settlement before that investment pays off. This would be much less of an issue for online purchases: given the additional lag involved in digging up the item out of a warehouse, packaging and shipping, an extra half-hour wait is noise. (But even that may change with the rise of same-day delivery and other services compressing the timeline from placing the order to a package showing up.) To wit, success stories of using Bitcoin at Sears/CVS/Home Depot turn out to be enabled by an intermediary exchanging Bitcoins for gift-cards, which are then processed by existing channels at the point-of-sale. Those merchants are not directly accepting Bitcoin; they do not have a Bitcoin address or operate a node on the network.**

Realistically, even highly motivated merchants can not unilaterally force consumers to adopt a new payment system. They can certainly express strong preferences towards minimizing transaction processing costs. They can nudge consumers in that direction, for example by setting minimum amounts for using cards. They can try passing on card fees to consumers or equivalently, offering discounts for cash- although that turns out to be so fraught with contractual issues that few venture there. They can lobby for structural changes behind the scenes: the Durbin amendment made it cheaper to process debit transactions. Some have even gotten into the open-loop card business by partnering with issuers, following the if-you-can’t-beat-them-join-them mantra. (That Costco-branded American Express card, which recently blew up in a very public spate between the two companies, let Costco share in revenue generated from cardholders while also reducing its own processing costs.) But at the end of the day, merchants must adopt to the existing payments ecosystem. As long as they conclude card-acceptance increases revenue by driving sales, they have an incentive to offer that option. In order for Bitcoin to become a viable alternative, there must exist a market segment of customers ready to spend Bitcoin and unable/unwilling to transact any other way. That critical mass does not exist at the moment, and it is far from clear that a demographic can emerge that simultaneously embraces Bitcoin while shunning mobile wallets such as Apple Pay or Android Pay, forcing merchants hand in having to cater to that preference.

Capitalizing on the unusual fee structure

The preceding issues reflect less on inherent flaws in Bitcoin than the current framing of scaling debate. The push for rapidly expanding block-size is predicated on the assumption that limited network capacity is holding back Bitcoin from achieving its manifest destiny of disrupting consumer payments. Build it and they will come, that argument goes. But the real question is not whether Bitcoin can compete with credit-cards in raw capacity, but whether it can compete on economical terms. For that matter, whether it needs to compete in order to be considered successful in its own right. Observe that wire-transfers move billions of dollars everyday, but no one has  penned an article announcing the demise of FedWire due to its inability to pay for coffee down the street. Payment systems have strengths and weaknesses. Even in its infancy, there are many applications where Bitcoin already outshines other alternative.

One theme uniting those scenario is fast and low-cost movement of funds. Writing a check does not incur any fees for either sender or recipient, but it is slow and requires physical shipment of pieces of paper. Wire transfers are real-time but come with hefty fees for individuals. Peer-to-peer systems such as Venmo and Google Wallet can move funds instantly at no-cost within the system, but they suffer from the problem of getting money into & out of the system; hefty credit-card fees are passed on to the consumer.

A  crucial special case of low-friction P2P transfers are cross-border remittances. If wiring money from one bank to another in the US sounds like an expensive proposition, imagine being a migrant worker trying to send money overseas to family. WorldBank tracks global remittances, and recently estimated an average ~7.5% fee globally. That estimate hides the true range of figures: trying to send $200 from Germany to China would incur a whopping 17% in fees. It’s not even a function of geography- France and Algeria are close but the average fee is 15%. Bitcoin vastly undercuts these expensive channels, translating into billions of dollars saved.

A core developer recently raised the alarm about Bitcoin development increasingly focusing on settlement scenarios instead of direct payments. There is a good reason for that bias: it plays to existing strengths of the design. Bitcoin is one of the most efficient ways of moving large sums around. Fees are charged per byte of the transaction. That is a very unusual metric because it is independent of the value moved. Under this regime a transaction moving a million dollars may pay less in fees than one moving a few dollars. By contrast most systems charge fees ad valorem. For credit cards those rates can hover around 2-3%. Even the Durbin amendment capping fees on PIN-debit set those limits as fixed cost plus 0.05% of the amount, retaining the proportionality feature. Bitcoin is unique in decoupling fees from the utility of the transaction as measured in the amount changing hands. It’s as if a bank decided to charge for check-cashing not based on the face value of that check, but on the thickness of paper used.

All of these applications still require Bitcoin to continue scaling up its throughput. Key difference is that the throughput targets are much lower than required for playing catch-up to Visa/MasterCard/Amex. Nor do these changes need to happen on an aggressive schedule, playing a game-of-chicken with hard forks. These markets are emerging gradually, with adoption driven organically because Bitcoin is a compelling  improvement over existing alternatives. No one will give up on Bitcoin because their transfer did not settle faster than Western Union or charged a few more Satoshis in network fees.

CP

** Ironically the intermediary eGiftCards itself uses yet another intermediary (Coinbase) for processing the Bitcoin transaction, and never directly taking on the risk of double-spending or currency volatility of BTC/USD. So much for direct peer-to-peer payments.