SSHキーの素材を安全なハードウェアエンクレーブに移動することで、ホストのファイルシステムが侵害されたとしても、物理的なハードウェアの存在なしには秘密鍵を流出させたり使用したりできないことを保証できます。この移行は、ローカルマシンへのルートアクセスを得た攻撃者に対して常にアクセス可能な状態にある「従来」のディスク上キーの脆弱性に対処するものです。

ハードウェア内蔵キーへの移行

従来のSSHキーは通常、パスフレーズのみで保護されたファイルとしてディスクに保存されます。パスフレーズはbcryptとAESを使用してキーを暗号化しますが、攻撃者がホスト上で十分な権限を獲得した場合、復号された素材は依然として脆弱です。ハードウェア内蔵キーは、この保護を安全なエンクレーブやYubiKeyのような専用デバイスに移動させます。

主なセキュリティ上の利点は、キーを生成するために使用したハードウェアが必要になることです。内部のキー素材を流出させるメカニズムが存在しないため、ディスクイメージを盗んだりリモートでルートアクセスを獲得したりした攻撃者は、ハードウェアを物理的に所有していない限り、キーを複製することはできません。

「ここでの理論的な利点は、SSHキーを生成するために使用したハードウェアが、キーを使用するために必要になることです。」

— I deleted all my SSH keys

実装方法:YubiKey、TPM、およびSecure Enclave

YubiKeyの方法はed25519-sk(Security Key)形式を利用します。レジデントオプションでキーを登録すると、YubiKeyは素材を内部に保存します。ホストディスク上のファイルは、ハードウェアデバイスを指し示す単なる「ハンドル」となります。ユーザーは、すべての認証試行において物理的なタッチを要求するようにこれらのキーを設定でき、高度なプレゼンス検出を提供します。

YubiKey ed25519-sk登録方法を示すコードリスト
YubiKeyデバイスにレジデントキーを登録するための構成例。web.archive.org

このスクリーンショットは、YubiKeyの内部メモリにキーを登録するための具体的なコマンドライン方法を示しています。

既存のハードウェアを活用したいユーザーには、ssh-tpm-agentを介してTPM(Trusted Platform Module)を使用できます。YubiKeyとは異なり、TPMはネイティブにSSHキーの登録をサポートしていません。代わりに、秘密鍵の素材は暗号化された形式でディスクに保存され、TPMを使用してそれを復号します。これにより、キーが特定のマシンのハードウェアに紐付けられます。

ssh-tpm-agentを使用した無人TPM使用のためのコードリスト
ディスク上の暗号化キーファイルをTPMで復号するための構成例。web.archive.org

この画像は、ssh-tpm-agentを使用したTPMバックアップキーの実装を実演しています。

macOSでは、Smart Card Authシステムを使用して、Apple Secure Enclave内にエクスポート不可能なアイデンティティを作成できます。作成時に-ne(non-exportable)フラグを使用することで、キーはエンクレーブ内に留まることが強制されます。これらのアイデンティティはディスクへのハンドルとしてエクスポートでき、OpenSSHはssh-keychain.dylibプロバイダーを介してそれらを使用できます。

Apple Secure Enclaveでエクスポート不可能なアイデンティティを作成するためのコードリスト
キーをApple Secure Enclave内に保持するために-neフラグを使用する例。web.archive.org

このスクリーンショットは、macOSでエクスポート不可能なアイデンティティを作成するプロセスを示しています。

運用のトレードオフと制限

ハードウェア内蔵キーへの移行は、特定の運用上の制約をもたらします。例えば、AppleのSecure Enclaveキーは、TouchIDが利用できないため「クラムシェルモード」(ノートパソコンの蓋を閉じた状態)では失敗する可能性があり、ユーザーはTouchID付きのBluetoothキーボードを使用するか、プレゼンス検出のためにYubiKeyを使用する必要があります。さらに、ハードウェアの故障や紛失によりキーが永久に使用できなくなる可能性があるため、複数のデバイスにわたる冗長性が不可欠です。

無人認証には大きな制限があります。YubiKeyは「タッチ不要」フラグをサポートしていますが、これはサーバー側でauthorized_keysファイルにキーを前置することで明示的に許可する必要があります。この要件は、GitHubやBitBucketなどのすべてのサードパーティサービスでサポートされているとは限らず、自動化されたワークフローでのこれらのキーの使用を制限する可能性があります。

Hacker Newsの読者の反応

  • 技術的な指摘: あるコメント投稿者は、TPMの方法でも秘密鍵の素材は暗号化された形式でディスクに保存されることを指摘し、TPMへのアクセス権を持つ人であれば、所有者のパスワードなしでキーを再作成できる可能性があると述べています。 コメント ↗
  • 技術的な指摘: 複数のコメント投稿者がハードウェアの信頼性について懸念を表明しており、あるユーザーはYubiKeyが溶けたという個人的な経験を共有し、別のユーザーはデバイスの紛失や損傷による永久的なロックアウトをどう対処すべきかを疑問視しています。 コメント ↗
  • 技術的な指摘: あるコメント投稿者は、YubiKeyを認証局として使用し、短期間でスコープ制限のあるSSH証明書に署名するという代替案を提案しました。 コメント ↗
  • 技術的な指摘: あるコメント投稿者は、マルチホップ認証に関する実用的な制限に言及し、ハードウェアキーが現在、ジャンプボックスを介した2番目のホップの認証をサポートできるかどうかを疑問視しました。 コメント ↗

Hacker Newsのスレッドで出た意見の要約です。事実として検証されたものではありません。 議論の全文を読む ↗