Appleが日曜夜にGatekeeperの「自宅への通話」がユーザー情報と関連していないことを確認する以前から、ある研究者が示唆するように、悪意のある人物がそのデータを使ってアプリの起動を監視しているというプライバシー上の懸念は、理論的には問題にならない。その理由は以下の通り。
木曜日、macOSユーザーからmacOS Big Surへのアップグレード中に問題が発生したという報告が寄せられました。また、アップグレードしなくてもアプリケーションが動作しなくなったという報告もありました。この問題はサーバー関連の問題であり、Apple側の問題により証明書チェック機能が正常に動作しなかったことが原因であると判明しました。
アプリケーションセキュリティと運用セキュリティのコンサルティング会社を創業したセキュリティ研究者、ジェフリー・ポール氏も、このサービスに注目しています。木曜日に執筆した長文の記事で、ポール氏はmacOSにおけるプライバシー問題、つまりユーザーが開いているアプリがAppleに報告されているという問題について、人々の意識を高めようと試みました。
ポール氏によると、AppleのMacと特定のサーバー間の通信は、IPアドレスから得られるデータと組み合わせることで、ユーザーの行動に関する大量のメタデータを作成できるという。これには、ユーザーの現在地や時間、コンピューターの詳細、実行中のソフトウェアなどが含まれる。
このデータを時間をかけて収集することで、悪意のある人物が簡単にマイニングできるアーカイブが作成され、大規模な監視を実行する能力が大幅に向上し、悪名高く現在は停止している PRISM 監視プログラムと同等のレベルに達する可能性があります。
問題は、事態はそこまで劇的でもなければ、それほど深刻でもないということです。しかも、ISPはもしその気になれば、Gatekeeperが開示するよりもはるかに多くのデータを、インターネットの一般的な利用状況だけで収集できるのです。
ゲートキーパーの仕組み
AppleはOSに様々なセキュリティ機能を組み込んでおり、macOSも例外ではありません。アプリ内でマルウェアが使用される可能性を防ぐため、Appleは開発者に対し、アプリがmacOSで動作するように様々なプロセスを経ることを義務付けています。
Appleは、開発者のアプリが正規のものであることを確認するのに役立つセキュリティ証明書の作成に加え、アプリの公証プロセスも義務付けています。登録開発者はアプリをAppleに提出し、セキュリティ上の問題や悪意のあるコードがないかスキャンされた後、承認されます。
Appleは2018年に開発者向けに認証プロセスを導入した。
つまり、アプリは通常、Appleが認識している開発者IDで署名され、Apple自身によるチェックを受けた上で、macOSで実行できるようになることで保護されています。署名されたセキュリティ証明書は、アプリの作成者が承認されていることを証明し、公証によってアプリの実行ファイルが改ざんされてマルウェアが混入される可能性を最小限に抑えます。
アプリや開発者に適用されるセキュリティ証明書はいつでも取り消すことができるため、マルウェアに感染していることが判明しているアプリや、何らかの形で不正行為を行ったアプリを迅速に無効化できます。これにより、証明書の有効期限が切れ、開発者が新しいバージョンのアプリで証明書を更新するまでアプリが動作しなくなるなどの問題が発生したケースもありましたが、このシステムは概ね成功を収めています。
コミュニケーションの崩壊
ここで問題となるのは、この形式のセキュリティを管理するセキュリティ機能であるGatekeeperが、そもそもどのようにタスクを実行するかという点です。プロセスの一環として、GatekeeperはAppleのオンライン証明書ステータスプロトコル(OCSP)レスポンダと通信し、OCSPがGatekeeperの証明書を確認します。
この通信では、macOS がハッシュ(チェックする必要があるプログラムの一意の識別子)を送信します。
ハッシュとは、文書や実行ファイルなどのデータブロックに対してアルゴリズムを用いて生成できる既知の文字列です。ハッシュは、ファイルが改ざんされたかどうかを確認する効果的な方法となります。なぜなら、改ざんされたファイルから生成されたハッシュは、期待されるハッシュ結果とほぼ確実に異なるため、何らかの問題が発生したことを示唆するからです。
macOS内のアプリケーションファイルからハッシュが生成され、OCSPに送られ、OCSPが認識しているアプリケーションのハッシュと照合されます。OCSPは通常、このハッシュ値のみに基づいて、ファイルが本物か、あるいは何らかの形で破損しているかを判断し、応答を返します。
macOS でソフトウェアを実行できなかったり、アップグレードを実行できなかったりする原因は、OCSP がリクエストに圧倒され、実行速度が非常に遅くなり、適切な応答を返せなくなったことにあります。
物事をめちゃくちゃにする
ページ氏は、これらの既知のハッシュが、ユーザーが何をいつ実行しているかをAppleに効果的に報告するものだと主張しています。さらに、基本的な位置情報を得るためにIPアドレスにマッピングされ、Apple IDなどのユーザーIDに何らかの形で接続されると、Appleは「友人宅のWi-FiでPremiereを開いた時や、旅行先のホテルでTorブラウザを開いた時などを把握できる」ようになります。
Appleの理論的な知識は確かに重要ですが、Page氏は、これらのOCSPリクエストハッシュは暗号化されずに公開されていると指摘しています。データパケットを解析する誰もが公開状態で読み取り可能なこの情報は、ISPや「ケーブルを盗聴した者」、あるいはAppleが利用するサードパーティのコンテンツ配信ネットワークにアクセスできる者によって、PRISMのようなユーザー監視に利用される可能性があります。
「このデータは、あなたの生活や習慣に関する膨大な量のデータであり、それをすべて把握している人は、あなたの動きや活動パターンを特定することができます」とペイジ氏は記している。「人によっては、身体的な危険さえも及ぼす可能性があります。」
ハッシュを分析し、十分な数のハッシュを保有し、そのハッシュの意味を解明できれば、特定の時間に実行したアプリケーションを特定できる可能性があります。セキュリティ専門家がハッシュを分析するためのツールは数多く存在するため、十分なリソース、データストレージ、そして計算能力を持つ人が同様のことを行うのは、決して不合理ではありません。
しかし、現実的に言えば、どのアプリが起動されているかを正確に知ることには、あまり意味がありません。また、ISPはAppleのGatekeeperが提供するような限定的な情報なしに、望めばそのデータを入手することも可能です。
これらのハッシュの大部分は、たとえ識別可能であっても、その汎用性や一部のアプリの高頻度な使用状況のため、ほとんど利用できないデータで構成されます。ハッシュはアプリ名を示すだけで、ユーザーが何を見ているかは示さないため、SafariやChromeを起動したユーザーを特定しても、収集できる情報はあまりありません。
macOSのプレビューアプリを15回連続で開いた人を国家が気にするとは思えません。確かに、非常に特殊な用途で第三者が関心を持つ可能性のあるアプリなど、例外的なケースはありますが、それはごく稀で、アプリが開かれたことを認識させるよりも、他の手段でデータを収集する方が簡単でしょう。
ターゲットユーザーが何を実行しているかを判断するためにハッシュを見る必要はありません。アプリケーションは特定のポートまたはポート範囲で実行される傾向があるため、データパケットを監視する立場にある人であれば誰でも、データが関連するポートを確認することで、実行されたアプリケーションを特定できます。
例えば、ポート80はHTTP、つまり標準的なウェブトラフィックに使用されていることがよく知られていますが、ポート1119はBlizzardのBattle.netがゲーム用に使用している可能性があります。アプリケーションが通信するポートを変更することも可能かもしれませんが、大規模な監視システムにおいては、オペレーターはSkype通話の兆候としてポート23399、VMwareの兆候としてポート8337を監視するでしょう。
例えば、1119 との間のトラフィックが停止すると、ISP はユーザーがWarcraft のプレイを終了したと判断できます。Gatekeeper はこのようなことを行いません。
確かに、ISPデータ全体とポート監視機能を備えたPRISM型のスパイプログラムが理論的に実現できる可能性はあります。しかし、そのようなものを構築したい人にとっては、その有用性は極めて低いでしょう。
「ユーザー 384K66478 が18:22 にRunescapeを開きました」は Gatekeeper が公開できる絶対的な最大値であり、誰の役にも立ちません。
これは全く新しいものではなく、秘密でもありません
データのこの潜在的な利用例は、Appleユーザーにとって最近発生した問題ではないことを指摘しておく価値があります。Appleは2012年に初めて実装されて以来、サーバーベースの確認による証明書のチェックにGatekeeperを採用しており、すでにかなり長い間運用されています。
もしこれがポールが述べたようなプライバシーの問題であったなら(そしてそれはそうではない)、それは何年もの間問題となっていたはずだ。
オンラインサーバーを用いてアプリの正当性を確認するシステムはmacOSに限ったものではなく、AppleはiOSエコシステムでも同様の検証プロセスを採用しています。また、少量のアプリがAppleのApp Storeルールを回避できるエンタープライズセキュリティ証明書も存在しますが、2019年初頭にFacebookが実証したように、それらも同様の方法で取り消し可能です。
Microsoftは独自のデバイスガードを備えています。これは、コード署名を悪用し、ハッシュをMicrosoftに送信してアプリの実行を許可または拒否するマルウェアに対抗するためのWindows 10のセキュリティ機能です。この機能では、アプリが正しく署名されているかどうかを確認するためにサーバーとの通信も行われます。
ポール氏はまた、この機能はユーザーには知られていない秘密のものであり、密かに利用習慣を監視するために利用される可能性があると述べています。しかし、オンライン広告会社やソーシャルネットワークなど、ユーザーのデータを収集している企業が数多く存在することを考えれば、特にセキュリティ上の理由から、Appleへの定期的な通報が行われていることは、ほとんどのユーザーにとって驚くべきことではないかもしれません。
不作法な失敗と「ブロックできない」メッセージ
ポールが注目する点の一つは、AppleがmacOS Big Surの一部としてシステムの機能を変更する変更を導入していることです。以前のバージョンのmacOSでは、「trustd」デーモンからのOCSPへのリクエストをファイアウォールやVPNでブロックすることで、システムを「フェイルクワイエット」状態にすることが可能でした。
ハッシュチェックシステムは通常、ハッシュをOCSPに送信し、2つのレスポンスを期待します。1つはハッシュの受信確認応答、もう1つはハッシュが本物であることを承認または拒否する応答です。最初の確認応答を受信した場合、trustdは2番目のレスポンスが届くまで待機します。
木曜日に発生した問題はまさにこのシナリオでした。確認通知は送信されたものの、後半部分が送信されていなかったのです。そのため、承認が届くはずだったのに届かず、申請が起動しなくなりました。
— ジェフ・ジョンソン(@lapcatsoftware)2020年11月12日Appleユーザーの皆さん:
Mac でアプリを起動するとハングアップする現象が発生している場合は、Little Snitch を使用して問題を解決しました。
https://t.co/FzIGwbGRan への接続は信頼されています
OCSP はソフト障害であるため、その接続を拒否すると問題は解決します。
(インターネットを切断しても解決します。)pic.twitter.com/w9YciFltrb
これはポール氏の主張と合致する。OCSPへのアクセスをブロックすると、最初のリクエストがサーバーに到達できず、最初の確認応答も承認も行われない。問題はそもそも確認応答の受信にあるため、アクセスをブロックするとサーバーからの確認応答が送信されなくなり、問題が解消される。
「fail quiet」要素は、一見オフラインの OCSP から通知されていないため、システム全体がアプリの実行を許可し、通常どおり続行されるため、ユーザーにとって有益です。
Jamfの主任セキュリティ研究者であるパトリック・ウォードル氏は、Appleがtrustdを「ContentFilterExclusionList」に追加したと指摘しています。これは、システム内のファイアウォールやVPNではブロックできないサービスやその他の要素のリストです。ブロックできないため、OCSPへの接続が常に試行され、Macは常にホームネットワークに接続します。
もちろん、これは完全にブロックできないものではありません。オフラインのMacはセキュリティ機能を利用できません。オンラインのMacの場合は、自宅のルーターや企業ネットワークのフィルタリングルールを使用して特定のトラフィックをブロックすることが可能です。また、旅行用ルーターを使用して移動中に同様のブロックを行う方法も考えられます。
議論を重ねる
もしこれがPRISMがまだ懸念材料だった頃に表面化していたら、もっと関心を払う価値があっただろう。メタデータを消費する監視システムが検討すべきデータが増え、政府が国民について活用できる情報も増えるからだ。
しかし、明らかにそうではありません。時が経ち、PRISMは存在しなくなり、1年以上が経ちました。そして、人々の活動や行動に基づいて日々データが生成されていることを、一般の人々は深く認識しています。ユーザーは無邪気さを失い、もはや自分たちが置かれている状況に無知ではいられなくなっています。
これを個人情報漏洩の可能性として隠蔽することは、数年前には意味があったかもしれないが、今はそうではない。
この情報は、誰かが相当な労力をかけて、誰かが1日に47回Safariを開いたとオンライン上で判断できる可能性が極めて低いことを考えると、取るに足らない情報に思えます。ISPがポートを監視することで、より少ない労力ではるかに多くのデータを取得できることを考えると、その情報はますます小さくなっています。
他の方法ではるかに優れた実用的なデータを取得できることを考えると、これは大局的に見てごく当たり前のことと言えるでしょう。AppleがGoogleのようにこのデータを利用する可能性すらありません。Appleは長年にわたりユーザーのプライバシーを熱心に擁護してきたため、そのような動きはまず考えられません。
ここでは、プライバシーに関する戦いが行われたり、開始されたり、エスカレートしたりすることはありません。
透明性は向上する
木曜日の2時間、Gatekeeperが一部ユーザーのアプリ起動を妨げていた間、Appleは沈黙を守っていた。原因、何が起こったのか、そしてなぜそうなったのかについては、今も沈黙を守っている。
Gatekeeperの「本国への発信」はAppleの利用規約で間接的に言及されているが、他の多くの注目度の高い失敗と同様に、Appleは木曜日にこの点についてもっと透明性を高めるべきだった。Gatekeeperのハッシュをどう扱うのかをユーザーに説明すべきだった。ハッシュを保持するのか、それとも使ってから破棄するのか、その時点で推測させるようなことは避けるべきだった。
Appleは自社製品に搭載されている他のセキュリティ機能について非常にオープンであるため、これは容易に実行できる。例えば、COVID-19スクリーニングアプリにおける匿名データ共有の導入のように、Appleが同様に公に透明性のある方法でこれに対応することは十分可能である。
これがPRISMのようなシステムの一部ではないかという声が大きいことを考えると、そうするのは難しいかもしれないが、不可能ではない。Appleはただ、これを公に説明し、不都合なことは何も起こっていないと保証する必要がある。そして、この記事が最初に公開されてから数時間後、Appleはまさにそれを実行した。
アップルのこの件に関する議論
日曜日の遅くに、Appleはこのシステムに関する文書を公開しました。具体的には、アプリのハッシュは開発者ごとに紐付けられており、iCloudアカウントやその他の識別情報にリンクされることは決してないと述べられています。
「Gatekeeperはオンラインチェックを実施し、アプリに既知のマルウェアが含まれていないか、また開発者の署名証明書が失効していないかを確認します」とサポート文書には記載されています。「これらのチェックから得たデータを、Appleユーザーやそのデバイスに関する情報と組み合わせたことはありません。また、これらのチェックから得たデータを使用して、個々のユーザーがデバイスで何を起動または実行しているかを把握することもありません。」
同社は IP アドレスのログを記録していた可能性があるが、今後はログの記録を停止し、ログから IP アドレスを削除するとも述べている。
Appleは、「これらのセキュリティチェックでは、ユーザーのApple IDやデバイスのIDは一切使用していません」と述べています。「プライバシーをさらに保護するため、開発者ID証明書のチェックに関連するIPアドレスの記録を停止しました。また、収集されたIPアドレスはログから確実に削除します。」
このような事態の再発を防ぐため、Appleは来年に向けて計画を立てています。ユーザーにさらなる制御権を与え、プロセスのセキュリティをさらに強化するための3つの対策を計画しています。
Appleの証明書検証プロセスの改善は来年に予定されている
- 開発者ID証明書失効チェック用の新しい暗号化プロトコル
- サーバー障害に対する強力な保護
- ユーザーがこれらのセキュリティ保護をオプトアウトするための新しい設定
11月15日午後10時54分(東部標準時)にAppleの計画と、同社がGatekeeperの情報をどのように扱うかについての詳細を更新しました。