AAOS SDV – Bảo mật từ trong thiết kế

Tại Google, chúng tôi tin rằng các sản phẩm của mình phải được thiết kế để đảm bảo tính bảo mật. Đó là lý do chúng tôi xây dựng Hệ điều hành Android Automotive cho Xe được xác định bằng phần mềm (AAOS SDV) trên các nền tảng hiện có, đã được thị trường chứng minh, tận dụng các công nghệ ảo hoá như Cuttlefish. Trong khi thông báo phát hành của chúng tôi tập trung vào các tính năng, thì bài đăng trên blog này trình bày một số khái niệm bảo mật.

Nền tảng: Cách ly miền

Ảo hoá để tách biệt các phiên bản được lưu trữ chung

Xu hướng hiện tại là hợp nhất các Bộ điều khiển điện tử (ECU) vào một khối duy nhất, giúp giảm bớt sự tách biệt bằng cách chạy nhiều miền song song.

Mặc dù các phiên bản AAOS SDV cung cấp cơ chế tách biệt nội bộ, nhưng bạn thường nên chạy các miền logic một cách độc lập. Ví dụ: cụm đồng hồ và hệ thống thông tin giải trí có các yêu cầu riêng biệt. Chúng tôi sử dụng máy ảo để chạy nhiều thực thể song song, đảm bảo rằng việc chia sẻ luôn rõ ràng và hành vi mặc định là tách biệt.

Bảo mật Android kế thừa

AAOS SDV phát triển từ Microdroid, một phiên bản Android tối giản được tối ưu hoá cho máy ảo riêng tư (pVM). Dòng này cung cấp cho các kỹ sư nền tảng Android các tính năng bảo mật đã được thiết lập mà họ đã biết.

Cô lập tiến trình và từ chối theo mặc định

AAOS SDV tuân theo mô hình tách biệt dựa trên Mã nhận dạng người dùng (UID) của Android để thiết lập hộp cát cho từng ứng dụng. Mỗi dịch vụ chạy trong một quy trình chuyên biệt có UID riêng để quản lý quyền truy cập, thư mục dữ liệu và các quy định hạn chế khác. Chúng tôi sử dụng các chức năng của Giao diện hệ điều hành di động (POSIX) để hạn chế nghiêm ngặt các hoạt động và kết hợp chức năng này với Security-Enhanced Linux (SELinux) để thực thi trạng thái "từ chối theo mặc định". Cách tiếp cận này hạn chế mỗi dịch vụ ở mức tối thiểu cần thiết, nghĩa là các cấu hình bị thiếu sẽ chặn quyền truy cập thay vì tạo ra một hệ thống có quyền quá mức. Chúng tôi áp dụng chiến lược tương tự cho hệ thống cấp quyền liên lạc, như được giải thích ở phần sau của bài viết này.

Quản lý lỗ hổng bảo mật đã được chứng minh

AAOS SDV tích hợp cơ sở hạ tầng quản lý lỗ hổng bảo mật và ứng phó bảo mật hoàn thiện của Android để xác định, phân loại, khắc phục và công bố các phát hiện về bảo mật. Vòng đời này bao gồm quy trình quét tự động liên tục, kiểm tra thâm nhập chuyên sâu hằng năm và thông tin tình báo do đối tác cung cấp thông qua quy trình báo cáo lỗ hổng bảo mật trên Android. Nhóm bảo mật sẽ phân loại các lỗ hổng bảo mật được phát hiện, chỉ định mức độ nghiêm trọng dựa trên rủi ro và theo dõi quá trình khắc phục cho đến khi hoàn tất. Chúng tôi điều phối các chính sách công bố và phát hành thông qua Bản tin về bảo mật Android hằng tháng, đồng thời bổ sung các quy trình kiểm tra bảo mật định kỳ nghiêm ngặt và quy trình xem xét toàn diện về cấu trúc để đảm bảo khả năng thích ứng và phục hồi lâu dài của nền tảng.

Tính toàn vẹn: Phân phối phần mềm an toàn

Ngoài việc đảm bảo cô lập tiến trình, một nền tảng bảo mật phải đảm bảo tính toàn vẹn của mã trước khi thực thi. Chúng tôi bảo mật việc phân phối phần mềm thông qua các phương pháp sau:

Phân phối phần mềm đã xác thực

AAOS SDV cung cấp hai phương thức cài đặt. Trước tiên, chúng tôi cài đặt phần mềm trực tiếp vào các phân vùng hệ thống, sản phẩm hoặc nhà cung cấp chỉ có thể đọc. Các phân vùng này sẽ xác thực chữ ký mỗi khi khởi động. Điều này giúp bảo mật các thành phần cơ bản của hệ thống.

Thứ hai, chúng tôi sử dụng các gói Android Pony EXpress (APEX) cho các dịch vụ. Mỗi APEX đóng gói phần mềm và các phần phụ thuộc của phần mềm, coi gói này là một phân vùng có quy trình xác thực chữ ký bắt buộc. Trong AAOS SDV, APEX coi việc ký mã là một hợp đồng liên tục, được thực thi bằng phần cứng. APEX đảm bảo giảm thiểu việc thực thi mã độc hại thông qua 4 trụ cột chính: 

1. Bộ nhớ bất biến

• Cơ chế: Nhân Android lặp trực tiếp tệp apex_payload.img dưới dạng thiết bị lưu trữ thô bằng cách sử dụng vòng lặp chỉ đọc, gắn tệp đó bằng cờ MS_RDONLY nghiêm ngặt.
• Tại sao phương thức này an toàn hơn: Phương thức này không hiển thị đường dẫn ghi vào hệ điều hành vì các tệp không được giải nén vào bộ nhớ của xe. Ngay cả khi kẻ tấn công có được đặc quyền gốc, chúng cũng không thể sửa đổi mã APEX đang chạy vì lớp hệ thống tệp từ chối tất cả lệnh ghi.

2. Tính toàn vẹn của mật mã

• Cơ chế: Chữ ký mật mã xác thực một Cây Merkle của toàn bộ hình ảnh hệ thống tệp.
• Lý do giúp phương thức này an toàn hơn: Nhân hệ điều hành sử dụng dm-verity cho mỗi khối để xác minh chữ ký cho mỗi khối dữ liệu 4KB một cách nhanh chóng. Nếu kẻ tấn công sửa đổi một khối thô trên bộ nhớ flash, thì hạt nhân sẽ phát hiện thấy hàm băm không khớp và dừng thực thi ngay lập tức.

3. Cách ly nghiêm ngặt

• Cơ chế: Cơ chế này áp dụng các quy tắc cô lập tiến trình như mô tả trong phần Cô lập tiến trình để tạo một hộp cát, trong đó APEX được gắn dưới dạng một phân vùng chuyên dụng trong /apex.
• Lý do giúp tăng cường bảo mật: Mỗi dịch vụ đều có thư mục người dùng và dữ liệu riêng, hạn chế quyền truy cập trừ phi được chia sẻ rõ ràng. Bằng cách tạo một phân vùng chuyên dụng, Android thiết lập một không gian tên trình liên kết chuyên dụng, đảm bảo chỉ những thư viện được hiển thị rõ ràng mới có thể truy cập được từ các trình nền hệ thống không có đặc quyền, từ đó giảm thiểu bề mặt tấn công.

4. Khôi phục nguyên tử

• Cơ chế: APEX sử dụng thiết kế "Đang hoạt động/Dự phòng" để bật tính năng khôi phục hai vùng đệm. APEX được cài đặt sẵn tại nhà máy vẫn nằm trên phân vùng /system không thể thay đổi, trong khi các bản cập nhật nằm trên phân vùng /data có thể thay đổi.
• Lý do an toàn hơn: Nếu bản cập nhật không thành công hoặc có vẻ độc hại, trình nền apexd sẽ đánh dấu bản cập nhật đó là "không thành công" trong giai đoạn khởi động sớm. Hệ thống sẽ ngay lập tức hoán đổi các đường liên kết tượng trưng trở lại phân vùng /system. Quá trình khôi phục nguyên tử này giúp đảm bảo hệ thống không ở trạng thái hỏng.

Khả năng phục hồi: Phát triển an toàn bộ nhớ

Quá trình tải đã xác minh bảo vệ hệ thống khỏi các hoạt động sửa đổi từ bên ngoài, nhưng khả năng phục hồi của nền tảng cũng phụ thuộc vào cách xây dựng mã cơ bản. Đối với các thành phần mới được phát triển cho AAOS SDV, chúng tôi ưu tiên tính an toàn của bộ nhớ.

Rust là ngôn ngữ chính

AAOS SDV nhắm đến các hệ thống nhỏ có yêu cầu về khả năng cung cấp nhanh; điều này ngăn việc xây dựng trên toàn bộ ngăn xếp Android, vì vậy, chúng tôi đã giới hạn phạm vi của mình ở khung gốc. Để tạo cơ sở hạ tầng cần thiết cho một hệ thống phân tán, chúng tôi đã phát triển nhiều thành phần ngoài cơ sở hạ tầng hiện có và sử dụng Rust làm ngôn ngữ chính. Chúng tôi cũng sử dụng Rust để phát triển logic nghiệp vụ của các dịch vụ, giúp các đối tác viết phần mềm bảo mật. Theo thiết kế, Rust tận dụng các tính năng an toàn bộ nhớ để giúp ngăn chặn các loại lỗ hổng an toàn bộ nhớ phổ biến, đồng thời hỗ trợ thông lượng của nhóm khi viết mã gốc.

Distributed Trust: Network & Access Control

Xe được điều khiển bằng phần mềm cần có các hoạt động tương tác an toàn giữa các miền riêng biệt. Kiến trúc cấp phép lưới SDV của AAOS giải quyết sự phức tạp này bằng cách xác minh bằng mật mã phiên bản và tác giả của mọi điểm cuối giao tiếp.

Cấp phép thiết bị và mạng lưới

AAOS SDV Mesh thiết lập quy trình xác thực bằng cách liên kết danh tính mạng của mọi thành phần theo toán học với trạng thái thực thi nhị phân thực tế của thành phần đó. Mô hình này thay thế sự tin tưởng ngầm định vào phần mềm bằng quy trình xác minh dựa trên phần cứng.

Quy trình xác thực lưới được thiết kế để diễn ra liên tục và sử dụng mật mã. Điều này giúp ngăn chặn các trường hợp, chẳng hạn như một dịch vụ như cổng kết nối xe tin tưởng một máy ảo thông tin giải trí bị xâm phạm chỉ vì máy ảo đó có địa chỉ IP phù hợp.

Các giao thức cách ly tự động và cách ly do phần cứng thực thi giúp bảo vệ nền tảng. Các thiết bị ngang hàng trong mạng lưới SDV sử dụng quy trình xác thực và chứng thực dựa trên DICE (như được trình bày chi tiết trong phần sau) để giúp xác định và ngăn chặn việc thực thi mã trái phép hoặc can thiệp vào cấu hình.

TLS dựa trên DICE để bảo mật hoạt động giao tiếp giữa các máy ảo

Xác định danh tính của người tổ chức trong thực tế

Quy tắc vàng của DICE (Công cụ kết hợp giá trị nhận dạng thiết bị): Nếu một dòng mã trong chương trình cơ sở thay đổi (ngay cả khi chỉ là một bản cập nhật nhỏ hoặc một hành vi khai thác độc hại), thì Giá trị nhận dạng thiết bị phức hợp (CDI) được lấy ra sẽ thay đổi hoàn toàn, tạo ra một Khoá đại diện hoàn toàn khác.

DICE và TLS (Bảo mật tầng truyền tải) tích hợp để giải quyết thách thức cơ bản của kiến trúc không tin tưởng: xác thực máy đồng thời xác minh tính toàn vẹn của phần mềm.

Sự kết hợp giữa thông tin nhận dạng dựa trên phần cứng của DICE và quy trình bắt tay mã hoá của TLS cho phép máy nhận xác minh cả danh tính của phương thức gọi và trạng thái phần mềm chính xác của phương thức đó.

Chứng chỉ truyền thống chỉ chứng minh quyền sở hữu một khoá bí mật chứ không thể phát hiện hành vi can thiệp vào chương trình cơ sở. DICE giải quyết vấn đề này thông qua phân lớp khởi động đo lường:

• Bí mật thiết bị duy nhất (UDS): Một bí mật mật mã ngẫu nhiên được tạo trong quá trình sản xuất. Chỉ trình tải khởi động giai đoạn đầu mới có thể truy cập vào UDS; tất cả phần mềm và giao diện bên ngoài khác đều không thể truy cập vào UDS.
• Đo lường theo lớp (Giá trị nhận dạng thiết bị phức hợp): ROM phần cứng bắt đầu chuỗi bằng cách băm UDS bằng mã chính xác và cấu hình của lớp chương trình cơ sở tiếp theo. Thao tác này sẽ tạo một CDI, sau đó tạo chuỗi tuần tự khi mỗi lớp tiếp theo khởi động.

Các biện pháp kiểm soát quyền truy cập nghiêm ngặt sẽ điều chỉnh hoạt động tương tác của dịch vụ trong lưới SDV của AAOS. Giống như tất cả phần mềm SDV của AAOS, các chế độ kiểm soát quyền truy cập này được xác thực và tính toàn vẹn của chúng được bảo vệ ở cấp thiết bị và trên các thiết bị trong mạng lưới thông qua quy trình xác thực dựa trên DICE.

Kiểm soát quyền truy cập theo lớp

AAOS SDV áp dụng chiến lược phòng thủ theo chiều sâu để cho phép cập nhật xe linh hoạt mà không ảnh hưởng đến cơ chế truy cập. Mô hình này dựa vào hai lớp tin cậy chính:

1. Quyền ở cấp dịch vụ: Xác định các tài nguyên cụ thể mà một dịch vụ trên một máy ảo nhất định có thể truy cập hoặc hiển thị trên lưới.
2. Quyền ở cấp máy ảo: Xác định ranh giới giao tiếp giữa các máy ảo cho tất cả dịch vụ được lưu trữ trên một máy ảo cụ thể.

Mô hình này cho phép OEM cân bằng giữa tính bảo mật và khả năng cập nhật. Đối với các dịch vụ không nhạy cảm về bảo mật, chính sách cấp máy ảo cho phép cài đặt thông qua các bản cập nhật APEX gọn nhẹ thay vì triển khai lại toàn bộ máy ảo.

Ngược lại, quyền đối với các tín hiệu nhạy cảm về bảo mật phải được cố định giá trị trong mã vào mọi máy ảo. Điểm đánh đổi là việc đưa một dịch vụ nhạy cảm về bảo mật vào một máy ảo mới đòi hỏi phải cập nhật các quyền ở cấp máy ảo trên toàn hệ thống. Điều này đòi hỏi phải cập nhật tất cả máy ảo trong lưới.

Kết luận

AAOS SDV mở rộng cấu trúc bảo mật của Android để đáp ứng các yêu cầu cụ thể của ngành ô tô thông qua phương pháp bảo mật từ trong thiết kế. Bằng cách tận dụng công nghệ ảo hoá để tách biệt miền và thực thi chính sách truy cập "từ chối theo mặc định", nền tảng này thiết lập một môi trường linh hoạt cho các phương tiện được xác định bằng phần mềm. Tính toàn vẹn của mật mã được duy trì thông qua quy trình xác minh tức thời, do phần cứng thực thi đối với mã được thực thi.

Nền tảng này tích hợp các vòng đời bảo mật liên tục, từ quản lý lỗ hổng bảo mật chủ động đến xác minh danh tính dựa trên phần cứng thông qua DICE. Các biện pháp phòng vệ nhiều lớp này cho phép OEM cân bằng giữa khả năng cập nhật tính năng nâng cao với khả năng bảo mật mạnh mẽ cần thiết cho môi trường ô tô hiện đại. Bạn có thể xem thông số kỹ thuật và thông tin chi tiết về cách triển khai trên trang Tổng quan về SDV của AAOS.