この記事は 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 に保存された認証シークレットなど、安全性の低い認証方法が採用され、リクエストごとに送信する必要があります。
たとえば、アリスが自分のメールアドレス alice@example.com の下に「一度に逃げる - すべてが発見されました」というメッセージに署名したかったとします。 彼女はどうやってそれを行うのでしょうか? 1 つの方法は、Alice が公開キー (PK) と署名キー (SK) を作成し、メールと PK の間のマッピングを公開することです。
このアプローチには 2 つの問題があります。 まず、このメッセージを確認するすべてのユーザーは、Web ページが Alice の電子メールを彼女の公開キーに正直にマップし、Alice になりすますために使用される可能性のある別のキーに悪意を持って公開キーを置き換えていないことを信頼する必要があります。 次に、アリスは、この公開キーに関連付けられた署名キーを保護および管理する必要があります。 歴史は、ユーザーが署名キーを保護するのが苦手であることを示しています。 おそらく 最も有名な例は 、5億ドル相当のビットコインを制御する署名キーを紛失した男です。
Web上の人間による認証は、もともとサーバー認証と同じように機能するはずでした。 認証局 (CA) がサーバーに証明書を発行し、公開鍵をサーバーの ID ('example.com') に関連付けるのと同じように、 計画は、CA が、公開鍵をその人の ID に関連付ける人物にクライアント証明書を発行するというものでした。 これらの クライアント証明書 はまだ存在し、特定のアプリケーションでよく使用されていますが、秘密の署名キーの保護と管理を人々に求めるというひどいユーザーエクスペリエンス(UX)のためと思われるため、 個人の使用が広く普及することはありませんでした。
OpenPubkeyは、これらの問題の両方に対処します。 ID プロバイダーを使用して、ID と公開鍵の間のマッピングを実行します。 すでに ID プロバイダーを信頼しているため、ID プロバイダーにこのマッピングを実行させても、新しい信頼できるパーティは追加されません。 たとえば、アリスは自分の ID プロバイダーである Example.com をすでに信頼して ID を管理する必要があります (alice@example.com)。 したがって、Example.com を使用して、アリスの公開鍵と彼女の Example.com アイデンティティ(alice@example.com)との間のマッピングを実行するのは自然なことです。 Example.com は @example.com ユーザーの認証方法をすでに知っているため、Alice は新しいアカウントを設定したり、新しい認証要素を作成したりする必要はありません。
次に、署名キーの紛失または盗難の問題を解決するために、OpenPubkey公開鍵と署名キーは一時的なものです。 つまり、署名キーは自由に削除して再作成できます。 OpenPubkey は、ユーザーが ID プロバイダーに認証されるたびに、ユーザーの新しい公開キーと署名キーを生成します。 公開鍵をエフェメラルにするこのアプローチは、公開鍵を持つ人々を認証する際の最も重要なUXの障壁の1つを取り除きます。 また、セキュリティの勝利も提供します。署名キーが盗まれた場合、ユーザーがアイドル状態またはログアウトしたときに署名キーを削除できるため、公開期間が大幅に短縮されます。
OpenPubkeyはどのように機能しますか?
私たちの状況に戻りましょう:アリスは彼女のアイデンティティ(alice@example.com)の下で「一度に逃げる-すべてが発見されました」というメッセージに署名したいと考えています。 まず、アリスのコンピュータは新しい公開鍵と署名鍵を生成します。 次に、ID プロバイダーである Example.com に、自分の ID をこの公開キーに関連付ける必要があります。 OpenPubkeyはどのようにこれを行いますか? プロセスを理解するには、まず SSO/OpenID Connect のしくみについて詳しく説明する必要があります。
Example.com は @example.com の ID プロバイダーです。 アリスが本当に alice@example.com ていることを確認する方法を知っています。 Example.com は、Alice が Example.com にサインインするたびにこれを行います。 OIDC では、ID プロバイダーは ID トークンと呼ばれるステートメントに署名し、大まかに "this is alice@example.com" を示します。 OIDCの認証プロセスの一部では、ユーザー(またはそのソフトウェア)が、発行されたIDトークンに含まれるランダムな値を送信できます。
Alice の OpenPubkey クライアントは、Alice の公開鍵の暗号化ハッシュを ID トークンのこの値に格納します。 Alice の OpenPubkey クライアントは、ID トークンを PK トークンと呼ばれるオブジェクトに変更し、基本的には「これは "これは alice@example.com で、彼女の公開キーは 0xABCE..." です。 OpenPubkeyの詳細についてはいくつか省略していますが、これが基本的な考え方です。
Example.com が署名したPKトークンを手に入れたので、アリスは公開鍵を自分のアイデンティティに結びつけ、「一度に逃げる - すべてが発見されました」という声明に署名し、メッセージ、署名、および彼女のIDトークンをブロードキャストできます。 ボブ、またはそれ以外の誰でも、IDトークンが Example.com によって署名されていることを確認し、アリスの署名がIDトークンの公開鍵と一致することを確認することで、このメッセージが本当に alice@example.com からのものかどうかを確認できます。
OpenPubkeyのユースケース
それでは、OpenPubkeyのユースケースを見てみましょう。
SSHの
OpenPubkeyは、友達に「すぐに逃げろ、すべてが発見された」と伝えるだけではありません。 ほとんどのセキュリティプロトコルは公開鍵暗号に基づいて構築されているため、OpenPubkeyは人間のIDをこれらのプロトコルに簡単にプラグインできます。
SSH は、公開鍵 (SSH キーとも呼ばれます) を使用したマシンとユーザーの両方の認証をサポートします。 ただし、これらの SSH キーは ID に関連付けられていません。 SSH キーを使用すると、「キー x 0のルートアクセスを許可」と言うことができますが、「alice@example.com のルートアクセスを許可」とは言えません。 これには、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 (alice@example.com) がサーバーへの接続を許可されているかどうかを確認できます。 これは、アリスはSSOを使用してSSHサーバーにアクセスできることを意味します。彼女は alice@example.com として Example.com にログインし、SSOが有効である限りサーバーにアクセスできます。
OpenPubkey認証は、SSHの設定を少し変更するだけでSSHに追加できます。 SSH のコードを変更する必要はありません。 試してみたり、OpenPubkeyのSSHの仕組みについて詳しく知りたい方は、最近の投稿「 SSHキーなしでOpenPubkeyを使用してSSHを使用する方法」をご覧ください。
安全なメッセージング
OpenPubkeyは、エンドツーエンドの暗号化メッセージングに関する主要な問題の1つを解決するためにも使用できます。 誰かが安全なメッセージングアプリであなたにメッセージを送ったとします:彼らが実際にその人であることをどのようにして知ることができますか? 一部の安全なメッセージングアプリでは、通信を保護している公開鍵を検索できますが、その公開鍵が実際に非公開で通信したい人の公開鍵であることをどうやって知ることができますか?
この公開鍵とIDの関係が、OpenPubkeyが解決する主要な問題です。 OpenPubkeyを使用すると、ボブは、アリスの公開鍵と彼女の電子メールアドレスを含む、Example.com によって署名されたIDトークンを確認することにより、alice@example.com の公開鍵を学習できます。 これには 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 コミュニティがお手伝いします。
- ドッカーは初めてですか? 始めましょう。