• 홈페이지
  • 문의

TPM는 모든 보안의 근간입니다. TPM 없으면 보안도 없습니다

PDF형식의 백서 사본은 여기에서 다운로드할 수 있습니다.

 

TPM(신뢰 플랫폼 모듈)은 모든 PC에 내장되어 있는 작은 반도체 장치로, CPU 자체 내부에 구현되어 있기도 합니다. 이는 암호화 키를 위한 안전 금고와 같은 역할을 하며, 결제 카드의 칩과 여러 면에서 유사합니다. TPM은 오랫동안 PC와 노트북 내부에 탑재되어 왔지만 은행 ATM 네트워크에 제대로 구축되지 않는 경우가 많습니다. 새로운 보안 아키텍처를 구현하기에는 타성에 젖어 있기 때문입니다. ATM 네트워크에는 다른 산업에서 쓰이는 것보다 더 많은 암호화 보안 아키텍처가 필요하다는 점을 고려하면 놀라운 일입니다.

사실 TPM는 단순한 보안키 저장소 이상의 역할을 합니다. PC 기반 네트워크의 모든 보안에 대한 신뢰 루트이며, ATM 네트워크에서도 마찬가지입니다.

이 백서에서는 은행이 ATM 보안 아키텍처를 설계할 때 고려해야 할 사항을 살펴보고 업계에서 TPM을 활용하여 하드웨어, 소프트웨어 및 네트워크를 암호화 방식으로 접근 제한하는 방법에 대해 알아봅니다.

서론

모든 사람은 ATM이 사용 편의성에 영향을 주지 않으면서 최대한 안전하게 보호되어야 한다는 데 동의합니다. 그러나 이를 달성할 방법에 대한 합의는 덜 된 것으로 보입니다. 물론 이러한 혼란은 여러 보안 제품이 고객의 관심을 끌기 위해 경쟁하고 있는 공급업체 간의 경쟁 때문에 발생합니다. 그러나 고객을 혼란에 빠뜨리고 결국 공격에 취약하게 만드는 잘못된 구현을 야기하는 틀린 정보도 상당량 존재합니다.

이 백서에서는 개별 컴퓨팅 시스템을 보호하는 기본적인 방법부터 시작하여 최고 수준의 보호를 필요로 하는 ATM 네트워크의 고유한 활용 사례에서 발생하는 문제를 해결하는 등 시스템 보안에 관한 중요한 기본 사항을 소개합니다. ATM 네트워크는 수백만 달러의 현금을 책임질 뿐만 아니라, 전 세계에 많은 돈을 송금할 수 있는 은행의 호스트 컴퓨터 시스템에 대한 진입점이기도 합니다. 보안 침해 사고가 발생한 ATM은 금고에 있는 현금 이상으로 은행에 더 큰 비용을 야기할 있습니다.

먼저 보안에 대한 몇 가지 일반적인 오해에 대해 살펴보겠습니다. 시스템 보안에 대한 가장 큰 오해는 계층화된 보안의 개념을 잘못 이해하고 있는 것일 수 있습니다. 복잡한 시스템의 보안을 지키는 단 하나의 마법 자물쇠는 존재하지 않습니다. 여러 개로 공조하는 자물쇠가 필요합니다. 그러나 이러한 개념은 보안 수준이 모호하고 복잡할수록 더 안전한 시스템 보안을 달성할 수 있다는 의미로 오해받는 경우가 많습니다. 그것은 전혀 사실이 아닙니다. 보안 아키텍처의 핵심을 형성해야 하는 간단하고, 공개적으로 논의되며, 오해를 불러일으키지 않는 기본적인 암호화 기법이 있습니다. 이러한 기술은 정량화할 수 있는 보안을 제공할 뿐만 아니라 사용이 간편하며 사용자가 사용을 위해 왜곡할 필요가 없습니다.

간단한 예시를 통해 설명하겠습니다. 우리 모두는 로그인하기 위해 사용자 ID와 암호를 요구하는 PC 시스템에 익숙합니다. 암호 기반 보안 시스템이 해커의 공격을 받게 되자, 조직들은 정기적인 암호 변경, 지난 몇 회 동안 사용했던 암호 사용 금지, 복잡하고 기억하기 어려운 암호 구성 등 정당한 사용자에게 매우 친화적이지 않은 복잡한 암호 규칙을 만들었습니다. 그러자 Microsoft는 “Windows Hello”를 통해 이러한 모든 문제를 해결했습니다.

Windows Hello는 TPM 보안 암호화 보안 하드웨어 장치 인식과 생체 인식 얼굴 인식을 결합합니다. 이는 실제로 ATM 업계가 잘 이해하고 있는 칩과 핀 번호라는 보안 개념과 매우 유사합니다. Windows Hello에서 칩의 역할은 결제 카드의 칩과 유사한 암호화 프로세서인 TPM이, 핀의 역할은 생체 인식 정보가 대신합니다. 이 시스템은 사용자 ID+암호 시스템보다 더 안전할 뿐만 아니라 매우 이용자 친화적입니다. Surface 태블릿에 얼굴만 비추면 즉시 로그인할 수 있는 것은 물론이고, 암호 한 글자를 입력하는 데 걸리는 시간보다 빠르게 로그인할 수 있습니다. 시스템을 더 안전하고 쉽게 사용하는 것이 가능할까요? 물론입니다. 고통 없이는 아무것도 얻을 수 없다는 생각에서 벗어나야 합니다. 진정한 보안은 사용자를 괴롭히지 않습니다.

앞 문단에서는 TPM의 개념을 소개했습니다. 이 백서는 컴퓨팅 분야에서 “핵심 신뢰 루트”인 TPM를 중심으로 작성되었습니다. TPM은 인텔, Microsoft, HP, IBM 등 주요 기업을 포함한 100개 사 이상으로 이루어진 트러스티드 컴퓨팅 그룹(TCG)에서 설계한 보안 아키텍처로 구성된 보안 반도체 칩입니다. 이러한 작업은 1999 초반부터 모든 컴퓨팅 보안을 해당 보안 코어에서 구축할 수 있도록 컴퓨팅 장치용 보안 코어를 만들겠다는 목표로 시작되었습니다. 좋은 소식은 TPM이 모든 새로운 PC 장치에서 완전히 표준으로 자리 잡아 수년 동안 사용되어왔다는 것입니다. 나쁜 소식은 많은 조직이 컴퓨팅 장치에 이러한 보석 같은 보안 수단이 있다는 사실을 모르고 이를 활용하지 못하고 있다는 것입니다. 이 백서는 특히 ATM 산업에서 이러한 상황을 변화시키기 위한 시도로써 제작되었습니다. 무엇보다, 이 분야는 다른 산업 분야보다 더 안전한 컴퓨팅을 필요로 하기 때문입니다.

TPM - “핵심 신뢰 루트”

“핵심 신뢰 루트”란 무엇을 의미하며 TPM이 컴퓨팅 보안에 중요한 이유는 무엇일까요? 이를 이해하려면 모든 컴퓨팅 보안이 암호화의 지능적인 사용에 의존한다는 점을 이해하는 것이 중요합니다. 암호화는 데이터를 “클리어” 형태에서 임의의 형식으로 변환했다가 다시 변환하는 컴퓨팅 방식입니다.

데이터 또는 정보가 클리어 형태로 되어 있는 경우 의도된 용도로 사용할 수 있습니다. 데이터가 암호화되면 암호가 복호화될 때까지 사용할 수 없습니다. 암호화 및 복호화에 있어 중요한 점은 데이터를 암호화하거나 복호화하려면 안전한 “키”가 필요하다는 것입니다. 키가 없으면 암호화된 데이터는 사용할 수 없습니다. 실제로 이러한 의미에서 “키”라는 단어는 금고를 여는 열쇠와 다르지 않습니다. 금고를 여는 열쇠를 분실하면 금고 안에 있는 금에 접근할 수 없는 것과 같습니다. 컴퓨팅의 경우, 금고 안의 금은 암호화 프로세스로 보호되는 데이터에 해당합니다.

이제 메시지 복호화를 위해 키를 사용하려면 키 자체가 클리어 형태여야 함을 이해하는 것이 중요합니다. 즉, 키를 안전하게 저장할 방법이 필요하다는 뜻입니다. 그렇습니다. 복호화 키를 다른 키로 암호화하는 것이 가능합니다. 이렇게 하면 원래 키를 안전하게 만들 수 있지만 두 번째 키의 저장 위치에 문제가 생깁니다. 이런 식으로 키 체인을 가질 수 있습니다(그리고 그러한 체인이 존재하는 경우가 종종 있습니다). 그러나 최초의 키는 안전한 곳에 클리어 형태로 저장해야 합니다. 컴퓨터 내부의 어디에 이렇게 클리어 마스터키를 저장할 수 있을까요? 하드 디스크(또는 SSD)는 정답이 아닙니다. 드라이브에 클리어 키를 안전하게 저장하는 것은 불가능합니다. 드라이브에 물리적으로 액세스할 수만 있으면 해커는 절대 실패하지 않고 클리어 키를 찾을 수 있습니다. 공격자가 물리적으로 액세스할 수 있는 경우 소프트웨어만으로는 이를 보호할 수 없습니다.

TPM을 입력합니다. TCG는 TPM을 비밀 정보를 위한 하드웨어 금고 용도로 설계되었으며, 마더보드 내부에 내장되어 있습니다. 일부 설계에서는 TPM이 CPU 칩 자체에 포함될 수 있습니다. 이런 설계의 목적은 키를 안전하게 저장하기 위한 것입니다. 또한 단순한 키 저장소 이상의 역할을 하므로, 다음 섹션에서 이에 대해 살펴보겠습니다. 현재로서는 컴퓨팅 시스템에 키 체인을 사용할 수 있지만, 체인의 시작 위치에 있는 키는 클리어 상태여야 하며 신뢰할 수 있는 용도로만 사용할 수 있도록 매우 안전하게 보관해야 합니다. TPM이 바로 키 저장소입니다.

CRTM - 핵심 신뢰 루트 측정

TPM은 단순히 미화된 키 저장소가 아닙니다. 직장에서 보안키 저장소를 사용하자 마자 이에 관하여 가장 먼저 발생할 수 있는 문제를 생각해보십시오. 누군가 TPM에 “제가 그 클리어 키를 써도 되나요?”라고 하면 누가 키를 요청하는지 어떻게 알 수 있습니까? 키를 안전하게 저장하는 것은 좋습니다만, 누구에게 그 키를 주겠습니까? 키 사용을 요청하는 것이 합법적인 코드입니까, 아니면 맬웨어입니까? 해커가 PC의 소프트웨어를 맬웨어로 수정한 후 정중하게 다음과 같이 말했던 적이 있습니다. “TPM, 키를 사용할 수 있습니까?” 이제 문제가 무엇인지 알 수 있을 것입니다. 단순히 키 저장소가 안전한 것만으로는 충분하지 않습니다. 이러한 키를 사용하도록 요청하는 소프트웨어에 대한 인증이 필요합니다. 이제 TPM의 다음 묘수인 CRTM(핵심 신뢰 루트 측정)을 입력하십시오.

CRTM은 전원을 켤 때 시작되는 신뢰 체인과 연동됩니다. 하드웨어 및 TPM은 초기 부팅부터 BIOS/UEFI까지, 그리고 운영 체제를 시작하는 모든 과정에 있어 PC의 부팅 순서를 “측정”하기 위해 함께 사용됩니다. 이는 PC의 소프트웨어가 시동 프로세스 중에 수정 또는 부당 변경되었는지 여부를 “측정”합니다. 이 프로세스는 현재 UEFI 펌웨어를 사용하여 PC를 시작하는 신형 PC 코어의 표준 기능인 보안 부팅(Secure Boot)으로 가장 잘 알려져 있습니다.

보안 부팅을 돕기 위해 TPM 설계에는 PCR(플랫폼 구성 레지스터)이라는 개념이 도입되었습니다. PCR 값은 “PCR 확장”이라고 불리는 프로세스에서 TPM에 의해 계산되며, 이는 블록체인 생성과 다소 유사한 방식으로 계산되므로 PCR은 PC의 시동 시퀀스에 대한 고유한 핑거프린트(예: 해시 세트)를 얻게 됩니다. PCR이 과거로부터 수정되지 않은 경우 PC의 시동 소프트웨어는 수정되지 않았음이 암호적으로 보장됩니다. 맬웨어가 측정된 시동 소프트웨어의 1바이트라도 PCR 값에 영향을 주지 않고 수정하는 것은 불가능합니다

tpm diagram 1

이것은 암호학에서 매우 중요한 개념입니다. “보안 해시 함수”는 데이터 블록을 원본 데이터의 핑거프린트 역할을 하는 고정된 길이의 문자열로 변환하는 암호화 방식의 함수입니다. 데이터가 변경되면 핑거프린트도 변경됩니다. 따라서 이는 대규모 소프트웨어에 아무리 사소한 수정 사항이 있더라도 감지할 수 있는 확실한 방법이 됩니다. TPM은 HMAC라고 하는 해싱 변형을 사용합니다. HMAC는 “키 기반 해시”에 해당하는 해시입니다. 즉, 올바른 보안키를 가진 사용자만 HMAC 해시를 생성하거나 확인할 수 있습니다. 이는 일종의 “암호화된 해시”입니다.

이 부분을 자세히 파고드는 데는 이유가 있습니다. 이것이 TPM 기술로 ATM의 핵심 소프트웨어를 100% 안전하게 보호하는 방식이기 때문입니다. TPM으로 보호되는 ATM의 부팅 시퀀스에서는 최신 암호화 기술을 파괴하지 않고는 소프트웨어의 단 1비트라도 수정할 수 없습니다. 또한 ATM의 나머지 부분을 보호하기 위해 이 백서에서 확장한 개념이기도 합니다.

소프트웨어 코어 안전성을 갖추고 난 다음, 애플리케이션 소프트웨어 보안은 어떻게 확보합니까?

Windows 10 ATM에서는 이 시점에서 다음과 같은 두 가지 중요한 Microsoft 기술인 BitLocker 및 Device Guard(현재의 WDAC - Windows Defender Application Control)가 적용됩니다. BitLocker는 Microsoft의 드라이브 암호화 기술입니다. 이 기술로는 하드 디스크 또는 SSD 전체를 암호화할 수 있는데, 가장 중요한 것은 드라이브 암호화 키를 “TPM”에 저장한다는 것입니다. 이는 실제로 TPM에 키를 저장하는 것보다 약간 더 복잡하므로, 좀 더 자세히 살펴보겠습니다.

키를 안전하게 저장하는 것만으로는 부족하고, 키를 넘겨주기 전에 키를 요청하는 것이 “누구”인지를 확인해야 한다는 점을 유념하십시오. TPM에는 키를 “봉인”하는 다른 신기능이 있습니다. ATM 드라이브가 안전한 환경에서 처음 암호화되고 Windows에서 새로운 키가 생성되면 해당 키는 KEK라는 별도의 “키 암호화 키”를 사용하여 암호화됩니다. KEK 자체는 PCR 값과 TPM의 개인 키를 사용하여 “봉인”이라는 프로세스에서 추가로 암호화됩니다. ATM이 부팅될 때, KEK 키는 PCR로 측정된 모든 핵심 소프트웨어 핑거프린트가 유효성을 확인 받은 경우에만, 즉, 앞에서 설명한 바와 같이 BIOS 및 Windows 코드가 부당 변경되지 않은 경우에만 사용할 수 있게 됩니다. KEK를 사용하여 Windows는 드라이브 암호화 키를 복호화하고 이 키를 사용하여 전체 드라이브를 복호화합니다. KEK가 회수되면 Windows에서 그 뒤의 KEK 도어를 닫습니다. 이 기능은 PCR 11을 “확장”함으로써 가능합니다. 즉, KEK의 봉인이 풀린 후 PCR 11이 수정되면 다른 누구도 KEK를 회수할 수 없습니다. KEK는 다음 부팅 시퀀스 시행되기까지 TPM에 의해 안전하게 유지되고, PCR이 코어 소프트웨어가 부당 변경되지 않았음을 확인한 경우에만 다시 사용할 수 있게 되며, KEK가 Bitlocker에 의해 드라이브의 암호를 복호화할 수 있게 되는 즉시 도어를 다시 잠급니다.

보시는 것과 같이, 부팅 프로세스를 완료하고 Windows를 로드할 때까지 PCR을 사용하여 각 소프트웨어를 검사해 부당 변경이 발생하지 않았는지 확인하며 핵심 소프트웨어를 단계별로 구축했습니다. 이제 ATM 애플리케이션 소프트웨어를 시동하고 실행 중인 모든 실행 파일이 사용하기 전에 부당 변경되지 않았는지 확인해야 합니다. 다시 말해서, 사용하기 전에 모든 소프트웨어 구성 요소의 암호화 지문을 확인하는 동일한 개념을 추가로 확장합니다. 이 시동 체인의 마지막 부분은 Windows WDAC(또는 유사한 기능을 가진 서드파티 소프트웨어)에 의해 실행됩니다. 이를 화이트리스트 작성(whitelisting)라고 합니다. 이 경우 실행이 허용되기 전에 모든 실행 파일의 해시(컴퓨팅을 거친 핑거프린트)가 확인됩니다.

ATM 화이트리스트 작성

Windows WDAC(또는 기타 화이트리스트 작성 소프트웨어)를 사용하여 ATM 소프트웨어 화이트리스를 작성하는 가장 좋은 방법은 “인증서 규칙”이라고 알려진 규칙을 사용하는 것입니다. ATM에 배포하는 소프트웨어에는 해당 소프트웨어 개발자의 사전 서명이 필요합니다. 예를 들어, Windows 10 실행 파일은 Microsoft에서 개인 키를 사용하여 서명됩니다. 즉, Microsoft의 코드 서명 공개 키를 사용하여 Windows 실행 파일을 확인하기만 하면 누구든지 Windows 실행 파일이 전송 중에 수정되거나 부당 변경되지 않고 Microsoft에 의해 서명된 시점의 상태와 동일함을 확인할 수 있습니다. WDAC가 이를 확인하도록 하기 위해 필요한 것은 마이크로소프트가 서명한 실행 파일을 안전하게 사용할 수 있다는 “인증서 규칙”을 만드는 것입니다.

마찬가지로 KAL의 소프트웨어는 항상 KAL의 코드 서명 개인 키로 서명됩니다. 고객은 각 ATM에 KAL의 코드 서명 인증서를 설치하여 KAL 소프트웨어가 부당 변경되지 않았는지 확인할 수 있습니다.

하지만 이러한 방식으로 사전 서명되지 않은 다른 소프트웨어는 어떻게 할까요? 은행은 다음 세 가지 옵션을 이용할 수 있습니다.

  1. 공급업체가 코드에 서명하도록 합니다.
  2. 공급업체를 해고합니다. (정말 2020년에 코드에 서명하지 않는 ATM 공급업체가 있을까요? 명백히 있습니다).
  3. “해시 규칙”을 사용합니다.
해시 규칙은 WDAC에 대한 화이트리스트 정책에 추가하는 규칙입니다. 이 규칙에서는 은행이 실행 파일에 서명하지 않은 공급업체의 각 파일에 대해 해시를 계산합니다. 즉, 공급업체를 위해 각 파일에 대한 코드 서명을 수행하는 것입니다. 보안 전송을 보장하기 위한 다른 메커니즘이 있더라도 공급업체와 은행 간에 전송 중에 발생하는 부당 변경을 감지할 수 없기 때문에 원 출처에서 서명된 코드만큼 좋은 것은 아닙니다. 이러한 방식으로 구현할 경우 두 번째 단점은 은행이 모든 실행 파일에 대해 “해시 규칙”을 만들어야 한다는 것입니다. 이 방법은 ATM은 해당 공급업체의 모든 실행 파일 및 해당 공급업체의 모든 향후 업데이트를 포함하는 공급업체의 공개 인증서를 ATM에 설치하는 것보다 덜 적합합니다.

아직 멀었을까요?

일단 이 지점에 도착하고 ATM이 가동 및 실행되면 모든 소프트웨어가 암호화로 검증됩니다. 부당 변경되거나 수정된 실행 파일은 실행할 수 없습니다. 최신 ATM에 사용되는 기가바이트 크기의 소프트웨어 실행 파일 중 단 1비트라도 탐지 및 차단되지 않은 채로 해킹하는 것은 불가능합니다.

하지만, 아직 그 수준에는 이르지 못했습니다. 이러한 방식으로 보호되는 ATM은 소프트웨어 스택의 무단 변경에 관한 한 무적입니다. 그러나 그것이 이야기의 끝은 아닙니다. ATM에 맬웨어를 삽입하는 것만이 ATM을 공격하는 유일한 방법은 아니기 때문입니다. 이제 TPM이 다른 유형의 공격에 어떻게 도움이 되는지 살펴보겠습니다.

TPM의 기능 이해하기

TPM은 단순히 ATM의 부팅 프로세스를 보호하는 것이 아닙니다. 이는 다른 모든 것도 보호할 수 있는 핵심 신뢰 루트입니다. 트러스티드 컴퓨팅 그룹의 멤버인 Will Arthur, David Challener, Kenneth Goldman이 쓴 멋진 저서를 살펴봅시다. “TPM 2.0에 대한 실용적인 가이드”(A practical guide to TPM 2.0)라는 교재는 매우 훌륭하며 이 백서의 작성에 영감을 준 소중한 아이디어들이 담겨 있습니다. 책은 여기에서 무료로 다운로드할 수 있습니다.

백서에서 이 책을 빠르게 요약하는 가장 좋은 방법은 책에 나와 있는 53가지 활용 사례에 초점을 맞추는 것입니다. 저자들의 허가를 받아, 활용 사례를 아래 목록으로 나열합니다.

1. 부팅 매개 변수 저장

2. VPN 키 액세스

3. 기본 키 최적화

4. ID 키 프로비저닝

5. 리소스 관리자가 TPM 키를 안전하게 관리할 수 있도록 허가

6. 공격자가 동일한 핸들에서 키를 변경하는 경우

7. UEFI

8. 증명 간 재부팅 감지

9. 대규모 파일 해싱하기

10. 신뢰할 수 있는 부팅 - 1

11. 신뢰할 수 있는 부팅 - 2

12. 여러 개의 동시 TPM 다이제스트 알고리즘

13. 로그인 암호를 저장하는 중

14. 핵심 신뢰 루트 서명 확인

15. 여러 개의 기본 키

16. 사용자 정의 기본 키

17. TPM 인용 키 인증

18. 인증서 체인 생성

19. 키 인증에 디지털 서명이 필요한지 확인

20. 키 인증에 생체 인증이 필요한지 확인

21. 비휘발성 데이터 확인

22. 비휘발성 확장 인덱스에 해당하는 인용문

23. 비밀 저장

24. 인증서 저장

25. 일반 암호 저장

26. 루트 공개 키 저장

27. HMAC 키 저장

28. 키에 대한 액세스 해지

 

29. 여러 사용자 키 해지

30. CA 키 사용에 대한 감사 로그 보안

31. 추가 PCR

32. 다른 속성을 가진 PCR

33. 가상화

34. 1회용 비휘발성 인덱스

35. 표준 인증서

36. 1회용, 항상 NV 인덱를 읽기

37. 정책 비밀 보안

38. 키 세트 복제

39. 하드 디스크 암호화 키를 플랫폼 상태로 봉인

40. VPN 키

41. OS 존재 환경에서 OS 부재 환경으로의 안전한 암호 전달

42. 인용문

43. 트랜잭션 간 재부팅 감지

44. VM용 증분 속성 PCR

45. 감사용 증분 속성 PCR

46. 사용자마다 다른 SrK 생성

47. 일체로 작동하는 서버 세트

48. 연결되어 있는 TPM은?

49. NV 인덱스, 카운터 또는 비트 필드 인덱스의 상태는?

50. PCR로 사용되는 NV 인덱스

51. 인증 기관으로 사용되는 TPM 감사

52. TPM을 사용한 애플리케이션 감사 로그 보호

53. 명령 시퀀스 중 PCR이 변경되지 않도록 하기

 

위의 활용 사례를 확인하십시오. 가장 먼저 인식해야 할 점은 TPM가 부트 프로세스 보안에만 국한된 것이 아니라는 점입니다. 앞에서 말했듯이 TPM은 ATM을 사용하여 수행해야 하는 보안이 필요한 작업을 한 번에 한 단계씩 수행할 수 있는 핵심 신뢰 루트입니다. 물론, 위의 모든 활용 사례가 이 업계에 반드시 적용되는 것은 아닙니다. 이러한 활용 사례는 암호화된 보안 방식으로 해당 항목을 보호하는 것임을 유념하십시오.

이제, 40번째 항목인 “ VPN 키”의 예를 들어 보겠습니다. 일반적으로 VPN은 두 시스템에 디지털 인증서(서명된 공개 키)를 설치하는 방법으로 ATM과 서버 사이에 설정됩니다. 하지만 누군가 인증서를 해킹하면 어떻게 될까요? 이 백서에서 설명된 잠금 기능을 사용하여 TPM으로 보호되는 Windows 환경에 저장된 인증서는 어느 정도 수정을 방지합니다. 그러나 여기서 한 단계 더 나아갈 수 있습니다. TPM을 사용하여 PCR에 대해 VPN 키를 봉인할 수 있습니다. 즉, VPN이 설정되려고 하는 순간, PCR이 올바른 상태일 경우에만 VPN을 설정하는 데 필요한 키를 사용할 수 있습니다. 조금이라도 차이가 있으면 VPN 연결이 거부됩니다. 이제 이 개념을 VPN 터널의 양쪽에 적용할 수 있다는 점을 생각해보십시오. PCR이 ATM 측에서 올바른 상태에 있어야 할 뿐만 아니라 데이터 센터의 ATM 서버에 대해 올바른 상태에 있어야 할 수도 있습니다. 이 작업이 수행되면, 연결하기 전에 ATM 및 ATM 서버가 모두 보안 상태에 있음을 암호를 통해 확인했을 것입니다. 지금까지 ATM과 ATM 서버에서 실행된 모든 실행 파일은 원래 상태의 흠결 없이 부당 변경되지 않은 상태이며, 이러한 시나리오가 두 시스템에서 모두 충족되는 경우에만 두 파일을 연결할 수 있다는 것을 알게 되었습니다.

네트워크 연결 보안

이전 섹션에서는 네트워크 보안에 대해 다루어 보았습니다. 이제 ATM에서 특히 중요한 활용 사례이므로 좀 더 자세히 살펴보겠습니다. 우리는 개별 ATM의 안전을 확보하기를 바라는 것에 그치지 않고, 백엔드 서버 시스템도 안전하고 보안 침해가 발생하지 않을 것을 요구하고 있습니다. 아래 다이어그램을 참고하십시오.

 

tpm diagram 2

 

이 다이어그램은 정교한 ATM 서비스를 사용하는 일반적인 대형 은행의 연결 시나리오를 보여 줍니다. ATM은 여러 백엔드 서버의 서비스를 조율하는 터미널 핸들러로 연결됩니다. HSM(하드웨어 보안 모듈)은 암호화 서비스를 제공하고 핀 조닝을 도와줍니다. 거래가 준비되고 승인을 받아야 하는 경우, “On Us” 거래인 경우에는 핵심 뱅킹 시스템으로, “Off Us” 거래인 경우에는 카드 체계로 전송됩니다.

이제 모든 ATM 및 모든 서버에 TPM(모든 최신 하드웨어의 경우 해당)이 있고 모든 시스템이 PCR 측정으로 부팅에서 검증되며, 모든 TLS 연결 및 VPN은 TPM에 의해 봉인되지 않은 인증서를 사용하여 설정되었기 때문에 암호로 부당 변경되지 않았음을 보장하는 보안 Utopia를 고려해 보십시오. 이름처럼 Utopia 그 자체입니다. 2020년 8월 기준으로 안타까운 상황은 이 수준의 보안을 달성한 은행이 거의 없다는 것입니다.

여기서 잠재적으로 구현해야 할 과제는 확장성과 클러스터링입니다. 연결이 개별 TPM에 연결된 경우 서버 클러스터를 어떻게 생성합니까? 위의 활용 사례 47번의 “일체로 작동하는 서버 세트”를 참조하십시오. TCG는 이미 그것에 대해 생각했습니다.

ATM의 하드웨어 장치 연결 보안

이 백서에서는 지금까지 ATM의 PC 코어에 대해 중점적으로 다루었으며, 시동 후 및 운영 중에 소프트웨어가 맬웨어를 사용하지 않도록 하는 방법에 대해 중점적으로 다루었습니다. 이제 ATM 내부의 개별 하드웨어 장치인 카드 판독기, 핀패드 및 현금 인출기를 살펴보겠습니다. PC 코어와 개별 장치 간의 연결에 대한 보안 상황은 어떨까요? 대부분의 ATM에서 이러한 연결은 물리적으로 부당 변경될 수 있는 USB 연결에 의하여 이루어집니다. 이러한 연결에 클리어 데이터가 있으면 ATM은 맬웨어에 감염되지 않더라도 공격에 취약해집니다. 다이어그램을 통해 이 문제를 다시 논의해보겠습니다.

 

tpm diagram 3

 

보시다시피, 공격 위험을 나타내기 위해 USB 연결을 클라우드로 표시했습니다. TPM은 PC 코어를 보호하지만, 보호되지 않는 USB 케이블은 공격을 받을 위험에 노출됩니다. ATM 하드웨어 공급업체는 이러한 연결을 보호해야 할 책임을 집니다. 그러나 하드웨어 장치와 나머지 시스템 간의 상호 운용성 요구 사항에 따라 상황이 달라지기 때문에 그렇게 간단하지 않습니다. 예를 들어 CDM(현금 인출기)로 보내는 메시지가 종단 간 암호화된 경우 “다른 쪽 종단”은 어디에 있어야 합니까? 가령 다른 쪽 종단이 터미널 핸들러에서 종료되는 경우, 많은 상호 운용성 요구 사항을 논의하고 합의해야 할 필요가 있습니다.

또한 다양한 “블랙박스 공격”에 대한 언론 보도를 보면 많은 ATM에서 현금 인출기가 제대로 보호되지 않는 것은 분명합니다. ATM 블랙박스 공격은 해커가 CDM에 대한 연결을 가로채고 자신의 PC 코어를 사용하여 현금을 인출함으로써 발생합니다. 대부분의 최신 ATM은 PC 코어에서 CDM으로 암호화된 연결을 가지고 있지만, KAL은 이러한 ATM 중 일부에는 TPM이 없기 때문에 보안 설계가 미흡하다고 생각합니다. 이제 분명히 말씀드리겠습니다. TPM이 없으면 보안도 없습니다. 마법으로 보호되는 키를 사용하여 연결을 암호화하는 애매한 방법은 보안이라고 할 수 없습니다. 그것은 모호함이자 희망사항에 불과합니다. 하드웨어 공급업체가 암호화 키 보호 방법에 대한 정보를 게시할 수 없는 경우, 키가 제대로 보호되지 않기 때문에 그 점을 분명히 알 수 있습니다.

XFS4IoT 및 하드웨어 장치 보호

다행인 것은 ATM 업계의 XFS 위원회가 차세대 ATM 장치를 보호하는 방법을 논의하고 있다는 것입니다. XFS4IoT라는 이름의 XFS 4.0이 곧 출시된다는 소식을 들어보신 분도 있을 것입니다. IoT 부분은 최신 IoT 환경에 대비하려는 사양의 의도를 보여줍니다. XFS4IoT 의 주요 목표는 다음과 같습니다.

    1. 사양은 운영 체제에 구애받지 않습니다. 이는 ATM에 Windows뿐만 아니라 Linux 또는 기타 OS도 ATM 내부에 설치할 수 있다는 의미입니다.
    2. 클라우드 친화적입니다. ATM 장치는 서비스를 클라우드에 직접 노출할 수 있습니다. ATM의 두뇌는 현재 ATM 내부뿐만 아니라 클라우드에도 존재할 수 있습니다. 예를 들어, 카드 판독기가 클라우드에 카드 판독기 서비스를 노출할 수 있습니다. 현금 인출기는 현금 인출 서비스를 클라우드에 노출시킬 수 있습니다.
    3. 이러한 방식으로 노출된 웹 서비스의 안전을 확보해야 합니다. XFS4IoT는 장치에 대한 엔드 투 엔드 보안을 확보하기 위한 보안 기능을 내장하고 있습니다. TLS에 의해 양쪽에 인증서가 있는 웹 소켓으로 전송 프로토콜이 선택되었습니다. 또한 각 XFS4IoT 장치에는 연결의 엔드 투 엔드 보안을 허용하는 하드웨어 보안 요소가 있을 수 있습니다. 이러한 연결은 ATM 내부에서 종료되거나(현재 일반적인 방식) 클라우드 서버에서 종료될 수 있습니다.

아래 다이어그램은 해당 개념을 보여줍니다.

tpm diagram 4

다행인 것은 ATM 업계의 XFS 위원회가 차세대 ATM 장치를 보호하는 방법을 논의하고 있다는 것입니다. XFS4IoT라는 이름의 XFS 4.0이 곧 출시된다는 소식을 들어보신 분도 있을 것입니다. IoT 부분은 최신 IoT 환경에 대비하려는 사양의 의도를 보여줍니다. XFS4IoT 의 주요 목표는 다음과 같습니다.

  • 사양은 운영 체제에 구애받지 않습니다. 이는 ATM에 Windows뿐만 아니라 Linux 또는 기타 OS도 ATM 내부에 설치할 수 있다는 의미입니다.
  • 클라우드 친화적입니다. ATM 장치는 서비스를 클라우드에 직접 노출할 수 있습니다. ATM의 두뇌는 현재 ATM 내부뿐만 아니라 클라우드에도 존재할 수 있습니다. 예를 들어, 카드 판독기가 클라우드에 카드 판독기 서비스를 노출할 수 있습니다. 현금 인출기는 현금 인출 서비스를 클라우드에 노출시킬 수 있습니다.
  • 이러한 방식으로 노출된 웹 서비스의 안전을 확보해야 합니다. XFS4IoT는 장치에 대한 엔드 투 엔드 보안을 확보하기 위한 보안 기능을 내장하고 있습니다. TLS에 의해 양쪽에 인증서가 있는 웹 소켓으로 전송 프로토콜이 선택되었습니다. 또한 각 XFS4IoT 장치에는 연결의 엔드 투 엔드 보안을 허용하는 하드웨어 보안 요소가 있을 수 있습니다. 이러한 연결은 ATM 내부에서 종료되거나(현재 일반적인 방식) 클라우드 서버에서 종료될 수 있습니다.

KAL은 TCG와 이 문제를 협의했으며 ATM 업계가 방안을 찾기 위한 브레인스토밍 한다면 기꺼이 돕겠다고 밝혔습니다. 실제로 TCG는 이미 “미니 TPM” 개념으로 어느 정도의 진전을 이루었습니다. 하나는 TCG의 DICE 설계이고 다른 하나는 TCG의 MARS 설계입니다. ATM 산업에서 DICE 및 MARS를 사용할 준비가 되어 있을까요? 그것은 알아보아야 합니다.

여기에서 흥미로운 생각할 거리는 표준 TPM이 각 장치 내에서 HSE로 사용될 수 있는지 여부입니다. 비용 측면에서는 그렇다고 답할 수 있습니다. OEM 볼륨에서 소요되는 TPM 비용은 1달러 미만이기 때문입니다. DICE는 훨씬 더 적은 비용이 들 수 있습니다. 수백만 달러의 소비자 자금을 보호하는 업계에서 TPM 또는 다른 유형의 HSE 비용이 문제가 될 가능성은 낮습니다.

ATM의 두 번째 신뢰 루트인 EPP

이전 섹션에서 장치 보호에 대해 설명했지만 보안 측면에서 강조해야 할 고유한 장치가 하나 있습니다. 바로 EPP(암호화 핀패드)입니다. EPP는 사실상 ATM 내부의 독립적인 신뢰 루트입니다. 매우 안전하며, PCI PED 요건을 통해 규제받고 있으며, 각 EPP는 개별적인 관리 및 전 세계적으로 업계 차원의 추적을 받고 있습니다. 부당 변경이 감지될 경우 자체 펌웨어에 대한 자체 CRTM 측정 및 자동 파괴가 가능합니다. 정말로 매우 안전합니다.

그러나 EPP는 업계 사용에 있어 장단점이었습니다. EPP가 ATM에 대해 일정 수준의 보안을 제공하기 때문에(한계에 대해서는 추후 논의) 은행들은 이를 활용하여 ATM 거래를 확보해 왔습니다. EPP는 은행의 마스터키를 안전하게 저장하며, 키 체인을 사용하여 핀 블록이 안전하게 보호되도록 하고 ATM과 호스트 간의 통신 메시지를 MAC으로 암호화합니다. 이것은 좋은 보안 방법입니다. 그러나 충분한 보안은 아닙니다.

EPP는 ATM이 부팅될 때는 물론이고 Windows가 부팅되고 XFS SP(ATM의 하드웨어 드라이버)가 시작작되기 전까지 사용할 수 없습니다. 즉, EPP는 ATM 내부의 소프트웨어 유효성 확인과 무관합니다. 맬웨어에 감염된 ATM 애플리케이션이 ATM 호스트에 PIN 또는 MAC 메시지를 수신하고자 하는 경우, EPP는 명령을 수행할 것입니다. EPP의 보호 경계는 너무 작아서 ATM 전체를 보호하는 데 도움이 되지 않습니다. TPM이 없는 잠재적으로 보호되지 않는 많은 소프트웨어들은 보안 침해의 타깃이 됩니다.

TPM으로 보호되는 중 소프트웨어를 업데이트하는 방법은?

이 단계에서 독자는 TPM으로 보호되는 ATM 내부의 소프트웨어를 변경할 수 없다면, 유효한 소프트웨어 업데이트를 수행하는 것이 어려울 것이라고 생각할 수 있습니다. 애플리케이션 소프트웨어는 인증서 규칙을 사용하여 보호됩니다. 이는 애플리케이션 개발자(은행 자체 또는 은행의 신뢰할 수 있는 공급업체)의 서명이 되어 있습니다. 업데이트된 소프트웨어에 소프트웨어 개발 조직의 보안 개인 키로 서명하면 ATM에서 변경 사항을 수락하게 됩니다. 아주 간단합니다.

PCR로 측정한 핵심 소프트웨어의 변경에는 추가적인 단계가 필요합니다. 핵심 소프트웨어는 기술자의 방문 없이 원격으로 완전히 업데이트할 수 있지만, 설치 프로세스 중에 변경되지 않은 PCR에 대해 봉인된 임시 키를 생성해야 합니다. 설치가 완료되면 새 키가 전체 PCR 세트에 대해 봉인됩니다. 쉽습니다.

Windows Hello에 관하여 이전에 들었던 예시를 떠올려보십시오. 좋은 보안이라고 사용하기 어려울 필요는 없습니다. 실제로 TPM 보호를 통해 은행에 제공되는 세계적 수준의 보안은 기존 방법과 비교했을 때 사용하기 쉽고 암호학적으로도 안전합니다.

물리적 공격에 대한 방어

지금까지 구체적으로 언급하지는 않았지만 위에서 논의된 내용 중 대부분은 물리적 공격과 소프트웨어 공격 모두로부터 ATM을 보호하는 방법에 관한 것입니다. ATM을 공격하는 일반적인 방법은 드라이브를 제거하고 소프트웨어를 수정한 후 ATM 및 다른 ATM의 변경 사항을 복원하는 것입니다. 드라이브가 암호화되어 있고 부트 체인이 TPM으로 보호되어 있는 경우에는 이러한 공격 방법이 통하지 않습니다.

또 다른 유형의 공격은 TPM을 “무차별 대입(brute-force)”하여 여러 키를 빠르게 연속해서 시도하는 것입니다. TPM에는 이러한 문제를 차단하는 “안티 해머링” 보호 기능이 내장되어 있습니다.

마지막으로, 마더보드 전자장치에 직접 간섭을 일으킬 수 있는 다른 유형의 극단적인 공격이 있습니다. 이러한 공격은 전문 장비를 필요로 하여 수행하는 데 많은 비용이 들기 때문에 지금까지 알고 있는 한 발생한 적이 없습니다. 하지만 마더보드의 노출된 전자 연결부를 보호하기 위해 레진을 사용하는 등 경제적인 방법으로 이러한 공격을 방지할 수 있습니다.

마법 같은 해결책을 경계하라

TPM을 신뢰의 루트로 하여 ATM과 PC를 보호하는 것은 컴퓨터 시스템을 완벽하게 보호하기 위해 유일하게 알려지고 공개된 방법입니다. 업계는 TPM 기반 보안이 ATM 네트워크에서 더 보편적으로 사용되지 않은 이유를 자문해야 합니다. 물론 여러 기업들은 시장에서 경쟁하고 각자의 보안 제품이 시장에 자리를 잡기를 원할 것입니다. 충분히 예상 가능한 바입니다. 그러나 은행이 환상 속에나 있을 듯한 해결책에 넘어가지 않는 것이 매우 중요합니다. 그 중 몇 가지를 살펴보겠습니다.

착각: “하드웨어 보안 요소는 필요 없다”

ATM의 디스크/SSD에 개인 키를 안전하게 저장할 수 없다는 점은 매우 분명합니다. 그 이유는 키 체인이 아무리 길어도 최초의 클리어 키가 있어야 하기 때문입니다. 드라이브에 해당 키가 “숨겨진” 경우 언제든지 복구할 수 있습니다. 일부 솔루션은 시동 시 키를 생성한다고 주장합니다. 그러나 그 키를 생성하려 해도 클리어 코드가 필요합니다. 아직 드라이브를 복호화하지 않았으므로 이 키는 클리어 키 안에 있어야 합니다. 클리어 키 안에 있는 경우, 드라이브 복호화 전에 클리어 키 안에 있는 복호화되지 않은 실행 가능한 코드에서 리버스 엔지니어링할 수 있습니다.

다른 방식으로 생각해 보십시오. 소프트웨어 기술만을 사용하여 ATM에서 키를 안전하게 보관할 수 있다면 우리 업계가 EPP를 구축하는 데 어려움을 겪을 필요가 없었을 것입니다.

착각: “키가 네트워크에 저장되므로 하드웨어 보안 요소는 필요 없다”

TPM이 없다는 이유로 ATM이 키를 안전하게 보관할 만큼 안전하지 않다면 키를 네트워크 위치로 이동하는 방법으로는 문제를 해결할 수 없습니다. 그 이유는 다음과 같습니다. ATM은 부팅될 때 보안키를 얻기 위해 네트워크에 액세스해야 합니다. 키 저장소가 없으면 네트워크에서 인증을 받기 위한 암호화된 보안 방법이 없는 것입니다. 즉, 네트워크 서버는 “누가 키를 요구하는지”를 알지 못합니다. 예를 들어 BitLocker가 네트워크에 키를 저장하는 경우에도, 네트워크에 대해 인증을 하기 위해서는 TPM이 필요합니다. TPM이 없으면 보안도 없습니다.

착각: “암호화 키는 필요 없다”

공급업체는 키 없이 암호화를 수행할 수 있는 마법과 같은 기술을 보유하고 있기 때문에 키를 저장할 필요가 없다는 주장을 하고 있습니다. 그게 사실이라면 정말 좋을 것 같습니다. 키가 필요다면 왜 세상이 키 관리 기술로 인해 계속 어려움을 겪고 있겠습니까? 3DES, AES 및 RSA와 같은 알려진 모든 암호화 기술에는 개인 키가 필요합니다. 개인 키는 안전하게 저장되어야 하므로 개인 키라고 합니다. 암호화 시스템의 보안 유지는 수많은 가능성 중에서 키가 선택되기 때문이빈다. 예를 들어 3DES에는 최소 2 112개의 키가 있습니다. 모든 키를 초당 50억 개의 속도로 대입해도 30년이 걸릴 것입니다. AES를 사용할 경우에는 같은 속도로 10 22 년이 걸립니다.

착각: “알고리즘은 기밀 사항이다”

진정한 보안은 공개 표준 및 공개 알고리즘과 기밀 키를 기반으로 합니다. 보안 시스템의 유일한 기밀 요소는 키입니다. 키가 손상된 경우 키를 변경하면 시스템이 다시 안전하게 보호됩니다.

착각: “접근 제어 목록(ACL)을 통한 안전한 보호가 가능하다”

접근 제어 목록은 TPM 잠금이 없는 경우 쉽게 우회 가능합니다. ACL에는 여러 가지 다른 단점이 있습니다. 여기서는 자세히 살펴볼 수 없지만 ACL이 ATM을 위한 충분한 보호 기능을 갖추었다기에 부족하다고는 말할 수 있습니다.

결론

TPM이 컴퓨팅 보안에 중요하며, 따라서 이것이 ATM 보안에서도 중요한 이유를 독자들이 이해할 수 있기를 바랍니다. 또한 대부분의 은행이 암호로 보장된 방식으로 은행 네트워크를 보호하기 위해서는 여전히 갈 길이 멀다는 것도 명확히 전달했기를 바랍니다. 또한 이러한 보안 시스템은 상호 운용성을 염두에 두고 설계되어야 합니다. 여러 공급업체와 여러 제품 솔루션은 오늘날의 ATM 기술 환경에서 표준적인 부분에 해당하므로 각 공급업체가 개별적으로 잠금 기능을 구현할 수는 없습니다. 그렇게 하면 사용할 수 없는 ATM을 만들게 될 것입니다.

이 백서가 TPM에서 제공하는 암호화 기반을 사용하여 상호 운용 가능한 보안 사양을 개발할 수 있는 프로세스의 시발점이 되기를 바랍니다. 트러스티드 컴퓨팅 그룹의 도움을 받았습니다. 이제 XFS4IoT, ATMIA 및 EAST와 같은 업계의 다양한 위원회와 은행 및 공급업체가 앞으로 나아갈 길을 설계해야 합니다.

감사한 분들

이 프로젝트에 기여해주신 다음 분들께 감사 드립니다.

  • Michael Moltke (NCC Group Denmark)
  • Kit Patterson (KAL)
  • Will Arthur, David Challener and Kenneth Goldman for writing the eBook on TPMs, and David Challener for organizing support from the TCG

자세한 정보가 필요하시면 이 이메일 주소가 스팸봇으로부터 보호됩니다. 확인하려면 자바스크립트 활성화가 필요합니다.으로 이메일을 보내주십시오