View
4
Download
0
Category
Preview:
Citation preview
NEW FRONTIERS IN
SECURE COMMERCE
EMV® 3-D SECUREEMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC.
SAM PFANSTIEL, MODERATOR
CONTROLSCAN
KEVIN CROCKETT
CARDINALCOMMERCE
STEVE KLEBE
TABITHA ODOM
EMVCo
SAM PFANSTIEL, MODERATOR
CONTROLSCAN
KEVIN CROCKETT
CARDINALCOMMERCE
STEVE KLEBE
TABITHA ODOM
EMVCo
Copyright ©2017 EMVCo 55Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
Role of EMVCo in EMV® 3-D Secure
What EMVCo Does What EMVCo Does NOT Do
• Develop specifications that support secure e-commerce transactions in a globally interoperable manner.
• Enhance specifications based on industry feedback.
• Maintain vendor / service provider relationships.
• Collaborate with other industry bodies.
• Implement and manage a testing and approval programme.
• Deliver royalty-free specification ‘tool box’ to be adapted by global, regional and domestic payment systems to meet regional market variations.
• Develop EMV 3-D Secure solutions / products.
• Implement EMV 3-D Secure solutions or services.
• Maintain ecosystem implementation and governance requirements.
• Mandate, incentivise or shape policies for EMV 3-D Secure solutions.
• Manage 3DS version 1.0 – Visa will maintain sole ownership and management of this version.
EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC.
Copyright ©2017 EMVCo 66Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
EMV® 3DS Technology
• Supports app-based purchases on mobile and other consumer devices.
• Enables merchants to integrate authentication into their checkout process for both app and browser-based implementations.
• Specifies the use of multiple options for step-up authentication.
• Adds a non-payment message category.
• Enables merchant-initiated account verification.
• Flexible to accommodate global and local needs.
• Available royalty-free from the EMVCo website.
Specification FeaturesEMVCo maintains the EMV 3DS
Specifications, administers testing
and provides an approval process to support e-commerce
transactions in a globally
interoperable manner.
Copyright ©2017 EMVCo 77Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
Key Benefits
Merchants Consumers Issuers
• Supports a consistent approach for cardholder authentication or account verification.
• Applies to multiple platforms and digital channels.
• Minimises checkout abandonment.• Protects merchants from exposure
to fraud-related chargebacks.
• Reduces risk of fraud.• Richer data exchange enables
frictionless authentications.• Supports new devices and
channels.• Encourages cardholders to
make purchases using their preferred medium.
• Enhances online security.• Increases convenience.• Maintains existing consumer
experience.
The exchange of 3DS data between the merchant and a card issuer can increase authorisationapproval rates and reduce the risk of fraud, while optimising the cardholder’s experience.
Copyright ©2017 EMVCo 88Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
EMV® 3-D SECURE TRANSACTION FLOWS
Copyright ©2017 EMVCo 99Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
ACS
The Access Control Server (ACS) – responsible for authentication of the cardholder
DSDirectory Server (DS) – operated by each participating Payment System
3DS Server
3DS Server – communicates with the merchant environment and the Directory Server (DS) to send and receive authentication messages
SDK3DS SDK running on the consumer device communicates with the 3DS Requestor Environment and the Access Control Server (ACS)
EMV® 3-D Secure Components
Copyright ©2017 EMVCo 1010Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
The consumer adds the item to their shopping
cart, completes the standard purchase
information and confirms the purchase
The purchase information along with device data and other details are submitted
to the ACS to determine cardholder
authentication
The ACS was able to authenticate the
cardholder via ‘risk-based authentication’ and the cardholder is
authenticated passively
Application Based Example – Frictionless Flow
Copyright ©2017 EMVCo 1111Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
Acquirer BIN
Acquirer Merchant ID
Cardholder Account Number
DS URL
Message, Extension, Version
Acquirer BIN
Acquirer Merchant ID
Card Expiry Date
Cardholder Account Number
DS URL
Merchant Country Code
Message Category, Extension, Type, Version
Purchase Amount, Currency, Date & Time
Recurring Expiry, Frequency
More than 10 X Data
Browser User-Agent
Browser User-Agent
IP address
Browser Time ZoneJavaScript Enabled
Cardholder Email Address, Home Phone Number, Mobile Phone Number, Work Phone Number
Cardholder Name
SDK App ID, SDK Encrypted Data, Ephemeral Public Key
SDK Reference Number, SDK Transaction ID
3DS Requestor URL, App URL
Browser Accept Headers
Cardholder Account
Information (Account
Age, Change, Password Change, Number of Transactions per Day /
Year, Shipping Name Indicator, Suspicious Activity, Payment
Account Age etc.)
Cardholder Account Identifier, Billing Address
Cardholder Shipping Address
Transaction Type
Account Type
Browser Time Zone
DS Reference Number, Transaction ID
EMV Payment Token Indicator, Payment Token Source
Purchase Date & Time
Recurring Expiry, Frequency
3DS Server Reference Number, Operator ID, Transaction ID, URL
Address Match Indicator
Device Channel, Device Information, Rendering Options
Supported
Message Category, Type
Merchant Name
Merchant Country Code
Merchant Category Code
Merchant Risk Indicator (Delivery Timeframe, Re-order, Pre-order, Gift Card)
3DS Requestor Authentication Information (Method), Challenge Indicator, ID, Initiated Indicator
3DS Requestor Name, Non-payment Indicator, Prior Transaction Authentication information
Instalment Payment Data
Browser Java Enabled, Language, Screen Color Depth, Height, Width
3DS 1.0 Data (Initial Message – VEReq) EMV® 3-D Secure Data (Initial Message – AReq)
Application Based Use Case Example – Challenge/Response Flow
Whitelisting Status, Status Source
ACS Decoupled Confirmation Indicator
3DS Requestor Decoupled Max Time, Decoupled Request Indicator
3DS Requestor Authentication Method Verification Indicator
Copyright ©2017 EMVCo 1212Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
The consumer adds the item to their shopping
cart, completes the standard purchase
information and confirms the purchase
The purchase information along with device data and other
details are submitted to the ACS to determine
cardholder authentication
The ACS was not able to authenticate the
cardholder via ‘risk-based authentication’. The
cardholder is requested to enter an OTP to
authenticate themselves
Application Based Use Case Example – One Time Passcode (OTP) Flow
Copyright ©2017 EMVCo 1313Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
The OTP information is sent to the ACS for verification
The ACS was able to verify the cardholder via the OTP
and the cardholder is authenticated
Application Based Use Case Example – OTP Flow: Success
Copyright ©2017 EMVCo 1414Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
EMV® 3DS V2.2.0
Copyright ©2017 EMVCo 1515Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
EMV® 3DS 2.2.0 Builds upon the Key Benefits
EMV 3DS
Promotion of Frictionless
Authentication
New Authentication
Channels
Better communication
across all Domains
Better User Experience (UX)
Identification and Verification
(ID&V)
Increase Approval Rates
Reduce Fraud
Copyright ©2017 EMVCo 1616Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
EMV® 3DS 2.2.0 Additional Features
Promotion of Frictionless
Authentication
Further promotion of frictionless authenticationEnhancements offer options for fewer step-up authentications, while still complying with regulations, such as PSD2 in Europe:• Indication if acquirer Strong Consumer Authentication (SCA) or Transactional Risk
Analysis (TRA) was already performed prior to the authentication message being sent.
• Ability to send data as Information Only to the ACS / Issuer.• Indicators communicating if the cardholder has already “whitelisted” themselves
to a merchant prior to the transaction or wish to whitelist themselves to the merchant during the transaction.
FIDO Authentication, Token, and Secure Remote Commerce (SRC) Data:• Additional information as to how the cardholder logged in to their 3DS Requestor
Account.• Specification has been updated to carry additional FIDO, Token and SRC data
from the merchant to the issuer.
Copyright ©2017 EMVCo 1717Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
EMV® 3DS v2.2.0 Key Features
User Experience with Whitelisting Checkout (SCA)
NOTE: UI Templates updated for both Native and Browser HTML
Copyright ©2017 EMVCo 1818Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
EMV® 3DS v2.2.0 Key Features
User Experience after Whitelisting (Frictionless)
Note: ACS still has the final decision as to whether SCA is required for the cardholder transaction
Copyright ©2017 EMVCo 1919Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
EMV® 3DS 2.2.0 Additional Features
New Authentication
Channels
Support of Mail Order / Telephone Order (MOTO) transactions
• MOTO transactions can now be identified within EMV 3DS 2.2.0• Specification has built in two key features to support MOTO
1. The addition of 3DS Requestor Initiated (3RI) Paymentso A channel that allows the merchant to initiate the authentication request
without the cardholder being in-session.o This channel only supported non-payment transactions within v2.1.0 for account
verification purposes only.o This channel has been expanded to support MOTO and recurring transactions
where authentication may be required but the cardholder is not in-session.2. The addition of a new authentication method: Decoupled Authentication
o A new authentication method which allows cardholder authentication to occur if the cardholder is offline.
o This authentication method can also be used if the cardholder is online via our Browser and App channels.
Copyright ©2017 EMVCo 2020Copyright ©2019 EMVCo – Unauthorised reproduction is prohibited
For more information www.emvco.com
Official specification & supporting material portal
FAQs general & technical
Seminar & meetings details
EMVCo approved products & accredited labs
White papers & best practice guides
or join us on LinkedIn.
Thank you!
SAM PFANSTIEL, MODERATOR
CONTROLSCAN
KEVIN CROCKETT
CARDINALCOMMERCE
STEVE KLEBE
TABITHA ODOM
EMVCo
EMV® 3-D Secure – how it has
changed/how it differs from 3DS 1.0
EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC
How has 3-D Secure changed?
Improvements to 3-D Secure
• 3DS was introduced in the early 2000s … updated with the consumer
experience in mind
3DS 1.0
• Friction on every transaction
• Designed for browser-based
transactions
• Limited data used for authentication
EMV 3DS
• Better consumer experience - most
transactions can be authenticated without
consumer impact
• Device agnostic
• More data points available for
authentication for more confident issuer
risk decisions
Why authentication matters.
Cardholders who are declined usually take one of the two paths of least resistance –
both are a unwanted experience for everyone.
When false declines happen, everyone loses.
Select another card
in the wallet
Purchase
elsewhere
Authentication first can increase approvals – and sales.We have analyzed selected verticals to share KPIs and stats about the card-not-present
market, authorization and fraud rates, and the impact of authentication using Cardinal.
Industry Authorization
Lift1
Removed Fraud1
Luxury Goods 5% 30 bps
Clothing &
Footwear
4.5% 13 bps
Sporting Goods 4.5% 121 bps
Computer &
Software
7% 18 bps
Jewelry 2% 2 bps
1 Source: Cardinal and Visa global data. Statistics are drawn from the latest available data covering the period Oct 2017 to Sept 2018.
EMV® 3-D Secure helps improve the ecosystem as a whole.
• Merchants & issuers collaborate to deliver mutual benefits
• Rich data sets deliver better results: authorization lift + decreased
fraud
• Authentication first – improves authentication process as a whole
• A better shopper experience – fewer false declines with near-zero
friction
Everybody wins.
• Merchants sell
• Shoppers buy
• Issuers collect funds
• A happy shopping experience for all
SAM PFANSTIEL, MODERATOR
CONTROLSCAN
KEVIN CROCKETT
CARDINALCOMMERCE
STEVE KLEBE
TABITHA ODOM
EMVCo
Proprietary + Confidential
The Google Pay™ API will help merchants meet SCA compliance on Android (app and web) with a seamless UX
Device-bound payment credentials*
Device biometrics
● One-time identification & verification flow to bind payment credentials to a device
● Google Pay™ returns an authenticated payload
● User performs 2-factor authentication with Google Pay (using biometric or device unlock) to complete a transaction with a device-bound payment credential
Android native app & mobile web Desktop (or when device binding unavailable)
Step up via PSP
● Merchants perform necessary step-ups via their own or their PSP’s SCA solution (3DS, etc)
● Applicable primarily to desktop web & non-Android mobile web
*All Google Pay credentials (device PAN or card) can be bound to a device; more details on further slides
Proprietary + Confidential
Transaction with any device-bound
credential
Google Pay™ 2FA, no step-up
Streamlined checkout with Google Pay™ device authentication
* Credential binding in GPay app = DPAN device token | ** Credential binding in GPay online buyflow = Path 2 for cards (FPANs)
Natively handled in Google Pay™ buyflow
Proprietary + Confidential
For non-device bound credentials, merchants will run EMV® 3DS 2.0 as they do with other cards
EMV ® 3DS 2.0 performed by the merchant using the Google Pay™ API
response in conjunction with their in-house or PSP-provided 3DS2 solution
**In the future, GPay will authenticate desktop transactions natively, using a secondary mobile device bound to a user’s Google Pay Account
*Illustrative UX
Proprietary + Confidential
● The Google Pay™ API can enable merchants to be SCA compliant while providing a frictionless flow
○ Merchants and PSP’s can integrate today → SCA compliance features will automatically go into effect
○ Existing Google Pay™ merchants must make a minor update to their integration
○ Existing PSP partners do not need to update their integration
● For Device Bound credential every Google Pay™ transaction will go through 2FA using device authentication.
● In scenarios where a payment credential is not bound to an Android device (e.g., desktop transactions), merchants
should comply through their own in-house and/or their PSP’s SCA solution
Executive summary
SAM PFANSTIEL, MODERATOR
CONTROLSCAN
KEVIN CROCKETT
CARDINALCOMMERCE
STEVE KLEBE
TABITHA ODOM
EMVCo
Relationship between EMVCo and PCI SSC
• EMVCo (owned equally by card brands) created, owns, and manages the 3-D Secure protocol and implementation specifications:
– EMV® 3-D Secure Protocol and Core Functions Specification 2.2.0
– EMV® 3-D Secure SDK Specification 2.2.0
• PCI SSC (founded and governed by the card brands) maintains the security standards, assessor program related to the security standard
– “PCI 3DS Security Requirements and Assessment Procedures forEMV® 3-D Secure Core Components: ACS, DS, and 3DS Server”(henceforth “PCI 3DS Core Security Standard”)
– “Security Requirements and Assessment Procedures forEMV® 3-D Secure SDK version 1.0”(henceforth “PCI 3DS SDK Security Standard”)
TerminologyTerm Definition / Usage (see PCI Glossary on the PCI SSC website for full definitions)
3DS Messages Messages conveyed between 3DS components (e.g., PReq, PRes, CReq, CRes)
3DS Data Specific data elements defined in 3-D Core Specification (generally any data transmitted in 3DS messages)
3DS Sensitive Data Specific data requiring additional protection (e.g., 3DS Authentication Data, Public Keys, Challenge Data)
3DS Keys Private Keys for ACS and DS key pairs, generated by HSM, protected by P2-6 key management processes
3DS Requestor Initiates authentication request, conduit for 3DS data to consumer. Typically an e-commerce web server.
3DSS 3DS Server – Server in Acquirer Domain collects data elements and validates 3DS Requestor
DS Directory Server – Server in Interoperability Domain that authenticates servers and routes messages
DS-CA Director Server Certificate Authority – Generates key pairs used by DS
ACS Access Control Server – Server in Issuing Domain that authenticates cardholder
3DE 3DS Data Environment – Secure area within which ACS, DS, 3DSS functions performed.
Note: May be equivalent to Cardholder Data Environment (CDE), in which case only Part 2 is completed.
CVM Cardholder Verification Method – E.g., Online PIN, Offline PIN, Challenge-response, Shared Secret, Static
Password, Biometric, One-time Passcode
CDI Consumer Device Information. – E.g., Smartphone, Laptop, Tablet
EMV® 3-D Secure Process, Domains, and Entities
3DS Client
3DS Requestor
3DS Server
Directory Server
Access Control Server
Issuer
AcquiringIssuing
Interoperability
PCI 3DS Core Security Standards v1.0
• 3DS ROC & 3DS AOC
• Identification/Evaluation of
Evolving Risks
– Requires robust risk-
management practice
• Compensating Controls
– Legitimate technical or
business constraint
• 3DS Assessors
– 3+ years experience QSA or
QSA(P2PE)
– Quality Assurance
– Validation Methods may Vary
(with justification)
PCI 3DS Core to PCI DSS Comparison – Part 1
3DS Part 1 Requirement Other PCI Standards (May be used for Mapping)
P1-1 – Maintain Security Policies for All Personnel PCI DSS 12
P1-2 – Secure Network Connectivity PCI DSS 1, 10, 11
P1-3 – Develop and Maintain Secure Systems PCI DSS 2, 6
P1-4 – Vulnerability Management PCI DSS 5, 6, 11
P1-5 – Manage Access PCI DSS 7, 8
P1-6 – Physical Security PCI DSS 9
P1-7 – Incident Response Preparedness PCI DSS 10, 12
PCI 3DS Core to PCI DSS Comparison – Part 2
3DS Part 2 Requirement Other PCI Standards (for Comparison Only)
P2-1 – Validate Scope All Standards Require Proper Scoping
P2-2 – Security Governance PCI DSS 12
P2-3 – Protect 3DS Systems and Applications PCI DSS 6
P2-4 – Secure Logical Access to 3DS Systems PCI DSS 8
P2-5 – Protect 3DS Data PCI DSS 3, 4, 10
P2-6 – Cryptography and Key Management P2PE Domain 5, 6
P2-7 – Physically Secure 3DS Systems P2PE Domain 5
PCI 3DS SDK Security Standards v1.0
• SDK Security
– SDK Integrity Protection
– Sensitive Information
Protection
– Cryptography
• SDK Vendor Requirements
– Risk and Vulnerability
– Stakeholder Guidance
PCI 3DS SDK and Vendor Security Requirements
SDK Security Requirements Vendor Security Requirements
1 – Mechanisms to Prevent Unauthorized Modification 4 – Manage Risks and Vulnerabilities
2 – Protect Sensitive 3DS SDK Data Elements 5 – Provide Guidance to Stakeholders
3 – Use Cryptography Appropriately & Correctly
Third-Party Service Providers (TPSP)
• Common Examples– Application Hosting
– Networking or Security Managed Service Provider
– Physical Security
– Fraud Analysis / Scoring
• Requirements– Due diligence and written agreement
– Clear definition of responsibilities
– Ongoing verification that responsibilities have been met
• Compliance Assessment– May undergo 3DS assessment and provide 3DS AOC or redacted 3DS ROC
– Validate specific controls for each client entity’s assessment, or provide evidence package
Preparing for 3DS Assessments
• Implement according to PCI 3DS Security Standards (Core and SDK)
• Complete EMVCo functional testing and certification
• Define Scope of 3DE– Network Devices
– Servers, Computing Devices
– Applications
– Virtualization Technology
– Security Services
– Any Connected-To Components or Devices
• Provide Supporting Evidence to 3DS Assessor (3DSA)– ROC
– Scoping
– Network Segmentation
• Entity submits3DS Core ROC / AOC to brands
OR
• Assessor submits3DS SDK ROV / AOV to Brands
• Remediate (if necessary)
Recommended