Do giao diện với các thiết bị mật mã, Cryptoki cung cấp một cơ sở cho an ninh trong hệ thống truyền thông và máy tính. Hai đặc tính cụ thể này của giao diện mà nó cung cấp cho an ninh như sau:
1.Truy xuất tới các đối tượng riêng trên Token, và có thể với các hàm mật và và/hoặc cũng như các chứng thư số, đòi hỏi một PIN. Do đó xử lý thiết bị mật mã mà triểnkhai Token có thể không đủ để sử dụng nó, PIN cũng có thể cần thiết. 2.Bảo vệ bổ xung có thể được cung cấp cho các khóa riêng và các khóa bí mật bằng cách đánh dầu “nhậy cảm” hoặc “không thể chiết xuất”. Các khóa nhậy cảm không thể bị phơi ra dưới dạng bản rõ ký tự ngoài token, và các khóa không thể chiết xuất không thể bị phơi ra khỏi Token ngay cả khi mã hóa.
Người ta kỳ vọng rằng việc truy xuất tời các đối tượng riêng, nhậy cảm, hoặc không thể chiến xuất bởi các hình thức khác hơn là Cryptoki sẽ rất khó khăn.
Nếu một thiết bị không có môi trường bảo đảm chống trộm hoặc bộ nhớ được bảo vệ trong nó để lưu trữ các đối tượng riêng và nhậy cảm, thiết bị có thể mã hóa các đối tượng với khóa chính nó có thể phát sinh từ PIN của người dùng. Dựa trên các đặc tính này có thể thiết kế các ứng dụng theo cách mà token có thể cung cấp an ninh phù hợp cho các đối tượng các ứng dụng quản lý.
Tất nhiên, ngành mật mã chỉ là một phần tử của an ninh, và token chỉ là một thành phần của một hệ thống. Trong khi Token tự nó có thể an toàn, một người cũng cần
51
phải xem xét vấn đề an ninh của hệ điều hành mà ứng dụng giao tiếp với nó, đặc biệt do PIN có thể dược chuyển qua hệ điều hành. Dễ dàng để Một ứng dụng lừa đảo trên hệ điều hành có thể lấy được PIN. Cũng có thể các thiết bị
khác giám sát kênh giao tiếp tới thiết bị mật mã có thể lấy được PIN. Các ứng dúng dụng lừa đảo và thiết bị có thể thay đồi các lệnh điều khiên được gửi tới thiết bị mật mã để lấy các dịch vụ hơn là cái mà ứng dụng yêu cầu.
Cần thiết phải đảm bảo rằng hệ thống là an toàn trước những tấn công như trên. Ví dụ Cryptoki cũng có thể đóng một vai trò ở đây, một token có thể được gắn vào trong việc khởi động của một hệ thống.
Chúng tôi lưu ý rằng không có cuộc tân công được mô tả có thể làm tổn hại đến các khóa được đánh dấu “Nhậy cảm”, do một khóa mà nó là nhậy cảm sẽ luôn
ở trạng thái nhậy cảm. Tương tự như vậy, một khóa mà nó không thể bị chiết xuất không thểđược thay đổi để chiết xuất.
Một ứng dụng cũng có thể muốn được đảm bảo rằng Token là xác thực ở một số
mặt (Vì những lý do đa dạng, bao gồm những hạn chế xuất và an ninh cơ bản). Điều này ngoài phạm vi của chuẩn này, nhưng nó có thể đạt được bằng cách phân phối token được đóng gói, chứng nhận cặp khóa Công khai/riêng, bằng cách đó Token có thể chứng minh tính toàn vẹn của nó. Chứng nhận có thể được ký bởi một đơn vị chức trách khóa công khai của họ được biết với ứng dụng. Ứng dụng sẽ kiểm tra chứng nhận và đánh giá token để chứng minh tính toàn vẹn của nó bằng cách ký một thông điệm thay đổi theo thời gian với khóa riêng đi kèm của nó.
Một khi người dùng thông thường được xác thực vào token, Cryptoki sẽ không hạn chế loại phép toán mật mã nào mà người dùng có thể thực hiện; người dùng có thể thực hiện bất kỳ một phép toán nào được hỗ trợ bởi Token. Một số Token thậm chí có thể không yêu cầu bất kỳ một loại xác thực nào để sẻ dụng dụng các hàm mật mã của nó.
52
Chương 3. PHÂN TÍCH THIẾT KẾ CÁC ỨNG DỤNG CHỮ KÝ SỐ TRÊN MOBILE.
3.1. THÀNH PHẦN KIẾN TRÚC ỨNG DỤNG.
Để triển khai các sản phẩm ứng dụng chữ ký số trên trên thiết bị di động cần phải trả lời ba câu hỏi vô cùng quan trọng là dùng cái gì để lưu trữ chữ ký số đảm bảo bảo mật, ứng dụng gì để dùng chữ ký số, và mở thị trường chữ ký số
trên thiết bị di động thế nào.
Đối với việc sử dụng chữ ký số trên các máy tính thông thường sẽ có các thiết bị lưu trữ chữ ký số chuyên dụng và cắm vào các máy tính qua các đầu giao tiếp USB để thực hiện các giao thức chữ ký số. Tuy nhiên đối với thiết bị cầm tay, các thiết bị để giao tiếp này chưa phổ biết, các ứng dụng trên thiết bị cầm tay cũng chưa phổ
biến. Hiện tại trên thị trường đã cung cấp một số thiết bị lưu trữ chữ ký số giao tiếp với thiết bị cậm tay qua cổng Audio, hoặc gắn kèm vào Sim hoặc. Tuy nhiên các thiết bị này thường chi phí cũng khá đắt, và việc sử dụng không được tiện dụng, với thiết bị cắm qua cổng Audio hiện tại độ ổn định còn rất thấp, các thiết bị trên Sim có thể nói nền tảng ứng dụng rất hiểm và khó dùng.
Đối với nền tảng ứng dụng, thực ra ai cũng mong muôn và kỳ vọng mở thị trường chữ ký số sử dụng cho lĩnh vực ngân hàng chứng khoán, vì nó đáp ứng được tất cả các yêu cầu của ngân hàng. Tuy nhiên đảm bảo thế nào để thực sự tiện lợi thì rất khó khăn. Nếu cố gắng đặt chân thẳng vào các thị trường chứng khoán, ngân hàng, thương mại điện tử ngay thì sẽ khó có bước chân phù hợp, vậy cách đặt chân nên từng bước mở sang những gì quen thuộc mà người dùng có thể dùng luôn để đảm bảo bước đầu xác lập tính quen thuộc, khả dụng ngay cho người dùng đồng thời từng bước mở ra thị trường.
Trên những cơ sở đặt vấn đề như thế, tôi quyết định lựa chọn thành phần kiến trúc sản phẩm của hệ thống sản phẩm Mobile PKI ban đầu như sau:
53
Signing App
Secured Email Client App
Hình 3.1: Kiến trúc thành phần
PKI Soft Token App: Ở đây để giải quyết các yêu cầu trên tôi thiết kế PKI Soft Token, đây là một ứng dụng phần mềm được thiết kế đi kèm với duy nhất mỗi thiết bị phần cứng. Chúng tôi thiết kế đảm bảo không thể sao chép và các lớp bảo mật giống như một thiết bị phần cứng. Chính vì vậy các chuẩn công nghiệp phục vụ
xây dựng thiết bị phần cứng sẽ được áp dụng và ánh xạ vào thiết bị phần mềm. Việc xây dựng này chúng tôi thực hiện nó tuân theo chuẩn thiết kế và triển khai công nghiệp của thiết bị phần cứng trong việc cung cấp và giao tiếp với các hệ
thống ứng dụng và thiết bị bên ngoài là PKCS#11. Đối với chuẩn thành phần kiến trúc và lưu trữ tất cả các thành phần chữ ký số cũng phải được kiểm soát và lưu trữ
bảo mật tôi thiết kế theo chuẩn công nghiệp PKCS#15.
Secured SMS App: Đây là ứng dụng còn tương đối thuần nguyên thủy về chữ ký số,
ứng dụng này sẽ không đóng gói chữ ký số theo chuẩn, mà ở đây đơn giản chỉ đóng
54
gói binary bình thường, chúng tôi thực hiện các lược đồ mã hóa và giải mã theo lược đồ chữ ký số RSA thông thường. Và ở đây với ứng dụng viết tôi triển khai phần thuần mã hóa và giải mã.
Secured Email Client App: Trong phạm vi triển khai của đề tài, ứng dụng này tôi thuần triển khai phần mã hóa, giải mã, ký số email và đóng gói các dữ liệu này theo đúng chuẩn PKCS#7 để đáp ứng tương xứng với các loại email. Các
ứng dụng phát triển tạo thành một bộ Email hoàn chỉnh cá nhân đã không tham gia nhiều, mà chỉ đảm bảo sao cho nó hoàn toàn chạy chau chuốt và tốt nhất với chức năng mình phát triển.
Signing Apps: Phần ký các ứng dụng trên nền Android và IOS không hề đơn giản với các ứng dụng phục vụ PDF và Ofice. Việc triển khai này đã mất hàng năm trời để tạo ra được các ứng dụng ký số, đóng gói hoàn chỉnh, sau đó áp dụn vào các tài liệu trên.
3.2. THIẾT KẾ CÁC MÔ HÌNH MẬT MÃ VÀ CHỮ KÝ SỐ3.2.1. Mật mã bất đối xứng và đối xứng kế hợp 3.2.1. Mật mã bất đối xứng và đối xứng kế hợp
Mô hình này được dùng trong việc mã hóa và giải mã Email và SMS. Đồng thời nó còn được dùng trong một số mô hình thiết kế để phục vụ mã hóa các dữ
liệu lớn trong các hệ thống, cũng như được sử dụng mã hóa và giải mã trong các hệ máy tính cá nhân để mã hóa giải mã cả một thư mục hoặc ổ đĩa.
55
Hình 3.2: Mô hình mật kết hợp để thực hiện bảo mật dữ liệu
B1: Hệ thống tự sinh một khóa đối xứng.
B2: Dùng khóa đối xứng để mã hóa dữ liệu.
B3: Dùng khóa bất đối xứng của chứng thư số của người nhận để mã hóa dữ liệu. B4: Gửi giao dịch về người nhận.
B5: Dữ liệu giao dịch ở phía người nhận sẽ được tách ra, dùng khóa riêng của người nhận để thực hiện việc giải mã khóa đối xứng.
B6: Dùng khóa đối xứng đã được giải mã để giải mã dữ liệu.
56
3.2.2. Mô hình sử dụng hạ tầng mã khóa công khai để đăng nhập hệ thống.
Hình 3.3: Mô hình đăng nhập hệ thống dùng chữ ký số
B1: Yêu cầu truy xuất hệ thống B2: Server sinh số ngẫu nhiên
B3: Gửi số ngẫu nhiên về phía Client B4: Hash số ngẫu nhiên.
B5: Lựa chọn chứng thư số
B6: Nhập password để xác thực truy xuất Private key của token. B7: Ký số giá trị Hash ở B4.
B8: Gửi về server.
B9: Dùng chứng thư số giải mã dữ liệu.
57
B10: Đưa số ngẫu nhiên trên server qua hàm Hash
B11: So sánh dữ liệu ở B9 và B10, nếu hai giá trị bằng nhau thì cho truy xuất.
3.2.3. Ký dữ liệu
Hình 3.4: Mô hình ký, kiểm tra trạng thái chứng thư số trong thực tế B1: Người dùng nhập dữ liệu giao dịch.
B2: Hệ thống tổng hợp dữ liệu đưa vào hàm ký.
B3: Lựa chọn chứng thư số từ trong token. B4: Nhập số Pin.
B5. Hệ thống thực hiện Hash dữ liệu đã tổng hợp, và ký vào dữ liệu đã tổng hợp. B6: Gửi dữ liệu ký qua mạng.
B7: Khi đến phía server dữ liệu sẽ được tách làm hai phần chữ ký và dữ liệu. 58
B8: Hash dữ liệu với hàm Hash đã dùng ở phía Client để kiểm tra chữ ký số. B9: Nếu chữ ký là hợp lệ, hệ thống sẽ thực hiện giao dịch và lưu vào CSDL.
3.2.4. Mô hình xác thực chữ ký số
Đây là mô hình triển khai mang tính chất một hệ thống Server, dữ liệu tổng hợp dưới dạng Binary.
Hình 3.5: Mô hình kiểm tra chữ ký số tổng thể
B1: Người nhận yêu cầu kiểm tra chữ ký số từ hệ thống server hoặc từ chính
ứng dụng người dụng.
B2: Hệ thống tổng hợp dữ liệu mà người nhận nhận được để Hash dữ liệu. B3: Lấy chữ ký số ứng với dữ liệu người nhận.
B4: So sánh dữ liệu ở B2, B3, nếu nó khớp nhau thì là ký số hiệu lực.
59
3.3. THIẾT KẾ CHỨC NĂNG
3.3.1. Thiết kế chức năng cho Soft Token
Sinh số nguyên tố lớn
Sinh khóa theo RSA, DSA, ECC...
SOFT TOKEN
Mã hóa và lưu trữ khóa
Xử lý các thuật toán ký số, mã hóa
Hình 3.6: Chức năng Soft Token
Soft token cho phép người dùng cuối sử dụng Chứng thư số của mình một cách dễ dàng và an toàn ngay trên mobile mà không phải mua thêm (hoặc đổi) bất kỳ một phần cứng nào. Tôi đặt vấn đề bảo mật của Soft token lên hàng đầu. Soft token được thiết kế tuân theo các chuẩn PKCS#15 và PKCS#11 của thế giới; các thông tin trong soft token được mã hóa và lưu an toàn bằng các thuật toán mã hóa mạnh (AES256) đảm bảo chỉ có người sở hữu chứng thư có thể truy cập được. Các bước đăng ký chứng thư, cài đặt chứng thư và kích hoạt soft token cũng được tích hợp cùng với ứng dụng quản lý soft token giúp người dùng có thể dễ dàng đăng ký và sử dụng được sản phẩm soft token và dịch vụ chứng thực số của VNPT ngay trên chính điện thoại di động của mình.
60
3.3.2. Thiết kế chức năng cho Secured SMS.
Là ứng dụng cho phép người dùng bảo mật các tin nhắn SMS bằng cách mã hóa nội dụng trước khi gửi đi. Ứng dụng sử dụng chứng thư số của VNPT để
thực hiện quá trình mã hóa này. Điều này đảm bảo chỉ duy nhất người nhận với mã PIN của Token (Soft và Hard) mới có thể đọc được nội dung SMS này, đối với người thứ 3 kể cả nhà mạng, đó chỉ là những chuỗi ký tự vô nghĩa.
3.3.3. Thiết kế chức năn cho Secured Email Client.
Dùng nhiều tài khoản online cùng lúc Hỗ trợ nhiều định dạng mail Email Client Mã hóa / Giải mã e- mail Tương thích với các
SMIME mail client khác
Hình 3.7: Chức năng Email Client
Ứng dụng Email Client của VNPT/VDC có tính sẵn sàng cao, cho phép người dùng có thể cài đặt nhiều hòm mail cùng lúc, hỗ trợ nhiều loại mail như: Gmail, VDC,
Yahoo, Outlook…
3.3.4. Thiết kế chức năng cho Signing App.
Mobile Signtool là ứng dụng cho phép người dùng thực hiện ký số các tài liệu Ofice và PDF với khóa bí mật và chứng thư số từ Token. Các chuẩn ký số tài liệu này tương
61
thích với Microsoft Office và Acrobat Reader hay Foxit Reader. Đây là ứng dụng có
ý nghĩa tích hợp rất lớn vào các hệ thống e-Ofice của các doanh nghiệp.
3.4. THIẾT KẾ KIẾN TRÚC
3.4.1. Kiến trúc Mobile PKI Soft Token App a. Kiến trúc dữ liệu của Soft Token App a. Kiến trúc dữ liệu của Soft Token
Hình 3.8: Kiến trúc của Soft Token
Kiến trúc dữ liệu của Soft token tuân thủ chặt chẽ chuẩn PKCS#15. Dữ liệu được chia và lưu trữ theo từng Object, mỗi object có một Handle tương ứng. Handle này có thể hiểu là giá trị để đánh chỉ mục và định danh cho Object bên trong Token.
Có 4 kiểu dữ liệu bên trong Soft token: Data, Key, Certifcate và Authentication Object. Các loại dữ liệu này được lưu trữdưới dạng cây thư mục như hình trên. Việc truy xuất các dữ liệu này hoàn toàn theo chuẩn PKCS#11.
b. Các chuẩn và thư viện sử dụng cho Soft token
- Chuẩn PKCS#15: Đây là tiêu chuẩn do phòng thí nghiệm RSA đặt ra. PKCS#15
quy định cách thức, quy tắc lưu trữ dữ liệu số (Object) bên trong Token hay Smart Card, đồng thời quy định cách thức truy cập vào các dữ liệu số này.
-Chuẩn PKCS#11: Tiêu chuẩn này quy định một bộ công cụ phát triển (API), được gọi là Cryptoki, dành cho các thiết bị lưu trữ bảo mật như Token hay SmartCard.
62
- Thư viện OpenSSL: Thư viện mã hóa được viết bằng ngôn ngữ C. - Thư viện Botan: Thư viện mã hóa được viết bằng ngôn ngữ C++.
3.4.2. Kiến trúc Secured SMS Appa. Kiến trúc tổng quan a. Kiến trúc tổng quan UI View Contact Cert Store WebService
PKCS#11 Wrapper Crypto Libs
Hình 3.9: Kiến trúc tổng quan của Secured SMS
Vì phải dùng Token (Soft và Hard) để đăng nhập vào phần mềm và để lấy khóa bí mật thực hiện việc giải mã nội dung, do đó SecureSMS yêu cầu phải có lớp PKCS#11 Wrapper.
Crypto Libs thực hiện các công việc như: sinh cặp khóa đối xứng, mã hóa tin nhắn SMS với chứng thư số của người nhận, giải mã nội dung với khóa bí mật của người sử dụng.
Lớp Contact thực hiện việc đồng bộ hóa danh bạ, lấy chứng thư số của những người đang sử dụng SecureSMS. Các chứng thư số này được lưu trữ trong Cert Store và cả trên hệ thống máy chủ của VDC.