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