TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

LUẬN VĂN THẠC SĨ

KÝ SỐ TỪ XA VÀ ỨNG DỤNG
NGUYỄN DUY GIANG
duygiangdg@gmail.com

Ngành Toán Tin

Giảng viên hướng dẫn: TS. Vũ Thành Nam

Chữ ký của GVHD

Viện: Toán ứng dụng và Tin học

HÀ NỘI, 12/2021
 CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập – Tự do – Hạnh phúc

BẢN XÁC NHẬN CHỈNH SỬA LUẬN VĂN THẠC SĨ

Họ và tên tác giả luận văn: Nguyễn Duy Giang

Đề tài luận văn: Ký số từ xa và ứng dụng

Chuyên ngành: Toán Tin

Mã số SV: CB190315

Tác giả, Người hướng dẫn khoa học và Hội đồng chấm luận văn xác nhận tác
giả đã sửa chữa, bổ sung luận văn theo biên bản họp Hội đồng ngày 18/12/2021
với các nội dung sau:

• Căn chỉnh định dạng bảng biểu.

• Thêm tài liệu tham khảo cho một số hình ảnh, trích dẫn.

Ngày 16 tháng 01 năm 2022

Giáo viên hướng dẫn Tác giả luận văn

CHỦ TỊCH HỘI ĐỒNG

1
 ĐỀ TÀI LUẬN VĂN

KÝ SỐ TỪ XA VÀ ỨNG DỤNG

Giáo viên hướng dẫn

Ký và ghi rõ họ tên

2
 LỜI CẢM ƠN

Lời đầu tiên, tôi xin bày tỏ lòng biết ơn sâu sắc tới TS. Vũ Thành Nam, trưởng
bộ môn Toán Tin trường Đại học Bách Khoa Hà Nội, đã giúp đỡ tôi rất nhiều trong
quá trình tìm kiếm tài liệu cũng như hoàn thành luận văn này. Sự chỉ bảo tận tình
của thày trong quá trình nghiên cứu để hoàn thiện những ý tưởng ban đầu cho đến
khi luận văn được hoàn thành là trợ giúp rất lớn đối với tôi.

Tiếp theo, tôi xin bày tỏ lòng biết ơn chân thành tới toàn thể các thầy cô giáo
trong bộ môn Toán Tin, viện Toán Ứng dụng và Tin học, Đại Học Bách Khoa Hà
Nội đã nhiệt tình hướng dẫn, giải đáp các thắc mắc.

Tôi cũng xin cảm ơn các bạn học cùng lớp Cao học Toán Tin 2019B, các anh
chị, bạn bè, đồng nghiệp của tôi đã có những đóng góp giúp tôi có thể hoàn chỉnh
luận văn này.

Cuối cùng tôi xin gửi lời cảm ơn gia đình tôi, những người đã luôn ở bên
cạnh động viên, ủng hộ tôi rất nhiều trong quá trình học và hoàn thiện luận văn.

Luận văn của tôi còn có nhiều thiếu sót, rất mong nhận được những ý kiến
đóng góp từ các thầy, cô, cũng như từ các bạn đồng nghiệp để có thể hoàn thiện
kiến thức của mình, cũng như tiếp tục hướng nghiên cứu này.

Tôi xin chân thành cảm ơn!

Hà Nội, tháng 12 năm 2021

3
 TÓM TẮT NỘI DUNG LUẬN VĂN

Hiện nay, việc sử dụng mật mã khoá công khai và dịch vụ chứng thực điện
tử để đảm bảo an toàn thông tin trong các hoạt động giao dịch điện tử là giải pháp
được nhiều quốc gia trên thế giới sử dụng. Chữ ký số ngày càng trở nên phổ biến
do những ưu điểm tốc độ ký nhanh, chính xác và dễ dàng kiểm định. Tuy nhiên
vẫn còn tồn tại những hạn chế như tốn kém, kém linh hoạt do cần thiết bị chuyên
dùng.

Với sự phát triển mạnh mẽ của thiết bị di động (máy tính bảng, điện thoại di
động, laptop,…), việc trao đổi thông tin, thực hiện các giao dịch điện tử trực tuyến
như tài chính, hành chính công ngày càng trở nên phổ biến. Không nằm ngoài xu
thế đó, chữ ký số cũng đã và đang được các quốc gia trên thế giới nghiên cứu và
triển khai trên nền tảng di dộng, tùy thuộc vào trình độ phát triển CNTT và hiện
trạng ứng dụng KPI của từng nước. Ký số trên di động đã tháo gỡ những khó khăn
của chữ ký số truyền thống, giúp việc ký số trở nên dễ dàng, minh bạch và tiết
kiệm chi phí.

Ở Việt Nam, chữ ký số và dịch vụ chứng thực chữ ký số truyền thống trên
các máy tính đã được triển khai rộng rãi. Tuy nhiên, chữ ký số mới chỉ được sử
dụng chủ yếu bởi các cơ quan chính phủ và doanh nghiệp. Việc ứng dụng chữ ký
số qua thiết bị di động đang có nhu cầu rất lớn và sẽ giúp thêm nhiều đối tượng cá
nhân và doanh nghiệp tiếp cận được với chữ ký số.

Thấy được tiềm năng của chữ ký số từ xa, qua báo cáo luận văn tốt nghiệp
này, tôi đi vào nghiên cứu về chữ ký số cũng như các thành phần, quy trình và tiêu
chuẩn ký số từ xa, và áp dụng trong việc xây dựng ứng dụng hỗ trợ ký số từ xa.

Trong khuôn khổ đề tài, tôi tập trung vào các vấn đề nghiên cứu sau đây:

• Mật mã và chữ ký số
• Các thành phần, quy trình và các tiêu chuẩn ký số từ xa.
• Ứng dụng hỗ trợ ký số từ xa.

4
 Kết quả của nghiên cứu này định hình hóa một phương án triển khai hệ thống,
ứng dụng hỗ trợ ký số từ xa phù hợp với các tiêu chuẩn được ban hành của Việt
Nam và thế giới.

Ứng dụng sẽ giúp người dùng tiết kiệm thời gian, chi phí và bảo đảm an toàn
cho các giao dịch. Dịch vụ web cũng có thể được công khai để sử dụng bởi các
ứng dụng hỗ trợ ký số từ xa khác.

5
 MỤC LỤC

DANH MỤC HÌNH VẼ .............................................................................. 10

DANH MỤC BẢNG BIỂU......................................................................... 12

LỜI MỞ ĐẦU ............................................................................................. 14

Lý do chọn đề tài ..................................................................................... 15

Đối tượng và phạm vi nghiên cứu ........................................................... 15

Ý nghĩa khoa học và thực tiễn của đề tài ................................................ 16

CHƯƠNG 1. TỔNG QUAN VỀ CHỮ KÝ SỐ........................................ 17

1.1 Mật mã .......................................................................................... 17

1.1.1 Nguyên lý mã hóa .................................................................... 17

1.1.2 Hệ mã khóa đối xứng ............................................................... 18

1.1.3 Hệ mã khóa công khai ............................................................. 19

1.2 Chữ ký số ...................................................................................... 22

1.2.1 Ý nghĩa của chữ ký viết tay ..................................................... 23

1.2.2 Giải pháp chữ ký số ................................................................. 24

1.2.3 Chứng thực khóa công khai ..................................................... 29

1.2.4 Những ưu thế và tầm quan trọng của chữ ký số ...................... 36

CHƯƠNG 2. KÝ SỐ TỪ XA ................................................................... 38

2.1 Ngữ cảnh về ký số từ xa ............................................................... 38

2.1.1 Giới thiệu ................................................................................. 38

2.1.2 Thách thức ............................................................................... 39

2.1.3 Những ưu thế của giải pháp ký số từ xa .................................. 40

2.1.4 Tính pháp lý ở EU.................................................................... 43

2.2 Hệ sinh thái và mô hình tổng thể ký số từ xa ............................... 43

2.2.1 Dịch vụ eID .............................................................................. 44

6
 2.2.2 Cơ quan chứng nhận (CA) ....................................................... 45

2.2.3 Cơ quan nhãn thời gian (TSA) ................................................. 45

2.2.4 Dịch vụ tạo và niêm phong chữ ký (SigS) ............................... 45

2.2.5 Dịch vụ Xác minh (ValS) ........................................................ 46

2.2.6 Dịch vụ bảo lưu (PresS) ........................................................... 46

2.2.7 Dịch vụ giao hàng điện tử (EDS)............................................. 46

2.3 Mô tả các Tiêu chuẩn ................................................................... 47

2.3.1 Tiêu chuẩn bảo mật 419 241-1 ................................................ 48

2.3.2 Tiêu chuẩn bảo mật 419 241-2 ................................................ 49

2.3.3 Tiêu chuẩn bảo mật 119 431 .................................................... 49

2.3.4 Tiêu chuẩn bảo mật 119 432 .................................................... 50

2.3.5 Tiêu chuẩn bảo mật 419 221-5 ................................................ 51

2.4 Các thành phần và quy trình ký số từ xa ...................................... 52

2.4.1 Các thành phần......................................................................... 52

2.4.2 Quy trình ký số từ xa ............................................................... 54

2.5 Tình hình thực tế ở Việt Nam....................................................... 55

2.5.1 Tình hình phát triển và ứng dụng chữ ký số ............................ 55

2.5.2 Tình hình phát triển và ứng dụng chữ ký số từ xa ................... 59

CHƯƠNG 3. ỨNG DỤNG HỖ TRỢ KÝ SỐ TỪ XA............................. 61

3.1 Tổng quan ứng dụng ..................................................................... 61

3.2 Phân tích yêu cầu .......................................................................... 64

3.2.1 Sơ đồ phân rã chức năng .......................................................... 64

3.2.2 Chức năng kích hoạt thiết bị .................................................... 65

3.2.3 Chức năng đăng nhập............................................................... 66

3.2.4 Chức năng đăng xuất ............................................................... 67

3.2.5 Chức năng cập nhật thông tin tài khoản .................................. 67

7
 3.2.6 Chức năng đổi mật khẩu .......................................................... 68

3.2.7 Chức năng xem yêu cầu ký ...................................................... 69

3.2.8 Chức năng chấp nhận yêu cầu ký ............................................ 69

3.2.9 Chức năng từ chối yêu cầu ký.................................................. 70

3.2.10 Chức năng xem chứng thư ..................................................... 71

3.3 Thiết kế cơ sở dữ liệu ................................................................... 72

3.3.1 Mô hình thực thể liên kết ......................................................... 72

3.3.2 Bảng users ................................................................................ 72

3.3.3 Bảng devices ............................................................................ 73

3.3.4 Bảng inactive_devices ............................................................. 75

3.3.5 Bảng credentials ....................................................................... 76

3.3.6 Bảng transactions ..................................................................... 80

3.4 Thiết kế dịch vụ Web ................................................................... 83

3.4.1 API xác thực ............................................................................ 83

3.4.2 API yêu cầu ký ......................................................................... 90

3.4.3 API chứng thư .......................................................................... 96

3.5 Thiết kế giao diện ......................................................................... 99

3.5.1 Giao diện kích hoạt thiết bị ...................................................... 99

3.5.2 Giao diện đăng nhập .............................................................. 100

3.5.3 Giao diện cá nhân .................................................................. 101

3.5.4 Giao diện cập nhật tài khoản.................................................. 102

3.5.5 Giao diện đổi mật khẩu .......................................................... 103

3.5.6 Giao diện thông tin yêu cầu ký .............................................. 104

3.5.7 Giao diện chấp nhận yêu cầu ký ............................................ 105

3.5.8 Giao diện từ chối yêu cầu ký ................................................. 106

3.5.9 Giao diện thông tin chứng thư ............................................... 107

8
 3.5.10 Giao diện cài đặt ứng dụng .................................................. 108

KẾT LUẬN ............................................................................................... 110

TÀI LIỆU THAM KHẢO ......................................................................... 111

9
 DANH MỤC HÌNH VẼ

Hình 1.1 Lược đồ mã hóa ............................................................................ 17

Hình 1.2 Hệ mã khóa đối xứng ................................................................... 19
Hình 1.3 Lược đồ hệ mã khóa công khai .................................................... 20
Hình 1.4 Ký số văn bản điện tử ................................................................... 24
Hình 1.5 Hàm băm mật mã ......................................................................... 26
Hình 1.6 Kiểm tra tính toàn vẹn thông tin bằng hàm băm mật mã ............. 27
Hình 1.7 Ký số sử dụng hàm băm mật mã .................................................. 28
Hình 1.8 Quy trình kiểm tra chữ ký số ........................................................ 28
Hình 1.9 Mạo danh bằng cách đánh tráo chìa khóa công khai ................... 29
Hình 1.10. Chứng thư số ............................................................................. 35
Hình 2.1 Hệ thống tin cậy eIDAS ............................................................... 44
Hình 2.2 Tổng quan về các tiêu chuẩn chữ ký ............................................ 48
Hình 2.3 Kiến trúc TOE của HSM .............................................................. 52
Hình 2.4 Số lượng chứng thư số đã cấp theo CA công cộng tính đến
31/12/2018............................................................................................................ 56
Hình 2.5 Tỉ lệ chứng thư số phân theo đối tượng tính đến 31/3/2019 ........ 57
Hình 2.6 Số lượng các loại chứng thư số đang hoạt động trong một số lĩnh
vực giai đoạn 2015 – 31/3/2019 ........................................................................... 57
Hình 3.1 Luồng đăng ký kích hoạt .............................................................. 62
Hình 3.2 Luồng xác nhận ký ....................................................................... 63
Hình 3.3 Mô hình logic hệ thống ký số từ xa .............................................. 63
Hình 3.4 Sơ đồ phân rã chức năng .............................................................. 64
Hình 3.5 Mô hình thực thể liên kết ............................................................. 72
Hình 3.6 Giao diện kích hoạt thiết bị ........................................................ 100
Hình 3.7 Giao diện đăng nhập ................................................................... 101
Hình 3.8 Giao diện cá nhân ....................................................................... 102
Hình 3.9 Giao diện cập nhật tài khoản ...................................................... 103
Hình 3.10 Giao diện đổi mật khẩu ............................................................ 104
Hình 3.11 Giao diện thông tin yêu cầu ký ................................................ 105
Hình 3.12 Giao diện chấp nhận yêu cầu ký .............................................. 106
10
Hình 3.13 Giao diện từ chối yêu cầu ký .................................................... 107
Hình 3.14 Giao diện thông tin chứng thư.................................................. 108
Hình 3.15. Giao diện cài đặt ...................................................................... 109

11
 DANH MỤC BẢNG BIỂU

Bảng 1.1 Chuẩn X.509 ................................................................................ 35

Bảng 3.1 Danh sách chức năng ................................................................... 64
Bảng 3.2 Bảng users .................................................................................... 72
Bảng 3.3 Bảng devices ................................................................................ 73
Bảng 3.4 Bảng inactive_devices ................................................................. 75
Bảng 3.5 Bảng credentials ........................................................................... 76
Bảng 3.6 Bảng transactions ......................................................................... 80
Bảng 3.7 API yêu cầu activate/login ........................................................... 83
Bảng 3.8 API phản hồi activate/login ......................................................... 84
Bảng 3.9 API yêu cầu activate/retrieveActivationCode ............................. 84
Bảng 3.10 API phản hồi activate/retrieveActivationCode .......................... 84
Bảng 3.11 API yêu cầu activate/initialize ................................................... 85
Bảng 3.12 API phản hồi activate/initialize ................................................. 85
Bảng 3.13 API yêu cầu activate/sendDevice .............................................. 86
Bảng 3.14 API phản hồi activate/sendDevice ............................................. 87
Bảng 3.15 API yêu cầu login ...................................................................... 88
Bảng 3.16 API phản hồi login ..................................................................... 88
Bảng 3.17 API yêu cầu revoke .................................................................... 89
Bảng 3.18 API phản hồi revoke .................................................................. 89
Bảng 3.19 API yêu cầu updateAccount ...................................................... 89
Bảng 3.20 API phản hồi updateAccount ..................................................... 89
Bảng 3.21 API yêu cầu changePassword .................................................... 90
Bảng 3.22 API phản hồi changePassword .................................................. 90
Bảng 3.23 API yêu cầu requests/list ........................................................... 90
Bảng 3.24 API phản hồi requests/list .......................................................... 91
Bảng 3.25 API yêu cầu requests/info .......................................................... 92
Bảng 3.26 API phản hồi requests/info ........................................................ 92
Bảng 3.27. API yêu cầu requests/confirm ................................................... 95
Bảng 3.28. API phản hồi requests/confirm ................................................. 95
Bảng 3.29 API yêu cầu requests/cancel ...................................................... 96
12
Bảng 3.30. API phản hồi requests/cancel.................................................... 96
Bảng 3.31 API yêu cầu credentials/list ....................................................... 96
Bảng 3.32 API phản hồi credentials/list ...................................................... 97
Bảng 3.33 API yêu cầu credentials/info ...................................................... 98
Bảng 3.34 API phản hồi credentials/info .................................................... 98

13
 LỜI MỞ ĐẦU

Hiện nay, việc sử dụng mật mã khoá công khai và dịch vụ chứng thực điện
tử để đảm bảo an toàn thông tin trong các hoạt động giao dịch điện tử là giải pháp
được nhiều quốc gia trên thế giới sử dụng. Chữ ký số ngày càng trở nên phổ biến
do những ưu điểm tốc độ ký nhanh, chính xác và dễ dàng kiểm định. Tuy nhiên
vẫn còn tồn tại những hạn chế như tốn kém, kém linh hoạt do cần thiết bị chuyên
dùng.

Với sự phát triển mạnh mẽ của thiết bị di động (máy tính bảng, điện thoại di
động, laptop,…), việc trao đổi thông tin, thực hiện các giao dịch điện tử trực tuyến
như tài chính, hành chính công ngày càng trở nên phổ biến. Không nằm ngoài xu
thế đó, chữ ký số cũng đã và đang được các quốc gia trên thế giới nghiên cứu và
triển khai trên nền tảng di dộng, tùy thuộc vào trình độ phát triển CNTT và hiện
trạng ứng dụng KPI của từng nước. Ký số trên di động đã tháo gỡ những khó khăn
của chữ ký số truyền thống, giúp việc ký số trở nên dễ dàng, minh bạch và tiết
kiệm chi phí.

Ở Việt Nam, chữ ký số và dịch vụ chứng thực chữ ký số truyền thống trên
các máy tính đã được triển khai rộng rãi. Tuy nhiên, chữ ký số mới chỉ được sử
dụng chủ yếu bởi các cơ quan chính phủ và doanh nghiệp. Việc ứng dụng chữ ký
số qua thiết bị di động đang có nhu cầu rất lớn và sẽ giúp thêm nhiều đối tượng cá
nhân và doanh nghiệp tiếp cận được với chữ ký số.

Nghị định số 130/2018/NĐ-CP (điểm b khoản 4 Điều 13; khoản 5 Điều 41;
và điểm b khoản 2 Điều 46) đã quy định: tổ chức cung cấp dịch vụ chứng thực chữ
ký số công cộng được cấp phép; tổ chức cung cấp dịch vụ chứng thực chữ ký số
chuyên dùng của cơ quan, tổ chức được cấp giấy chứng nhận đảm bảo an toàn; tổ
chức cung cấp dịch vụ chứng thực chữ ký số nước ngoài được công nhận phải tuân
thủ các quy chuẩn kỹ thuật, tiêu chuẩn bắt buộc áp dụng về chữ ký số và dịch vụ
chứng thực chữ ký số do Bộ TTTT ban hành.

- Đối với việc cung cấp dịch vụ chứng thực chữ ký số truyền thống, Bộ TTTT
đã ban hành Thông tư 06/2015/TT-BTTTT ngày 23/3/2015 quy định Danh mục
tiêu chuẩn bắt buộc áp dụng về chữ ký số và dịch vụ chứng thực chữ ký số.
14
 - Đối với việc cung cấp dịch vụ chứng thực chữ ký số qua thiết bị di động,
do Mobile PKI có những đặc thù riêng, nhiều giải pháp triển khai; tương ứng với
mỗi giải pháp là các tiêu chuẩn kỹ thuật riêng. Thông tư 06/2015/TT-BTTTT chưa
bao quát các giải pháp công nghệ và tiêu chuẩn này.

Do vậy Bộ TTTT đã tổ chức nghiên cứu, xây dựng quy định Danh mục quy
chuẩn kỹ thuật, tiêu chuẩn bắt buộc áp dụng về chữ ký số trên thiết bị di động để
áp dụng cho các tổ chức cung cấp dịch vụ chứng thực chữ ký số qua thiết bị di
động, đảm bảo tính an toàn, giá trị pháp lý của chữ ký số; làm căn cứ để cấp phép,
cấp giấy chứng nhận, công nhận cho tổ chức cung cấp dịch vụ chứng thực chữ ký
số và thúc đẩy triển khai dịch vụ chữ ký số qua thiết bị di động tại Việt Nam [1].

Thấy được tiềm năng của chữ ký số từ xa, qua báo cáo luận văn tốt nghiệp
này, tôi đi vào nghiên cứu về chữ ký số cũng như các thành phần, quy trình và tiêu
chuẩn ký số từ xa, và áp dụng trong việc xây dựng ứng dụng hỗ trợ ký số từ xa.

Lý do chọn đề tài
Với những kiến thức về bảo mật và phân tích thiết kế hệ thống đã học trong
chương trình Đại học và Cao học, cùng với kinh nghiệm phát triển phần mềm và
ứng dụng bảo mật trong hệ thống tại các công ty đã làm việc, tôi mong muốn qua
luận văn này có thể tổng kết lại kiến thức và giải quyết một bài toán quan trọng
trong thực tế.

Đối tượng và phạm vi nghiên cứu

Trong khuôn khổ đề tài, tôi tập trung vào các vấn đề nghiên cứu sau đây:

• Mật mã và chữ ký số
• Các thành phần, quy trình và các tiêu chuẩn ký số từ xa.
• Ứng dụng hỗ trợ ký số từ xa.

15
Ý nghĩa khoa học và thực tiễn của đề tài
Kết quả của nghiên cứu này định hình hóa một phương án triển khai hệ thống,
ứng dụng hỗ trợ ký số từ xa phù hợp với các tiêu chuẩn được ban hành của Việt
Nam và thế giới.

Ứng dụng sẽ giúp người dùng tiết kiệm thời gian, chi phí và bảo đảm an toàn
cho các giao dịch. Dịch vụ web cũng có thể được công khai để sử dụng bởi các
ứng dụng hỗ trợ ký số từ xa khác.

16
 CHƯƠNG 1. TỔNG QUAN VỀ CHỮ KÝ SỐ

1.1 Mật mã

1.1.1 Nguyên lý mã hóa

Mặc dù mật mã có một lịch sử lâu dài, song các kỹ thuật mã hóa hiện đại,
bao gồm nhiều kỹ thuật được sử dụng trên Internet, dựa trên những tiến bộ có được
trong 30 năm trở lại đây.

Kỹ thuật mã hóa cho phép người gửi ngụy trang dữ liệu để kẻ xâm nhập có
thể không nhận được thông tin gốc từ dữ liệu bị chặn. Người nhận, tất nhiên, phải
có khả năng khôi phục dữ liệu gốc từ dữ liệu được cải trang. Lược đồ mã hóa được
minh họa trong sơ đồ sau:

Hình 1.1 Lược đồ mã hóa [19]

Trong Hình 1.1, Alice được cung cấp khóa 𝐾𝐾𝐴𝐴 và tiến hành mã hóa bằng thuật
toán mã hóa nhận đầu vào là 𝐾𝐾𝐴𝐴 và bản rõ 𝑚𝑚. Từ đó, Alice thu được bản mã 𝐾𝐾𝐴𝐴 (𝑚𝑚)
và gửi đi trên môi trường mạng đến Bob. Bob được cung cấp khóa 𝐾𝐾𝐵𝐵 sau khi nhận
được bản mã sẽ sử dụng thuật toán giải mã với đầu vào là 𝐾𝐾𝐵𝐵 và bản mã để thu
được bản rõ ban đầu. Nói một cách hình thức thì K A và 𝐾𝐾𝐵𝐵 phải thỏa mãn
𝐾𝐾𝐴𝐴 �𝐾𝐾𝐵𝐵 (𝑚𝑚)� = 𝑚𝑚. Trong hệ mã khóa đối xứng thì khóa của Alice và Bob là giống
nhau và phải được giữ bí mật. Đối với hệ mã khóa công khai thì người ta sử dụng
một cặp khóa thay vì chỉ sử dụng một khóa đơn. Trong đó, một khóa được công

17
khai và khóa còn lại được giữ bí mật mà chỉ có bản thân chủ sở hữu khóa mới có
quyền được biết.

1.1.2 Hệ mã khóa đối xứng

Các thuật toán khóa đối xứng là một lớp các thuật toán mật mã hóa trong đó
các khóa dùng cho việc mật mã hóa và giải mã có quan hệ rõ ràng với nhau (có thể
dễ dàng tìm được một khóa nếu biết khóa kia). Mã khóa loại này không công khai.

Khóa dùng để mã hóa có liên hệ một cách rõ ràng với khóa dùng để giải mã
có nghĩa chúng có thể hoàn toàn giống nhau, hoặc chỉ khác nhau nhờ một biến đổi
đơn giản giữa hai khóa. Trên thực tế, các khóa này đại diện cho một bí mật được
phân hưởng bởi hai bên hoặc nhiều hơn và được sử dụng để giữ gìn sự bí mật trong
kênh truyền thông tin.

Thuật toán khóa đối xứng có thể được chia ra làm hai loại, mật mã luồng
(stream ciphers) và mật mã khối (block ciphers). Mật mã luồng mã hóa từng bit
của thông điệp trong khi mật mã khối gộp một số bit lại và mật mã hóa chúng như
một đơn vị. Một số ví dụ các thuật toán khóa đối xứng nổi tiếng và khá được tín
nhiệm bao gồm Twofish, Serpent, AES (còn được gọi là Rijndael), Blowfish,
CAST5, RC4, Tam phần DES (Triple DES), và IDEA (International Data
Encryption Algorithm - Thuật toán mật mã hóa dữ liệu quốc tế).

Các thuật toán khóa đối xứng nói chung đòi hỏi công suất tính toán ít hơn
các thuật toán khóa bất đối xứng (asymmetric key algorithms). Trên thực tế, một
thuật toán khóa bất đối xứng có khối lượng tính toán nhiều hơn gấp hằng trăm,
hằng ngàn lần một thuật toán khóa đối xứng (symmetric key algorithm) có chất
lượng tương đương.

18
 Hình 1.2 Hệ mã khóa đối xứng [19]

1.1.3 Hệ mã khóa công khai

Mã hóa khóa công khai ra đời cách đây 42 năm, đánh dấu bởi công trình khoa
học của Whitfield Diffie và Martin Hellman. Đó thực sự là một bước ngoặt đưa
mật mã từ một nghệ thuật thành một ngành khoa học. Trong quá trình 42 năm phát
triển, những phát kiến trong mật mã hầu hết rất phản trực quan, và do đó càng bất
ngờ thú vị, đã có ảnh hưởng lớn đến nhiều ngành khoa học khác: áp dụng những
kết quả trừu tượng trong lý thuyết số vào thực tế; thúc đẩy sự phát triển của các
thuật toán xác suất; đưa ra những khái niệm quan trọng trong lý thuyết tính toán
mà điển hình là khái niệm chứng minh tương tác; tạo cầu nối giữa lý thuyết số và
khoa học máy tính thông qua lý thuyết số tính toán,...

Mô hình của hệ mã khoá công khai

Hệ mã khóa bí mật gặp phải những vấn đề sau:

• Vấn đề chia sẻ và chuyển chìa khoá.

• Vấn đề toàn vẹn thông tin và ký văn bản điện tử.
• Vấn đề ai là ai trong mạng thông tin điện tử.

Mật mã khóa công khai đã vượt qua các rào cản đó và đưa đến một bước
ngoặt trong sự phát triển ngành mật mã. Ý tưởng chính của nó khá giản đơn: lập
mã và giải mã là hai quá trình có bản chất khác nhau, nếu như giải mã nhất thiết
phải dùng khóa bí mật (nếu không ai cũng giải được) thì lập mã lại không nhất
thiết như vậy, và thậm chí sẽ càng tốt hơn khi ai cũng có thể lập mã. Do vậy, nếu
19
ta có thể sinh ra một khóa bí mật cho giải mã và một khóa công khai tương ứng
cho lập mã thì quá trình lập mã không còn cần bất kỳ bí mật nào. Tuy có vẻ tự
nhiên nhưng việc mã hóa sử dụng khóa công khai làm thay đổi hoàn toàn yêu cầu
về sự an toàn: khóa bí mật không cần chia sẻ nữa, mỗi người có khóa bí mật của
riêng mình và chỉ cần giữ kín nó, không cần thiết phải chia sẻ nó với bất kỳ ai khác.
Sự đảm bảo an toàn không còn cần dựa trên sự tin tưởng lẫn nhau giữa người gửi
và người nhận.

Hình 1.3 Lược đồ hệ mã khóa công khai [19]

Như vậy, mỗi cá thể tham gia vào hệ thống sẽ được cấp một cặp chìa khoá,
trong đó, chìa khoá lập mã có thể được công bố công khai cho mọi người biết
(public key) còn chìa khoá giải mã thì có mình cá thể đó biết (private key). Điều
cần lưu ý là từ khoá công khai không thể tính ra chìa khoá bí mật. Mọi người trong
hệ thống đều có thể mã hoá dữ liệu để gửi cho một cá thể nào đó (bằng khóa công
khai) và chỉ một mình cá thể này mới có thể giải mã được các tài liệu mật. Một
cách dễ hình dung, mọi người đều có thể gửi thư mật cho một người thông qua khe
của hòm thư đặt trước cửa nhà, và chỉ có người ấy mới có chìa khoá mở thùng thư
lấy ra đọc (ở đây, cửa khe đóng vai trò khóa công khai còn chìa mở thùng thư là
khóa bí mật).

Mật mã khóa công khai còn làm thay đổi hoàn toàn phạm vi ứng dụng, cho
phép mật mã được sử dụng rộng rãi trong thực tế: việc thiết lập kênh bí mật giữa
một nghìn hay một triệu người thì cũng chỉ yêu cầu mỗi người cần giữ một khóa
bí mật và công bố một khóa công khai, không cần phải thống nhất khóa chung nào.
Áp dụng vào thực tế, một cửa hàng trực tuyến có thể thu hút hàng triệu khách hàng

20
mà chỉ cần công khai duy nhất một khóa để ai mua hàng cũng chỉ cần dùng khóa
công khai đó để gửi thông tin bảo mật về thẻ thanh toán.

Hệ mã khóa công khai RSA

Trước hết, ta chọn khoá công khai là cặp (𝑒𝑒, 𝑛𝑛), gồm số mũ 𝑒𝑒 và modulo 𝑛𝑛.
Số 𝑛𝑛 được dùng ở đây là tích của 2 số nguyên tố rất lớn nào đó 𝑛𝑛 = 𝑝𝑝𝑝𝑝, sao cho
gcd�𝑒𝑒, ϕ(𝑛𝑛)� = 1, trong đó ϕ(𝑛𝑛) là hàm Euler để chỉ số lượng các số nguyên
dương nhỏ hơn 𝑛𝑛 và nguyên tố cùng nhau với 𝑛𝑛. Để mã hoá một khối 𝑃𝑃 trong văn
bản, ta lập khối 𝐶𝐶 theo công thức:

C = E(𝑃𝑃) ≡ 𝑃𝑃𝑒𝑒 mod n, 0 < C < n

Quá trình giải mã đòi hỏi phải biết một nghịch đảo 𝑑𝑑 của 𝑒𝑒 theo modulo
ϕ(𝑛𝑛). Nghịch đảo này tồn tại theo điều kiện gcd�𝑒𝑒, ϕ(𝑛𝑛)� = 1, cặp �𝑑𝑑, ϕ(𝑛𝑛)� như
vậy được gọi là khoá bí mật.

Hệ mã khóa công khai ECC

Lược đồ ECC. Bây giờ giả sử có tập hợp 𝑛𝑛 cá thể 𝐴𝐴𝑖𝑖 cần trao đổi thông tin
mật với nhau.

Chọn đường cong 𝐸𝐸 trên trường 𝑭𝑭q và một điểm 𝐵𝐵 thuộc 𝐸𝐸 làm cơ sở. Những
thông tin này được công khai, dĩ nhiên là 𝑞𝑞 phải đủ lớn.

Sau đó, mỗi cá thể 𝐴𝐴𝑖𝑖 chọn cho mình khoá 𝑒𝑒𝑖𝑖 , là một số nguyên nào đó. Khoá
này được giữ bí mật nhưng 𝐴𝐴𝑖𝑖 thông báo công khai 𝑒𝑒𝑖𝑖 𝐵𝐵. Điều này không làm lộ
khoá 𝑒𝑒𝑖𝑖 do độ phức tạp của thuật toán tính logarit.

Giả sử 𝐴𝐴𝑗𝑗 cần gửi thông báo mật 𝑚𝑚 cho 𝐴𝐴𝑖𝑖 . Trước tiên, 𝑚𝑚 được tương ứng
với 𝑃𝑃𝑚𝑚 như trên. Sau đó, 𝐴𝐴𝑗𝑗 chọn ngẫu nhiên số 𝑠𝑠 và chuyển cho 𝐴𝐴𝑖𝑖 cặp điểm sau
đây: �𝑠𝑠𝑠𝑠, 𝑃𝑃𝑚𝑚 + 𝑠𝑠(𝑒𝑒𝑖𝑖 𝐵𝐵)�, nhờ 𝑒𝑒𝑖𝑖 𝐵𝐵 đã được công khai. Khi nhận được cặp điểm này,
𝐴𝐴𝑖𝑖 chỉ việc lấy số sau trừ đi 𝑒𝑒𝑖𝑖 lần số trước để nhận được 𝑃𝑃𝑚𝑚 :

𝑃𝑃𝑚𝑚 = 𝑃𝑃𝑚𝑚 + 𝑠𝑠(𝑒𝑒𝑖𝑖 𝐵𝐵) − 𝑒𝑒𝑖𝑖 (𝑠𝑠𝑠𝑠)

Chú ý rằng chỉ có 𝐴𝐴𝑖𝑖 làm được điều này do 𝑒𝑒𝑖𝑖 bí mật và 𝑠𝑠 không thể tìm thấy
trong thời gian đa thức.

21
 Hệ quả tương tự mã mũ. Trong cách này, ta cần chọn 𝐸𝐸 với 𝑁𝑁 điểm. Các
tham số này được thông báo công khai. Mỗi cá thể 𝐴𝐴𝑖𝑖 chọn cho mình khoá 𝑒𝑒𝑖𝑖 là số
nguyên dương nằm trong đoạn [1, 𝑁𝑁] và gcd(𝑒𝑒𝑖𝑖 , 𝑁𝑁) = 1. Bằng thuật toán Euclid,
𝐴𝐴𝑖𝑖 tìm được 𝑑𝑑𝑖𝑖 thoả mãn: 𝑑𝑑𝑖𝑖 𝑒𝑒𝑖𝑖 = 1 (mod 𝑁𝑁). Bây giờ giả sử 𝐴𝐴𝑖𝑖 cần gửi thông báo
𝑚𝑚 cho 𝐴𝐴𝑗𝑗 . Cũng như cách trên, ta tìm điểm 𝑃𝑃𝑚𝑚 trên đường cong. Sau đó:

• 𝐴𝐴𝑖𝑖 gửi cho 𝐴𝐴𝑗𝑗 thông báo 𝑒𝑒𝑖𝑖 𝑃𝑃𝑚𝑚 . Dĩ nhiên khi nhận được thông báo này thì
𝐴𝐴𝑗𝑗 chưa thể giải mã vì không biết 𝑒𝑒𝑖𝑖 và 𝑑𝑑𝑖𝑖 .
• 𝐴𝐴𝑗𝑗 nhân thông báo nhận được với 𝑒𝑒𝑗𝑗 và gửi trả lại cho 𝐴𝐴𝑖𝑖 thông báo
𝑒𝑒𝑗𝑗 (𝑒𝑒𝑖𝑖 𝑃𝑃𝑚𝑚 ).

• 𝐴𝐴𝑖𝑖 gửi lại cho 𝐴𝐴𝑗𝑗 thông báo sau khi đã nhân với 𝑑𝑑𝑖𝑖 : 𝑑𝑑𝑖𝑖 �𝑒𝑒𝑗𝑗 (𝑒𝑒𝑖𝑖 𝑃𝑃𝑚𝑚 )�

• Nhận được thông báo cuối cùng này, 𝐴𝐴𝑗𝑗 nhân nó với khoá 𝑑𝑑𝑗𝑗 của mình để
nhận được 𝑃𝑃𝑚𝑚 và từ đó giải ra thông điệp ban đầu.

Dễ thấy rằng, trong toàn bộ quá trình thì các khoá 𝑒𝑒𝑖𝑖 hay 𝑑𝑑𝑖𝑖 đều không bị lộ.

1.2 Chữ ký số
Trong phần trước, chúng ta đã thấy vai trò của mật mã trong việc đem lại tính
bảo mật khi giao tiếp qua mạng. Trong phần này, chúng ta sẽ xem xét cách thức
để đảm bảo tính toàn vẹn thông tin nhờ ứng dụng hệ mật mã khóa công khai.

Vấn đề toàn vẹn thông tin là mối quan tâm hàng đầu trong các giao thức
mạng an toàn. Ví dụ, xét mạng máy tính sử dụng thuật toán định tuyến trạng thái
kết nối (chẳng hạn OSPF) để xác định tuyến giữa mỗi cặp router trong mạng. Trong
một thuật toán trạng thái kết nối, mỗi router cần phát quảng bá một thông điệp
trạng thái kết nối tới tất cả các bộ định tuyến khác trong mạng. Thông báo bao gồm
danh sách các láng giềng được kết nối trực tiếp và chi phí trực tiếp kết nối đến
người hàng xóm này. Khi router nhận được thông báo trạng thái kết nối từ tất cả
router khác, nó có thể tạo ra một bản đồ hoàn chỉnh của mạng, chạy định tuyến chi
phí thấp nhất và cấu hình lại bảng chuyển tiếp của nó. Một cuộc tấn công vào thuật
toán định tuyến là để Trudy phân phối các thông điệp trạng thái liên kết không có
thật hoặc không chính xác. Do đó sự cần thiết về tính toàn vẹn của thông điệp - khi
bộ định tuyến B nhận được thông báo trạng thái kết nối từ bộ định tuyến A, bộ
22
định tuyến B phải xác minh rằng bộ định tuyến A thực sự đã tạo ra thông điệp và,
hơn nữa, không ai làm xáo trộn thông điệp quá cảnh.

Từ đây, thay vì xét các tin nhắn qua mạng, ta sẽ xem xét một đối tượng khái
quát hơn là văn bản điện tử. Văn bản trên giấy có tính chất “bước chân đi, cấm kỳ
trở lại” (những gì đã viết ra thì không thể thay đổi mà không để lại dấu vết), cho
nên tự nó có tính bảo toàn nội dung, không dễ bị bóp méo hay xuyên tạc. Với văn
bản điện tử thì thuộc tính này không còn nữa, người ta dễ dàng thay đổi nó mà
không để lại dấu vết gì. Rõ ràng với những văn bản cần được ký thì điều này là
không thể chấp nhận được. Trước khi đi tìm một giải pháp cho việc ký văn bản
điện tử thì ta cần tìm hiểu rõ hơn về chữ ký truyền thống trên văn bản giấy.

1.2.1 Ý nghĩa của chữ ký viết tay

Một cách lý tưởng thì chữ ký viết tay mang các ý nghĩa và thuộc tính sau
đây:

• Chữ ký là bằng chứng thể hiện người ký tán thành nội dung và có chủ
định ký văn bản.
• Chữ ký thể hiện chủ quyền người ký (cho biết ai là người ký văn bản).
• Chữ ký không thể tái sử dụng, tức là nó chỉ có hiệu lực trên văn bản được
ký.
• Văn bản đã ký không thể thay đổi được nội dung (việc tẩy xoá, sửa chữa
sẽ làm nó mất hiệu lực).
• Chữ ký là không thể chối bỏ và không thể giả mạo (người ký văn bản
không thể phủ nhận việc mình đã ký, còn người khác thì không thể tạo ra
chữ ký đó).

Như vậy, để ký một văn bản điện tử, người ta cần phải tạo ra một đối tượng
có đủ 5 thuộc tính giống như chữ ký viết tay trên văn bản giấy (đã nêu ở trên), để
sao cho văn bản điện tử đi cùng với đối tượng này thì nó sẽ có hiệu lực giống như
là văn bản giấy sau khi được ký. Rõ ràng, nếu như ta có đưa được hình ảnh chữ ký
viết tay vào trong văn bản điện tử thì nó cũng không thể có được 5 thuộc tính đã
nêu ở trên (vì người ta dễ dàng sao chép nó từ văn bản này sang văn bản khác và
cũng dễ dàng thay đổi nội dung văn bản mà không để lại dấu vết). Do vậy, với văn
23
bản điện tử, cần có giải pháp hoàn toàn khác. Thật bất ngờ, giải pháp cho vấn đề
này lại đến từ hệ mã khoá công khai, một công cụ vốn sinh ra để phục vụ các văn
bản bí mật, chứ không phải các văn bản mang tính công khai đại chúng.

1.2.2 Giải pháp chữ ký số

Giả sử những người tham gia vào hệ thống trao đổi thông tin với nhau có sử
dụng một hệ mật mã khoá công khai (ví dụ ECC đã giới thiệu ở phần trước). Khi
ấy, mỗi cá thể được sở hữu một cặp chìa khoá (bí mật, công khai) riêng biệt (không
ai giống ai) và người ta có thể đưa ra mô hình ký văn bản điện tử dựa trên ý tưởng
của hai nhà khoa học Diffie và Hellman.

Mô hình cho việc ký văn bản điện tử

Nguyên tắc ký văn bản điện tử được tóm gọn như sau:

• Ông A ký văn bản bằng cách dùng chìa khoá bí mật của mình để mã hoá
nó.
• Ông B kiểm tra chữ ký bằng cách dùng chìa khoá công khai của ông A
để giải mã văn bản. Nếu giải mã thành công thì đúng là văn bản được ký
bởi ông A.

Hình 1.4 Ký số văn bản điện tử [19]

Ta chứng minh giao thức này mang đầy đủ thuộc tính cơ bản của thủ tục ký
tay trên giấy, thật vậy:

• Văn bản được ký (văn bản mã) là sản phẩm của người chủ động tạo ra nó,
tức là người đã dùng chìa khoá bí mật của mình để mã hoá văn bản.
24
 • Văn bản được ký cho biết người ký là ai (chính là chủ sở hữu chìa khoá
công khai đã được dùng để kiểm tra chữ ký).
• Chữ ký không thể tái sử dụng cho văn bản khác, vì 2 văn bản khác nhau
có bản mã khác nhau.
• Văn bản đã ký không thể thay đổi được nội dung. Vì nếu mở ra (tức là
giải mã) để thay đổi nội dung thì không thể ký lại (mã hoá) được nữa, do
không có chìa khoá bí mật của người đã ký trước đó.
• Không ai làm giả được chữ ký, vì rằng không có ai có được chìa khoá bí
mật của người đã ký (mã hoá) văn bản đó. Người ký văn bản không thể
thoái thác việc mình đã ký, vì không còn ai khác có khoá đã được dùng
để mã hoá đó (kiểm tra bằng khóa công khai).

Quy trình ký nêu trên là phù hợp về mặt logic nhưng cũng có những điều bất
cập sau:

• Văn bản sau khi ký luôn ở trong dạng mã hoá, kể cả văn bản cần công
khai rộng rãi (điều này là không tự nhiên).
• Tốc độ ký rất chậm, sẽ không phù hợp khi ký các văn bản dài như hợp
đồng, văn kiện,... (do thuật toán mã hoá chậm).
• Chữ ký là cả văn bản ký cho nên dài như một văn bản (không phù hợp
với đặc tính tự nhiên vốn có của chữ ký là ngắn gọn, súc tích).

Cho nên quy trình nêu trên chỉ mang tính nguyên tắc, mà không khả thi trong
thực tiễn. Để khắc phục những bất cập và có được một quy trình khả thi, người ta
cần đến sự giúp đỡ của một công cụ nữa đến từ mật mã là hàm băm mật mã.

Hàm băm mật mã

Hàm băm mật mã nhận giá trị đầu vào là văn bản điện tử có độ dài tuỳ ý và
cho đầu ra là một xâu chữ số có độ dài xác định (tương đối ngắn, khoảng vài trăm
ký tự) với các thuộc tính quan trọng sau:

• Có tính tất định, văn bản giống nhau luôn thu được mã băm giống nhau.
• Tốc độ băm rất nhanh (Thời gian tính cho mọi văn bản là không đáng kể).
• Có tính một chiều (Không thể tạo ra văn bản đầu vào khi có đầu ra cho
trước).
25
 • Rất nhạy đối với các thay đổi của văn bản (hai văn bản đầu vào dù khác
nhau rất nhỏ thì cũng có đầu ra khác biệt rõ rệt).
• Không thể tìm ra hai văn bản khác nhau có cùng mã băm.

Hình 1.5 Hàm băm mật mã [19]

Việc thiết lập hàm băm có các thuộc tính trên là không đơn giản và là một
ngành quan trọng của mật mã học.

MD5 của Ron Rivest là một trong những hàm băm mật mã được sử dụng phổ
biến ngày nay. Kết quả của phép băm là mã băm 128 bit được tính thông qua 4
bước. Một bước chèn thêm bộ đệm (thêm bit 1 theo sau bởi các số 0 để độ dài
thông điệp ít hơn một bội của 512 là 64). Sau đó, chèn 1 số nguyên 64 bit (độ dài
của thông điệp gốc) vào sau để thu được đoạn bit có chiều dài là bội của 512. Khởi
tạo 4 khối, mỗi khối có độ dài 32 bit. Tiến hành thay đổi giá trị mỗi khối bằng các
khối 512 bit của thông điệp. Kết quả cuối cùng sẽ là mã băm 128 bit của thông
điệp ban đầu.

Thuật toán SHA (Secure Hash Algorithm) là thuật toán băm được sử dụng
phổ biến chỉ sau MD5. Nguyên lý thiết kế SHA tương tự MD4 (tiền thân của
MD5). SHA-1 là chuẩn bắt buộc của bất kỳ một hàm băm mật mã nào được sử
dụng trong ứng dụng của liên bang. Mã băm của SHA-1 có độ dài 160 bit nên được
cho là an toàn hơn MD5.

Đầu ra của hàm băm thường được gọi là mã băm. Từ các thuộc tính của hàm
băm ta suy ra mã băm có tính đặc trưng rất cao: một khi văn bản bị thay đổi thì ắt

26
mã băm phải thay đổi. Do vậy, mã băm còn được gọi là đại diện của văn bản, tương
tự như dấu vân tay của mỗi người có thể xem là đại diện của người đó.

Từ tính chất của hàm băm mật mã, chúng ta có thể xây dựng lược đồ kiểm
tra tính toàn vẹn của thông tin như sau mà không cần đến một hệ mã nào:

Hình 1.6 Kiểm tra tính toàn vẹn thông tin bằng hàm băm mật mã [19]

Tuy nhiên vấn đề đặt ra là làm thế nào để phân bổ khóa bí mật S ở trong sơ
đồ trên mà không bị lộ. Rất may mắn, kết hợp lược đồ trên và lược đồ chữ ký số
cổ điển sẽ cho ta lược đồ có đủ tính chất mà ta cần để kiểm tra tính toàn vẹn thông
tin.

Quy trình ký và kiểm chứng văn bản điện tử trong thực tế

Rõ ràng để đảm bảo nội dung văn bản không bị thay đổi, ta chỉ cần quan tâm
đại diện của nó không bị thay đổi. Do vậy, ta có một quy trình ký mới, tương đương
với quy trình nguyên tắc đã nêu ở trên.

Một cá thể A muốn ký văn bản P thì chỉ cần thực hiện các bước sau:

• Tính đại diện của văn bản P (bằng hàm băm mật mã có sẵn trên hệ thống).
• Dùng chìa khoá bí mật của mình để mã hoá dãy số đại diện văn bản thu
được và đính kèm với văn bản.

27
 Hình 1.7 Ký số sử dụng hàm băm mật mã [19]

Để kiểm tra chữ ký số của ông A trên văn bản P thì cần tiến hành các bước
sau:

• Tính đại diện của văn bản P bằng hàm băm mật mã có sẵn trên hệ thống.
• Giải mã chữ ký số bằng chìa khoá công khai của ông A rồi so sánh nó với
đại diện văn bản tính được ở bước trên. Nếu chúng khớp nhau thì văn bản
đã được ký bởi ông A và nội dung của nó không bị thay đổi sau khi ký.

Hình 1.8 Quy trình kiểm tra chữ ký số [19]

28
 Dễ thấy rằng quy trình này khắc phục được các nhược điểm đã nêu trên, cụ
thể là:

• Văn bản sau khi ký không bị mã hoá (mà chỉ bị đính thêm một xâu số, là
chữ ký số).
• Thời gian tạo chữ ký là không đáng kể (vì việc lấy mã băm rất nhanh, vì
nó rất nhỏ so với văn bản ký).
• Chữ ký chỉ là một xâu số ngắn đi kèm theo văn bản mà không phải là cả
văn bản.

1.2.3 Chứng thực khóa công khai

Khả năng mạo danh bằng cách đánh tráo chìa khoá công khai

Trong mô hình chữ ký số nêu trên thì chữ ký số được tạo ra bằng chìa khoá
bí mật của người ký và được kiểm tra bằng chìa khoá công khai của người đó. Như
vậy, nếu như kẻ gian có thể thay thế chìa khoá công khai của ông A nào đó bằng
chìa khoá công khai của mình thì kẻ đó có thể giả danh ông A một cách hoàn hảo.
Vì khi ấy, mọi văn bản mà hắn ký sẽ được hiểu là do ông A ký. Khi ấy hệ thống
sẽ trở nên hỗn loạn khôn lường, vì kẻ gian có thể đóng vai trò một nhà lãnh đạo.
Để không xảy ra tình trạng này thì phải có giải pháp ngăn chặn việc đánh tráo chìa
khoá công khai, tức là xác định chính xác ai sở hữu chìa khoá công khai nào.

Hình 1.9 Mạo danh bằng cách đánh tráo chìa khóa công khai [19]

29
 Như vậy, vấn đề đặt ra là cần tìm một giải pháp để gắn kết một chìa khoá
công khai với một thực thể, mà kẻ gian không thể nào phá vỡ được. Giải pháp cho
vấn đề này đưa ta đến với khái niệm chứng thư số (có vai trò như chứng minh thư
của công dân).

Hạ tầng khóa công khai

Hạ tầng khóa công khai (tiếng Anh: public key infrastructure, viết tắt PKI) là
một cơ chế để cho một bên thứ 3 (thường là nhà cung cấp chứng thư số) cung cấp
và xác thực định danh các bên tham gia vào quá trình trao đổi thông tin. Cơ chế
này cũng cho phép gán cho mỗi người sử dụng trong hệ thống một cặp khóa công
khai/khóa bí mật. Các quá trình này thường được thực hiện bởi một phần mềm đặt
tại trung tâm và các phần mềm phối hợp khác tại các địa điểm của người dùng.
Khóa công khai thường được phân phối trong chứng thư khóa công khai.

PKI cho phép những người tham gia xác thực lẫn nhau và sử dụng thông tin
từ các chứng thư khóa công khai để mã hóa và giải mã thông tin trong quá trình
trao đổi. Thông thường, PKI bao gồm phần mềm máy khách (client), phần mềm
máy chủ (server), phần cứng (như thẻ thông minh) và các quy trình hoạt động liên
quan. Người sử dụng cũng có thể ký các văn bản điện tử với khóa bí mật của mình
và mọi người đều có thể kiểm tra với khóa công khai của người đó. PKI cho phép
các giao dịch điện tử được diễn ra đảm bảo tính bí mật, toàn vẹn và xác thực lẫn
nhau mà không cần phải trao đổi các thông tin mật từ trước.

Hầu hết các hệ thống PKI quy mô doanh nghiệp đều dựa trên các chuỗi chứng
thư để xác thực các thực thể. Chứng thư của người dùng sẽ được một nhà cung cấp
chứng thư số cấp, đến lượt nhà cung cấp này lại có chứng thư được một nhà cung
cấp khác ở cấp cao hơn tạo ra,... Hệ thống sẽ bao gồm nhiều máy tính thuộc nhiều
tổ chức khác nhau với các gói phần mềm tương thích từ nhiều nguồn khác nhau.
Vì vậy, các tiêu chuẩn là yếu tố rất quan trọng đối với hoạt động của các PKI. Hầu
hết các tiêu chuẩn về PKI hiện tại được soạn thảo bởi nhóm làm việc PKIX của
IETF.

Các hệ thống PKI doanh nghiệp thường được tổ chức theo mô hình danh bạ
trong đó khóa công khai của mỗi người dùng được lưu trữ (bên trong các chứng

30
thư số) kèm với các thông tin cá nhân (số điện thoại, email, địa chỉ, nơi làm việc,...).
Hiện nay, công nghệ danh bạ tiên tiến nhất là LDAP và định dạng chứng thư phổ
biến nhất (X.509) cũng được phát triển từ mô hình tiền nhiệm của LDAP (X.500).

Nhà cung cấp chứng thư số

Nhà cung cấp chứng thư số (tiếng Anh: Certificate Authority, viết tắt: CA)
là thực thể phát hành các chứng thư khóa công khai cho người dùng. Nhà cung cấp
chứng thư số đóng vai trò là bên thứ ba (được cả hai bên tin tưởng) để hỗ trợ cho
quá trình trao đổi thông tin an toàn. Các nhà cung cấp chứng thư số là thành phần
trung tâm trong nhiều mô hình hạ tầng khóa công khai (PKI).

Hiện nay có nhiều CA thương mại mà người dùng phải trả phí khi sử dụng
dịch vụ. Các tổ chức và chính phủ cũng có thể có những CA của riêng họ. Bên
cạnh đó cũng có những CA cung cấp dịch vụ miễn phí.

CA phát hành các chứng thư khóa công khai trong đó thể hiện rằng CA đó
chứng nhận khóa công khai nằm trong mỗi chứng thư thuộc về cá nhân, tổ chức,
máy chủ hay bất kỳ thực thể nào ghi trong cùng chứng thư đó. Nhiệm vụ của CA
là kiểm tra tính chính xác của thông tin liên quan tới thực thể được cấp chứng thư.
Khi người sử dụng tin tưởng vào một CA và có thể kiểm tra chữ ký số của CA đó
thì họ cũng có thể tin tưởng vào khóa công khai và thực thể được ghi trong chứng
thư.

Khi CA có thể bị xâm nhập thì an toàn của hệ thống sẽ bị phá vỡ. Nếu kẻ tấn
công (Trudy) có thể can thiệp để tạo ra một chứng thư giả trong đó gắn khóa công
khai của kẻ tấn công với định danh của người dùng khác (Alice) thì mọi giao dịch
của người khác với Alice có thể bị Trudy can thiệp.

Việc đảm bảo độ chính xác của thông tin trong chứng thư là rất quan trọng
nhưng lại khó thực hiện, đặc biệt khi phần lớn các giao dịch sẽ được thông qua
đường điện tử. Vì thế các CA thương mại thường dùng phối hợp nhiều biện pháp
để kiểm tra thông tin: dùng các thông tin hành chính (chính phủ), hệ thống thanh
toán, các cơ sở dữ liệu của bên thứ 3 và các phương pháp riêng biệt khác. Trong
một số hệ thống của doanh nghiệp, thì việc cấp chứng thư có thể thực hiện thông
qua một giao thức nhận chứng thư nội bộ (chẳng hạn như Giao thức Kerberos).

31
Sau đó, chứng thư này được dùng để giao dịch với hệ thống bên ngoài. Một số hệ
thống khác lại đòi hỏi có sự tham gia của công chứng viên khi cấp chứng thư.

Khi được ứng dụng trên quy mô lớn, hệ thống sẽ bao gồm nhiều nhà cung
cấp chứng thư số. Giả sử Alice và Bob cần trao đổi thông tin nhưng chứng thư của
hai người lại do hai nhà cung cấp khác nhau tạo ra. Khi đó chứng thư của Bob gửi
tới Alice phải bao gồm cả khóa công khai của nhà cung cấp của Bob và được ký
bởi một nhà cung cấp khác để Alice có thể kiểm tra. Quá trình này sẽ dẫn đến một
hệ thống các nhà cung cấp tổ chức theo thang bậc hoặc mạng lưới.

Dưới đây là danh sách một số CA được nhiều người biết đến. Khi sử dụng
bất kỳ CA nào thì người sử dụng cũng phải tin vào CA đó. Trong trường hợp một
trình duyệt web truy cập vào trang web có chứng thư thì lý tưởng nhất là trình
duyệt đó đã nhận biết CA cấp chứng thư. Trong trường hợp ngược lại thì người
dùng sẽ đưa ra quyết định có tin vào CA đó hay không. Một số CA tự nhận rằng
đã được 99% trình duyệt tin tưởng.

• CA thu phí: VeriSign, Thawte, GeoTrust, GoDaddy.

• CA không thu phí: Startcom, CACert.

Mạng lưới tín nhiệm

Mạng lưới tín nhiệm là một mô hình dùng trong các hệ thống PGP, GnuPG,
và các hệ thống dựa trên OpenPGP để thiết lập tính xác thực của mối liên hệ giữa
khóa công khai và người sử dụng. Trong một khía cạnh nào đó, đây là một lựa
chọn thay cho mô hình hạ tầng khóa công khai tập trung (PKI) dựa trên các nhà
cung cấp chứng thư số. Cũng như mạng máy tính, tồn tại nhiều mạng lưới tín nhiệm
hoạt động độc lập với nhau. Mỗi người sử dụng trong mô hình này có thể là thành
viên của nhiều mạng và như vậy họ trở thành cầu nối giữa các mạng đó.

Tất cả các hệ thống tuân theo OpenPGP đều quy định cách thức để xem xét
các chứng thư. Các chứng thư thường được chính người dùng tạo ra cho mình
(thông qua phần mềm máy khách) và sẽ được ký xác nhận bởi những người dùng
khác nếu họ biết được rằng mối quan hệ giữa khóa công khai và định danh người
dùng trong chứng thư là đúng. Thông thường việc ký xác nhận được tiến hành
trong các buổi ký xác nhận khóa (key signing party).

32
 Các hệ thống tuân theo OpenPGP còn bao gồm các cơ chế để người dùng
quyết định sự tin tưởng vào thông tin trong một chứng thư. Chẳng hạn người dùng
sẽ tin vào một chứng thư khi chứng thư đó có tối thiểu 3 xác nhận bán phần hoặc
1 xác nhận toàn phần. Các quy định này thông thường có thể thay đổi và thậm chí
có thể được bỏ qua.

Các cơ chế mạng lưới tin cậy rất mềm dẻo và việc quyết định hoàn toàn phụ
thuộc vào từng người sử dụng. Vì thế chúng không hoàn hảo và cần được giám sát
thường xuyên bởi chính những người sử dụng. Các hệ thống hạ tầng khóa công
khai trung tâm thì trái lại. Chúng kém mềm dẻo và người dùng bắt buộc phải tuân
theo những quy định của nhà cung cấp chứng thư số trung tâm. Các hệ thống này
cũng không hoàn hảo và người dùng vẫn cần phải thận trọng khi sử dụng.

Trong mô hình PKI theo tiêu chuẩn X.509 thì mỗi chứng thư chỉ được ký bởi
một thực thể duy nhất là nhà cung cấp chứng thư số (CA). Chứng thư của CA này
có thể lại được ký bởi một nhà cung cấp chứng thư số khác cho tới CA cấp cao
nhất (tự xác nhận - root CA). Do đó, các chứng thư gốc phải được phân phối rộng
rãi và đảm bảo sẵn sàng bất cứ khi nào cần đến. Một cách phân phối đã được sử
dụng là thông qua các trình duyệt và chương trình email máy khách. Bằng cách
này, các trang web dùng giao thức SSL/TLS hay các email có thể được chứng thực
mà người dùng không cần phải cài đặt các chứng thư gốc. Ngày nay, nhiều ứng
dụng đã được cài sẵn hàng trăm chứng thư gốc của nhiều nhà cung cấp PKI khác
nhau để có thể tự động nhận dạng phần lớn các chứng thư. Tuy nhiên trong số các
chứng thư gốc được cài sẵn, một số lại thuộc về các công ty đã ngừng hoạt động
(trong thời kỳ bong bóng đầu tư dot.com chẳng hạn). Vì thế trừ trường hợp các
PKI này vẫn được quản lý tốt thì các PKI gốc đó không nên được sử dụng.

Mạng lưới tín nhiệm sẽ không bị ảnh hưởng đáng kể khi một công ty nào đó
ngừng hoạt động. Tuy nhiên cũng có nhiều vấn đề nảy sinh trong cách hoạt động
của hệ thống. Nếu một người dùng nào đó (cá nhân hoặc tổ chức) bị mất khóa bí
mật thì không thể giải mã được các thông tin gửi đến sử dụng khóa công khai trong
chứng thư của mình. Trong trường hợp này người nhận chỉ có thể hủy các thông
điệp nhận được và thông báo lại cho bên gửi để gửi lại với khóa công khai khác.
Các chứng thư PGP thời kỳ đầu hoàn toàn không có thời gian sử dụng. Các phiên

33
bản PGP về sau và các hệ thống dựa trên OpenPGP đều đã đưa thêm thời gian sử
dụng vào trong chứng thư. Việc này đã loại bỏ được một số vấn đề khi được sử
dụng hợp lý.

Do mạng lưới tín nhiệm không có thực thể đóng vai trò điều khiển trung tâm,
một vấn đề khác nảy sinh liên quan đến khía cạnh xã hội của hệ thống. Phần lớn
người sử dụng hệ thống sẽ chỉ tin tưởng vào những chứng thư đã được xác nhận
bởi một hoặc nhiều người sử dụng khác. Vì thế một người sử dụng mới sẽ không
được những người khác tin tưởng cho đến khi có một người sử dụng nào đó xác
nhận vào chứng thư mà quá trình này nhiều khi đòi hỏi có sự gặp mặt trực tiếp.
Điều này càng đặc biệt khó khăn cho những người sử dụng ở những vùng hẻo lánh
hoặc kém phát triển vì mật độ người sử dụng ở những nơi này rất thấp. Một điều
nữa cần chú ý là nếu người ký vào chứng thư cũng là người sử dụng mới hoặc
không được nhiều người biết đến thì chữ ký của họ cũng sẽ có ít giá trị. Các buổi
ký xác nhận khóa là một cơ chế tương đối mới để giải quyết vấn đề này. Tại những
buổi như vậy, người dùng có cơ hội dễ dàng hơn để tìm ra người sử dụng khác ký
xác nhận cho mình. Ngoài ra cũng có các website cung cấp những thông tin về địa
chỉ người dùng hệ thống OpenPGP để giúp cho việc ký xác nhận. Ví dụ như trang
Gossamer Spider Web of Trust giúp liên kết người sử dụng OpenPGP thông qua
việc tổ chức mạng lưới tín nhiệm theo thứ bậc.

Chứng thư số

Chứng thư số là cơ chế chứng thực sử dụng chữ ký số để gắn một chìa khoá
công khai với một thực thể (một cá nhân, một cơ quan, một công ty, một máy chủ
hay một phần mềm dịch vụ,...).

Nội dung của chứng thư số luôn bao gồm một chìa khoá công khai, một số
thông tin về chủ thể sở hữu chìa khoá công khai đó (tên, địa chỉ, đặc điểm,...) và
một chữ ký số đảm bảo mối liên kết của 2 phần thông tin đó. Chữ ký số này thuộc
về cơ quan thẩm quyền phát hành chứng thư số (Certificate Authority, viết tắt là
CA).

Để tạo ra một chứng thư số, CA phải sinh được một cặp chìa khoá phi đối
xứng có độ an toàn cao để gán cho chủ thể (người yêu cầu cấp chứng thư).Thông

34
tin trên chứng thư số của người dùng (trong đó có chìa khoá công khai) là chính
xác nếu như chữ ký số ở trong chứng thư đó là chính xác. Đây là chữ ký của CA
và để kiểm tra nó thì cần phải có thông tin chính xác về chìa khoá công khai của
CA. Thông tin này có trong chứng thư số của CA và chứng thư này luôn sẵn có
trên hệ thống, như là yêu cầu đặt ra đối với hệ thống xác thực chuẩn mực.

Hình 1.10. Chứng thư số [19]

Trong một mô hình hạ tầng khóa công khai (PKI) tiêu biểu, chữ ký trong
chứng thư thuộc về nhà cung cấp chứng thư số. Trong mô hình mạng lưới tín nhiệm
(web of trust), thì chữ ký có thể là của chính thực thể đó hoặc của một thực thể
khác. Trong bất kỳ trường hợp nào thì chữ ký trong chứng thư là sự đảm bảo của
người ký về mối liên hệ giữa khóa công khai và thực thể được chứng nhận.

Cả Liên minh Viễn thông Quốc tế (ITU) và IETF đều xây dựng các tiêu chuẩn
cho CA. ITU X.509 [ITU 2005a] chỉ định dịch vụ xác thực cũng như cú pháp cụ
thể cho chứng thư. [RFC 1422] mô tả quản lý khóa dựa trên CA để sử dụng với e-
mail Internet bảo mật. Nó tương thích với X.509 nhưng vượt xa X.509 bằng cách
thiết lập các quy trình và quy ước cho một kiến trúc quản lý khóa. Sau đây là mô
tả một số trường quan trọng trong một chứng thư.

Bảng 1.1 Chuẩn X.509

Tên thuộc tính Mô tả

35
 Version Số phiên bản của đặc tả X.509.
Serial number Định danh duy nhất cho một chứng thư số do CA phát
hành.
Signature Xác định thuật toán được sử dụng bởi CA để ký chứng
thư số này.
Issuer name Định danh của CA phát hành chứng thư số này, trong định
dạng tên phân biệt (DN)[RFC 4512].
Validity period Bắt đầu và kết thúc thời hạn hiệu lực của chứng thư số.
Subject name Định danh của chủ thể sở hữu khóa công khai liên kết với
chứng thư số này, trong định dạng DN.
Subject public key Khóa công khai của chủ thể cũng như chỉ báo về thuật
toán khóa công khai (và các tham số thuật toán) sẽ được
sử dụng với khóa này.

1.2.4 Những ưu thế và tầm quan trọng của chữ ký số

So với chữ ký thông thường (trên văn bản giấy), chữ ký số có những ưu thế
vượt trội như:

• Các ý nghĩa và thuộc tính của chữ ký viết tay (đã nêu ở trên) chỉ mang
tính lý tưởng, nhưng với chữ ký số đã trở thành hiện thưc.
• Chữ ký số là chính xác tuyệt đối (không còn mối e ngại về việc chữ ký
không giống nhau mỗi lần ký, như khi phải ký tay).
• Chữ ký số có thể được kiểm định một cách dễ dàng. Mọi sự giả mạo, gian
lận vì thế đều bị phát hiện tức khắc. (Trong khi việc kiểm định chữ ký
tay, con dấu giả,... là không đơn giản và thường đòi hỏi phương tiện kỹ
thuật đặc biệt.)

Ngày nay văn bản điện tử đang dần thay thế các văn bản giấy trên mọi bình
diện, do tính ưu việt của nó như: tra cứu dễ dàng, lưu trữ thuận tiện (với chi phí
thấp) và thuận tiện cho công tác bảo mật, luân chuyển nhanh và an toàn (khó thất
lạc), phổ biến dễ dàng, nhanh chóng và rộng khắp,... Cho nên chữ ký số là công cụ
không thể thiếu, và là điều kiện tiên quyết cho việc vận hành mọi mô hình chính
phủ điện tử mà các quốc gia trên thế giới đang hướng đến.

Tầm quan trọng đặc biệt của chữ ký số (và cũng thể hiện tính hơn hẳn của nó
so với chữ ký viết tay) là ở chỗ đảm bảo được sự tin tưởng giữa các bên đối tác,
ngay cả khi họ hoàn toàn không có lòng tin vào nhau, như trường hợp của Liên Xô
36
và Mỹ trong việc kiểm soát Hiệp ước cấm thử vũ khí hạt nhân mà hai bên đã ký
kết trong những năm cuối của thế kỷ trước.

Trước khi có công nghệ chữ ký số, việc kiểm soát là vô cùng khó khăn và
phức tạp. Khó khăn là ở chỗ bên này không có được thông tin đầy đủ về các vụ nổ
mà bên kia tiến hành (trong giới hạn cho phép), còn thông tin về các vụ nổ mà bên
này cung cấp cho bên kia (dưới dạng các dữ liệu thông tin đo đạc địa chấn) thì lại
không được bên kia tin tưởng. Đơn giản là vì bên nào cũng chỉ tin tưởng vào thông
tin máy đo của bên mình cung cấp. Khoảng cách địa lý xa xôi giữa hai bên không
cho phép đặt máy đo bên này có thể đo đạc thông tin về các vụ nổ tiến hành ở đất
bên kia. Nếu như cho phép A đặt máy đo trên đất của B rồi truyền thông tin qua
một kênh an toàn về bên A thì sẽ phát sinh lo ngại về việc máy có thể đo và cung
cấp thông tin mà bên B không kiểm soát được. Nếu cho phép bên B kiểm soát
thông tin kết quả đo thì phát sinh lo ngại về việc bên B có thể làm thay đổi thông
tin đo đạc trước khi truyền về bên A. Chính những khó khăn này đã làm cho công
tác kiểm soát của hai bên là vô cùng khó khăn và phức tạp trong những năm đầu
(khi chưa có công nghệ chữ ký số). Với công nghệ chữ ký số thì việc này hết sức
đơn giản. Người ta chỉ cần thêm vào máy đo một chức năng mới là ký số các kết
quả đo đạc của chính nó. Khi ấy bên A có thể đặt máy đo trên đất bên B và cho
phép B xem toàn bộ kết quả đo đạc của máy, mà không sợ bên B thay đổi các kết
quả này, bởi vì mọi hành vi thay đổi kết quả đo của bên B nếu có sẽ bị lật tẩy bởi
chữ ký số.

Khả năng tạo niềm tin giữa các bên đối tác (hay nói đúng hơn là làm cho họ
không thể lừa được nhau) của chữ ký số còn được thể hiện rõ nét và rộng rãi hơn
trong ứng dụng làm nên tiền mật mã, mà đại diện tiêu biểu hiện nay là đồng
Bitcoin.

37
 CHƯƠNG 2. KÝ SỐ TỪ XA

Chữ ký số dựa trên đám mây (cloud-based digital signature), hoặc “chữ ký
từ xa – Remote signature” là một thế hệ chữ ký số mới có thể hoạt động trên các
thiết bị máy tính để bàn, thiết bị di động và web - và đáp ứng mức độ tuân thủ và
đảm bảo cao nhất cho xác thực người ký. Mỗi người ký được cấp ID số dựa trên
chứng thư số cấp bởi các nhà cung cấp dịch vụ tin cậy (TSP). Khi ký số một tài
liệu, ID người dùng được sử dụng với mã PIN cá nhân và các bước xác minh khác
để chứng minh danh tính của người ký.

2.1 Ngữ cảnh về ký số từ xa

2.1.1 Giới thiệu

Điều gì thúc đẩy các giải pháp thương mại điện tử và chính phủ điện tử? Câu
trả lời rất đơn giản: các ứng dụng hữu ích và thân thiện với người dùng nhưng vẫn
đảm bảo an toàn mà có thể tiết kiệm được chi phí vận hành. Thẻ thông minh, được
sử dụng để cung cấp chữ ký số cho Giao dịch Điện tử, không bao giờ thu hút được
sự chú ý đáng kể vì thực tế là có rất ít đầu đọc thẻ thông minh xung quanh, do bản
chất tốn kém và cồng kềnh của đầu đọc.

Tuy nhiên có một cách tiếp cận thay thế: Thẻ thông minh ảo, Chữ ký trên
Đám mây hay Máy chủ Chữ ký - cụ thể là một cách tiếp cận cho phép PKI minh
bạch, giống như khi chúng ta sử dụng thẻ tín dụng hoặc thẻ ghi nợ. Cách tiếp cận
này đã thành công rực rỡ ở các quốc gia như Đan Mạch, Na Uy và Luxembourg
và nó cũng đang vươn ra bên ngoài châu Âu. Ở Đan Mạch, tất cả các công ty và
công dân bây giờ, về nguyên tắc, phải có khả năng giao tiếp điện tử với các cơ
quan chính phủ và các ngân hàng.

Rõ ràng là có những khoản tiết kiệm khổng lồ cho các cơ quan chính phủ,
các công ty, cá nhân và môi trường nếu chúng ta có thể giao tiếp - và không kém
phần cam kết và chịu trách nhiệm - bằng điện tử, sử dụng chữ ký số thay vì bằng
giấy. Tuy nhiên, chúng ta cần bắt đầu với các ứng dụng làm cho điều đó hấp dẫn
với người dùng cuối. Chúng ta đã thấy ngân hàng điện tử và mua sắm trực tuyến

38
đã trở nên phổ biến như thế nào, và nếu nghĩ về tất cả các lá thư chúng ta nhận
được trong suốt cả năm từ các cơ quan công quyền, ví dụ như về các loại thuế khác
nhau, đăng ký bỏ phiếu, lương hưu, v.v., chúng ta bắt đầu hiểu được tầm quan
trọng của việc số hóa.

2.1.2 Thách thức

Những gì bạn thấy là những gì bạn ký

Khi ký điện tử vào một tài liệu, tính toàn vẹn của chữ ký không chỉ phụ thuộc
vào tính hợp lý của các thuật toán chữ ký số được sử dụng, mà còn dựa vào tính
bảo mật của nền tảng máy tính được sử dụng để ký tài liệu. Thuộc tính WYSIWYS
(What You See Is What You Sign) của các hệ thống chữ ký số nhằm giải quyết
vấn đề này bằng cách định nghĩa một thuộc tính mong muốn rằng sự thể hiện trực
quan của tài liệu số phải nhất quán trên các hệ thống máy tính, đặc biệt là ở các
điểm tạo chữ ký số và xác minh chữ ký số.

Việc thay đổi cách thể hiện của một tài liệu kỹ thuật số là tương đối dễ dàng
bằng cách thực hiện các thay đổi trên hệ thống máy tính nơi tài liệu đang được xử
lý. Từ góc độ ngữ nghĩa, điều này tạo ra sự không chắc chắn về những gì chính
xác được ký. WYSIWYS là một thuộc tính của hệ thống chữ ký số đảm bảo rằng
cách biểu diễn ngữ nghĩa của một thông điệp được ký điện tử không thể thay đổi,
dù là do vô tình hay cố ý. Thuộc tính này cũng đảm bảo rằng một tài liệu kỹ thuật
số được ký không thể chứa nội dung ngữ nghĩa ẩn có thể bị tiết lộ sau khi chữ ký
đã được áp dụng. Mặc dù việc triển khai WYSIWYS chỉ an toàn tương đương với
nền tảng máy tính mà nó đang chạy, nhưng nhiều phương pháp khác nhau đã được
đề xuất để làm cho WYSIWYS mạnh mẽ hơn.

Lưu trữ, Truy cập và Tạo chữ ký an toàn

Bất kể kiến trúc tổng thể là gì, điều cực kỳ quan trọng là các khóa bí mật
được lưu trữ an toàn và theo cách mà chỉ chủ sở hữu mới có thể truy cập để tạo
chữ ký và chữ ký được tạo ra trong một môi trường được bảo vệ.

Vào cuối những năm 90, người ta thường chấp nhận rằng cách khả thi duy
nhất là sử dụng thẻ thông minh cho việc này. Tuy nhiên, có những phương tiện để

39
bảo vệ các khóa bí mật có khả năng chống chịu cao hơn nhiều đối với các cuộc tấn
công khác nhau vào khóa, gọi là mô-đun bảo mật phần cứng (HSMs). Chúng đã
được sử dụng rộng rãi bởi các ngân hàng trên toàn thế giới.

2.1.3 Những ưu thế của giải pháp ký số từ xa

Tính di động và giảm thiểu chi phí

Ưu điểm nổi bật nhất của chữ ký trên đám mây là người dùng không bị giới
hạn trong một máy trạm hoặc máy tính xách tay cụ thể, điều này làm cho nó trở
thành một giải pháp thực sự linh hoạt. Một lợi thế khác là nếu bạn đã có cơ sở hạ
tầng và các ứng dụng, rất hiệu quả về chi phí để thêm nhiều người dùng hơn vì bạn
không cần thêm bất kỳ phần cứng bổ sung nào.

Tính bảo mật

Với một máy chủ chữ ký trung tâm, còn được gọi là chữ ký trên đám mây,
thách thức đối với người dùng cá nhân là đảm bảo rằng:

1. Người dùng được xác thực một cách hợp lý trước khi có thể ký tin nhắn.

2. Chỉ có chủ sở hữu khóa bí mật cụ thể mới có thể khởi tạo tính toán chữ ký.

3. WYSIWYS.

Để đạt được điều này, cách tiếp cận an toàn nhất là có hai máy chủ độc lập,
một để xác thực và một để ký.

Chúng thậm chí có thể nằm ở các môi trường khác nhau với một kênh an toàn
kết nối chúng. Trên thực tế, máy chủ chữ ký có thể được kết nối với một số máy
chủ xác thực khác nhau. Mỗi máy chủ được hỗ trợ bởi các mô-đun bảo mật phần
cứng (HSMs), và tất cả các tính toán và xác minh an toàn được thực hiện hoàn toàn
bởi và trong một HSM. Điều này rất giống với các giao dịch thẻ ghi nợ và thẻ tín
dụng đang được các ngân hàng ủy quyền.

Ưu điểm của việc này là người ta sẽ có đầy đủ các cơ chế xác thực khác nhau
có sẵn. Dưới đây là ví dụ sử dụng đơn giản của kịch bản này:

Người dùng tạo ra một tin nhắn để ký trên máy tính bảng hoặc máy trạm và
chuyển tiếp yêu cầu ký kết đến máy chủ xác thực cùng với một phương thức xác

40
thực mạnh ưa thích để xác minh người dùng. Máy chủ xác thực xác minh danh tính
của người dùng và, nếu thành công, chuyển tiếp để tạo chữ ký.

Máy chủ chữ ký chuyển tiếp một bản sao của tin nhắn đến thiết bị di động
của người dùng cùng với mã ủy quyền gồm 6 ký tự. Nếu người dùng hài lòng
anh/cô ta nhập mã này và chữ ký được tạo bởi máy chủ chữ ký thông qua một
đường hầm TLS an toàn vào máy chủ xác thực.

Nếu Máy chủ xác thực và Máy chủ chữ ký ở các môi trường khác nhau, điều
này cho phép hai ghi chép nhật ký độc lập khi người dùng khởi tạo ký, vì vậy hệ
thống biết chính xác khi nào điều này xảy ra, trái ngược với cách tiếp cận thẻ thông
minh.

Do đó, WYSIWYS đạt được bằng khả năng so sánh các phiên bản đã ký
trong mỗi kênh và quan sát thấy chúng giống hệt nhau.

Tính minh bạch

Hơn thế nữa, giải pháp này cho phép bạn đơn giản hóa những khó khăn và
thiếu sót của một giải pháp PKI truyền thống, nơi mọi người về nguyên tắc có thể
giao tiếp an toàn với mọi người.

Do đó, tất cả các ứng dụng sử dụng cơ sở hạ tầng này về nguyên tắc sẽ có thể
nhận biết rằng chữ ký nhận được có phải từ một người dùng khác đã được tạo trên
máy chủ bảo mật không thay vì thẻ thông minh hoặc thậm chí tệ hơn, trong phần
mềm. Điều này rõ ràng đòi hỏi việc lưu trữ an toàn khóa công khai của CA - nhưng
đó sẽ luôn là vấn đề với PKI.

Chứng thư hết hạn/bị thu hồi không còn là vấn đề

Chứng thư giống như giấy phép lái xe: chúng có vẻ như nói điều gì đó về
tương lai, nhưng thực chất chúng chỉ nói về quá khứ. Ví dụ, tương đối dễ dàng cho
một người để có được một bản sao gốc của giấy phép lái xe của mình, chỉ cần đi
đến cơ quan thích hợp và giải thích bạn đã mất nó. Bây giờ người đó có hai giấy
phép lái xe. Nếu giấy phép của của người đó bị thu hồi, chỉ cần trả lại giấy phép
mới nhất. Người đó vẫn có thể thuê một chiếc xe với giấy phép ban đầu như thường
nếu như không có một cuộc kiểm tra nào được thực hiện trên một cơ sở dữ liệu
trung tâm.
41
 Tương tự như vậy, nếu bạn nhận được chữ ký số, bạn phải tự hỏi: tôi có thể
dựa vào nó hay có thể khóa bí mật được sử dụng để tạo ra nó đã bị thu hồi sau hoặc
thậm chí trước khi chữ ký được tạo ra không? Mấu chốt là tất cả những gì một
chứng thư cho bạn biết là tại một số thời điểm trong quá khứ khóa bí mật tương
ứng là hợp lệ. Nhưng để xác định rằng khóa bí mật vẫn còn hiệu lực tại thời điểm
chữ ký được cho là được tạo ra, bạn cần liên hệ với CA, ví dụ thông qua OCSP
(Giao thức trạng thái chứng thư trực tuyến) để hỏi xem liệu khóa đã bị thu hồi vào
thời điểm đó.

Với cách tiếp cận ký tập trung, vấn đề này biến mất ngoại trừ một khoảng
thời gian bù trừ giao dịch rất ngắn. Thật vậy, với cách tiếp cận ký tập trung, trong
vòng mili giây chứng thư bị CA thu hồi, máy chủ chữ ký trung tâm được CA thông
báo và yêu cầu từ người dùng để ký bằng khóa bí mật của anh ta không còn được
chấp nhận.

Nhãn thời gian độc lập không còn cần thiết

Hãy xem xét kịch bản bạn là người dùng giải pháp PKI truyền thống, nơi mọi
người dùng đều có khóa bí mật trên thẻ thông minh thuộc sở hữu cá nhân của mình.
Giả sử bạn nhận được chữ ký số từ Alice vào ngày 1 tháng 12 năm 2014, cam kết
rằng cô ấy sẽ trả cho bạn €1000 vào ngày 1 tháng 4 năm 2015. Sau đó, bạn hỏi, giả
sử vào ngày 2 tháng 12, với CA rằng chứng thư của cô ấy đã bị thu hồi không, và
câu trả lời là không. Ngày 1 tháng 4 đến, không nhận được tiền, bạn liên lạc với
Alice, và cô ấy nói rằng Bob sống bên cạnh có khả năng đã đánh cắp thẻ thông
minh của cô ấy trong năm mới. Alice cho rằng đã thu hồi khóa của mình vào ngày
2 tháng 1, nhưng dường như có một luồng chữ ký số liên tục được tạo ra bằng khóa
riêng của cô sau đó.

Tất nhiên bạn có thể biết rằng Alice đang nói dối, vì bạn biết khi nào bạn
thực sự nhận được chữ ký - nhưng nếu không có biện pháp bổ sung, bạn không thể
chứng minh điều đó!

Đây là lý do tại sao nhãn thời gian độc lập là cần thiết trong một giải pháp
PKI truyền thống. Bạn cần gửi tất cả các chữ ký nhận được cho một cơ quan độc
lập của bên thứ ba để ghi nhãn thời gian độc lập - cách tiếp cận phổ biến nhất được

42
đề xuất - hoặc có các phương tiện khác để chứng minh thời điểm nhận được chữ
ký. Đáng buồn thay, đây vẫn không phải là một rủi ro được hiểu rõ.

2.1.4 Tính pháp lý ở EU

Quy chuẩn số 910/2014 của Nghị viện châu Âu và của Hội đồng ngày 23
tháng 7 năm 2014 về dịch vụ nhận dạng và ủy thác điện tử cho các giao dịch điện
tử trên thị trường nội bộ, thường được gọi là "Quy chuẩn eIDAS", cung cấp một
khung pháp lý chung cho chữ ký điện tử trong EU. Nó nhằm mục đích giúp công
dân và doanh nghiệp trong các quốc gia thành viên EU dễ dàng cung cấp các giao
dịch điện tử và các tài liệu được ký kỹ thuật số khác tình trạng pháp lý tương tự
như các giao dịch dựa trên giấy tờ.

Theo quy chuẩn, eIDAS bao gồm toàn bộ chuỗi tin cậy bao gồm niêm phong,
xác nhận, gán nhãn thời gian và ký tập trung, làm cho nó phù hợp hơn với việc
cung cấp trải nghiệm người dùng thân thiện với thiết bị di động.

Ủy ban Châu Âu đã thiết lập các tiêu chuẩn xung quanh việc ký máy chủ
trung tâm và ký thẻ thông minh để cung cấp một khuôn khổ pháp lý rõ ràng cho
việc triển khai công nghệ này. Để thực hiện ký tập trung tuân thủ eIDAS, có một
số tiêu chuẩn CEN và ETSI, chẳng hạn như TS 419 241: 2014, cần được tuân thủ.

Công nghệ ký điện tử phải trải qua một cuộc kiểm toán được thực hiện bởi
một giám định viên bảo mật được công nhận bởi một cơ quan giám sát nếu một
doanh nghiệp muốn được chứng nhận là cung cấp chữ ký điện tử tiên tiến hoặc đủ
điều kiện.

2.2 Hệ sinh thái và mô hình tổng thể ký số từ xa

Như được minh họa trong Hình 2.1, "Hệ sinh thái eIDAS" được cư trú bởi
"Người dùng", sử dụng một số loại "Dịch vụ Giao dịch dựa trên eIDAS". Các Dịch
vụ Giao dịch này lần lượt có thể sử dụng một loạt các "Dịch vụ eIDAS", trong đó
sự tin cậy được duy trì bởi "Hệ thống Tin cậy eIDAS".

43
 Hình 2.1 Hệ thống tin cậy eIDAS

"Hệ thống tin cậy eIDAS" cung cấp nền tảng đáng tin cậy cho toàn bộ "Hệ
sinh thái eIDAS" bằng sự kết hợp thích hợp của các biện pháp bao gồm công nhận,
đánh giá sự phù hợp, giám sát và xử lý sự cố.

"Dịch vụ eIDAS" bao gồm "Dịch vụ eID" cho nhận dạng điện tử được quy
định bởi Chương II và một loạt các "Dịch vụ Ủy thác" theo Điều 3 và được quy
định bởi Chương III của Quy chuẩn eIDAS. Các dịch vụ này cụ thể bao gồm:

• "Dịch vụ tạo chữ ký và niêm phong" (SigS)

• "Dịch vụ xác thực" (ValS)
• "Dịch vụ bảo lưu" (PresS)
• "Dịch vụ giao hàng điện tử" (EDS)
• "Cơ quan nhãn thời gian" (TSA)
• "Cơ quan chứng nhận" (CA)

2.2.1 Dịch vụ eID

"Dịch vụ eID" cung cấp các dịch vụ cho việc nhận dạng và xác thực điện tử
an toàn của người dùng và pháp nhân. Các phương tiện và dịch vụ được sử dụng
để định danh và xác thực điện tử bao gồm các chương trình định danh điện tử, đã

44
được thông báo theo Điều 9 cũng như các chương trình khác. Theo quy định tại
Điều 8 của Quy chuẩn eIDAS và đạo luật thực thi liên quan CIR (EU) 2015/1502,
độ tin cậy của một chương trình nhận dạng điện tử và các phương tiện nhận dạng
được triển khai bên trong, được phản ánh trong mức độ đảm bảo của nó. Các mức
độ đảm bảo được chỉ định dao động từ "thấp" qua "đáng kể" đến "cao". Các chương
trình eID được thông báo cung cấp ít nhất một mức độ đảm bảo đáng kể sẽ được
công nhận lẫn nhau trong các giao dịch xuyên biên giới theo Điều 6 của Quy chuẩn
eIDAS.

2.2.2 Cơ quan chứng nhận (CA)

Cơ quan chứng nhận (CA) tạo chứng thư điện tử và cấp chúng cho Người
dùng hoặc các thực thể khác, thường được gọi là Chủ thể của chứng thư. Việc này
có thể diễn ra trực tiếp, thông qua "Dịch vụ giao dịch dựa trên eIDAS" hoặc "Dịch
vụ tạo chữ ký và con dấu" (SigS). SigS tương tác với hệ thống CA, thực hiện nhận
dạng thích hợp Chủ thể và xác nhận các thuộc tính nhận dạng được cung cấp, được
kết hợp với khóa công khai và được CA ký để tạo chứng thư.

2.2.3 Cơ quan nhãn thời gian (TSA)

Chứng minh sự tồn tại của một bộ dữ liệu kỹ thuật số nhất định tại một thời
điểm nhất định là một yêu cầu cơ bản trong nhiều giao dịch điện tử, bao gồm chữ
ký điện tử, các khía cạnh quản lý quyền kỹ thuật số, hợp đồng điện tử hoặc yêu
cầu trách nhiệm giải trình chẳng hạn. Với mục đích này, Cơ quan Nhãn Thời gian
(TSA) nhận dữ liệu cần được gán nhãn thời gian hoặc một mã băm của nó, và trả
về mã thông báo nhãn thời gian, được ký bởi TSA.

2.2.4 Dịch vụ tạo và niêm phong chữ ký (SigS)

Dịch vụ tạo chữ ký và niêm phong (SigS) cho phép tạo chữ ký điện tử (đủ
điều kiện) theo Mục 4 và (đủ điều kiện) con dấu điện tử theo Mục 5 của Quy chuẩn
eIDAS ở các định dạng kỹ thuật như CAdES, XAdES và PAdES chẳng hạn.

45
2.2.5 Dịch vụ Xác minh (ValS)
Các chữ ký và con dấu điện tử (đủ điều kiện) được tạo bằng SigS ở trên có
thể được xác minh với Dịch vụ xác minh (ValS). ValS sử dụng các chứng thư có
trong Danh sách tin cậy theo Điều 22 của Quy chuẩn eIDAS, Đạo luật thực hiện
tương ứng CID (EU) 2015/1506 và ETSI TS 119 162 (v2.1.1) làm neo ủy thác và
thực hiện xác thực chữ ký theo EN 319 102-1 bằng chính sách xác nhận phù hợp.

2.2.6 Dịch vụ bảo lưu (PresS)

Việc lưu giữ lâu dài các tài liệu đã ký đòi hỏi một hình thức giữ an toàn đảm
bảo tính rõ ràng và khả năng kết luận bất kể phương tiện lưu trữ. Để đảm bảo tính
hợp pháp của chữ ký điện tử và con dấu điện tử trong thời gian dài, người ta cần
áp dụng các kỹ thuật bảo lưu phù hợp như trong ETSI SR 019 510.

Các kỹ thuật bảo lưu được thực hiện bởi Dịch vụ Bảo lưu (PresS) theo Điều
34 có thể liên quan đến Hồ sơ Bằng chứng theo RFC 4998 hoặc RFC 6283 hoặc
tăng cường liên tục chữ ký bằng cách sử dụng nhãn thời gian lưu trữ theo CAdES
hoặc XAdES chẳng hạn.

2.2.7 Dịch vụ giao hàng điện tử (EDS)

Trong một thế giới dựa trên giấy tờ, cách duy nhất để biết rằng một lá thư
thực sự đã đến được người nhận là gửi nó qua hộp thư đã đăng ký. Đây là một dịch
vụ được cung cấp bởi các nhà cung cấp dịch vụ thư. Người gửi viết ra các tuyên
bố của mình trên một tờ giấy và đặt nó vào một phong bì kín, được đánh dấu bằng
tọa độ của người nhận và gửi nó qua đường bưu điện. Trách nhiệm giải trình, tính
bảo mật và tính toàn vẹn của bức thư chủ yếu được đảm bảo bởi tác giả, trong khi
các nhà cung cấp dịch vụ thư chủ yếu đảm bảo tính khả dụng và giao hàng chính
xác.

Theo Điều 44 của Quy chuẩn eIDAS "dịch vụ giao hàng đăng ký điện tử đủ
điều kiện phải đáp ứng các yêu cầu sau:

• Chúng được cung cấp bởi một hoặc nhiều nhà cung cấp dịch vụ ủy thác đủ
điều kiện;

46
 • Họ đảm bảo với mức độ tin cậy cao về nhận dạng của người gửi;
• Họ đảm bảo việc xác định người nhận trước khi cung cấp dữ liệu;
• Việc gửi và nhận dữ liệu được bảo mật bằng chữ ký điện tử tiên tiến hoặc
con dấu điện tử tiên tiến của nhà cung cấp dịch vụ ủy thác đủ điều kiện theo
cách ngăn chặn khả năng thay đổi dữ liệu mà không bị phát hiện;
• Bất kỳ thay đổi dữ liệu cần thiết cho mục đích gửi hoặc nhận dữ liệu được
chỉ định rõ ràng cho người gửi và người nhận dữ liệu;
• Ngày, giờ gửi, nhận và bất kỳ thay đổi dữ liệu nào được ghi bằng nhãn thời
gian điện tử đủ điều kiện".

Với những yêu cầu này, rõ ràng là EDS cần sử dụng một loạt các Dịch vụ
eIDAS khác như eID-Service, SigS, TSA, ValS và thông tin trạng thái chứng chỉ
do CA cung cấp.

2.3 Mô tả các Tiêu chuẩn

Quy chuẩn eIDAS đã bổ sung nhiều dịch vụ ủy thác mới và các khía cạnh
của nhận dạng điện tử (eID) vào khuôn khổ châu Âu hiện có cho chữ ký điện tử và
nhãn thời gian. Ngoài chữ ký từ xa được đề cập trong điều (52), các dịch vụ xác
minh và bảo quản lâu dài chữ ký và con dấu đã được bao gồm trong các mục 33,
34 và 40 của Quy chuẩn eIDAS. Để tạo điều kiện thuận lợi cho việc sử dụng thực
tế các dịch vụ ủy thác mới này một cách tương thích và cung cấp một nền tảng
vững chắc cho một hệ sinh thái eIDAS thịnh vượng và bền vững, các ủy ban tiêu
chuẩn hóa chịu trách nhiệm về các công nghệ chữ ký điện tử tại OASIS (Dịch vụ
chữ ký số eXtended, DSS-X) và ETSI (Chữ ký và Cơ sở hạ tầng điện tử, ESI) gần
đây đã áp dụng các tiêu chuẩn API cho việc tạo ra, xác minh và bảo quản lâu dài
chữ ký, con dấu, nhãn thời gian và hồ sơ chứng cứ.

47
 Hình 2.2 Tổng quan về các tiêu chuẩn chữ ký

Như được mô tả trong Hình 2.2, các tiêu chuẩn API mới cung cấp giao diện
lập trình cho các dịch vụ chính trong hệ sinh thái eIDAS. Chữ ký và con dấu có
thể được tạo thông qua Dịch vụ tạo và niêm phong chữ ký (SigS), được xác minh
thông qua Dịch vụ Xác minh (ValS) và cuối cùng được bảo quản trong thời gian
dài với Dịch vụ Bảo quản (PresS). Các hệ thống ứng dụng sử dụng các API dựa
trên dịch vụ web được phát triển bởi ETSI ESI và OASIS DSS-X. Trong khi các
giao diện cho việc tạo (ETSI TS 119 432) và xác nhận chữ ký và con dấu điện tử
(ETSI TS 119 442) dựa trên phiên bản mới 2.0 des OASIS DSS-X Core, chỉ có
các tệp lược đồ cơ bản được tạo bởi OASIS ("Base" và "Metadata") đã được nhập
và mở rộng để định nghĩa giao diện của Dịch vụ bảo quản (ETSI TS 119 512).
Ngoài các thông số kỹ thuật giao diện kỹ thuật được xem xét chi tiết hơn dưới đây,
ETSI TS 119 431 (phần 1 và phần 2), ETSI TS 119 441 và ETSI TS 119 511 quy
định các yêu cầu chính sách và bảo mật tương ứng, tạo cơ sở cho việc đánh giá sự
phù hợp của các dịch vụ ủy thác liên quan (đủ điều kiện) theo Quy chuẩn eIDAS.

2.3.1 Tiêu chuẩn bảo mật 419 241-1

Tiêu chuẩn bảo mật 419 241-1 định nghĩa một tập hợp các yêu cầu và đề xuất
bảo mật để có một hệ thống đáng tin cậy được tạo ra ở phía máy chủ ứng dụng ký
số (Trustworthy System Supporting Server Signing (TW4S)). Định nghĩa chi tiết
trong tài liệu prEN 419 241-1.

Tài liệu prEN 419 241-1 cung cấp các mô hình chức năng thường được công
nhận của TW4S, chỉ định các yêu cầu tổng thể áp dụng trên tất cả các dịch vụ được
48
xác định trong mô hình chức năng, chỉ định các yêu cầu bảo mật cho từng dịch vụ
được xác định trong SSA, chỉ định các yêu cầu bảo mật cho các thành phần hệ
thống nhạy cảm có thể được SSA sử dụng (ví dụ: Thiết bị tạo chữ ký (SCDev)).

Lưu ý: Các khía cạnh sau đây được coi là ngoài phạm vi của tài liệu prEN
419 241-1: Các dịch vụ đáng tin cậy khác có thể được sử dụng cùng với dịch vụ
này như dịch vụ xác thực chữ ký, dịch vụ đánh dấu thời gian và dịch vụ bảo quản
thông tin, bất kỳ ứng dụng hoặc hệ thống nào bên ngoài SSA, giải thích pháp lý
của bất kỳ hình thức chữ ký nào (ví dụ: ý nghĩa của chữ ký, của nhiều chữ ký và
chữ ký bao gồm các cấu trúc thông tin phức tạp có chứa các chữ ký khác).

2.3.2 Tiêu chuẩn bảo mật 419 241-2

Tiêu chuẩn 419 241-2 đặc tả cấu hình bảo vệ cho Signature Activation
Module (SAM), module này có chức năng điều khiển việc truy cập khóa bí mật
cho người dùng, nhằm đáp ứng các yêu cầu của QSCD như được chỉ định trong
Quy chuẩn (EU) số 910/2014 [eIDAS] (Định nghĩa chi tiết trong tài liệu prEN 419
241-2:2017 được trình bày bởi Technical Committee CEN/TC 224).

2.3.3 Tiêu chuẩn bảo mật 119 431

Tiêu chuẩn ETSI TS 119 431-1 v1.1.1 chỉ định các yêu cầu về chính sách và
bảo mật cho TSP nhằm triển khai hệ thống dịch vụ vận hành tạo chữ ký số từ xa
(SCDev). Những yêu cầu này áp dụng cho khi thiết bị là QSCD được quy định
trong (EU) No 910/2014. Tiêu chuẩn ETSI EN 319 411-1 phù hợp các yêu cầu
chính sách và tài liệu tuyên bố thực hành áp dụng cho các TSPs.

Các yêu cầu về chính sách và bảo mật được xác định theo việc tạo, duy trì,
quản lý vòng đời và việc sử dụng khoá trong tạo chữ ký số.

Tiêu chuẩn này được sử dụng cho các cơ quan độc lập làm cơ sở cho việc
đánh giá sự phù hợp của TSP để có thể tin cậy vận hành QSCD/SCDev từ xa.

Tiêu chuẩn không chỉ định giao thức truy cập SSASC. Tiêu chuẩn hiện tại
xác định các kiểm soát cụ thể cần thiết để giải quyết các rủi ro liên quan đến các
dịch vụ hoạt động từ xa QSCD / SCDev.

49
 Tiêu chuẩn có tham chiếu tới tiêu chuẩn CEN EN 419 214-1 (chỉ định mức
độ an toàn cho việc kiểm soát duy nhất). Thuật ngữ “sole control – kiểm soát duy
nhất” không có nghĩa chỉ áp dụng cho chữ ký điện tử theo quy chuẩn (EU) No
910/2014 được giải thích trong tiêu chuẩn CEN EN 4190241-1 điều 5.3. Các yêu
cầu này còn có thể áp dụng cho con dấu điện tử.

2.3.4 Tiêu chuẩn bảo mật 119 432

Tài liệu ETSI TS 119 432 đặc tả các giao thức và các giao tiếp đối với quy
trình tạo chữ ký số chuẩn AdES (Được định nghĩa trong tài liệu ETSI TS 119 102-
1 [i.7]) và/hoặc chữ ký số DSV (Digital Signature Value) là kết quả của Đại diện
cho tài liệu cần ký số DTBSR (Data To Be Signed Representation). Được thực
hiện trên máy chủ dịch vụ ký số đặt từ xa, sử dụng giải pháp phân tán Cloud PKI
bao gồm hai hoặc nhiều hệ thống/dịch vụ/thành phần.

Đặc tả kỹ thuật của tiêu chuẩn ETSI TS 119 432 chỉ giới hạn ở việc ký số tạo
chữ ký số trên máy chủ đặt từ xa, tức là khóa mật mã để ký được lưu giữ quản lý
từ một hệ thống dịch vụ chia sẻ ở xa người ký.

Lưu ý: Việc ký số từ xa nhưng quá trình tạo chữ ký số được thực hiện bởi
trạm đầu cuối (thiết bị cá nhân của người ký), như là khóa mật mã để ký được lưu
giữ quản lý ở tại thiết bị đầu cuối của người ký còn các bước thực hiện thủ tục ký
số được thực hiện từ các dịch vụ trên mạng Internet không thuộc phạm vi tài liệu
này. Tài liệu ETSI TS 119 432 đặc tả các giao thức với hai định dạng: XML và
JSON. Giao thức cho phép yêu cầu tạo và trả về kết quả cho các định dạng chữ ký
số AdES sau đây:

• Dạng Digital Signature Values (General)

• Dạng CadES (CMS)
• Dạng PadES (PDF)
• Dạng XadES (XML)

Giao thức hỗ trợ cả hai phương thức đồng bộ và dị bộ cho quản lý các yêu
cầu và phản hồi.

Giao thức hỗ trợ tạo ra chữ ký số đính kèm và không đính kèm nội dung.

50
 Các giao thức trong tài liệu này sử dụng lại hệ thống cấu trúc theo những đặc
tả XML CSC JSON và OASIS DSS-X. Những trường hợp không thể sử dụng lại,
tài liệu này xây dựng thêm đặc tả ngữ nghĩa và cú pháp theo hai định dạng: XML
và JSON. Cho các thành phần mới.

Việc xác thực quyền sử dụng khóa mật mã tạo chữ ký số của người ký yêu
cầu cơ chế kiểm tra nhiều lớp để đảm bảo sự kiểm soát người ký hợp lệ. Cách thức
quy trình xác thực người ký được thực hiện bởi nhà cung cấp dịch vụ bằng các cơ
chế xác thực đa nhân tố không thuộc phạm vi tài liệu này.

2.3.5 Tiêu chuẩn bảo mật 419 221-5

Đây là tiêu chuẩn bảo mật áp dụng cho mô đun mật mã HSM.

Protection Profile (PP) - Hồ sơ bảo vệ, xác định yêu cầu bảo mật cho các mô-
đun mật mã sử dụng bởi nhà cung cấp dịch vụ tin cậy, hỗ trợ ký điện tử và dịch vụ
xác thực. Nó bao gồm hỗ trợ tùy chọn để sao lưu khóa được bảo vệ.

Protection Profile hỗ trợ các nhà cung cấp dịch vụ tin cậy được xác định theo
quy định đề xuất của Nghị viện Châu Âu và của Hội đồng về nhận dạng điện tử và
dịch vụ tin cậy cho các giao dịch điện tử trên thị trường nội bộ châu Âu (eIDAS).

TOE (Target of Evaluation) là mô đun bảo mật, tạo và/hoặc bảo vệ khóa bí
mật cũng như các dữ liệu nhạy cảm khác và cho phép việc kiểm soát các dữ liệu
hoặc các service mật mã được hỗ trợ bởi nhà cung cấp dịch vụ.

51
 Hình 2.3 Kiến trúc TOE của HSM

Có thể xem kiến trúc của TOE là định hướng chung mà các nhà sản xuất
HSM phải tuân thủ để đạt chứng nhận PP-5. TOE là một tập các phần mềm và
phần cứng được cấu hình.

2.4 Các thành phần và quy trình ký số từ xa

2.4.1 Các thành phần

Nhà cung cấp dịch vụ CA

• Cung cấp module Server Signing Application (máy chủ ứng dụng ký số).
Module này cần tuân thủ tiêu chuẩn bảo mật EN 419 241-1.
• Cung cấp module Signature Activation Module (SAM) có chức năng điều
khiển việc truy cập khóa bí mật người dung. Module này cần tuân thủ tiêu
chuẩn 419 241-2.
• Cung cấp Crypto Module. Đây còn gọi là module HSM có chức năng sinh
khóa và mã hóa khóa người dùng. Module này cần tuân thủ tiêu chuẩn bảo
mật PP (Protection Profile) 419 221-5.

52
Người sử dụng

• Đăng ký sử dụng, được cấp chứng thư số cho dịch vụ ký số từ xa.

• Xác thực quyền ký số trên thiết bị di động cá nhân (Signer Interaction
Component).
• Thực hiện ký số từ xa theo dịch vụ.

Thông tin trao đổi giữa thiết bị di động cá nhân (Signer Interaction
Component) và máy chủ ứng dụng ký số (Server Signing Application) cần tuân
theo giao thức TS 119 432.

Quy trình tạo chữ ký đưa ra các kịch bản mà chữ ký số AdES và/hoặc chữ ký
số (DSV) được tạo ra bằng cách sử dụng khóa mật mã tạo chữ ký số được lưu giữ
quản lý trong một mô-đun mật mã gọi là Thiết bị tạo chữ ký số (SCDev) và được
vận hành bởi Nhà cung cấp dịch vụ tạo chữ ký số (SCSP).

Dựa trên phân loại quản lý dữ liệu khác nhau trong các lệnh và phản hồi, hai
cấu phần chính trong sơ đồ quy trình trên cung cấp các giao diện khác nhau cho
quá trình ký số: Thành phần dịch vụ ứng dụng máy chủ ký số (SSASC) và Thành
phần dịch vụ ứng dụng tạo chữ ký số (SCASC) được đặc tả sau đây.

SSASC

SSASC là thành phần hỗ trợ tạo chữ ký số (DVS). SSASC có khả năng tương
tác với SCDev đang quản lý khóa riêng của người ký. Khi SSASC sử dụng SCDev,
người ký có khả năng kiểm soát khóa mật mã tạo chữ ký số với các cấp độ tin cậy
xác định. Đầu vào chính cho giao diện SSASC là Đại diện dữ liệu cần ký số
(DTBSR) và các tham số khác hỗ trợ và đầu ra chính là chữ ký số (DVS).

SCASC

SCASC là cấu phần hỗ trợ tạo chữ ký số AdES và thực hiện một số chức
năng cụ thể của quy trình tạo chữ ký số. SCASC có khả năng tương tác với SSASC
cho lệnh tạo chữ ký số (DVS).

Giao tiếp với SCASC là các tài liệu cần được ký số (SD) hoặc đại diện của
các tài liệu cần được ký số (SDR) và các tham số khác là đầu vào chính và các tài
liệu đã ký số hoặc các chữ ký số (DVS) là đầu ra chính.

53
 SCS chỉ dịch vụ TSP triển khai Ứng dụng Tạo chữ ký số (SCA) và/hoặc ứng
dụng máy chủ ký số (SSA).

Một số tùy chọn giao tiếp tùy thuộc vào sự phân chia chức năng giữa SCS và
phía hệ thống cục bộ từ người ký.

2.4.2 Quy trình ký số từ xa

Quy trình sinh khóa

• Người dùng xác thực quyền trên ứng dụng của thiết bị di động cá nhân.
• Ứng dụng trên thiết bị di động cá nhân gửi thông tin và yêu cầu sinh khóa
về server.
• Server tiếp nhận và sử dụng thông tin, sinh cặp khóa tại HSM và chia sẻ với
ứng dụng trên thiết bị di động cá nhân.
• Hệ thống đồng bộ thông tin, xác nhận sinh khóa thành công, lưu trữ thông
tin người dùng vào CSDL và công bố chính thức cặp khóa.
• Sử dụng cặp khóa đã được hệ thống công bố để tạo request và cấp chứng
thư số.

Quy trình ký số

• Người dùng gửi yêu cầu ký số dữ liệu về hệ thống.

• Hệ thống xử lý yêu cầu và bắt buộc người dùng xác thực quyền qua ứng
dụng trên thiết bị di động cá nhân.
• Hệ thống kiểm tra tính hợp lệ và thực hiện ký số đối với dữ liệu của người
dùng.
• Hệ thống trả về dữ liệu đã được ký số, thông báo đến người dùng ký số
thành công.

54
2.5 Tình hình thực tế ở Việt Nam

2.5.1 Tình hình phát triển và ứng dụng chữ ký số

Quản lý nhà nước về chữ ký số và dịch vụ chứng thực chữ ký số

Thời gian qua, Chính phủ đã ban hành nhiều văn bản như Nghị định số
130/2018/NĐ-CP ngày 27/9/2018 quy định chi tiết thi hành Luật Giao dịch điện
tử về chữ ký số và dịch vụ chứng thực chữ ký số; Nghị định số 119/2018/NĐ-CP
ngày 12/9/2018 quy định về hóa đơn điện tử khi bán hàng hóa, cung cấp dịch vụ;
Nghị định số 165/2018/NĐ-CP ngày 24/12/2018 về giao dịch điện tử trong hoạt
động tài chính; Quyết định số 28/2018/QĐ-TTg ngày 12/7/2018 của Thủ tướng
Chính phủ về việc gửi, nhận văn bản điện tử giữa các cơ quan trong hệ thống hành
chính nhà nước; Nghị quyết số 17/NQ-CP ngày 07/3/2019 về một số nhiệm vụ,
giải pháp trọng tâm phát triển Chính phủ điện tử giai đoạn 2019 – 2020, định hướng
đến 2025; Quyết định số 274/QĐ-TTg ngày 12/3/2019 của Thủ tướng Chính phủ
phê duyệt Đề án Cổng Dịch vụ công quốc gia là những văn bản quy phạm pháp
luật và văn bản chỉ đạo quan trọng, làm căn cứ cho việc xây dựng và phát triển
Chính phủ điện tử, hướng tới Chính phủ số, nền kinh tế số, trong đó chữ ký số là
một thành tố quan trọng đảm bảo tính pháp lý, bảo mật cho giao dịch điện tử của
người dân, doanh nghiệp và cơ quan, tổ chức.

Nhà nước định hướng về chữ ký số, dịch vụ chứng thực chữ ký số và xác
thực điện tử trong thời gian tới:

• Nghiên cứu, đề xuất giải pháp thúc đẩy phát triển thị trường ứng dụng chữ
ký số công cộng, tạo điều kiện cho mọi tổ chức, người dân có thể sử dụng
chữ ký số và các phương thức xác thực điện tử, góp phần nâng cao hiệu quả
cung cấp, sử dụng dịch vụ công trực tuyến và phát triển kinh tế số.
• Nghiên cứu, tham mưu, đề xuất các chính sách để đảm bảo an toàn cho giao
dịch điện tử, góp phần đẩy mạnh phát triển thương mại điện tử, kinh tế số
tại Việt Nam.

55
 • Xây dựng và phát triển khuôn khổ hệ sinh thái về định danh và xác thực số
toàn diện áp dụng cho các cá nhân, tổ chức và các đối tượng tham gia giao
dịch điện tử.
• Nghiên cứu, đề xuất triển khai, ứng dụng các công nghệ mới (blockchain,
AI,…) phục vụ việc định danh và xác thực điện tử.

Tình hình phát triển và ứng dụng chữ ký số công cộng

Theo số liệu thống kê của Trung tâm Chứng thực điện tử quốc gia (NEAC)
đến 31/12/2018, các CA công cộng đã cấp 2.420.048 chứng thư số công cộng, thu
hồi 178.018 chứng thư số, số lượng chứng thư số hoạt động là 1.068.961 (chiếm
44,17%).

Chi tiết số lượng chứng thư số đã cấp từng CA công cộng được mô tả như
trong Hình 2.4.

Hình 2.4 Số lượng chứng thư số đã cấp theo CA công cộng tính đến 31/12/2018 [2]

Tính đến hết 31/3/2019, tổng số chứng thư số đang hoạt động khoảng
1.155.060 chứng thư số, trong đó 1.070.072 chứng thư số cấp cho khoảng 740.000
doanh nghiệp và 83.988 chứng thư số cá nhân.

Tỉ lệ chứng thư số phân chia theo cá nhân và tổ chức, doanh nghiệp được thể
hiện như Hình 2.5.

56
 Hình 2.5 Tỉ lệ chứng thư số phân theo đối tượng tính đến 31/3/2019 [2]

Số lượng chứng thư số công cộng đến nay được cấp và sử dụng chủ yếu trong
các dịch vụ công trực tuyến như khai và nộp thuế qua mạng; kê khai hải quan điện
tử; và các dịch vụ bảo hiểm xã hội điện tử.

Hình 2.6 Số lượng các loại chứng thư số đang hoạt động trong một số lĩnh vực giai
đoạn 2015 – 31/3/2019 [2]

Theo số liệu cung cấp từ các cơ quan, tổ chức thuế, hải quan, bảo hiểm xã
hội, tính đến thời điểm 31/3/2019 có:

• 711.604 tổ chức, doanh nghiệp và các đơn vị trực thuộc, các chi nhánh sử
dụng chữ ký số trong lĩnh vực thuế, tăng 63.474 tổ chức, doanh nghiệp so
với cùng kỳ năm 2018;

57
 • 203.976 doanh nghiệp sử dụng chữ ký số trong hoạt động trong lĩnh vực hải
quan, tăng 61.874 tổ chức, doanh nghiệp so với cùng kỳ năm 2018;
• 323.481 doanh nghiệp sử dụng chữ ký số trong kê khai bảo hiểm xã hội,
tăng 97.771 tổ chức, doanh nghiệp so với cùng kỳ năm 2018.

Tình hình phát triển và ứng dụng chữ ký số chuyên dùng trong cơ quan
nhà nước

Việc sử dụng chữ ký số cho văn bản điện tử đảm bảo an toàn cho việc trao
đổi văn bản điện tử giữa các cơ quan nhà nước, tạo được môi trường làm việc hiện
đại, tiết kiệm thời gian và chi phí; nâng cao hiệu quả công việc, tăng tính công
khai, minh bạch trong quản lý điều hành; góp phần tích cực trong việc cải cách
hành chính và phát triển Chính phủ điện tử.

Các loại văn bản điện tử đang được ký số bằng chữ ký số của Ban Cơ yếu
Chính phủ ở các cơ quan, đơn vị gồm: Giấy mời; Lịch làm việc; Đăng ký họp; Tài
liệu họp; Văn bản để biết; Báo cáo; Thông báo; Tờ trình; Kế hoạch; Công văn;
Thông tin chỉ đạo điều hành. Phần lớn các đơn vị sử dụng chữ ký số cho tất cả các
loại văn bản trừ văn bản mật (theo Quyết định số 28/2018/QĐ-TTg ngày
12/7/2018).

Tỉ lệ văn bản điện tử áp dụng chữ ký số trên tổng số văn bản chuyển qua
mạng của các cơ quan, đơn vị ở mức cao (có cơ quan đạt 95%).

Phạm vi sử dụng chữ ký số: Trên hệ thống trục liên thông văn bản quốc gia;
Ký email; Ký văn bản điện tử.

Tình hình phát triển và ứng dụng chữ ký số chuyên dùng trong tổ chức,
doanh nghiệp

Việc ứng dụng chữ ký số để đảm bảo an toàn thông tin, xác thực được thông
tin qua môi trường mạng ngày càng được áp dụng rộng rãi.

Nhận thức được ưu điểm của chữ ký số như đảm bảo an toàn thông tin, xác
thực thông tin người dùng qua môi trường mạng nên các tổ chức, doanh nghiệp tại
Việt Nam đều tích cực ứng dụng chữ ký số. Lựa chọn xây dựng hệ thống cung cấp
dịch vụ chứng thực chữ ký số chuyên dùng (CA chuyên dùng) để tự cấp, sử dụng

58
vì giải pháp này so với chữ ký số công cộng vừa tận dụng được ưu điểm của chữ
ký số và đáp ứng được yêu cầu về kinh phí.

Đến 31/12/2018, Bộ Thông tin và Truyền thông đã cấp giấy chứng nhận đăng
ký hoạt động cho 04 tổ chức cung cấp dịch vụ chứng thực chữ ký số chuyên dùng
bao gồm:

• Ngân hàng Nhà nước Việt Nam

• Ngân hàng Thương mại Cổ phần Kỹ thương Việt Nam
• Ngân hàng Nông nghiệp và Phát triển Nông thôn Việt Nam
• Ngân hàng Thương mại Cổ phần Đông Nam Á

2.5.2 Tình hình phát triển và ứng dụng chữ ký số từ xa

Ngày 5/12/2019, Bộ Thông tin và Truyền thông ban hành thông tư số
16/2019/TT-BTTTT quy định Danh mục tiêu chuẩn bắt buộc áp dụng về chữ ký
số và dịch vụ chứng thực chữ ký số theo mô hình ký số trên thiết bị di dộng và ký
số từ xa.

Ngày 6-10, Tập đoàn VNPT đã triển khai hội thảo “Chữ ký số - Công dân số
- Chìa khóa thành công” qua hình thức trực tuyến với sự có mặt của nhiều chuyên
gia hàng đầu về số hóa tại Việt Nam cùng hàng trăm khách mời đến từ các cơ quan
nhà nước, tổ chức, doanh nghiệp trong và ngoài nước. Tại hội nghị, các diễn giả
đã chia sẻ về kinh nghiệm triển khai chữ ký số, cơ sở pháp lý chữ ký số trên thế
giới và tại Việt Nam, đồng thời nêu ra thực trạng, hạn chế của quá trình số hóa
trong nước. Nhiều diễn giả cùng bày tỏ sự quan ngại khi hình thức chữ ký số sử
dụng USB token hiện nay như phụ thuộc vật lý vào thiết bị PC, laptop cũng như
giới hạn về tốc độ, lượt ký và vấn đề chữ ký số từ xa (Remote Signing) cũng được
đặc biệt quan tâm. Theo ông Nguyễn Thiện Nghĩa, Giám đốc Trung tâm Chứng
thực điện tử quốc gia - Bộ Thông tin và Truyền thông, hình thức ký số từ xa đã
được triển khai trên thế giới được 1-2 năm nay. Nhiều đơn vị đã gửi hồ sơ tới Bộ
Thông tin và Truyền thông để được cấp phép cung cấp dịch vụ này. Trong thời
gian tới, đơn vị nào đáp ứng được các điều kiện an toàn sẽ được phê duyệt.

Liên tiếp trong những ngày đầu của tháng 11/2021, Bộ Thông tin và Truyền
thông đã trao giấy phép cung cấp dịch vụ chứng thực chữ ký số công cộng theo
59
mô hình ký số từ xa cho các doanh nghiệp: Tập đoàn VNPT, Công ty cổ phần
MISA và Công ty cổ phần công nghệ SAVIS.

Tại hội thảo trực tuyến về chữ ký số cá nhân diễn ra sáng 16/11, các diễn giả
đến từ Bộ TT&TT, Ngân hàng Nhà nước, đại diện các ngân hàng, công ty chứng
khoáng, bảo hiểm và công nghệ đã dành nhiều thời gian nói về ký số từ xa (remote
signing), đặc biệt ứng dụng trong lĩnh vực tài chính - ngân hàng. Đáng chú ý, thứ
trưởng Nguyễn Huy Dũng thông tin thêm, dự kiến đầu năm 2022, Bộ TT&TT sẽ
ban hành chương trình hành động chữ ký số cá nhân trong xã hội. Hay nói cách
khác, trong tương lai tới đây, chữ ký số sẽ dần trở nên thông dụng hơn trong cuộc
sống của mỗi cá nhân, chứ không chỉ dành cho doanh nghiệp như bấy lâu nay.

60
 CHƯƠNG 3. ỨNG DỤNG HỖ TRỢ KÝ SỐ TỪ XA

Chương này trình bày giải pháp xây dựng một ứng dụng ký số từ xa, tuân thủ
những quy định hiện hành được ban hành bởi Bộ TTTT và phù hợp với Quy chuẩn
eIDAS. Khuôn khổ hệ thống được trình bày trong báo cáo này xoay quanh dịch vụ
Tạo chữ ký điện tử, các dịch vụ khác như Gán nhãn thời gian, Xác minh chữ ký và
Bảo lưu chữ ký,… sẽ không được đề cập chi tiết. Nội dung được trình bày bao gồm
phân tích yêu cầu hệ thống, thiết kế cơ sở dữ liệu, thiết kế dịch vụ Web và thiết kế
ứng dụng di động. Những thiết kế này được kế thừa phần lớn từ Tiêu chuẩn ETSI
TS 119 432.

3.1 Tổng quan ứng dụng

Đối với ký số từ xa, người ký có quyền kiểm soát việc ký. Tuy nhiên nơi lưu
chứng thư và việc chạy mã lệnh ký được thực hiện bởi dịch vụ tin cậy ở xa. Người
dùng sử dụng ứng dụng di động để xác nhận cho phép dịch vụ tin cậy thực hiện
ký. Ứng dụng có chức năng đăng nhập tài khoản đã có, lấy thông tin chứng thư và
xác nhận việc ký.

Ứng dụng bao gồm hai quy trình tác nghiệp cơ bản là

• Đăng ký tài khoản chứng thực và kích hoạt

• Xác nhận việc ký

Luồng đăng ký kích hoạt

1. Người dùng đăng ký dịch vụ:

• Người dùng đăng ký tài khoản tại văn phòng của nhà cung cấp dịch vụ.
• Nhà cung cấp dịch vụ liên hệ với CA để tạo và cấp chưng thư cùng tài
khoản.
• Nhà cung cấp dịch vụ gửi email chứa tên đăng nhập, mật khẩu, mã kích
hoạt cho người dùng.

2. Người dùng kích hoạt ứng dụng di động:

• Tải và cài ứng dụng.
61
 • Đăng nhập với tên đăng nhập, mật khẩu.
• Vào chức năng kích hoạt, nhập mã kích hoạt.
• Xác nhận mã kích hoạt thành công, ứng dụng sẽ gửi mã FirebaseID (để
gửi thông báo đẩy) lên máy chủ dịch vụ và nhận kết quả kích hoạt.

Lúc đăng ký sử dụng

Cài đặt mobile app

Người dùng

Đăng ký Nhận tt tài khoản: Nhập passphrase

Nhập Login ID + pass
Trên web RA cho login ID +pass, cho chứng thư đc
Kích hoạt bằng
remotesigning activation code cấp
activation code
Web đăng ký-RA

Đăng ký, kiểm tra, cấp chứng thực số

Cấp tài khoản: login ID + pass; activation
code
Mobile app

Kích hoạt tài khoản

Cập nhật tt
lấy thông tin chứng thư
Remote signing

Tạo login ID Tạo key

Cập nhật tt
Tạo key Yc cấp chứng thư

Cấp chứng thư

CA

Hình 3.1 Luồng đăng ký kích hoạt

Luồng xác nhận ký

1. Ứng dụng di động nhận được thông báo về yêu cầu ký.
2. Người dùng đăng nhập ứng dụng, nếu đang đăng nhập thì không cần đăng
nhập nữa.
3. Người dùng vào xem yêu cầu ký.
4. Người dùng nhấn chấp nhận ký hoặc từ chối, có thể thêm lý do.
5. Ứng dụng di động thực hiện và hiển thị kết quả tác vụ ký/từ chối ký.

62
 Người dùng
Mở & Xem thông báo
Nhập passPhrase
Đăng nhập nếu chưa
Có thể lưu danh
sách các yc ký
Không ký
Chấp nhận ký
Mobile app

Hiển thị thông tin Kiểm tra

Nhận thông báo có Yêu cầu nhập
yêu cầu ký Nếu sai-báo lỗi Gửi yc từ chối Thông báo kết quả
yc ký passphrase
+ chấp nhận/+hủy Đúng => ký
Remote signing

Thực hiện theo yc

Push tới mobileApp ký/từ chối
Thông báo kết quả ?

Thông điệp yc ký
Ứng dụng tác
nghiệp-SCA

vCSP Vd Windows App

RP Server app

Hình 3.2 Luồng xác nhận ký

Mô hình logic của hệ thống

Hình 3.3 Mô hình logic hệ thống ký số từ xa

• Máy chủ ký số: Thành phần trung tâm, quản lý các yêu cầu ký của người
dùng, xác minh yêu cầu ký và thực hiện ký.
• Cơ sở dữ liệu: Chứa thông tin đăng nhập, thông tin yêu cầu ký và thông tin
chứng thư của người dùng.
• Ứng dụng di động: Thông báo yêu cầu ký tới người dùng và người dùng
xác nhận ký.
• Ứng dụng tác nghiệp: Có thể là một ứng dụng của nhà cung cấp dịch vụ ký
số từ xa, hoặc một ứng dụng tích hợp API của nhà cung cấp dịch vụ ký số
từ xa, có chức năng gửi yêu cầu ký số văn bản.

63
3.2 Phân tích yêu cầu

3.2.1 Sơ đồ phân rã chức năng

Hình 3.4 Sơ đồ phân rã chức năng

Bảng 3.1 Danh sách chức năng

STT Tên chức năng Mô tả

1 Kích hoạt thiết bị Người dùng kích hoạt thiết bị
2 Đăng nhập Người dùng đăng nhập vào hệ thống
3 Đăng xuất Người dùng đăng xuất khỏi hệ thống
4 Cập nhật tài khoản Người dùng thay đổi thông tin họ tên và/hoặc
email cá nhân
5 Đổi mật khẩu Chức năng này cho phép người dùng thay đổi mật
khẩu đang sử dụng
6 Xem yêu cầu ký Chức năng này cho phép người dùng xem danh
sách và thông tin chi tiết yêu cầu ký
7 Chấp nhận yêu cầu ký Chức năng này cho phép người dùng chấp nhận
yêu cầu ký
8 Từ chối yêu cầu ký Chức năng này cho phép người dùng từ chối yêu
cầu ký

64
 9 Xem chứng thư Chức năng này cho phép người dùng xem danh
sách và thông tin chi tiết chứng thư

3.2.2 Chức năng kích hoạt thiết bị

Mô tả. Người dùng kích hoạt thiết bị.

Điều kiện tiên quyết. Thiết bị chưa được kích hoạt.

Trình tự thực hiện.

1. Người dùng mở ứng dụng trên thiết bị chưa được kích hoạt.

2. Hệ thống yêu cầu nhập thông tin xác thực (tên tài khoản và mật khẩu).

3. Người dùng nhập thông tin xác thực.

4. Người dùng nhấn nút Kích hoạt.

5. Hệ thống kiểm tra thông tin xác thực. [Ngoại lệ a]

6. Hệ thống thông báo gửi mã kích hoạt vào email/SMS của người dùng.

7. Hệ thống yêu cầu nhập mã kích hoạt.

8. Người dùng nhập mã kích hoạt.

9. Người dùng nhấn nút Gửi. [Ngoại lệ b].

10. Hệ thống kiểm tra mã kích hoạt. [Ngoại lệ c]

11. Hệ thống hiển thị màn hình chính.

12. Use case kết thúc.

Ngoại lệ a. Thông tin xác thực không hợp lệ.

a.5. Thông tin xác thực không hợp lệ.

a.6. Hệ thống báo thông tin xác thực không hợp lệ, kích hoạt không thành
công.

a.7. Quay lại bước 2.

Ngoại lệ b. Người dùng hủy bỏ nhập mã kích hoạt.

a.9. Người dùng đóng cửa sổ yêu cầu nhập mã kích hoạt để hủy bỏ.

65
 a.10. Quay lại bước 2.

Ngoại lệ c. Mã kích hoạt không hợp lệ.

a.10. Mã kích hoạt không hợp lệ.

a.11. Hệ thống báo thông tin mã kích hoạt không hợp lệ, kích hoạt không
thành công.

a.12. Quay lại bước 8.

Kết quả. Kích hoạt thành công.

3.2.3 Chức năng đăng nhập

Mô tả. Người dùng đăng nhập vào hệ thống.

Điều kiện tiên quyết. Hệ thống chưa được đăng nhập và thiết bị đã được
kích hoạt.

Trình tự thực hiện.

1. Người dùng mở ứng dụng trên thiết bị đã được kích hoạt.

2. Hệ thống hiển thị tên người dùng và yêu cầu nhập mật khẩu.

3. Người dùng nhập mật khẩu.

4. Người dùng nhấn nút Đăng nhập.

5. Hệ thống kiểm tra thông tin đăng nhập. [Ngoại lệ a]

6. Hệ thống hiển thị màn hình chính

7. Use case kết thúc.

Ngoại lệ a. Thông tin đăng nhập không hợp lệ.

a.5. Thông tin đăng nhập không hợp lệ.

a.6. Hệ thống báo thông tin xác thực không hợp lệ, đăng nhập không thành
công.

a.7. Quay lại bước 2.

Kết quả. Đăng nhập thành công.

66
3.2.4 Chức năng đăng xuất
Mô tả. Người dùng đăng xuất khỏi hệ thống.

Điều kiện tiên quyết. Người dùng phải đăng nhập vào hệ thống.

Trình tự thực hiện.

1. Từ giao diện chính, người dùng chọn nút Đăng xuất trong màn hình Cá
nhân.

2. Hệ thống đăng xuất người dùng khỏi hệ thống.

3. Hệ thống hiển thị màn hình đăng nhập.

4. Use case kết thúc.

Kết quả. Đăng xuất thành công.

3.2.5 Chức năng cập nhật thông tin tài khoản

Mô tả. Người dùng thay đổi thông tin họ tên và/hoặc email cá nhân.

Điều kiện tiên quyết. Người dùng phải đăng nhập vào hệ thống.

Trình tự thực hiện.

1. Từ giao diện chính, người dùng mở màn hình Cá nhân/Tài khoản của
tôi/Cập nhật tài khoản.

2. Hệ thống hiển thị họ tên và email hiện tại và cho phép chỉnh sửa.

3. Người dùng nhấn nút Lưu. [Ngoại lệ a]

4. Hệ thống thông báo cập nhật thông tin tài khoản thành công.

5. Use case kết thúc.

Ngoại lệ a. Thông tin không hợp lệ.

a.3. Họ tên quá ngắn hoặc email không đúng định dạng.

a.4. Hệ thống báo thông tin không hợp lệ, cập nhật thông tin tài khoản không
thành

công.

67
 a.5. Quay lại bước 2.

Kết quả. Cập nhật thông tin tài khoản thành công.

3.2.6 Chức năng đổi mật khẩu

Mô tả. Chức năng này cho phép người dùng thay đổi mật khẩu đang sử dụng.

Điều kiện tiên quyết. Người dùng phải đăng nhập vào hệ thống.

Trình tự thực hiện.

1. Từ giao diện chính, người dùng mở màn hình Cá nhân/Tài khoản của
tôi/Mật khẩu.

2. Hệ thống yêu cầu nhập mật khẩu hiện tại, mật khẩu mới và xác nhận mật
khẩu mới.

3. Người dùng nhập mật khẩu hiện tại, mật khẩu mới và xác nhận mật khẩu
mới.

4. Người dùng ấn nút Lưu mật khẩu mới. [Ngoại lệ a]

5. Hệ thống kiểm tra mật khẩu hiện tại. [Ngoại lệ b]

6. Hệ thống thông báo đổi mật khẩu thành công.

7. Use case kết thúc.

Ngoại lệ a. Xác nhận mật khẩu không trùng khớp.

a.4. Xác nhận mật khẩu không trùng khớp.

a.5. Hệ thống báo xác nhận mật khẩu không trùng khớp, đổi mật khẩu không
thành công.

a.6. Quay lại bước 2.

Ngoại lệ b. Mật khẩu hiện tại không đúng.

a.5. Mật khẩu hiện tại không đúng.

a.6. Hệ thống báo mật khẩu hiện tại không đúng, đổi mật khẩu không thành
công.

a.7. Quay lại bước 2.

68
 Kết quả. Đổi mật khẩu thành công.

3.2.7 Chức năng xem yêu cầu ký

Mô tả. Chức năng này cho phép người dùng xem danh sách và thông tin chi
tiết yêu cầu ký.

Điều kiện tiên quyết. Người dùng phải đăng nhập vào hệ thống.

Trình tự thực hiện.

1. Từ giao diện chính, người dùng mở màn hình Yêu cầu ký.

2. Hệ thống hiển thị danh sách các yêu cầu ký đang chờ xác nhận.

3. Người dùng nhấn vào một yêu cầu ký bất kỳ.

4. Hệ thống hiển thị thông tin chi tiết yêu cầu ký đó.

5. Use case kết thúc.

Kết quả. Xem yêu cầu ký thành công.

3.2.8 Chức năng chấp nhận yêu cầu ký

Mô tả. Chức năng này cho phép người dùng chấp nhận yêu cầu ký.

Điều kiện tiên quyết. Người dùng phải đăng nhập vào hệ thống.

Trình tự thực hiện.

1. Từ giao diện chính, người dùng mở màn hình Yêu cầu ký.

2. Hệ thống hiển thị danh sách các yêu cầu ký đang chờ xác nhận.

3. Người dùng nhấn vào một yêu cầu ký bất kỳ.

4. Hệ thống hiển thị thông tin chi tiết yêu cầu ký đó.

5. Người dùng nhấn nút Chấp nhận.

6. Hệ thống yêu cầu người dùng nhập lý do chấp nhận yêu cầu ký.

7. Người dùng có thể nhập lý do chấp nhận ký hoặc để trống. [Ngoại lệ a]

8. Người dùng nhấn nút Gửi.

9. Hệ thống gửi mã OTP đến người dùng qua email/SMS.

69
 10. Hệ thống yêu cầu nhập mã OTP.

11. Người dùng nhập mã OTP. [Ngoại lệ b]

12. Người dùng nhấn nút gửi.

13. Hệ thống thông báo xác nhận ký thành công.

14. Use case kết thúc.

Ngoại lệ a. Người dùng hủy bỏ chấp nhận yêu cầu ký.

a.7. Người dùng đóng cửa sổ yêu cầu nhập lý do để hủy bỏ.

a.8. Quay lại bước 4.

Ngoại lệ b. Người dùng hủy bỏ nhập OTP.

a.11. Người dùng đóng cửa sổ yêu cầu nhập OTP để hủy bỏ.

a.12. Quay lại bước 4.

Kết quả. Chấp nhận yêu cầu ký thành công.

3.2.9 Chức năng từ chối yêu cầu ký

Mô tả. Chức năng này cho phép người dùng từ chối yêu cầu ký.

Điều kiện tiên quyết. Người dùng phải đăng nhập vào hệ thống.

Trình tự thực hiện.

1. Từ giao diện chính, người dùng mở màn hình Yêu cầu ký.

2. Hệ thống hiển thị danh sách các yêu cầu ký đang chờ xác nhận.

3. Người dùng nhấn vào một yêu cầu ký bất kỳ.

4. Hệ thống hiển thị thông tin chi tiết yêu cầu ký đó.

5. Người dùng nhấn nút Từ chối.

6. Hệ thống yêu cầu người dùng nhập lý do từ chối yêu cầu ký.

7. Người dùng có thể nhập lý do từ chối ký hoặc để trống. [Ngoại lệ a]

8. Người dùng nhấn nút Gửi.

9. Hệ thống thông báo từ chối ký thành công.

70
 10. Use case kết thúc.

Ngoại lệ a. Người dùng hủy bỏ từ chối yêu cầu ký.

a.7. Người dùng đóng cửa sổ yêu cầu nhập lý do để hủy bỏ.

a.8. Quay lại bước 4.

Kết quả. Từ chối yêu cầu ký thành công.

3.2.10 Chức năng xem chứng thư

Mô tả. Chức năng này cho phép người dùng xem danh sách và thông tin chi
tiết chứng thư.

Điều kiện tiên quyết. Người dùng phải đăng nhập vào hệ thống.

Trình tự thực hiện.

1. Từ giao diện chính, người dùng mở màn hình Cá nhân/Chứng thư.

2. Hệ thống hiển thị danh sách các chứng thư.

3. Người dùng nhấn vào một chứng thư bất kỳ.

4. Hệ thống hiển thị thông tin chi tiết chứng thư đó.

5. Use case kết thúc.

Kết quả. Xem chứng thư thành công.

71
3.3 Thiết kế cơ sở dữ liệu

3.3.1 Mô hình thực thể liên kết

Hình 3.5 Mô hình thực thể liên kết

3.3.2 Bảng users

Bảng 3.2 Bảng users

Kiểu dữ Ràng
STT Tên thuộc tính Mô tả
liệu buộc
1 id bigint Khóa Mã người dùng
chính
2 usertype varchar Not Loại định danh người dùng
null
3 username varchar Not Định danh người dùng
null

72
 4 password varchar Not Chuỗi ký tự bí mật được ghi
null nhớ bởi người dùng cuối
5 access_token varchar Mã truy cập dịch vụ tồn tại
trong thời gian ngắn được sử
dụng để xác thực các yêu cầu
dịch vụ web tiếp theo trong
cùng phiên làm việc
6 expires_at datetime Thời điểm access_token hết
hạn sử dụng
7 remaining_counter int Not Số lần đăng nhập sai còn lại
null trước khi bị khóa tài khoản
8 temp_lockout_until datetime Thời điểm tài khoản được mở
khóa
9 full_name varchar Not Tên đầy đủ của người dùng
null
10 phone varchar Not Số điện thoại của người dùng
null
11 email varchar Not Email của người dùng
null
12 oauth2 varchar Thông tin OAUTH2 của tài
khoản
13 created_at timestamp Thời điểm tạo tài khoản
14 updated_at timestamp Thời điểm cập nhật thông tin
tài khoản gần nhất

3.3.3 Bảng devices

Bảng 3.3 Bảng devices

Kiểu dữ Ràng
STT Tên thuộc tính Mô tả
liệu buộc
1 device_uuid varchar Khóa Mã thiết bị
chính
73
 2 user_id bigint Khóa Mã người dùng
ngoại
3 lang varchar Ngôn ngữ của thiết bị
4 otp_encrypted varchar Mã hóa base64 của OTP
đã được mã hóa bởi
KAK.PublicKey
5 access_token varchar Mã truy cập dịch vụ tồn
tại trong thời gian ngắn
được sử dụng để xác thực
các yêu cầu dịch vụ web
tiếp theo trong cùng
phiên làm việc
6 expires_at datetime Thời điểm access_token
hết hạn sử dụng
7 remember_me int Not null refresh_token có hiệu lực
hay không
8 refresh_token varchar Mã làm mới dài hạn được
sử dụng để xác thực lại
người dùng trong các
phiên làm việc sau
9 remaining_counter int Not null Số lần đăng nhập sai còn
lại trước khi bị khóa thiết
bị
10 temp_lockout_until datetime Thời điểm thiết bị được
mở khóa
11 change_device int Not null Đã thay đổi thiết bị hay
thiết bị đầu tiên
12 os_type varchar Loại hệ điều hành của
thiết bị di động
13 os_version varchar Phiên bản hệ điều hành
của thiết bị

74
 14 model varchar Mẫu thiết bị di động
15 tse_version varchar Not null Phiên bản của ứng dụng
TSE
16 firebase_id varchar Not null Mã Firebase của thiết bị
di động, giá trị này được
lấy từ dịch vụ Firebase
dùng cho thông báo đẩy
17 client_uuid varchar Not null Thông tin của thiết bị di
động, có thê là IMEI
hoặc MAC hoặc một
chuỗi được sinh ngẫu
nhiên bởi ứng dụng TSE
hoặc tổ hoặc của chúng
18 kak_public_key varchar Not null Mã hóa base64 của khóa
công khai của khóa xác
thực
19 kak_private_encrypted varchar Not null Mã hóa base64 của khóa
bí mật của khóa khóa xác
thực
20 recovery_code varchar Mã phục hồi, nếu có sẽ
được máy chủ gửi tới
người dùng thông qua
email
21 created_at timestamp Thời điểm tạo thiết bị
22 updated_at timestamp Thời điểm cập nhật thông
tin thiết bị gần nhất

3.3.4 Bảng inactive_devices

Bảng 3.4 Bảng inactive_devices

Kiểu dữ Ràng
STT Tên thuộc tính Mô tả
liệu buộc

75
 1 device_uuid varchar Khóa Mã thiết bị
chính
2 user_id bigint Khóa Mã người dùng
ngoại
3 activation_code varchar Not null Mã kích hoạt thiết bị được
gửi đến người dùng qua
email
4 activation_token varchar Mã truy cập dịch vụ tồn tại
trong thời gian ngắn được
sử dụng để xác thực các
yêu cầu kích hoạt thiết bị
5 expires_at datetime Thời điểm
activation_token hết hạn
sử dụng
6 created_at timestamp Thời điểm tạo thiết bị
7 updated_at timestamp Thời điểm cập nhật thông
tin thiết bị gần nhất

3.3.5 Bảng credentials

Bảng 3.5 Bảng credentials

Kiểu dữ Ràng
STT Tên thuộc tính Mô tả
liệu buộc
1 id bigint Khóa Mã chứng thư
chính
2 user_id bigint Khóa Mã người dùng
ngoại
3 cert_status varchar Not Trạng thái của chứng
null thư
4 cert_certificates varchar Not Một hoặc nhiều mã
null hóa base64 của các

76
 chứng thư X.509v3
từ chuỗi chứng thư.
5 cert_issuer_dn varchar Not Issuer Distinguished
null Name từ chứng thư
X.509v3 dưới dạng
chuỗi ký tự được mã
hóa UTF-8.
6 cert_serial_number varchar Not Serial Number từ
null chứng thư X.509v3
được biểu diễn dưới
dạng chuỗi hexa.
7 cert_thumbprint varchar Not Dấu tay của chứng
null thư. Giá trị này được
tính bằng cách băm
biểu diễn nhị phân
của chứng thư được
mã hóa. Thuật toán
SHA-256 thường
được sử dụng để băm
dữ liệu này.
8 cert_subject_dn varchar Not Subject
null Distinguished Name
từ chứng thư
X.509v3 dưới dạng
chuỗi ký tự được mã
hóa UTF-8.
9 cert_valid_from datetime Not Ngày bắt đầu có hiệu
null lực từ chứng thư
X.509v3 dưới dạng
chuỗi ký tự.

77
10 cert_valid_to datetime Not Ngày hết hiệu lực từ
null chứng thư X.509v3
dưới dạng chuỗi ký
tự.
11 cert_profile_name varchar Not Tên hồ sơ của chứng
null thư.
12 cert_profile_desc varchar Mô tả hồ sơ chứng
thư.
13 cert_purpose varchar Mục đích sử dụng
của chứng thư.
14 shared_mode varchar Not Chế độ chia sẻ nào sẽ
null được sử dụng trong
ký số từ xa.
15 created_rp varchar Not Tên của Relying
null Party. Nó ám chỉ
rằng chứng thư đã
được tạo bởi RP đó.
16 multisign int Not Một số bằng hoặc lớn
null hơn 1 đại diện cho số
lượng chữ ký tối đa
có thể được tạo bằng
chứng thư này với
một yêu cầu ủy
quyền duy nhất.
17 auth_modes varchar Not Chỉ định một trong
null các chế độ ủy quyền.
18 auth_mode varchar Not Một giá trị trong các
null giá trị của
auth_modes, là chế
độ ủy quyền được
kích hoạt lúc này. Để

78
 thay đổi phải do quản
trị viên RRSP thực
hiện.
19 scal int Not Các giá trị 1: Mã băm
null dùng để ký không
được liên kết với dữ
liệu kích hoạt chữ ký;
2: Mã băm dùng để
ký được liên kết với
dữ liệu kích hoạt chữ
ký.
20 contract_expiration_date datetime Not Ngày hết hạn hợp
null đồng.
21 remaining_signing_counter int Not Số lượt ký còn lại của
null chứng thư này.
22 auth_email varchar Not Email ủy quyền.
null
23 auth_phone varchar Not Số điện thoại ủy
null quyền.
24 default_passphrase int Not True nếu passphrase
null là mặc định và người
dùng phải thay đổi
passphrase trước khi
thực hiện mã hóa.
25 kak_changed int Not Cờ ám chỉ trạng thái
null của KAK sẽ thay đổi.
26 created_at timestamp Thời điểm tạo chứng
thư
27 updated_at timestamp Thời điểm cập nhật
thông tin chứng thư
gần nhất

79
3.3.6 Bảng transactions

Bảng 3.6 Bảng transactions

Kiểu dữ Ràng
STT Tên thuộc tính Mô tả
liệu buộc
1 id bigint Khóa Mã giao dịch
chính
2 credential_id bigint Khóa Mã chứng thư
ngoại
3 notification_message varchar Tin nhắn được hiển
thị ở thông báo đẩy.
4 message_caption varchar Chú thích của tin
nhắn.
5 message varchar Văn bản được hiển
thị bên cạnh Tên
dịch vụ và trước khi
yêu cầu mã PIN xác
thực.
6 logo_uri varchar URI của logo tùy
chọn để hiển thị
trong trình xác thực.
7 bg_image_uri varchar URI của hình nền để
hiển thị trong trình
xác thực.
8 rp_icon_uri varchar URI của biểu tượng
Relying Party tùy
chọn được hiển thị
trong trình xác thực.
9 rp_name varchar Not Tên tùy chỉnh của
null Relying Party được

80
 hiển thị trong trình
xác thực.
10 confirmation_policy varchar Not Chính sách xác
null nhận, một trong
"PIN", "FINGER-
PRINT", "TAP",
"SWIPE", "IRIS".
11 vc_enabled int Not Bật
null VerificationCode.
Giá trị mặc định là
true.
12 ac_enabled int Not Bật AuthorizeCode.
null Nếu giá trị là true,
nó yêu cầu người
dùng cuối nhắc lại
AC mỗi khi lấy
trạng thái.
13 num_signatures int Not Số lượng chữ ký
null cho ủy quyền một
lần.
14 doc_digests_hashes text Một hoặc nhiều giá
trị băm được mã hóa
base64 sẽ được ký.
Nó được yêu cầu
khi SCAL là cấp 2.
15 doc_digetst_hash_algo_oid varchar Not OID của thuật toán
null băm dùng để tính
các mã băm của tài
liệu.
16 sca_identity varchar Not Tên của SCA.
null

81
17 auth_data_hash_algo_oid varchar Not Thuật toán băm.
null Mặc định SHA256.
18 auth_data_sign_algo varchar Not Thành phần chỉ
null định OID thuật toán
được sử dụng để ký.
19 auth_data_sign_algo_params varchar Mã hóa base64 của
tham số chữ ký
ASN.1 mã hóa
DER, nếu thuật toán
chữ ký yêu cầu.
20 auth_data_challenge varchar Not Mã hóa base64 của
null chuỗi thử thách.
21 type varchar Not Loại giao dịch, có
null ba giá trị "SIGN",
"SYNC" và
"LOGIN".
22 expires_at datetime Not Ngày giờ yêu cầu
null giao dịch hết hạn.
23 sign_algo varchar Not Thành phần chỉ
null định OID thuật toán
được sử dụng để ký.
24 sign_algo_params varchar Mã hóa base64 của
tham số chữ ký
ASN.1 mã hóa
DER, nếu thuật toán
chữ ký yêu cầu.
25 status varchar Not Trạng thái hiện tại
null của yêu cầu ký, một
trong "WAITING,
SIGNED,

82
 CANCELED,
EXPIRED".
26 created_at timestamp Thời điểm tạo giao
dịch
27 updated_at timestamp Thời điểm cập nhật
thông tin giao dịch
gần nhất

3.4 Thiết kế dịch vụ Web

3.4.1 API xác thực

Chức năng activate cho phép thiết bị di động ràng buộc với tài khoản của
người dùng cuối (chủ sở hữu). Chức năng này có bốn bước:

• login: Đăng nhập với tên tài khoản và mật khẩu để lấy access-token.
• retrieveActivationCode: Sử dụng access-token để lấy mã kích hoạt qua
email hoặc SMS.
• initialize: Thiết bị TSE gửi mã kích hoạt đến endpoint. Endpoint sẽ phản
hồi activation-token lại cho thiết bị TSE.
• sendDevice: Sử dụng activation-token để cập nhật thông tin thiết bị.

activate/login

Chức năng này nhận access-token dùng để truy xuất mã kích hoạt.

Bảng 3.7 API yêu cầu activate/login

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 usertype string Có Giá trị luôn là
"USERNAME".
2 username string Có Tên người dùng duy nhất.

83
 3 password string Có Giá trị bí mật được ghi nhớ
bởi người dùng cuối.

Bảng 3.8 API phản hồi activate/login

Các thuộc tính phản hồi

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.
3 accessToken string Có Mã truy cập dịch vụ tồn tại
trong thời gian ngắn được
sử dụng để xác thực các
yêu cầu API tiếp theo trong
cùng một phiên làm việc.

activate/retrieveActivationCode

Chức năng này yêu cầu RSSP gửi mã kích hoạt cho người dùng cuối thông
qua email hoặc SMS. Người dùng cuối phải đăng ký sử dụng TSE trước, việc đăng
ký thực hiện trong BackOffice.

TSE Client phải gửi access-token nhận được từ activate/login trong HTTP
header với tên: "Authorization" bắt đầu bằng "Bearer".

Bảng 3.9 API yêu cầu activate/retrieveActivationCode

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc

Bảng 3.10 API phản hồi activate/retrieveActivationCode

Các thuộc tính phản hồi

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc

84
 1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.
3 deviceUUID string Có Định danh của thiết bị TSE.
4 changeDevice bool Có true nếu thay đổi thiết bị,
false nếu kích hoạt thiết bị
đầu tiên.

activate/initialize

Chức năng này để khởi tạo kích hoạt, TSE gửi mã kích hoạt đến máy chủ
RSSP.

Bảng 3.11 API yêu cầu activate/initialize

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 deviceUUID string Có Định danh của thiết bị TSE,
nhận trong
getActivationCode.
2 activationCode string Có Mã kích hoạt, giá trị này
được gửi bởi RSSP tới người
dùng cuối qua email hoặc
SMS.

Bảng 3.12 API phản hồi activate/initialize

Các thuộc tính phản hồi

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.
3 activationToken string Có Mã truy cập dịch vụ tồn tại
trong thời gian ngắn được
sử dụng để xác thực các

85
 yêu cầu API tiếp theo trong
cùng một phiên làm việc.

activate/sendDevice

TSE client phải gửi activationToken nhận được từ activate/initialize trong

HTTP header với tên: "Authorization" bắt đầu bằng "Bearer".

TSE client phải tạo KAK là cặp khóa RSA. Nếu người dùng cuối đồng ý sao
lưu KAK thì TSE client phải gửi kakPrivateEncrypted trong phần nội dung yêu
cầu, kakPrivateEncrypted được mã hóa bằng RECOVERY CODE và phải có
checksum (ví dụ: HMAC256) để TSE client có thể kiểm tra tính toàn vẹn của KAK
khi khôi phục KAK.

Bảng 3.13 API yêu cầu activate/sendDevice

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 osType string Có Loại hệ điều hành của thiết bị
di động, một trong ba giá trị
"IOS", "ANDROID" và
"WINDOWS_PHONE".
2 osVersion string Có Phiên bản hệ điều hành của
thiết bị di động. Ví dụ:
13.0.1.
3 model string Mẫu của thiết bị di động. Thí
dụ: Vsmart Joy 1+.
4 tseVersion string Phiên bản của ứng dụng
TSE.
5 firebaseID string Có Mã Firebase của thiết bị di
động, giá trị này được truy
xuất từ dịch vụ Firebase,
được sử dụng để đẩy thông
báo.
86
 6 clientUUID string Có Thông tin của thiết bị di
dộng, có thể là IMEI hoặc
MAC hoặc được sinh ngẫu
nhiên bởi TSE client hoặc tổ
hợp của tất cả chúng.
7 kakPublicKey string Có Mã hóa base64 của khóa
công khai của khóa ủy
quyền.
8 kakPrivateEncrypted string Mã hóa base64 của khóa bí
mật của khóa ủy quyền.
9 rememberMe bool Yêu cầu refresh-token từ
TSE, giá trị mặc định là false.

Bảng 3.14 API phản hồi activate/sendDevice

Các thuộc tính phản hồi

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.
3 accessToken string Có Mã truy cập dịch vụ tồn tại
trong thời gian ngắn được
sử dụng để xác thực các
yêu cầu API tiếp theo
trong cùng một phiên làm
việc.
4 ownerInfo/fullName string Có Tên đầy đủ của người
dùng.
5 ownerInfo/phone string Có Số điện thoại của người
dùng.
6 ownerInfo/email string Có Email của người dùng.

87
login

Chức năng này truy xuất token dùng cho các yêu cầu API tiếp theo trong
cùng phiên làm việc.

Bảng 3.15 API yêu cầu login

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 usertype string Có Giá trị luôn là
"DEVICE_UUID".
2 username string Có Device UUID được trả về bởi
RSSP trong
activate/retrieveActivationCode.
3 password string Có Giá trị bí mật được ghi nhớ bởi
người dùng cuối.
4 rememberMe bool Yêu cầu refresh-token từ TSE,
giá trị mặc định là false.

Bảng 3.16 API phản hồi login

Các thuộc tính phản hồi

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.
3 accessToken string Có Mã truy cập dịch vụ tồn tại
trong thời gian ngắn được
sử dụng để xác thực các
yêu cầu API tiếp theo trong
cùng một phiên làm việc.

88
revoke

Chức năng này thu hồi access-token hoặc refresh-token khi người dùng đăng
xuất trên TSE client. TSE client phải gửi access-token nhận được từ login trong
HTTP header với tên: "Authorization" bắt đầu bằng "Bearer".

Bảng 3.17 API yêu cầu revoke

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc

Bảng 3.18 API phản hồi revoke

Các thuộc tính phản hồi

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.

updateAccount

Chức năng này cập nhật tên đầy đủ và/hoặc email của người dùng. TSE client
phải gửi access-token nhận được từ login trong HTTP header với tên:
"Authorization" bắt đầu bằng "Bearer".

Bảng 3.19 API yêu cầu updateAccount

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 fullName string Tên đầy đủ của người dùng.
2 email string Email của người dùng.

Bảng 3.20 API phản hồi updateAccount

Các thuộc tính phản hồi

89
 Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.

changePassword

Chức năng này cập nhật mật khẩu tài khoản. TSE client phải gửi access-token
nhận được từ login trong HTTP header với tên: "Authorization" bắt đầu bằng
"Bearer".

Bảng 3.21 API yêu cầu changePassword

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 password string Có Mật khẩu hiện tại.
2 newPassword string Có Mật khẩu mới.

Bảng 3.22 API phản hồi changePassword

Các thuộc tính phản hồi

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.

3.4.2 API yêu cầu ký

requests/list

Chức năng này truy xuất danh sách giao dịch chờ xác nhận từ người dùng.

TSE client phải gửi access-token nhận được từ login trong HTTP header với
tên: "Authorization" bắt đầu bằng "Bearer".

Bảng 3.23 API yêu cầu requests/list

90
Các thuộc tính yêu cầu
Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc

Bảng 3.24 API phản hồi requests/list

Các thuộc tính phản hồi

Bắt
ST Kiểu
Tên thuộc tính buộ Mô tả
T dữ liệu
c
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.
3 requests/transactionI int[] Có Định danh của giao dịch.
D
4 requests/ string[ Có Tin nhắn được hiển thị ở thông
notificationMessage ] báo đẩy.
5 requests/ string[ Có Chú thích của tin nhắn.
messageCaption ]
6 requests/type string[ Có Loại giao dịch.
]
7 requests/rpIconURI string[ URI của biểu tượng Relying
] Party tùy chỉnh sẽ được hiển thị
trong trình xác thực.
8 requests/createdDt string[ Ngày giờ mà máy chủ nhận được
] yêu cầu từ RP. Theo định dạng
YYYYMMDD’T’HHMMSS’Z’
.
9 requests/scaIdentity string[ Tên của SCA.
]

91
 10 string Ngày giờ yêu cầu giao dịch hết
hạn. Theo định dạng YYYYM-
MDD’T’HHMMSS’Z’.

requests/info

Chức năng này lấy thông tin giao dịch chờ xác nhận từ người dùng.

TSE client phải gửi access-token nhận được từ login trong HTTP header với
tên: "Authorization" bắt đầu bằng "Bearer".

Bảng 3.25 API yêu cầu requests/info

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 transactionID int Có Định danh của giao dịch.

Bảng 3.26 API phản hồi requests/info

Các thuộc tính phản hồi

Kiểu Bắt
STT Tên thuộc tính Mô tả
dữ liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.
3 transactionID int Có Định danh của giao dịch.
4 notificationMessage string Có Tin nhắn được hiển thị ở thông
báo đẩy.
5 messageCaption string Có Chú thích của tin nhắn.
6 message string Có Văn bản được hiển thị bên cạnh
Tên dịch vụ và trước khi yêu cầu
mã PIN xác thực.
7 logoURI string URI của logo tùy chọn để hiển thị
trong trình xác thực.
8 bgImageURI string URI của hình nền để hiển thị
trong trình xác thực.
92
 9 rpIconURI string URI của biểu tượng Relying
Party tùy chọn được hiển thị
trong trình xác thực.
10 rpName string Tên tùy chỉnh của Relying Party
được hiển thị trong trình xác
thực.
11 confirmationPolicy string Chính sách xác nhận, một trong
"PIN", "FINGERPRINT",
"TAP", "SWIPE", "IRIS".
12 vcEnabled bool Bật VerificationCode. Giá trị
mặc định là true.
13 acEnabled bool Bật AuthorizeCode. Nếu gía trị là
true, nó yêu cầu người dùng cuối
nhắc lại AC mỗi khi lấy trạng
thái.
14 numSignatures int Có Số lượng chữ ký cho ủy quyền
một lần.
15 documentDigests/ string[] Có Một hoặc nhiều giá trị băm được
hashes mã hóa base64 sẽ được ký. Nó
được yêu cầu khi SCAL là cấp 2.
16 documentDigests/ string Có OID của thuật toán băm dùng để
hashAlgorithmOID tính các mã băm của tài liệu.
17 scaIdentity string Tên của SCA.
18 authData/ string Thuật toán băm. Mặc định SHA-
hashAlgorithmOID 256.
19 authData/signAlgo string Có Thành phần chỉ định OID thuật
toán được sử dụng để ký. Mặc
định RSA.
20 authData/ string Mã hóa base64 của tham số chữ
signAlgoParams ký ASN.1 mã hóa DER, nếu thuật

93
 toán chữ ký yêu cầu. Mặc định
thành phần này bị thiếu.
21 authData/challenge string Có Mã hóa base64 của chuỗi thử
thách.
22 credentialID int Có Định danh của chứng thư dùng để
ký. Chỉ trả về khi type là AUTH.
23 type string Có Loại giao dịch, có ba giá trị
"SIGN", "SYNC" và "LOGIN".
24 createdDt string Ngày giờ mà máy chủ nhận được
yêu cầu từ RP. Theo định dạng
YYYYMMDD’T’HHMMSS’Z’.
25 expiredDt string Ngày giờ yêu cầu giao dịch hết
hạn. Theo định dạng
YYYYMMDD’T’HHMMSS’Z’.
26 signAlgo string Thành phần chỉ định OID của
thuật toán dùng để ký.
27 signAlgoParams string Mã hóa base64 của tham số chữ
ký ASN.1 mã hóa DER, nếu thuật
toán chữ ký yêu cầu.

requests/confirm

Chức năng này để:

• Chấp nhận giao dịch. OTP trong yêu cầu là giá trị được lưu trữ trong TSE
với định dạng được mã hóa. TSE phải giải mã nó bằng khóa bí mật của
KAK trước khi gửi.
• Xác nhận đăng nhập từ vCSP. OTP trong yêu cầu là giá trị được lưu trữ
trong TSE với định dạng được mã hóa, TSE phải giải mã nó bằng khóa
bí mật của KAK trước khi gửi.
• Dữ liệu đồng bộ: cập nhật otpEncoded để chống sao chép. OTP trong yêu
cầu là giá trị được gửi từ máy chủ cho người dùng thông qua email hoặc
SMS.

94
 TSE client phải gửi access-token nhận được từ login trong HTTP header với
tên: "Authorization" bắt đầu bằng "Bearer".

Trong giai đoạn 2, TSE phải sử dụng khóa bí mật của KAK để ký vào
authData/challenge với thuật toán được chỉ định trong các requests/info.

Bảng 3.27. API yêu cầu requests/confirm

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 transactionID int Có Định danh của giao dịch.
2 authSignature string Có Mã hóa base64 của chữ ký
ủy quyền được tạo bởi
khóa bí mật ký vào
challenge.
3 confirmationReason string Lý do chấp nhận giao dịch.
4 otp string Có Mật khẩu một lần để chống
sao chép.
5 credentialID int Có Định danh của chứng thư
dùng để ký.
6 signatures string[] Có Một hoặc nhiều mã băm đã
ký được mã hóa base64.
Trong trường hợp có nhiều
chữ ký, các mã băm đã ký
sẽ được trả về theo thứ tự
giống như các mã băm
tương ứng được cung cấp
dưới dạng tham số đầu
vào.

Bảng 3.28. API phản hồi requests/confirm

Các thuộc tính phản hồi

95
 Kiểu Bắt
STT Tên thuộc tính Mô tả
dữ liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.

requests/cancel

Chức năng này để hủy bỏ giao dịch.

TSE client phải gửi access-token nhận được từ login trong HTTP header với
tên: "Authorization" bắt đầu bằng "Bearer".

Bảng 3.29 API yêu cầu requests/cancel

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 transactionID int Có Định danh của giao dịch.
2 denyReason string Lý do hủy bỏ giao dịch.

Bảng 3.30. API phản hồi requests/cancel

Các thuộc tính phản hồi

Kiểu Bắt
STT Tên thuộc tính Mô tả
dữ liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.

3.4.3 API chứng thư

credentials/list

Chức năng này lấy danh sách chứng thư.

TSE client phải gửi access-token nhận được từ login trong HTTP header với
tên: "Authorization" bắt đầu bằng "Bearer".

Bảng 3.31 API yêu cầu credentials/list

96
 Các thuộc tính yêu cầu
Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc

Bảng 3.32 API phản hồi credentials/list

Các thuộc tính phản hồi

Kiểu Bắt
STT Tên thuộc tính Mô tả
dữ liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.
3 certs/credentialID int Có Định danh của chứng thư
dùng để ký.
4 certs/issuerDN string Có Issuer Distinguished Name
từ chứng thư X.509v3 dưới
dạng chuỗi ký tự được mã
hóa UTF-8.
5 certs/subjectDN string Có Subject Distinguished Name
từ chứng thư X.509v3 dưới
dạng chuỗi ký tự được mã
hóa UTF-8.
6 certs/validFrom date Có Ngày bắt đầu có hiệu lực từ
chứng thư X.509v3 dưới
dạng chuỗi ký tự.
7 certs/validTo date Có Ngày hết hiệu lực từ chứng
thư X.509v3 dưới dạng
chuỗi ký tự.

credentials/info

Chức năng này lấy thông tin của chứng thư.

TSE client phải gửi access-token nhận được từ login trong HTTP header với
tên: "Authorization" bắt đầu bằng "Bearer".
97
 Bảng 3.33 API yêu cầu credentials/info

Các thuộc tính yêu cầu

Kiểu dữ Bắt
STT Tên thuộc tính Mô tả
liệu buộc
1 credentialID int Có Định danh của chứng thư.

Bảng 3.34 API phản hồi credentials/info

Các thuộc tính phản hồi

Kiểu Bắt
STT Tên thuộc tính Mô tả
dữ liệu buộc
1 error int Có Mã mô tả kết quả.
2 errorDescription string Có Mô tả chi tiết kết quả.
3 credentialID int Có Định danh của chứng
thư dùng để ký.
4 cert/certificates string[] Có Một hoặc nhiều mã
hóa base64 của các
chứng thư X.509v3
từ chuỗi chứng thư.
5 cert/issuerDN string Có Issuer Distinguished
Name từ chứng thư
X.509v3 dưới dạng
chuỗi ký tự được mã
hóa UTF-8.
6 cert/subjectDN string Có Subject
Distinguished Name
từ chứng thư
X.509v3 dưới dạng
chuỗi ký tự được mã
hóa UTF-8.
7 cert/serialNumber string Có Serial Number từ
chứng thư X.509v3

98
 được biểu diễn dưới
dạng chuỗi hexa.
8 cert/validFrom date Có Ngày bắt đầu có hiệu
lực từ chứng thư
X.509v3 dưới dạng
chuỗi ký tự.
9 cert/validTo date Có Ngày hết hiệu lực từ
chứng thư X.509v3
dưới dạng chuỗi ký
tự.
10 cert/certificateProfile/name string Có Tên hồ sơ của chứng
thư.
11 cert/certificateProfile/description string Mô tả của hồ sơ
chứng thư.
12 cert/purpose string Mục đích sử dụng
của chứng thư.
13 authorizationEmail string Có Email ủy quyền.
14 authorizationPhone string Có Số điện thoại ủy
quyền.

3.5 Thiết kế giao diện

3.5.1 Giao diện kích hoạt thiết bị

Giao diện này hiển thị khi người dùng mở ứng dụng trên một thiết bị mới
chưa được kích hoạt. Dùng để kích hoạt thiết bị hiện tại. Người dùng được yêu cầu
nhập tên đăng nhập, mật khẩu để nhận mã kích hoạt. Sau đó người dùng nhập mã
kích hoạt nhận được qua email.

99
 Hình 3.6 Giao diện kích hoạt thiết bị

3.5.2 Giao diện đăng nhập

Giao diện này hiển thị khi người dùng mở ứng dụng trên một thiết bị đã được
kích hoạt. Ứng dụng hiển thị tên người dùng ở lần kích hoạt trước và yêu cầu nhập
mật khẩu.

100
 Hình 3.7 Giao diện đăng nhập

3.5.3 Giao diện cá nhân

Giao diện này chỉ hiển thị khi người dùng chọn mục Cá nhân ở thanh tùy
chọn bên dưới. Yêu cầu người dùng phải đăng nhập. Giao diện hiển thị các thông
tin cá nhân của người dùng, chứa các thông tin bổ sung liên quan đến ứng dụng,
các tùy chọn cài đặt ứng dụng theo sở thích.

101
 Hình 3.8 Giao diện cá nhân

3.5.4 Giao diện cập nhật tài khoản

Giao diện này hiển thị khi người dùng chọn mục Cá nhân/Tài khoản của
tôi/Sửa tài khoản. Yêu cầu người dùng phải đăng nhập. Giao diện hiển thị thông
tin họ tên và email người dùng, cho phép cập nhật các thông tin này.

102
 Hình 3.9 Giao diện cập nhật tài khoản

3.5.5 Giao diện đổi mật khẩu

Giao diện này hiển thị khi người dùng chọn mục Cá nhân/Tài khoản của
tôi/Đổi mật khẩu. Yêu cầu người dùng phải đăng nhập. Giao diện này cho phép
người dùng đổi mật khẩu mới bằng mật khẩu hiện tại.

103
 Hình 3.10 Giao diện đổi mật khẩu

3.5.6 Giao diện thông tin yêu cầu ký

Giao diện này hiển thị khi người dùng đăng nhập thành công hoặc khi người
dùng chọn mục Yêu cầu ở thanh tùy chọn bên dưới. Yêu cầu người dùng phải đăng
nhập. Giao diện này hiển thị danh sách các yêu cầu ký đang chờ, và người dùng có
thể chọn một yêu cầu ký để xem thông tin chi tiết hoặc thực hiện thao tác ký/từ
chối.

104
 Hình 3.11 Giao diện thông tin yêu cầu ký

3.5.7 Giao diện chấp nhận yêu cầu ký

Giao diện này hiển thị khi người dùng mở chi tiết một yêu cầu ký đăng chờ
và nhấn nút Chấp nhận. Yêu cầu người dùng phải đăng nhập. Giao diện này cho
phép người dùng chấp nhận yêu cầu ký, có thể nhập thêm lý do và bắt buộc nhập
mã OTP để xác nhận ký.

105
 Hình 3.12 Giao diện chấp nhận yêu cầu ký

3.5.8 Giao diện từ chối yêu cầu ký

Giao diện này hiển thị khi người dùng mở chi tiết một yêu cầu ký đăng chờ
và nhấn nút Từ chối. Yêu cầu người dùng phải đăng nhập. Giao diện này cho phép
người dùng từ chối yêu cầu ký, có thể nhập thêm lý do.

106
 Hình 3.13 Giao diện từ chối yêu cầu ký

3.5.9 Giao diện thông tin chứng thư

Giao diện này hiển thị khi người dùng chọn mục Cá nhân/Chứng thư. Yêu
cầu người dùng phải đăng nhập. Giao diện này hiển thị danh sách các chứng thư
người dùng sở hữu, và người dùng có thể chọn một chứng thư để xem thông tin
chi tiết.

107
 Hình 3.14 Giao diện thông tin chứng thư

3.5.10 Giao diện cài đặt ứng dụng

Giao diện này hiển thị khi người dùng chọn mục Cá nhân/Cài đặt Ứng dụng.
Yêu cầu người dùng phải đăng nhập. Giao diện này cho phép người dùng thay đổi
các tùy chọn ngôn ngữ, giao diện theo sở thích cá nhân.

108
Hình 3.15. Giao diện cài đặt

109
 KẾT LUẬN

Luận văn đã giới thiệu một cái nhìn tổng quát về mật mã và chữ ký số, các
thành phần, quy trình và các tiêu chuẩn ký số từ xa. Luận văn cũng đề xuất và phát
triển một ứng dụng hỗ trợ ký số từ xa phù hợp với các tiêu chuẩn đặt ra. Xét về cơ
bản, hệ thống đã thỏa mãn đầy đủ các yêu cầu ban đầu đặt ra, cung cấp đủ các chức
năng phù hợp phục vụ cho quá trình ký số từ xa, bao gồm xác thực, quản lý yêu
cầu ký, quản lý chứng thư số. Hệ thống có tiềm năng được phát triển thêm và áp
dụng vào thực tiễn giúp đơn giản hóa và tăng tính an toàn cho các giao dịch từ xa.

Hướng phát triển tiếp theo:

• Đánh giá khả năng chịu tải.

• Tăng khả năng mở rộng của hệ thống.
• Phát triển thêm các tính năng đăng ký tài khoản, xem tài liệu, cập nhật
thông tin chứng thư số,…

Do thời gian làm luận văn có hạn, tôi hy vọng nhận được nhiều góp ý để đồ
án được hoàn thiện tốt hơn.

110
 TÀI LIỆU THAM KHẢO

[1] BTTTT, Thông tư 16/2019/TT-BTTTT: Quy định Danh mục tiêu chuẩn bắt
buộc áp dụng về chữ ký số và dịch vụ chứng thực chữ ký số theo mô hình ký
số trên thiết bị di động và ký số từ xa, 2019.

[2] NEAC, Báo cáo tình hình phát triển và ứng dụng chữ ký số tại Việt Nam năm
2019, Nhà xuất bản Thông tin và Truyền thông, 2019.

[3] CEN, EN 419241-1:2018: Trustworthy Systems Supporting Server Signing

- Part 1: General system security requirements, 2018.

[4] CEN, EN 419221-5:2018: Protection Profiles for TSP Cryptographic

modules - Part 5: Cryptographic Module for Trust Services, 2018.

[5] CEN, EN 419241-2:2019: Trustworthy Systems Supporting Server Signing

- Part 2: Protection Profile for QSCD for Server Signing, 2019.

[6] D. R. Stinson, Cryptography: Theory and Practice, Third Edition, Chapman

and Hall/CRC, 2015.

[7] J. P. Aumasson, Serious Cryptography: A Practical Introduction to Modern

Encryption, No Starch Press, 2017.

[8] Linda A. Bertram, Gunther van Dooble, Nomenclatura - Encyclopedia of

modern Cryptography and Internet Security: From AutoCrypt and
Exponential Encryption to Zero-Knowledge-Proof Keys, Books on Demand,
2019.

[9] ETSI, ETSI TS 119 431-1: Electronic Signatures and Infrastructures (ESI);
Policy and security requirements for trust service providers; Part 1: TSP
service components operating a remote QSCD/SCDev, 2018.

111
[10] ETSI, ETSI TS 119 431-2: Electronic Signatures and Infrastructures (ESI);
Policy and security requirements for trust service providers; Part 2: TSP
service components supporting AdES digital signature creation, 2018.

[11] ETSI, ETSI TS 119 432: Electronic Signatures and Infrastructures (ESI);
Protocols for remote digital signature creation, 2018.

[12] Iain Beveridge, Nick Pope, Faithe Wempen, The eIDAS Regulation For
Dummies, Entrust Special Edition, Chichester, West Sussex, United
Kingdom: John Wiley & Sons, Ltd, 2021.

[13] Katz, Jonathan and Lindell, Yehuda, Introduction to Modern Cryptography,

CRC Press, 2014.

[14] Paar, Christof and Jan Pelzl, Understanding Cryptography: A Textbook for
Students and Practitioners, Springer, 2009.

[15] W. Mao, Modern Cryptography Theory and Practice, 2004.

[16] Goldreich, Oded, Foundations of Cryptography, Cambridge University

Press, 2004.

[17] Bertram, Linda A. / Dooble, Gunther van, Transformation of Cryptography:

Fundamental concepts of Encryption, Milestones, Mega-Trends and
sustainable Change in regard to Secret Communications and its
Nomenclatura, 2019.

[18] M. Bishop, Introduction to Computer Security, Addison - Wesley, 2004.

[19] W. Stallings, Cryptography And Network Security: Principles and Practices,

Prentice Hall, 2005.

[20] C. Pfleeger, Security in Computing, Prentice Hall, 2006.

[21] B. Schneier, Applied Cryptography, Wiley, 1996.

112
 TÓM TẮT NỘI DUNG LUẬN VĂN

Đề tài: Ký số từ xa và ứng dụng

Tác giả luận văn: Nguyễn Duy Giang

Chuyên ngành: Toán Tin

Mã số SV: CB190315

Người hướng dẫn: TS. Vũ Thành Nam, viện Toán Tin ứng dụng, trường Đại
học Bách Khoa Hà Nội

Nội dung tóm tắt:

Hiện nay, việc sử dụng mật mã khoá công khai và dịch vụ chứng thực điện
tử để đảm bảo an toàn thông tin trong các hoạt động giao dịch điện tử là giải pháp
được nhiều quốc gia trên thế giới sử dụng. Chữ ký số ngày càng trở nên phổ biến
do những ưu điểm tốc độ ký nhanh, chính xác và dễ dàng kiểm định. Tuy nhiên
vẫn còn tồn tại những hạn chế như tốn kém, kém linh hoạt do cần thiết bị chuyên
dùng.

Với sự phát triển mạnh mẽ của thiết bị di động (máy tính bảng, điện thoại di
động, laptop,…), việc trao đổi thông tin, thực hiện các giao dịch điện tử trực tuyến
như tài chính, hành chính công ngày càng trở nên phổ biến. Không nằm ngoài xu
thế đó, chữ ký số cũng đã và đang được các quốc gia trên thế giới nghiên cứu và
triển khai trên nền tảng di dộng, tùy thuộc vào trình độ phát triển CNTT và hiện
trạng ứng dụng KPI của từng nước. Ký số trên di động đã tháo gỡ những khó khăn
của chữ ký số truyền thống, giúp việc ký số trở nên dễ dàng, minh bạch và tiết
kiệm chi phí.

Ở Việt Nam, chữ ký số và dịch vụ chứng thực chữ ký số truyền thống trên
các máy tính đã được triển khai rộng rãi. Tuy nhiên, chữ ký số mới chỉ được sử
dụng chủ yếu bởi các cơ quan chính phủ và doanh nghiệp. Việc ứng dụng chữ ký
số qua thiết bị di động đang có nhu cầu rất lớn và sẽ giúp thêm nhiều đối tượng cá
nhân và doanh nghiệp tiếp cận được với chữ ký số.

113
 Thấy được tiềm năng của chữ ký số từ xa, qua báo cáo luận văn tốt nghiệp
này, tôi đi vào nghiên cứu về chữ ký số cũng như các thành phần, quy trình và tiêu
chuẩn ký số từ xa, và áp dụng trong việc xây dựng ứng dụng hỗ trợ ký số từ xa.

Trong khuôn khổ đề tài, tôi tập trung vào các vấn đề nghiên cứu sau đây:

• Mật mã và chữ ký số
• Các thành phần, quy trình và các tiêu chuẩn ký số từ xa.
• Ứng dụng hỗ trợ ký số từ xa.

Kết quả của nghiên cứu này định hình hóa một phương án triển khai hệ thống,
ứng dụng hỗ trợ ký số từ xa phù hợp với các tiêu chuẩn được ban hành của Việt
Nam và thế giới.

Ứng dụng sẽ giúp người dùng tiết kiệm thời gian, chi phí và bảo đảm an toàn
cho các giao dịch. Dịch vụ web cũng có thể được công khai để sử dụng bởi các
ứng dụng hỗ trợ ký số từ xa khác.

Giáo viên hướng dẫn

Ký và ghi rõ họ tên

114