Windows 의 Bitlocker는 기본적으로 TPM을 통해 암호키를 저장하여 하드디스크를 암호화 한다. 그렇기 때문에 HDD만 단독으로 다른 컴퓨터에 붙인다고 해서 디스크를 읽지 못한다.
하지만 이를 도난시 데이터 보호용으로는 사용할 수 없다. BitLocker가 TPM을 사용할 때 Parameter Encryption을 사용하지 않기 때문에 단순히 Logic Analyzer나 MCU를 통해 손쉽게 TPM의 통신 내용을 Sniffing 하여 Unseal 과정을 그대로 볼 수 있기 때문이다.
참고:
이를 해결하기 위해 Parameter Encryption 을 사용하면 이를 방지할 수 있다.
Sniffing Test
tpm2-tools 개발사의 블로그에 소개되어있는 디스크 암호화 방법이다. 이 방식을 사용하면 TPM을 통해 디스크를 암호화할 수 있다. 하지만 여기 나온 방법만으로는 Bitlocker 처럼 Sniffing 공격에 취약하다.
관련 내용 : https://tpm2-software.github.io/2020/04/13/Disk-Encryption.html
이를 증명하기 위해 swtpm + qemu 를 이용했다. 가장 단순하게 테스트를 해 본다.
1. primary context 생성
$ tpm2_createprimary --hierarchy=o --key-algorithm=rsa --key-context=prim.ctx
2. 암호화 키 생성
$ dd if=/dev/urandom of=disk.key bs=1 count=32
$ hexdump -C disk.key
00000000 21 2b 95 aa 1e 81 fb ee 01 f8 78 ba 6d e1 71 ca |!+........x.m.q.|
00000010 fa 52 4c 42 7c 98 28 13 a3 43 ca d9 d0 3e 45 f5 |.RLB|.(..C...>E.|
3. Seal
$ tpm2_create -Q -g sha256 -u seal.pub -r seal.priv -i disk.key -C prim.ctx
$ tpm2_load -Q -C prim.ctx -u seal.pub -r seal.priv -n seal.name -c seal.ctx
4. Unseal (여기서 스니핑을 한다):
$ tpm2_unseal -Q -c seal.ctx | hexdump -C
00000000 21 2b 95 aa 1e 81 fb ee 01 f8 78 ba 6d e1 71 ca |!+........x.m.q.|
00000010 fa 52 4c 42 7c 98 28 13 a3 43 ca d9 d0 3e 45 f5 |.RLB|.(..C...>E.|
동 시간대 스니핑 정보:
SWTPM_IO_Read: length 91
80 02 00 00 00 5B 00 00 01 5E 80 00 00 00 00 00
00 49 02 00 00 01 00 20 51 3C 51 55 04 8D 2E 7D
70 17 7B 05 0F E8 51 61 E0 9F 53 61 CC 78 74 08
2F D0 CA 22 6C E3 B5 BF 01 00 20 C0 05 46 7A 71
09 AC 80 DC 37 62 F4 34 1C EB 9E E9 2E 3A 73 B7
23 30 54 81 76 E8 18 6B 71 02 EA
SWTPM_IO_Write: length 117
80 02 00 00 00 75 00 00 00 00 00 00 00 22 00 20
21 2B 95 AA 1E 81 FB EE 01 F8 78 BA 6D E1 71 CA
FA 52 4C 42 7C 98 28 13 A3 43 CA D9 D0 3E 45 F5
00 20 2C 84 8F 92 7A C3 04 04 10 67 72 97 A5 3F
93 F9 92 63 2C D4 48 EC 27 2A 92 AD 77 5A 36 62
4E 52 01 00 20 42 15 86 B3 F3 E2 51 26 EE 27 2C
49 CF B6 45 AE 62 C1 36 DB 82 C6 12 BC CD A8 18
25 14 7E 95 7F
그대로 보인다...
HMAC Session
이를 해결하기 위해 tpm2-tools 5.1.1 버전 부터는 hmac-session(Parameter Encryption, Salted Session)을 지원한다.
참고: https://github.com/tpm2-software/tpm2-tools/blob/master/man/tpm2_startauthsession.1.md
이를 사용하면 Sniffing을 해도 민감한 데이터가 보이지 않는다.
$ tpm2_startauthsession -c prim.ctx -S session.ctx --hmac-session
$ tpm2_create -Q -g sha256 -u seal.pub -r seal.priv -i disk.key -C prim.ctx -S session.ctx
$ tpm2_load -Q -C prim.ctx -u seal.pub -r seal.priv -n seal.name -c seal.ctx
$ tpm2_unseal -Q -c seal.ctx -S session.ctx | hexdump -C
$ tpm2_flushsession session.ctx
하지만 여기서 의문점이 생겨야 당연하다. 암호화를 하려면 두 피어간 암호키를 공유해야 하는데 어떻게 공유할까?
If tpmKey is TPM_RH_NULL, the session is an unsalted session; otherwise, it’s a salted session, and the encryptedSalt parameter is decrypted by the TPM to get the salt value used to add entropy. The TPM uses the loaded key pointed to by the tpmKey handle to do the decryption of encryptedSalt.
사실 TPM에 대한 자료가 방대하고.. 어려워서.. 정확하게는 파악을 못했지만 대충 보면 위의 경우에서는 prim.ctx 의 키를 통해 암호키를 공유하는 것으로 보인다.
자 암호키가 어떻게 공유되는지를 알았다. 그럼 이건 안전할까? 스니핑에는 안전할 수는 있지만, 우리는 장치가 도난 당했다는 가정을 하고 있다. 즉 하드웨어를 건드릴 수 있다는 것이다.
TPM을 물리적으로 분리하여 MITM(Man-in-the-middle)공격이 가능하다는 의미이다.
MITM
이 부분은 아직 연구 중이다... :)
원격 검증 과정에서는 EK (Endorsement Key) Public을 기억하고 있으면 이를 통해 검증 가능(세션을 열고 EK 를 검사하고 이후 동작 수행)한데...
나는 안전한 디스크 암호화가 목적이기 때문에 로컬 에서 이를 검증하는 과정을 연구 중이다.
<공격 시나리오>
1. 정상 상태에서 첫번째 부팅을 하여 DISK를 현재 TPM PCR으로 암호화.
2. 이후 부팅 시 TPM을 통한 DISK복호화
3. 해커가 PC 탈취 후 TPM MITM 공격
* PC는 Session 생성 후 persistent handle로 TPM에 Sealed Key복호화 요청
* 공격자는 Session 생성 당시부터 MITM공격을 통해 PC와는 자신의 Session Key 사용
* TPM은 Sealing 당시의 PCR과 현재 PCR이 다르지 않음을 확인하고 Unsealed Key를 PC에 세션키로 암호화하여 전송
* TPM이 주는 세션은 공격자의 세션이기 때문에 공격자가 Unsealed Key 탈취 가능함
포럼에 문의했는데 아직 별 답변이 없다..
https://lists.01.org/hyperkitty/list/tpm2@lists.01.org/thread/ETZM6ECYGPWBNZGTPQJVUGJJ5U5YZJCV/
2022년 업데이트: 음.. 연구좀 해봐야겠다
https://lists.01.org/hyperkitty/list/tpm2@lists.01.org/thread/RCY5PVWXHGGWBIR7GWXPKC5O5NMJPNK4/
'보안' 카테고리의 다른 글
tpm 키 테스트 (0) | 2021.08.03 |
---|---|
wip: Rock64에서 UEFI Secure Boot & TPM Measured Boot (0) | 2021.05.22 |
github 피싱 메일 주의! (0) | 2020.04.05 |
SafeNet 5110 AES Performance Test (0) | 2020.01.23 |
한국 메일로 유포되는 악성메일 분석 (JS/Obfus.S29) (0) | 2016.04.30 |
댓글