NFC Payments Analysis


1.    Requirement 3

2.    Description. 4

3.    Technical terms. 5

4.    Payment basics. 7

5.    HCE support in Android (Version 4.4 onwards) 7

6.    Traditional Application mechanism.. 8

7.    Secret storage in SE-Based/HCE model 8

8.    NFC Payment App using HCE.. 9

9.    HCE application to NFC Loyalty. 10

10.  Credential Manager 10

11.   Hacking proof and Rooting detection. 10

12.   Attestation & Security. 10

13.   Implementation & Secure Storage. 10

14.   End to End Encryption. 10

15.   Tokenization & DeTokenization. 10

16.   Payment Token Transaction Flows. 10

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







Post a Comment

0 Comments