Apple Private Cloud Compute: クラウドAIプライバシーの新たな境界
(security.apple.com)- Apple Intelligenceは、オンデバイスで処理しにくいリクエストを大規模なファウンデーションモデルに任せるため、Private Cloud Compute(PCC) を導入し、クラウドでも個人データへのアクセスを最小化する設計を打ち出している
- PCCは、カスタム Apple siliconサーバー、Secure Enclave、Secure Boot、Code Signing、サンドボックス化を組み合わせ、データセンターにデバイスレベルのセキュリティモデルを持ち込もうとしている
- ユーザーのリクエストは、検証済みのPCCノード公開鍵で直接暗号化され、ロードバランサーやプライバシーゲートウェイはリクエストを復号する鍵を持たない
- 運用の利便性のためによく使われるリモートシェル、対話型デバッグ、汎用ロギングを除外し、監査済みログと限定的なメトリクスだけがノード外に出るよう設計している
- Appleは、プロダクションソフトウェアイメージ、透明性ログ、研究環境、Apple Security Bountyを通じて、外部から検証可能なクラウドAI を実現する計画である
Apple Intelligenceがクラウドに移るときに生じるプライバシー問題
- Apple Intelligence は、iPhone、iPad、Macに生成モデルベースのパーソナルインテリジェンス機能を提供するシステムである
- より複雑なデータに対して推論が必要な高度な機能には、より大規模な ファウンデーションモデル が必要であり、そのためにAppleは Private Cloud Compute(PCC) を作った
- PCCは、個人向けAI処理のために設計されたクラウドインテリジェンスシステムであり、ユーザーの個人データがAppleを含む誰にも露出しないことを目標としている
- オンデバイス処理は、ユーザーデータのセキュリティとプライバシーに有利である
- ユーザーのデバイスにしか存在しないデータは、中央集約された攻撃ポイントに置かれない
- 最も機微なクラウドデータには、エンドツーエンド暗号化が強力な防御手段となる
- エンドツーエンド暗号化が適切でないクラウドサービスでは、一時的な処理や、ユーザーの身元をぼかす無関係なランダム識別子を利用できる
従来のクラウドAIセキュリティモデルの限界
- クラウドAIは、強力なデータセンターハードウェアと大規模な機械学習モデルを活用できる一方、リクエストと関連する個人データへの 非暗号化アクセス を必要とする
- このため完全なエンドツーエンド暗号化だけでは処理できず、既存のクラウドAIサービスは従来型のクラウドセキュリティ方式に依存してきた
- 従来のアプローチには3つの弱点がある
- セキュリティ・プライバシー保証の検証が難しい
- サービスが特定ユーザーのデータを記録しないとしても、研究者がそれを確認するのは難しい
- 新バージョンが機微なデータを誤ってログに残したり、TLSを終端するロードバランサーが障害対応中にユーザーリクエストを大量記録したりする可能性がある
- ランタイム透明性の提供が難しい
- クラウドAIサービスは、実際に稼働しているソフトウェアスタックを通常公開しない
- オープンソースソフトウェアだけを使っていても、ユーザーデバイスやブラウザがサービスのソフトウェアが改変されていないことを確認する、広く配布された方法はない
- 強い権限アクセス制限が難しい
- SREや管理者は、障害や重大インシデント時にSSHのような高権限アクセスを利用できる
- 管理者がライブサーバーデータをバックアップする際に機微なユーザーデータをコピーしてしまったり、犯罪者が管理者資格情報を盗んでユーザーデータを持ち去ったりする可能性がある
- セキュリティ・プライバシー保証の検証が難しい
PCCの5つの設計要件
-
個人ユーザーデータに対するステートレス計算
- PCCは、受け取った個人データをユーザーリクエスト処理の目的にのみ使用しなければならない
- データは、Apple従業員を含め、ユーザー以外の誰にも提供されてはならない
- 応答返却後は、ログやデバッグ用途を含め、いかなる形でも保持されてはならない
-
技術的に強制可能な保証
- セキュリティとプライバシーの保証は、システム全体の重要な構成要素を制限し分析できるときに最も強くなる
- PCCの中核的な保証は、TLS終端ロードバランサーのような外部構成要素に依存してはならない
- サーバーメトリクスやエラーログ収集のような運用要件も、プライバシー保護を弱めない方法で支えられる必要がある
-
特権ランタイムアクセスなし
- PCCには、AppleのSREが障害対応中であってもプライバシー保証を回避できる特権インターフェースが存在してはならない
- ランタイムで追加ソフトウェアを読み込み、特権アクセスの範囲を広げる仕組みもサポートしてはならない
-
非標的化
- 攻撃者が特定のPCCユーザーの個人データを狙うには、PCCシステム全体に対する広範な侵害を試みる必要がある
- サプライチェーン上でPCCノードに物理攻撃を行ったり、データセンターへのアクセスを得たりした攻撃者でも、特定ユーザーのリクエストを侵害ノードへ誘導できてはならない
-
検証可能な透明性
- セキュリティ研究者は、PCCのセキュリティ・プライバシー保証がAppleの公開約束と一致しているかを高い信頼性で検証できなければならない
- 研究者が検査したソフトウェアと、PCCの本番環境で実行中のソフトウェアが同一であることも確認可能でなければならない
PCCノードとセキュリティ基盤
- PCCの信頼のルートは、カスタム設計されたサーバーハードウェアである PCCコンピュートノード である
- PCCノードは、iPhoneで使われているハードウェアセキュリティ技術をデータセンターへ持ち込む
- OSは、LLM推論ワークロード向けに最適化されたiOSとmacOSベースの強化サブセットである
- 攻撃面を狭く保つよう設計されている
- Code Signing や サンドボックス化 といったiOSのセキュリティ技術を活用する
- Appleは、データセンター管理で一般に重要とされる構成要素をPCCノードから除外している
- リモートシェル
- システム内部観測と汎用観測ツール
- その代わり、SRE担当者に小さく限定された運用メトリクスだけを決定論的に提供する、目的特化型の構成要素を用いる
- Swift on Server で クラウドベースのファウンデーションモデル をホスティングするための新たな機械学習スタックを構築した
ユーザーリクエスト処理とデータ保持防止
- PCCはユーザーリクエストのデータをモデル推論に使う必要があるため、完全なエンドツーエンド暗号化だけで設計することはできない
- その代わり、PCCコンピュートノードが処理中のユーザーデータプライバシーを技術的に強制し、ジョブサイクル終了後にはデータを保持できないようにする
- PCCのユーザーデータ処理保証は3つある
- ユーザーのデバイスは、推論リクエスト処理という唯一の目的のためにのみPCCへデータを送る
- ユーザーデータは、応答返却前まで、リクエストを処理するPCCノード内にだけ留まる
- ユーザーデータは、本番サービスやハードウェアへの管理アクセス権を持つApple従業員にも提供されない
- Apple IntelligenceがPCCを使う際、デバイスはプロンプト、利用したいモデル、推論パラメータでリクエストを構成する
- デバイス上のPCCクライアントは、まず検証され暗号学的に認証されたPCCノードの公開鍵でリクエストを直接暗号化する
- ユーザーデバイスから検証済みPCCノードまでエンドツーエンド暗号化が提供される
- ロードバランサーやプライバシーゲートウェイのような補助的データセンターサービスは信頼境界の外にあり、リクエストを復号する鍵を持たない
- PCCノードは、Secure BootとCode Signingにより承認され暗号学的に測定されたコードしか実行できない
- 実行可能なすべてのコードはAppleが署名し、特定のPCCノードに承認されたtrust cacheに含まれていなければならない
- trust cacheはSecure Enclaveが読み込み、ランタイムで変更や追加はできない
- JITマッピングを作成できないため、ランタイムコードのコンパイルや注入を防ぐ
- コードとモデル資産は、Signed System Volume で使われているものと同じ完全性保護を利用する
- Secure Enclaveは、リクエスト復号鍵が複製または抽出されないことを強制する
- データ保持を防ぐため、Secure Enclaveは再起動ごとにデータボリューム暗号化鍵をランダム化し、この鍵を永続保存しない
- PCCノードのSecure Enclave Processorが再起動するたび、データボリュームは暗号学的に消去される
- 推論プロセスは、リクエスト完了時に関連データを削除する
- ユーザーデータを処理したアドレス空間は、予期せずメモリに残るデータの影響を減らすため、定期的に再利用される
- Pointer Authentication Codes とサンドボックス化は、保証回避を狙うエクスプロイトを難しくし、PCCノード内部での水平移動を制限する
- 推論制御とディスパッチ層はSwiftで書かれており、メモリ安全性を確保しつつ、リクエストの初期処理を別アドレス空間に分離する
特権ランタイムアクセスの排除
- PCCノードには リモートシェル や対話型デバッグ機構が含まれない
- Code Signingは追加コードの読み込みを防ぐが、Appleはこのようなオープンなアクセス自体を、システムのセキュリティとプライバシーを回避しうる広い攻撃面と見なしている
- PCCノードではDeveloper Modeを有効化できず、デバッグワークフローに必要なツールも含まれない
- 可観測性と管理ツールには、ユーザーデータ露出を防ぐプライバシー保護策が組み込まれている
- 汎用ロギング機構がない
- 事前指定され、構造化され、監査済みのログとメトリクスだけがノード外へ出られる
- 複数の独立したレビュー層が、当該メカニズムを通じたユーザーデータの偶発的露出を防ぐために用いられる
- この設計により、指定されたコードだけがユーザーデータにアクセスし、システム管理中にユーザーデータがPCCノード外へ漏れないことを、強制可能な形で保証する
非標的化とハードウェア攻撃への対処
- PCCの脅威モデルには、コンピュートノードへ物理的にアクセスし、システムの一部ハードウェアセキュリティ特性を回避して処理中データを抽出できる高度な攻撃者が含まれる
- Appleは2つの方法で防御する
- PCCハードウェアに強化されたサプライチェーンを適用し、大規模なハードウェア攻撃を非常に高コストかつ発見可能にする
- 小規模な攻撃が特定ユーザーデータの標的化に使えないようにする
- PCCハードウェアセキュリティは製造段階から始まる
- サーバーが封印され改ざんスイッチが有効化される前に、PCCノード構成要素のインベントリ化と高解像度イメージングを行う
- データセンター到着後、PCCプロビジョニング前に広範な再検証を行う
- 複数のAppleチームが独立ソースのデータを相互照合し、Appleと無関係な第三者オブザーバーが手順を追加監視する
- 各PCCノードには、Secure Enclave UID にルートを持つ鍵証明書が発行される
- ユーザーデバイスは、証明書を検証できないPCCノードにはデータを送らない
- より小規模で巧妙な攻撃を防ぐため、PCCは 標的拡散(target diffusion) アプローチを採用する
- リクエストメタデータには、送信元デバイスやユーザーに関する個人識別情報が含まれない
- 適切なモデルへルーティングするのに必要な、限定的なリクエストコンテキストデータのみを含む
- このメタデータだけが、PCC信頼境界外のロードバランサーやデータセンター構成要素に提供される
- メタデータには、RSA Blind Signatures ベースの使い捨て資格情報が含まれ、リクエストを特定ユーザーに結びつけることなく有効なリクエストを承認する
- PCCリクエストは、第三者が運営する OHTTP relay を通過する
- リクエストがPCCインフラに到達する前に、デバイスの送信元IPアドレスを隠す
- 攻撃者がIPアドレスでリクエストを識別したり個人に結びつけたりするのを防ぐ
- 送信元IPベースでトラフィック誘導を行うには、第三者リレーとAppleロードバランサーの両方を侵害する必要がある
- ユーザーデバイスは、PCCサービス全体ではなく、PCCノードのサブセットに対してのみリクエストを暗号化する
- ロードバランサーは、リクエストを処理できる可能性が高いノードのサブセットを返す
- ロードバランサーはユーザーやデバイス識別情報を持たないため、特定ユーザー向けに集合を偏らせることはできない
- 単一ノードが侵害されても、復号できるのは流入リクエストのごく一部に限られる
- ロードバランサーが選択したPCCノード集合は統計的に監査可能である
検証可能な透明性と研究者アクセス
- Appleは、PCCに対する公的信頼のためには、セキュリティ研究者がエンドツーエンドのセキュリティ・プライバシー保証を検証できる必要があると考えている
- PCCの公開時には、すべてのプロダクションビルドのソフトウェアイメージ をセキュリティ研究目的で公開する計画である
- ユーザーデバイスは、公開登録されたソフトウェアを実行していることを暗号学的に証明できるPCCノードにのみデータを送るよう設計されている
- Appleの検証可能な透明性計画には以下が含まれる
- PCCで実行されるすべてのコードの測定値を、追記専用方式の暗号学的改ざん耐性を持つ透明性ログに公開
- ログと関連バイナリソフトウェアイメージを、プライバシー・セキュリティ専門家が検査・検証できるよう公開
- PCCノードソフトウェア分析用の公式ツールセットを公開・維持
- Apple Security Bounty を通じて重要な研究成果に報奨
- すべてのプロダクションPCCソフトウェアイメージは、独立したバイナリ検査のため公開される
- OS、アプリケーション、関連実行ファイルが含まれる
- 研究者はこれを透明性ログの測定値と照合して検証できる
- ソフトウェアは、ログへの掲載後90日以内、または関連ソフトウェアアップデート提供後のいずれか早い時点で公開される
- リリースがログに署名付きで記録されると、検知されずに削除することはできない
- ユーザーデバイスは、PCCノードの証明済み測定値が公開透明性ログのソフトウェアリリースと一致する場合にのみ、リクエストペイロード鍵をそのノードの公開鍵でラップする
- Code Signingは未承認ソフトウェアの読み込みを防ぎ、PCCノード上のすべてのコードが証明に含まれるようにする
PCC研究環境と報奨
- Appleは、研究者がPCCのプライバシー約束を迅速に検証し問題を見つけられるよう、3つの追加施策を計画している
- PCC Virtual Research Environment の公開
- Apple silicon搭載Mac上でPCCノードをシミュレートするツールとイメージセット
- 仮想化で動作するよう最小限の修正が加えられたPCCソフトウェア版を起動できる
- すべてのプロダクションPCCビルドのバイナリイメージとは別に、セキュリティ上重要なPCCソースコードの一部を定期的に公開
- Appleプラットフォームで初めて、PCCイメージにsepOSファームウェアとiBootブートローダーを平文で含める
- PCC Virtual Research Environment の公開
- Apple Security Bountyは、PCCソフトウェアスタック全体に関する研究成果を報奨対象とする
- PCCのプライバシー約束を弱める問題には、特に大きな報奨が提供される予定である
今後公開予定の事項
- PCCは、ステートレス計算、強制可能な保証、特権アクセスなし、非標的化、検証可能な透明性の要件を満たすよう設計されている
- PCCがベータ提供された後、さらに踏み込んだ技術説明が続く予定である
- 今後、各中核要件の実装と動作に関する追加の技術詳細を共有する計画である
- Appleは、セキュリティ研究者に対し、PCCソフトウェアとPCC Virtual Research Environmentを近日中に初公開する予定である
1件のコメント
Hacker News のコメント
クラウドやインターネットに接続されるものはすべて、オープンソースでサーバーが分散型でない限り、結局は誰かを信頼しなければならない
Apple は自社以外の誰もデータにアクセスできないよう最善を尽くすことはできるが、Apple はすべてのエンドポイント、iPhone のアップデート、サーバーを管理している
「Web ベースの暗号化は常に詐欺だ」という記事を思い出す: https://www.devever.net/~hl/webcrypto
ローカルに保存されたデータであっても、Apple が望めばアクセスできる力があり、政府命令があればそうするかもしれない。だから「プライベート」という言葉は、より多くの主体ではなく、Apple だけが知り得るという意味に近いと思う
代替案がデータをより多くの場所に流す可能性があるという点ではましだが、宣伝されているような破られない暗号化とはほど遠い
Google は広告、レコメンド、AI などのためにユーザーを追跡しているのは明白で、隠してもおらず、ビジネスモデルの中核でもある
一方 Apple は、この AI システムで従業員がユーザーデータにアクセスできないよう、かなり真剣に取り組んでおり、ログ取得と可観測性を強く制限し、独自のチップやオペレーティングシステムまで設計している
クライアントが監査されていないシステムと通信しないようにしている点も大きな違いだ
Apple の言葉をそのまま信じることはできないが、第三者監査こそがこのシステムのプライバシーを信頼し検証する核心だと思う
「Apple は君が何をしているか知っている」という言い方は、Apple 内部の誰かがデバイスからプライベートクラウドへ送られたデータにアクセスできるというニュアンスだが、それは事実ではないように見える
Apple のビジネスモデルにおいてプライバシーが大きな柱である点も信頼の一要素だ。Apple は別の方法で収益を上げる製品を作って財務的に成功してきており、データを売る方向へ進むことは必要でもなければ良いビジネスアイデアでもない
第三者による検証までは懐疑的でいるのは妥当だが、Apple のアプローチが OpenAI や Google よりデータとプライバシーの面で優れていないと言うのは不当だ
人々が自分のサーバーを運用できないなら、公開リポジトリのコードが実際のクラウドサーバーで動いているコードと同じかどうか分からないため、オープンソースだけでは不十分だ
もちろん検証作業は必要だが、それでも大きな前進だ
私の見るところ、代替案はばらばらで焦点も弱いので、Apple を信頼する
暗号学者 Matt Green の良いコメントがここにある: https://x.com/matthew_d_green/status/1800291897245835616?t=C...
X アカウントなしではツイートを読めないことを Matt が知っているのか分からない。BlueSky や Mastodon を使ってくれるとよいのだが
スレッドまとめ: https://threadreaderapp.com/thread/1800291897245835616.html?...
「ブログ記事には、おそらく技術的な詳細がさらに 6 つほどある。非常に慎重な設計だ。優秀なチームに大金を払って世界最高の『プライベート』クラウドを作れと言ったら、おそらくこういうものになるだろう」
「もちろん、超スパイが最大の敵ではないことを覚えておく必要がある。多くの人にとって最大の敵は、デバイスとソフトウェアを売った会社だ。この PCC システムは、Apple がユーザーデータを『のぞき見しない』という実際の約束を示している。大きな意味がある」
データはデバイス内にとどまるほうが好ましいが、少なくともこれは正しい方向への大きな約束か、あるいは間違った方向ではあるが競合よりはるかによくやっているものなのかもしれない
AI 機能全体、つまりオンデバイスとオフデバイスの両方をオフにする選択肢はあると推測している
デバイスメーカーがオンデバイス AI 専用オプションを用意しない理由があるだろうか？ iOS 17 の AI 機能は今でも iCloud なしで使える
Apple が
*.pcc.apple.comのような固有ドメインを使って、ネットワークレベルでフィルタリングできるとよい全部読んでみても、結局は「私たちを信じてください」に行き着く。Apple はいつでもバックドア入りのアップデートに署名して承認できるし、政府は署名一つで Apple にそれを強制でき、すべてが静かに進められ得る。
Apple がやっていることに利点があるのは理解している。しかし、信頼を売るのであれば 100% 真実であるべきで、このようなデータアクセスの可能性がなお存在することを透明に明かさなければ、メッセージ全体が汚染される。
オペレーティングシステムを作る人たちを信頼できないなら、オフデバイス AI 処理を心配するよりもはるかに深い問題があるということだ。
Apple はボタン一つで iPhone に望むデータをサーバーへアップロードさせることができる。その論理なら、ローカル実行の AI まで含めて何も信頼すべきではない。おそらく正しいが、実用的ではない。
Matthew Green のスレッドの最後の部分がよく要約している。「完璧さが、非常に良いものの妨げになることがある。実際、オンデバイスの代替は、機微なデータを OpenAI やもっと怪しいところへ送ることだ。多くの人にとって最大の敵は、デバイスとソフトウェアを売った会社だ。PCC は Apple がデータを『のぞき見しない』という実際の約束であり、大きなことだ。いまやスマートフォンの一部が 2,000 マイル離れたデータセンターに存在する世界へ向かっているのだから、セキュリティ側の人たちもその事実に慣れ、あらゆる部分をできる限り安全にしなければならない」
非常に興味深い。Apple の Private Cloud Compute は、同僚たちと 6 年前に始めたオープンソースプロジェクト System Transparency と概念的に同じものに見える。
さらに多くの技術的詳細に期待している。Apple 関係者が見ているなら、stromberg@mullvad.net まで連絡してもよい。私たちの設計と Apple の設計について議論したり、フィードバックを提供したりできる。
関連リンク: https://mullvad.net/en/blog/system-transparency-future
http://system-transparency.org
http://sigsum.org
Apple がやっているのは Confidential Computing だ。実装例を探してみると、さらに多くの技術的詳細を理解できる。
Apple は Confidential Computing Consortium のメンバーではないが、ARM はメンバーだ。
Trusted Computing についてもかなり楽観的で、勢いが増しているように見える。
もっとオープンで、スタック全体を制御し、ハードウェアプラットフォームに独自のルート証明書や鍵をインストールできればよいのだが、それでも多くの利点をもたらし得る。
Apple がこれをメインストリームに押し上げれば、採用がさらに増えると期待している。
「Apple プラットフォームで初めて、PCC イメージは sepOS ファームウェアと iBoot ブートローダーを平文で含み、研究者がこれらの中核コンポーネントをこれまでになく容易に研究できるようにする」という部分はとても良い。
ただし、「ソフトウェアはログに含まれてから 90 日以内、または関連するソフトウェアアップデートが提供された後のいずれか早い時点で公開される」という部分は、理論上、脆弱なソフトウェアの公開と発見可能性の間に最大 90 日の空白を残す。
実際のイメージ提供は、最大値よりもはるかに即時に近いことを願う。
米国では完全なプライバシーは不可能だ。政府が Apple に内部を開示するよう強制できるだけでなく、その事実を話すことも禁じられるからだ。
Apple がこの「制約」を回避する方法は事実上ない。機会があれば、PATRIOT Act の延長に賛成した「代表者」に感謝すればよい。
入ってくるリクエストからデータを収集するには、政府が求めるリアルタイム傍受のようなものが必要になるだろうが、それは別の状況かもしれない。
もちろん私はインターネット上の一人にすぎず、この懸念への反論を思いついてみた程度なので、方向性が合っているかも分からない。
政府がデータを要求することはできる。しかし Apple のシステムは、Apple 自身が話せなくても、そのような侵入を公衆に明らかにすることになるはずだ。
国家安全保障書簡でも、もはや存在しないデータを要求することはできない。
大きな疑問がある。これは誰のためのものなのだろうか？
誤解してほしくないが、これは素晴らしい取り組みで、A+級のナード仕事だ。自分の言葉で語ってくる代物だ。
ただ、自分なら単に家に電話する機能をオフにする方法を探すと思う。そもそもそういう動作を望んでいないからだ。
これは、自分に「Appleが最も安全な選択肢だ」と他人に言わせるためのものなのだろうか？ Linuxを勧めるのは嫌だ。技術サポートをしたくないから。
いまでは「自分のデータに手を出すな」と叫ぶ老人になった気分だ。
MicrosoftのAIへの取り組みに関する見出しは、概して悪夢に近く、悪い報道が多かった。
Apple AI関連の報道が、セキュリティとプライバシーに過剰なくらい配慮しているという内容で埋まるなら、人々が使ううえで多少は安心できる可能性が高い。
OpenAI製品を多用しているわけではないが、使うならOpenAIに直接行くより、Appleの匿名化レイヤー経由で使うほうがよさそうだ。
AppleもAI中心の企業になれることを示さなければならない。ただしAppleには、プライバシーを守ろうとする組織文化がある。
政府がデータにアクセスすることは気にしていない。ただ、詐欺師、外国政府、広告テクノロジー企業、保険会社のような悪意ある行為者に、自分の個人データへアクセスしてほしくない。
同時にLLMの能力も使いたい。そんなに非現実的な要求だろうか？
現実的には、米国政府はすでに自分の全データを持っていると考えている。現状が気に入っているわけではないが、現実は現実だ。
実際にはiPhone規模のLLMとクラウドインフラが用意されており、これは単なる2年がかりの作業ではない。
Appleは期待されている通り、プライバシーを強調しているのだ。
Geminiもプライバシーを主張できるかもしれないが、それが本当ならむしろ性能が落ちるだろうと人々は考えそうだ。
Appleが短く言及したAWS Nitro Enclavesとどう比較されるのか気になる。
主な違いは、ファームウェアレベルまで検証可能である点にあるように見える。
Nitro Enclavesはファームウェア[0]やハイパーバイザーの測定値を提供しておらず、ハイパーバイザーのコードはいつでも透過的に更新され得ると述べている[1]。
AppleはSecure Enclave ProcessorのOSであるsepOSとブートローダーイメージを提供する予定だ。
ブログ記事は明確ではないが、これらのコンポーネントのソースコードも提供するように聞こえる。
[0]: https://docs.aws.amazon.com/enclaves/latest/user/set-up-atte...
[1]: https://docs.aws.amazon.com/pdfs/whitepapers/latest/security...
自動的に呼び出しがかかり、セキュリティチームも介入する可能性が高い。
EC2ではハイパーバイザーはファームウェアではないため、ハイパーバイザーのファームウェアを測定する理由はない。
マザーボードのBIOS/UEFIファームウェアは、改ざんされると上書きされる。
ハイパーバイザーのコードはすべてのコードと同様に常に署名され、Nitroカードが測定ブートやセキュアブートを活用する検証可能なセキュリティシステムを通じてサーバーへストリーミングされる。
顧客向けの用語である「Nitro enclaves」が正確に何を意味するのかは分からないが、EC2エンジニアたちは些細なセキュリティリスクと判断しただけでも、呼び出しで軍隊のように動く。
こうした基本事項は対処済みで、コアダンプに実際の顧客データが暗号化された形でさえ入らないよう保証するレベルにまで及んでいる。
このオペレーティングシステムをぜひ見てみたいし、大手テック企業が実際に監査可能なセキュリティ保証を提供する最初の事例になり得るという点で、慎重ながら楽観している
展開次第では、Apple がユーザーからすでに得ている信頼を、ある程度は実際に獲得できるかもしれず、それはかなり素晴らしいことだと思う
さらに素晴らしいのは、管理チェーン全体の監査を提供することで、そのためにはスタックのほかの部分も一部公開する必要がありそうだ
とくに約束どおりクラウド OS がオープンソースになるなら、非常に価値がある
現時点での主な懸念は、実際のデプロイで仮想化が使われる場合、ユーザー端末上で動くまだプロプライエタリな OS 部分の Secure Enclave が鍵を渡し、私たちが監査していないハイパーバイザーがコンテナにアクセスするバックドアが存在し得る点だ
セキュリティの専門性がより高い人たちは、もっとよい問いを投げかけるだろう
Apple が研究者からのフィードバックに反応するなら、このツールチェーンのより多くの部分が監査可能になるかもしれない
たとえ Apple が承認したユースケースの安全性を検証できないとしても、このクラウド OS はセキュリティ推論とセキュアクラウドにおける大きな前進になり得るし、人々が独自にホスティングしたり派生版を作ったりすることもできる
最悪のケースは Apple が実際にはやらないことだが、少なくともその約束は守る可能性がかなりありそうに見える。そうなれば最悪の場合でも「大規模セキュアコンピューティングのための非常に有益なオープンソースコードベースが出てきた」ということになり、ほかの部分がどうであれ良いことだ
[0] https://docs.aws.amazon.com/enclaves/latest/user/nitro-encla...
Asahi Linux にはオンデバイスのブートチェーンセキュリティ概要がよくまとまっている: https://github.com/AsahiLinux/docs/wiki/Apple-Platform-Secur...
「PCC Virtual Research Environment を公開する。Apple silicon Mac 上で PCC ノードをシミュレートし、仮想化を成功させるために最小限修正された PCC ソフトウェア版を起動できるツールとイメージのセットだ」という文言は、PCC ノードがベアメタルであるという意味のように見える
M4 Apple Silicon 搭載の iPad Pro でも PCC ノードをシミュレートできるのだろうか？
「最後に Swift on Server を使って、クラウドベースの基盤モデルホスティング用の新しい機械学習スタックを作った」という部分が興味深い
ここで Swift on Server が登場したのが目を引く: https://www.swift.org/documentation/server/