Saturday, July 19, 2014

Catalog of Attacks on Retail Payment Hubs

I want to focus on materialistic outside attacks of payment conveyance mechanisms because regardless of the design of a payment hub, attacks will occur and some will succeed.  There are two types of attacks: attacks derived from intercepted payment data, or attacks derived from manufactured data. Except in the extraordinary case where manufactured data is the same as legitimate data (in which case it is the same as intercepted data), real time validation of some transaction data should detect manufactured data before payee acceptance. Transaction data critical to successful completion includes:

  • Payer Data (Account Linked)
  • Payee Data (Account Linked)
  • Amount
  • Date, Time
  • Location of payer

The manufacture of Payee data does not accomplish an attack; it will create a failed transaction. The intercept and substitution of payee data can lead to a successful attack; however funds are recoverable if the original payee detects and reports the loss before the attacker escapes. The small value gross real time payment (SVGRTP) such as the virtual bum’s pocket (described in earlier blogs) virtually eliminates this type of attack because the payee anticipates the push of funds. The time for escape will be minimal because the payer will see the value removed from an associated account, from the notification of the removal, however the payee will not have notification of funds receipt. The funds become immediately recoverable after successful revocation of the currency certificate. However the next intended payee of the attacker must validate the certificate or the attack will succeed.

The manufacture of payer data can lead to a successful attack and payee loss. The authentication of the originator offers no defense. If the payer data does not receive validation before the payee receives notification of funds receipt the attack will succeed. Since the payer data does not actually link to an account, the attack fails if notification to payee does not occur until removal of funds from a payer account. Also if delivery of goods or services only occurs after a delay then the attack likely fails proportionally to the length of the delay.

Intercept of payer data can lead to a successful attack. With absolutely no data to back me up, I want to say the greatest vulnerability of all retail payment systems is the intercept of payer data. If true, then the attack deserves the greatest resources for defense. I described in earlier blog that one defense against the attack is to validate that the distance and time from the last transaction is possible. However, once a payment hub deploys that defense, attackers defeat it by substituting the new location details to meet the possibility criteria. Authentication of the user does not prevent interception of user data. Authentication of the electronic device (if used to originate a transaction) seems to give the greatest consistent defense against intercepted payer data use in a transaction. For example if the currency described for use by the virtual bum’s pocket is registered by an insurance company as residing in a specific device, then that specific device must be able to provide a certificate showing it is the device known to the insurer without repudiation.   Generally, validating that the payment hub “knows” an initiating device, works against attackers using intercepted payer data, especially if the device is unique to the payer. In other words using a cell phone to initiate a payment may provide greater defense than a common device such as a point of sale card acceptance device used by the public at large.

Next Blog: Continued taxonomy of attacks

No comments:

Post a Comment