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

Khi một OTA sẽ được tải về và chuẩn bị để được áp dụng thông qua bản cập nhật A / B , ảo A / B , hoặc phương pháp khác có sẵn thông qua lớp RecoverySystem , Resume-on-Khởi động lại sẽ cố gắng mở khóa lưu trữ Credential được mã hóa (CE) sau khi khởi động lại thiết bị để áp dụng OTA. Điều này có thể được ghép nối với hệ thống OTA áp dụng các bản cập nhật khi thuận tiện hơn cho người dùng, chẳng hạn như thời gian thiết bị dự kiến ​​ở chế độ chờ.

Tiểu sử

Đối với các nhà phát triển ứng dụng, Android hỗ trợ Boot Direct cho phép các ứng dụng để khởi động trước khi (CE) lưu trữ Credential mã hóa được mở khóa bởi người sử dụng. Khi nhiều nhà phát triển ứng dụng triển khai hỗ trợ Khởi động trực tiếp, người dùng có 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ủa họ được nhập sau khi khởi động.

Resume-on-Reboot cho phép mở khóa bộ nhớ CE của tất cả các ứng dụng, bao gồm cả những ứng dụng chưa hỗ trợ Direct Boot, sau khi khởi động lại bằng 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ọ sau khi khởi động lại.

Mô hình mối đe dọa

Việc triển khai Tiếp tục khi khởi động lại phải bảo toàn tài sản mà khi thiết bị rơi vào tay kẻ tấn công, kẻ tấn công đó 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à người dùng đã mở khóa thiết bị sau khi nhận được OTA; để chống lại cuộc tấn công nội bộ, chúng tôi cũng giả định rằng kẻ tấn công có quyền truy cập vào các khóa ký mật mã phát sóng.

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

  • 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 OTA.
  • Có thể sửa đổi hoạt động của bất kỳ phần cứng nào (Bộ xử lý ứng dụng, flash, v.v.) ngoại trừ được nêu chi tiết bên dưới, nhưng việc sửa đổi đó liên quan đến độ trễ ít nhất một giờ và chu kỳ năng lượng phá hủy nội dung RAM.
  • 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 không thể nhập thông tin đăng nhập của người dùng.

Hướng dẫn cho người triển khai

Kể từ tháng 7 năm 2020, việc triển khai Resume-on-Reboot 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 hoặc SoC của thiết bị hỗ trợ vùng phủ cứng an toàn (bộ đồng xử lý bảo mật rời với RAM và ROM riêng), thì ngoài ra nó phải:
    • 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; nghĩa 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 Resume-on-Reboot theo cách khiến người trong cuộc hoặc những kẻ tấn công không thể khôi phục nó.

Ký quỹ RAM mặc định

AOSP có một triển khai HAL tiếp tục khi khởi động lại 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ỉ khi 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 bên dưới.

Khi một OTA sẽ được tải về và chuẩn bị để được áp dụng bằng phương pháp A / cập nhật B , ảo A / B , hoặc phương pháp khác có sẵn thông qua lớp RecoverySystem , Resume-on-Khởi động lại sẽ cố gắng mở khóa lưu trữ Credential được mã hóa (CE) sau khi thiết bị khởi động lại để áp dụng bản cập nhật OTA. Điều này có thể được ghép nối với hệ thống OTA áp dụng các bản cập nhật khi thuận tiện hơn cho người dùng, chẳng hạn như thời gian thiết bị dự kiến ​​ở chế độ chờ.

Quy trình cập nhật OTA sử dụng Tiếp tục khi khởi động lại

Ứng dụng OTA khách hàng qua điện thoại phải có Manifest.permission.REBOOTManifest.permisson.RECOVERY quyền để gọi các phương pháp cần thiết để thực hiện Resume-on-Khởi động lại. Với điều kiện tiên quyết đó, quy trình cập nhật là:

  1. Cập nhật lượt tải xuống ứng dụng khách OTA
  2. OTA ứng dụng client cuộc gọi đến RecoverySystem#prepareForUnattendedUpdate mà gây nên người dùng được nhắc nhập mã PIN của họ, khuôn mẫu, hoặc mật khẩu trên màn hình khóa trong khóa tiếp theo
  3. Khi người dùng mở khóa thiết bị tiếp theo ở màn hình khóa, thiết bị đã sẵn sàng để áp dụng bản cập nhật
  4. OTA cuộc gọi ứng dụng client để RecoverySystem#rebootAndApply mà ngay lập tức gây nên mộ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à cơ chế Tiếp tục khi khởi động lại sẽ mở khóa bộ nhớ được mã hóa thông tin xác thực (CE). Để ứng dụng, xuất hiện điều này như một mở khóa người dùng bình thường, vì vậy mà họ nhận được tất cả các tín hiệu, chẳng hạn như ACTION_LOCKED_BOOT_COMPLETEDACTION_BOOT_COMPLETED khi họ bình thường.

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 Tiếp tục khi Khởi động lại, sản phẩm đó phải bao gồm việc 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 (nghĩa là, nguồn điện không bị loại bỏ khỏi DRAM 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, 65536 (0x10000) byte phải được dành riêng cho việc triển khai. Các byte này không được ghi vào bộ lưu trữ không bay hơi để giữ các thuộc tính bảo mật.

Thay đổi cây thiết bị nhân Linux

Trong cây thiết bị hạt nhân của Linux, bạn phải dành bộ nhớ cho một pmem khu vực. Trong ví dụ sau 0x50000000 đã được dành riêng:

  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 với một cái tên như /dev/block/pmem0 (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 pmem0 , các mục mới sau đây phải đượ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

Mục mới của thiết bị file_contexts phải được thêm vào:

/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