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ế an toàn. Đó 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 đã được chứng minh trên thị trường hiện có, tận dụng các công nghệ ảo hoá như Cuttlefish. Mặc dù 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, nhưng bài đăng này trên blog sẽ trình bày một số khái niệm về bảo mật.

Nền tảng: Tách biệt miền

Ảo hoá để cô lập các phiên bản được lưu trữ cùng nhau

Xu hướng hiện tại là hợp nhất các Bộ điều khiển điện tử (ECU) thành một chip duy nhất, giúp giảm sự cô lập 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ế cách ly nội bộ, nhưng bạn nên chạy các miền logic một cách độc lập. Ví dụ: cụm 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 song song nhiều phiên bản, đảm bảo rằng việc chia sẻ vẫn rõ ràng và cách ly là hành vi mặc định.

Bảo mật Android được kế thừa

AAOS SDV được phát triển từ Microdroid, một phiên bản Android tối giản được tối ưu hoá cho các máy ảo riêng tư (pVM). Dòng dõi này cung cấp cho các kỹ sư nền tảng Android những 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 cách ly dựa trên Mã nhận dạng người dùng (UID) của Android để thiết lập một 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 với một UID duy nhất để quản lý quyền truy cập, thư mục dữ liệu và các 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 tuyệt đối 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 quá cho phép. Chúng tôi áp dụng chiến lược tương tự cho hệ thống quyền giao tiếp của mình, như sẽ giải thích ở phần sau của bài viết này.

Quản lý lỗ hổng đã được chứng minh

AAOS SDV tích hợp cơ sở hạ tầng quản lý lỗ hổng và phản hồi bảo mật hoàn chỉnh của Android để xác định, phân loại theo mức độ ưu tiên, 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 thử 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 của Android. Nhóm bảo mật sẽ phân loại các lỗ hổng đã 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 phối hợp các chính sách công bố và phát hành thông qua Bản tin bảo mật Android hằng tháng, đồng thời bổ sung các hoạt động kiểm tra bảo mật định kỳ nghiêm ngặt và các hoạt động đánh giá toàn diện về cấu trúc để đảm bảo khả năng 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 2 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 chỉ đọc của hệ thống, sản phẩm hoặc nhà cung cấp. Các phân vùng này sẽ xác thực chữ ký trong mỗi lần 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 SDV AAOS, 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 thông qua 4 trụ cột cốt lõi: 

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 một thiết bị lưu trữ thô bằng cách sử dụng vòng lặp chỉ đọc, gắn tệp này bằng cờ MS_RDONLY nghiêm ngặt.
• Lý do an toàn hơn: Phương thức này không để lộ đườ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 sẽ từ chối mọi lệnh ghi.

2. Tính toàn vẹn 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 an toàn hơn: Nhân sử dụng dm-verity cho mỗi khối để xác minh chữ ký cho mọi khối dữ liệu 4KB ngay lập tức. Nếu kẻ tấn công sửa đổi một khối thô trên bộ nhớ flash, thì nhân sẽ phát hiện thấy sự không khớp băm 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, với 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ụ sẽ nhận đượ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ó sự 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ỉ các thư viện được hiển thị rõ ràng mới có thể truy cập từ các trình nền hệ thống không có đặc quyền, do đó 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" để cho phép khôi phục có bộ nhớ đệm kép. APEX được nạp từ nhà máy vẫn nằm trên phân vùng /system bất biến, 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 giúp quá trình này 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 quá trình 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. Quy trình khôi phục nguyên tử này giúp đảm bảo hệ thống không bị hỏng.

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

Tính năng tải đã xác minh giúp bảo vệ hệ thống khỏi bị sửa đổi 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 tạo 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ề tính sẵn có nhanh chóng; điều này ngăn việc xây dựng trên ngăn xếp Android đầy đủ, vì vậy, chúng tôi đã giới hạn phạm vi của mình trong khuôn khổ 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 về bộ nhớ để giúp ngăn chặn các lớp lỗ hổng bảo mật bộ nhớ phổ biến, đồng thời hỗ trợ hiệu suất của nhóm khi viết mã gốc.

Distributed Trust: Kiểm soát quyền truy cập và mạng

Xe được xác định bằng phần mềm yêu cầu các hoạt động tương tác an toàn giữa các miền biệt lập. Cấu trúc cung cấ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 theo phương thức mã hoá 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

Lưới SDV AAOS thiết lập quy trình xác thực bằng cách liên kết về mặt toán học danh tính mạng của mọi thành phần với trạng thái thực thi nhị phân thực tế. Mô hình này thay thế niềm tin 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.

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

Các giao thức cách ly tự động và cách ly bắt buộc bằng phần cứng giúp bảo mật nền tảng. Các thiết bị ngang hàng trong mạng lưới SDV sử dụng quy trình chứng thực và xác 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 hành vi thực thi mã trái phép hoặc giả mạ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 VM

Xác định danh tính của máy chủ lưu trữ trong thực tế

Quy tắc vàng của DICE (Công cụ tạo 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 lỗ hổng bảo mật độc hại), thì Giá trị nhận dạng thiết bị kết hợp (CDI) được tạo sẽ thay đổi hoàn toàn, tạo ra một Khoá bí danh 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 cậy: xác thực một 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 tính năng nhận dạng dựa trên phần cứng của DICE và quy trình bắt tay được mã hoá của TLS cho phép máy nhận xác minh cả danh tính của người gọi và trạng thái phần mềm chính xác của người gọi.

Các chứng chỉ truyền thống chỉ chứng minh quyền sở hữu một khoá bí mật; chúng không thể phát hiện hành vi giả mạ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:

• Khoá bí mật duy nhất của thiết bị (UDS): Khoá 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 tiên 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ị kết hợp): ROM phần cứng khởi tạo 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 phần mềm cơ sở tiếp theo. Thao tác này sẽ tạo một CDI, sau đó sẽ liên kết 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 chi phối các hoạt động tương tác dịch vụ trong mạng lưới SDV của AAOS. Giống như mọi phần mềm SDV AAOS, các chế độ kiểm soát quyền truy cập này đều đượ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 sử dụng chiến lược phòng thủ chuyên sâu để cho phép cập nhật xe linh hoạt mà không ảnh hưởng đến các cơ chế truy cập. Mô hình này dựa trên 2 lớp tin cậy chính:

1. Quyền ở cấp dịch vụ: Xác định những 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 toàn bộ 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ả cá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 các 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, các chính sách cho phép ở cấp VM sẽ 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ộ VM.

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 mã hoá cứng vào mọi VM. Nhược điểm là việc giới thiệu một dịch vụ nhạy cảm về bảo mật cho một VM mới đòi hỏi phải cập nhật hệ thống quyền ở cấp VM trên toàn hệ thống. Điều này đòi hỏi bạn phải cập nhật tất cả các VM 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 tính năng ả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 tạo ra 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 mật mã được duy trì thông qua quy trình xác minh mã đã thực thi theo thời gian thực và do phần cứng 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ừ hoạt động 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. Những biện pháp bảo vệ nhiều lớp này cho phép các OEM cân bằng khả năng cập nhật tính năng nâng cao với tính bảo mật mạnh mẽ cần thiết cho môi trường ô tô hiện đại. Thông số kỹ thuật và thông tin chi tiết về việc triển khai có trên trang Tổng quan về SDV trên AAOS.