TPM 内で TLS ハンドシェイクに署名する
Signing TLS handshakes inside a TPM
秘密鍵をファイルに保存すると、ヒープダンプやコアダンプ、メモリスナップショットから盗まれる可能性があります。TPM は鍵を外部に出すことなく署名できるため、真のマシン ID を実現します。この記事では、Go の crypto/tls が TPM 鍵と連携する仕組み、TPM 鍵を自動的に見つけるライブラリ go-tpm-tls の設計、そして TPM が解決する脅威と解決しない脅威について解説します。
ファイル内の鍵は、実際にはマシンの ID ではありません。それはたまたまマシンに保存されているベアラー資格情報であり、それを読み取った人は誰でも、誰かが気づいて証明書を失効させるまで、どこでもそのマシンになります。
HNでの議論
46- bob1029
この価値は、脅威モデル次第だと思います。TPMは、マシンが鍵を所有していることのより強い保証を与えてくれますが、専用のHSMの方が鍵材料を抽出するのははるかに難しいでしょう。TPMがマシン内部にあることは諸刃の剣です。一方で、アテステーションを実現可能にしますが、他方で、セキュリティのブラックボックスが、それを使用するマシンと同じ物理領域内にあることになります。これらのシステムが共存すると、サイドチャネル抽出のリスクが劇的に高まります。ネットワーク越しにHSMを計測するのははるかに困難です。
- KaiserPro
私が働いていたある会社で、未知の経路でマシンを出荷し、改ざんされていないというある程度の確信が必要でした。私の脅威モデルは、かなり技術的なエンジニアが何らかの理由でドライブを交換する、または誰かがマシンが「違う」と主張する、といったものでした（国家レベルのものはありません）。マシンがイメージングされた後、中央の設定サーバーに接続し、ホスト名を取得し、TPMに埋め込まれる鍵を交換します。マシンが出荷され起動すると、チェックインしてチャレンジに署名します。中央APIでのあらゆるアクションにチャレンジを要求できます。各マシンは少なくとも1時間に1回はアテステーションを受けます。これがどれほど「安全」かはわかりませんが、機能しているようです。
- duk3luk3
興味深いですね。ただ、残念なのは、著者の洞察ではなく、LLMが生成したテキストしか得られないことです。
- ted_dunning
アテステーションと鍵の間のリンクは、TASでうまく作られています。TASは証明書を発行し、Spiffeはそのような証明書を要求して、mTLSの証明書として使用するSVIDを発行します。これは、アテステーションの証拠がライブのポリシーと一致することを検証するソフトウェア（TAS）を通じて信頼のルートがつながることを意味します。これはSpiffeに変更を加えることなく機能します。結果として得られるSVIDはメモリ内に数分間保持されるため、鍵をメモリから出しておくという要件を実際に満たすわけではありませんが、ほとんどの人のニーズは満たします。https://github.com/TEE-Attestation/tas
- yusufmotiwala
これはすでに十分に議論された問題であり、TPMに固有のものではないのではありませんか？私たちも同様の問題に直面しました（OpenSSLを使用しています）。OpenSSLにはOPENSSL_secure_malloc()があり、機密メモリがダンプされるのを防ぎます。しかし、問題は、すべてのパスがセキュアアロケータを使用するわけではないことです。例えば、この問題：https://github.com/openssl/openssl/issues/27603。OpenSSL 4.xでこれが変更されたかどうかはわかりませんが、確かに望ましいことです。