Hướng dẫn này mô tả các phương pháp hay nhất do Google đề xuất để áp dụng các bản vá bảo mật được Bộ kiểm tra khả năng tương thích Android (CTS) đánh giá. Nó dành cho các nhà sản xuất thiết bị OEM (nhà sản xuất) tương thích với Android sẽ được hỗ trợ lâu hơn ba năm như xe cộ, TV, hộp giải mã tín hiệu và thiết bị gia dụng. Hướng dẫn này không dành cho người dùng cuối (ví dụ: chủ phương tiện).
Lời cảm ơn và tuyên bố từ chối trách nhiệm
Hướng dẫn này không ràng buộc về mặt pháp lý hoặc hợp đồng với Google hoặc các nhà sản xuất khác và không nhằm mục đích trở thành một bộ yêu cầu. Đúng hơn, hướng dẫn này là một công cụ hỗ trợ giảng dạy mô tả các phương pháp thực hành được khuyến nghị.
Nhận xét
Hướng dẫn này không nhằm mục đích toàn diện; các sửa đổi bổ sung được lên kế hoạch. Gửi phản hồi tới nhà sản xuất-guide-android@googlegroups.com.
Bảng chú giải
| Thuật ngữ | Sự định nghĩa |
|---|---|
| ACC | Cam kết tương thích với Android. Trước đây được gọi là Thỏa thuận chống phân mảnh Android (AFA). |
| AOSP | Dự án mã nguồn mở Android |
| ASB | Bản tin bảo mật Android |
| BSP | Gói hỗ trợ bảng |
| CDD | Tài liệu định nghĩa khả năng tương thích |
| CTS | Bộ kiểm tra khả năng tương thích |
| FOTA | phần mềm qua mạng |
| GPS | Hệ thống định vị toàn cầu |
| MISRA | Hiệp hội độ tin cậy phần mềm công nghiệp ô tô |
| NIST | Viện Tiêu chuẩn và Công nghệ |
| OB | chẩn đoán trên tàu ( OBD-II là một cải tiến so với Obd-I cả về khả năng và tiêu chuẩn hóa ) |
| OEM | Nhà sản xuất thiết bị gốc |
| hệ điều hành | hệ điều hành |
| SEI | Viện kỹ thuật phần mềm |
| SoC | hệ thống trên chip |
| SOP | bắt đầu sản xuất |
| SPL | Cấp độ bản vá bảo mật |
| TPMS | lốp xe Hệ thống giám sát áp suất |
Giới thiệu về hệ điều hành Android
Android là một kho phần mềm đầy đủ dựa trên Linux, mã nguồn mở, được thiết kế cho nhiều loại thiết bị và kiểu dáng. Kể từ lần phát hành đầu tiên vào năm 2008, Android đã trở thành Hệ điều hành (HĐH) phổ biến nhất, hỗ trợ hơn 1,4 tỷ thiết bị trên toàn thế giới (2016). Khoảng 67% trong số các thiết bị đó sử dụng Android 5.0 (Lollipop) hoặc mới hơn tính đến tháng 3 năm 2017 (có nhiều số liệu gần đây hơn trên Bảng điều khiển Android ). Trong khi phần lớn thiết bị là điện thoại di động và máy tính bảng, Android đang phát triển trên đồng hồ thông minh, TV và thiết bị thông tin giải trí trên ô tô (IVI).
Số lượng ứng dụng Android có sẵn trong Cửa hàng Google Play đã đạt hơn 2,2 triệu (2016). Việc phát triển ứng dụng Android được hỗ trợ bởi chương trình Tương thích Android, chương trình này xác định một bộ yêu cầu thông qua Tài liệu định nghĩa tương thích (CDD) và cung cấp các công cụ kiểm tra thông qua Bộ kiểm tra tương thích (CTS) . Các chương trình tương thích với Android đảm bảo mọi ứng dụng Android đều có thể chạy trên mọi thiết bị tương thích với Android có hỗ trợ các tính năng cần thiết cho ứng dụng.
Google thường xuyên phát hành các phiên bản hệ điều hành mới, bản cập nhật bảo mật hệ điều hành và thông tin về các lỗ hổng được phát hiện. Bản tin bảo mật Android cần được các nhà sản xuất xem xét về khả năng áp dụng các bản cập nhật này cho các sản phẩm được hỗ trợ bởi hệ điều hành Android. Để xem xét về tính bảo mật, khả năng tương thích và hệ thống xây dựng của Android, hãy xem phần sau:
- Bảo mật thiết bị Android
- Tài nguyên và cập nhật bảo mật
- Bộ kiểm tra khả năng tương thích
- Tên mã, thẻ và số bản dựng
Giới thiệu về phương tiện được kết nối (sản phẩm có tuổi thọ cao theo tiêu chuẩn)
Các phương tiện bắt đầu được kết nối với sự ra đời của đài AM vào những năm 1920. Từ đó, số lượng kết nối vật lý và không dây bên ngoài bắt đầu tăng lên khi các cơ quan quản lý và nhà sản xuất ô tô chuyển sang sử dụng thiết bị điện tử để dễ dàng chẩn đoán và bảo trì (ví dụ: cổng Obd-II), cải thiện độ an toàn (ví dụ: TPMS) và đáp ứng các mục tiêu tiết kiệm nhiên liệu. . Làn sóng kết nối tiếp theo đã giới thiệu các tính năng tiện lợi cho người lái như ra vào không cần chìa khóa từ xa, hệ thống viễn thông và các tính năng thông tin giải trí tiên tiến như Bluetooth, Wi-Fi và trình chiếu trên điện thoại thông minh. Ngày nay, các cảm biến và kết nối tích hợp (ví dụ: GPS) hỗ trợ các hệ thống lái xe bán tự động và an toàn.
Khi số lượng kết nối phương tiện tăng lên thì diện tích bề mặt tấn công của phương tiện cũng tăng theo. Các kết nối mang theo một loạt các mối lo ngại về an ninh mạng tương tự như đối với thiết bị điện tử tiêu dùng. Tuy nhiên, mặc dù việc khởi động lại, cập nhật bản vá hàng ngày và các hành vi không giải thích được là tiêu chuẩn đối với thiết bị điện tử tiêu dùng nhưng chúng lại không nhất quán đối với các sản phẩm có hệ thống quan trọng về an toàn như ô tô.
Các nhà sản xuất phải thực hiện cách tiếp cận chủ động để đảm bảo tình trạng an ninh và an toàn liên tục của sản phẩm tại hiện trường. Tóm lại, nhà sản xuất phải nhận thức được các lỗ hổng bảo mật đã biết trong sản phẩm và thực hiện phương pháp tiếp cận dựa trên rủi ro để giải quyết chúng.
Đảm bảo an ninh lâu dài
Một phương tiện được kết nối thường có một hoặc nhiều bộ điều khiển điện tử (ECU) bao gồm nhiều thành phần phần mềm như hệ điều hành, thư viện, tiện ích, v.v. Các nhà sản xuất nên theo dõi các thành phần đó và xác định các lỗ hổng đã được công bố bằng phân tích chủ động, bao gồm:
- Thường xuyên đánh giá sản phẩm dựa trên cơ sở dữ liệu về Lỗ hổng và Phơi nhiễm Thông thường (CVE).
- Thu thập thông tin tình báo về các lỗi bảo mật liên quan đến sản phẩm.
- Kiểm tra an ninh.
- Tích cực phân tích Bản tin bảo mật Android.
Ví dụ về các bản cập nhật bản vá bảo mật và hệ điều hành (IVI chạy Android):
Hình 1. Mẫu triển khai bản cập nhật bảo mật và hệ điều hành chính trong suốt vòng đời của xe.
| # | Bước chân | Các hoạt động |
|---|---|---|
① | Chi nhánh phát triển | Nhà sản xuất chọn phiên bản Android (Android X). Trong ví dụ này, "Android X" trở thành nền tảng cho những gì sẽ được vận chuyển trên xe hai năm trước khi bắt đầu sản xuất (SOP) lần đầu. |
| ② | Ra mắt lần đầu | Vài tháng trước khi Android X trở thành phiên bản hệ điều hành đầu tiên được cung cấp trong sản phẩm, các bản cập nhật bảo mật được lấy từ Bản tin bảo mật Android (ASB) và các nguồn có thể khác được nhà sản xuất coi là có giá trị. y2 = Bản tin bảo mật thứ hai dành cho phiên bản X của Android, được nhà sản xuất áp dụng (được chuyển ngược lại) cho Android X. Bản cập nhật này được cung cấp trong sản phẩm và đồng hồ sản xuất bắt đầu tích tắc vào Năm 0 với Android X.y2. Trong ví dụ này, nhà sản xuất đã đưa ra quyết định không phát hành bản phát hành hàng năm Android X+1 mới hơn. Lý do gửi bản phát hành gần đây nhất bao gồm thêm các tính năng mới, giải quyết các lỗ hổng bảo mật mới và/hoặc gửi các dịch vụ của Google hoặc bên thứ ba yêu cầu phiên bản Android mới hơn. Lý do không muốn vận chuyển bản phát hành gần đây nhất là thiếu thời gian vốn có cho quá trình phát triển và ra mắt phương tiện cần thiết để tích hợp, kiểm tra và xác nhận các thay đổi, bao gồm cả việc tuân thủ tất cả các yêu cầu quy định và chứng nhận. |
| ③ | Cập nhật hệ điều hành đầy đủ | Sau SOP, nhà sản xuất phát hành bản cập nhật hệ điều hành Android X+2, đây là hai bản phát hành Android sau phiên bản được sử dụng cho sản phẩm đầu tiên (Android X0). Các bản cập nhật bảo mật ASB có sẵn cho cấp độ API (kể từ ngày xuất bản), do đó, bản cập nhật sẽ xuất hiện dưới dạng X+2.y0 khoảng 1,25 năm sau SOP. Bản cập nhật hệ điều hành này có thể tương thích hoặc không tương thích với các sản phẩm hiện có. Nếu đúng như vậy, một kế hoạch có thể được tạo ra để cập nhật các phương tiện đã triển khai. Trừ khi có các thỏa thuận kinh doanh khác, quyết định thực hiện bản cập nhật hệ điều hành đầy đủ hoàn toàn theo quyết định của nhà sản xuất. |
| ④ | Cập nhật bảo mật | Hai năm sau vòng đời sản xuất của xe, nhà sản xuất đã vá lỗi hệ điều hành Android X+2. Quyết định này dựa trên đánh giá rủi ro của nhà sản xuất. Nhà sản xuất chọn bản cập nhật bảo mật ASB thứ ba cho bản phát hành X+2 làm cơ sở cho bản cập nhật. Các sản phẩm nhận được bản cập nhật bảo mật hiện ở mức (X+2.y3) OS + Cấp bản vá bảo mật Android. Mặc dù nhà sản xuất có thể chọn các bản vá bảo mật riêng lẻ từ bất kỳ ASB riêng lẻ nào nhưng họ phải khắc phục tất cả các vấn đề bắt buộc trong bản tin để sử dụng cấp bản vá bảo mật Android (SPL) được liên kết với bản tin (ví dụ: 05-02-2017). Trách nhiệm của nhà sản xuất là thực hiện việc đưa ra backport và bảo mật cho sản phẩm được hỗ trợ. |
| ⑤ | Cập nhật hệ điều hành đầy đủ | Lặp lại bước 3 (Cập nhật hệ điều hành đầy đủ), bản cập nhật hệ điều hành đầy đủ thứ hai sẽ đưa sản phẩm lên Android X+4, sau ba năm kể từ vòng đời sản xuất của xe. Nhà sản xuất hiện đang cân bằng các yêu cầu phần cứng mới hơn của phiên bản Android gần đây với phần cứng trong sản phẩm và người dùng sẽ được hưởng lợi từ hệ điều hành Android được cập nhật. Nhà sản xuất phát hành bản cập nhật không có bản cập nhật bảo mật, vì vậy sản phẩm hiện ở cấp (X+4.y0) OS + Bản vá bảo mật Android. Trong ví dụ này, do những hạn chế về phần cứng, X+4 là phiên bản Android chính cuối cùng sẽ được cung cấp cho sản phẩm này, mặc dù tuổi thọ dự kiến hơn 6 năm của xe vẫn yêu cầu hỗ trợ bảo mật. |
| ⑥ | Cập nhật bảo mật | Lặp lại bước 4 (Cập nhật bảo mật). Nhà sản xuất có nhiệm vụ lấy các bản cập nhật bảo mật ASB từ phiên bản Android mới hơn (X+6) và chuyển một số hoặc tất cả các bản cập nhật đó trở lại Android X+4. Trách nhiệm của nhà sản xuất là hợp nhất, tích hợp và thực hiện cập nhật (hoặc ký hợp đồng với bên thứ ba). Ngoài ra, nhà sản xuất nên lưu ý rằng các vấn đề bảo mật trong các phiên bản Android không còn được hỗ trợ sẽ không được đề cập trong ASB. |
| ⑦ | Cập nhật bảo mật | Tám năm trong vòng đời sản xuất của xe, bốn bản phát hành Android kể từ bản cập nhật hệ điều hành cuối cùng ở Bước 5 (Cập nhật hệ điều hành đầy đủ) và mười năm kể từ khi Android X được chỉ định, gánh nặng quản lý và cung cấp các bản vá bảo mật hoàn toàn thuộc về nhà sản xuất. những phiên bản cũ hơn ba năm kể từ bản phát hành công khai ở cấp độ API. |
Các biện pháp bảo mật tốt nhất
Để làm cho việc thỏa hiệp bảo mật trở nên khó khăn hơn, Google khuyến nghị và sử dụng các phương pháp hay nhất thường được chấp nhận về bảo mật và công nghệ phần mềm, như được mô tả trong Triển khai bảo mật .
Nguyên tắc bảo mật
Các phương pháp được đề xuất để bảo mật bao gồm:
- Sử dụng các phiên bản mới nhất của thư viện bên ngoài và các thành phần nguồn mở.
- Không đưa chức năng gỡ lỗi xâm nhập vào các phiên bản phát hành của HĐH.
- Loại bỏ chức năng không sử dụng (để giảm bề mặt tấn công không cần thiết).
- Sử dụng nguyên tắc đặc quyền tối thiểu và các phương pháp hay nhất khác để phát triển ứng dụng Android .
Nguyên tắc phát triển phần mềm
Các phương pháp được đề xuất để phát triển phần mềm an toàn trong vòng đời của hệ thống bao gồm:
- Thực hiện mô hình hóa mối đe dọa để xếp hạng và xác định tài sản, mối đe dọa và các biện pháp giảm thiểu tiềm năng.
- Thực hiện xem xét kiến trúc/thiết kế để đảm bảo thiết kế an toàn và hợp lý.
- Thực hiện đánh giá mã thường xuyên để xác định các mẫu chống lỗi và lỗi càng sớm càng tốt.
- Thiết kế, triển khai và chạy thử nghiệm đơn vị bảo hiểm mã cao, bao gồm:
- Kiểm tra chức năng (bao gồm các trường hợp kiểm tra tiêu cực)
- Kiểm tra hồi quy thường xuyên (để đảm bảo các lỗi đã sửa không xuất hiện trở lại)
- Kiểm thử Fuzz (là một phần của bộ kiểm thử đơn vị)
- Sử dụng các công cụ phân tích mã nguồn tĩnh (scan-build, lint, v.v.) để xác định các vấn đề tiềm ẩn.
- Sử dụng các công cụ phân tích mã nguồn động, chẳng hạn như addressSanitizer, UndeedBehaviorSanitizer và FORTIFY_SOURCE (dành cho các thành phần gốc) để xác định và giảm thiểu các sự cố tiềm ẩn trong quá trình phát triển hệ thống.
- Có chiến lược quản lý mã nguồn phần mềm và cấu hình/phiên bản phát hành.
- Có chiến lược quản lý bản vá để tạo và triển khai các bản vá phần mềm.
Chính sách backport bảo mật
Google hiện cung cấp hỗ trợ tích cực cho các bản báo cáo ngược về bảo mật của các lỗ hổng bảo mật được phát hiện và báo cáo trong ba (3) năm kể từ khi phát hành công khai ở cấp độ API . Hỗ trợ tích cực bao gồm những điều sau đây:
- Nhận và điều tra các báo cáo về lỗ hổng.
- Tạo, kiểm tra và phát hành các bản cập nhật bảo mật.
- Cung cấp các bản phát hành định kỳ của các bản cập nhật bảo mật và thông tin chi tiết về bản tin bảo mật.
- Thực hiện đánh giá mức độ nghiêm trọng theo hướng dẫn đã được thiết lập.
Sau ba năm kể từ ngày phát hành công khai ở cấp độ API, Google khuyến nghị các nguyên tắc sau:
- Sử dụng bên thứ ba (chẳng hạn như nhà cung cấp SoC hoặc nhà cung cấp hạt nhân) để hỗ trợ backport cho các bản cập nhật bảo mật hệ điều hành cũ hơn ba năm kể từ khi phát hành API.
- Sử dụng bên thứ ba để thực hiện đánh giá mã bằng cách sử dụng ASB được cung cấp công khai. Mặc dù ASB xác định các lỗ hổng cho phiên bản hiện được hỗ trợ nhưng nhà sản xuất có thể sử dụng thông tin được cung cấp để so sánh các bản cập nhật mới phát hành với các phiên bản trước đó. Dữ liệu này có thể được sử dụng để thực hiện phân tích tác động và có khả năng tạo ra các bản vá tương tự cho các phiên bản hệ điều hành cũ hơn ba năm kể từ khi phát hành API.
- Khi thích hợp, hãy tải các bản cập nhật bảo mật lên Dự án mã nguồn mở Android (AOSP).
- Nhà sản xuất phải phối hợp xử lý các bản cập nhật bảo mật cho mã dành riêng cho nhà cung cấp (ví dụ: mã dành riêng cho thiết bị).
- Nhà sản xuất nên tham gia nhóm thông báo Xem trước đối tác Bản tin bảo mật Android NDA (yêu cầu ký kết các thỏa thuận pháp lý như NDA dành cho nhà phát triển). Các bản tin nên bao gồm:
- Thông báo
- Tóm tắt các vấn đề theo cấp độ bản vá, bao gồm CVE và mức độ nghiêm trọng
- Chi tiết về lỗ hổng khi thích hợp
Tài liệu tham khảo bổ sung
Để biết hướng dẫn về thực hành phát triển phần mềm và mã hóa an toàn, hãy tham khảo tài liệu sau:
- Hiệp hội Độ tin cậy Phần mềm Công nghiệp Ô tô (MISRA) .
- Các công cụ và phương pháp của Viện Kỹ thuật Phần mềm (SEI) .
- Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST).
Thực hành sản phẩm được đề xuất
Google khuyến khích sử dụng các phương pháp được đề xuất sau đây.
Hướng dẫn khởi chạy chung
Thông thường, mọi sản phẩm được kết nối đều nên ra mắt phiên bản hệ điều hành mới nhất và nhà sản xuất nên cố gắng sử dụng phiên bản hệ điều hành mới nhất trước khi tung ra sản phẩm. Mặc dù việc khóa phiên bản là cần thiết để tăng cường độ ổn định trước khi thử nghiệm và xác thực nhưng nhà sản xuất phải cân bằng độ ổn định của sản phẩm đạt được từ các phiên bản hệ điều hành cũ hơn với các phiên bản hệ điều hành mới hơn có ít lỗ hổng bảo mật hơn được biết đến và các biện pháp bảo vệ nâng cao.
Các hướng dẫn được đề xuất bao gồm:
- Do thời gian phát triển vốn có của quá trình phát triển xe kéo dài nên các nhà sản xuất có thể cần tung ra phiên bản hệ điều hành n-2 trở lên.
- Duy trì sự tuân thủ với Khả năng tương thích của Android cho từng phiên bản hệ điều hành Android được phát hành bằng chiến dịch qua mạng (OTA).
- Triển khai sản phẩm Android Firmware-over-the-air (FOTA) - có khả năng cập nhật nhanh chóng, thân thiện với khách hàng. FOTA phải được thực hiện bằng cách sử dụng các biện pháp bảo mật tốt nhất như ký mã và kết nối TLS giữa sản phẩm và bộ phận hỗ trợ CNTT.
- Gửi các lỗ hổng bảo mật Android được xác định độc lập cho nhóm Bảo mật Android.
Lưu ý: Google đã dự tính loại thiết bị hoặc thông báo theo ngành cụ thể trong Bản tin bảo mật Android. Tuy nhiên, vì Google không biết hạt nhân, trình điều khiển hoặc chipset cho một thiết bị nhất định (xe, TV, thiết bị đeo, điện thoại, v.v.) nên Google không có cách xác định nào để gắn nhãn bất kỳ vấn đề bảo mật cụ thể nào cho một loại thiết bị .
Nguyên tắc chu kỳ sản phẩm
Nhà sản xuất nên cố gắng hết sức để sử dụng phiên bản hệ điều hành mới nhất hoặc các bản cập nhật bảo mật cho phiên bản đang sử dụng trong quá trình cải tiến chu kỳ sản phẩm. Cập nhật có thể được thực hiện trong quá trình cập nhật sản phẩm định kỳ hoặc thực hiện các bản sửa lỗi nóng để giải quyết các vấn đề về chất lượng và/hoặc các vấn đề khác. Các phương pháp được đề xuất bao gồm:
- Tạo một kế hoạch để giải quyết các bản cập nhật trình điều khiển, kernel và giao thức.
- Sử dụng một phương pháp thích hợp trong ngành để cung cấp thông tin cập nhật cho các phương tiện được triển khai.
Tài liệu Định nghĩa Tương thích (CDD)
Tài liệu Định nghĩa Tương thích (CDD) mô tả các yêu cầu để một thiết bị được coi là tương thích với Android. CDD được công khai và sẵn có cho mọi người; bạn có thể tải xuống các phiên bản CDD từ Android 1.6 lên phiên bản mới nhất từ source.android.com .
Việc đáp ứng các yêu cầu này đối với một sản phẩm bao gồm các bước cơ bản sau:
- Đối tác ký Cam kết tương thích Android (ACC) với Google. Sau đó, Tư vấn giải pháp kỹ thuật (TSC) sẽ được chỉ định làm người hướng dẫn.
- Đối tác hoàn tất quá trình đánh giá CDD cho phiên bản hệ điều hành Android của sản phẩm.
- Đối tác chạy và gửi kết quả CTS (được mô tả bên dưới) cho đến khi kết quả được chấp nhận đối với Khả năng tương thích của Android.
Bộ kiểm tra khả năng tương thích (CTS)
Công cụ kiểm tra Bộ kiểm tra tương thích (CTS) xác minh việc triển khai sản phẩm tương thích với Android và có bao gồm các bản vá bảo mật mới nhất hay không. CTS là công khai, mã nguồn mở và có sẵn cho tất cả mọi người; bạn có thể tải xuống các phiên bản CTS từ Android 1.6 lên phiên bản mới nhất từ source.android.com .
Mỗi bản dựng phần mềm Android được phát hành ra công chúng (hình ảnh cài đặt tại nhà máy và bản cập nhật tại hiện trường) phải chứng minh Khả năng tương thích với Android thông qua kết quả CTS. Ví dụ: nếu thiết bị chạy Android 7.1 thì phiên bản tương ứng mới nhất của CDD 7.1 và CTS 7.1 sẽ được tham chiếu khi tạo và thử nghiệm hình ảnh bản dựng có mục đích phát hành. Các nhà sản xuất được khuyến khích sử dụng CTS sớm và thường xuyên để xác định và khắc phục sự cố.
Quy trình làm việc của CTS
Quy trình làm việc của CTS bao gồm việc thiết lập môi trường thử nghiệm, chạy thử nghiệm, diễn giải kết quả và hiểu mã nguồn CTS. Các hướng dẫn sau đây nhằm mục đích giúp người dùng CTS (ví dụ: nhà phát triển, nhà sản xuất) sử dụng CTS một cách hiệu quả và hiệu quả.
- Chạy thử nghiệm thường xuyên . CTS được thiết kế như một công cụ tự động tích hợp vào hệ thống xây dựng của bạn. Chạy CTS thường xuyên có thể giúp bạn tìm ra lỗi nhanh chóng và sớm khi xảy ra hiện tượng xuống cấp hoặc hồi quy phần mềm.
- Tải xuống và kiểm tra mã nguồn CTS . Mã nguồn CTS đầy đủ là phần mềm nguồn mở mà bất kỳ ai cũng có thể tải xuống và sử dụng (mã nguồn đã tải xuống hoàn toàn có thể xây dựng và chạy được). Khi thử nghiệm thất bại trên thiết bị, việc kiểm tra phần liên quan của mã nguồn có thể giúp bạn xác định lý do.
- Nhận CTS mới nhất . Các bản phát hành Android mới có thể cập nhật CTS với các bản sửa lỗi, cải tiến và thử nghiệm mới. Kiểm tra Tải xuống CTS thường xuyên và cập nhật chương trình CTS của bạn nếu cần. Nhà sản xuất và Google sẽ đồng ý về việc phiên bản CTS được phép ra mắt sản phẩm vì sản phẩm phải bị đóng băng tại một thời điểm nào đó trong khi CTS tiếp tục được làm mới.
Vượt qua CTS
Đối với sản phẩm Tương thích với Android, Google đảm bảo kết quả kiểm tra CTS của thiết bị và Trình xác minh CTS báo cáo kết quả kiểm tra đều có thể chấp nhận được. Về nguyên tắc, tất cả các bài kiểm tra đều phải vượt qua. Tuy nhiên, thử nghiệm không thành công vì những lý do khác ngoài việc thiết bị không tuân thủ các yêu cầu về Khả năng tương thích của Android sẽ được Google xem xét. Trong suốt quá trình này:
- Nhà sản xuất cung cấp cho Google các bản vá CTS được đề xuất, xác nhận bản vá và các biện minh để chứng minh lập luận.
- Google kiểm tra tài liệu đã gửi và nếu được chấp nhận, Google sẽ cập nhật các bài kiểm tra CTS có liên quan để thiết bị có thể vượt qua trong bản sửa đổi CTS tiếp theo.
Nếu thử nghiệm CTS đột nhiên thất bại sau khi áp dụng bản vá bảo mật, nhà sản xuất phải sửa đổi bản vá đó để không phá vỡ tính tương thích HOẶC chứng minh rằng thử nghiệm đó sai và đưa ra cách khắc phục cho thử nghiệm (như mô tả ở trên).
CTS vẫn mở để xem xét các bản sửa lỗi thử nghiệm. Ví dụ: Android 4.4 tiếp tục chấp nhận các bản sửa lỗi (xem https://android-review.googlesource.com/#/c/273371/ ).
Các câu hỏi thường gặp (FAQ)
Câu hỏi: Ai chịu trách nhiệm áp dụng các bản cập nhật bảo mật cho việc triển khai cụ thể của Android?
Trả lời: Nhà sản xuất trực tiếp cung cấp thiết bị phải chịu trách nhiệm. Tổ chức này không phải là Google, công ty xuất bản các bản cập nhật bảo mật trong AOSP chứ không phải cho một thiết bị cụ thể (chẳng hạn như ô tô).
H: Google xử lý các vấn đề bảo mật trong Android như thế nào?
Đáp: Google liên tục điều tra các vấn đề và phát triển các bản sửa lỗi tiềm năng mà Google cung cấp cho tất cả các cấp API được hỗ trợ như một phần của quy trình cập nhật bảo mật thường xuyên. Kể từ tháng 8 năm 2015, Google đã duy trì nhịp độ xuất bản đều đặn các bản tin và liên kết tới các bản cập nhật lên source.android.com ; Google cũng xuất bản các bản cập nhật bảo mật như một phần của các bản phát hành hệ điều hành chính. Xem thêm Chính sách backport bảo mật .
Câu hỏi: Nếu một nhà sản xuất tích hợp tất cả các bản vá AOSP từ ASB nhưng không tích hợp các bản vá từ nhà cung cấp BSP được đề cập trong cùng một bản tin, liệu nhà sản xuất đó vẫn có thể nâng mức độ bảo mật (ví dụ: áp dụng bản vá tương ứng cho nền tảng/bản dựng) không ?
Đáp: Để khai báo mức bản vá bảo mật Android (SPL), nhà sản xuất phải giải quyết tất cả các vấn đề bắt buộc được xuất bản trong Bản tin bảo mật Android ( bao gồm cả các bản tin trước đó ) và ánh xạ tới một SPL Android cụ thể. Ví dụ: một nhà sản xuất sử dụng Bản tin bảo mật tháng 3 năm 2017 (01-03-2017 SPL) đã giải quyết tất cả các vấn đề bắt buộc được ghi trong bản tin tháng 3 năm 2017 cho SPL đó và tất cả các bản cập nhật trước đó bao gồm các bản cập nhật dành riêng cho thiết bị cho tất cả các Bản tin bảo mật Android trước đó, bao gồm các bản cập nhật dành riêng cho thiết bị liên quan đến SPL 2017-02-05.
Câu hỏi: Điều gì xảy ra khi nhà sản xuất không đồng ý với các bản cập nhật bảo mật do nhà cung cấp BSP cung cấp HOẶC khi các bản cập nhật bảo mật do ASB ủy quyền không được nhà cung cấp cung cấp?
Đáp: ASB mô tả các lỗ hổng bảo mật (được liệt kê theo danh sách CVE) và thường cung cấp các bài kiểm tra bảo mật phù hợp. Mục đích là để đảm bảo các lỗ hổng được liệt kê không thể tái tạo trên thiết bị được nữa và thiết bị đó có thể vượt qua các bài kiểm tra bảo mật liên quan. Do đó, vấn đề không phải là việc nhận bản cập nhật bảo mật do Google hoặc nhà cung cấp bên thứ ba cung cấp mà là do nhà sản xuất chứng thực rằng thiết bị không dễ bị tổn thương trong danh sách CVE trong ASB. Nhà sản xuất có quyền tự do sử dụng các bản cập nhật bảo mật được cung cấp hoặc nếu họ có thay đổi phù hợp hơn với thiết bị của mình thì hãy sử dụng thay đổi đó để thay thế.
Ví dụ: hãy xem xét trường hợp Google xử lý lỗ hổng bảo mật AOSP bằng cách thay đổi mã cho phép thành phần này duy trì đầy đủ chức năng và tuân thủ CDD. Nếu nhà sản xuất xác định thành phần này không cần thiết trên thiết bị hoặc không được CDD (hoặc thử nghiệm chứng nhận liên quan) bắt buộc, thì nhà sản xuất có thể loại bỏ thành phần đó để giảm nhu cầu bảo trì trong tương lai và giảm bề mặt tấn công. Mặc dù nhà sản xuất không sử dụng bản cập nhật bảo mật được cung cấp nhưng nó vẫn đảm bảo thiết bị không dễ bị CVE ghi trong bản tin bảo mật. Tuy nhiên, khi đi chệch khỏi bản cập nhật bảo mật được khuyến nghị, nhà sản xuất đang gặp rủi ro khi giải quyết vấn đề không chính xác, gây ra các lỗ hổng bảo mật mới hoặc làm giảm chức năng của bản dựng cuối cùng.
Mặc dù chúng tôi làm việc với tất cả các đối tác SoC để đảm bảo có các bản sửa lỗi cho mọi sự cố trong ASB, nhưng chúng tôi khuyên các nhà sản xuất nên đạt được thỏa thuận dịch vụ với các nhà cung cấp SoC của họ trong suốt vòng đời của thiết bị. SoC có thể ngừng cung cấp chipset sớm hơn mong muốn, vì vậy, việc thiết lập các thỏa thuận trước khi lựa chọn chipset cho thiết bị là một phần quan trọng trong quá trình ra mắt thiết bị.
Cuối cùng, trong trường hợp không thể trực tiếp lấy hoặc tạo bản sửa lỗi một cách độc lập cho sự cố được ghi trong ASB, nhà sản xuất có thể duy trì Android SPL trước đó và vẫn thêm các bản sửa lỗi mới có sẵn vào bản dựng. Tuy nhiên, cách làm này cuối cùng sẽ dẫn đến các vấn đề với chứng nhận bản dựng (vì Android đảm bảo cấp bản vá bảo mật mới nhất có sẵn trên các thiết bị được chứng nhận). Google khuyên bạn nên làm việc trước với SoC của bạn để tránh trường hợp này.
Câu hỏi: Nếu nhà sản xuất xác định một mặt hàng ASB không thể áp dụng cho sản phẩm của họ thì mặt hàng đó vẫn cần được áp dụng hoặc vá để đáp ứng các yêu cầu khác của Google hoặc để vượt qua CTS phải không?
Trả lời: Chúng tôi không yêu cầu phải thực hiện các bản vá để khai báo mức bản vá bảo mật Android (SPL); chúng tôi yêu cầu nhà sản xuất chứng thực rằng hệ thống của họ không gặp phải vấn đề này.
Một ví dụ là khi một thành phần đang được vá không tồn tại trong hệ thống của nhà sản xuất hoặc một thành phần bị xóa khỏi hệ thống của nhà sản xuất để giải quyết vấn đề. Trong trường hợp đó, hệ thống có thể tuân thủ mà không yêu cầu nhà sản xuất phải đưa ra bản vá.
Điều này về cơ bản khác với việc nhà sản xuất muốn, chẳng hạn, chỉ sửa các bản vá quan trọng, trong khi không sử dụng các bản vá hiện hành khác, điều này có thể khiến quá trình kiểm tra bảo mật không thành công. Trong trường hợp này, SPL được coi là không được đáp ứng.