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 http://paymentnetworks.blogspot.com/2014/09/is-implementing-hypervisor-for-ecr.html ). 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