1. 사용자 인증 방식 발전 과정
- 초기 인증 방식은 비밀번호만 사용하여, 비밀번호 유출로 인한 보안 사고 발생 증가
- 비밀번호+MFA 방식은 사용자 단말 분실/교체 시 복원이 어렵고, 피싱 등 사회공학 공격에 취약
- 패스키 방식은 사용자 단말 분실/교체 시에도 복원 쉽고, 등록된 웹사이트나 APP/브라우저만 허용하여 인증하므로 기존 인증 방식의 근본적인 문제점 해결 가능
2. 비밀번호 없는 안전한 인증 방식, 패스키의 개요
(1) 패스키 (Passkey)의 개념
(2) 패스키의 특징
| 비밀번호 불필요 | Relying party에서 비밀번호 대신 공개키를 저장 및 관리 |
| 서비스 별 고유성 | 서비스/웹사이트 별 고유한 패스키 생성, 재사용 불가 |
| 비정상 인증 방지 | 패스키는 사용자 장치에 저장, 개인키는 Authenticator에 저장, 보안 강화 |
| 피싱 방지 | 패스키 생성 시 등록된 웹사이트나 APP, 브라우저에서만 사용 가능 |
- 피싱 공격 방지를 위해 사용자가 정확한 웹사이트 주소 확인 및 APP/브라우저 해킹 인지 불필요
- 비밀번호 방식 등 기존 인증 방식의 근본적인 문제점을 해결하여, 사용자는 비밀번호 기억이 불필요하고 서비스 제공자는 비밀번호 유출에 따른 법적 리스크 감소
3. 패스키 인증 메커니즘 및 구성 요소
(1) 패스키 인증 메커니즘
(2) 패스키 인증 환경 구성 요소
| 구분 | 구성 요소 | 역할 |
|---|---|---|
| 사용자/인증 상호작용 측면 | Authenticator | – 사용자의 신원 증명을 위한 인증 – 인증 대상 개인키를 저장/서명 |
| Client application | – 사용자와 상호작용하는 Front-end APP – 사용자의 패스키 인증 및 등록 절차 수행 | |
| Relying party | – 사용자가 요청한 리소스 접근 여부 결정 – 패스키 인증 및 등록 Back-end APP | |
| 인증 수행 측면 | Application layer | – 자격 증명 관리 핵심 비즈니스 로직 담당 – 자격 증명 저장소 참조하여 패스키 등록/인증 |
| Identity provider | – 인증 토큰(OAuth2) 발급 서비스 – 솔루션 유형에 무관한 패스키(WebAuthn) 지원 | |
| Credential repository | – 인증에 사용되는 자격 증명(공개키) 저장소 – 공개키, 자격 증명 ID 및 사용자 핸들 저장 | |
| Metadata repository | – 등록된 인증자의 제조사와 모델 식별 – 모범 사례에 포함되는 옵션 구성 요소 |
- 패스키는 FIDO Alliance에서 표준화, Google, Microsoft, Apple 등 빅테크 기업을 시작으로 적용 확산
4. 패스키 등록/인증 과정
(1) 패스키 등록 과정
(2) 패스키 인증 과정
- Google, Microsoft, Apple 등 빅테크 기업을 시작으로 패스키 사용 환경이 확대되고 있으며, SK텔레콤 등 국내에서도 패스키 인증 지원을 통한 패스키 사용 환경 확대중
[참고]
- fido alliance, Passkeys
- dev.yubico, Passkeys
View Comments (6)
잘 정리해주셨는데 질문이 있어요.
2요인 인증이 좋은데 늘 단말기 분실, 고장 등이 걱정이지요. Authy와 같은 앱은 복수의 단말기에 설치 가능해 단말기 분실, 고장에 대비할 수 있는데, 패스키는 어떻게 이 문제를 해결하는 것인지요?
초두에 아래와 같은 설명이 있긴 한데 제가 패스키는 한번도 안써봐서요.
"패스키 방식은 사용자 단말 분실/교체 시에도 복원 쉽고, 등록된 웹사이트나 APP/브라우저만 허용하여 인증하므로 기존 인증 방식의 근본적인 문제점 해결 가능"
패스키도 복수의 단말기에 저장할 수 있고, 패스키가 저장된 유일한 단말기 분실, 고장 시 Authenticator(구글, 애플 등 패스키 서비스 제공자)를 통해 기존 패스키를 해지하고 신규 패스키를 생성해서 새로운 단말기에 저장하면 됩니다.
참고로 패스키는 비밀번호와 함께 사용하는 2요인 인증 방식은 아니고, 등록된 서비스나 웹사이트에서 특정 단말기만 인증하도록 단말기에 고유한 패스키를 생성하는 차세대 인증 방식입니다. (패스키가 저장된 단말기가 아닌경우 등록된 서비스나 웹사이트에서 인증 불가) 물론 2요인 인증 방식과 마찬가지로 패스키를 사용하기 위해서는 서비스나 웹사이트도 패스키 인증 기능을 제공해야 합니다.
답변 감사합니다.
주신 답변에 따르면 패스키(가 저장된 단말기) 분실 시 authenticator로 기존 패스키 해지 후 신규 생성이 가능하다고 하셨는데 authenticator를 미설정해둔 경우에는 기존 패스키를 어떻게 해지하나요? 이 경우 전통적인 비밀번호, 패스워드로 계정에 접근하게 되는 것인가요?
제가 이해한 바로는 패스키가 기존 패스워드를 대체하기 위함인데 이런 긴급한 경우에 대비해 기존 패스워드는 여전히 살려둬야 한다면 패스키의 존재 의미는 무엇인지요?
(딴지 걸려는 게 아니라 정말 몰라서 하는 기초적인 질문일 수 있으니 양해바랍니다. 외국 문헌들도 좀 읽어봤는데 단말기 분실, 고장 등의 경우에 대해 명확히 설명된 부분을 아직 못 본 듯 해서요)
패스키를 사용하기 위해서는 먼저 authenticator 설정(구글 계정에서 패스키 사용 설정)해야 패스키를 만들거나 해지할 수 있으므로 패스키 사용 시 authenticator는 항상 설정이 필요합니다. 질문하신 부분이 authenticator 접근에 문제가 발생한 경우라면, 예를 들어, 구글 접속을 위해 구글 계정으로 패스키를 생성했는데 해당 패스키를 분실했다면 말씀하신 대로 전통적인 비밀번호나 2차 인증을 통해 계정에 접근하게 됩니다. 이 부분은 개선의 여지가 있어보이긴 합니다.
제가 생각했을 때 패스키의 존재 의미는, 비상 시 구글 등 authenticator에 접속하기 위한 패스워드나 2차 인증은 어쩔 수 없이 써야 하겠지만, 그 외의 일반적인 경우(네이버, 유튜브, 다음, 페이스북, 트위터, 틱톡, 각종 쇼핑몰, 기관 홈페이지 등등) 매우 많은 웹사이트와 Application의 패스워드를 관리하지 않고도 보안성이 확보된다는 장점에 따라 의미가 있을 것으로 생각합니다. 아직 패스키 시장이 성숙하지 않아 패스키 지원 웹사이트나 Application이 많지 않지만 앞으로 패스키 지원 웹사이트와 Applicatino이 많아진다면 충분히 사용할만한 보안 기술로 생각됩니다.
실제 패스키 사용 관련하여 더 궁금하신 부분은 패스키 관련 구글 블로그(링크)를 참고해주세요~
SKT 신기은 매니저님 프레젠테이션 영상을 보고
추가적인 정보들도 찾아보고 있었는데 등록과정, 인증과정을 구분하여 설명해주셔서 이해가 잘됩니다 감사합니다^^
도움이 되신다니 다행입니다. 감사합니다.^^