Dùng kính hiển vi photon và laser để phá khóa Secure Debug trên chip RP2350

Chip RP2350 của Raspberry Pi được thiết kế với nhiều lớp bảo vệ phần cứng, bao gồm secure boot, TrustZone của Arm và cơ chế vô hiệu hóa gỡ lỗi vĩnh viễn. Thế nhưng một nhóm nghiên cứu tại Ledger Donjon vừa chứng minh rằng chỉ cần vài xung laser đúng vị trí, họ có thể khôi phục quyền truy cập gỡ lỗi vào vùng Secure — và từ đó đọc được bí mật lưu trong bộ nhớ một lần ghi.

Bối cảnh: RP2350 và mô hình bảo mật

RP2350 là vi điều khiển lõi kép của Raspberry Pi, cho phép mỗi khe xử lý chọn lõi Arm Cortex-M33 hoặc RISC-V Hazard3 khi khởi động. Các tính năng bảo mật phần cứng chính gồm:

• Secure boot, xác thực firmware đã ký dựa trên dấu vân tay khóa công khai nạp trong bộ nhớ OTP (One-Time Programmable)
• TrustZone theo kiến trúc Armv8-M, tách biệt trạng thái thực thi Secure và Non-secure
• Cấu hình vô hiệu hóa gỡ lỗi vĩnh viễn
• Bộ phát hiện glitch, dùng để phát hiện các nhiễu loạn thời gian do thao túng xung nhịp hoặc nguồn điện

Raspberry Pi từng công khai mời giới nghiên cứu kiểm tra các biện pháp bảo vệ này thông qua RP2350 Hacking Challenge. Sau khi một số phát hiện được xử lý, Raspberry Pi phát hành phiên bản A4 — chính là phiên bản mà nhóm Ledger Donjon thử nghiệm.

Bộ nhớ OTP được tổ chức thành các trang 128 byte, được bảo vệ bằng hai hàng khóa cứng (LOCK0 và LOCK1). Mỗi bit chỉ có thể đảo từ 0 sang 1 một lần và không thể quay lại. Các trường bảo mật quan trọng còn được mã hóa dư thừa: cờ quan trọng dùng bỏ phiếu ba trong tám, còn bit khóa OTP được nhân ba và bỏ phiếu theo đa số.

Một chi tiết đáng chú ý: khi OTP reset, các giá trị khóa cứng sẽ khởi tạo khóa runtime (còn gọi là khóa mềm). Firmware chỉ có thể siết chặt khóa này cho đến lần reset OTP tiếp theo, chứ không thể nới lỏng.

Điểm yếu nằm ở thanh ghi DEBUGEN

Cờ CRIT1.DEBUG_DISABLE vĩnh viễn được thiết kế để đóng đường gỡ lỗi. Khi được đặt, nó đưa tín hiệu cho phép của các bộ truy cập bộ nhớ (Mem-AP) về 0, ngăn các AP thực hiện bất kỳ truy cập bus nào.

Tuy nhiên, tồn tại một cơ chế ghi đè: thanh ghi DEBUGEN cho phép phần mềm Secure bật lại Mem-AP của từng lõi và cho phép truy cập Secure qua đó. Theo tài liệu kỹ thuật, DEBUG_DISABLE "có thể bị ghi đè hoàn toàn bằng cách đặt tất cả các bit của thanh ghi này".

DEBUGEN có năm bit chức năng:

• Bit 0 (PROC0): bật Mem-AP của lõi 0
• Bit 1 (PROC0_SECURE): cho phép truy cập Secure qua Mem-AP của lõi 0
• Bit 2 (PROC1): bật Mem-AP của lõi 1
• Bit 3 (PROC1_SECURE): cho phép truy cập Secure qua Mem-AP của lõi 1
• Bit 8 (MISC): bật các thành phần gỡ lỗi bổ sung

Điểm mấu chốt: khác với các trường bảo mật OTP, tài liệu kỹ thuật không ghi nhận bất kỳ cơ chế dư thừa, chẵn lẻ hay bỏ phiếu đa số nào cho DEBUGEN.

Định vị bằng kính hiển vi phát xạ photon

Bài toán đầu tiên là phải biết nhắm laser vào đâu. Việc đặt một bit DEBUGEN đơn lẻ đồng nghĩa với việc đánh trúng vùng lưu trữ của một bit thanh ghi — khó hơn nhiều so với các lỗi bỏ qua lệnh thông thường trong tấn công laser, vốn có vùng nhạy cảm rộng đủ để quét ngẫu nhiên tìm ra.

Bởi vậy nhóm nghiên cứu dùng kính hiển vi phát xạ photon (PEM) làm bước định vị đầu tiên. Các transistor chuyển mạch phát ra photon hồng ngoại gần rất yếu, tương quan với hoạt động của chúng. Vì DEBUGEN là thanh ghi ánh xạ bộ nhớ, phần mềm Secure có thể đảo các bit cụ thể trong vòng lặp, tạo ra trạng thái thay đổi lặp lại mà phép đo cần.

Sơ đồ phát xạ photon thô và ảnh hiệu số

Nhóm so sánh các vòng lặp đảo các bit DEBUGEN khác nhau, chỉ khác nhau ở bit mục tiêu. Việc lấy trung bình nhiều khung hình giúp triệt nhiễu cảm biến, còn phép trừ hai chồng trung bình loại bỏ mọi thứ chung giữa hai vòng lặp: nền tĩnh, độ lệch cảm biến, phát xạ nhiệt và các chuyển mạch không liên quan. Kết quả còn lại chính là phát xạ bám theo các bit được chọn.

Phương pháp này thu hẹp không gian tìm kiếm xuống còn vùng chỉ vài micromet, tạo tiền đề cho bước quét laser tiếp theo.

Bản đồ phát xạ photon với các vị trí bit DEBUGEN

Kết quả: laser mở lại Secure Debug

Với tấn công lỗi bằng laser (LFI), nhóm dùng laser xung bước sóng 980 nm, công suất quang tối đa 2,97 W nhưng vận hành ở khoảng 40% (tức khoảng 1,2 W), độ rộng xung 100 ns qua vật kính 50x. Sau mỗi xung, họ dò các cổng truy cập gỡ lỗi qua giao diện SWD.

Trong vùng do PEM xác định, nhóm chạy quét LFI và dùng phản hồi SWD để hiệu chuẩn hai vị trí phản hồi cách nhau vài micromet. Tại một vị trí, xung laser bật truy cập bus qua Mem-AP của lõi 1, cho thấy PROC1 đã được đặt. Tại vị trí kia, thanh ghi trạng thái báo SDeviceEn = 1, dấu hiệu cho thấy PROC1_SECURE có khả năng đã được đặt.

Bản đồ so sánh vị trí PEM và điểm tấn công laser

Một xung có thể đặt bit này nhưng xóa bit kia, nên cần một chuỗi lặp. Script của nhóm xung vào vị trí PROC1 cho đến khi có truy cập bus, rồi xung vào vị trí PROC1_SECURE cho đến khi SDeviceEn = 1, quay lại vị trí đầu mỗi khi mất truy cập bus. Khi các vị trí và tham số xung đã được hiệu chuẩn, chuỗi này mở được Secure Debug trong vòng vài giây.

Đáng chú ý, nhóm không thể tái tạo chuỗi này bằng vật kính 20x, bởi hai vị trí chỉ cách nhau vài micromet nên điểm sáng rộng hơn sẽ đánh trúng cả vùng đặt bit lẫn vùng xóa bit.

Khai thác bí mật trong OTP

Việc mở Secure Debug vẫn chưa đủ để đọc bí mật của thử thách, vì khóa runtime ở trang 48 chặn cả truy cập Secure lẫn Non-secure sau khi firmware chạy. Nhưng khóa phần mềm "được khởi tạo từ các trang khóa OTP khi reset", và thao tác ghi chỉ tiến trạng thái "cho đến lần reset tiếp theo".

Điểm mấu chốt là RP-AP — cổng truy cập luôn hoạt động ngay cả khi gỡ lỗi bên ngoài bị vô hiệu hóa. Đặt CTRL.RESCUE_RESTART sẽ kích hoạt rescue reset: một lần reset toàn hệ thống, đồng thời đánh dấu để boot ROM dừng lại trước khi bất kỳ phần mềm người dùng nào chạy.

Quy trình nhóm thực hiện:

1. Rescue reset: đặt CTRL.RESCUE_RESTART = 1 rồi xóa về 0 qua RP-AP. Chip reset và dừng ở đường chờ của boot ROM, nên firmware đã ký không bao giờ chạy và sw_lock[48] không bị siết lại
2. Tấn công lỗi DEBUGEN thành 0xc: với cả hai lõi đang chờ, đặt PROC1 và PROC1_SECURE như mô tả
3. Dừng lõi 1 qua thanh ghi DHCSR trên Mem-AP đã có thuộc tính Secure
4. Đọc bí mật từ các hàng OTP 0xc08–0xc0f qua giao diện đọc được bảo vệ

Nhóm đã chạy chuỗi này trên thiết bị thử nghiệm và thu hồi được toàn bộ bí mật của thử thách.

DEBUGEN_LOCK cũng không ngăn được laser

Một phát hiện đáng lo ngại khác: DEBUGEN_LOCK được thiết kế để chặn ghi phần mềm vào các bit DEBUGEN tương ứng, mỗi bit khóa "ghi 1 để khóa bit […] của DEBUGEN. Không thể xóa một khi đã đặt". Tài liệu kỹ thuật giới thiệu cơ chế này như cách "tránh ghi nhầm".

Thế nhưng trong thử nghiệm với bit DEBUGEN mục tiêu ở giá trị 0 và bit khóa ở 1, xung laser vẫn đặt được DEBUGEN trong khi khóa giữ nguyên giá trị 1. Xung cũng đặt được chính các bit khóa. Trong các chuỗi thành công, cả năm bit khóa chức năng đều bằng 1 khi PROC1 và PROC1_SECURE cùng được đặt. Nhóm chưa từng thấy bit khóa quay về 0, nghĩa là sau khi lỗi laser đặt khóa tương ứng, thao tác ghi DEBUGEN = 0 không thể khôi phục trạng thái vô hiệu hóa.

Hạn chế của các biện pháp giảm thiểu bằng phần mềm

Một khi truy cập Secure qua Mem-AP được bật, thuộc tính Secure không còn tách biệt debugger khỏi firmware Secure nữa. Truy cập này không ghi đè khóa OTP cứng hay các kiểm soát riêng của ngoại vi, nhưng ACCESSCTRL cũng không tự nó ngăn được việc debugger điều khiển lõi Secure gây ra truy cập từ lõi hoặc trích xuất giá trị đã nạp qua thanh ghi lõi.

Sau rescue reset, ACCESSCTRL trở về mặc định mở hoàn toàn ở thời điểm reset, trước khi firmware kịp cấu hình lại. Vì vậy ACCESSCTRL chỉ giảm mức độ phơi bày trực tiếp qua Mem-AP, chứ không tạo thành ranh giới bảo mật độc lập.

Firmware vẫn có thể giảm phơi bày sau khởi động bằng cách từ chối debugger truy cập các mục tiêu nhạy cảm trong ACCESSCTRL, rồi đặt bit debugger trong ACCESSCTRL.LOCK. Firmware Secure cũng có thể kiểm tra DEBUGEN định kỳ và kích hoạt reset an toàn khi phát hiện giá trị bất thường. Nhưng đây đều là biện pháp runtime "nỗ lực tốt nhất": debugger đã bật có thể dừng lõi trước lần kiểm tra tiếp theo, còn rescue reset thì dừng lại trước khi firmware kịp cấu hình ACCESSCTRL.

Yêu cầu của cuộc tấn công

Chuỗi tấn công này cung cấp truy cập bộ nhớ có thuộc tính Secure, quyền điều khiển thực thi vùng Secure và khả năng đọc bí mật của thử thách. Nhưng nó đòi hỏi:

• Truy cập vật lý phá hủy: quá trình bóc lớp mặt sau (backside decapsulation) thay đổi vĩnh viễn vỏ chip và để lộ die
• Thiết bị phòng thí nghiệm chuyên dụng: toàn bộ thiết lập ước tính khoảng 250.000 USD
• Chuyên môn bảo mật phần cứng: cần chuẩn bị mẫu, điều hướng die, chọn tham số laser và phối hợp điều khiển laser, định vị bàn thử với đo lường SWD

Bài học hệ thống

Điểm đáng suy ngẫm là RP2350 mã hóa dư thừa các cờ vô hiệu hóa gỡ lỗi quan trọng trong OTP, nhưng DEBUGEN có thể ghi đè hiệu lực của chúng mà lại không có cơ chế bảo vệ tương đương trong tài liệu kỹ thuật. Từng cơ chế phần mềm đều thực hiện đúng chức năng được ghi chép, nhưng sự tương tác giữa chúng với lỗi laser lại mở ra Secure Debug.

Bài học ở cấp hệ thống là phân tích bảo mật phải bao quát toàn bộ đường thực thi, từ cấu hình OTP bền vững qua các thanh ghi điều khiển có thể thay đổi cho tới hành vi reset — bởi bảo mật hệ thống phụ thuộc vào cả đường đi đó, chứ không phải vào từng cơ chế riêng lẻ.

Với người dùng Việt Nam làm việc trong lĩnh vực IoT, thiết bị nhúng hay bảo mật phần cứng, đây là lời nhắc rằng bảo vệ chống gỡ lỗi trên vi điều khiển thường chỉ là rào cản nhiều lớp chứ không phải bức tường tuyệt đối. Với các ứng dụng triển khai ngoài thực địa — nơi kẻ tấn công có thể tiếp cận thiết bị — việc lưu trữ khóa và bí mật dài hạn chỉ trong OTP, dựa hoàn toàn vào cờ vô hiệu hóa gỡ lỗi, cần được đánh giá lại nghiêm túc.

Phía Ledger Donjon cho biết họ đã báo cáo lỗi này cho Raspberry Pi vào ngày 28/7/2026 và cảm ơn đội ngũ Raspberry Pi đã trao đổi thẳng thắn trong quá trình công bố.