何気ない記録

なんとなく自分の意見を書き記すときにつかいます。つまり不定期更新です。

さらっと凄い事かいてあるんだが・・・

 

管理不備と報じられたLINEの問題についてまとめてみた - piyolog

エンドツーエンド暗号化としてLetter Sealingを適用しているとしていたが、トークテキストについて捜査機関の要請に応じられるようにテキストを復号化できる仕組みを準備していると?それはエンドツーエンド暗号化なのか

 

データセンターが何処の国にあるとか、業務上管理者権限を誰が持っているか等というのは、各種成約(明示的な告知/表示義務等)を適切に行っている限りは些末な問題だと思う。

 

そもそも多くのサービスのデータは国内にはあるかもしれないが、それを運用しているのがそもそも日本人とは限らないわけで。

 

ただ、むしろ今回の件で気になるのはこれまでも何度か怪しいとされていたプライベートな情報であるはずのトーク内容について、少なくともLINEとしては内容を確認する術を持っているのではないかという事がより気になる記述になっているわけで、こっちの方が大きな問題だと思うのだが。

 

LINEの暗号化対応状況はレポートにまとめられており、例えば直近であれば2020年11月分が以下のように公表されている。

 


この中でも触れているように、LINEでは2015年より一部のサービスで暗号化の適用を開始し、少なくともテキストに関しては2016年に主要な部分で対応を完了したとしている。

 

ここでいう暗号化とは以下のように記述されている。

 

LINEではユーザーの情報を保護するため、様々な方式の暗号化を行っています。LINEクライアントとサーバー間の通信を保護する通信レイヤーの暗号化(LEGY暗号、HTTPS)に加えて、 対応しているメッセージタイプや通話タイプにおいては Letter Sealing による暗号化が行われます。 Letter Sealing はLINEの開発したエンドツーエンド暗号化(end-to-end encryption, E2EE)プロトコルです。

「LINE 暗号化状況レポート」内「LINEが提供する暗号化」部分を引用

参考:https://linecorp.com/ja/security/encryption/2020h1

 

Letter SealingはLINEによるエンドツーエンド暗号化の実装です。 Letter Sealingが有効化されたメッセージは、LINEクライアント内で予め暗号化された状態で送信され、LINEサーバー側でも内容を解読することは出来ません。 Letter Sealingは2015年8月よりオプション機能として提供され、2016年中に主要な利用環境でデフォルトで有効化されました。現時点では、Letter Sealingによる暗号化に対応しているメッセージタイプは限定されています。

「LINE 暗号化状況レポート」内「(3)Letter Sealing (end-to-end encryption) 適用状況」部分を引用

参考:https://linecorp.com/ja/security/encryption/2020h1

 

さて、この説明を読むかぎり、まず基本的には特別な事情がないかぎりLINEのサービス内のデータは「Letter Sealing」によるエンドツーエンド暗号化が行われている事、そしてこの「Letter Sealing」によるエンドツーエンド暗号化が行われたデータについては「LINEサーバー側でも内容を解読すること」ができないと明確に記述されています。

 

また同社の公表する「捜査機関への対応」によると、少なくともトークテキストについては、「Letter Sealing」によるエンドツーエンド暗号化が行われている場合については、そもそも復号化ができない為、対応する事はできないと明確に記述されています。

 

 

さて、ここで疑問に思うのは、それではなぜその暗号化されたテキストを実務ベースで捜査機関に対して提供及び支援するツールの開発が必要なのかという点です。

 

仮に、暗号化済みデータであっても提供をする義務があるとする場合、これは単純に当該データを提供するだけで事足りる話しです。

特別なツールを作るとして単純に指定されたユーザーや時間に応じたデータを切り出すだけの事であり、サービスの規模を考えれば、それなりのツールを事前に準備する必要はありますが、それ程の負荷、体制をとる事もないでしょう。

そもそも捜査支援にかかわらず監視業務や運用業務でもそういった作業はありえますし、そもそも通報された場合のトーク内容は部分的な監視を個別に行っているわけですから、その付帯機能程度(未暗号化のテキストデータを参照するのか、暗号化済みのテキストデータを参照するのかの違いでしかない)であり、専用に開発する必要性は感じません。

 

この部分について、あえて捜査協力の為に、且つ、トークテキストを含む形で開発をする目的とはなんでしょうか。

なんとも情報がないので言えませんが、復号化できる、という機能が存在するのではないか、という事しか考えられないのですが・・・。

 

仮に「いやいや、そんな情報は提供できないですから」というのであれば、そもそも同ツールの開発にトークテキストを含める必要はありません。

 

「いやいや、だから通報時の対応のみだから」というのであれば、それ、通常の運用時にそのデータ福岡や大連で見てるんでしょ?管理ツールあるよね?という話しで、それこそ専用のツールの開発とは一体?となる話しです。

 

「いやいや。捜査機関の方がわかりやすく、見やすく、捜査しやすいように加工してあげているんですよ」と仰るかもしれませんが、私が知る限り、相手方の強い要望がある場合を除き、私が知る限りでは運営会社がそんなご丁寧にサービスたっぷりのデータ提供をしているという事例は知りませんが。

場合によっては普通に生ログを出しますし、というか相手も加工データだけでは通常は受け取らないと思うのですが(改竄の恐れもあるので)。

 

結局のところわざわざ捜査機関への協力のためのツール開発、と言う物に対して、わざわざ暗号化されたデータを含める意図が不明ですし、日常運営の範疇であればそもそもそんなものの開発は不要だと思われます。

 

余程照会件数が多すぎて、もう、日常運用の負担よりも、捜査機関からの照会件数が多すぎるので、そっちの支援を専門部署にやらせないとダメなんで、というレベルでなければそこまでの開発体制なんてとらないでしょうし、仮にとったとするならば、尚更、原則秘匿とされている暗号化テキストがツールの開発対象に含まれる理由の説明は必要かと思いますが。

 

本件の話しの本筋については個人的には「そうですか」程度の話しでしたが、むしろこの部分の矛盾というか、説明不足についてもう少しちゃんと説明してほしいところです。

 

なお、そもそもこういったツールについて「国産の」等と謎のアイデアを出す人もいますが、大抵のサービス領域において日本は周回遅れの状況なので、仮に盗聴のリスクがあったとしても、サービスとして使う必要があるのであれば海外事業者のサービスの方が真っ当なのでは?と、私は思わなくもないですが。

 

海外云々、外国人云々で議論し始めると、そもそも使えるアプリやサービスなんてCOCOAぐらいしか残らないんじゃないですかね。

 

あ、ゴメン、あれもデータ自前じゃないわ。

 

そんな感じですかね。