Coding Log


FIDO 2.0: Key Attestation Format

FIDO의 3가지 스펙 문서 중 Key Attestation Format부터 정리한다.

블로그 제목의 길이가 길어지면 가독성이 떨어지기 때문에 편의상 KAF로 줄여서 제목을 붙이도록하겠다.

참고 FIDO alliance : FIDO 2.0 Key Attestation Format 문서

Attestation Statement(증명서) - (4)

Verifying an Attestation statement(증명서 검증)

Attestation statement의 유형과 상관없이 이를 검증하기 위한 알고리즘에 대해 알아보자.

Attestation statement를 받은 Relying Party는 아래의 절차를 수행하며 검증한다.

  1. Attestation statement가 올바른 형식으로 작성되어있는지 검증

  2. attestationSignature.alg 값이 ECDAA 가 아닌 경우의 검증
    바로 아래에서 따로 다룬다.

  3. attestationSignature.alg 값이 ECDAA 인 경우의 검증
    바로 아래에서 따로 다룬다.

  4. clientData에서의 contextual binding 검증

  5. Authenticator Model과 관련하여 사용자를 검증하고 Authenticator의 나머지 특성이 Relying Party의 정책과 일치하는지 검증

    참고 FIDO Metadata Service를 이용해 Authenticator의 특성에 쉽게 접근할 수 있다.

attestationSignature.alg 값이 ECDAA 가 아닌 경우의 검증
ED256, ED512가 아닌 경우를 말한다.

  1. 신뢰할 수 있는 곳에서 Attestation Root Certificate를 찾는다. 위에서 언급했듯 FIDO Metadata Service를 이용해 쉽게 접근할 수 있다. 
    Attestation Root Certificate를 찾을 땐 header.claimedAAGUID를 사용할 수 있다.

  2. Attestation Certificate chain이 유효한지 검증하고 난 뒤 신뢰할 수 있는 루트까지 연결되어 있는 지 확인한다.

    참고 RFC 5280 Specification

  3. Attestation Certificate가 FIFO Authenticator 유형 기반의 EKU를 올바르게 사용하고 있는지 검증한다.

    참고 EKU : Extended Key Usage

    참고 예를 들어 type이 tpm 인 경우 EKU는 OID "2.23.133.8.3"이어야 한다.

  4. Attestation type이 android 인 경우 hostname "attest.android.com"에 Attestation Certificate가 발급되었는지 검증한다.

    참고 SafetyNet in Android Document

  5. chain에 속한 모든 CA Certificate가 모두 유효한지 또는 취소되지 않았는지 검증한다.

  6. header.alg 식별자를 사용하여 Attestation Certificate의 public key 및 알고리즘을 사용하여 core.rawData 에서 signature를 검증한다.

  7. core.rawData 구문을 확인하고 이 구문이 header.alg 에 지정된 서명 알고리즘과 상충되지 않는지 검증한다.

  8. Authenticator Model을 식별하기 위해 Attestation Certificate가 확장되어 id-fido-gen-ce-aaguid 가 포함된 경우 확장된 값들이 header.claimedAAGUID 와 일치하는지 검증한다.

    참고 id-fido-gen-ce-aaguid 는 OID 1 3 6 1 4 1 45724 1 1 4를 말한다.

  9. Attestation Certificate가 확장되지 않은 경우 Attestation Root Certificate는 Single Authenticator Model 이다.

attestationSignature.alg 값이 ECDAA 인 경우의 검증
ED256, ED512의 경우를 말한다.

  1. 신뢰할 수 있는 곳에서 DAA root key를 찾는다. FIDO Metadata Service를 이용해 쉽게 접근할 수 있다.
    DAA root key를 찾기 위해 header.claimedAAGUID를 사용할 수 있다.

    참고 DAA : Direct Anonymous Attestation(직접 익명 증명)

  2. core.rawData 에 대한 서명을 할 땐 DAA-Verify 를 수행한다.

    참고 FIDO ECDAA Algorithm

  3. core.rawData 구문을 확인하고 이 구문이 header.alg 에 지정된 서명 알고리즘과 상충되지 않는지 검증한다.

  4. DDA root Key는 Single Authenticator Model 에 쓰인다.

Relying Party는 Authenticator Statement의 검증이 실패할 경우엔 아래의 두 가지 동작 중 하나를 수행한다.

  • Attestation Statement와 관련된 Registration 같은 RP Client의 요청을 거부한다.

  • Attestation Statement와 관련된 요청을 수락하지만 Basic Attestation이 존재하는 경우 검증된 FIDO Credential을 정책적으로 허용 한다. 이럴 경우엔 FIDO Credential이 특정 Authenticator Model에 의해 생성되었다는 것을 증명할 암호가 없다.

참고 FIDO Security Reference

참고 FIDO UAF Protocol

Attestation Statement를 검증하려면 Relying Party가 신뢰할 수 있는 Attestation Certificate Chain의 root가 필요하다. 또한 Relying Party는 중간 CA Certificate에 대한 Certificate Status Information에 접근할 수 있어야 한다.

Relying Party는 클라이언트가 Attestation Information의 chain을 제공하지 않은 경우 Attestation Certificate Chain을 구축할 수 있어야 한다.

DISQUS 로드 중…
댓글 로드 중…

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다