쎄이 시큐리티 - Say Security

몇 년 전 비트코인이 무엇인지 한창 화제였죠. 조금 잠잠해지나 싶더니 요새는 블록체인 기술을 활용해서 다양한 서비스에 활용하려는 움직임이 활발해지고 있습니다.

자... 기업에서 블록체인 기술을 이용해 새로운 서비스를 창출하거나, 블록체인 기반의 특정 솔루션 또는 서비스를 도입하고자 할 경우 보안 담당자로서 무엇을 이해하고 있어야 할까요? 

오늘은 비트코인을 기반으로 그 안의 핵심기술인 블록체인을 이해해보고자 합니다. 그리고 블록체인을 활용한다면 어떤 장단점이 있는지, 어떤 부분이 보안측면에서 체크포인트인지 정리해보고자 합니다.

비트코인에 대해서...

비트코인(Bitcoin)은 2009년 사토시 나카모토(Satoshi Nakamoto)가 만든 디지털 통화입니다. 비트코인은 블록체인을 기반기술로 하면서 통화거래내역을 P2P기반의 분산네트워크에 의해 공유되는 블록에 담아 다수에 의해 공유 및 검증되는 시스템이라 할 수 있습니다. 예를 들어, 자신이 보유한 비트코인으로 물건을 구매하기 위해, 상대방에게 비트코인을 지불하는 거래내용을 만들고(단순 텍스트에 불과) 자신만이 가진 개인키로 서명을 하여, 블록체인을 관리하는 P2P분산네트워크에 전송하면 다수의 노드에 의해 검증되어 블록체인에 거래내용이 추가되어 영구적으로 보관됩니다. 비트코인은 비트코인거래소에서 구매하거나 환전할 수 있는데 우리나라는 코빗(KORBIT) 등이 있습니다. 꼭 거래소가 아니더라도 비트코인을 가진 사람한테 돈을 주고 자신의 지갑으로 송금해달라고 해도 됩니다.

비트코인주소, 공개키

우리가 일반적으로 뱅킹을 이용해서 돈을 보내거나 받으려면 계좌번호를 알아야 하지요, 마찬가지로 비트코인도 계좌를 대신할 만한게 있는데 그것이 비트코인주소입니다. 비트코인거래를 위해 할일은 먼저 개인키/공개키 쌍을 생성합니다. 그리고 공개키를 해시한 값을 비트코인주소로 사용합니다. 이 비트코인주소는 계좌번호처럼 사용할 수 있고 그 주소로 보내지는 비트코인에 대한 거래권한은 비트코인주소(공개키)에 대한 개인키를 소유한 사람이 주인이 됩니다. 개인키관리가 얼마나 중요한지 알 수 있겠죠(개인키를 잃어버리거나 유출되면 모든 비트코인을 잃어버리는 것과 같습니다). 비트코인주소는 개인이 얼마든지 생성할 수 있고 제한이 없습니다. 비트코인주소는 임의의 문자열(1 또는 3으로 시작)이다보니 사람이 외우기 어려워 QR코드로 표현하여 사용하기도 합니다.

비트코인 거래 승인, 블록체인

비트코인 모바일 지갑을 사용한다면, 비트코인을 송금할 비트코인주소와 금액을 입력하면됩니다. 이 때 거래내용이 작성되면 실제 승인을 받기 위해서는 P2P네트워크에 전송되어 마이너(Miner)들에 의해 블록체인에 기록되어야 합니다. 마이너들은 거래내용을 검증하고 문제가 없으면 모든 노드들이 가지고 있는 블록에 추가를 합니다. 그러면 모든 노드들이 해당블록을 공유함으로써 소위 공개장부에 기록되어 거래가 승인되는 것입니다.

마이닝

거래승인을 위해 블록체인에 신규 블록이 추가되기 위해서는 네트워크에 존재하는 노드들이 신규 블록의 내용을 검증하고 공유해야하는데 이를 마이닝이라고 합니다. 마이닝을 하는데는 하드웨어도 필요하고 전기도 필요한데 왜 자발적으로 참여해서 블록체인을 형성해줄까요? 바로 비트코인을 얻기 위해서 입니다. 마이너는 블록마다 생성되는 비트코인(코인베이스)과 각 거래마다 존재하는 수수료를 얻게 됩니다. 새 블록으로부터 나오는 비트코인은 가장먼저 블록을 형성시키는 마이너에게 돌아가기 때문에 전문적인 마이너들은 해시연산(해싱파워가 중요)을 잘 하도록 하드웨어를 제작(ASIC)하고 어레이로 엮어 수입을 창출합니다.

마이닝 수입 = 블록 당 발생 비트코인(코인베이스) + 거래 수수료(거래자가 지불)

비트코인발행

블록이 새로 생성될때마다 비트코인이 거래와 상관없이 새로 생성됩니다. 블록의 첫번째 거래는 위에서 설명한 마이너의 수입에 해당되는 코인베이스라는 것인데요 이것은 비트코인의 화폐발행정책이기도 합니다. 블록은 계속 누적될텐데 함께 발행되는 비트코인이 무한대로 생기면 안되기 때문에 약 4년주기로 발행코인은 반감됩니다. 구체적으로 설명하자면, 처음 0번 블록체인이 생성되고 약 10분마다 한 개씩 블록이 추가되는데(이후에 설명), 4년이면 총 2,102,400분(60분×24시간×365일×4년)이고 10분에 1블록이 생성되니까 약 21만개의 블록이 생성됩니다.

그렇게, 처음 4년(2009년~2013년) 동안 약21만개의 블럭 생성 시 블록당 50비트코인이 발행되고 그 다음 4년(2013년~2017년) 동안 약21만개의 블럭 생성 시에는 발행코인이 반감되어 블록당 25비트코인 생성됩니다. 그러다 64회까지 반감되다가 그 뒤에는 더 이상 새로운 비트코인은 발행되지 않도록 설계되어 있습니다(비트코인의 체계라고 할 수 있죠). 마이너들은 발행된 비트코인과 수수료를 얻기 위해 열심히 블록체인 생성에 참여하고 있는 것이죠. 만약 점점 코인베이스 수익이 줄어 64회까지 반감된 뒤 수수료만 얻어야 한다고 할지라도 마이너들이 자원투자를 열심히 할지 잘 모르겠네요. 참고로 위 그래프는 비트코인의 발행이 기하급수적으로 줄어드는 것을 표현한 것입니다.

블록체인 기술에 대해 조금 더 자세히...

비트코인에 대해 개념을 알아보았지만 그 핵심은 블록체인입니다. 블록체인이 어떻게 생겼길래 분산구조로 안전하다고 하고, 한번 승인되면 위변조하기 어려워 무결성이 확보된다고 할까요. 

블록구조

블록체인이라는 것은 블록들이 체인형태로 연결되어 있는 것을 말합니다. 우선 블록의 구조를 살펴보겠습니다.

크게 블록크기/블록헤더/트랜젝션데이터로 구성됩니다.

• 블록크기 : 바이트 단위의 블록크기입니다.

• 버전 : 데이터구조의 버전입니다. 구조변경 시 필요하겠죠.
• 이전 블록해시 : 블록의 체인구조에서, 이전블록(부모블록)에 대한 해시 참조값입니다. 이렇게 이전 블록에 대한 해시를 참조함으로써 각 블록이 강하게 연결되고 중간에 블록이 훼손되기 어렵게 합니다.
• 머클루트 : 해당 블록에 포함된 거래로부터 생성된 머클 트리의 루트에 대한 해시이며, 블록에 들어있는 모든 거래의 요약본이라 할 수 있습니다. 비교적 큰 데이터 집합을 효율적으로 요약하고 검증할 수 있습니다.
• 타임스탬프 : 블록의 생성시간, 1970.1.1 이후 초단위 시간입니다.
• 난이도 목표 : bit값으로 블록의 작업증명 알고리즘에 대한 난이도 목표입니다. 이는 해싱을 어렵게 만드는 척도로서 블록 한개를 생성하는데 10분정도 걸리도록 유도합니다. 만약, 컴퓨팅 파워가 좋아지고 해싱파워(해시를 계산하는 능력)가 증가하여 10분이 걸리지 않으면 난이도를 높여 10분을 유지하도록 조정가능합니다.
• 난스 : 작업증명 알고리즘에 사용되는 카운터입니다.

• 트랜잭션 카운트 : 포함한 거래 개수입니다.
• 코인베이스 트랜잭션 : 블록 생성 시 발생되는 비트코인이며, 본 블록을 마이닝한 마이너의 수입이 됩니다.
• 트랜잭션 : 10분동안 수집한 거래정보입니다.

블록체인구조

위와 같은 블록들이 체인처럼 연결되면 오른쪽 그림과 같이 블록체인이 됩니다. 블록체인은 이전 블록의 해시를 참조하여 연결되기 때문에 중간에 데이터가 변경되거나 위조되기가 어렵습니다. 어렵다는 뜻은, 각 블록이 해시값으로 연결되어 있기 때문에 만약 중간의 값을 변경하려면 그 위에 있는 모든 데이터를 함께 변경해야합니다. 

• 블록높이 : 블록높이는 현재 블록 중 가장 최신의 블록을 뜻합니다. 블록체인의 각 노드들은 블록체인을 서로 공유하는데, 이 때 블록높이만 봐도 내가 최신인지 남이 최신인지 알 수 있습니다.

• 블록깊이 : 그림에서 1011번째 블록을 기준으로 본다면, 위에 몇 개의 블록이 있는지에 대한 값입니다. 즉, 위에 블록이 쌓일때마다 자신의 블록도 함께 승인이 됩니다. 만약 내용을 변경하고자할 경우 위의 블록까지 함께 변경해야 하기 때문에 보통 거래가 발생되어 블록에 저장되면, 6번의 승인이 이루어져야 취소가 불가능하다고 봅니다. 체인이 길어질 수록 수학적 계산의 양이 급격하게 늘어나기 때문이죠.

• 메인블록체인
• 2차블록체인 : 메인블록체인에서 브랜치 형성
• 고아(orphan)블록 : 수신된 블록의 이전(parent) 블록이 현 체인에 발견되지 않는 경우로, 대개 두 개의 블록이 각자 짧은 시간 내에 마이닝되어 반대의 순서(부모블록 전에 자식블록이 도착)로 도착한 경우 발생합니다. 고아블록풀에 저장되어 있다가 부모블록이 도착하고 기존 체인에 연결되면 고아풀에서 부모블록에 연결됩니다.

블록체인 특징 요약 (분산된 공개장부)

• 분산구조 : 중앙집중식이 아닌 P2P네트워크를 이용한 분산구조입니다. 블록체인 복사본들이 분산된 노드들에게 보관되어 있습니다.

• 투명성 : 블록체인내 모든 내용이 공유되어 있습니다. 

• 가용성 : 특정 노드가 서비스 불가하더라도 수 많은 노드들에 의해 블록체인이 유지됩니다. 즉, 중앙집중식인 경우 Single Point of Failure 가 존재하지만 블록체인은 안전하다고 할 수 있습니다.

• 신뢰성 : 다수에 의해 결정되므로 결과를 신뢰할 수 있습니다. 51%의 노드들이 모두 조작되거나 공격받지 않는 이상 신뢰할 수 있습니다.

• 무결성 : 블록체인에 기록된(승인된) 기록을 삭제하거나 조작할 수 없습니다.

블록체인 활용 시 고려사항

블록체인을 이용해서 기업의 서비스를 창출하거나, 블록체인기반 솔루션을 도입할 때 보안담당자로서 체크해야할 사항을 고민해보았습니다.(아직 보편적으로 도입된 것이 아니라 저도 상상을...)

데이터관점

- 블록체인은 무결성은 좋지만, 기밀성은 제공하지 않습니다. 이를 고려하여 어떤 내용을 불록체인에 담을 것인가가 중요합니다. 비트코인은 거래내역을 담았을 뿐, 어떤 서비스 또는 기능을 할 것인가에 따라 그 내용이 달라져야겠죠. 블록체인은 공개장부개념으로, 공개가능한 내용을 데이터로 가져가야 할 거라 생각됩니다.

- 블록체인 내 들어가는 데이터 크기를 고려해야 합니다. 블록체인은 영구적인 누적데이터이기 때문에 결국엔 풀노드에겐 스토리지가 지속적으로 증가할 수 밖에 없습니다.

- 승인을 취소하기 어렵다는 사실을 서비스 특성에 맞게 고려해야합니다. 비트코인에서 타인에게 잘 못 보냈을 경우 다시 찾을 수 없다는 것과 같은 이치입니다.

네트워크 관점

-  분산네트워크기반으로 그 규모에 따라 신뢰도가 높아지므로 규모를 고려해야 합니다. 분산네트워크를 크게 가져가면 인프라구성이 쉽지 않고 작게 가져가면 신뢰도가 떨어지겠죠.

- 마이너가 가져갈 이득은 무엇인지 고려해야 합니다. 비트코인의 경우 블록생성 시 발생되는 비트코인(코인베이스 + 수수료)을 수익으로 받기 때문에 마이너가 참여를 경쟁적으로 하고 있어 블록체인이 활성화되는 것입니다.

- 블록체인 생성 주기를 고려해야 합니다. 생성주기는 서로 트레이드오프 관계인 분기발생확률과 블록체인 내용의 확정시간을 조율하게 됩니다. 

보안 관점

- 개인키관리가 보안의 핵심입니다. 개인키를 잃어버리거나 유출되었을 때 전 재산을 잃어버리게 됩니다. 

- 기본적으로 익명성을 제공하지만 개인정보와 연결되면(가입시, 지갑사용 시 등) 과거 모든 데이터까지 개인정보와 매핑이 가능하므로 이에 대한 고려가 필요합니다.

- 공격가능성에 대해 대책을 마련해야 합니다. 의도적 분기유발, 특정 거래나 주소에 대한 DoS공격이 가능하며 특히 공격자가 소유한 해싱파워가 높을수록 공격가능성은 증대됩니다.

예) 고가의 물건 구매 후, 안전하다고 판단되는 6회의 승인(1시간정도)이 이루어지기 전 물건을 가져간다면 자신이 소유한 고성능 해싱파워를 이용해 종전 거래를 무효화할 수 있도록 공격가능

결국, 기업에서 블록체인 기술을 홀용하고자할 때 단순히 DB를 사용하지 않고 거대한 인프라기반의 블록체인을 쓰는 이유에 대해서 분명히 비교분석한 후 장단점을 고려하여 결정해야 겠습니다.

생체인증에 관한 이야기 시작....

최근 기사만 봐도 알 수 있듯이 최근 금융권에서는 FIDO도 뿐만 아니라, 손바닥 정맥이나 홍채인식을 통한 ATM 무인점포 등 생체인식 시스템을 경쟁적으로 도입하는 것을 알 수 있습니다.

관련기사, <직원·점포 없이 거래 맘대로...은행들 바이오인증 도입 붐>

FIDO는 애플페이, 삼성페이 등 생체인식을 활용한 모바일간편결제 및 인증 상용화에 따라 많은 주목을 받고 있고 이에 대해 제가 간단하게 포스팅도 했었습니다.

<핀테크 보안 핫 이슈, 생체인증을 주도할 FIDO 이야기>

위 글에서도 언급했지만, FIDO를 이용한 생체인증의 핵심은 공개키기반로서 실제 서비스를 제공하는 서버에 절대 사용자의 생체정보가 저장되지 않고 공개키만 저장된다고 설명했었습니다(생체인증은 사용자 단말에서의 개인키에 접근하기 위한 로컬인증에 사용할 뿐).

오늘은 같은 생체인증 이야기이지만, 생체정보관리 측면에서 FIDO와는 다르게 사용자의 생체정보를 서버에 저장하여 생체인증을 서비스하는 생체인식 시스템에 대해서 간략하게 설명하고자 합니다. 은행에서 도입하는 생체인식을 활용한 ATM 서비스 등은 홍채/정맥/지문 등 사용자의 생체정보를 은행들이 직접 수집/저장/관리하며, 사용자가 인증 시도 시 등록된 생체정보와 비교함으로써 본인여부를 판단합니다. 이러한 생체인식 시스템에 대해 개념적 구조설명과 기업 입장에서 사용자 생체정보의 보안요구사항에 대해 간략하게 이야기 하겠습니다.

생체인식에 사용할 생체정보의 특성

생체인증은 본인을 증명하는 수단으로써 기존의 패스워드가 아닌 사용자가 보유한 생체정보를 이용하기 때문에 생체인식 시스템에서 사용할 생체정보는 다음의 특성이 요구됩니다.

• 보편성(Universal) : 누구나 갖고 있는 특성
• 유일성(Unique) : 각 개인을 구별할 수 있는 고유한 특성
• 영속성(Permanent) : 변하지 않고 변경이 불가한 특성
• 획득성(Collectable) : 센서에 의한 획득과 정량화가 용이한 특성

이러한 요구특성을 고려하여 홍채, 지문, 정맥, 음성 등 다양한 생체정보를 활용하게 됩니다.

예를 들어, 후지쯔사에서는 손바닥의 정맥을 이용하여 생체정보를 추출합니다.

생체인식 시스템 구조

[용어정의]

• 생체인식 특성(Biometric Characteristics) : 생체인식 특징을 추출할 수 있는 개인의 생리학적 특성이나 행동 특성

• 생체인식 샘플(Biometric Sample) : 생체인식 획득 서브시스템으로부터 얻은 생체인식 특성의 아날로그 또는 디지털 표현

• 생체인식 레퍼런스(Biometric Reference) : 하나 이상의 저장된 생체인식 샘플, 생체인식 템플릿 또는 생체인식 모델

• 생체인식 특징(Biometric Feature) : 생체인식 샘플에서 추출된 것으로 비교에 사용되는 데이터(숫자 또는 레이블)

생체인식 시스템의 구조는 아래 그림과 같습니다.

<그림> 생체인식 시스템 구조

DATA Capture Subsystem(데이터 획득 서브시스템)

이 서브시스템은 센서를 통해 사용자의 생체인식 특성을 입력받아 생체인식 특징을 추출하기 위한 생체인식 샘플을 생성합니다. 예를 들어, 지문인식의 경우 지문이미지, 음성인식인 경우 음성 녹음파일 등을 추출합니다. 생체인식 샘플은 같은 사용자가 사용할 때마다 매번 다른 샘플이 추출될 수 밖에 없습니다. 그 이유는 센서를 통한 인식 시 조명, 온도 등 주변 환경 및 사용자의 사용패턴에 따라 매 번 다를 수 밖에 없기 때문입니다.

Signal Processing Subsystem(신호처리 서브시스템)

이 서브시스템은 생체인식 샘플을 입력받아 다른 샘플과 유사도를 비교할 수 있는 생체인식 특징을 추출합니다. 생체인식 특징을 추출하는 알고리즘은 제조사 고유의 기술로서 이에 따라 얼마나 효율적으로 정확하게 비교할 수 있는지가 결정됩니다. 참고로, 사용자가 처음 생체정보를 등록할 경우, 이 서브시스템에서 추출된 생체인식 특징은 데이터 저장 서브시스템에 생체인식 레퍼런스로 저장됩니다. 등록 이후 사용자 인증을 시도할 경우 생체인식 특징은 저장된 생체인식 레피런스와 비교하기 위해 비교 서브시스템으로 전달될 것입니다.

Data Storage Subsystem(데이터 저장 서브시스템)

이 서브시스템은 사용자의 등록된 생체인식 레퍼런스를 저장하는 데이터베이스입니다. 주로 사용자의 신원정보와 함께 연계할 수 있도록 구성됩니다. 하지만 생체인식 레퍼런스 데이터베이스는 개인정보 보호를 위해 신원정보와 직접적으로 연결하지 않고 논리적/물리적으로 분리운영해야 합니다. 예를 들어, 생체인식 레퍼런스 데이터베이스가 해킹당하더라도 누구의 생체정보인지 바로 알 수 없도록 보호해야 합니다.

Comparison Subsystem(비교 서브시스템)

이 서브시스템은 사용자로부터 획득된 생체인식 특징을 저장된 생체인식 레퍼런스와 비교하여 유사도를 측정합니다. 비교대상의 일치여부를 판별하지 않고 유사도(특징이 얼마나 유사한가)를 측정하는 이유는 앞서 설명한 바와 같이 같은 사용자가 같은 센서를 사용하여 생체인식 샘플을 추출하더라도 절대 환경적 요인으로 같을 수는 없다는 사실에 기반하여 일치할 수는 없는 것입니다. 하지만 같은 사용자이기 때문에 거의 유사한 특징이 추출되겠죠. 다시 말해, 인증 시도 시 유사하기는 하나 일치할 가능성이 거의 없으며 오히려 완전히 일치하는 경우 재사용 공격으로 판단하는 것이 옳을 것입니다.

그리고 비교 서브시스템에는 1:1 비교하는 경우와 1:N으로 비교하는 경우가 있습니다. 만약 주민등록번호 같은 신원정보와 함께 생체인증을 시도하는 경우 해당 신원정보에 해당하는 저장 정보와 1:1 비교를 하겠지만 아무 정보 없이 생체인증을 시도할 경우 1:N으로 비교해서 해당 사용자가 존재하는지 부터 판단하게 되겠죠.

Decision Subsystem(판정 서브시스템)

이 서브시스템은 비교 서브시스템으로부터 유사도(점수)를 입력받아 인증 성공 또는 실패를 결정합니다. 임계치를 설정하여 유사도가 임계치를 넘으면 성공이고 그 보다 낮으면 실패로 판정하는 개념입니다. 임계치를 설정하는 것이 매우 중요하겠죠.

생체인식 정확도 측정 기준

생체인식을 사용할 경우 위의 각 서브시스템 특성에 따라 정확도가 높을 수도 있고 낮을 수도 있습니다. 정확도가 높을 수록 신뢰할 수 있고 비용도 비싸겠죠. 생체인식 시스템의 정확도를 측정하는 기준은 아래와 같습니다.

  1) 본인거부율(FRR: False Rejection Rate)

   - 허가된 사용자(본인)가 시스템의 오류로 인하여 접근 거부되는 비율

  2) 타인허용율(FAR: False Acceptance Rate)

   - 허가되지 않은 사용자(타인)가 시스템의 오류로 인하여 접근 허용되는 비율

  3) FRR/FAR 교차점(CER : Crossover Error Rate)

   - 본인거부율(FRR)과 타인허용율(FAR)의 교차점

   - EER : Equal Error Rate

  4) 등록실패율(FER : Failure to Enroll Rate)

   - 하나의 생체 원시 데이터 레코드를 등록할 수 없는 사용자가 발생할 비율

• 시스템의 정책과 중요도에 따라 생체인식 시스템에 요구되는 FAR과 FRR의 값이 달라짐

• 엄격한 보안이 요구되는 경우는 FAR을 낮추고 FRR을 증가시킴으로써 보안성을 향상시킬 수 있음

생체인증의 키인 생체정보에 대한 보안요구사항

기밀성(Confidentiality)

저장된 생체인식 레퍼런스는 개인의 중대한 프라이버시에 해당하기 때문에 기밀성이 확보되어야 합니다. 검증 및 식별을 위해 신원정보와 결합되거나 비교 서브시스템으로 전송 시 접근 통제 및 다양한 암호화 기법을 적용해야 합니다.

무결성(Integrity)

생체인증의 신뢰도를 위해서는 생체인식 레퍼런스가 악의적 공격에 의해 위변조되거나 시스템의 오동작에 의해 무결성이 훼손되지 않아야 합니다. 

재발급성 및 폐기성(Renewability and revocability)

앞의 기밀성과 무결성은 보안의 3요소에도 있듯 당연하게 생각되겠지만 이 부분은 조금 생소할 수 있습니다. 만약 아이디/패스워드가 유출된 경우 어떻게 대응합니까? 사실을 알리고 패스워드를 급히 변경하게 하죠. 생체인식도 마찬가지 입니다. 생체인식 레퍼런스 데이터베이스가 해킹되거나 훼손된 경우 대응방안으로 해당 레퍼런스는 즉시 폐기하고 재발급해야야 할 것입니다. 앞에서 사용자의 생체인식 특성으로부터 샘플 및 특징을 추출하는 것은 생체인식 시스템의 중요한 기술이라고 했습니다. 재발급은 사용자의 생체정보가 노후화되어 인증성공률이 낮아져 갱신하기 위해 재발급하는 일반적인 경우도 있겠지만, 해킹에 의해 유출되어 재발급해야 한다고 생각해봅시다. 사용자의 생체정보가 변했을리 없는데(영속성: 변해서도 안되고) 같은 센서, 같은 특징추출 알고리즘을 적용할 경우 재발급한 레퍼런스는 유출된 기존 레퍼런스와 유사하게 생성될 수 밖에 없습니다. 이는 유출된 레퍼런스를 폐기하고 재발급했다고 보기 어려울 것입니다(유출된 패스워드를 새로운 패스워드로 변경하는 것과 같은 이치). 같은 생체정보로부터 다른 레퍼런스를 생성할 수 있어야 가능하겠죠. 

생체인식 시스템 도입 시 보안 담당자로서의 체크 포인트

생체인식 시스템을 도입할 경우 다음을 고려해야 할 것입니다.

신뢰도

앞서 설명한 생체인식 정확도 측정기준을 활용하여 신뢰도를 고려해야 합니다. 특히, 보안측면에서는 타인수용률인 FAR이 매우 중요합니다.

생체인식 시스템의 보안 요구사항

생체인식 레퍼런스의 기밀성, 무결성, 재발급성 및 폐기성이 확보되는지를 고려해야 합니다. 최근 생체인식 시스템의 경우 기밀성과 무결성은 어느 정도 만족하지만 재발급성 및 폐기성을 제공하는 업체는 많지 않은 것 같습니다. 현재는 금융권에 생체인식 시스템이 활성화되는 시작단계라서 사용자의 생체정보가 수집된 경우가 극히 적지만, 앞으로 생체인식 시스템이 더욱 활성화 된다면 수집 및 저장되는 경우가 많아지고 관련 사고발생 시 그 대응방안으로 재발급성 및 폐기성이 핵심화두로 떠오르지 않을까 개인적으로 생각합니다.

생체정보 프라이버시

생체정보는 매우 민간함 개인정보로서 다음을 고려해야 합니다.

• 비가역성(Irreversibility) : 사용자로부터 추출한 생체인식 데이터는 비가역적으로 처리되어 생체인식 데이터로부터 사용자정보를 알 수 없어야 함
• 불연계성(Unlinkability) : 저장된 생체인식 레퍼런스는 애플리케이션 또는 데이터베이스 간에 연계 불가해야함
• 기밀성(Confidentiality) : 생체인식 레퍼런스에 접근하는 것을 방지하기 위해 생체인식 레퍼런스는 기밀성을 유지해야 함

위와 같은 목표와 함께 생체인식 정보 라이프싸이클(수집/저장/사용/폐기)에 따른 프라이버시 보호 대책을 수립해야 합니다.

단계별 위협 대책

생체인식 시스템의 각 단계별 위협에 대한 보안대책을 고려해야합니다.

• 데이터획득/신호처리 단계 : 생체인식 샘플이나 특징에 대해 도청/재사용/무작위대입
• 저장/비교 단계 : 생체인식 레퍼런스에 대해 도청/재사용/힐클라이밍
• 판정 단계 : 유사도 점수 및 임계치 조작

기타

• CC인증 등 신뢰있는 기관으로부터의 인증 확인
• 사업 특성을 고려하여 적절한 생체인증 유형 검토
• 이중화, 아카이빙 및 백업 등 가용성 확보 대책 등

더 자세한 내용은 생체인식 시스템 관련 표준을 참고하면 되겠습니다.

ISO/IEC 24724 Biometric Templete Protection

X9.84 Biometric Information Management and Security for the Financial Services Industry

한국정보보호진흥원, 생체정보 보호 가이드라인 (2005) 등

<추가>

관련 기사 참조하시면 좋겠네요.

<금융권 흔드는 생체인증, 얼마나 안전할까?>

위 기사에서 얘기하는 보안 대책 중,

- 전체지문정보를 저장하지 말라는 것은 비가역성과 연관이 있고

- 템플릿을 비밀번호 변경하듯 변경할 수 있어야 한다는 것은 재발급성 및 폐기성과 관련이 있습니다.

- 마지막으로, 템플릿을 분산저장하는 것은 그 방식자체가 템플릿 유출 가능성을 낮출 수는 있으나 완전히 제거할 수 있는 것은 아니기 때문에 재발급성과는 별개로 대책수립이 되어져야 할 것입니다.

[참조]

X9.84-2003 Biometric Information Management and Security for the Financial Services Industry

ISO/IEC 24745 Biometric Templete Protection

http://www.christoph-busch.de/files/Busch-EAB-ISO-24745-120713.pdf

좀 지난 이야기지만, HCE의 기술적 특징을 중심으로 HCE NFC 모바일결제에 대해서 이야기 하고자 합니다.

모바일결제 분야에서 SE중심의 주도권 경쟁

핀테크열풍에 각종 페이들이 나오고 있죠. 사용자는 편하기만 하면 되지만 업계는 결제분야에 주도권을 장악하기 위한 전쟁터나 다름 없습니다. 모바일 카드결제에서 가장 중요한 것은 무엇일까요? 안전한 카드정보의 관리입니다. 사실 보관만 잘 하면 되는 것이 아니라 사용 시 POS같은 결제단말기에서도 정보가 유출될 수 있기 때문에 각종 부정거래사고가 발생하는 것이구요.

모바일결제에서 결제앱이 SW로 구현되다 보니 해킹당한 단말에서 중요정보가 유출되는 것은 시간문제죠. SW의 보안강도를 높여나가긴 하지만 결국은 SW접근을 엄격히 통제하는 별도의 하드웨어공간을 필요로 하게 되는데 그것을 SE(Secure Element)라고 합니다. 우리나라에서는 통신사 가입모듈인 USIM에 있는 SE를 많이 사용해오고 있습니다.

이는 통신사 소유이다보니 통신사에게 수수료도 지불해야 할 뿐만 아니라 통신사에 대한 종속성도 커지니 카드사들은 좋을리가 없겠죠. 반면에 하드웨어 제조사들은 단말 내에 고정 장착된 eSE(Embeded SE)를 제공하고 활성화하려고 많은 노력을 하고 있습니다. 최근에는 TEE(Trusted Execution Environment)라고 해서 ARM Trustzone과 같이 격리된 별도의 하드웨어에서 안전하게 보안서비스를 할 수 있도록 제공하기도 하면서 주도권을 장악하려고 합니다. 

통신사/제조사의 종속성 탈피를 위한 선택, HCE

이런 와중에 카드사 입장은 어떨까요. 보안도 신경써야겠고 USIM을 많이 이용할 수록 통신사에 종속되고, eSE를 사용하자니 단말종속성이 발생합니다. 구글월렛이라는 모바일결제시스템을 가진 구글도 마찬가지 고민을 한 끝에 안드로이드 4.4부터 SE를 사용하지 않는 HCE(Host-base Card Emulation)를 지원하게 되었습니다. 그럼, HCE의 개념을 살펴보도록 하겠습니다.

먼저 SE를 사용하는 NFC card emulation은 아래와 같습니다.

<출처:http://developer.android.com/>

SE에 카드정보를 앱을 통해 저장한 환경에서, Reader(NFC결제 단말기)에 단말을 접근시키면 NFC 컨트롤러는 SE로 라우팅을 하고 Reader는 SE와 직접적으로 연결되는 형태입니다. 즉, SE에서 Reader가 통신하며 안드로이드 앱은 전혀 개입하지 않는 구조입니다.

<출처:http://developer.android.com/>

반면에 안드로이드 4.4부터 지원하는 HCE는 SE없이 NFC 컨트롤러가 SE가 아닌 CPU로 연결되고 관련된 앱을 직접 연결할 수 있도록 지원합니다. 물론, HCE지원 버전에서 SE도 사용할 수 있습니다. 어떤 서비스를 호출할지에 대해서는 AID라는 것을 등록하여 선택하도록 되어 있는데 AID에 따라 컨트롤러에서 라우팅을 합니다. 

딱 여기까지가 HCE입니다. 일반적으로 HCE 관련 자료를 보다보면 항상 클라우드가 등장하는데 클라우드로 할지 그냥 앱내 관리할지 그것은 NFC컨트롤러가 연결해준 앱(서비스)의 몫인 것입니다.

결론은, 안드로이드가 4.4버전부터 SE를 사용하지 않을 수 있는 NFC결제 기능이 HCE라는 이름으로 생겼다는 사실입니다. 이것은 적어도 통신사 USIM이나 제조사 eSE 종속성이 사라지고 안드로이드 4.4 이후 버전은 모두 범용적으로 사용가능하다는 장점입니다.

SE탈피는 했는데, 그 다음은?

그렇다면, 앞에서 설명할 때는 중요 결제정보의 안전한 보관을 위해 SE가 필요하고 했는데 HCE는 오히려 SE를 탈피하고 있으니 보안은 어떻게 된걸까요? 당연히 더 취약해질 수 밖에 없습니다. 안드로이드의 샌드박스를 믿고 앱내 저장할 수도 없고(샌드박스를 믿을 거였으면 처음부터 SE가 필요하지도 않았겠죠), 결국 외부 서버에 저장하는 방식을 선택하게 됩니다. 그래서 클라우드 얘기가 함께 등장합니다. HCE방식을 도입한 VISA카드는 아래와 같이 잘 표현해 놓았습니다.

<출처 : VISA Korea>

HCE를 도입한 경우 SE에 저장할 정보를 클라우드에 저장함으로써 취약한 단말의 경우에도 안전하게 보관가능하다는 얘기입니다.

그렇다면, 카드정보를 클라우드에 저장한다고 하면 다 된 걸까요? 실제 NFC단말에 결제를 시도할 경우 결국은 클라우드에 있는 카드정보를 네트워크 통신으로 수신하여 전송해야하지 않을까요? 그 과정에 카드정보는 앱에서 처리하게 될테고 결국 유출이 될 수 있겠죠. 이를 보완하기 위해서는 애플페이나 삼성에서도 사용하는 토큰화(Tokenization) 기술을 도입하여 OTP처럼 1회용 카드번호를 사용할 수 밖에 없는 것입니다.

토큰화기술 활용

토큰화에 대해서도 많은 내용이 있지만, 애플페이의 토큰화 기술 처리흐름도를 이용하여 간략하게 개념만 설명해보겠습니다.

<출처:여신금융협회>

요약하면, 가맹점의 NFC결제단말기에 절대로 카드정보를 제공하지 않는 것이 핵심입니다. 토큰화서버에게 카드정보에 해당하는 토큰을 발급받아 결제단말기에 승인요청하면 다시 토큰화서버를 통해 다시 카드정보로 복원되어 결제승인이 이루어 집니다.

애플페이는 SE에 카드정보를 저장하지만, HCE를 사용한다면 서버에 카드정보가 이미 있으니 다른 방식으로 사용자를 인증하고 해당하는 카드정보의 토큰을 발급받아 사용하면 되지 않을까 생각됩니다.

제 생각엔, HCE방식이 결코 SE를 활용하는 기술보다 더 안전하다고 생각되지는 않습니다. 다만 종속성을 탈피하고 하드웨어 관련 비용을 절감하면서 어느 정도 보안 수준을 유지할 수 있으니 카드사 입장에서는 충분히 메리트가 있습니다.

HCE NFC 모바일 결제방식을 도입하는 보안 담당자로서 체크포인트

HCE가 아무래도 SW이기 때문에 SE를 사용할 때 만큼의 보안수준을 유지할 수 있는 방안이 무엇인지 확인해야 합니다. 위에서 설명한 것처럼, 중요정보를 보관하는 것 뿐만 아니라 사용시에도 중요정보 유출을 방지할 수 있는지 확인해야 합니다. 일단 HCE NFC 모바일 결제 앱 구현 시 앱 무결성탐지 및 루팅탐지 등 보안솔루션을 도입하더라도 100% 안전한 것이 아니기 때문에 앱은 신뢰하지 않는 다는 전제로 다양한 인증, 암호화기술, 토큰화 기술 적용 등 구조적으로 보완할 수 있는 다양한 방법을 활용해야 할 것입니다.

최근 핀테크...핀테크..하면서 정부정책부터 기업에 이르기까지 핀테크로 먹거리를 찾기위해 분주하죠. 우리나라에서는 소위 '천송이코트' 이슈로 인해 불거졌다고 할 수 있는데요. 핀테크분야도 광범위하지만 그 중에서도 우리나라에는 간편결제분야에 많이 집중하고 있죠. 핀테크에 대해서는 나중에 따로 정리한번 하도록 하고 간편결제 또는 간편송금 등에 활용할 간편인증 방식으로 각광받고 있는 FIDO에 대해서 이야기 하고자 합니다.

FIDO 등장배경

FIDO는 Fast IDentity Online의 약자로서, 온라인 환경에서 빠르게 인증을 수행하기 위한 기술표준입니다. 지금도 온라인상에서 많은 사이트에 가입하고 로그인 하면서 쓰고 있는데 왜 굳이 FIDO라고 해서 새롭게 등장하는 것일까요? 우리는 기억도 못할 정도로 다양한 곳에 아이디와 패스워드를 만들고 가입하여 사용하고 있습니다. 항상 패스워드에는 보안을 강화하라고 하고 있지만 너무 많은 곳에 패스워드를 등록하여 사용하는 우리는 그것들을 다 기억하기 어렵죠. 그래서 대부분 동일한 아이디와 패스워드를 사용함에 따라 한 번 패스워드가 유출되면 그 파급 효과는 엄청나겠죠.

이렇듯 패스워드 의존도는 낮추면서 개방성˙확장성˙상호운용성을 제공하는 인증방식 개발을 목표로 2012년 7월 비영리단체인 FIDO Alliance가 설립되었고 2014년 12월 9일 FIDO 1.0을 공개했습니다. 조만간 2.0이 나올 것으로 알고 있구요.

FIDO의 2가지 표준

FIDO Alliance에서는 2가지의 표준을 공개했습니다. 두 표준 모두 공개키방식이며, 둘 중 원하는 것을 선택해서 활용하면 됩니다.

첫 째는 UAF(Universal Authentication Framework)표준으로 비패스워드(Passwordless)방식으로 지문, 음성, 홍체, 얼굴 등 사용자 고유의 생체정보 인증방식입니다. 디바이스에서 생체인증을 성공하면 디바이스에 저장된 개인키에 접근권한이 발생하여 전자서명하는 방식입니다.

둘 째는 U2F(Universal 2nd Factor)표준으로 기존 패스워드방식을 1차 인증요소로 사용하고 보안키를 저장한 동글을 이용하여 2차인증을 추가하는 인증방식입니다. USB로 연결된 동글내 버튼을 누르거나 NFC를 이용하여 탭핑하는 방식 등이 사용 시나리오로 등장합니다.

FIDO 사용 사용시나리오

생체인증을 활용하는 UAF를 예를 들어 FIDO를 어떻게 사용하는지 알아보겠습니다.

크게 ①등록, ②로그인 하는 시나리오에 대해서 설명하겠습니다.

등록

site.com에서 FIDO인증을 사용하기 위해 ①등록버튼을 누르고 ②지문인증을 하면 ③디바이스의 안전한 공간에 개인키/공개키 쌍을 새로 생성하여 ④site.com에 공개키를 전송하여 등록하게 됩니다. 이 때, 새로은 키는 디바이스별/서비스별/사용자계정별로 고유하게 생성됩니다.

로그인

등록된 site.com 사이트에 FIDO를 이용하여 쉽게 로그인하는 과정입니다. ①site.com에 로그인버튼을 누르고 ②지문인증을 하면 ③사이트에 등록된 공개키 쌍에 해당하는 개인키에 접근이 가능하고(실제 첼린지방식의 전자서명 수행) ④서버는 전자서명 확인 후 서비스에 로그인이 됩니다.

중요) FIDO를 생체인증이라고 생각하지만 생체인증은 디바이스 단에 저장된 개인키에 접근하기 위한 편리하고 안전한 인증수단을 제공할 뿐(디바이스 로컬인증) 실제 서버와의 인증 자체는 공개키방식이라고 생각하면 됩니다.

FIDO 주요 구성

UAF에 대한 구성을 살표보겠습니다.

UAF 프로토콜

사용자 단말과 서비스간의 프로토콜로서 앞에서 설명한 등록 및 사용자 인증(로그인)을 위한 프로토콜 외에 등록을 해제하는 등록해제, 그리고 보안 트랜잭션 확인(ex: 거래내용 확인) 프로토콜을 제공한다.

UAF 클라이언트/서버

UAF 프로토콜 통신을 위한 클라이언트 및 서버에 해당합니다. 클라이언트는 디바이스내 위치하고 서버는 서비스에 위치하여 등록된 사용자 계정에 대한 UAF 인증자 관리 등의 역할을 수행합니다.

UAF 인증자(Authenticators)

인증자는 보안 엔티티(Secure Entity)에 인증키를 생성하고 인증을 위한 서명을 수행합니다. 그림에서도 알 수 있듯이 인증자는 하나의 디바이스에 여러개가 존재할 수 있는데 지문, 홍체, 음성 등 생체인증 유형 별 제조사에 따라 존재하게 됩니다. 예를 들어, 삼성갤럭시 휴대폰의 지문인증도 하나의 인증자를 제공하고 임의의 기업이 삼성지문인증을 활용하여 다양한 서비스를 만들기 위해 FIDO 클라이언트를 구현하여 활용할 수 있는 구조입니다.

FIDO 프로토콜 동작 방식

앞에서 등록과 인증시나리오에 대해서 살펴보았으나 이번에는 FIDO에서 제공하는 4가지 프로토콜에 대한 플로우를 간단히 알아보겠습니다.

인증자 등록(Authenticator Registration)

①등록을 시작하면 ②서버에서 인증자에 대한 정책을 보내줍니다.

③사용자는 사용할 인증자를 선택하여 로컬인증을 수행하면 고유한 개인키/공개키 쌍을 생성하여 개인키는 안전한 보안엔티티에 저장하고 ④공개키는 서버로 전송한다. 이 때 Attestation(Authenticator Attestation ID, 인증자의 밴더 및 모델에 따라 제조시 저장한 고유한 키)를 함께 전송하면 ⑤서버에는 응답을 확인하고 Attestation과 공개키를 저장한다.

인증(Authentication)

①인증을 시도하면 ②서버에서 인증자에 대한 정책과 함께 첼린지값을 보내줍니다.

③사용자는 로컬인증을 수행하면 해당 개인키를 사용하여 첼린지 값에 전자서명을 하고 ④서버로 전송합니다. ⑤서버는 서명된 첼리지값을 사용자의 공개키로 검증함으로써 인증을 완료합니다.

트랜잭션 확인(Transaction Confirmation)

트랜잭션 확인의 활용을 예를 들면, 금융거래 후 거래할 내역이 맞는지 확인할 때 사용할 수 있습니다. 거래내용을 클라이언트에 전송하고 거래내용에 개인키로 서명하게 함으로써 중요거래에 대해 사용자에게 확실하게 인증받는 것입니다. 거래내용 무결성에 해당하고, 이를 잘 활용하면 부인방지에도 활용할 수 있겠죠.

①거래확인을 시도하면 ②서버에서는 트랜잭션 텍스트를 보내줍니다. 거래내용 등이 들어갈 수 있겠죠.

③사용자는 수신된 트랜잭션 텍스트를 확인하고 로컬인증을 수행하면 확인한 트랜잭션 텍스트에 대해 해당 개인키를 사용하여 전자서명을 하고(해시를 이용할 수도 있겠죠) ④서버로 전송합니다. ⑤서버는 트랜잭션 텍스트 서명값을 사용자의 공개키로 검증함으로써 트랜젝션 텍스트에 대한 무결성을 보증할 수 있습니디ㅏ.

인증자 해제(Authenticator Deregistration)

서비스를 더 이상 사용하지 않을 경우 해제를 할 수 있습니다.

①서버에 접속 후 해제를 신청하면 ②서버로부터 등록해제메시지를 수신하면 ③인증자에서 관련 정보를 삭제합니다. 물론 서버에서도 삭제를 하겠죠.

금융거래 활용 시 보안 담당자로서의 체크포인트

지금까지 FIDO 개념으로 시작해서 프로토콜까지 살펴보았습니다. 요약하면 FIDO는 온라인 환경에서 편리하고 안전하게 인증을 하기 위한 기술표준이며 주로 생체인증에 많이 사용될 수 있습니다. FIDO는 생체인증을 지원하지만 실질적으로는 공개키방식이라는 점을 인지하셔야 하며, 개인키에 접근하기 위해 다양한 인증을 제공할 수 있고 다양한 인증을 제공하기 위해서는 인증자가 제조사로부터 공급되어야 합니다. 또한 FIDO 생체인증을 활용할 경우 클라이언트 단말에서나 생체정보가 활용되는 것이지 서버에는 절대 사용자 생체정보가 저장되는 것이 아닙니다(공개키가 저장될 뿐). 

다양한 인증방식이 생길 수록 다양한 제조사가 생긴다는 얘기인데요, 결국은 개인키관리가 보안의 핵심인데 이를 관리하는 인증자를 얼마나 안전하게 만들었냐가 중요합니다. 따라서 생체인증을 이용하여 FIDO를 도입할 경우 개인키관리를 얼마나 잘하는지가 중요하겠습니다. 

그리고, FIDO를 이용하여 최근 단순인증기능에 사용하기도 하고 금융거래에서 공인인증서를 대체하여 사용하려고 하기도 합니다. FIDO를 어디에 활용하느냐에 따라 그 중요도가 달라지는데요, 만약 금융거래 중 계좌이체에 활용한다고 가정하면 높은 보안강도를 필요하겠죠. 게다가 우리나라에서는 아직도 부인방지에 대해 많이 고민하는 것 같습니다. 만약 FIDO를 이용하여 거래사실에 대한 부인방지까지 고려하고 싶다면 결국 TTP(Trusted Third Party)에서 공개키를 인증할 수 있는 기반구조를 구축하는 것이 가장 확실하겠죠. 그런데 이런 모양으로 가다보면 결국 공인인증서의 또 다른 형태가 될 것 같습니다.

마지막으로, FIDO 도입 시 FIDO Alliance 에서 인증여부를 확인 할 수 있습니다.

(https://fidoalliance.org/certification/fido-certified)

Client/Server/Authenticator 로 구분하여 각 제조사별로 인증여부에 대한 정보가 공개되어 있으니 도입 시 확인하시면 도움될 것 같습니다.

[참고]

https://fidoalliance.org/specifications/overview

UAF Technical Overview, Davit Baghdasaryan, Nok Nok Labs