Trong Android 11, bạn có thể áp dụng các bản cập nhật qua mạng (OTA) bằng cách sử dụng cơ chế bản cập nhật A/B hoặc bản cập nhật A/B ảo, kết hợp với các phương thức 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 sau khi khởi động lại (RoR) sẽ mở khoá Bộ nhớ được mã hoá thông tin đăng nhập (CE) của thiết bị.
Mặc dù các đối tác có thể kết hợp quy trình này với một tính năng hệ thống OTA áp dụng các bản cập nhật khi thiết bị dự kiến ở 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 mang lại sự an toàn và thuận tiện hơn cho người dùng vì các bản cập nhật có thể được thực hiện trong thời gian thiết bị ở trạng thái chờ, trong khi các chức năng cập nhật dựa trên máy chủ và nhiều ứng dụng của Android 12 cùng nhau cung cấp tính năng bảo mật loại cấp phần cứng cho thiết bị.
Mặc dù bạn phải cấp quyền cho thiết bị đối với 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 phiên bản này không dùng HAL.
Thông tin khái quát
Kể từ Android 7, Android đã hỗ trợ chế độ Khởi động trực tiếp. Chế độ này 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 đến 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 về màn hình khoá (LSKF) sau khi khởi động.
RoR cho phép mở kho lưu trữ CE của tất cả ứng dụng trên thiết bị, kể cả những ứng dụng không hỗ trợ tính năng Khởi động trực tiếp, khi quá trình khởi động lại được bắt đầu sau khi cập nhật qua 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 sẽ cực kỳ khó khôi phục dữ liệu được mã hoá CE của người dùng, ngay cả khi thiết bị đang bật, bộ nhớ CE đã được mở khoá và người dùng mở khoá thiết bị sau khi nhận được bản cập nhật OTA. Khả năng chống tấn công nội gián phải hiệu quả ngay cả khi kẻ tấn công có quyền truy cập vào các khoá ký mã hoá truyền tin.
Cụ thể, bộ nhớ CE không được bị kẻ tấn công đọc khi kẻ đó có thiết bị thực và có các khả năng cũng như hạn chế sau:
Khả 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 thông báo tuỳ ý.
- Có thể khiến thiết bị nhận được bản cập nhật qua mạng không dây.
- Có thể sửa đổi hoạt động của mọi phần cứng (chẳng hạn như bộ xử lý ứng dụng hoặc bộ nhớ flash) – ngoại trừ những trường hợp được nêu chi tiết trong phần Các hạn chế bên dưới. (Tuy nhiên, việc sửa đổi như vậy sẽ mất ít nhất một giờ và một chu kỳ bật/tắt nguồn sẽ xoá nội dung RAM.)
Giới hạn
- Không thể sửa đổi hoạt động của phần cứng chống giả mạo (ví dụ: Titan M).
- Không đọc được RAM của thiết bị đang hoạt động.
- Không được đ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 họ nhập thông tin đó.
Giải pháp
Hệ thống cập nhật RoR của Android 12 giúp bảo vệ thiết bị khỏi những kẻ tấn công tinh vi, đồng thời mật khẩu và mã PIN trên thiết bị sẽ vẫn nằm trên thiết bị mà 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 cấp độ bảo mật được cung cấp tương tự như hệ thống RoR dựa trên phần cứng ở cấp thiết bị:
- Android áp dụng các biện pháp bảo vệ bằng mật mã cho 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ỉ phát hành các khoá nếu hệ điều hành đang chạy vượt qua quy trình xác thực mật mã (quy trình khởi động đã xác minh).
- Dịch vụ RoR chạy trên các máy chủ của Google sẽ bảo mật dữ liệu CE bằng cách lưu trữ một khoá bí mật mà chỉ có thể truy xuất trong một khoảng thời gian giới hạn. Quy định này áp dụng trên toàn bộ hệ sinh thái Android.
- Khoá mật mã (được bảo vệ bằng mã PIN của người dùng) được dùng để mở khoá thiết bị và giải mã bộ nhớ CE.
- Khi có lịch khởi động lại qua đêm, Android sẽ nhắc người dùng nhập mã PIN, sau đó tính toán một mật khẩu tổng hợp (SP).
- Sau đó, nó 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 được mã hoá hai lần sẽ được lưu trữ trên đĩa và bị xoá khỏi RAM. Cả hai khoá đều mới được tạo và chỉ được dùng cho 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 cóK_ksẽ được mã hoá trước khi được 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 máy chủ để truy xuấtK_s.K_kvàK_sđược dùng để giải mã SP được lưu trữ trên ổ đĩa.- Android dùng SP để mở khoá bộ nhớ CE và cho phép khởi động ứng dụng thông thường.
K_kvàK_ssẽ bị loại bỏ.
Các bản cập nhật giúp điện thoại của bạn luôn an toàn có thể diễn ra vào thời điểm thuận tiện cho bạn: trong khi bạn ngủ.
Phát lại mã PIN của SIM
Trong một số điều kiện nhất định, 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 của 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 mã PIN của SIM) sau khi khởi động lại mà không cần người dùng thao tác để khôi phục kết nối di động (bắt buộc đối với 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 tương ứng (ICCID và số khe cắm SIM) được lưu trữ cùng nhau một cách an toàn. 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 có sự tham gia của người dùng. Nếu thiết bị được bảo mật, mã PIN của SIM sẽ được lưu trữ cùng với các khoá do LSKF bảo vệ. Nếu SIM đã bật mã PIN, thì việc tương tác với máy chủ RoR yêu cầu phải có kết nối Wi-Fi để cập nhật qua mạng (OTA) và RoR dựa trên máy chủ, đảm bảo chức năng cơ bản (có kết nối di động) sau khi khởi động lại.
Mã PIN của SIM sẽ đượ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ị loại bỏ nếu xảy ra bất kỳ trường hợp nào sau đây:
- SIM đã bị tháo hoặc đặt lại.
- Người dùng tắt mã PIN.
- Đã xảy ra một lần khởi động lại không do RoR khởi tạo.
Bạn chỉ có thể dùng mã PIN của SIM đã lưu một lần sau khi khởi động lại do RoR và chỉ trong thời gian rất ngắn (20 giây) – nếu thông tin chi tiết về thẻ SIM trùng khớp. Mã PIN của SIM được lưu trữ sẽ 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ã PIN này.
Nguyên tắc triển khai
Trong Android 12, các chức năng RoR dựa trên nhiều máy khách và máy chủ giúp giảm tải cho các đối tác khi họ đẩy các 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ị không hoạt động, chẳng hạn như trong những giờ ngủ đã chỉ định.
Để đảm bảo các bản cập nhật OTA trong những khoảng thời gian như vậy không làm gián đoạn người dùng, hãy sử dụng chế độ tối để giảm thiểu lượng ánh sáng phát ra. Để làm như vậy, hãy để trình tải khởi động của thiết bị tìm kiếm chuỗi reason unattended. Nếu unattended là true, hãy đặt thiết bị ở chế độ tối. Xin lưu ý rằng mỗi OEM đều có trách nhiệm 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 ra mắt các 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 ứng dụng, isPreparedForUnattendedUpdate, như minh hoạ bên dưới:
@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ì HAL đã ngừng hoạt động kể từ Android 12.
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 di chuyển tất cả mã PIN đã 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 REBOOT hiện có trong Tệp kê khai.
/**
* 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()
Các APK có đặc quyền sử dụng API hệ thống TelephonyManager.
Thử nghiệm
Để kiểm thử API mới, hãy thực thi lệnh sau:
adb shell cmd phone unattended-rebootLệnh này chỉ hoạt động khi trình bao đang chạy ở chế độ gốc (adb root).
Chỉ dành cho 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, các cách triển khai RoR HAL được chia thành 2 danh mục:
- Nếu phần cứng SoC hỗ trợ tính năng duy trì RAM khi khởi động lại, thì OEM có thể sử dụng chế độ triển khai mặc định trong AOSP (RAM Escrow mặc định).
- Nếu phần cứng thiết bị hoặc SoC hỗ trợ một vùng bảo mật phần cứng (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 thấy một lần khởi động lại CPU chính.
- Có nguồn hẹn giờ phần cứng duy trì hoạt động sau khi khởi động lại. Tức là vùng an toàn phải có khả năng phát hiện quá trình khởi động lại và hết thời gian chờ đã đặt trước khi khởi động lại.
- Hỗ trợ lưu trữ khoá được uỷ thác trong RAM/ROM của vùng biệt lập để không thể khôi phục bằng các cuộc tấn công ngoại tuyến. Bạn phải lưu trữ khoá RoR theo cách khiến người trong nội bộ hoặc kẻ tấn công không thể khôi phục khoá đó.
RAM ký quỹ mặc định
AOSP có một cách triển khai RoR HAL bằng cách sử dụng tính năng duy trì RAM. Để tính năng này hoạt động, các OEM phải đảm bảo rằng SoC của họ hỗ trợ khả năng duy trì RAM trong quá trình khởi động lại. Một số SoC không thể duy trì nội dung RAM trong quá trình khởi động lại, vì vậy, các OEM nên tham khảo ý kiến của đối tác SoC trước khi bật HAL mặc định này. Thông tin tham khảo chính thức cho vấn đề này có trong phần sau.
Quy trình cập nhật qua mạng không dây bằng RoR
Ứng dụng khách 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. Khi có điều kiện tiên quyết đó, quy trình cập nhật sẽ diễn ra theo các bước sau:
- Ứng dụng khách OTA tải bản cập nhật xuống.
- Các lệnh gọi ứng dụng OTA client đến
RecoverySystem#prepareForUnattendedUpdatesẽ kích hoạt lời nhắc yêu cầu người dùng 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ị ở màn hình khoá và thiết bị đã sẵn sàng để áp dụng bản cập nhật.
- Các lệnh gọi ứng dụng khách OTA đến
RecoverySystem#rebootAndApply, ngay lập tức kích hoạt quá trình khởi động lại.
Khi quy trình này kết thúc, thiết bị sẽ khởi động lại và cơ chế RoR sẽ mở khoá bộ nhớ được mã hoá thông tin đăng nhập (CE). Đối với các ứng dụng, thao tác này xuất hiện dưới dạng thao tác mở khoá thông thường của người dùng, vì vậy, các ứ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à các ứng dụng thường nhận được.
Sửa đổi cấu hình sản phẩm
Một sản phẩm được đánh dấu là có hỗ trợ tính năng RoR trong Android 11 phải có một bản triển khai HAL RebootEscrow và có tệp XML đánh dấu tính năng. Phương thức 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 lại nóng (khi nguồn điện cho DRAM vẫn bật trong quá trình khởi động lại).
Điểm đánh dấu tính năng uỷ thác khởi động lại
Bạn cũng phải có điểm đánh dấu tính năng:
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 HAL mặc định để khởi động lại tính năng ký quỹ
Để sử dụng chế độ triển khai mặc định, bạn phải dành riêng 65536 (0x10000) byte. Không bao giờ ghi các byte này vào bộ nhớ không biến đổi để đảm bảo các thuộc tính bảo mật vẫn tồn tại.
Các thay đổi về cây thiết bị trong kernel Linux
Trong cây thiết bị của nhân Linux, bạn phải dành riêng bộ nhớ cho một 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 của bạn ở 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 mới nà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