Update firmware mà không có bảo mật đúng nghĩa là chừa sẵn một cánh cửa rất rộng cho thiết bị. Cánh cửa đó không chỉ cho phép nạp bản firmware mới.
Nó còn có thể cho phép nạp firmware giả, kéo máy về bản cũ có lỗ hổng hoặc sửa trạng thái boot theo cách làm hỏng cả chuỗi tin cậy phía sau.
Với MCU, secure update không phải chuyện thêm CRC cho đủ checklist. Nó là bài toán quyết định thiết bị nên tin cái gì, tin ở đâu và tin vào thời điểm nào.
Bài này nhìn update flow dưới góc threat model, trust anchor, anti-rollback và mức bảo vệ tối thiểu đủ thực dụng cho một sản phẩm thật.
Fail-safe giúp thiết bị sống sót khi update lỗi. Secure update giúp nó không bị update bởi thứ không nên được tin.
Mục lục
Thiết bị đang sợ gì?
Nếu không có threat model, bài toán bảo mật rất dễ biến thành danh sách tính năng rời rạc. Với firmware update trên MCU, vài rủi ro thường gặp xuất hiện lặp đi lặp lại ở rất nhiều sản phẩm.
- firmware giả đi vào qua đúng kênh update hợp lệ
- firmware cũ có lỗ hổng bị cố tình đẩy lại
- metadata hoặc boot state bị sửa để bootloader tin nhầm image
- tool update giả mạo mở được phiên cập nhật
- trust anchor nằm ở vùng dễ ghi đè
Chỉ cần một cửa như vậy mở ra, update flow vẫn có thể chạy đúng chức năng nhưng không còn đáng tin về mặt security.
Đừng nhầm fail-safe
Một hệ thống có thể rollback rất đẹp khi update lỗi nhưng vẫn hoàn toàn không an toàn. Nếu bootloader chấp nhận bất kỳ image nào miễn là CRC đúng, attacker vẫn có thể nạp một firmware độc hại nhưng hoàn chỉnh.
Fail-safe giải bài toán availability. Secure update giải bài toán trust. Hai phần này liên quan chặt, nhưng không thể thay cho nhau.
Rollback tốt mà vẫn nhận firmware giả thì đó chỉ là một hệ dễ hồi phục, chưa phải một hệ an toàn.
Ba lớp cần tách
Integrity, authenticity và authorization thường bị trộn vào nhau, trong khi mỗi lớp lại khóa một kiểu rủi ro khác nhau.
- integrity hỏi dữ liệu có còn nguyên vẹn không
- authenticity hỏi dữ liệu có đúng từ nguồn được tin không
- authorization hỏi ai được phép bắt đầu và thực hiện update
CRC làm khá tốt phần integrity cho lỗi ngẫu nhiên. Nhưng CRC không chứng minh được ai tạo ra dữ liệu đó. Nếu dừng ở đây, cánh cửa cho firmware giả vẫn còn mở.
CRC, hash, chữ ký
CRC hoặc checksum hợp cho bắt lỗi truyền nhận và kiểm tra sơ bộ sau khi ghi. Hash cho biết nội dung có thay đổi hay không. Nhưng cả hai vẫn chưa trả lời được câu hỏi về nguồn gốc.
Chữ ký số mới là thứ cho phép bootloader xác thực image dựa trên một điểm tin cậy đã được ghim sẵn. Đây là ranh giới thật giữa kiểm tra dữ liệu và xác thực firmware.
Nếu cần nói ngắn: CRC bắt lỗi, hash phát hiện thay đổi, chữ ký số xác thực nguồn phát hành.
Trust anchor ở đâu?
Bootloader chỉ verify được image nếu nó có một điểm tin cậy không phụ thuộc vào image mới vừa nhận. Điểm đó thường là public key, key hash hoặc trust anchor tương đương.
Nếu trust anchor nằm ở vùng dễ bị update như metadata hay application thông thường, attacker không cần bẻ chữ ký. Họ chỉ cần thay luôn thứ được dùng để verify chữ ký.
- hardcode public key: đơn giản, nhỏ gọn
- key hash: linh hoạt hơn một chút
- OTP, eFuse, secure storage: chắc hơn nhưng phụ thuộc phần cứng
- secure element: mạnh hơn nhưng tăng cost và công tích hợp
Ai được update?
Nhiều thiết kế chỉ kiểm tra firmware ở cuối flow mà quên cánh cửa đầu vào. Nếu bất kỳ ai cũng có thể đưa thiết bị vào update mode, bề mặt tấn công vẫn rất rộng.
Secure update thường cần ít nhất hai lớp: quyền mở phiên update và quyền cài image đó vào hệ thống. Mức kiểm soát cụ thể nên đi theo risk profile của sản phẩm, không nên nặng hơn nhu cầu thật.
Image được ký đúng chưa đủ nếu cánh cửa đưa thiết bị vào chế độ update vẫn mở quá rộng.
Anti-rollback để làm gì?
Rollback trong fail-safe update là quay về image cũ còn dùng được khi image mới boot fail. Anti-rollback trong security lại là chuyện khác: không cho quay về một version cũ hơn mức an toàn đã định.
Nếu một bản firmware cũ có lỗ hổng đã biết, cho phép hạ version vô điều kiện chính là để lộ một cửa tấn công cố định. Vì vậy nhiều hệ dùng security counter hoặc monotonic counter để chặn downgrade.
Trade-off nằm ở chỗ rollback quá rộng thì kém an toàn, nhưng anti-rollback quá cứng cũng có thể làm recovery khó hơn. Cách cân bằng thường là chỉ cho rollback trong một tập version hoặc slot đã được thiết kế sẵn.
Có cần certificate chain?
Certificate chain cho phép phân tầng niềm tin và linh hoạt hơn khi thay key. Nhưng với MCU nhỏ, cái giá không hề nhẹ: thêm parsing, thêm verify logic, thêm RAM và thêm việc vận hành vòng đời certificate.
Phần lớn sản phẩm MCU không cần kéo cả certificate chain vào bootloader. Một public key hoặc key hash được ghim chắc, cộng với quy trình phát hành tốt, thường là mức cân bằng hợp lý hơn.
trust anchor -> verify signature -> check version policy -> decide boot / reject
Baseline nên có
Nếu phải chốt một mức tối thiểu thực dụng cho đa số MCU nhỏ, em sẽ chọn một bộ nhỏ nhưng đủ chặt để không tự lừa mình rằng hệ đã an toàn.
- firmware được ký số, không chỉ có CRC
- public key hoặc key hash ở vị trí khó bị sửa
- metadata không được tin trước khi verify xong
- version policy hoặc counter để chặn downgrade vô tội vạ
- ít nhất một recovery path đã được kiểm chứng
Mức này chưa phải enterprise security, nhưng đã vượt rất xa kiểu có CRC là đủ. Quan trọng hơn, nó vẫn nằm trong khả năng triển khai của nhiều đội embedded nhỏ.
Kết luận
Secure update trên MCU là bài toán của niềm tin được đóng vào kiến trúc: trust anchor đặt ở đâu, image được verify lúc nào, downgrade bị chặn ra sao và recovery path có còn giữ được policy an toàn không.
Với đa số sản phẩm, hướng tối ưu vẫn là trust anchor đơn giản nhưng khó bị sửa, firmware được ký số và anti-rollback đủ dùng. Làm đúng ba phần đó, hệ đã đi rất xa so với phần lớn những thiết kế chỉ có update nhưng chưa thật sự có secure update.