2週間前、macOSユーザーは、Mac AppStoreからダウンロードされていないアプリを開くと奇妙なフリーズを報告し始めました。多くの人がデバイスのハードウェアの問題を疑っていましたが、ソーシャルメディアから、これは広範囲にわたる問題であることがわかりました。そして、それがmacOS BigSurの発売直後に発生したのは偶然ではありません。



結局、ジェフ・ジョンソンのツイートは根本的な原因を明確に示していました。 AppleのOCSPレスポンダーサービスが過負荷になっていることが判明したため、macOSはアプリケーション開発者の暗号化証明書を検証できませんでした。





しかし、なぜOCSPレスポンダーがアプリケーションを起動するための重要なパスにあるのでしょうか。この記事では、コード署名、オンライン証明書ステータスプロトコル（OCSP）の仕組み、完全に間違っている理由、およびいくつかの最良の代替案について簡単に説明します。この事件に関する他のメモとは異なり、私は実際の暗号化の側面（高レベル）について議論し、バランスの取れた視点を提供したいと思います。

コード署名

開発者ポータルで、Appleはコード署名の目的を説明しています。

アプリのコードに署名することで、ユーザーはそれが既知のソースからのものであり、最後に署名されてから変更されていないことを確認できます。アプリを統合したり、デバイスにインストールしたり、アプリカタログに入力したりする前に、Appleが発行した証明書でアプリに署名する必要があります。

つまり、アプリがmacOSで信頼されるためには、独自のキーペアベースの証明書で署名する必要があります。キーチェーンは、開発者が使用する秘密鍵と配布用の公開鍵を含む一意の「開発者ID」証明書を作成するために使用されます。 Appleが開発者ID証明書に署名すると、開発者は秘密鍵を使用して、リリースごとにアプリに暗号化署名を作成できます。



アプリケーションが起動されると、その署名は開発者の証明書の公開鍵に対して検証されます。次に、証明書自体が検証され、有効期限が切れていないこと（証明書は通常1年間有効）、および最終的にAppleルート証明書によって署名されていることを確認します。ルート証明書までのチェーンの一部として中間証明書が存在する場合もあります。開発者ID証明書はアプリケーションによって署名され、中間証明書は開発者ID証明書に署名し、Appleルート証明書は中間証明書に署名したため、これは「信頼の連鎖」です。どのAppleデバイスでも、この信頼の連鎖を確認できるため、アプリの起動を承認できます。



これは、インターネットのTLSパブリックキーインフラストラクチャに似ています。しかし、Appleは独自の信頼の連鎖を完全に制御しているため、根本的に異なります。他のCAは、すべての証明書をAppleに関連付ける必要があるため、有効なコード署名証明書を発行することは許可されていません。



検証が失敗した場合、ユーザーにはひどいウィンドウが表示されます。

フィードバック

開発者がAppleのポリシーに違反したり、秘密鍵を紛失したりするとどうなりますか？認証機関は、発行された証明書を即座に取り消す必要があります。証明書が悪意を持って使用されている場合、証明書が自然に期限切れになるまで数日または数か月待つことはできません。そうしないと、秘密鍵が漏洩するとシステム全体が使用できなくなります。



証明書が取り消されるのはこの状況です。これは、署名検証プロセスの追加の手順であり、証明書がまだ有効であることを認証機関に確認する必要があります。



インターネットでは、これは最も簡単な方法で行われます。 CAは、取り消されたすべての証明書のシリアル番号を含む証明書失効リスト（CRL）を提供し、証明書がリストにないことを確認します。ただし、リストがどんどん長くなるにつれて、ブラウザーはこのアプローチの使用を停止しました。特にHeartbleedのような恐ろしい悪用が大規模な証明書の失効を必要とした後。



オンライン証明書ステータスプロトコル（OCSP）は、証明書をリアルタイムで検証できる代替手段です。各証明書には、組み込みの「OCSPレスポンダー」が含まれています。これは、要求するURLであり、証明書が取り消されているかどうかを示します。 Appleの場合、これはocsp.apple.com..。そのため、署名の暗号化の有効性をチェックすることに加えて、アプリを起動するたびに、Appleサイトでリアルタイムのチェックを実行し（キャッシュを使用）、開発者の証明書が正当であると見なされていることを確認します。

OCSPの可用性の問題

OCSPの大きな問題は、外部サービスが単一の障害点になることです。 OCSPレスポンダーがダウンしているか利用できない場合はどうなりますか？証明書の検証を拒否しているだけですか（ハードフェイル）？それとも、チェックが成功した（ソフトフェイル）ふりをしますか？



Appleはソフトフェイル動作を使用することを余儀なくされます。そうしないと、アプリケーションはオフラインで動作しません。 OCSPレスポンダーは従来信頼性が低く、CAレスポンダーが一時的にダウンしている場合でもブラウザーがサイトをロードしたいため、すべての主要なブラウザーはソフトフェイル動作も実装しています。



ただし、ソフトフェイルは適切なオプションではありません。ネットワークを制御すると、攻撃者はレスポンダーへの要求をブロックでき、チェックがスキップされるためです。実際、このようなエラーの「修正」は、このインシデントの間にTwitterで広く配布されました。エラーへのトラフィックocsp.apple.comは、/ etc / hostsファイルの行によってブロックされました。OCSPを無効にしても目立った問題は発生しないため、多くの人はしばらくこの行を離れます。

インシデント

AppleのOCSP検証がソフト障害に基づいて構築されている場合、OCSPレスポンダーが無効になっているとアプリケーションがハングするのはなぜですか？おそらくそれは実際には別のグリッチだったためです。OCSPレスポンダーは実際には完全に無効にされていませんでした。うまくいきませんでした。



macOS Big Surに更新していた世界中の何百万ものユーザーからの負荷のために、Appleのサーバーは速度が低下し、OCSP要求に適切に応答しませんでした。しかし同時に、それらは十分に機能したため、ソフトフェイルは機能しませんでした。

OCSPプライバシーの問題

OCSPの可用性の問題に加えて、プロトコルはそもそもプライバシーを保護するように設計されていませんでした。基本的なOCSP要求には、証明書のシリアル番号を使用したOCSPレスポンダーへの暗号化されていないHTTP要求が含まれます。したがって、レスポンダーは、関心のある証明書だけでなく、ISPやパケットを傍受する他の人も判断できます。Appleは、開いている開発者アプリを順番にリストでき、部外者も同じことができます。







暗号化が追加された可能性があり、OCSPステープリングと呼ばれるより優れたよりプライベートなバージョンがありますが、Appleもこれを行っていません。このシナリオでは、OCSPステープルは実際には意味がありませんが、このテクノロジーは、OCSPがデフォルトでデータをリークしてはならないことを示しています。

より良い未来

この事件はコミュニティで活発な議論を引き起こし、一方は「あなたのコンピュータは本当にあなたのものではない」と述べ、もう一方は「アプリケーションへの信頼を確立するのは難しいが、Appleはそれをうまくやっている」と主張した。私は、OCSPがとにかく証明書の失効を管理するためのひどい方法であることを示しようとしています。将来的には、レスポンダーの可用性とプライバシーに関連するインシデントが増えることになります。私の意見では、これは悪いエンジニアリング上の決定です-アプリケーションランチャーのOCSPへの依存関係を設定することです。少なくとも短期的には、応答のキャッシュ時間を増やすことで被害を軽減しました。



幸いなことに、証明書を取り消すための最良の方法であるCRLiteはほぼ熟しています。これにより、すべての証明書失効リストを適切なサイズに短縮できます。ではスコットHelmeブログはCRLiteがOCSPまで操作取り消された証明書のリストで古いアプローチを返すために、ブルームフィルタを使用する方法の良い要約を提供します。



MacOSデバイスは、このCRLの更新を定期的に受信し、デバイス上でローカルにチェックを実行して、OCSPの可用性とプライバシーの問題に対処する場合があります。一方、開発者ID失効リストは、すべてのPKI失効証明書のリストよりもはるかに小さいため、AppleがCRLを使用しない理由を尋ねる価値があります。どの証明書が取り消されたかを開示したくない場合があります。

結論

全体として、この事件は、AppleやMicrosoftなどの組織によって推進されている信頼モデルを振り返る十分な理由でした。マルウェアはより洗練されており、ほとんどの人は特定のバイナリを実行しても安全かどうかを判断できません。コード署名は、アプリケーションの信頼を確立し、少なくともアプリケーションを有名な開発者とリンクするための優れた暗号化方法のようです。そして、証明書を取り消すことは、その信頼の必要な部分です。



ただし、OCSP検証プロセスのわずかな不具合により、コードの署名および検証プロセスの暗号化の優雅さが損なわれます。 OCSPは、インターネット上のTLS証明書にも広く使用されていますが、CAの数が多く、ブラウザーからの障害が広く認識されていないため、障害が発生する可能性は低くなります。さらに、人々は時々利用できないWebサイトを見ることに慣れていますが、自分のコンピューター上のアプリケーションに同じことを期待していません。 MacOSユーザーは、自分のアプリがAppleのインフラストラクチャの問題の影響を受けるのではないかと心配していました。ただし、これは、証明書の検証が外部インフラストラクチャに依存し、100％信頼できるインフラストラクチャがないという事実に起因する必然的な結果です。



スコットヘルムはまた、証明書の取り消しが実際に機能する場合にCAが得る力について懸念を表明しています。検閲の可能性について心配していなくても、エラーが発生することがあるため、セキュリティ上の利点と比較検討する必要があります。ある開発者が、Appleが誤って証明書を取り消したときに発見したように、隔離されたプラットフォームで実行するリスクは、隔離されたプラットフォームから隔離される可能性があることです。