4. An ninh trong TMĐT

- Bảo mật giao dịch thanh toán

- Bảo mật tiền số

- Bảo mật séc điện tử

4.1. Bảo mật giao dịch thanh toán

- Giao dịch thanh toán điện tử là sự thực thi các giao thức mà theo đó một khoản tiền được lấy từ người trả tiền và chuyển cho người nhận

- Trong một giao dịch thanh toán, chúng ta thường phân biệt giữa các thông tin đặt hàng (hàng hóa, dịch vụ phải trả) và tài liệu thanh toán (ví dụ, số thẻ tín dụng)

- Từ góc độ an ninh, hai loại thông tin này cần thiết phải được xử lý đặc biệt

1.  Nặc danh người dùng và không theo dõi thanh toán

2.  Nặc danh người thanh toán

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

4.  Bảo mật dữliệu giao dịch thanh toán

5.  Thông điệp chống phủđịnh giao dịch thanh toán

4.1.1. Nặc danh người dùng và không theo dõ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

+ 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)

+ Thông điệp được mã hóa với khóa công khai của hỗn hợp, EM. 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:  E M (Y, EY  (Y, Message))

+ 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)

+ 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

+ 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)

+ 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ế

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

- 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 1thông điệp nặc danh, không bị theo dõi tới Y, A sửdụng giao thức sau:

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

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

+ Mix2 →Mix3:    E3 (Y, Message)

+ Mix3 →Y:          Message

+ ERecipient (Next recipient, ENext recipient(…))          

4.1.2. 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    

a. Bút danh

* Hệ thống First Virtual    

- 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

- 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

- 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

- 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

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

- 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

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

- (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

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

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

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

- (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)

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

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

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

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

4.1.3. 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 1giá 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)

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

+ 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

+ 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:

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

+ Ngày hết hạn

+ 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

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

+ 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             

4.1.4. 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

+ 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)

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

+ 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

+ 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ự

+ 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õ

+ 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)

+ 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

+ 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

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

+ Để 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

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

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

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

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

+ 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

-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

- 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

- 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

- 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

- 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

4.1.5. 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 bàn giao

- 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

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

+ 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

+ 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

+ 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ụ

+ 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)

+ 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

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

+ 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

+ 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

+ 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

+ 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ả      

+ 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ả

+ 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   

+ Người nhận tiền hỏi  Acquirer thông điệp Acquirer’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

+ 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

+ 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

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

4.2. Bảo mật tiền số

4.2.1. 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 phần còn lại của thông điệp

+ Đồ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

4.2.2. Chống double spending

- Tiền số có thể được sao chép một cách dễ dàng và tùy tiện, được thực thiệ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ó 1 đồng xu có giá trị hợp lệ, có thể cố gắng chi tiêu nhiều hơn 1 lần

- Giải pháp

+ Nặc danh có điều kiện bằng cắt và chọn (cut-and-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ách hàng trung thực không cố gắng tiêu xu nhiều hơn 1 lần và vẫn còn nặc danh

+ Khách hàng không trung thực là những người cố gắng tiêu xu 2 lần, danh tính bị tiết lộ

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

- Ý tưởng: chia 1 thông điệp M thành các mẩu tin và do đó 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ắt bí mật tổng quan, chỉ cần 1 tập con các mẩu tin là đủ)

- Tìm M1 và M2  sao cho:   M = M1 + M2

- Thực  hiện:   chọn  M1 ngẫu  nhiên, cùng độ dài  M và tính M2 theo  M2 =  M +  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= I­1 + 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ùng1 cặp) sẽ được tiết lộ.

4.2.3. 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 xuấ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  2m(k-1)/k  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

4.2.4. 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

a. Đặ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à đảmbả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ị

+ Bcó 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 t B )

+ 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

4.3. Bảo mật séc điện tử

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

+ Proxies

·         Kerberos

·         Restricted Proxy

·         Cascaded Proxies

a. 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 theo1 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

b. Proxies

- Hệ thống NetCheque được phát triển bởi Information Sciences Institute of theUniversity      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 trongNetCheque 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 , K proxy2 }K proxy1 , {K proxy2,  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 nhận để đặt tiền vào tài khoản tương ứng với AS1 tại ASS

              Proxy 3:{deposit <check> to AS2 , Kproxy3  } K proxy2  , {K proxy3 , 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ừ Proxy2,   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