Secure boot trên microcontroller không phải chuyện kiểm tra chữ ký cho có. Chỗ đáng quan tâm nằm ở lúc chip vừa thoát reset: thiết bị có thật sự chỉ chạy image hợp lệ, có chặn rollback, và có giữ recovery path khỏi thành cửa hậu hay không. Bài này đi thẳng vào các điểm đó.
Mục lục
Secure boot là policy, không chỉ là verify
Nói ngắn gọn, secure boot là chính sách cưỡng chế: thiết bị chỉ được phép chuyển quyền thực thi sang firmware hoặc boot stage kế tiếp khi đối tượng đó thỏa điều kiện tin cậy đã định trước.
Điều kiện này trên MCU thường gồm:
- chữ ký số hoặc hash phải hợp lệ
- image phải đúng format và đúng vùng nhớ dự kiến
- metadata liên quan tới version hoặc trạng thái phải hợp lệ
- trust decision không được dựa vào dữ liệu mutable một cách tùy tiện
Chỗ nhiều người hay nhầm là coi secure boot như một phép kiểm tra mật mã, trong khi phần mật mã chỉ là công cụ, bản chất của secure boot vẫn là quyết định “cho chạy hay không cho chạy”.
Một bootloader có verify chữ ký nhưng vẫn chạy tiếp khi verify fail, với lý do “để tiện debug”, thì nghe có vẻ thực dụng nhưng không còn là secure boot đúng nghĩa nữa. Policy đã thủng ngay tại chỗ đáng lẽ phải cứng nhất.
Verified boot là cơ chế kiểm tra
Verified boot hẹp hơn. Nó mô tả hành vi kỹ thuật: bootloader có verify image trước khi boot không, verify cái gì, verify bằng cách nào.
Trong khá nhiều hệ MCU, verified boot chính là cơ chế dùng để thực thi secure boot, nhưng hai khái niệm này không đồng nhất.
Verified boot thường chỉ trả lời các câu hỏi như:
- image có được kiểm tra trước khi chạy không
- phép kiểm tra dựa trên signature, hash hay cơ chế nào khác
- đối tượng được kiểm tra là payload thôi hay cả metadata quan trọng
Còn secure boot rộng hơn:
- image nào được phép chạy
- nếu verify fail thì thiết bị đi về đâu
- version cũ có bị chặn không
- recovery path có còn nằm trong trust model không
Nói gọn, verified boot là cơ chế. Secure boot là policy xây trên cơ chế đó.
Root of trust phải có hai nửa
Muốn có trust thật ở thời điểm boot, hệ thống phải có một điểm bắt đầu mà nó dám tin. Đó là root of trust.
Trên MCU, chỗ này hay bị nói quá gọn vì root of trust không chỉ là “một cái key”, nó thường gồm hai phần:
- đoạn code đầu tiên bất biến hoặc rất khó sửa
- trust anchor mà đoạn code đó dùng để verify stage kế tiếp
Phần thứ nhất thường là ROM code, mask ROM, hoặc first-stage bootloader đã được write-protect thật sự. Phần thứ hai có thể là public key gốc, hash của public key, certificate digest, hoặc dữ liệu nằm trong OTP, eFuse, secure storage.
Thiếu một trong hai là gãy.
Nếu immutable first code không đủ tin cậy, chain khởi động không có gốc. Nếu trust anchor lại nằm ở chỗ attacker có thể ghi đè, attacker đâu cần phá crypto. Họ chỉ cần thay cái gốc mà thiết bị đang tin.
Chain of trust là chuyện chuyển quyền thực thi
Chain of trust nghe có vẻ to tát, nhưng bản chất rất đời thường: mỗi lần chuyển quyền thực thi đều phải có căn cứ tin cậy rõ ràng.
Một flow quen thuộc trên MCU thường là:
- ROM code chạy đầu tiên.
- ROM code verify bootloader kế tiếp.
- Bootloader đã được verify tiếp tục verify application image.
- Chỉ image hợp lệ mới được chạy.
Nếu hệ có thêm secure world, non-secure world hoặc loader trung gian, mỗi stage lại phải làm việc tương tự với stage tiếp theo.
Điều thú vị là chain of trust không chỉ nằm ở file firmware chính. Nó còn chạm vào:
- image header
- version hoặc security counter
- key selector
- boot state như pending hoặc confirmed
- nơi chứa trust anchor
Ký payload rất đẹp mà metadata quyết định hành vi boot lại nằm ngoài phạm vi bảo vệ thì vẫn có thể hở như thường.
Trusted boot nhấn vào trust lineage
Trusted boot thường bị dùng lẫn với secure boot, tôi không thích cách dùng đó.
Nếu secure boot nhấn vào cưỡng chế “image sai thì không được chạy”, thì trusted boot nhấn vào chuyện trust được truyền qua từng stage như thế nào. Tùy tài liệu và vendor, nó còn có thể bao gồm measurement, provenance, thậm chí attestation.
Vì vậy, có thể hiểu ngắn như sau:
verified boot: verify image trước bootsecure boot: chỉ cho chạy image hợp lệtrusted boot: trust được truyền, đo đạc hoặc thể hiện xuyên suốt qua boot chain
Nghe có vẻ gần nhau, nhưng gộp cả ba thành một sẽ làm tài liệu kỹ thuật mờ đi rất nhanh.
Một hệ có secure boot cơ bản chưa chắc đã có trusted boot theo nghĩa measurement hoặc attestation. Ngược lại, có measurement nhưng không chặn image không hợp lệ thì cũng chưa nên kết luận là secure.
Boot state và signed metadata không phải một
Đây là chỗ nhiều người đánh giá thấp, vì quyết định boot hiếm khi chỉ dựa vào chữ ký hợp lệ, hệ thống còn cần boot state: image nào đang pending, image nào đã confirmed, lần boot trước có fail không, thiết bị đang ở production mode hay recovery mode.
Boot state là trạng thái vận hành, có thể thay đổi theo vòng đời thiết bị. Nó không đồng nghĩa với metadata đã được ký sẵn trong image.
Ví dụ:
- version nằm trong manifest là signed metadata
- việc image đã qua self-test chưa lại là boot state
Hai thứ này liên quan với nhau, nhưng không thay nhau được. Nếu đánh đồng mutable boot state với signed image metadata, thiết kế rất dễ gãy ở rollback, revert hoặc xác nhận image quá sớm.
Anti-rollback gần như bắt buộc
Một image cũ vẫn có thể có chữ ký hợp lệ. Đó là lý do anti-rollback không nên bị đẩy xuống chân trang như một ghi chú phụ.
Nếu không chặn rollback, attacker chỉ cần ép thiết bị quay về firmware cũ đã biết lỗ hổng. Khi đó verify vẫn pass, còn security posture thì tụt lùi một nhịp dài.
Trên MCU, anti-rollback thường cần cả hai vế:
- image mang version hoặc security counter đã được bảo vệ
- thiết bị giữ một mốc version tối thiểu ở nơi không thể kéo lùi tùy tiện
Mốc đó thường nằm ở OTP, monotonic counter phần cứng hoặc secure storage đủ tin cậy. Chỉ nhét version vào metadata rồi ký lại là chưa đủ. Thiết bị phải có cách nhớ rằng nó đã đi tới đâu, và không chấp nhận bị kéo về sau.
Đổi lại, anti-rollback làm recovery khó hơn. Đây là cái giá thật, không phải chi tiết phụ.
Recovery path phải nằm trong trust model
Verify fail thì không boot mới chỉ là nửa đầu của câu chuyện. Nửa sau mới đáng sợ hơn: không boot rồi làm gì.
Recovery path nếu thiết kế hời hợt sẽ biến thành cửa hậu cho chính hệ secure boot.
Một recovery path tử tế phải trả lời rõ:
- đứng lại ở ROM, bootloader hay recovery image riêng
- image recovery có phải verify theo cùng trust anchor không
- cổng nhận firmware mới có yêu cầu xác thực không
- có cho boot image tạm không, nếu có thì điều kiện là gì
- boot state và version state được cập nhật ra sao sau recovery
Nghe có vẻ hợp lý, nhưng rất nhiều hệ lại làm theo kiểu “cứ cứu máy trước đã”, cách đó tiện ở lab, nhưng lên production thì thường là mở sẵn một bypass mà không tự nhận ra.
Nếu cần nối sang phần update flow, bài firmware update là mảnh trước của câu chuyện. Còn góc tấn công ở quá trình nạp image thì nằm ở bài bảo mật update.
Secure boot luôn có giá của nó
Secure boot không miễn phí. Trên MCU, cái giá này khá cụ thể:
- boot time tăng vì phải verify
- tốn thêm ROM hoặc flash cho code xác minh và metadata handling
- tốn RAM tạm cho crypto context hoặc buffer
- làm provisioning, debug và field recovery phức tạp hơn
Nhìn lại thì đây cũng là lý do nhiều đội nói “có secure boot” rất sớm, nhưng khi soi kỹ thì policy vẫn mềm ở debug mode, recovery mode hoặc factory flow, họ không hẳn sai về mặt ý tưởng, chỉ là chưa trả hết giá để policy đó đứng vững.
Cách dùng thuật ngữ cho đỡ loạn
Nếu phải viết tài liệu hoặc review thiết kế, tôi thấy cách dùng an toàn nhất là:
- dùng
verified bootkhi nói về hành vi verify image trước boot - dùng
secure bootkhi nói về policy cưỡng chế chỉ chạy image hợp lệ - dùng
trusted bootkhi nói về trust propagation, measurement, provenance hoặc attestation qua các stage
Giữ ranh giới đó, bài viết sẽ ít mơ hồ hơn nhiều, và quan trọng hơn, thiết kế cũng ít tự lừa mình hơn.
Nói cho cùng, secure boot trên microcontroller không phải chuyện “có check chữ ký là xong”. Nó là bài toán dựng một gốc tin cậy đủ cứng, truyền trust qua từng lần chuyển quyền thực thi, giữ boot state cho đúng, chặn rollback cho chặt, và không biến recovery thành đường đi vòng. Làm được hết chỗ đó thì mới đáng gọi là một boot chain có kỷ luật.