쎄이 시큐리티 - Say Security

보안책을 보면, 늘 앞에 나오는 것이 암호화죠.

암호화는 보안의 3요소(기밀성/무결성/가용성) 중 기밀성을 중점적으로 제공합니다.

기밀성을 간단히 얘기하면, 허가받은 사용자만이 접근하게 하는 것이죠. 암호화는 복호화키를 알고 있는 사람만이 접근할 수 있게 하기 때문에 기밀성을 제공합니다.

암호는 IT환경에서 안쓰이는 곳이 거의 없습니다.

예를 들면, 인터넷뱅킹을 한다고 하면 ID/PWD 로그인을 하더라도 해당 정보가 암호화 되어 서버로 전송됩니다. 공인인증서를 쓸 때도 사용되구요, 단순히 웹페이지를 접근할 때도 https를 쓰는 환경이라면 모든 컨텐츠를 암호화되어 송수신되죠. 계좌번호나 중요한 정보 입력할 때는 스마트폰이나 피씨 등 클라이언트에서부터 중요정보유출을 방지하기 위해 입력 즉시 암호화되지요. 

암/복호화를 설명할 때 스테가노그래피 등 암호의 역사부터 얘기하는데요, 오늘은 다 생략하고 알고리즘의 상세내용도 덮고, 대칭키 기반 알고리즘과 비대칭키 기반 알고리즘... 두 가지의 개념이해, 장단점 이해(암기필요없음...이해하면됨)를 해보시죠. 그러면 어떻게 활용되는지도 함께 이해할 수 있습니다.

그리고, 비대칭키기반 암호 알고리즘을 잘 이해하면 가상화폐에서 사용되는 블록체인의 원리를 이해하는데 많은 도움이 됩니다.

암복호화 개념

암호화는 평문을 타인이 못알아보도록 만드는 과정입니다. 

복호화는 암호문을 다시 평문으로 만드는 과정이겠죠.

암복호알고리즘은 보통 공개되어 있으니 어떤 알고리즘을 쓰느냐를 비밀로 할 필요는 없습니다.

중요한 것은 사용자가 암복호화할 때 정한 암호화키, 복호화키가 중요합니다.

대칭키, 비대칭키 암복호화 개념

대칭키 암호화구조라고하면, 암호화할 때의 키와 복호화 때의 키가 동일한 암호화 방식을 말합니다.

비댕키 암호화구조라고하면, 반대곘죠... 암호화키와 복호화키가 서로 다른 암호화 방식입니다.

대칭키 암호화

암호화키와 복호화키가 같다는 것은 키가 하나라는 뜻이지요. 그리고 이것은 절대 알려지면 안되기 때문에 비밀키라고 합니다.

암호화할 때와 복호화할 때 같은 키를 요구하는 알고리즘을 대칭키기반 암호 알고리즘이라고 하고 DES, 3DES, SEED, AES  등 다양한 알고리즘이 있습니다. 이들 알고리즘들은 각각 암호화하는 방식이 다르고 반복 단계(라운드)가 달라 암호강도가 다를 뿐, 키의 관점에서보면 암호화할 때와 복호화 할 때 같은 키를 요구하는 것은 동일합니다.

대칭키는 비대칭키구조보다 빠른 속도록 암복호화 하는 장점이 있지만, 상대방한테 내가 정한 비밀키가 무엇인지 알려줘야 합니다. 알려주다 보면 해커에게 노출되기 때문에 암호화 해봤자 키가 노출되어 기밀성이 확보되지 않는 것이죠. 키를 전달해주는 것이 중요해져서 키교환을 안전하게 할 수있는 키교환알고리즘이 함께 사용되기도 합니다.

비대칭키 암호화

비대칭키는 암호화키와 복호화키가 서로 다르기 때문에 대칭키하고 사용방법이 조금 다릅니다.

암호를 하는 사람은 먼저 키 생성을 합니다. 이 때  키1쌍(개인키/공개키)이 생성되고 이 둘의 키만이 서로 암호화와 복호화를 가능하게 해줍니다.그리고 개인키는 자신만이 소유하고 절대 외부에 노출하지 않습니다. 공개키는 나와 암호통신을 하고자 하는 사람에게 얼마든지 제공할 수 있습니다. RSA, ECC 등의 알고리즘이 있죠.

영수가 철수에게 비대칭키를 이용하여 안전하게 데이터를 전송하는 과정을 살펴보자.

철수는 개인키와 공개키를 가지고 있는 상태에서, 철수의 공개키는 아무나 제공받을 수 있죠. 영수는 철수의 공개키를 이용해서 원문을 암호화하여 전송하면, 해당 공개키의 쌍이 되는 개인키는 오직 철수만이 가지고 있어서 철수만이 복호화 가능합니다.

반대로, 철수도 영수에게 암호문을 보내고 싶으면 영수(수신자)의 공개키를 이용해서 암호화 후 전송하면 해당 공개키의  쌍인 개인키는 영수만이 가지고 있어 영수만 복호화 가능합니다.

이렇게 하면, 대칭키방식처럼 비밀키를 공유하다가 키가 노출되는 문제를 방지할 수 있습니다.

그렇다면, 대칭키를 쓸 이유가 없지 않나요?

대칭키방식은 비대칭키방식에 비해서 속도가 빠릅니다. 간단한 데이터는 모르겠지만 대용량 파일을 암호화 전송할 때 비대칭키방식은 비효율적이겠죠.

대칭키와 비대칭키 방식의 혼합 활용

각각의 장단점이이 있으니 이 둘을 합하여 장점들을 활용해서 많이 사용합니다.

대표적인 것이 SSL 프로토콜입니다. 네트워크 상에서 암호화 통신을 하기 위한 프로토콜이지요.

HTTPS에 적용되어 있구요.

<출처 : https://www.ibm.com 그림 편집>

속도가 빠른 대칭키 암호화에 사용할 비밀키를 생성하고 이 비밀키를 비대칭키를 사용하여 안전하게 교환하는 것이 핵심입니다. 비밀키 교환이 되면 그 다음부터는 빠른 속도를 위해 대칭키알고리즘을 사용하여 통신을 하게 됩니다.

세션을 새로 생성할 때마다 새로운 비밀키를 생성하여 교화하기 때문에 비밀키도 세션마다 변경됩니다. 이렇게 세션에만 유효하게 사용하는 경우를 세션키라고 하기도 하죠.

대칭키 vs 비대칭키 방식 비교

위에서 언급한 것을 표로 비교하면 아래와 같습니다.

그리고, 비대칭키 암호화 개념을 이해하면 이어서 이해할 수 있는 것이 많습니다.

비대칭키방식의 암호화를 반대로 사용하면 전자서명이 되고, 공인인증서, 블록체인 등 많은 부분에 응용됩니다.

리눅스나 유닉스계열 서버의 접근통제 정책을 얘기할 때 iptables와 tcp wrapper를 많이 언급하고 그 둘의 장단점을 비교하지요. 보안기사에서도 시험에 종종 나오구요.

tcp wrapper는 inetd 데몬에서 처리하는 접근제어이고, 여기서는 iptables로 많이 알려진 기능을 지원해주는 netfilter의 개념을 설명하고자 합니다.

netfilter 개요

리눅스 커널소스를 보면, 네트워크관련 소스가 전체의 1/3 정도를 차지합니다. 그만큼 네트워크의 비중이 높다는 뜻인데요, 그 중에서도 netfilter는 리눅스 커널모듈로서 네트워크 패킷을 처리하기 위한 프레임워크입니다.

주요 제공 기능

• NAT(Network Address Translation) : 사설IP와 공인IP를 변환해주거나 포트변환 등
• Packet filtering : 특정 패킷을 차단 또는 허용하는 기능. 서버의 접근제어 또는 방화벽기능 구현 가능
• packet mangling : 필요시 패킷 헤더의 값을 변경

netfilter 구조

• PREROUTING : 인터페이스를 통해 들어온 패킷을 가장 먼저 처리. 목적지 주소의 변경(DNAT)
• INPUT : 인터페이스를 통해 로컬 프로세스로 들어오는 패킷의 처리(즉, 패킷을 받아 처리할 프로세스가 내 시스템에서 동작하는 경우). INPUT에서 패킷 처리(차단/허용) 후 user space의 프로세스로 전달
• OUTPUT : 해당 프로세스에서 처리한 패킷을 밖으로 내보내는 패킷에 대한 처리(차단/허용)
• FORWARD : 다른 호스트로 통과시켜 보낼 패킷에 대한 처리(차단/허용). 방화벽이나 IPS 등과 같이 내가 수신하는 패킷이 아니고 지나가는 패킷을 처리
• POSTROUTING : 인터페이스를 통해 나갈 패킷에 대한 처리. 출발지 주소의 변경(SNAT)

iptables을 이용하여 netfilter에 룰을 넣자

• -A : add rule to chain
• -D : delete rule from chain
• -I : insert rule
• -R : replace rule
• -F : flush all rules
• -L : list all rules
• -N : create a new chain
• -X : delete user defined chain
• -P : set default target

netfilter 활용 예시

• 커널모듈로 네트워크 패킷을 처리할 수 있는 프레임웍이 있는데 그걸 netfilter라고 하는구나.
• netfilter는 INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING이라는 5개의 hook(후킹)지점을 제공하는구나.
• INPUT, OUTPUT은 내 서버의 로컬 프로세스로 전달하거나 로컬 프로세스에서 나가는 패킷들에 대한 처리를 할 수 있어서 내 서버를 보호하기 위한 접근통제에 사용할 수 있구나.
• FORWARD는 방화벽이나 IPS 등과같이 나의 시스템과는 관련은 없지만 지나가는 패킷을 처리할 때 네트워크 접근통제 정책을 설정할 수 있구나. 그리고 PREROUTING와 POSTROUTING은 NAT할 때 사용할 수 있구나.
• netfilter에 내가 원하는 정책을 넣어야 하는데 그럴 때 사용하는 프로그램이 iptables라는 것이구나. iptables은 그냥 룰을 넣고 조회하는 단순한 프로그램이구나.
• netfilter는 커널에서 통제를 하기 때문에 tcp wrapper처럼 어플리케이션 레벨에서 접근통제하는 것보다 우선순위가 높고 보안성이 우수하겠구나. 

보통 기업 내부망 접근제어를 위해 VLAN(Virtual Local Area Network)을 많이 사용합니다. 망과 노드에 대해서 네트워크 트래픽을 분리하고 접근통제하기 위해 모든 것을 물리적으로 적용하면 훨씬 좋겠지만, 비용과 시간이 많이 들겠죠. 가상으로, 즉 논리적으로 망을 재구성할 수 있게 하는 것이 VLAN입니다.

VLAN 개념

VLAN은 물리적으로 혼재된 네트워크 노드들을 논리적으로 구성하여 워크그룹단위로 묶는 네트워크 표준입니다.

예를 들어, 기업내에서 부서별로 네트워크를 묶거나, 특정 업무에 관련된 PC들만 별도로 네트워크를 구성하는 등 필요에 따라 네트워크를 구성하거나 접근통제를 해야하는데 이럴 때 사용할 수 있는 것이 가상랜입니다.

<출처 : http://www.learncisco.net>

위 그림에서 VLAN2, VLAN3... 과 같이 VLAN옆에 붙은 숫자가 VLAN ID입니다. 같은 ID로 묶인 PC들이 같은 네트워크상에 있는 것입니다. VLAN이 없다면 그냥 다들 2개의 스위치에 연결된 상태이겠죠. 스위치에서 VLAN을 지원한다면 논리적으로 다시 구성할 수 있는 것입니다.

그러면 조금 더 자세히 들어가보겠습니다.

 IEEE 802.1Q

VLAN을 위한 표준입니다. Inter-Switch Link(ISL)은 시스코 스위치에서 지원하는 방식이고, IEEE 802.1Q가 표준입니다. 아래 그림은 802.1Q 태그에 대한 그림입니다.

<출처 : https://ciscohite.wordpress.com>

이 그림은 L2의 프레임입니다. DA, SA는 L2의 MAC주소인 일반적인 이더넷프레임에 파란색의 802.1Q VLAN TAG(4bytes)가 추가된 것입니다. OSI 7계층으로 보면 L2와 L3사이에 VLAN 계층이 하나 추가된거죠.

VLAN태그는 4바이트 이고, 그 4바이트는 두번째 라인처럼 구성되어 있습니다. 그중에 마지막 12bits에 해당하는 부분이 VLAN ID이고 12bits가 할당되어 0~4095까지 설정할 수 있죠.

VLAN TAG

• TPID(16bits) : VLAN 프로토콜임을 나타내는 0x8100 값을 가집니다.
• UP(3bits) : 우선순위로서 QoS에 활용합니다.0~7(3bits)까지 표현가능합니다.
• CFI(1bit) : MAC주소가 Canonical Format인지 여부를 나타내는 플래그입니다. Non-Canonical format을 가지는 토큰링을 구분할 수 있습니다.
• VLAN ID(12bits) : 가장 중요한 VLAN ID입니다. ID가 같은 PC들만 통신할 수 있습니다. 0~4095(12bits)까지 표현할 수 있습니다.

VLAN Trunk

스위치와 스위치 사이에 VLAN 프레임을 주고 받기 위한 통로를 트렁크(Trunk)라고 합니다.

서로 다른 스위치에 연결된 PC들을 같은 VLAN으로 묶을수도 있지요. 스위치간에 VLAN 구성에 대한 정보를 주고받기 위한 프로토콜을 VTP(VLAN Trunking Protocol)라고 합니다.

VLAN 구성방식

VLAN을 구성하는 대표적인 방법 3가지를 비교해보겠습니다.

마무리

VLAN을 사용하면 논리적으로 네트워크를 재구성할 수 있기 때문에 비용이 절감되겠죠. 그리고 스위치 레벨에서 접근통제를 할 수 있어 보안성이 강화됩니다.

보안담당자로서는 보안성에 집중하면 될테구요. 시스템간에 접근제어를 해야할 때 VLAN 활용을 고려해보시고, 포트/MAC/IP 등 구성방식에 따라 보안성을 참고하여 선택하면 되겠습니다.

스위치가 뭔지는 알아도 조금 더 구체적으로 들어가면 L2스위치, L3스위치, L4스위치, L7스위치 등... 숫자가 들어가지요. 스위치라고 다 똑같은 스위치가 아닙니다. L2와 같이 기능이 단순한 것도 있지만, L7과 같이 기능이 무지 많고 엄청 비싼 스위치도 있습니다.

스위치 계층

L2스위치, L3스위치, L4스위치 등 스위치를 보통 얘기할 때 스위치가 처리할 수 있는 계층(Layer)을 의미하는 숫자가 함께 붙습니다. 계층을 잘 모른다면 아래 글을 한 번 보시길 바랍니다.

"OSI 7 계층 vs TCP/IP 계층"

예를 들어, 보통 우리가 많이 쓰는 L2스위치는 MAC주소를 기반으로 패킷을 처리해주는 스위치입니다. L3스위치는 L2에 해당하는 MAC주소 뿐만 아니라, L3에 해당하는 IP주소를 기반으로 패킷처리가 가능합니다. 이런식으로 보면 L4스위치는 MAC, IP주소 뿐만 아니라 Port번호를 기반으로도 패킷을 처리해줄 수 있겠죠. 

계층별 스위치

계층별로 스위치가 패킷을 처리하는 개념을 보겠습니다.

L2스위치

Layer 2 기반의 스위치입니다. L2스위치는 PC들이 연결되면 NIC(Netwrok Interface Card)에 할당되어 있는 MAC주소들을 수집하여 각 포트별로 연결된 PC들을 구분합니다. 즉, MAC 주소 테이블을 관리한다는 뜻이구요. 이를 이용하여 L2스위치에 연결된 서로 다른 PC들이 통신을 한다면 L2스위치는 두 PC가 연결되어 있는 인터페이스로만 패킷을 전달합니다.

<출처: 구글검색>

예를 들어, 위와 같은 L2 스위치의 각 포트에 A, B, C, D의 시스템이 연결되어 있다면 L2스위치는 위와 그림에서처럼 MAC주소와 포트정보로 구성된 MAC테이블을 관리합니다. 그리고 A가 C에게 패킷을 보내기 위해서 C의 MAC주소를 목적지로 하는 패킷을 보내면 L2스위치는 C가 연결된 E2 인터페이스로만 패킷을 보냄으로써 C가 패킷을 수신하게 됩니다.

몇 가지 부연설명을 하자면,

- E1, E3에 연결된 B, D 시스템은 A가 C에게 보낸 패킷을 구경도 할 수 없습니다. 이유는 스위치가 그쪽으로 패킷을 아예 보내지도 않기 때문입니다. 참고로, 더미허브였다면 모든 패킷을 복사하여 모든 포트로 보내주기 때문에 B와 D도 C로 가는 패킷을 구경할 수 있습니다. 스니핑(snifing)이라고 하지요.

- 또하나, A가 C에게 보낸 패킷에는 L2에 해당하는 MAC주소 말고도 L3에 해당하는 IP주소도 있습니다. 하지만 L2는 L2의 헤더에 해당하는 MAC주소정보만 참고하고 나머지는 모두 관심없는 L3이상의 데이터이기 때문에 IP주소조차 확인하지 않습니다. L3스위치라면 IP까지도 볼 수 있겠지만요. 그래서 L2스위치는 IP정보를 이용하여 접근제어는 못하지만 MAC주소로 접근제어는 가능하겠죠. 

L3스위치

L3스위치는 L2와 L3의 정보를 모두 확인하기 때문에, L2보다 스마트하다고 할 수 있죠. L2가 할 수 있는 기능은 당연하고, L3에 해당하는 IP정보를 확인하여 패킷처리가 가능합니다. IP정보를 기반으로 패킷 필터링도 가능하겠죠. L3는 보통 네트워크와 네트워크간에 패킷을 전송하는 라우터에 해당됩니다.

<출처: 구글검색>

같은 네트워크가 아니라면 라우터를 통해 패킷이 목적지까지 라우팅되어야 원하는 목적지까지 패킷이 전달됩니다. 위 그림과 같이 라우터는 L3에 해당하는 IP정보를 처리하여 라우팅을 합니다.

L4스위치

그런식으로 L4스위치는 L2, L3는 물론 L4에 해당하는 Port정보를 확인하여 패킷처리가 가능합니다. 보통 Port정보를 이용해서 처리하는 것은 로드밸런싱이나 포트포워딩, QoS 등의 기능이 있죠. 보안기능으로 보면 소스IP/소스Port/목적지IP/목적지Port를 기반으로 패킷을 허용 또는 차단하는 기본적인 방화벽기능도 가능합니다. 점점 스마트해지고 점점 비싸지는 거죠...

아래 그림은, L4 스위치에 가상IP(Virtual IP)를 할당하고 포트에 따라 L4스위치 뒤에 실제로 배치된 웹 또는 메일서버(SMTP)로 연결하기도 하고 부하를 고려하여 로드밸런싱도 하는 예를 설명하고 있습니다.

<출처 : 구글검색>

L7스위치

L7 스위치는 예상하시는 것과 같이 패킷의 모든 계층의 정보를 커버할 수 있으니 하고 싶은 것은 다 할수 있겠죠. L4스위치가 하는 것은 물론이고, 웹프록시 같은 L7프로토콜을 처리하는 것도 가능하고, 캐싱도 가능합니다. 패킷을 검사하여 침입탐지도 가능합니다. 물론 기본적으로 스위치의 역할에 충실해야하니 너무 많은 기능을 넣으면 스위치 성능이 떨어질테죠.

L4와 L7 스위치를 비교하면 아래와 같습니다.

<출처 : 정보보안기사, 예문사>

결론

계층이 높을 수록 스마트하지만 비싼 스위치가 됩니다. 용도에 맞게 적절한 스위치를 사용하여 네트워크 인프라를 설계해야 합니다.

그리고 보안 담당자는 각 스위치의 동작원리를 어느정도 이해해야 합니다. 다른 시스템간의 통신을 훔쳐보는 것을 스니핑(sniffing)이라고 하는데, 이것을 막기위해 기본적으로 허브를 사용하지 않고 스위치를 사용합니다. 스위치를 사용하더라도 패킷을 내가 훔쳐볼 수 있도록 스위치 재밍(switch jamming)을 할수도 있으며, ARP spoofing을 이용하여 패킷을 훔쳐보고 변조할 수도 있습니다. 오늘은 이러한 공격기법을 설명한 것은 아니지만 이런 것들을 이해하려면 기본동작원리는 어느정도 이해해야 합니다.

L3 스위치...L4스위치...L7 프로토콜... L4에서 동작해? L2야? 등 등...

네트워크 관련된 얘기를 하다보면 1~7 사이의 숫자가 많이 등장하죠. 바로 OSI 7 계층(Layer)에서 정의한 계층을 의미합니다.

이번에는 네트워크 관련된 어떠한 내용이던, 이해를 하거나 의사소통하는데 반드시 알아야 할 필수 아이템인 OSI 7계층에 대해서 (역시나) 개념만 간단히 설명하겠습니다. OSI 7계층이 이론상 표준이라고 한다면, 사실상 표준에 해당하는 TCP/IP 계층과 살짝 비교하면서 마칠께요.

개요

네트워크 통신에는 통신 끝단의 클라이언트와 서버, 중간에서 패킷들을 처리해서 전달해 주는 스위치, 브릿지, 라우터 등 많은 요소들이 있습니다. 보이지 않는 것들까지 자세히 보자면 더 많죠. 이렇게 요소들도 많지만, 하드웨어든 소프트웨어든 이를 만들어 제공하는 벤더들도 참 많죠. 그래서 의사소통이나 각 요소들간의 호환성을 목적으로 네트워크 통신에 필요한 기능들을 쪼개고 쪼개서 각 계층을 7가지로 정의하고 표준화한 것이 OSI 7계층입니다. 각 계층별 정의부터 보죠.

<출처 : 정보보안기사, 예문사>

네트워크 통신에 필요한 기능을 쪼개어 위와 같이 계층을 나누었습니다. 그 역할은 위 표를 보면되구요. 꼭 알아야 할 계층만 설명해보면,

• 1계층 - 전기적인 신호입니다. 예를들어 유선랜 통신은 랜케이블의 전기적 신호이고, 무선랜인 경우 무선AP와 통신하는 무선주파수가 해당됩니다.

• 2계층 : NIC(네트워크 인터페이스 카드)(유/무선)에서 1계층에 해당하는 전기신호를 bit 신호로 바꾸겠죠. 그리고 통신을 하기 위해 주변의 NIC와 통신해야하는데 이때 MAC주소라는 것이 사용됩니다. NIC의 주소이죠. 이더넷의 경우 6바이트이구요. MAC주소는 Broadcast Domain내에서만 사용됩니다. 즉 내 PC가 연결되어 있는 작은 네트워크 내에서만 사용되고 다른 네트워크에 전달되기 위해서는 상위계층인 IP주소를 이용해야합니다.

• 3계층 : IP주소를 사용하는 계층입니다. IP주소는 네트워크 내에 PC나 서버까지 데이터를 도달할 수 있는 주소입니다. 

• 4계층 : 포트를 사용하는 계층입니다. 3계층인 IP주소를 이용해서 해당 시스템까지 데이터가 전달되었다고 해봅시다. 그 시스템에는 데이터를 기다리는 여러 서비스가 실행되고 있을텐데, 그 시스템으로 데이터가 도달하더라도 어떤 통신프로그램에게 데이터를 전달해야할지 정해야합니다. 이 역할을 하는 것이 포트번호입니다. 즉, 내 PC로 구글검색도하고, 메신저도 써야하기 때문에 내 PC의 IP로 전달된 데이터들도 포트번호를 보고 구글검색을 하는 웹브라우저로 전달할지 메신저에게 전달할지 결정합니다.

• 7계층 : 5~6계층은 그냥 읽어보시면 되고, 7계층은 우리가 보통 웹프로토콜(http), 메일프로토콜(smtp, pop3 등) 등 최종적으로 어플리케이션이 사용하는 데이터들을 처리한다고 보면 됩니다.

캡슐화

OSI 7계층 vs TCP/IP 계층

• 어플리케이션(Application) 계층 : 네트워크를 사용하는 응용프로그램. FTP, TELNET, HTTP 등
• 전송(Transport) 계층 :  애플리케이션 계층에 세션과 데이터그램(Datagram) 통신 서비스 제공. TCP, UDP 등
• 인터넷(Internet) 계층 : 어드레싱(addressing), 패키징(packaging), 라우팅(routing) 기능 제공. IP, ARP, ICMP, IGMP 등
• 네트워크 연결(Network Access) 계층 :  TCP/IP 패킷(packet)을 네트워크 매체로 전달하는 것과 네트워크 매체에서 TCP/IP 패킷을 받아들이는 과정을 담당

대표적 네트워크 보안장비 중에 IDS와 IPS를 빼놓을 수 없죠. 이 둘은 거의 동일한 탐지엔진을 가지고 있지만 용도에 따라 활용이 조금 다르고, 용도가 다르기 때문에 주의할 점도 조금 다릅니다. 오늘은 IDS와 IPS의 주요기능을 살펴보고 어떻게 다른지 알아보겠습니다.

시기적으로 보면 침입탐지시스템이라고 하는 IDS(Instrusion Detction System)가 먼저 나왔다가 엔진이 안정화되고 장비성능이 안정화되면서, 탐지가 아니라 아예 사전에 방지하자는 침입방지시스템인 IPS(Intrusion Protection System)로 진화했다고 할 수 있습니다. 하지만 장단점이 있어서 둘 다 현재 많이 사용되고 있지요.

IDS나 IPS는 호스트기반 IDS/IPS, 네트워크 기반 IDS/IPS가 있지만 자주사용하는 네트워크 기반 유형만 설명하겠습니다.

설치 위치

<출처: www.kumkang21.co.kr>

보통 방화벽 뒤에 내부망(또는 DMZ)에 설치합니다. 그 이유를 간단히 설명하겠습니다.

• 거의 최전방에 위치하는 이유 : 내부망으로 들어오는 모든 패킷을 검사하기 위해서입니다. IDS/IPS는 모니터링하고 있는 네트워크를 지나가는 모든 패킷을 검사할 수 있습니다. 

• 하지만 방화벽 뒤에 주로 위치하는 이유 : 성능입니다. IDS/IPS는 패킷의 헤더부터 페이로드 내 데이터까지 모두 Deep Inspection을 하기 때문에 주로 패킷의 헤더정보만 검사하는 방화벽보다 많은 성능을 필요로 하기 때문입니다. 즉, 방화벽에서 쓸데없는 패킷들을 우선 필터링 해주고 방화벽에서 허용해준 트래픽에 대해서만 IDS/IPS가 고급정보까지 심도있게 분석하여 공격을 탐지 및 차단하겠다는 것입니다. 경우에 따라서는 방화벽 앞에 가기도 합니다. 방화벽에서 차단할 것이지만, 어떤 공격들이 우리 네트워크에 인입되려는 시도가 있었는지도 궁금하다면 그럴 수 있겠죠. 예를 들면, 관제목적으로 사용되는 경우 그럴 수 있습니다. 하지만, 성능이 충분히 보장되어야 합니다.

진단 룰

IDS/IPS를 만드는 벤더들은 대부분 리눅스 기반에 snort엔진을 많이 수정하여 사용합니다. 최근에는 성능을 고도로 높이기 위해 전용하드웨어를 도입하여 하기도 하지만 원리는 크게 변하지 않을 것입니다.

snort(https://snort.org)는 오픈소스의 네트워크 보안 소프트웨어 입니다. 사이트를 한 번 들어가보는 것도 추천합니다. snort룰은 거의 사실상 표준(defacto)이라고 보면 됩니다. 웬만한 네트워크 보안 장비들은 snort룰 형식을 사용합니다. 보안기사 시험에도 종종 나오죠. 룰의 세세한 옵션까지 자세히 이해하려면 많은 시간과 지식이 필요하구요, 개념만 살펴보겠습니다.

         [snort 룰 예]

<출처 : 정보보안기사 예문사>

위의 내용과 같이, 패킷의 내용을 분석하여 특정 조건에 해당될 경우 drop하라는 등 탐지조건과 처리방법을 정의할 수 있습니다. 보통 IPS/IDS에는 이러한 룰들이 몇 천 개 이상 들어가고, 패킷을 하나 하나 검사할 때마다 들고 있는 모든 룰들에 해당하는지를 검사해야 합니다. 이것을 패턴매칭이라고 하고 이 패턴매칭 알고리즘이 장비의 성능을 좌우한다고 할 수 있습니다. 

또한 룰을 얼마나 잘 정의하느냐에 따라 외부 공격을 잘 탐지 및 차단하느냐를 결정합니다. 룰을 잘 못 정의하면 오탐 또는 미탐이 발생할 수 있습니다.

• 오탐(False Positive) : 정상패킷을 공격으로 잘 못 탐지를 한 것입니다. 정상적인 서비스가 안될 수 있겠죠.
• 미탐(False Negative) : 공격패킷을 정상으로 인지하여 탐지하지 못한 것입니다. 외부로부터 공격패킷을 내부로 그냥 보내게 되겠지요.

IPS와 IDS의 비교

IPS는 보통 인라인(inline)장비라고 합니다. 네트워크 라인 내 중간에 삽입된 개념으로 IPS로 인입되는 패킷을 신속하게 처리하여 내보내줘야 서비스가 느려지지 않습니다. 인입된 패킷을 검사한 결과 공격이라고 탐지한 경우, 그 패킷을 내보지 않고 차단(drop)시킨다면 공격패킷을 내부로 들어가지 못하게 되는 것입니다. 이렇기 때문에 공격을 실시간으로 차단할 수 있습니다.

반면, IDS는 패킷을 미러링(Mirroring)합니다. 즉, 지나가는 패킷을 복사하여 검사를 합니다. 복사하여 검사는 하지만, 이미 그 패킷을 지나가버린 상태이죠. 그래서 내부로 공격패킷을 인입되는 것을 실시간으로 막을 수는 없고 사후에 탐지하는 개념으로 보면 됩니다.

그렇다면, IPS가 무조건 IDS보다 좋은걸까요? 장단점이 있습니다.

• IPS : 실시간 공격차단 가능하지만, 처리할 트래픽이 많을 경우 네트워크 부하가 발생하여 서비스가 지연될 수 있고, 장비가 다운될 경우 네트워크에 장애가 발생합니다. 이래서 이중화가 중요하지요. 부하를 줄이기 위해서는 룰 최적화가 중요하고 그래도 부하가 있으면 룰을 줄여서 탐지를 다 못하더라도(Hit가 적은 룰부터 삭제 등) 네트워크 가용성을 확보해야 겠지요. 또한 오탐발생 시 아주 심각합니다. 예를 들어, 정상적인 인터넷뱅킹을 이용하는데도 공격으로 오인하여 서비스장애가 발생할 수 있기 때문입니다.

• IDS : 네트워크 부하를 유발하지 않습니다. IDS장비가 소위 버벅거린다해서 실제 네트워크에는 영향을 주지 않아 부담이 적습니다. 하지만, 공격패킷을 실시간 차단할 수 없는 단점이 있습니다. 공격 탐지 시 방화벽과 연계하는 등의 조치가 필요합니다. 부담이 적다보니 오탐이 발생해도 둔감할 수 있어 룰최적화가 실질적으로 잘 안이루어질 수 있고 오탐에 의한 이벤트로그들이 다량으로 발생할 경우, 보안 담당자는 IDS의 로그를 신뢰하지 않고 귀찮게 여기는 경우도 비일비재합니다. 관리를 잘 해야겠지요.

보안 담당자 체크 포인트

설치 위치 및 성능

보호하고자 하는 네트워크 지점이 어디인지를 고려하여 적절하게 위치해야 합니다. 또한 장비의 성능을 고려하여 네트워크 트래픽이 과도하게 몰려 성능부하가 초래되지 않도록 설치 위치를 결정합니다. 예를 들어, 방화벽 앞에 있는 것과 뒤에 있는 것은 장비로 인입되는 트래픽이 많이 차이날 것입니다. 장비의 성능만 확실하다면 가장 최전방에 설치하는 것이 모든 트래픽을 검사할 수 있겠죠. 하지만 트래픽이 너무 많은 경우 장비의 가용성을 고려하여 분산시켜 위치할 수도 있습니다.

또한, VPN과 같이 암호화된 패킷이 존재하는 경우 복호화되는 시점 이후에 검사를 하느냐에 따라 암호화 패킷도 제대로 검사할 수 있는지도 결정됩니다.

룰 최적화 및 최신 업데이트

룰을 최적화하는 것이 오탐 및 미탐을 줄일 수 있으며 장비의 성능에도 영향을 줄 수 있습니다. 또한, 최신 공격에 얼마나 신속하게 대응하느냐도 중요한 요소입니다.

네트워크 이중화

특히 IPS의 경우 인라인장비로서 가용성이 매우 중요합니다. 반드시 이중화하여 장비가 다양한 이유로 다운 될 경우에도 네트워크 가용성이 확보될 수 있어야 합니다.

참고로, 장비가 다운될 경우 네트워크가 끊어진 것처럼(Fail close) 할 것인지 장비가 없는 것처럼 동작(Fail open)할 것인지를 보통 장비에서 선택가능합니다. Fail close는 장비 다운 시 네트워크가 단절이 되기 때문에 정상패킷과 공격패킷 모두 차단되겠죠. 반면, Fail open은 장비가 다운 시 네트워크 라인을 물리적으로 연결시켜주기 때문에 장비가 없는 것과 같이 정상 패킷, 공격 패킷 모두 허용됩니다. 공격패킷을 일부 허용하더라도 정상서비스 유지가 중요한지, 정상서비스를 못하더라도 혹시 모를 공격패킷은 절대 허용할 수 없는 상황인지에 따라 선택하겠죠.

리패키징이 얼마나 쉬운지 10분만에 안드로이드 리패키징을 직접 해보겠습니다.

앵그리버드 앱에 SMS를 탈취하는 코드를 삽입 후 리패키징하는 작업을 할 건데요,

프로그래밍적인 지식은 딱하나만 들어갑니다. SMS를 후킹하여 탈취하는 코드 하나 짜야합니다. 이건 미리 짜놓은 것으로 사용하여 10분안에 마칠 겁니다. 관련 코드는 인터넷만 검색해도 아주 쉽게 만들 수 있거든요.

앵그리버드앱 설치부터 리패키징까지의 전 과정인 10분짜리 동영상을 참고해주시고 아래 내용은 요약입니다.

리패키징 시나리오

- 앵그리버드 앱에 SMS를 탈취하는 코드 삽입하는 리패키징

1. 구글플레이에서 앵그리버드 설치

2. 앵그리버드 설치파일 추출

3. APKTOOL을 사용하여 리버싱(smali 코드추출)

4. 삽입할 코드(SMS탈취목적)를 작성 후 빌드(SMS Hooker)

5. SMS Hooker 설치파일을 APKTOOL로 리버싱하여 SMS를

    탈취하는 smali코드 준비

6. 앵그리버드 코드에 준비한 SMS 후킹 코드 추가

7. 앵그리버드 리패키징(재빌드)하여 설치

8. SMS 탈취 기능 테스트

환경구축

• 테스트 폰 2대 : 한 대는 리패키징 앱을 설치, 한 대는 SMS를 탈취하여 수신할 테스트 폰(해커입장의 폰)
• 안드로드 개발환경(스튜디오) : SMS 리시버에 SMS 수신시 테스트폰으로 수신SMS를 전송하는 앱 빌드
• APKTOOL : 공개용 안드로이드 리버싱 툴

리패키징 따라하기

제가 직접 만들어 본 동영상입니다. 글로도 설명을 자세히 하고 싶지만, 다음 기회에...^^;

결론

동영상과 같이 특별히 전문적인 기술이 없더라도 안드로이드 리패키징은 매우 간단합니다. 물론 목적에 따라 복잡해질 수도 있지만요. 

안드로이드 악성코드의 대부분이 이 리패키징을 전제로 하는 경우가 많습니다. 리패키징은 남이 만든 앱을 자신이 만든것처럼 하여 저작권을 침해하기도하고, 악성코드 삽입을 목적으로 하기도 합니다.

이러한 리패키징앱이 많이 유통되는 원인 중 하나는 구글의 앱스토어 개방 정책입니다. 애플과 달리 안드로이드의 앱스토어는 전세계에 엄청나게 많습니다. 우리나라만 해도 통신사별로, 포탈별로, 폰 제조사별로 앱스토어가 존재하기 때문에 리패키징 앱을 다른 스토어에 올려 마치 원래 앱인 것처럼 위장하기 참 좋은 환경이죠.

오늘은 안드로이드를 중심으로, 모바일 보안 취약점 점검 기준에 대한 이야기를 하고자 합니다. 예를 들어, 신규 서비스를 위해 모바일 앱을 배포할 경우 보안담당자라면 취약점 분석평가를 기업 자체적으로 하거나 보안컨설팅 전문업체에 의뢰해서 모바일 보안 취약점을 평가하겠죠. 이 때 점검기준에 의해 결과보고서가 나올 텐데, 보안 담당자는 각 점검기준에 대한 최소한의 이해가 필요합니다. 그래야 취약점분석 결과보고서에 있는 각 이슈에 대해 정확한 이해를 바탕으로 그에 적절한 수준의 대응책을 마련할 수 있을 것입니다. 

모바일 보안의 중요성

스마트폰을 이용해서 인터넷뱅킹, 주식투자, 게임 등 못하는 것이 없죠. 어느새 PC보다도 더 많이 사용하는 것 같습니다. 게다가 핀테크 활성화가 시작되면서 간편결제 등 PC로 못하는 것까지 스마트폰으로 하고 있죠. 이렇듯 스마트폰에서 금융거래와 같은 중요정보를 처리하려다보니 NFC기반의 IC태깅기술, FIDO기반의 생체인증, 하드웨어기반의 TEE 등 다양한 보안기술을 도입하여 편의성을 증대하면서도 보안성을 확보하려고 노력하고 있죠. 꼭 이처럼 별도의 하드웨어까지 활용하지 않고 순수 소프트웨어만으로 구현한 간편송금앱 TOSS나 뱅크월렛카카오와 같은 서비스도 점점 많아지고 있습니다. 이렇게 스마트폰의 역할이 중요해질수록 공격대상으로서의 가치는 올라가고, 실제 모바일 악성코드 및 해킹사례들이 늘고 있는 추세입니다. 최근에는 이상거래탐지시스템(FDS)과 같이 백엔드에서도 열심히 보안을 강화하고 있지만 그래도 클라이언트(스마트폰)에서의 보안이 여전히 중요한 건 변함없을 것입니다.

모바일 보안 취약점 점검 기준 파헤치기

전자신문 기사에 의하면, 2013년 금융감독원에서 '스마트폰 금융 안전대책 이행실태 체크리스트'를 배포하면서 금융 모바일앱을 점검하도록 하였습니다.

[기사 일부 발췌]

"11일 당국과 업계에 따르면 최근 금융감독원은 시중 금융 전(全) 업권 80여곳에 `스마트폰금융 안전대책 이행 실태점검 체크리스트`를 발송하고, 점검 결과를 4월까지 반송하라고 통보했다."

물론, 이 기준이 모든 앱에 대해 보안측면의 만병통치약이라고 할 수도 없습니다. 특히 최근에는 보안이슈를 클라이언트에서만 해결하려던 과거의 분위기에서 기업 자율보안체계로 패러다임이 변화되고 있는 추세에서 이 기준을 반드시 만족시켜야 한다는 법은 없다고 생각합니다. 그렇다고 스마트폰에서 모바일앱에 대한 보안이 중요하지 않다는 뜻이 아니며 오히려 자율보안체계에서는 상황에 따라 적절히 필요한 기준을 적용해야할 것이고, 보안담당자는 이러한 기준의 의미를 정확히 알고 있어야 합니다.

점검기준 요약은 아래 표와 같습니다.

위 점검기준 외에도 앱 특성에 따라 적절한 점검기준이 적용될 수 있겠지만 오늘은 금감원에서 배포한 기준을 하나씩 살펴보겠습니다.

백신프로그램 적용

앱 실행 시 백신모듈을 탑재하거나 백신앱을 연동하는지에 대한 내용입니다. 요새는 모바일 보안 패키지에 기본적으로 포함되는 것 같더라구요. 앱 내 백신을 라이브러리 형태로 포함하기도 하고, 안랩의 V3Mobile과 같이 독자 앱을 연동하기도 합니다. 백신앱 구동여부 외에도 앱 사용 도중 백신앱을 강제종료시켰을 때 이를 인지하는지도 포함하여 점검하기도 합니다.

그렇다면, 백신앱은 어떤 의미를 가질까요? 백신앱은 PC환경에서와 마찬가지로 잘 알려진 악성코드(앱)를 탐지합니다. 여기서 '잘 알려진' 이란 누군가가 악성앱으로 인해 피해를 입었고 그것이 백신업체에 신고 및 수집되어 알려지게 되는 것입니다. 최초 알려지더라도, '수집->분석->배포' 단계에 이르기까지 시간이 소요될수밖에 없으니 최신 백신엔진이 배포되기 전까지는 백신이 해결해줄수도 없는 노릇이죠. 그나마 최신업데이트라도 열심히 한다면 배포단계 이후에 최신백신이 바로 적용되겠죠.

여기서 잠깐 안드로이드와 iOS환경에서의 백신얘기를 좀 하자면, 애플앱스토어에는 백신앱을 등록할 수 없습니다. 애플은 앱스토어에 등록대기 중인 앱에 대해 전수조사를 철저히 하기 때문에 백신앱이 필요없고 인정하지도 않습니다. 사실 애플은 앱스토어를 개방하지 않고 애플앱스토어 하나만 인정하며 블랙마켓(애플앱스토어가 아닌 앱스토어)으로부터의 앱 설치를 차단하고 있습니다. 블랙마켓앱을 설치하려면 애플의 통제에서 벗어나기위해 JailBreak를 하죠. 반면, 안드로이드는 어떨까요? 구글도 구글플레이(구글앱스토어)에 등록대기중인 앱을 당연히 검사합니다. 하지만 애플만큼 까다롭지 않고 더 중요한 것은 앱스토어를 개방한다는 것이죠. 우리나라만 해도 각 통신사별, 각 제조사별로 앱스토어가 별도로 있으며 포탈업체도 앱스토어를 운영하니 전세계적으로 Third Party 앱스토어가 엄청 많겠죠. 게다가 설정에서 '알수없는 소스' 항목만 체크하면 아무 URL을 통해서도 다운받은 앱도 설치할 수 있습니다. 이로 인해 안드로이드는 스미싱으로 인한 악성앱 설치유도도 상당히 많죠('알수없는 소스' 체크를 못하도록만 막아도 스미싱은 급격하게 줄 것입니다). 그래서 안드로이드는 백신앱이 많이 있습니다. 참고사항이지만, V3Mobile은 국제인증인 AVT에서도 좋은 결과는 내놓고 있구요.

입력정보 보호대책

비밀번호, 주민번호 등 중요정보를 사용자가 입력 시 노출되지 않도록 가상키패드 등을 적용하는 것입니다. 앱내 단순 텍스트창에서 중요정보를 입력하고 마스킹처리를 하더라도 그것은 UI상에서만 안보일 뿐 실제 실행되는 앱의 프로세스에 할당된 메모리 내에는 평문으로 들고 있을 경우 메모리 덤프 등을 통해 중요정보를 해커가 가져갈 수 있기 때문입니다. 물론 뒤에서 설명할 '루팅' 된 환경에서 입니다. 가상키패드의 역할은 사용자가 입력하는 키값을 종단간암호화(E2E)를 하는 것입니다. 키패드에서 키값 하나 하나를 입력할 때마다 그 값을 즉시 암호화하고 입력 종료 시 전송하면 서버에서 값을 복호화합니다. 당연히 가상키패드는 서버모듈이 있을 테고 둘 사이에 매번 변하는 키값을 사용해야 합니다.

가상키패드를 사용하더라도 유의할 점이 있습니다.

- 가상키패드가 실행 시 매번 자판의 배열이 랜덤하게 변하는지

- 혹시 랜덤하게 변하는 규칙에 대한 설정을 앱내 설정파일에 저장하고 있어 이를 수정할 경우 고정자판이 되는건 아닌지

- 가상키패드에서 열심히 E2E를 하지만, 적용을 제대로 못해서 평문으로도 들고 있어 메모리상에 노출되거나 디버깅로그가 남지 않는지

- 입력값 암호화 키를 고정키를 사용하고 있어 재사용공격이 가능하지 않는지 등

금융정보 종단간 암호화

앞에서도 설명한 E2E암호화에 대한 내용입니다. E2E암호화는 네트워크 암호화 전송보다 조금 더 강한 보안요구사항이지요. 네트워크암호화는 클라이언트와 서버 중간의 네트워크 영역에서 스니핑 등을 통해 중요정보가 노출되는 것을 방지하는 것이지만, E2E는 중요정보가 네트워크로 나가기 전부터 스마트폰 내(클라이언트) 다른 프로세스에 의해서도 중요정보가 노출되는 것을 방지하기 위한 것입니다. 비밀번호부터 개인정보까지 굉장히 중요한 정보를 네트워크 암호화와 별도로 E2E암호화를 요구하는 것입니다.

폰 임의개조 탐지 및 차단

안드로이드의 '루팅', iOS의 'JailBreak' 탐지에 해당합니다. 대부분의 스마트폰OS는 Sandbox개념을 도입하여 보안을 유지하는데 루팅이라는 것은 이것을 깨는 행위입니다.

루팅을 살펴보기 전에, 안드로이드의 보안 아키틱처에 해당하는 Sandbox 개념을 살펴보겠습니다.

<Sandbox 개념>

<출처: 안랩>

스마트폰에 앱을 설치하면 위 그림처럼 앱마다 UID/GID가 다릅니다. 각 앱마다 다른 ID를 부여하고 각 ID별로 서로의 자원에 접근하지 못하도록 통제하는 것이죠. 아래 그림은 서로 다은 앱에 대한 Sandbox 상세 개념도 입니다.

<출처 : IBM>

위 그림에서 서로 다른 앱의 ID는 12345, 54321 이고 각 앱별로 File, DB, SMS, Sensors 등을 OS(안드로이드 커널은 Linux커널)에서 제공합니다. 예를 들어, 왼쪽 앱(ID:12345)이 생성한 파일을 오른쪽 앱(ID:54321)이 접근할 수 없도록 안드로이드가 통제를 합니다. 쉽게 말해서 자신만 실행되고 있는 박스에서 각각 실행된다고 생각하면 됩니다. 물론, 필요하면 서로 공유하거나 연동할 수 있도록 OS는 다양한 메카니즘을 제공하지만 기본적인 구조는 박스처리해서 서로 접근이 불가하도록 만드는 것입니다.

이러한 Sandbox가 완벽하게 보장된다면, 사실 앱은 중요정보를 파일에 평문으로 저장해도 되겠죠. 아무도 보지 못하고 해당 앱만 접근이 가능하니까 기밀성은 충분히 확보되는 셈이죠. 하지만 Sandbox가 완벽하게 보장되지 않기 때문에 이러한 보안 요구사항들이 나오게 됩니다. Sandbox를 보장하지 않는 대표적인 것이 루팅입니다. 시스템에는 root라는 계정이 있습니다. 모든 권한을 가진 수퍼유저계정이죠. 루팅이라는 것은 root권한을 획득하는 것을 의미합니다. 예를 들어, 처음 스마트폰을 사면 root권한은 오픈되지 않습니다. 하지만, 스마트폰 사용자는 단말의 제약을 풀기위해(특히, iOS) 루팅도구(테그락 등)를 이용해 루팅을 직접하는 경우도 있고, 악성코드에 의해 본인도 모르게 루팅이 되는 경우도 있습니다. 

경우가 어떻든, 루팅이 되면 언제든지 Sandbox의 통제를 벗어나 스마트폰 내 모든 권한을 보유하게 되고 다른 앱들의 저장파일은 물론 디버깅, 메모리덤프 등 원하는 작업을 할 수 있게됩니다. 이처럼 보안 아키텍처가 완벽히 보장되지 않기 때문에 백신도 설치하라고 하고, 가상키패드도 쓰고, 종단간 암호화, 뒤에 나올 앱위변조 등에 대해 대응을 하라는 것이죠.

취약점 점검하는 전문기관에서 진단을 시작하려면 루팅을 가장 먼저 시도할 것입니다. 중요정보를 파일에 저장하는지 점검하려면 점검자부터 root권한이 필요하기 때문이죠. 루팅만 100% 막아도 어느정도 루팅을 전제로 이어지는 공격들을 상당부분 막을 수 있게됩니다. 하지만 루팅을 100% 탐지하는 경우는 드뭅니다. 예를 들어, 최악의 경우 루팅탐지를 아무리 잘하더라도 루팅탐지 모듈을 무력화시키도록 수정 후 동작할 수 있습니다. 이는 앱 위변조에서 막아야 하지만 이것 또한 100% 탐지는 어렵습니다. 창과 방패와 같은 이치라고 보면 됩니다. 그래서 루팅탐지는 진화하는 루팅방법들은 신속하고 지속적으로 대응할 수 있는 체계구성이 중요합니다.

루팅탐지는 다양한 요소를 확인함으로써 탐지합니다. 예를 들어, 루팅도구 앱 설치여부, 관련 프로세스 실행 여부, su파일 존재 여부, adbd의 root권한 실행여부 등으로 탐지하는데 루팅탐지를 우회하며 진화하는 루팅도구들을 효과적으로 탐지하기 위한 노력이 지속적일 수 밖에 없습니다. 몇년 전에 이런 경우도 있었습니다. 어떤 제조사의 안드로이드 단말에 출고시부터 su파일이 포함되어 있었고 su파일을 실행해보니 패스워드가 걸려있었습니다. 해당 제조사는 패스워드가 걸려 있으니 su파일이 있어도 괜찮지 않냐며 유지보수용으로 넣어둔 것이고 했습니다. 이것은 루팅을 위한 대표적 백도어라고 할 수 있죠. 제조사가 악의적 목적이 아니라고 하더라도 언제든지 악의적인 목적으로 사용될 수 있는 백도어이기 때문에 출시부터 루팅단말이라고 할 수 있죠. 제조사에서 루팅에 대한 이해가 부족해서 그러지 않았나 하는 상황이였습니다.

루팅 얘기를 너무 많이 했는데요, 루팅관련 내용은 기회되면 한 번 정리해보도록 하고 다음으로 넘어가겠습니다.

앱 무결성 검증

안드로이드의 앱 무결성에 대한 대상을 열거하면 APK파일, DEX파일, so파일, ODEX파일 등이 있습니다. 여기에 리소스파일(이미지파일 등)도 포함하긴 하지만 리소스파일보다 실행파일이 더 중요한 대상입니다. 

• APK파일

안드로이드 설치파일인 APK파일을 이용해서 앱이 설치되면 APK파일이 그대로 시스템에 저장됩니다. 이 파일에 대한 무결성을 확인해야 합니다.

• DEX(Dalvik Executable)파일 / ODEX파일

APK파일은 단순히 PKZIP 압축파일일 뿐이고, 압축해제하면 classes.dex파일이 하나 있습니다(경우에 따라 2개 이상일 수도 있습니다만). 이것이 실제 안드로이드 실행파일입니다. JAVA로 구현된 코드가 들어있죠. 앱이 설치되면 실제 단말의 시스템환경에서 빠르게 동작하기 위해 시스템 최적화된 DEX파일인 ODEX파일도 함께 생성됩니다.

• SO파일

공유라이브러리 파일입니다. DEX파일은 Dalvik이라는 가상머신에서 실행되는데 so파일은 가상머신이 아닌 Native환경에서 실행되는 코드입니다. 보통 가상머신에서 동작하는 DEX파일은 리버싱이 너무 쉽기 때문에 암호모듈이나 인증모듈 등 중요한 모듈은 상대적으로 리버싱이 어려운 SO파일로 구현하는 경우가 많습니다.

그리고 가끔 라이브러리를 제공받아 사용하는 경우 JAR파일에 대한 무결성 얘기를 하는 사람도 있는데, JAR파일은 소스레벨에서 의미가 있고 안드로이드 빌드 시 모두 DEX파일에 포함되기 때문에 앱 실행 시 JAR자체에 대한 무결성을 확인하는 것은 불가하고 무의미합니다.

무결성확인도 역시 창과 방패의 이야기입니다. 앱 스스로 자신이 무결한지 확인하는 것 자체가 무리가 있습니다. 무결한지 확인하는 코드 자체가 삭제되거나 무력화될 가능성이 높기 때문에, 앱(클라이언트)뿐만 아니라 서버까지 서로 연결되어 타이트하게 무결성을 확인하는 등 앱 무결성확인을 위해 다양한 기법이 적용되고 있습니다.

<리패키징(Repackaging)>

앱 무결성에서 리패키징 얘기가 빠질순 없죠. 리패키징은 남이 배포한 APK파일을 마치 내가 개발하여 배포하는 것처럼 다시 패키징하는 것을 의미합니다. 안드로이드환경에는 리버싱(역공학) 관련 도구가 상당히 많아(apktool, dex2jar, jd-gui 등) 너무 쉽게 APK파일을 디컴파일하고 원하는 내용 수정 후 다시 컴파일할 수 있습니다. 

<출처 : 안랩>

리패키징을 하는 목적을 크게 2가지로 분류하면, 악성코드 삽입 및 지적재산권침해(남이 만든 앱을 이용하여 광고수입 가로채기 등)입니다. 리패키징을 하려면 반드시 APK파일에 서명을 해야하는데 서명에 사용되는 개인키는 유출되지 않는다는 전제로, 리패키징하게 되면 반드시 원본앱(원작자의 서명)과 서명(리패키징한 사람의 서명)이 달라질 수 밖에 없습니다. 따라서 APK파일에 대한 무결성을 확인할 때 APK에 대한 서명부터 확인하는 것이 가장 좋겠지요. 리패키징에 대한 얘기는 너무 길어 이정도로하고 넘어가겠습니다.

코드 모듈 보호

대표적인 것이 코드난독화 및 디버깅방지(역분석방지)겠죠. 난독화는 말 그대도 코드를 읽기 어렵게 만드는 기술입니다. 개발자에게 코드의 가독성이란 엄청 중요한 요소인데 난독화는 오히려 반대개념이죠. 코드 가독성을 떨어뜨려 앱을 디컴파일해서 소스를 보더라도 로직분석이 잘 안되게 만드는 기술입니다. 안드로이드에서는 기본적으로 제공하는 proguard라는 난독화 도구가 있습니다. 다른 상용제품보다 난독화 수준은 조금 떨어지긴 합니다. 참고로, 난독화는 소스코드작성 시에 적용하는 것이 아니라 빌드 시에 적용하는 것입니다. 개발할 때는 가독성 및 모듈성을 고려하여 개발하고 빌드 시 가독성을 떨어지게 만드는 것이죠. 코드난독화는 코드암호화가 아니라 난독화이기 때문에 코드를 열심히 쫓아가면 분석이 가능하다는 한계가 있는 것을 분명히 이해해야합니다. 한 마디로 보조수단이죠.

그리고, 앱을 분석하기 위해 디버깅모드로 실행 후 디버깅을 시도할 수 있습니다. 중요트랜잭션이 발생하는 곳에서부터 디버깅을 시도하여 중요정보를 알아내거나 중요로직을 파악할 수 있죠. 디버깅방지 기능은 디거깅 행위를 방지하기 위해 디버깅이 시도되면 이를 감지하고 앱을 종료시켜 코드를 보호할 수 있습니다. 

기타

앱 취약점 점검, 앱 위변조 로그 기록은 별 내용 없네요. 멀티로그인 차단은 동시 로그인을 방지하여 사용자폰에서 알아낸 정보를 즉시 이용하여 해킹할 수 없도록 하기 위한 목적일 수 있겠네요. 스마트폰에 중요정보 저장금지는 역시 루팅 시 또는 백업 시 중요정보가 유출되지 않기 위한 것이고, 금융거리기록 정보보관은 관리적인 절차에 해당한다고 볼 수 있습니다.

결론

지금까지 금감원에서 제시한 모바일 보안 취약점 점검기준에 대해서 기술적인 개념분석을 해보았습니다. 본 기준은 스마트폰에서 실행되는 모바일앱(클라이언트)에 대한 점검기준이며, 이 기준이 항상 정답은 아니라는 것을 다시 한 번 강조합니다. 클라이언트 보안에서 모든 것을 해결하려는 기존 분위기에서 최근에는 서버단에서 함께 보안을 적절히 나누면서(FDS등) 클라이언트의 사용성을 강조하는 경우도 많이 있습니다. 다만, 보안 담당자로서 본 내용을 정확하게 이해한다면, 효율적으로 적절한 대응책을 마련하는데 도움이 될 것입니다. 참고로, 모든 리스크를 완전히 제거하는 것만이 좋은 것은 아닙니다. 위험수준과 발생확률을 감안해서 적절한 수준(때론 리스크 수용)의 대응을 함으로써 효율성을 고려할 수 있을 것입니다. 

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

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

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

비트코인에 대해서...

비트코인(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