Quyết định 769/QĐ-BTTTT 2022 Hướng dẫn kết nối ứng dụng sử dụng chữ ký số với tổ chức cung cấp dịch vụ
- Tóm tắt
- Nội dung
- VB gốc
- Tiếng Anh
- Hiệu lực
- VB liên quan
- Lược đồ
- Nội dung MIX
- Tổng hợp lại tất cả các quy định pháp luật còn hiệu lực áp dụng từ văn bản gốc và các văn bản sửa đổi, bổ sung, đính chính…
- Khách hàng chỉ cần xem Nội dung MIX, có thể nắm bắt toàn bộ quy định pháp luật hiện hành còn áp dụng, cho dù văn bản gốc đã qua nhiều lần chỉnh sửa, bổ sung.
- Tải về
Đây là tiện ích dành cho thành viên đăng ký phần mềm.
Quý khách vui lòng Đăng nhập tài khoản LuatVietnam và đăng ký sử dụng Phần mềm tra cứu văn bản.
Đây là tiện ích dành cho thành viên đăng ký phần mềm.
Quý khách vui lòng Đăng nhập tài khoản LuatVietnam và đăng ký sử dụng Phần mềm tra cứu văn bản.
thuộc tính Quyết định 769/QĐ-BTTTT
Cơ quan ban hành: | Bộ Thông tin và Truyền thông | Số công báo: Số công báo là mã số ấn phẩm được đăng chính thức trên ấn phẩm thông tin của Nhà nước. Mã số này do Chính phủ thống nhất quản lý. | Đang cập nhật |
Số hiệu: | 769/QĐ-BTTTT | Ngày đăng công báo: | Đang cập nhật |
Loại văn bản: | Quyết định | Người ký: | Nguyễn Huy Dũng |
Ngày ban hành: Ngày ban hành là ngày, tháng, năm văn bản được thông qua hoặc ký ban hành. | 27/04/2022 | Ngày hết hiệu lực: Ngày hết hiệu lực là ngày, tháng, năm văn bản chính thức không còn hiệu lực (áp dụng). | Đang cập nhật |
Áp dụng: Ngày áp dụng là ngày, tháng, năm văn bản chính thức có hiệu lực (áp dụng). | Tình trạng hiệu lực: Cho biết trạng thái hiệu lực của văn bản đang tra cứu: Chưa áp dụng, Còn hiệu lực, Hết hiệu lực, Hết hiệu lực 1 phần; Đã sửa đổi, Đính chính hay Không còn phù hợp,... | Đã biết Vui lòng đăng nhập tài khoản gói Tiêu chuẩn hoặc Nâng cao để xem Tình trạng hiệu lực. Nếu chưa có tài khoản Quý khách đăng ký tại đây! | |
Lĩnh vực: | Thông tin-Truyền thông |
TÓM TẮT VĂN BẢN
Hướng dẫn kết nối ứng dụng sử dụng chữ ký số với tổ chức cung cấp dịch vụ
Ngày 27/4/2022, Bộ Thông tin và Truyền thông ra Quyết định 769/QĐ-BTTTT về việc ban hành hướng dẫn kết nối ứng dụng sử dụng chữ ký số với tổ chức cung cấp dịch vụ chứng thực chữ ký số công cộng đối với hình thức ký số từ xa.
Theo đó, tài liệu hướng dẫn gồm 13 trang, đặc tả các giao thức kết nối để chuyển yêu cầu ký số từ một dịch vụ/ứng dụng có kết nối mạng (SP) đến Tổ chức cung cấp dịch vụ chứng thực chữ ký số (CA) và nhận lại chứng thư số của người ký, kết quả ký số (gồm: Định nghĩa giao thức; Yêu cầu kỹ thuật; Chính sách;...)
Giao thức này có thể được ứng dụng để thực hiện các hành động khác của người dùng (đăng ký, đăng nhập,...). Tuy nhiên, tài liệu hướng dẫn này không áp dụng đối với các dịch vụ/ứng dụng đã tích hợp chức năng ký số, các phần mềm ký số.
Ngoài ra, trong trường hợp pháp luật chuyên ngành có quy định về định dạng của dữ liệu thì áp dụng trực tiếp quy định đó.
Quyết định 769/QĐ-BTTTT có hiệu lực kể từ ngày ký.
Xem chi tiết Quyết định 769/QĐ-BTTTT tại đây
tải Quyết định 769/QĐ-BTTTT
Nếu chưa có tài khoản, vui lòng Đăng ký tại đây!
BỘ THÔNG TIN VÀ | CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM |
Số: 769/QĐ-BTTTT | Hà Nội, ngày 27 tháng 4 năm 2022 |
QUYẾT ĐỊNH
Ban hành Hướng dẫn kết nối ứng dụng sử dụng chữ ký số với tổ chức cung cấp dịch vụ chứng thực chữ ký số công cộng đối với hình thức ký số từ xa
___________
BỘ TRƯỞNG BỘ THÔNG TIN VÀ TRUYỀN THÔNG
Căn cứ Luật Giao dịch điện tử ngày 29 tháng 11 năm 2005;
Căn cứ Nghị định số 130/2018/NĐ-CP ngày 27 tháng 9 năm 2018 của Chính phủ 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ố;
Căn cứ Nghị định số 17/2017/NĐ-CP ngày 17 tháng 02 năm 2017 của Chính phủ quy định chức năng, nhiệm vụ, quyền hạn và cơ cấu tổ chức của Bộ Thông tin và Truyền thông;
Căn cứ Thông tư số 16/2019/TT-BTTTT ngày 05 tháng 12 năm 2019 của Bộ trưởng Bộ Thông tin và Truyền thông 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;
Theo đề nghị của Giám đốc Trung tâm Chứng thực điện tử quốc gia.
QUYẾT ĐỊNH:
Điều 1. Ban hành kèm theo Quyết định này Hướng dẫn kết nối ứng dụng sử dụng chữ ký số với tổ chức cung cấp dịch vụ chứng thực chữ ký số công cộng đối với hình thức ký số từ xa.
Điều 2. Quyết định này có hiệu lực thi hành kể từ ngày ký.
Điều 3. Chánh Văn phòng, Giám đốc Trung tâm Chứng thực điện tử quốc gia, Thủ trưởng các đơn vị thuộc Bộ, các tổ chức, cá nhân có liên quan chịu trách nhiệm thi hành Quyết định này./.
Nơi nhận: | KT. BỘ TRƯỞNG |
HƯỚNG DẪN
KẾT NỐI ỨNG DỤNG SỬ DỤNG CHỮ KÝ SỐ VỚI TỔ CHỨC CUNG CẤP DỊCH VỤ CHỨNG THỰC CHỮ KÝ SỐ CÔNG CỘNG ĐỐI VỚI HÌNH THỨC KÝ SỐ TỪ XA
(Ban hành kèm theo Quyết định số 769/QĐ-BTTTT ngày 27 tháng 4 năm 2022 của Bộ trưởng Bộ Thông tin và Truyền thông)
I. Giới thiệu
Hướng dẫn này là đặc tả các giao thức kết nối để chuyển yêu cầu ký số từ một dịch vụ/ứng dụng có kết nối mạng (SP) đến Tổ chức cung cấp dịch vụ chứng thực chữ ký số (CA) và nhận lại chứng thư số của người ký, kết quả ký số.
Hướng dẫn này không áp dụng đối với các dịch vụ/ứng dụng đã tích hợp chức năng ký số, các phần mềm ký số.
Trong trường hợp pháp luật chuyên ngành có quy định về định dạng của dữ liệu thì áp dụng trực tiếp quy định đó.
Giao thức này có thể được ứng dụng để thực hiện các hành động khác của người dùng (đăng ký, đăng nhập,...).
Do đặc thù của ký số từ xa cần phải có sự xác nhận của người sử dụng thông qua một phương tiện điện tử khác nên giao thức ký được miêu tả theo tài liệu là giao thức ký không đồng bộ. Tức là giữa SP và CA không duy trì kết nối trong quá trình CA xác thực với người dùng. Sau khi người dùng xác thực ký, kết quả ký số sẽ được CA trả về trên một kết nối khác tuân theo phương thức kết nối webhook như mô tả trong tài liệu này. Tuy nhiên, trong trường hợp khả thi, SP và CA được khuyến khích duy trì kết nối khoá phiên theo chuẩn TLS.
II. Đặc tả chi tiết
1. Sơ đồ
Hình 1. Sơ đồ luồng kết nối ký số tài liệu
2. Luồng xử lý yêu cầu ký số
2.1. Khởi tạo yêu cầu ký số
Người sử dụng thực hiện yêu cầu ký số.
SP đóng gói dưới dạng .xml (hoặc json) yêu cầu ký số bao gồm: thông tin xác thực tài khoản của SP (sp_credentials), mã tài liệu (doc_id), mã giao dịch (transaction_id), mã định danh người ký trong hệ thống SP (user_id), số xê-ri của chứng thư số (serial_number, trường hợp người dùng có nhiều hơn 01 chứng thư số), thời gian thực hiện yêu cầu.
SP gửi dữ liệu đã được đóng gói theo giao thức TLS cho CA.
SP gọi CA để lấy thông tin chứng thư.
SP tiến hành băm tài liệu cần được ký số và nén dữ liệu.
SP gửi mã băm (file_hash), thông tin xác thực tài khoản của SP (sp_credentials), mã giao dịch (transaction_id) cho CA.
2.2. Thực hiện ký số
CA bóc tách thông tin các thông tin trong dữ liệu .xml (hoặc json).
CA xác thực sp_credentials.
CA tìm thuê bao từ user_id, gửi lại chứng thư số cho SP.
CA gửi yêu cầu và nhận lại xác nhận ký đến người dùng (thông qua app của CA) để thực hiện quy trình ký số.
CA thực hiện cấp dấu thời gian cho giao dịch (nếu có).
2.3. Trả kết quả
CA đóng gói kết quả ký số dưới dạng .xml (hoặc json), gồm: chữ ký số theo từng mã tài liệu (doc_id), chứng thư số của người ký (user_cert), dấu thời gian (nếu có), thời gian thực hiện yêu cầu, mã giao dịch (transaction_id).
CA gửi dữ liệu đã được đóng gói theo giao thức TLS cho SP.
SP gắn chữ ký vào file và hoàn tất quy trình ký.
Hình thức trả:
Thông qua cơ chế webhook: Khi có kết quả ký tài liệu, CA sẽ gửi kết quả cho SP theo url webhook SP đăng ký trước với CA.
3. Định nghĩa giao thức
3.1. API lấy thông tin chứng thư
Mô tả:
- SP gọi CA.
- Khi người dùng tạo yêu cầu ký số, SP gọi CA để lấy dữ liệu chứng thư người dùng.
- CA sẽ kiểm tra và trả về danh sách chứng thư của người dùng.
- Khi có thông tin chứng thư, SP sử dụng dữ liệu này để tính toán hash file cần ký.
a. Đặc tả API
Phương thức: GET
Đường dẫn: https://x.x.x.x/get_certificate (x.x.x.x là URL API sẽ do mỗi CA tự quyết định)
Tham số đầu vào:
STT | Tham số | Kiểu dữ liệu | Bắt buộc | Chú thích |
1 | sp_id | String | Tên tài khoản của SP do CA cung cấp | |
2 | sp_password | String | Mật khẩu do CA cung cấp cho SP | |
3 | user_id | String | Số CCCD/CMND/Hộ chiếu/Mã số thuế/ của cá nhân/tổ chức muốn đăng nhập | |
4 | serial_number | String | Số xê-ri của chứng thư số | |
5 | transaction_id | String | Mã giao dịch khởi tạo bởi SP |
Ví dụ tham số đầu vào:
Tham số đầu ra:
STT | Tham số | Kiểu dữ liệu | Chú thích |
1 | status_code | Int | Mã request thành công hoặc mã lỗi tương ứng. VD: 200, 401,403, 500... |
2 | message | String | Thông điệp thành công hoặc thông điệp lỗi tương ứng với mã trạng thái ở status_code. |
3 | cert_id | String | Định danh chứng thư số (còn gọi là cert alias) |
4 | cert_data | String | Raw data chứng thư (dạng base64) |
5 | chain_data | List<String> | List chứng thư, gồm 3 phần tử. Phần tử đầu tiên là chứng thư số người ký, thứ hai là chứng thư số của CA, cuối cùng là chứng thư số root do NEAC cấp. |
6 | serial_number | String | Số xê-ri của chứng thư số |
7 | transaction_id | String | Mã giao dịch khởi tạo bởi SP |
Ví dụ tham số đầu ra:
3.2. API ký số tài liệu
a. Mô tả
- SP gọi CA, cung cấp mã giao dịch (transaction_id)
- SP dùng dữ liệu chứng thư người dùng để tính toán mã băm của tệp cần ký.
- SP gửi dữ liệu file_hash đến CA để thực hiện ký số tài liệu.
- SP sử dụng mã giao dịch để lấy thông tin chữ ký khi cần.
- Trong trường hợp đặc thù cần thiết, SP và CA có thể trao đổi thêm để trả về luôn kết quả ký tại request này (giữ và chờ request).
b. Đặc tả API
Phương thức: POST
Đường dẫn: https://x.x.x.x/sign (x.x.x.x là URL API sẽ do mỗi CA tự quyết định)
Tham số đầu vào:
STT | Tham số | Kiểu dữ liệu | Bắt buộc | Chú thích |
1 | sp_id | String | Tên tài khoản của SP do CA cung cấp | |
2 | sp_password | String | Mật khẩu do CA cung cấp cho SP | |
3 | user_id | String | Số CCCD/CMND/Hộ chiếu/Mã số thuế/ của cá nhân/tổ chức muốn đăng nhập | |
4 | data_to_be_signed | String | Chuỗi biểu diễn của tài liệu được yêu cầu ký số (base64 string với file, hex với hash) | |
5 | doc_id | String | Mã tài liệu yêu cầu ký số (Mã này cần được hiển thị đồng thời tại giao diện của SP và tại giao diện tại ứng dụng của CA khi người dùng thực hiện xác thực yêu cầu ký số) | |
6 | file_type | String | Loại file: xml/json/word/pdf/excel/... | |
7 | sign_type | String | Loại ký số: hash/file | |
8 | serial_number | String | Số xê-ri của chứng thư số (trong trường hợp một chủ thể có nhiều chứng thư số) | |
9 | time_stamp | String | Thời gian người dùng gửi yêu cầu ký số. Định dạng: YYYYMMddHHmmSS | |
10 | transaction_id | String | Mã giao dịch khởi tạo bởi SP |
Lưu ý: Truyền data_to_be_signed dạng base64 dung lượng tăng thêm 30%, khuyến nghị sử dụng mã băm (hash) trong việc chuyển yêu cầu ký.
Ví dụ tham số đầu vào:
Tham số đầu ra:
STT | Tham số | Kiểu dữ liệu | Chú thích |
1 | status_code | Int | Mã request thành công hoặc mã lỗi tương ứng. VD: 200, 401, 403, 500... |
2 | message | String | Thông điệp thành công hoặc thông điệp lỗi tương ứng với mã trạng thái ở status_code |
3 | transaction_id | String | Mã giao dịch khởi tạo bởi SP |
4 | doc_id | String | Mã tài liệu yêu cầu ký số (Mã này cần được hiển thị đồng thời tại giao diện của SP và tại giao diện tại ứng dụng của CA khi người dùng thực hiện xác thực yêu cầu ký số) |
5 | signature_value | String | Dữ liệu chữ ký gắn với tài liệu (dạng base64) |
6 | timestamp_signature | String | Chữ ký của CA lên dấu thời gian của giao dịch ký số |
Ví dụ tham số đầu ra:
a. Đối với trường hợp ký không đồng bộ:
b. Đối với trường hợp ký đồng bộ: Khi theo cơ chế đồng bộ (giữ request ký và chờ xác nhận của người dùng) thì CA sẽ trả về kèm theo dữ liệu ký số file ở trường signed_files. Thời gian chờ xác nhận của người dùng phụ thuộc vào chính sách của từng CA. Sau khi hết thời gian chờ xác nhận, phiên giao dịch sẽ bị hủy bởi SP và yêu cầu ký số được xem là không thành công.
3.3. API webhook nhận thông tin ký tài liệu
a. Mô tả
- CA gọi SP theo url đăng ký trước.
- Sau khi CA có kết quả ký số tài liệu, CA sẽ gửi kết quả về cho SP.
- SP gắn chữ ký vào file, trả về cho người dùng, kết thúc luồng ký.
b. Đặc tả API
Phương thức: POST
Đường dẫn: https://x.x.x.x/recv_signature (x.x.x.x là URL API sẽ do mỗi CA tự quyết định)
Tham số đầu vào:
STT | Tham số | Kiểu dữ liệu | Bắt buộc | Chú thích |
1 | sp_id | String | Tên tài khoản của SP do CA cung cấp (SP có thể dùng để phân biệt request của CA nào gửi về) | |
2 | status_code | int | Mã request thành công hoặc mã lỗi tương ứng. VD: 200, 401, 403, 500... | |
3 | message | String | Thông điệp thành công hoặc thông điệp lỗi tương ứng với mã trạng thái ở status_code | |
4 | transaction_id | String | Mã giao dịch khởi tạo bởi SP | |
5 | doc_id | String | Mã tài liệu yêu cầu ký số | |
6 | signature_value | String | Dữ liệu chữ ký gắn với tài liệu (dạng base64) | |
7 | timestamp_signature | String | Chữ ký của CA lên dấu thời gian của giao dịch ký số |
Ví dụ tham số đầu vào:
Tham số đầu ra:
STT | Tham số | Kiểu dữ liệu | Chú thích |
1 | status_code | Int | Mã request thành công hoặc mã lỗi tương ứng. VD: 200, 401, 403, 500... |
2 | message | String | Thông điệp thành công hoặc thông điệp lỗi tương ứng với mã trạng thái ở status_code |
Ví dụ tham số đầu ra:
3.4. Bảng mã trạng thái
STT | Status_code | Chú thích |
1 | 200 | Thành công |
2 | 400 | Tài liệu không hợp lệ |
3 | 401 | Credentials không hợp lệ |
4 | 403 | Chứng thư bị thu hồi hoặc không rõ định dạng |
5 | 500 | Lỗi hệ thống |
| ... | Các lỗi khác (Nếu có) |
- Bảng mã lỗi này tượng trưng cho các nhóm mã trạng thái cơ bản: thành công (mã 2xx, ví dụ 201, 202...), không hợp lệ do phía người dùng (mã 4xx, ví dụ 401, 402...) và lỗi hệ thống (mã 5xx, ví dụ 500, 503...).
- Nếu CA có hệ thống mã trạng thái riêng thì có thể áp dụng hệ thống mã trạng thái đó, nhưng bắt buộc phải có đầy đủ 5 nhóm mã trạng thái cơ bản như trên và phải được công bố cho các bên muốn kết nối.
III. Chính sách
1. Trách nhiệm chung:
Trách nhiệm giữa tổ chức cung cấp dịch vụ (SP) và tổ chức cung cấp dịch vụ chứng thực ký số cộng cộng (CA) khi sử dụng giao thức quy định tại hướng dẫn này:
- SP và CA có trách nhiệm thỏa thuận SP_credentials với độ an toàn phù hợp với yêu cầu kỹ thuật được nêu chi tiết ở Phụ lục, quản lý và sử dụng an toàn, bí mật thông tin này.
- SP và CA có trách nhiệm thống nhất về các địa chỉ URL dành cho yêu cầu ký số, mã trạng thái và thông điệp trong trường hợp kết nối thành công cũng như lỗi.
- SP và CA có trách nhiệm thiết lập đường truyền TLS trong việc truyền, nhận dữ liệu, tránh trường hợp bị tấn công dẫn đến lộ, lọt dữ liệu.
2. Trách nhiệm của SP:
- Xác thực và chịu trách nhiệm về thông tin được truyền tải;
- Bảo mật thông tin của người dùng khi nhận được chứng thư số;
- Có phương án ngăn chặn việc lạm dụng giao thức này cho các mục đích khác, bảo vệ quyền lợi người dùng.
3. Trách nhiệm của CA:
- Đảm bảo tính sẵn sàng của dịch vụ ký số để phục vụ nhu cầu của SP.
- Đảm bảo hệ thống ký số đáp ứng các tiêu chuẩn.
YÊU CẦU KỸ THUẬT
STT | Nội dung | Yêu cầu kỹ thuật |
1 | sp_credentials | Chuẩn bị, thực thi và so sánh chuỗi username và password (theo RFC 8265) |
2 | Mã băm (hash) | Mã băm phải đạt được ít nhất độ an toàn theo chuẩn băm SHA (theo RFC 6234) hoặc cao hơn. |
3 | Ký số | Theo Thông tư số 22/2020 của Bộ Thông tin và Truyền thông Quy định về yêu cầu kỹ thuật đối với phần mềm ký số, phần mềm kiểm tra chữ ký số |
4 | TLS | Kết nối đạt chuẩn an toàn tầng giao vận TLS 1.3 (theo RFC 8446) |
5 | Hex | Chuẩn mã hóa base16, base32 và base64 (theo RFC 4648) |
6 | Chứng thư số của người dùng | Chứng thư số đạt chuẩn x509 (theo RFC 5280) |