FIPS 140-3 인증 GKI 암호화 모듈

GKI 커널에는 암호화 소프트웨어 모듈에 대한 FIPS 140-3 요구 사항을 준수하는 fips140.ko 라는 Linux 커널 모듈이 포함되어 있습니다. 이 모듈은 GKI 커널을 실행하는 제품에 필요한 경우 FIPS 인증을 위해 제출할 수 있습니다.

특히 다음 FIPS 140-3 요구 사항은 암호화 루틴을 사용하기 전에 충족되어야 합니다.

  • 모듈은 암호화 알고리즘을 사용 가능하게 만들기 전에 자체 무결성을 확인해야 합니다.
  • 모듈은 사용 가능하도록 하기 전에 알려진 답변 자체 테스트를 사용하여 승인된 암호화 알고리즘을 실행하고 확인해야 합니다.

별도의 커널 모듈을 사용해야 하는 이유

FIPS 140-3 검증은 소프트웨어 또는 하드웨어 기반 모듈이 일단 인증되면 절대 변경되지 않는다는 아이디어를 기반으로 합니다. 변경된 경우 재인증을 받아야 합니다. 이것은 오늘날 사용 중인 소프트웨어 개발 프로세스와 쉽게 일치하지 않으며, 이 요구 사항의 결과로 FIPS 소프트웨어 모듈은 일반적으로 암호화와 관련되지 않은 변경 사항이 다음을 수행할 수 있도록 최대한 암호화 구성 요소에 집중하도록 설계되었습니다. 암호화 재평가가 필요하지 않습니다.

GKI 커널은 지원되는 전체 수명 동안 정기적으로 업데이트됩니다. 이로 인해 전체 커널이 FIPS 모듈 경계 내에 있도록 할 수 없습니다. 이러한 모듈은 모든 커널 업데이트 시 재인증되어야 하기 때문입니다. 또한 GKI는 LTO(Link Time Optimization)가 활성화된 상태로 컴파일되는데, LTO는 중요한 보안 기능인 CFI 의 전제 조건이기 때문입니다. 이렇게 하면 커널의 암호화 코드 주위에 FIPS 모듈 경계를 그리는 것이 불가능합니다. 이러한 코드는 결과 바이너리에서 명확하게 정의된 위치에 있지 않기 때문입니다. 커널 업데이트는 암호화 코드를 변경할 수도 있습니다.

따라서 FIPS 140-3 요구 사항에서 다루는 모든 코드는 빌드된 GKI 커널 소스에 의해 노출된 안정적인 인터페이스에만 의존하는 별도의 커널 모듈 fips140.ko 로 패키징됩니다. 이것은 모듈이 같은 세대의 다른 GKI 릴리스와 함께 사용될 수 있음을 보장하고, 모듈 자체에 의해 전달되는 코드에서 문제가 수정된 경우에만 인증을 위해 업데이트하고 다시 제출해야 합니다.

모듈을 사용하는 경우

GKI 커널 자체는 FIPS 140-3 커널 모듈에도 패키징된 암호화 루틴에 의존하는 코드를 전달합니다. 따라서 내장된 암호화 루틴은 실제로 GKI 커널 외부로 이동하는 것이 아니라 모듈에 복사됩니다. 모듈이 로드되면 내장된 암호화 루틴이 Linux CryptoAPI에서 등록 취소되고 모듈이 전달하는 루틴으로 대체됩니다.

즉, fips140.ko 모듈은 완전히 선택 사항이며 FIPS 140-3 인증이 요구 사항인 경우에만 배포하는 것이 좋습니다. 그 외에 모듈은 추가 기능을 제공하지 않으며 불필요하게 로드하면 이점을 제공하지 않고 부팅 시간에만 영향을 줄 수 있습니다.

모듈을 배포하는 방법

모듈은 다음 단계를 사용하여 Android 빌드에 통합할 수 있습니다.

  • BOARD_VENDOR_RAMDISK_KERNEL_MODULES 에 모듈 이름을 추가하십시오. 이로 인해 모듈이 공급업체 램디스크에 복사됩니다.
  • BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD 에 모듈 이름을 추가합니다. 이로 인해 모듈 이름이 대상의 modules.load 에 추가됩니다. modules.load 는 장치가 부팅될 때 init 에 의해 로드되는 모듈 목록을 보유합니다.

무결성 자가 점검

FIPS 140-3 커널 모듈은 모듈 로드 시 자체 .code.rodata 섹션의 HMAC-SHA256 다이제스트를 가져와 모듈에 기록된 다이제스트와 비교합니다. 이것은 Linux 모듈 로더가 ELF 재배치 처리 및 해당 섹션에 대한 CPU 에라타에 대한 대안 패치와 같은 일반적인 수정을 이미 수행한 후에 발생합니다. 다이제스트가 올바르게 재현될 수 있도록 다음과 같은 추가 단계가 수행됩니다.

  • ELF 재배치는 HMAC 입력에 역으로 적용될 수 있도록 모듈 내부에 유지됩니다.
  • 정적 키와 트레이스포인트 및 벤더 후크를 포함한 다른 모든 코드 패치는 모듈에 대해 비활성화됩니다.

정답이 있는 자가 테스트

FIPS 140-3 요구 사항이 적용되는 구현된 알고리즘은 사용하기 전에 알려진 답변 자체 테스트를 수행해야 합니다. FIPS 140-3 구현 지침 10.3.A 에 따르면 지원되는 키 길이를 사용하는 알고리즘당 단일 테스트 벡터는 암호화와 암호 해독이 모두 테스트되는 한 암호에 충분합니다.

Linux CryptoAPI에는 동일한 알고리즘의 여러 구현(예: 특수 암호화 명령을 사용하는 구현 및 해당 명령을 구현하지 않는 CPU에 대한 대체)이 공존할 수 있는 알고리즘 우선 순위 개념이 있습니다. 따라서 동일한 알고리즘의 모든 구현을 테스트할 필요가 있습니다. 이것은 Linux CryptoAPI가 우선 순위 기반 선택을 생략하고 우선 순위가 낮은 알고리즘을 대신 선택하도록 허용하기 때문에 필요합니다.

모듈에 포함된 알고리즘

android13-5.10 소스 에서 빌드할 때 FIPS 140-3 모듈에 포함된 모든 알고리즘은 다음과 같습니다.

연산 구현 승인 가능 정의
aes aes-generic , aes-arm64 , aes-ce , AES 라이브러리 작동 모드가 없는 일반 AES 블록 암호: 모든 키 크기(128비트, 192비트 및 256비트)가 지원됩니다. 라이브러리 구현을 제외한 모든 구현은 템플릿을 통한 작동 모드로 구성할 수 있습니다.
cmac(aes) cmac (템플릿), cmac-aes-neon , cmac-aes-ce AES-CMAC: 모든 AES 키 크기가 지원됩니다. cmac 템플릿은 cmac(<aes-impl>) 을 사용하여 aes 를 구현하여 구성할 수 있습니다. 다른 구현은 독립 실행형입니다.
ecb(aes) ecb (템플릿), ecb ecb-aes-neon , ecb-aes-neonbs , ecb ecb-aes-ce AES-ECB: 모든 AES 키 크기가 지원됩니다. ecb 템플릿은 ecb(<aes-impl>) 를 사용하여 모든 aes 구현으로 구성할 수 있습니다. 다른 구현은 독립 실행형입니다.
cbc(aes) cbc (템플릿), cbc-aes-neon , cbc-aes-neonbs , cbc-aes-ce AES-CBC: 모든 AES 키 크기가 지원됩니다. cbc 템플릿은 ctr(<aes-impl>) 을 사용하여 모든 aes 구현으로 구성할 수 있습니다. 다른 구현은 독립 실행형입니다.
cts(cbc(aes)) cts (템플릿), cts-cbc-aes-neon , cts-cbc-aes-ce 암호문 도용이 있는 AES-CBC-CTS 또는 AES-CBC: 사용된 규칙은 CS3 입니다. 마지막 두 암호문 블록은 무조건 교환됩니다. 모든 AES 키 크기가 지원됩니다. cts 템플릿은 cts(<cbc(aes)-impl>) 를 사용하여 모든 cbc 구현으로 구성할 수 있습니다. 다른 구현은 독립 실행형입니다.
ctr(aes) ctr (템플릿), ctr-aes-neon , ctr-aes-neonbs , ctr-aes-ce AES-CTR: 모든 AES 키 크기가 지원됩니다. ctr 템플릿은 ctr(<aes-impl>) 을 사용하여 모든 aes 구현으로 구성할 수 있습니다. 다른 구현은 독립 실행형입니다.
xts(aes) xts (템플릿), xts-aes-neon , xts-aes-neonbs , xts-aes-ce AES-XTS: 모든 AES 키 크기가 지원됩니다. xts 템플릿은 xts(<ecb(aes)-impl>) 를 사용하여 ecb( ecb(aes) 구현으로 구성할 수 있습니다. 다른 구현은 독립 실행형입니다. 모든 구현은 FIPS에서 요구하는 약한 키 검사를 구현합니다. 즉, 전반부와 후반부가 동일한 XTS 키는 거부됩니다.
gcm(aes) gcm (템플릿), gcm-aes-ce 1번 AES-GCM: 모든 AES 키 크기가 지원됩니다. 96비트 IV만 지원됩니다. 이 모듈의 다른 모든 AES 모드와 마찬가지로 호출자는 IV를 제공할 책임이 있습니다. gcm 템플릿은 gcm_base(<ctr(aes)-impl>,<ghash-impl>) 를 사용하여 ctr(aes)ghash 의 모든 구현으로 구성할 수 있습니다. 다른 구현은 독립 실행형입니다.
sha1 sha1-generic , sha1-ce SHA-1 암호화 해시 함수
sha224 sha224-generic , sha224-arm64 , sha224-ce SHA-224 암호화 해시 함수: 코드가 SHA-256과 공유됩니다.
sha256 sha256-generic , sha256-arm64 , sha256-ce , SHA-256 라이브러리 SHA-256 암호화 해시 기능: 기존 CryptoAPI 인터페이스 외에 SHA-256에 라이브러리 인터페이스를 제공합니다. 이 라이브러리 인터페이스는 다른 구현을 사용합니다.
sha384 sha384- sha384-generic , sha384-arm64 , sha384-ce SHA-384 암호화 해시 함수: 코드가 SHA-512와 공유됩니다.
sha512 sha512- sha512-generic , sha512-arm64 , sha512-ce SHA-512 암호화 해시 함수
hmac hmac (템플릿) HMAC(Keyed-Hash Message Authentication Code): hmac 템플릿은 hmac(<sha-alg>) 또는 hmac(<sha-impl>) 을 사용하여 모든 SHA 알고리즘 또는 구현으로 구성할 수 있습니다.
stdrng drbg_pr_hmac_sha1 , drbg_pr_hmac_sha256 , drbg_pr_hmac_sha384 , drbg_pr_hmac_sha512 명명된 해시 함수로 인스턴스화되고 예측 저항이 활성화된 HMAC_DRBG: 상태 확인이 포함됩니다. 이 인터페이스의 사용자는 자신의 DRBG 인스턴스를 얻습니다.
stdrng drbg_nopr_hmac_sha1 , drbg_nopr_hmac_sha256 , drbg_nopr_hmac_sha384 , drbg_nopr_hmac_sha512 drbg_pr_* 알고리즘과 동일하지만 예측 저항이 비활성화됩니다. 코드는 예측 내성 변형과 공유됩니다. 가장 높은 우선 순위의 DRBG는 drbg_nopr_hmac_sha256 입니다.
jitterentropy_rng jitterentropy_rng 아니요 Jitter RNG 버전 2.2.0: 이 인터페이스의 사용자는 자신의 Jitter RNG 인스턴스를 얻습니다. DRBG가 사용하는 인스턴스를 재사용하지 않습니다.
xcbc(aes) xcbc-aes-neon , xcbc-aes-ce 아니요
cbcmac(aes) cbcmac-aes-neon , cbcmac-aes-ce 아니요
essiv(cbc(aes),sha256) essiv-cbc-aes-sha256-neon , essiv-cbc-aes-sha256-ce 아니요

소스에서 모듈 빌드

fips140.ko 모듈은 다음 명령을 사용하여 GKI 커널 소스에서 빌드할 수 있습니다.

BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh

이것은 커널과 fips140.ko 모듈을 사용하여 전체 빌드를 수행하고 해당 콘텐츠의 올바른 HMAC-SHA256 다이제스트가 포함되어 있습니다.

최종 사용자 지침

암호화 책임자 안내

커널 모듈을 작동하려면 운영 체제가 단일 운영자 작동 모드로 제한되어야 합니다. 이것은 프로세서의 메모리 관리 하드웨어를 사용하여 Android에서 자동으로 처리됩니다.

커널 모듈은 별도로 설치할 수 없습니다. 장치 펌웨어의 일부로 포함되며 부팅 시 자동으로 로드됩니다. 승인된 작동 모드에서만 작동합니다.

암호 책임자(Crypto Officer)는 장치를 다시 시작하여 언제든지 자체 테스트가 실행되도록 할 수 있습니다.

사용자 안내

커널 모듈의 사용자는 암호화 알고리즘을 사용해야 하는 다른 커널 구성 요소입니다. 커널 모듈은 알고리즘 사용에 추가 논리를 제공하지 않으며 암호화 작업을 수행하는 데 필요한 시간을 초과하는 매개변수를 저장하지 않습니다.

FIPS 준수를 위한 알고리즘 사용은 승인된 알고리즘으로 제한됩니다. FIPS 140-3 "서비스 표시기" 요구 사항을 충족하기 위해 모듈은 알고리즘이 승인되었는지 여부를 나타내는 기능 fips140_is_approved_service 를 제공합니다.

자체 테스트 오류

자체 테스트가 실패하는 경우 커널 모듈은 커널을 패닉 상태로 만들고 장치가 부팅을 계속하지 않습니다. 장치를 재부팅해도 문제가 해결되지 않으면 장치를 다시 플래시하여 문제를 해결하려면 장치를 복구 모드로 부팅해야 합니다.


  1. 모듈의 AES-GCM 구현은 "알고리즘 승인"이 될 수 있지만 "모듈 승인"은 될 수 없습니다. 검증할 수 있지만 AES-GCM은 FIPS 모듈 관점에서 승인된 알고리즘으로 간주될 수 없습니다. 이는 GCM에 대한 FIPS 모듈 요구 사항이 자체 IV를 생성하지 않는 GCM 구현과 호환되지 않기 때문입니다.