macOS Secure Enclaveを使用したSSHキーの保護

標準的なSSHキーは通常 `~/.ssh/` ディレクトリ内に存在し、ファイル権限によってのみ保護されているため、ファイルシステムへのアクセス権を得た悪意のあるスクリプトに対して脆弱です。macOSのSecure Enclaveを活用することで、秘密鍵がメモリやディスク上のファイルとして存在しないことを保証でき、代わりに署名操作を内部で実行する専用のセキュリティチップ内に保管されます。

この画像は、ハードウェア保護されたキーを使用したすべてのSSH認証試行に必要となる、強制的なTouch ID生体認証プロンプトを説明しています。

ハードウェアによるキーの隔離

Secure EnclaveはMacのチップ上にあるセキュリティサブシステムであり、メインプロセッサから隔離されています。SSHキーがこのハードウェアによって保護される場合、秘密鍵はエンクレーブ内で生成され、それから外に出ることはありません。接続が開始されると、Macはエンクレーブに認証チャレンジの署名を依頼し、実際のキーはオペレーティングシステムからアクセス不可能な状態に保たれます。

HN Digestによるgithub.comの報告数値に基づくチャート。数値はソースの表記通りです。

このアプローチは、重大なセキュリティ上の欠陥に対処するものです。暗号化されたヴォルトのようなソフトウェアベースのソリューションは、使用中にキーをメモリに復号しますが、対照的にSecure Enclaveは、キー情報がメインCPUに決して公開されないため、完全に侵害されたオペレーティングシステムであっても秘密鍵を「盗む」ことができないことを保証します。

技術的な実装と構成

ネイティブなアプローチを設定するには、`sc_auth`コマンドを使用してCryptoTokenKitアイデンティティを作成する必要があります。ユーザーはNIST P-256曲線と、生体認証を要求するための`bio`フラグを指定する必要があります。このプロセスにより「キーハンドル」が生成されます。これは、SSHクライアントに対して生の秘密鍵ファイルを読み取るのではなく、エンクレーブに署名を要求するよう指示する参照ファイルです。

システムを機能させるために、ユーザーは`SSH_SK_PROVIDER`環境変数を`ssh-keychain.dylib`ライブラリを指すように設定する必要があります。SSHはこれらの特定のキーハンドルを自動的に検出しないため、システムが標準的なRSAまたはEd25519キーよりもSecure Enclaveキーを優先するように、`~/.ssh/config`ファイル内で明示的に定義する必要があります。

トレードオフとユーザーエクスペリエンス

この高度なセキュリティに対する主なトレードオフは、ポータビリティの欠如です。Secure Enclaveキーは特定のMacハードウェアに紐付いているため、デバイスが故障するとキーは失われます。ユーザーは、サーバーからロックアウトされることを防ぐために、YubiKeyや他のマシンに保存されるような二次的なバックアップキーを維持する必要があります。

ネイティブのmacOS体験は、標準的なSSHインターフェースではなく、低レベルな「ctccardtoken」プロンプトが表示されるなど、著しく洗練されていないのが特徴です。より洗練された体験を求めるユーザーには、Secretiveのようなサードパーティ製アプリケーションがあり、同じ基礎となるSecure Enclaveハードウェアを利用しながら、洗練されたUIとシステム通知を提供します。

このスクリーンショットは、キー認証のためにネイティブなmacOS実装で使用される、洗練されていない低レベルのインターフェースを示しています。

Secretiveは、ネイティブの実装と比較して、より洗練されたUIとシステム通知を提供するサードパーティ製アプリケーションです。