“Public-Key Cryptography(공개키 암호기술)”를 적용하고 있는 대표적 기술인 FIDO(Fast IDentity Online)에 대하여, 암호 기술이 적용되는 곳을 기준으로 동작 개념을 정리하였습니다.
FIDO에서 사용하는 “Public-Key Cryptography”에서는 타원곡선암호기술(ECC)에 속하는 ECDSA 암호알고리즘만 사용합니다.
참고로, PKI는 Public Key Infrastructure의 약자로 Public-Key Cryptography 방식에다가 외부 공인 기관인 CA 기관을 필요로 하는 방식입니다.
1. FIDO(Fast Identity Online)란?
FIDO는 Password를 서로 공유하여 인증하는, 공유방식 인증 방식 대신, 사람의 생체정보(지문, 얼굴모양, 홍채 등)나 외부 인증장치(Yubikey, Titan Security key 등)을 사용하여, “Public-Key Cryptography(공개키 암호기술)” 방식으로 보다 편리하고 안전하게 인증 기능을 제공하는 인증(Authentication) 프로토콜 표준입니다. 즉 FIDO는 생체정보(biometrics) 뿐만 아니라, USB Security Token, Smart Card 등 기존 Hardware 기반 Protection 장치를 포함한 모든 인증(authentication) 기술을 지원합니다. 또한 사용자 인증장치(Authenticator)를 등록하는 과정에서 기존 PKI 기술을 활용합니다..
산업계 관련 회사들이 만든 단체인 FIDO Alliance에서, FIDO 표준을 제정하여 발표하고 있습니다
FIDO는 생체정보(biometrics)도 사용할 수 있는 인증 표준이기에, 시대의 흐름(스마트폰에서 생체정보 스캔 기능 지원)에 따라 사용자들에게 부각되었으며, ID 와 Password가 없는 세상 구현을 위한 기술로 주목을 받고 있습니다.
국내에서는 금융거래 확인 시, 공인인증서 및 OTP(또는 보안카드)를 소유기반 인증 방식으로 사용하고 있었는데, 공인인증서 사용의무가 폐지됨에 따라, “생체정보 기반 인증 기술”이 공인인증서를 대체할 차세대 인증 수단으로 사용자들에게 부각되었습니다. 즉 “생체정보 기반 인증 기술”은 보안성 과 편리성 두 가지를 모두 제공하고 있기 때문입니다. 참고로 공인인증서를 사용하려면 Password를 필요로 합니다.
요약하면, FIDO는 기존 인증 기술인 ID, Password, 공인인증서 등을, 한꺼번에 대체하는 차세대 인증 기술로, 생체정보나 외부인증장치를 사용하여, “Public-Key Cryptography(공개키 암호기술)” 방식으로 구현하며, 서버에 Public-Key만 보관하여, 서버 해킹으로 인한 개인 정보 유출 문제를 해결할 수 있는 기술입니다.
구현 방식에 따라 아래 3가지 표준이 나와 있습니다.
1) UAF(Universal Authentication Framework) : ID 와 Password 인증 방식 대신, 개인의 고유한 생체정보를 인증 과정에 사용합니다. 스마트폰에서 생체정보 스캔 기능을 지원하고 있으므로, 스마트폰과 같은 모바일 환경에 적합합니다.
2) U2F(Universal 2nd Factor) : 기존 ID, Password 인증 방식과 함께 “생체정보나 별도의 2차 인증 장치”를 추가적인 인증 용도로 사용하는 것입니다. “FIDO U2F Certified Device” 즉 U2F 인증을 받은 “hardware 2nd factor device”가 시장에 출시되어 있습니다. 외부 인증 장치를 사용할 수 있기 때문에 기존 PC 환경에 적합합니다.
3) FIDO 2.0 : Web Browser를 사용하는 Web 환경에서 사용할 수 있도록, UAF 와 U2F를 통합 확장한 것입니다, 이를 지원하기 위해 WebAuthn 표준이 제안되어졌고, WebAuthn은 2019년 3월 4일에 W3C 의 Recommendation이 되었습니다(W3C가 WebAuthn을 표준으로 발표하였다는 의미입니다).
참고로 UAF 와 U2F 는 FIDO 1.0 에 속하는 방식입니다. 현재 UAF의 최신 버전은 1.1 이며 U2F의 최신 버전은 1.2 입니다. 따라서 FIDO 버전도 FIDO 1.1 로 upgrade 되었습니다.
FIDO 인증 기술을 사용하기 위해서는, Authenticator(인증장치) 라고 불리는 H/W적인 기능이 요구되어 졌기 때문에, 일반적인 서비스의 인증 수단으로 사용되기 보다는, 온라인 상에서 스마트폰으로 지불 결제 시, 인증 수단으로만 사용되어 지고 있습니다. 일반적인 서비스의 인증 수단으로 사용되도록 FIDO 2.0 이 제안되어졌지만, 대중화 되기에는 시간이 필요하다고 생각됩니다. FIDO 2.0에서는 스마트폰도 외부 Authenticator로 사용 가능하게 합니다.
모든 FIDO 프로토콜에는 Registration(등록) 과 Authentication(인증)이라는 프로세스가 있습니다.
2. Registration(등록) 과 Attestation(증명)
온라인 환경에서 새로운 서비스를 사용하기 위해서는 먼저 사용자 등록을 해야 합니다.
사용자 등록을 할 때, “FIDO authenticator(FIDO 지원 Device에 내장된 Module 또는 외부인증장치)”는 해당 서비스를 위해 새로운 “Key Pair(Private-key 와 Public-key)”을 generate 하고, Public-key는 FIDO 지원 Device에 의해 FIDO Server에 보내어지게 됩니다. Private-key는 Authenticator 내부의 secure key store 영역에 안전하게 보관되어지며, 외부로 유출되어서도 안됩니다. 참고로, 스마트폰 모델 중, 보다 안전한 secure key store 영역을 지원하기 위해, TEE(Trusted Execution Environment) 또는 SE(Secure Element) 기능을 제공하고 있는 스마트폰도 있습니다(TEE 나 SE 기능이 없는 스마트폰은 S/W 방식으로 구현해야 합니다).
U2F 방식인 경우, 사용되는 “FIDO U2F Certified Device” 즉 U2F 인증을 받은 “hardware 2nd factor device” 는 “FIDO authenticator” 의 한 유형으로 보시면 됩니다.
서비스마다 새로운 key Pair(쌍)를 generate 하기 때문에, 하나의 key Pair는 하나의 서비스에만 사용됩니다. 보안을 위해 Authenticator(인증장치)는 unique한 Key Pair를 generate하는 기능을 가지고 있어야 합니다. FIDO 에서는 이러한 key Pair(쌍)을 “credential key pair” 라고도 부릅니다.
(출처 : FIDO Alliance)
Public-key는 서비스업체의 FIDO Server에 보내져서 저장됩니다. 이 FIDO Server는 인증 기능을 수행하는 서버이며, Public-key는 사용자를 인증하는 용도로 사용됩니다.
등록 프로세스의 초기에, FIDO Server가 등록 요청 Device에게 challenge(random number)를 보내는 데, 이것은 replay attack을 방지하기 위한 기능입니다.
“FIDO 지원 Device”에서는 새로운 Key Pair 를 generate(생성) 하기 전에, 사용자 정보를 받아서 Device 내부에 저장하는 작업을 먼저 수행합니다. 사용자 정보는 사용자 본인을 확인하는 용도로 사용됩니다. 생체정보를 사용자 본인임을 확인하기 위한 용도로 사용한다면, 사용자의 생체정보는 Device의 Capture 기능으로 capture되어, Device 내부에만 보관되어지고, 이 생체정보는 FIDO Server로 보내지지 않습니다.
생체정보를 비롯한 사용자 정보에 대한 등록 절차 및 저장 장소는 FIDO 표준 규격에 정의되어 있지 않습니다. 따라서 FIDO Device를 제공하는 기업에서 스스로 결정해야 합니다. 저장 장소로는 대부분 Authenticator 내부 안전한 영역을 사용합니다.
“hardware 2nd factor device”를 사용자 본인임을 확인하기 위한 용도로 사용한다면, 예를 들면, Device의 button을 누르기만 하면 됩니다(이 방식을 “User Presence” 라고 합니다. 참고로, 생체정보를 기반으로 사용자 본인임을 확인 하는 것은 “User Verification” 이라고 부릅니다).
참고로, FIDO에서도 사용자 본인임을 확인하기 위한 용도로, PIN 번호를 사용할 수 도 있습니다. 하지만 이 방법은 기존 Password 방식과 유사하고 보안성도 떨어집니다.
attestation(증명)은 FIDO Server에 등록(registration) 하는 과정에서 사용되는 프로세스로, 특정---attestation certificate를 가진 즉 인증된--- FIDO Authenticator(인증장치)에서 사용자가 “인증 정보(credential key pair)”를 생성 하였다는 것을 증명하기 위한 용도로 사용되는 프로세스 입니다.
attestation(증명)를 위하여, “attestation key pair”가 사용되는 데, “attestation key pair”는 제조사에서 “Authenticator가 내장된 Device”를 생산할 때, Authenticator 안에 심어놓은 Key Pair 입니다. 정확히 말하면 Private-key 와 Certificate(Certificate안에 Public-key가 들어있음) 입니다. Device 제조사는 생산하는 model 별로 동일한 “Private-key 와 Certificate(인증서)”를 심어 놓습니다. 제조사가 동일하더라도 model이 다르면 “Private-key 와 Certificate”는 다릅니다.
“attestation key pair” 는 앞에서 언급한 “credential key pair” 와 다릅니다. “attestation key pair”는 한 쌍만 존재하며, “credential key pair”는 서비스 마다 생성됩니다.
attestation(증명)은 사용자가 등록을 할 때, 사용자가 특정한 Device Model을 가지고 인증 정보를 생성하였다는 것을 암호기법으로 증명하는 것입니다. 생성된 key pair 중 Public-key를 서비스회사의 서버로 보낼 때, attestation private-key로 sign(전자서명)한 signature 와 attestation certificate 를 함께 보내는 것입니다. 즉 서버는 받은 Public-key가 특정 Device로 부터 보내졌다는 것을, 함께 받은 attestation signature를 검증(attestation certificate 안에 들어 있는 attestation public-key로 검증)함으로 확인합니다. 이를 위해 서버는 attestation certificate 가 신뢰할 만 한 것인지를 먼저 검증해야 합니다. 따라서 Device 제조사는 공인된 CA 기관으로부터 device certificate를 받아야 합니다. 즉 attestation 프로세스는 기존 PKI 방식을 활용합니다.
attestation(증명) 은 Public-Key가 서비스 회사로 전달되는 도중에 변조되는 것을 방지하는 기능을 수행합니다. 하지만 이미 Device 와 서비스회사 사이의 통신은 TLS 프로토콜을 사용하여 암호통신으로 수행되므로, 전달되는 도중에 Public-Key가 외부 공격자에 의해 변조되는 가능성은 없기 때문에, CA 기관에서 발행한 Certificate 대신 스스로 발행한 Self-Certificate를 사용해도, 서비스 회사에서 받아 들일 수 있습니다 이러한 기능을 Self Attestation(또는 Surrogate Attestation) 이라고 부릅니다.
UAF 와 U2F 는 attestation 관련 정보를 내부에 저장하거나 서비스회사로 보내기 위한 각각 고유한 attestation format을 가지고 있습니다.
참고로, attestation key 및 certificate는 model 별로 생성되기 때문에, attestation key 또는 attestation certificate로 사용자를 tracking을 할 수 없습니다. attestation certificate를 FIDO의 규정에 어긋나게 device별로 발행하면 사용자의 Privacy가 보호되지 않는다고 합니다.
3. Unique Model Number 와 Metadata Service(MDS)
서비스회사 입장에서는 서비스를 요청하는 Authenticator인 Device에 대하여 알아야 하기 때문에, 등록 시, FIDO에서 정의한 unique model number를 필요로 합니다. 즉 FIDO를 지원하는 Device는 unique한 model number를 가지고 있어야 하며, 등록 시 다른 정보(Public-Key, attestation signature, attestation certificate) 와 함께 서비스회사로 보내어야 합니다.
Unique model number는 사용되는 FIDO 방식에 따라 아래와 같이 부릅니다.
UAF : AAID(Authenticator Attestation ID)
U2F : Attestation Certificate Key Identifier
FIDO 2.0 : AAGUID(Authenticator Attestation Globally Unique ID)
FIDO MDS(Metadata Service)의 record에는 “unique model number” , “attestation root certificate”, “Device에 대한 metadata”가 기록되어 있습니다. “attestation root certificate”는 “attestation certificate”를 발행한 CA 기관의 Certificate이며, metadata는 Device 의 “Security and Biometric Characteristics”에 관련된 정보를 의미 합니다.
MDS의 record는 Device Vendor가 publish하는 metadata statement를 받아서 구성하며, FIDO Server(서비스회사의 서버)는 metadata statement를 검증할 수 있는 URL 주소가 포함된, sign된 “metadata Table of Contents” file을 주기적으로 다운로드 받아서, Device의 integrity를 확인 하는 데 사용합니다. Sign된 Signature를 검증을 하기 위해서는 FIDO Alliance의 root certificate를 받아야 합니다.
서비스회사는 Device로부터 “unique model number”를 받으면, MDS에 있는 record를 검색해서, 일치하면 record에 들어있는 “attestation root certificate”을 가지고 attestation certificate를 검증하고, 검증이 되면, certificate안에 있는 attestation public-key로 signature를 검증함으로, 사용자의 Public-Key를 검증합니다.
MDS 기능을 사용하는 목적은 등록된 Device만 등록 하고 인증하기 위하여 사용됩니다.
MDS는 기능적으로 보면, PKI 의 Certification Revocation List 기능과 유사하며, 다른 방식으로 부정 조작된 Authenticator를 관리할 수 있다면, 사용하지 않아도 된다고 합니다.
4. Authentication(인증) 과 Assertion(승인)
인증(authentication)에는 로그인을 위한 인증과 거래(Transaction) 확인(Confirmation)을 위한 인증, 2가지 경우가 있습니다.
FIDO Device는, 등록 하였을 때와 동일한 사용자 확인 방식(생체정보, PIN, 외부인증장치 등)을 사용하여(예를 들면, 지문 인식기에 손가락을 대던가 USB token의 버튼을 누름), 사용자 본인임을 확인합니다. Device에 저장된 사용자 정보와 일치하지 않으면 더 이상 진행하지 않습니다. 먼저 사용자 확인을 하는 목적은, Device의 Authenticator 내부에 저장된 Private-key를 사용하기 위해서 입니다.
위의 단계를 통과하면, FIDO Device는 FIDO Server에 자신의 account 사용을 위한 인증(authentication)을 요청하며, FIDO Server는 Device에게 challenge(random Number)를 보냅니다(실제 구현 시에는, challenge를 받은 다음에, 사용자 본인 확인 프로세스를 수행하는 순서로 되어 있습니다)..
Device는 자신의 Private-key로 challenge를 sign(전자서명)해서 FIDO Server로 보냅니다. Device에서 Private-key로 sign하는 기능을 assertion(승인) 이라고 하며, assertion 하는 데 사용되는 Private-key는 앞에서 언급한 “credential key pair” 에 속한 Key 입니다. 즉 Device는 FIDO Server에게 assertion(승인) 요청을 보냅니다.
FIDO Server는 내부에 보유한, 사용자 account에 해당되는 Public-key로 sign된 challenge를 검증하여, 검증되면 인증(authentication)이 완료 되었다는 것을 Device에게 알려 줍니다.
즉 assertion(승인)은 인증(authentication) 할 때 수행되는 프로세스 중 하나에 속합니다.
인증하는 과정이 Server에서 challenge(random number)를 Client에게 보내고, Client는 자신만이 보유하고 있는 Private-key로 challenge를 sign(전자서명)해서 Server로 돌려 보내면, Server는 Private-key에 대응되는 Public-key로 검증하는 것으로 되어 있습니다. 이러한 방식을 “Public-Key Cryptography 기반 challenge-response protocol” 이라고 부릅니다. UAF는 “Public-Key Cryptography 기반 challenge-response protocol”에다가 스마트폰이 가진 생체정보 인식 기능을 융합한 것입니다.
FIDO 인증 방식을 간단히 기술할 때, “사용자 단말기에서 인증을 한 후, 전자서명 값을 FIDO인증 서버로 보내어 서버에서 최종 인증하는 방식입니다” 라고 합니다. 첫 번째 “인증” 은 “Local 인증”을 의미하며, 두 번째 “인증”은 “서버에서 하는 원격 인증”을 의미 하지만, “인증”이란 용어가 두 군데 나오기 때문에 혼동을 줄 수 있으므로, 좀 더 명확히 기술하여, “사용자 단말기에서 먼저 사용자 확인을 한 후, 전자서명 값을 FIDO인증 서버로 보내어 서버에서 최종 인증하는 방식입니다” 라고 해야 합니다.
아래 그림은 인증 프로세스 개념을 보여 주는 그림입니다.
(출처 : FIDO Alliance )
5. FIDO 1.0 Device & Server 내부 동작 구조
아래 그림은 “UAF 지원 FIDO mobile device” 와 “U2F 지원 Device”의 내부 동작 구조 와 Server의 동작구조를 보여 줍니다.
※ Authenticator : ECDSA key-pair Generate 및 Sign 기능을 수행하는 H/W Module
※ ASM(Authenticator Specific Module) : Mobile Device Vendor 가 제공하는 S/W Library
※ U2F 방식에서 외부 Authenticator 와 I/F 방식에는 USB 외에 Bluetooth 와 NFC도 지원합니다.
※ App 과 Web Application은 RP(Relying Party) Client 라고 부르며, Web Server 는 RP Server라고 부릅니다.
6. FIDO 2.0
FIDO 2.0은 FIDO 1.0의 구성 요소인 FIDO Client, ASM, Authenticator를, OS 와 Web Browser로 구성된 하나의 Platform(플랫폼)으로 통합시켜 구현한 것입니다. 외부 인증장치(Authenticator)를 지원하기 위하여 CTAP(Client to Authenticator Protocol) 라 불리는 새로운 표준 프로토콜을 추가로 개발하였습니다. CTAP는 USB, Bluetooth, NFC I/F를 지원합니다(참고로, CTAP는 U2F 1.2를 기반으로 개발한 것이라고 합니다).
또한 사용자 Application에서 사용할 수 있도록, Web Authentication(WebAuthn) 이라 부르는 표준 API를 개발하였습니다. “WebAuthn API”는 FIDO Authentication을 Web Browser에서 가능하도록 하는 JavaScript API 입니다.
“WebAuthn API”를 지원 Web Browser 로는 Google사의 Chrome, Microsoft사의 Edge, Mozilla 재단의 Firefox 가 있습니다.
요약하면, FIDO 2.0 에서 지원하는 2개의 표준은 WebAuthn 과 CTAP 입니다.
Platform 기반 FIDO 2.0 은 Microsoft, Google 같은 Platform 업체가 주축이 되어 제공될 것이라고 합니다. 물론 FIDO 2.0 을 지원하는 즉 CTAP를 지원하는 외부 인증장치도 많이 개발될 것이라고 합니다. 스마트폰이 CTAP를 지원하면 스마트폰도 FIDO 2.0의 외부 인증장치로 사용될 수 있다는 것입니다.
참고로, Platform을 Web Platform 이라고도 부르는 데, Web Platform이란, W3C(World Wide Web Consortium), IETF 등의 단체에서, Web Page를 publication하기 위해, HTML, CSS, HTTP 와 같이 표준으로 개발한 Web 관련 기술들의 집합을 의미 합니다.
아래 그림은 FIDO 2.0의 내부 동작 구조를 보여 줍니다.
7. ITU standards(표준)
FIDO(파이도) Alliance는 2018년 12월 18일, UAF 1.1 과 CTAP Specification이, ITU standards((ITU-T Recommendations)으로 채택 되었다고 발표하였습니다.
FIDO UAF 1.1 : Recommendation ITU-T X.1277
CTAP : Recommendation ITU-T X.1278
8. FIDO 의 단점
서비스회사마다 등록 절차를 밟아야 합니다. 즉 서비스마다 “credential key pair” 을 생성해야 합니다. 이것은 오히려 security를 더 높일 수 있습니다.
FIDO 지원 Device 에서 생성되고 보관 중인, Private-key 가 외부로 나갈 수 없기 때문에, 사용자가 Device를 변경하면, 사용하고 있는 모든 서비스에 대하여, 다시 등록해야 합니다. 이를 극복하기 위해 .Private-key를 안전하게 복사하는 기능을 연구하고 있다고 합니다.
FIDO 지원 Device가 고장 나거나 분실되면(일시적 분실 포함), 대체 인증 수단이 없을 경우, 서비스를 받지 못하는 현상이 발생합니다.
단점은 아니지만, FIDO Server에서 보관 중인 사용자 Public-key가 외부 공격자로부터 부정조작을 당하면, 사용자는 더 이상 자신의 계정을 사용할 수 없게 됩니다. 물론 새롭게 등록을 하여 새로운 계정을 만들어 사용하면 되겠지만, 서비스회사로선 이미지에 손상을 입게 됩니다. 따라서 서비스회사 입장에선 사용자의 Public-key를, 이전 password 보관처럼, 안전하게 보관해야 합니다. 즉 FIDO Server가 해킹을 당하면, 개인 정보 유출은 발생하진 않지만, 서비스 거부 공격을 받게 되는 것입니다..
가장 큰 잠재적인(Potential) 문제점은, 기술적인 면이 아니라, 새로운 사회 범죄 현상의 출현에 대한 문제라고 생각됩니다. 범죄자들이 해킹으로 목적을 달성하지 못하니까, 물리적인 범죄 즉 스마트폰 같은 FIDO Device를 훔치며, 또한 소유자의 생체정보가 필요한 경우, 생체정보를 얻기 위해 또 다른 범죄 행위를 할 가능성이 있다라는 것입니다. 즉 사이버 범죄는 줄어들게 되겠지만, 물리적인 범죄가 증가되는 현상이 나타날 가능성이 있다라는 것입니다.
9. FIDO 인증과 모듈인증 방식의 2차 인증의 비교
결론은 "생체 인증을 도입했다"는 것이 아니라 기술 및 보안성 등 "어떤 생체 인증을 도입했느냐"가 관건
출처: https://m.blog.naver.com/aepkoreanet/221510427704
'▶ BaroSolution > 기술문서' 카테고리의 다른 글
비밀번호를 매번 사용할 때마다 매번 변하거나 한번 사용하고 버리는 일회성/휘발성 같은 동적보안 솔루션으로 대체 했을 때 이점 (0) | 2023.05.20 |
---|---|
BaroPAM 솔루션의 3단계 인증 체계란? (0) | 2023.05.04 |
웹 애플리케이션 서버(WAS) 로그인 시 보안의 취약점을 개선하기 위한 사용자 식별ㆍ인증을 위하여 2차 인증의 필요성 (0) | 2023.03.09 |
"2차 인증을 도입했다"는 것이 아니라 기술 및 보안성 등 "어떤 2차 인증을 도입했느냐"가 관건 (0) | 2023.02.15 |
정보자산의 보안을 강화하기 위하여 주목해야 할 것들 (0) | 2023.01.27 |