The Dialectic of Attack and Defense of Payment Systems

Designers of payment systems need to think more than the clearing, settlement, security, and marketing of these systems. Designers need to consider the evolution of attacks once a security posture is in place. The security design of Europay, MasterCard, and Visa (EMV) for example used public key interchange (PKI) and the cryptogram evolved from static data authentication (SDA) to dynamic data authentication (DDA) to combined data authentication (CDA) and yet this evolution did nothing to stop the type of attacks that compromised the cardholder data originating from card accepting devices. The designers of EMV also did not consider how to protect an attack against cardholder not present (CNP) transactions. The payment solutions of the future cannot present a security posture and dare anyone to attack it. Designers must engineer payment solutions to present different defense postures depending on the environment of their deployment and the type of current attacks.

Payment initiation software must include sensors that indicate an attacker is currently present, and shut down depending on the configuration of the payment initiating device. Software deployed in payment initiation devices must know what their environment is. If (as likely) the operating system is interrupt driven then the software must look at all of the interrupt vectors and determine if those are pointers to legitimate drivers signed by legitimate developers. Payment system software must identify every logical port and verify the legitimate uses of those ports. Introduction of new software into the payment initiation environment cannot take place without validation.   These are primitive examples of design considerations taken at the software level that do not rely on hardware to respond to evolving attacks.

As digital currency gradually replaces card base technology, the currency must include software with the payment data that recognizes its environment and responds to attacks. For example the currency will know its payer and intended payee before a transaction takes place. If the currency finds itself in an environment that it did not expect the software within the currency must invalidate the financial data present in the currency. Attackers naturally will respond by mimicking the intended environment so the software imbedded in the currency must continually update the parameters that define a legitimate payee. The logic using those parameters must also contain an ability to change although without giving a vector for an attack. These are not easy architectural problems to solve and mistakes may lead to the compromise of financial data on an unprecedented scale. However, planning a mission to Mars seems more difficult and the world embraces that challenge.

Next Blog: The consequences of diverging payment methodologies