Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

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

Trong Android 11, các bản cập nhật OTA có thể được áp dụng bằng cách sử dụng cập nhật A / B hoặc cơ chế 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, Tiếp tục khi khởi động lại (RoR) sẽ mở khóa bộ nhớ được mã hóa 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 quá 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 ​​không hoạt động trong Android 11, nhưng trong Android 12, các đối tác không cần tính năng hệ thống OTA bổ sung. Quy trình RoR cung cấp thêm tính bảo mật và tiện lợi 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ị không hoạt động, trong khi các chức năng cập nhật dựa trên máy chủ và đa máy khách của Android 12 cùng cung cấp bảo mật loại cấp phần cứng của thiết bị.

Mặc dù bạn 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 phải làm như vậ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.

cung cấp quyền thiết bị cho tính năng android.hardware.reboot_escrow . Bạn không cần phải làm bất cứ điều gì để bật RoR dựa trên máy chủ trong Android 12 vì Android 12 trở lên không sử dụng HAL.

Tiểu sử

Bắt đầu từ Android 7, Direct Boot được hỗ trợ bởi Android, cho phép các ứng dụng trên thiết bị khởi động trước khi bộ lưu trữ CE được người dùng mở khóa. Việc triển khai hỗ trợ Khởi động trực tiếp đã cung cấp cho Người dùng trải nghiệm tốt hơn trước khi Hệ số kiến ​​thức màn hình khóa (LSKF) cần được nhập sau khi khởi động.

RoR cho phép mở khóa bộ lưu trữ CE của tất cả các ứng dụng trên thiết bị, bao gồm cả những ứng dụng không hỗ trợ Direct Boot, khi khởi động lại được thực hiện sau bản 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 của họ, đăng khởi động lại.

Mô hình đe dọa

Việc triển khai RoR phải đảm bảo rằng khi 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ã hóa CE của người dùng, ngay cả khi thiết bị được bật nguồn, bộ lưu trữ CE được mở khóa và thiết bị được mở khóa bằng người dùng sau khi nhận được bản cập nhật OTA. Khả năng chống lại cuộc tấn công nội bộ phải có hiệu quả ngay cả khi kẻ tấn công giành được quyền truy cập vào các khóa ký mật mã phát sóng.

Cụ thể, bộ nhớ CE không được đọc bởi kẻ tấn công có thiết bị và có các khả năng và hạn chế sau:

Năng lực

  • Có thể sử dụng khóa ký của bất kỳ nhà cung cấp hoặc công ty nào để ký các thông báo tùy ý.
  • 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ừ được nêu chi tiết trong Giới hạn bên dưới. (Tuy nhiên, việc sửa đổi như vậy bao gồm cả độ trễ ít nhất một giờ và chu kỳ năng lượng phá hủy nội dung RAM.)

Hạn chế

  • 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 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ở khóa, mật khẩu) hoặc có thể khiến họ bị nhập.

Giải pháp

Hệ thống cập nhật Android 12 RoR cung cấp khả năng bảo mật chống lại những kẻ tấn công rất tinh vi và làm như vậy trong khi mật khẩu và mã PIN trên thiết bị vẫn ở trên thiết bị — chúng không bao giờ được gửi đến hoặc lưu trữ trên máy chủ của Google. Đây là 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 được bảo vệ bằng các khóa được lưu trữ trong môi trường thực thi đáng tin cậy (TEE).
  • TEE chỉ giải phóng các khóa 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 máy chủ của Google bảo mật dữ liệu CE bằng cách lưu trữ bí mật chỉ có thể được truy xuất trong một thời gian giới hạn . Điều này hoạt động trên toàn bộ hệ sinh thái Android.
  • Khóa mật mã, được bảo vệ bằng mã PIN của người dùng, được sử dụng để mở khóa thiết bị và giải mã bộ lưu trữ CE.
    • Khi khởi động lại qua đêm được lên lịch, 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 đó, nó mã hóa SP hai lần: một lần với khóa K_s được lưu trữ trong RAM và một lần nữa với khóa K_k được lưu trữ trong TEE.
    • SP được mã hóa kép được lưu trữ trên đĩa và SP sẽ bị xóa khỏi RAM. Cả hai khóa đều được tạo mới và chỉ được sử dụng cho một lần khởi động lại .
  • Khi đến lúc khởi động lại, Android sẽ giao K_s cho máy chủ. Biên lai với K_k được mã hóa trước khi nó đượ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 đến máy chủ để lấy K_s .
    • K_kK_s được sử dụng để giải mã SP được lưu trữ trên đĩa.
    • Android sử dụng SP để mở khóa bộ nhớ CE và cho phép khởi động ứng dụng bình thường.
    • K_kK_s bị loại bỏ.

Các bản cập nhật giữ an toàn cho điện thoại của bạn có thể xảy 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 được xác minh từ bộ nhớ đệm, một quá trình được gọi là phát lại mã PIN của SIM.

Thẻ SIM có mã PIN được bật cũng phải trải qua quá 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 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à các dịch vụ dữ liệu). Mã PIN của SIM và thông tin thẻ SIM phù hợp (ICCID và số khe cắm SIM) được lưu trữ cùng nhau một cách an toàn. Mã PIN đã lưu chỉ có thể được truy xuất và sử dụng để 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, mã PIN của SIM được lưu trữ bằng các khóa được LSKF bảo vệ. Nếu SIM đã bật mã PIN, việc tương tác với máy chủ RoR yêu cầu kết nối WiFi 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ã hóa 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 bất kỳ điều nào sau đây xảy ra:

  • Đã tháo hoặc đặt lại SIM.
  • Người dùng vô hiệu hóa mã PIN.
  • Đã xảy ra khởi động lại không do RoR thực hiện.

Mã PIN của SIM đã lưu chỉ có thể được sử dụng một lần sau khi khởi động lại bằng RoR và chỉ trong khoảng thời gian rất ngắn (20 giây) - nếu chi tiết của thẻ SIM 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à không thể truy xuất mã PIN này bằng các mô-đun bên ngoài.

Hướng dẫn thực hiện

Trong Android 12, các chức năng RoR dựa trên nhiều máy khách và máy chủ cung cấp tải nhẹ hơn cho các đối tác khi họ đẩy các bản cập nhật OTA. Các cập nhật cần thiết có thể xảy 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 rằng các cập nhật OTA trong 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 phát thải ánh sáng. Để làm như vậ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 mà unattended . Nếu không được unattendedtrue , hãy đặt thiết bị ở chế độ tối. Lưu ý rằng trách nhiệm của mỗi OEM là giảm thiểu phát thải âm thanh và ánh sáng.

Nếu bạn đang nâng cấp lên Android 12 hoặc khởi chạy thiết bị Android 12, bạn không cần phải làm bất kỳ điều gì để triển khai chức năng RoR mới.

Có một lệnh gọi mới trong luồng 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 phải triển khai điều này vì HAL không còn được dùng cho Android 12.

TelephonyManager

Ứng dụng khách OTA gọi API hệ thống TelephonyManager khi sắp có khởi động lại trong Android 12. API này di chuyển tất cả các mã PIN đã lưu trong bộ nhớ cache từ trạng thái AVAILABLE SN sang trạng thái REBOOT_READY . API hệ thống TelephonyManager được bảo vệ bởi quyền Tệp kê khai REBOOT hiện có.

 /**
    * 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 tra 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 root ( 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 được chia thành hai loại:

  1. Nếu phần cứng SoC hỗ trợ RAM bền bỉ khi khởi động lại, OEM có thể sử dụng cài đặt mặc định trong AOSP (Ký quỹ RAM mặc định ).
  2. Nếu phần cứng của thiết bị hoặc SoC hỗ trợ một bộ vi xử lý phần cứng an toàn (một bộ đồng xử lý bảo mật rời với RAM và ROM của riêng nó), thì ngoài ra nó phải thực hiện những việc sau:
    • Có thể phát hiện khởi động lại CPU chính.
    • Có nguồn hẹn giờ phần cứng vẫn tồn tại qua các lần khởi động lại. Đó là, enclave phải có khả năng phát hiện khởi động lại và hết hạn đặt bộ hẹn giờ trước khi khởi động lại.
    • Hỗ trợ lưu trữ khóa ký quỹ trong RAM / ROM vùng kín để không thể khôi phục nó khi bị tấn công ngoại tuyến. Nó phải lưu trữ khóa RoR theo cách khiến người trong cuộc hoặc kẻ tấn công không thể khôi phục được.

Ký quỹ RAM mặc định

AOSP có một triển khai RoR HAL bằng cách sử dụng RAM bền bỉ. Để điều này hoạt động, các OEM phải đảm bảo rằng các SoC của họ hỗ trợ RAM bền bỉ qua các lần khởi động lại. Một số SoC không thể duy trì nội dung RAM khi khởi động lại, vì vậy OEM nên tham khảo ý kiến ​​đối tác SoC của họ trước khi bật HAL mặc định này. Tham chiếu chính tắc cho điều này trong phần sau.

Quy trình cập nhật OTA sử dụng RoR

Ứng dụng khách OTA trên điện thoại phải có quyền Manifest.permission.REBOOTManifest.permission.RECOVERY để gọi các phương thức cần thiết để triển khai RoR. Với điều kiện tiên quyết đó được áp dụng, quy trình cập nhật sẽ tuân theo các bước sau:

  1. Ứng dụng khách OTA tải xuống bản cập nhật.
  2. Ứng dụng khách OTA gọi đến RecoverySystem#prepareForUnattendedUpdate sẽ kích hoạt người dùng được nhắc nhập mã PIN, hình mở khóa hoặc mật khẩu của họ trên màn hình khóa trong lần mở khóa tiếp theo.
  3. Người dùng mở khóa thiết bị ở màn hình khóa 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 , khởi động lại ngay lập tức.

Khi kết thúc quy trình này, thiết bị sẽ khởi động lại và cơ chế RoR sẽ mở khóa bộ nhớ được mã hóa thông tin xác thực (CE). Đối với ứng dụng, điều này xuất hiện như một người dùng mở khóa bình thường, vì vậy họ nhận được tất cả cá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

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 RebootEscrow HAL và bao gồm tệp XML đánh dấu tính năng. Việc triển khai mặc định hoạt động tốt trên các thiết bị sử dụng khởi động lại ấm (khi nguồn điện cho 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 ký quỹ

Điểm đánh dấu đối tượng địa lý 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

Khởi động lại mặc định triển khai HAL ký quỹ

Để sử dụng triển khai mặc định, bạn phải đặt trước 65536 (0x10000) byte. Không bao giờ ghi các byte này vào bộ nhớ không bay hơi để đả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 Linux

Trong cây thiết bị của nhân Linux, bạn phải dự trữ bộ nhớ cho một vùng pmem . Ví dụ sau 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ó thiết bị mới trong thư mục khối với tên như /dev/block/pmem0 (chẳng hạn như pmem1 hoặc pmem2 ).

Thay đổi Device.mk

Giả sử rằng thiết bị mới của bạn từ bước trước được đặt 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 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