問題タブ [jwe]

REST Web サービスに 2 レベルのセキュリティを実装したいと考えています。

1. トランスポート層 ポイント ツー ポイント セキュリティ (トランスポート層) には、HTTPS を使用することにしました。

2. メッセージ レイヤー (エンド ツー エンド) json データ (非常に機密) を暗号化された形式にする必要があります。これは、意図したユーザーのみが復号化できます。

これを実装する方法についていくつか提案が必要ですか? SOAP の WS-Security のような、使用できる Web 標準はありますか? JSON Web Encryption (JWE) に出会いましたが、それで目的が十分に達成できるかどうかはわかりません。

認証サーバーでJSONWebトークン（JWT）をサポートすることを検討しているため、最新のドラフトは08であるJSON Web暗号化（JWE）仕様を読んでいます。

定義されている非対称暗号化方式を使用して、対称鍵（コンテンツマスター鍵）は受信者の公開鍵を使用して暗号化されます。これは、受信者だけがそれを復号化でき、トークンが受信者向けであることを確認できるようにするために意味があります。

通常、トークンの出所を証明するものも表示されると思います。たとえば、公開鍵を使用して検証できる発行者の秘密鍵を使用して作成された署名などです。ただし、署名は、コンテンツマスターキーまたは受信者の公開キーのいずれかから派生しているように見え、発行者の秘密キーについては言及されていません。

これがないと、予想されたトークンの形式がわかっている限り、受信者の公開鍵を持っている人（つまり誰でも）が有効なトークンを生成できるように思えます。信頼できる認証サーバーだけではありません。

私は暗号化の専門家ではないので（それからはほど遠い）、ここで何かが欠けていると確信しています。受信者は、非対称に暗号化されたトークンが信頼できる発行者からのものであることをどのように確認しますか？

JSON Web Signatures（JWS）仕様では、発行者の秘密鍵を使用し、公開鍵で検証できる署名が定義されていることを考えると、JWEトークンのペイロードをJWSトークンにする必要があるのではないかと思います。

既存のライブラリは必要なアルゴリズムをサポートしていないため、PHP で JWE トークンを復号化するコードを作成しようとしています ( A128CBC+HS256、非推奨のアルゴリズムです)。

私の問題は、「連結キー導出関数」を使用するコンテンツ暗号化キーを生成する方法を理解できないことです (ここのセクション 5.8.1 を参照してください: http://csrc.nist.gov/publications/nistpubs/800-56A/ SP800-56A_Revision1_Mar08-2007.pdf )。関数の記号と説明が頭をよぎります。

JOSE JSON Web アルゴリズム ドラフト 06に基づいて値を取得しています。

これまでのところ、コードの関連部分は次のようになります。

おそらく関連する、ビッグエンディアン整数を取得するための私の関数:

ここに示されていない唯一の変数$masterKeyは、復号化されたコンテンツ マスター キーです。

Google は現在、https://www.googleapis.com/oauth2/v2/certsで次の証明書の値を公開しています。

oicとjwkestを使用して Google API にアクセスしようとすると、エラーが発生します

この問題はn、両方のキーのパラメーターが=文字で終わるために発生します。IIUC では、 JSON Web アルゴリズム ドラフトに従って Base64URL エンコードする必要があり、 JSON Web 署名ドラフト=に従って、Base64URL は文字を削除します。

このエラーは私が使用している Python ライブラリにあるのでしょうか、それとも実際に Google が仕様に準拠していないのでしょうか? 後者の場合: どこに報告できますか?

すべての JWE は、認証済み暗号化と関連データ (AEAD) アルゴリズムを使用して暗号化されます。IV および暗号化されたコンテンツ暗号化キー(CEK) を追加認証データ (AAD)に含めたくない理由はありますか? なんらかの形で JWE を脆弱にするのでしょうか?

編集：私はこれを調査し続け、 RFC 5116 セクション 2.1に従って見つけました

ナンスはアルゴリズムに対して内部的に認証され、AD 入力に含める必要はありません。アプリケーションにとって便利な場合は、ノンスを P または A に含めることができます。

と

秘密鍵 K は、他の入力 (N、P、および A) のいずれにも含めてはなりません。(この制限は、これらの入力の値をチェックして、キーに一致する部分文字列が含まれていないことを確認する必要があることを意味するのではなく、キーをこれらの入力に明示的にコピーしてはならないことを意味します。)

残りの質問は、暗号化されたコンテンツ キーがランダムな値と同等であると考えることです。それを aad に含めても問題ありませんか? ここでも完全に便宜上です。それとも情報漏えいの可能性があるのでしょうか?

JOSE を使用する場合、任意の種類のペイロードを使用できますか?

次のようなことを考えていました: {"alg":"ES512", "cty":"XML" }

XMLファイルから文字列を作成するだけで、サーバー側でctyをチェックしてXMLを作成します。

私はそれが可能であると確信していますが、例を見ていないので、おそらくそれは jose の背後にあるアイデアではなく、cty はペイロードが JWT または jose に関連するものであることを示すためだけのものであると考え始めました。

私は最近、Web セキュリティのソリューションを見つけています。私が知っている限り、HTTPS はより多くのセキュリティ Web をもたらしますが、JOSE(JWT&JWE) の別のセキュリティ ソリューションを見つけたので、知りたいです。将来それを使用できますか? HTTP のみを使用し、HTTPS は使用しませんか?

クリス。
ありがとう