14.3.4. Lưu ý về bảo vệ đọc bộ nhớ flash¶

Mặc định khi xuất xưởng, firmware trên một OpenMV cam được giao hàng có thể đọc được bởi bất kỳ ai có quyền truy cập vật lý vào thiết bị. Kẻ tấn công cầm camera trong tay có thể gắn đầu dò SWD vào header debug, giao tiếp với giao diện debug của MCU và dump toàn bộ bộ nhớ flash -- bao gồm tất cả các mô-đun Python đã đóng băng và nội dung của phân vùng ROMFS. Firmware OpenMV mặc định không bật tính năng bảo vệ đọc flash theo mặc định.

Trang này ghi lại điều đó một cách rõ ràng để nhóm phát hành sản phẩm biết trách nhiệm thuộc về ai.

14.3.4.1. Camera hoạt động như thế nào theo mặc định¶

Bootloader và runtime của camera không bật bất kỳ tính năng bảo vệ đọc nào của MCU bên dưới. Giao diện debug vẫn mở, bộ nhớ flash vẫn có thể đọc được, và bản build chạy theo cách nó chạy trên bàn của nhà phát triển. Đó là giá trị mặc định đúng đắn cho đối tượng hướng dẫn -- một camera được giao hàng với tính năng bảo vệ đọc đã bật là một camera không thể nạp lại firmware qua IDE, không thể khôi phục lại sau một lần triển khai thất bại, và không thể cứu vãn bởi bất kỳ ai ngoài nhóm build.

Sự đánh đổi thay đổi khi camera chuyển từ "thiết bị phát triển" sang "sản phẩm". Một sản phẩm mà giá trị của nó phụ thuộc vào việc mã ứng dụng giữ nguyên bí mật phải tự bật tính năng bảo vệ; firmware OpenMV không làm điều đó.

14.3.4.2. Những gì nhóm sản phẩm thực hiện¶

Mỗi nhà cung cấp MCU đều cung cấp một cơ chế bảo vệ đọc. Các chi tiết khác nhau -- cầu chì ở mức bit, chuyển đổi vòng đời một lần, ảnh flash có chữ ký -- nhưng hình thức chung là:

Một bit cụ thể của nhà cung cấp (hoặc tập hợp các bit) được ghi vào silicon, thường thông qua một công cụ của nhà cung cấp giao tiếp với cổng debug của MCU lần cuối.
Sau khi ghi, cổng debug từ chối đọc bộ nhớ flash. Camera vẫn khởi động và chạy ứng dụng; nó chỉ không còn tiết lộ nội dung của mình cho đầu dò nữa.
Việc ghi là không thể đảo ngược. Không có cách nào để đưa camera trở lại trạng thái có thể debug mà không phá hủy nó.

Việc thiết lập này đặc thù theo từng MCU, và các bước phụ thuộc vào linh kiện trên camera đang được bảo vệ. Tài liệu tham khảo của nhà cung cấp là nguồn thông tin đáng tin cậy; bộ phận hỗ trợ của nhà cung cấp là kênh để thực hiện đúng trên dây chuyền sản xuất.

Đây là phần dễ.

Phần khó là việc đóng tất cả các đường khác mà kẻ tấn công có để chạy mã trên camera hoặc đọc những gì ứng dụng đang làm. Bảo vệ đọc chỉ ngăn đầu dò debug dump bộ nhớ flash. Camera vẫn cần đóng:

REPL của MicroPython. Một REPL kết nối qua USB chấp nhận Python tùy ý. Bảo vệ đọc không thay đổi điều đó. Một phiên REPL có thể đọc RAM, gọi hàm, lọc ra bất cứ thứ gì ứng dụng đang chạy có thể thấy -- thực tế là, một REPL có thể truy cập bỏ qua tất cả những gì bảo vệ đọc mang lại. Vô hiệu hóa quyền truy cập REPL là thay đổi build firmware mà nhóm sản phẩm chịu trách nhiệm.
Tải lên tập lệnh qua IDE. Đường dẫn "chạy tập lệnh này trên camera" của IDE sử dụng cùng bề mặt giao thức USB mà REPL sử dụng. Đóng REPL sẽ đóng cái này theo; để mở một trong hai là để mở một kênh thực thi mã tùy ý vào camera.
Chiếm quyền kiểm soát điểm vào từ hệ thống tệp. Đã được đóng khi ứng dụng được giao hàng thông qua Đóng băng tập lệnh vào firmware -- runtime phân giải boot.py và main.py đã đóng băng trước bất kỳ bản sao hệ thống tệp nào, vì vậy không có gì được thả trên flash hoặc SD có thể ghi đè chúng. Sự bảo vệ này là miễn phí một khi ứng dụng đã được đưa vào build.
Bộ nhớ flash bên ngoài trên các camera mới hơn. Các camera lưu trữ ảnh ứng dụng trong bộ nhớ flash bên ngoài đặt ảnh đó trên một chip nằm lộ liễu trên PCB; chip có thể bị hàn tách ra và đọc trực tiếp bằng các công cụ thông dụng, hoặc đọc tại chỗ bằng cách thăm dò bus. Bảo vệ nó đòi hỏi bật phần cứng trên chip giải mã nội dung flash trong quá trình đọc, tạo khóa mã hóa, cung cấp khóa đó cho camera, và ghi không thể đảo ngược vào bộ nhớ lập trình một lần của MCU. Mỗi thứ đó là một thao tác một lần riêng biệt, và bất kỳ thao tác nào thực hiện sai trên một đơn vị sản xuất sẽ làm hỏng đơn vị đó.

Mỗi mục trong danh sách này là cả một tập hợp riêng các công việc build firmware, các bước trên dây chuyền sản xuất và các cam kết không thể đảo ngược. Một sản phẩm thực sự được khóa chặt là một build firmware tùy chỉnh, một bootloader tùy chỉnh, một quy trình sản xuất cung cấp khóa theo từng đơn vị, và một bộ kiểm tra chứng minh rằng khóa thực sự đã đóng trước khi đơn vị rời dây chuyền. Đó là công việc của nhiều tháng, không phải ngày, và tính không thể đảo ngược có nghĩa là sai lầm tốn kém các đơn vị.

Tại sao giá trị mặc định là mở

Danh sách này cũng là lý do tại sao firmware OpenMV mặc định được giao hàng không có bảo vệ đọc được bật. Một camera với REPL đã đóng, tải lên tập lệnh qua IDE bị vô hiệu hóa, và firmware bị khóa là một camera không thể phát triển trên đó -- quy trình làm cho OpenMV cam có thể sử dụng ngay từ đầu sẽ biến mất. Mặc định để mọi thứ mở; nhóm sản phẩm chọn phần nào cần đóng trên đường đến một đơn vị được giao hàng.

14.3.4.3. Những gì quyền truy cập vật lý vẫn mang lại¶

Ngay cả với bảo vệ đọc đã bật, kẻ tấn công cầm camera trong tay có thể làm được khá nhiều:

Phát lại lưu lượng mạng của camera bằng cách nghe lén đầu ra của nó.
Quan sát hành vi hiển thị của nó và suy ra cách nó phản ứng với các đầu vào.
Trong một số trường hợp, khôi phục bí mật thông qua các cuộc tấn công fault-injection hoặc side-channel chuyên biệt chống lại MCU được bảo vệ.

Bảo vệ đọc làm tăng chi phí để tiếp cận mã nguồn của ứng dụng. Nó không loại bỏ chi phí đó. "Truy cập vật lý = xâm phạm" là giả định làm việc mà một đánh giá bảo mật nên bắt đầu từ; cơ chế bảo vệ chỉ quyết định sự xâm phạm đó tốn bao nhiêu thời gian và thiết bị.

14.3.4.4. Những gì firmware OpenMV được giao hàng kèm theo¶

Một tóm tắt, để điều này rõ ràng:

Không bật bảo vệ đọc theo mặc định.
Không có cờ build trong firmware mặc định để bật nó.
Không có API cấp ứng dụng để gọi từ MicroPython.

Một sản phẩm cần sự bảo vệ sẽ giao hàng firmware tùy chỉnh. Tùy chỉnh đó nằm trong bootloader của bo mạch và quy trình sản xuất, và nằm ngoài codebase OpenMV. Các nhóm thực hiện điều này lần đầu tiên nên lên kế hoạch đưa nó vào dòng thời gian phát triển như một phần công việc riêng biệt, không phải là thứ để thêm vào cuối -- tính không thể đảo ngược làm cho "thêm sau" trở nên tốn kém.