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
Bạn đang đọc truyện trên: Truyen2U.Pro