TPM 내부에서 TLS 핸드셰이크 서명하기
Signing TLS handshakes inside a TPM
이 글은 기밀 VM에서 원격 증명 작업을 하는 저자가 TPM을 사용하여 상호 TLS 인증을 구현하는 방법을 설명합니다. 디스크에 저장된 클라이언트 키는 메모리 덤프나 하이퍼바이저 스냅샷을 통해 탈취될 수 있는 반면, TPM은 키를 외부로 노출하지 않고 서명만 수행하므로 더 안전합니다. 저자는 파일 권한, 단기 인증서, KMS 등 대안을 비교하고, TPM이 키를 하드웨어에 바인딩하고 추가 자격 증명 없이 접근 가능한 유일한 방법임을 강조합니다. 또한 Go의 crypto.Signer 인터페이스를 통해 TPM 서명을 TLS 스택에 통합하는 방법과, 인증서의 공개 키를 사용하여 TPM 핸들을 자동으로 찾는 설계 결정을 설명합니다.
파일에 있는 키는 실제로 머신의 신원이 아닙니다. 그것은 우연히 머신에 저장된 전달자 자격 증명일 뿐이며, 그것을 읽는 사람은 누구든지 그 머신이 되는 것입니다.
HN 토론
46- bob1029
이것의 가치는 위협 모델에 달려 있다고 생각합니다.
TPM은 시스템이 키를 소유하고 있다는 더 강력한 보증을 제공하겠지만, 전용 HSM은 키 자료를 추출하기 훨씬 더 어렵게 만들 가능성이 높습니다.
TPM이 시스템 내부에 있다는 것은 양날의 검입니다. 한편으로는 증명(attestation)을 실현 가능하게 하지만, 다른 한편으로는 이제 보안 블랙박스가 그것을 사용하는 시스템과 동일한 물리적 영역 안에 있게 됩니다. 이러한 시스템들이 공존할 때 부채널 추출의 위험이 극적으로 증가합니다. 네트워크를 통해 HSM을 계측하는 것은 훨씬 더 어렵습니다.
- KaiserPro
제가 일했던 회사에서 알 수 없는 경로를 통해 시스템을 배송하면서도 조작되지 않았는지 어느 정도 확신이 필요한 경우가 있었습니다.
제 위협 모델은 합리적으로 기술적인 엔지니어가 어떤 이유로든 드라이브를 교체하거나, 누군가가 시스템이 '다르다'고 주장하는 상황이었습니다. (국가 차원의 공격 같은 건 아니고요)
시스템에 이미징이 끝나면, 중앙 구성 서버에 연결하여 호스트 이름을 받고 TPM에 내장될 키를 교환했습니다.
시스템이 배송되어 부팅되면, 체크인하고 챌린지에 서명합니다. 중앙 API에 대한 어떤 종류의 작업에도 챌린지가 있을 수 있습니다. 각 시스템은 적어도 한 시간에 한 번은 증명됩니다.
이 모든 것이 얼마나 '안전한지'는 잘 모르겠지만, 작동하는 것 같습니다.
- duk3luk3
흥미롭게 들리네요. 아쉽게도 우리가 얻는 것은 저자의 통찰력이 아니라 LLM이 만든 텍스트뿐이라는 것이.
- ted_dunning
증명(attestation)과 키 사이의 연결이 TAS로 잘 이루어집니다. TAS는 인증서를 제공하고, Spiffe는 그런 인증서를 요구하여 mTLS용 인증서로 사용하는 SVID를 발급합니다.
이는 신뢰의 뿌리가 증명 증거가 실시간 정책과 일치하는지 검증하는 소프트웨어(TAS)를 통해 이어진다는 것을 의미합니다. 이는 Spiffe를 변경하지 않고도 작동합니다.
결과 SVID가 메모리에 몇 분 동안 유지되므로 키를 메모리에서 유지하지 않으려는 요구 사항을 완전히 충족하지는 못하지만, 대부분의 사람들의 요구를 충족시킵니다.
- yusufmotiwala
이미 널리 논의된 문제이고 TPM에만 국한된 것이 아닌가요?
저희도 비슷한 문제에 직면했습니다 (OpenSSL을 사용합니다). OpenSSL에는 민감한 메모리가 덤프되지 않도록 방지하는 OPENSSL_secure_malloc()이 있습니다. 그러나 문제는 모든 경로가 보안 할당자를 사용하지 않는다는 것입니다. 예를 들어, 이 이슈: https://github.com/openssl/openssl/issues/27603
OpenSSL 4.x에서 이것이 변경되었는지는 확실하지 않지만, 분명히 바람직한 것입니다.