この記事は BastionZero の寄稿によるものです。
ユーザーが自分の ID でメッセージに署名できるようにすることは、非常に強力です。 たとえば、この機能を使用すると、サーバーに SSH で接続し、ソフトウェア成果物に署名し、シングル サインオン (SSO) ID でエンドツーエンドの暗号化通信を作成できます。
OpenPubkeyプロトコルとオープンソースプロジェクトは、信頼できる関係者を追加することなく、人とワークロードの両方にデジタル署名の力をもたらします。OpenPubkeyは、Google、Microsoft、Okta、Facebookなどの主要なIDプロバイダーでサポートされているOpenID Connect(OIDC)SSOプロトコルに基づいて構築されています。
この記事では、OpenPubkeyがどのように機能するかを探り、3つのユースケースを詳しく見ていきます。
OpenPubkeyで何ができますか?
公開鍵暗号は 1970年代に発明され、セキュリティエンジニアリングのツールボックスの中で最も強力なツールになりました。 これにより、公開鍵とそれに関連する署名鍵を保持するすべてのものが暗号化IDを作成できます。 この ID は、当事者が署名キーを使用して本人であることを証明するだけでなく、この ID でメッセージに署名することもできるため、非常に安全です。
多くの場合、サーバーはサーバーの ID に関連付けられた公開キーを使用してユーザーに対して自分自身を認証しますが、このプロセスが逆に機能することはめったにありません。 個人のIDに関連付けられた公開鍵を使用してサーバーに対して認証を行うことはめったにありません。 代わりに、Cookie に格納された認証シークレットなど、すべての要求で送信する必要がある、安全性の低い認証方法が採用されています。
例えば、アリスが自分のメールアドレス [email protected]で「Escape at immediately — all is discovered」というメッセージに署名したいとします。 彼女ならどうするだろうか? 1 つの方法は、Alice が公開キー (PK) と署名キー (SK) を作成し、電子メールと PK の間のマッピングを公開することです。
このアプローチには 2 つの問題があります。 まず、このメッセージを確認するすべてのユーザーは、Web ページが Alice の電子メールを Alice の公開キーに正しくマップし、Alice の公開キーを悪意を持って Alice のなりすましに使用できる別のキーに置き換えていないことを信頼する必要があります。 次に、Alice は、この公開キーに関連付けられた署名キーを保護および管理する必要があります。 歴史を振り返ると、ユーザーは署名キーの保護が苦手です。 おそらく 最も有名な例は 、5億ドル相当のビットコインを管理する署名キーを紛失した男です。
Web上の人間による認証は、もともとサーバー認証と同じように機能するはずでした。 認証局 (CA) がサーバーに証明書を発行し、公開鍵をサーバーの ID ('example.com') に関連付けるのと同じように、 この計画では、CA が、公開鍵をその人の ID に関連付けるクライアント証明書を発行するというものでした。 これらの クライアント証明書 はまだ存在し、特定のアプリケーションでよく使用されていますが、秘密の署名キーの保護と管理を人々に求めるというひどいユーザーエクスペリエンス(UX)のために、 個人的な使用が広まることはありませんでした。
OpenPubkeyは、この2つの問題に対処します。 ID プロバイダーを使用して、ID と公開キーの間のマッピングを実行します。 すでに ID プロバイダーを信頼しているため、ID プロバイダーにこのマッピングを実行しても、新しい信頼できるパーティは追加されません。 たとえば、アリスは自分のアイデンティティを管理するために、すでにIDプロバイダーである Example.com を信頼している必要があるため([email protected])、アリスの公開鍵と Example.com アイデンティティ( [email protected] )の間のマッピングを実行するために Example.com を使用するのは自然なことです。Example.com は @example.com ユーザを認証する方法をすでに知っているため、Alice は新しいアカウントを設定したり、新しい認証要素を作成したりする必要はありません。
第二に、署名鍵の紛失や盗難の問題を解決するために、OpenPubkeyの公開鍵と署名鍵はエフェメラルです。 つまり、署名キーは自由に削除して再作成できます。 OpenPubkey は、ユーザーが ID プロバイダーに対して認証されるたびに、ユーザーの新しい公開鍵と署名鍵を生成します。 公開鍵をエフェメラルにするこのアプローチは、公開鍵でユーザーを認証する上で最も大きなUX障壁の1つを取り除きます。 また、セキュリティ上の利点も得られます。ユーザーがアイドル状態またはログアウトしたときに署名キーを削除できるため、署名キーが盗まれた場合の露出期間が大幅に短くなります。
OpenPubkeyはどのように機能しますか?
アリスは、自分の身分証([email protected])で「Escape at immediately — all is discovered」というメッセージに署名したいと考えています。 まず、アリスのコンピュータは新しい公開鍵と署名鍵を生成します。 次に、ID プロバイダー Example.com に、自分の ID をこの公開キーに関連付ける必要があります。 OpenPubkeyはどのようにこれを行いますか? このプロセスを理解するには、まず SSO/OpenID Connect のしくみについての詳細を提供する必要があります。
Example.com は @example.com の ID プロバイダーです。 アリスが本当に[ email protected]であることを確認する方法を知っています。 Example.com は、Alice が Example.com にサインインするたびにこれを行います。 OIDCでは、IDプロバイダーはIDトークンと呼ばれるステートメントに署名し、大まかに「これは [email protected]です」と記載します。 OIDCの認証プロセスの一部では、ユーザー(またはそのソフトウェア)が、発行されたIDトークンに含まれるランダムな値を送信できます。
Alice の OpenPubkey クライアントは、Alice の公開鍵の暗号化ハッシュを ID トークンのこの値に入れます。 Alice の OpenPubkey クライアントは、ID トークンを PK トークンと呼ばれるオブジェクトに変更し、基本的には「これは [email protected] で、公開鍵は xABCE 0...」と表示されます。 OpenPubkeyの詳細は省略しますが、これが基本的な考え方です。
Alice は、公開鍵を ID にバインドする Example.com によって署名された PK トークンを取得したので、"Escape at immediately — all is discovered" というステートメントに署名し、メッセージ、署名、ID トークンをブロードキャストできます。 ボブ、またはそのことに関する他の人は、IDトークンが Example.com によって署名されていることを確認し、アリスの署名がIDトークンの公開鍵と一致することを確認することで、このメッセージが本当に[ email protected]からのものかどうかを確認できます。
OpenPubkeyのユースケース
それでは、OpenPubkeyのユースケースを見てみましょう。
SSHの
OpenPubkeyは、友達に「すぐに逃げろ、すべてが発見された」と伝えるだけではありません。 ほとんどのセキュリティプロトコルは公開鍵暗号に基づいて構築されているため、OpenPubkeyは人間のIDをこれらのプロトコルに簡単にプラグインできます。
SSH は、公開鍵 (SSH 鍵とも呼ばれます) を使用したマシンとユーザーの両方の認証をサポートします。 ただし、これらの SSH キーは ID に関連付けられていません。 SSHキーでは、「xABCDキー 0ルートアクセスを許可する...」と言うことはできますが、「 [email protected]のルートアクセスを許可する」と言うことはできません。 これにより、UXとセキュリティの問題がいくつか発生します。 前述したように、人々は秘密の署名キーの管理に苦労しており、SSHも例外ではありません。
さらに問題なのは、公開鍵は ID に関連付けられていないため、SSH 鍵がアクセスできなくなった人やマシンを表しているかどうかを見分けるのが難しいことです。 SSH の発明者である Tatu Ylonen 氏は、最近の論文 「Challenges in Managing SSH Keys — and a Call for Solutions」で次のように述べています。
「数十の大企業のSSHキーを分析したところ、多くの環境で、すべての認証キーの 90%が使用されなくなっていることが判明しました。 これらは、プロビジョニングされたが、ユーザーが退職したとき、またはアクセスの必要性が存在しなくなったときに終了しなかったアクセスを表します。 許可されたキーの一部は 10〜20 年前のもので、通常、それらの約 10%はルートアクセスまたはその他の特権アクセスを許可します。 ほとんどの環境で見られる秘密ユーザー鍵の大部分は、パスフレーズを持っていません。
OpenPubkeyは、SSHキーをユーザーIDにバインドすることで、この問題を解決するために使用できます。 そうすることで、サーバーはID([email protected])がサーバーへの接続を許可されているかどうかを確認できます。 これは、アリスがSSOを使用してSSHサーバーにアクセスできることを意味します。彼女は [email protected] として Example.com にログインし、SSO が有効である限り、サーバーにアクセスできます。
OpenPubkey認証は、SSH設定を少し変更するだけでSSHに追加できます。 SSH のコードを変更する必要はありません。 試してみたり、OpenPubkeyのSSHの仕組みについて詳しく知りたい方は、最近の記事「 How to Use OpenPubkey to SSH Without SSH Keys」をご覧ください。
安全なメッセージング
OpenPubkeyは、エンドツーエンドの暗号化メッセージングに関する主要な問題の1つを解決するためにも使用できます。 誰かが安全なメッセージングアプリであなたにメッセージを送ったとします:彼らが実際にその人であることをどうやって知ることができますか? 安全なメッセージングアプリの中には、通信を保護している公開鍵を検索できるものがありますが、その公開鍵が実際にプライベートに通信したい相手の公開鍵であることをどうやって知ることができますか?
この公開鍵とIDの関係は、OpenPubkeyが解決する中核的な問題です。 OpenPubkeyを使用すると、ボブはアリスの公開鍵と彼女のメールアドレスを含む Example.com 署名されたIDトークンを確認することで、[ email protected] の公開鍵を知ることができます。 これには Example.com を信頼することが含まれますが、通常はSSO @example.com ユーザーへの Example.com をすでに信頼する必要があります。
ここでは説明しませんが、OpenPubkeyはオプションのプロトコル(MFA連帯保証人)をサポートしており、IDプロバイダーを信頼する必要がなくなります。 しかし、MFA 連署者プロトコルがなくても、OpenPubkey は Bob が Alice の公開鍵を Alice の ID プロバイダーから直接学習できるため、エンドツーエンドの暗号化されたメッセージングのセキュリティを強化します。
コンテナー イメージへの署名
OpenPubkeyは、人間のユースケースに限定されません。OpenPubkeyの開発者は、GitHubのIDプロバイダーとGitHub Actionsを使用して、(人ではなく)ワークフローがイメージに署名できるようにするソリューションに取り組んでいます。 このユースケースの詳細については、「 GitHub ActionsワークロードでOpenPubkeyを使用する方法」を参照してください。
OpenPubkeyの有用性の拡大にご協力ください
これら3つのユースケースは、OpenPubkeyでできることの限界と見なされるべきではありません。 このアプローチは非常に柔軟性が高く、VPN、連署、コンテナサービスメッシュ、暗号通貨、Webアプリケーション、さらには物理アクセスにも使用できます。
OpenPubkeyに貢献したい人は誰でも、 GitHubリポジトリにアクセスしてスターを付けてください。 私たちはオープンでフレンドリーなコミュニティを構築しており、誰からのプルリクエストも歓迎します — 詳細については、 コントリビューションガイドライン を参照してください。
さらに詳しく
- GitHub ActionsワークロードでOpenPubkeyを使用する方法を読んでください。
- 「SSH キーなしで OpenPubkey を使用して SSH を実行する方法」をお読みください。
- 炉辺談話 — セキュリティ標準の再定義:認証局としてのアイデンティティ・プロバイダ。
- Docker デスクトップの最新リリースを入手します。
- 次のものに投票してください! 公開ロードマップをご覧ください。
- 質問がありますか? Docker コミュニティがお手伝いします。
- ドッカーは初めてですか? 始めましょう。