769/QĐ-BTTTT

BỘ THÔNG TIN VÀ TRUYỀN THÔNG ------- CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM Độc lập - Tự do - Hạnh phúc --------------- 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: - Như Điều 3; - Bộ trưởng Nguyễn Mạnh Hùng; - Các Thứ trưởng; - Cổng thông tin điện tử của Bộ; - Lưu: VT, NEAC. KT. BỘ TRƯỞNG THỨ TRƯỞNG Nguyễn Huy Dũ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 _ signe d 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/f i le 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 _i d 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 _f iles . 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_co d e 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 (Neu 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)