Trong Android 11, bạn có thể áp dụng bản cập nhật OTA bằng cách sử dụng cơ chế cập nhật A/B hoặc cập nhật A/B ảo, kết hợp với các phương thức của lớp RecoverySystem. Sau khi thiết bị khởi động lại để áp dụng bản cập nhật OTA, tính năng Tiếp tục khi khởi động lại (RoR) sẽ mở khoá bộ nhớ được mã hoá thông tin xác thực (CE) của thiết bị.
Mặc dù các đối tác có thể ghép nối quy trình này với một tính năng hệ thống OTA áp dụng bản cập nhật khi thiết bị dự kiến sẽ ở trạng thái rảnh trong Android 11, nhưng trong Android 12, các đối tác không cần thêm tính năng hệ thống OTA. Quy trình RoR tăng cường tính bảo mật và sự thuận tiện cho người dùng vì có thể cập nhật trong thời gian thiết bị ở trạng thái rảnh. Trong khi đó, các chức năng cập nhật dựa trên nhiều máy khách và dựa trên máy chủ của Android 12 cùng cung cấp khả năng bảo mật loại phần cứng của thiết bị.
Mặc dù phải cung cấp quyền thiết bị cho tính năng android.hardware.reboot_escrow để hỗ trợ RoR trong Android 11, nhưng bạn không cần làm việc này để bật RoR dựa trên máy chủ trong Android 12 trở lên, vì các tính năng này không sử dụng HAL.
Thông tin khái quát
Kể từ Android 7, Android hỗ trợ tính năng Khởi động trực tiếp, cho phép các ứng dụng trên thiết bị khởi động trước khi người dùng mở khoá bộ nhớ CE. Việc triển khai tính năng hỗ trợ Khởi động trực tiếp đã mang lại cho Người dùng trải nghiệm tốt hơn trước khi cần nhập Hệ số kiến thức màn hình khoá (LSKF) sau khi khởi động.
RoR cho phép mở khoá bộ nhớ CE của tất cả ứng dụng trên một thiết bị, bao gồm cả những ứng dụng không hỗ trợ Khởi động trực tiếp, khi khởi động lại sau khi cập nhật OTA. Tính năng này cho phép người dùng nhận thông báo từ tất cả các ứng dụng đã cài đặt, sau khi khởi động lại.
Mô hình mối đe doạ
Việc triển khai RoR phải đảm bảo rằng khi một thiết bị rơi vào tay kẻ tấn công, kẻ tấn công rất khó khôi phục dữ liệu đã mã hoá CE của người dùng, ngay cả khi thiết bị đang bật nguồn, bộ nhớ CE được mở khoá và thiết bị được người dùng mở khoá sau khi nhận được bản cập nhật OTA. Khả năng chống tấn công nội bộ phải có hiệu quả ngay cả khi kẻ tấn công có được quyền truy cập vào khoá ký mật mã truyền tin.
Cụ thể, bộ nhớ CE không được đọc bởi kẻ tấn công có thiết bị trên thực tế cũng như có các khả năng và hạn chế sau:
Chức năng
- Có thể dùng khoá ký của bất kỳ nhà cung cấp hoặc công ty nào để ký các tin nhắn tuỳ ý.
- Có thể khiến thiết bị nhận được bản cập nhật OTA.
- Có thể sửa đổi hoạt động của bất kỳ phần cứng nào (chẳng hạn như bộ xử lý ứng dụng hoặc bộ nhớ flash) – ngoại trừ mục đích nêu chi tiết trong phần Các giới hạn bên dưới. (Tuy nhiên, việc sửa đổi đó sẽ liên quan đến cả độ trễ ít nhất là một giờ và chu kỳ nguồn làm huỷ bỏ nội dung của RAM.)
Giới hạn
- Không thể sửa đổi hoạt động của phần cứng chống can thiệp (ví dụ: Titan M).
- Không thể đọc RAM của thiết bị đang hoạt động.
- Không thể đoán thông tin đăng nhập của người dùng (mã PIN, hình mở khoá, mật khẩu) hoặc khiến người dùng nhập thông tin đó.
Giải pháp
Hệ thống cập nhật Android 12 RoR cung cấp cơ chế bảo mật chống lại những kẻ tấn công rất tinh vi. Điều này xảy ra ngay cả khi mật khẩu và mã PIN trên thiết bị vẫn còn trên thiết bị. Những dữ liệu này không bao giờ được gửi đến hoặc lưu trữ trên các máy chủ của Google. Đây là thông tin tổng quan về quy trình đảm bảo các mức bảo mật được cung cấp tương tự như hệ thống RoR cấp thiết bị dựa trên phần cứng:
- Android áp dụng các biện pháp bảo vệ bằng mật mã đối với dữ liệu được lưu trữ trên thiết bị.
- Tất cả dữ liệu đều được bảo vệ bằng các khoá được lưu trữ trong môi trường thực thi đáng tin cậy (TEE).
- TEE chỉ giải phóng khoá nếu hệ điều hành đang chạy vượt qua phương thức xác thực bằng mật mã (xác minh quy trình khởi động).
- Dịch vụ RoR chạy trên các máy chủ của Google bảo mật dữ liệu CE bằng cách lưu trữ một khoá bí mật có thể truy xuất chỉ trong một khoảng thời gian giới hạn. Phương thức này hoạt động trên toàn bộ hệ sinh thái Android.
- Khoá mã hoá (được bảo vệ bằng mã PIN của người dùng) dùng để mở khoá thiết bị và giải mã bộ nhớ CE.
- Khi lên lịch khởi động lại qua đêm, Android sẽ nhắc người dùng nhập mã PIN của họ, sau đó tính toán mật khẩu tổng hợp (SP).
- Sau đó, phương thức này mã hoá SP hai lần: một lần bằng khoá
K_sđược lưu trữ trong RAM và một lần nữa bằng khoáK_kđược lưu trữ trong TEE. - SP mã hoá kép được lưu trữ trên đĩa và SP sẽ bị xoá sạch khỏi RAM. Cả hai phím đều được tạo mới và dùng để chỉ một lần khởi động lại.
- Khi đến thời điểm khởi động lại, Android sẽ giao phó
K_scho máy chủ. Biên nhận vớiK_ksẽ được mã hoá trước khi lưu trữ trên ổ đĩa. - Sau khi khởi động lại, Android sử dụng
K_kđể giải mã biên nhận, sau đó gửi biên nhận này đến máy chủ để truy xuấtK_s.K_kvàK_sdùng để giải mã SP được lưu trữ trên ổ đĩa.- Android sử dụng SP để mở khoá bộ nhớ CE và cho phép khởi động ứng dụng một cách bình thường.
K_kvàK_sbị loại bỏ.
Các bản cập nhật giúp bảo mật điện thoại có thể diễn ra vào thời điểm thuận tiện cho bạn, đó là trong khi bạn ngủ.
Phát lại SIM-PIN
Trong một số điều kiện, mã PIN của thẻ SIM sẽ được xác minh từ bộ nhớ đệm – một quy trình gọi là phát lại mã PIN trên SIM.
Thẻ SIM có mã PIN đã bật cũng phải trải qua quy trình xác minh mã PIN liền mạch (phát lại SIM-PIN) sau khi khởi động lại mà không giám sát để khôi phục kết nối di động (bắt buộc đối với các cuộc gọi điện thoại, tin nhắn SMS và dịch vụ dữ liệu). Mã PIN của SIM và thông tin thẻ SIM trùng khớp (số ICCID và số khe cắm SIM) được lưu trữ an toàn cùng nhau. Bạn chỉ có thể truy xuất và sử dụng mã PIN đã lưu trữ để xác minh sau khi khởi động lại thành công mà không cần giám sát. Nếu thiết bị được bảo mật, thì mã PIN của SIM sẽ được lưu trữ bằng các khoá được bảo vệ bằng LSKF. Nếu SIM đã bật mã PIN, thì việc tương tác với máy chủ RoR sẽ yêu cầu kết nối Wi-Fi để cập nhật OTA và RoR dựa trên máy chủ. Điều này đảm bảo chức năng cơ bản (với kết nối di động) sau khi khởi động lại.
Mã PIN của SIM được mã hoá lại và lưu trữ mỗi khi người dùng bật, xác minh hoặc sửa đổi thành công. Mã PIN của SIM sẽ bị huỷ nếu xảy ra một trong những trường hợp sau đây:
- Đã tháo hoặc đặt lại SIM.
- Người dùng vô hiệu hoá mã PIN.
- Đã xảy ra quá trình khởi động lại không do RoR khởi tạo.
Bạn chỉ có thể sử dụng mã PIN SIM đã lưu một lần sau khi khởi động lại theo quy trình RoR và chỉ sử dụng trong khoảng thời gian rất ngắn (20 giây) – nếu thông tin chi tiết của thẻ SIM trùng khớp. Mã PIN của SIM được lưu trữ không bao giờ rời khỏi ứng dụng TelephonyManager và các mô-đun bên ngoài không thể truy xuất mã này.
Nguyên tắc triển khai
Trong Android 12, các hàm RoR nhiều ứng dụng và dựa trên máy chủ sẽ cung cấp tải nhẹ hơn cho các đối tác khi họ đẩy bản cập nhật OTA. Các bản cập nhật cần thiết có thể diễn ra trong thời gian thiết bị ngừng hoạt động thuận tiện, chẳng hạn như trong giờ ngủ được chỉ định.
Để đảm bảo các bản cập nhật OTA trong khoảng thời gian đó không làm gián đoạn người dùng, hãy sử dụng chế độ tối để giảm thiểu bức xạ ánh sáng. Để thực hiện việc này, hãy yêu cầu trình tải khởi động của thiết bị tìm kiếm lý do chuỗi unattended. Nếu unattended là true, hãy đặt thiết bị ở chế độ tối. Xin lưu ý rằng trách nhiệm của mỗi OEM là giảm thiểu lượng khí thải âm thanh và ánh sáng.
Nếu đang nâng cấp lên Android 12 hoặc chạy thiết bị Android 12, bạn không cần làm gì để triển khai chức năng RoR mới.
Có một lệnh gọi mới trong quy trình nhiều khách hàng, isPreparedForUnattendedUpdate,
xuất hiện dưới đây:
@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)
Bạn không cần triển khai việc này vì kể từ Android 12, HAL đã không còn được dùng nữa.
TelephonyManager
Ứng dụng OTA sẽ gọi API hệ thống TelephonyManager khi sắp khởi động lại trong Android 12. API này chuyển tất cả mã PIN được lưu vào bộ nhớ đệm từ trạng thái AVAILABLE sang trạng thái REBOOT_READY. API hệ thống TelephonyManager được bảo vệ bằng quyền hiện có đối với Tệp kê khai REBOOT.
/**
* The unattended reboot was prepared successfully.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;
/**
* The unattended reboot was prepared, but the user will need to manually
* enter the PIN code of at least one SIM card present in the device.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;
/**
* The unattended reboot was not prepared due to generic error.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;
/** @hide */
@Retention(RetentionPolicy.SOURCE)
@IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
value = {
PREPARE_UNATTENDED_REBOOT_SUCCESS,
PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
PREPARE_UNATTENDED_REBOOT_ERROR
})
public @interface PrepareUnattendedRebootResult {}
/**
* Prepare TelephonyManager for an unattended reboot. The reboot is
* required to be done shortly after the API is invoked.
*
* Requires system privileges.
*
* <p>Requires Permission:
* {@link android.Manifest.permission#REBOOT}
*
* @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
* {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
* at least one SIM card for which the user needs to manually enter the PIN
* code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
* of error.
* @hide
*/
@SystemApi
@RequiresPermission(android.Manifest.permission.REBOOT)
@PrepareUnattendedRebootResult
public int prepareForUnattendedReboot()
API hệ thống TelephonyManager được sử dụng bởi các APK đặc quyền.
Kiểm thử
Để kiểm thử API mới, hãy thực thi lệnh sau:
adb shell cmd phone unattended-reboot
Lệnh này chỉ hoạt động khi shell đang chạy dưới dạng thư mục gốc (adb root).
Chỉ Android 11
Phần còn lại của trang này áp dụng cho Android 11.
Kể từ tháng 7 năm 2020, việc triển khai RoR HAL (Lớp trừu tượng phần cứng) được chia thành 2 loại:
- Nếu phần cứng SoC hỗ trợ khả năng lưu trữ cố định RAM trong các lần khởi động lại, thì OEM có thể sử dụng phương thức triển khai mặc định trong AOSP (Default RAM Escrow (Dịch vụ lưu giữ RAM mặc định)).
- Nếu phần cứng thiết bị hoặc SoC hỗ trợ một mạng lưới phần cứng bảo mật (một bộ đồng xử lý bảo mật riêng biệt có RAM và ROM riêng), thì ngoài ra, thiết bị đó phải thực hiện những việc sau:
- Có thể phát hiện quá trình khởi động lại CPU chính.
- Có một nguồn bộ tính giờ phần cứng luôn tồn tại khi khởi động lại. Điều đó nghĩa là lớp phủ phải có khả năng phát hiện lần khởi động lại và hết hạn bộ tính giờ đã đặt trước khi khởi động lại.
- Hỗ trợ lưu trữ khoá đã uỷ thác trong RAM/ROM của mạng lưới để không thể khôi phục khoá bằng các cuộc tấn công ngoại tuyến. Ứng dụng này phải lưu trữ khoá RoR sao cho người trong cuộc hoặc kẻ tấn công không thể khôi phục khoá đó.
Ủy thác RAM mặc định
AOSP đã triển khai RoR HAL bằng cách sử dụng khả năng lưu trữ RAM cố định. Để làm được điều này, OEM phải đảm bảo rằng SoC của họ hỗ trợ tính năng lưu trữ cố định RAM sau các lần khởi động lại. Một số SoC không thể lưu trữ nội dung RAM khi khởi động lại, vì vậy nhà sản xuất thiết bị gốc nên tham khảo ý kiến của các đối tác SoC trước khi bật lớp HAL mặc định này. Tài liệu tham khảo chuẩn cho nội dung này trong phần sau.
Quy trình cập nhật qua mạng không dây (OTA) bằng RoR
Ứng dụng OTA trên điện thoại phải có các quyền Manifest.permission.REBOOT và Manifest.permission.RECOVERY để gọi các phương thức cần thiết nhằm triển khai RoR. Với điều kiện tiên quyết đó, quy trình cập nhật sẽ tuân theo các bước sau:
- Ứng dụng khách OTA sẽ tải bản cập nhật xuống.
- Ứng dụng OTA sẽ gọi đến
RecoverySystem#prepareForUnattendedUpdateđể kích hoạt người dùng được nhắc nhập mã PIN, hình mở khoá hoặc mật khẩu trên màn hình khoá trong lần mở khoá tiếp theo. - Người dùng mở khoá thiết bị tại màn hình khoá và thiết bị đã sẵn sàng để áp dụng bản cập nhật.
- Ứng dụng khách OTA sẽ gọi đến
RecoverySystem#rebootAndApplyđể ngay lập tức kích hoạt quá trình khởi động lại.
Khi kết thúc quy trình này, thiết bị khởi động lại và cơ chế RoR sẽ mở khoá bộ nhớ được mã hoá thông tin xác thực (CE). Đối với ứng dụng, thông tin này sẽ xuất hiện dưới dạng một lượt mở khoá thông thường của người dùng, vì vậy, ứng dụng sẽ nhận được tất cả tín hiệu, chẳng hạn như ACTION_LOCKED_BOOT_COMPLETED và ACTION_BOOT_COMPLETED mà chúng thường thực hiện.
Sửa đổi cấu hình sản phẩm
Một sản phẩm được đánh dấu là hỗ trợ tính năng RoR (RoR) trong Android 11 phải bao gồm việc triển khai HAL uỷ thác khởi động lại và bao gồm tệp XML của điểm đánh dấu tính năng. Cách triển khai mặc định hoạt động tốt trên các thiết bị sử dụng tính năng khởi động ấm (khi nguồn điện cho DRAM vẫn bật trong quá trình khởi động lại).
Khởi động lại điểm đánh dấu tính năng uỷ thác
Điểm đánh dấu đối tượng cũng phải có:
PRODUCT_COPY_FILES += \
frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml
Triển khai lớp trừu tượng phần cứng (HAL) cho việc khởi động lại mặc định
Để sử dụng cách triển khai mặc định, bạn phải đặt trước 65536 (0x10000) byte. Đừng bao giờ ghi các byte này vào bộ nhớ bất biến để đảm bảo rằng các thuộc tính bảo mật vẫn tồn tại.
Thay đổi cây thiết bị nhân hệ điều hành Linux
Trong cây thiết bị của nhân Linux, bạn phải dự trữ bộ nhớ cho vùng pmem.
Ví dụ sau đây cho thấy 0x50000000 đang được đặt trước:
reserved-memory {
my_reservation@0x50000000 {
no-map;
reg = <0x50000000 0x10000>;
}
}
reboot_escrow@0 {
compatible = "pmem-region";
reg = <0x50000000 0x10000>;
};
Xác minh rằng bạn có một thiết bị mới trong thư mục khối có tên như /dev/block/pmem0 (chẳng hạn như pmem1 hoặc pmem2).
Các thay đổi đối với Device.mk
Giả sử thiết bị mới ở bước trước có tên là pmem0, bạn phải đảm bảo các mục mới sau đây được thêm vào vendor/<oem>/<product>/device.mk:
# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
android.hardware.rebootescrow-service.default
Quy tắc SELinux
Thêm các mục nhập mới sau đây vào file_contexts của thiết bị:
/dev/block/pmem0 u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default u:object_r:hal_rebootescrow_default_exec:s0