web-dev-qa-db-ja.com

Javascriptでエンドツーエンドの暗号化は可能ですか?

私は現在、暗号化、つまりセキュリティの観点から(peer2peer)メッセージングクライアントを作成する可能性を研究しています。このアプリケーションは、Webテクノロジーに基づいています(可能な場合)。

私の質問は次のとおりです。javascript(client&node.js/peer.js)のみでエンドツーエンドの暗号化は可能ですか?はいの場合:HMAC(RSA)の種類の暗号化技術を調べるのは正しいですか?私はすでにこれらのライブラリがどのように機能するかを少し理解しようとしましたが、今のところ運がありません:)

libは面白いと思いますが、(このユースケースでは)実装方法を(完全に)理解しておらず、わかりません。

必要に応じて、さらに詳しく説明することができます。

更新:アプリケーションはモバイルアプリケーションになります。 Webテクノロジーの使用は、少し概念実証です。

14
Dominique

現在、セキュリティの実装を検討しています。これらのライブラリの背後にあるセキュリティモデルと暗号化を理解していない場合、ソリューションは-確実に-安全ではありません。

Artjomは、ピアツーピア暗号化の場合、おそらく両方の当事者の認証が必要であることを示しています。これは通常のSSL/TLSでは提供されないため、クライアント認証が必要になります。ただし、クライアントとサーバーの認証では、trustを確立する必要があります。通常のブラウザでは、これは内部証明書ストアによって提供されます。ただし、クライアントを信頼するのは非常に困難です。

他のすべてのもの(RSAがHMACではない方法など)は実装の詳細です。ただし、現時点では実装しないでくださいセキュリティに関連するもの。まず、ユースケース、脅威シナリオ、およびプロトコル設計に焦点を当てます。

3
Maarten Bodewes

エンドツーエンド暗号化の目標は、中央サーバーが不正行為をしている場合でも、ユーザーが通信のセキュリティを確実にできるようにすることです。解決する必要がある2つの主な課題があります。

(1)ユーザーは、自分が通信していると思う相手と通信していることを100%確信している必要があります。これは、man-in-the-middle(MITM)攻撃を防ぐためです。この場合、man-in-the-middleは、サーバー自体を含むすべての人になります(例: Apple iMessageにはこの弱点があります )。

(2)クライアント側のコードが不正行為をしていないことを100%確認する必要があります。たとえば、実際に相手の公開鍵を使用してデータを暗号化しているのか、それとも単に平文で別の場所に送信して、そこから暗号化しているのか。サーバーにアクセスできる人は誰でもいつでもJavaScriptを交換できることを考えると、これは大きな課題です。

どちらの問題も解決できるようです。

(1)の場合、ユーザーは PGP/GPG で行われるように、公開鍵を帯域外で検証できます(残念ながら、多くの人がこの手順をスキップしますが、真のエンドツーエンドのセキュリティを実現するには、 it)または keybase.io

(2)の場合、MITのグループは マイラー 設計でこれを解決したと主張しています。セクション6を参照してください。研究者はセキュリティの問題を発見したことを述べておく必要があります。マイラーですが、私の知る限り、クライアント側のコードの整合性に対するソリューションは妥協されていません。

したがって、理論的には、エンドツーエンド暗号化は完全にJavaScriptで実行できます(使用されるサーバー言語はそれほど重要ではありません)。実際には...それは簡単ではありません。

2
TheGreatContini

せいぜい、WebブラウザでJavascriptを使用して「斬新な」エンドツーエンド暗号化を行うことができます。つまり、エンドツーエンドの暗号化のように見えますが、実装は暗号学者によって嘲笑される可能性があります。

主な理由は、フロントエンドでデータを暗号化するためにどのパズルを解いても、クライアントは最終的にサーバーが送信する内容に依存するためです。

必読:

2
Snowman