🔐

Appleの製品セキュリティ解説が面白い

2021/08/04に公開

Security

Apple

idea

Appleは自社の製品セキュリティについて割と詳細に解説したホワイトペーパーを公開している。何故か日本語版もある。

~~(PDF版) https://manuals.info.apple.com/MANUALS/1000/MA1902/ja_JP/apple-platform-security-guide-j.pdf~~ EDIT: ~~日本語版は無くなったようだ~~
(PDF版) https://help.apple.com/pdf/security/ja_JP/apple-platform-security-guide-j.pdf EDIT: 新しいURLで公開された
(PDF版) https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf

このドキュメントは言わば ユーザのプライバシで商売をすることの決意表明 であり、このレベルの仕組みとその開示がユーザの "信頼" を得るには必要とAppleは考えていると言える。(ただ、これは別にApple固有でもなく、例えば、1Passwordは同様のレベルの開示 https://1password.com/files/1Password-White-Paper.pdf をしている。)

Webページ版はちょっと一覧性がイマイチなので、PDF版を上から下まで眺めてみることをオススメしたい。

おもしろポイント

... オススメだけだとあんまりなので以下おもしろポイントについて。

書かれていない項目(= 現実のセキュリティ危機)

このドキュメントは継続的にアップデートされているが、いくつか記載されていない詳細がある。

EDIT: 修正された脆弱性についてはシステムアップデートの際に表示されるURLで案内される。例えば下で挙げている IOMobileFrameBuffer の修正についてもページがあって簡単に説明されている。

例えば、 The Great iPwn のようなレポートで有名になった iMessageのゼロクリック攻撃はiOS14で抜本的な緩和策である BlastDoor が導入され、対策された。このドキュメントからは、このような攻撃があったことや実際に対処した事が殆ど読みとれない。

(ゼロクリック攻撃のスライドに唐突にたまごっちのイラストが入っているのは、Googleの担当者がファンでたまごっちのリバースエンジニアリングでも著名なため。)

もっとも、最近のアムネスティのレポート (Engadget日本語版の記事)にもあるようにiOS 14でも引き続きiMessage経由でのゼロクリック攻撃が存在することが示唆されるレポートが上がっていて、BlastDoorのような方法でデバイス上での信頼されないメッセージのパースを保護する手法にも限界があると言える。

EDIT: Corelliumは和解に到達していた。あとCorelliumは動作ハードウェアについてこれといった情報を出していないので、デバイスは単純にエミュレーションしている可能性が高いと見られる。

また、現実のiOSは最新版でもJailbreakされていて、 ~~JailbreakされたiPhone12までのハードウェアに自前のHypervisorを搭載してリモート機としたサービスまで存在しAppleと係争している~~ 。Jailbreakはこのドキュメントで記述されているセキュリティ機構が完全に動作していればそもそもできないはずで、逆に言えば文章は現状Appleが "何に失敗しているのか" は述べていないことになる。最新のiOS 14.7.1 でも IOMobileFrameBuffer のカーネル脆弱性を修正していて、とにかくセキュリティには終わりがない。

専用Cコンパイラ

BlastDoorの解説ではSwift実装であることが特徴に挙げられていたが、Appleはブートローダのために専用のCコンパイラを用意している。

iOS 14およびiPadOS 14では、セキュリティを向上させるために、iBootブートローダーのビルドに使用するCコンパイラツールチェーンを変更しました。変更されたツールチェーンは、通常はCプログラムで発生するメモリおよび型の安全性の問題を防止するように設計されたコードを実装します。

このドキュメントでは触れられていないが、Appleは伝統的にセキュリティサンドボックスの構成用にScheme(Lispの一種)を採用していて、↑のGoogleによるBlastDoorのwriteupでもScheme(のS式)で書かれたサンドボックス定義のコードが出てくる。

L4カーネルの使用

セキュリティシステムはたまにマイナーなOSを採用して世間を驚かせる。例えば Intel ME ではMINIXが動作しているとされ、作者であるタネンバウム -- Linux vs. Minix の議論をLinusとしたその人 -- がオープンレターを出している。

AppleはそのMINIXと同様にマイクロカーネルデザインを採るOSであるL4をSecure EnclaveプロセッサのOSとして採用している:

Secure EnclaveプロセッサはAppleがカスタマイズしたL4マイクロカーネルのバージョンを実行します。これは低いクロック速度でも効率的に動作するよう設計されており、クロック攻撃や電力攻撃を受けても保護されます

もっとも、MINIXと比較するとL4は界隈ではメジャーな方のOSで、iPhone以前にもQualcommのチップセットで採用される等していた。

SoC世代毎の実装セキュリティの違い

最近ではiOS 15がiPhone6s以降を引き続きサポートする事が話題になったように、人々は自分のデバイスについていつサポートされなくなるかに関心がある。今のところiOS 15ファミリがサポートする最古のSoCはAppleTV HDのA8だが、現時点ではそれがこのドキュメントで言及される最古のSoCとなっている。

注記: 2020年秋に初めてリリースされたA12、A13、S4、およびS5製品は第2世代のセキュア・ストレージ・コンポーネントを搭載していますが、同じSoCに基づくそれ以前の製品は第1世代のセキュア・ストレージ・コンポーネントを搭載しています。

また、セキュリティ機能の実装表にはA10以降のSoCしか載っていない。

現状のiOSはSoCがMetalをサポートしているかどうかでサポート可否が分かれているが、今後はセキュリティ機能の有無で差別化される可能性もあり、そうだとすればセキュリティ機能が完備となったA12以降となるのではないだろうか。

A11までは広く知られたbootrom脆弱性( checkm8 )があり、USB DFUモードにあるデバイスで任意コード実行が可能になっている。これとSecure Enclaveにある別の脆弱性を組み合わせることが、現状ではメジャーなJailbreak手段になっている。

ファームウェアアップデートの個体化

プラットフォームセキュリティの重要な側面は"永続化させない事"と言える。例えば、 checkm8 による現状のJailbreakは"tethered jailbreak"と呼ばれ、電源を切るとその効果は消失する。このため、他人の電話にこっそり仕込むことが困難で、悪用しづらい。

iOSのバージョンアップによって新しいファームウェアをインストールするというのは、コードの変更を永続化させることに相当するので、かなり慎重にデザイン・実装されているように見える。

これらの安全なプロセスを適切に使用することで、Appleは既知の脆弱性を持つ古いバージョンのオペレーティングシステムへの署名を停止でき、ダウングレード攻撃を防ぐことができます。

Appleが設計したシリコン（セキュリティチップおよびIntelプロセッサ搭載Macなど）で、デバイスをアップデートするために常にAppleへのネットワーク接続が必要となるのは、パーソナライズプロセスを実行するためです。

ファームウェアアップデートは相互認証の上行われていることになる。つまり、ファームウェアアップデートを要求するデバイスはAppleのサーバと通信し、インストールするアップデートの署名値とともにAppleからの承認を得る必要がある。

重要な側面として、オフラインで実行されるAppleデバイスは基本的にAppleに対する利益を生まない(ユーザの写真データを送信したりApp Storeで購入したりしない)のでサポートする必要が無いという点がある。

オンラインを前提にしなければ、個体化は機能しない。 ...例えばデバイスのアクティベーションキーを電話で伝えてアップデートファイルを郵送してもらうみたいなのは考えられるかもしれないが。。

Secure Enclave直結の物理ボタン

Secure Enclaveは、物理的なボタンで暗号機能の利用を承認するための機能を備えている。

...M1 Mac + Wireless Keyboardはワイヤレスなので更に追加の考察がある。

(このため、TouchID付きワイヤレスキーボードのセキュリティ機能はM1 Mac専用になる)

https://jp.techcrunch.com/2021/08/04/2021-08-03-apples-touch-id-enabled-keyboard-is-finally-available-on-its-own/

重要な注意点は、Touch IDはM1チップで動くMacでのみ使えるということ。つまり、現在マーケットに出回っているかなりのMacでは使えない。もしあなたがそうしたすてきな新システムを持っているのなら、安全なログインや購入などのためにTouch IDを使うことができる。こうした制限は、Touch IDが新しいチップに組み込まれたSecure Enclaveを使用しているためのようだ。

専用のボタンがセキュリティ意思表明に使われるのは、悪意のあるソフトウェアによってユーザの意思に反して操作が行われることを防ぐのに効果的と言える。例えば、Windowsがログイン時にCTRL+ALT+DELを要求するのも、このキーコンビネーションがWindowsのAPIから操作できないことに依る(Secure Attention Sequenceとして使われている)。

最弱の暗号

基本的には妥当なレベルの暗号化を殆どの箇所で使用しているように見える。文章中で用いられている暗号で最弱のものはRSA 1024bitsのようだ。

AirPlayでも、認証ICを使用して、レシーバがAppleによって認定されていることを確認します。AirPlayオーディオおよびCarPlayビデオストリームでは、MFi-SAP（Secure Association Protocol）を使用して、アクセサリとデバイス間の通信がAES128のカウンタ（CTR）モードで暗号化されます。また、Station-to-Station（STS）プロトコルの一部として、一時鍵がECDH鍵交換（Curve25519）により交換され、認証ICの1024ビットRSA鍵を使って署名されます。

これは認証ICの真正性を確認するもので、プロトコル実装の正当性自体は担保しない(AirPlay2まではオプショナルだったと見られる)のであまり重要な暗号とは言えないだろう。

英語版

WebページやPDFには英語版もある。

(PDF) https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/apple-platform-security-guide.pdf

... 英語版の方がページ数が多い。内容は一見同じなのに。。日本語版には固有のごく軽微なtypoが2、3ある。

かんそう

プラットフォーマーをやるにはこれだけのものが必要 ...なのだろうか。

りんご鍵

ページのアイコンとしてAppleマークを南京錠にみたてた独自の鍵マークが使用されている。この鍵のマークはセキュリティに関するコミュニケーションで使用されていて、特にEpicとの裁判の流れで公開された、アプリのサイドロードの害について述べた文章で使われている。

(PDF) https://www.apple.com/privacy/docs/Building_a_Trusted_Ecosystem_for_Millions_of_Apps.pdf -- 日本語版は存在しない？
Engadget日本語版の記事 https://japanese.engadget.com/apple-sideloading-privacy-risk-110026727.html

その結果、ユーザーは常に詐欺に注意しなければならなくなり、限られた開発者からわずかなアプリしかダウンロードできなくなるとのことです。その一方でアップルはApp Storeを「信頼できる場所」と表現し、何重ものセキュリティが「悪意のあるソフトウェアからの比類のないレベルの保護」を提供し、ユーザーに安心感を与えていると述べています。

裁判自体はいわゆる"Apple税"にフォーカスしているが、このサイドロードの影響がセキュリティの文脈で語られていることにポイントがある。

実際AltStore(ゲーム機のエミュレータを配布するために作成されたサイドロードヘルパ)がやっているように、アプリケーションを署名さえすれば現状でもサイドロードは可能となっている。AppleにとってAltStoreを塞ぐことは難しくない -- Webページ上での手動操作をReCAPTCHAで強要する等、無料の署名に手動操作を要求すること自体は原理的に可能 -- が、現実問題としてはそこまでの対策は打っていない。

なのでAppleの言うところのサイドロードはAltStoreくらい面倒な(PC側に再署名daemonを常駐させる必要がある)ものは含まず、Appleがでかいコストを掛けて築き上げた "信頼" の上にAppleの承認の入らないアプリが動作することを防ぎたいのだろう。

不完全な信頼に基づくセキュリティは可能か

Appleは完全なセキュリティをコストを掛けて実現し、その上でユーザにはAppleを究極的に信頼させて各種サービスを提供している。このモデルならApple Payのようなアプリケーションを実現できるが、Epicとの裁判に代表されるような不満も出ている。

究極的な信頼を要求しないモデルで同等のサービスを提供することは可能なのだろうか？

例えば、現状のDRMシステムは究極的な信頼を要求せずに機能している。MSのPlayReadyではInsecure worldとSecure world(TEE)を明確に区別し、Insecure worldが存在しても機能する設計となっている。

もしUSB接続のクレジットカードがあったら？

仮にVISAが発行するクレジットカードにUSB端子が付いていて、PC上での決済処理をそのカードで行うことができたとしてどのような問題があるだろうか。

(外見が非常にダサいというのは除く)

直ぐにわかる問題として、 PC上には安全に暗証番号を入力する方法がない という点が挙げられる。暗証番号は頻繁には更新されないため、キーロガー等が仕込まれていたら終わってしまう。Apple Payの場合、番号入力や指紋認証による代理入力は安全なOSが処理しているのでこの問題は(バグが無ければ)存在しない。

ユーザの意思とコンピュータをセキュアに繋ぐには

ここには、Apple製品ユーザの "信頼" の正体の一端があるように思える。つまり、Apple提供のUIが、

意図を正確に反映し、意図しない3rd partyに意思が伝わることがない
自分以外の人間が、自分のふりをして意思を伝えることがない

というポイントを実現していると確信することが、ユーザがApple製品に寄せている信頼であり、その信頼をもってApple Payなり写真なりSiriのようなユーザの高度なプライバシーに依存したアプリケーションを実現しているのではないだろうか。

承認を与えたアプリケーションしか動作させないというのは、もっとも単純にこの期待を実現する方法と言える。 他の方法は難しい 。例えば、WebブラウザがどんなにSSL情報をアドレスバーに出してもフィッシング詐欺にはあまり効果がない -- ユーザへの教育によってこの方式の信頼を成立させるのは困難と言える。

今のところ、Windows11もTPM2.0を要求する等、業界は割と安直にシステム全体での一貫性によって信頼を得る方向に向かっている。しかし、ユーザが何を信頼したいのかをもっと真剣に考察して、もっとコンパクトにユーザの信頼を獲得することはできないものだろうか。