2.5.1. Giao thức SSL
SSL (Secure Socket Layer) là giao thức mã hóa web mục đích chung cho kênh giao tiếp hai chiều bảo mật trên mạng Internet [16].
Giao thức SSL cung cấp bảo mật sử dụng như sau:
- Tính riêng tư (privacy): toàn bộ dữ liệu truyền qua kết nối đều được mã hoá
- Xác thực định danh (Identity Authentication): việc xác thực định danh được thực hiện nhờ sử dụng chứng thư số.
- Tính tin tưởng (reliability): duy trì tin cậy của kết nối bằng việc kiểm tra tính toàn vẹn của thông điệp.
Phiên bản hiện tại của SSL là phiên bản 3.0 được Netscape công bố vào năm 1999. Tổ chức Tiêu chuẩn hoá thế giới (IETF) đã tạo giao thức tương tự nhằm cung cấp giao thức SSL chuẩn trong giao tiếp trên mạng và giao thức này được gọi là giao thức TSL (Transport Layer Security).
Kết nối SSL thường được khởi tạo cùng với trình duyệt web sử dụng một URL đặc biệt, ví dụ https được sử dụng để chỉ ra một kết nối HTTP mã hóa SSL.
Giao thức SSL bao gồm bốn tầng giao thức:
Record Layer: quy định định dạng của các thông điệp sử dụng bởi các giao
header cho mỗi thông điệp và giá trị băm được sinh bởi MAC. Header có độ dài 5 byte, bao gồm: Protocol Definition (1 byte), Protocol Version (2 byte) và Length (2 byte).
ChangeCipherSpec Protocol: được tạo ra bởi một tin nhắn thông báo rằng
bắt đầu truyền thông an toàn giữa máy chủ và máy khách. Mặc dù ChangeCipherSpec Protocol sử dụng định dạng quy đinh bởi Record Layer nhưng thực tế, thông điệp chỉ có độ dài là 1 byte, tín hiệu thay đổi trong giao thức có giá trị ‘1’.
Alert Protocol: giao thức thông báo lỗi, vấn đề hoặc những cảnh báo về kết
nối giữa các thành viên. Tầng này có cấu trúc bao gồm hai trường: Severity Level và Alert Description.
Severity Level: có vai trò gửi thông điệp cùng với giá trị ‘1’ hoặc ‘2’, phụ
thuộc vào bản thân thông điệp. Severity Level có giá trị ‘1’ tương ứng với thông điệp cảnh báo; có giá trị ‘2’ là khi là những cảnh báo quan trọng, yêu cầu các bên tham gia chấm dứt phiên kết nối.
Alert Description: chỉ ra các lỗi cụ thể, trường này chỉ có độ dài 1 byte, có
miền giá trị từ 1 đến 12 tương ứng với 12 lỗi nghiêm trọng.
Handsake Protocol
Mọi phiên làm việc của giao thức SSL đều bắt đầu bằng thủ tục “Handsake”, thủ tục có vai trò trao đổi thông điệp giữa các thành viên tham gia sử dụng mã hoá công khai với mục đích tạo ra một kênh giao tiếp an toàn.
Bước 1 (ClientHello): máy khách gửi tới máy phục vụ một yêu cầu phiên
làm giao tiếp an toàn, trong thông điệp bao gồm: phiên bản SSL, cipher setting (CipherSuite), dữ liệu phiên làm việc (session-specific data) và một số thông tin khác mà server cần để giao tiếp với client sử dụng SSL.
Bước 2 (ServerHello): Máy phục vụ gửi tới máy khách phiên bản SSL,
cipher setting, dữ liệu phiên làm việc (session-specific data) và một số thông tin khác mà máy khách cần để giao tiếp với máy phục vụ thông quan kênh giao tiếp SSL.
Trong bước này, máy phục vụ cũng gửi tới máy khách chứng thư số sở hữu của mình (đây chính là SSL một chiều). Nếu máy khách yêu cầu sử dụng tài nguyên trên máy phục vụ được cấu hình phải xác thực máy khách thì máy phục sẽ yêu cầu máy khách gửi chứng thư số sở hữu bởi máy khách (đây chính là SSL hai chiều hoặc là mutual SSL).
Bước 3: Máy khách sử dụng thông tin được gửi bởi máy phục vụ để xác thực máy phục vụ. Trong trường hợp việc xác thực server thất bại, người dùng
sẽ được cảnh báo và thông báo rằng kết nối mã hoá và xác thực là không thể thực hiện, trường hợp ngược lại sẽ chuyển sang bước tiếp theo.
Bước 4: Sử dụng tất cả dữ liệu được sinh ra trong bước bắt tay trước, máy
khách tạo ra một pre-master secret cho phiên làm việc này, mã hoá bởi khoá công khai của máy phục vụ (được lấy từ chứng chỉ số mà máy phục vụ gửi cho máy khách trong Bước 2) và gửi tới máy phục vụ.
Bước 5: Nếu server yêu cầu máy khách phải xác thực, máy khách cũng phải ký lên một mẫu dữ liệu khác (mẫu này là duy nhất và phải được thống nhất giữa máy khách và máy phục vụ) và gửi mẫu dữ liệu này cùng chứng thư số sở hữu bởi máy khách kèm với pre-master sercret tới máy phục vụ.
Bước 6: Khi máy phục vụ đã yêu cầu xác thực máy khách, nếu máy khách
không thể xác thực, phiên làm việc sẽ kết thúc. Nếu máy khách xác thực thành công, máy phục vụ sẽ sử dụng private key của mình để giải mã pre-master secret và thực hiện một chuỗi các bước để sinh master secret (tại máy khách cũng thực hiện bước sinh master secret từ cùng một pre-master secret mà máy khách đã gửi cho máy phục vụ).
Bước 7: Cả máy khách và máy phục vụ đều sử dụng master secret để sinh
ra khoá phiên (session key – là khoá đối xứng) và sử dụng khoá này để mã hoá và giải mã thông tin trao đổi trong suốt phiên làm việc SSL và xác thực tính toàn vẹn của dữ liệu.
Bước 8: máy khách gửi tin nhắn (message) tới máy phục vụ thông báo rằng
các tin nhắn tiếp theo sẽ được mã hoá sử dụng khoá phiên (session key). Sau đó sẽ gửi một tin nhắn khác (mã hoá sử dụng khoá phiên) để thông báo vai trò của máy khách trong thủ tục bắt tay kết thúc.
Bước 9: máy phục vụ gửi một tin nhắn tới máy khách thông báo các tin
nhắn tiếp theo từ máy phục vụ sẽ được mã hoá sử dụng khoá phiên. Sau đó sẽ gửi một tin nhắn khác thông báo vai trò của máy phục vụ trong thủ tục bắt tay kết thúc.
2.5.2. Giao thức TLS
Năm 1999, công nghệ TLS được thiết kế để tạo ra chuẩn mã hoá cho giao tiếp nội bộ. Mục đích của TLS là ngăn chặn việc nghe trộm, giả mạo tin nhắn. TLS được thiết kế để cung cấp tầng an ninh mã hoá hoàn chỉnh, đảm bảo tính bảo mật cho thông tin truyền tải giữa các máy chủ. Giao thức TLS được xây dựng dựa trên hai giao thức con.
Giao thức TLS Record: Giao thức Record giải quyết kết nối riêng tư được thành lập giữa máy khách và máy chủ. Trong giao thức sử dụng khoá mã hoá đối xứng để đảm bảo kết nối riêng. Một kết nối có thể bảo đảm bằng việc sử dụng hàm băm, và trong TLS sử dụng thuật toán MAC (Message Authentication Code) là một dạng hàm băm.
Thuật toán MAC cũng tương tự như các hàm băm (hash function), thuật toán MAC cũng chỉ ra với đầu vào là một khoá bí mật (MAC secret) và một tin nhắn có độ dài tuỳ ý cần xác thực, hàm MAC sẽ cho ra một đầu ra. Giá trị MAC có tính năng sử dụng bảo toàn dữ liệu cũng như xác thực. Thuật toán MAC phải xử lý yêu cầu bảo mật khác các hàm băm ở điểm: Hàm MAC phải chống lại được các cuộc tấn công giả mạo sử dụng phương pháp chọn bản rõ (Tức là trong trường hợp kẻ tấn công có thể truy cập CSDL chứa khoá bí mật và giá trị MAC sinh ra cho các tin nhắn mà kẻ tấn công sử dụng, kẻ tấn công cũng không thể đoán ra giá trị MAC cho các tin nhắn khác một cách dễ dàng). Thủ tục MAC khác so với chữ ký số ở điểm giá trị MAC được sinh ra và kiểm tra bởi cùng một khoá bí mật, điều này có nghĩa rằng người gửi và người nhận phải thoả thuận và thống nhất cùng một khoá trước khi giao tiếp và đó chính là một trường hợp của mã hoá đối xứng (sysmetric encryption)
Giao thức Handsake: Giao thức Handsake (bắt tay) cho phép máy chủ và
máy khách giao tiếp hợp lệ với nhau. Giao thức đảm bảo rằng máy chủ và máy khách thoả thuận thuật toán mã hoá và khoá trước khi gửi và nhận dữ liệu. Giao thức này tạo ra tính xác thực giữa máy chủ và máy khách.
2.5.3. So sánh TLS và SSL
Hiện tại, cả hai giao thức đều được sử dụng để tạo kết nối bảo mật giữa máy chủ và máy khách, giao thức TLS sử dụng phiên bản TLS 1.0, giao thức
SSL sử dụng phiên bản SSL 3.0. Giữa hai giao thức có các điểm khác biệt chính sau đây:
Alert Message: Nếu máy khách không có chứng nhận để sử dụng, anh ta
có thể gửi tin nhắn “No Certificate” trong giao thức TLS. Trong khi giao thức SSL, nếu máy khách không có chứng nhận, sẽ không cần tin nhắn riêng.
Message Authentication: TLS áp dụng thuật toán MAC (H-MAC) trong
nhiều cài đặt, trong khi đó SSL sử dụng MD5 và SHA. Lợi ích của việc sử dụng H-MAC có thể điều khiển bởi bất kỳ hàm băm nào.
Key Material Generation: TLS áp dụng chuẩn HMAC và PRF để tạo ra khoá. SSL sử dụng RSA, Diffie-Hellman, Fortezza/DMS để sinh khoá.
Certificate Verify Message: Trong giao thức TLS, tin nhắn xác thực
chứng nhận đã chứa tin nhắn bắt tay, tin nhắn này đã được trao đổi trong phiên làm việc. Trong SSL, phải trải quá một quy trình khó khăn để truyền tin nhắn xác minh giấy chứng nhận.
Finished: Trong TLS, tin nhắn hoàn thành được tạo sử dụng hàm PRF với
tham số đầu vào là tin nhắn “client finish” hoặc “server finish”. Trong SSL, tin nhắn hoàn thành được tạo ra tương tự như cách sinh khoá, sử dụng thuật toán mã hoá và bộ tham số thông tin.
2.6. Ứng dụng của chữ ký mù trong giải pháp đảm bảo an ninh thươngmại điện tử mại điện tử
2.6.1. Ứng dụng trong Tiền điện tử2.6.1.1. Giao thức dùng tiền 2.6.1.1. Giao thức dùng tiền
Trong tài liệu về Tiền điện tử [7], tác giả Trịnh Nhật Tiến đã trình bày giao thức cơ bản của lược đồ chữ ký mù được đề xuất bởi Chaum để thực hiện việc dùng tiền điện tử bằng một ví dụ minh hoạ đơn giản, trong đó người mua hàng là A muốn mua một quyển sách với giá $100 từ một người bán hàng trực tuyến bằng tiền điện tử, cả A và người bán hàng cùng sử dụng dịch vụ của một Ngân hàng. Khi đó, giao dịch được thự hiện như sau:
1./ Rút tiền
- A tạo ra đồng tiền điện tử C bao gồm một chuỗi các bit để xác định các thông tin trên đồng tiền C như: số seri và giá trị của C (trong ví dụ là $100).
- Ngân hàng ký mù lên đồng tiền C.
- Ngân hàng trừ $100 trong tài khoản của A tại ngân hàng.
- A yêu cầu cuốn sách mà mình cần mua, sau đó A chuyển đồng tiền C (đã có chữ ký của ngân hàng) tới cho người bán hàng.
- Người bán hàng kiểm tra tính hợp lệ của đồng tiền C mà A gửi tới bằng cách xác thực chữ ký (sử dụng khoá công khai của ngân hàng). Nếu chữ ký không hợp lệ thì người bán hàng kết thúc giao dịch, ngược lại sẽ thực hiện bước tiếp theo.
3./ Gửi tiền
- Người bán hàng lấy đồng tiền C (đã nhận được từ A) gửi tới ngân hàng.
- Ngân hàng xác thực chữ ký trên đồng tiền C. Nếu chữ ký là hợp lệ thì ngân hàng sẽ kiểm tra đồng tiền C đã được tiêu xài trước đây chưa. Trường hợp nếu đồng tiền chưa được tiêu trước đó thì ngân hàng sẽ cộng thêm vào tài khoản người bán giá trị của đồng tiền là $100, đồng thời cập nhật đồng tiền vào danh sách đồng tiền đã được tiêu xài.
- Sau khi gửi tiền tại ngân hàng được chấp nhận, người bán hàng chuyển sách tới cho A.
Khi sử dụng chữ ký mù, người bán hàng khó có thể phát hiện đồng tiền C được tiêu từ tài khoản nào, thêm vào đó, khi người bán hàng gửi đồng tiền C vào tài khoản của mình, ngân hàng cũng khó có thể biết đồng tiền đó là được tiêu xài bởi A vì nó đã được ký mù.
2.6.1.2. Vấn đề phát sinh khi dùng chữ ký mù
Khi sử dụng chữ ký mù, vấn đề có thể xảy ra đối với việc ngân hàng ký mù lên đồng tiền điện tử. Ví dụ, A gửi cho ngân hàng một đồng tiền, tuy nhiên A không trung thực khi khai báo giá trị đồng tiền và yêu cầu ngân hàng ký lên đồng tiền đó. Khi đó, sẽ xảy ra trường hợp A làm tờ tiền $1000 nhưng lại khai báo với ngân hàng giá trị đồng tiềnl à $100, tuy nhiên ngân hàng sẽ không phát hiện ra giá trị thật của đồng tiền vì khi ký đồng tiền đã được làm mù. Trong [7] trình bày hai cách giải quyết vấn đề trên:
1./ Cách thứ nhất
Ngân hàng sử dụng các khoá ký (bí mật) khác nhau với các lượng tiền khác nhau. Theo đó, nếu A muốn lấy đồng tiền trị giá $1000 nhưng khai báo với ngân hàng giá trị đồng tiền là $100, vì thế ngân hàng sẽ dùng bộ khoá tương ứng với đồng tiền trị giá $100 để ký. Khi A tiêu xài đồng tiền, ngân hàng sẽ kiểm tra chữ ký và giá trị đồng tiền và phát hiện ra khoá ký và giá trị đồng tiền là không hợp lệ.
2./ Cách thứ hai
A và ngân hàng sẽ thực hiện một giao thức dựa trên xác suất, giao thức đó sẽ được thực hiện như sau:
Trước tiên, A sẽ phải tạo ra k đồng tiền (c1, c2 , …, ck), các đồng tiền này có mệnh giá giống nhau, chỉ khác nhau về số seri. Sau đó, A làm mù k đồng tiền này và gửi tới cho ngân hàng.
Tiếp theo, ngân hàng chọn ngẫu nhiên k – 1 đồng tiền và yêu cầu A tiết lộ thông tin để khử mù k – 1 đồng tiền này. Ngân hàng xoá mù k – 1 đồng tiền, sau đó kiểm tra tính hợp lệ, nếu toàn bộ đồng tiền là hợp lệ thì ngân hàng sẽ ký mù lên đồng tiền còn lại và gửi cho A. Ngược lại, ngân hàng sẽ từ chối ký và huỷ đồng tiền còn lại.
Nếu k càng lớn thì xác suất A gian lận giá trị của đồng tiền còn lại càng thấp.
2.6.2. Ứng dụng trong Bầu cử điện tử trực tuyến
Trong tài liệu Quy trình bỏ phiếu từ xa [8], tác giả Trịnh Nhật Tiến đã trình bày ứng dụng của chữ ký mù trong bỏ phiếu trực tuyến như sau:
2.6.2.1. Giao thức
Theo phương thức bỏ phiếu điện tử, mỗi lá phiếu phải có thông tin định danh. Nó có thể là số x nào đó và phải khác nhau. Mỗi lá phiếu phải có chữ ký trên định danh x thì lá phiếu mới có giá trị để bầu cử.
Nếu cử tri CT chuyển định danh x cho Ban bầu cử ký, thì những thành viên trong ban bầu cử có thể xác định được mối quan hệ giữa cử tri và x. Đó là điều cử tri không muốn vì sợ rắc rối sau này.
Vì thế, cử tri biến đổi x thành y trước khi đưa cho ban bầu cử ký xác nhận, Ban bầu cử ký vào y. Họ trao chữ ký trên y là z cho CT. Cử tri xoá mù trên z sẽ thu được chữ ký của Ban bầu cử trên định danh x, như vậy cử tri CT có quyền bầu cử.
Với kỹ thuật này, cuộc bỏ phiếu đảm bảo được: quyền bỏ phiếu và bí mật, tức là chí có người có quyền bầu cử mới được bỏ phiếu (vì trên lá phiếu đã có chữ ký của ban bầu cử).
2.6.2.2. Vấn đề phát sinh khi dùng chữ ký mù
Do ký mù trên lá phiếu nên Ban bầu cử không ghi lại được định danh của cử tri. Do đó, cử tri có thể xin nhiều lá phiếu để bỏ phiếu nhiều lần. Vấn đề này có thể giải quyết như sau:
- Cử tri
+ Cử tri chọn bí mật số định danh x, “làm mù” thành y = blind(x)
+ Cử tri gửi tới ban bầu cử thông tin nhận dạng của mình, chưng minh thư điện tử, số y (định danh x đã được làm mù thành y).
- Ban bầu cử
+ Nếu hồ sơ của cử tri hợp lệ, khớp với danh sách cử tri của Ban điều hành, cử tri chưa xin cấp chữ ký lần nào, thì ra lệnh cho Hệ thống “ký” lên y. Đó là chữ ký z = sign(y).
+ Ban bầu cử ghi số chứng minh thư của cử tri vào danh sách cử tri đã được