PrivateSkyでデータが表示されないのはなぜですか？

Question

PrivateSkyは、暗号化された「クラウドのような」安全な情報交換を約束するWebサイトです。彼らは、送信者と受信者を除いて、誰もあなたのデータを見ることができないと約束します。昨日テストしたのですが、どうしてそうなるのかわかりません。

私がやったことを段階的に説明しましょう。 2つの電子メールアドレスAとBがあるとします。AからBに暗号化されたメッセージを送信したいので、次のように進めました。

メールアドレスAのPrivateSkyアカウントを作成しました。
Aで受け取ったリンクをクリックして、メールアドレスを確認しました。
PrivateSkyに戻り、AにPINを作成しました。
PrivateSkyにAとしてログインし、暗号化されたメッセージBを送信します（最初にBのPrivateSkyアカウントを作成しません）。
メールアドレスBのPrivateSkyアカウントを作成しました。
Bで受け取ったリンクをクリックして、メールアドレスを確認しました。
PrivateSkyに戻って、私はPIN for Bを作成しました。
Aからの私のメッセージは、BのPrivateSkyアカウントの「受信トレイ」に表示されました。

繰り返しますが、どうすれば私のデータを見ることができなくなりますか？ AからBに直接送信した情報はありません。すべての通信はPrivateSky経由で行われました。また、BはPrivateSkyアカウントを作成する前にメッセージを「受信」したので、暗号化キーをAからBに安全に送信するにはどうすればよいでしょうか。

Rasmus Faber · Accepted Answer

ホワイトペーパーによると、彼らはアイデンティティベースの暗号化スキームである SK-KEM を使用します。これが、暗号化されたメッセージをBに送信するためにBの公開鍵を必要としない理由を説明しています（メールアドレスは公開鍵です）。

通常、IDベースの暗号化は、信頼できるサードパーティに依存しています。したがって、メッセージ自体を復号化できないという彼らの主張は、基本的にハードウェアセキュリティモジュールに相当するものの内部にマスター秘密キーと関連する秘密キージェネレーターを配置したことに基づいています。

Brian Spector · Answer

これはブライアンスペクターです。私は CertiVox のCEOです。

安全な情報交換サービスである PrivateSky についてこのディスカッションを開始していただきありがとうございます。このスレッドに関するインテリジェントなコメントと批判に答えるように最善を尽くします。

次に、統合されたキー管理と2要素認証のしくみについて、順を追って読者に説明できるように最善を尽くします。

ホワイトペーパーを読んでいないこのスレッドのユーザーに、ぜひお読みください。私が書いているものはすべて詳細に記述されており、Webサイトのそのドキュメントで公開されています。しかし、誰も白書を読んでいないので…。

まず、私たちが「嘘をついている」という声明に反駁しましょう。私たちはそうではありません。実際、私たちは自分たちが何をするかについて可能な限り透明性を保つよう努めています。この種の包括的な声明で議論するのは難しいので、そこに行くのではなく（「ジョーンズさん、いつあなたの妻を殴るのをやめたのですか？」）、このスレッドのインテリジェントなポイントを調べてみましょう。少ない。

そのため、ウェブサイトから無料で入手できる MIRACL SDK をオープンソースにしています。 MIRACLはPrivateSkyを強化し、PrivateSkyで使用されているのと同じ暗号化プロセスがMIRACL SDKのライブラリとして利用できるため、コードを確認できます。 MIRACLは世界中の数百の企業で使用されており、制約のある環境向けに最適化された非常に高速な楕円曲線暗号を使用しているというかなりの評判があります。多くの組織から信頼されています。私たちはその信頼を非常に真剣に受け止めています。それは私たちのパンとバターです。

ここでルーカスの発言を修正するには：

おそらく簡単な答えは、そうではありません。

私が正しく読んだ場合、それらは対称暗号化の形式を使用してシステムに認証されたようです。その後、秘密鍵にアクセスしてデータを暗号化できます（秘密鍵はピンで暗号化されています）。

不正解です。最初にそれを片付けましょう。メールアドレスと4桁のPINを使用してPrivateSkyにログインするSkyPinは、楕円曲線に基づいて、認証の2つの要素を使用する認証済みの鍵合意プロトコルです IEEE P1636.3ドラフト標準、Wangのプロトコル、私たちの主な暗号学者、 Dr。 Michael Scottの単純なトークンと4桁のピンを使用したリモートログインのプロトコル楕円曲線双線形ペアリングを使用。

Mikeのプロトコルは2002年の最初の公開以来広範囲にわたって peer reviewed であり、10年間以上の暗号解読に耐えてきたことに注意してください。更新バージョンを公開しましたWangのプロトコルで使用します。

2つの要素のうち、最初の要素はブラウザに保存されている数学トークンであり、認証サービスのドメインにロックされています。2番目の要素はピンです。これは次のように機能します。使用するSkyPin Padは、実際にはメールアドレスのIDで発行されたIDベースの暗号化キーの再構成を実行しています。登録時にこれを発行します。登録プロセス中に、SkyPinパッドは、選択した4桁を使用して、発行されたIBEキーに対して方程式を実行します。このプロセスはローカルで実行されます。これらの4桁が何であるかはわかりません。その時点で、これは「トークン」と呼ばれるものになります。トークンは、セッションストレージ（Cookieではない）ではなく、ブラウザのHTML5ローカルストレージに保存されます。これは認証サービスのドメインにロックされています。

次回ログインすると、SkyPin Padは（TLS経由でDNSSECによって保護されたドメインで）Webサーバーから提供され、ブラウザーでローカルに実行されます。 SkyPin Padは4桁を入力として受け取り、方程式を逆にして、ローカルで実行した登録時に発行したIDベースの暗号化キーを再構成します。これはスコットのプロトコルです。次のステップは、Wangのプロトコルに基づく認証済みの鍵合意プロトコルです。これにより、暗号化されたナンスがサーバーのIDと交換され、個人が相互に認証を試みます。その後、プロトコルの最後で、サーバーと個人の両方が互いに自分自身を識別し、それぞれの側で自由にセッションキーであるAES 128ビットキーを取得します。したがって、用語。認証済みのキー合意プロトコル。

そのため、このシステムは対称鍵を使用してユーザーを認証しません。これは、JavaScriptで実行される楕円曲線暗号に基づく2要素認証システムであり、HTML5互換ブラウザー向けに調整されており、認証済みのキー合意を実行します。

Lucasもこのステートメントでは正しくありません（一般に、公開鍵で復号化せず、公開鍵で署名を検証し、公開鍵で暗号化するLucasに注意してください）。

それはまだ他の人の公開鍵ブラウザサイドで解読されるかもしれません。しかし、再び、誰もが利用可能な公開鍵を持っているので、サーバーからそれをフェッチして、ブラウザで適用するだけです。 – Lucas Kauffman5時間前

それに関連して、Rasmusは次のステートメントで正しいです（ホワイトペーパーを読んでいただきありがとうございます）。

ホワイトペーパーによると、彼らはアイデンティティベースの暗号化スキームであるSK-KEMを使用しています。これが、暗号化されたメッセージをBに送信するためにBの公開鍵を必要としない理由を説明しています（電子メールアドレスは公開鍵です）。

私たちが使用しているSK-KEMのバリアントのような指数反転システムでは、これは実際にはキーカプセル化システムです。これにより、コンテンツ暗号化キーは、システムのグローバルな公開キーの入力を持つプロトコルを使用してカプセル化（つまり、暗号化）されます。受信者のメールアドレス。メッセージは [〜＃〜] eccsi [〜＃〜] プロトコルを使用して、私たちの秘密鍵ジェネレーターから発行されたユーザーの秘密鍵で署名されます。ユーザーは、秘密鍵ジェネレーターから発行された別の秘密鍵を使用して、メッセージを復号化します [〜＃〜] sakke [〜＃〜] プロトコル（SK-KEMの変種）。 SAKKEのすばらしい点は、秘密鍵ジェネレーターを統合する機能も備えていることです。ユーザーが別の秘密鍵ジェネレーターの公開パラメーターにアクセスできる場合、PKG Aの秘密鍵を持つユーザーAは、PKG Bから発行された秘密鍵を持つユーザーBと通信できます。

ECCSIとSAKKEはどちらも MIKEY-SAKKE と呼ばれるIETF情報草案の一部であり、3Gネットワークで音声データと暗号化を提供するために標準化されています。 MIKEY-SAKKEには、マスターキーのローテーション（30日ごと）やパケットアセンブリなどのニュアンスをカバーするPKGの運用に関する厳格なガイドラインがあります。

最近まで、秘密鍵ジェネレータを指数反転システムで配布できないと想定されていました。ありがたいことに、 Smart and others は、このような可能性を可能にするマルチパーティ計算プロトコルを考案しました。その作業をさらに発展させて、Smart and Geislerは、「 Sakai–Kasahara Based Systemsの鍵配布センターの配布」という論文を発表しました。

効果的には、PKGを分散された秘密キージェネレーターまたはD-PKGに分割できます。これの良い点は、初期設定の後、マスターキーが全体としてどこにも存在しないことです。それは3つに分かれています。 3つのノードのうち2つだけが、目的のパーティへの秘密鍵のサーバー共有に使用できる必要があります。マスターノードはオフラインになり、セットアップ後に破棄されます。これを行うためのプロセスを構築していると仮定すると、そのようなシステムの秘密鍵の共有は、要求に応じて動的に作成できます。

Rasmusは次のように述べています。

通常、IDベースの暗号化は、信頼できるサードパーティに依存しています。したがって、メッセージ自体を復号化できないという彼らの主張は、基本的にハードウェアセキュリティモジュールに相当するものの中にマスター秘密キーと関連する秘密キージェネレーターを配置したことに基づいています。

ルーカスは次のように述べています。

はい、彼らはどこかに信頼を置いているようです。彼らは自分でそれを解読することはできませんが、他の誰も偽ることはできないという彼らの主張は

ラスムスは部分的に正しく、ルーカスは正しくありません。これは実際にはいくつかのハードウェアセキュリティモジュールであり、実際には全体としてマスターキーを所有しているものはありません。追加の手順を実行します。D-PKGノードを改ざん防止、改ざん防止、VMの起動時に整合性検証を行い、状態を伝えません（マスターキーの共有と共有を配布するためのコード以外）認証済みリクエスト）。高価なキットを台無しにしないと、D-PKGの共有にアクセスできません。しかし、PKGのシェアを再構成できるとしましょう。

私たちはMIKEY-SAKKE運用ガイドラインに従っているため、これらのD-PKGは1か月間のみ稼働します。つまり、発行されたマスターキーとそれに続く秘密キーは1か月間のみ有効で、母集団全体が毎月ローテーションされます。

PrivateSkyでは、ユーザーは一意のパスフレーズを作成するよう求められます。これは、32バイトの長寿命 [〜＃〜] ecdh [〜＃〜] 秘密鍵（および後続の公開鍵）を作成するために使用され、でも使用できます。 [〜＃〜] ecies [〜＃〜] 設定。ユーザーのECDH公開鍵は私たちのディレクトリに保存されています。 D-PKGには、長期間ではなく毎月のみ有効なECDHキーペアがあります。新しい鍵が発行されると、D-PKG月秘密鍵とユーザーのECDH公開鍵の間にDH秘密鍵が作成され、ユーザー用に新しく発行されたECCSIおよびSAKKE秘密鍵が暗号化されます。これはすべてのユーザーに起こります。これらはユーザーのディレクトリ内に保存されるため、30日間のマスターキーローテーションウィンドウの外で古いメッセージを復号化できます。

ポイントは、マスターキーの共有が使用されている30日間の期間が経過した後、VMが破棄され、HSM内のキーマテリアルが消去されて、最初からやり直すことです。

それでは、一般的な攻撃シナリオの概要を説明しましょう。

30日の時間枠内で、データを復号化する（または、情報要求の召喚状が提供されたらキーを引き渡す）には、次のようにします。

ユニットを2度破壊しないように、FIPS 140-2 Level 3でHSMを2回注意深くハックする必要があります。2つの異なるデータセンターで。

30日間の期間外：

アーカイブされた秘密鍵を復号化するには、AES 256をクラックする必要がありますOR
誰かがメッセージごとにAES 128ビットをクラックする必要がある

あなたはおそらく不思議に思っているでしょう、なぜこれらの人たちはそのようなシステムを構築するためにそんなに長い時間を費やしたのですか？特にこの入場に照らして：

ユーザー1202236は次のように述べています。

明確にしていただきありがとうございます。したがって、ソフトウェア会社を信頼する代わりに、ハードウェア会社を信頼し、ソフトウェア会社が提供されたハードウェアを実際に使用するとします。 PGPと比較すると、かなりの数の人を信頼する必要があるように思えます。

そのとおりです。これはより直接的な方法です。信頼のスケールで、誰もあなたのデータを見ることができないことを100％確実にしたい場合は、PGPまたはPrivateSkyを使用する方が良いでしょうか。回答：PGPなどのシステムを介して独自の秘密鍵を作成する方が信頼モデルとして優れていることは間違いありません。全く問題ありません。

問題は1つだけです。 PGPと現在の最新技術は、一般の人々が一般的に使用するにはあまりにも難しいです。このボード上の人々はあなたを気にしません。しかし、私は私の娘、または彼女の友人、または私の両親を意味します。

PrivateSkyでは、PIN、パスフレーズ、電子メールアドレスを使用して、2要素認証をボーナスとして使用して、ユーザーに近づくことができます。そして、あなたは何も学ぶ必要はありません。 PrivateSkyを使用するために、他のWebプロパティと何もする必要はありません。それが私たちがそれを構築した理由です。

CertiVoxの人々は、インターネットを介して何かをやり取りしたいからといって、政府、NSA、Dropbox、Google、その他のメディア企業が私の家族の情報を利用したり、これまでで最大のデータマイニング詐欺で自分の情報を入手したりする権利を与えられないと信じています人類に犯された。

ビジネスの観点から見ると、私たちのアーキテクチャは次のことも実現します：当局からの情報の要求に応えます。 Saasのビジネスを運営しているとき、それは現実の事実です。ありがたいことに、英国とEUには、これに関する正当な手続きと法律があります。コンプライアンスの方法、およびコンプライアンスの範囲を証明する能力は、開発するアーキテクチャにかかっています。私たちがあなたのデータに平文でアクセスできる場合、それを裏返す必要があります。そうでない場合でも、それを裏返す必要があります。しかし、私たちが引き渡すものが暗号化されていて、鍵を所有していない場合、データは（暗号化されている）何が良いのでしょうか。情報の要求に応じることは、若い企業にとって本当に、非常に費用がかかります。このようなリクエストのターゲットにならないことは、競争力のあるエッジです。

それが私を次のポイントに導きます。 CertiVoxのチームは、私たちのビジネスモデルがデータを表示しないことに依存している安全な情報交換サービスの市場があることに賭けています。プライバシーの侵害を懸念しているが、それについて何かを行うための技術的な専門知識を持っていない人々や組織は、世の中に十分にあると私たちは信じています。 Dropboxは、重複を排除するためにデータを確認する必要があります。 Googleが広告を配信するには、データを確認する必要があります。私たちはどちらもしませんし、するつもりもありません。

そのため、まもなくOWN分散秘密鍵ジェネレーターを実行する機能を紹介し、これらをSAKKEフェデレーション機能を介してシステムに登録して、ループから完全に抜け出します。ユーザーの母集団を制御し、マスターキーを自由にローテーションしたり、ユーザーを取り消したりすることができます。これにより、PGPと同等の信頼モデルが得られます。

最後に、統合された鍵管理システムが機能する手順を見ていきましょう。これをシークレットキーと呼びます。以下の説明の視覚的な図である情報グラフィックPDF をダウンロードできます。

メッセージを暗号化して署名するには：

アリスは彼女のスカイピンとメールアドレスでPrivateSkyにログインします。 2要素認証済みのキー合意プロトコルは、ブラウザー側と認証サーバー側で使用するAES 128ビットキーを生成します。
認証サーバーはAESキーを「ブラックボックス」であるD-PKGノードに渡します。
D-PKGノードは、アリスのECCSIキーの共有を組み立て、AESキーを使用してこれらを暗号化します。
アリスは暗号化されたECCSIキー（共有）を受け取り、AESキーで共有を復号化し、共有からECCSIキーを組み立て、準備が整います。
アリスはメッセージをボブに書き込み、コンテンツ暗号化キーと呼ばれるAESキーでメッセージを暗号化します。
アリスは、グローバル公開キーとボブの電子メールアドレスを入力してコンテンツ暗号化キーをカプセル化し、暗号化/カプセル化されたキーをメッセージに追加します。
アリスは彼女のECCSIキーでメッセージに署名します。

メッセージを復号化して確認するには：

ボブは自分のスカイピンとメールアドレスでPrivateSkyにログインします。 2要素認証済みのキー合意プロトコルは、ブラウザー側と認証サーバー側で使用するAES 128ビットキーを生成します。
認証サーバーはAESキーを「ブラックボックス」であるD-PKGノードに渡します。
D-PKGノードは、ボブのSAKKE秘密鍵の共有を組み立て、これらをAES鍵で暗号化します。
ボブは、暗号化されたSAKKE秘密鍵（共有）を受け取り、AESセッションキーで共有を復号化し、SAKKE秘密鍵を組み立て、準備が整います。
ボブは、カプセル化されたコンテンツ暗号化キーを含むメッセージを自分のポータルで受信します。
ボブはアリスの署名を確認し、SAKKE秘密鍵でコンテンツ暗号化キーのカプセル化を解除します。
ボブはコンテンツ暗号化キーを使用してメッセージを復号化します。

だからあなたはそれを持っています。数学、実装、または私たちの意図に反論することができますが、うまくいけば、3つすべてを明確にしました。

最後までお読みいただき、ありがとうございました PrivateSkyにサインアップ！このすべてが実際に動作しているのがわかります。

ブライアン

Brian Spector · Answer

ブライアンキャンベルの質問に答えるには、次のように説明します。

あなたのユーザーが調査の対象であった場合、政府はD-PKGインスタンスの30日間のローテーションを禁止し、科学捜査のためにそれらを引き渡すように要求する場合があります。

それは起こるかもしれませんが、EUとイギリスでは非常にまれです。他の住所ではそれほどありそうにありません。また、前述したように、これらはHSM内のコードブロックを実行し忘れているため、マスターシークレット全体でさえも状態を伝達せず、HSMがFIPS 140に検証されているため-2レベル3、それはクラックするのがかなり難しいナッツになります。さらに、ローテーションを行わないようにすることは、英国でのコンピューターの誤用行為の違反となる可能性があるため、それが発生した場合、少なくともそれは素晴らしいことになります法廷。

リソースの豊富な政府は、HSMをバイパスして秘密キーを復元できる場合があります。それを防ぐために何かしますか？

詳細を教えてください。私も含めて、チームの私たちの多くは、営利目的のHSMベンダーのために幅広く働いてきました。これが技術的にどのように適切に製造されたHSMでレベル3程度に達成されるかについては、私たちは知りません。あなたが詳細を知っているなら、そう言ってください。

秘密鍵がエスクローされ、AES-256ビットの鍵で保護されている場合、作成された可能性があるのは、AES 256ビットに依存しています。それがひび割れている場合、PrivateSkyよりも大きな問題があります。

また、復号化はJavaScriptでクライアント側で実行されます。悪意のあるJavaScriptが（あなた、XSS攻撃、またはルート証明書を手に入れてWebサイトのMITMを手にした人によって）注入され、ユーザーの秘密キーを盗むのを防ぐにはどうすればよいですか

まず、プロトコルでは証明書を使用しません。これは certificateless cryptography と呼ばれます。（私たちはwikiの記事で説明されているのと同じシステムを使用していませんが、タイプ1および2の敵対者に対して耐性があると信じています）。サーバー側のTLS証明書を使用して、セキュリティで保護されたポータルでMITMを防止し、DNSSECでドメインを保護して、キャッシュポイズニングを防止します。しかし、フロントオブハウス認証ソリューションであるSkyPinは、実際にはTLSがなくても機能します（選択した場合）。ただし、DNSSECがないと機能しません。認証済みの鍵合意プロトコルは、Diffie-Hellman鍵合意セッションが確立されたときに、大きな素数を毎日クリア（SSL/TLS）で取引するプロトコルと同じであるため、DNSSECははるかに重要なコンポーネントです。これは、SSL/TLSセッションを確立する方法として認められている方法の1つです。魔法のように聞こえます。サーバーとクライアントの間で大きな素数を平文でやり取りしているので、中間にいる男性でさえ、プロトコルの終わりにセッションキーを知ることはありません。これがSkyPinが行っていることです（非常に高いレベルで）。

そのため、認証プロセスはSSL/TLS、さらに重要なのはDNSSECによって保護されているため、説明している内容は可能ですが、実際にはリモートであるように感じます。あなたが言及したことの中で、ユーザーが侵害される可能性が最も高い方法は次のとおりです。

悪意のあるJavaScript/XSS攻撃

悪意のあるブラウザーのプラグインがあり、画面記録を行っていたホストマルウェアがあった場合、これはかなり簡単に発生します。ブラウザプラグインが実際にブラウザを攻撃して、セッションストレージからアイテムを盗み（ブラウザへの壊滅的な攻撃）、ドメインにロックしないようにし、かつホストコンピュータがマルウェアに感染していて、画面では、攻撃者がブラウザのストレージからSkyTokenを盗み、あなたのPIN入力を記録します（このシナリオを緩和するための手順は既に講じていますが）、そしてどういうわけか、理論的には可能です。同じ攻撃で、ピンを別のブラウザーに再挿入し、別のコンピューターであなたになりすまして認証済みの鍵合意プロトコルを実行し、アカウントにアクセスします。これらの両方のことは、知らないうちに起こる必要があることに注意してください。少なくともホストアンチウイルスを実行しているが可能であれば、これは難しい注文です。また、ログインプロセスで詐欺のスクリーニングをバイパスする必要があります。つまり、攻撃者はあなたのPIN =/Peoriaとsでマシンからトークンを取得すぐに中国からサービスにログインします。特にジオロケーションをスクリーニングします。

当社のTLS証明書ベンダーのルート証明書が危険にさらされており、PrivateSkyを考えている別のサイトを閲覧しています。

残念ながら、最近このような WAY TOO MANY と報告された事件がありました。これは私たちが心配することであり、SkyPinを実装したのはこのためです。このセキュリティで保護されたポータルにユーザー名とパスワードでログインするだけで、ドメインにDNSSECがない場合、昨年と同じ攻撃に対して脆弱になります Googleは革命的な警備員の好意によります昨年。

SkyPinプロンプトが表示されない限り、PrivateSkyにログインしないでください。上記で概説した攻撃の逆のように、この攻撃を阻止するには、攻撃者がDNSSECプロトコルを侵害し、TLS証明書ベンダーのルート証明書を侵害し、サーバーに侵入してMITM攻撃を実行して、秘密鍵は動的に生成されて送信されます。最初の回答で以前に述べたように（また、ホワイトペーパーにもあります）、秘密キーの共有自体は、D-PKGで暗号化されます。セッションキーは、 SkyPinは、当社の認証サービスを使用した鍵合意プロトコルを認証しました。実際に私たちを認証し、ホスト上のマルウェアを介してブラウザーからセッションキーを盗む必要があります。また、TLSベンダーのルート証明書とDNSSECを侵害することも意味します。それは不可能だとは言わないが、それはいくつかの深刻な、深刻な国家支援のリソースを必要とするでしょう。

CertiVox/PrivateSkyによって挿入された悪意のあるJavaScript

私たちもこれについて心配しています。私は内部統制プロセスが何であるかを明らかにするつもりはありませんが、私たちはそれについてかなり勤勉です。ただし、前述のように、私たちのビジネスの「賭け」は、主な差別化要因がデータを表示しないことが私たちのようなサービスの市場であると考えてサイコロを振るということです。したがって、このシナリオでは、コードを悪用している内部の不正な従業員です。可能ですが、私たちが実施しているセーフガードを考慮することはほとんどありません。

Brian Spector · Answer

私がBrian Campbellに提供した回答の更新として、2人のセキュリティ研究者であり、その中の2人のセキュリティ研究者、Aldo Cortesi（素晴らしい情報セキュリティプロ）は、PrivateSky ISがSSL証明書ベンダーの壊滅的な侵害に対して脆弱であることを指摘しました。

アルドが言ったように（アルド、私があなたに引用しても構わないことを願っています）、

「…PrivateSkyは、サーバーが悪意のある場合、またはSSL証明書が侵害された場合、攻撃に耐性がありません…」

SSL証明書攻撃がどのように機能するかを以下に示します（これはかなり単純化されていますが、一般的には正しいです）。

政府/州が後援する事業体は、SSLセッションを保護するために使用する証明書ベンダー（GlobalsignまたはVerisign）を最初に侵害する必要があります（これは些細なことではありません。これらのベンダーのDiginotar攻撃によりセキュリティがアップグレードされたと思います）。
政府機関/州が支援する事業体は、PrivateSkyとユーザー間のネットワーク接続にタップを設定し、攻撃の被害者を選択した後にMITM攻撃を容易にします。
ユーザーがログインすると、ユーザーのブラウザーがPrivateSkyにメッセージのリクエストを送信し、攻撃者は悪意のあるJavaScript行を応答に挿入します。
次に、この悪意のあるJavaScriptはメッセージを復号化し、メッセージの内容をクエリ文字列ログファイルに記録していたサーバーにコンテンツをajax呼び出しで送信します。

アルドは言います、

「これについて2つのことを言う必要があります。まず、これはPrivateSkyの価値命題の中心にあるとは限りません。製品is従来のサービスを悩ませる他のさまざまな問題に耐性があります-妥協、クライアント情報を開示するという法的圧力などの場合に大量のユーザーデータが漏洩するなど。

第二に、悪意のあるサーバーとSSLインターセプトに耐性のある100％Webベースの製品を作成することは現時点では非現実的であり、アプリ自体に「ブラウザー拡張」などの「外部」が必要であり、ユーザーの利便性のコスト。 cryp.srを作成したとき、私はこの問題に正確に取り組みたいと思っていました。サーバーからのデータの「パッケージ」の整合性を、ブラウザー拡張機能で暗号ハッシュを使用して確認し、有効なハッシュを完全に独立したチャネル。私がこれについて書いた（長い）ブログ投稿をここで参照してください：

http://corte.si/posts/security/hostproof.html

http://corte.si/posts/security/crypsr.html

この問題を解決するためにブラウザのみの方法があったら、それは確かに画期的なことでしょう。しかし、これを行う方法はないと私はかなり確信しています。

SSL証明書の信頼システムが壊れていることはわかっていますが、アプリケーションレベルでこれに対抗することはお勧めできません。セキュリティを意識したクライアントがこれを修正するために使用できる他のソリューションがあります。 1つの可能性は、クライアント側の証明書のピン留めです。この場合、ユーザーは、証明書を有効にするために特定の公開鍵で署名する必要があることを指定します。 Chromeはこれを初期サポートしており、STSモジュールを通じてすべてのGoogleプロパティに使用されます。

http://dev.chromium.org/sts

別の可能性は、非常に優れたセキュリティ研究者であるMoxieによって最近リリースされた代替の証明書検証スキームであるConvergenceです。

http://convergence.io/

Convergenceが成功するかどうかは明らかではありませんが、従来のSSL署名信頼のWebとは完全に独立して、SSLインターセプトに対して優れた堅牢な保護を提供します。したがって、私の基本的なポイントは、Certivoxが行うことは何でも、HTTPアプリレベルでのSSLインターセプトの可能性を修復または補償することはおそらく価値がないということです。

ここで注意しなければならないもう1つのことは、ここで取り上げている攻撃の種類の相対的な確率です。現時点では、有効に見える悪意のあるSSL証明書を作成できるエンティティはごくわずかです。基本的には、信頼できる署名者を侵害した諜報機関や他の数人の人々について取り扱っています。これを行う能力は嫉妬深く守られ、非常に控えめに使用されます。

本質的に、このようなSSL証明書が傍受に使用されていることを検出できます。これは、署名IDが必然的に変更されるためです（これは、証明書のピン留めによって検出されます）。したがって、それらを使用すると、特定の個人または組織に対して、非常に小規模で、非常に的を絞った方法で使用されます。この手順から逸脱し、偽の証明書が大規模に素人っぽく使用されると、必然的に検出され、非常に貴重な署名資産が台無しになります（イランによる最近の行動、およびその後のDiginotarハックの発見を参照）。そのため、これと比較して、Certivoxサーバーの侵害は1桁、クライアントのデスクトップ環境の侵害は何桁も発生する可能性が高くなります。悪意のある証明書について心配する必要があるのは、これらの機能を持つタイプの人々の標的となる可能性がある「特別な」クライアントだけです。これらの人々は、上で述べたSSLレベルのソリューションを必ず使用する必要があります。他の誰もがリラックスできます。」

これは、モバイルクライアントを間もなく導入することを言及する絶好の機会だと思います。

Aldoが言い続けているように、「IOSアプリは証明書のピン留めを簡単に組み込むことができ、開発環境は注入の問題の影響を受けにくく、実行環境ははるかに安全であり、実行可能コードをダウンロードする必要はありません。 Certivoxサーバー。また、アプリケーションはCertivoxサーバーとは別に配布され、別個の認証および検証プロセス（この場合はAppleのアプリストア）を使用するため、鶏と卵の問題も解決します。このようなIOSアプリは、Certivoxによる現時点での強力な主張（実際にはCertivoxを含む）がクライアントデータを読み取ることができないという（いくつかの条件付きで）本当に満たすことができました。」

前の文でAldoが言及しているのは、1人のセキュリティ研究者がマーケティング資料のコンテキストで「できない」という単語の使用に関して大きな問題を抱えているということです（私たちが遭遇したこのような唯一の意見だと言っておくべきです））、私たちがシステムを悪意のある悪意のある方法で操作した場合に顧客のデータを「見る」ことができるWebアプリケーションであることを意図して、意図的に「誤解を招く」と非難しました。ずっと言ったように、私たちはこの方法で操作しておらず、その結果、潜在的なアクセスを提供するような方法でユーザーの暗号化データを保存していません（そのため、Wordの使用は「できない」）。。

このスレッドで指摘したように、PrivateSkyを実行するユーザーは、運用中に悪意のある、または悪意のある方法で行動しないように信頼する必要があります。これは、一部の人々が拡大するには不適切な量の信頼になる可能性があります。 PGP/SMIMEまたはその他のシステムで、最初の秘密鍵と公開鍵のペアを作成し、その鍵が完全に管理下にあるため、この点で依然として最適です（ただし、平均的なユーザーが頭を回すのは困難です）。

この状況を詳しく説明し、コメント、提案、フィードバックを求める別のブログ/スレッドを開始します。取締役会の皆様のご意見をお待ちしておりますので、どうぞよろしくお願いいたします。

最後に、別の点でこのスレッドでいくつかコメントを追加したいです。

最初に、モバイルおよびデスクトップクライアントが導入され、Webアプリが単なる便利なUIである場合、クライアントデータのこの潜在的なリークを閉じるためにWebアプリへのアクセスを遮断する機能を顧客に提供する必要があります。インストールされているクライアントの1つを介してメッセージとファイルが交換されていることを想定した、証明書ベンダーの壊滅的な妥協点。この種の妥協点はありませんか？ XSS攻撃（上記で既に投稿した）でさえ、ユーザーデータをリークする可能性があることにも注意してください（ただし、これは私たちのメジャーリーグの問題です）。この証明書の侵害攻撃で最も心配しているのは、完全にPrivateSkyの制御外にあることですが、リモートであり、州がスポンサーするリソースを必要とします。

次に、この抜け穴をふさぐコンテキストで、どのクライアントを最初に見たいですか？
•Mac OS X•iOS•Android•Windows•Linux•Windows Phone

注：最初のクライアントは、まもなく導入されるOutlookプラグインです。

最後に、PrivateSkyシステム上のすべてのユーザーが独自の指数反転分散マスターキーサーバーを実行できる機能を間もなく導入することも指摘しておきます。これにより、PrivateSkyポータルへのアクセスが制限され、メッセージが暗号化され、インストールされているクライアントでローカルに復号化されます。あなたはその時点で自分を信頼する必要があるだけです。

乾杯、ブライアン