Thanh toán Điện tử

ThS Phạm Mạnh Cường

Chương 1: Introduction to Money

Outline
◼ Nature of money
◼ What is a payment?
◼ What is a payment system?
◼ Desirable properties of money
◼ Payment system requirements
◼ Payment risks
The Payment Process
Payment is just ONE component of eCommerce,
but a VERY IMPORTANT component

NATIONAL ECONOMY / FINANCIAL MARKETS

CUSTOMER PAYMENT SERVICE SYSTEM
BANKING SYSTEM
INTERBANK SYSTEM
Buyer Seller
Payment Payment
Access Access
Buyer Point Bank Clearing House Central Bank Bank Point Seller

Agree on Instruct Initiate Clear/ Complete Notify of Complete

Trade Payment Payment Switch Settle Payment Trade
Payment

SOURCE: PHILIP TROMP, PERAGO.COM

Development of Money
◼ Definition: “something generally accepted as a medium of
exchange, a measure of value, or a means of payment.”
(một cái gì đó được chấp nhận như một phương tiện trao
đổi, một thước đo giá trị, hay một phương tiện thanh toán)

Monetary History:
ABSTRACTION
◼ Barter (direct exchange of goods)
◼ Medium of exchange (arrowheads, salt)
◼ Coins (gold, silver)
NEED
◼ Tokens (paper) BANKS

◼ Notational money (bank accounts)

◼ Dematerialized schemes (pure information)
Barter
◼ Direct exchange of goods and services -- possible when
production exceeds individual needs
◼ Problem: “double coincidence of wants”
❑ Trade a bicycle for a cow
❑ Alice must have a bicycle and want a cow UNLIKELY
❑ Bob must have a cow and want a bicycle
◼ But: Internet allows rapid discovery of wants
◼ Problem: remote barter requires an escrow (or risk)
◼ Problem: outside the monetary and tax systems
◼ When money is not trusted, barter returns
◼ Electronic barter systems exist, e.g. LETS
Types of Money:
Fiduciary vs. Scriptural

◼ Fiduciary money (fiat money – tiền được thừa

nhận, legal tender – tiền pháp định)
❑ Issued by a central (government) bank
❑ Cannot be refused
◼ Scriptural money (not legal tender)
❑ Money not issued by a central bank
❑ Examples: bank accounts, travelers cheques, gift
certificates, Octopus
❑ Can be refused
Types of Money:Token vs. Notational

◼ Token money
❑ Represented by a physical article (e.g. cash)
❑ Can be lost
◼ Notational money
❑ Examples: bank accounts, frequent flyer miles
❑ Electronic (scriptural) money: wide recognition
❑ Jeton = electronic token with limited recognition
◼ Hybrid money
❑ Check
❑ Telephone card (carries jetons for future service)
The Money Matrix

TOKEN NOTATIONAL HYBRID

FIDUCIARY ◼ CASH ACCOUNT
◼ ◼

◼ WITH GOVERNMENT
GOVERNMENT CENTRAL CHECK
BEARER BANK
BOND
SCRIPTURAL ◼ CERTIFIED ◼ BANK ◼ PERSONAL
CHECK ACCOUNT CHECK
◼ TRAVELER’S ◼ FREQUENT ◼ GIFT
CHECK FLYER MILES CERTIFICATE
Specialized Payment
Instruments
◼ Money order (allows named person to claim money)
◼ Traveler’s check (limited to one spender)
◼ Gift certificate (limited to one merchant)
◼ Coupons, food stamps (limited to certain goods)
◼ Bill of lading (sight draft), letter of credit
❑ Purpose: atomicity (connect goods and payment)
 Ecommerce Payment Ranges
Minimum Typical Maximum
AMOUNTS IN USD Transaction Transaction Transaction
Value Value Value

Macro $100 $1000 

Mini $1 $10 $100

Micro $0.01 $0.1 $1

SOURCE: COMPAQ CORP.

 Objective of Payment Systems
◼ To allow the payee to obtain money, fiduciary or its
equivalent
❑ Usually in his bank account (convertible to fiduciary)
❑ Cash is rare except for low-value face-to-face payments
❑ How does the money get into the bank account?
◼ Payment in real money is called settlement
◼ Most payments are not settled individually
❑ Example: bank checks, ATM withdrawals – too small for
separate transfers of funds; batched for efficiency
◼ Batching to determine how much money must be paid
is called clearance or clearing
◼ Payment systems must provide for both clearance
and settlement
 Credit Card Transaction
1. BUYER TENDERS CREDIT CARD INFO TO SELLER

BUYER SELLER
6. SELLER SHIPS GOODS TO BUYER
2. SELLER TRANSMITS
PAYMENT DATA TO
11. BUYER PAYS 10. BUYER’S BANK
8. SELLER’S BANK SELLER’S BANK
BUYER’S BANK SENDS BILL TO 5. SELLER’S BANK
CREDITS SELLER’S
USING SOME BUYER NOTIFIES SELLER
ACCOUNT
OTHER METHOD
OF PAYMENT 7. END OF DAY,
SELLER UPLOADS
3. SELLER’S BANK
COMPLETED
ASKS BUYER’S BANK
TRANSACTIONS
FOR AUTHORIZATION
TO BANK
BUYER’S SELLER’S
BANK BANK
4. BUYER’S BANK
AUTHORIZES/REJECTS

9. BUYER’S BANK PAYS

SELLER’S BANK
CLEARANCES: SETTLEMENTS:
2. HOW MUCH SHOULD SELLER GET? HOW? 7. SELLER GETS PAID
-- HOW MUCH SHOULD EACH BANK GET/PAY? HOW MUCH? 9. SELLER’S BANK GETS PAID
10. HOW MUCH SHOULD BUYER’S BILL BE? 11. BUYER’S BANK GETS PAID
Vấn đề trong thanh toán
◼ Làm thế nào để người trả biết phải trả bao nhiêu?
(bill presentment, invoicing)
◼ Cơ chế nào được sử dụng để “trả tiền” (payment)?
◼ Khi nào thanh toán sẽ được thực hiện (trước, trong, sau)
◼ Làm thế nào các khoản thanh toán sẽ được điều chỉnh?
(clearance)?
◼ Làm thế nào người thụ hưởng nhận được tiền thật
(settlement-kết toán)?
◼ Làm thế nào người thụ hưởng ghi nợ người trả
(reconciliation)?
◼ Những hồ sơ nào mỗi bên phải lưu giữ (audit)?
◼ An toàn (Security) cho các vấn đề trên
❑ Chứng thực các bên
❑ Phòng chống giả mạo (prevention of forgery)
Hệ thống thanh toán theo thời gian
◼ Hệ thống trả trước - Prepaid Systems (Bank access before
transaction)
❑ Cash
❑ Octopus, phone card
❑ Bank stored-value cards (GeldKarte)
◼ Hệ thống trả nay - Instant-Paid Systems (Access during
transaction)
❑ Debit card – Thẻ ghi nợ
◼ Hệ thống trả sau - Post-Paid Systems (Access after transaction
= credit – tín dụng)
❑ Credit card, EZPass, Speedpass
❑ Checks & electronic forms, eChecks
❑ Commercial invoice
◼ Có sự khác biệt lớn trong rủi ro, xác thực, chi phí
Vài phương thức “Thanh toán”
◼ Cash
◼ Check
◼ Point-of-sale (POS) debit
◼ ATM
◼ Credit transfer (giro), automated clearing house
(ACH) – Trung tâm thanh toán bù trừ tự động
◼ Interbank transfer (EFT – electronic funds transfer
– chuyển tiền điện tử)
◼ Credit cards – Thẻ tín dụng
◼ Payment cards, smart cards (Octopus, Mondex)
Vài phương thức “Thanh toán”
◼ Mobile payment (Paybox)
◼ Accumulating balance – số dư tích luỹ, e.g. Valista
iPin
◼ Intermediaries, peer-to-peer (P2P), PayPal
◼ Scrip systems (micropayments-thanh toán nhỏ lẻ)
◼ Loyalty systems (Flooz, Beenz -- now bankrupt)
◼ Electronic cash (eCash), digital currency
◼ Crypto Currency (bitcoin)
System Issues
◼ Physical support (smart card, files, encrypted strings)
◼ Value representation (denominations – mệnh giá,
numbers)
◼ Location of value store (bank, electronic wallet)
◼ Discharging power (who accepts it?)
◼ Mode of use (remote, face-to-face)
◼ Methods of payment (credit transfer)
◼ Genuineness – Trung thực (is it valid? stolen?
double-spent?)
◼ Authentication – xác thực (of user)
◼ Traceability – theo vết (anonymity, privacy)
◼ Scalability – khả năng mở rộng, cost
Desired Properties of Money
◼ Universal acceptance
◼ Transferability, portability
◼ Safety (unforgeable – giả mạo, unstealable –
trôm cắp)
◼ Privacy (no one except parties know the amount)
◼ Anonymity (no one can identify the payor)
◼ Work off-line (no need for on-line verification)
◼ Divisible into change (pay for $10 item with $100
bill)
◼ Arbitrary denominations – mệnh giá linh động
(e.g. $325.14)
Costs of Money
◼ Time
◼ Risk
◼ Physical cost (print currency, mint coins)
◼ System infrastructure
◼ Processing cost (transactions)
◼ Security
◼ Human time
◼ Law enforcement
B2B Payments
◼ High dollar value
◼ Tied to paperwork
❑ Requisitions, authorization, purchase order, shipping
documents
◼ Financial controls, auditing
◼ Connection with legacy ERP and accounting
systems
◼ Cash management
◼ International issues
❑ Customs documents, foreign currency
B2B Payments
Buyer Supplier
Order
• Procurement • Order Mgmt
• Receipt Status Order Confirmation • Fulfillment
• Reconciliation • Credit and
and Payment Advance Shipping Notice Collections
• Financing/ • Financing/
Cash Mgmt Invoice
Cash Mgmt

Letter of Credit/ Payment Guarantee/

Escrow/ Financial Insurance/
Line of Credit/ Institution Trade Finance/
Risk Management Risk Management
Cash Cash
Payment Receipt
Details Logistics Providers
Proof of Delivery Packing List Details
• Order Mgmt
Shipping Invoice • Credit/ Collections Proof of Delivery Cash
• Financing/ Cash Mgmt Shipping Invoice Payment
Details
Payment Payment (Shipping
Cash Receipt Details
Authorization Authorization Charges)
Logistics (Shipping
Provider Charges)
Bank
Buyer Cash Account Cash Supplier
Bank Bank
Account Cash Account

SOURCE: TRADECARD
Goods Move Faster Than Money
 Bill of Lading (B/L) Transaction
PURPOSE: LINK PAYMENT TO SHIPMENT

1. BUYER SENDS SIGHT DRAFT TO SELLER

(ORDER TO BANK TO PAY ON SIGHT WHEN
ALSO PRESENTED WITH B/L
BUYER SELLER
2. SELLER DELIVERS 6. SELLER’S BANK
8. BUYER PRESENTS GOODS TO CARRIER; CREDITS SELLER’S
B/L, CLAIMS GOODS CARRIER GIVES B/L ACCOUNT, NOTIFIES
4. SAILING SELLER
7. BUYER’S BANK LANDING CARRIER
DEBITS BUYER’S DOCK
ACCOUNT, GIVES
B/L TO BUYER

3. SELLER SENDS B/L WITH

DRAFT TO BUYER’S BANK

BUYER’S SELLER’S
BANK BANK
5. BUYER’S BANK PAYS
DRAFT TO SELLER’S BANK

CARRIER IS AN ESCROW AGENT. IF B/L IS NOT PRESENTED, GOODS WILL NOT BE DELIVERED.
IF SELLER NEVER SHIPS GOODS, THERE WILL BE NO B/L AND BUYER’S BANK WILL NOT PAY
Major Ideas
◼ Money classifications
❑ Token v. notational (what form does it take?)
❑ Fiduciary v. scriptural (government or issuer-based)
❑ Prepaid, Instant-Paid, Postpaid
◼ Payment methods
◼ Cash is very expensive to use
◼ B2B payments are complex
◼ Atomicity between shipments and payments is
difficult to achieve
Q&A
Payment Risks
◼ ALL RISK HAS COST
❑ Suffering loss has cost

❑ Protecting against loss has cost

◼ System design must respond to risk posture

(willingness to accept various kinds of risk)
◼ Transferable v. non-transferable risk
❑ Insurance

❑ Hedging

◼ Example tradeoff: open v. closed payment

networks
Payment Risks
System design must respond to risk posture
◼ Operational (reliability and integrity)
❑ Security (unauthorized access)

❑ Employee fraud

❑ Counterfeiting (ecash)

❑ System design, implementation, maintenance

❑ Customer misuse

❑ Service provider risk

❑ System obsolescence

❑ Transaction repudiation by customer

Payment Risks
◼ Reputational
❑ Negative public opinion → loss of business

◼ Bank of New York Russian money laundering

◼ Lose both legitimate customers AND launderers
❑ System deficiencies
❑ Security breach

❑ Failure of similar systems

◼ Systemic
❑ Risk that failure to meet an obligation spreads
through the system, causing others to fail to
meet obligations
Payment Risks
◼ Legal
❑ Violation of law, ambiguity, legal sanctions

❑ Money laundering

❑ Inadequate disclosure

❑ Violation of privacy

❑ Violation by linked site

❑ Certificate authority risk

❑ Foreign law
Payment Risks
◼ Banking
❑ Credit (non-payment, insolvency)

❑ Liquidity (demand for redemption of ecash)

❑ Interest rate (spread)

❑ Market (inflation, foreign exchange)

❑ Cross-border (social, political, economic)

◼ Crime
❑ Fraud, forgery

❑ Theft

❑ Kiting (illegal use of float)

Chương 2: Banking System
ThS Phạm Mạnh Cường
Outline
◼ Vai trò của Ngân hàng
◼ Vai trò luân chuyển tiền tệ
◼ Trao đổi ngoại hối (Foreign exchange)
 Hệ thống ngân hàng thế giới
Các ngân hàng tư nhân Các ngân hàng tư nhân Các ngân hàng tư nhân
& các tổ chức tín dụng & các tổ chức tín dụng & các tổ chức tín dụng

NHTW thuộc sở hữu hỗn hợp NHTW thuộc sở hữu chính phủ
NHTW thuộc sở hữu tư nhân
Bỉ Ngân hàng Pháp
Cục dự trữ liên bang Hoa Kỳ
Ngân hàng Nhật Bản Ngân hàng Anh

Quỹ tiền tệ quốc tế

Ngân hàng thanh toán quốc tế
(PUBLIC POLICY LENDER $300B)
(A BANK FOR 45 CENTRAL BANKS, $130B)
182 MEMBER COUNTRIES
BASEL, SWITZERLAND
WASHINGTON, DC

SOURCE: TRANSACTION.NET
Ngân hàng trung ương
◼ Tiền hợp pháp (tiền thật) được ban hành bởi các
ngân hàng trung ương có thẩm quyền
❑ Chính phủ sở hữu

❑ Sở hữu Tư nhân

❑ Sở hữu liên kết giữa Tư nhân và chính phủ

◼ Các ngân hàng khác không thể phát hành tiền

hợp pháp.
◼ Các ngân hàng khác phải duy trì tài khoản trong
ngân hàng trung ương.
◼ Các ngân hàng thực hiện giao dịch chuyển tiền
thực thông qua ngân hàng trung ương
Movement of Money
◼ World economic product ~$127T
❑ Time to circulate $30T ~ 6 days
◼ Money supply (U.S., July 31, 2001)
❑ M1 (spendable now; money for payments) $1.1T (liquid
= cash + non-interest deposits + travelers checks)
❑ M2 (M1+ short-term investments < $100K) $5.3T (M1 +
time deposits + money market funds)
❑ M3 (M2 + long-term investments) $7.7T (M2 + big
deposits: institutional money funds)
◼ Cash (U.S, July 31, 2001) $554B
❑ 0.1% counterfeit (in the U.S., only 0.03% is counterfeit)
❑ Over 70% held outside the U.S. (but counted in M1
because it can be spent in the U.S.)
The U.S. Money Supply
In billions on Currency 554
July 31, 2001 Non-bank travelers checks 9
Demand deposits 313
Other checkable deposits 260 .
M1 Total 1136
Savings 2087
Small time deposits <100K 1116 .
Retail money market funds 984
M2 Total 5323
Large time deposits >100K 812 .

Institutional money funds 986

Bank agreements 379
Eurodollars 197
M3 Total 7697 SOURCE: FEDERAL RESERVE
Function of Banks
◼ Central banks:
❑ Issue fiduciary money (both token and
notational)
◼ All other (non-central) banks:
❑ Issue notational scriptural money (bank
accounts)
◼ Not fiduciary (“real money”), not token
◼ Non-central banks
❑ Move notational money

❑ Accept deposits (loans from depositors)

❑ Loan deposits to others (borrowers)

 What is a Bank Account?
◼ Notational representation of a loan to the bank
from a depositor
◼ Once the depositor puts money in his account, it
becomes the bank’s money, not the depositor’s
◼ When the bank deposits its money in the central
bank, it becomes fiduciary (real) money
◼ The bank then owes the depositor real money
◼ Effect of deposit: bank ends up with more real
money
I HAVE $800. BANK HAS
I DEPOSIT BANK DEPOSITS $200
I HAVE BANK OWES $200 MORE
$200 IN THE IN CENTRAL BANK
$1000 ME $200 (MY MONEY NOW
BANK
“ACCOUNT”)
BANK’S ASSETS:
MY ASSETS:
MY ASSETS: +$200 REAL MONEY
$1000 CASH
$800 CASH - $200 DEBT
+$200 OWED BY BANK
Benefit of a Bank Deposit
◼ Bank can
❑ loan the money (more than was deposited!)

❑ invest the money

❑ move the money, e.g. make payments

❑ buy foreign currency with the money

 Payment Orders (Checks)
CHECK
DATE NUMBER
MAKER (DRAWER)

PAYEE
AMOUNT

CURRENCY

DRAWEE
BANK

DRAWEE BANK
ACCOUNT NUMBER AUTHORIZED
NUMBER
SIGNATURE OF
MAKER’S AGENT
THIS CHECK IS AN ORDER TO MELLON BANK TO
PAY $100 TO PAYEE OR HIS TRANSFEREE FROM
THE CARNEGIE MELLON UNIVERSITY ACCOUNT
Checks
◼ U.S. -- 63 billion checks per year, average $1100
◼ 80% of noncash payments made by check
◼ “On-Us” (payor and payee in same bank -- 30%)
◼ Interbank (payor and payee in different banks) --
requires settlement
❑ Direct sends(Direct presentment)

❑ Correspondent banks

❑ Clearing house associations (150)

❑ Federal Reserve system (15 billion

checks/year, 27%)
◼ Complex laws re bank liability in check
processing
 Check Processing
“On-Us”

Check Check
Deposit
Ticket
Encode Sort/Balance Deposit
Ticket

BANK A’S
DEPOSITS

Clearing Check
Cash
House Letter

Check
“Clearing
Cash
House” Letter
OTHER BANKS
“Direct
Sends”

BANK B SOURCE: PNCBANK

 Clearing Payment Orders
(Check)
1. CMU SENDS CHECK TO SHAMOS
CUSTOMER CMU CUSTOMER SHAMOS
OF MELLON BANK “PAY SHAMOS $100” OF CITIBANK
9. MELLON SENDS 2. SHAMOS DEPOSITS
CHECK BACK TO CMU CHECK AT CITI

MELLON BANK 8. CLEARING HOUSE CITIBANK

SENDS CHECK TO
4. CITI SENDS CHECK
MELLON
TO CLEARING HOUSE
CUSTOMER A CUSTOMER A
CUSTOMER CMU -100 CLEARING HOUSE CUSTOMER B
... (FEDERAL RESERVE) ...
CUSTOMER Y SHAMOS +100
MELLON -100
CUSTOMER Z CUSTOMER Z
BANK A
7. MELLON 6. CLEARING ... 3. CITIBANK CREDITS
DEDUCTS $100 HOUSE SENDS SHAMOS WITH $100
BANK Z
FROM CMU MELLON
ACCOUNT DEBIT INFO CITIBANK +100

5. CLEARING HOUSE ADDS $100 TO CITI,

SUBTRACTS $100 FROM MELLON
 Settling Payment Orders
(Checks)
1. AT END OF DAY, EACH 2. BANKS WITH NEGATIVE
BANK HAS A NET POSITIVE REAL-TIME GROSS BALANCES MUST PAY;
OR NEGATIVE CLEARING SETTLEMENT SYSTEM THOSE WITH POSITIVE
HOUSE BALANCE (FEDWIRE) BALANCES RECEIVE
MELLON +34,299,321 MONEY
BANK A
6. CLEARING HOUSE PAYS ... 4. CITI PAYS THE CLEARING
MELLON $34,299,321 BANK Z HOUSE THROUGH RTGS

CITIBANK -107,071,775
MELLON BANK CLEARING CITIBANK
+107,071,775
HOUSE

CUSTOMER A -15085 CUSTOMER A +2786

CUSTOMER CMU +3167 CLEARING HOUSE CUSTOMER B -988713
... (FEDERAL RESERVE) ...
CUSTOMER Y +728103 SHAMOS +100
MELLON +34,299,321
CUSTOMER Z +35529 CUSTOMER Z -31872
BANK A
5. CLEARING HOUSE ADVISES ... 3. CLEARING HOUSE INFORMS
MELLON IT WILL BANK Z CITI IT MUST PAY $107,071,775
RECEIVE $34,299,321
CITIBANK -107,071,775
 Electronic Clearing
MAKER (DRAWER) DATE CHEQUE The paper cheque is just
NUMBER
PAYEE
a carrier of information.
AMOUNT
Electronic transmission is
CURRENCY
DRAWEE better.
BANK
AUTHORIZED
DRAWEE BANK SIGNATURE OF We dematerialize the cheque
DRAWER MAKER’S AGENT
NUMBER
ACCOUNT
(remove the paper).
NUMBER

06130018184310143700000000100000USD061200356425020010130
DRAWEE DRAWER CHECK AMOUNT CURRENCY PAYEE PAYEE DATE
BANK ACCOUNT NUMBER BANK ACCOUNT
NUMBER NUMBER NUMBER NUMBER

Only the information is sent to the clearing house

Foreign Exchange
◼ Currency = token fiduciary money of a central bank
◼ Every bank account is denominated in one currency
◼ Most banks allow accounts in only one currency
◼ All currencies have three-letter ISO currency codes:
❑ USD (U.S. dollar) JPY (Japan yen)
❑ GBP (Great Britain pound) CHF (Swiss franc)
❑ HKD (Hong Kong dollar) EUR (Euro)
◼ Usually, the first two letters indicate the country; third letter
is the first letter of the currency name
◼ Foreign exchange is a barter transaction
❑ To buy GBP for USD, buyer has to find someone with GBP
who wants USD
Foreign Exchange
◼ Every bank must have an account at the central
bank (or with another bank that has one)
◼ The account is (usually) denominated in that
country’s currency and is used to settle
obligations in that currency
◼ A foreign exchange transaction requires two
settlements, one in each currency
◼ Therefore, two countries’ central banks are
involved
Foreign Exchange Example
◼ Bank B (buyer) in the U.S. buys 1 million GBP for
1.44 million USD from Bank S (seller) in the UK
◼ Bank B must have an account denominated in
GBP somewhere, probably at Bank C in the UK
◼ Bank S must have an account denominated in
USD somewhere, probably at Bank T in the US
Foreign Exchange Example
BANK T (US)
US BANKS (NOSTRO ACCOUNT)
BANK S (UK)
BANK S WILLING TO SELL
BANK B (US) USD ACCOUNT BANK C (UK) 1 MILLION GBP
WANTS TO BUY FOR USD
1 MILLION GBP (NOSTRO ACCOUNT) BANK B
FOR USD GBP ACCOUNT
UK BANKS

US FEDERAL THE BANK

RESERVE BANK OF ENGLAND
BANK B USD ACCOUNT BANK S GBP ACCOUNT
BANK T USD ACCOUNT BANK C GBP ACCOUNT

SETTLEMENT ONE: SETTLEMENT TWO:

BANK B TRANSFERS BANK S TRANSFERS
1.44 MILLION USD TO 1 MILLION GBP TO BANK
BANK T BY FEDWIRE C BY CHAPS (BOE RTGS)

SELLER S NOW HAS 1.44 BUYER B NOW HAS 1

MILLION USD IN BANK T MILLION GBP IN BANK C
The Euro – A Basket Currency
◼ Single currency for 11 European countries
◼ Issued by the European Central Bank (ECB)
◼ 1 euro (EUR) =
❑ 1.95583 DEM (German deutschmark)
❑ 6.55957 FRF (French franc)
❑ 1936.27 ITL (Italian lira)
❑ 166.386 ESP (Spanish peseta)
❑ 2.29371 NLG (Netherlands guilder)
❑ 40.3399 BEF (Belgian franc)
❑ 13.7603 ATS (Austrian schilling)
❑ 200.482 PTE (Portuguese escudo)
❑ 5.94573 FIM (Finnish markka)
❑ 0.787564 IEP (Irish punt)
❑ 40.3399 LUF (Luxembourg franc)
 Thanh toán Điện tử
Trong Thương mại Điện tử

Automated Clearing and

Chương 3:

Settlement Systems
Sự kiện Blockchain Hub

https://tienmahoa.net.vn https://goo.gl/hbTYpF
 Bù trừ điện tử -Electronic Clearing
MAKER (DRAWER) DATE CHECK
NUMBER The paper check is just
PAYEE a carrier of information.
AMOUNT

CURRENCY
Electronic transmission is
DRAWEE
BANK better.

DRAWEE BANK
DRAWER
AUTHORIZED
SIGNATURE OF
We dematerialize the check
NUMBER
ACCOUNT MAKER’S AGENT (remove the paper).
NUMBER

06130018184310143700000000010000USD06520035
DRAWEE DRAWER CHECK AMOUNT CURRENCY PAYEE PAYEE DATE
BANK ACCOUNT NUMBER 6425020010130 BANK ACCOUNT
NUMBER NUMBER NUMBER NUMBER

Chỉ thông tin được gửi đến trung tâm thanh toán bù trừ
Automated Clearing House (ACH)
Trung tâm thanh toán bù trừ tự
động
◼ Hệ thống thanh toán bù trừ điện tử
◼ Giao dịch được thực hiện theo lô (batch)
◼ Các Ngân hàng gửi giao dịch thanh toán đến ACH
◼ Các giao dịch được xử lý theo lô và chuyển kết quả bù trừ
cho các Ngân hàng
◼ Thực hiện định kỳ (ở Mỹ 1 giờ một lần, Hàn Quốc 1 lần
mỗi ngày).
◼ Hàng ngày thực hiện Kết toán (settlement) thông qua hệ
thống RTGS (Real Time Gross Settlement).
◼ Báo có trong vòng 1 đến 2 ngày làm việc.
◼ Chi phí thông thường (theo bên Mỹ) : $0.02 mỗi giao dịch;
phí thì cao hơn
Giao dịch không dùng tiên mặt của mỗi cá nhân

Annual Annual Percentage

Country Paper-based Electronic Electronic Payments

Switzerland 2 65 97%
Netherlands 19 128 87
Belgium 16 85 84
Denmark 24 100 81
Japan 9 31 78
Germany 36 103 74
Sweden 24 68 74
Finland 40 81 67
United Kingdom 7 58 50
France 86 71 45
Canada 76 53 41
Norway 58 40 41
Italy 23 6 20
United States 234 59 20
SOURCE: CHARLIE COOK
ACH Credit Transaction
1. BUYER SENDS
AN ORDER TO
BUYER’S BANK TO BUYER
CREDIT $X TO SELLER
SELLER’S ACCOUNT
6. SELLER’S BANK
IN SELLER’S BANK
CREDITS SELLER’S
2. BUYER’S BANK ACCOUNT WITH $X
SENDS TRANSACTION
TO AUTOMATED
BUYER’S CLEARINGHOUSE SELLER’S
BANK BANK

4. BUYER’S BANK
PAYS $Y TO
SETTLEMENT BANK

SETTLEMENT CLEARINGHOUSE
BANK
3. CLEARINGHOUSE DETERMINES THAT
5. SETTLEMENT BANK
BUYER’S BANK OWES SELLER’S BANK $Y
PAYS $Y TO
(ALL TRANSACTIONS ARE NETTED)
SELLER’S BANK
ATM and Debit Networks

SOURCE: U.S. BANCORP

Debit Card Authorization

• A IS MERCHANT’S BANK; B IS CUSTOMER’S BANK

• A AND B BELONG TO DIFFERENT REGIONAL ATM
NETWORKS ON THE SAME NATIONAL NETWORK
• DEBIT IS IMMEDIATE WHEN BANK B AUTHORIZES

SOURCE: HAYASHI, WORLD BANK

 Debit Card Settlement
1. NATIONAL NETWORK CLEARS FOR ITS REGIONAL NETWORKS,
SETTLES REGIONAL NETWORK’S ACCOUNTS IN CENTRAL BANK
2-3. REGIONAL NETWORK CLEARS FOR ITS MEMBERS THROUGH
NETWORK’S CLEARING BANK
4-5. ACH OPERATOR FOR REGIONAL NETWORK INITIATES DEBITS
AND CREDITS TO REGIONAL BANKS THROUGH ACH

SOURCE: HAYASHI, WORLD BANK

Vai trò của Ngân hàng Nhà
nước
◼ Hệ thống Thanh toán Ngân hàng Việt Nam
(HTTT NHNN BuiQuangTien 2008.pdf)
◼ Banknetvn
◼ Smartlink
Smartlink
◼ Smartlink để thực hiện việc truyền dẫn, trao
đổi và xử lý trung gian các giao dịch điện tử
tự động giữa người sử dụng với các đơn vị
cung ứng hàng hóa, dịch vụ, các ngân hàng
thành viên và các tổ chức khác
◼ Xử lý giao dịch ATM/POS
◼ Payment Gateway
Banknetvn
◼ Hệ thống Chuyển mạch Banknetvn được
thiết lập cho phép thực hiện các chức năng
cơ bản của một hệ thống chuyển mạch tài
chính quốc gia chung, bao gồm: Xử lý
chuyển mạch các giao dịch thẻ, thanh toán
bù trừ, quyết toán các giao dịch thẻ,...
◼ Hệ thống Chuyển mạch Banknetvn là hệ
thống được thiết lập để kết nối và chia sẻ
dùng chung các mạng lưới thanh toán thẻ
ATM/POS của các ngân hàng Việt Nam
U.S. Electronic Payment Volumes
(2000)
NUMBER VALUE AVG. VAL.
ACH 6,900 M 20,300 B $ 2,942
ATM 13,200 M 800 B $ 60
CREDIT CARD 20,000 M 1,400 B $70
DEBIT CARD 9,300 M 400 B $ 43
FEDWIRE 108 M 379,756 B $ 3,516,000
CHIPS 58 M 292,147 B $ 5,040,000
TOTAL 49,566 M 694,803 B $ 14,018

SOURCE: NACHA
Electronic v. Traditional Payments (U.S., 2000)

NUMBER (B) VALUE (T) AVG.

VAL.
ELECTRONIC 49.5 (7.4%) 695 (88.9%) $ 14,018
CHECK 69 (10.3%) 85 (10.9%) $ 1,232
CASH 550 (82.3%) 2.2 (0.3%) $4
TOTAL 669 782 $ 1,169

2400 TRANSACTIONS USD 2.8M

PER PERSON PER PERSON
SOURCE: NACHA
6.6 PER PERSON USD 7700
PER DAY PER PERSON
PER DAY
Các ý chính
◼ Trung tâm thanh toán bù trừ - Automated
clearing house
◼ Qui trình giao dịch ATM / POS
◼ Qui trình xử lý thẻ ghi nợ (Debit card)
Chương 4: ePayment Security

ThS Phạm Mạnh Cường

Vấn đề của thanh toán trực
tuyến
Đặc tính của giao dịch trực tuyến

Thực hiện từ xa, người mua/bán không gặp mặt

Rất khó xác nhận người nào đã thực hiện giao dịch

Khó mà chứng minh “giao dịch đã thực hiện”

❑ Rủi ro liên quan đến giao dịch và thông tin tài khoản cá nhân
❑ Rất khó bảm đảm tính toàn vẹn của thông tin được truyền
❑ Dễ tạo các tài liệu giả mạo
CASE STUDY

Office B need to make withdrawals with Bank A

Customers have to take

?
$ 5,000,000 place to trade. OK !

Sent by email Sender: Offfice B

Sender: Offfice B
Receiver: Bank A Receiver: Bank A
Sent date:
Content:
15/10/2010 Sent date:
Content:
……..
?
15/10/2010

……..
Withdrawal $5,000,000 Withdrawal $5,000,000
Account number: NHB- Account number: NHB-
212551245 212551245
Offfice B Bank A
… .... … .... Send
Gửi
Vấn đề của thanh toán trực
tuyến
◼ Các lỗ hổng bảo mật
❑ Mất cắp thông tin cá nhân và thông tin giao
dịch thẻ
❑ Vi phạm thông tin cá nhân
❑ Hacker/Trộm cắp thông tin tài khoản trên
Internet
❑ Trôm cắp tên truy nhập và mật khẩu
➔Cần giải pháp bảo mật hiệu quả
 An toàn trong Thanh toán điện tử
◼ Bảo mật thông tin (Privacy): Đảm bảo thông tin thanh toán
được giữ bí mật đối với đối tượng không được phép.
❑ CRYPTOGRAPHY – Mã hoá
◼ Toàn vẹn thông tin (Integrity): bảo đảm tính toàn vẹn
thông tin trong liên lạc hoặc giúp phát hiện rằng thông tin
đã bị sửa đổi.
❑ HASH FUNCTIONS – Hàm băm
◼ Xác thực (Authentication): xác thực các đối tác trong liên
lạc và xác thực nội dung thông tin trong liên lạc.
❑ PASSWORDS, DIGITAL CERTIFICATES – Mật khẩu, chứng thư số
◼ Chống lại sự thoái thác trách nhiệm (Non-repudiation): đảm
bảo một đối tác bất kỳ trong hệ thống thanh toán không thể
từ chối trách nhiệm về hành động mà mình đã thực hiện.
❑ DIGITAL SIGNATURES – Chữ ký số
Đối chiếu với sơ đồ OSI
OSI 7 Layer
PKI related product
Application Layer Digital Signature
Encryption/
Presentation Layer PKI toolkit Decryption
SSL Certificate

Session Layer
VPN

Transport Layer Protocols IDS

Firewall

Network Layer Router / Switch

Data Link Layer Topology, Flow control

Network adapter

Physical Layer Cable

Sơ đồ bảo mật đơn giản

First Second Third Fourth

Defense Defense Defense Defense
Intrusion

Firewall IDS Application Data

(Intrusion Detection Server protection Protection
System)
 Protect  Network traffic  Security for  2048bit/
intrusion filtering access 128bit
from the  Clear  Log encryption
outside monitoring management ( RSA/AES )
the wall  Network control
 Giải pháp chống tấn công

Phương pháp
Vấn đề Công nghệ sử dụng
bảo mật

Khó xác nhận Xác thực đối tượng Công nghệ chữ ký số
đối tượng tham gia tham gia (User authentication)

Dễ dàng để làm giả mạo hoặc Công nghệ chữ ký số

Bảo đảm tính toàn vẹn
sửa đổi về nội dung (Message authentication)

Chống lại sự thoái thác Công nghệ chữ ký số

Phủ nhận các giao dịch
trách nhiệm (Message authentication)

Công nghệ mã hoá

Vi phạm thông tin Bảo mật
(Message authentication)
Tiêu chuẩn Việt Nam bắt buộc
◼ Mã hóa bất đối xứng và chữ ký số:
❑ PKCS #1: RSA Cryptography Standard
❑ Phiên bản 2.1
◼ Mã hóa đối xứng (Symmetric encryption)
❑ FIPS PUB 197: Advanced Encryption Standard (AES)
❑ FIPS PUB 46-3: Data Encryption Standard (DES,
3DES)
◼ Hàm băm bảo mật (Hash)
❑ FIPS PUB 180-2: Secure Hash Standard: SHA-1, SHA-
256, SHA-384, SHA-512
Một số thuật ngữ
◼ Giao dịch điện tử là giao dịch được thực hiện
bằng phương tiện điện tử
◼ Giao dịch điện tử tự động là giao dịch được
thực hiện tự động từng phần hoặc toàn bộ
thông qua hệ thống thông tin được thiết lập
sẵn.
◼ Hệ thống thông tin là hệ thống được tạo lập
để gửi, nhận, lưu trữ, hiển thị hoặc thực hiện
các xử lý khác đối với thông điệp dữ liệu
Một số thuật ngữ
◼ Thông điệp dữ liệu là thông tin được tạo ra,
được gửi đi, được nhận và được lưu trữ
bằng phương tiện điện tử.
◼ Trao đổi dữ liệu điện tử (EDI – electronic
data interchange) là sự chuyển thông tin từ
máy tính này sang máy tính khác bằng
phương tiện điện tử theo một tiêu chuẩn đã
được thỏa thuận vê câu trúc thông tin.
Hàm Hash (Băm)
◼ Hàm băm (Hash function) là một hàm toán học chuyển
đổi một thông điệp đầu vào có độ dài bất kỳ thành một
dãy bit có độ dài cố định (tuỳ thuộc vào thuật toán băm).
Dãy bit này được gọi là thông điệp rút gọn (message
digest) hay giá trị băm (hash value), đại diện cho thông
điệp ban đầu.
 Hash Functions
Hàm băm (hash function) là hàm một chiều mà nếu đưa một lượng
dữ liệu bất kì qua hàm này sẽ cho ra một chuỗi có độ dài cố định ở
đầu ra.
Vùng thông điệp
(Các thông điệp thường là dạng text)

Vùng HASH
“Chuyển 5.000.000
đồng vào
• (Thông điệp đã bị băm)

tài khoản của tôi”

• •
• •
• ? Không thể
•
dịch ngược

•
“AF0E891B293”
Hàm Hash một chiều (One-
Way)
◼ Với bất kỳ thông điệp s, gọi hash của s là H(s), H(s)
có độ dài cố định (thường ngắn hơn s) còn được gọi
là bản tóm tắt của thông điệp (message digest)
◼ Tính một chiều: không thể suy ra dữ liệu ban đầu từ
kết quả, điều này tương tự như việc bạn không thể
chỉ dựa vào một dấu vân tay lạ mà suy ra ai là chủ
của nó được.
◼ Tính duy nhất: xác suất để có một vụ va chạm (hash
collision), tức là hai thông điệp khác nhau có cùng
một kết quả hash, là cực kỳ nhỏ.
Hàm Hash một chiều (One-
Way)
◼ Chỉ cần thay đổi một ký tự của thông điệp s thì hàm
hash mới sẽ khác nhiều với hàm cũ
❑ Từ "Illuminatus" đi qua hàm SHA-1 cho kết quả :

E783A3AE2ACDD7DBA5E1FA0269CBC58D
❑ Từ "Illuminatis" đi qua hàm SHA-1 cho kết quả :

A766F44DDEA5CACC3323CE3E7D73AE82
Ứng dụng củs hàm Hash
◼ Xác thực mật khẩu
◼ Xác thực thông điệp (Message authentication –
Thông điệp tóm tắt -message digests)
◼ Bảo vệ tính toàn vẹn của tập tin, thông điệp được
gửi qua mạng.
◼ Tạo chữ ký điện tử (Digital signatures)
Hàm hash SHA-1

◼ Secure Hash Algorithm (SHA) do Viện Tiêu

chuẩn và Công nghệ quốc gia của Mỹ
(NIST) và Cục an ninh quốc gia Mỹ (NSA)
phát minh năm 1995 và trở thành chuẩn bảo
mật cơ sở phổ biến nhất trên Internet.
◼ Thông điệp được xử lý theo từng khối 512
bit.
◼ Thông điệp rút gọn còn độ dài 160 bit.
 Mật mã học (Cryptography)
MESSAGE SPACE CODE SPACE
(ALL POSSIBLE (ALL POSSIBLE
PLAINTEXT MESSAGES) ENCRYPTED MESSAGES)

“TRANSFER
$5000 TO MY
• •
•
Có thể chuyển ngược lại
SAVINGS (Chỉ khi biết
ACCOUNT” khóa bí mật))

•
•
• •
•
• •
“1822UX S4HHG7 803TG
0J71D2 MK8A36 18PN1”
 Mật mã học (Cryptography)
MESSAGE SPACE CODE SPACE
(ALL POSSIBLE (ALL POSSIBLE
ENCRYPTION IS SECURE IF ENCRYPTED MESSAGES)
PLAINTEXT MESSAGES) ONLY AUTHORIZED PEOPLE
KNOW HOW TO REVERSE IT

“TRANSFER
$5000 TO MY
• •
SAVINGS
ACCOUNT” •
•
•
• •
•
• •
ENCRYPTION IS ONE-TO-ONE “1822UX S4HHG7 803TG
AND REVERSIBLE 0J71D2 MK8A36 18PN1”
EVERY CODE CORRESPONDS
TO EXACTLY ONE MESSAGE
Mật mã học (Cryptography)
◼ Cryptography giúp đảm bảo những tính chất
sau cho thông tin:
❑ Tính bí mật (confidentiality): thông tin chỉ được tiết
lộ cho những ai được phép.
❑ Tính toàn vẹn (integrity): thông tin không thể bị
thay đổi mà không bị phát hiện.
❑ Tính xác thực (authentication): người gửi (hoặc
người nhận) có thể chứng minh đúng là họ.
❑ Tính không chối bỏ (non-repudiation): người gửi
hoặc nhận sau này không thể chối bỏ việc đã gửi
hoặc nhận thông tin.
Data Encryption Standard (DES)
◼ Tiêu chuẩn mã hoá dữ liệu.
◼ DES là một phương pháp mật mã hóa được
FIPS (Tiêu chuẩn Xử lý Thông tin Liên bang Hoa
Kỳ) chọn làm chuẩn chính thức vào năm 1976.
◼ DES là thuật toán mã hóa khối, độ dài mỗi khối là
64 bit . nó xử lý từng khối thông tin của bản rõ có
độ dài xác định và biến đổi theo những quá trình
phức tạp để trở thành khối thông tin của bản mã
có độ dài không thay đổi.
Data Encryption Standard (DES)
◼ DES sử dụng khóa để cá biệt hóa quá trình
chuyển đổi. Nhờ vậy, chỉ khi biết khóa mới có thể
giải mã được văn bản mã.
◼ Khóa dùng trong DES có độ dài toàn bộ là 64 bit.
Tuy nhiên chỉ có 56 bit thực sự được sử dụng; 8
bit còn lại chỉ dùng cho việc kiểm tra.
◼ DES xuất ra bản mã 64 bit.
◼ Nhanh chóng thực hiện bằng phần cứng: 1
gigabit/second
Triple DES – 3DES
◼ Triple-DES chính là DES với hai chìa khoá
56 bit.

K1 K2 K3

Bản mã
Bản rõ
BLOCK 1
DES DES DES BLOCK 1
ENCRYPT DECRYPT ENCRYPT

• Nếu K1 = K2 = K3 chính là thực hiện 1 DES

Ứng dụng của DES
◼ DES thường được dùng để mã hoá bảo mật các
thông tin trong quá trình truyền tin cũng như lưu trữ
thông tin.
◼ Một ứng dụng quan trọng khác của DES là kiểm tra
tính xác thực của mật khẩu truy nhập vào một hệ
thống (hệ thống quản lý bán hàng, quản lý thiết bị
viễn thông,…), hay tạo và kiểm tính hợp lệ của một
mã số bí mật (thẻ internet, thẻ điện thoại di động trả
trước), hoặc của một thẻ thông minh (thẻ tín dụng,
thẻ payphone,…).
AES, thuật toán thay thế DES
◼ AES = Advanced Encryption Standard
◼ DES has weaknesses:
◼ slow (by modern standards)
◼ weak (can be broken by fast computers)
◼ NIST ran a competition to replace DES
◼ Winner: Rijndael, invented by Vincent Rijmen and
Joan Daeman (both male)
◼ No patenting allowed
◼ Round block cipher of similar structure to DES but
faster, more secure
AES
◼ Advanced Encryption Standard – Tiêu
chuẩn mã hoá tiên tiến.
◼ Thuật toán được thiết kế bởi hai nhà mật
mã học người Bỉ Joan Daemen và Vincent
Rijmen.
◼ AES được chấp nhận làm tiêu chuẩn liên
bang bởi Viện tiêu chuẩn và công nghệ
quốc gia Mỹ (NIST).
AES
◼ AES là thuật toán mã hóa khối đối xứng, độ dài
mỗi khối là 128 bit.
◼ Sử dụng khoá mã có độ dài 128, 192 và 256 bit.
◼ Độ dài của khối đầu vào và khối đầu ra đều là
128 bit.
AES
Bao gồm các bước:
1.Khởi động vòng lặp
1.AddRoundKey — Mỗi cột của trạng thái đầu tiên lần lượt được kết hợp
với một khóa con theo thứ tự từ đầu dãy khóa.
2.Vòng lặp
1.SubBytes — đây là phép thế (phi tuyến) trong đó mỗi byte trong trạng
thái sẽ được thế bằng một byte khác theo bảng tra (Rijndael S-box).
2.ShiftRows — dịch chuyển, các hàng trong trạng thái được dịch vòng
theo số bước khác nhau.
3.MixColumns — quá trình trộn làm việc theo các cột trong khối theo
một phép biến đổi tuyến tính.
4.AddRoundKey
3.Vòng lặp cuối
1.SubBytes
2.ShiftRows
3.AddRoundKey
Tại chu trình cuối thì bước MixColumns không thực hiện.
AES
Ứng dụng của AES
◼ Mã hoá dữ liệu trong thanh toán trực tuyến,
tính bảo mật cao.
◼ Mã hoá dữ liệu bảo mật trên ổ cứng, USB,
thiết bị lưu trữ,…
◼ Mã hoá thông tin truyền tải của hệ thống
mạng.
Chương 5: ePayment Security II
Outline
◼ Mã hóa khóa công cộng (Public-key
Cryptography).
◼ One-way trapdoor functions
◼ RSA
◼ Protocol Failure
 Public Key Encryption
Clear-text Input Cipher-text Clear-text Output
“The quick “The quick
brown fox “Py75c%bn&*)9|fDe^ brown fox
jumps over bDFaq#xzjFr@g5=&n jumps over
the lazy mdFg$5knvMd’rkveg the lazy
dog” Ms” dog”

Encryption Decryption

public private
Different but
Recipient’s mathematically Recipient’s
public key linked keys private key

SOURCE: ALBERTO PACE

One-Way Trapdoor Function
◼ A function that is easy to compute
◼ Computationally difficult to invert without knowing
the secret (the “trapdoor”)
◼ Easy to invert with the secret
◼ Example: f x (y) = x • y
◼ Given f x (y), it is difficult to find either x or y
◼ Given f x (y) and x (the secret), it is easy to find y:
y = x•y / x
◼ ANY one-way trapdoor function can be used in
public-key cryptography.
Trapdoor Functions for
Cryptogrpahy
◼ Alice wants to send message m to Bob
◼ Bob’s public key e is a parameter to the trapdoor
function fe(x)
◼ The inverse fe -1(y) is easy to compute knowing
Bob’s private key d but difficult without d
◼ Alice computes fe(m), sends it to Bob
◼ Bob computes fe -1(fe(m)) = m (easy if d is known)
◼ Eavesdropper Eve can’t compute m = fe -1(fe(m))
without the trapdoor d to find the inverse fe -1
◼ Symmetric encryption satisfies the trapdoor
criteria except that e and d are the same, so
neither can be made public
Rivest-Shamir-Adelman (RSA)
◼ It is easy to multiply two numbers but apparently
hard to factor a number into a product of two
others.
◼ Given p, q, it is easy to compute n = p • q
◼ Example: p = 5453089; q = 3918067
◼ Easy to find n = 21365568058963
◼ Given n, hard to find two numbers p, q with p • q
=n
◼ Now suppose n = 7859112349338149
What are p and q such that p • q = n ?
◼ Multiplication is a one-way function
◼ RSA exploits this fact in public-key encryption
RSA Encryption
◼ Select two large prime numbers p, q (e.g. 1024 bits)
◼ Let n = p • q
◼ Choose a small odd integer e that does not divide
m = (p - 1)(q - 1). Then find x with x(p-1)(q-1) = 1 (mod n)
◼ Compute d = e-1(mod m)
❑ That is, d • e gives remainder 1 when divided by m
❑ Then xe •d = x (mod n) (by Fermat’s “Little” Theorem)
◼ Public key is the pair (e, n)
◼ Private key is the pair (d, n)
◼ d cannot be calculated quickly from (e, n)
Still need p and q, which involves factoring n
RSA Encryption
◼ Message M is a number

◼ To encrypt message M using key (e, n):

◼ Compute E(M) = M e (mod n)

◼ To decrypt message E(M) using key (d, n):

◼ Compute D(E(M)) = E(M) d (mod n)

◼ Note that D(E(M)) = E(D(M)) = (M e)d (mod n)

= M e•d (mod n) = M
because e • d = 1 (mod m) and m = (p-1)(q-1)
Protocol Failure
◼ A “secure” cryptosystem is not secure if used carelessly
◼ Protocols must be followed carefully or a “protocol failure”
occurs
◼ Example: “common modulus” failure
◼ Bob and Carol have the same public-key modulus n with
encryption exponents eBOB and eCAROL having no common
factor
◼ Alice sends the same plaintext M to both Bob and Carol
◼ Bob gets yBOB = MeBOB mod n
◼ Carol gets yCAROL = MeCAROL mod n
◼ If Eve intercepts both, she can read the message
◼ WARNING: NEVER SEND THE SAME MESSAGE TWICE!
Protocol Failure
KNOWN QUANTITIES:
n
eBOB
◼ Eve computes: eCAROL
yBOB
c1 = eBOB-1 (mod eCAROL ) yCAROL
c2 = ((c1 eBOB) - 1 )/ eCAROL
M = yBOBc1 ( yCAROLc2 )-1 (mod n)
= (MeBOB)c1 ((MeCAROL)c2)-1 (mod n)
= (MeBOB)c1 ((MeCAROL)(c1(eBOB)-1)/eCAROL)-1 (mod n)
= (MeBOB)c1 (M(c1eBOB-1))-1 (mod n)
= M (Mc1(eBOB)-1)) (M( c1(eBOB)-1))-1 (mod n)
= M mod n
◼ So Eve recovers the original message!
Major Ideas

◼ Any one-way trapdoor function can be used as

the basis of a public-key cryptosystem
◼ Public-key encryption is slow because of the
need to work with huge numbers (~2000 bits)
◼ Cryptosystems can be insecure if not used
properly
◼ Elliptic curve cryptography allows high security
with small key sizes
Câu hỏi:

◼ Chữ ký số có thể dùng trong phương pháp

bảo mật nào để đảm bảo an toàn trong thanh
toán điện tử? Nêu từng phương pháp và giải
thích cụ thể?
◼ Hiện nay có bao nhiêu nhà cung cấp dịch vụ
chữ ký số tại Việt Nam và chữ ký số của nhà
cung cấp nào là tốt?
Chương 5.1: Digital Certificates
Chứng thư điện tử
Nội dung

◼ Chữ ký số - Digital signatures

◼ Giấy tờ tuỳ thân
◼ Chứng thư số - Digital certificates
◼ Hệ thống chứng thực phân cấp
◼ Chuỗi chứng thực
◼ Xác thực từ xa
◼ Hạ tầng khoá công khai (PKI)
◼ Mã hoá ASN.1 của chứng thư số
Chữ ký số - Digital Signatures

◼ Chữ ký viết tay là một chức năng của người ký,

nó không phải thông điệp.
◼ Chữ ký viết tay có thể sao chép và giả mạo.
◼ Thực hiện số hoá chữ ký viết tay sẽ không có ích
lợi gì trong TMĐT.
◼ Chữ ký số phải có khả năng
❑ Tương đương như chữ ký “thực sự” và
❑ Bảo đảm rằng nó không bị sao chép hay giả mạo.
◼ Làm thế nào để chứng minh danh tính của mình
trên Internet?
Theo Luật Giao dịch điện tử
◼ Chữ ký điện tử là
❑ Dữ liệu dưới dạng điện tử (từ, chữ, số, ký
hiệu, âm thanh hoặc các hình thức khác)
❑ Gắn liền hoặc kết hợp một cách lô gíc với

thông điệp dữ liệu

❑ Có khả năng xác nhận người ký thông điệp dữ

liệu và xác nhận sự chấp thuận của người đó

đối với nội dung thông điệp dữ liệu được ký
Chữ ký số
◼ Một Chữ ký số là chức năng của cả người ký và
thông điệp dữ liệu.
◼ Chữ ký số có được bằng cách đem mã hoá bản
tóm tắt của thông điệp bằng khoá bí mật của
người ký. Thông điệp M

Thực hiện hàm băm (SHA-1)

Tạo ra bản tóm tắt (MESSAGE DIGEST)

HASH
Khoá bí mật Mã hoá bằng khoá bí mật
của MR. A

SIG Đây là Chữ ký số của

MR. A trên thông điệp M
 Chứng thực bằng chữ ký số
Người nhận sẽ nhận Thông điệp + chữ ký số

SIG Thông điệp M

Thông điệp M

Giải mã chữ ký số bằng Sử dụng hàm SHA-1

khoá công khai của người ký Để băm thông điệp

HASH =? HASH

Nếu kết quả băm giống nhau, Thông điệp được xác thực.
Tại sao?
Vì nếu bất kỳ BIT nào của M hay SIG bị thay đổi, kết quả băm sẽ khác
Giấy tờ tùy thân
◼ Giấy tờ tuỳ thân là gì? (Chứng minh nhân dân,
Passport, khai sinh, bằng lái xe)
❑ Mảnh giấy

❑ Phát hành bởi bên thứ 3 được tin tưởng.

❑ Với thông tin xác minh danh tính của người sở hữu

◼ Giấy tờ tuỳ thân không có giá trị nếu không có dấu

hiệu nhận diện
◼ Nhận diện : giao thức để người cầm giấy tờ chứng
minh mình là người có tên trong giấy tờ này
❑ Hình

❑ Chữ ký

❑ Vân tay
Tin tưởng giấy tờ tuỳ thân
◼ Tại sao mọi người tin tưởng giấy tờ tuỳ thân?
◼ Phụ thuộc cơ quan ban hành
❑ Tôi có nhận ra giấy tờ này không?

❑ Tôi có biết cơ quan ban hành?

❑ Giấy tờ này có bị làm giả hay thay đổi?

❑ Dấu hiệu nhận diện nào có hiệu lực?

Minh họa
Chứng thư số - Digital
Certificate
◼ Một giấy tờ tuỳ thân số gắn kết một cặp khoá (bí
mật, công khai) với một cá nhân hay tổ chức.
◼ Xác minh một chữ ký số chỉ chứng minh rằng
người ký có khoá bí mật phù hợp với khoá công
khai đã dùng giải mã chữ ký.
◼ Không chứng minh là cặp khoá thuộc về cá nhân
hay tổ chức đã công bố/khai báo.
◼ Chúng ta cần một tổ chức độc lập xác thực nhân
thân (theo cách thông thường) và phát hành
chứng thư số.
Nội dung của Chứng thư số
◼ Số Serial
◼ Tên chủ thể của chứng thư
◼ Khoá công khai
◼ Tên của tổ chức cấp chứng thư số (Cơ quan
chứng thực CA - Certificate Authority)
◼ Chữ ký số của CA cấp chứng thư số đó.
◼ Thông tin về thuật toán Hash (băm), thuật toán
khoá công khai sử dụng.
◼ Một số thông tin khác về chủ thể như số CMND,
số giấy phép ĐKKD,…
Generating a Digital Certificate
Version of Certificate Standard
Hashing
Certificate Serial Number
Algorithm
Signature Algorithm Identifier

Issuer
Message
Period of Validity
Digest
Subject
C=US ST=NY L=Albany O=OFT CN=John Doe

Subject’s Public Key

Algorithm Identifier + Key Value
Issuer’s
Signature of Issuer Private
Key
SOURCE: CARL SMIGIELSKI
Chứng thư máy trạm - Client
◼ Còn gọi là chứng thư cho cá
nhân hay cho trình duyệt.
◼ Signing certificate
❑ Bound to key-pair used for
digital signatures
◼ Encrypting certificate
❑ Bound to key-pair used for
encryption
◼ Extensive support found in
SSL/TLS (next lecture)
SOURCE: CARL SMIGIELSKI
Other Types of Certificates
◼ Root Certificates
❑ Self-signed by a Certification Authority
◼ CA Certificates
❑ For verifying signatures on issued certificates
◼ Server Certificates
❑ For use by SSL/TLS servers
◼ Software Signing Certificates
❑ For signing executable code

SOURCE: CARL SMIGIELSKI

 Digital Certificate Verification
◼ Do I trust the CA? (Is it in my list of trust root certification
authorities?)
◼ Is the certificate genuine?
❑ Look up the CA’s public key; use it to decrypt the signature
❑ Compute the certificate’s hash; compare with decrypted sig
◼ Is the holder genuine? This requires a challenge
◼ If the holder is genuine, he must know the private key
corresponding to the pubic key in the certificate
◼ Having the certificate is not enough. (They are exchanged
over the Internet all the time)
◼ Send him a nonce (random 128-bit number)
 Challenge by Nonce

◼ If you’re really Shamos, you must know his private

key
◼ So please encrypt this nonce with his private key:
“A87B1003 9F60EA46 71A837BC 1E07B371”
◼ When the answer comes back, decrypt it using the
public key in the certificate
◼ If the result matches, the remote user knew the
correct private key
◼ Never use the same nonce twice
 ISO X.500 Directory Standard
PURPOSE: MAKE SURE NO TWO ENTITIES OR PEOPLE HAVE THE SAME NAME

STANDARD FOR HIERARCHICAL RDN: RELATIVE DISTINGUISHED NAME

DIRECTORIES
C: ISO COUNTRY CODE

O: ORGANIZATION

CN: COMMON NAME

EACH RDN MAY HAVE ATTRIBUTES

SOURCE: XCERT.COM
Certification Hierarchy

◼ What happens if you don’t recognize the CA in a

certificate or it is not a trusted CA?
◼ Suppose CA has a certificate issued by trusted
CA2?
◼ You may choose to trust CA if you can verify that
its certificate is genuine
CA2
CA’S CERTIFICATE
ISSUED BY CA2
CA
HOLDER’S CERTIFICATE
ISSUED BY CA
CERTIFICATE
HOLDER
Certificate Authority Hierarchy

Root CA issues its own certificate!

RCA
RCA : Root Certificate Authority
BCA : Brand Certificate Authority
BCA GCA : Geo-political Certificate Authority
CCA : Cardholder Certificate Authority
MCA : Merchant Certificate Authority
PCA : Payment Gateway
GCA Certificate Authority

CERTIFICATE ISSUANCE

CCA MCA PCA

 Certification Path
SEQUENCE OF CERTIFICATES LEADING TO A TRUST POINT, USUALLY A ROOT

Root CA
Root CA Certificate Info Root CA's Private Key
Self Signed
Root Signature

Subordinate CA
Certificate Info Root CA's Private Key
Sub CA
Root Signature

Subordinate CA's Private Key

Alice
Certificate Info
SubCA's Signature

Text
Document Alice's Private Key

Alice's Signature

SOURCE: MARK SILVERMAN

Building a Certification Path

Bob gets cert from Alice HHS Root CA

1. Alice's cert signed by CDRH

NIH FDA
2. CDRH's cert signed by FDA
3. FDA's cert signed by HHS
CIT CDRH
HHS is Bob's trust point,
therefore Bob trust's Alice's cert

Bob Alice

SOURCE: MARK SILVERMAN

Certification Paths
◼ Alice has a certificate issued by authority D
◼ To verify Alice’s certificate, Bob needs the public
key of authority D (to decrypt D’s signature on the
certificate)
◼ How does Bob get it so he is sure it is really the
public key of D? This is another verification
problem.
◼ Solution: Alice sends Bob a certification path, a
sequence of certificates leading from her
authority D to Bob. The public key of D is in D’s
certificate
◼ (D’s certificate is not enough for verification since
Bob may not know D’s certification authority G)
One-Way Remote
Authentication
◼ How can Alice send a message to Bob so
Bob knows that
❑ the message is from the real Alice
❑ the message was intended for Bob
❑ no one has altered or replayed the message
◼ Message must include
❑ Alice’s signature & certification path
❑ Bob's identity
❑ timestamp & nonce
 One-Way Authentication
Alice Insecure Channel Bob
IDA RA RS RS random value
Challenge (Nonce)

IDA INCLUDES A Eve

CERTIFICATE AND Hash
CERTIFICATION PATH IDA RA RS
Encryption with
Private Key
Hash Hash

IDA RA Sig Response

Decryption with
Public Key

Sig
SOURCE: ANDREAS STEFFEN, ZHW
Public Key Infrastructure (PKI)
◼ Digital certificates alone are not enough to
establish security
❑ Need control over certificate issuance and management
◼ Certification authorities issue certificates
◼ Who verifies the identify of certification
authorities?
◼ Naming of entities
◼ Certification Practice Statement
◼ Certificate Revocation List
◼ The metafunctions of certificate issuance form
the Public Key Infrastructure
Certification Practice Statement
◼ Satement by a CA of the policies and procedures
it uses to issue certificates
◼ CA private keys are on hardware cryptomodules
◼ View Verisign Certification Practice Statement
◼ INFN (Istituto Nazionale di Fisica Nucleare) CPS

IBM S/390 SECURE LITRONIC 440

RAINBOW LUNA CA3 CIPHERACCELERATOR
TRUSTED ROOT KEY SYSTEM CRYPTOGRAPHIC MODULE
Certificate Revocation List
◼ Online list of revoked certificates
◼ View Verisign CRL
◼ Verisign CRL usage agreement
Functions of a Public Key
Infrastructure (PKI)
◼ Generate public/private key pairs
◼ Identify and authenticate key subscribers
◼ Bind public keys to subscriber by digital certificate
◼ Issue, maintain, administer, revoke, suspend,
reinstate, and renew digital certificates
◼ Create and manage a public key repository
Format of Digital Certificates
◼ Certificates contain many fields, must be read by
computers all over the world
◼ X.509 certificates are in a standard format
described in the language ASN.1
◼ ASN.1 is a method of encoding data so that the
format can be decoded from the data itself
◼ ASN.1 is not a programming language
◼ It describes only data structures. No code, no
logic.
◼ Can be used as input to a compiler to produce
code
X.509 Certificate
Abstract Syntax Notation
◼ ASN.1 is widely used – e.g. all digital certificates
◼ ASN.1 has primitive types:
BOOLEAN, INTEGER, REAL, ENUMERATED, BIT STRING,
IA5STRING, . . .
◼ ASN.1 has
❑ SET (unordered)
❑ SEQUENCE (fixed order) of primitive types
❑ CHOICE for selecting alternative types (integer or real)
◼ Can define new types:
Month ::= INTEGER (1..12)
Day ::= INTEGER (1..31)
Daily-stock-volume ::= SEQUENCE SIZE (31) OF
INTEGER
Basic Encoding Rules (BER)
◼ Define how fields described in ASN.1 should be encoded
◼ Units of BER are data elements
◼ A data element is a triple TLV:
{ type, length, value }
◼ Some type codes:
BOOLEAN 01
IA5STRING 16 (8-BIT ASCII)
INTEGER 02
SEQUENCE 10
SET 31

◼ The string “Customer” would be encoded as

16 08 43 75 73 74 6F 6D 65 72
IA5STRING LENGTH HEX HEX HEX
8 “C” “u” “r”
Basic Encoding Rules
◼ Content field may be primitive (value) or
structured (content has subcomponents)
Basic Encoding Rules
BBCard ::= SEQUENCE {
name IA5String (SIZE (1..60)),
team IA5String (SIZE (1..60)),
age INTEGER (1..100),
position IA5String (SIZE (1..60)),
handedness ENUMERATED {left-handed(0),
right-handed(1), ambidextrous(2)},
batting-average REAL }

“Casey”, “Mudville Nine”, 32, “left field”,

ambidextrous, 0.250 (47 bytes of text)
C a s e y M u d v i l l e
302D1605 43617365 79160D4D 75647669 6C6C6520
4E696E65 02012016 0A6C6566 74206669 656C640A
01020903 80FE01 (47 bytes in BER)
ASN.1 Definition of X.509
Certificate
“TO BE SIGNED” CERTIFICATE
Certificate ::= SEQUENCE { = INTERMEDIATE (NON-ROOT)
tbsCertificate TBSCertificate, CERTIFICATE
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name, validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,--
If present, version shall be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,--
If present, version shall be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL --
If present, version shall be v3 }
ASN.1 Definition of X.509
Certificate
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL}
Name ::= CHOICE { RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType
Validity ::= SEQUENCE {
notBefore Time, notAfter Time }
Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime }
UniqueIdentifier ::= BIT STRING
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
Using ASN.1/BER

SOURCE LANGUAGE APPLICATION

ASN.1 ASN.1 (JAVA, C)
DEFINITIONS COMPILER CODE
DATA STRUCTURES

ENCODER/ APPLICATION PROGRAM

DECODER

(JAVA, C)
COMPILER

APPLICATION PROGRAM APPLICATION

NOW READS AND WRITES PROGRAM
DATA ACCORDING TO BER
ASN.1 Applications
◼ Telephone billing information
❑ Transferred Account Procedure (TAP3)
❑ UMTS (3G phones)
◼ X9 financial services (checks, electronic funds transfer)
◼ Air-to-ground aircraft information
◼ Electric and gas utilities
◼ Automobile diagnostic monitoring systems
◼ Radio Frequency Identification (RFID)
◼ Biometric IDs (Proposed ANSI Standard X9.84)
❑ Common Biometric Exchange File Format CBEFF
◼ Smart cards (ISO 7816-4)
◼ MORE
Major Ideas
◼ Digital signature = hash of message encrypted
with signer’s private key. Computationally
unforgeable
◼ Digital certificate = digital identity document
issued by a trusted third party. Associates a
public key with a real person
◼ A digital signatures without a certificate does not
prove identity
◼ The holder of a certificate must be challenged to
prove he knows the correct private key
◼ Certificate authorities form trust hierarchies, with
certificate paths from sender to recipient, allowing
verification of the trust relationship
Major Ideas
◼ MANY eCommerce applications do not require
verification of identity, but only verification of
authorization
◼ Digital certificates are useful when identity must
be proven or when interacting with multiple
parties not known in advance
◼ A long-term relationship between two parties
does not require a digital certificate; a password
is often (not always) sufficient
◼ ASN1. is a “hidden” method of specifying data
formats, but used is many applications, including
digital certificates
6.1 PAY WITH VISA
 Lơi ích của Thẻ

◼ Có thể làm gì với Thẻ Visa?

◼ Chấp nhận thanh toán thẻ Visa, ĐVCNT được
lợi gì?
◼ Trò chơi “Chung sức”
 Lợi ích của ĐVCNT khi tham gia
chấp nhận thanh toán thẻ Visa

◼ Chấp nhận thẻ để phát triển, tăng doanh thu và cơ

hội kinh doanh
◼ Thu hút khách hàng toàn cầu do xu hướng toàn
cầu chuyển hướng sang thanh toán điện tử
◼ Phục vụ khách hàng nhanh, tạo hình ảnh chuyên
nghiệp hơn
◼ Tránh sai sót trong thanh toán
 Tiện ích của thẻ

◼ Thanh toán hàng hóa, dịch vụ

◼ Thanh toán hóa đơn dịch vụ
◼ Thanh toán trực tuyến trên Internet
◼ Rút tiền mặt, chuyển khoản, kiểm tra số
dư,… từ máy ATM
 Qui trình chấp nhận thanh toán thẻ Visa

◼ Qui trình thanh toán là gì, nó hoạt động như

thế nào và các thành phần, đối tượng nào
tham gia qui trình này?
◼ Điều gì xảy ra sau khi thực hiện cà thẻ?
Các đối tượng tham gia
qui trình chấp nhận thẻ Visa

Chủ thẻ (Cardholder): Người sử dụng thẻ Visa

Ngân hàng phát hành (NHPH - Issuer): Tổ chức

tài chính phát hành thẻ và ký kết hợp đồng với chủ
thẻ.

Đơn vị chấp nhận thẻ (ĐVCNT): Đơn vị kinh

doanh có đăng ký chấp nhận thanh toán hàng hóa,
dịch vụ bằng thẻ Visa.
Các đối tượng tham gia
qui trình chấp nhận thẻ

Ngân hàng thanh toán (NHTT - Acquirer): Tổ

chức tài chính ký hợp đồng thanh toán thẻ với
ĐVCNT để thanh toán hàng hóa, dịch vụ.

VisaNet: Hệ thống quản lý các giao dịch thanh

toán qua thẻ Visa, gồm cả dịch vụ thanh toán bù
trừ và kết toán để chuyển thông tin thanh toán giữa
các đối tượng liên quan tham gia quá trình chấp
nhận và thanh toán thẻ.
Qui trình chấp nhận & thanh toán

Qui trình chính trong giao dịch thanh toán thẻ:

1. Chấp nhận thẻ/Cấp phép/Chuẩn chi (Authorization)
2. Thanh toán bù trừ và kết toán (Clearing & Settlement)
1. Qui trình chấp nhận thẻ/cấp phép
(Authorization)
2. Qui trình thanh toán bù trừ & kết toán
(Clearing & Settlement)
 Giới thiệu thẻ

◼ Thẻ thông dụng hiện nay là một miếng

plastic, có kích thước chuẩn (8.5cm x 5.3cm)

Thẻ từ Thẻ chip

Logo Visa

Logo Visa mới

được thiết kế
Logo mới
đơn giản, dễ
nhận diện hơn,
với tông màu và
kiểu chữ tương
tự như logo cũ.
Logo cũ
 Các loại thẻ Visa

◼ Thẻ Visa Credit (thẻ tín dụng Visa)

◼ Thẻ Visa Debit (thẻ ghi nợ Visa)
◼ Thẻ Visa Prepaid (thẻ trả trước Visa)
 Thẻ tín dụng Visa (credit card)
◼ Là thẻ cho phép chủ thẻ ◼ Chủ thẻ sẽ trả những khoản
thực hiện giao dịch trong tiền đã thanh toán bằng thẻ tín
phạm vi hạn mức tín dụng dụng khi nhận được thông báo
đã được cấp.
của ngân hàng hay tổ chức
phát hành thẻ.
◼ Phạm vi sử dụng: trong
nước và quốc tế.

◼ Tính năng: chi tiêu trước,

trả tiền sau, dùng để thanh
toán hàng hóa dịch vụ; rút
tiền mặt, có thể thanh toán
trực tuyến trên Internet và
thanh toán MOTO (Mail
Order/Telephone Order).
 Thẻ Visa Debit
◼ Là thẻ cho phép chủ thẻ thực
hiện giao dịch trong phạm vi
số tiền có trong tài khoản tiền
gửi vãng lai (checking
account) của chủ thẻ.

◼ Phạm vi sử dụng: trong nước

và quốc tế.

◼ Tính năng: dùng để thanh toán

hàng hóa dịch vụ; rút tiền mặt,
có thể thanh toán trực tuyến
trên Internet và thanh toán
MOTO (Mail Order/Telephone
Order).
 Thẻ Visa Prepaid
◼ Là thẻ đã được nạp tiền sẵn
trong tài khoản, an toàn, tiện
lợi
◼ Dùng thẻ để mua sắm tại bất
cứ điểm chấp nhận thẻ Visa.
◼ Tính năng: dùng để thanh toán
hàng hóa dịch vụ; rút tiền mặt,
có thể thanh toán trực tuyến
trên Internet và thanh toán
MOTO (Mail Order/Telephone
Order).
 Nhận diện thẻ Visa (mặt trước)

Số thẻ dập nổi

hoặc in chìm Logo Visa: phải
trên thẻ bao gồm hoặc nằm ở vị trí
16 chữ số, bắt góc dưới bên phải
đầu với số 4, các hay góc trên bên
số phải bằng phải hay góc trên
nhau và thẳng bên trái
hàng. Thẻ bị sửa
Chữ "V" phản xạ
đổi các số có thể
cực tím: phải được
có cạnh bị mờ
nhìn thấy trên logo
hay có thể nhìn Bốn số đầu “Good Thru” (hay Visa khi được đặt
thấy bóng mờ của được in ngay “Valid Thru”) Date dưới ánh sáng cực
số bị xóa đi. dưới dãy số thẻ
tím (của máy soi tiền)
phải hoàn toàn
giống với bốn
chữ số đầu tiên
của số thẻ
 Nhận diện thẻ Visa (mặt sau)

Hình chim bồ
câu 3D: phải
trông như hình
3 chiều và Card Verification
dường như Value (CVV2): là 3
đang di chuyển số nằm chung trên
khi nghiêng thẻ khung chữ ký hay
tới phía trước nằm ngay bên phải
rồi ra phía sau. khung chữ ký (một
phần của số thẻ
Khung chữ ký: có thiết kế riêng biệt cũng có thể in trên
Dải từ khung chữ ký.
nhưng luôn chứa dòng chữ VISA
được in bằng mực in phản xạ tia cực
tím. Nếu ai đó cạo sửa băng chữ ký
thì sẽ lộ ra chữ “VOID”
Nhận diện thẻ Visa
Loại 1 Loại 2
Nhận diện thẻ Visa (tt)
Loại 3 Loại 4
7 thao tác cơ bản khi thực hiện cà thẻ

1. Kiểm tra thẻ

2. Cà thẻ
3. Kiểm tra kết quả cấp phép (chuẩn chi)
4. Đối chiếu các con số
5. Yêu cầu chủ thẻ ký tên vào hóa đơn
thanh toán
6. Kiểm tra chữ ký chủ thẻ
7. Giao liên có chữ “Customer copy” hay
“Cardmember copy” cho chủ thẻ
 Thao tác thanh toán thẻ

◼ Để tạo sự tin tưởng và hài lòng cho khách

hàng, thu ngân cần:
❑ Kiểm tra nhanh dấu hiệu bảo mật trên thẻ
❑ Thực hiện các thao tác thanh toán chính xác và
chu đáo.
Thao tác với thẻ chip
1. Xác nhận lại với chủ thẻ tổng số tiền giao dịch;
2. Đưa thẻ vào khe đọc của thiết bị EDC và thực hiện theo
hướng dẫn trên màn hình (tham khảo chi tiết tại mục “Các
chức năng cơ bản của thiết bị EDC”);
3. Yêu cầu chủ thẻ nhập mã PIN hoặc ký tên vào hóa đơn.
Chỉ rút thẻ ra khỏi thiết bị EDC khi trên màn hình hiện ra
lời nhắc rút thẻ ra;
4. So sánh chữ ký trên hóa đơn và trên thẻ;
5. Trả thẻ cho chủ thẻ cùng với bản sao hóa đơn của khách
hàng (customer/cardmember copy).
Thao tác với thẻ từ
1. Xác nhận lại với chủ thẻ tổng số tiền giao dịch;
2. Quét thẻ qua khe đọc của thiết bị EDC và thực hiện theo
hướng dẫn trên màn hình (tham khảo chi tiết tại mục “Các
chức năng cơ bản của thiết bị EDC” );
3. Yêu cầu chủ thẻ ký tên vào hóa đơn;
4. So sánh chữ ký trên hóa đơn và trên thẻ; đồng thời thực
hiện kiểm tra một số điểm bảo mật khác;
5. Trả thẻ cho chủ thẻ cùng với bản sao hóa đơn của khách
hàng (customer/cardmember copy).
 Các thông báo trên màn hình EDC
Thông báo Xử lý

Approved Yêu cầu chủ thẻ ký vào hóa đơn

(chuẩn chi)

Declined Trả thẻ lại cho chủ thẻ và yêu cầu chủ thẻ đưa
(không chuẩn chi) thẻ Visa khác.

Call hay Call Center Gọi Trung tâm thẻ của NH thanh toán và nói
bạn nhận thông báo “Call” hay “Call Center”.
Thực hiện theo hướng dẫn của nhân viên NH.
Lưu ý: Trong hầu hết trường hợp, một thông
báo “Call” hoặc "Call Center" chỉ có nghĩa là
đơn vị phát hành thẻ cần bổ sung một số
thông tin trước khi giao dịch có thể được chấp
nhận.
 Các thông báo trên màn hình EDC

Thông báo Xử lý

Pick Up Giữ lại thẻ nếu bạn có thể thực hiện điều
(giữ thẻ) này một cách ôn hòa, ổn thỏa.

No Match Thực hiện cà thẻ và chú ý kiểm tra bốn

(không trùng) chữ số cuối của thẻ. Nếu "No Match”
xuất hiện một lần nữa, hãy giữ thẻ nếu
bạn có thể thực hiện một cách ôn hòa, ổn
thỏa. Thực hiện yêu cầu cấp phép “Code
10”.
 Kiểm soát gian lận

◼ Tuân thủ thao tác cơ bản khi cà thẻ

◼ Khi có nghi ngờ gian lận

 Tuân thủ thao tác cơ bản khi thực hiện cà
thẻ
1. Kiểm tra thẻ

2. Cà thẻ

3. Kiểm tra kết quả cấp phép (chuẩn chi)

4. Đối chiếu các con số

5. Yêu cầu chủ thẻ ký tên vào hóa đơn thanh

toán
6. Kiểm tra chữ ký

7. Giao liên có chữ “Customer copy” hay

“Cardmember copy” cho chủ thẻ
 Khi nghi ngờ có gian lận

◼ Gọi Trung tâm thẻ ngân hàng để yêu cầu cấp

phép Code 10.
◼ Cầm thẻ trên tay để sẵn sàng trả lời các câu
hỏi và cung cấp một số thông tin về ĐVCNT
và/hoặc các chi tiết giao dịch cho Trung tâm
Thẻ.
◼ Sau đó, có thể bạn sẽ được chuyển sang nói
chuyện với Ngân hàng phát hành để xác định
xem bạn đang nghi ngờ thẻ hoặc chủ thẻ.
 Khi nghi ngờ có gian lận (tt)

◼ Khi trao đổi với nhân viên ngân hàng, hãy

bình tỉnh trả lời các câu hỏi với giọng nói bình
thường;
◼ Thực hiện các thao tác theo hướng dẫn của
nhân viên ngân hàng;
◼ Nếu nhân viên ngân hàng yêu cầu bạn giữ lại
thẻ, hãy tuân thủ theo yêu cầu này nếu như
có thể thực hiện một cách ổn thỏa, an toàn.
 Hoàn tiền (Chargeback)
◼ Là khoản tiền mà ĐVCNT, thông qua ngân hàng thanh
toán thẻ, phải hoàn trả toàn bộ hoặc một phần giá trị của
một giao dịch nào đó cho chủ thẻ thông qua ngân hàng
phát hành thẻ.
◼ Hầu hết các chargeback xảy ra khi các ĐVCNT không
tuân theo các thủ tục giao dịch chuẩn (ví dụ: quên xin
cấp phép cho một giao dịch, hoặc vô tình thực hiện một
giao dịch nhiều hơn một lần).
◼ Một số nguyên nhân khác như tên ĐVCNT không thể
nhận ra trên sao kê, không thực hiện tra soát, không
nhận hàng hoá, hoặc chủ thẻ phủ nhận không thực hiện
giao dịch đó.
 Chủ động tránh bị chargeback
◼ Thực hiện theo đúng qui trình để tránh những tổn thất
không cần thiết.
◼ Hành động ngay khi nhận khiếu nại hợp lệ từ những
khách hàng uy tín, đáng tin cậy.
◼ Khi chủ thẻ liên hệ trực tiếp với bạn để giải quyết khiếu
nại, hãy xử lý kịp thời để tránh những khiếu nại không
cần thiết và những chi phí xử lý chargeback liên quan.
◼ Phản hồi ngay với các trường hợp xảy ra chagreback.
◼ Quan tâm đến mọi yêu cầu thích đáng của chủ thẻ.
◼ Hãy chắc chắn cung cấp những thông tin “thuyết phục”
để chứng minh chủ thẻ có tham gia giao dịch, nhận hàng
hoá, dịch vụ, các lợi ích được hưởng từ giao dịch.
 Thực hiện yêu cầu tra soát
◼ Do ngân hàng phát hành thẻ yêu cầu ĐVCNT cung cấp
hóa đơn thanh toán cà thẻ của một giao dịch nào đó.
◼ Nếu nhận được yêu cầu tra soát, hãy tìm lại và photo
cẩn thận hóa đơn thanh toán đó và fax hoặc gởi cho
Ngân hàng thanh toán thẻ của bạn trong thời gian được
ấn định
◼ Bằng chứng thuyết phục:
❑ Có sự trao đổi qua lại bằng văn bản/thư từ giữa chủ
thẻ và ĐVCNT để chứng minh rằng đơn vị đã có trao
đổi với chủ thẻ hoặc đã nhận thư xác nhận rằng họ
hiểu tính hợp lệ của giao dịch.
❑ Bằng chứng cho thấy ĐVCNT đã cà thẻ qua thiết bị
điện tử hay thiết bị cà tay, đã được cấp phép và có
chữ ký của chủ thẻ.
 Điều gì xảy ra khi bạn không thực hiện/
không phản hồi yêu cầu tra soát?

◼ Thực hiện yêu cầu tra soát rất quan trọng, khi
yêu cầu này không được thực hiện, hoặc không
thực hiện theo đúng thời gian, hoặc bản sao
không rõ, việc bị chargeback hầu như không thể
tránh khỏi.
◼ Do đó, nếu ĐVCNT có lưu giữ hóa đơn thanh
toán, hãy nhanh chóng phản hồi và thực hiện
đúng các yêu cầu tra soát.
 Hạn chế bị “yêu cầu tra soát”

◼ Đảm bảo thông tin giao dịch trên hóa đơn cà

thẻ đầy đủ, chính xác, rõ ràng trước khi hoàn
tất giao dịch đó;
◼ Đảm bảo khách hàng nhận diện được tên
đơn vị/cơ sở kinh doanh của bạn;
◼ Đảm bảo tên đơn vị/cơ sở kinh doanh mà
bạn đăng ký giao dịch với ngân hàng thể hiện
trong sao kê tài khoản cũng cùng tên thể hiện
trên các hóa đơn thanh toán Bạn giao cho
khách hàng.
 Tránh “chứng từ không rõ ràng”

◼ Thay giấy in khi thấy có vệt/đường sọc màu

xuất hiện.
◼ Giữ lại liên trắng của hóa đơn cà thẻ (hoặc
liên có chữ “Merchant copy”.
◼ Lưu giữ cẩn thận những hóa đơn in trên giấy
than (giấy carbon).
◼ Vị trí in logo công ty hay thông điệp tiếp thị
trên hóa đơn cà thẻ phải tách rời/riêng biệt
với thông tin giao dịch.
 Thanh toán Điện tử
Trong Thương mại Điện tử

Chương 6: Credit Card Protocols

and Application
Outline
◼ Credit card participants (7)
◼ Secure Sockets Layer (SSL)
❑ security with public keys

◼ Secure Electronic Transactions (SET)

❑ authentication with certificates

◼ 3-D Secure
❑ authentication without certificates

◼ Fraud
◼ Pay with VISA
 Participants

Processor Processor

Card
Association

Merchant
• Issuing Bank Consumer • Merchant Bank (Acquirer)
• Issues card • Sets up merchant
• Extends credit • Extends credit
• Assumes risk of card • Assumes risk of merchant
• Cardholder reporting • Funds merchant
Credit Cards on the Internet
◼ Problem: communicate credit card and purchasing
data securely to gain consumer trust
❑ Authentication of buyer and merchant
❑ Confidential transmissions
◼ Systems vary by
❑ type of public-key encryption
❑ type of symmetric encryption
❑ message digest algorithm
❑ number of parties having private keys
❑ number of parties having certificates
 Credit Card Protocols
◼ SSL 1 or 2 parties have private keys VERY IMPORTANT.
◼ TLS (Transport Layer Security) USAGE INCREASING

❑ IETF version of SSL

◼ i KP (IBM) i parties have private keys

◼ SEPP (Secure Encryption Payment Protocol) OBSOLETE
❑ MasterCard, IBM, Netscape based on 3KP
◼ STT (Secure Transaction Technology)
❑ VISA, Microsoft

◼ SET (Secure Electronic Transactions) VERY SLOW

ACCEPTANCE; DEAD
❑ MasterCard, VISA all parties have certificates
RAPID
◼ 3-D Secure real-time authentication EXPANSION
 SSL (Secure Sockets Layer) Concept
PURPOSE: ALLOW A USER WITHOUT A CERTIFICATE TO SEND
SECRET INFORMATION (A CREDIT CARD NUMBER) EFFICIENTLY

Merchant
Non-Internet (telephone) line
Credit Card
Secure Acquirer
“tunnel”
through the ◼ Consumer must
Internet trust merchant
with card Acquirer
◼ Similar to notifies
Internet ordinary phone Issuer
order
◼ High transaction
costs

Credit Card
Consumer Issuer bills Consumer Issuer

SOURCE: MARVIN SIRBU

SSL Overview

◼ Client has no certificate

◼ Merchant has a certificate, therefore
public and private keys
MERCHANT
CLIENT ◼ Merchant sends its certificate; client now
SERVER
has merchant’s public key
◼ Client can send encrypted data to
merchant
◼ Merchant can’t send encrypted data to
client
◼ BRILLIANT IDEA: client creates a
symmetric key, sends it to merchant
◼ Now both can communicate secretly and
fast

SOURCE: CARL SMIGIELSKI

SSL (Secure Sockets Layer)
◼ NOT a payment protocol -- can be used for any
secure communications, like credit card numbers
◼ SSL is a secure data exchange protocol providing
❑ Privacy between two Internet applications
❑ Authentication of server
❑ Authentication of user optional (not authenticated)
◼ Uses enveloping: public-key encryption used to
exchange symmetric keys
◼ SSL Handshake Protocol
❑ Negotiates symmetric encryption protocol
◼ SSL Record Protocol
❑ Packs/unpacks records, performs encryption/decryption
 SSL Handshake MERCHANT
CLIENT SERVER

Client and Server Hello

Client now Certificate Merchant’s

has server’s digital
public key Contains server’s public key certificate

Generate Client Key Exchange Decrypt

pre-master Pre-master secret encrypted pre-master
secret with server’s public key secret

Derive ChangeCipherSpec Derive

session key session key
from from
pre-master Finished pre-master
secret secret
SOURCE: CARL SMIGIELSKI
Cipher Suite
◼ For public-key, symmetric encryption and
certificate verification we need
❑ public-key algorithm
❑ symmetric encryption algorithm
❑ message digest (hash) algorithm
◼ This collection is called a cipher suite
◼ SSL supports many different suites
◼ Client and server must decide on which one to
use
◼ The client offers a choice; the server picks one
Cipher Suites
SSL_NULL_WITH_NULL_NULL = { 0, 0 } INITIAL (NULL) CIPHER SUITE

PUBLIC-KEY SYMMETRIC HASH

ALGORITHM ALGORITHM ALGORITHM

SSL_RSA_WITH_NULL_MD5 = { 0, 1 } CIPHER SUITE CODES USED

IN SSL MESSAGES
SSL_RSA_WITH_NULL_SHA = { 0, 2 }
SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0, 3 }
SSL_RSA_WITH_RC4_128_MD5 = { 0, 4 }
SSL_RSA_WITH_RC4_128_SHA = { 0, 5 }
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0, 6 }
SSL_RSA_WITH_IDEA_CBC_SHA = { 0, 7 }
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0, 8 }
SSL_RSA_WITH_DES_CBC_SHA = { 0, 9 }
SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0, 10 }
TLS (Transport Layer Security)
◼ SSL is so important it was adopted by the
Internet Engineering Task Force (IETF)
◼ TLS Protocol 1.0 (RFC 2246)
◼ TLS is very similar to SSL but they do not
interoperate
◼ Browsers understand both SSL and TLS
◼ Goals
❑ Separate record and handshaking protocols
❑ Extensibility (add new cipher suites easily)
❑ Efficiency (minimize network activity)
Secure Electronic Transactions (SET)
◼ Merchant doesn’t see card #
Secure ◼ Uses Internet to reach acquirer
“tunnel” ◼ High transaction cost
through the
Internet

Internet
Credit Card
Acquirer

Credit Card
Issuer
Consumer Issuer bills Consumer

SOURCE: MARVIN SIRBU, CMU

Parties in SET

SOURCE: WILLIAM STALLINGS

 SET Flow
cardholder merchant
order info + payment instruction MERCHANT
CERT
ack + services

Internet payment info, authorization capture capture

CARD-
HOLDER authorization response + request response
CERT request capture token + token
AT PURCHASE AT END OF DAY

payment GATEWAY
CERT
gateway

payment network
money transfer
issuer acquirer
(cardholder’s bank) (merchant’s bank)
 SET Message Flow

Non-SET Financial Network Non-SET

Payment
Card Issuer
Gateway

9. 5. Auth. Request
Payment Capture 6. Auth.
10. Response
Payment Capture
Request Response
SET
1.
7.
3. Init
Inquiry
Request
PurchaseRequest
Request
Card Merchant
8. 2. Init Response
4. Inquiry
Purchase Response
Response
Holder
SET

SOURCE: HUTTER/STEPHAN
Dual Signature

◼ Links two messages intended for different

recipients SENDER’S
PRIVATE KEY
data1 hash

hash sign
DUAL
SIGNATURE
data2 hash

RECIPIENT 1 RECIPIENT 2
RECEIVES: RECEIVES:

data1 data2

HASH OF HASH OF
DATA 2 DATA 1
DUAL
SIGNATURE
Using the Dual Signature

PI Hash Bank

PIMD

 Hash POMD En- Dual Sig.

crypt
OIMD
Customer’s
public key
Customer’s
private key
OI Hash

Merchant

SOURCE: RICHARD STANLEY

Cardholder Purchase Request

SOURCE: HENRIC JOHNSON

SET Objectives
◼ Confidentiality of payment and order information
❑ Encryption
◼ Integrity of all data (digital signatures)
◼ Authentication of cardholder & account (certificates)
◼ Authentication of merchant (certificates)
◼ No reliance on secure transport protocols (TCP/IP)
◼ Interoperability between SET software and
network
❑ Standardized message formats
◼ SET is a payment protocol
❑ Messages relate to various steps in a credit card
transaction
SET Security
◼ Digital envelopes, nonces
◼ Two public-private key pairs for each party
❑ One for digital signatures; one for key exchange

messages
◼ 160-bit message digests
◼ Statistically globally unique IDs (XIDs)
◼ Certificates (5 kinds)
❑ Cardholder, Merchant, Acquirer, Issuer, Payment
Gateway
◼ Hardware cryptographic modules (for high security)
◼ Idempotency (message can be received many times but is
only processed once) f (f (x)) = f (x)
◼ Complex protocol. Over 600 pages of detail
◼ Dual signatures
SET Process Steps (Simplified)
1. Merchant sends invoice and unique transaction ID (XID)
2. Merchant sends merchant certificate and bank certificate
(encrypted
with CA’s private key)
3. Customer decrypts certificates, obtains public keys
4. Customer generates order information (OI) and payment info
(PI)
encrypted with different session keys and dual-signed
5. Merchant sends payment request to bank encrypted with bank-
merchant session key, PI, digest of OI and merchant’s certificate
6. Bank verifies that the XID matches the one in the PI
7. Bank sends authorization request to issuing bank via card
network
8. Bank sends approval to merchant
9. Merchant sends acknowledgement to customer
Secure Electronic Transactions (SET)
SET Overhead
Simple purchase transaction:
◼ Four messages between merchant and customer
◼ Two messages between merchant and payment gateway
◼ 6 digital signatures
◼ 9 RSA encryption/decryption cycles
◼ 4 DES encryption/decryption cycles
◼ 4 certificate verifications
Scaling:
◼ Multiple servers need copies of all certificates
◼ Compaq sells SET software equipped for 5,000,000
certificates
◼ NO ONE USES SET. WHY?
◼ Visa used to list all SET-enabled merchants on its website.
No more.
3-D Secure
◼ Idea: authenticate user without a certificate
◼ Requires the user to answer a challenge in real-
time
◼ Challenge comes from the issuing bank, not the
merchant
◼ Issuing bank confirms user identity to merchant
 3-D (3-Domain) Model

Internet
Merchant
Cardholder
eMerchant Server
Wallet Server

Issuer Acquirer

Payment
Association
Issuer Domain Interoperability Domain Acquirer Domain

SOURCE: MASTERCARD
 3-D Secure Process Flow

1. Card and order data

6. Response Verify user SSL

participation Merchant

Cardholder 2. Determine
issuer
MPI
SSL Merchant Plug-In
3. Check user
participation Global 5. Verify user
participation
Directory
SSL
Issuer 4. Verify user
participation Payment Gateway

ACS Acquirer
Access Control Server

SOURCE: MASTERCARD
 3-D Secure Process Flow
10. Payer Authentication Response

Merchant
SSL
Cardholder

7. Payer Authentication Request MPI

8. Cardholder Authentication
9.Payer Authentication Response
11. Normal Transaction

Global
Directory
Issuer
Payment Gateway

12. Normal Authorization Process

ACS Acquirer

SOURCE: MASTERCARD
3-D Secure (1)
1. Customer enters details at
merchant site Active Merchant Merchant
Customer 3-D Secure
Acquirer Plug-in
Merchant Plug-in

2. Merchant Plug-in checks card issuer

participation with VISA directory

3. VISA directory checks card

participation with issuer Visa
Directory

3-D Secure
Access Control Payment
Server Visanet Gateway
Issuer Acquirer
SOURCE: KMIS
3-D Secure (2)
6. Merchant Plug-in redirects
customer’s browser to issuer’s Access
Control Server with transaction details Active Merchant Merchant
Customer 3-D Secure
Acquirer Plug-in
Merchant Plug-in

5. Location of issuer’s Access Control

Server sent to Merchant Plug-in

4. Issuer confirms card

participation Visa
Directory

3-D Secure
Access Control Payment
Server Visanet Gateway
Issuer Acquirer
SOURCE: KMIS
3-D Secure (3)

Active Merchant Merchant

Customer 3-D Secure
Acquirer Plug-in
Merchant Plug-in

7. Issuer’s Access Control

Server requests username
and password from customer

8. Customer presents
password into issuer system Visa
Directory
9. Issuer’s Access Control
Server validates password,
signs response and redirects
customer to Merchant Plug-in

3-D Secure
Access Control Payment
Server Visanet Gateway
Issuer Acquirer
SOURCE: KMIS
3-D Secure (4)
14. Merchant confirms transaction
and issues receipt to customer Active Merchant Merchant
Customer 3-D Secure
Acquirer Plug-in
Merchant Plug-in

13. Acquirer
sends transaction
response back to
merchant
10. Merchant
Visa submits normal
Directory transaction to
acquirer

11. Acquirer sends authorization requests to issuer

3-D Secure via Visanet
Access Control Payment
Server Visanet Gateway
Issuer 12. Issuer sends authorization response to acquire Acquirer
via Visanet
Major Ideas
◼ Credit cards are used because of convenience
◼ But the processing cost is high
◼ SSL, TLS are secure message protocols, not
payment protocols
◼ SSL requires the vendor to have a certificate
◼ SSL is secure against breaking of any one form of
encryption
◼ SET is a payment protocol
◼ SET requires all parties to have certificates
◼ SET uses dual signatures
◼ 3-D Secure provides authentication without
certificates
Q&A
SSL (Secure Sockets Layer)

INITIALIZES SECURE ERROR HANDLING

COMMUNICATION

HANDLES COMMUNICATION
WITH THE APPLICATION

Protocols
INITIALIZES COMMUNCATION
BETWEEN CLIENT & SERVER
HANDLES DATA
COMPRESSION
 SSL Handshake Messages
CLIENT SIDE SERVER SIDE
OFFER CIPHER SUITE SELECT A CIPHER SUITE
MENU TO SERVER
SEND CERTIFICATE AND
CHAIN TO CA ROOT

SEND PUBLIC KEY TO

ENCRYPT SYMM KEY

SEND ENCRYPTED SERVER NEGOTIATION

SYMMETRIC KEY FINISHED

ACTIVATE
ENCRYPTION
CLIENT PORTION ( SERVER CHECKS OPTIONS )
DONE ACTIVATESERVER
ENCRYPTION
( CLIENT CHECKS OPTIONS ) SERVER PORTION
DONE
NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

High Risk Merchants
Product Services Method of Sale
Illegal goods Investment opportunities Outbound telemarketing

Book and record club Travel agency Inbound teleservices

Pawn shop Dating/escort service Door to door sales

Vitamins Limousine/taxi service Future services

Computer software Bail/bond payments Out of home sales

Stamp/coin stores Massage parlors Nonpermanent locations

Auto rental/leasing Employment Flea markets/no store

services agencies/collection front
services
Water purification Timeshare/audio text pay Use of third party for
per call product, sales, or delivery
Secure Electronic Transactions (SET)
3-D Secure

SOURCE: VISA
 3-D Secure Transaction Flow
Merchant Plug-in queries
Cardholder visits merchant site
and selects “Buy”
2
1 Directory for account
participation
MERCHANT
Cardholder

Merchant
Plug-in

Directory
Issuer 3
Directory
response
5
Access
Control indicates Merchant verifies the signature
4 Server CH is/not and sends an Authorization
enrolled Request with selected
Authentication
Issuer prompts for password (and chip card History authentication data (ECI and
insertion), validates password (and Server CAVV) to the Acquirer
cryptogram), calculates CAVV, digitally
signs response to Merchant, sends copy to
Authentication History Server
ISSUER
Visa Acquirer
Net Payment
Processor
8
Acquirer formats
Issuer verifies CAVV (or 7 6 message with ECI
interrogates VisaNet and CAVV
codes), authorizes the VisaNet verifies CAVV, forwards to Issuer
transaction, sends
response to the Acquirer
 SPA (1)
3. SPA Applet requests
authentication information
from the user 1. SPA Applet detects SPA-enabled
merchant page
Customer Merchant
SPA Applet Acquirer Plug-in
2. SPA Applet reads information from
merchant’s websites

4. SPA Applet sends

authentication and
transaction information
to issuer’s SPA Server

5. Issuer SPA Server

sends authentication
token back to SPA
Applet

SPA Payment
Server Banknet Gateway
Issuer Acquirer
SOURCE: KMIS
SPA (2)

6. SPA Applet embeds the authentication token in the

merchant’s site and optionally fills the online form
Customer Merchant
SPA Applet 11. Merchant confirms transaction and Acquirer Plug-in
issues receipt to customer

7. Merchant sends
authorization request
and authentication
token to acquirer

10. Acquirer sends

transaction response
back to merchant
8. Acquirer sends authorization request and
authentication token to issuer via Banknet
SPA Payment
Server Banknet Gateway
Issuer 9. Issuer sends authorization response to acquirer
Acquirer
Using Dual Signatures
◼ Alice wants to send Message 1 to Bob and Message 2 to
Carol
◼ Message 1 is order info; Message 2 is payment info
◼ Alice encrypts Message 1 with Bob’s public key; Message 2
with Carol’s public key
◼ Both Bob and Carol must be convinced that the messages are
linked and unaltered
◼ Alice sends { PKBOB(Message 1), PKCAROL (Message 2),
DualSig} to both Bob and Carol
◼ Bob hashes PKBOB(Message 1), concatenates with PKCAROL
(Message 2), and hashes again to give the dual hash
◼ Bob decrypts the dual signature with Alice’s public key
◼ If the new hash and the decrypted signature match, all is OK
Dual Signatures on Plaintext
◼ Alice wants to send Message 1 to Bob and Message 2 to
Carol in plaintext
◼ Bob can’t see Message 2; Carol can’t see Message 1
◼ Both Bob and Carol must be convinced that the messages are
linked and unaltered
◼ Alice sends Bob { Message 1, Digest 2, Dual Signature}
◼ Bob hashes Message 1, concatenates with Digest2 and
hashes
◼ Bob decrypts the dual signature with Alice’s public key
◼ If the new hash and the decrypted signature match, all is OK
◼ Now Bob can send Carol Digest 2 and ask if she got the
message corresponding to it!
◼ (Carol got { Message 2, Digest 1, Dual Signature} )
SET in Practice

SOURCE: http://www.software.ibm.com/commerce/payment/specsheetetill.html
MasterCard Banknet
◼ Closed TCP/IP network
◼ Payment authorization in 130 milliseconds avg.
◼ Capacity: 2.5M transactions/hour, 700/second
◼ Busiest day: 36M authorizations, 40M debits
◼ 210 countries (more than SWIFT!)
◼ 25,000 issuing banks
◼ 650 service delivery points
❑ 13 global hubs
❑ 32 country hubs

SOURCE: MASTERCARD
Chương 7: Stored-Value Cards
ThS Phạm Mạnh Cường
Outline

◼ Smart card types

◼ Operating systems
◼ Wireless cards
◼ Card manufacture and issuance
◼ Security
◼ Octopus
 Smart Card Applications

E-Government
Banking Mass Transit Public
Telephony

Mobile Retail
Telecommunications W-LAN

Digital Rights
Enterprise Management
Security
Access control SOURCE: JEAN-JACQUES VANDEWALLE
ePayment by Smart Card
◼ Objective: replace cash
◼ Cash is expensive to make and use
❑ Printing, replacement
❑ Anti-counterfeiting measures
❑ Transportation
❑ Security
◼ Cash is inconvenient
❑ not machine-readable
❑ humans carry limited amount
❑ risk of loss, theft
◼ Additional smart card benefits
 Smart Cards
◼ Magnetic stripe
❑ 3 tracks, ~140 bytes, cost $0.20-0.75
◼ Memory cards
❑ 1-4 KB memory, no processor, cost $1.00-2.50
◼ Optical memory cards
❑ 4 megabytes read-only (CD-like), $7-12
◼ Microprocessor cards
❑ Imbedded microprocessor
◼ (OLD) 8-bit processor,
16 KB ROM, 512 bytes RAM
◼ Equivalent power to IBM XT PC
◼ 32-bit processors now available
Magnetic Stripe Cards
◼ Three tracks: 1 & 3 at 210 bits/inch; 2 at 75 bpi
◼ Start sentinel (1 char): %
◼ Format code (1 char): B for bank/financial
◼ Primary Account Number (PAN) (19 char)
❑ Major industry identifier (1 or 2 char): 4, 5 for credit cards

❑ Issuer (up to 5 char)

❑ Individual account number (up to 12 char)

◼ Field separator (1 char): ^

◼ Name
◼ Field separator
◼ Expiration date (4 char): YYMM
◼ Proprietary fields, including Pin Verification Value (P V V)
Other Smart Card Types

SIM card

Crypto card
USB token

Memory card Java card

SOURCE: ANDREAS STEFFEN
Laser Optical Memory Card
Capacity: 1MB - 1GB
Hong Kong Smart ID
 Microprocessor Card Adoption
2,000
1,800
1,600
1,400 Asia Pacific
1,200 Japan
MILLIONS
OF CARDS 1,000 Europe
WORLDWIDE 800 Americas
600 North America
400
200
0
2000 2001 2002 2003 2004

1999: 500 M microprocessor cards

2004: 1750 M microprocessor cards
SOURCE: DATAQUEST (10/2000)
 Smart Card Structure

Microprocessor

Contacts
Contacts
Card
(Upside-down) Epoxy

Contacts (8)
SOURCE: SMART CARD FORUM
Old (8-bit) Smart Card
Architecture

EEPROM:
Electrically
Erasable
Programmable
Read-Only
Memory

SOURCE: SMART CARD FORUM

Smart Card Components
Processors
◼ 8-bit, typical clock speed: 5 MHz (8-bit)

◼ Optional cryptographic processor

◼ 32-bit, clock speed 300 MHz

◼ 64-bit, 600 MHz

SOURCE: SUMIT DHAR

Smart Card Components
ROM: Read Only Memory
◼ Used for storing fixed programs. Holds the
operating system
◼ Typically varies from 2KB to around 16 KB

◼ Once written, cannot be changed

◼ Occupies the least area

PROM: Programmable Read Only Memory

◼ Used for loading card serial number

◼ Very small, typically just 32 bytes

SOURCE: SUMIT DHAR
Smart Card Components

EEPROM: Electrically Erasable Read Only Memory

◼ Stores variable data

◼ Holds various applications and their data.

◼ Can be read or written to subject to permissions.

◼ Typically 2 - 32 KB

RAM: Random Access Memory

◼ Used as temporary storage.

◼ Erased on power off.

◼ Typically 128-512 bytes

SOURCE: SUMIT DHAR

Cyberflex™ Java Smart Card
◼ Complete 32-bit Java run-time environment on a
card
◼ Utilities for compiling and loading cardlets onto
the card from a PC
CARDLETS

1 2 3

JAVA VIRTUAL MACHINE

OPERATING SYSTEM
MICROPROCESSOR
Smart Card Architecture
◼ File structure (ISO 7816-4)
❑ Cyclic files

◼ Database management on a card

❑ SCQL (Structured Card Query Language)
❑ Provides standardized interface
❑ No need to know file formatting details
Cyclic File
byte number
1 2 3 4 5 6 7 8 9 m
record 1
number
2
3
4

n
n+1st record

❑ READ gives the most recently written record

❑ Maximum number of records: 254
❑ When maximum is reached, first record is overwritten
❑ Record length: 1 .. 254 bytes SOURCE: ANDREAS STEFFEN
ATM and Debit Card Cryptography

◼ PIN cannot be stored anywhere in plaintext

◼ PIN cannot be reverse-engineered from the card
or any database
◼ Generate a random 4-digit number (the PIN)
◼ Combine PIN with other data (account number)
to form a data block
◼ Encrypt the data block using 3DES and secret
bank keys
◼ Select several digits from the encrypted data to
use as the Pin Verification Value (P V V)
Forming the Pin Verification Value

ACCOUNT 4-DIGIT
NUMBER PIN

SECRET ENCRYPTED
BANK KEYS
3DES DATA BLOCK
SELECT 4-6 DIGITS
FROM ENCRYPTED DATA
BLOCK TO FORM P V V

PIN VERIFICATION
VALUE (P V V)

CARD HAS
ACCOUNT NUMBER
AND P V V
Using the Card
CARD HAS
ACCOUNT NUMBER
AND PVV
P V Vs MATCH?
ATM MACHINE READS ACCOUNT USER IS AUTHENTIC
NUMBER AND P V V
P V Vs DIFFERENT?
USER TYPES PIN
USER IS REJECTED
MACHINE NOW HAS:

ACCOUNT 4-DIGIT
PVV COMPARE CARD P V V
NUMBER PIN
WITH COMPUTED P V V
MACHINE HAS BANK
KEYS IN HARDWARE:

SECRET ENCRYPTED
BANK KEYS
3DES DATA BLOCK
PVV

COMPUTE P V V
 OpenCard Framework (OCF)

CardService
Layer
(TALKS TO CARD)

CardTerminal
Layer
(TALKS TO READER)

SOURCE: OPENCARD.ORG

SOURCE: OPENCARD.ORG
 Card Security Threats

Group 5
ATTACKS ON THE RUN-TIME
ENVIRONMENT THROUGH THE
Group 6
CARD ACCEPTANCE DEVICE (CAD)
THREATS FROM CARD APPS AND
NEED TO SHARE RESOURCES
Clone
Future
Past Group 7
Group 3 Current
ATTACKS USING CARDS THREATS BASED ON RTE
NOT YET ISSUED, OLD
CARDS, CLONES
CAD IMPLEMENTATION

Group 4
Group 1 ATTACKS ON CARD’S
INTERFACE TO THE OUTSIDE, Group 2
DIRECT ATTACKS ON E.G. PREMATURE REMOVAL INDIRECT ATTACKS
CHIP CIRCUITRY
ON CHIP CIRCUITRY

SOURCE: GAMMA
Power and Timing Analysis

NOP MUL JMP

(no operation) (multiplication) (jump)

power
consumption

time
Source: Rankl and Effing, "Handbuch der Chipkarten", 2002
 Differential Power Analysis
◼ Send different inputs to the Smart Card to learn details of its
encryption key
◼ When a correct key value is tried, the algorithm responds
◼ Incorrect keys have zero average response

INITIAL SMART CARD POWER CONSUMPTION 16 DES ROUNDS

PERMUTATION DURING DES ENCRYPTION
FINAL PERMUTATION

EXPANDED VIEW
OF ROUNDS 2 & 3

SOURCE: cryptography.com
Reverse
engineering
Probing with Needles
Contactless Card

◼ Communicates by radio
❑ Power supplied by reader
❑ Data rate 106 Kb/sec
❑ Read 2.5 ms, write 9 ms
❑ 8 Kb EEPROM, unlimited read, 100,000 writes
❑ Effective range: 10 cm, signals encrypted
❑ Lifetime: 2 years (data retention 10 years)
❑ Two-way authentication, nonces, secret keys
❑ Anticollision mechanism for multiple cards
❑ Unique card serial number SOURCE: GEMPLUS
RFID Tags
IC Chip

32mm and 23mm

capsule transponder

Antenna
 How RFID Works
◼ Tag enters RF field Antenna
◼ RF signal powers tag
◼ Tag transmits ID, plus data
◼ Reader captures data
◼ Reader sends data to
computer
◼ Computer determines action
◼ Computer instructs reader
◼ Reader transmits data to tag Tag

Computer
RFID
Reader
SOURCE: PHILIPS
Euro Banknotes
◼ European Central Bank has announced plans to
implant RFID tags in banknotes by 2005

• Uses
– Anti-counterfeiting
– Tracking money flows
PAYMENT ON A KEYCHAIN

SMALL AND CHEAP

Automated Toll Collection
Hong Kong Smart Cards

◼ Octopus
❑ 12 million cards, 15,000 readers
❑ 7 million transactions/day
❑ $48M HKD per day
◼ Visacash
◼ ComPass Visa (VME)
◼ Mondex
◼ GSM SIM, ePark
Octopus Card Features
◼ Hong Kong RFID payment card
◼ Operating distance: 15 cm
◼ Bandwidth: 211 Kb/sec
◼ Triple DES in 70 sec
◼ EEPROM 1536 bytes
◼ 128-byte data backup area
◼ 16-byte manufacturer ID; 16-byte issue ID
◼ Processing time: 50 msec on card, 300 msec
overall
◼ Random access and cyclic files SOURCE: MITSUBISHI

◼ Anti-collision protocol
Octopus Card Security

SOURCE: MITSUBISHI
Octopus

SONY RC-S833
CONTACTLESS SMART CARD
SONY READER/WRITER

I/O SPEED: 211 Kbps

SOURCE: SONY
Octopus Expansion

• Identity card
• Access control
• Hotel room key
• Credit card
• McDonalds
• Mobile phone
• Home readers

SOURCE: CREATIVE STAR

Octopus Clearing

CENTRAL CLEARING
HOUSE SYSTEM

SERVICE
PROVIDER
CENTRAL
COMPUTER

LOCAL
DATA
PROCESSOR

SOURCE:

SOURCE: SAMMY KAM

 Octopus Settlement
SERVICE PROVIDER
• CONSOLIDATE DATA CENTRAL COMPUTERS
• PRINT REPORTS (SPCC)
• ROUTE DATA TO CCHS MTR CENTRAL
COMPUTER LOAD AGENT
CENTRAL
COMPUTER

• DISTRIBUTE SOFTWARE
CENTRAL
• COLLECT TRANSACTIONS
STATION CLEARING
• PRINT REPORTS
COMPUTER HOUSE
• SEND DATA TO SPCC
CCHS SYSTEM
• VALIDATE DATA
• NET ACCOUNTING
SETTLE MENT
• MUTUAL HSBC HEXAGON OCTOPUS
AUTHENTICATION BANK
• CHECK BLACKLIST
• UPDATE CARD LOAD REGULAR ACCT
MTR’S
• STORE TRANSACTIONS AGENT’S BUFFER ACCT
BANK
FARE PROCESSORS BANK RESERVE ACCT
Major Ideas
◼ Smart cards replace cash
◼ Potential of cards is unexplored; new uses every
day
◼ Powerful microprocessors allow
❑ cryptography
❑ certificates, authentication
❑ secure purses
◼ Wireless (contactless) cards enable new business
models
◼ Smart card security is not perfect
Chương 8.1: Peer-to-Peer Payments
ThS Phạm Mạnh Cường
Outline
◼ Peer-to-peer payments
❑ PayPal
❑ eCount.com
◼ Electronic banking
◼ B2B payments
1. Peer-to-Peer (P2P) Concepts
◼ P2P
❑ payments not involving a bank
❑ payments “directly” between payor and payee
❑ classic example: cash
❑ email payments, transfers between digital wallets
❑ purchasing online content
❑ micropayments
◼ Distinguish between P2P payments and P2P
technology
❑ Napster, bitTorrent, Gnutella
◼ Someday we may use P2P technology for P2P
payments
PayPal
◼ > 188,000,000 accounts (2016)
◼ RTGS payment system (Real-time gross
settlement )
◼ Credit card hub
◼ Bookkeeping & accounting system
◼ Low-value foreign exchange system
 PayPal Structure
PUBLIC COMPANY

eBay

BETWEEN TWO PAYPAL

USERS, TRANSACTIONS
ONLY MAINTAINS LEDGERS
ARE PURELY BOOK ENTRIES
NO MOVEMENT OF REAL
MONEY WITHIN PAYPAL
PayPal Private Bank
IF REAL MONEY MUST
MOVE, PAYPAL SENDS X.COM’s BANK
USER INTERACTS
INSTRUCTIONS TO ITS INTERACTS WITH
WITH PAYPAL
BANK BANKING SYSTEM
THROUGH BROWSER
THROUGH ACH

User User’s Bank

USER MAINTAINS NORMAL
RELATIONS WITH HIS BANK
PayPal
◼ It’s a big disk drive!

- $100

+ $100
 PayPal
1. A PAYS X VIA 6. PAYPAL NOTIFIES
PAYPAL (A HAS X OF PAYMENT. X
ENOUGH IN PAYPAL CHOOSES PAYMENT
ACCOUNT) METHOD
ACCOUNT INTERNET
PAYPAL EMAIL
ACCOUNT
HOLDER A HOLDER X
ACCOUNT A
... 5. PAYPAL CREDITS
ACCOUNT X’S PAYPAL ACCOUNT
ACCOUNT X
HOLDER A’S 2. OR: PAYPAL
CHARGES X’S
CREDIT CARD CREDIT CARD

3. OR: PAYPAL
INITIATES ACH
DEBIT
ACCOUNT 7. OR: PAYPAL ACCOUNT
ACH
HOLDER A’S INITIATES
HOLDER X’S
PROCESSOR ACH CREDIT
BANK BANK

4. FUNDS ARE PAYPAL’S

DEPOSITED IN 8. OR: PAYPAL MAILS CHECK TO X
BANK
PAYPAL’S BANK
PayPal Concepts
◼ Merchants pay low fees; individuals pay nothing
◼ Interest paid on deposits
◼ Mass (bulk) payments possible
◼ Business model: fees + float
◼ FDIC pass-through insurance (Federal Deposit
Insurance Corporation)
❑ Against bankruptcy of PayPal
❑ Different protection for fraud
◼ Mobile payments supported
PayPal Fees

SOURCE: PAYPAL
 PayPal and Foreign Exchange
eBay

$ £
U.S. U.K.
PayPal U.S. PayPal U.K.
PayPal Bank PayPal Bank
U.K. PayPal $ Acct U.S. PayPal £ Acct

U.S.
U.S. User U.K. User U.K.
User’s Bank User’s Bank
PayPal Worldwide

202 countries Currencies: USD, CAD, GBP, EUR, JPY

SOURCE: PAYPAL
 PayPal Statistics
Products Credit cards, payment systems

[1]
Revenue US$10.84 billion (2016)

[1]
Operating income US$1.586 billion (2016)

[1]
Net income US$1.401 billion (2016)

[1]
Total assets US$33.1 billion (2016)

[1]
Total equity US$14.71 billion (2016)

[1]
Employees 18,100 (2016)
Total PayPal Payment Volume
$3,000

2003 TOTAL > 14 BILLION

$2,500
Payment Volume ($M)

$2,000

$1,500

$1,000

$500

$0
Q100 Q200 Q300 Q400 Q101 Q201 Q301 Q401 Q102 Q202 Q302 Q402 Q103

SOURCE: PAYPAL
PayPal Growth by Number of
Users 30,000
APRIL, 2004 > 41 MILLION
25,000

20,000
Users (000)

15,000

10,000

5,000

0
Q100 Q200 Q300 Q400 Q101 Q201 Q301 Q401 Q102 Q202 Q302 Q402 Q103

SOURCE: PAYPAL
PayPal Concepts (con.t)
◼ Merchants pay low fees; individuals pay nothing
◼ Interest paid on deposits
◼ Mass (bulk) payments
◼ Business model: fees + float
◼ Mobile payments possible
◼ What would happen if PayPal could be used for
everything?
Email Payments Market

SOURCE: CELENT.COM
Ecount.com

SOURCE: LAUDON & TRAVER

2. Electronic Banking
Opportunities
◼ Financial supply chain (FSC)
◼ Consumer marketing (statement has hyperlinks!)
◼ Data-rich environment
◼ Customized financial services & relationship
◼ Moving toward fee for services instead of floats
and spreads
◼ Greater security through digital signatures
◼ Risk reduction through speed
◼ Computer-initiated services means more services
Banking Services

◼ Consumer ◼ Business
❑ Payments, eCheques ❑ Payments
❑ Savings ❑ Cash management
❑ Loan services ❑ Credit
❑ Aggregation of ❑ Financial instruments
accounts ❑ Factoring
❑ Securities ❑ Trade financing
❑ Insurance
◼ Both ❑ Foreign exchange
❑ Accounting
❑ Bill presentment
❑ Integration with
❑ Reporting
business systems
◼ Terrorism, laundering
❑ 24/7 generates
business
 Australia Integrated eBanking Framework
Government Outputs: Budget Sector

Public Ledger and Central Agencies

Departmental Accounting

Revenue Expenditure
• Human Services • Commonwlth • Salaries
• Justice • Educat, NRE • Suppliers
• Taxes • Parliam, AG • Service Providers
Receipts • Tolls Cash • Transfer Payments
E-Business Management E-Commerce Payments
Value Bank Value
Transfer Bank Service and Transaction
Mgmt Transfer
• EFT • internet Single Acct for Govt
• cards • electronic OR • EFT • internet
• Single Acct for Dept • •
• cheq Maxi cards electronic
• cash • teleph Outer Budget • cheq • teleph
• mail TCV Balances • cash • mail
• counter

Information
Flows
Fund Flows Financial
Markets SOURCE: VICTORIA DEPT OF
TREASURY AND FINANCE (AU)
Internet Banking Services 2001
% of Banks Surveyed

Offer in 2001 Offer in 2004

Account Balances 52% 91%
Account Transfers 52% 90%
E-Bill Payment 41% 84%
E-Bill Presentment 10% 64%
P2P Payments 17% 61%
Brokerage Accounts 9% 56%
Account Aggregation 3% 42%
SOURCE: GRANT THORNTON 2001
3. B2B Payment Types

Payment Type Example Purpose

Payment Order Like wire transfer Buyer trusts Seller to

deliver

Payment Obligation Like promissory Seller trust Buyer to

note or purchase PAY
order

Certification Like bank- Seller doubts Buyer

accepted bill ability to PAY
of lading

Conditional Like a letter of Buyer doubts seller

credit or escrow ability to DELIVER
payment

• Payment Orders & Obligations can be future dated

• Attributes can be combined, eg conditional certified payment obligation
• Obligations can be discounted by seller’s bank & traded freely
SOURCE: DEBRA MITTERER
 B2B Payments
Initiation response Initiation confirmation
3 3
Initiation
2
Buyer’s bank Seller’s bank
e-paymentsPlus
Syntax validation bank co-branded
Non repudiation
Transaction status
TrustAct Server
Initiation
Initiation confirmation
2 5 4
Initiation Signed receipt
confirmation
Buyer 1 Seller
Agree on terms of purchase
 B2B Payments
7
Funds transfer

Debit Credit
confirmation 8’ 9’ confirmation
Buyer’s Seller’s
bank 6 bank
Confirm conditions*

8 Debit advice e-paymentsPlus Credit advice 9

bank co-branded

TrustAct Server

Confirm conditions*
6
Buyer Seller
*Optional flow
Major Ideas
◼ P2P is cheap
◼ P2P can be ubiquitous (email)
◼ P2P is real-time
◼ eBanking is unexplored territory
❑ Start: replicate paper statements
◼ B2B payments as part of a larger trade process
 Thanh toán Điện tử
Trong Thương mại Điện tử

Chương 8: MICROPAYMENTS I
Micropayments
◼ Replacement of cash
❑ Cheaper (cash very expensive to handle)

❑ Electronic moves faster

❑ Easier to count, audit, verify

◼ Small transactions
❑ Beverages

❑ Phone calls

❑ Tolls (lệ phí cầu đường), transportation,

parking
❑ Copying

❑ Internet content

❑ Lotteries (xổ số), gambling (cờ bạc)

Micropayments
◼ Số tiền giao dịch thấp, e.g. less than $1.00
◼ Chi phí xử lý giao dịch phải thấp
◼ Các tiết giảm về mặt kỹ thuật:
❑ Không xác minh mỗi giao dịch

❑ Sử dụng mã hoá đối xứng

◼ Phương pháp thực hiện

❑ Trả trước (Prepayment)

❑ Nhóm lại (Grouping)

◼ Aggregate purchases (to amortize fixed costs)
◼ Provide float to processor
◼ Partial anonymity (individual purchases disguised)
Micropayments
◼ Thẻ trả trước (Prepaid cards)
❑ Không nhất thiết do Ngân hàng phát hành

❑ Sau này dùng thanh toán cho hàng hoá/dịch vụ.

❑ Không phải tiền vì chỉ dùng được với một nhà

cung cấp.
◼ Ví điện tử (Electronic purse / wallet)
❑ Phát hành bởi Ngân hàng, tổ chức tài chính

❑ Được bảo đảm bằng tiền thật.

❑ Dùng như một dạng thức của thẻ (for face-to-

face or Internet use)
❑ Dùng trong dạng thức ảo (computer file for
Internet use)
❑ Hai dạng thức đang hội tụ, e.g. wireless
Electronic Wallet Issues
◼ Nạp (loading, charging) ví bằng tiền
◼ Dùng thanh toán (removing money from the card)
◼ Thanh toán bù trừ (Clearance - getting money
into the seller’s account)
GeldKarte

◼ Issued by Zentraler Kreditausschuß (Germany)

◼ Card contains counters representing money value
❑ Max balance 200 EUR = USD252
◼ Card is loaded through a loading terminal
❑ Debits customer’s bank account
◼ Spending at merchant terminal or on Internet
❑ Amount deducted from card, added to merchant terminal
(card)
❑ No real-time authorization
◼ End-of-day: merchant uploads transactions
◼ Money credited to merchant account
◼ Bank fee: 0.3%, minimum USD 0.01
 Loading GeldKarte
1. LOAD REQUEST + PIN
LOADING
TERMINAL
(ATM) 8. VALUE TRANSFER

2. AUTHORIZATION 5. AUTHORIZATION
REQUEST

7. SAM EXCHANGE
SAM SAM
LOADING MANAGER ISSUING BANK
9. OFFLINE
FILE TRANSFER
3. AUTHORIZATION SAM = SECURITY
4. AUTHORIZATION REQUEST APPLICATION
6. UPDATE
ACCOUNTS MODULE

AUTHORIZATION ACCOUNT
SERVER DATABASE

SOURCE: SHERIF
GeldKarte Payment
◼ Customer inserts GeldKarte in slot (at merchant
terminal or PCMCIA card)
◼ Merchant authenticates customer card OFFLINE
(NO THIRD PARTY)
◼ Customer authenticates merchant card
◼ Transfer purchase amount
◼ Generate electronic receipts

◼ (Later) Merchant presents receipt to issuing bank

to obtain credit to merchant account
◼ No purse-to-purse transactions
GeldKarte Card Authentication
◼ Merchant SAM generates a random number RAND
(to prevent replay attack), sends to customer card
with request for customer card ID (CID)
◼ Card sends CID, a generated sequence number
SNo, RAND, and H(CID) encrypted with a
symmetric secret key SKC (known to card, not
customer)
◼ No public-key encryption
◼ Merchant computes SKC from CID and his own
secret key SKM (known to card, not merchant)
◼ Merchant can now validate integrity of the card
message by computing H(CID)
GeldKarte Value Exchange
◼ Customer sends StartPayment message
◼ Merchant sends MID, merchant’s transaction number TNo,
SNo, a MAC encrypted with SKC, CID and the value M to be
transferred, all encrypted with SKC
◼ Customer can decrypt this message with SKC and validate
merchant
◼ Customer checks CID, M and SNo (prevent replay)
◼ Customer card verifies at least M remaining, subtracts M,
increments SNo, records payment data, generates proof of
payment and sends to merchant card:
{ M, MID, SNo, TNo, ANo, MAC }

AMOUNT MERCHANT CUSTOMER MERCHANT CUSTOMER MESSAGE AUTHENTICATION

ID SEQUENCE # SEQUENCE # ACCOUNT # CODE
GeldKarte Value Exchange,
cont.

◼ Merchant verifies payment:

❑ compute actual payment amount M' from the proof of
payment, compare with M
❑ verify MID and TNo
❑ increment TNo, increase balance by M
❑ notify merchant of success
❑ record transaction data with different secret key KZD
◼ Merchant requests payment from bank (later)
❑ sends encrypted proofs of payment to bank
❑ TNo prevents more than one credit per transaction
GeldKarte Clearing
◼ Uses a “shadow account”
(Börsenverechnungskonto) to track the contents of
the card
❑ When card is loaded, shadow account is credited
❑ When money is spent, shadow account is debited
◼ online transactions immediately

◼ offline transactions later

◼ If card is lost or damaged, money can be replaced

◼ Problem: every transaction is recorded, no
anonymity
◼ Solution: “Weisse Karte.” Bought for cash, not
connected to any bank account
GeldKarte Security
◼ DES (customer), triple DES (merchant) (cipher
block chaining or cipher feedback mode)
◼ 128-bit hashes
◼ Each card has unique ID, unique symmetric key,
PIN stored in “secret zone” and in bank
◼ Unique transaction numbers
 GeldKarte Internet Payment

“Caroline” Trusted
Wallet Device

GeldKarte Reader
USB or Infrared
Connection to PC

◼ Wireless potential CASHMOUSE

Other Electronic Purses

QIANFLEX (CHINA) AUSTRIAN QUICK

PRISMERA PEOPLE’S BANK OF CHINA ePURSE

CYBERFLEX JAVA CARD

DANMØNT
Remote Micropayments
◼ Remote micropayments
❑ Buyer is not physically in seller’s presence
❑ Can’t insert card into vendor’s machine
❑ No physical goods, only information goods
◼ if micropayment will work, goods must be cheap, e.g.
$0.01
❑ Subscriptions, credit cards, checks, ACH (even PayPal)
too expensive
◼ Examples: web pages, stock quotes,news
articles, weather report, directory lookup
◼ Need instant service for large numbers of 1¢
transactions + reasonable profit to payment
provider
 Remote Micropayment Parties
◼ Users (buyers) User Vendor
◼ Vendors (sellers) Web
Browser
Web
Server
◼ Brokers (intermediaries)
Scrip
❑ issue “scrip” (virtual money – tiền ảo)
to users
Broker
❑ redeem scrip from vendors Server
for real money Broker

◼ Assumptions
❑ Quan hệ User-Broker là quan hệ lâu dài
❑ Quan hệ Vendor-Broker là quan hệ lâu dài
❑ Quan hệ User-Vendor là quan hệ ngắn hạn
Micropayment Efficiency
◼ Providers need to process a peak load of at least
2500 transactions/second
◼ Public-key cryptography is expensive
❑ 1 RSA signature verifications = 1000 symmetric encryptions
= 10,000 hashes
◼ Need to minimize Internet traffic
❑ Servers must be up
❑ More servers required, longer queues, lost packet delay
❑ Remove the provider from the process (user + vendor only)
◼ For small payment amounts, perfection (sự hoàn
hảo) is not needed
❑ Losing a micropayment –
❑ Keep micropayment fraud low
Payword Concept
◼ Hash functions are one-way and easy to compute
◼ Use them to secure scrip
◼ Suppose we need N “coins”
◼ Start with a random number WN
◼ Hash it N times to form W0
WN WN-1 WN-2 • • • W1 W0
WN-1 = H(WN ) WN-2 = H(WN-1 ) W1 = H(W2 ) W0 = H(W1 )

◼ Vendor receives W0 to start

◼ Each payword is worth one unit
◼ When vendor receives W53 he verifies it by
hashing
Payword
◼ Based on “paywords,” strings that will be accepted
by vendors for purchases
◼ User authenticates himself to a broker with one
signature verification, establishes means of paying
“real” money for paywords
◼ User sets up with broker a linked chain of paywords
to be used with a specific vendor. (Linking is used
to make authentication of the paywords very cheap.)
◼ User pays vendor by revealing (tiết lộ) paywords to
vendor
◼ Marginal cost of a payment: one hash computation
Payword
◼ User sets up Payword account with a broker (pays
real money)
◼ Broker issues user a “virtual card” (certificate)
❑ broker name, user name, user IP address, user public key
◼ Certificate authenticates user to vendor
◼ User creates payword chains (typical length: 100
units) specific to a vendor
Buying Paywords
◼ User visits broker over secure channel (e.g.
SSL), giving coordinates of bank account or
credit card:
U, A U, PKU, TU, $U
USER USER USER USER COORDINATES OF BANK
NAME ADDRESS PUBLIC KEY CERTIFICATE ACCOUNT OR CC

◼ Broker issues a subscription card

CU = { B, U, AU, PKU, E, IU } SKB

BROKER EXPIRATION USER INFORMATION BROKER

NAME DATE (CARD #, CREDIT LIMIT) PRIVATE KEY

◼ Vendor will deliver goods only to AU

 Making Payment
◼ Commitment to a payword chain = promise by user to
pay vendor for all paywords given out by user before E
❑ N = value in jetons needed for purchases (1 payword = 1 jeton)
❑ WN = last payword, a random value chose by user
◼ User creates payword chain backwards by hashing WN
WN-1 = H(WN); WN-2 = H(WN-1) = H(H(WN)) , etc., giving
 CAN EASILY COMPUTE THIS WAY
W = { W0, W1, . . . WN-1, WN } → DIFFICULT TO COMPUNTE THIS WAY

◼ User “commits” this chain to a vendor, sends

M IS VENDOR EXPENSIVE: REQUIRES
SPECIFIC AND M = { V, CU, W0, D, IM } SKU DIGITAL SIGNATURE
USER-SPECIFIC

(NO USE TO EXPIRATION

VENDOR “FIRST” DATE OF
EXTRA INFORMATION USER
ANYONE ELSE) NAME (VALUE OF CHAIN) PRIVATE KEY
PAYWORD COMMITMENT
Making Payment, cont.

◼ Vendor can use PKU and PKB to read the commitment to

know that U is currently authorized to spend paywords.
◼ User “spends” paywords with the vendor in order
W1 , W2 , . . . , WN . To spend payword Wi, user sends the
vendor the unsigned token P = { Wi, i }.
◼ To verify that P is legitimate, vendor hashes it i times to
obtain W0 . If this matches W0 in the commitment, the
payment is good.
◼ If V stores the last payword value seen from U, only one hash
is needed. (If last hash was Wi, when vendor receives Wi+1,
can hash it once and compare with Wi .)
◼ P does not have to be signed because hash is one-way.
Settlement with Payword
◼ Even if vendor has no relationship with broker B,
can still verify user paywords (only need broker’s
public key)
◼ For vendor to get money from B requires
relationship
◼ Vendor sends broker B a reimbursement request for
each user that sent paywords with M, WL (last
payword received by vendor)
◼ Broker verifies each commitment using PKU and
performs L hashes to go from WL to W0
◼ Broker pays V, aggregates commitments of U and
bills U’s credit card or debits money from U’s bank
account
Payword Payment Properties
◼ Payment and verification by vendor are offline (no
use of a trusted authority).
◼ Payment token P does not reveal the goods
◼ Fraud by user (issuing paywords without paying for
them) will be detected by the broker; loss should be
small
◼ Vendor keeps record of unexpired paywords to
guard against replay
Major Ideas
◼ Micropayment systems must be fast and cheap
◼ They MUST lack features of higher-value
payment systems
◼ Use of hashing instead of cryptography
◼ Micropayment parties: buyer, seller, broker
◼ Payword user generates his own coins!
◼ Fraud is not a serious problem with
micropayments
Chapter 9:
Crypto Currencies

MSc Phạm Mạnh Cường

Crypto Currencies and Virtual
Currencies
◼ Crypto Currencies
❑ Based on algorithm that generates unique
tokens that can be used in “real” world
❑ Example: Bitcoin, Ethereum, Bitcoin Cash
◼ Virtual currencies
❑ Circulate within internal virtual world
❑ Example: Linden Dollars in Second Life,
Facebook Credits
What e-mail was
to post-cards,
Bitcoin is to
cash-money.
Bitcoin is Amazing

⚫ No Central ownership,
authority, or control
⚫ Open Source, peer-
reviewed
⚫ Secure! And we know
this.
⚫ Push, not “pull” based
Who created bitcoin?
What is the most expensive
pizza in the world?
Bitcoin Basics
⚫ There will only ever be 21 million coins
⚫ Divisible! One bitcoin can be divided into
100,000,000 Satoshis
⚫ Network maintenance is performed by
miners, who are rewarded in Bitcoin
⚫ Defines a 'blockchain' the world's
distributed asset/ownership ledger
Bitcoin last year!
Bitcoin right now!
 The Blockchain is Revolutionary
⚫ A protocol (system) for allocating scarce
resources
⚫ Has no center, everyone participates
⚫ Asserts 'truth' when everyone has an
incentive to lie
⚫ Manages Scarcity (Domain names, SSL
Certificates, Bandwidth Credits, Property
Deeds, Identity)
 Why do we need Bitcoin?
⚫ Cash doesn't work online.
⚫ Credit cards are inconvenient
⚫ Transaction fees are too high
⚫ Micropayments
⚫ Current systems require too much trust!
⚫ Not all good customers are creditworthy.
⚫ Underserved Banking clients
⚫ Globalization
Traditonal Checkouts vs Bitcoin

1
2
3 4
5
6
7
8
9
10 11
12
13
Common Misconceptions
Where is this going?
⚫ Incumbents will compete, and fail.
⚫ Fast adoption in Remittance markets
⚫ Innovation without permission
⚫ Some countries will be forced to embrace a
mainstream Bitcoin economy
⚫ What Internet was to newspapers, Bitcoin
is to banks
⚫ Migrations away from Centralized
Databases
How to get started
⚫ Create a Coinbase account and buy some
bitcoins
⚫ Create a Blockchain.info wallet and
install the app on your phone
⚫ Accept Bitcoin from peers and clients.
⚫ Pro-actively offer to pay vendors in
Bitcoin in person and online!
Bitcoin is real, and here to stay!
Other popular digital cash