Chương 4.

Thanh toán điện tử (tiếp)

- Mong muốn của tiền điện tử

• Tiền số phải được chấp nhận mọi nơi

• Tiền số phải có thể giao dịch được
• Có thể chia ra?
• Không bị giả mạo
• Tính bảo mật (không ai ngoại trừ những bên liên quan biết đến số lượng)
• Tính ẩn danh (không ai biết người mua, kể cả ngân hàng)
• Off-line (không cần xác thực online)

1. Electronic Cash
- Advantage: small-medium purchases (<10$)

+) Micropayments (<1$)

- Giao thức cơ bản của tiền điện tử

1.1. Vấn đề lớn nhất của E cash

• E-coins (chỉ là tài liệu điện tử → dễ dàng bị sao chép, giả mạo) chỉ được tiêu một lần (không được
tiêu nhiều lần)
• Người dùng muốn hưởng tính ẩn danh như tiền mặt
• Divisibility and Convenience
• Giao dịch phức tạp

1.2. Lưu trữ:

+) Online

• cất tại một nơi thứ 3

+) Offline

• Người dùng cất ecoin tại smartcards hoặc ví điện tử

• Đòi hỏi các kỹ thuật đặc biệt chống gian lận, double spending

1.3. Advantages & Disadvantages của e cash

Advantages:

• Tiện lợi, không/ít mất phí

• Ai cũng có thể sử dụng được (không như credit card – cần xác thực danh tính)

Disadvantages:

• Rửa tiền, tống tiền (blackmail)

• Trốn thuế
• Dễ dàng lừa đảo

1.4. Ecash security

- Các giao thức thuật toán phức tạp để phòng trống double spending

→ Tính ẩn danh là tuyệt đối nhưng người mà double spending có thể bị truy vết

→ Chống double spending mà vẫn giữ được tính ẩn danh

- Serial numbers có thể cho phép lần vết để ngăn chặn rửa tiền

→ Không thể chặn double spending

2. Blind signatures (QUAN TRỌNG) (104-

- Mục tiêu: Cho nhà bank kí đồng tiền mà bank không biết mình kí gì

→ Đảm bảo tính ẩn danh mà vẫn có thể xác thực (anonymity + authentication)

Trong hệ chữ ký thường, người ký phải được nắm rõ nội dung văn bản cần ký, có thể lưu bản sao. Với chữ
ký số, vấn đề an toàn nhắc lại ở đây, khi B ký vào M do A tạo ra, việc A có thể bóp méo văn bản M sau đó
phải được phòng chống

→ Nói cách khác, khi A xin được từ B văn bản có chữ ký 𝑀||𝑆 = 𝑆𝐵 (𝑀) , A sẽ không thể tạo ra một cặp
𝑀′ ||𝑆 ′ sao cho 𝑆 ′ = 𝑆𝐵 (𝑀′ )

Trong hệ chữ ký mù (blind signature) thì ngược lại, người ký sẽ không được làm chủ thực sự lên nội dung
mình ký.

→ Nói cách khác, khi B ký lên M do A tạo ra, sau đó A có thể tạo ra 𝑀′ ||𝑆 ′ = 𝑆𝐵 (𝑀′), mà B thì không biết
được 𝑀′ dù đã lưu M trước đó.

Tuy nhiên, hệ chữ ký này đảm bảo cho người ký B khả năng kiểm tra tính hợp lệ của thông tin cần ký.

→ Cách thức tạo ra 𝑀 và 𝑀′ của A vẫn được kiểm soát

Có thể hiểu như cho hợp đồng vào phong bì (làm bằng giấy than) và khóa lại

→ nhà băng kí vào bên ngoài phong bì (thì nó sẽ kí luôn bên trong)

→ về nhà mình sẽ mở khóa ra lấy message đã có chữ kí của ngân hàng

→ Mặc dù B không biết được nội dung thật của văn bản này, nhưng có thể đánh giá được tính
trung thực của A (không tạo ra gì xấu cho B) bằng một phép kiểm tra challenge-response.
Ví dụ: ví dụ đơn giản thể hiện ứng dụng của blind signature trong e-cash

Alice khi muốn đưa nhà băng ký lên một văn bản x nào đó, sẽ sử dụng một số p (bí mật). Thay vì
đưa thẳng cho nhà băng giá trị băm h(x) thì đưa
ℎ(𝑥)𝑝3 (𝑚𝑜𝑑 𝑁)
Nhà băng ký lên (tức là tính căn bậc 3 của giá trị đó) (chỉ nhà băng làm được vì mình nó nắm được
PTTSNT của N) rồi trả cho Alice
ℎ(𝑥)1/3 𝑝 (𝑚𝑜𝑑 𝑁)
Alice chỉ việc chia giá trị này cho p thì thu được ℎ(𝑥)1/3 tức là chữ ký của nhà băng (trong khi nhà
băng không hề biết được h(x))
1
→ Alice có (𝑥, ℎ(𝑥)3 ) như một đồng tiền mặt, khi đi mua hàng có thể trả cho người bán hàng.
Người bán hàng sẽ kiểm tra một đồng tiền (𝑎, 𝑏) bằng cách so sánh ℎ(𝑎) với 𝑏 3 . Nếu hợp lệ thì
chấp nhận đồng tiền đó.
→ Sau này đồng tiền điện tử đó sẽ được chủ cửa hàng gửi về nhà băng để được thánh toán vào
tài khoản anh ta.

- How? - Challenge and response (ví dụ capcha…)

- Ý tưởng:

Đồng tiền không phải do nhà băng tạo ra nữa

Người tiêu tiền tự tạo ra, ẩn ID của người ta vào (tại sao? → để cung cấp tính ẩn danh)

- Người ta muốn off-line và ẩn danh và security chống double spending cho E-cash

Phát hành từ nhà băng chuyển nhiệm vụ cho người tiêu dùng (nhưng mà đồng tiền vẫn phải có chữ ký của
nhà băng thì mới hợp pháp) → sinh ra chữ ký mù

- Tạo ra như một cặp số (a,b) mà thỏa mãn quan hệ mà khớp với ID của người này R(a,b,ID) = True, ví dụ
b/a = ID (có vô số cặp như vậy)

3. Cut and Choose

- Vấn đề: làm sao để khiến nhà băng tin tưởng tính hợp lệ của ID (tin tưởng nội dung bên trong phong bì)

→ Nguyên tắc Cut and Choose

- Thu hết 10 cái, chọn 1 cái ngẫu nhiên cho vào túi và bảo C mở ra 9 phong bì ra (show nội dung
a,b,ID, a2, b2, a3, b3... ra)

- Nhà băng kiểm tra xem 9 cái có lưu ID xịn không (quan hệ B(a,b,ID) = True)

- Sau khi hợp lệ thì kí lên cái còn lại

4. Detecting Double Spending (QUAN TRỌNG) (221-

Vấn đề: đồng e-cash có thể được tiêu nhiều lần (vì chúng chỉ là bits).
➔ Vì vậy, trong quá trình thanh toán người ta luôn cần có thủ tục kiểm tra tính hợp lệ của đồng tiền số,
bao gồm cấu trúc đồng tiền và hiệu lực thanh toán hiện thời của chúng (đồng tiền đã được tiêu lần nào
chưa).

Ví dụ: Ẩn ID đúng một lần → người ta hỏi cấu trúc mình sẽ trả lời → không bị lộ ID

Customer có ID là (a, b) (cái ID này customer muốn giữ bí mật)

Customer đi đến Merchant 1 (M1) để mua, M1 đưa r1 cho C (kiểu để challenge, mong đợi
customer response bằng tiền)
M → C: r1
C → M: a*r1 + b = t1
Lúc này M1 sẽ đem (r1, t1) đến ngân hàng đổi tiền. Trong trường hợp Customer này tiêu tiền ở
chỗ khác nữa (double spending)
M2 → C: r2
C → M2: a * r2 + b = t2
→ Nếu M2 đem (r2, t2) đến ngân hàng, ngân hàng sẽ tìm ra được (a,b) và lấy được ID của thằng
này đã tiêu nhiều lần

6. Remote Micropayment (QUAN TRỌNG)

6.0. Abstract
- provider phải cung cấp giải pháp có tốc độ xử lý rất nhanh (ít nhất 2500 giao dịch/s)

+) Vì kiểu micro thì thường click nhanh → thanh toán phải nhanh (dùng chữ kí điện tử thì chậm)

+) Sử dụng hàm băm (light-weight crypto tools) vì hiệu quả. Tất nhiên không bảo mật như RSA
verifications = 10,000 hash, mã hóa đối xứng)

Khi xử lý thanh toán → dồn lại thành batch

- Thiếu vắng chữ kí điện tử không đúng

- bấm từng trang thì dùng hàm băm, nhưng mà thoát ra vào lại thì dùng chữ kí điện tử để kiểm tra cả một
session.

- Các nhân vật:

+) Môi giới (cò) trung gian (nói đến thường là một công ty) (user, vendor thường là nhỏ lẻ)

(Cung cấp giải pháp mạnh, scrip là một loại tiền riêng nội bộ, nó đơn giản cho phép user tự tạo ra để dùng
→ khi tạo ra cần có sự cho phép broker (ủy nhiệm phát hành)

→ user-vendor: vãng lai → user-broker và vendor-broker: lâu dài

6.1. Pha 1: user mua paywords

- User sẽ phải đưa thông tin mình cho broker

User → Broker U, Au, PKu, Tu, $u

(user name; address; Public Key user; Certificate; Bank account)

- Broker sẽ đưa cho User cái thẻ subscription

Broker → User Cu = {B, U, Au, PKu, E, Iu} SKu

(Broker name; U; Au; PKu; Expiration date; User information (card limit…) , Broker private key)

→ Lúc này nếu đi mua vendor thì vendor sẽ chỉ đưa hàng cho Au thôi.

6.2. Pha 2: User đi shopping

- User tạo payword bao gồm N đồng bằng cách hash N lần

- User phải tạo cam kết với vendor là chuỗi W = {Wo , …., WN } chỉ tiêu cho vendor này thôi, bằng cách
gửi commitment

User → Vendor

- Vendor sẽ dùng PKu (để mở khóa commitment rằng chỉ tiêu cho vendor này thôi) và PKb (để mở khóa
Cu) để biết rằng U đang có quyền được tiêu đống payword này.

(Chú ý hai lần mở khóa này là dùng RSA sign verification ~ 10,000 hash)

- User tiêu payword theo thứ tự W1, ..., Wn. Để tiêu Wi thì
 user -> vendor token (unsigned) P {Wi, i}

- Vendor nhận token và kiểm tra token hợp lệ hay không bằng cách hash Wi I lần xem nó có bằng Wo hay
không (Vendor đã thấy Wo vì vừa dùng PKu để mở commit M ra mà)

6.3. Pha 3: Vendor thanh toán với broker

- Vendor gửi broker yêu cầu thanh toán bằng cách

Vendor → broker M (cam kết) + WL (last payword mà nhận được)

- Broker sẽ

+) Xác thực cam kết M bằng PKu → thu được Wo (để check)

+) Thực hiện hash L lần xem WL kia có bằng Wo mới thu được hay không.

- Nếu có, broker thanh toán cho vendor và xuất hóa đơn vào thẻ tín dụng của User hoặc trừ tiền từ tài
khoản ngân hàng của User.

6.4. Bài tập trên lớp

Coi mỗi lần băm là mất 1 đồng CPU time. Có một người vào shop thanh toán cọc xu 1000 coin.

Tổng CPU times mà shop phải tiêu là bao nhiêu?

Bài làm

- Shop là vendor. (đọc lại pha 2)

- Vendor sẽ dùng PKu (để mở khóa commitment rằng chỉ tiêu cho vendor này thôi) và PKb (để mở khóa
Cu) để biết rằng U đang có quyền được tiêu đống payword này.

→ Vendor mất 2 lần verify bằng khóa chữ kí, mỗi lần tốn = 10,000 hash

Sau đó, vendor sẽ hash 1000 lần xem đồng tiền user đưa có bằng Wo hay không (tốn 1000đ)

→ Tốn 21,000đ

NHÁP (ĐỪNG ĐỌC)