쎄이 시큐리티 - Say Security

좀 지난 이야기지만, 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% 안전한 것이 아니기 때문에 앱은 신뢰하지 않는 다는 전제로 다양한 인증, 암호화기술, 토큰화 기술 적용 등 구조적으로 보완할 수 있는 다양한 방법을 활용해야 할 것입니다.