Khi khóa bảo mật của một tổ chức chứng thực chỉ là… số 4

Một trong những khóa riêng của tổ chức chứng thực (CA) thuộc eMudhra chính là số 4. Không phải một số bắt đầu bằng 4, cũng không phải số 4 theo sau bởi vài trăm chữ số ngẫu nhiên — chỉ đơn giản là 4. Một khóa khác là 56, một khóa khác nữa là 115. Tất cả đều có thể khôi phục được từ các chứng chỉ công khai chỉ trong chưa đầy một giây.

Chuyện gì đã xảy ra?

Vào thứ Bảy ngày 17/10, một nhà nghiên cứu bảo mật đã báo cáo cho Apple, Google, Microsoft, Mozilla và eMudhra rằng khóa riêng của tám chứng chỉ trung gian của eMudhra đã bị xâm phạm. Chrome phát hành bản cập nhật CRLSet chặn chúng ngay trong buổi tối hôm đó, còn Mozilla chặn trên Firefox thông qua OneCRL chỉ vài giờ sau.

Đến thứ Ba ngày 20/10, Mozilla công bố công khai và phát hành bản cập nhật NSS loại bỏ root của eMudhra. Chrome xác nhận root này cũng sẽ bị gỡ khỏi Chrome Root Store v43.

Tám chứng chỉ trung gian bao gồm sáu CA cấp phát TLS (DV, OV và EV, mỗi loại hai thế hệ) và hai CA ký mã, tất cả đều được tạo vào tháng 4/2025. Mỗi chứng chỉ còn được Sectigo ký chéo bằng root AAA Certificate Services vào tháng 5/2025.

"Chúng là những khóa một byte yếu về bản chất mà bất kỳ ai cũng có thể phân tích, và vấn đề không thể nào được khoanh vùng." — Ian Carroll

Khóa riêng thực chất là gì?

Đây là các khóa đường cong elliptic trên đường cong P-384. Khóa riêng chỉ đơn giản là một số d. Khóa công khai — thứ được đưa vào chứng chỉ cho cả thế giới nhìn thấy — là d × G, với G là một điểm cố định trên đường cong.

Việc tính xuôi thì dễ, nhưng tính ngược từ khóa công khai về d được coi là bất khả thi. Toàn bộ mô hình bảo mật dựa trên điều này, và nó chỉ đứng vững nếu d là một số cực lớn. Một khóa P-384 đúng chuẩn phải là số ngẫu nhiên 384 bit, tức khoảng 10¹¹⁵ khả năng.

Khóa của eMudhra trông như thế này:

d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004

Trong khi khóa P-384 đúng chuẩn phải trông như thế này:

d = 0x48ac06790886c80c48d31691fd4c0fe9ce3207f9807f2fe571d6e4ec426d78644298fc53df2b92566970e757ac998c34

Đó là 47 byte số 0 rồi đến một byte duy nhất. Một byte chỉ có 256 giá trị khả dĩ, nên "việc tìm kiếm" chỉ là tính 1 × G, 2 × G, 3 × G… và dừng lại khi khớp với chứng chỉ — tối đa 255 bước.

Toàn bộ mọi thứ mà các CA này có thể cấp phát, mọi máy khách đã tin tưởng chúng, đều chỉ dựa trên tám bit.

Kết quả kiểm chứng

Nhà nghiên cứu đã tải toàn bộ 16 chứng chỉ bị ảnh hưởng và brute-force chúng. Tất cả đều sụp đổ ngay lập tức:

• EM DV TLS CA - G3B: d = 156
• EM DV TLS CA - G3C: d = 230
• EM EV TLS CA - G3B: d = 115
• EM EV TLS CA - G3C: d = 56
• EM OV TLS CA - G3B: d = 155
• EM OV TLS CA - G3C: d = 4
• EM OV CS CA - G3B: ký mã, d = 66
• EM OV CS CA - G3C: ký mã, d = 237

Điều đáng chú ý là không có gì trên những chứng chỉ này trông sai. Khóa công khai dẫn xuất từ d = 4 vẫn là một điểm hợp lệ trên đường cong, cách mã hóa ổn, đường cong ổn, mọi kiểm tra cấu trúc đều đạt. Cách duy nhất để phát hiện là thử.

Vì sao "không thể khoanh vùng"?

Thông thường khi khóa CA bị xâm phạm, nghĩa là ai đó đã đánh cắp nó. Có thủ phạm, có thời điểm, và ít nhất bạn có thể suy luận về việc ai đang nắm giữ khóa đó.

Ở đây, không ai phải đánh cắp gì cả. Khóa thực chất đã công khai ngay từ ngày chứng chỉ tồn tại. Bất kỳ ai nhìn vào một trong những chứng chỉ này, tại bất kỳ thời điểm nào từ tháng 4/2025, đều có thể khôi phục khóa trong vài mili giây trên phần cứng phổ thông. Đó là khoảng thời gian 17 tháng, và không có cách nào biết liệu đã có người làm vậy chưa.

Chrome lập luận rằng vì Chrome bắt buộc Certificate Transparency (CT), và không có chứng chỉ TLS nào nối tới các CA này xuất hiện trong CT, nên không chứng chỉ giả nào có thể được tin tưởng mặc định trên Chrome. Điều đó đúng và đáng yên tâm với trình duyệt — nhưng CT chỉ phát hiện việc cấp phát sai, không ngăn chặn, và rất nhiều phần mềm không kiểm tra CT chút nào.

Ai đang bị ảnh hưởng?

Trình duyệt phổ thông đã cập nhật thì gần như an toàn. Chrome và Firefox chặn trực tiếp các chứng chỉ trung gian và đều yêu cầu CT, Safari cũng vậy.

Nhưng mọi thứ khác lại là câu chuyện khác. Phần lớn các máy khách TLS không phải trình duyệt — curl, Python, Node, Go, Java, git, các trình quản lý gói và mọi script, daemon trên máy bạn — có ba đặc điểm:

• Chúng tin tưởng vào một gói CA trên đĩa
• Chúng không kiểm tra thu hồi theo mặc định
• Chúng không kiểm tra CT

Vì vậy việc eMudhra và Sectigo đã thu hồi các chứng chỉ trung gian này không giúp ích gì cho chúng. Các nhóm cần cập nhật ngay:

• Trình cài đặt và tự cập nhật dạng curl | sh: rustup, nvm, trình cài Homebrew, vô số trang "install.sh", bộ cập nhật firmware IoT. Một chứng chỉ giả ở đây đồng nghĩa với việc chạy mã của kẻ tấn công, thường với quyền root.
• Đường ống CI/CD: GitHub/GitLab runner, Jenkins và container build tải phụ thuộc và đẩy artifact, trong khi nắm giữ khóa cloud, token registry và khóa ký.
• Gọi API giữa các máy chủ: nhà cung cấp thanh toán, webhook, trao đổi token OAuth và SDK cloud (AWS CLI dùng bundle certifi riêng; Terraform và kubectl dùng Go).
• Thiết bị IoT, nhúng và OT: camera, router, ô tô, thiết bị y tế, thiết bị gia dụng thông minh, máy thanh toán và bộ điều khiển công nghiệp. Gói CA của chúng bị đóng băng đến năm 2039 — đây chính là điểm "không thể khoanh vùng" thành hiện thực.
• Ký mã trên Windows: Windows tin tưởng trực tiếp root CS của eMudhra. Phần mềm độc hại được ký bằng EM OV CS CA - G3B/G3C trông giống như phần mềm đã ký từ một nhà phát hành thật.

Nhà nghiên cứu đã tự kiểm chứng bằng một máy chủ cục bộ với chứng chỉ cho api.stripe.com. Với cấu hình mặc định, curl báo "SSL certificate verify ok", Python hoàn tất bắt tay, và Node trả về "authorized: true" trên mọi máy Linux và macOS được thử.

Bạn nên làm gì ngay bây giờ?

Lời khuyên suy cho cùng vẫn là "hãy cập nhật" — nhưng vấn đề nằm ở những thiết bị bạn không thể cập nhật hoặc cập nhật khó khăn.

• Cập nhật mọi thứ đi kèm gói CA: gói ca-certificates của hệ điều hành, certifi, Node, Homebrew, và build lại các container image sau khi base image nhận thay đổi.
• Thiết bị không thể cập nhật là phần khó nhất. Router, máy in, TV, thiết bị gia dụng có firmware đóng băng sẽ tin tưởng những chứng chỉ này cho đến khi hết hạn vào tháng 7/2039.

Tám bit. Trong suốt 17 tháng, đó là tất cả những gì đứng giữa một lượng lớn phần mềm không phải trình duyệt và một chứng chỉ giả cho bất kỳ trang web nào, đủ để phá vỡ bảo mật toàn bộ lưu lượng mã hóa của bạn.

Góc nhìn cho người dùng và doanh nghiệp Việt Nam

Sự cố này là lời nhắc nhở rõ ràng cho các đội DevOps và bảo mật tại Việt Nam, đặc biệt những đơn vị vận hành hệ thống IoT, thiết bị thanh toán hoặc hạ tầng CI/CD dựa nhiều trên container.

• Rà soát lại toàn bộ gói CA trong các image Docker và máy chủ, đặc biệt các hệ thống chạy curl, Python hay Go để gọi API thanh toán.
• Không phụ thuộc vào thu hồi chứng chỉ như biện pháp bảo vệ duy nhất — nhiều công cụ mặc định bỏ qua bước này.
• Kiểm tra các thiết bị đầu cuối cố định như máy POS, camera IP, router biên — nhóm thường bị bỏ quên và có vòng đời firmware rất dài.

Câu chuyện của eMudhra cũng cho thấy một lỗi nhỏ trong quy trình vận hành — theo eMudhra, một lỗi trong script dùng trong nghi thức đã tạo ra cặp khóa yếu thứ hai trên HSM, và do tên gần giống nhau, sai sót của con người dẫn đến việc dùng nhầm khóa — có thể gây hậu quả trên toàn hệ sinh thái Internet. Kiểm tra tự động sau nghi thức tạo khóa không còn là tùy chọn, mà là yêu cầu bắt buộc.