파일 기반 암호화

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Android 7.0 이상은 파일 기반 암호화(FBE)를 지원합니다. 파일 기반 암호화를 사용하면 독립적으로 잠금 해제할 수 있는 다른 키로 다른 파일을 암호화할 수 있습니다.

이 문서에서는 새 장치에서 파일 기반 암호화를 활성화하는 방법과 시스템 응용 프로그램에서 Direct Boot API를 사용하여 사용자에게 가장 안전하고 최상의 환경을 제공하는 방법을 설명합니다.

직접 부팅

파일 기반 암호화를 사용하면 Android 7.0에 도입된 Direct Boot 라는 새로운 기능을 사용할 수 있습니다. Direct Boot를 사용하면 암호화된 장치를 잠금 화면으로 바로 부팅할 수 있습니다. 이전에는 전체 디스크 암호화 (FDE)를 사용하는 암호화된 장치에서 사용자가 데이터에 액세스하기 전에 자격 증명을 제공해야 했기 때문에 전화기에서 가장 기본적인 작업을 제외한 모든 작업을 수행할 수 없었습니다. 예를 들어, 알람이 작동하지 않고, 접근성 서비스를 사용할 수 없으며, 전화는 전화를 받을 수 없지만 기본적인 긴급 다이얼러 작동으로 제한되었습니다.

파일 기반 암호화(FBE) 및 애플리케이션이 암호화를 인식하도록 하는 새로운 API의 도입으로 이러한 앱은 제한된 컨텍스트 내에서 작동할 수 있습니다. 이는 사용자가 개인 사용자 정보를 계속 보호하면서 자격 증명을 제공하기 전에 발생할 수 있습니다.

FBE 지원 장치에서 장치의 각 사용자는 응용 프로그램에 사용할 수 있는 두 개의 저장 위치를 ​​가집니다.

  • CE(자격 증명 암호화) 저장소는 기본 저장소 위치이며 사용자가 장치를 잠금 해제한 후에만 사용할 수 있습니다.
  • DE(장치 암호화) 저장소는 직접 부팅 모드 동안과 사용자가 장치를 잠금 해제한 후에 사용할 수 있는 저장소 위치입니다.

이렇게 분리하면 암호화가 더 이상 부팅 시 암호에만 기반하지 않으므로 한 번에 두 명 이상의 사용자를 보호할 수 있으므로 직장 프로필의 보안이 강화됩니다.

Direct Boot API를 사용하면 암호화 인식 응용 프로그램이 이러한 각 영역에 액세스할 수 있습니다. 잠금 화면에서 사용자 인증 정보를 처음 입력한 것에 대한 응답으로 사용자의 CE 저장소가 잠금 해제 될 때 또는 직장 프로필이 직장 챌린지 를 제공하는 경우 애플리케이션에 알려야 하는 필요성을 수용하기 위해 애플리케이션 수명 주기가 변경되었습니다. Android 7.0을 실행하는 기기는 FBE 구현 여부에 관계없이 이러한 새로운 API 및 수명 주기를 지원해야 합니다. FBE가 없으면 DE 및 CE 스토리지는 항상 잠금 해제 상태입니다.

Ext4 및 F2FS 파일 시스템에서 파일 기반 암호화의 완전한 구현은 AOSP(Android 오픈 소스 프로젝트)에서 제공되며 요구 사항을 충족하는 장치에서만 활성화하면 됩니다. FBE를 사용하기로 선택한 제조업체는 사용된 SoC(시스템 온 칩)를 기반으로 기능을 최적화하는 방법을 모색할 수 있습니다.

AOSP의 모든 필수 패키지는 직접 부팅을 인식하도록 업데이트되었습니다. 그러나 장치 제조업체가 이러한 앱의 맞춤형 버전을 사용하는 경우 최소한 다음 서비스를 제공하는 직접 부팅 인식 패키지가 있는지 확인하기를 원할 것입니다.

  • 전화 서비스 및 다이얼러
  • 잠금 화면에 비밀번호를 입력하는 방법

예제 및 소스

Android는 vold( system/vold )가 Android에서 저장 장치 및 볼륨을 관리하기 위한 기능을 제공하는 파일 기반 암호화의 참조 구현을 제공합니다. FBE를 추가하면 vold에 여러 사용자의 CE 및 DE 키에 대한 키 관리를 지원하는 몇 가지 새로운 명령이 제공됩니다. 커널에서 파일 기반 암호화 기능을 사용하기 위한 핵심 변경 사항 외에도 잠금 화면 및 SystemUI를 포함한 많은 시스템 패키지가 FBE 및 직접 부팅 기능을 지원하도록 수정되었습니다. 여기에는 다음이 포함됩니다.

  • AOSP 다이얼러(패키지/앱/다이얼러)
  • 탁상 시계(패키지/앱/DeskClock)
  • LatinIME(패키지/입력 방법/LatinIME)*
  • 설정 앱(패키지/앱/설정)*
  • SystemUI(프레임워크/베이스/패키지/SystemUI)*

* defaultToDeviceProtectedStorage 매니페스트 속성을 사용하는 시스템 애플리케이션

암호화를 인식하는 애플리케이션 및 서비스의 더 많은 예는 AOSP 소스 트리의 프레임워크 또는 패키지 디렉토리에서 mangrep directBootAware 명령을 실행하여 찾을 수 있습니다.

종속성

FBE의 AOSP 구현을 안전하게 사용하려면 기기가 다음 종속성을 충족해야 합니다.

  • Ext4 암호화 또는 F2FS 암호화에 대한 커널 지원 .
  • HAL 버전 1.0 또는 2.0에서 Keymaster 지원 . Keymaster 0.3은 필요한 기능을 제공하지 않거나 암호화 키에 대한 충분한 보호를 보장하지 않으므로 지원되지 않습니다.
  • 키마스터/키 저장소 및 게이트키퍼 는 인증되지 않은 OS(장치에 플래시된 사용자 지정 OS)가 단순히 DE 키를 요청할 수 없도록 DE 키를 보호하기 위해 TEE( 신뢰할 수 있는 실행 환경 )에서 구현되어야 합니다.
  • 인증되지 않은 운영 체제에서 장치 암호화 자격 증명에 액세스할 수 없도록 하려면 keymaster 초기화에 바인딩된 하드웨어 신뢰 루트 및 자체 검사 부팅 이 필요합니다.

참고 : 저장소 정책은 폴더 및 모든 하위 폴더에 적용됩니다. 제조업체는 암호화되지 않은 콘텐츠를 OTA 폴더와 시스템을 해독하는 키가 있는 폴더로 제한해야 합니다. 대부분의 콘텐츠는 장치 암호화 저장소가 아닌 자격 증명 암호화 저장소에 있어야 합니다.

구현

무엇보다도 알람 시계, 전화, 접근성 기능과 같은 앱은 Direct Boot 개발자 문서에 따라 android:directBootAware로 만들어야 합니다.

커널 지원

Ext4 및 F2FS 암호화에 대한 커널 지원은 Android 공통 커널 버전 3.18 이상에서 사용할 수 있습니다. 버전 5.1 이상의 커널에서 활성화하려면 다음을 사용하십시오.

CONFIG_FS_ENCRYPTION=y

이전 커널의 경우 장치의 userdata 데이터 파일 시스템이 Ext4이면 CONFIG_EXT4_ENCRYPTION=y 를 사용하고 장치의 사용자 데이터 파일 시스템이 userdata 이면 CONFIG_F2FS_FS_ENCRYPTION=y 를 사용합니다.

장치가 채택 가능한 저장소 를 지원하거나 내부 저장소에서 메타데이터 암호화 를 사용할 경우 메타데이터 암호화 설명서 에 설명된 대로 메타데이터 암호화에 필요한 커널 구성 옵션도 활성화합니다.

Ext4 또는 F2FS 암호화에 대한 기능 지원 외에도 장치 제조업체는 암호화 가속을 활성화하여 파일 기반 암호화 속도를 높이고 사용자 경험을 개선해야 합니다. 예를 들어 ARM64 기반 장치에서 ARMv8 CE(Cryptography Extensions) 가속은 다음 커널 구성 옵션을 설정하여 활성화할 수 있습니다.

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

성능을 더욱 향상시키고 전력 사용량을 줄이기 위해 장치 제조업체는 인라인 암호화 하드웨어 구현을 고려할 수도 있습니다. 이 하드웨어는 데이터가 저장 장치로/로부터 오는 동안 데이터를 암호화/복호화합니다. Android 공통 커널(버전 4.14 이상)에는 하드웨어 및 공급업체 드라이버 지원이 가능할 때 인라인 암호화를 사용할 수 있는 프레임워크가 포함되어 있습니다. 인라인 암호화 프레임워크는 다음 커널 구성 옵션을 설정하여 활성화할 수 있습니다.

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

장치가 UFS 기반 저장소를 사용하는 경우 다음도 활성화합니다.

CONFIG_SCSI_UFS_CRYPTO=y

장치가 eMMC 기반 저장소를 사용하는 경우 다음도 활성화합니다.

CONFIG_MMC_CRYPTO=y

파일 기반 암호화 활성화

장치에서 FBE를 활성화하려면 내부 저장소( userdata )에서 활성화해야 합니다. 또한 채택 가능한 스토리지에서 FBE를 자동으로 활성화합니다. 그러나 필요한 경우 채택 가능한 저장소의 암호화 형식을 무시할 수 있습니다.

내부 저장소

FBE는 fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] 옵션을 userdata 에 대한 fstab 행의 fs_mgr_flags 열에 추가하여 활성화됩니다. 이 옵션은 내부 저장소의 암호화 형식을 정의합니다. 콜론으로 구분된 최대 3개의 매개변수를 포함합니다.

  • contents_encryption_mode 매개변수는 파일 내용을 암호화하는 데 사용되는 암호화 알고리즘을 정의합니다. aes-256-xts 또는 adiantum 일 수 있습니다. Android 11부터는 기본 알고리즘인 aes-256-xts 를 지정하기 위해 비워둘 수도 있습니다.
  • filenames_encryption_mode 매개변수는 파일 이름을 암호화하는 데 사용되는 암호화 알고리즘을 정의합니다. aes-256-cts , aes-256-heh , adiantum 또는 aes-256-hctr2 있습니다. 지정하지 않으면 content_encryption_mode 가 aes-256- adiantum 인 경우 기본값은 aes-256-cts 이고 contents_encryption_mode aes-256-xts 인 경우 contents_encryption_mode adiantum .
  • Android 11에 새로 추가된 flags 매개변수는 + 문자로 구분된 플래그 목록입니다. 다음 플래그가 지원됩니다.
    • v1 플래그는 버전 1 암호화 정책을 선택합니다. v2 플래그는 버전 2 암호화 정책을 선택합니다. 버전 2 암호화 정책은 보다 안전하고 유연한 키 파생 기능 을 사용합니다. 기본값은 기기가 Android 11 이상( ro.product.first_api_level 에 의해 결정됨)에서 시작된 경우 v2이고, 기기가 Android 10 이하에서 시작된 경우 v1입니다.
    • inlinecrypt_optimized 플래그는 많은 수의 키를 효율적으로 처리하지 않는 인라인 암호화 하드웨어에 최적화된 암호화 형식을 선택합니다. 파일당 하나가 아니라 CE 또는 DE 키당 하나의 파일 콘텐츠 암호화 키를 파생하여 이를 수행합니다. 이에 따라 IV(초기화 벡터)의 생성이 조정됩니다.
    • emmc_optimized 플래그는 inlinecrypt_optimized 와 유사하지만 IV를 32비트로 제한하는 IV 생성 방법도 선택합니다. 이 플래그는 JEDEC eMMC v5.2 사양을 준수하므로 32비트 IV만 지원하는 인라인 암호화 하드웨어에서만 사용해야 합니다. 다른 인라인 암호화 하드웨어에서는 대신 inlinecrypt_optimized 를 사용하십시오. 이 플래그는 UFS 기반 저장소에서 사용하면 안 됩니다. UFS 사양은 64비트 IV의 사용을 허용합니다.
    • 하드웨어 래핑 키 를 지원하는 기기에서 wrappedkey_v0 플래그를 사용하면 FBE에 하드웨어 래핑 키를 사용할 수 있습니다. 이것은 inlinecrypt 마운트 옵션 및 inlinecrypt_optimized 또는 emmc_optimized 플래그와 함께만 사용할 수 있습니다.

인라인 암호화 하드웨어를 사용하지 않는 경우 대부분의 장치에 권장되는 설정은 fileencryption=aes-256-xts 입니다. 인라인 암호화 하드웨어를 사용하는 경우 대부분의 장치에 권장되는 설정은 fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (또는 동등하게 fileencryption=::inlinecrypt_optimized )입니다. AES 가속이 없는 장치에서는 fileencryption=adiantum 을 설정하여 AES 대신 Adiantum 을 사용할 수 있습니다.

Android 14(AOSP 실험 중) 이후로 AES-HCTR2는 가속 암호화 지침이 있는 기기에 선호되는 파일 이름 암호화 모드입니다. 그러나 최신 Android 커널만 AES-HCTR2를 지원합니다. 향후 Android 릴리스에서는 파일 이름 암호화의 기본 모드가 될 예정입니다. 커널에 AES-HCTR2 지원이 있는 경우 filenames_encryption_modeaes-256-hctr2 로 설정하여 파일 이름 암호화를 활성화할 수 있습니다. 가장 간단한 경우 이것은 fileencryption=aes-256-xts:aes-256-hctr2 됩니다.

Android 10 이하로 출시된 기기에서는 FSCRYPT_MODE_PRIVATE 파일 콘텐츠 암호화 모드의 사용을 지정하기 위해 fileencryption=ice 도 허용됩니다. 이 모드는 Android 공통 커널에 의해 구현되지 않지만 사용자 지정 커널 패치를 사용하여 공급업체에서 구현할 수 있습니다. 이 모드에서 생성된 온디스크 형식은 공급업체에 따라 다릅니다. Android 11 이상으로 실행되는 기기에서는 이 모드가 더 이상 허용되지 않으며 대신 표준 암호화 형식을 사용해야 합니다.

기본적으로 파일 내용 암호화는 Linux 커널의 암호화 API를 사용하여 수행됩니다. 인라인 암호화 하드웨어를 대신 사용하려면 inlinecrypt 마운트 옵션도 추가하십시오. 예를 들어 전체 fstab 행은 다음과 같습니다.

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

채택 가능한 스토리지

Android 9부터 FBE와 채택 가능한 스토리지 를 함께 사용할 수 있습니다.

userdata 에 대해 fileencryption fstab 옵션을 지정하면 채택 가능한 스토리지에서 FBE와 메타데이터 암호화 가 모두 자동으로 활성화됩니다. 그러나 PRODUCT_PROPERTY_OVERRIDES 에서 속성을 설정하여 채택 가능한 스토리지에서 FBE 및/또는 메타데이터 암호화 형식을 재정의할 수 있습니다.

Android 11 이상으로 출시된 기기에서 다음 속성을 사용하세요.

  • ro.crypto.volume.options (Android 11의 새로운 기능)는 채택 가능한 저장소에서 FBE 암호화 형식을 선택합니다. fileencryption fstab 옵션에 대한 인수와 동일한 구문을 가지며 동일한 기본값을 사용합니다. 여기에서 사용할 항목은 위의 fileencryption 권장 사항을 참조하십시오.
  • ro.crypto.volume.metadata.encryption 은 채택 가능한 스토리지에서 메타데이터 암호화 형식을 선택합니다. 메타데이터 암호화 문서 를 참조하십시오.

Android 10 이하로 출시된 기기에서는 다음 속성을 사용하세요.

  • ro.crypto.volume.contents_mode 는 콘텐츠 암호화 모드를 선택합니다. 이는 ro.crypto.volume.options 의 첫 번째 콜론으로 구분된 필드와 동일합니다.
  • ro.crypto.volume.filenames_mode 는 파일 이름 암호화 모드를 선택합니다. 이것은 ro.crypto.volume.options 의 두 번째 콜론으로 구분된 필드와 동일하지만 Android 10 이하로 실행된 기기의 기본값은 aes-256-heh 입니다. 대부분의 기기에서 이는 aes-256-cts 로 명시적으로 재정의해야 합니다.
  • ro.crypto.fde_algorithmro.crypto.fde_sector_size 는 채택 가능한 스토리지에서 메타데이터 암호화 형식을 선택합니다. 메타데이터 암호화 문서 를 참조하십시오.

Keymaster와 통합

키 생성 및 커널 키링 관리는 vold 에 의해 처리됩니다. FBE의 AOSP 구현을 위해서는 기기가 Keymaster HAL 버전 1.0 이상을 지원해야 합니다. 이전 버전의 Keymaster HAL은 지원되지 않습니다.

처음 부팅할 때 사용자 0의 키가 생성되어 부팅 프로세스 초기에 설치됩니다. initon-post-fs 단계가 완료될 때까지 Keymaster는 요청을 처리할 준비가 되어 있어야 합니다. Pixel 장치에서 이것은 스크립트 블록이 /data 가 마운트되기 전에 Keymaster가 시작되도록 하여 처리됩니다.

암호화 정책

파일 기반 암호화는 디렉터리 수준에서 암호화 정책을 적용합니다. 장치의 userdata 파티션이 처음 생성될 때 기본 구조와 정책은 init 스크립트에 의해 적용됩니다. 이 스크립트는 첫 번째 사용자(사용자 0)의 CE 및 DE 키 생성을 트리거할 뿐만 아니라 이러한 키로 암호화할 디렉토리를 정의합니다. 추가 사용자 및 프로필이 생성되면 필요한 추가 키가 생성되어 키 저장소에 저장됩니다. 자격 증명 및 장치 저장 위치가 생성되고 암호화 정책이 이러한 키를 해당 디렉터리에 연결합니다.

Android 11 이상에서 암호화 정책은 더 이상 중앙 집중식 위치에 하드코딩되지 않고 init 스크립트의 mkdir 명령에 대한 인수로 정의됩니다. 시스템 DE 키로 암호화된 디렉터리는 encryption=Require 를 사용하는 반면 암호화되지 않은 디렉터리(또는 하위 디렉터리가 사용자별 키로 암호화된 디렉터리)는 encryption=None 을 사용합니다.

Android 10에서 암호화 정책은 다음 위치에 하드코딩되었습니다.

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Android 9 및 이전 버전에서 위치는 다음과 같습니다.

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

특정 디렉토리가 전혀 암호화되지 않도록 예외를 추가할 수 있습니다. 이러한 종류의 수정이 이루어진 경우 장치 제조업체는 암호화되지 않은 디렉터리를 사용해야 하는 응용 프로그램에만 액세스 권한을 부여하는 SELinux 정책 을 포함해야 합니다. 이것은 모든 신뢰할 수 없는 응용 프로그램을 제외해야 합니다.

이에 대해 알려진 유일한 사용 사례는 레거시 OTA 기능을 지원하는 것입니다.

시스템 응용 프로그램에서 직접 부팅 지원

응용 프로그램 직접 부팅 인식 만들기

시스템 앱의 신속한 마이그레이션을 용이하게 하기 위해 애플리케이션 수준에서 설정할 수 있는 두 가지 새로운 속성이 있습니다. defaultToDeviceProtectedStorage 속성은 시스템 앱에서만 사용할 수 있습니다. directBootAware 속성은 모두가 사용할 수 있습니다.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

애플리케이션 수준의 directBootAware 속성은 앱의 모든 구성 요소를 암호화 인식으로 표시하기 위한 약식입니다.

defaultToDeviceProtectedStorage 속성은 기본 앱 저장소 위치를 CE 저장소를 가리키는 대신 DE 저장소를 가리키도록 리디렉션합니다. 이 플래그를 사용하는 시스템 앱은 기본 위치에 저장된 모든 데이터를 주의 깊게 감사하고 CE 스토리지를 사용하도록 민감한 데이터의 경로를 변경해야 합니다. 이 옵션을 사용하는 장치 제조업체는 저장하는 데이터에 개인 정보가 포함되어 있지 않은지 주의 깊게 검사해야 합니다.

이 모드에서 실행할 때 다음 시스템 API를 사용하여 필요할 때 CE 저장소가 지원하는 컨텍스트를 명시적으로 관리할 수 있습니다. 이는 장치 보호 대응과 동일합니다.

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

여러 사용자 지원

다중 사용자 환경의 각 사용자는 별도의 암호화 키를 받습니다. 모든 사용자는 DE와 CE 키의 두 가지 키를 받습니다. 사용자 0은 특수 사용자이므로 먼저 장치에 로그인해야 합니다. 이것은 장치 관리 용도와 관련이 있습니다.

암호화 인식 응용 프로그램은 다음과 같은 방식으로 사용자 간에 상호 작용합니다. INTERACT_ACROSS_USERSINTERACT_ACROSS_USERS_FULL 을 사용하면 응용 프로그램이 장치의 모든 사용자에 대해 작동할 수 있습니다. 그러나 이러한 앱은 이미 잠금이 해제된 사용자의 CE 암호화 디렉터리에만 액세스할 수 있습니다.

응용 프로그램은 DE 영역에서 자유롭게 상호 작용할 수 있지만 한 명의 사용자가 잠금 해제되어 있다고 해서 장치의 모든 사용자가 잠금 해제된 것은 아닙니다. 애플리케이션은 이러한 영역에 액세스하기 전에 이 상태를 확인해야 합니다.

각 직장 프로필 사용자 ID에는 DE와 CE라는 두 개의 키도 있습니다. 작업 챌린지가 충족되면 프로필 사용자의 잠금이 해제되고 Keymaster(TEE)가 프로필의 TEE 키를 제공할 수 있습니다.

업데이트 처리

복구 파티션은 사용자 데이터 파티션의 DE 보호 스토리지에 액세스할 수 없습니다. FBE를 구현하는 기기는 A/B 시스템 업데이트 를 사용하여 OTA를 지원하는 것이 좋습니다. OTA는 정상 작동 중에 적용될 수 있으므로 암호화된 드라이브의 데이터에 액세스하기 위해 복구할 필요가 없습니다.

userdata 데이터 파티션의 OTA 파일에 액세스하기 위해 복구가 필요한 레거시 OTA 솔루션을 사용하는 경우:

  1. userdata 파티션에 최상위 디렉토리(예: misc_ne )를 만듭니다.
  2. 암호화 정책 예외에 이 최상위 디렉터리를 추가합니다(위의 암호화 정책 참조).
  3. OTA 패키지를 보관할 최상위 디렉터리 내에 디렉터리를 만듭니다.
  4. SELinux 규칙 및 파일 컨텍스트를 추가하여 이 폴더와 해당 콘텐츠에 대한 액세스를 제어합니다. OTA 업데이트를 받는 프로세스 또는 응용 프로그램만 이 폴더를 읽고 쓸 수 있어야 합니다. 다른 응용 프로그램이나 프로세스는 이 폴더에 액세스할 수 없습니다.

확인

기능의 구현된 버전이 의도한 대로 작동하는지 확인하려면 먼저 DirectBootHostTestEncryptionTest 와 같은 많은 CTS 암호화 테스트를 실행하십시오.

기기에서 Android 11 이상을 실행하는 경우 vts_kernel_encryption_test 도 실행합니다.

atest vts_kernel_encryption_test

또는:

vts-tradefed run vts -m vts_kernel_encryption_test

또한 장치 제조업체는 다음과 같은 수동 테스트를 수행할 수 있습니다. FBE가 활성화된 기기:

  • ro.crypto.state 가 존재하는지 확인
    • ro.crypto.state 가 암호화되었는지 확인
  • ro.crypto.type 이 존재하는지 확인
    • ro.crypto.typefile 로 설정되어 있는지 확인하십시오.

또한 테스터는 기본 사용자에 설정된 잠금 화면으로 userdebug 인스턴스를 부팅할 수 있습니다. 그런 다음 adb 셸을 장치에 넣고 su 를 사용하여 루트가 됩니다. /data/data 에 암호화된 파일 이름이 포함되어 있는지 확인하십시오. 그렇지 않으면 문제가 있는 것입니다.

장치 제조업체는 또한 장치 또는 커널 에서 fscrypt에 대한 업스트림 Linux 테스트를 실행하는 방법을 탐색하는 것이 좋습니다. 이 테스트는 xfstests 파일 시스템 테스트 제품군의 일부입니다. 그러나 이러한 업스트림 테스트는 Android에서 공식적으로 지원되지 않습니다.

AOSP 구현 세부정보

이 섹션에서는 AOSP 구현에 대한 세부 정보를 제공하고 파일 기반 암호화 작동 방식을 설명합니다. 장치 제조업체가 장치에서 FBE 및 직접 부팅을 사용하기 위해 여기에서 변경할 필요는 없습니다.

fscrypt 암호화

AOSP 구현은 커널에서 "fscrypt" 암호화(ext4 및 f2fs에서 지원)를 사용하며 일반적으로 다음과 같이 구성됩니다.

  • XTS 모드에서 AES-256으로 파일 내용 암호화
  • CBC-CTS 모드에서 AES-256으로 파일 이름 암호화

Adiantum 암호화 도 지원됩니다. Adiantum 암호화가 활성화되면 파일 내용과 파일 이름이 모두 Adiantum으로 암호화됩니다.

fscrypt에 대한 자세한 내용은 업스트림 커널 설명서 를 참조하십시오.

키 파생

512비트 키인 파일 기반 암호화 키는 TEE에 보관된 다른 키(256비트 AES-GCM 키)에 의해 암호화되어 저장됩니다. 이 TEE 키를 사용하려면 세 가지 요구 사항이 충족되어야 합니다.

  • 인증 토큰
  • 확장된 자격 증명
  • "secdiscardable 해시"

인증 토큰 은 사용자가 성공적으로 로그인할 때 Gatekeeper 에 의해 생성된 암호로 인증된 토큰입니다. TEE는 올바른 인증 토큰이 제공되지 않는 한 키 사용을 거부합니다. 사용자에게 자격 증명이 없으면 인증 토큰이 사용되거나 필요하지 않습니다.

확장된 자격 증명scrypt 알고리즘으로 솔트 및 스트레칭 후 사용자 자격 증명입니다. 자격 증명은 scrypt 에 전달하기 위해 vold 에 전달되기 전에 잠금 설정 서비스에서 실제로 한 번 해싱됩니다. 이것은 KM_TAG_APPLICATION_ID 에 적용되는 모든 보장과 함께 TEE의 키에 암호로 바인딩됩니다. 사용자에게 자격 증명이 없으면 확장된 자격 증명이 사용되거나 필요하지 않습니다.

secdiscardable hash 는 시드와 같은 키를 재구성하는 데 사용되는 다른 정보와 함께 저장된 임의의 16KB 파일의 512비트 해시입니다. 이 파일은 키가 삭제될 때 안전하게 삭제되거나 새로운 방식으로 암호화됩니다. 이 추가된 보호 기능을 통해 공격자는 키를 복구하기 위해 안전하게 삭제된 파일의 모든 비트를 복구해야 합니다. 이것은 KM_TAG_APPLICATION_ID 에 적용되는 모든 보장과 함께 TEE의 키에 암호로 바인딩됩니다.

대부분의 경우 FBE 키는 파일별 또는 모드별 키와 같이 실제로 암호화를 수행하는 데 사용되는 하위 키를 생성하기 위해 커널에서 추가 키 파생 단계를 거칩니다. 버전 2 암호화 정책의 경우 이를 위해 HKDF-SHA512가 사용됩니다.