JSON Webトークンの対称または非対称暗号化？
私たちは、認証サーバーにJSON Web Token（JWT）を使用することを計画しており、現在、JWEトークンに対してどの暗号化アプローチを取るかを評価しています。
対称暗号化キーを管理するには、2つのオプションがあるようです。
- 発行者/受信者は対称鍵を事前共有し、それを使用してすべてのトークンを暗号化します。対称鍵はメッセージに含まれていません。
- 発行者はトークンごとに対称キーを生成し、受信者の公開キーを使用してトークンを暗号化し、メッセージに含めます。
十分に強力なアルゴリズムと十分な大きさの鍵サイズが使用されている限り、どちらにも固有のセキュリティ上の利点があるとは思えません。
主な違いは、最初のケースでは受信者が発行者を信頼して事前共有キーを漏らさないようにする必要があるのに対し、2番目のケースでは受信者だけが必要な復号化キーを持っていることです。ただし、このJWEトークンのペイロードは署名付きのJWSトークンになるため、受信者は発行者との強い信頼関係を持ち、自分の秘密署名キーを漏らさないように信頼する必要があるため、これは大きなものではないようです。問題。
オプション1がはるかに小さいトークンを生成する場合（暗号化された対称鍵が埋め込まれていないため）、オプション2を選択する理由はありますか？
オプション2の主な利点は、事前共有鍵を配布する（または侵害された場合は更新する）必要がないことです。どういうわけか、事前共有キーを転送する安全なメカニズムがあることを確認できる場合（つまり、これを行う必要があるのは1人だけであり、電話でそれらに話しかけ、キーをスペルアウトすることに自信がある- -明らかに、これにはセキュリティリスク（電話のタップ、反対側の紙に書かれたキーなど）があり、評価する必要があります）オプション1を選択します。ただし、クライアントが接続して起動できるAPIインターフェイスを構築したい場合帯域外の鍵交換なしの安全な接続、オプション2に進みます。
これをGoogleで見つけた人のためにここに配置したいだけです（現在、2番目の検索結果jwt public private vs symmetric）
オプション2はセキュリティリークです。発行者が受信者の公開鍵を使用してメッセージを暗号化する場合、はい、情報をデコードできるのは受信者だけですが、JWTを使用すると、必要なセキュリティはJWTは完全に無傷で変更されていません。公開鍵による暗号化はそれを行いません-誰でも同じことをすることができ、発行者になりすますです。
実際の解決策は、発行者のプライベートキーを使用してトークンに署名することです。その後、発行者が実際にJWTでその権限を確認した発行者のPUBLICキーを使用して誰でも確認できます。
オプション1では、発行者と受信者の両方が対称鍵を秘密にしておく必要があります。受信者が別の当事者によって作成および保守されているマルチテナントクラウドサービスである場合、これはリスクが高すぎる可能性があります。誰かが設定ファイルまたはデータベースにアクセスした場合、システム内の誰かになりすますトークンを作成することができます。
オプション2は、発行者にキーを秘密にしておく責任があります。あなたが受信者である場合、あなたは公開鍵のみを保持しているので、これは多くの責任とセキュリティの懸念を軽減します。発行者は、秘密暗号化キーのセキュリティに対して単独で責任を負うため、信頼が高まります。
つまり、対称鍵を安全に保つために受信者をどれだけ信頼するかにかかっています。そして、もしあなたが受信者であれば、製品と評判を賭けても構わないと思っていれば、それを安全に保つことができます。