패스키 ('passkey'): 멀티 디바이스 FIDO 크리덴셜
최근에 애플, MS, 구글 등을 통해서 소개됨
<FIDO 란 >
먼저 한국에서 파이도에 대한 현황은 한국은 금융, 정부, 이커머스에 많이 사용되고 대부분 FIDO v1 UAF 형태( 모바일에서 생체인증이나 손쉬운 인증방식 활용하는 용도)로 사용. 그래서 한국에서는 FIDO가 생체인증인지 알고 있는데 아니고 파이도는 2012년경 많은 산업체에 있는 기업들이 모여서 새로운 인증 표준기술을 만들고 패스워드에 의존적인 인증수단을 개선하기 위해서 만들기술로 그 기술을 기반으로 표준 작업을 거쳐 널리 이용할 수 있게 하는 것을 목표로 설림이 됨
2012년에 설립된 후 약 10년이 흘렀는데 많은 기술중 하나인 패스키를 소개하고자 함
<패스키 소개>
FIDO의 개념 설명 : 지식기반의 인증수단에서 소유기반의 인증수단으로 패러다임 쉬프트
패스워드 같은 인증수단은 그 보안강화를 위해서 추가적인 인증수단(SMS OTP를 사용) 활용하는 반면 소유기반의 인증수단이 FIDO는 디바이스에 저장되고 그 해당정보를 활용해서 인증하는 방식(현재 이 방법의 문제점이 다수 발견된다고 FIDO 얼라이언스 업데이트에서 FIDO 얼라이언스 이사장겸 마케팅 책임자 앤드류 시키어가 발표함)
지식기반 인증에서 소유기반 인증방식으로 전환되면서 기존 취약점이 많이 해결됨 특히 FIDO에서 여러 보안위협중에 피싱에 대한 방어 또는 내성을 가지기 위해서 디자인 할 때 그런 부분을 고려
2012년 부터 걸어온 마일스톤을 살펴보면
2012년에 FIDO V1 인 UAF (Universal Authentication Framework)라고해서 모바일 환경에서 생체인증이나 손쉬운 인증방식을 활용하는 인증형태로 국내에 많이 사용됨 또 U2F(Universal 2nd Factor)인 특히 데스크탑, 웹환경에서 ID( 유저네임) , PW에 더해서 추가적인 인증팩터(usb, secret key) 을 활용하는 형태(외부장치를 사용하는 것이 한계)
또 FIDO2 는 기존 FIDO V1의 단점을 보완하는 FIDO v2를 비슷한 시기에 발표했고 이 기술은 FIDO의 웹환경에서도 손십게 사용하는 것이 목표
동시에 웹환경에서도 사용하기 위해서 릴리즈되었고 FIDO2의 웹표준을 WebAuthn이라고 부르고 이 기능이 브라우져에 탑재되기 시작
거의 비슷한 시기에 WebAuthn 기술이 플랫폼, 플랫폼 os 에 탑재되어 기존 외부장치(구매가 필요)에 의존하는 인증장치에서 사용자가 가지고 있는 스마트폰, 래탑, 데스크탑에서 인증장치를 제공하는데 이런 기능을 platform Authenticator라고 부른다.
~~~~ 그런데 아직 파이도 사용에 망설여짐 ?
패스키가 탄생하게 된 계기
파이도 인증의 핵심은 Authenticator(가운데)라는 디바이스를 활용하는데 오른쪽에 위치한 서비스( 로그인페이지를 제공하거나 인증을 제공하는 백앤드 서버)와 왼쪽은 사용자라고 보면 됩
그래서 FIDO2, WebAuthn 는 Authenticator와 서비스 사이에서 발생하는 인증이라고 보면 될 것 같고
사용자가 보유하고 있는 장치를 백앤드에서 다시한번 확인함으로써 인증하는 형태라고 보시면 됨 그리고 기기 소유여부를 기존 디바이스의 인증방식으로 한번 더 거침
자세히 살펴보면 인증을 위해서 1. Challenge(문제를 냄)를 요청하면 Authenticator는 자신만이 알고 있는 private key로 해답을 구하게 되는데 이 해답은 전자서명이란 형태로 해답을 찾게 되고 이 해답을 찾기 위해서는 반듯이 private key를 활용해야 합니다. 그래서 결국에는 private key를 보유하고있는 장치만이 challenge에 대한 정확한 해답을 찾을 수 있다
2. 이 private key를 액세스하기 위해서 사용자가 그 authenticator에 소유자인지 확인하는 프로세스가 있고 그래서 사용자가 authenticator와 사용자 액션을 수행하게 되는데 이때 생체인증 아니면 패턴 아니면 디바이스 패스코드 등등을 입력을 하게 되고 Authenticator는 디바이스에서 기존에 사용자가 등록했던 어떤 그런 생체정보 또는 패스코드를 찾아 확인을 하게되고 정상적으로 기기소유자임이 판명되면 말씀드린 private key 를 꺼내서 3. challenge에 대해서 전자서명을 하게 되고 그 전자서명 결과를 인증의 최종결과로 전송을 하게 됨
그럼 4. 서비스쪽 백앤드에서는 해당 전자서명 값을 받고 authentictor에 있는 private key에 대응되는 public key로 전자서명을 검증을 하게 되고 검증이 성공하게 되면 해당 authentictor가 보유하고 있는 private key로 정상적인 서명을 했다고 판단할 수 있고 판단이 되면 5. 인증이 완료되는 프로세스임
좋은 점 : 패드워드와 같은 백엔드에서 발생하는 여러가지 보안리스크가 굉장히 작고 그렇기 때문에 좀 더 안전하게 사용자를 인증할 수 있다.
이러한 형태로 인증이 진행이 되는데 앞서 설명한 것과 같이 그럼에도 불구하고 실제로 FIDO 기술이 여러 서비스나 여러 산업군에서 적용되는 부분들은 아직도 조금 제약적인 부분들이 있었고 그러한 이유로 말씀드린것 처럼 널리 이런 기술을 활요하기 위해서는 많은 사용자 커버가 필요한데 그런 부분들이 여러 제약사항으로 존재했지만 최근에 많이 해결되었음
~~~~ 그런데 아직 파이도 사용에 제약이 있음
그럼에도 불구하고 그럼에도 불구하고 이 기술을 활용하는데에는 여러가지 제약사항이 아직도 존재하는데 그 이유는 1. FIDO 를 활용했을 때 우리가 마켓에서 원하는 모든 사용자 유즈케이스(use case) 를 커버하지는 못하고, 2. PW 취약점이 존재하기에 FIDO 활용해서 좀더 안전한 형태로 인증을 제공할 수 있지만 만약 FIdo 크리덴셜을 보유하고 있는 기기를 잃거나 고장이 나면 파이도형태로 인증수행이 어렵기 때문임
3. 또, 많은 플랫폼이나 브라우져에서 많은 기능들이 제공되기 시작했지만 그 플랫폼별로 그 기술을 지원하는 set 이나 정도에 차이가 생기고 그래서 서비스에서 그런 기술들을 반영할 때는 플랫폼이나 브로우저에 따른 분기가 항상 필요하게 되고 그렇다보니 이런것을 반영하는 것이 쉽지 않았음 그리고 아직도 FIDO를 잘 모르고 그 장점을 모르는 경우도 많음
<패스키 탄생 배경>
사용자의 크리덴셜이 들어있는 기기를 분실하거나 고장이 나면 어떤 상황이 생기나요? 이런것은 우리의 집키를 잃어버리는 것과 동일한 상황인데 우리가 집키를 잃어버리면 열쇠공을 불러서 키를 다시 만들거나 복사하는 행위를 하게되듯이 파이도 등록을 새로하거나 복사를 해야 한다.
이렇게 파이도키를 복제하거나 백업하는 것을 패스키라고 하고 패스키란 용어는 작년에 애플에서 WWDC에서 먼저 사용을 했고 google , MS도 동일하게 사용됨
<패스키 사용 방식 2가지 >
패스키는 FIDO 크리덴셜이 다른 디바이스로 이동할 때 이를 안전하게 이동하는 위해서 일반적으로 많이 사용되는 방식인 종단간 암호 채널을 열고 EE2E라고 부르고 종단간 채널을 만들고 이 종단간 채널을 통해서 사용자의 크리덴셜을 전달을 하게 됨. 이 종단간 채널은 안전한 형태의 키교환 환경이 사전에 보장이 되야하고 이를 위해서 보통 Diffie-Hellman이라는 알고리즘을 사용하게 됨 이것을 sync 방식이라고 하고
또 다른 방식은 backup and recovery로 앞서 sync와 거의유사한데 한가지 다른 점은 크리덴셜이 백업되고 클라우드에 저장되어 있고 어느시점에 복원을 한다. 그래서 기기간에 그런 정보가 직접 전송되는 형태가 아니라 백업되는 시점과 복원되는 시점이 차이가 있을 수 있고, 마찬가지로 크리덴셜을 클라우드에 전송할 때 EE2E 인 종단간암호화 를 사용
또, 이것은 최종 HSM에서 복원을 하게 되면 클라우드 프로바이더의 취약점을 이용해서 사용자의 크리덴셜에 접근이 가능할 수 있어 오로지 사용자만이 생성할 수 있는 값으로 한번 더 암호화하여 저장함
<BS, BE를 flags에 추가>
서비스입장에서는 사용자의 크리덴셜이 백업이 가능한 형태인지(BE, Backup Eligiblity) 백업이 현재 되었는지(Backup Status) 여러가지 목적으로 확인이 필요하고 이런 수정 변경사항이 기존 spec에 반영이됨.
인증을 하거나 아니면 등록하는 프로세스에 Authenticator Data라는 정보가 있는데 그중에 Flags 가 다수 포함되는데 여기 에 BS, BE가 추가됨
<패스키에서 한 플랫폼에 한정적인 문제 해결>
이런 패스키는 플랫폼에 한정적이라는 것이고 이런 문제를 해결하기 위해서 서로 다른 기기 또는 서로다른 에코시스템간에 크리덴셜을 활용하는 형태를 패스키에서는 제공해야 함 이것을 Cross Device Sign-in user experience라고 함
랩탑과 스마트폰 사이뿐만아니라 지금 보시는 것처럼 ios와 안드로이드 사이에서도 동일하게 그러한 형태의 인증을 수행하고
서로 다른 플랫폼간 , echo 시스템 크리덴셜을 활용하기 위해서 패스키의 한기능으로 제공함
<근접한 기기각 크리덴셜을 주고 받는 메카니즘 hybrid>
근접한 랩탑과 핸드폰간에 파이도 클라덴셔을 주고 받는 기능을 예전에는 caBLE(cloud assist BLE)라고 불렀는데 지금은 hybrid라고 함
이 것은 랩탑에서 QR를 표출하고 그 QR 코드를 파이도 크리덴셜이 들어있는 안드로이드 핸들폰으로 읽고 또 서로 블루투스 통신( BLE scan, BLE advertisement)을 하면서 QR 코드에 내장된 정보값으로 양 기기간 암호화된 종단채널을 만드는 기술이고 이 종단 채널을 통해 파이도 명령을 주고 받고 인증이 끝나면 크리덴셜을 안드로이드에서 macbook으로 이동해서 사용하는 기술임
<DPKs의 목적>
크리덴셜이 특정기기에 머물러야 하는 경우가 있는데 그런 경우를 위해서 패스키에서는 DPKs라는 것을 익스텐션의 형태로 제공
서비스입장에서 특정기기에 종속되어 있는 키를 확인하고 자 할 때 활용할 수 있음
그래서 서비스에서 사용자 기기를 통해서 사용자 인증을 하거나 크리덴셜를 생성을 할 때 DPKs를 요청할 수 있구요 해당 authenticator 기기에는 DPKs요청에 대해서 관련된 정보를 생성해서 요청에 대한 응답에 포함해서 전송을 할 수 있음 이것은 DPKs(Device-bound public key)라고 함
<Conditional mediation 소개>
UX관련된 부분인데 앞서 패스키 소개할 때 기존의 유저네임과 pw를 넣는 그런 형태에서 패스키에서는 사용자의 계졍정보 없이도 사용자가 바로 기기에 보유되어 있는 크리덴셜을 활용할 수 있도록 UI를 제공하고 있다고 했는데 이것을 Conditional mediation 이라고 부름
<패스키와 Social 로그인 비교>
패스키는 FIDO 와 WebAuthn 기반이고 해당페이지로 다이렉션이 필요없고 패스워드가 전혀 필요없고 개인정보나 어떤 로그인 정보를 플랫폼기업에 따라 가져갈 수도 있고 아닐수도 있음
반면 소셜 로그인은 OICD(인증), OAuth2(인가)기반이고 해당 페이지로 리다이렉션이 생기고 본인 인증시 패스워드가 필요하고 Identity Provider가 사용자가 누구인지 언제 로그인을 했는 지 정보를 알 수 있음
<Recap>
요약하면 기존의 파이도의 싱글디바이스 크레덴셜이라는 제약사항을 멀티디바이스라는 형태로 확장을 했고요 그래서 기기간 크리덴셜이 동기화가 될 수 있고 그렇기 때문에 신규기기 또는 사용자가 보유하고 있는 여러기기간에 크리덴셜이 공유가 되고 백업이 되고 기존에 사용자가 접근할 수 없는 케이스(분실 등)에 대해서도 사용자가 이후에 복원을 할 수 있는 것도 가능하고
여러 기기간에 파이도 크리덴셜을 활용할 수 있도록 hybrid 제공 ( cross 디바이스, 플랫폼, 에코시스템) , 새로운 use case가 될 수 있는 공공기관의 PC에 사용자가 보유하고 있는 폰에 있는 크리덴셜을 활용하여 공공pc에 인증가능
마지막으로 사용자 UX를 개선하기 위해서 시스템 또는 브라우져에서 로그인 페이지에 사용자가 접속을 했을 때 해당 기기에서 사용가능한 크리덴셜을 사용자에게 오퍼하고 사용자는 해당 오퍼를 클릭하므로서 손쉽게 패스키를 사용할 수 있고 서비스입장에서도 불필요한 버튼 또는 불필요한 UI 변경없이도 기존에 어떤 로그인폼에서도 손쉽게 활용가능하도록 관련 기능을 제공함
또 패스키가 사용자 유저네임 없이도 활용가능한 그런 형태의 크리덴셜이기에 사용자 계정없이도 인증을 수행할 수 있는 그런 형태의 유저네임 리스로도 지원이 가능함
