FIDO 2.0 Key Attestation Format
FIDO의 3가지 스펙 문서 중 Key Attestation Format부터 정리한다.
블로그 제목의 길이가 길어지면 가독성이 떨어지기 때문에 편의상 KAF로 줄여서 제목을 붙이도록하겠다.
Attestation Statement(증명서) - (1)
Authenticator에 대한 증명서가 필요한 경우, 클라이언트는 Authenticator가 인증서를 생성하도록 요청한다.
이번 포스팅에서는 증명서의 데이터 구조에 대해 다루도록 하겠다.
이 증명서의 데이터에는 호스트와 다른 Authenticator의 정보도 포함될 수 있다.
증명서는 아래의 3가지로 구성되어 있다.
- header object
서명 알고리즘과 Attestation 서명을 검증하는 데 필요한 추가 정보를 포함한다. - core object
증명된 데이터를 포함하는 객체로, 여러 Attestation rawData type을 전달하고 어떤 인증 모델을 사용하는지를 담은 컨테이너를 전달한다. - signature object
암호화된 서명이 담긴 rawData 를 포함하는 객체로 객체의 구조는 서명 알고리즘에 따라 달라진다.
외부의 Authenticator가 컴퓨터로 증명서를 반환하는 방법은 Authenticator Protocol에서 다루겠다.
Client encoding of attestations statements(증명서의 클라이언트 인코딩)
클라이언트 플랫폼은 Authenticator가 생성한 attestation 서명 과 rawData 객체 를 사용하여 증명서를 생성한다.
이 증명서는 나중에 RP(Relying Party) 로 반환되며 아래의 형식으로 인코딩한다.
1 | interface AttestationStatement { |
AttestationHeader header
header는 알고리즘이 포함된 속성값이다. 추가적으로 claimed AAGUID와 attestation의 증명서 체인은 포함시킬 수도 있다.참고 AAGUID 는 GUID의 version 4로 Authenticator Attestation Globally Unique Identifier의 준말이다. 자세한 내용은 RFC4112 표준 문서를 참고하자.
AttestationCore core
core 속성값은 증명된 rawData와 rawData의 유형, 버전이 포함된 객체다.DOMString signature
signature 속성값은 base64url 방식으로 인코딩된 서명이다. signature 객체의 구조는 header에 지정된 서명 알고리즘에 따라 바뀌게 된다.
위의 증명서는 클라이언트의 API에 따라 RP(Relying Party) 에 전달된다. 증명서에는 RP의 FIDO 서버가 서명 기반의 문자열을 재구성 하고 클라이언트 및 Authenticator 정보를 디코딩 하고 유효성을 검증 하는 데 필요한 모든 데이터가 포함되어 있다.
AttestationCore
Authenticator에 의해 증명한 데이터와 그 데이터 구조에 대해 알아보자.
Authenticator의 유형이 다르면 Authenticator가 생성하는 객체들의 유형 또한 다르게 생성된다.
아래의 interface 형식을 먼저 살펴보자.
1 | interface AttestationCore { |
DOMString type
type 속성값은 rawData 객체의 유형을 나타낸다. FIDO에서는 유형으로 TPM(Trusted Platform Module), packed, android 의 Attestation 유형을 정의하고 있으며, 다른 유형은 이후 버전에서 추가 정의될 수 있다.unsigned long version
version 속성값은 rawData 객체의 버전을 나타낸다.DOMString rawData
rawData 속성값은 type이 android 유형일 경우엔 public key와 clientDataHash를 포함한 객체를, type이 TPM, packed 일 경우엔 base64url로 인코딩된 객체를 표현한다.DOMString clientData
clientData 속성값은 FIDOSignatureFormat인 clientDataJSON의 base64url 인코딩을 표현한다. 인코딩은 clientDataHash로 계산되어 보존되어야 한다.
Client data
클라이언트 플랫폼은 EAP API를 통해 clientDataHash를 Authenticator에게 전달해야 한다.
클라이언트 플랫폼은 encodedClientData를 보존하여 서명 객체에 포함하여 RP에 다시 보내야 한다.
이는 같은 Client Data가 다중 JSON을 인코딩할 수 있도록 하기 위해 필요하다.
AttestationHeader
Attestation 서명을 검증하기 위해 추가된 데이터를 말한다.
아래의 interface 형식을 살펴보자.
1 | interface AttestationHeader { |
DOMString claimedAAGUID
claimedAAGUID 속성값은 FIDO 서버에서 AttestationCore 객체를 확인하기 위한 trust anchor 를 조회하는 데 사용된다.
조회가 성공하면 trust anchor와 관련된 AAGUID를 신뢰할 수 있는 것으로 판단한다.
DDA 모델처럼 증명서가 사용되지 않은 경우나 인증서에 AAGUID 값이 포함되어 있지않은 경우에 꼭 필요한 속성이다.참고 trust anchor는 X.509 인증서에서 인증 기관의 루트 인증서를 말한다. 루트 인증서에서 최종 인증서까지의 인증서로 트러스트 체인이 설정된다.
DOMString[] x5x
Attestation 증명서와 이에 대한 chain은 RFC 7515 Document 4.1.6에 명세되어 있다.DOMString alg
alg 속성값은 Attestation 서명을 위해 어떤 알고리즘이 사용되었는지를 나타낸다. 이에 대한 알고리즘은 JWA(JSON Web Algorithm)에서 찾아볼 수 있다.
위의 JWA의 서명 알고리즘을 이용해 FIDO 서버를 구현한다.