Kiến trúc thẻ Quantum Safe trên Java Card – từ chip bảo mật đến tích hợp ứng dụng doanh nghiệp

1. Vì sao mô hình thẻ Quantum Safe có ý nghĩa kỹ thuật thực sự

Trong nhiều chương trình chuyển đổi hậu lượng tử, thách thức không nằm ở việc chọn thuật toán trên lý thuyết, mà ở việc đưa thuật toán mới vào môi trường vận hành thực tế: thẻ thông minh, đầu đọc, phần mềm trung gian trên máy tính, ứng dụng ký số, định dạng gói chữ ký và quy trình nghiệp vụ đang tồn tại.

Với sản phẩm dựa trên thẻ thông minh, mục tiêu không chỉ là “có ML-DSA trên chip”, mà là tạo ra một chuỗi vận hành hoàn chỉnh: ứng dụng gọi phần mềm trung gian, phần mềm trung gian gọi thẻ, applet kích hoạt hàm mật mã PQC, kết quả được đóng gói thành định dạng chữ ký mà hệ sinh thái doanh nghiệp có thể sử dụng.

2. Kiến trúc kỹ thuật tổng thể

Một triển khai thẻ Quantum Safe theo định hướng Java Card / JavaCOS thường được chia thành 5 lớp rõ ràng:

• Lớp silicon / bộ điều khiển bảo mật: cung cấp phần cứng an toàn, vùng lưu khóa, bộ gia tốc hoặc thư viện mật mã mức nền.
• Lớp hệ điều hành thẻ (JavaCOS): quản lý vòng đời ứng dụng, cung cấp API hoặc hàm mật mã cần thiết cho applet.
• Lớp PQC applet: chịu trách nhiệm thiết kế mô hình đối tượng, tập lệnh và logic nghiệp vụ trên thẻ.
• Lớp phần mềm trung gian trên máy tính: cầu nối giữa thẻ thông minh với Windows CSP/KSP hoặc macOS CryptoTokenKit.
• Lớp ứng dụng nghiệp vụ: Adobe Acrobat, Microsoft Office, phần mềm ký nội bộ và các hệ thống quy trình doanh nghiệp.

Hình 1: Kiến trúc end-to-end của hệ thống thẻ Quantum Safe — từ ứng dụng đến chip bảo mật

3. Ranh giới kỹ thuật giữa JavaCOS và applet

Khi chuyển từ OpenPGP truyền thống sang hậu lượng tử, điểm quyết định không phải chỉ là viết lại applet. Điểm quyết định là JavaCOS có cung cấp được hàm mật mã PQC ở tầng applet hay không.

Nói cụ thể hơn, applet nên được thiết kế như một lớp điều phối và kiểm soát chính sách trên thẻ: quản lý đối tượng, xác thực điều kiện sử dụng, điều phối khe khóa, cung cấp tập lệnh APDU và gọi hàm mật mã do hệ điều hành thẻ hỗ trợ.

4. Thiết kế PQC applet: từ tư duy OpenPGP đến thiết kế hướng lệnh

Nếu xuất phát từ một OpenPGP applet đã chạy tốt trên Java Card 3.0.5, bước chuyển sang PQC không nên chỉ là “thêm một thuật toán mới”. Cách tiếp cận đúng là thiết kế lại một số lớp trừu tượng quan trọng:

• Khe khóa không còn bị ràng buộc tuyệt đối theo mô hình RSA / ECC cũ.
• Tập lệnh cần tách riêng phần quản lý khóa và phần thao tác ký.
• Applet cần dự tính dữ liệu vào/ra lớn hơn — có thể phải chia nhỏ qua nhiều lệnh APDU.
• Siêu dữ liệu về thuật toán, bộ tham số, trạng thái khóa và chính sách sử dụng cần được chuẩn hóa nội bộ.

// Ví dụ mô hình lệnh APDU (mang tính định hướng)

Mô hình trên phản ánh một nguyên tắc quan trọng: với PQC, tập lệnh nên rõ ràng, tuần tự và tránh phụ thuộc vào cách ánh xạ cũ của RSA / ECC.

5. Bài toán APDU, bộ nhớ và hiệu năng

PQC gần như chắc chắn tạo áp lực lên thẻ ở ba điểm: dung lượng đối tượng, kích thước khóa công khai và luồng dữ liệu khi ký. Điều này kéo theo ba bài toán kỹ thuật cần giải quyết rõ ràng:

5.1. Truyền tải APDU

Khi dữ liệu vào/ra vượt quá kích thước APDU thông thường, phần mềm trung gian và applet phải có cơ chế chia nhỏ dữ liệu ổn định. Tầng ứng dụng không nên biết chi tiết này — việc chia nhỏ cần được xử lý hoàn toàn ở phần mềm trung gian và giao thức nội bộ với applet.

5.2. Bố cục bộ nhớ

Applet phải tối ưu vòng đời đối tượng, tránh sao chép bộ đệm không cần thiết và hạn chế lưu nhiều trạng thái trung gian. Mọi đối tượng dài hạn trên thẻ cần có chiến lược phân loại rõ ràng: lưu trữ bền vững, tạm thời khi hủy chọn thẻ, và tạm thời khi khởi động lại.

5.3. Giới hạn hiệu năng

Với ký số trên máy tính, người dùng cuối vẫn kỳ vọng thời gian phản hồi chấp nhận được. Vì vậy, phần mềm trung gian cần được thiết kế để giảm thiểu số lần trao đổi không cần thiết, còn luồng lệnh trên thẻ cần tránh các bước kiểm tra lặp lại thừa.

6. Phần mềm trung gian: nơi quyết định khả năng thương mại hóa

Một trong những sai lầm phổ biến của các dự án dựa trên thẻ thông minh là đánh giá thấp vai trò của phần mềm trung gian. Trên thực tế, đây mới là lớp biến thẻ thông minh thành sản phẩm mà doanh nghiệp có thể sử dụng được.

Đối với sản phẩm Quantum Safe, phần mềm trung gian còn phải giải quyết thêm bài toán ánh xạ chữ ký PQC vào định dạng mà quy trình doanh nghiệp đang tiêu thụ. Nếu lớp này không đủ tốt, sản phẩm sẽ mắc kẹt ở mức “đã ký được trên thẻ nhưng chưa dùng được trong ứng dụng thực tế”.

7. Định dạng chữ ký và tích hợp ứng dụng

Ở góc độ tích hợp máy tính, ứng dụng không quan tâm nhiều đến cách thẻ xử lý nội bộ. Điều chúng quan tâm là có nhận được một đối tượng chữ ký phù hợp với luồng xử lý mà chúng đang hỗ trợ hay không.

Vì vậy, khi xây dựng sản phẩm thẻ Quantum Safe, cần phân tách rõ ràng ba lớp:

• Thao tác trên thẻ: cơ chế ký số được thực hiện bên trong thẻ thông minh.
• Đóng gói tại phần mềm trung gian: cách đóng gói kết quả thành cấu trúc mà tầng ứng dụng hiểu được.
• Chiến lược tương thích ứng dụng: ứng dụng nào hỗ trợ trực tiếp, ứng dụng nào cần quy trình kiểm soát hoặc bộ xác thực riêng.

8. Lộ trình hiện thực hợp lý

9. Giá trị kỹ thuật của hướng tiếp cận này

Ở góc độ kỹ thuật và sản phẩm, mô hình thẻ Quantum Safe có ba giá trị cốt lõi:

• Thứ nhất: tạo ra niềm tin dựa trên phần cứng ở mức cao cho các người dùng đặc quyền — khóa bí mật không bao giờ rời khỏi thẻ.
• Thứ hai: cho phép giữ nguyên quy trình ký số hiện hữu trên máy tính, thay vì buộc tổ chức thay đổi toàn bộ hệ thống.
• Thứ ba: đưa PQC từ “năng lực thuật toán” sang “năng lực triển khai thực tế” — và đây mới là tiêu chí thị trường đánh giá nhà cung cấp.