はじめに
2021年3月、大手SNSのLINEにおいて、 利用者の個人情報が中国の開発委託先から閲覧可能になっていた、 というニュースが流れました。
LINEの個人情報、中国の開発委託先から閲覧可能に 「説明不足だった」と謝罪
これをキッカケに、LINEの危険性が広く周知され、 LINEの代替となるチャットアプリを探す動きが、 顕著になっているようです。
ただ、チャットアプリの安全性とひとくちに言っても、 安全って何がどうであれば安全なのかよくわからない、 という方も多いのではないでしょうか。
ですので、 チャットアプリの安全性について、 簡単にパターン分けをし、 どのような仕組みのサービスであれば安全と言えるのか を示していきたいと思います。
なお、当方は元セキュリティエンジニアですが、 内容の正確性について保証しているわけではありません。 ざっくりとした整理と考察ですのであしからず。。
チャットサービスのパターン分けと安全性
チャットアプリのサービス全体を指すため、 以降、「チャットアプリ」ではなく「チャットサービス」と記述します。
チャットサービスの安全性について考えるには、 以下のような観点で場合分けしていかねばなりません。 (分かりやすいように宅配便に例えた補足をつけています。)
- 通信経路の構成(端末間で直接か、サーバを経由するのか)
- 通信経路の保護(通信の暗号化はされているか)
- 個人情報の保護(個人情報の暗号化はされているか)
宅配便で言えば配送経路の構成。
小包(個人情報)を、差出人(端末)から受取人(端末)へ直接運ぶのか、一旦配送所(サーバ)を経由して運ぶのか。
宅配便で言えば配送経路の保護。
配送経路が保護されていて、小包が途中で盗まれたりすり替えられたりしないか。
宅配便で言えば小包の保護。
小包が保護されていて、差出人と受取人のみ開封できるようになっているか。
「個人情報」については、 氏名、電話番号、メアド、トーク内容、画像、 と多岐に渡りますが、 それをいちいち区別していくと話が非常に煩雑になるので、 それらのプライベートな情報群について、 まとめて「個人情報」と表現します。
なお、端末、サーバの物理的な接続構成は以下のようになります。
すごーくざっくりした図ですが(笑
実際には、インターネットを経由する過程で、 様々なサーバやらルータやらを通っていきます。
が、まぁ、抽象化するとこんな感じです。 ここから、通信がどう組み立てられるかを見ていきます。
なお、技術的な話について、どの暗号化方式がいいとか、 どの通信プロトコルがいいとかいう細かい話はしません。 それは「手段」の話であり、 ここではもう少し大きな観点から、話を整理したいと思います。
以下、6パターンに分けて解説していきます。
- A1:端末間で暗号化せず通信
- A2:端末間で暗号化通信、個人情報は暗号化せず保管
- A3:端末間で暗号化通信、個人情報は暗号化して保管
- B1:サーバを介して暗号化せず通信
- B2:サーバを介して暗号化通信、個人情報は暗号化せず保管
- B3:サーバを介して暗号化通信、個人情報は暗号化して保管
Aは端末間通信、Bはサーバ経由の通信、数字は暗号化の状況を示しています。
細かいことを言えばもっと多くのパターン分けが必要になりますが、 あまり細かくしても分かりづらくなるので、ある程度簡便な分類にしています。
パターンA1:端末間で暗号化せず通信
- 通信経路の構成:端末間直接
- 通信経路の保護:暗号化なし
- 個人情報の保護:暗号化なし
このパターンは、 ネットワーク上における通信経路の保護という観点において、 安全とは言えないでしょう。
通信が暗号化されていない時点で、 通信相手の真正性が保証されず、 また通信内容の秘匿性も保証されません。
パターンA2:端末間で暗号化通信、個人情報は暗号化せず保管
- 通信経路の構成:端末間直接
- 通信経路の保護:暗号化あり
- 個人情報の保護:暗号化なし
このパターンは、 ネットワーク上における通信経路の保護という観点において、 またサーバ上に個人情報を保管しないという観点において、 安全と言えるでしょう。
個人端末間で暗号化通信を行い、端末間の通信が一本の暗号化トンネルで保護されます。 いわゆる エンドツーエンド暗号化 というやつですね。
メリットとしては、 通信自体が暗号化で保護されているということに加え、 サーバに個人情報を保管しない(できない、しても意味がない)ので、 サーバからの個人情報漏えいリスクは避けられるということです。
デメリットとしては、 サーバに個人情報を保管していないため、 原則として1アカウントで使える端末が1つに制限されるということです。 つまり、複数端末で同時に使えないですし、 機種変などをすると、データは引き継がれません。 引き継ぐためには、一旦バックアップを作成して、 新しい端末にコピーして、、、のような面倒な手順が必要となります。 端末をなくしたりしたら、アウトです。
また、端末上の個人情報については暗号化されていません。 端末自体のセキュリティが担保されていない場合、 安全上の問題になる可能性はあります。
この方式を採用しているチャットサービスに、 Signal があります。 ただ、端末上の個人情報が暗号化されているかどうかについては調べておりません。 端末上の個人情報が暗号化されているのであれば、次のパターンA3となります。
パターンA3:端末間で暗号化通信、個人情報は暗号化して保管
- 通信経路の構成:端末間直接
- 通信経路の保護:暗号化あり
- 個人情報の保護:暗号化あり
このパターンは、 ネットワーク上における通信経路の保護という観点において、 またサーバ上に個人情報を保管しないという観点において、 安全と言えるでしょう。
メリット・デメリットについてはA2と同様です。
ネットワーク上の安全性についてはA2と変わりませんが、 端末上で個人情報を暗号化している分、安全性は高いと言えるでしょう。
パターンB1:サーバを介して暗号化せず通信
- 通信経路の構成:サーバ経由
- 通信経路の保護:暗号化なし
- 個人情報の保護:暗号化なし
このパターンは、 ネットワーク上における通信経路の保護や、 サーバ上における個人情報の保護という観点において、 安全とは言えないでしょう。
通信が暗号化されていない時点で、 通信相手の真正性が保証されず、 また通信内容の秘匿性も保証されません。
パターンB2:サーバを介して暗号化通信、個人情報は暗号化せず保管
- 通信経路の構成:サーバ経由
- 通信経路の保護:暗号化あり
- 個人情報の保護:暗号化なし
このパターンは、 ネットワーク上における通信経路の保護という観点においては安全と言えますが、 サーバ上における個人情報の保護という観点においては、 安全とは言えないでしょう。
現状、多くのチャットサービスがこのパターンではないかと思います。
メリットとしては、 サーバに個人情報が蓄積されているため、 同一アカウントを複数の端末で使えたり、 機種変などでのデータの引き継ぎが簡単だったりと、 利便性が高いことでしょう。
デメリットとしては、 サーバに個人情報が蓄積され、かつサーバ管理者が内容を確認できてしまう、 ということでしょう。 安全性が担保されているとは言い難い状態と言えます。
LINEでLetter Sealing オフだとこの状態でしょう。
なお、サーバ上において個人情報に何らかの暗号化が施されていたとしても、 それの復号がサーバ管理者側で可能なのであれば、 安全性としては問題があるということになります。 その場合、どの程度の安全性が担保されているかは、 サーバの情報管理体制に依存します。
パターンB3:サーバを介して暗号化通信、個人情報は暗号化して保管
- 通信経路の構成:サーバ経由
- 通信経路の保護:暗号化あり
- 個人情報の保護:暗号化あり
このパターンは、 ネットワーク上における通信経路の保護や、 サーバ上における個人情報の保護という観点において、 安全と言えるでしょう。
通信経路の構成はサーバ経由となっているため、 B2と同様に暗号化トンネルが複数本になります。
このパターンのメリットは、B2と同じく、 サーバに個人情報が蓄積されているため、 同一アカウントを複数の端末で使えたり、 機種変などでのデータの引き継ぎがしやすかったりと、 利便性が高いことでしょう。
また、やりとりする個人情報に端末でのみ復号可能な暗号化を施すことで、 サーバ上の個人情報についての秘匿性を担保することができます。
デメリットとしては、 暗号化されているとはいえサーバに個人情報を蓄積しているため、 端末でしか復号できないような暗号化がされているかどうか? という点に注意が必要なところでしょう。
また、鍵が異なると復号できないため、 複数端末で使う場合や機種変などをする場合、 復号鍵の管理に工夫が必要となるでしょう。
ちなみにLINEの場合、「Letter Sealing」をオンにすると、 暗号化通信とは別に、 個人端末間でのみ復号可能な暗号化が施されるそうです。
なお、日本もそうですが、国によっては、 犯罪捜査などにおいて、 「捜査機関の要請に応じて、通信内容を開示しなければならない」 などと法律で定められている場合があります。
この場合、 仮に個人情報が暗号化されて保管されていたとしても、 捜査機関に情報提供できるように、 サーバ管理者側でマスターキーのようなもので 復号できるような仕様になっている可能性があります。 このような場合は、技術的に安全性が担保されているとは言えないでしょう。
その場合、技術的な安全性とはまた別の次元で、 その国が信頼できるかどうかといった、 カントリーリスクの評価みたいな話になってくるかと思います。
いざという時にはサーバ側で復号できてしまうことに変わりはないですが、
- 「日本にあるサーバで、日本企業が管理していて、日本の捜査機関が開示を要請する」
- 「中国にあるサーバで、中国企業が管理していて、中国の捜査機関が開示を要請する」
上記2つでは、意味合いが全く変わってくるということです。
サービスが安全かどうかの判断方法
既存のチャットサービスが安全かどうか判断するためには、
下記を見ていき、先述したどのパターンに当てはまるかを見ていく必要があります。
「1.セキュリティの仕様が公開されている」 に関しては、 どういう動作仕様なのかが公開されていなければ、 判断のしようがありません。 安全かそうでないか分からない、、、という状態です。
例えばLINEですと、 LINE セキュリティ&プライバシー にセキュリティの仕様が公開されています。
Signalであれば、 Signalサポート セキュリティ にて確認できます。
「2.公開されている仕様は安全なものである」 に関しては、 主に、通信の安全性、個人情報保管の安全性が担保されているか、を見ます。 サーバやネットワーク上の第三者への情報漏えいを防ぎたい、ということであれば、 パターンA2、A3、B3、のいずれかであれば大丈夫でしょう。
「3.ソースコードが公開されている」 に関しては、 オープンソースのプロジェクトでもない限り、 通常は公開されていないでしょう。 これは企業が事業として開発するアプリであれば、致し方ないことではあります。 ソースコードを公開したらパクられてしまうリスクがありますから。 そうすると、その企業が信頼できるかどうか、、、 といった、技術的な視点以外のところで安全性を測ることになってくるでしょう。
「4.公開されているコードは、仕様通りの動作になっている」 に関しては、 公開されている仕様と、 公開されているコードで、 整合性が取れているかということですね。 あとはまぁ、脆弱性がないか、というところも検証可能ですね。 とはいえ、コードが読める人でないと意味不明な文字列なので、 誰でも検証可能なわけではなく、 こういったことをボランティアで検証してくれるエンジニアの方々が頼りとなります。
理想的には、 1,2,3,4全てを満たすのが「技術的に安全性が高い」と 言えるかと思います。 安全性を最優先するのであれば、 そういうサービスを選ぶべきでしょう。
なお、1,2,3,4を満たしている場合、 技術的な安全性が担保されているため、 そのアプリを「誰が作ったのか」ということを気にする必要はありません。 「どこ製だから安全」とか「どこ製だから危険」というのはナンセンスです。
ただ、現実的には、 どのチャットサービスを使うかというのは、 技術的な安全性だけで決まるわけではなく、 機能性とか、匿名性とか、ユーザーの多さとか、色々あるわけです。 例えば前述の「Signal」は、1,2,3,4を満たしていますが、 このアプリは利用者同士では電話番号が筒抜けになります。 第三者への秘匿性は高くても、 利用者同士の匿名性という観点では微妙だったりするわけです。
で、企業が開発しているサービスは、 機能性や匿名性は優れていたりするわけですが、 安全性という意味では3,4は満たされない可能性が高いです。 なので、企業が事業として開発しているサービスに関しては、 少なくとも1,2を満たすサービスであることと、 その企業が信頼に足る企業であるかどうか、 その企業の国籍が信頼に足る国であるかどうか、 といったことが判断基準になってくるかと思います。
まとめ
チャットサービスの安全性について、 通信の安全性と、個人情報の安全性に分けて解説してみましたが、 いかがでしたでしょうか。
個人的には、国産で、安全で便利なチャットサービスが出てきてくれると、 嬉しいなと思っています。 GoogleにしろFacebookにしろLINEにしろ外国企業ばかりですからね。。。 (LINEは一応日本企業ですが、中身は韓国企業ということで笑)
以上、チャットサービスの安全性を考える上での、 思考の整理の一助となれば幸いです。