mật mã đƣờng cong Elliptic
Nhƣ đã đề cập ở trên, hạ tầng khóa công khai sử dụng các hệ mật mã công khai để cung các dịch vụ an ninh. Hiện nay, các chứng thƣ đƣợc phát hành hầu hết sử dụng hệ mật mã RSA. Nếu các đối tƣợng sử dụng cuối là các thiết bị có cấu hình cao nhƣ máy vi tính, router, hay nhƣ các thiết bị chuyên biệt thì việc triển khai chứng thƣ sử dụng hệ mật mã RSA hoàn toàn không có trở ngại nào. Tuy nhiên, việc triển khai hệ mật mã RSA trên các thiết bị có năng lực tính toán hạn chế nhƣ trên các thiết bị di động thì hoàn toàn không thích hợp. Chính vì lẽ đó cho tơi nay, các thiết bị di động gần nhƣ không thể sử dụng chứng thƣ số cho các giao dịch cần đƣợc xác thực.
Hệ mật mã ECC là hệ mật mã công khai, có nhiều ƣu điểm vƣợt trội so với hệ mật mã RSA, rất phù hợp cho việc áp dụng trên các thiết bị di động. Do vậy việc sử dụng hệ mật mã công khai trên nền tảng hạ tầng khóa công khai cho phép các thiết bị di động có thể sử dụng các chứng thƣ số mà không gặp phải những rào cản về tốc độ xử lý cũng nhƣ hạn chế về bộ nhớ và băng thông.
Trong phần này, học viên sẽ đề xuất ứng dụng triển khai hạ tầng khóa công khai sử dụng hệ mật mã ECC trong việc phát hành chứng thƣ cho thiết bị di động. Việc xây dựng một hệ thống CA với đầy đủ các tính năng là một công việc rất lớn, do vậy trong phạm vi của luận văn, học viên sẽ xây dựng giao thức cấp phát chứng thƣ cho thiết bị di động. Sau khi chứng thƣ đƣợc phát hành thành công, việc xác thực dựa trên dịch vụ ký số là một hoàn toàn đơn giản.
3.3.4.1. Giao thức cấp pháp chứng thư trên thiết bị di động
Giao thức cấp phát chứng thƣ cho thiết bị di động đƣợc xây dựng gồm 2 giai đoạn:
a.Giai đoạn đăng ký cấp phát chứng thƣ
Trong giao đoạn này, ngƣời sử dụng sẽ phải đăng ký thủ tục cấp phát chứng thƣ với đơn vị đăng ký (RA – Register Authority). Sau khi đƣợc xét duyệt, đơn vị RA sẽ cấp cho khách hàng một mã định danh và một mã xác thực. Việc cung cấp này đƣợc thực thi bằng nhiều biện pháp tin cậy khác nhau nhƣ bằng vật lý, hoặc việc cung cấp cho ngƣời dùng 1 đƣờng liên kết web sử dụng giao thực https. Mã xác thực ngƣời dùng nhận đƣợc sẽ đƣợc sử dụng để xác thực việc cấp phát chứng thƣ cho ngƣời dùng hợp lệ.
Các bƣớc thực thi đƣợc mô tả trong hình vẽ dƣới đây:
b. Giai đoạn cấp phát chứng thƣ
Sau khi đăng ký phát hành chứng thƣ thành công với cơ quan RA. Ngƣời sử dụng nhận đƣợc mã xác thực RegCode, sau đó ngƣời dùng sẽ đƣợc hƣớng dẫn cài đặt 1 phần mềm lên thiết bị di động của mình. Phần mềm đƣợc phát triển trên nền tảng Java sử dụng công nghệ J2ME để tƣơng thích với hầu hết các thiết bị di động có năng lực xử lý hạn chế. Để thuận tiện, chứng thƣ của CA đƣợc cài đặt mặt định sẵn trong phần mềm. Do vậy, để tránh sự giả mạo thì phần mềm này cũng phải đƣợc cài đặt bằng 1 phƣơng pháp an toàn (Ví dụ cài đặt bởi các kỹ thuật viên của cơ quan CA, hoặc phần mềm đƣợc chứng thực bởi kỹ thuật Code Signing).
Sau khi phần mềm đƣợc cài đặt, ngƣời sử dụng sẽ sử dụng phần mềm để khởi tạo chứng thƣ và gửi yêu cầu cấp phát chứng thƣ. Giao thức pháp hành chứng thƣ đƣợc mô tả trong hình 3.9, gồm các bƣớc sau đây:
Bƣớc 1: Ngƣời sử dụng nhập các thông tin cần thiết, bao gồm mã ngƣơi
sử dụng và mã xác thực RegCode. Sau đó bấm nút kích hoạt yêu cầu. Sau khi yêu cầu đƣợc kích hoạt, chƣơng trình sẽ sinh ra một mã ngẫu nhiên Key và một số khởi tạo IV. Chƣơng trình sử dụng khóa công khai của CA để mã hóa 3 thông tin RegCode, Key và IV, ta có thể viết E(PuCA,RegCode || Key || IV), sau đó truyền thông điệp : ID || E(PuCA, RegCode || Key || IV)
Khách hàng RA
1. Thông tin đăng ký phát hành chứng thƣ
2. Kiểm tra tính hợp lệ 3. Sinh mã xác thực
RegCode
4. Truyền mã RegCode bằng theo 1 kênh an toàn
Bƣớc 2: CA nhận đƣợc thông điệp kích hoạt từ phía Client. CA sẽ sử dụng khóa bí mật để giải mã các thông tin RegCode, Key và IV. Sau đó sẽ so sánh mã định danh ID và RegCode có hợp lệ không. Nếu không hợp lệ CA sẽ trả lại thông điệp DENY. Nếu hợp lệ Server sẽ sử dụng hệ mật mã AES và và khóa Key để mã hóa giá trị (IV + 1) và gửi lại cho
Client thông điệp: ACCEPT || EAES(Key, IV+1).
Bƣớc 3: Client nhận đƣợc thông điệp trả lời từ CA. Nếu là thông điệp từ
chối thì Client sẽ thông báo lại cho ngƣời sử dụng. Nếu nhận đƣợc thông điệp chấp nhận, client sẽ sử dụng khóa Key để giải mã ra giá trị (IV + 1). Đến bƣớc này, client có thể xác thực đƣợc CA dựa vào giá trị (IV+1).
Bƣớc 4: Client sẽ sinh ra cặp khóa bí mật và khóa công khai. Khóa bí mật sẽ đƣợc mã hóa bằng mật khẩu của ngƣời dùng. Khóa công khai sẽ đƣợc sử dụng để sinh ra thông điệp cấp phát chứng thƣ dƣới định dạng PKCS10 [19]. Sau đó PKCS10 và giá trị (IV+2) sẽ đƣợc mã hóa và gửi
cho CA : EAES(Key, PKCS10 || IV + 2)
Bƣớc 5 : CA nhận đƣợc thông điệp gửi trả lại từ phía Client, CA sử dụng
Key để giải mã và nhận đƣợc mã PKCS10. Đến đây, CA sẽ sử dụng khóa bí mật của mình để tạo chứng thƣ X.509 cho client. Sau đó gửi trả lại chứng thƣ đó cho Client. Đến đây chứng thƣ của ngƣời sử dụng chính thức có hiệu lực. Giao thức kết thúc.
Client CA
1. ID || E(PuCA, RegCode || Key || IV)
2. ACCEPT || EAES(Key, IV + 1)
3. Sinh khóa (Pr,Pu) và PKCS10 4. EAES(Key, PKCS10 || IV + 2)
5.Certificate
Hình 3.9 : Giao thức phát hành chứng thƣ
Comment [u31]: RSA Laboratories (2000) : PKCS#10 - Certification Request Syntax Standard
Ta hãy phân tích các thành phần thông điệp của giao thức chứng minh độ an toàn của giao thức:
Trong thông điệp thứ nhất, client gửi mã định danh và mã hóa các thông
tin RegCode, Key, IV bằng khóa công khai của CA. Do vậy chỉ CA mới có thể đọc đƣợc nội dung phần thông điệp đƣợc mã hóa. CA sẽ đối chiếu RegCode và ID để kiểm tra tính hợp lệ của yêu cầu phát hành chứng thƣ. Khóa Key có tác dụng là khóa phiên bí mật giữa Client và CA trong các phiên tiếp theo. IV là biến đếm đƣợc sử dụng kết hợp với khóa Key để Client xác thực CA. Đồng thời có tác dụng chống tấn công gửi lặp lại.
Trong giao thức phát hành chứng thƣ, mã RegCode đƣợc truyền bí mật
đối thủ không thể nghe lén đƣợc do đƣợc mã hóa bằng khóa công khai của CA. Sau khi chứng thƣ đƣợc phát hành thì mã RegCode cũng không còn tác dụng và có thể đƣợc hủy bỏ.
Trong thông điệp 4, thông điệp PKCS10 và giá trị (IV + 2) đƣợc bảo mật
bởi hệ mật mã AES với khóa là Key. Do vậy có thể chống đƣợc tấn công sửa đổi và tấng công gửi lặp lại.
3.3.4.2. Xác thực di động dựa trên chưng thư số sử dụng hệ mật mã ECC
Theo cuốn sách của William Stalling [32] chuẩn X.509 định nghĩa 3 giao thức xác thực khác nhau dựa trên hạ tầng khóa công khai có thể đƣợc áp dụng một cách tổng quát trên nhiều ứng dụng khác nhau. Giả sử Alice và Bob tham gia 1 phiên xác thực, Alice và Bob đều có đƣợc chứng thƣ số của nhau và các chứng thƣ số này đều đƣợc xác thực thông qua 1 tổ chức chứng thực.
3 giao thức xác thực đƣợc chuẩn X.509 định nghĩa gồm :
a. Giao thức xác thực một bƣớc
Giao thức xác thực một bƣớc đƣợc mô tả trong hình 3.10. Alice sẽ gửi cho Bob thông điệp M = tAlice || rAlice || IDBob || SigData || E(PUBob, KAB). Trong đó :
tAlice : Là nhãn thời gian của thông điệp đƣợc gửi bởi Alice, theo đó Bob sẽ xác định đƣợc hiệu lực thông điệp Alice gửi.
rAlice : Là một mã định danh duy nhất trong khoảng thời gian hiệu lực của thông điệp. Tham số định danh này cho phép Bob chống đƣợc tấn công gửi lại.
Comment [u32]: William Stalling (2005) “Cryptography and Network Security”, Prentice Hall Publisher, pp 426
IDBob : Định danh của Bob
SigData: Là chữ ký số của Alice trên 3 trƣờng trƣớc đó. Chữ ký số này cho phép Bob xác thực đƣợc Alice và đảm bảo đƣợc thông điệp M không bị tấn công sửa đổi.
KAB : Là thành phần tùy chọn, là khóa phiên giữa Alice và Bob, khóa phiên đƣợc bảo mật bằng cách sử dụng khóa công khai của Bob để mã hóa.
b. Giao thức xác thực hai bƣớc
Giao thức xác thực hai bƣớc đƣợc phát triển mở rộng từ giao thức xác thực một bƣớc. Hình 3.11 mô tả giao thức xác thực hai bƣớc, ta nhân thấy ở bƣớc thứ nhất tƣơng tự với bƣớc 1 ở giao thức xác thực một bƣớc. Thông điệp ở bƣớc thứ hai do Bob gửi Alice có dạng: tBob || rBob || IDAlice || rAlice || SigData || E(PUAlice, KBA).
Hình 3.10a: Giao thức xác thực một bƣớc
Alice Bob
1. tAlice || rAlice || IDBob || SigData || E(PUBob, KAB)
2. tBob || rBob || IDAlice || rAlice || SigData || E(PUAlice, KBA)
Alice Bob
1. tAlice || rAlice || IDBob || SigData || E(PUBob, KAB)
Các thành phần của thông điệp thứ 2 Bob gửi cho Alice có ý nghĩa tƣơng tự
nhƣ ở thông điệp 1. Chỉ có khác là trong thông điệp 2, Bob gửi trả lại tham số rAlice
cho Alice. Tham số nay nhằm mục đích định danh thông điệp Bob gửi là trả lời cho thông điệp Alice gửi trƣớc đó.
c. Giao thức xác thực ba bƣớc
Tƣơng tự giao thức xác thực hai bƣớc, giao thức xác thực 3 bƣớc đƣợc phát triển mở rộng từ giao thức xác thực 2 bƣớc. 2 thông điệp đầu của giao thức này giống với 2 thông điệp của giao thức xác thực 2 bƣơc.
Thông điệp thứ 3 Alice gửi cho Bob là : rBob. Việc trả lại tham số rBob để Bob không cần kiểm tra lại nhãn thời gian. Bởi vì các tham số rAlice và rBob đƣợc đƣợc gửi 2 lần theo chiều xuôi và chiều ngƣợc lại, do vậy giúp cho Alice và Bob có thể kiểm tra và phòng chống tấn công lặp lại. Việc này là cần thiết khi đồng hồ của Bob và Alice là không đƣợc đảm bảo là đồng bộ.
3.3.5. Kết quả
3.3.5.1. Thiết kế chương trình
Để mô phỏng giao thức cấp phát chứng thƣ số dành cho điện thoại di động, học viên đã xây dựng 1 chƣơng trình theo mô hình Client – Server. Trong đó :
Client đóng vai trò là chiếc điện thoại di động khách, đƣợc triển khai bằng công nghệ J2ME đƣợc chay mô phỏng trên công cụ Wireless
Alice Bob
1. tAlice || rAlice || IDBob || SigData || E(PUBob, KAB)
2. tBob || rBob || IDAlice || rAlice || SigData || E(PUAlice, KBA)
3. rBob
Toolkit 3.0. Để phục vụ cho các thao tác mật mã, học viên có sử dụng thƣ viện mã nguồn mở Bouncy Castle phiên bản trên di động.
Server: Đóng vai trò nhƣ CA, cung cấp dịch vụ phát hành chứng thƣ cho
phía máy khách. Server đƣợc xây dựng dựa trên công nghệ Java, sử dụng thƣ viện mã nguồn mở Bouncy Caslte phục vụ cho các thao tác mật mã.
Môi trƣờng truyền thông : Client sẽ sử dụng dịch vụ GPRS hoặc dịch vụ
3G để kết nối Socket tới CA. Tất cả các thông điệp trao đổi giữa Client và CA đều đƣợc truyền qua kết nối Socket.
3.3.5.2. Các bước thực hiện
Trƣớc tiên, để Server có thể đóng vai trò là 1 CA, Server sẽ phải sinh một cặp khóa gồm khóa bí mật và khóa công khai. Sau đó Server sẽ thực hiện tự sinh 1 chứng thƣ cho chính bản thân bằng cách lấy khóa bí mật ký xác nhận cho chứng thƣ đƣợc sinh ra. Sau khi hoàn tất bƣớc này, Server sẽ sở hữu 1 chứng thƣ số và khóa bí mật đƣợc sử dụng để phát hành các chứng thƣ sau này của Client. Mã nguồn việc sinh khóa và việc tự ký của CA đƣợc trích dẫn trong phần phụ lục.
Sau đó Server CA sẽ chạy 1 dịch vụ để phục vụ việc cấp phát chứng thƣ từ các máy khách. Để đơn giản hóa việc thực thi, học viên thiết kế Server chấp nhận tất cả các yêu cầu cấp phát chứng thƣ với bất cứ mã ID và RegCode nào đƣợc gửi từ phía Client.
Phía Client, ngƣời sử dụng sẽ điền các thông tin về chứng thƣ của mình, sau đó sẽ kích hoạt giao thức phát hành chứng thƣ. Client và server thực thi giao thức đƣợc đặc tả trong mục 3.3.4.1b
Hình 3.11a: Chứng thƣ của CA
Hình 3.11c: Thuật toán ký của CA
Hình 3.11e: Form điền thông tin cấp yêu cầu phát chứng thƣ
Hình 3.11g: Thuật toán ký số của CA trên chứng thƣ phát hành
3.3.5.3. Đánh giá hiệu năng của hệ mật mã ECC
Việc đánh giá hiệu năng của hệ mật mã ECC đã có rất nhiều công trình nghiên cứu đã chứng minh rằng hệ mật mã ECC nhanh và hiệu quả hơn so với hệ mật mã RSA trên ở cùng 1 cấp độ an toàn. Do vậy trong luận văn, học viên sẽ không đi vào tính toán và đánh giá lại hiệu năng của hệ mật mã ECC so với hệ mật mã RSA. Tuy nhiên để có thể thấy rõ đƣợc sự khác biệt về hiệu suất giữa hệ mật mã ECC và RSA, học viên xin trích lại kết quả nghiên cứu đƣợc công bố với công ty Certicom – Công ty nghiên cứu hàng đầu về hệ mật mã ECC – đƣợc công bố năm 2005 [21]
ECC keysize RSA keysize Symmetric keysize ECDSA Sign (Sigs/min) RSA Sig (Sigs/min) ECC benefit
224 bit 2048 bit 3DES-112 105840 2940 3600%
256 bit 3072 bit AES-128 54000 480 11250%
384 bit 7680 bit AES-192 30960 60 51600%
512 bit 15360 bit AES-256 14400 60 24000%
ECC keysize RSA keysize Symmetric keysize ECDSA Verify (Vef/min) RSA Verify (Vef/min) ECC benefit
224 bit 2048 bit 3DES-112 47520 26880 117%
256 bit 3072 bit AES-128 22800 11280 202%
384 bit 7680 bit AES-192 11040 2160 511%
512 bit 15360 bit AES-256 5280 480 1100%
Hai bảng so sánh 3.5a và 3.5b cho ta một cái nhìn trực quan về hiệu suất giữa hệ mật mã ECC và RSA. Ta nhận thấy, ở cùng 1 độ an toàn, độ dài khóa của RSA tăng nhanh hơn so với độ dài khóa của ECC. Hơn nữa tốc độ thực hiện (Ký – Xác thực trong một phút) của RSA cũng giảm nhanh hơn so với ECC.
Bảng 3.5a : So sánh tốc độ ký giữa hệ mật mã ECC và RSA
Hình 3.5b: So sanh tốc độ xác thực giữa hệ mật mã ECC và RSA
Comment [u33]: Scott Vanstone (2005) : “An introduction to use of ECC-based certificates”. Code and Cipher vol2, no2. pp -3
3.4. Kết luận chƣơng 3
Trong chƣơng 3, với mục đích nghiên cứu phƣơng pháp xác thực phù hợp đối với các thiết bị vô tuyến có hạn chế về năng lực tính toán và tài nguyên bộ nhớ. Luận văn đã giới thiệu nghiên cứu hệ mã hóa đƣờng cong Elliptic, cơ sở toán học đề xây dựng hệ mật mã ECC, các dịch vụ an ninh, các thuật toán thực thi trong hệ mật mã ECC.
Với những ƣu điểm của hệ mật mã ECC, trong phần cuối của chƣơng, học viên đã đề xuất khả năng xây dựng hạ tầng khóa công khai cho nền tảng di động dựa trên hệ mật mã ECC. Để hiện thực hóa, học viên đã thiết kế giao thức và triển khai ứng dụng cấp phát chứng thƣ cho thiết bị di động
Tổng kết và hƣớng nghiên cứu tiếp theo
Trong luận văn của mình, xuất phát từ những tồn tại trong vấn đề xác thực của