なぜ誰かが「二重暗号化」するのでしょうか？
保護されたSSL/TLS接続（つまりHTTPS）を介してサーバーと通信し、すでに安全な接続の上にあるユーザーとサーバーの間で送受信されるメッセージを暗号化するWebサイトまたはモバイルアプリがある場合、不必要な動きをしていますか？または、二重暗号化は一般的な方法ですか？もしそうなら、なぜですか？
珍しいことではありませんが、必須ではないかもしれません。多くの開発者は、HTTPSトラフィックがすでに暗号化されていることを忘れているようです-このWebサイトにクライアント側の暗号化を実装することに関する質問の数を見てください-または、次のような広く知られた問題のために信頼できないと感じています- Lenovo SSL MitM混乱 。
ただし、ほとんどの人はこれによる影響を受けず、TLSv1.2に対する現時点で特に実行可能な攻撃はないため、実際にはそれほど効果はありません。
一方、場合によっては、送信前にデータを暗号化する正当な理由があります。たとえば、ストレージアプリケーションを開発している場合、ユーザーだけが知っているキーを使用してクライアント側のアプリを使用して暗号化することができます。これは、サーバーがデータを復号化できないことを意味します。しかし、それはまだそれを保存することができました。 HTTPS経由で送信することは、攻撃者がクライアントの暗号化データを取得することもできないことを意味しますが、取得したとしても、問題にはなりません。このパターンは、クラウドベースのパスワードマネージャーでよく使用されます。
基本的に、それは防御する対象によって異なります。ただし、SSL/TLSを信頼していない場合でも、（Webアプリケーションの場合）送信している暗号化コードも信頼できない可能性があります。
HTTPSは、メッセージがネットワーク/インターネット経由で転送されている間のみ暗号化を提供します。
メッセージが最終的に処理するクライアントとサーバーの間のある時点でメッセージが仲介者（メッセージキューなど）によって格納または処理される場合、メッセージは中間にある間は暗号化されたままにはなりません。
また、TLS/SSLがサービス境界で終了している場合（ロードバランサーなど）、内部ネットワークでは暗号化されていない可能性があります。これは、たとえば一部の規制環境で高度なセキュリティが必要な場合に問題となる可能性があります。
これらのどちらの場合でも、メッセージレベルの暗号化により、クライアントと最終受信者の間のすべてのポイントでデータが確実に暗号化されます。
@honzeが言ったように、これは多層防御と呼ばれ、システムが部分的に侵害された場合でも保証することを目的としています（たとえば、システムが中間者攻撃を実行してSSL/TLSを侵害したり、静止データを取得するためのメッセージキューの脆弱性）攻撃者は保護されたデータを取得できません。
タイトルの質問について私の経験を共有したいと思います。それは完全な質問自体には実際には関係ありませんが、これは「なぜ誰かが二重に暗号化するのか」という質問に答えます。
過去には、医療提供者（医師、病院など）と保険組織（複数）の間のコミュニケーションを扱う組織で働いていました。ルーターのように振る舞った。
スキーマはおおよそ次のとおりです。
care provider 1 \ / insuring organization 1
care provider 2 ---- router (us) ---- insuring organization 2
care provider 3 / \ insuring organization 3
次の保護がありました。
- エンドツーエンドの暗号化：医療提供者1は、患者情報を保険会社1に送信する必要があります。この情報はプライバシーに敏感であるため、暗号化する必要があります。私たちのレベルでは、保険会社に送信されているデータを知る権利はありません。
- Care-provider-router encryption：ケアプロバイダーは、メタデータとして情報を送信し、それを処理できるようにします。この情報は暗号化する必要があります。契約では、メッセージはネットワーク内でも暗号化する必要があるため、送信される情報のメタデータを知っているサーバーは1つだけであると述べています。いくつかのパイプ（ロードバランサー、ファイアウォールなど）があるため、このレベルでも暗号化が必要です。
- MITM攻撃を回避するためのHTTPS：データを保護する必要があるだけでなく、HTTPメタデータも保護する必要があり、したがってHTTPSも保護する必要があります。
これにより、複数の暗号化レイヤーが必要になる理由が明らかになったと思います。
あなたが正しいです。これは多層防御と呼ばれる多層セキュリティの概念です。
暗号化されたメッセージはエンドツーエンドの暗号化を扱う可能性が高く、SSL/TLSはメタデータの暗号化を扱います。これは便利なパターンです。
HTTPSは転送中に暗号化され、最後に復号化されます。したがって、二重暗号化が必要になる可能性のある明らかな状況は、しないでくださいエンドの1つ（またはおそらく両方！）クリアテキスト。
頭の上から考えることができるいくつかの状況：
ウェブメールプロバイダーを介した暗号化メール。 HTTPS接続でアクセスするGPG暗号化メッセージをGmail経由で送信すると、2回暗号化されます。 gmailに内容を読ませたくないからです。
暗号化されたバックアップサービス。 HTTPSを使用してログイン認証情報が盗まれるのを防ぎたいのですが、バックアップサービスにバックアップの「内部」を見せたくありません。
支払いゲートウェイ。安全な支払いハードウェアトークンと銀行の間で暗号化されたメッセージがを介してユーザーの安全でないデバイスと販売者のサイトを介して送信されることを想像できます。中央のリンクはHTTPSである必要がありますが、それだけでは不十分です。安全でないPCおよび安全性の低い販売者のWebサイトで暗号化する必要があります。
S/MIMEは「トリプルラップ」（sign/encrypt/sign）を提供することに注意してください： https://tools.ietf.org/html/rfc2634 なので、署名を検討する場合暗号化だけでなく、さらに多くの可能性が理にかなっています。
私は追加の理由を挙げたかった：標準化。
セキュリティ上の理由から、アプリケーションに出入りするすべてのデータを暗号化する必要があるアプリケーションがあります。データは一度暗号化されているため、データはhttp（レガシー）接続とhttps（現在）接続の両方を介して流れることが許可されています。 httpsで暗号化せずに実行し、httpで暗号化するバージョンのアプリケーションを作成するよりも、2回暗号化する方がはるかに理にかなっています。
財務データ、医療データ、軍事データ、心理データなどの機密性の高い情報を扱う場合は、ベストプラクティスです。複数の暗号化の基本的な考え方は、権限のないユーザーがデータを取得できないようにすることです。暗号化方法の最初の可能な組み合わせが10億であると仮定します。その上に別の暗号化方法を適用することにより、可能性を1b ^ 3に乗算できます。これは、権限のないユーザーがデータを復号化するのに時間がかかることを必要とします。暗号化はまだ完全ではありませんが、より優れています。
私が働いていた組織の1つでは、複数の暗号化を利用していました。これは、前のフローを簡略化したものです。
- ソフトウェア上のクリアランスについてクライアントとサーバーの両方のデバイスとコンポーネントを監査する
- ストレージ上のデータを暗号化する
- データを圧縮する
- 独自のソフトウェアでデータを暗号化する
- サーバーとの接続を開始
- クライアントとサーバーの両方のデバイスとコンポーネントの接続のクリアランスを監査する
- 圧縮トランスミッション
- 暗号化接続を介してデータを送信します。接続が切断された場合は、プロセス全体を再起動してください。
- ファイルが正常に完了したら、データの整合性を監査します
機密データを含むネットワーク負荷の高い環境を扱っていない場合、これはやりすぎです。
この方法の背後にある戦略により、デバイス、コンポーネント（MAC）、およびIPが確実に認証されます。データの暗号化は標準的な手順であり、HTTPS経由での送信も同様です。一部の組織は、基本的なセキュリティを超えており、接続するためにFreenet、I2P、IPsec/VPN、またはTorを利用するダークネットのようなネットワークも必要とします。暗号化に関係なく、データ圧縮は必要なストレージとネットワークリソースを削減します。ただし、パフォーマンスがRAMまたは処理にオフセットされます。最後に、切断後に接続を再開した理由は、man-in-the-middle経由でデータストリームをハイジャックする方法を発見したためです。 。
究極的には、データを永久に暗号化する完璧な方法はありませんが、データや情報が無関係になるか、データを暗号化する優れた方法を生み出すまで、暗号化に注力してください。
暗号化された接続を介して暗号化されたデータを送信する理由はいくつかあります。
- 接続の暗号化が壊れていても（たとえば、MitM、可能ですがHTTPSに挑戦し、送信されたすべてのデータの傍受につながる）、データはまだ暗号化されています
- hTTPSサーバーは信頼されていない可能性があり、データを別のサーバーに中継する責任があります
- 同様に、HTTPSサーバーは、暗号化されていない接続を介してデータを別のサーバーに中継し、送信前にクライアントにデータを暗号化させることで、HTTPSサーバーの負荷を軽減します。まっすぐ通り抜ける
API難読化
すべての通信がHTTPSを介して暗号化されている場合でも、クライアントはさまざまなデバッグツールを使用して暗号化する前にトラフィックを確認することができます。特に、基盤となるシステムによって提供されるhttpsを備えたブラウザー環境またはアプリを使用する場合。
この場合、静的キーを使用してデータを暗号化できるため、クライアントはトラフィックを簡単に読み取って操作できません。もちろん、これは難読化のみです。キーはクライアントマシンのどこかに（少なくともRAMに）格納する必要があるためですが、ソフトウェアソースコードでは常に難読化されています。ユーザーは、キーを回復し、トラフィックを復号化して要求の操作を読み取るために、かなりの労力を費やす必要があります。
例としては、プレーヤーにハイスコアを送信するWebベースのゲームがあります。
私が正しく理解していれば、Torネットワークは次のように機能します。
アリスはデイブに手紙を書き、それを3回暗号化します。最初にデイブのキーで暗号化し、次にデイブのアドレスを追加し、クレイグのキーでパッケージを暗号化し、クレイグのアドレスを追加してボブのキーでパッケージを暗号化します。
それから彼女はボブに手紙を送り、ボブはそれを解読し、クレイグの住所を見つけて彼に転送します。
クレイグはそれを解読し、デイブの住所を見つけ、彼に転送します。デイブはそれを解読し、手紙は彼のためのものであることがわかります
完全な世界では、アリスとデイブ以外の誰も、デイブが実際にその手紙の受信者であるとは言えません。なぜなら、彼はエミリーの住所を封筒の中に見つけて転送したことになるからです。
2番目のアプリケーションは、秘密鍵と受信者の公開鍵の両方でメッセージを暗号化することです。受信者はあなたの公開鍵と自分の秘密鍵を使ってメッセージを復号化するので、メッセージがあなたからそして彼のためにあるという情報を得ることができます。しかし通常、HMACはメッセージが確かに特定の送信者からのものであり、改ざんされていないことを確認するために使用されます。
マルチレベル暗号化の主な理由は、懸念の分離です。
多くの場合、データのセットは複数のサーバーによって処理される可能性があり、複数の組織によって制御される可能性があります。そのすべてがデータ全体で完全に信頼されているわけではありません。ほとんどの場合、これらの中間サーバーのほとんどはデータの一部のみを処理する必要があるため、データの一部を表示する必要がない場合は、その部分を暗号化できます。あなたは、彼らが持っているキーで暗号化して見る必要があるデータへの中間アクセスと、彼らがさらなる処理のために他のサーバーに渡すことができる暗号化されたブロブを与えます。
最も簡単な例は、GPGおよびTLS暗号化を使用した電子メールです。メール転送エージェント（メールリレー）の主な仕事は、メールをあるホップから次のホップに転送することです。彼らは仕事をするためにメールルーティング情報を見る必要がありますが、メッセージ自体を見る必要はありません。したがって、メール転送エージェントが理解できる1つのキーと、受信者しか理解できない別のキーでメッセージを二重に暗号化します。
別の例は、カレンダー/通知スケジューリングサービスです。カレンダーにイベントを入力し、特定の時間に何かが起こっていることをカレンダーアプリケーションから通知されます。カレンダーは、イベントが何であるか、イベントに関与している人、イベントがどこにあるのかを知る必要がありませんでした。
複数の暗号化の2番目の理由は、暗号化層の1つが破損した場合の保険としてです。 IMO、これははるかに弱い理由です。不必要な追加のレイヤーがすべて実装の複雑さを増し、複雑さがセキュリティの敵であることを考慮する必要があるためです。
これについてはここでは触れていませんが、コメントよりも少し重要だと思います。彼らは perfect forward secrecy に対してそれを行うかもしれません。攻撃者はHTTPS接続の鍵を知らない可能性がありますが、すべてのバイトを記録して何年も保存する可能性があります。次に、彼らはあなたをハッキングしたり、脆弱性を発見したり、後でサーバーの秘密鍵を明らかにするように強要したりして、履歴に戻ってメッセージを復号化します。 HTTPS接続の下で 一時的な一時キー メッセージを暗号化することにより、攻撃者は引き続きメッセージを読み取ることができないか、少なくとも大幅に遅延します。
厳密にはHTTPSの問題ではありませんが、「配信担当者を信じていないため、より多くの手順を使用して匿名性を維持したい」場合に備えて、Torでは一般的に別の二重暗号化の有効な使用例が使用されています。
すべての「配達人」は、エンベロープのみを復号化して、他の配達人を見つけます。この場合の通信は、SOCKSプロキシでカプセル化および暗号化されます。
アルゴリズムと実装の両方に欠陥が存在する可能性が高く、まだ発見されていません。理想的には、これらの欠陥は存在しないはずですが、存在します。
2つの異なるアルゴリズムで暗号化し、そのうちの1つだけに欠陥がある場合でも、問題はなく、データは安全です。最初の層が壊れている場合、攻撃者は暗号文しか取得できません。 2番目のレイヤーが壊れている場合、攻撃者は最初のレイヤーを通過できません。
二重暗号化（または3倍または4倍など）は、すべての卵を1つのバスケットに入れるのを避けるための良い方法です。
PCIコンプライアンスの問題を回避するために、開発者は支払いゲートウェイを使用したいと考え、サードパーティにコンプライアンスの責任を課します。
フォームポストのフィールドはクライアント側で暗号化できるため、開発者は暗号化されていないカードの詳細をシステムに渡す必要がありません（そのため、それらを保存しないよりもさらに進んだステップです）。
特に、これはHTTPSの上にあります。したがって、Webサイトには暗号化されていないデータは表示されず、ユーザーと支払いゲートウェイのみが表示されます。
ブレインツリー支払いゲートウェイの例： https://www.braintreepayments.com/blog/client-side-encryption/