1. Requirement
2. Description
3. Technical terms
4. Payment basics
5. HCE support in Android (Version 4.4 onwards)
6. Traditional Application mechanism
7. Secret storage in SE-Based/HCE model
8. NFC Payment App using HCE
9. HCE application to NFC Loyalty
10. Credential Manager
11. Hacking proof and Rooting detection
12. Attestation & Security
13. Implementation & Secure Storage
14. End to End Encryption
15. Tokenization & DeTokenization
16. Payment Token Transaction Flows
1. Requirement
Payment App which should support all possible contectless payment method
2. Description
“All-in-one”: unifying payment, eTicket,
Loyalty, coupons, gifting, eMarketing
SE
vs Host Card Emulation (HCE)
SE
& HCE both can co-exist in the
same Android device
1 3.Technical
terms
1. Primary
account number (PAN)
The 14, 15 or 16 digit number that appears on the primary account
holder’s credit card. Often, the primary account number is
also simply called the account number. A variable length, 13 to 19-digits, ISO 7812-compliant
account number that is generated within account ranges associated with a BIN by
a Card Issuer.
2. Secure
element (SE)
3.
Trusted execution environment (TEE)
4.
EMV Payment Tokenization Specification
(EMV)
It defines key roles of
the entities necessary to support Payment Tokenization, identifies impacts of
this specification, specifies the required and optional data fields associated
with Token requests, Token issuance and provisioning, transaction processing,
and identifies necessary application programming interfaces (APIs).
Ø Payment
tokens: It refers to tokens as defined under the EMV Payment
Tokenization Specification.
Ø Acquirers
Ø
TSP(Token Service Provider)
Ø Merchants
Card Issuers
Ø Cardholders
Ø Bank
Identification Number (BIN)
BINs are assigned by Payment Networks
to Card Issuers. BINs are consistent with ISO 7812 requirements to identify the
Payment Network based on the BIN and associated account ranges.
Ø
BIN Controller / Manager
Ø
3-D Secure
Protocol for Cardholder authentication
in e-commerce.
Ø
Agent
An entity appointed by the
Card Issuer to perform specific functions on behalf of the Card Issuer. Some
examples of these functions include card processing, Cardholder verification
using the 3-D Secure protocol, and Token Service.
Ø Card
Any Cardholder device or form factor,
such as a mobile phone, that can be used to initiate financial transactions.
Ø
Card Holder
Any individual that has been issued a
financial account provisioned to a Card by a Card Issuer.
Ø
Card Acceptor
The entity that initiates a payment
transaction and presents transaction data to the Acquirer, typically a Merchant
Ø
Card Acceptor ID
The identification value for the Card
Acceptor.
Ø
Card Issuer or financial institutions
(FI)
A financial institution or its Agent
that issues the Card to Cardholders.
Ø
Card Issuer Access Control Server
(ACS)
The Card Issuer’s Agent that provides
a 3-D Secure service for ID&V.
Ø
De-Tokenisation
Ø Identification and Verification (ID&V)
A valid method through
which an entity may successfully validate the Cardholder and the Cardholder’s
account in order to establish a confidence level for Payment Token to PAN /
Cardholder binding. Examples of ID&V methods are:
i. Account verification
message.
ii. Risk score based on
assessment of the PAN.
iii. Use of one time password
by the Card Issuer or its Agent to verify the Cardholder.
Ø Payment Network
An electronic payment system used to accept, transmit, or process
transactions made by payment cards for money, goods, or services, and to
transfer information and funds among Issuers, Acquirers, Payment Processors,
Merchants, and Cardholders.
Ø Payment Processor
An entity that provides payment processing services for Acquirers
and / or Issuers. A Payment Processor may in addition to processing provide
operational, reporting and other services for the Acquirer or Card Issuer.
Ø Payment Token
Payment Tokens can take on
a variety of formats across the payments industry. For this specification, the
term Payment Token refers to a surrogate value for a PAN that is a 13 to
19-digit numeric value that must pass basic validation rules of an account
number, including the Luhn check digit. Payment Tokens are generated within a
BIN range that has been designated as a Token BIN Range and flagged accordingly
in all appropriate BIN tables. Payment Tokens must not have the same value as
or conflict with a real PAN.
Ø Requested Token Assurance Level / Assigned Token Assurance Level
Ø NFC with a secure element (SE)
embedded in the mobile phone that stores a payment token to replace the primary
account number (PAN).
Ø NFC with host card emulation (HCE) software
that replaces the SE in the mobile phone to enable the NFC wallet app to
perform card emulation. Payment tokens4 are downloaded from a cloud server and
stored in the mobile operating system (OS).
Ø NFC with a trusted execution environment
(TEE), a secure area of the main processor in the mobile phone that stores the
payment token.
Ø The secure domain protects the user’s
credentials and processes the payment transaction in a trusted environment.
There are three types of SEs—Subscriber Identity Module (SIM)/Universal
Integrated Circuit Card (UICC), micro SD, and embedded secure element (eSE).
Ø
Automatic
wake-up of a mobile application on AID selection based on declaration (static
only)
Ø
AID
conflict resolution
Ø
AID
grouping (answer, no-answer)
Ø
Categories
: Payment, Other
o
Payment
applications need to provide a service banner (logo) to be displayed on
“Tap-and-pay” section of Settings for choice of default application
o
Applications
can check if they are default and request to be made default
Ø
No
HCE transactions when screen is off.
Ø
HCE
transactions can be placed with device locked; a flag indicates if there should
be a request to unlock the device.
Ø
Apple
Pay stores payment tokens in the SE in the mobile phone (model 1).
Ø
Google
Android Pay9 uses HCE to store tokens in the Android KitKat v4.4 (or higher)
mobile OS (model 2).
Ø
Samsung
Pay uses NFC and HCE, but stores the payment token and cryptographic keys in
the TEE in the mobile phone (model 3)
TBD
0 Comments