Khóa CA của eMudhra bị xâm phạm do quy trình tạo khóa riêng tư cực kỳ yếu

Vào ngày 17 tháng 10 năm 2026, một nhà nghiên cứu bảo mật đã báo cáo cho các công ty công nghệ lớn rằng các khóa riêng tư (private keys) của tám chứng chỉ trung gian eMudhra đã bị xâm phạm. Lỗ hổng này bắt nguồn từ sự yếu kém cực độ trong quá trình tạo khóa, nơi các khóa riêng tư thực chất chỉ là các số nguyên một byte. Đến ngày 20 tháng 10, Mozilla và Google đã công bố việc thu hồi các chứng chỉ này và loại bỏ niềm tin đối với các cơ quan cấp chứng chỉ gốc liên quan.

Chuyện gì đã xảy ra

Sự cố liên quan đến tám chứng chỉ trung gian do eMudhra phát hành, được tạo vào tháng 4 năm 2025. Bao gồm sáu chứng chỉ cấp TLS cho xác minh tên miền (Domain Validation), xác minh tổ chức (Organization Validation) và xác minh mở rộng (Extended Validation), cùng với hai chứng chỉ ký mã (code-signing). Tất cả tám chứng chỉ trung gian này cũng đã được ký chéo bởi gốc AAA Certificate Services của Sectigo vào tháng 5 năm 2025. Ngay khi nhận được báo cáo, Chrome đã triển khai bản cập nhật CRLSet để chặn các chứng chỉ trung gian trong cùng ngày, trong khi Mozilla chặn chúng trên Firefox thông qua OneCRL ngay sau đó.

Đến thứ Ba, ngày 20 tháng 10, Mozilla đã công bố thông báo chính thức và tung ra bản cập nhật NSS loại bỏ hoàn toàn gốc eMudhra. Google xác nhận rằng gốc eMudhra sẽ bị loại bỏ khỏi Chrome Root Store trong phiên bản 43. Vấn đề cốt lõi không phải là trộm cắp khóa theo nghĩa truyền thống, mà là lỗi trong quy trình tạo khiến các khóa riêng tư trở nên dễ dàng suy ra từ các chứng chỉ công khai.

Các khóa riêng tư của những chứng chỉ này được phát hiện là những con số cực nhỏ, chẳng hạn như 4, 56 và 115. Trong mật mã đường cong elip (elliptic-curve cryptography), cụ thể là trên đường cong P-384 được sử dụng ở đây, khóa riêng tư phải là một số ngẫu nhiên lớn. Bảo mật của hệ thống phụ thuộc vào việc số này đủ lớn để làm cho việc tấn công vét cạn (brute-forcing) là bất khả thi. Tuy nhiên, các khóa của eMudhra bao gồm chủ yếu là các số 0 theo sau bởi một byte khác không duy nhất. Điều này giảm không gian tìm kiếm xuống chỉ còn 256 khả năng, cho phép bất kỳ ai có quyền truy cập vào chứng chỉ công khai đều có thể khôi phục khóa riêng tư trong vài mili giây trên phần cứng tiêu chuẩn.

Chi tiết chính

• Tám chứng chỉ trung gian đã bị xâm phạm, bao gồm sáu chứng chỉ TLS và hai chứng chỉ ký mã.
• Các khóa riêng tư là các giá trị một byte, chẳng hạn như 4, 56 và 115, thay vì các số ngẫu nhiên 384-bit theo yêu cầu.
• Việc khôi phục các khóa riêng tư từ chứng chỉ công khai mất chưa đầy một giây trên phần cứng thương mại phổ biến.
• Các chứng chỉ bị ảnh hưởng được tạo vào tháng 4 năm 2025 và được ký chéo bởi Sectigo vào tháng 5 năm 2025.
• Các trình duyệt lớn như Chrome và Firefox đã thu hồi niềm tin, nhưng nhiều máy khách không phải trình duyệt vẫn dễ bị tổn thương.
• Khoảng thời gian phơi nhiễm kéo dài từ tháng 4 năm 2025 cho đến khi thu hồi vào tháng 10 năm 2026, và không có cách nào để xác định xem các khóa đã bị khai thác hay chưa.

Bối cảnh

Để hiểu mức độ nghiêm trọng, cần biết cách hoạt động của mật mã đường cong elip. Khóa riêng tư là một số bí mật, thường được ký hiệu là d. Khóa công khai, được chia sẻ công khai trong các chứng chỉ, được suy ra bằng cách nhân số bí mật này với một điểm cố định trên đường cong. Mặc dù việc tính toán khóa công khai từ khóa riêng tư là dễ dàng, nhưng việc đảo ngược quá trình để tìm khóa riêng tư từ khóa công khai là bất khả thi về mặt tính toán nếu khóa riêng tư lớn và ngẫu nhiên.

Đối với các đường cong P-384, khóa riêng tư phải là một số 384-bit, cung cấp khoảng 10¹¹⁵ tổ hợp có thể. Không gian tìm kiếm khổng lồ này đảm bảo an ninh. Tuy nhiên, nếu khóa riêng tư nhỏ, chẳng hạn như một byte, thì chỉ có 256 giá trị có thể. Kẻ tấn công chỉ cần thử từng giá trị cho đến khi tìm thấy giá trị khớp với khóa công khai. Đây chính xác là điều đã xảy ra với các khóa của eMudhra, làm cho lớp bảo vệ mật mã trở nên vô dụng.

Tại sao điều này quan trọng

Trong khi các trình duyệt hiện đại như Chrome, Firefox và Safari được bảo vệ vì chúng thực thi Transparency Chứng chỉ (Certificate Transparency) và nhanh chóng cập nhật danh sách chặn, thì hệ sinh thái rộng lớn hơn đang gặp rủi ro. Nhiều ứng dụng không phải trình duyệt, bao gồm các công cụ dòng lệnh như curl, môi trường chạy ngôn ngữ lập trình như Python và Node.js, và các trình quản lý gói, không kiểm tra nhật ký Transparency Chứng chỉ hoặc danh sách thu hồi theo mặc định. Chúng dựa vào các kho lưu trữ tin cậy cục bộ có thể không được cập nhật ngay lập tức.

Điều này tạo ra rủi ro đáng kể cho giao tiếp giữa máy chủ với máy chủ, các pipeline CI/CD và thiết bị IoT. Ví dụ, một tập lệnh tải xuống các bản cập nhật qua HTTPS bằng một bó chứng chỉ cũ có thể chấp nhận một chứng chỉ giả mạo được ký bởi các khóa eMudhra bị xâm phạm. Điều này sẽ cho phép kẻ tấn công chặn lưu lượng truy cập, chèn mã độc hoặc đánh cắp dữ liệu nhạy cảm. Các thiết bị có firmware đóng băng, chẳng hạn như router và thiết bị gia dụng thông minh, có thể tiếp tục tin tưởng vào các chứng chỉ không hợp lệ này cho đến khi phần cứng của chúng được thay thế hoặc cập nhật thủ công, có thể là nhiều năm sau.

Bạn có thể làm gì

• Cập nhật ngay lập tức các bó chứng chỉ CA trên tất cả máy chủ, máy trạm và hình ảnh container.
• Kiểm tra các bản cập nhật cho các môi trường chạy ngôn ngữ như Python, Node.js và Go, vì chúng thường đi kèm với các kho lưu trữ chứng chỉ riêng.
• Xem xét các pipeline CI/CD để đảm bảo chúng sử dụng các hình ảnh cơ sở mới nhất và xác minh tính hợp lệ của chứng chỉ một cách nghiêm ngặt.
• Xác định các thiết bị IoT và nhúng không thể dễ dàng cập nhật và đánh giá rủi ro khi chúng tin tưởng vào các CA bị xâm phạm.
• Bật kiểm tra thu hồi chứng chỉ nghiêm ngặt khi có thể, mặc dù lưu ý rằng nhiều máy khách không hỗ trợ điều này theo mặc định.
• Giám sát mọi hoạt động bất thường trong các hệ thống phụ thuộc vào kết nối TLS với các dịch vụ bên ngoài.