暗号化
匿名性が高く安全なメッセンジャーとして知られ、ユーザーが増え続けているThreemaに、今週スキャンダルが浮上しました。スイスの名門チューリッヒ工科大学（ETH Zurich）の研究者が、Threemaのプロトコルに7つの脆弱性を発見しました。一方で、アプリの開発者側は、これらのバグを重視しておらず、「すべての問題は2、3週間のうちに解決する」、「いずれも現実の世界に大きな影響を及ぼさない」とブログで発表しています。さて、実際のところはどうなのでしょうか。ユーザーは、今すぐSignalに切り替えるべきでしょうか。
このThreemaスキャンダルの核心に迫るのは容易ではありません。双方の対応は、理想的とは言えないからです。チューリッヒ工科大学のチームは、脆弱性の発見がどれほど重要か、明らかに誇張する言い方を使っており、脆弱性だけでなく、万が一それが悪用された場合のシナリオについても言及しています。それに対してThreemaの開発者たちは、脆弱性の深刻度を明らかに軽視しており、悪用される可能性は極めて低いと主張しています。
結論のみに興味がある方は、この記事の最後のセクションまでスキップすることができます。
Threemaの脆弱性
すべての脆弱性に関する情報は、10月に責任をもって開示され、その後修正されています。研究者側とアプリ開発側の主張によりますと、これらの脆弱性が悪用された事例は確認されていません。そのため、これらの脆弱性に不安を感じる必要はないように見えるかもしれませんが、懸念すべき理由もあります。
チューリッヒ工科大学による研究リポート、Threema側の発表、および、一般に公開されているThreemaアプリやそのプロトコルに関する調査結果を詳しくみてみましょう。
このアプリでは、強度の高い暗号化アルゴリズムが使用されており、堅牢性が高く、標準化されたNaClが実装されています。ただし、この暗号化アルゴリズムがThreema独自の情報交換プロトコルでラッピングされており、このプロトコルの実装に不備があります。それにより、理論上さまざまな攻撃のリスク（受信者によって異なって見えるメッセージをグループチャットで送信する、など）が生じるだけでなく、いくつかの現実的な攻撃のシナリオも指摘されています。例えば、攻撃者が標的とするスマホに物理的にアクセスできる場合、アプリを保護するためのパスフレーズが設定されていなければ、デバイス上のThreemaのデータベースやバックアップを比較的簡単に読み取ることができます。Threema IDを複製することも可能で、攻撃者はそれによって（被害者と同時でなければ）被害者の名前でメッセージを送信できるようになります。もちろん、スマホに物理的にアクセスできる状況は、ほぼ「最悪の事態」と言えるので、その状態で攻撃を防ぐのは極めて難しいことです。
今回発見された脆弱性を攻撃者が実際に悪用して攻撃を成功させるには、クリアしなければならない条件があります。例えば、攻撃者がデータ交換ネットワークでフルコントロールの権限を手に入れる必要があります。しかも、脆弱性の悪用にはその他の複雑な条件も同時に満たされなければなりません。一つ例を挙げれば、被害者に非常に奇妙な内容のメッセージをThreemaを使って送信させる必要があります。実際、それを強制することが不可能に近いでしょう。
通信プロトコルの不備の中で最も憂慮すべきなのは、前方秘匿性がないことです。これは、メッセージが一度復号されれば、それ以降メッセージも複合されることを意味します。この問題点についてはかなり以前から指摘されていて、おそらくそれが理由で、Threemaは12月、このプロトコルのより安全な新バージョンを発表しました。Ibexというこの新しいプロトコルは、独立機関によるセキュリティ監査をこれから受けることになっています。そのため、今の時点では、このプロトコルが最新の暗号化を実現するすべての要素に対応しているという、開発者の言葉を信じるしかありません。Threemaは、新バージョンリリース後ではなく、開発の早い段階でプロトコルの外部監査を実施するように勧めるチューリッヒ工科大学のアドバイスに従うのが賢明かもしれません。
一部の脆弱性を攻撃者が悪用するためには、まずThreemaサーバーに侵入する必要があります。さらに、オペレーター側の誰かが意図的に、やり取りされたデータの窃取または通信の妨害を試みなければなりません。企業用のThreemaのプロダクト、Threema Workを使用している企業にとってはこの点が重要です。仮説の上での話であっても、リスクをとることが許されない企業は、独自のThreemaサーバーを持つThreema OnPremへの切り替えを検討した方がよいでしょう。その場合、管理者はサーバーのセキュリティを強化する（堅牢化する）方法を模索する必要があります。
アプリの開発者も、この状況から学ぶ必要があります。暗号化の専門家たちが終始声を大にして伝えていることですが、「独自の暗号化アルゴリズムを作らないように」してください（Telegramなども忠告を無視した一例です）。しかしながら、Threemaの開発者が採用したのは、適切な標準的な実装で、テストされた独自の暗号化アルゴリズムでした。多数のバグが入り込んだのは、標準のTLSの代わりに導入した独自のクライアント/サーバー間の通信プロトコルの中で標準の暗号化を使用したことによるものです。専門家は「独自の暗号化アルゴリズムやプロトコルを作らないようにしてください」と繰り返しアドバイスをするべきだったかもしれません。
現実的な結論
「暗号強度が最も高いメッセンジャー」だと信じてThreemaを選び、メッセンジャーで電話番号を使用することに抵抗がなく、細かい技術的な問題に捉われたくない人は、Signalに切り替えることをお勧めします。実際のハッキングと裁判所命令で証明されたとおり、Signalの暗号化とデータ保存の原則は堅牢性と耐性に優れています。仕事用のメッセンジャーとしてThreemaを使用する必要があったり、Threema IDと電話番号が紐付けられていない点を重視するのなら、使い続けても構いませんが、リスクは事前に知っておく必要があります。上記のリスクは（今のところ）仮説にすぎませんが、そういった完全に無視することは危険です。念のために再確認を行い、新しい連絡先のThreema IDについてはオフラインで確認し、ログインのセキュリティ保護のためにパスフレーズを使用しましょう。
中規模、大規模の企業で業務にThreemaを使用している場合は、メッセンジャーサーバーを社内で完全に管理できるように、Threema OnPremへの移行を真剣に検討する必要があります。
ヒント