情報保護

昨今、いろんな情報流出が問題になってきている。

基本的にはすべてインターネットを経由した情報流失ではあるが、いかんせん皆さんの意識が低すぎるように思える。確かに、ネットでの通信、特にLINEのようなメッセンジャー系の通信を使ってる人からすると『聞かれてもマズイような内容なんかないよ』とかいう軽い答えが返ってくる可能性も高いと思う。けど、ホントにそれでいいのかな？そのメッセージの中には個人情報が含まれてない？自分の情報だけじゃない、他人の情報を伝える上でそういうメッセンジャーツールを使うときにはその情報を漏らした側の責任も出てくる事になる。

それではどのように情報保護を行っていけばいいのか？

 

秘匿通信

昨今のインターネットでは通信を秘匿化するアプリがあるという事実を知って頂きたい。

先日、元CIA / NSA のエドワード・スノーデン氏も『暗号化されていないテキストを送るな、代わりにRedPhoneやSilent Circleのようなサービスを使え。』と言っていたように、暗号化して通話や通信を秘匿化することが出来るものが数種ある。

基本的にMicrosoft、Yahoo!、Google、Facebook、PalTalk、YouTube、Skype、AOL、Apple などが米CIAやNSAの通信傍受に協力させられていたということは以前から指摘されていたらしい。つまり、これらの企業から提供されているサービスは基本的に通信傍受されておりプライバシーは無いと考えた方が良い。

また、ここに書かれてはいないが、DropboxやGoogle Drive、boxなどのいわゆるクラウドストレージや日本で流行っているLINEやkakaoなども同様に情報が抜き取られているといっても間違いはないだろう。

つまりざっくりというと『大手サービスやメジャーなサービスを使う以上はプライバシーは存在しない』ということである。

そんな中、安心安全なメッセージングが出来るのはどのアプリか？という問いに対するアプリの検査を行ったところがある。　Electronic Frontier Foundation (電子フロンティア財団:EFF) のプロジェクトである A Project of the Electronic Frontier Foundation による Secure Messaging Scorecar という興味深いレポートである。

その中でも検査７項目で満点の高スコアをたたき出したアプリが以下の8つである。

• ChatSecure + Orbot
• CryptoCat
• Off-The-Record Messaging for Windows (Pidgin)
• Signal / RedPhone
• Silent Phone
• Silent TextTelegram (secret chats)
• TextSecure

この中で、Text とか Chat とかの文字がある分がテキスト通信用、phoneとあるのが通話用と考えて差し支えない。またこの検査は昨年のものであるが、今現在では

Signal / RedPhone  +  TextSecure  →  Signal Private Messenger

と言う風に統合されたものもある。

いずれにしてもここに挙げられていないアプリは何らかのプライバシーに関する不安要素があるということであり、利用に関してはOWN RISKである。

 

検査方法

以下は検査方法に関する原文である。

Methodology

Here are the criteria we looked at in assessing the security of various communication tools.

1. Is your communication encrypted in transit?

This criterion requires that all user communications are encrypted along all the links in the communication path. Note that we are not requiring encryption of data that is transmitted on a company network, though that is ideal. We do not require that metadata (such as user names or addresses) is encrypted.

2. Is your communication encrypted with a key the provider doesn't have access to?

This criterion requires that all user communications are end-to-end encrypted. This means the keys necessary to decrypt messages must be generated and stored at the endpoints (i.e. by users, not by servers). The keys should never leave endpoints except with explicit user action, such as to backup a key or synchronize keys between two devices. It is fine if users' public keys are exchanged using a centralized server.

3. Can you independently verify your correspondent's identity?

This criterion requires that a built-in method exists for users to verify the identity of correspondents they are speaking with and the integrity of the channel, even if the service provider or other third parties are compromised. Two acceptable solutions are:

An interface for users to view the fingerprint (hash) of their correspondent's public keys as well as their own, which users can verify manually or out-of-band.

A key exchange protocol with a short-authentication-string comparison, such as the Socialist Millionaire's protocol.

Other solutions are possible, but any solution must verify a binding between users and the cryptographic channel which has been set up. For the scorecard, we are simply requiring that a mechanism is implemented and not evaluating the usability and security of that mechanism.

4. Are past communications secure if your keys are stolen?

This criterion requires that the app provide forward secrecy, that is, all communications must be encrypted with ephemeral keys which are routinely deleted (along with the random values used to derive them). It is imperative that these keys cannot be reconstructed after the fact by anybody even given access to both parties' long-term private keys, ensuring that if users choose to delete their local copies of correspondence, they are permanently deleted. Note that this criterion requires criterion 2, end-to-end encryption.

Note: For this phase of the campaign, we accept a hybrid forward-secrecy approach with forward secrecy on the transport layer (for example through TLS with a Diffie-Hellman cipher suite) and non-forward-secret end-to-end encryption, plus an explicit guarantee that ciphertexts are not logged by the provider. This is a compromise as it requires trusting the provider not to log ciphertexts, but we prefer this setup to having no forward secrecy at all.

5. Is the code open to independent review?

This criterion requires that sufficient source-code has been published that a compatible implementation can be independently compiled. Although it is preferable, we do not require the code to be released under any specific free/open source license. We only require that all code which could affect the communication and encryption performed by the client is available for review in order to detect bugs, back doors, and structural problems. Note: when tools are provided by an operating system vendor, we only require code for the tool and not the entire OS. This is a compromise, but the task of securing OSes and updates to OSes is beyond the scope of this project.

6. Is the crypto design well-documented?

This criterion requires clear and detailed explanations of the cryptography used by the application. Preferably this should take the form of a white-paper written for review by an audience of professional cryptographers. This must provide answers to the following questions:

Which algorithms and parameters (such as key sizes or elliptic curve groups) are used in every step of the encryption and authentication process

How keys are generated, stored, and exchanged between users

The life-cycle of keys and the process for users to change or revoke their key

A clear statement of the properties and protections the software aims to provide (implicitly, this tends to also provide a threat model, though it's good to have an explicit threat model too). This should also include a clear statement of scenarios in which the protocol is not secure.

7. Has there been an independent security audit?

This criterion requires an independent security review has been performed within the 12 months prior to evaluation. This review must cover both the design and the implementation of the app and must be performed by a named auditing party that is independent of the tool's main development team. Audits by an independent security team within a large organization are sufficient. Recognizing that unpublished audits can be valuable, we do not require that the results of the audit have been made public, only that a named party is willing to verify that the audit took place.

We've discussed this criterion in depth in a Deeplinks post: What Makes a Good Security Audit?

これをGoogle翻訳で機械翻訳にかけてみた(笑)

方法論

ここでは、さまざまなコミュニケーションツールのセキュリティを評価する際に見た基準があります。

1.あなたの通信はトランジットで暗号化されていますか？

この基準は、すべてのユーザーの通信は、通信経路のすべてのリンクに沿って暗号化されている必要があります。我々はそれが理想的ですが、会社のネットワーク上で送信されるデータの暗号化を必要としないことに注意してください。我々は暗号化されている（例えば、ユーザ名やアドレスなど）そのメタデータを必要としません。

2.あなたのコミュニケーションは、プロバイダがアクセスを持っていない鍵で暗号化されていますか？

この基準は、すべてのユーザーの通信は、エンドツーエンドの暗号化されていることが必要です。これは、メッセージを解読するために必要なキーが生成され、（いないサーバーでは、ユーザーによって）エンドポイントで保存されなければならないことを意味します。キーは、バックアップキーのように、明示的なユーザアクションを除いてエンドポイントを残さないか、2つのデバイス間でキーを同期ありません。ユーザーの公開鍵は、中央サーバを使用して交換されている場合は問題ありません。

3.あなたは独立して、あなたの特派の身元を確認することはできますか？

この基準は、ユーザーがサービスプロバイダまたはその他の第三者が侵害されたとしても、彼らが話している特派員のアイデンティティとチャネルの完全性を検証するための組み込みメソッドが存在することが必要です。二つの許容可能な解決策は以下のとおりです。

ユーザーは、ユーザーが手動またはアウトオブバンド確認することができ、自分自身だけでなく、彼らの通信員の公開鍵のフィンガープリント（ハッシュ）を表示するためのインターフェイス。

このような社会主義百万長者のプロトコルとしてショート認証文字列の比較、と鍵交換プロトコル。

他の解決法も可能ですが、すべてのソリューションは、ユーザーおよび設定されている暗号化チャネル間の結合を確認する必要があります。スコアカードのために、私たちは単にメカニズムが実装されていることを要求し、そのメカニズムの有用性と安全性を評価されていません。

あなたの鍵が盗まれている場合、過去の通信は、セキュア4.ていますか？

この基準は、アプリは、すべての通信が日常的に（それらを導出するために使用されるランダムな値と一緒に）削除される一時的な鍵で暗号化されなければならない、つまり、前進の秘密保持を提供する必要があります。それは誰でも事実があっても、ユーザーが対応のローカルコピーを削除することを選択した場合、それらが完全に削除されていることを確認して、双方の長期の秘密鍵へのアクセス権を与えられた後に、これらのキーを再構成することができないことが肝要です。この基準は基準2、エンドツーエンドの暗号化が必要なことに注意してください。

注：キャンペーンのこの段階では、我々は、（Diffie-Hellman暗号スイートを使用し、TLSを介して例えば）輸送層の上に前進の秘密保持と非前進秘密エンドツーエンドの暗号化とのハイブリッドフォワード秘密のアプローチを受け入れます暗号文は、プロバイダによってログに記録されていない明示的な保証をプラス。それは暗号文をログに記録しないプロバイダを信頼する必要があり、これは妥協案ですが、私たちはまったく前進の秘密保持を持たないこの設定を好みます。

5.コードは独立したレビューに公開されていますか？

この基準は、十分なソース・コードが互換性の実装では、独立してコンパイルすることができますことを公開されていることが必要です。それは好ましいが、私たちは、特定のフリー/オープンソースライセンスの下でリリースされるコードを必要としません。私たちは、クライアントが行う通信と暗号化に影響を与える可能性があるすべてのコードは、バグ、バックドア、および構造的な問題を検出するためにレビュー用に利用可能であることが必要です。注意：ツールは、オペレーティング・システム・ベンダーによって提供されているとき、我々は唯一のツール全体ではなく、OSのコードを必要とします。これは妥協案ですが、OSのにOSや更新を確保する作業は、このプロジェクトの範囲を超えています。

6.暗号設計が十分に立証されていますか？

この基準は、アプリケーションで使用される暗号化の明確かつ詳細な説明を必要とします。好ましくは、これはプロの暗号の聴衆によってレビューのために書かれたホワイトペーパーの形を取る必要があります。これは、次の質問に対する答えを提供する必要があります。

どのアルゴリズムと（そのようなキーのサイズや楕円曲線グループなど）のパラメータは、暗号化と認証プロセスのあらゆる段階で使用されています

どのキーは、生成された格納され、ユーザ間で交換されます

鍵のライフサイクルと、ユーザーが自分のキーを変更し、又は取り消す旨のためのプロセス

特性の明確な声明とソフトウェアを保護（それはあまりにも明白な脅威モデルを持って良いことだけれども、暗黙的に、これは、また、脅威モデルを提供する傾向がある）を提供することを目的とします。これはまた、プロトコルはセキュリティで保護されていないシナリオの明確な声明を含める必要があります。

7.独立したセキュリティ監査が行われていますか？

この基準は、独立したセキュリティレビューは評価の前に12カ月以内に行われている必要があります。このレビューはデザインやアプリの実装の両方をカバーしなければならないし、ツールの主な開発チームから独立しているという名前の監査当事者によって行われなければなりません。大規模な組織内の独立したセキュリティチームによる監査が十分です。未発表の監査は貴重であることを認識し、我々は、名前のパーティは、監査が行われたことを検証する意思があることだけが、監査の結果が公表されていることを必要としません。

私たちは、ディープリンクの記事で詳しくこの基準を説明しました：何が良いセキュリティ監査を行いますか？

Signal Private Messenger

これは通話と通信を統合的に行えるアプリである。自分が個人的にこのアプリを推す理由は以下の通りである。

• フリーソフトである。
• オープンソースである。
• 通話とテキスト、画像、ファイルすべてに対応する。
• AndroidとiOSの両方に対応している。
• IDという概念が存在せず、ベースは電話番号である。
• アプリ専用の連絡先は存在せず、スマートフォンの電話帳を利用する。
• スマートフォンのSMSアプリに置き換える形でSignalを使えるのでアプリを使い分ける必要がなくなる。
• バッテリの消費が少ない。

特に2番目のオープンソースという事に関して言えば、これほどに安心感を得られるものは無い。(プログラムのコードがしっかりと精査されていれば、という前提付きだが…)

ここまでの部分と、かつ使ってみた上で、残念だなと感じた点やデメリットは以下の通りである。

• Signalを使ってない人に何気なくSignalのアプリからからメッセージを送るとキャリアのSMS扱いになるので課金されてしまう。
• IDでの管理ではないので電話番号が必須となる。
• 電話番号を伏せた上で、ID等による匿名を前提としたメッセージのやりとりには利用できない。
• タブレットには対応していない。
• Windows / Mac / Linux 用のいずれのクライアントソフトも存在しない。

この中でも最後のPC用のクライアントソフトはあればあったで活用の幅が広がるのは間違いない。少しでも早く作って欲しいところだ。

また、まだ試し切れてないので判ってない不安要素として以下のものが挙げられる。

• 通話の音質、通話品質
• 移動時の音質、通話品質

これらについては追々に追加レポートを上げていく事とする。

 

終わりに

ここでは通話とメッセンジャーに関する記事、特に Signal Private Messenger の利用促進の目的で書いたが、インターネット上やそれ以外の部分でもプライバシーをキープするためにはその他にもいろいろと気を付けるべき項目がある。

• Webブラウザにおける暗号化通信
• クラウドストレージ
• 電子メール
• LAN内のファイルサーバー
• USBメモリ
• HDD (ハードディスク)

これらについてはまた追って書いて行きたいと思う。