FIDO 2.0 Key Attestation Format
FIDO의 3가지 스펙 문서 중 Key Attestation Format부터 정리한다.
블로그 제목의 길이가 길어지면 가독성이 떨어지기 때문에 편의상 KAF로 줄여서 제목을 붙이도록하겠다.
개요
Attestation Models(증명 모델)
FIDO 2.0은 여러개의 인증 모델을 스펙으로 지정한다.
Full Basic Attestation(전체 기본 인증)
Full Basic Attestation은 인증자의 private key를 인증자의 모델에만 적용한다.
즉, 동일한 모델의 인증 장치 그룹이 하나의 Attestation key를 공유하게 된다.
Full Basic Attestation은 FIDO UAF 1.0과 FIDO U2F 1.0에도 사용된다.
Surrogate Basic Attestation(대리 기본 인증)
Surrogate Basic Attestation은 인증자가 특정 key를 가지고 있지 않다.
특정 key를 가지고 있지 않은 대신 authentication key를 가지고 증명 메시지에 자체 서명하는 방식으로 증명된 private key가 보호되지 않는 인증자는 일반적으로 Surrogate Basic Attestation을 사용한다.
Privacy CA
인증자는 인증을 위한 특별한 key를 하나 소유하며, 이 키는 신뢰할 수 있는 제 3자와 통신하는 데 사용된다.
인증자는 여러 개의 인증 key 쌍을 생성하고 Privacy CA에 인증을 위한 인증서를 발급받기 위한 요청을 한다.
위와 같은 방법을 이용하여 인증자는 Privacy CA에 대한 인증 key가 최대한 노출되지 않도록 작업할 수 있다.
증명 key는 각 FIDO 자격 증명 마다 개별적으로 요청할 수 있다.
Note Privacy CA는 일반적으로 여러 증명 인증서를 생성하며 가장 최근에 요청된 증명 인증서를 “active” 라고 부른다.
DAA : Direct Anonymous Attestation(직접 익명 증명)
인증자는 하나의 DAA 발급 기관으로부터 자격 증명을 받는다. 이 DAA 자격 증명은 입증된 데이터에 서명하기 위한 블라인드도 함께 사용하여 DAA 자격 증명이 전역적으로 처리되는 부작용을 방지한다.
FIDO 2.0은 FIDO ECDAA 알고리즘을 사용하여 DAA를 지원한다.
FIDO 서버는 위의 많은 증명 모델을 모두 지원해야 하며, 인증자는 이 모델들 중에서 어떠한 증명 모델을 사용할 것인지 선택할 수 있다.
Note FIDO를 구현하는 당사자는 허용 가능한 증명 모델을 결정할 수 있도록 정책적으로 제공해야 한다.
Contextual Data(문맥 데이터)
FIDO 2.0 Attestation은 다양한 Contextual Data에 바인딩 된다.
위의 데이터는 서버에서 Authenticator로 전달되는 서명 요청에 따라 여러 계층에서 추가되거나 관찰된다.
서명을 검증할 땐 서버는 Contextual Data에 바인딩 된 데이터를 예상값과 대조하여 검사한다.
계층은 총 세가지로 구분된다.
- RP(Relying Party)
RP는 온라인 서비스와 클라이언트 애플리케이션의 두 가지 하위 요소로 구성된다. 클라이언트 애플리케이션은 브라우저에서 실행되는 웹 애플리케이션이거나 운영체제에서 직접 실행되는 애플리케이션일 수 있다. - 클라이언트 플랫폼
클라이언트 플랫폼은 사용자의 운영체제와 디바이스로 구성된다. 이 클라이언트 플랫폼에 클라이언트 애플리케이션이 올라가 동작하며 웹 애플리케이션의 경우 브라우저도 클라이언트 플랫폼에 속한다. - Authenticator
Authenticator 그 자신도 하나의 계층에 속한다. Authenticator는 key를 생성하고 관리하며 암호화된 서명을 제공한다.
위와 같은 계층 구조의 목적은 아래와 같이 요약할 수 있다.
- key와 attestation을 생성하는 Schema는 클라이언트 플랫폼과 Authenticator 사이의 연결에서 대역폭이나 지연 시간과 같은 것이 매우 제한적인 경우에도 동작해야 한다. 위의 제한 사항을 가진 것은 저전력 근거리 블루투스 통신이 대표적이다.
- Authenticator가 처리하는 데이터는 매우 작고 저수준의 코드에서 해석하기 쉬워야한다. Authenticator는 JSON과 같은 상위 수준의 인코딩 포맷을 알 필요가 없기 때문이다.
- Authenticator와 클라이언트 플랫폼 모두 필요에 따라 Contextual 바인딩을 추가할 수 있는 유연성을 가져야 한다.
- 기존 인코딩 형식을 가능한 많이 재사용하는 설계 구조를 가져야 한다.
Contextual 바인딩은 두 가지 유형이 있다.
RP 또는 클라이언트 플랫폼에 의해 추가된 Client Data 와 Authenticator에 의해 추가된 Attestation Data 가 그 유형이다.
Client Data는 반드시 서명되어야 하지만 Authenticator는 서명 여부에 대해 알 필요가 없다.
좀 더 구체적으로 말하면, Authenticator는 바인딩된 데이터의 정확성을 증명할 수 없으므로 Authenticator에 대한 대역폭과 처리 요구 사항을 저장하기 위해 클라이언트 플랫폼은 Client Data를 hash 처리하고 hash된 결과만 Authenticator에게 보내는 것이다.
Authenticator의 Attestation은 이 hash와 Attestation Data의 조합을 포함하여 전달된다.
Attestation Types(증명의 유형들)
FIDO는 접속할 수 있는 Attestation Type들을 표준으로 정의한다.
다시 말해 Authenticator에 의해 증명되는 데이터를 직렬화하는 방법을 정의하는 것인데, TPM 및 여러 플랫폼의 형식을 지원할 수 있기 때문이다.
Attestation Type은 public key, Authenticator Model, Contextual Data 를 떨어져있는 원격의 상대방에게 암호로 증명할 수 있는 기능을 제공한다.
