Hacker News Nổi bật (buzzing.cc bản dịch tiếng Trung)
92

Nghiên cứu

Ledger Donjon bẻ khóa bảo mật chip RP2350 bằng kỹ thuật tiêm lỗi laser

(giờ Việt Nam)

Tóm tắt AI

Các chuyên gia tại Ledger Donjon đã sử dụng kính hiển vi phát xạ photon và xung laser để ghi đè thanh ghi DEBUGEN, từ đó khôi phục quyền truy cập gỡ lỗi trên chip RP2350 vốn đã bị khóa vĩnh viễn.

Bản dịch AI

Photon-Emission-Guided Laser Fault Injection Enables RP2350 Secure Debug | Ledger Donjon

TL;DR (Tóm tắt)

— Kỹ thuật hiển vi phát xạ photon (photon-emission microscopy) đã cho phép chúng tôi xác định vị trí của một thanh ghi chịu trách nhiệm kích hoạt các tính năng gỡ lỗi (debug) trên vi điều khiển Raspberry Pi.

— Các xung laser tại hai vị trí gần nhau sau đó đã khôi phục quyền truy cập trình gỡ lỗi vào vùng Secure world của chip, ngay cả khi tính năng gỡ lỗi đã bị vô hiệu hóa vĩnh viễn.

— Sử dụng quyền truy cập đó sau khi thực hiện reset khẩn cấp, chúng tôi đã khôi phục một khóa bí mật từ bộ nhớ lập trình một lần (OTP). Quá trình reset đã làm dừng chip trước khi firmware kịp áp dụng khóa runtime, vì vậy trang bộ nhớ vẫn ở trạng thái Secure-readable (có thể đọc được ở chế độ bảo mật).

— Cuộc tấn công đòi hỏi quyền truy cập vật lý, quá trình chuẩn bị có tính phá hủy và khoảng 250.000 USD thiết bị phòng thí nghiệm.

Mô hình bảo mật của RP2350

RP2350 là vi điều khiển lõi kép của Raspberry Pi: mỗi socket bộ xử lý có thể 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 của nó bao gồm:

Raspberry Pi đã chủ động mời các nhà nghiên cứu đánh giá các biện pháp bảo vệ này thông qua chương trình RP2350 Hacking Challenges. Thử thách đầu tiên diễn ra từ tháng 8 đến tháng 12 năm 2024 nhắm vào con chip gốc. Sau khi giải quyết một số phát hiện, Raspberry Pi đã phát hành bản sửa đổi A4—phiên bản mà chúng tôi đã thử nghiệm.

Cấu hình bảo mật vĩnh viễn và dấu vân tay khóa công khai khởi động (boot public key fingerprints) được lưu trữ trong bộ nhớ lập trình một lần (OTP): mỗi bit có thể được chuyển từ 0 sang 1 một lần duy nhất và không bao giờ quay lại được, vì vậy bất cứ thứ gì được ghi vào đó sẽ tồn tại trong suốt vòng đời của chip.

OTP được tổ chức thành các trang 128 byte được bảo vệ bởi hai hàng khóa bền vững (persistent) hoặc khóa cứng (hard lock): đối với trang n, PAGEn_LOCK0 cấu hình các khóa đọc và ghi tùy chọn cùng hành vi khi không có khóa nào được nhập, trong khi PAGEn_LOCK1 chứa các quyền LOCK_S và LOCK_NS do phần cứng thực thi. Các trạng thái đó có thể chuyển từ đọc-ghi sang chỉ đọc hoặc không thể truy cập, nhưng không thể trở nên dễ dãi hơn.

Hệ thống con OTP sử dụng các mã hóa dư thừa cho các trường liên quan đến bảo mật: các cờ quan trọng được "mã hóa bằng cơ chế bỏ phiếu ba-trên-tám qua tám hàng OTP liên tiếp", và các bit khóa OTP được "mã hóa dư thừa gấp ba với cơ chế bỏ phiếu đa số", theo bảng dữ liệu của RP2350.

Khi reset OTP, các giá trị LOCK_S và LOCK_NS bền vững sẽ khởi tạo một khóa runtime cho mỗi trang, còn được gọi là khóa mềm (soft lock). Firmware có thể thắt chặt khóa này cho đến lần reset OTP tiếp theo, nhưng không thể nới lỏng nó. Thay đổi runtime sẽ không còn sau khi reset.

Trình gỡ lỗi bên ngoài giao tiếp với RP2350 thông qua giao diện Serial Wire Debug (SWD) của Arm. Các yêu cầu trước tiên đến Serial Wire Debug Port (SW-DP) và sau đó được định tuyến đến các cổng truy cập. Trong cấu hình Cortex-M33 được sử dụng ở đây, mỗi lõi có một cổng truy cập bộ nhớ (Mem-AP) kết nối với bus hệ thống của nó; một Mem-AP được kích hoạt cho phép trình gỡ lỗi đọc và ghi vào bộ nhớ và thiết bị ngoại vi được cấp phép. Một cổng truy cập luôn bật riêng biệt, RP-AP, cung cấp một tập hợp nhỏ các điều khiển reset và khôi phục.

Gỡ lỗi bảo mật (Secure debug) đề cập đến quyền truy cập Mem-AP với thuộc tính Secure. Trình gỡ lỗi sau đó có thể giao dịch với các tài nguyên được ánh xạ bộ nhớ Secure mà logic kiểm soát truy cập cho phép, đồng thời tạm dừng hoặc kiểm tra một lõi đang chạy ở trạng thái Secure.

Cờ CRIT1.DEBUG_DISABLE vĩnh viễn nhằm mục đích đóng đường dẫn này. Khi được thiết lập, nó đưa các tín hiệu kích hoạt cho Mem-AP của cả hai lõi về 0, điều này "ngăn chặn các AP thực hiện bất kỳ truy cập bus nào", và vô hiệu hóa giao diện kiểm tra nhà máy JTAG cũng như cổng truy cập mô-đun gỡ lỗi RISC-V. SW-DP và RP-AP vẫn phản hồi, nhưng không Mem-AP lõi nào có thể truy cập bus hệ thống.

Tuy nhiên, có một cơ chế ghi đè: thanh ghi DEBUGEN được ánh xạ bộ nhớ cho phép phần mềm Secure kích hoạt lại Mem-AP của mỗi lõi và, một cách riêng biệt, các truy cập Secure thông qua nó. Bảng dữ liệu nêu rõ rằng DEBUG_DISABLE "có thể được ghi đè hoàn toàn bằng cách thiết lập tất cả các bit của thanh ghi này".

Cơ chế ghi đè quan trọng trong chuỗi thực thi này chính là mục tiêu của chúng tôi đối với giao diện gỡ lỗi. Việc giành quyền truy cập vào gỡ lỗi bảo mật trên Mem-AP là một nguyên hàm đa năng để đọc và ghi bộ nhớ Secure, tạm dừng và thực hiện từng bước một lõi, và kiểm tra các thanh ghi của nó. Liệu thanh ghi đó có thể được thiết lập bởi một lỗi (fault) hay không là câu hỏi mà phần còn lại của bài viết này sẽ trả lời.

Thiết lập thực nghiệm

Cấu hình mục tiêu

RP2350 Hacking Challenge của Raspberry Pi yêu cầu người tham gia trích xuất một khóa bí mật 128-bit được lưu trữ trong OTP1. Khi khởi động, firmware thử thách đã ký đảm bảo rằng trang 48 có khóa bền vững như mong đợi, sau đó áp dụng một khóa runtime từ chối cả quyền truy cập Secure và Non-secure đối với khóa bí mật cho đến lần reset OTP tiếp theo.

Chúng tôi đã sao chép cấu hình do nhà cung cấp xác định này trên thiết bị sửa đổi A4 của riêng mình:

Việc kích hoạt secure boot chỉ cho phép các lõi Cortex-M33, vì vậy cả hai socket bộ xử lý đều sử dụng Arm cho các thí nghiệm này.

Chuẩn bị mẫu và bàn thử nghiệm

Thiết bị đã được loại bỏ lớp vỏ (decapsulated) từ mặt sau, để ánh sáng hồng ngoại tiếp cận các bóng bán dẫn qua đế silicon thay vì bị chặn bởi các lớp kim loại ở mặt trước. Chip sau đó được hàn lại vào một bo mạch con kết nối với Scaffold, nền tảng mã nguồn mở của Ledger Donjon để điều khiển và giám sát các thiết bị đang thử nghiệm. Việc loại bỏ khung chì ở mặt sau của chip làm đứt kết nối GND của nó, vì vậy một dây đồng được sử dụng để khôi phục lại.

DEBUGEN: ghi đè tính năng vô hiệu hóa gỡ lỗi vĩnh viễn

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

Gỡ lỗi bảo mật trên một lõi cần cả hai bit của nó: bit kích hoạt Mem-AP và bit cho phép các truy cập Secure thông qua nó.

Trái ngược với mã hóa dư thừa được sử dụng cho các trường bảo mật OTP, bảng dữ liệu không ghi lại bất kỳ sự dư thừa bit, chẵn lẻ hoặc bỏ phiếu đa số nào cho DEBUGEN.

Do đó, chúng tôi đã kiểm tra xem các xung laser có thể thiết lập các bit DEBUGEN trên thiết bị bảo mật được mô tả ở trên hay không.

Định vị dựa trên phát xạ photon

Thử nghiệm đó trước tiên đòi hỏi phải biết nhắm vào đâu. Việc thiết lập một bit DEBUGEN riêng lẻ có nghĩa là đánh trúng bộ lưu trữ của một bit thanh ghi duy nhất, giống như mò kim đáy bể. Đây là một vấn đề nhắm mục tiêu khó hơn so với các lỗi bỏ qua lệnh (instruction-skip faults) phổ biến trong tiêm lỗi laser (laser fault injection), nơi việc làm nhiễu bất kỳ flip-flop nào trong số nhiều flip-flop trong đường ống lõi có thể tạo ra cùng một lần bỏ qua: điều đó làm lan rộng khu vực nhạy cảm đủ để một quá trình quét ngẫu nhiên có thể tìm thấy nó. Việc quét mù cho một bit DEBUGEN là không thực tế.

Các bóng bán dẫn chuyển mạch phát ra các photon cận hồng ngoại mờ nhạt tương quan với hoạt động của chúng, vì vậy việc thu thập phát xạ đó qua quá trình thực thi lặp đi lặp lại có thể tiết lộ nơi một điều khiển được chọn thay đổi trạng thái. Điều này làm cho kỹ thuật hiển vi phát xạ photon (PEM) trở nên phù hợp với DEBUGEN: là một thanh ghi được ánh xạ bộ nhớ, phần mềm Secure có thể chuyển đổi các bit chính xác trong một vòng lặp, thúc đẩy các thay đổi trạng thái lặp đi lặp lại mà phép đo cần. Chúng tôi đã sử dụng nó như giai đoạn định vị đầu tiên, và bản đồ kết quả đã giới hạn quá trình quét laser tiếp theo vào một vùng vài micromet.

Chúng tôi đã so sánh các vòng lặp liên tục chuyển đổi các bit DEBUGEN được chọn bật và tắt, chỉ khác nhau ở các bit mà chúng nhắm tới. Phát xạ photon của một thanh ghi rất mờ so với nhiễu của chính camera và nhạy cảm với các điều kiện môi trường thay đổi chậm như nhiệt độ, vì vậy một khung hình duy nhất không tiết lộ điều gì. Việc lấy trung bình nhiều khung hình của mỗi vòng lặp đã triệt tiêu nhiễu cảm biến ngẫu nhiên, và việc trừ hai chồng trung bình đã loại bỏ mọi thứ mà các vòng lặp chia sẻ: nền tĩnh, độ lệch cảm biến, phát xạ nhiệt và chuyển mạch không liên quan đến các bit được chọn. Việc xen kẽ hai giá trị trong quá trình thu thập đã ngăn chặn sự trôi chậm làm sai lệch phép trừ đó. Những gì còn lại là phát xạ theo dõi các bit được chọn.

Các so sánh lặp đi lặp lại trên các mặt nạ bit khác nhau đã làm lộ ra các vị trí nhỏ gọn liên quan đến các bit DEBUGEN 0–3 trên ba vùng của trường camera.

Các vùng này cho thấy hoạt động chuyển mạch liên quan đến từng bit DEBUGEN; chúng không xác định trực tiếp các ô lưu trữ. Nhiều điểm nóng (hotspots) được quan sát cho mỗi bit có thể phát sinh từ phần tử lưu trữ hoặc từ logic liên quan. Nếu không có dữ liệu bố trí (layout data), chúng tôi không thể phân biệt giữa hai loại này. Tuy nhiên, các vùng này vẫn giảm đáng kể không gian tìm kiếm.

Phát hiện 1 — gây lỗi DEBUGEN để có được gỡ lỗi bảo mật

Đối với tiêm lỗi laser (LFI), chúng tôi đã sử dụng laser xung ở bước sóng 980 nm với công suất quang tối đa 2,97 W, hoạt động ở mức khoảng 40% (khoảng 1,2 W), với độ rộng xung 100 ns thông qua vật kính 50x. Sau mỗi xung, chúng tôi thăm dò các cổng truy cập gỡ lỗi qua SWD.

Trong khu vực tìm thấy từ PEM, chúng tôi đã chạy quét LFI và sử dụng phản hồi SWD đó để hiệu chỉnh hai vị trí phản hồi cách nhau vài micromet. Tại một vị trí, các xung đã kích hoạt quyền truy cập bus thông qua Mem-AP của lõi 1, cho thấy PROC1 đã được thiết lập. Tại vị trí kia, Word Trạng thái/Điều khiển của Mem-AP báo cáo SDeviceEn = 1, một tín hiệu hướng dẫn trạng thái cho thấy PROC1_SECURE có khả năng đã được thiết lập. Chúng tôi đã kiểm tra cả hai chỉ báo sau mỗi xung.

Một xung thiết lập bit này có thể xóa bit kia, vì vậy việc thiết lập cả hai đòi hỏi một trình tự lặp đi lặp lại. Tập lệnh của chúng tôi đã phát xung vào vị trí PROC1 cho đến khi có quyền truy cập bus, sau đó phát xung vào vị trí PROC1_SECURE cho đến khi SDeviceEn = 1, quay lại vị trí đầu tiên bất cứ khi nào quyền truy cập bus bị mất. Khi các vị trí và tham số xung được hiệu chỉnh, trình tự này đã kích hoạt gỡ lỗi bảo mật trong vài giây. Thú vị là, chúng tôi không thể tái tạo trình tự này bằng vật kính 20x. Vì hai vị trí chỉ cách nhau vài micromet, điểm sáng rộng hơn đó có khả năng đã đánh trúng cả vùng thiết lập bit và vùng xóa bit, vì vậy không thể thu được giá trị chính xác.

Bảo mậtPhần cứngRP2350LedgerLỗ hổng
Đọc bài gốc

Bài viết được AI dịch và tổng hợp tự động từ Hacker News Nổi bật (buzzing.cc bản dịch tiếng Trung). Liên kết bài gốc ở phía trên. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.