セキュリティ健全性チェック

Question

私が統合しようとしているサービスがこのプロトコルを使用している会社：

AESキーはAndroidライブラリに埋め込まれています。
自身を認証するために、ライブラリはプレーンHTTPを介してキーのSHA1ハッシュを送信します。
応答には、同じAESキーを使用して暗号化されたRSA公開キーが含まれています。
一時的なAESキーがクライアントで生成されます。
一時的なAESキーと機密データはRSAキーで暗号化され、プレーンHTTP経由で送信されます。

HTTPSを使用しない言い訳は、サーバーだけでなく、サポートするすべてのモバイルデバイスで署名済み証明書の料金を支払う必要があると考えていることです。彼らはまた、HTTPSはモバイルデバイスで使用するにはネットワークオーバーヘッドが多すぎると考えています。ああ、彼らのシステムはより長いAESキーを使用しているため、「HTTPSよりも安全」です。これはクレジットカードの処理に使用されていると言ったでしょうか。

私はこれが全く正気でないことを彼らに納得させようとしています。 PHBが理解できる明確で簡潔な説明を誰かに教えてもらえますか？（または、ボートを揺さぶったことで解雇された場合、失業の聴聞会に持ち込むことができますか？）

AJ Henderson · Accepted Answer

ええ、あなたがそれを正確に説明しているなら、これは完全に壊れており、役に立たないほどです。

最初のAESキーはアプリ内に存在することで危険にさらされ、アプリを持っている人はだれでもAESキーにアクセスできます。これがグローバルなものである場合、それは十分かつ真にねじ込まれています。それが各アプリケーションに固有である場合、希望の小さな断片がある可能性があります。

SHA-1は完全に再生可能です。ソルトについては触れていませんが、ソルトがある場合でも、攻撃者は正当なクライアントに対してMitMとして再生し、サーバーにクライアントとして表示されるように有効に応答できます。

その後、サーバーは攻撃者に公開鍵を暗号化された形式で提供しますが、これは攻撃者にとって特に有用ではありませんが、公開鍵でもあります...公開されているはずです。プライベートにしても何も起こりません。クライアントが侵害された場合（またはAESキーがグローバルの場合は任意のクライアント）、アプリケーションによってAESキーが漏洩し、公開キーも攻撃者に利用可能になります。

さらに、クライアントがRSA公開鍵を検証する方法がないため、AES鍵が侵害された場合、攻撃者は任意の公開鍵を送信できます。

クライアントで生成されるAESキーは十分なアイデアですが、これまでのところ、攻撃者が独自のAESキーを生成するのを妨げるものはありません。さらに、クライアントに独自の公開鍵を提供して、クライアントをだますこともできます。

RSAキーでデータが暗号化されるのはなぜですか？では、一時的なAESキーのポイントは何ですか？本当に完全に未使用ですか？ RSAを使用した長いデータの暗号化は、対称暗号化を使用する場合よりも安全性が低いと見なされます。これは、処理に多くの作業が必要であり、他のセキュリティに影響する可能性があるためです。通常、対称鍵を交換し、それをデータ交換に使用するだけです。

つまり、システムは完全に役に立たないのです。

アプリケーションのサーバーの公開キーを単純に埋め込み、それを使用してクライアントにAESキーを生成させ、セッション通信用に交換させると、実際にははるかに便利です。クライアント自体については何も検証しませんが、セッションが初期化された後、パスワードやその他のトークンを使用して検証できます。その時点では、自己署名HTTPSの使用にかなり近いですが、HTTPSが何らかの理由（クライアントに信頼されたルート証明書を追加できないなど）がない場合は、カスタム実装として使用できます。デバイス）。

David · Answer

まあ、ライブラリに埋め込まれたAESキーは完全に役に立たず、サーバー側の検証がないようです。このスキームには多くの問題があります。

Androidライブラリにアクセスできるユーザーは誰でもAESキーを抽出できます。
プレーンHTTP経由で静的な値のハッシュを送信することは、プレーンHTTP経由でパスワードを送信することと同じです。誰でも受動的な観察からそれをつかむことができるので、クライアントの認証はありません。
サーバーの認証がないため、1つのクライアントにアクセスできれば（したがって、静的AESキーを盗むことができます）、任意のクライアントをMITMし、自分のRSAキーを送信し、すべてのトラフィックを読み取り/変更/改ざんすることができます。

RSAキーが使用されるモード/パディングでAESがどのように実装されるか（どのモード、IVがどのように生成されるかなど）については言及しません（パッドなしで使用する場合、別名「教科書RSA」、さらに壊れています）.

これはクレジットカードの処理に使用されているとのことですが、私はPCIの専門家ではありませんが、PCIコンプライアンスに合格しないと確信しています。