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.
b. Quy trình giải mã và mã hóa SMS
• Mã hóa
63
Compos e SMS
Hình 3.10: Quy trình mã hóa
Qúa trình mã hóa SMS yêu cầu người dùng cung cấp đầy đủ: Nội dung SMS và số điện thoại của người nhận. Ứng dụng sẽ kiểm tra và lấy chứng thư số tương ứng với số điện thoại đã cung cấp từ Cert Store và máy chủ qua các Web-service. Nếu không có chứng thư số tương ứng, quá trình mã hóa không thể thực hiện, người dùng chỉ có thể gửi SMS bình thường.
• Giải mã
Encrypted Encrypted Send Clear
SMS Content SMS Content
Get User s
PIN code Private Private
key Key
Hình 3.11: Quy trình giải mã
Quá trình giải mã cần đến khóa bí mật của người dùng, do đó cần cung cấp chính xác mã PIN của Token cho ứng dụng. Để đảm bảo tính bảo mật, mỗi lần đọc nội dung đã
mã hóa đều cần nhập mã PIN, kể cả nội dung đã giải mã trước đó.
c. Các chuẩn và thư viện áp dụng
- PKCS#11: bộ API giao tiếp với Token và SmartCard.
- OpenSSL: thư viện mã hóa mã nguồn mở thực thi các giao thức SSL/TLS, được viết bằng ngôn ngữ C.
- Bouncy Castle: thư viện mã hóa mã nguồn mở được viết bằng ngôn ngữ
Java.
- DroidSMS: ứng dụng quản lý SMS mã nguồn mở cho Android.
3.4.3. Kiến trúc Secured Email Client App a. Kiến trúc phần mềm App a. Kiến trúc phần mềm
Contact
PKCS#11 Wrapper
Hình 3.12: Kiến trúc của Secured Email Client
Kiến trúc phần mềm được thiết kế phân tách nhiều lớp độc lập, để có thể hoạt động linh hoạt, dễ dàng phát triển và triển khai.
- Mail Core là tầng thấp nhất trong phần mềm, xử lý các tác vụ lấy email, phân tích và gửi email.
-PKCS#11 Wrapper và Crypto Libs là các thư viện thực hiện kết nối Token và thực hiện các quá trình mã hóa, xác thực email.
- Contact cho phép ứng dụng quản lý danh bạ, chứng thư số trong danh bạ và Apptentive Connect có nhiệm vụ kết nối ứng dụng với AppStore, Google Play Store, feedback nhà phát triển.
b. Quy trình tạo email SMIME của phần mềm
Tiêu đề
Soạn
Nội dung
Hình 3.13: Quy trình tạo Email
Ứng dụng khi ký số hay mã hóa email chỉ thực hiện với phần Nội dung của email, bao gồm cả các tệp đính kèm. Vì vậy cần tách nội dung theo chuẩn MIME để thực hiện quy trình này.
Tiêu đề Nội dung Cert Crypto Store, libs, Web PKCS#11 Service Wrapper
Hình 3.14: Quy trình mã hóa Email
Nếu thực hiện mã hóa, ứng dụng bắt buộc phải có chứng thư số của người nhận, lớp Cert Store lưu trữ các chứng thư số này và lớp Web Service thực hiện đồng bộ danhbạ và các chứng thư số giữa ứng dụng và Server đặt tại VDC. Quy trình ký số yêu cầu ứng dụng phải giao tiếp với Token (Soft hoặc Hard), lớp PKCS#11 Wrapper thực hiện chức năng giao tiếp này. Người dùng cung cấp mã PIN để lớp Wrapper lấy khóa bí mật thực hiện ký số hoặc giải mã các email. Chữ ký số cho email phải theo đúng chuẩn PKCS#7 trước khi chèn Header và đóng gói toàn bộ theo chuẩn SMIME trước khi gửi đi.
c. Các chuẩn và thư viện áp dụng
- MIME: chuẩn định dạng cho thư điện tử khi truyền qua Internet - S/MIME: chuẩn mã hóa và ký số cho thư điện tử MIME
- PKCS#11: bộ API giao tiếp với Token và SmartCard - PKCS#7: chuẩn định dạng tin nhắn mã hóa
- OpenSSL: thư viện mã hóa mã nguồn mở thực thi các giao thức SSL/TLS, được viết bằng ngôn ngữ C.
- Bouncy Castle: thư viện mã hóa mã nguồn mở được viết bằng ngôn ngữ
Java.
- SMTP, IMAP: các giao thức gửi nhận email.
- K-9 Mail: ứng dụng Mail Client mã nguồn mở cho Android. - Mailcore2: thư viện xử lý email mã nguồn mở cho iOS.
3.4.4. Kiến trúc Signing Apps
a. Kiến trúc tổng quan
UI View
OOXML Lib PDF Lib
PKCS#11 Wrapper Crypto Libs
Hình 3.15: Mô hình kiến trúc Signing Apps
Tương tự với 2 ứng dụng trên, Secure Mail và Secure SMS, Signtool cũng cần kết nối với Token (Soft hoặc Hard) qua lớp PKCS#11 Wrapper. Cũng cần các thư viện mã hóa như OpenSSL và BouncyCastle trong lớp Crypto Libs để thực hiện các chức năng ký số.
Lớp các thư viện OOXML Lib và PDF Lib cho phép ứng dụng phân tích và đóng gói các tài liệu OOXML (Ofice là một trong số đó) và PDF, lấy ra các thông tin cần thiết để tạo chữ ký số.
b. Các chuẩn và thư viện áp dụng
- PKCS#11: Bộ API giao tiếp với Token và SmartCard.
- PKCS#1 : Chuẩn cung cấp các định nghĩa, khuyến nghị cơ bản để thực hiện thuật toán RSA cho mã hóa công khai.
- PKCS#7: Chuẩn định dạng tin nhắn mã hóa.
- OOXML: Open Ofice XML, chuẩn định dạng dữ liệu của Microsoft cho các tài liệu Office: Word, Excel, PowerPoint,…
- Bouncy Castle: thư viện mã hóa mã nguồn mở được viết bằng ngôn ngữ
Java.
KẾT LUẬN
5.1. NHỮNG CÔNG VIỆC MÀ LUẬN VĂN ĐÃ ĐẠT ĐƯỢC
Luận văn này với mục tiêu nghiên cứu và ứng dụng lý thuyết cũng như các chuẩn công nghiệp được chấp nhận toàn cầu vào lĩnh vực chữ ký số để áp dụng vào thực tiễn trển khai trên các thiết bị cầm tay. Xét về mặt kết quả tổng quan, Luận văn đã đưa ra được các:
- Nghiên cứu tổng quan về chữ ký số.
- Nghiên cứu tình hình triển khai chữ ký số tổng quan trong nước và quốc tế.
- Nghiên cứu lý thuyết cơ sở về chữ ký số.
- Nghiên cứu các chuẩn công nghiệp về chữ ký số.
- Phát triển các ứng dụng chữ ký số nhằm tương tác với thiết bị cầm tay tương đương với việc ứng dụng chữ ký số đang được sử dụng trên máy tính thông thường.
5.2. KHẢ NĂNG PHÁT TRIỂN CỦA LUẬN VĂN
Luận văn này dựa trên nghiên cứu cơ sở lý thuyết, thực tiễn phát triển và ứng dụng chữ ký số, mở sang một nền tảng áp dụng sản phẩm chữ ký số trên thiết bị cầm tay. Trên cơ sở thực tế của Luận văn sẽ có nhiều cơ sở để thúc đẩy thị trường chữ ký số trên thiết bị cầm tay, đảm đảm an ninh thông tin trên thiết bị cầm tay. Và chính trên nền tảng mở ra nền tảng ứng dụng chữ ký số trên thiết bị cầm tay được áp dụng trong mọi giao dịch điện tử, và đây cũng là hướng phát triển tương lai thực sự
của Luận văn để mở sang một kỳ vọng cho tương lai là mọi giao dịch thực hiện được trên nềntảng điện tử hoàn toàn mà vẫn đảm bảo tin cậy, xác thực, bảo mật.
TÀI LIỆU THAM KHẢO
1. OASIS TC Administration (2013), PKCS #11 Cryptographic Token Interface Base Specification Version 2.40, 90-150
2. RSA Laboratories (2012), PKCS #1 v2.3: RSA Cryptography Standard, 26-63
3. RSA Laboratories (2012), PKCS #7: Cryptographic Message Syntax Standard, 20-100
4. RSA Laboratories (2012), PKCS #15: Cryptographic Token Information Format Standard, 20-100
70