FIDO (Fast IDentity Online) 1.0
FAR (False Acceptance Ratio) : 타인 수락률 (보안성)
FRR (False Rejection Ratio) : 본인 거부율 (편의성)
보통 안드로이드 / 아이폰 지문의 FAR 은 0.002% 로, 50000명이 오면 통과할 수도 있다.
홍채는 0.0001% 로 가장 낮다.
그러나 사실은 Bandwith 로 따지면 패스워드가 가장 안전하다고 볼 수 있다.
지문 템플릿이 유출되면 안되므로 (변경이 불가하다)
ARM 社 에서 TEE (Trusted Execution Environment) 를 개발해 보관.
전세계적으로 서버가 지문 템플릿을 저장하는 경우는 없다.
페이팔에서 도용에 의한 사고율이 0.9%
어마어마한 돈을 들여 FDS 회사 $169M 에 사들였지만 0.3%
참고로 한국은 0.0002% 지만
ActiveX 엄청깔고 공인인증서 도입해야됨...
안되겠다 FIDO Alliance 를 만들자!
FIDO
- 가입자 인증 후 서버에 공개키 등록
- 서버가 Challenge 를 생성해서 보내면 클라이언트에서 전자서명 해서 다시 서버로 보냄
- 개인키 이용 권한 획득 행위를 다양화 (지문 / PIN / 얼굴인식 / 홍채 ...)
- 등록 :
TEE에서 비대칭키 생성하고 공개키를 서버에 등록하고 Attestation 을 함께 첨부함.
- 인증 :
서버가 보낸 Challenge TEE에서 개인키로 전자서명 해서 서버로 전송하고,
서버는 등록된 공개키로 이를 검증. 단, 부인방지의 기능은 전혀 없음.
- 거래 확인 : 거래하는 내용에 대해 확인 / 전자서명
인증 과정과 프로토콜은 동일하고, Challenge 와 서명해야 할 원문 데이터도 함께 옴
- 해지 : 단말에 저장된 이용자의 개인키 삭제
UAF (Universal Authentication Factor) : 모바일 중심 - 패스워드 없이 다양하게 인증
U2F (Universal 2 Factor) : PC 중심 - 패스워드 인증 후 2차 인증
Attestation : 이 공개키의 출처가 어디냐?
CA입장에서 사용자의 환경(USB/보안토큰/TEE)이 안전한지 확인할 방법이 전혀 없다.
사실 키를 관리하는 인증 장치가 다 다르므로, FIDO 에서는 이를 고민했다.
지문을 사용하는지, 패스워드인지, 얼굴 인증인지, 어떤 환경인지?
하지만 Attestation(증명) 이 쉽게 조작되면 안되므로,
제조사에서 FIDO 장치에 대해 인증서를 다 발행해 박아두었다.
공개키 키쌍 / 키길이 / 해시알고리즘 / 저장 위치 / 인증 행위 (PIN/지문/홍채)
등을 metadata에 기록.
원래 클라이언트 (삼성) - 서버 ( 라온시큐어 ) 도 다 호환 된다.
그러나 무결성 검증을 위해서는 서버에 Metadata 를 넣어줘야 하는데,
상업용 표준이다 보니 특히 삼성에서 잘 안준다. 돈 내야 준다.
FIDO 시스템 구성
[외부]
Relying Party Client (뱅킹앱) - HTTPS - Relying Party Server(뱅킹 서버) - FIDO Server
[내부]
FIDO Authenticator - FIDO ASM App - FIDO Client App - Relying Party Client(뱅킹앱)
FIDO Server : FIDO Authenticator 에서 생성된 사용자의 공개키를 등록/관리/검증
FIDO Client : 통신중인 Fido Server의 정책에 따라 인증장치(ASM/Authenticator)를 필터링 하는 역할을 수행하고 FIDO ASM 과의 업무 앱 간 중계 역할을 수행.
FIDO ASM : FIDO Client와 Authenticator 간의 중계역할을 수행하고, FIDO Client 가 요구한 Authenticator로 요청 명령을 전달, 생성된 응답을 Client로 리턴함.
오로지 등록할때 썼던 Fido Client App 에서 요청 했을 때만
FIDO ASM App 에서 데이터를 준다.
FIDO Authenticator : 생체 인증으로 사용자를 인증, 서버와의 원격 인증을 위한 공개키/개인키 쌍을 생성해 공개키를 서버로 전달하며, 개인키를 이용해 전자서명 수행함.
FIDO METADATA
어떤 인증인지 ? (지문 / 홍채 / 핀 / ...)
전자서명 알고리즘 종류
키가 어디에 저장되는지 ? (TEE / SDCARD / ...)
지문 정보가 어디에 저장되는지? (TEE / SDCARD / ...)
거래 확인 과정에서 TUI 를 사용하는지 ? (Trustzone 에서 띄운 UI)
FIDO UAF Registration (등록)
AppID (안전한 앱인지?) - https://fidotest.com/facetIDList.txt
Assertion : 서명값이라고 보면 됨
Assertion 구조
서버에서 생성한 Challenge 와 부가 정보를 포함해 전자서명.
서버에서는 METADATA를 통해 전자서명 알고리즘을 확인.
assertion = {Sprivatekey(AAID | H(fcparam) | keyID | Counters | PublicKey) | AttestationCert}
fcparam = {appID | chalenge | facetID | channelBinding}
각 항목 설명
challenge : RandomStr
KeyID : FIDO Authenticator 에서 키 쌍과 함께 생성한 키 ㅣ식별자
PublicKey : 이용자의 공개키
Sprivatekey : 제조사가 박은 Attestation 개인키로 서명 원문을 전자서명.
AttestationCert : FIDO Authentication 내 내장된 제조사 인증서
Counter : Attestation 개인키로 몇 번 서명이 이루어졌는가
FIDO Transaction Confirmation(거래 확인 전자서명) 구조
assertion = SprivateKey (AAID | nonce | H(fcparam) | H(TC) | KeyID | Counters )
fcparam = {appID | challenge | facetID | channelBinding}
H( ) : SHA256
KeyID : 전자서명시 사용된 개인키의 키 식별자
TC : 거래 확인용 데이터 Image 또는 Text
FIDO 의 특징
TEE / SE 사용 권장
허용하지 않은 RP Client 거절 : 가짜 앱 방지
등록 (모듈) 경로
FIDO 1.0 과 2.0 비교
일단 2.0부터는 Microsoft에서 주도하고 있고, 개념만 같지 스펙이 완전히 다르다.
아직 표준화 작업이 완료되진 않았다.
지원 RP Client : APP -> APP + Browser
통신 프로토콜 : UAF Protocol -> 단순 서명 값 전달
FIDO Client 호출 방식 : Intent, URL Scheme -> Javascript
FIDO Client 제공자 : 3rd Vendor -> Platform Vendor
FIDO Authenticator 제공자 : 3rd Vendor, 단말 제조사 -> Platform Vendor
외부 FIDO 인증장치 표준 연동 : X -> CTAP (USB, NFC, BLE)
번외 : 블록체인 - 작업증명
거래 데이터 : 누구계좌에서 누구 계좌로 돈을 보내겠다.
계좌는 누가 개설하는게 아니다. 그냥 내가 만들면 된다.
ECDSA 개인키 하나 만들고 공개키도 만들고 이걸로 계좌를 만든다.
만약 키를 잃어버리면 거기 안에 있는 비트코인은 평생 찾을 수 없다.
10분에 한번씩 블록이 만들어지고 모든 블록이 이전 블록의 해시값을 갖고있다.
이 해시값은 특별하며, 이걸 먼저 만들기 위해 모두가 경쟁한다.
10분안에 누군가 해시값을 공개하는데 6자리에 해당하는 해시값을 찾아 nonce와 함께 전자서명 해서 공개했는데
10분안에 누군가가 7자리에 해당하는 해시값을 찾음
9분 50초 안에 누군가 8자리 찾음 ; 이 사람에게 12.5 비트코인을 준다.
작업한 양 만큼 비트코인을 나눠주는 것도 있다.
해커가 블록 하나를 변조하려면 50% 이상의 마이너들의 정보를 동시에 바꿔야 가능하다.
과반이상이 동일한 정보를 갖고 있으면 그걸 맞다고 생각하니까.
0 개의 댓글:
댓글 쓰기