Sự cố chứng chỉ eMudhra: Vì sao vi điều khiển (MCU) của bạn nhiều khả năng vẫn an toàn

Sự cố lộ khóa riêng tư của tám chứng chỉ CA trung gian thuộc eMudhra được công bố ngày 20/10/2026 đã khiến giới kỹ thuật phần mềm chao đảo. Ngay sau đó, hàng loạt sản phẩm từ trình duyệt, môi trường phát triển cho tới các gói hệ điều hành đồng loạt phát hành bản cập nhật để loại bỏ các chứng chỉ bị ảnh hưởng.

Trong bối cảnh đó, một số ý kiến lo ngại rằng các thiết bị IoT, đặc biệt là thiết bị vi điều khiển (MCU), sẽ vĩnh viễn rơi vào tầm ngắm của tấn công xen giữa (MITM) vì không thể cập nhật firmware. Tuy nhiên, trên thực tế, phần lớn MCU nhiều khả năng vẫn an toàn trong sự cố cụ thể này.

Chuyện gì đã xảy ra với eMudhra?

Tám chứng chỉ CA trung gian của eMudhra bị phát hiện có khóa riêng tư nằm công khai trên internet. Đáng chú ý hơn, các khóa này được sinh ra một cách cực kỳ yếu kém: 376 bit đầu của khóa P-384 đều bằng 0, thậm chí có khóa chỉ đơn giản là số 4.

Điều này có nghĩa là bất kỳ ai có hiểu biết kỹ thuật ở mức trung bình cũng có thể tự phát hành một chứng chỉ lá (ví dụ cho một tên miền bất kỳ), rồi gửi kèm chứng chỉ trung gian để nó được tin cậy bởi mọi kho chứng chỉ có chứa chứng chỉ gốc của eMudhra.

Tuy nhiên, có một điểm mấu chốt: các trình duyệt lớn như Firefox, Chrome, Edge và Safari còn yêu cầu chứng chỉ lá phải xuất hiện trong nhật ký Certificate Transparency (CT) thì mới được tin cậy. Do không có bản ghi CT nào cho các chứng chỉ trung gian này trong khoảng thời gian bị lỗi, có thể khẳng định người dùng trình duyệt không bị tấn công.

Vấn đề nằm ở chỗ nhiều ứng dụng ngoài hệ sinh thái trình duyệt không bắt buộc Certificate Transparency. Đây chính là nhóm khách hàng tiềm năng bị ảnh hưởng, và là lý do các nhà phát triển trên khắp thế giới phải khẩn trương vá lỗi.

Vì sao MCU thoát khỏi vòng nguy hiểm?

Câu trả lời nằm ở giới hạn tài nguyên. Trên máy chủ, máy tính để bàn hay thậm chí một chiếc Raspberry Pi, việc cài sẵn một hoặc nhiều bộ chứng chỉ gốc chỉ tốn vài kilobyte, không đáng kể.

Nhưng với thiết bị thường có dung lượng lưu trữ không bay hơi dưới 1 MB, thậm chí thấp hơn nhiều, mọi kilobyte đều quý. Các nhà phát triển MCU không thể dựa vào nhà cung cấp hệ điều hành hay trình duyệt để đánh giá và giám sát các chứng chỉ gốc ứng viên. Họ thường phải tự chịu trách nhiệm cho toàn bộ hệ thống, từ ứng dụng chạy trực tiếp trên phần cứng (bare metal) đến các hệ điều hành thời gian thực (RTOS) nhẹ.

Ví dụ, mẫu HTTP GET trong Zephyr RTOS khi kết nối tới google.com chỉ cần duy nhất một chứng chỉ gốc là GlobalSign R1 để xác minh. Chứng chỉ này nặng gần 1 KB khi mã hóa DER, và bản thân kích thước không phải là yếu tố duy nhất cần cân nhắc.

Bật tất cả thuật toán ký, đường cong và thuật toán băm có trong chuỗi chứng chỉ sẽ làm tăng đáng kể kích thước mã. Bên cạnh đó, vùng đệm cũng phải được cấu hình đủ lớn cho toàn bộ chuỗi — chuỗi càng dài thì càng tốn bộ nhớ.

Bài học từ sự cố

Theo tác giả Daniel Mangum, những hạn chế tưởng như gây khó chịu này lại là điểm mạnh theo một cách nào đó.

Một hệ thống chỉ tập trung hoàn thành một tập nhiệm vụ cố định, được định nghĩa rõ ràng, lại có giá trị riêng của nó.

Điều này được thể hiện rõ qua một câu hỏi đơn giản: MCU của bạn có thực sự cần kết nối tới máy chủ sử dụng chuỗi tin cậy bắt nguồn từ chứng chỉ gốc eMudhra hay không? Nếu câu trả lời là không — và với phần lớn thiết bị nhúng thì đúng là như vậy — thì firmware của bạn gần như chắc chắn không chứa chứng chỉ liên quan, và do đó không bị ảnh hưởng bởi lỗ hổng cụ thể này.

Còn lại là công việc vá lỗi

Trong khi firmware nhúng có thể yên tâm, các kỹ sư phần mềm vẫn còn một khối lượng công việc không nhỏ phía trước. Các môi trường CI/CD, công cụ phát triển, dịch vụ đám mây và phần mềm văn phòng hằng ngày đều cần được vá và xác minh lại cấu hình tin cậy chứng chỉ.

Với các thiết bị chạy Linux như Raspberry Pi — nếu xét chúng là thiết bị IoT — người vận hành nên áp dụng cập nhật OTA ngay khi có bản vá từ nhà cung cấp. Sự cố này là lời nhắc nhở rằng một chiến lược cập nhật bảo mật chủ động cho thiết bị ngoại vi vẫn luôn cần thiết, ngay cả khi lần này các thiết bị nhúng nhỏ nhất lại là nhóm may mắn nhất.