Tiếp tục khi khởi động lại

Trên Android 11, bạn có thể áp dụng bản cập nhật OTA bằng cách sử dụng bản cập nhật A/B hoặc cập nhật A/B ảo, kết hợp với Khôi phục hệ thống phương thức lớp. Sau khi thiết bị khởi động lại để áp dụng bản cập nhật OTA, Tiếp tục khi khởi động lại (RoR) mở khoá bộ nhớ được mã hoá thông tin xác thực (CE) của thiết bị.

Mặc dù đối tác có thể ghép nối quy trình này với tính năng của hệ thống OTA có áp dụng các bản cập nhật khi thiết bị dự kiến sẽ không hoạt động trong Android 11, trong Các đối tác Android 12 không cần có thêm hệ thống OTA của chúng tôi. Quy trình RoR tăng cường bảo mật và 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, còn Android 12 các chức năng cập nhật dựa trên nhiều máy khách và máy chủ cùng cung cấp thiết bị bảo mật loại cấp phần cứng.

Mặc dù bạn phải cấp quyền truy cập thiết bị cho android.hardware.reboot_escrow để hỗ trợ RoR trong Android 11, bạn không cần thực hiện việc này để bật RoR dựa trên máy chủ trong Android 12 trở lên vì chúng không sử dụng HAL.

Thông tin khái quát

Kể từ Android 7, tính năng Khởi động trực tiếp được hỗ trợ trên Android, cho phép các ứng dụng trên một thiết bị khởi động trước khi bộ nhớ CE được mở khoá bằng người dùng. Việc triển khai hỗ trợ Khởi động trực tiếp đã mang lại cho Người dùng tính năng trước khi cần nhập Yếu tố kiến thức trên 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 những trình khởi động lại không hỗ trợ Direct Boot, khi khởi động lại được bắt đầu sau Cập nhật qua mạng không dây. Tính năng này cho phép người dùng nhận thông báo từ tất 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 (RoR) phải đảm bảo rằng khi một thiết bị rơi vào kẻ tấn công cực kỳ khó khăn khi muốn khôi phục CE của người dùng dữ liệu đã mã hoá, ngay cả khi thiết bị đang bật nguồn, bộ nhớ CE luôn đượ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. Nội bộ tính năng chống tấn công 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ã hoá truyền tin.

Cụ thể, kẻ tấn công trên thực tế không được đọc bộ nhớ CE thiết bị, đồng thời có các khả năng và giới hạn 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) – trừ phi được nêu chi tiết trong Các giới hạn dưới đây. (Tuy nhiên, việc sửa đổi đó bao gồm độ trễ ít nhất là một giờ và chu kỳ nguồn phá huỷ 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 can thiệp (ví dụ: Titan M).
  • Không thể đọc RAM của thiết bị đang hoạt động.
  • Không đoán được thông tin đăng nhập của người dùng (mã PIN, hình mở khoá, mật khẩu) hoặc nguyên nhân khác mà bạn muốn nhập.

Giải pháp

Hệ thống cập nhật RoR (RoR) Android 12 cung cấp khả năng bảo mật trước những kẻ tấn công vô cùng tinh vi và làm như vậy khi đang lưu trữ mật khẩu cũng như Mã PIN nằm trên thiết bị. Ứng dụng sẽ không bao giờ gửi mã PIN đến hay lưu trữ mã PIN trên các máy chủ của Google. Chiến dịch này là thông tin tổng quan về quy trình nhằm đảm bảo các mức bảo mật được đưa ra 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á lưu trữ trong môi trường thực thi đáng tin cậy (TEE).
  • TEE chỉ giải phóng các khoá nếu hệ điều hành đang chạy vượt qua xác thực mật mã (khởi động được xác minh).
  • 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 thời gian có hạn. Phương thức này hoạt động trên toàn bộ hệ sinh thái Android.
  • Một 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 có 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_s cho máy chủ. Biên nhận với K_k sẽ đượ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, rồi gửi biên nhận tới máy chủ để truy xuất K_s.
    • K_kK_s dù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_kK_s bị loại bỏ.

Quá trình cập nhật giúp điện thoại của bạn luôn an toàn có thể diễn ra bất cứ lúc nào thuận tiện dành cho bạn: trong khi bạn ngủ.

Phát lại SIM-PIN

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 SIM-PIN.

Thẻ SIM đã bật mã PIN cũng phải trải qua một mã PIN liền mạch xác minh (phát lại SIM-PIN) sau khi khởi động lại mà không cần chú ý để khôi phục dữ liệu di động khả năng kết nối (cần thiết cho 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 (ICID và khe cắm SIM) số) được lưu trữ an toàn cùng nhau. Bạn có thể truy xuất và sử dụng mã PIN đã lưu trữ để xác minh chỉ sau khi khởi động lại thành công mà không giám sát. Nếu thiết bị là mã PIN của SIM được lưu trữ bằng các khoá được bảo vệ bằng LSKF. Nếu SIM có đã bật mã PIN, nên việc tương tác với máy chủ RoR cần có kết nối Wi-Fi dành cho bản cập nhật OTA và RoR dựa trên máy chủ, đả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 thành công. xác minh hoặc sửa đổi dữ liệu đó. Mã PIN của SIM sẽ bị huỷ nếu có bất kỳ trường hợp nào sau đây xảy ra xảy ra:

  • Đã 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ể dùng mã PIN SIM đã lưu trữ một lần sau khi khởi động lại theo quy trình RoR, và chỉ trong khoảng thời gian rất ngắn (20 giây) – nếu thông tin chi tiết của SIM thẻ trùng khớp. Mã PIN của SIM đã lưu trữ chỉ bao giờ rời khỏi ứng dụng TelephonyManager và mã PIN đó không thể được truy xuất bởi mô-đun bên ngoài.

Nguyên tắc triển khai

Trong Android 12, RoR đa ứng dụng và dựa trên máy chủ các chức năng này giúp đối tác tải nhẹ hơn khi họ cập nhật qua mạng không dây. 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ư số giờ ngủ chỉ định.

Để đảm bảo rằng 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, sử dụng chế độ tối để giảm thiểu bức xạ ánh sáng. Để làm như vậy, hãy chuẩn bị sẵn thiết bị tìm kiếm trình tải khởi động vì lý do chuỗi unattended. Nếu unattendedtrue, đặ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 của âm thanh và ánh sáng.

Nếu bạn đang nâng cấp lên Android 12 hoặc đang chạy với thiết bị Android 12, bạn không cần phải 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, được hiển thị 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 lớp 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 được lưu vào bộ nhớ đệm từ từ trạng thái AVAILABLE sang trạng thái REBOOT_READY. Hệ thống TelephonyManager API được bảo vệ bằng REBOOT hiện có Quyền truy cập 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()

API hệ thống TelephonyManager được sử dụng bởi các APK đặc quyền.

Thử nghiệm

Để 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:

  1. Nếu phần cứng SoC hỗ trợ tính năng lưu trữ cố định RAM qua các lần khởi động lại, OEM có thể sử dụng thuộc tính triển khai mặc định trong AOSP (Uỷ quyền RAM mặc định).
  2. 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 có RAM và ROM riêng), ngoài ra, bộ đồng xử lý này phải 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. Đó là mạng lưới phải có khả năng phát hiện quá trình khởi động lại và hết hạn bộ tính giờ trước khi khởi động lại.
    • Hỗ trợ lưu trữ khoá ký quỹ trong RAM/ROM của mạng lưới để hệ thống không thể có thể được khôi phục bằng các cuộc tấn công ngoại tuyến. Ứng dụng phải lưu trữ khoá RoR sao cho khiến người trong cuộc hoặc kẻ tấn công không thể khôi phục.

Ủ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 khi khởi động lại. Một số SoC không thể lưu trữ nội dung trên RAM sau 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 khách OTA trên điện thoại phải có Manifest.permission.REBOOTManifest.permission.RECOVERY để gọi các phương thức cần thiết đến triển khai RoR. Khi có sẵn điều kiện tiên quyết đó, luồng bản cập nhật, hãy làm theo các bước sau:

  1. Ứng dụng khách OTA sẽ tải bản cập nhật xuống.
  2. Ứng dụng khách OTA 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.
  3. Người dùng mở khoá thiết bị khi màn hình khoá và thiết bị đã sẵn sàng để áp dụng bản cập nhật.
  4. Ứng dụng khách OTA gọi đến RecoverySystem#rebootAndApply, ngay lập tức kích hoạt khởi động lại.

Khi kết thúc quy trình này, thiết bị sẽ khởi động lại và RoR cơ chế này mở khoá bộ nhớ được mã hoá thông tin đăng nhập (CE). Đối với ứng dụng, xuất hiện dưới dạng mở khoá thông thường của người dùng, vì vậy, họ nhận được tất cả tín hiệu, chẳng hạn như ACTION_LOCKED_BOOT_COMPLETEDACTION_BOOT_COMPLETED mà họ thường làm.

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 trong Android 11 phải bao gồm triển khai HAL Restart Escrow và đưa vào tệp XML đ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 lại ấm (khi nguồn của DRAM vẫn bật trong khi 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. Chưa bao giờ đăng 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 tồn tại lâu dà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 có tên như trong thư mục khối /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 nhập mới sau đượ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