‘Scrambled X’: a scheme to thwart government surveillance of sensitive online payments

o-ONLINE-PRIVACY-facebookIn the final of a two-part series, Simon Davies outlines a scheme that could bring an end to government snooping on sensitive online transactions, including financial support for political and human rights campaigns.

In the first part of this series I outlined a common security gap for companies that offer secure products and services. Specifically, the card payment gateway used to subscribe to these services is the weak link – even for the most impressive secure platforms.

In summary, my concern is that the card payment stage is vulnerable to broadly framed access requests, so it’s quite likely that government has full access to the identities, bank details and addresses of, for example, nearly all Silent Circle customers. This will be equally true of many subscription services for secure products and indeed any online activity that government might regard as troublesome. Any claim to strong end-to-end security is a little glib unless suppliers can find a way to crack this weak-spot.

My chief concern lies with users outside Europe and North America who live under dangerous and intolerant regimes where the use of such technology can lead to sometimes fatal action by the State.

The potential for government to access such purchase data from these payment gateways has relevance way beyond the supply of sensitive security products such as Silent Circle.

The potential for government to access such purchase data from these payment gateways has relevance way beyond the supply of sensitive security products such as Silent Circle. Donations to organisations such as Wikileaks, contributions to civil and political rights defenders, purchase of trades union and political party membership and – in particular – payments made to and from people living in non-democratic parts of the world all need protection from agencies that would seek to identify who made payment for what.

Banks and merchant providers don’t have the most celebrated history of transparency when it comes to their relationship with government. We’re only just now starting to learn about the scale of government capture of financial transaction records, but enough is known anecdotally to indicate a huge and ongoing data grab by agencies.

The possible solution that I’ve been working on – which for the moment I’m calling ‘Scrambled X‘ – can best be described as a federated payment model. Elements of this idea are already in existence. But before setting out the scheme in more detail, I need to be clear on three points. First, this paper is relevant only to government access to payer identities, addresses, payments and bank details. If you believe government access to this information is not an important privacy and security issue, this paper is probably not relevant to you.

Second, this is a concept paper only; it’s not a proof of concept. Nor is it a technical paper. At this stage I just want to test the waters on an overall idea to see if others have trodden this path before and how they addressed the various challenges.

Finally, it goes without saying that this concept doesn’t in any way offer an infallible barrier to government interception of financial payments and identities. Its purpose is to complicate the payment ecosystem to such an extent that such snooping becomes either onerous or legally untenable.

The typical payment model for online services

To use most subscription services, you must pay online for a package. This is the case for nearly all commercial products that don’t offer a “free” basic service requiring simple email verification. Instead, users must proceed through a payment gateway (or Merchant Account Provider). These are typically third party sites that process the card payment as a sort of virtual ATM. Screenshot (187)

Any organisation such as Silent Circle using a payment gateway will invariably be issued with a Merchant Number or similar code that identifies the payee so a path can be established and the funds directed to the right destination. The customer is linked to the supplying company. The more focused the activity of the company, the greater the certainty that a snooping agency will know what a customer has bought (if it isn’t already identified in the transaction data, which it usually is).

In this conventional payment model the merchant provider has a record of precisely who is subscribing to a privacy or security product – their full name, bank details and address. Because web merchants are part of the banking food chain, they are bound to financial regulations that require the data to be stored – sometimes for years. Even if the vendor promises a zero-data policy, the customer identity and payment information will be available on the third party site.

The challenge

The aim of any privacy-centred payment alternative will be to put as much distance as possible between the customer and the payment gateway. As outlined in the first part of this paper, initiatives such as Silent Circle’s Ronin Card offer a partial solution, even if it’s impractical for many customers.

Screenshot (190)While a person enabling a service through a purchased Ronan code can be reasonably certain of anonymity (if an email address is not entered) the person making the initial purchase of that code will be fully identifiable by the payment gateway.

Supplier companies such as Silent Circle should thus strive to avoid mainstream payment gateways that rely on the major credit and debit cards. But this is easier said than done. Stored value (pre-paid) cards are used in abundance, but they don’t function on a single standard and are of limited value to a global online provider. Systems such as Bitcoin have real potential, but – for many vendors and consumers – they are viewed (often incorrectly) as arcane and clunky.

There is a second, very important, commercial consideration. A very high proportion of online transactions use credit cards. To rely on a pre-paid solutions cuts companies out of a big part of the market.

Top-level view of a possible solution

Scrambled X‘ relies on variants of secure code for its integrity, but also requires two key “tangible” components that will be explained in detail later:

  1. A federated product and services site (perhaps best imagined as a “family” of suppliers) that contains not just sensitive security providers and rights defenders, but also a large number of merchants of general goods and services ranging from clothing to image licencing. Each vendor is able to conduct secure communications with the others. The core idea of this system is to create a product pool that disguises precisely which purchase has been made. Thus each site in the federation can be a proxy purchase point for any other site. There are some liability issues here under consumer law that need to be addressed.
  1. An entity that ensures payment architecture is strong and stable and that transactions are paid to the relevant vendors. This “Authority” also conducts oversight to ensure that merchants in the federation are legitimate and is responsible for a single merchant account for all vendors in the federation. This enables a payment gateway that all sellers can use. While this Authority exercises human oversight, it should not be assumed that there’s a need for centralization. The technology should be as decentralized as possible.

The best way to imagine the new process is as a sort of “product steganography” in which a single transaction for a sensitive service is hidden within a much larger environment of product purchases among many suppliers.

Building the federated merchant site involves an element of crowdsourcing, in which individual sellers and general merchants who care about privacy join the system. Thus it’s possible to encompass many hundreds or even many thousands of sellers, within which there is a smaller population of sensitive products and services.

To understand how this system operates, let’s imagine a company called Privacy Panther that seeks to sell high grade communications security software and which wants to protect its customers from identification by law enforcement at the payment stage. The process may follow this path:

  1. A customer wishing to purchase Privacy Panther visits the company’s site, identifies the desired product and then executes the “buy now” option. In normal events this action would direct the customer to a third party payment gateway and would be directly identifiable. Instead, on receiving the purchase request, the Privacy Panther site generates a product purchase code, securely identifies a conventional product of an identical or near-identical value and then initiates an encrypted channel to divert the customer – and the product purchase code – to the relevant alternative product. Thus, a customer wishing to purchase a security product for $12.99 may end up on a clothing site selling a t-shirt for $12.99. Needless to say, customers are made aware in advance of this process.
  1. Having arrived on the clothing site, the customer initiates payment for the “t-shirt” and only at this stage is directed to the third party payment gateway. The gateway processes this payment, which goes into a single merchant account operated by the federation’s Authority. Thus all payments for any item feed through the same gateway and arrive in the same merchant account. The only information known about the customer is that she has purchased an item, among many thousands of items, for $12.99.
  1. Once the payment for the “t-shirt” has been made, the gateway generates a payment authorization code which is transmitted – along with the encrypted product code – to the federation merchant (the Authority). This encrypted product code is the only link that exists between the customer and the actual product that has been purchased. The Authority can identify through this code which payments are due to which merchants and will make a periodic batch payment to those merchants without having to identify individual customers.

This is, as I indicated earlier, only a top level view of the system. Just how secure channels and messaging can be designed is a challenge in itself, but the key initial question is whether a model such as this has the potential to frustrate security and law enforcement access to customer payment and subscription data.