Bài giảng thương mại điện tử chương 6 đỗ thị nhâm

29/08/2017 Chương An ninh TMĐT Nguyên nhân trở ngại TMĐT phát triển Nguyên nhân trở ngại TMĐT phát triển Vấn đề an ninh cho hệ thống TMĐT Các giao thức bảo mật Cho tơi lòng tin (của khách hàng), tơi trở thành tỷ phú (USD) “Lý làm người dùng ngần ngại An ninh TMĐT sử dụng TMĐT lo bị thơng tin thẻ tín dụng, bí mật cá nhân bị dùng sai mục đích.” www.ecommercetimes.com, 2003 2 Vấn đề an ninh cho hệ thống TMĐT Vấn đề an ninh cho hệ thống TMĐT  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ử…  Một số dạng công tin học TMĐT  Phần mềm độc hại (virus, trojan, worm)  Rủi ro thương mại truyền thống xuất TMĐT hình thức tinh vi, phức tạp  Tin tặc  Gian lận thẻ tín dụng  Tội phạm TMĐT tinh vi, phức tạp  Tấn công từ chối dịch vụ (DOS)  Phishing (kẻ giả mạo)  Các hệ thống an ninh tồn điểm yếu  Vấn đề an ninh với việc dễ dàng sử dụng hai mặt đối lập  Phụ thuộc vào vấn đề an ninh Internet, an ninh toán, số lượng trang web… 3 Các giao thức mật mã Các giao thức mật mã  Mật mã giải vấn đề có liên quan đến bí mật, xác thực, tính tồn vẹn, chống phủ định   Một người khơng tạo nên giao thức Một người thực loạt bước để hoàn thành nhiệm vụ, điều giao thức  Giao thức chuỗi bước, liên quan đến hai nhiều bên, thiết kế để thực nhiệm vụ  “Chuỗi bước”: giao thức có trình tự, từ đầu đến cuối “Liên quan đến hai hay nhiều bên”: hai người yêu cầu hoàn thành giao thức  “Được thiết kế để hoàn thành nhiệm vụ”: giao thức phải đạt  Mỗi bước phải thực lần lượt, khơng bước trước bước trước kết thúc 29/08/2017 Các giao thức mật mã Các giao thức mật mã  Tất người tham gia giao thức phải  Một giao thức mật mã liên quan đến số thuật toán mật mã, nói chung, mục tiêu giao thức khơng phải bí mật đơn giản  Biết giao thức tất bước để làm theo  Đồng ý làm theo  Giao thức phải rõ ràng  Các bên muốn  Mỗi bước phải xác định rõ ràng  Chia sẻ phần bí mật để tính tốn giá trị  Khơng có hội để hiểu lầm  Cùng tạo chuỗi ngẫu nhiên  Giao thức phải hoàn thành  Thuyết phục người khác xác thực  Hoặc đồng thời ký hợp đồng  Phải có hành động cụ thể cho tình xảy Các giao thức mật mã Danh sách người tham gia thường xuyên  Cốt lõi việc sử dụng mật mã học giao thức ngăn chặn phát nghe gian lận  Alice: Người thứ tham gia vào tất giao thức  Không nên làm nhiều tìm hiểu nhiều quy định giao thức  Bob: Thứ hai tham gia tất giao thức  Trent: Trọng tài tin cậy Giao thức trọng tài Giao thức trọng tài  Trọng tài: bên thứ ba đáng tin cậy giúp hồn thành giao thức hai hai bên khơng tin tưởng  Trong giới thực, luật sư thường sử dụng trọng tài  10 Ví dụ: Alice bán xe cho Bob, người lạ Bob muốn tốn séc, Alice khơng có cách để biết séc có hiệu lực 11  Nhờ luật sư đáng tin cậy cho hai Với giúp đỡ luật sư, Alice Bob sử dụng giao thức sau để đảm bảo khơng có gian lận  (1) Alice trao quyền cho luật sư  (2) Bob gửi séc cho Alice  (3) Alice đặt cọc séc  (4) Sau chờ đợi khoảng thời gian cụ thể để séc làm rõ ràng, luật sư trao quyền cho Bob Nếu séc không rõ ràng khoảng thời gian cụ thể, Alice chứng minh với luật sư luật sư trả trao quyền lại cho Alice 12 29/08/2017 Giao thức phân xử Giao thức phân xử  Bởi chi phí th trọng tài cao, giao thức trọng tài chia thành giao thức  Ví dụ: giao thức ký kết hợp đồng thức hóa theo cách   Giao thức khơng có trọng tài, thực thi thời điểm  Giao thức khơng có trọng tài (thực thi thời điểm): bên muốn hoàn thành giao thức  (1) Alice Bob đàm phán điều khoản hợp Giao thức có trọng tài, thực thi hồn cảnh ngoại lệ - có tranh chấp  (2) Alice ký hợp đồng đồng  (3) Bob ký hợp đồng 13 Giao thức phân xử  14 Trao đổi khóa với mã đối xứng Giao thức phân xử (chỉ thực thi có tranh chấp):  (4) Alice Bob xuất trước quan tòa  (5) Alice đưa chứng  (6) Bob trình bày chứng  Giả sử Alice Bob muốn chia sẻ khóa bí mật với thông qua Key Distribution Center (KDC) trọng tài giao thức  Các khóa phải thực trước giao thức bắt đầu  (1) Alice gọi trọng tài yêu cầu khóa phiên dùng chung để giao tiếp với Bob  (2) Trọng tài tạo khóa phiên ngẫu nhiên, mã hóa hai nó: khóa Alice khóa Bob Trọng tài gửi copy tới cho Alice  (7) Quan tòa phán dựa chứng 15 Trao đổi khóa với mã đối xứng  (3) Alice giải mã khóa phiên  (4) Alice gửi cho Bob khóa phiên  (5) Bob giải mã khóa phiên  (6) Cả Alice Bob dùng khóa phiên để giao tiếp an tồn 17 16 Trao đổi khóa với mã đối xứng 18 29/08/2017 Trao đổi khóa với mã đối xứng Trao đổi khóa với mã đối bất xứng  Alice Bob sử dụng mật mã khóa cơng khai để thống khóa phiên dùng chung, dùng khóa phiên để mã hóa liệu  Trong số triển khai thực tế, hai khóa cơng khai Alice Bob ln có sẵn CSDL 19 Trao đổi khóa với mã bất đối xứng 20 Giao thức Needham-Schroeder  (0) Trước giao dịch diễn ra, người sử dụng hệ thống có khóa bí mật chia sẻ với  (1) Alice nhận khóa công khai Bob từ KDC  (2) Alice tạo khóa phiên ngẫu nhiên, mã hóa cách sử dụng khóa cơng khai Bob gửi đến Bob  (3) Bob sau giải mã thơng điệp Alice cách sử dụng khóa riêng  (1) Alice gửi thơng điệp đến Trent bao gồm tên mình, tên Bob, số ngẫu nhiên: A, B, RA  (4) Cả hai mã hóa thơng tin liên lạc sử dụng khóa phiên  (2) Trent tạo khóa phiên ngẫu nhiên K, mã hóa thơng điệp bao gồm khóa phiên ngẫu nhiên tên 21 Trent Alice khóa bí mật Bob Sau đó, mã hóa giá trị ngẫu nhiên Alice, tên Bob, khóa, thơng điệp mã hóa khóa bí mật chia sẻ với Alice, gửi Alice mã hóa: EA (RA, B, K, EB(K,22 A)) Giao thức Needham-Schroeder Chữ ký mù  (3) Alice giải mã tin nhắn rút K Alice khẳng định RA giá trị mà gửi Trent bước (1) Sau đó, Alice gửi Bob tin nhắn Trent mã  Đặc tính tất yếu giao thức chữ ký số người ký biết ký hóa khóa Bob: EB(K, A)  (4) Bob giải mã tin nhắn rút K Sau đó, Bob tạo giá trị ngẫu nhiên, RB, mã hóa tin nhắn với K gửi cho Alice: EB(RB)  (5) Alice giải mã tin nhắn với K, tạo RB - mã hóa với K, sau gửi tin nhắn cho Bob: EB(RB - 1) 23  Chúng ta muốn người ký văn mà khơng nhìn thấy nội dung  Bob công chứng viên Alice muốn Bob ký tài liệu, khơng muốn có ý tưởng ký  Bob khơng quan tâm tài liệu nói, xác nhận có cơng chứng thời gian định Bob sẵn sàng làm điều 24 29/08/2017 Chữ ký mù Lược đồ chữ ký mù  (1) Alice có tài liệu nhân giá trị ngẫu nhiên (multiple) Giá trị ngẫu nhiên gọi yếu tố làm mù  (2) Alice gửi tài liệu mù Bob  3) Bob ký tài liệu mù  (4) Alice phân tách yếu tố làm mù, để lại tài liệu gốc có chữ ký Bob  Bước 1: A làm mù x hàm: z=Blind(x), gửi z cho B  Bước 2: B ký z hàm y = Sign(z) = Sign(Blind(x)), gửi lại y cho A  Bước 3: A xóa mù y hàm Sign(x) = UnBlind(y) = UnBlind(Sign(Blind(x))) 25 26 Chữ ký mù An ninh TMĐT  Các thuộc tính chữ ký mù hồn chỉnh  Bảo mật giao dịch toán  Chữ ký Bob lên tài liệu hợp lệ  Bảo mật tiền số  Chữ ký minh chứng Bob ký tài liệu  Nó thuyết phục Bob ký tài liệu hiển thị cho  Nó có tất thuộc tính khác chữ ký số  Bảo mật séc điện tử  Bob đánh đồng văn ký kết với hành vi ký kết tài liệu  Ngay Bob giữ hồ sơ tất chữ ký mù, Bob xác định ký tài liệu 27 28 4.1 Bảo mật giao dịch toán 4.1 Bảo mật giao dịch toán  Giao dịch toán điện tử thực thi giao thức mà theo khoản tiền lấy từ người trả tiền chuyển cho người nhận Nặc danh người dùng khơng theo dõi tốn  Trong giao dịch tốn, thường phân biệt thơng tin đặt hàng (hàng hóa, dịch vụ phải trả) tài liệu tốn (ví dụ, số thẻ tín dụng) Nặc danh người tốn Khơng theo dõi giao dịch toán Bảo mật liệu giao dịch tốn Thơng điệp chống phủ định giao dịch tốn  Từ góc độ an ninh, hai loại thông tin cần thiết phải xử lý đặc biệt 29 30 29/08/2017 4.1.1 Nặc danh người dùng không theo dõi Chuỗi hỗn hợp Mixes  Đặc tính nặc danh người dùng khơng theo dõi tốn cung cấp riêng biệt  Ý tưởng  Thông điệp gửi từ A, B, C (đại diện cho khách hàng có yêu cầu nặc danh) tới hỗn hợp từ hỗn hợp tới X, Y, Z (đại diện cho người bán ngân hàng “tò mò” thơng tin xác thực khách hàng)  Thơng điệp mã hóa với khóa cơng khai 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  Dịch vụ an ninh nặc danh người dùng “tinh khiết” 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 tốn “tinh khiết” bảo vệ chống lại tiết lộ địa điểm thông điệp gốc Y, A gửi tới hỗn hợp cấu trúc sau:  A → Mix: EM(Y, EY(Y, Message))  Giải pháp: Sử dụng chuỗi hỗn hợp Mixes  Bây giờ, hỗn hợp giải mã gửi kết cho Y:  Mix → Y: EY(Y, Message) 31 Chuỗi hỗn hợp Mixes Chuỗi hỗn hợp Mixes  Chỉ có Y đọc thơng điệp mã khóa cơng khai Y, EY  Nếu A muốn Y phản hồi, A hàm chứa địa phản hồi nặc danh thông điệp gửi tới Y: Mix, EM(A)  32 A tạo khóa Kx khóa phiên dùng chung (chỉ dùng lần) với  Theo cách này, thông điệp phản hồi gửi tới mix, mix biết người gửi  Hạn chế  Hỗn hợp phải hoàn toàn đáng tin cậy Y Và khóa S1 khóa ngẫu nhiên dùng để liêm phong  A gửi Mix thông điệp:  A → Mix:  hỗn hợp Mix giải mã gửi kết cho Y  Mix → Y: EY(Y, Message, Mix, EM(A,S1),Kx)  Y → Mix: EM(A,S1), Kx(Response)  Mix → A: S1(Kx(Response)) EM(Y, EY(Y, Message, Mix, EM(A,S1),Kx)) 33 Chuỗi hỗn hợp Mixes 34 Chuỗi hỗn hợp Mixes  Giải vấn đề tin cậy hỗn hợp, sử dụng chuỗi hỗn hợp (mạng) 35 36 29/08/2017 Chuỗi hỗn hợp Mixes 4.1.2 Sự nặc danh người toán  Nếu A muốn gửi thông điệp nặc danh, không bị theo dõi tới Y, A sử dụng giao thức sau:  Người trả tiền sử dụng bút danh thay nhận dạng  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(…))  Nếu bên muốn chắn hai giao dịch toán khác thực người liên kết với nhau, đặc tính khơng theo dõi giao dịch toán phải cung cấp  Giải pháp: Sử dụng bút danh 37 38 Bút danh Bút danh  Hệ thống First Virtual  Hệ thống First Virtual  Thông điệp ủy quyền FV người bán trước chuyển hàng cần phải 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), chuỗi kí tự chữ số hoạt động bút danh cho thẻ tín dụng, gửi qua email   Nếu khách hàng cố gắng sử dụng VPIN mà không ủy quyền, FV thông báo VPIN bị đánh cắp khách hàng phản hồi “fraud” (có gian lận) cho yêu cầu FV để xác nhận mua bán  Trong trường hợp VPIN bị hủy bỏ  Cơ chế đảm bảo tính bí mật lệnh tốn người bán kẻ nghe trộm tiềm Nếu VPIN bị đánh cắp, khách hàng khơng có thẩm quyền khơng thể sử dụng tất giao dịch xác nhận email trước trừ tiền thẻ tín dụng 39 40 Bút danh Bút danh  Hệ thống First Virtual  Giao dịch hệ thống FV 41  (1) Khách hàng gửi đơn hàng tới người bán 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ụ toán FV  (3) Nếu VPIN 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 toán cho dịch vụ (qua e-mail) (Khách hàng từ chối tốn dịch vụ chuyển khơng đáp ứng mong đợi mình) 42 29/08/2017 Bút danh 4.1.3 Khơng theo dõi giao dịch tốn  Giao dịch hệ thống FV  Hashsum ngẫu nhiên toán iKP  (7) Nếu khách hàng muốn toán, trả lời “Yes”  (8a) Số lượng toán trừ tài khoản khách hàng  (8b) Gửi vào tài khoản người bán  (9) Giao dịch bù trừ ngân hàng  Hashsum ngẫu nhiên SET 43 44 Hashsum ngẫu nhiên toán iKP Hashsum ngẫu nhiên SET  Khi khởi tạo giao dịch toán, khách hàng chọn giá trị ngẫu nhiên RC tạo giá trị bút danh dùng lần IDC theo cách sau:  Người bán nhận giá trị hashsum từ lệnh toán IDC = hk(RC, BAN)  Lệnh toán chứa 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  BAN số tài khoản ngân hàng khách hàng   hk(.) đụng độ hash 1-chiều, không tiết lộ thông tin BAN RC chọn ngẫu nhiên Khóa chia sẻ bí mật chủ thẻ, cổng toán chứng thực ủy quyền chủ thẻ, PANSecret  Người bán nhận IDC (không phải BAN), tính BAN Giá trị ngẫu nhiên nonce ngăn chặn công từ điển, EXNonce  Khi nonce khác với giao dịch, người bán liên kết giao dịch với dùng chung PAN 46  45 4.1.4 Bảo mật liệu giao dịch toán Hàm số ngẫu nhiên giả  Hàm số ngẫu nhiên giả  Thanh toán iKP họ giao thức toán (i = 1, 2, 3) phát triển IBM  Chữ ký kép (Dual signature)  Hỗ trợ giao dịch thẻ tín dụng, với CyberCash, Secure Transaction Set Technology giao thức tóan điện tử an tồn hình thức nguyên thủy quan trọng SET 47 48 29/08/2017 Hàm số ngẫu nhiên giả Hàm số ngẫu nhiên giả  Cơ chế 1KP cung cấp tính bảo mật thơng tin với cổng tốn, người bán, nặc danh khách hàng  Bảo mật thông tin tương ứng với ngân hàng toán thực theo cách tương tự  Khi khởi tạo giao dịch, khách hàng chọn giá trị ngẫu nhiên RC tạo bút danh dùng lần IDC:  giao dịch, gửi cho người bán dạng liệu rõ  Dùng hàm hash trên, người bán gửi mô tả thông tin (DESC) cho ngân hàng tốn:  Ngân hàng tốn nhìn thấy giá trị hashsum khơng đủ thơng tin để tìm DESC IDC = hk(RC, BAN)  BAN số tài khoản ngân hàng khách hàng  hk(.) đụng độ hash k-chiều, không tiết lộ thông tin BAN RC chọn ngẫu nhiên  Người bán nhận IDC (khơng phải BAN), khơng thể tính BAN 49 Hàm số ngẫu nhiên giả    Khách hàng chọn giá trị ngẫu nhiên SALTC khác cho hk(SALTC, DESC) 50 Hàm số ngẫu nhiên giả Nếu số lượng DESC khơng nhiều, ngân hàng tốn tính tất giá trị hashsum với SALTC cho trước lấy thông tin Ngân hàng tốn tin tưởng vài phạm vi Để truyền lệnh toán tới ngân hàng tốn mà người bán khơng thể đọc được, iKP sử dụng khóa cơng khai 51  Khách hàng mã hóa thơng điệp, gồm:  Giá hàng hóa đặt  Lệnh tốn (số thẻ tín dụng, mã PIN)  hk(SALTC, DESC) băm với liệu giao dịch  Giá trị ngẫu nhiên RC để tạo bút danh dùng lần với khóa cơng khai ngân hàng tốn  Thơng điệp mã hóa gửi cho người bán chuyển tiếp tới ngân hàng toán 52 Hàm số ngẫu nhiên giả Chữ ký kép (Dual signature)  Khách hàng phải có chứng thực khóa cơng khai ngân hàng toán phát hành tổ chức chứng thực ủy quyền tin cậy  SET tiêu chuẩn mở cho giao dịch thẻ tín dụng an tồn mạng  Chỉ có ngân hàng tốn giải mã thơng điệp, qua RC xác thực độ xác IDC  Kết nối lệnh toán thông tin đặt hàng thiết lập thông qua giá trị hk(SALTC, DESC) tất bên biết  Khởi động Visa MasterCard năm 1996, dùng cơng nghệ mã hóa RSA  Để bảo vệ số thẻ tín dụng (lệnh tốn khách hàng) từ việc nghe trộm hay người bán không trung thực, SET sử dụng chữ ký kép  Sự kết hợp giá trị cho giao dịch 53 54 29/08/2017 Chữ ký kép (Dual signature) Chữ ký kép (Dual signature)  Kịch toán  Khách hàng tính DS = DC(h(h(PI),h(OI)))  PI – lệnh toán (payment instruction)  Giả sử M biết OI, P biết PI, nhận phần bí mật hashsum  OI – thông tin đặt hàng  M – người bán  M nhận: OI, h(PI), DS  P – payment gateway  P nhận: PI, h(OI), DS  Mục tiêu: Người bán M khơng thể đọc thơng tin lệnh tốn, cổng tốn P khơng thể đọc thơng tin đặt hàng  Cả xác thực DS  Nếu P đồng ý, lệnh tốn xác, cấp quyền khả thi, P kí lên PI, M đồng ý, ký lên OI  Thực hiện: Khách hàng thực chữ ký kép lên yêu cầu tốn, tức là, C kí lên PI OI dự định gửi cho P M, sử dụng hàm mã hóa hash h(.) khóa bí mật DC từ thuật tốn khóa cơng khai 55 Chữ ký kép (Dual signature)  Trong SET, h(PI) h(OI) giá trị hashsum SHA-1  C gửi PI tới M theo dạng mã hóa (thuật tốn mã hóa đối xứng với khóa ngẫu nhiên bí mật K)  Khóa bí mật mã hóa gửi khóa cơng khai P, EP, P đọc  C → M: OI, h(PI), DS, EP(K), EK(P, PI, h(OI))  M chuyển tiếp tất thành phần thông điệp (ngoại trừ OI) tới P yêu cầu cấp phép 56 4.1.5 Chống phủ định giao dịch toán  Chống phủ định ngăn chặn việc từ chối nguồn gốc tài liệu phủ nhận chứng bàn giao  Giải pháp: Chữ ký số 57 58 Chữ ký số Chữ ký số  Để giải thích vấn đề chống phủ định, ta sử dụng mơ hình 3KP  Ví dụ   Acquirer đại diện cho cổng toán ngân hàng tốn Thẻ tín dụng 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)   Giả định thông tin đặt hàng (hàng hóa, dịch vụ, giá cả, hình thức giao hàng) thương lượng trước thông báo (yêu cầu) tốn Người nhận tiền muốn xác thực thẻ tín dụng dùng để tính tốn, gửi thơng báo yêu cầu ủy quyền (authorization request) tới ngân hàng tốn   Thơng báo tốn để xác thực giao dịch toán Thông điệp trả lời ủy quyền (authorization response) chứa kết ủy quyền   Người trả tiền gửi người nhận thơng báo tốn gồm lệnh tốn cơng cụ tốn xác định Nếu kết chắn, người nhận gửi xác nhận toán (payment receipt) cho người trả gửi hàng hóa dịch vụ 59 60 10 29/08/2017 Chữ ký số Chữ ký số 61 62 Chữ ký số Chữ ký số  Vấn đề chống phủ định ủy quyền  Vấn đề chống phủ định ủy quyền  Thông điệp ủy quyền gửi thành phần, thành phần có cặp khóa cơng khai, khóa chứng thực tổ chức chứng thực đáng tin cậy  Người nhận cần chứng (không thể từ chối) người trả đồng ý trả khoản tiền định  Bằng chứng chứa thông điệp Payer’s Payment Authorization, đảm bảo chống phủ định ủy quyền toán người trả  Ngân hàng toán ngân hàng phát hành cần chứng Payer’s Payment Authorization để thu hồi số tiền bán hàng từ tài khoản người trả, ghi có tài khoản người nhận, ký khóa bí mật người trả  Ngân hàng toán ngân hàng phát hành cần chứng chống phủ định ủy quyền tóan người nhận, chức Payee’s Payment Authorization, đảm bảo chống phủ định ủy quyền tốn, ký khóa bí mật người nhận 63 64 Chữ ký số 4.2 Bảo mật tiền số  Vấn đề chống phủ định ủy quyền Khơng theo dõi giao dịch tố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 tóan, khóa khóa bí mật Acquirer  Acquirer’s payee auth chứng minh người nhận toán ủy quyền để nhận khoản toán  Giấy chứng nhận gửi cho người nhận chuyển tiếp cho người trả, người nhận từ chối người trả trả cho đơn hàng đặt  Biên lai thường ký người nhận 65 Chống double spending Chống làm giả xu Chống đánh cắp xu 66 11 29/08/2017 4.2.1 Không theo dõi giao dịch tốn 4.2.1 Khơng theo dõi giao dịch toán  Khi khách hàng rút tiền truyền thống từ máy ATM tài khoản ngân hàng, chuỗi series numbers tiền thường không ghi lại  Serial numbers tồn dạng số dễ tạo ghi lưu lại thông tin khách hàng  Các giao dịch tốn khơng thể liên kết tới khách hàng cụ thể  Vì vậy, đơn giản để thực theo dõi giao dịch toán điện tử khách hàng cách lần theo serial numbers  Tiền số có số serial numbers biểu diễn số thỏa mãn điều kiện cụ thể  Giải pháp  Chữ ký mù  Trao đổi xu 67 68 Chữ ký mù Chữ ký mù  D Chaum đề xuất nhằm che giấu liên kết đồng xu phát hành với thông tin xác thực khách hàng  Kịch (dựa thuật toán RSA)  Cung cấp nặc danh cho người toán khơng theo dõi giao dịch tốn dựa chữ ký mù  Người ký khơng nhìn thấy ký  d khóa bí mật người gửi, e n khóa cơng khai  Tham số k gọi nhân tố làm mù, chọn message provider  Provider làm mù thông điệp M: M’ = Mke mod n  Người ký thực 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 69 Chữ ký mù 70 Trao đổi xu  Người ký thường muốn kiểm tra thông điệp M (tức là, tiền giấy hay tiền số) hợp lệ  Provider chuẩn bị n thông điệp làm mù với nhân tố làm mù khác  Người ký chọn n-1 thông điệp ngẫu nhiên hỏi provider để gửi nhân tố mù tương ứng  Người ký kiểm tra n-1 thông điệp, đúng, ký lên thông điệp lại  Đồng xu điện tử làm mù theo cách sử dụng hệ thống toán online, để kiểm tra double spending, phải kiểm tra CSDL trung tâm 71  Cơ chế nặc danh người dùng nặc danh toán dựa bên thứ ba đáng tin cậy  Sử dụng mạng máy chủ tiền để trao đổi sở xác thực xu cho xu nặc danh, sau khẳng định tính hợp lệ kiểm tra double spending  Kiểu nặc danh yếu chữ ký mù  Với chữ ký mù, xác định danh tính người dùng  Với máy chủ tiền, bên có âm mưu, gồm máy chủ tiền giao dịch, xác định sử dụng tiền 72 12 29/08/2017 4.2.2 Chống double spending Nặc danh có điều kiện cắt chọn  Tiền số chép cách dễ dàng tùy tiện, thực thiện liệu điện tử đơn giản  Được kích hoạt cho khách hàng khơng trung thực  cố gắng chi tiêu nhiều lần  Giải pháp  Nặc danh có điều kiện cắt chọn (cut-and-choose)  Người bảo vệ Khách hàng trung thực không cố gắng tiêu xu nhiều lần nặc danh  Người trả tiền có đồng xu có giá trị hợp lệ,  Khách hàng khơng trung thực người cố gắng tiêu xu lần, danh tính bị tiết lộ 73 74 Nặc danh có điều kiện cắt chọn Nặc danh có điều kiện cắt chọn  Cơ chế chia cắt bí mật  Trong tiền số, đồng xu gán chuỗi số N cặp mã hóa khác (I1, I2) (tức là, mã với khóa khác nhau) để thơng tin xác thực khách hàng tiết lộ  Ý tưởng: chia thông điệp M thành mẩu tin tất mẩu tin phải xếp để tái tạo lại M (trong mơ hình chia cắt bí mật tổng quan, cần tập mẩu tin đủ)  Tìm M1 M2 cho  Khi khách hàng trả tiền, người bán yêu cầu khách giải mã I1 I2 từ cặp (chọn ngẫu nhiên)  Thực hiện: chọn M1 ngẫu nhiên, độ dài M tính M2 theo 75 76 Nặc danh có điều kiện cắt chọn Người bảo vệ  Xác minh xem kết giải mã hợp lệ áp dụng thuật tốn mã khóa cơng khai  Tập chế phức tạp bảo vệ chống lại double spending hệ thống toán off-line  Nếu khách hàng cố gắng tiêu xu lần nữa, với N đủ lớn (N=100), phần I giống với phần  Cơ chế tương tự sử dụng wallet I tiết lộ thời điểm tiêu lần đầu (từ cặp) tiết lộ  Ý tưởng: Bên phát hành tổ chức ngân hàng phát triển tiền điện tử  Ví (wallet) chứa ví (purse), tin tưởng người trả tiền, người bảo vệ tin cậy bên phát hành 77 78 13 29/08/2017 Người bảo vệ Người bảo vệ  Người bảo vệ: Là chip vi xử lý đặt cố định ví thẻ thơng minh  Bảo vệ lợi ích bên phát hành giao dịch toán offline   Là thiết bị chống trộm 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, hình riêng  Bảo vệ lợi ích người trả tiền (nặc danh theo dõi)  Xác thực người bảo vệ, người bảo vệ giao tiếp bên ngồi thơng qua purse 79 80 Chữ ký người bảo vệ Chữ ký người bảo vệ  Người trả tiền rút tiền điện tử từ tài khoản tiền xu nạp vào ví  Tham số công khai giống DSA  p số nguyên tố đủ lớn  “một phần” đồng xu đưa vào ví  q số nguyên tố đủ lớn  “một phần” khác gửi tới người bảo vệ  g sinh module p q, tức g = hp-1/q mod p > (1