Khởi động an toàn (Secure Boot) và Chuỗi tin cậy (Chain of Trust)
1. Tổng quan
A. Định nghĩa
Khởi động an toàn (Secure Boot) là một thể chế bảo mật khởi động trong đó, xuất phát từ Gốc tin cậy (Root of Trust, RoT) được cố định trong phần cứng, mỗi giai đoạn từ firmware → bộ nạp khởi động (bootloader) → nhân hệ điều hành → ứng dụng sẽ kiểm chứng (hoặc đo lường) tính toàn vẹn của giai đoạn kế tiếp bằng mật mã trước khi thực thi nó rồi mới chuyển giao tin cậy, bắt đầu ngay từ thời điểm cấp nguồn. Cấu trúc mà tin cậy được kế thừa từng bước không gián đoạn như vậy được gọi là Chuỗi tin cậy (Chain of Trust), và UEFI Secure Boot, Measured Boot, chứng thực từ xa (Attestation) là các công nghệ tiêu biểu hiện thực hóa nó.
Ý tưởng cốt lõi của khởi động an toàn nằm ở việc phá vỡ bài toán vòng lặp "cái gì bảo chứng cho tính toàn vẹn của chính phần mềm bảo mật?". Các giải pháp bảo mật như diệt virus, EDR, tường lửa rốt cuộc đều là mã chạy trên hệ điều hành, nên nếu nhân, hay bootloader và firmware khởi động sớm hơn cả nhân, bị giả mạo thì hệ thống đã bị chiếm giữ trước cả khi phần mềm bảo mật được nạp. Nói cách khác, nếu "mã chạy đầu tiên" không được tin cậy thì mọi bảo mật xây dựng bên trên nó đều là lâu đài trên cát. Khởi động an toàn đóng điểm xuất phát của tin cậy vào phần cứng khó giả mạo và chuyển giao tin cậy lên các tầng trên từng bước một, "chứng minh" từng bước khi đi, qua đó lấp đầy khoảng trống này.
Điểm cốt yếu ở đây là tin cậy được kế thừa có tính bắc cầu (transitive). Bản thân RoT không được bên ngoài kiểm chứng mà là một tiên đề (axiom) được giả định là đáng tin nhờ phần cứng, và mọi giai đoạn sau đó được tin cậy vì giai đoạn ngay trước đó kiểm chứng cho nó. Do đó, nếu bất kỳ mắt xích nào trong chuỗi bị bỏ qua không kiểm chứng, hoặc gốc bị tổn hại, thì tin cậy của toàn bộ phần bên dưới nó sẽ sụp đổ. Đây là lý do thiết kế khởi động an toàn rốt cuộc quy về bài toán "mắt xích yếu nhất".
B. Bối cảnh ra đời và sự cần thiết
Bảo mật truyền thống tập trung bảo vệ giai đoạn "sau" khi hệ điều hành đã khởi động. Tuy nhiên, khi các bootkit, rootkit và cấy ghép firmware (firmware implant) chiếm chỗ trước cả hệ điều hành xuất hiện, các mối đe dọa mà bảo mật ở mức hệ điều hành thực chất không thể phát hiện lẫn loại bỏ đã trở thành hiện thực. Mã độc chiếm giữ các giai đoạn khởi động sớm sẽ né tránh việc kiểm chứng chữ ký nhân, vô hiệu hóa trước các phòng vệ như BitLocker, HVCI, Defender ngay trong quá trình khởi động, và dù cài lại hệ điều hành vẫn tồn tại bên ngoài đĩa (trong firmware hoặc ESP) để gây tái nhiễm.
Mức độ nghiêm trọng của các mối đe dọa này đã bộc lộ qua một trường hợp thực tế. BlackLotus, được công bố năm 2023, là bootkit thương mại đầu tiên né tránh được UEFI Secure Boot ngay cả trên Windows 11 đã vá đầy đủ, lợi dụng CVE-2022-21894 (Baton Drop) vốn cấy lại một bootloader cũ dễ bị tấn công, cùng CVE-2023-24932 kế tiếp. Tác động lớn đến mức NSA của Hoa Kỳ phải phát hành hướng dẫn giảm thiểu riêng và Microsoft phải triển khai từng bước việc đăng ký các bootloader dễ bị tấn công vào danh sách thu hồi (dbx). Điều này cho thấy chỉ riêng việc "có khởi động an toàn" là chưa đủ; nó phải đi kèm với vận hành thu hồi (Revocation) các phần tử tin cậy đã trở nên dễ bị tấn công và giữ chúng luôn mới.
Khởi động an toàn cũng ngày càng cần thiết với tư cách là nền tảng cho tin cậy chuỗi cung ứng và tin cậy thiết bị. Để phán định "có nên tin thiết bị này không?" trong Zero Trust, phải có cơ sở phần cứng rằng thiết bị đó đã khởi động ở trạng thái chưa bị giả mạo. Khi các rủi ro chuỗi cung ứng gia tăng — giả mạo firmware máy chủ trung tâm dữ liệu, tráo đổi firmware trên thiết bị IoT/OT, cấy ghép trong thiết bị đã qua sử dụng hoặc mang vào — thì khởi động an toàn và chứng thực từ xa dựa trên các giá trị đo của nó đang trở thành yêu cầu nền tảng chứ không phải là lựa chọn.
2. Cấu trúc tổng thể của Chuỗi tin cậy và các khái niệm cốt lõi
Cần hiểu khởi động an toàn như một cấu trúc phân tầng trong đó tin cậy chảy một chiều từ "gốc phần cứng → các tầng trên". Sơ đồ cấu trúc tổng thể bên dưới thể hiện luồng trong đó, ngay sau khi cấp nguồn, tin cậy bắt đầu từ RoT bất biến, mỗi giai đoạn kiểm chứng (Verify) hoặc đo lường (Measure) giai đoạn kế tiếp trong khi chuyển giao điều khiển, và các giá trị đo được tích lũy vào TPM để cuối cùng được dùng cho chứng thực từ xa.
flowchart TD
RoT["Gốc tin cậy(RoT) - Boot ROM·cầu chì bất biến"]
FW["firmware nền tảng(UEFI/BIOS)"]
BL["bootloader(shim·GRUB v.v.)"]
OS["nhân·trình điều khiển OS"]
APP["ứng dụng·dịch vụ"]
TPM[("TPM - tích lũy PCR")]
VER["máy chủ kiểm chứng từ xa(Attestation)"]
RoT -->|"kiểm chứng rồi chuyển giao điều khiển"| FW
FW -->|"kiểm chứng rồi chuyển giao điều khiển"| BL
BL -->|"kiểm chứng rồi chuyển giao điều khiển"| OS
OS -->|"kiểm chứng rồi chuyển giao điều khiển"| APP
RoT -.->|"extend giá trị đo"| TPM
FW -.->|"extend giá trị đo"| TPM
BL -.->|"extend giá trị đo"| TPM
OS -.->|"extend giá trị đo"| TPM
TPM -->|"nộp PCR đã ký(Quote)"| VER
style RoT fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style TPM fill:#eafbea,stroke:#2f9e44,stroke-width:1px
style VER fill:#fef3e8,stroke:#ed8f2f,stroke-width:1px
A. Gốc tin cậy (Root of Trust)
Chuỗi tin cậy phải xuất phát từ "một cái gì đó không thay đổi". Điểm xuất phát này là RoT, thường được hiện thực bằng mã bất biến (immutable Boot ROM) được khắc vào ROM mặt nạ khi sản xuất chip, cùng với cầu chì lập trình một lần (OTP fuse) chứa băm của khóa công khai OEM và không thể ghi lại. Vì không thể bị phần mềm thay thế hay sửa đổi, đây là điểm khó cho kẻ tấn công chạm tới nhất, và chính tính chất này trao cho nó tư cách trở thành "tiên đề của tin cậy".
RoT được chia thành ba loại theo chức năng. Gốc đo lường (RTM, Root of Trust for Measurement) tính băm của một phần tử khởi động lần đầu tiên và khởi phát việc đo lường chuỗi tin cậy; Gốc lưu trữ (RTS) cất giữ an toàn các khóa và giá trị đo; còn Gốc báo cáo (RTR) chứng thực đáng tin kết quả đo ra bên ngoài. Vai trò được phân chia sao cho TPM đảm nhiệm RTS và RTR, còn mã đo lường sớm nhất bên trong CPU (CRTM) đảm nhiệm RTM. Chỉ khi định nghĩa các gốc rõ ràng theo chức năng thì "tin cái gì và chứng thực cái gì" mới trở nên rõ ràng.
Nguyên tắc thiết kế quan trọng là gốc phải nhỏ và đơn giản. Nếu mã RoT lớn và phức tạp, khiếm khuyết bên trong nó sẽ trực tiếp dẫn đến sự sụp đổ của toàn bộ tin cậy, nên chỉ đặt lượng mã tối thiểu có thể kiểm chứng (cỡ vài KB) ở đó và giao phần chức năng còn lại cho các tầng trên. Nguyên tắc "Nền tảng tin cậy tối thiểu (Minimal TCB)" này là bài học chung không chỉ cho khởi động an toàn mà cho mọi thiết kế điện toán tin cậy.
B. Nguyên lý kế thừa tin cậy (Chain of Trust)
Mỗi mắt xích của chuỗi tin cậy lặp lại cùng một khuôn mẫu. (1) Giai đoạn hiện tại nạp vào bộ nhớ đoạn mã sẽ chạy kế tiếp → (2) kiểm chứng (hoặc đo lường) chữ ký/băm của đoạn mã đó → (3) chỉ chuyển giao quyền điều khiển khi kiểm chứng đạt. Chỉ khi quy tắc "kiểm chứng rồi thực thi (verify-then-execute)" này đi tới gốc mà không gián đoạn thì bảo đảm "toàn bộ ngăn xếp phần mềm đã khởi động là đáng tin cậy" mới thành lập.
Điều quan trọng ở đây là tính bất đối xứng rằng tin cậy chỉ chảy xuống dưới. Tầng trên buộc phải tin tầng dưới, nhưng tầng dưới không tin tầng trên mà ngược lại kiểm chứng nó. Do đó, nếu một phần tử ở giữa chuỗi dễ bị tấn công thì mọi thứ bên dưới nó (các giai đoạn về sau) đều bị nhiễm, nhưng mọi thứ bên trên nó (các giai đoạn trước đó) không bị ảnh hưởng. Việc BlackLotus nhắm vào giai đoạn "bootloader" cũng chính vì nó có thể chiếm giữ toàn bộ nhân và hệ điều hành bên dưới cùng một lúc.
C. Khởi động kiểm chứng và khởi động đo lường
Khởi động an toàn có hai cách tiếp cận khác tính chất, và hệ thống thực tế dùng cả hai cùng nhau. Khởi động kiểm chứng (Verified/Secure Boot) là cách thức lấy "Phòng ngừa (Prevention)" làm trọng tâm, dừng khởi động nếu kiểm chứng chữ ký thất bại, trong khi khởi động đo lường (Measured Boot) là cách thức lấy "Phát hiện (Detection)" làm trọng tâm, chỉ ghi băm của mỗi giai đoạn vào TPM PCR rồi tiếp tục khởi động, sau đó cho phép "chứng thực" trạng thái bằng các giá trị đo đó. Cách đầu ngăn chặn chính việc thực thi mã bị giả mạo; cách sau để lại bằng chứng về "hệ thống đã khởi động vào trạng thái nào" sau sự việc.
| Phân loại | Khởi động kiểm chứng (Verified Boot) | Khởi động đo lường (Measured Boot) |
|---|---|---|
| Mục đích | Phòng ngừa (chặn thực thi mã trái phép) | Phát hiện (chứng thực trạng thái khởi động) |
| Hoạt động | Dừng khởi động khi kiểm chứng chữ ký thất bại | Tích lũy băm vào TPM PCR, tiếp tục khởi động |
| Căn cứ | Chữ ký khóa công khai·db/dbx | Giá trị PCR + chứng thực từ xa |
| Giới hạn | Mã được phép nhưng dễ bị tấn công vẫn lọt qua | Không thể chặn (việc phán định thuộc về bên kiểm chứng) |
| Tiêu biểu | UEFI Secure Boot | Measured Boot dựa trên TPM |
Hai cách thức bổ sung cho nhau. Chỉ dùng kiểu kiểm chứng thì không ngăn được bootloader "ký hợp lệ nhưng dễ bị tấn công" (ví dụ nhị phân Baton Drop cũ), còn chỉ dùng kiểu đo lường thì chỉ phát hiện mã bị giả mạo sau khi nó đã chạy. Vì vậy trong thực tế, kiểu kiểm chứng chặn tuyến đầu, còn kiểu đo lường cộng với chứng thực từ xa kiểm chứng cả "trong số những thứ được phép thì thực sự cái gì đã khởi động", tạo nên thế phòng thủ theo chiều sâu (Defense in Depth).
3. Cơ chế hoạt động — UEFI Secure Boot·đo lường TPM·chứng thực từ xa
Sơ đồ chi tiết bên dưới, dựa trên nền tảng x86, thể hiện cùng lúc luồng trong đó firmware UEFI kiểm chứng chữ ký bootloader bằng phân cấp khóa (PK·KEK·db·dbx) và đồng thời băm của mỗi giai đoạn được tích lũy vào TPM PCR rồi dẫn tới chứng thực từ xa. Điểm cốt yếu là kiểm chứng (đường liền) và đo lường (đường đứt) diễn ra song song trong cùng một quá trình khởi động.
sequenceDiagram
participant FW as firmware UEFI
participant KEYS as DB khóa(PK·KEK·db·dbx)
participant BL as bootloader
participant TPM as TPM(PCR)
participant SRV as máy chủ kiểm chứng
FW->>KEYS: tra cứu chữ ký bootloader
KEYS-->>FW: trả lời có trong db(cho phép)·dbx(thu hồi) hay không
alt chữ ký hợp lệ và không có trong dbx
FW->>TPM: extend băm bootloader(PCR)
FW->>BL: chuyển giao điều khiển(thực thi)
BL->>TPM: extend băm nhân·cấu hình(PCR)
else chữ ký không khớp hoặc nằm trong dbx
FW--xBL: dừng khởi động(chặn kiểu kiểm chứng)
end
BL->>SRV: khởi động hoàn tất, kích hoạt yêu cầu Quote
TPM-->>SRV: nộp chữ ký giá trị PCR(Quote)
Note over SRV: so sánh với giá trị chuẩn(golden) để phán định tin cậy
A. Phân cấp khóa của UEFI Secure Boot
UEFI Secure Boot quản lý tin cậy bằng bốn loại biến. PK (Platform Key) cấp cao nhất tượng trưng cho thẩm quyền của chủ sở hữu nền tảng (OEM) và quản lý KEK. KEK (Key Exchange Key) là khóa thẩm quyền có thể cập nhật db và dbx. db (Signature Database) là "danh sách cho phép" gồm các bên ký/băm được phép khởi động, còn dbx (Forbidden Signature Database) là "danh sách thu hồi" chặn các nhị phân bị phán định là dễ bị tấn công hoặc độc hại. Firmware chỉ thực thi một bootloader khi chữ ký của nó nằm trong db và không có trong dbx.
Lý do cấu trúc phân cấp này quan trọng nằm ở thu hồi (dbx) và phân tách thẩm quyền. Khi một bootloader cụ thể trở nên dễ bị tấn công, có thể thêm băm của nó vào dbx để chặn trên phạm vi toàn cầu, đây chính là nguyên lý giống như thu hồi chứng thư. Phe Linux đặt một bootloader shim được Microsoft UEFI CA ký, để một bản phân phối có thể khởi động GRUB và nhân do chính nó ký bằng khóa riêng dưới sự tin cậy của Microsoft, qua đó bảo đảm tính liên vận. Tuy nhiên cấu trúc này phụ thuộc hoàn toàn vào tiền đề rằng PK được quản lý an toàn.
Trường hợp tiêu biểu mà chính tiền đề đó bị phá vỡ là PKfail năm 2024. Binarly đã phát hiện ra sự thật rằng một Platform Key do American Megatrends (AMI) tạo ra để kiểm thử và ghi rõ "DO NOT TRUST" đã được xuất xưởng y nguyên, không được thay thế, vào khoảng 813 sản phẩm của Acer, Dell, HP, Lenovo, Supermicro v.v. (firmware ra mắt từ tháng 5 năm 2012 đến tháng 6 năm 2024) (BRLY-2024-005). Kẻ tấn công nắm khóa riêng của PK kiểm thử bị rò rỉ đó có thể thao túng KEK, db, dbx để vô hiệu hóa Secure Boot. Sự việc này phơi bày đúng bản chất của chuỗi tin cậy: "một khi việc quản lý khóa ở gốc tin cậy sụp đổ thì mọi kiểm chứng bên trên nó đều mất ý nghĩa".
B. Khởi động đo lường và TPM PCR
Trái tim của khởi động đo lường là bản ghi tích lũy PCR (Platform Configuration Register) của TPM. Mỗi giai đoạn tính băm của đoạn mã kế tiếp trước khi thực thi nó và ghi vào PCR, nhưng không phải bằng cách ghi đè mà bằng cách extend (tích lũy) theo dạng PCR_new = Hash(PCR_old ‖ giá trị đo). Phép toán này không thể đảo ngược, nên nếu bất kỳ một giai đoạn nào của quá trình khởi động thay đổi thì giá trị PCR cuối cùng sẽ thay đổi hoàn toàn. Nói cách khác, PCR trở thành "dấu vân tay không thể giả mạo của lịch sử khởi động".
Chẳng hạn, PCR0–7 ghi các giá trị đo của firmware, option ROM, cấu hình và bootloader, còn các PCR cao hơn ghi riêng các giá trị đo của bộ nạp OS và nhân. Việc tách PCR theo giai đoạn như vậy cho phép sau này phán định tinh vi điểm giả mạo, như "firmware bình thường nhưng chỉ bootloader thay đổi". Các bản ghi đo lường được giữ cùng với một nhật ký sự kiện bên ngoài TPM để bên kiểm chứng có thể tái dựng ý nghĩa của từng giá trị đo.
C. Chứng thực từ xa (Remote Attestation) và chống quay lui
Nếu giá trị đo chỉ được giữ bên trong thiết bị thì chúng chỉ dừng ở sự tự tham chiếu kiểu "xin hãy tin tôi". Vì vậy TPM ký các giá trị PCR bằng khóa chứng thực (AIK/AK) (một Quote) và nộp cho máy chủ kiểm chứng từ xa; máy chủ so sánh chúng với giá trị chuẩn (golden measurement) đã thu thập trước để phán định xem thiết bị có khởi động vào trạng thái đáng tin cậy hay không. Đây là cốt lõi của việc chống lưng cho tin cậy thiết bị bằng cơ sở phần cứng trong Zero Trust, và chứng thực VM trong điện toán bảo mật (Intel TDX·AMD SEV-SNP) cũng dùng cùng nguyên lý.
Mặt khác, chuỗi tin cậy cũng phải phòng vệ trước tấn công quay lui (hạ cấp). Để ngăn các cuộc tấn công đưa về một phiên bản firmware/bootloader cũ được ký hợp lệ nhưng đã biết có lỗ hổng, người ta đặt cơ chế chống quay lui (Anti-rollback) cưỡng chế phiên bản tối thiểu được phép bằng bộ đếm đơn điệu tăng (monotonic counter) hoặc cầu chì. Hơn nữa, NIST SP 800-193 (Platform Firmware Resiliency) quy định bảo mật firmware theo ba trục Bảo vệ (Protection)·Phát hiện (Detection)·Phục hồi (Recovery), đòi hỏi cả tính phục hồi (Resiliency) — tự động khôi phục về bản sao lưu đáng tin cậy khi phát hiện giả mạo.
4. So sánh triển khai theo nền tảng và các trường hợp
Nguyên lý chuỗi tin cậy là chung, nhưng đặt gốc ở đâu và kiểm chứng ra sao thì khác nhau theo từng nền tảng. Máy chủ và PC trước tiên kiểm chứng chính firmware bằng Intel Boot Guard / AMD PSB vốn đặt gốc trong CPU/chipset; thiết bị di động và nhúng dùng Boot ROM bên trong SoC cùng chuỗi ARM TrustZone / TF-A; còn Apple, một hệ sinh thái đóng, xây dựng một chuỗi rất kiên cố bằng Boot ROM bất biến và Secure Enclave. Những khác biệt này phản ánh sự đánh đổi giữa "mở và có thể thay thế đến đâu" và "được kiểm soát và kiên cố đến đâu".
| Nền tảng | Gốc tin cậy | Chuỗi kiểm chứng | Đặc điểm |
|---|---|---|---|
| PC/máy chủ x86 | Intel Boot Guard·AMD PSB(cầu chì) | firmware→UEFI Secure Boot→bootloader | mở·liên vận(shim), thu hồi dbx |
| Di động/nhúng ARM | Boot ROM của SoC | BL1→BL2→BL31→bootloader(TF-A) | tách thế giới an toàn TrustZone |
| Apple | Boot ROM bất biến·Secure Enclave | LLB→iBoot→nhân | đóng·cực kiên cố, cưỡng chế chống quay lui |
| Android | RoT phần cứng | Android Verified Boot(dm-verity) | toàn vẹn phân vùng·chống quay lui |
| Chromebook | firmware chỉ đọc | RO→RW(A/B)→nhân | dự phòng phục hồi·tự sửa chữa |
Lấy một trường hợp cụ thể, Verified Boot của Google Chromebook lấy firmware chỉ đọc làm gốc và giữ hai bản firmware đọc/ghi (A/B), để nếu một bản hỏng thì tự động khôi phục qua bản kia hoặc qua chế độ phục hồi — đây là hiện thực hóa ở mức sản phẩm cái "phục hồi" mà NIST SP 800-193 mô tả. AVB (Android Verified Boot) của Android kiểm chứng tính toàn vẹn ở mức khối của phân vùng hệ thống bằng dm-verity và giữ phiên bản tối thiểu được phép trong vbmeta để chặn hạ cấp. Apple cấu thành một chuỗi mà chỉ cần một chữ ký từ Boot ROM đến nhân lệch là rơi vào chế độ phục hồi — khiến nó trên thực tế thuộc nhóm thiết bị thương mại khó giả mạo nhất.
5. Chuyên sâu — Tấn công·né tránh Chuỗi tin cậy và xu hướng mới nhất
Khi khởi động an toàn trở nên phổ biến, kẻ tấn công tiến hóa theo hướng nhắm vào "mắt xích yếu nhất" của chuỗi. Xu hướng thứ nhất là né tránh bằng cách cấy lại một phần tử được ký hợp lệ nhưng dễ bị tấn công. Điển hình là BlackLotus (2023) tái sử dụng bootloader cũ Baton Drop (CVE-2022-21894) để vượt qua Secure Boot của Windows 11 đã vá; điều này để lại bài học rằng "kiểm chứng chỉ dựa trên danh sách cho phép (db) là chưa đủ, phải giữ thu hồi (dbx) luôn mới". Tuy nhiên, việc cập nhật dbx có thể vô tình khiến các thiết bị bình thường không khởi động được, nên Microsoft phải ứng phó bằng triển khai từng bước thận trọng (KB5025885 v.v.).
Xu hướng thứ hai là sự sụp đổ của chính việc quản lý gốc·khóa. PKfail (2024) phơi bày rằng nếu một PK kiểm thử bị bỏ mặc trong hàng trăm mẫu máy thì dù việc kiểm chứng ở tầng trên tinh vi đến đâu, một khi khóa gốc bị chia sẻ hay rò rỉ thì toàn bộ sẽ sụp đổ. Điều này ngụ ý rằng rủi ro của khởi động an toàn không nằm ở thuật toán mật mã mà ở bài toán vận hành quản lý vòng đời khóa (tạo·tiêm·xoay·thu hồi).
Xu hướng thứ ba là mở rộng tới các môi trường IoT·nhẹ không có TPM. DICE (Device Identifier Composition Engine) của TCG, dành cho các thiết bị nhỏ không có chip bảo mật chuyên dụng, đưa một bí mật riêng của chip (UDS) và giá trị đo của mỗi tầng vào hàm dẫn xuất khóa để dẫn ra Định danh phức hợp theo từng tầng (CDI), qua đó cung cấp đồng thời tin cậy phần cứng và một định danh riêng của thiết bị. Vì mỗi tầng xóa bí mật của chính mình sau khi dùng rồi mới kế thừa lên tầng trên, nên có thể hiện thực chuỗi tin cậy và chứng thực từ xa ngay cả trên các MCU chi phí thấp, do đó việc áp dụng đang tăng trong Android, điện toán bảo mật và tương tự.
Xu hướng thứ tư là tính linh hoạt mật mã (Crypto Agility) và chuyển đổi hậu lượng tử. Khi RSA và ECDSA dùng cho chữ ký khởi động bị phơi bày trước mối đe dọa điện toán lượng tử, đang có thảo luận về việc thiết kế firmware và cấu trúc khóa sao cho thuật toán kiểm chứng khởi động có thể được thay bằng mật mã kháng lượng tử (PQC) như ML-DSA. Việc thay khóa gốc và thể chế chữ ký kéo theo việc ký lại và thu hồi quy mô lớn, nên phản ánh trước khả năng thay thế thuật toán của chuỗi tin cậy vào thiết kế đang ngày càng trở nên quan trọng.
6. Các điểm cần cân nhắc và hàm ý
Thứ nhất, cần đánh giá khởi động an toàn không phải bằng "có hay không có tính năng" mà bằng "thể chế vận hành·thu hồi". Như trường hợp BlackLotus cho thấy, dù Secure Boot được bật, nó vẫn bị né tránh nếu không thể thu hồi (dbx) phần tử dễ bị tấn công. Tổ chức phải đưa việc cập nhật firmware, bootloader và dbx vào quản lý tài sản·quản lý bản vá, và thiết lập quy trình kiểm chứng trước·triển khai từng bước để việc phát hành thu hồi không biến thiết bị bình thường thành cục gạch.
Thứ hai, phải ưu tiên hàng đầu việc kiểm soát quản lý khóa vốn là gốc tin cậy. Như PKfail cho thấy, việc chia sẻ hay rò rỉ khóa gốc vô hiệu hóa toàn bộ việc kiểm chứng ở tầng trên. OEM và bên vận hành phải quy định rõ ràng, như những yêu cầu bảo mật chuỗi cung ứng, việc tạo PK riêng cho từng thiết bị, chặn khóa kiểm thử lọt vào sản xuất, ký dựa trên HSM, và quy trình xoay·thu hồi khóa, và phải kiểm chứng những điều này ở khâu mua sắm.
Thứ ba, phải dùng kết hợp kiểu kiểm chứng và kiểu đo lường để tạo phòng thủ theo chiều sâu, và liên kết chứng thực từ xa với Zero Trust. Chặn việc thực thi mã trái phép bằng khởi động kiểu kiểm chứng, và dùng khởi động kiểu đo lường cộng với chứng thực từ xa để kiểm chứng cả "trạng thái thực sự đã khởi động trong số những thứ được phép", rồi áp dụng vào phán định tin cậy thiết bị. Điều này trở nên hiệu quả hơn khi tích hợp với MDM, truy cập có điều kiện và chứng thực điện toán bảo mật.
Thứ tư, phải đưa tính phục hồi (Resiliency) vào như một yếu tố thiết kế. Theo các nguyên tắc Bảo vệ, Phát hiện, Phục hồi của NIST SP 800-193, chỉ khi có cơ chế tự động khôi phục về một ảnh vàng (golden image) đáng tin cậy khi phát hiện giả mạo firmware (dự phòng·vùng phục hồi) thì mới bảo vệ được đồng thời tính sẵn sàng và bảo mật. Đặc biệt với các máy chủ, OT và IoT vận hành không người·từ xa, tự động hóa phục hồi là bắt buộc.
Thứ năm, về triển vọng, cần đầu tư đón đầu vào RoT nhẹ và tính linh hoạt mật mã. Để mở rộng điện toán tin cậy tới IoT·biên quy mô lớn không có TPM, cần xem xét các chuẩn RoT nhẹ như DICE, và về dài hạn cần thiết kế thuật toán chữ ký khởi động theo cấu trúc có thể thay thế để chuẩn bị cho chuyển đổi PQC. Nhận thức rằng khởi động an toàn không phải là việc xây dựng một lần mà là bài toán quản lý Chuỗi cung ứng tin cậy (Trust Supply Chain) vốn liên tục làm mới, chứng thực và phục hồi các phần tử tin cậy, chính là quan điểm ở tầm Kỹ sư chuyên nghiệp.
Tài liệu tham khảo
- NIST, "SP 800-193: Platform Firmware Resiliency Guidelines", https://csrc.nist.gov/publications/detail/sp/800-193/final
- NSA, "BlackLotus Mitigation Guide" (2023.06), https://media.defense.gov/2023/Jun/22/2003245723/-1/-1/0/CSI_BlackLotus_Mitigation_Guide.PDF
- Binarly, "PKfail: Untrusted Platform Keys Undermine Secure Boot" (2024), https://binarly.io/blog/pkfail-untrusted-platform-keys-undermine-secure-boot-on-uefi-ecosystem
- Binarly Advisory BRLY-2024-005, https://binarly.io/advisories/brly-2024-005
- Android Open Source Project, "Device Identifier Composition Engine (DICE)", https://source.android.com/docs/security/features/dice
Tóm tắt một câu: Khởi động an toàn là một chuỗi mà, xuất phát từ Gốc tin cậy phần cứng (RoT), truyền tin cậy qua "kiểm chứng rồi thực thi" lên firmware, bootloader và nhân; nó phải vận hành đồng thời UEFI Secure Boot (kiểu kiểm chứng), TPM Measured Boot và chứng thực từ xa, đồng thời vận hành cả thu hồi dbx, quản lý khóa và tính phục hồi (NIST SP 800-193) thì mới chặn được các kiểu né tránh như BlackLotus và PKfail.