Những nguy cơ khi sử dụng chung chứng thư số cho lập mã và ký số
14:40 | 03/12/2015 | CÔNG NGHỆ PKI
Bài báo giải quyết vấn đề tranh cãi, khi sử dụng mỗi thiết bị đầu cuối chỉ phải dùng một chứng thư số với thuật toán mật mã RSA để đảm bảo đồng thời cả tính xác thực và tính bảo mật trên các VBĐT, đặt ra một vấn đề tranh cãi là liệu nó có làm ảnh hưởng đến các chức năng ký số hay lập mã và làm giảm độ an toàn của thuật toán ký số và thuật toán lập mã RSA hay không?
Mở đầu
Các ứng dụng ràng buộc PKI hay các ứng dụng PKI Client tích hợp các dịch vụ chứng thực số, hay chứng thực điện tử (CTĐT) vào ứng dụng công nghệ thông tin (CNTT) trên các giao dịch điện tử (GDĐT), thông điệp điện tử (TĐĐT) hay văn bản điện tử (VBĐT) trong quá trình hoạt động nhận các dịch vụ tin cậy từ ứng dụng PKI Server hay hạ tầng PKI.
Các ứng dụng PKI Client này sử dụng các chứng thư số (CTS) của các thuê bao đầu cuối (người dùng) trong quá trình hoạt động để cung cấp các dịch vụ ký số, kiểm tra hợp lệ chữ ký số (CKS), lập mã hay giải mã các giao dịch điện tử hay các VBĐT.
Thông thường các CTS cung cấp các thuật toán ký số, lập mã phi đối xứng RSA theo chuẩn PKCS#1. CTS số sử dụng để ký số sẽ tương ứng với thuật toán ký số RSA và CTS lập mã sẽ tương ứng với thuật toán lập mã phi đối xứng RSA. CTS với thuật toán ký số RSA có thể cung cấp các dịch vụ đảm bảo tính xác thực, tính toàn vẹn và tính không chối bỏ trên các VBĐT, trong khi đó CTS với thuật toán lập mã phi đối xứng RSA có thể cung cấp các dịch vụ đảm bảo tính bí mật trên các VBĐT.
Muốn có được các dịch vụ CTĐT đảm bảo cả tính xác thực và tính bí mật trên các VBĐT thì một thuê bao đầu cuối (TBĐC) cần phải sở hữu đồng thời CTS để ký số và CTS để lập mã. Việc này gây khó khăn cho các TBĐC khi phải quản lý nhiều CTS cùng một lúc.
Do tính đối ngẫu của thuật toán mật mã RSA, nên về mặt lý thuyết thì ký số và lập mã là hai quá trình ngược lại của cùng một thuật toán. Khi ký số một VBĐT người ký sử dụng khóa bí mật RSA của mình để ký số lên VBĐT. Người kiểm tra tính hợp lệ của CKS trên VBĐT sử dụng khóa công khai RSA của người ký số trên VBĐT.
Ngược lại, khi lập mã một VBĐT, người lập mã sử dụng khóa công khai RSA của người nhận để lập mã. Người nhận VBĐT sử dụng khóa bí mật RSA của mình để giải mã VBĐT đã được lập mã. Thuật toán RSA ký số và lập mã là hoàn toàn giống nhau.
Trên thực tế, có một vấn đề nảy sinh là, khi ứng dụng vào công việc, để tiết kiệm và tránh gây phiền hà cho mình, mỗi TBĐC muốn chỉ phải dùng một CTS với thuật toán mật mã RSA để đảm bảo đồng thời cả tính xác thực và tính bảo mật trên các VBĐT. Điều này đặt ra một vấn đề tranh cãi là liệu nó có làm ảnh hưởng đến các chức năng ký số hay lập mã và làm giảm độ an toàn của thuật toán ký số và thuật toán lập mã RSA hay không?
Bài báo này hướng đến việc giải quyết vấn đề tranh cãi nêu trên, dựa trên cơ sở khoa học mật mã hiện đại hiện nay, qua đó đưa ra khuyến nghị với các tổ chức, người dùng.
Các vấn đề chức năng và an toàn sử dụng
Về mặt chức năng chúng ta thấy rõ có sự phân biệt giữa chức năng ký số và chức năng lập mã.
Đối với chức năng ký số, khóa bí mật RSA được sinh ra một lần duy nhất và chỉ được lưu trữ bên trong thiết bị USB Token và đi liền với CTS tương ứng. Khóa bí mật sử dụng để ký số không thể được ủy nhiệm hoặc lưu trữ tại bất kỳ nơi khác ngoài thiết bị USB Token.
Nếu thiết bị USB Token bị thất lạc hoặc bị phá hủy thì TBĐC không thể tiếp tục ký số được, nhưng các VBĐT đã được ký số vẫn được đảm bảo tính xác thực bằng việc kiểm tra CKS trên VBĐT, sử dụng khóa công khai tương ứng của TBĐC đã ký số trên VBĐT.
Quy trình ký số như vậy cũng đảm bảo tính không chối bỏ của TBĐC trên VBĐT đã được ký số, vì chỉ có duy nhất một người dùng sở hữu thiết bị USB Token với CTS tương ứng có thể ký số trên VBĐT.
Chức năng lập mã thì khác, mỗi CTS lập mã ngoài bản sao khóa bí mật sử dụng để giải mã (được lưu bên trong thiết bị USB Token thuộc về TBĐC) thì còn có bản sao khóa bí mật lưu tại Cơ quan ủy nhiệm khóa. Trong trường hợp TBĐC làm mất bản sao khóa bí mật của mình, thì cơ quan ủy nhiệm khóa vẫn có thể cung cấp bản sao khóa bí mật để TBĐC có thể giải mã VBĐT đã được lập mã trước đây.
Nếu sử dụng chung một CTS cho cả ký số và lập mã, thì các tính chất mật mã sẽ bị nhầm lẫn và phá vỡ lẫn nhau. Khi sử dụng CTS lập mã để ký số, thì tính không chối bỏ bị phá vỡ (vì khóa bí mật không còn là duy nhất được TBĐC sở hữu bởi nữa, mà còn được sở hữu bởi cơ quan ủy nhiệm khóa. Vì vậy, cơ quan này cũng không thể chối bỏ là họ cũng có thể ký số trên VBĐT).
Trong trường hợp sử dụng CTS ký số để lập mã, thì về mặt lý thuyết, rất có thể TBĐC ký số trên VBĐT do chính người đó đã lập mã và điều này giống với việc chính người đó đã giải mã và làm lộ VBĐT cần giữ bí mật.
Thông thường, các CTS sử dụng để ký số thường có thời hạn sử dụng ngắn hơn các CTS sử dụng để lập mã. Khi sử dụng CTS cho cả hai mục đích, thì vòng đời của CTS sử dụng để ký số được coi là bị kéo dài bằng vòng đời của CTS sử dụng để lập mã, điều này dẫn đến sự không rõ ràng về chức năng. Ở khía cạnh khác, vấn đề an toàn được coi là quan trọng hơn so với sự không rõ ràng về chức năng khi sử dụng một CTS cho cả ký số và lập mã. Trong nhiều kịch bản ứng dụng, việc yêu cầu giải mã một VBĐT là có thể thực hiện và việc này sẽ dẫn đến việc giả mạo được CKS trên thông báo M.
Đầu tiên, kẻ muốn giả mạo CKS trên thông báo M băm thành thông báo C = Hash(M). Sau đó kẻ giả mạo CKS yêu cầu giải mã thông báo C để nhận được thông báo rõ Decrypt(C), đây thực chất chính là CKS trên thông báo M.
Chúng ta xem xét một kịch bản phức tạp. Trong kịch bản này bên nhận sẽ ký số vào thông báo nhận được và gửi lại cho bên gửi mà tuyệt nhiên không giải mã thông báo gửi đến. Giả sử kẻ giả mạo muốn giải mã thông báo mã c = me (mod N) của bên nhận thì anh ta chọn một số ngẫu nhiên r (r phải là nguyên tố cùng nhau với N hay GCD(N, r) = 1, N là số được sử dụng để tạo ra khóa bí mật và khóa công khai RSA (N = p*q)). Sau đó anh ta chọn thông báo mới m’ = me.re ((e, N) là khóa công khai)) và gửi cho bên nhận. Khi bên nhận ký số trên thông báo nhận được, thì chúng ta có m’d = (me.re)d = m.r (mod N) và chúng ta nhân kết quả với r-1 để nhận được m chính là thông báo bí mật đã được giải mã.
Trên thực tế người ta không ký số hoặc lập mã một cách đơn giản như trên các VBĐT lý thuyết. Đối với ký số, người ta băm thông báo cần ký số trước khi ký. Cả hai trường hợp ký số và lập mã các VBĐT đều được đệm thông báo (Padding) trước để thay đổi nội dung VBĐT và phá vỡ các tính chất đồng cấu nhân của thuật toán mật mã RSA, làm cho độ an toàn mật mã được nâng cao (như trong trường hợp chuẩn PKCS#1).
Đầu ra của các VBĐT được lập mã hoặc ký số cũng được đệm tuân theo chuẩn PKCS#7 cho phù hợp với các quá trình xử lý, lưu trữ và vận chuyển thông tin. Các chuẩn đệm này gây khó khăn đối với các tấn công lý thuyết nêu trên và người ta nghĩ rằng đã ngăn chặn được các tấn công như vậy trên thực hành, nhưng không phải vậy. Năm 1998, chính Daniel Bleichenbacher đã nghĩ ra cách thức tấn công có thể giải mã được bất kỳ một thông báo mã RSA nào mà không cần biết khóa bí mật tương ứng, bằng cách biến phần mềm hay thiết bị phần cứng chuyên dụng giải mã cần tấn công thành các hàm tiên tri đệm thông báo của mình.
Việc giải mã được bất kỳ một bản mã RSA nào mà không cần biết khóa bí mật tương ứng cũng đồng nghĩa với khả năng có thể giả mạo CKS trên bất kỳ thông báo nào, nếu các phần mềm hay thiết bị phần cứng chuyên dụng sử dụng cùng một CTS cho cả chức năng ký số và chức năng lập mã. Sự phức tạp ở đây là tấn công có thể áp dụng cho các thông báo đã áp dụng chuẩn đệm thông báo PKCS#1 tại đầu vào và chuẩn PKCS#7 tại các đầu ra.
Tuy nhiên, đối với chuẩn PKCS#1, tấn công giải mã được bất kỳ một thông báo mã nào mà không cần biết khóa bí mật tương ứng của Daniel Bleichenbacher áp dụng thành công trên thực tế đối với chuẩn PKCS#1 phiên bản 1.5.
Tấn công của Daniel Bleichenbacher còn có thể áp dụng cho lược đồ lập mã RSA-OAEP (Được đưa vào chuẩn PKCS#1 phiên bản 2.0 và 2.1) và những mô hình đệm thông báo tương tự. Chính vì vậy, PKCS#1 phiên bản 2.0 và phiên bản 2.1 cũng là không an toàn, nếu thuật toán RSA ký số và lập mã sử dụng cùng một cặp khóa RSA.
Vấn đề cần lưu ý là, nếu tách biệt chức năng ký số và chức năng lập mã, thì lược đồ ký số an toàn chứng minh được RSA-PSS trong chuẩn PKCS#1 phiên bản 2.1 hiện vẫn là an toàn. Nhưng nếu tấn công Bleichenbacher hiệu quả trên thực hành đối với lược đồ lập mã RSA-OAEP trong chuẩn PKCS#1 phiên bản 2.1 và không tách biệt chức năng ký số và chức năng lập mã, thì chính lược đồ ký số RSA-PSS cũng bị gián tiếp tổn hại theo.
Trong các kịch bản ứng dụng mà chỉ sử dụng một CTS với thuật toán mật mã RSA cho cả chức năng lập mã và ký số thì tính đối ngẫu là rất rõ ràng. Nếu lược đồ lập mã bị tổn hại, sẽ kéo theo lược đồ ký số cũng bị tổn hại và ngược lại. Chỉ khi tách biệt chức năng lập mã và ký số, thì mới loại trừ được hoàn toàn mối tương hỗ không mong muốn này.
Cũng không thể chắc chắn rằng các CTS với các thuật toán mật mã phi đối xứng khác sẽ không có mối tương hỗ giữa chức năng lập mã và ký số. Nhưng mối tương hỗ này không hiển hiện như đối với thuật toán mật mã RSA mà thôi.
Khuyến nghị
Sử dụng một CTS cho cả chức năng ký số và lập mã đối với thuật toán mật mã RSA sẽ tiết kiệm được một CTS trong sử dụng cho TBĐC, nhưng có thể dẫn đến sự nhầm lẫn chức năng và chịu các tấn công giả mạo CKS, hay giải mã thông báo đã lập mã.
Vấn đề này không chỉ tồn tại trong các thuật toán ký số hay lập mã RSA trên lý thuyết mà cả trên thực hành, tương ứng với các phương pháp đệm thông báo tại đầu vào của thuật toán RSA (như chuẩn PKCS#1) hay tại đầu ra của thuật toán RSA (như chuẩn PKCS#7) và các chuẩn khác.
Các phương pháp đệm thông báo đã giúp giảm được nhiều điểm yếu trên lý thuyết và ngăn chặn được nhiều tấn công thực hành. Hiện nay, chuẩn PKCS#1 phiên bản 2.1 trở lên (trong thực hành) được coi là an toàn vì chưa phát hiện được các tấn công hiệu quả. Bởi vậy, hiện tại sử dụng một CTS cho cả chức năng lập mã và ký số trên các VBĐT, nếu sử dụng đệm thông báo theo chuẩn PKCS#1 từ phiên bản 2.1 trở lên cũng không an toàn về mặt lý thuyết, nhưng an toàn về mặt thực hành (Do thuật toán tấn công Bleichenbacher chưa có cài đặt thực hành hiệu quả trong trường hợp này).
Nhưng người ta không dám chắc và càng không thể chứng minh được rằng, trong tương lai sẽ không xuất hiện các tấn công kiểu như tấn công của Daniel Bleichenbacher giải mã được các thông báo lập mã RSA bất kỳ, được lập mã bởi các ứng dụng hay các thiết bị phần cứng chuyên dụng mà không cần biết khóa bí mật.
Bởi vậy, việc không nên sử dụng cùng một CTS cho cả chức năng ký số và chức năng lập mã giúp giải quyết tận gốc các nguy cơ tấn công giả mạo CKS trên thực hành, ứng dụng ngay cả đối với chuẩn PKCS#1, cho dù tương ứng với bất kỳ phiên bản nào.
Ngay cả các CTS không sử dụng thuật toán RSA để ký số và lập mã, cũng không nên sử dụng chỉ một CTS cho cả chức năng ký số và lập mã để tránh những rắc rối về chức năng, cũng như những tấn công phá vỡ an toàn mật mã.
Việc sử dụng chung một CTS cho hai chức năng ký số và lập mã sẽ giảm bớt được một CTS đối với mỗi TBĐC. Tuy nhiên, nếu coi an toàn mật mã là ưu tiên hàng đầu, thì không được phép sử dụng một CTS cho cả hai chức năng này, trước hết đối với thuật toán mật mã RSA. Ngoài ra, các vấn đề rắc rối về sự khác biệt trong sử dụng đối với CTS ký số và CTS lập mã cũng cần xem xét nghiêm túc để tránh xảy ra những sự cố mất an toàn đáng tiếc. Có thể trong tương lai, khi sự phát triển của khoa học mật mã đạt được những thành tựu để có thể khẳng định rằng, việc sử dụng một CTS cho các chức năng ký số và chức năng lập mã (Và có thể là tất cả các chức năng) không làm phát sinh các tấn công làm suy yếu các thuật toán mật mã bên trong CTS về độ an toàn mật mã.
