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.
No comments:
Post a Comment