파일 기반 암호화

Android 7.0 이상에서는 파일 기반 암호화(FBE)를 지원합니다. 파일 기반 암호화를 사용하면 개별적으로 잠금 해제 가능한 여러 키를 사용하여 여러 파일을 암호화할 수 있습니다.

이 문서에서는 새 기기에 파일 기반 암호화를 사용 설정하는 방법, 그리고 시스템 애플리케이션이 어떻게 Direct Boot API를 사용하여 가장 안전한 최상의 환경을 제공할 수 있는지에 대해 설명합니다.

직접 부팅

파일 기반 암호화는 Android 7.0에서 새로 도입된 기능인 직접 부팅을 지원합니다. 직접 부팅을 사용하면 암호화된 기기를 잠금 화면에 바로 부팅할 수 있습니다. 이전에는 전체 디스크 암호화(FDE)를 사용하는 암호화된 기기에서 사용자는 데이터에 액세스하려면 사용자 인증 정보를 제공해야 했으며 휴대전화는 가장 기본적인 작업만 실행할 수 있었습니다. 예를 들면 알람이 작동하지 않았고 접근성 서비스에 액세스할 수 없었고 휴대전화로 전화를 받을 수 없었으며, 기본적인 비상 전화만 사용이 가능했습니다.

애플리케이션이 암호화를 인지하도록 하기 위한 파일 기반 암호화(FBE)와 새로운 API의 도입으로 이제는 앱이 제한된 환경에서 작동할 수 있습니다. 이는 사용자가 사용자 인증 정보를 제공하기 전에 발생할 수 있으며, 비공개 사용자 정보는 계속해서 보호됩니다.

FBE가 사용 설정된 기기에서는 기기의 각 사용자가 두 개의 저장소 위치를 애플리케이션에 사용할 수 있습니다.

  • 자격증명 암호화(CE) 저장소는 기본 저장소 위치이며, 사용자가 기기의 잠금을 해제한 후에만 사용할 수 있습니다.
  • 기기 암호화(DE) 저장소는 직접 부팅 모드 시 그리고 사용자가 기기의 잠금을 해제한 후에 모두 사용할 수 있는 저장소 위치입니다.

이렇게 구분할 경우 암호화가 더 이상 부팅 시점의 비밀번호에만 의존하지 않고 2명 이상의 사용자를 동시에 보호할 수 있으므로 직장 프로필이 훨씬 안전해집니다.

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

AOSP(Android 오픈소스 프로젝트)에는 Ext4 및 F2FS 파일 시스템에서 파일 기반 암호화의 완전한 구현이 마련되어 있으며 요구사항을 충족하는 기기에서 사용 설정만 하면 됩니다. FBE를 사용하기로 결정한 제조업체는 사용된 단일 칩 시스템(SoC)에 따라 기능을 최적화하는 방법을 살펴보는 것이 좋습니다.

AOSP의 모든 필수 패키지는 직접 부팅 인식으로 업데이트되었습니다. 하지만 앱의 맞춤설정된 버전을 사용하는 기기 제조업체는 최소 다음과 같은 서비스를 제공하는 직접 부팅 인식 패키지가 있는지 확인해야 합니다.

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

예 및 소스

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

  • AOSP 다이얼러(패캐지/앱/다이얼러)
  • 탁상 시계(패키지/앱/DeskClock)
  • LatinIME(패키지/inputmethods/LatinIME)*
  • 설정 앱(패키지/앱/설정)*
  • SystemUI(프레임워크/기반/패키지/SystemUI)*

* defaultToDeviceProtectedStorage manifest 속성을 사용하는 시스템 애플리케이션

암호화를 인식하는 애플리케이션과 서비스의 추가적인 예를 확인하려면 AOSP 소스 트리의 프레임워크나 패키지 디렉터리에서 명령어 mangrep directBootAware를 실행하세요.

종속 항목

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

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

참고: 저장소 정책은 폴더와 모든 하위 폴더에 적용됩니다. 제조업체는 암호화되지 않은 콘텐츠를 OTA 폴더, 그리고 시스템을 복호화하는 키가 저장된 폴더로 제한해야 합니다. 대부분의 콘텐츠는 기기로 암호화된 저장소가 아닌 사용자 인증 정보로 암호화된 저장소에 상주해야 합니다.

구현

가장 중요한 점은 알람 시계, 전화, 접근성 기능 등의 앱이 직접 부팅 개발자 문서에 따라 android:directBootAware로 만들어져야 한다는 것입니다.

커널 지원

Ext4 및 F2FS 암호화를 위한 커널 지원은 Android 공통 커널 버전 3.18 이상에서 제공됩니다. 버전 5.1 이상의 커널에서 사용 설정하려면 다음을 사용합니다.

    CONFIG_FS_ENCRYPTION=y
    

이전 커널의 경우 기기의 userdata 파일 시스템이 Ext4라면 CONFIG_EXT4_ENCRYPTION=y를 사용하고 기기의 userdata 파일 시스템이 F2FS라면 CONFIG_F2FS_FS_ENCRYPTION=y를 사용합니다.

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

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

    CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
    CONFIG_CRYPTO_SHA2_ARM64_CE=y
    

성능을 더욱 개선하고 전력 사용량을 줄이기 위해 기기 제조업체는 인라인 암호화 하드웨어를 구현하여 저장 장치와의 데이터 송수신 중에 데이터를 암호화/복호화할 수도 있습니다. Android 공통 커널(버전 4.14 이상)에는 하드웨어 및 공급업체 드라이버 지원이 제공될 때 UFS 기반 저장소에서 인라인 암호화를 사용할 수 있는 프레임워크가 포함되어 있습니다. 인라인 암호화 프레임워크는 다음 커널 구성 옵션을 설정하여 사용할 수 있습니다.

    CONFIG_BLK_INLINE_ENCRYPTION=y
    CONFIG_FS_ENCRYPTION=y
    CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
    CONFIG_SCSI_UFS_CRYPTO=y
    

파일 기반 암호화 사용 설정

기기에서 FBE를 사용 설정하려면 내부 저장소(userdata)에서 사용 설정해야 합니다. 이렇게 하면 채택 가능한 저장소에서 자동으로 FBE가 사용 설정됩니다. 그러나 채택 가능한 저장소의 암호화 형식은 필요한 경우 재정의될 수 있습니다.

내부 저장소

FBE는 userdatafstab 줄의 fs_mgr_flags 열에 fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] 옵션을 추가하여 사용 설정됩니다. 이 옵션은 내부 저장소의 암호화 형식을 정의합니다. 콜론으로 구분된 매개변수를 최대 세 개까지 포함할 수 있습니다.

  • contents_encryption_mode 매개변수는 파일 콘텐츠를 암호화하는 데 사용되는 암호화 알고리즘을 정의합니다. aes-256-xts 또는 adiantum이 될 수 있습니다.
  • filenames_encryption_mode 매개변수는 파일 이름을 암호화하는 데 사용되는 암호화 알고리즘을 정의합니다. aes-256-cts, aes-256-heh 또는 adiantum이 될 수 있습니다. 매개변수가 지정되지 않은 경우, contents_encryption_modeaes-256-xts이면 aes-256-cts가, contents_encryption_modeadiantum이면 adiantum이 기본값으로 지정됩니다.
  • Android R의 새로운 flags 매개변수는 + 문자로 구분된 플래그 목록입니다. 지원되는 플래그는 다음과 같습니다.
    • v1 플래그는 버전 1 암호화 정책을 선택하고 v2 플래그는 버전 2 암호화 정책을 선택합니다. 버전 2 암호화 정책은 더욱 안전하고 유연한 키 파생 함수를 사용합니다. Android R 이상으로 출시된 기기(ro.product.first_api_level에 정의된 대로)는 v2를, Android 10 이하로 출시된 기기는 v1을 기본값으로 합니다.
    • inlinecrypt_optimized 플래그는 많은 수의 키를 효율적으로 처리하지 않는 인라인 암호화 하드웨어에 최적화된 암호화 형식을 선택합니다. 파일당 하나가 아닌 CE 또는 DE 키당 하나의 파일 콘텐츠 암호화 키를 도출하여 이를 실행합니다. 이에 따라 IV(초기화 벡터)의 생성이 조정됩니다.
    • wrappedkey_v0 플래그를 통해 하드웨어 래핑 키를 사용할 수 있습니다. 사용 설정되면 FBE 키는 소프트웨어에서 생성되지 않고 STORAGE_KEY 태그를 사용하여 Keymaster에서 생성됩니다. 그런 다음, 실제로 커널에 제공되는 각 FBE 키는 Keymaster에서 내보낸 STORAGE_KEY 키로, 부팅할 때마다 임시 키를 사용하여 래핑됩니다. 그 후 커널에서 래핑된 키를 인라인 암호화 하드웨어에 직접 제공합니다. 올바르게 구현되었다면 래핑되지 않은 키는 시스템 메모리에 존재하지 않으며 재부팅 후에는 손상된 래핑 키를 사용할 수 없습니다. 이 플래그는 하드웨어 지원, STORAGE_KEY용 Keymaster 지원, 커널 드라이버 지원 및 inlinecrypt 마운트 옵션이 필요합니다.

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

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

기본적으로 파일 콘텐츠 암호화는 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와 채택 가능한 저장소를 함께 사용할 수 있습니다.

또한, userdatafileencryption fstab 옵션을 지정하면 자동으로 채택 가능한 저장소에 FBE와 메타데이터 암호화가 모두 사용 설정됩니다. 하지만, PRODUCT_PROPERTY_OVERRIDES에 속성을 설정하여 채택 가능한 저장소에 FBE 및/또는 메타데이터 암호화 형식을 재정의할 수 있습니다.

Android R 이상으로 출시된 기기는 다음 속성을 사용합니다.

  • ro.crypto.volume.options(Android R의 새로운 기능)는 채택 가능한 저장소에 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는 파일 이름 암호화 모드를 선택합니다. 이는 Android 10 이하로 출시된 기기의 기본값이 aes-256-heh인 경우를 제외하고 ro.crypto.volume.options의 콜론으로 구분된 두 번째 필드와 동일합니다. 이 값은 대부분의 기기에서 명시적으로 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 R 이상에서는 암호화 정책이 더 이상 중앙 집중화된 위치에 하드코딩되지 않고 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 저장소에 의해 지원되는 컨텍스트를 명시적으로 관리할 수 있습니다. 이는 기기로 보호되는 API와 동일합니다.

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

멀티 사용자 지원

멀티 사용자 환경의 각 사용자는 별도의 암호화 키를 받습니다. 모든 사용자는 DE 및 CE 키, 이렇게 두 개의 키를 받습니다. 사용자 0은 특수 사용자이므로 먼저 기기에 로그인해야 합니다. 이는 기기 관리 용도와 관련이 있습니다.

암호화 인식 애플리케이션은 이러한 방식으로 모든 사용자와 상호작용합니다. INTERACT_ACROSS_USERSINTERACT_ACROSS_USERS_FULL은 애플리케이션이 기기의 모든 사용자에 대해 기능할 수 있도록 해줍니다. 하지만 이러한 앱은 이미 잠금 해제된 사용자와 관련하여 CE로 암호화된 디렉터리에만 액세스할 수 있습니다.

애플리케이션은 DE 영역 전체에 걸쳐 자유롭게 상호작용할 수 있지만 사용자 한 명이 잠금 해제되었다고 해서 기기의 모든 사용자가 잠금 해제되는 것은 아닙니다. 애플리케이션은 이러한 영역에 액세스하려고 하기 전에 이 상태를 확인해야 합니다.

각 직장 프로필 사용자 ID에도 DE 및 CE라는 두 개의 키가 주어집니다. 직장 보안 확인이 충족되면 프로필 사용자가 잠금 해제되며 TEE의 Keymaster는 프로필의 TEE 키를 제공할 수 있습니다.

업데이트 처리

복구 파티션은 사용자 데이터 파티션의 DE 보호 저장소에 액세스할 수 없습니다. FBE를 구현하는 기기는 A/B 시스템 업데이트를 사용하여 OTA를 지원하는 것이 좋습니다. OTA는 일반적인 작업 중에 적용할 수 있습니다. 따라서 복구 시 암호화된 드라이브의 데이터에 액세스할 필요가 없습니다.

복구 시 userdata 파티션의 OTA 파일에 액세스해야 하는 레거시 OTA 솔루션을 사용할 때에는 다음을 실행합니다.

  1. userdata 파티션에서 최상위 수준 디렉터리(예: misc_ne)를 생성합니다.
  2. 최상위 수준 디렉터리를 암호화 정책 예외(위의 암호화 정책 참조)에 추가합니다.
  3. 최상위 수준 디렉터리 내에 OTA 패키지를 보관할 디렉터리를 생성합니다.
  4. SELinux 규칙 및 파일 컨텍스트를 추가하여 이 폴더와 콘텐츠에 대한 액세스를 제어합니다. OTA 업데이트를 수신하는 프로세스나 애플리케이션만 이 폴더에 읽기 및 쓰기를 수행할 수 있습니다. 다른 어떤 애플리케이션이나 프로세스도 이 폴더에 액세스할 수 없어야 합니다.

유효성 검사

기능의 구현된 버전이 의도대로 작동하는지 확인하려면 다수의 CTS 암호화 테스트를 사용해야 합니다.

보드의 커널 빌드 후에는 QEMU에 x86을 빌드하고 실행하여 kvm-xfstests로 테스트해야 합니다. Ext4에는 다음을 사용합니다.

    kvm-xfstests -c ext4/encrypt -g auto
    

F2FS에는 다음을 사용합니다.

    kvm-xfstests -c f2fs/encrypt -g auto
    

또한 기기 제조업체는 다음과 같은 수동 테스트를 수행할 수도 있습니다. FBE가 사용 설정된 기기에서 다음을 실행합니다.

  • ro.crypto.state가 있는지 확인합니다.
    • ro.crypto.state가 암호화되어 있는지 확인합니다.
  • ro.crypto.type이 있는지 확인합니다.
    • ro.crypto.typefile로 설정되어 있는지 확인합니다.

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

AOSP 구현 세부정보

이 섹션에서는 AOSP 구현, 그리고 파일 기반 암호화의 원리에 대해 자세히 설명합니다. 기기 제조업체가 FBE 및 직접 부팅을 기기에서 사용하기 위해 여기서 내용을 변경할 필요는 없습니다.

fscrypt 암호화

AOSP 구현은 ext4 및 f2fs에서 지원하는 'fscrypt' 암호화를 커널에 사용하며, 일반적인 구성은 아래와 같습니다.

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

Adiantum 암호화도 지원됩니다. Adiantum 암호화를 사용 설정하면 파일 콘텐츠와 파일 이름 모두 Adiantum으로 암호화됩니다.

fscrypt에 관한 자세한 내용은 업스트림 커널 문서를 참조하세요.

키 파생

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

  • 인증 토큰
  • 확장된 사용자 인증 정보
  • 'secdiscardable 해시'

인증 토큰은 사용자가 성공적으로 로그인할 때 게이트키퍼에 의해 생성되는 암호화 방식으로 인증된 토큰입니다. TEE는 올바른 인증 토큰이 제공되지 않은 이상 키 사용을 거부합니다. 사용자에게 사용자 인증 정보가 없으면 어떤 인증 토큰도 사용되지 않고 필요도 없습니다.

확장된 사용자 인증 정보scrypt 알고리즘으로 솔팅 및 확장을 거친 사용자 인증 정보입니다. 사용자 인증 정보는 vold에 이어 scrypt로 전달되기 전에 잠금 설정 서비스에서 실제로 1회 해시됩니다. 이는 암호화 방식으로 TEE의 키에 바운드되며 KM_TAG_APPLICATION_ID에 적용되는 모든 보증을 포함합니다. 사용자에게 사용자 인증 정보가 없으면 어떤 확장된 사용자 인증 정보도 사용되지 않고 필요도 없습니다.

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

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