2022년 7월 19일 화요일

FIDO 기초에 대한 이해 - FIDO 101

FIDO 기초에 대한 이해 - FIDO 101
<서론>
파이도가 기존 패스워드기반의 인증을 대체하는 시스템이기때문에 패스워드에 대해 어떤점이 문제인지 제약사항은 무엇인지 알아보고
패스워드를 기반으로하는 인증시스템의 대체수단으로 공개키기반의 인증시스템이 오래전에 소개되었는데 계속 발전하지 못한 이유와 그 공개키기반의 인증시스템을 접목한 파이도가 사용자 편의성과 보안 이 2마리 토끼를 잡을 수 있었던 이유와 그 적용사례에 대해 살펴보고 그 한계와 극복한 방법을 살펴보고자 함
<패스워드 기반 인증 시스템>
[문제점]
1. Malware key logging, 2. Social engineering, 3. Data breach, 4. Man in the middle(피싱), 5. 크리덴셜 스터핑이 발생할 수 있음
[해결책]
다중 요소 인증(MFA)를 도입하는 것인데 패스워드 + 다른 인증 방식의 형태(SMS OTP, Hardware OTP)는 패스워드 보다는 안전하지만 추가단계를 거침에 따라 사용성이 저하되어 여전히 피싱공격에 취약하고 현재 침해된 많은 사례가 있음
* 피싱의 대부분은 피싱 메일을 통해서 이뤄지는데 그 이유는 저렴하고 성공율(40% 정도) 높기 때문인데 KISA가 권고하는 가이드는 모두 사용자가 잘 판단해서 피싱당하지 않도록 주의하세요임
[패스워드의 문제는 모두 사람이 주원인]
그래서 근본적인 문제는 사람이고 사람은 기억력의 한계로 유니크한 안전한 값을 생성 및 기억할 수 없고 고도로 진흥화된 피싱 기술로 사람의 인지에는 한계가 존재
[공개키 암호방식 등장]
그래서 나온것인 공개키 암호 방식이고 이것은 수학적으로 결합된 두개의 키(키 쌍)을 활용하여 개인키와 공개키로 구성되고, 개인키는 실제 Secret의 역할을 하며, 공개키는 개인키에 대응된 값으로 공개해도 무방함
* 공개키 암호를 활용한 인증 절차
1. 서비스는 인증대상에게 challenge를 전송
2. 인증 요청을 받은 대상은 자신이 소유한 개인키로 challenge에 전자서명 수행
3. 전자서명을 서비스에 전송
4. 서비스는 전달 받은 전자서명과 전송하였던 challenge에 대하여 인증 요청후 대상의 공개키로 검증 수행
[공개키의 한계]
1. 안전한 개인키 관리(저장)의 어려움
2. 범용성 측면에서 디바이스에 종속
3. 표준 인터페이스를 제공하지 못하고 버젼별 기능차이와 플랫폼별 별도 api 제공
이런 문제를 해결하고 더불어 개인키의 저장 방식의 보안이 점점 고도화되면서 기존에 os level에서 관리되던 것이 이제는 hw level에서 관리가 됨으로서 공개키를 사용하는데 어느정도 환경이 조정된 것으로 판단됨
[파이도의 탄생]
이 공개키 암호 알고리즘 기반으로 두마리 토끼(강력한 보안 + 사용자 편의성)을 다 잡을 수 있는 WebAuthn fido 기술이 탄생함
* FIDO Protocal
UAF (Universal Authentication Framework): 비밀번호가 필요하지 않은 온라인 로그인 환경을 지원, 생체인증,PIN 등 다양한 방법을 통해 보안 및 편의성 제공하고 표준화 주도기업은 PayPal, Nok Nok Labs 며 ITU-T에 V1.1이 표준으로 등록됨
U2F(Universal Second Factor) : 2단계 온라인 Web 로그인 환경을 지원하고 기존인증에 더 강력한 보안을 제공하고 표준화 주도기업은 구글과 유비코고 마찬가지로 ITU-T에 V1.2이 표준으로 등록됨
[FIDO 기술의 변화]
UAF의 한계 : Universal Authentication을 표방하였지만 표준 Web API의 미지원으로 인해 플랫폼 확장이 제한적이고 FIDO Client Stack의 구현 주체(주로 Device 제조사)에 따라 이질적인 UX를 제공하고 기술의 복잡도로 작은 기업은 도입의 어려움이 많음
U2F의 한계 : 추가 인증을 위한 기술로 모바일 환경에서의 Primary 인증 수단 제공 불가하고 웹기반의 인증 기술이었으나, 표준 Web API의 미지원으로 인해 브라우저에 따른 지원 여부 차이가 있고, 추가 인증을 위해 외부 인증 장치(usb, secret key)에 의존 필요하여 비용이 발생하고 대고객 환경에서의 빠른 도입이 불가함
[FIDO 2로 진화]
따라서 이 문제를 해결하고자
FIDO v2(FIDO2)가 제안되었고 UAF, U2F의 사용성을 포용하며 Web, Native 등의 환경 구분 없이 기술을 활용 가능케 하고자 하였고, 표준 API 지원을 위한 W3C 웹 표준화 작업 동시 진행하였고, 제조사와 솔루션 별 이질적인 UX를 제거하고 Out-of-box로 기술을 제공하는 위해 플랫폼 제공자(OS, Browser)등에서 FIDO Client Stack 을 직접 구현가능하거나 제공됨
[FIDO2의 한계]
하지만 FIDO2도 새로운 기기를 구매하거나 분실하거나 고장났을 경우 다시 FIDO2 크리덴셜을 다시 등록해야 하는 한계가 존재 함
이를 극복하고자 "패스키"가 고안되었음
파이도의 한계와 그를 극복한 노력에 대한 것은 패스키의 강좌를 참고하시기 바랍니다.(https://youtu.be/Jy-n35nws0I)

댓글 없음:

댓글 쓰기