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 bảo mật từ trong thiết kế. Đó 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, 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 trên blog này sẽ trình bày một số khái niệm về bảo mật.

Nền tảng: Cô lập miền

Ảo hoá để cô lập các thực thể được đồng lưu trữ

Xu hướng hiện tại là hợp nhất các Đơn vị điều khiển điện tử (ECU) thành một chip duy nhất, làm giảm khả năng cô lập bằng cách chạy nhiều miền song song.

Mặc dù các thực thể AAOS SDV cung cấp cơ chế cô lập nội bộ, nhưng thường thì bạn nên chạy các miền logic một cách độc lập. Ví dụ: một cụm và một 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 thực thể, đảm bảo rằng việc chia sẻ vẫn rõ ràng và khả năng cô lập là hành vi mặc định.

Bảo mật Android được 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 quyền riêng tư (pVM). Dòng sản phẩm 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 cô lập 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 tiến trình riêng biệt có UID riêng biệ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 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 tư thế "từ chối theo mặc định". Phương pháp 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 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, như giải thích sau trong 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 trưởng thành của Android để xác định, phân loại theo mức ưu tiên, khắc phục và tiết lộ các phát hiện về bảo mật. Vòng đời này kết hợp tính năng quét tự động liên tục, kiểm thử xâ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 theo mức ưu tiên các lỗ hổng đượ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 tiết lộ và phát hành thông qua Bản tin bảo mật Android hằng tháng, được bổ sung bằng các cuộc kiểm tra bảo mật định kỳ nghiêm ngặt và các bài đánh giá kiến trúc toàn diện để đả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 khả năng cô lập tiến trình, một nền tảng an toàn 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 để đọc các phân vùng hệ thống, sản phẩm hoặc nhà cung cấp chỉ có thể đọc, xác thực chữ ký trên mỗi lần khởi động. Điều này giúp bảo mật các thành phần hệ thống cơ bản.

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 việc thực thi mã độc hại được giảm thiểu thông qua 4 trụ cột cốt lõi: 

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

• Cơ chế: Hạt nhân Android trực tiếp lặp lại 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 lại an toàn hơn: Điều 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 giành đượ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ả các lệnh ghi.

2. Tính toàn vẹn mật mã học

• Cơ chế: Chữ ký mật mã học xác thực Cây Merkle của toàn bộ hình ảnh hệ thống tệp.
• Tại sao lại an toàn hơn: Hạt nhân sử dụng dm-verity trên 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, hạt 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ô lập nghiêm ngặt

• Cơ chế: Điều 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 riêng biệt trong /apex.
• Tại sao lại an toàn hơn: Mỗi dịch vụ 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 việc chia sẻ là rõ ràng. Bằng cách tạo một phân vùng riêng biệt, Android thiết lập một không gian tên trình liên kết riêng biệt, đảm bảo chỉ các 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, nhờ đó 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/Sao lưu" để bật khả năng khôi phục được đệm kép. APEX được flash tại 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.
• Tại sao lại an toàn hơn: Nếu một 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. Quá 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ớ

Quá trình tải đã xác minh giúp bảo vệ hệ thống khỏi việc 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 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 cho 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 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à áp 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 an toàn. Theo thiết kế, Rust tận dụng các tính năng an toàn cho bộ nhớ để giúp ngăn chặn các lớp lỗ hổng an toàn cho bộ nhớ phổ biến, đồng thời hỗ trợ thông lượng của nhóm khi viết mã gốc.

Tin cậy phân tán: Kiểm soát mạng và quyền truy cập

Các 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 bị cô lập. Kiến trúc cung cấp lưới AAOS SDV giải quyết sự phức tạp này bằng cách xác minh phiên bản và tác giả của mọi điểm cuối giao tiếp bằng mật mã học.

Cung cấp thiết bị và lưới

Lưới AAOS SDV thiết lập quy trình xác thực bằng cách liên kế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ế độ tin cậy ngầm định của 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ế để liên tục và mật mã học. Điều này 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.

Khả năng cô lập được thực thi bằng phần cứng và các giao thức kiểm dịch tự động giúp bảo mật nền tảng. Các thiết bị ngang hàng trong lưới SDV sử dụng quy trình xác thực và chứng thực dựa trên DICE, như 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 giao tiếp giữa các VM

Đặt danh tính máy chủ vào thực tế

Quy tắc vàng của DICE (Công cụ tạo mã 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ả bản cập nhật nhỏ hoặc khai thác độc hại), Mã nhận dạng thiết bị tổng hợp (CDI) được dẫn xuất sẽ thay đổi hoàn toàn, tạo ra 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à 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 bí mật; chúng 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 lớp khởi động được đo lường:

• Bí mật thiết bị duy nhất (UDS): Một bí mật mật mã học 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.
• Các phép đo theo lớp (Mã nhận dạng thiết bị tổng hợp): ROM phần cứng khởi tạo chuỗi bằng cách băm UDS với 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 đó liên kết tuần tự khi mỗi lớp tiếp theo khởi động.

Các chế độ 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 giữa các dịch vụ trong lưới AAOS SDV. Giống như tất cả phần mềm AAOS SDV, 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 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ủ theo chiều sâu để cho phép cập nhật xe động mà không ảnh hưởng đến 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 các tài nguyên cụ thể mà một dịch vụ trên một VM nhất định có thể truy cập hoặc hiển thị trên lưới.
2. Quyền ở cấp VM: Xác định ranh giới giao tiếp giữa các VM cho tất cả các dịch vụ được lưu trữ trên một VM 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 ở cấp VM 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, các 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 VM. Điểm đánh đổi 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 phải cập nhật tất cả các VM trong lưới.

Kết luận

AAOS SDV mở rộng kiến trúc bảo mật của Android để giải quyết các yêu cầu cụ thể về ô 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á để cô lập miền và thực thi các 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 xe được xác định bằng phần mềm. Tính toàn vẹn mật mã học được duy trì thông qua quy trình xác minh mã được thực thi ngay lập tức, được thực thi bằng phần cứng.

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 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 thủ 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ề cách triển khai có trên trang Tổng quan về AAOS SDV.