W3C Web Payments IG/SG

Security, Next Steps

Erik Anderson, Bloomberg

Review of Capabilities• https://docs.google.com/document/d/1FbHscEFUA1P6Frm9h-98bgBF8oCNNu3_0BZh8l7Aa0c/edit#heading

=h.gn0ex7y2p7d6• Protocol to strongly bind an identifier to a real world identity and a cryptographic token

• Identifiers• Payment schemes define identifier syntax and semantics (e.g., primary account numbers (PANs) for credit cards, or bitcoin

account identifiers). We expect to support scheme-specific identifiers. But where global identifiers are required and are not scheme specific, we expect to use URIs.

• Due to the nature of payments and the fundamental challenge of preventing “double-spending” as part of the payments process, it is important that every actor/system be uniquely identifiable to other actors and systems participating in the payments process. While each actor must be identifiable, a number of use cases that need to be addressed include low value or less-sensitive payments which do not require the knowledge of a participant’s identity as a part of the transaction. Because of this, it is important to de-couple the identification (non-identity based unique ID) of each participant in the Architecture from the Identity data (sensitive/private data about the participant) which describes information about a participant taking part in the system

• Security• Messages must not be altered in transit, but may be included as part of encapsulating messages created by intermediaries.• It must be possible to provide read-only access to transaction information to third parties (with user consent).• Signatures must be non-forgeable.

• Identity, Privacy and Consumer Protection• To satisfy regulatory requirements and financial industry expectations, some use cases will require strong

assurances of connections between a Web identity and a real-world identity.• At the same time, any source of information that can lead to the unintended disclosure or leakage of a user’s

identity (or purchasing habits) is likely protected in a jurisdiction somewhere in the world by a legal/regulatory entity having responsibility for its citizens.

• For discussion: the role of per-transaction pseudo-anonymous identity mechanisms for some use cases. These mechanisms would make it much more difficult for an unauthorized party to track a user’s purchasing habits from 1 transaction to another transaction. This will also eliminate the loss of that identity from affecting other services that user is enrolled in.

• Regulations in several jurisdictions require the consumer to be notified every time their personal information/credentials are accessed. To discuss: cryptography requiring a user’s input/knowledge to open that information.

• Some purchases in combination (e.g., products accommodating prenatal care needs) will leak sensitive information. To discuss: dynamic key construction can be applied to each line item in a receipt to help prevent unauthorized data mining of individuals, legal & regulatory snooping. Even if the protected information is stolen or accidentally forwarded to unauthorized parties they will not have the correct tokenized inputs to recreate the dynamic keys to unlock access to the protected information.

• Role based access controls when applied to dynamic key construction for each individual credential or large sets of data will help facilitate interoperable access without needless duplication and encryption of information for each authorized party. For discussion: Use dynamic keys to protect a static key where various dynamic keys can be used to unlock the static key that protects the sensitive content.

• The system should support privacy by requiring only the minimal amount of information necessary to carry out a transaction. Additional considerations (e.g., marketing initiatives with user consent, or legal requirements) may lead to additional information exchange beyond the minimum required.

• Payment account providers must take measures to ensure that account identifiers are not, on their own, sufficient to identify the account holder.

• Another suggestion: “Don’t require personal authentication, but make sure it can be done properly”

• Legal and Regulatory• In some jurisdictions legal or regulatory entities may need to be granted “time-limited

access” to a transaction to view specific credentials and purchased items of the user. The system should limit what is viewed to the minimum necessary. Examples: Government subsidies such as food stamps, controlled substances. In these cases those particular line items in the receipt may be required to be viewable via individuals or computers charged with the responsibility to prevent abuse of those programs (e.g., unauthorized reselling). There may also be a requirement to view identities or credentials.• For certain classes of payments, such as high value or international, it must be possible

to provide role-based access controls to pierce a pseudo-anonymous identity mechanism so the transaction can be counter signed by a legal, regulatory, or KYC/AML system yet safeguard against disclosing unnecessary information. It must be infeasible for the piercing of this mechanisms to leak enough information for those authorities to forge user information.

Key takeaways from 4-Jun-2015 Federal Reserve Secure Payments Taskforce inaugural meeting

• Presidential Order 13636, Improving Critical Infrastructure Cybersecurity• Controlling Security Risk, Risk Containment• Reducing Fraud• Data Breaches• Limiting access: Access to data, access to payment networks.• High risk of emerging payment mechanisms.• Privacy• Fraud Alerts, Credit Freezes, Realtime indicators.• No talks, not 1 mention, of digital signatures. Used for message integrity not

authorization nor authenticity. Doesn’t solve non repudiation.• Tokenization: Overused term. Refers to encryption, privacy, data security,

protocols

https://www.w3.org/Payments/IG/wiki/Security_Task_Force/Feds_06_04_15_meeting

• Due to technologies advancements, counterfeit of payment instruments is becoming nearly impossible. Theft of sensitive data and private keys are the key factor enabling many methods of payment fraud. These thefts enable misrepresentation of authority, counterfeit cards and checks, compromise security protocols at financial institutions, account takeover, and creation of a new-account fraud in the victim’s name.• In many of these cases, breaches are not detected at the time of

intrusion into the system, in part because the hackers wait for an opportune time to monetize the compromised information. But when they do act, recent experience suggests that they move quickly and, at times, employ a sophisticated criminal organization. Recent data breaches are particularly notable for the sophistication of techniques employed by criminals.

Key takeaways…

• Studies conducted since 2009 show that hackers are migrating toward attacking private data over payment instruments themselves. Having access to data is allowing the fraudsters to conduct large volumes of smaller value transactions. Smaller transactions and new accounts may go unnoticed by consumers. Depending on the half-life (ie. value decay over time) of the information these breaches can affect consumers for 10+ years. Payment instruments can be immediately cancelled but the lifetime of private data can be measured in decades having severe long term consequences for victims.• Identity theft and fraud is drastically increasing (25-50% per year) because of

personal data sharing mechanisms, data breaches, password/account recovery mechanisms, malware, phising, etc.• Information is powering the digital economy. For transactions to settle faster we

need to move information about the identity (ie credentials) with the payment instrument. Moving this information has increased risks because of the potential abuse of long living information.• Current data security approaches are still leaning to securing the network. This is

leading to overall security depending on the security of each element of a network. Furthermore, these weak links can change as the security preferences or makeup of payment participants change over time. The only solution is to end-to-end secure the data itself and let the network/channel independently evolution.

Key takeaways…

• Consumer use of corrective financial protection mechanisms, such as Fraud Alerts and Credit Freeze systems, has been very low (<10%) and unsuccessful. Consumers don't use these particular types of identity theft protections and by the time the alert or freeze occurs the damage has been done. When consumers use those systems it ends up costing several days of time. Must protect the data around identity (ie credentials & private keys) with better access controls and protection mechanisms. It should be infeasible to defeat the authentication, identification, and access control mechanisms to expose the data even on a compromised PC, merchant, or at a compromised consumer data collection facility.• Countries that adopted chip-n-pin carts have noticed that fraudsters shifted their

efforts to identity fraud, taking over or creating new accounts, and IMOTO (Internet and Mail Order and Telephone Order) causing a dramatic rise in associated fraud losses. History shows that new payment instruments & technologies lack adequate protective measures, such as Web enabled mechanisms, causing a major influx of fraudsters. Adopting chin&pin in the US will have unintended consequences such as flocking to internet based payment methods. There are countless consumer warnings sent per week to avoid the internet payment mechanisms.

Key takeaways…

• Security Framework should recognize the global nature of technology yet avoid guidance based on country of origin, which would impede international commerce. National cybersecurity concerns can be addressed in alignment with an international standard which lets you tailor your risk vs security.• Its not possible for any single Government or even entities within one Government to have

an exclusive, comprehensive regulatory, or supervisory jurisdiction over such a security framework. Framework must allow security layer(s) that allows access to data within their jurisdiction yet not allow snooping & information leakage outside their sandbox.• To keep the costs low, the optimal control point should use a least-cost method to enhance

security. Meaning the payer’s bank, for example, can best determine whether the payer’s signature on a check is genuine, and the payee’s bank can best determine whether the payee’s endorsement on the check is genuine. Example: We dont need a massive government based KYC physical & Biometric signature verification platform when the existing Banks can perform these tasks. Over doing the security, identity, KYC/AML, & legal/regulatory structure will create misaligned incentives that are not socially optimal nor justified. A browser based security framework can accomplish this and keep down the costs to consumers and institutions.• The right security framework will allow internet based commerce to attain low fraud rates

without a central authority implementing significant rules or oversight.

Key takeaways…

• Framework must address protection of the data itself.• A payment and information networks consists of many components—computers,

communication channels, software, and users—each subject to attack and requiring defense.• The weakness of each component will vary, and attackers will strike vulnerabilities with

the highest expected payoff.• Engineers who protect these components make judgements about their vulnerability and

prioritize each component to determine which weakness to correct. These assessments are difficult, costly, and uncertain, and some weaknesses will likely remain due to undetected vulnerabilities or imprecise assessments (such as underestimates of potential damages).• Engineers cant protect all the components all the time so we must work on protecting

the underlying data. This requires a data protection framework that spans the UI to the very data storage. A proper framework will allow the web/internet to be used as the payment pipes. Without such a data protection framework it will be impossible to safely use the web/internet because of the uncertainty of security of each network node a transaction goes through.

Existing Standards

• ISO 20022 – Data Dictionary for most financial services asset classes. No built in security mechanisms.• ISO 12812 – Part 2 directly references data at rest, data in transit, HMAC,

encryption, tamper resistant key material storage, keys to encrypt keys, channel security for general protection and encryption of sensitive information within the messages themselves, keys that encrypt other keys, • X9.69 & X9.73 – Standard for Dynamic Key Management. Unique encryption

key per message, transaction, identity based encryption mechanisms, etc.• X9.119 part 2 – Static tokenization of card data, not a dynamic token

required for payments.• X9.122 – Debit card authentication mechanisms• Various NIST and ANSI standards. All are referenced in the above standards.

W3C browser standard

Java

scrip

t AP

I

Web Application

JSO

N

ISO 20022 (optional example)

X9.73

Core BrowserEngine (C/C++)

X9.73X9.69

SSL

Financial ServiceProvider

SSL

X9.69 / X9.73Attribute

Administration

ISO 20022 (optional example)

Vario

us c

rede

ntial

s

And

key

split

s

Out of bands communications

from your payment provider to

your providers secure browser

SILO/storage area?

Once/month?

Each financial institution

manages their own security,

crypto algorithms, and KYC

via CKM management

system

Erik AndersonBloomberg, X9 & W3C Web Payments

?ISO 20022

FpMLFIX

ISO8583?

FIDO U2F hardware token or

other Sec Crypto Device

Secure SILO can be stored in the browser, cloud,

or hardware device

Mo m&Pap

Ripple

Target

Bloomberg

PIV

Card

Clou

d

Cloud

Card

X9.69 (CKM runtime)

X9.69 (CKM runtime)

Encryption as a service: Instruction Set/Object (no raw developer API͛]s)

Possible proprietary

hardware engine

Attribute based dynamic key encryption engineOpenVEIL®

OpenVEIL®

KeyVEIL®

$

Bank or Payment Network

Pseudo random Identity for every transactionProtects the consumers privacy

IdentityConfiguration

Public/Private token bound to the identity of the individual. Pseudo random every

transaction. Never stored!

Digital ID not bound to the analog of the individual.

Protection isnt critical but desired.

Erik AndersonBloomberg R&DX9 & W3C Web

Payments

Credentials standard Credentials standard?

Identitystandard?

$

Bank

X9.73X9.69

X9.69

X9.73

X9.69

X9.73

X9.69

X9.73

X9.69

X9.73 Biometrics and Identity based

encryption to bind the digital goods

to me whether the goods are on my hard drive, cloud,

or even a Blockchain

International regulatory and compliance Information

written for and only readable by International

Regulatory bodies

Transaction value is over $3000 so

additional information

written for and only readable by FinCEN (Financial

Crimes Enforcement)

State Information? Example: New York State sales tax information for

automation of state collected sales taxes

Identity, like a passport, is assigned globally but permissions are local. Requires cryptographic objects with varying levels of permissions for each data & identity element. Each tier of regulators

could get access to the individual elements they are authorized to see (not an inch more)

Erik AndersonBloomberg, X9 & W3C Web Payments

Steps• Short term – Protect the data, everywhere. Cradle to grave.

• Data breaches, hackers, regulatory• Mid term - Protect electronic cash letters and improve authorization in card

payments.• Make the payment instrument more secure

• Long term - effective security standards and improved incentives• One key long-run principle to ensure efficient processing and strong security would be to

standardize security protocols embedded in and around the electronic payment messages. An example would be to segregate anonymized elements in every message in its own security layer such that each element is individually encrypted but also unusable without attacking and reassembling the whole.

• Minimize the new security standards. Too many to implement for interoperability. So many new tokenization standards. Standard should be high enough to allow its underlying technology to evolve over time yet not expose the details of cryptography to the mistakes applications make. Example: API to make secure payment vs API to encrypt/decrypt data with my home-brew key.

• Proprietary standards may be quick to develop, but have never scaled internationally.• Assigning liability to the control point best suited to prevent fraud provides strong incentive to

detect and deter fraud in a cost-effective manner.• Financial institutions & merchants must accept the consequence of a fraud & security failure but

that does not always match who has the ability to correct those security gaps.