Sunday, September 28, 2014

The Coming Digital Currency Future

For digital currency on a personal electronic device (PED) to find widespread worldwide acceptance it must meet, at a minimum, the following requirements:

  • Invulnerability to theft.
  • Anonymous use (with allowances for law enforcement)
  • Easy and real time conversion to non-digital currency
  • Legal protection

Invulnerability to theft may seem to be unattainable, however if sufficient business processes exist, theft can become so hazardous to the perpetrators, that it simply will not be worth the attempt. Simple features such as user authentication function accepting two personal identification numbers, one for regular access to the stored value, and one that broadcasts a robbery is in progress. Payment applications revoke the user signature if the payee does not receive a transaction within a configurable period. Insurers restore funds (OK insurers will still be vulnerable to theft, but they are insurers, they will make more than they lose or will not be in the business) in a rare case of a successful attack (an attack is only successful if the attacker converts the digital funds to regular currency). Regular synchronization of the payment log with the insurer will limit friendly fraud and losses due to damaged or lost PED.

The possibility of anonymous use will attract the paying public away from card technology and will become a great draw for widespread acceptance of digital currency. All transferred values will require the signature of the payee, but the insurer and/or the FI that issued the value to the PED only need to know the real identity of the signer.

A typical payment application might give users a menu shown in Diagram 28.

Diagram 28 A Sample Menu for PED Digital Currency Application

Shoulder surfers might see the log displayed in Diagram 29 or exactly what the user intends.

Diagram 29 Example Payment Log

Secure, fast, and cheap means widespread acceptance by PED users. Unlimited deposited funds for unlimited time will attract the first issuers followed rapidly by their competitors. It cannot happen fast enough what with the flat footed response by payment industry to data scraping attacks and the loss of revenue by capped interchange fees. Will the last retailer using a point of sale, please turn out the lights.

Next Blog: A timed embezzlement attack

Friday, September 26, 2014

Consequences of Digital Currency

In theory any entity can issue a digital currency but practically only a financial institution (FI) has the trust of the public at large to issue wholesale stored value to personal electronic devices (PED). However once issued, there is nothing preventing the purchaser of digital currency from reissuing it, and that dear reader(s) will attract the attention of smugglers, terrorist groups, legitimate commercial sectors, and financial crime investigators.   

FI can know their customers quite well, but will never know the difference between a reissuance and a legitimate purchase, especially if digital currency freely circulates for years or decades without returning to the issuing FI. If the security for stored monetary value makes successful conventional attacks too expensive then the values stored on PED will increase dramatically; people will think nothing of purchasing houses, cars, or jumbo passenger jets with currency stored on their PED.

I can read your thoughts dear reader(s); I am channeling “Farfetched”, “impossible”, or “not in this century”. Yet we already see the demand for the semi-anonymous bitcoin, regardless of its fatal flaws. Consider stored values with associated currency able for exchange or validation instantly. FI or digital currency insurers can add multiple features to data associated with the value stored on PEDs. Customers will demand anonymous transfers or interest payments and FI will respond if not constrained by regulators.

The initiation of secure and speedy movement of large values by PED may make gross real time payment systems obsolete and central banks as relevant as buggy whips in the near future. After all why let FI know the destination of your payments if it is not required. Why would FI need a discount window or to tie up funds in reserves if people purchase digital currency and never redeem it until the accrued interest has increased the purchased value exponentially?

Next Blog: The importance of digital currency logs

Wednesday, September 24, 2014

Evolution of Stored Value on a Personal Electronic Device

Circulation of digital money using personal electronic devices (PED)  must be reliable and secure for widespread acceptance. Vulnerabilities existing in current electronic payment systems remain with digital money, however the methods to exploit the risks change. Vulnerabilities include:

  • Issuance to a counterfeit PED
  • Unauthorized issuance
  • Intercept and capture of issuance to a legitimate PED
  • Surreptitious or unauthorized transfer from a PED to another device  
  • Payment to a counterfeit payee
  • Intercept and capture of payment to a payee
  • Intercept and capture of payee redemption
  • Capture by use of force
  • Friendly Fraud

Mitigation of these vulnerabilities requires careful design of the end-to-end solution. The solution requires the use of public key interchange (PKI) (or similar method to create a non-reputable issued or transferred value). There must be a method to determine the history of legitimate transfer of value from one point to another with the understanding that the circulation of the digital value does not require redemption at the issuer within any time limit. The PED transfer and receive functions must detect attacking agents and have the capability to evolve easily as attacking agents mutate.

Manufacturers must design PEDs better to mitigate the vulnerabilities of digital money. Certainly the use of biometrics to validate users has helped the situation but the capability of PEDs to detect and prevent attacks remains abysmal. PEDs must have situational knowledge when transferring digital currency and that requires allowing only code registered with the payment application to execute during vulnerable processing cycles. 

As manufacturers, financial institutions, and others involved in the payment services industry tighten their security posture the ease, cost effectiveness, and ubiquity of digital currency tied to a value in an account will increase to the point that payment cards and the infrastructure that supports them will go the way of all things.

Next Blog: Digital Currencies and Underground Economies

Tuesday, September 23, 2014

Storing Value on Personal Electronic Devices; Push Pay Nirvana

It is just a matter of time before people start storing monetary value on their personal electronic devices (PED); cooperative solution of a few architectural problems solution remains the only obstacle. Some of those problems include:

  • Lost, damaged, or stolen (LDS) PEDs
  • Foreign exchange
  • Standard data protocols
  • Communication Network availability

People solved these problems more or less with pull payment architecture and provided a common (and somewhat shaky environment) for payers and payees alike. A push architecture (moving value directly from payer to payee, not a payee requesting payment from the payer) requires less messages and less time, and so is inherently more secure. Storing value on a PED eliminates the need for payment networks and if designed correctly eliminates the need for any network if payer and payee share the same physical space.

Tying the value to the holder of the value mitigates the LDS threat. Foreign exchange occurs when the value arrives at a financial institution (FI). However getting makers of PEDS and network providers to cooperate and develop a data standard is harder than herding cats. Perhaps we do not need such a standard.  One FI will issue electronic value to its customers and the storage of that data on the device will become a de facto standard much as the VISA 1 standards evolved from the early attempts to negotiate a line and send a payment message.

If people share the same space then use of USB ports solves the problem of network availability. The problem of converting the ownership of value from payer to payee in a secure manner remains a delicate problem, however there are enough smart engineers out there to do it well. The German Geldkarte solves most of these problems; I wonder if the world will shake if Geldkarte move their solution from smart card to PED.

Next Blog: Payment Traffic Jams

Monday, September 22, 2014

If State Governments Build a Bum’s Pocket for Pot Purchases, Would the Feds Bust ‘em?

Twenty one States and DC have some form of legal marijuana distribution. Two more have imitative on the 2014 ballot. Yet the Federal Government continues to force consumers and businesses to pay for pot with cash. Financial Institutions (FI) do not want to get involved in business that may force their permanent closure and have their principals banned from the financial services industry forever. Governments, with a theoretical purpose of protecting citizens, instead put them at risk by forcing them to carry and keep large volumes of cash. It’s really time for State Governments to pool their resources, build a jointly held bum’s pocket for any retailer to join, and move marijuana industry money safely and efficiently. If the States adopt some of the features that I described in an earlier blog (see ) then states can protect their citizens and create a continuous daily stream of tax money that the businesses will no longer need to collect and pay.  

I understand the reluctance to attempt the push payment architecture of the bum’s pocket, but all state governments already have a ubiquitous payment system using a pull design for consumer redemption at retailer locations. All States have electronic benefit transfer (EBT) used to efficiently allow citizens to access their cash from many different types of government programs such as SNAP (nee food stamps), or child support funds. It would be simple to add a pot program to allow consumers to fund the account and retailers to accept the EBT card. Consumers can walk into any grocery store or retail location that accepts EBT cards, and fund accounts with a return transaction. The entire infrastructure already exists!

The account aggregation occurs at the State treasury level. Since the State treasuries actually move the money into the retailer accounts, they act as the FI. If the Feds want to stop it, they would have the Hobson’s choice of taking action against the State government or its EBT contractor. Either way, the 22 point headlines will scream something like “Black Booted Federal Thugs block Food Funds destined for Poor Children”. The public outcry might accelerate the movement to repeal Federal marijuana laws once and for all.

I ask the States that allow legal distribution of marijuana, do you want to protect your citizens or let them operate with the Federal Sword of Damocles dangling over their heads? What happens if citizens pass a referendum that requires EBT systems to support pot purchases? That is a case to make Supreme Court justices queasy and the DEA and FINCEN despair.

Next Blog: Unnatural Payment System Evolution

Sunday, September 21, 2014

Is an Escrow System Cheaper than Charge Backs

Trust is tough when payer and payee never meet physically. When any part of a transaction fails costs mount and recriminations fly. If the concept of a small value gross real time payment system succeeds it will need a mechanism other than Reg E or charge backs to cure a failed transaction.

So the bum’s pocket (small value gross real time payment system designed earlier in this blog) requires a method to protect both sides of a transaction. I envisage different solutions when the world eliminates charge backs. There might be healthy competition between shippers and financial institutions (FI). 

Shippers may offer a service similar to collection on delivery except collection occurs before shipment. In this scenario the payer pays shipper; shipper picks up and delivers goods; payer accepts shipment; shipper pays payee (keeping shipping fees).If the payer or payee disputes the transaction then the shipper picks up the goods and returns them to the payee and refunds the payer(subtracting more fees).

Another alternate solution dictates the design of the data protocol for a command to pay message. The message must allow for multiple payees. In that way a FI can offer standard escrow services. The payer directs the bum’s pocket to credit a shipper and an escrow account owned by the FI.  The FI moves the funds to the payee after notification of receipt by the payer or the passage of time. In the case of a dispute the FI holds the funds until payer and payee resolve it and both parties notify the FI they resolved the dispute. 

The question arises what costs more, routine multiple transactions, or charge backs. It seems to me that the former is more cost effective, but without any data or actual firms providing these services it is at best a haphazard guess. Certainly the passage of time allows for interest charges which allows the intermediary payee a chance for income without charging either the payer or payee.

However the payment system evolves, payees likely will be happier, and payers will not see much difference unless they intend to defraud their payees.

Next Blog: A discussion on current methods for foreign exchange transactions

Friday, September 19, 2014

Payment System Architecture for the Colorado Pot Industry

The Colorado (CO) pot industry suffers from the war on drugs; the industry requires a payment system architecture that cannot use common settlement procedures available to all other commercial enterprises. Headline: Government Hypocrisy Makes Payment Architects Drool (excuse the puddle).

CO needs a bum’s pocket (small value gross real time payment system) for its pot industry, and I thought I would sketch out a design.  

Step 1: Assign a public account number to all payees. The number only allows credits to the account, no debits.

Step 2: Give payers a private number associated with a funded account. The funded account might be the same account as the public payee account, just assigned a separate number.

Step 3: Write a clearing application, which receives a message from the payer to move funds to a payee; moves the funds electronically; notifies the payer and payee of the results.

Step 4: Create a club of merchants and their customers. The club’s business is to serve its members but not participate directly in the marijuana trade. When members deposit money to their accounts the club pools all the money in a financial institution account but keeps track of money with normal accounting methods.

Payers will fund their accounts using the regular payment system infrastructure. Payers then go to any establishment connected to the Bum’s pocket. Retailers of all kinds should be able to join this new merchant payment hub. The payer initiates a payment to by using the publically accessible payee account number as a destination for the funds already in their account. The club’s clearing system moves the money to the correct account. Whenever a member wishes to cash out, the club deposits their money in a bank account if the member is fortunate enough to have one or pay cash otherwise.

It may be hard to convince a financial institution to create a bank account for the club. However since the money deposited at the club comes from private citizens and not marijuana businesses it should not be denied access to banking services. I encourage any reader with legal training to comment on whether this payment hub runs afoul of the bank blab everything act.

Next Blog: A clearing house for barter services

Wednesday, September 17, 2014

Repeal the Bank Blab Everything Act

The war on drugs now the war on terror has become a war on banks, needlessly, causing great harm to the country. The intrusive nose of government only serves to have legitimate financial activity flee the US because a group of analysts at FinCen scrutinize every wee dime and can deduce future activity, which people want to keep secret for legitimate purposes.

There are plenty of ways government can monitor the aggregate movement of money in small and large value payment systems; and present a court of law a probable cause warrant to get details of particular financial activity; without having to watch everyone’s financial activity every second.
This 70’s relic of a law symbolizes the surrender of  people’s liberties to the right wing cause that government dictate citizen behavior conform to an obtuse concept of morality based on 17th century religious ideals. How much of our payment infrastructure flees every day to unregulated, unsafe, and untaxed methods because of this constitutionally suspect practice? 

We cannot fulfill the dream of a cashless society without people initiating their transactions with anonymity. We see the routine avoidance of government detection methods for two reasons, movement of funds to and from underground payment hubs, and preventing people other than government from seeing financial activity. How many FinCen investigations turned up adulterers, closet drinkers, compulsive gamblers, small cash businesses, and other harmless souls not requiring investigation by the Federal Government? It’s odd, but I see no data on the investigation of false positives and yet that is a critical number to determine the effectiveness of any payment hub detection activity. More to the point, how many money launderers no longer use US banks?

If banks did not spend the money needed to comply to this ridiculous intrusive nanny requirement perhaps they could use those funds to bolster their current payment architectures and stop relying on other companies to perform what used to be one of their primary functions, efficient cost effective funds movement.

Next Blog: Welding a push payment architecture to a bum’s pocket

Monday, September 15, 2014

An Open Letter to the ETSI, TIA, the Fed, BIS, and the ECB

I write this open letter to the European Telecommunications Standards Institute (ETSI), Telecommunications Industry Association (TIA), the United States Federal Reserve Bank (the Fed), the Bank for International Settlements (BIS), and the European Central Bank (ECB) to propose that you folks get together and create a tagged base data standard (like ISO 20022) for transportation of payment data to financial institutions (FI) from personal electronic devices (PED). 

It’s important the standard be flexible (allow many different types of encryption methods for example) and yet transport the minimum data to enable a push of funds from the payer account to the payee(s) account. If large respected institutions create an open standard that meet requirements for payments at least for the group of 20, then manufacturers can produce personal electronic devices containing acceptable applications that push funds to payees.

If on the other hand, manufacturers create their own specifications, large individual firms will produce proprietary schemes that lock out competitors and create a Tower of Babel for a vital communication network. Further a standard specification creates a minimum security posture for the initiation of payment pushes giving confidence that devices will not be lax creating a minimally acceptable effort to protect payer funds.  

It is in the best interest of financial institutions that have regulations in place to protect the public in a reasonable and unobtrusive way to specify a safe method to initiate payment instructions and receive notification of results. Further the current retail payment architecture creates monopolistic practices with banks and network providers setting fees as a single entity rather than competing by offering various fee structures to the purchasing public.

It should not take long to create an adequate specification with the right technical people sitting in a room with a strong financial interest to build a new small value payment infrastructure. The work I predict will take less than a year because most of the critical elements are part of current financial data standards. Some needs based architectures require redemption of goods by description of the goods and not of the value of goods and your new protocol needs to support this practice. 

I know there will be lobbyists and politicians in Gucci suits representing well-heeled constituents screaming that institutions such as you should not dictate protocols for good capitalists. I note that standards are not regulations, more like guidelines, and only provide a common language and not necessarily a regulated methodology.  Allowing innovation is good for all including people in jeans and a tee shirt, like me.

Thank you for your consideration of this request.


Ed Oppenheimer

Sunday, September 14, 2014

Pricing the Push Model; Putting Apple Pay into Obsolescence; Same Thing

The push model (payer directs financial institution (FI) to pay; payee does not request payment) has many price options which make income from interchange fees look like the punk change its fast becoming.  As governments move to cap interchange fees (the MasterCard decision in Europe and the Durbin Amendment in the US) FI incentive to create a new billing structure that cuts out the transportation middle men and keeps most fees in-house increases. The Push model will do just that.

If payees have a common registry which FI access to route push payments then payer (nee Issuer) FI charge consumers various types of fees consistent with transaction volume and value. Since Regulation E does not apply (Reg E forbids payer liability for pulled payments) FI can charge payers for insurance for unauthorized transactions, or charge a set fee for a capped number of transactions over a set time period.

Consider each FI account world wide as a potential retailer number. Compare that number with strictly retail accounts receiving payments from payment card activity. Since the retailer subset is clearly quite less than the complete set of all accounts, the potential fee payer pool is quite less and therefore cannot dilute fees in a reasonable manner. The push model changes the number of fee payers to all with any kind of FI account and so the fees can be significantly less and still increase FI income considerably. FI also remove themselves from the clutches of anti-trust warriors because they will compete for accounts by changing the fee structure for various types of customers.

Retailers themselves without the overhead of payment origination infrastructure may offer to pay some or all of consumer fees to attract bargain hunters. If a common standard exists for a data protocol (tailored ISO 20022 anyone) from personal electronic devices (PED) to FI then a total amount can be diverted to various parties including fee payees and tax authorities. Signs at the checkout lanes may offer discounts for specific payer FIs because of deals struck by regional, national, or local FI.

In short retailers will stop accepting payment cards because of the expense and the race to get payer money by striking deals with large and small FI going after various segments of the payer business. Apple Pay will be obsolete in a few years and EMV compared unfavorably to the beta max video model.

Next Blog: Payment Homeomorphisms

Saturday, September 13, 2014

Will an Iphone Competitor Offer a Push Transaction and Eat Apple’s Lunch

In a recent review ( see )  of the Iphone payment application, I noted it offered a reasonable risk posture (surmised from a conjecture of the payment architecture, not knowledge of the payment architecture) for the time being but open to a variety of attacks likely to occur when data scraping attacks meet tough new defenses. The conjecture of the Iphone architecture came partly from various descriptions I picked up from surfing the net ( see for example Ian Kar excellent post  or ) and partly from techniques I have discussed on this blog (see for example ). 

With the implementation of a token (finally eliminating a personal account number (PAN) in a transaction when the card is not present) and taking the validation of the user out of the authorization process the application meets some of my criteria for a secure payment method. However, the payment method does not accomplish a payment push to a payee and still needs an acquirer to route its transaction in a conventional way.

Personal electronic device (PED) manufacturers and their software developers will likely notice these glaring holes and see the value of transmitting payment data directly to the payer’s financial institution (FI). For this to work payees must exist in a data store that allows the payer’s FI to route the payment correctly and instantly notify the payee and payer that funds are en route. The account numbers associated with the payee must be one way only and not allow a transaction push or pull to originate from the same number. Such a convention allows banks to assign potential payees a publically accessible number without any risk to the funds in the associated account. The equivalent of a bank routing number embedded in the identifying number will eliminate duplicates by competing financial institutions.

Best of all, the merchants will not need to pay an acquirer, Reg E. will not apply, and attackers will only have small windows for a man in the middle or lunch room type of attacks against the payer only; data scraping will be useless. Those pluses will spur PED developers to create the next payment super application. 

Next Blog: Eliminating data scraping attacks in a payment push architecture

Thursday, September 11, 2014

Does Government have a Role in the Evolution of Payment Systems?

Lawmakers cannot define a payment hub. When they try, they make laws like defining pi as 3.141 to make construction budgets (and therefore timed payments) precise. Other than being really funny (forgive my odd sense of humor), such bizarre attempts raise a legitimate question, namely, does government influence on payment system architecture needlessly force modifications or does it have a benefit. 
I think payment hub design requires data elements that support the only legitimate government concern, taxes, and fight back on government encroachment on anonymity due to cross border or value inspections. Governments wanting to know specifics of transactions traveling within payment systems need warrants based on probable cause other than detection of a large value because of a large tax payment.   

I am not naïve; governments can, have, and will use payment systems, like any other commercial infrastructure, as a weapon or an intelligence platform, so be it, but that requirement should not influence efficient design. This discussion leads naturally to a question of a cash pools, their union, and the obvious attraction they garner from thieves and governments alike.
No reader yet has contradicted me on the published premise that payment systems require speed between initiation and settlement to reduce risk. So why are we not seeing various economic sectors teaming together to form small value gross real time payment systems (SVGRTP) based however loosely on the Bum’s Pocket I described earlier in this blog

My vision of a patron at say an Indian casino in Michigan with a windfall of winnings, leaving with nothing more than a passport, and traveling to Macau and back without a payment card, cash, or anything except the ability to transfer funds immediately from the casino to the taxi, the airline, the hotels, the restaurants, and tips in cash when required, without any trepidation, remains only a vision.

Certainly the toothless antitrust authorities in the US do not stand in the way and the other G20 nations endorse cross small value transfers using the haphazard pull methodologies implemented by cards and other tokens set up in advance under careful host government scrutiny. Why financial institutions let large payment networks dictate the relationship between them and their retailers and force apart their natural conduit of fund movement remains a true mystery.

I do understand the reluctance of financial institutions (FI) to meddle with a working system regardless of leaky pipes and archaic data structures. However, at what point do FI look around and realize that their customers demand rapid movement of their funds in a secure reliable way and they will go elsewhere to get that service as manifested by growth of private label and pre paid cards. True governments such as the US making prohibitions for instance on gambling, requiring funds reporting, allowing the immediate ex-judicial seizure of cash in or out of bank accounts, enforcing card issuer and payment network monopolies by allowing the price fixing of fees, and many other nanny policies increase the search for alternate payment methodologies. However, FIs need to pull their collective heads out of the sand and compete in a realistic manner or they will find themselves on the losing end of a retailer revolt that creates self sustaining models of the bum’s pocket.

Next Blog: A PED design for access to the Bum’s Pocket

Wednesday, September 10, 2014

Review of The Iphone Payment Initiation Method

After doing a bit of research on the new Iphone payment application and finding very few facts, I thought I could easily make up some facts and see if my reader(s) agree. The application initiates a payment using a token, a cryptogram, a geocoded position, and an approved amount. User authentication (biometric) occurs as a separate function from payment initiation A large acquirer routes the transaction by translating a portion of the token as a bank identification number (BIN). The acquirer forms an 8583 request using the personal account number (PAN) portion of the token which the issuing institution (or its agent, likely the large acquirer) translates to the actual PAN. No EMV required although a PKI method may have produced the cryptogram giving a nod to the EMV Imperium.

Apple cut a deal so they will assume some Reg. E payouts and that might be the devil that makes or breaks the venture. The scheme (if I am remotely near the actual facts) likely will succeed in the near term because there is easier money in data scraping electronic cash registers in regional and national chains than there is in jail breaking the I6 and launching a lunch time attack. However the imagined payment architecture is vulnerable to a lunchtime attack, (ultimately allowing intercept of NFC transmissions, and counterfeiting the results) or a Man-in-the-middle attack (intercepting and moving the auth request to another retailer while jamming the NFC with the retail receiver). Neither attack is cost effective while the keystone cops trace data scrape attackers with “tut, tut, you need EMV”. Sooner or later, however, just like the price of oil causes wildcatters to reopen wells, moving data scrapers to the iphone application, its predecessors, and its progeny will seem like a reasonable business proposition.

As long as financial institutions do not push payer funds to payee accounts with real time notification routed correctly to payer and payee then payer funds remain vulnerable to retailer foibles, mainly the false retailer belief that possession of payer financial data increases the velocity or impact of payments.

Next Blog: Something you know, something you have, and something you will think.

Saturday, September 6, 2014

Restricting PED Functions while initiating Payments

The initiation of a payment is the result of a series of discreet functions. The functions act on sensitive data (payer and payee financial data) which requires a unique environment because money attracts theft. The rapid growth of payment initiation from a personal electronic device (PED) naturally attracts thieves (and possibly others with different motivations). However the operating systems of commercially available PEDs allow unrestricted user activity because diversity of functions available to users drives PED ubiquity.

This divergence of function (restricted v. unrestricted) requires a reasoned response fitting the problem and yet still allowing users the myriad activity available to them. In the previous post I advocated the use of a hypervisor to monitor operations of electronic cash registers based on X86 architectures (see ). This approach works only with devices dedicated to initiating payment and is not practical for a PED.

If we look at operating systems available for most PEDs and consider their use for initiating payments it’s a bit like looking into the mouth of an alligator just before you put your head between its jaws. Further, payment data moving in the clear from device to device, allows interception outside of PED operating systems and thus gives attackers the opportunity to counterfeit payment initiation. Encryption of all data with keys accessible only to the payer and the account administrator clearly solves the problem of financial data traveling in the clear. However the data still exists in the clear on the PED before transmission and thus open to attack with very little ability for defense. Providing defenses against attacks requires slowing all activity on the device (a non-starter) or slowing payment initiation to make sure the PED does not host attacking software.

I take the liberty to define hypervisor differently than the precise use of the term in my previous post. I define hypervisor as any trusted kernel that only allows software registered with it to run. The kernel can increase protection and slow the initiation of payment further at a level that makes sense for the risk of harm present in a transaction.

The hypervisor may be present after boot-up, but only active when users initiate payments. If we consider the various software present in a PED as sets of functions, then diagram 27 shows the intersection of a hypervisor with other functions.

Diagram 27: Intersecting Sets of Functions

Designers now can create trusted applications and drivers, register them with hypervisor providers and grow the relationship between hypervisor and trusted applications to services other than payment initiation. In the US this tradeoff between speed, flexibility (running a non-trusted application while initiating a payment), and transaction security, does not seem to appeal, because unauthorized transactions must be refunded as per Reg E. However if Regulation E no longer applies because user push payments instead of having the payee pull the payment, then the tradeoff may be more acceptable. Predicting the reactions to users is for marketers and not a topic of this post, however, neutralizing future attacks on PEDs, may boil down to a question of selling it to the users.

Next Blog: How safe is NFC transport 

Tuesday, September 2, 2014

Is Implementing a Hypervisor for ECR Payment Applications Cost Prohibitive?

The publicity surrounding data scraping attacks against ECR applications prompted me to write a few posts about approaches to stop the execution of such malware at the operating system level (see for example ). After the recent UPS attacks, I think it is quite clear that the payment systems industry will not form a uniform response to these attacks and instead touts Europay, MasterCard, VISA (EMV) as more of a prayer than a solution.

The ability for the Intel and AMD X86 to host hypervisor kernels provides ECRs a superior ability to detect and stop these attacks; however, retailers will be in no mood to deploy such a response once they have already forked over most of their equipment upgrade budget to move to EMV.  Certainly ECR software developers will likely have some academic help.

Amit Vasudevan and his fellow researchers at CyLab, Carnegie Mellon University seem to have a clear sensible approach to any that care to listen about methods to control applications running on a platform processing sensitive data such as payer financial data. 

For example in:

“Requirements for an Integrity-Protected Hypervisor on the x86 HardwareVirtualized Architecture”
 by Amit Vasudevan, Jonathan M. McCune, Ning Qu, Leendert van Doorn  and Adrian Perrig  (from  CyLab, Carnegie Mellon University; Nvidia Corp; Advanced Micro Devices (AMD) Corp) ( )

The researchers describe clear rules for implementing a hypervisor generally (which no one has yet done, and maybe extremely difficult to do but implementing just a fraction of them (which has been done) would significantly deter data scraping attacks).

The researchers provided another jewel:

“It’s an app. It’s a hypervisor. It’s a hypapp.”:Design and Implementation of an eXtensible and Modular Hypervisor Framework

By Amit Vasudevan, Jonathan M. McCune, and James Newsome (all from CyLab, Carnegie Mellon University, 2012)

The article describes design principles for creating the secure environment.

 AMD and Intel hypervisor modes are not compatible with each other so developers will need to write different versions, one for Intel’s “Separation Kernel Model” and the other for AMD’s “SVM – Secure Virtual Machine (PACIFICA)”.

 If these are successful (counters data scraping attacks) then users on compatible computers initiating payment for personal use might be able to implement similar approaches. If the costs to implement this type of approach prove to be cost effective then more trusted applications working with payment operating systems would increase the efficiency of managing sensitive data in hostile environments and quickly deploy to face future threats.

Next Blog: The Difference between DUKPT and EMV approach to Security