1. 시작하며
UAF 인증의 흐름은 크게 '등록'과 '인증'과정으로 나뉜다. 사용자 자신의 Credential값을 FIDO Server에 등록하는 과정이 '등록'이며, 등록된 Credential값을 토대로 인증하는 과정이 '인증'이다.
이전 FIDO UAF의 개념과 필요성 2편을 통해 SSL의 인증서의 서명과 검증 방식에 대해 다루었고, 이를 FIDO에 응용하여 Attestation의 서명과 검증 방식 흐름에 대해 알아보았다. 그리고 최종적으로 FIDO Root CA에 의해 서명된 Attestation 인증서가 만들어진다는 것도 알았고, 이러한 인증서가 FIDO MDS에 적재된다는 것 또한 알았다. 이로써 FIDO의 전체적인 인증 흐름을 알기 위한 필요 조건은 갖추게 되었다. 이제서야 비로소 '등록'과 '인증' 흐름에 대해 알아보고자 한다.
2. 등록
위 사진은 FIDO Aliance에 기반한 UAF 등록 흐름이다. 번호별로 각각의 과정에 대해 설명을 이어나가려 한다.
- Client Party는 등록을 위해 FIDO Server에 등록요청을 한다.
- FIDO Server는 replay attack을 방지하기 위해 challenger값을 응답해준다.
[Replay Attack이란?]
여기서 replay어택이란, Client Party의 비공개키가 탈취되어, 해커가 임의로 등록 요청하는 것을 방지하기 위한 값으로, FIDO Server가 한시적인 시간동안만의 등록을 허용하게 해주는 임의의 값을 말한다.
- Client Party의 Authenticator는 이제 사용자로부터 생체 인증 정보를 입력받는 준비를 하며,
- 사용자는 생체 인증 정보를 Authenticator에 입력한다.
- 올바르게 입력되었다는 전제로, 이제 Authenticator에서는 사용자의 고유 정보를 나타내며, 고유 서비스 접근을 식별할 수 있는 Credential Key Pair를 만든다.
- Credential Key Pair의 비공개키를 사용하여 Client Party의 각종 정보와 Challenger값을 서명한다.
- Credential Signiture가 생성된다.
- 이제 신뢰할 수 있는 Authenticator로부터 서명값이 생성되었다는 것을 보장하기 위해, Authenticator가 보유하고 있는 Attestation Key Pair를 조회한다.
- Attestation 비공개키로 Credential Signiture를 서명한다.
- Attestation Signiture가 생성된다.
- 이제 이 정보를 통해 추후 '인증'과정때 사용할 Credential 비공개키를 client party에 저장하고 재활용할 수 있어야 할 것이다. 이를 위해 앱 내 안전한 저장소에 저장한다.
- 최종적으로 '등록'할때 필요한 요청 결과물 생성이 완료된다.
1. AAID
2. Attestation Signiture
3. Attestation Certificate
4. Credential Public Key[AAID란?]
Authenticator Attestation ID의 약자로, Client Party가 보유한 Authenticator가 신뢰할 수 있다는 정보를 나타내는 'Attestation Certificate'와 이를 생성할 때 사용한 'Attestation Root Certificate' 등 의 각종 정보들을 하나로 묶은 ID를 의미한다.
13 ~ 14. 최종 요청 결과물을 Server Party로 전송하고 이를 수신한다.
15 ~ 16. 응답받은 Attestation Signiture의 신뢰성 검증 작업으로, AAID를 사용하여 Attestation Root Certificate를 응답받는다.
17 ~ 18. Attestation Root Certificate를 사용하여, Attestation Certificate를 검증한다.
19. 검증 완료시, Attestation Certificate내의 Public Key와 Client Party로부터 받은 Attestation Public키를 비교 후, 옳다면 이를 사용하여 Attestation Signiture를 검증한다.
20 ~ 21. Client Party에서 서명할때 사용하던 Credential Signiture를 얻어낸다.
22 ~ 24. Credential Public Key를 사용하여 Credential Signiture를 검증하고, Client Party에서 최초 서명할때 사용된 데이터를 얻어낸다(Challenger, Client Party의 각종 정보들...) 그 후, '인증'과정때 사용하기 위해 DB에 Credential Public Key를 저장한다.
25. Client Party에게 '등록'과정이 끝났다는 응답을 내보낸다.
이 과정이 FIDO UAF에서 '등록' 과정을 수행하기 위한 일반적인 흐름으로, 2개의 Key Pair를 사용한다는 점이 추후, '인증'과정과의 큰 차이 중 한가지이다.('인증'과정에선 1개의 Key Pair(=Credential Key Pair)만 사용함)
3. 인증
위 사진은 UAF '인증'과정의 흐름이다. 마찬가지로 번호를 매겨가며 설명을 시작한다.
- Client Party가 Server Party에게 '인증'요청을 한다.
- Replay Attack 방지를 위해 Challenger값을 응답한다.
- Client Party의 Authenticator는 이제 사용자로부터 생체 인증 정보를 입력받는 준비를 하며,
- 사용자는 생체 인증 정보를 Authenticator에 입력한다.
- 이전 '등록'과정때 DB에 저장해놓았던 'Credential Private Key'를 조회한다.
- Credential Private Key를 사용하여 각종 Challenger, Client Party의 각종 정보들을 서명한다.
- Credential Signiture를 만든다.
- 등록 요청 결과물을 생성 및 전송한다.
- AAID
- Credential Signiture
9 ~ 10. Server Party에선 결과물을 수신한다.
11. DB로부터 '등록'과정때 저장한 'Credential Public Key'를 조회해온다.
12. 'Credential Public Key'를 사용하여 Client Party로부터 받은 'Credential Signiture'를 검증한다.
13. Client Party가 최초 서명할때 사용하던 각종 정보(Challenger, Client Party의 각종 정보 등...)를 추출 및 최종 검증까지 완료한다.
14. 인증에 성공했다는 응답값을 Client Party에게 보낸다.
4. 마치며
여기까지가 FIDO UAF의 전체적인 흐름도이다. 전체적으로 요약을 해보자. 우선, FIDO 인증 프로토콜을 사용하기 위해선, Client Party가 소유하고 있는 Authenticator가 신뢰할 수 있는 모듈인지를 확인하는 작업이 필요하다. 이를 가능하게 하기 위해선 Authenticator는 공인된 상위 인증 기관(=FIDO Root CA)으로부터 인증서를 발급받아야만 한다. 그와 동시에 FIDO 서버가 소유하고 있는 MDS(=Meta Data Service)에 해당 인증서에 관련된 모든 부분(=Attestation Certificate, Attestation Root Certificate, 인증서 생성 서명 알고리즘 등...)을 적재를 한다. 이로써 Client Party가 가지고 있는 Authenticator는 FIDO CA로부터 신뢰성을 인정받게 되는 것이다.
이로써 해당 Authenticator를 사용해 등록과 인증 과정을 수행한다. 등록 과정에선 'Attestation Key Pair'와 'Credential Key Pair'를 사용해 2번의 서명과정을 거친다. 이에 대한 서명값을 받은 Server Party에선 MDS로부터 Attestation Signiture의 신뢰성을 검증하고 2번의 체인 검증을 통해 Client Party가 사용한 정보까지 접근함으로써 등록 과정이 완료된다.
인증 과정에선 Client Party가 소유한 'Credential Private Key'와 Server Party가 소유한 'Credential Public Key'를 사용하여 서명과 검증의 과정을 거침으로써 인증이 완료된다.
