Câu 24: Tìm hiểu về Thẻ thông minh

.

16

Câu 25: Tiền mặt điện tử (Electronic Cash)

18

Câu

26

. Thanh toán Micropayment và Thanh toán Micropayment từ xa

.

19

CÂU 27. Payword

.

21

CÂU 28. MicroMint

23

CÂU29. Millicent

25

CÂU 30:Nguyên nhân trở ngại của TMĐT phát triển

.

27

CÂU 31: Vấn đề an ninh cho các hệ thống TMĐT

.

27

CÂU 32: Giao thức trọng tài

27

CÂU

33: Giao thức phân xử

.

28

CÂU 34: Giao thức Trao đổi khóa với mã đối xứng

.

28

CÂU 35: Giao thức Trao đổi khóa với mã khóa công khai

29

CÂU 36: Giao thức

Needham-Schroede

r

29

CÂU 37:  Chữ ký mù

.

30

CÂU 38. Không theo dõi giao dịch thanh toán

.

30

CÂU 39 : Nặc danh người dùng và không theo dõi

31

CÂU 40 . Sự nặc danh người thanh toán

.

32

CÂU 41 . Bảo mật dữ liệu giao dịch thanh toán

.

34

CÂU 42 . Chống phủ định giao dịch thanh toán

.

35

Câu 43. Không theo dõi giao dịch thanh toán

Câu 24

a)

Khái niệm:

Thẻ điện tử có chứa một microchip nhúng, cho phép các hoạt động xác định trước, thêm, xóa hay thao tác thông tin trên thẻ

§

Contact card

–

Một thẻ thông minh có chứa một đĩa vàng nhỏ trên mặt khi được đưa vào trong một đầu đọc thẻ thông minh

thì tiếp xúc

và chuyển dữ liệu

tới

và từ

micro

chip nhúng

§

Contactless (proximity) card

–

T

hẻ thông minh với một ăng-ten nhúng,

theo đó

dữ liệu và các ứng dụng được truyền đến và đi từ một đơn vị đầu đọc thẻ hoặc thiết bị khác mà không cần tiếp xúc giữa thẻ và đầu đọc thẻ

§

Smart card reader

–

Kích hoạt và đọc nội dung của các chip trên một thẻ thông minh, thường là

chuyển

các thông tin t

ới

một hệ thống máy chủ

§

Smart card operating system

–

Hệ thống đặc biệt tổ chức quản lý tập tin

,

tính bảo mật

, đầu vào/đầu ra (I/O), thực hiện lệnh và cung cấp một giao diện lập trình ứng dụng (API) cho thẻ thông minh

b)

Ứng dụng của thẻ thông minh:

-

Hoạt động mua/bán lẻ

+ Ví điện tử E-purse

i.

Ứng dụng t

hẻ thông minh

,

nạp tiền từ tài khoản ngân hàng của chủ thẻ

lên

thẻ chip thông minh

ii.

Có đ

ặc điểm kỹ thuật

 của v

í điện tử thông thường

, t

iêu chuẩn điều chỉnh hoạt động và khả năng tương tác của các dịch vụ ví điện t

ử

-

Transit Giá vé

+

Để loại bỏ sự bất tiện của nhiều loại vé được sử dụng trong các phương tiện giao thông công cộng

+ T

hực hiện hệ thống bán vé

  bằng

thẻ thông minh

-

Chứng thực điện tử (E-Identification)

+ L

ưu trữ thông tin cá nhân

:

hình ảnh, nhận dạng sinh trắc học, chữ ký số, và các phím

bảo mật

cá

nhân, thẻ thông minh đang được sử dụng trong một loạt các ứng dụng xác định, kiểm soát truy cập, và xác thực

+ eID

+ eDriver’s License

+ ePassport

+ eHealth Card

+ eEmployee Card

+ eDigital Signature Card

+ eCitizen Card

Ứng dụng thẻ thông minh trong chăm sóc y tế

§

Lưu trữ thông tin y tế quan trọng trong trường hợp

khẩn cấp

§

Ngăn chặn các bệnh nhân

nhận đơn thuốc

từ các bác sĩ khác nhau

§

Xác minh danh tính của bệnh nhân và bảo hiểm

§

Đẩy nhanh

quy

trình

giường bệnh

hoặc

các tình huống khẩn cấp

§

Cung cấp cho học viên y tế có quyền truy cập an toàn vào lịch sử y tế của bệnh nhân hoàn chỉnh

§

Đẩy nhanh quá trình thanh toán và tuyên bố

§

Cho phép bệnh nhân để truy cập các hồ sơ y tế của họ qua Internet

c)

Thẻ thông minh an ninh

-

Thẻ thông minh lưu trữ hoặc cung cấp truy cập vào tài sản có giá trị hoặc thông tin nhạy cảm

-

Phải

được

đảm

bảo

an toàn,

chống trộm cắp, lừa đảo, hoặc sử dụng sai

-

Khả năng để thực hiện hack

vào một thẻ thông minh

thuộc

phân loại tấn công

“

lớp 3

”

,

đồng nghĩa với việc

chi phí

liên quan

đến thẻ vượt xa những lợi ích

mang lại

d)

Thẻ lưu trữ giá trị (Stored-value Card)

Một thẻ có giá trị tiền tệ được nạp vào nó và thường có thể

chuyển đổi

 Câu 25 tiền mặt điệ tử

Giao thức tiền mặt điện tử cơ bả

§

Các bước cơ bản của giao thức

q

(1) C mua/trừ tiền mặt từ Ngân hàng

q

(2) B → C: đồng xu điện tử, khi tính số tiền yêu cầu + lệ phí

q

(3) C → M: đồng xu điện tử

q

(4) M → B: yêu cầu kiểm tra tính hợp lệ của đồng xu điện tử

q

(5) B → M: Xác thực giá trị đồng tiền

q

Các bên tiếp tục hoàn tất giao dịch cùng với người bán

ð

Tiền mặt điện tử hiện tại gửi vào ngân hàng phát hành khi hàng/dịch vụ được chuyển giao

Hai phương thức lưu trữ

§

On-lin

e

Người

dùng

không có sở hữu cá nhân

với

e

-

coins

, Do b

ên thứ ba đáng tin cậy chẳng hạn như ngân hàng trực tuyến nắm giữ

tài khoản tiền mặt của khách hàng

§

Off-line

Người dùng có thể giữ e-

coins

trong

thẻ thông minh

hoặc phần mềm

ví

điện tử, Sự g

ian lận và

sử dụng 2 lần đòi hỏi các kỹ thuật chống trộm đặc biệt

 Thuận lợi và bất lợi của tiền mặt điện tử

§

Thuận lợi: Hiệu quả hơn, Chi phí giao dịch thấp hơn, Thực hiện được với tất cả mọi người, không giống với thẻ tín dụng (yêu cầu cấp quyền hạn đặc biệt)

§

Bất lợi: Thuế, Nạn rửa tiền, Dễ bị làm giả

Câu

26

. Thanh toán Micropayment và Thanh toán Micropayment từ xa

+/ Thanh toán Micropayment

§

Thay thế cho phương tiện tiền mặt điện tử

§

Rẻ hơn, không quá đắt để quản lý

§

Quay vòng nhanh hơn

§

Dễ dàng đếm, kiểm soát, xác thực

§

Giá trị giao dịch thấp

§

Chi phí giao dịch thấp

§

Thích hợp nhất với những giao dịch nhỏ (nhỏ hơn 1$)

§

Đồ uống

§

Cuộc gọi điện thoại

§

Lệ phí cầu đường, vận chuyển, đỗ xe

§

Sao chép, nội dung Internet, Xổ số, cờ bạc

§

Thẻ trả trước

§

Không được phát hành bởi ngân hàng

§

Ứng dụng cuộc gọi trong tương lai

§

Ví điện tử

q

Phát hành bởi ngân hàng

q

Tiết kiệm trong việc lựa chọn công nghệ

q

Xác nhận có chọn lọc (không phải tất cả các giao dịch)

q

Sử dụng công cụ mã hóa đơn giản hơn

q

Phương pháp dự trữ động

q

Thanh toán trước

q

Quản lý biểu diễn tiền thật dưới dạng của thẻ

q

Đăng tải (tính phí) với tiền

q

Thanh toán: Loại bỏ tiền khỏi thẻ

+/ Thanh toán Micropayment từ xa

§

Bên mua là từ xa

so với bên bán

§

Không thể

chèn thẻ vào

máy của nhà cung cấp

§

Không

có

hàng hoá

vật lý

, chỉ có hàng hóa

thông tin

§

Khi sử dụng

hệ thống

micropayment, hàng hoá phải

có

giá rẻ, ví dụ như 0

.

01

$

§

Thanh toán truyền thống là quá đắ

t

§

Thuê bao điện thoại

, thẻ tín dụng,

séc

, ACH hoặc PayPal

§

Ví dụ như thanh toán

để xem

 các trang web, giá cổ phiếu, tin tức, báo cáo thời tiết,

thư mục tra cứu

§

Tính năng yêu cầu

§

Dịch vụ n

gay lập tức

§

G

iao dịch

có

giá rẻ

(

1

coins)

nhưng trong

1

số lượng

giao dịch

lớn

§

Lợi

nhuận

hợp lý cho nhà cung cấp dịch vụ

thanh toán

§

Người sử dụng (người mua)

§

Các nhà cung cấp (bên bán)

§

Môi giới (trung gian)

q

Phát hành ‘scrip’

(

là loại

tiền ảo

cho người sử dụng

)

q

M

ua lại scrip từ các nhà cung cấp

để lấy

tiền thậ

t

§

Các giả định

q

Quan hệ User-Broker là quan hệ lâu dài

q

Quan hệ Vendor-Broker là lâu dài

q

Quan hệ User-Vendor là

ngắn hạn

Hiệu quả của Micropayment

§

Các nhà cung cấp cần phải xử lý

thời

điểm

có nhiều giao dịch (

2500

giao dịch/giây

)

§

Sử dụng công cụ

bảo

mật

có chi phí thấp

q

Mật mã khóa công khai là đắt tiền

q

Cần giảm thiểu lưu lượng truy cập Internet

q

Máy chủ phải được

nâng cấp

q

Nhiều máy chủ yêu cầu, hàng đợi lâu hơn,

thất thoát

gói tin

đến

chậm

q

Hủy bỏ các

broker

khỏi

quy

trình (

chỉ có

người sử dụng +

vendor

)

§

Đối với các khoản thanh toán nhỏ,

sự

hoàn hảo là không cần thiết

q

Không phải là vấn đề lớn, nếu mất đi một micropayment

q

Cần

đảm bảo

việc gian lận

micropayment

là thấp

CÂU 27.

Payword

+/ Khái niệm

§

Phương thức thanh toán an toàn

sử dụng hàm băm

q

Như một công cụ mã hoá

light-weight

,

các hàm băm

dễ dàng

tính toán

, thuộc tính 1 chiều

của

nó

giúp bảo vệ chống lại việc

ăn cắp

các

giá trị nhỏ

§

Giả sử chúng ta cần N

“đồng xu”

q

Bắt đầu với một số ngẫu nhiên

WN

q

Băm N

lần để hình thành W

0

q

N con số

này sẽ được sử dụng như là

“

đồng xu

”

, hoặc payword, mỗi

đồng có giá trị một đơn vị

q

Người bán hàng nhận W

0­

để bắt đầu

+/ Payword

§

Dựa trên những

chuỗi “payword”

được chấp nhận bởi các nhà cung cấp để mua hàng

§

Đầu tiên, người

dùng

xác thực

với nhà môi giới

của mình một chữ ký xác minh, trả

tiền thật cho các paywords

§

Người

dùng thiết lập với

nhà môi giới

(Broker)

một chuỗi liên kết

các

paywords được

dùng

với một nhà cung cấp

(Vendor)

cụ thể

§

Liên kết được sử dụng để chứng thực các paywords có thể được

kết

hợp, vì vậy chi phí rất rẻ

§

Người dùng t

rả tiền cho nhà cung cấp

bằng cách tiết lộ

paywords cho nhà cung cấp

§

Chi phí biên của một khoản thanh toán: một tính toán hash

§

Người

dùng

thiết lập tài khoản Payword với một nhà môi giới (trả tiền thật)

§

Nhà

Môi giới

phát hành cho người dùng 1 thẻ “

ảo

”

(chứng nhận)

§

Tên nhà

Môi giới, tên người dùng,

địa chỉ IP

người sử dụn

g

, khóa công khai người sử dụng

§

C

hứng nhận xác thực người dùng với nhà cung cấp

§

Người sử dụng tạo ra chuỗi payword (

độ dài

điển hình

là

: 100 đơn vị)

đặc trưng

cho một nhà cung cấp

+/ Mua Payword

§

Người dùng

“t

hăm

”

nhà môi giới

thông qua

kênh an toàn (ví dụ như SSL),

cung cấp sự kết hợp với

khoản ngân hàng hoặc thẻ tín dụng:

§

Nhà trung gian môi giới phát hành 1 thẻ thuê bao

§

Nhà cung cấp chỉ gửi hàng tới AU

+/ Thực hiện thanh toán

§

Cam kết một chuỗi payword = lời hứa

của

người sử dụng

trả cho

nhà cung cấp cho tất cả paywords được đưa ra bởi người sử dụng trước khi

hết hạn sử dụng

q

N = giá trị

trong các

jetons cần thiết cho việc mua bán (1 payword = 1 jeton)

q

W

N

= payword cuối cùng, giá trị ngẫu nhiên đã chọn bởi người sử dụng

§

Tạo ra chuỗi payword ngược bằng cách băm W

N

§

Người dùng “cam kết” chuỗi này với vendor và gửi

§

Người bán hàng có thể sử dụng PK

U

và PK

B

để đọc các cam kết để biết rằng U hiện đang được uỷ quyền để chi tiêu paywords

§

Người sử dụng

“

chi tiêu

”

paywords với các nhà cung cấp theo thứ tự

W

1

, W

2

,. . . , W

N

§

Để chi tiêu payword W

i

, người sử dụng gửi các nhà cung cấp mã thông báo unsigned P = {W

i

, i}

§

Để xác minh rằng P là hợp pháp, nhà cung cấp thực hiện băm i lần để có được W

0

, n

ếu phù hợp với W

0

trong cam kết, thanh toán

sẽ thực hiện

tốt

§

Nếu V lưu trữ các giá trị payword cuối cùng từ U, chỉ cần băm 1 lần

(

n

ếu lần cuối băm là W

i

, khi nhà cung cấp nhận được W

i+1

, có thể băm nó một lần và so sánh với W

i

)

§

P không

cần phải

ký kết bởi vì

hàm

băm là một chiều

+/ Thanh toán với Payword

§

Ngay cả khi

vendor

không có mối quan hệ với nhà môi giới B, vẫn có thể xác minh paywords

của

người sử dụng (chỉ cần khóa công khai của nhà môi giới)

§

Đối với

vendor

để có được tiền từ B đòi hỏi phải có mối quan hệ

§

Vendor

gửi môi giới B yêu cầu bồi hoàn cho các người dùng gửi paywords với M, W

L

(

giá trị

payword

cuối cùng

nhận được bởi

vendor

)

§

Broker

kiểm tra từng cam kết sử dụng

P

K

U

và thực hiện

L

băm

để đi

từ W

L

tới

W

0

§

Broker

trả tiền cho V, tập hợp các cam kết của U và các hóa đơn thẻ tín dụng của U hoặc ghi nợ tiền từ tài khoản ngân hàng của U

+/ Thuộc tính của thanh toán Payword

§

Thanh toán và xác

thực

bởi nhà cung cấp

là offline

(không sử dụng

thẩm quyền

đáng tin cậy)

§

Thanh toán thẻ P không tiết lộ hàng

§

Gian lận bằng cách sử dụng (phát hành paywords mà không phải trả tiền cho chúng) sẽ được phát hiện bởi nhà môi giới, mất mát nhỏ

§

Vendor giữ hồ sơ của paywords chưa hết hạn để bảo vệ chống lại phát hành lại

+/ Ý tưởng chính

§

N

hanh chóng và

có chi phí thấp

§

T

hiếu các tính năng của hệ thống thanh toán

các

giá trị cao hơn

§

Sử dụng

hàm

băm thay vì

mã hóa

§

Thành phần của

Micropayment: người mua, người bán, môi giới

§

Payword người

dùng

tạo ra đồng tiền riêng của mình

§

Gian lận không phải là một vấn đề nghiêm trọng với micropayments

CÂU 28.

MicroMint

§

Brokers

sản xuất

“

đồng

xu”

có

vòng đời

ngắn, bán tiền xu

cho

người sử dụng

§

Người sử dụng phải trả nhà cung cấp bằng tiền xu

§

Các nhà cung cấp trao đổi tiền xu với các nhà môi giới

bằng

tiền

“thật”

bỏ ra

Đúc xu trong MicroMint

§

Ý tưởng: làm cho đồng tiền dễ dàng để xác minh, nhưng khó khăn để tạo ra (vì vậy không có lợi

khi làm

giả)

§

Trong MicroMint,

đồng xu

được

biểu diễn bởi đụng độ hash-function

, các giá trị x, y

sao

cho H (x) = H (y)

§

Nếu H (•)

trả

kết quả

là

một

giá trị

băm n-bit, chúng ta phải

thử

2

n/2

giá trị của x để tìm một

đụng độ 2-chiều

đầu tiên

§

Thử

c

*

2

n/2

giá trị của x

để có

c

2

đụng độ

§

Việc

tạo ra

c

ác

đụng độ

trở nên rẻ hơn sau khi một trong những

đụng độ

đầu tiên được tìm thấy

§

Một đụng độ k-chiều là một tập hợp {x

1

, x

2

,. . ,

xk} với

H (x

1

) = H (x

2

) = . . = H (x

k

)

§

Phải mất khoảng

2n(k-1)/k

giá trị của x để tìm một đụng độ k chiều

§

Phép thử

c•

2n(k-1)/k

giá trị của

x

sản

xuất

khoảng

c

k

đụng độ

§

Nếu k>2, việc tìm kiếm một đụng độ đầu tiên là chậm, nhưng chuỗi đụng độ sau đó sẽ nhanh chóng

§

Nếu một đụng độ k-chiều {x

1

, x

2

,.

.

. ,

xk

}

biểu diễn

cho một đồng

xu

, dễ dàng được xác nhận bằng

cách

tính H (x

1

), H (x

2

). . , H (x

k

)

§

Một người môi giới có thể dễ dàng tạo ra 10 tỷ đồng tiền xu mỗi tháng bằng cách sử một cơ chế

Bán xu

MicroMint

-

Môi giới tạo ra 10 tỷ đồng tiền và các

lưu trữ

(x, H (x)) cho mỗi đồng xu,

với

thời gian hiệu lực

là

một tháng

-

Các

hàm

H thay đổi ở đầu mỗi tháng

- Broker

bán đồng

xu

{x

1

, x

2

,. . ,

xk

.}

c

ho người sử dụng

để lấy

tiền

“thật”

, ghi lại thông tin những người mua xu

-

Vào cuối tháng, người sử dụng đổi lại những đồng xu chưa tiêu để lấy xu mới

Chi tiêu xu MicroMint

-

Người sử dụng gửi

vendor

một đồng xu {x

1

, x

2

,. . ,

xk

}

Người bán hàng kiểm tra tính hợp lệ bằng cách kiểm tra

H (x

1

) = H (x

2

) = . . = H (xk) (k phép tính băm)

- Nếu hợp lệ nhưng những đồng xu sử dụng 2 lần (trước đây được sử dụng với một nhà cung cấp khác) không thể được phát hiện vào thời điểm này

- Vào cuối ngày, vendor gửi tiền xu tới broker

- Broker xác minh đồng tiền, kiểm tra tính hợp lệ, kiểm tra double spending, trả tiền cho vendor

Phát hiện giả mạo MicroMint

Một đồng xu giả mạo là đụng độ k chiều {x1, x2,. . , xk} dưới hàm H (•) là không được đúc bởi broker

Người bán hàng không có thể xác định điều này trong thời gian thực

Quy mô nhỏ nên việc giả mạo là không khả thi

Giả mạo tiền trở nên không hợp lệ sau một tháng

Giả mạo không thể bắt đầu trước khi hàm băm mới được công bố

CÂU29.

Millicent

§

Vendor

sản xuất

“scrip” cùng thông xác định vendor

, bán cho

brokers

để thu

tiền

thật

§

Broker

bán scrip

của

nhiều

vendors

cho nhiều người sử dụng

§

Scrip

được

trả trước:

cam kết các

dịch vụ

tương lai

từ nhà cung cấp

§

Người sử dụng

“

chi tiêu

”

scrip với

vendors

,

ghi

nhận thay đổi

§

Broker

q

Phát hành broker

scrip cho người sử dụng

q

T

rao đổi

broker

scrip

với vendor

scrip

q

Giao

tiếp với

hệ thống ngân hàng

q

Thu thập

ngân

quỹ từ người sử dụng

q

Trả tiền cho

vendors

(ít hoa hồng)

§

User

q

Mua

broker

scrip từ

brokers

q

Chi tiêu bằng cách lấy scrip

có thông

nhà cung cấp cụ thể từ

broker

§

Vendor

q

Bán scrip cho

brokers

q

Chấp nhận

vendor scrip

từ người sử dụng

q

Gửi những

thay đổi cho người dùng

trong vendor scrip

Thành phần của Millicent

Ví điện tử

q

Tích hợp với trình duyệt như là một

“

proxy

”

q

Giao diện người dùng (nội dung, sử dụng)

§

P

hần mềm

của vendor

q

Dễ dàng để tích hợp như là một web

relay

q

Tiện ích cho quản lý giá

§

Phần mềm của broker

q

Xử lý tiền thật

Xác thực scrip Millicent

§

Mã thông báo kèm theo các yêu cầu HTTP

§

S

crip không thể được:

q

Tiêu

hai lần

q

Làm giả

q

B

ị đánh cắp

§

S

crip được xác nhận

q

Thông qua vendor

q

Chi phí tính toán thấp

q

Không c

ần

kết nối mạng

q

Không c

ần

CSDL

tìm kiếm

Máy chủ của vendor

§

Máy chủ nhà cung cấp

hoạt động như một proxy cho máy chủ

Web thực

§

Máy chủ nhà cung cấp

xử lý tất cả các yêu cầu

q

Millicent relay web server

q

M

áy chủ

§

Xử lý

Millicent

q

Xác nhận scrip và tạo ra thay đổi

q

Bán

bản

đăng ký

, Xử lý

replay,

cash-out

, và hoàn lại tiền

CÂU 30:Nguyên nhân trở ngại của TMĐT phát triển

Trả lời:

- “Lý do đầu tiên làm người dùng ngần ngại khi sử dụng TMĐT là lo bị mất thông tin thẻ tín dụng, bí mật cá nhân bị dùng sai mục đích.”

- Người dân và doanh nghiệp chưa có thói quen

- Hệ thống thanh toán điện tử còn bất cập.

- An ninh chưa đảm bảo.

- Môi trường pháp lí chưa đảm bảo.

- Môi trường xã hội và tập quán kinh doanh chưa tương thích.

- Nguồn nhân luxjwj công nghệ thông tin còn yếu và thiếu kỹ năng.

- Hạ tầng CNTT và VT chưa đáp ứng yêu cầu.

CÂU 31:

Vấn đề an ninh cho các hệ thống TMĐT

Trả lời:

§

TMĐT gắn liền với giao dịch, thẻ tín dụng, séc điện tử, tiền điện tử…

§

Rủi ro trong thương mại truyền thống

§

Tội phạm trong TMĐT tinh vi, phức tạp hơn

§

Các hệ thống an ninh luôn tồn tại điểm yếu

§

Vấn đề an ninh với việc dễ dàng sử dụng là hai mặt đối lập

§

Phụ thuộc vào vấn đề an ninh của Internet, an ninh thanh toán, số lượng trang web…

CÂU 32:

Giao thức trọng tài

§

Trọng tài: bên thứ ba

đáng

tin cậy giúp

hoàn thành

giao thức giữa hai hai bên không tin tưởng

§

Trong thế giới thực, luật sư thường được sử dụng như các trọng tài

q

Ví dụ: Alice bán một chiếc xe

cho

Bob,

là

một người lạ. Bob muốn thanh toán bằng séc, nhưng Alice không có cách nào để biết séc là có hiệu lực.

q

Nhờ một luật sư đáng tin cậy cho cả hai. Với sự giúp đỡ của luật sư, Alice và Bob có thể sử dụng giao thức sau đây để đảm bảo rằng không có ai gian lận

q

(1) Alice

trao

quyền cho luật sư

q

(2) Bob

gửi séc cho

Alice

q

(3) Alice

đặt cọc séc

q

(4) Sau khi chờ đợi một khoảng thời gian

cụ thể để séc được làm rõ ràng

, luật sư

trao

quyền cho Bob. Nếu séc không được làm sáng tỏ trong khoảng thời gian cụ thể, Alice chứng minh với luật sư và luật sư trả trao quyền lại cho Alice.

CÂU

33: Giao thức phân xử

§

Bởi vì chi phí thuê trọng tài cao, giao thức trọng tài có thể được chia thành 2 giao thức con

q

Giao thức con không có trọng tài, thực thi tại mọi thời điểm các bên muốn hoàn thành giao thức

q

Giao thức con có trọng tài, thực thi chỉ trong hoàn cảnh ngoại lệ - khi có tranh chấp

§

Ví dụ: giao thức ký kết hợp đồng có thể được

chính thức hóa theo cách này

q

Giao thức con không có trọng tài (thực thi ở mọi thời điểm):

§

(1) Alice và Bob đàm phán các điều khoản của hợp đồng

§

(2) Alice ký hợp đồng

§

(

3) Bob ký hợp đồng

q

Giao thức con phân xử

(

chỉ

thực

thi khi có

tranh chấp):

§

(4) Alice và Bob xuất hiện trước một

quan tòa

§

(5) Alice đưa ra bằng chứng của mình

§

(6) Bob trình bày bằng chứng của mình

§

(7)

Quan tòa

phán quyết dựa trên

bằng chứng

CÂU 34: Giao thức Trao đổi khóa với mã đối xứng

§

Giả sử Alice và Bob

muốn

chia sẻ một khóa bí mật với

nhau thông qua

Key Distribution Center (KDC)

là trọng tài trong

giao thức

q

Các khóa này phải được thực hiện trước khi giao thức

bắt đầu

q

(1) Alice gọi

trọng tài

và yêu cầu

khóa phiên dùng chung để giao tiếp với

Bob

q

(

2)

Trọng tài

tạo ra một khóa phiên ngẫu nhiên

,

mã hóa hai bản sao

c

ủa nó: một

bằng

khóa của

Alice

và một

bằng khóa của Bob

.

Trọng tài gửi cả 2 bản copy tới cho Alice.

q

(3) Alice giải mã bản sao của khóa phiên

q

(

4) Alice gửi cho Bob bản sao của khóa phiên

q

(5) Bob giải mã bản sao của khóa phiên

q

(6)

Cả Alice và Bob dùng khóa phiên để giao tiếp

an toàn

Giải thích:

Trong đó:KA-KDC  và KB-KDC:Là 2 khóa được đăng ký sẵn trong CSDL  của KDC

-

KA-KDC  :Chỉ A biết và KDC biết

-

KB-KDC  :Chỉ B biết và KDC biết

Bước 1:Tại A gửi cho KDC:

KA-KDC  (A,B):Tôi muốn nói chuyện với B sinh cho tôi một khóa.

Bước 2:Tại KDC sinh ra khóa ngẫu nhiên R1

mã hóa hai bản sao

c

ủa nó: một

bằng

khóa của

Alice

và một

bằng khóa của Bob

.

Trọng tài gửi cả 2 bản copy tới cho Alice = lệnh

KA-KDC  (R1, KA-KDC  (A,R1))

Bước 3:Bên A chỉ đọc được R1 không đọc được KB-KDC  (A,R1) và sẽ gửi sang cho B: KB-KDC  (A,R1)

Bước 4:Hai bên sẽ dùng khóa dùng chung là R1 để nói chuyện với nhau

CÂU 35: Giao thức Trao đổi khóa với mã khóa công khai

§

Alice và Bob sử dụng mật mã khóa công khai để thống nhất

về khóa phiên dùng chung

, và

dùng khóa

phiên

đó

để mã hóa dữ liệu

§

Trong một số triển khai thực tế, cả hai

khóa công khai của Alice và Bob

sẽ

luôn

có sẵn tr

ong CSDL

§

(1) Alice

nhận khóa công khai của Bob

từ KDC

§

(2) Alice tạo ra một khóa phiên ngẫu nhiên, mã hóa nó bằng cách sử dụng

khóa công khai của

Bob và gửi nó đến Bob

§

(3) Bob sau đó giải mã thông điệp

của Alice

bằng cách sử dụng khóa riêng của mình

§

(4) Cả hai mã hóa các thông tin liên lạc sử dụng cùng một

khóa

phiên

CÂU 36: Giao thức

Needham-Schroede

r

§

(1) Alice gửi một thông điệp đến

Trent

bao gồm tên của

mình, tên Bob, và một số ngẫu nhiên: A, B, R

A

§

(2)

Trent

tạo ra một khóa phiên ngẫu nhiên

,

mã hóa

thông điệp

bao gồm khóa phiên ngẫu nhiên và tên của Alice

cùng

với khóa bí mật

của

Bob. Sau đó, mã hóa giá trị ngẫu nhiên của Alice, tên của Bob, khóa, và thông điệp mã hóa cùng với khóa bí mật chia sẻ với Alice, và gửi Alice mã hóa: EA (RA, B, K, EB(K, A))

§

(3) Alice giải mã tin nhắn và rút ra K. Alice khẳng định rằng RA là giá trị mà mình đã gửi Trent trong bước (1). Sau đó, Alice gửi Bob tin nhắn được Trent mã hóa bằng khóa của Bob: EB(K, A)

§

(4) Bob giải mã tin nhắn và rút ra K. Sau đó, Bob tạo ra một giá trị ngẫu nhiên, RB, mã hóa tin nhắn với K và gửi nó cho Alice: EK(RB)

§

(5) Alice giải mã các tin nhắn với K, tạo ra RB - 1 và mã hóa nó với K, sau đó gửi tin nhắn cho Bob: EK(RB - 1)

CÂU 37:  Chữ ký mù

§

Đặc

tính

tất

yếu của các giao thức chữ ký số là

người ký biết những gì

mình

ký

§

Chúng ta muốn mọi người ký các văn bản mà không bao giờ nhìn thấy

nội dung

q

Bob là một công chứng viên. Alice muốn Bob ký một tài liệu, nhưng không không muốn anh ta có bất kỳ ý tưởng về những gì mình ký.

Ø

Bob không quan tâm những gì tài liệu nói, anh ta chỉ xác nhận rằng mình có công chứng tại một thời gian nhất định.

Bob

sẵn sàng

làm điều

này.

q

(1) Alice có các tài liệu

và nhân bản

nó bằng một giá trị ngẫu nhiên

(multiple)

. Giá trị ngẫu nhiên này được gọi là một yếu tố làm mù.

q

(2) Alice gửi tài liệu mù Bob

q

3) Bob ký tài liệu mù

q

(4) Alice phân

tách

các yếu tố làm mù, để lại tài liệu gốc

có chữ ký của Bob

§

Các thuộc tính của chữ ký mù hoàn

chỉnh

§

1

. Chữ ký của

Bob

l

ên tài liệu là hợp lệ

q

Chữ ký là một minh

chứng rằng Bob đã ký các tài liệu

q

Nó sẽ thuyết phục Bob rằng

anh ta

đã ký các tài liệu nếu nó

đã từng

được hiển thị cho anh ta

q

Nó cũng có tất cả các

thuộc tính

khác của chữ ký số

§

2

. Bob

không

thể

đánh đồng

các văn bản

được

ký kết với các hành vi

ký kết các tài liệu

q

Ngay cả nếu

Bob

giữ hồ sơ của tất cả các chữ ký mù,

Bob

không

t

hể xác định

mình đã

ký tài liệu nào

CÂU 38

.

Không theo dõi giao dịch thanh toán

a. Hashsum ngẫu nhiên trong thanh toán iKP

§

Khi khởi tạo 1 giao dịch thanh toán, khách hàng chọn 1 giá trị ngẫu nhiên RC và tạo ra giá trị bút danh dùng 1 lần IDC theo cách sau:

IDC = hk(RC, BAN)

q

BAN là số tài khoản ngân hàng của khách hàng

q

hk(.) là đụng độ hash k-chiều, không tiết lộ thông tin BAN khi RC được chọn ngẫu nhiên

q

Người bán nhận IDC (không phải BAN), không thể tính ra BAN

b. Hashsum ngẫu nhiên trong SET

§

Người bán nhận 1 giá trị hashsum từ lệnh thanh toán

§

Lệnh thanh toán chứa các thông tin:

q

Số tài khoản chính, PAN (ví dụ, số thẻ tín dụng)

q

Ngày hết hạn

q

Khóa chia sẻ bí mật giữa chủ thẻ, cổng thanh toán và chứng thực ủy quyền của chủ thẻ, PANSecret

q

Giá trị ngẫu nhiên nonce ngăn chặn tấn công từ điển, EXNonce

q

Khi nonce là khác nhau với mỗi giao dịch, người bán không thể liên kết 2 giao dịch với nhau ngay cả khi dùng chung PAN

CÂU 39

: Nặc danh người dùng và không theo dõi

Trả lời:

§

Đặc tính nặc danh người dùng

và

không theo dõi thanh toán

có thể được cung cấp riêng

biệt

§

D

ịch vụ an ninh nặc danh người dùng “tinh khiết” sẽ bảo vệ chống lại tiết lộ xác thực người dùng

§

Dịch vụ

an ninh

không theo dõi thanh toán “tinh khiết” sẽ

bảo vệ chống lại tiết lộ

địa điểm của thông điệp gốc

§

Giải pháp: Sử dụng chuỗi hỗn hợp Mixes

Chuỗi hỗn hợp Mixes

§

Ý tưởng

q

Thông điệp được gửi từ A, B, và C (đại diện cho khách hàng có

yêu cầu

nặc danh) tới hỗn hợp

và từ hỗn hợp tới X, Y, Z (đại diện cho các người bán hoặc ngân hàng “tò mò” về thông tin xác thực khách hàng)

q

Thông điệp

được mã hóa với khóa công khai của hỗn hợp, E

­M

. Nếu khách hàng A muốn gửi thông điệp cho người bán Y, A gửi tới hỗn hợp cấu trúc sau:

ð

A → Mix:      EM(Y, EY(Y, Message))

q

Bây giờ, hỗn hợp có thể giải mã và gửi kết quả cho Y:

ð

Mix → Y:      EY(Y, Message)

q

Chỉ có Y mới đọc được thông điệp khi nó được mã bằng khóa công khai của Y, EY

q

Nếu A muốn Y phản hồi, A có thể hàm chứa địa chỉ phản hồi nặc danh trong thông điệp gửi tới Y: Mix, EM(A)

q

Theo cách này, thông điệp phản hồi được gửi tới mix, chỉ mix biết ai là người gửi

§

Hạn chế

q

Hỗn hợp phải hoàn toàn đáng tin cậy

Chuỗi hỗn hợp Mixes

§

Giải quyết vấn đề tin cậy của hỗn hợp, sử dụng 1 chuỗi các hỗn hợp (mạng)

§

Nếu A muốn gửi 1 thông điệp nặc danh, không bị theo dõi tới Y, A sử dụng giao thức sau:

q

A → Mix1:                E1(Mix2, E2(Mix3, E3(Y, Message)))

q

Mix1 → Mix2:          E2(Mix3, E3(Y, Message))

q

Mix2 → Mix3:          E3(Y, Message)

q

Mix3

→ Y:                Message

q

ERecipient(Next recipient, ENext recipient(…))

CÂU 40 . Sự nặc danh người thanh toán

§

Người trả tiền sử dụng bút danh thay vì sự nhận dạng của mình

§

Nếu

một bên

muốn chắc chắn rằng hai giao dịch thanh toán khác nhau

thực hiện

bởi cùng một người không thể

được liên kết

với nhau

,

khi đó đặc tính không theo dõi giao dịch

thanh toán phải được cung cấp

§

Giải pháp: Sử dụng bút danh

Bút danh

§

Hệ thống First Virtual

q

Thông điệp ủy quyền giữa FV và người bán trước khi chuyển hàng cần phải được bảo vệ để ngăn chặn việc chuyển số lượng hàng lớn tới khách hàng gian lận

q

Khách hàng nhận VPIN (Virtual Personal Identification Number), là 1 chuỗi kí tự chữ và số hoạt động như là bút danh cho thẻ tín dụng, có thể được gửi qua email

q

Nếu VPIN bị đánh cắp, khách hàng không có thẩm quyền cũng không thể sử dụng vì tất cả các giao dịch sẽ được xác nhận bằng email trước khi trừ tiền trong thẻ tín dụng

q

Nếu khách hàng cố gắng sử dụng VPIN mà không được ủy quyền, FV sẽ được thông báo về VPIN bị đánh cắp khi khách hàng phản hồi “fraud” cho yêu cầu của FV để xác nhận mua bán

q

Trong trường hợp này VPIN sẽ bị hủy bỏ ngay lập tức

q

Cơ chế này đảm bảo tính bí mật của lệnh thanh toán đối với người bán và kẻ nghe trộm tiềm năng

§

Giao dịch của hệ thống FV

q

(1) Khách hàng gửi đơn hàng tới người bán cùng với VPIN

q

(2) Người bán gửi yêu cầu cấp phép VPIN tới nhà cung cấp dịch vụ thanh toán FV

q

(3) Nếu VPIN là hợp lệ

q

(4) Người bán cung cấp dịch vụ cho khách hàng

q

(5) Người bán gửi thông tin giao dịch cho FV

q

(6) FV hỏi khách hàng xem đã sẵn sàng thanh toán cho các dịch vụ (qua e-mail) (Khách hàng có thể từ chối thanh toán khi dịch vụ đã được chuyển đi nhưng không đáp ứng mong đợi của mình)

q

(7) Nếu khách hàng muốn thanh toán, trả lời “Yes”

q

(8a) Số lượng thanh toán được trừ trong tài khoản của khách hàng

q

(8b) Gửi vào tài khoản người bán

q

(9) Giao dịch bù trừ giữa các ngân hàng

CÂU 41 . Bảo mật dữ liệu giao dịch thanh toán

a. Hàm số ngẫu nhiên giả

§

Thanh toán iKP là 1 họ các giao thức thanh toán (i = 1, 2, 3) được phát triển bởi IBM

§

Hỗ trợ giao dịch thẻ tín dụng, cùng với CyberCash, Secure Transaction Set Technology và các giao thức thanh tóan điện tử an toàn là hình thức nguyên thủy quan trọng nhất của SET

§

Cơ chế 1KP cung cấp tính bảo mật của các thông tin với cổng thanh toán, người bán, sự nặc danh khách hàng

q

Khi khởi tạo giao dịch, khách hàng chọn 1 giá trị ngẫu nhiên RC và tạo bút danh dùng 1 lần IDC:

                              IDC = hk(RC, BAN)

q

BAN là số tài khoản ngân hàng của khách hàng

q

hk(.) là đụng độ hash k-chiều, không tiết lộ thông tin BAN khi RC được chọn ngẫu nhiên

q

Người bán nhận IDC (không phải BAN), không thể tính ra BAN

§

Bảo mật thông tin tương ứng với ngân hàng thanh toán được thực hiện theo cách tương tự

q

Khách hàng chọn giá trị ngẫu nhiên SALTC khác nhau cho mỗi giao dịch, gửi cho người bán ở dạng dữ liệu rõ

q

Dùng hàm hash như ở trên, người bán gửi 1 mô tả của thông tin (DESC) cho ngân hàng thanh toán:

                              hk(SALTC, DESC)

q

Ngân hàng thanh toán có thể nhìn thấy giá trị hashsum nhưng không đủ thông tin để tìm ra DESC

q

Nếu số lượng DESC không nhiều, ngân hàng thanh toán có thể tính ra tất cả các giá trị của hashsum với SALTC cho trước và lấy thông tin

q

Ngân hàng thanh toán có thể được tin tưởng trong một vài phạm vi

q

Để truyền lệnh thanh toán tới ngân hàng thanh toán mà người bán không thể đọc được, iKP sử dụng khóa công khai

q

Khách hàng mã hóa thông điệp, gồm:

q

Giá của những hàng hóa đã đặt

q

Lệnh thanh toán (số thẻ tín dụng, mã PIN)

q

hk(SALTC, DESC) được băm cùng với dữ liệu giao dịch

q

Giá trị ngẫu nhiên RC để tạo bút danh dùng 1 lần cùng với khóa công khai của ngân hàng thanh toán

q

Thông điệp mã hóa này được gửi cho người bán và chuyển tiếp tới ngân hàng thanh toán

q

Khách hàng phải có chứng thực khóa công khai của ngân hàng thanh toán được phát hành bởi tổ chức chứng thực ủy quyền tin cậy

q

Chỉ có ngân hàng thanh toán mới giải mã được thông điệp, qua RC xác thực độ chính xác của IDC

q

Kết nối giữa lệnh thanh toán và thông tin đặt hàng được thiết lập thông qua giá trị hk(SALTC, DESC) và tất cả các bên đều biết

q

Sự kết hợp 2 giá trị này là duy nhất cho mỗi giao dịch

b. Chữ ký kép (Dual signature)

§

SET là một tiêu chuẩn mở cho giao dịch thẻ tín dụng an toàn trên mạng

§

Khởi động bởi Visa và MasterCard năm 1996, dùng công nghệ mã hóa RSA

§

Để bảo vệ số thẻ tín dụng (lệnh thanh toán của khách hàng) từ việc nghe trộm hay những người bán không trung thực, SET sử dụng chữ ký kép

§

Kịch bản thanh toán

§

PI – lệnh thanh toán (payment instruction)

§

OI – các thông tin đặt hàng

§

M – người bán

§

P – payment gateway

§

Mục tiêu: Người bán M không thể đọc thông tin lệnh thanh toán, cổng thanh toán P không thể đọc thông tin đặt hàng

§

Thực hiện: Khách hàng thực hiện chữ ký kép lên yêu cầu thanh toán, tức là, C kí lên PI và OI dự định gửi cho P và M, sử dụng hàm mã hóa hash h(.) và khóa bí mật DC từ thuật toán khóa công khai

§

Khách hàng tính DS = DC(h(h(PI),h(OI)))

§

Giả sử M chỉ biết OI, P chỉ biết PI, thì chỉ nhận được từng phần bí mật của hashsum

§

M nhận: OI, h(PI), DS

§

P nhận: PI, h(OI), DS

§

Cả 2 có thể xác thực DS

§

Nếu P đồng ý, lệnh thanh toán là chính xác, cấp quyền là khả thi, P kí lên PI, nếu M đồng ý, ký lên OI

§

Trong SET, h(PI) và h(OI) là các giá trị hashsum SHA-1

§

C gửi PI tới M theo dạng mã hóa (thuật toán mã hóa đối xứng với khóa ngẫu nhiên bí mật K)

§

Khóa bí mật này được mã hóa và gửi cùng khóa công khai của P, EP, vì vậy chỉ P có thể đọc

§

C → M: OI, h(PI), DS, EP(K), EK(P, PI, h(OI))

§

M chuyển tiếp tất cả các thành phần của thông điệp (ngoại trừ OI) tới P trong 1 yêu cầu cấp phép

CÂU 42 . Chống phủ định giao dịch thanh toán

- Chống phủ định sẽ ngăn chặn việc từ chối nguồn gốc của tài liệu hoặc phủ nhận bằng chứng giao dịch.

- Giải pháp: chữ ký số

Chữ ký số

§

Để giải thích các vấn đề chống

phủ định

,

ta

sử dụng mô hình 3KP

q

Acquirer đại diện cho cổng thanh toán và ngân hàng thanh toán

q

Giả định các thông tin đặt hàng (hàng hóa, dịch vụ, giá cả, hình thức giao hàng) đã được thương lượng trước thông báo (yêu cầu) thanh toán

q

Thông báo thanh toán này là duy nhất để xác thực các giao dịch thanh toán

q

Người trả tiền gửi người nhận thông báo thanh toán gồm lệnh thanh toán và công cụ thanh toán xác định

§

Ví dụ

q

Thẻ tín dụng có các thông tin: Ngân hàng phát hành, Số thẻ, Ngày hết hạn (thời gian hiệu lực)

q

Người nhận tiền muốn xác thực thẻ tín dụng có thể được dùng để tính toán, sẽ gửi thông báo yêu cầu ủy quyền (authorization request) tới ngân hàng thanh toán

q

Thông điệp trả lời ủy quyền (authorization response) chứa kết quả ủy quyền

q

Nếu kết quả là chắc chắn, người nhận sẽ gửi xác nhận thanh toán (payment receipt) cho người trả và gửi hàng hóa dịch vụ

§

Vấn đề chống phủ định và ủy quyền

q

Thông điệp ủy quyền được gửi bởi 3 thành phần, mỗi thành phần có 1 cặp khóa công khai, mỗi khóa được chứng thực bởi 1 tổ chức chứng thực đáng tin cậy

q

Người nhận cần 1 bằng chứng (không thể từ chối) rằng người trả đã đồng ý trả 1 khoản tiền nhất định

q

Bằng chứng này được chứa trong thông điệp Payer’s Payment Authorization, đảm bảo chống phủ định ủy quyền thanh toán của người trả

q

Ngân hàng thanh toán và ngân hàng phát hành cần bằng chứng Payer’s Payment Authorization để thu hồi số tiền bán hàng từ tài khoản của người trả, ghi có tài khoản người nhận, được ký bằng khóa bí mật của người trả

q

Ngân hàng thanh toán và ngân hàng phát hành cần bằng chứng chống phủ định ủy quyền thanh tóan của người nhận, đó là chức năng của Payee’s Payment Authorization, đảm bảo chống phủ định ủy quyền thanh toán, được ký bằng khóa bí mật của người nhận

q

Người nhận tiền hỏi Acquirer thông điệpAcquirer’s Payment Authorization để chứng minh Acquirer đã đồng ý với giao dịch thanh tóan, được khóa bằng khóa bí mật của Acquirer

q

Acquirer’s payee auth

chứng minh rằng người nhận thanh toán được ủy quyền để

nhận

các khoản thanh toán

q

Giấy chứng nhận gửi cho người

nhận

được chuyển tiếp cho người

trả, người nhận không thể từ chối là người trả đã trả cho những đơn hàng đã đặt

q

Biên lai thường được ký bởi người nhận

Câu 43. Không theo dõi giao dịch thanh toán

§

Khi khách hàng rút tiền truyền thống từ máy ATM hoặc tài khoản ngân hàng, chuỗi series numbers trên tiền thường không được ghi lại

§

Các giao dịch thanh toán không thể liên kết tới 1 khách hàng cụ thể

§

Tiền số cũng có số serial numbers và đôi khi được biểu diễn bởi các số duy nhất thỏa mãn các điều kiện cụ thể

§

Serial numbers tồn tại dưới dạng số rất dễ tạo ra bản ghi lưu lại thông tin khách hàng

§

Vì vậy, nó rất đơn giản để thực hiện theo dõi giao dịch thanh toán điện tử của khách hàng bằng cách lần theo serial numbers

§

Giải pháp

§

Chữ ký mù

§

Trao đổi xu

a/ Chữ ký mù

§

D. Chaum đề xuất nhằm che giấu sự liên kết giữa các đồng xu được phát hành với thông tin xác thực khách hàng

§

Cung cấp sự nặc danh cho người thanh toán và không theo dõi giao dịch thanh toán dựa trên chữ ký mù

§

Người ký không nhìn thấy những gì mình ký

§

Kịch bản (dựa trên thuật toán RSA)

–

d là khóa bí mật của người gửi, e và n là khóa công khai

–

Tham số k được gọi là nhân tố làm mù, được chọn bởi message provider

–

Provider làm mù thông điệp M:

                              M’ = Mke mod n

–

Người ký thực hiện chữ ký mù:

                                          S’ = (M’)d mod n = kMd mod n

–

Provider loại bỏ nhân tố làm mù

                                          S = S’/k = Md mod n

–

Người ký thường muốn kiểm tra nếu thông điệp M (tức là, tiền giấy hay tiền số) nếu nó là hợp lệ

–

Provider chuẩn bị n thông điệp và làm mù cùng với nhân tố làm mù khác nhau

–

Người ký chọn n-1 thông điệp ngẫu nhiên và hỏi provider để gửi nhân tố mù tương ứng

–

Người ký kiểm tra n-1 thông điệp, nếu đúng, ký lên thông điệp còn lại

–

Đồng xu điện tử được làm mù theo cách này chỉ được sử dụng trong hệ thống thanh toán online, để kiểm tra double spending, phải được kiểm tra trong CSDL trung tâm

b/ Trao đổi xu

§

Cơ chế nặc danh người dùng và nặc danh thanh toán dựa trên các bên thứ ba đáng tin cậy

§

Sử dụng mạng các máy chủ tiền để trao đổi cơ sở xác thực xu cho những xu nặc danh, sau khi khẳng định tính hợp lệ và kiểm tra double spending

§

Kiểu nặc danh này yếu hơn chữ ký mù

–

Với chữ ký mù, không thể xác định được danh tính người dùng

–

Với máy chủ tiền, nếu các bên có âm mưu, gồm cả máy chủ tiền trong giao dịch, có thể xác định ai đã sử dụng tiền

Câu 44  Chống double spending

- Tiền số có thể được sao chép một cahcs dễ dàng và tùy tiện, được thực hiện bởi bất cứ ai vì nó là dữ liệu  điện tử đơn giản

- Người trả tiền có một đồng xu có giá trị hợp lệ, họ có thể cố gắng chi tiêu nhiều hơn 1 lần vì thế giải phápđể chống 1 đồng xu được tiêu 2 lần:

+ Nặc danh có điều kiện bằng cắt và chọn (cut anh choose)

+ Người bảo vệ

a/  Nặc danh có điều kiện bằng cắt và chọn:

- Được kích hoạt cho những khách hàng không trung thực (KH cố gắng tiêu xu hơn 1 lần)

- Cơ chế chia cắt bí mật

- ý tưởng: chia thông điệp M thành các mẫu tin và tất cả các mẫu tin phải được sắp xếp cùng nhau để tái tạo lại M (trong mô hình chia cắ bí mật tổng quan, chỉ cần 1 tập con các mẩu tin là đủ)

- Tìm M1, M2 sao cho: M= M1  XOR  M2

- Thực hiện: Chọn M1 ngẫu nhiên, cùng độ dài M và tính M2 theo M2 = M XOR M1

- Trong tiền số, mỗi đồng xu được gán 1 chuỗi số và N cặp mã hóa khác nhau (I1, I2) (tức là, được mã với khóa khác nhau) để thông tin xác thức khách hàng có thể được tiết lộ I=I1 XOR I2

- Khi khách hàng trả tiền, người bán yêu cầu khách giải mã hoặc I1 hoặc I2 từ mỗi cặp (chọn ngẫu nhiên)

- Xác minh xem kết quả giải mã là hợp lệ nếu áp dụng thuật toán mã khóa công khai

- Nếu khách hàng cố gắng tiêu xu 1 lần nữa, với N đủ lớn (N=100), ít nhất 1 phần của I giống với 1 phần của I đã được tiết lộ ở thời điểm tiêu lần đầu (từ cùng 1 cặp) sẽ được tiết lộ

Tiêu nhiều hơn 1 lần có thể xuất hiện I=I’ đã tiết lỗ trước đó nên đồng xu sẽ bị phát hiện

Chi phí sản xuất xu đắt

b/ Người bảo vệ

§

Tập cơ chế phức tạp bảo vệ chống lại double spending trong hệ thống thanh toán off-line

§

Cơ chế tương tự được sử dụng

wallet

§

Ý tưởng: Bên phát hành là tổ chức ngân hàng phát triển tiền điện tử

§

Ví (wallet) chứa ví (purse), được tin tưởng bởi người trả tiền, và một người bảo vệ được tin cậy bởi bên phát hành

§

Người bảo vệ: Là chip vi xử lý đặt cố định trong ví hoặc trên 1 thẻ thông minh

§

Bảo vệ lợi ích bên phát hành trong giao dịch thanh toán off-line

§

Là thiết bị chống trộm hoặc chống giả mạo

§

Ví có dạng máy tính cầm tay nhỏ có nguồn cung cấp, bàn phím, màn hình riêng

§

Bảo vệ lợi ích của người trả tiền (nặc danh và không thể theo dõi)

§

Xác thực người bảo vệ, người bảo vệ giao tiếp ra bên ngoài thông qua purse

* Chữ ký của người bảo vệ

§

Người trả tiền rút tiền điện tử từ 1 tài khoản tiền xu và nạp vào ví

–

“một phần” của mỗi đồng xu được đưa vào ví

–

“một phần” khác gửi tới người bảo vệ

§

Người sử dụng chi tiêu tiền trong 1 giao dịch thanh toán, người bảo vệ phải đồng ý

–

Cả hai phần của đồng xu phải được kết hợp để có được 1 đồng xu có thể được chấp nhận

–

Sử dụng 1 loại chữ ký số đặc biệt

§

Tham số công khai giống như trong DSA

–

p là số nguyên tố đủ lớn

–

q là số nguyên tố đủ lớn

–

g là bộ sinh module p của q, tức là g = hp-1/q mod p  > 1 (1<h<p-1)

–

Nhóm tạo bởi g tạo nên Gq, giả sử người bảo vệ là bên ký, khóa gồm 2 số:

–

Số nguyên ngẫu nhiên x, 0 < x < q (private key)

                  h = gx mod p (public key)

§

Purse muốn nhận 1 chữ ký mù từ người bảo vệ lên thông điệp

§

Thông điệp có thể biểu diễn 1 đồng xu

§

Chữ ký gồm:

§

Chứng minh rằng:

§

Tương đương với khóa bí mật x của người bảo vệ

§

Với m và z đã cho, giao thức sau người chứng minh có thể chứng minh với người xác thực (purse) là biết x:

–

1. Prover → Verifier:

–

2. Verifier → Prover:

–

3. Prover → Verifier:

§

1. Verifier sẽ kiểm tra xem các biểu thức sau:

§

2. Nếu chữ ký là hợp lệ:

§

3. Chữ ký thực lên m được xác định

§

H(.) là hàm băm 1 chiều

§

Người bảo vệ chọn s không mất phí

§

Purse ngăn chặn bằng cách xác định a và b

§

Thay vì s, s0 + s1 được sử dụng, s0 chọn bởi purse, s1 chọn bởi người bảo vệ, các giá trị sau đây được sử dụng:

* Chữ ký bên phát hành

§

Chữ ký trên đồng xu mà purse nhận từ ngân hàng phát hành phải được làm mù

–

1.

Verifier → Signer            m0 = mt mod p,

                                                      t là ngẫu nhiên, 0 < t < q

–

2. Signer → Verifier            a0 = gs mod p, b0 = m0s mod p,

                                                      s là ngẫu nhiên, 0 < s < q

–

3. Verifier → Signer            c0 = c/u mod q,

                                                      u là ngẫu nhiên, 0 ≤ u < q

–

4. Signer → Verifier            r0 = (s + c0x) mod q

Câu 45  Chống làm giả xu

§

Khó làm giả tiền truyền thống

§

Giấy phải đặc biệt, đắt hoặc khó sản xuất các đặc tính vật lý (in ấn)

§

Số series phải hợp lệ

§

Nếu là giả thì dễ kiểm tra

§

Giải pháp: chi phí sản xuất xu đắt

*  Chi phí sản uất xu đắt

§

Chi phí sản xuất những đồng xu giá trị thấp là đắt

§

Nếu cần thiết để thiết lập 1 kênh đầu tư sản xuất xu (giả mạo), những xu giả mạo sẽ không thể thanh toán hết phí đầu tư

§

Sản xuất nhiều xu sẽ rẻ hơn sản xuất 1 vài đồng xu

§

Hệ thống thanh toán MicroMint

§

Sử dụng hàm hash

§

Tạo đụng độ hash k-chiều (x1, x2, K, xk), sao cho

§

h(x1) = h(x2) = K = h(xk)

§

h(.) là hàm mã hóa hash ánh xạ m-bit đầu vào (xi, i = 1, K, k) sang n-bit đầu ra (hashsum)

§

Xác thực xu thực hiện bằng cách kiểm tra các giá trị x phân biệt cùng sản xuất ra hashsum giống nhau

§

Khoảng            giá trị của x cần kiểm tra để nhận được đụng độ k-chiều đầu tiên (xác suất 50%)

§

Lặp c lần, ck đụng độ k-chiều được tìm thấy

Câu 46 Chống ăn cắp xu

§

Một cách trực quan để bảo vệ xu khỏi bị đánh cắp thông qua nghe trộm là sử dụng mã hóa

–

Xu thường có giá trị danh nghĩa khá thấp (nhỏ hơn 1 đồng Euro)

–

Không hiệu quả khi sử dụng mã hóa

§

Giải pháp: Tùy chỉnh xu

*

Đặc trưng khách hàng và nặc danh xu

§

Xu có thể được tùy chỉnh để sử dụng chỉ với khác hàng cụ thể trong giai đoạn nhất định

§

Cơ chế duy trì tính nặc danh, bảo vệ chống double spending và đảm bảo khách hàng nhận biên lai hay tiền thừa hợp lệ

§

Giao thức gồm 4 bước

–

A gửi coins tới CS để nhận về 1 đồng coin triplet

§

Step1:  ECS(coins, KAN1, EB, tB, tA)

–

Thông điệp được mã bởi khóa công khai ECS của máy chủ

–

KAN1 là khóa phiên đối xứng được sử dụng bởi CS để mã hóa bộ triplet

§

Step2: <CB, CA, CX>

–

Mỗi xu trong triplet có cùng chuỗi serial numbers và giá trị

–

B có thể sử dụng xu CB trước thời điểm tB. Nếu B muốn dùng coin trong giao dịch với CS, phải chứng minh biết khóa bí mật DB, khi khóa công khai EB được nhúng vào CB.

–

Nếu A quyết định tiêu xu với B, A gửi thông điệp tới B cho biết dịch vụ đang sử dụng (ServiceID)

§

Step 3: EB(CB, KAN2, Kses, ServiceID)

–

B giữ lại khóa phiên Kses

–

Tại thời điểm dịch vụ được cung cấp, B xác thực rằng A biết Kses, B phải chuyển đổi xu khi nó có hiệu lực (trước thời điểm tB)

–

Giả sử B phản hồi thông điệp trong bước 3 cùng 1 biên lai có kí tên chứa thông tin giao dịch (Amount, TransactionID) và time stamp (TS), mã với khóa phiên đối xứng KAN2

–

Step 4: KAN2(DB(Amount, TransactionID, TS))

§

Nếu B không gửi A biên lai, A yêu cầu CS kiểm tra xem B đã sử dụng xu. Nếu B sử dụng xu, CS phát hành 1 biên lai đã kí tên tới A xác định giá trị xu và khóa của B. Nếu B chưa dùng xu, A nhận 1 khoản tiền trong thời gian CA có hiệu lực.

§

A có thể sử dụng xu CA sau tB trước tA. A quyết định không tiêu xu với B (CB) nhưng sử dụng trong giao dịch với CS (CA), A phải chứng minh biết khóa riêng DA, khi khóa công khai EA được nhúng trong CA

§

Cuối cùng, CX được dùng nếu A không tiêu xu với B

Câu 47: Bảo mật séc điện tử

- Giải pháp: Chuyển giao ủy quyền thanh toán

v

Proxies

§

Kerberos

§

Restricted Proxy

§

Cascaded Proxies

- Chuyển giao ủy quyền thanh toán

§

Sự ủy quyền thanh toán được chuyển từ người trả sang người nhận kèm theo 1 số hạn chế nhất định

§

Cơ chế chữ ký điện tử lên séc điện tử dựa trên những proxies hạn chế được sử dụng để cài đặt cho hệ thống NetCheque

-

Proxies

§

Hệ thống NetCheque được phát triển bởi Information Sciences Institute of the University of Southern California

§

Ban đầu là 1 dịch vụ phân tán để bảo trì hạn mức cho tài nguyên hệ thống phân tán

§

Hỗ trợ mô hình thanh toán dựa trên credit-debit

§

Trong mô hình credit, khoản phí được gửi tới 1 tài khoản và khách hàng thanh toán lượng tiền yêu cầu cho dịch vụ thanh toán sau

§

Trong mô hình debit, tài khoản được ghi nợ khi séc (giao dịch ghi nợ) được xử lý

§

Cơ chế mô tả trong phần này áp dụng cho mô hình debit

§

Séc NetCheque là tài liệu điện tử, gồm:

ü

Payer’s name, Payer’s account identifier (number) & bank name

ü

Payee’s name, The amount of money, The issue date

ü

Payer’s electronic signature, Payer’s electronic endorsement

- Kerberos

§

Proxy là thẻ cho phép thực hiện với quyền và độ ưu tiên mà một bên cho phép với proxy

§

Restricted proxy là proxy kèm theo những hạn chế

§

Trong ví dụ séc điện tử, sự hạn chế là các người nhận tiền (designated customer), số lượng tiền được thanh toán và ngày phát hành

§

NetCheque proxies dựa trên Kerberos, phát triển bởi MIT năm 1986, ban đầu là hệ thống chứng thực phân tán

§

Client có “mong muốn” sử dụng dịch vụ S trong hệ thống phân tán, nhận service ticket từ TGS

ü

Chứng thực bản thân với AS (authenticate service)

ü

Nếu thành công, C nhận TGS ticket và khóa phiên KC-TGS để yêu cầu service ticket từ TGS

{C, TGS, t1, t2, KC-TGS}KTGS, {KC-TGS, n1}KC

ü

t1, t2 là mốc bắt đầu và kết thúc của giai đoạn xác thực ticket

ü

n1, n2 là các giá trị nonces (xâu ngẫu nhiên)

ü

KTGS là khóa bí mật của TGS, KC  là khóa bí mật của client

§

Client yêu cầu một service ticket

ü

TGS gửi client service ticket và khóa phiên KC-S để yêu cầu dịch vụ

{C, S, t1, t2, KC-S}KS, {KC-S, n2}KC-TGS

ü

KS là khóa bí mật của server

ü

Nếu service ticket là hợp lệ, client được phép dùng dịch vụ

ü

Tất cả các khóa (ngoại trừ KC-S) được biết bởi Kerberos server, mỗi server đều phải chia sẻ khóa bí mật với các server khác

- Restricted Proxies

§

Hệ thống Kerberos TGS ticket trên thực tế là một restricted proxy

§

Hạn chế ở đây là khoảng thời gian (t1, t2) trong đó ticket là hợp lệ

§

Dạng tổng quan của sự ủy restricted proxy:

      {restrictions, Kproxy}Kgrantor, {Kproxy, nonce}Kgrantee

§

Grantor là thành phần đại diện cho proxy cho phép truy cập (tức là, TGS)

§

Grantee là thành phần được chỉ định để thay thế grantor (tức là dịch vụ khách hàng). Restriction được biểu diễn bởi dữ liệu séc:

      {<check>, Kproxy}Kpayer, {Kproxy, nonce}Kpayee

-

Cascaded proxies

§

Thực tế, người trả tiền và người nhận tiền không cần phải có tài khoản tại cùng một ngân hàng

§

Khi đó, séc sẽ được bù trừ thông qua nhiều hệ thống Accounting server trong NetCheque system

§

Khách hàng tạo ra 1 Kerberos ticket được dùng để chứng thực khách hàng với Accounting server

§

Được đặt trong thành phần chữ ký của séc và gửi cho người bán (bước 1)

   Proxy 1:{<check>, Kproxy1}Kcustomer,{Kproxy1, n1}Kmerchant

§

Người bán tạo ra 1 chứng thực xác thực séc dưới tên của người nhận để đặt cọc tiền chỉ gửi vào tài khoản của người nhận (bước 2)

§

Người bán gửi chứng thực cùng thông điệp gốc của khách tới Accounting Server đầu tiên (AS1)

Proxy 2:{deposit<check> to AS1, Kproxy2}Kproxy1, {Kproxy2, n2}KAS1

§

AS1 chia sẻ khóa bí mật Kmerchant với người bán, có thể nhận Kproxy1 từ Proxy 1 và dùng mã hóa ticket từ Proxy 2

§

Cuối cùng, AS1 tạo 1 chứng thực cho tờ séc dưới tên của người người nhận để đặt tiền vào tài khoản tương ứng với AS1 tại AS2

  Proxy 3:{deposit <check> to AS2, Kproxy3}Kproxy2, {Kproxy3, n3}KAS2

§

Cả 3 cascaded proxies được gửi tới Accounting server của khách hàng AS2

§

Server xác thực cascaded proxies cùng ticket trong Proxy1, trao đổi khóa bí mật Kcustomer với khách hàng

§

AS2 nhận Kproxy1 dùng để giải mã ticket trong Proxy 2

§

Thông qua Kproxy2 từ Proxy 2, AS2 giải mã ticket từ Proxy 3

§

Ticket này sẽ cho biết séc nên được đặt cọc vào tài khoản tương ứng của AS1 hay không

37