Managed Device Attestationの紹介

♪ ♪ こんにちはBob Whitemanです iOS Device Managementの シニアエンジニアです 企業や教育環境管理デバイスの 重要なセキュリティの新機能をご紹介します まず デバイスセキュリティ の状況を確認しましょう ユーザーは Web サイトや AP サーバー データベースなど 組織のリソースにアクセスする必要があります このリソースにアクセスしたい攻撃者もいます リソース保護の従来のモデル は境界のセキュリティです イントラネットの周囲に セキュリティの境界線を引き ファイアウォールやVPN を立ち上げ 正規の顧客を許可し脅威を拒否します これでは現代の組織とのやり 取りに追いつかないです クラウドプロバイダーは リソースを境界の外に置き 脅威は境界の内側から始まる可能性があります

正規の顧客になりすまし境界 に侵入することができます

最新のセキュリティはネット ワーク境界を信頼しません 代わりに 各リソースは 独自の信頼性評価を行います ゼロトラストアーキテクチャの基本原則です

信頼性評価は関数として考えることができます 入力は顧客の体制情報で 出力はアクセスの許可または拒否の決定です 信頼性評価を正しく行うのが非常に重要です 検出漏れはユーザーの活動の妨げになりますが 誤判定は攻撃者がリソースに アクセスできるようになり 正確な体制情報を持つことも重要です では 体制の一般的な要素を調べてみましょう 顧客と要求について得られる すべての情報を使用します 誰が要求しているのか 使用しているデバイスや場所などです 信頼性評価は異なるリソース へのアクセスに対して 体制の中で異なる詳細を 使用する場合があります 低セキュリティリソースへの アクセスは ID のみが必要で 重要インフラへのアクセスは 体制項目の評価が必要です どの詳細が関連するかを 決定するのは組織次第です

体制の中心的な要素の 1 つはユーザーの ID です これは誰が要求しているかを示します

Apple デバイスは拡張可能な シングルサインオン機能など ユーザー ID をサポートする技術を提供し App ウェブサイトアカウントのユーザー認証を 容易にする Kerberos拡張機能を内蔵しています また 新しい登録型シングル サインオン機能により Appはユーザーの登録中および登録後の ユーザー認証を容易にします このセッションはユーザーID についてではなく デバイス ID についてです この体制要素はどのデバイス が要求しているかを示します

デバイスが各 MDM 通信で報告する UDID は MDM サーバーが管理している デバイスを知る主な方法です DeviceInformation クエリ は MDM サーバーに提供し シリアル番号を含むデバイス の属性にも提供します 管理対象デバイスはMDM サーバーとは別に 組織内の他のシステムとよく通信します MDM サーバーは他のシステム にデバイス ID を宣言し 顧客証明書を使用して デバイスをよく構成します このデバイスの識別方法は役立ってきましたが 結局デバイスの主張を信頼することになります 背景が変わってきたので これまで以上にデバイスが分散され セキュリティのニーズは進化してきました これに対処するために デバイスの ID を証明する 強力な新手法 管理対象デバイス認証をご紹介します 管理対象デバイス認証では 要求をする際に自身に関する 強力な証拠を提供します これは体制情報を向上させ それに基づく信頼性評価はより正確になります つまり 管理対象デバイス 認証とは正規のデバイスが 確実にリソースにアクセスし 攻撃者が阻止されます このリリースでは iOS 16 iPadOS 16 tvOS 16 の 管理対象デバイス認証が提供されます このセッションでは新しい 認証機能の概要から始まり 認証機能を使用する利点を説明し その後 実装の詳細を説明します まず 認証とは何でしょうか 認証とは事実を宣言することです 主張する主体を信頼する場合は 事実が真実であることを 受け入れることになります ソフトウェアでは認証は暗号化された事実です これは通常X.509 証明書です 署名者の信頼は事実が真実 であることを受け入れます 管理対象デバイス認証の場合 事実はデバイスの ID とその他のプロパティで 署名者は Apple です デバイスの正確さの受け入れ は Apple への信頼ですが Apple コードすべてを 信頼する必要はありません Secure Enclave とApple の認証サーバーを 信頼するだけで済み Apple の製造記録と OS カタログにアクセスします もしデータを Apple の デバイスに保存しているなら 暗黙のうちに信頼していることになります 管理対象デバイスに認証の力 をもたらす方法を紹介します デバイス認証は証明書を使用 する 2 つの方法があります DeviceInformation のMDM コマンドを強化し MDM サーバーで認証の利点を 利用できるようにします また 自動証明書管理環境 プロトコルサポートを追加し ACME プロファイルのペイロードを追加し これにより認証の利点を組織の基盤全体で 利用可能になります

DeviceInformation の認証のため MDM サーバーはクエリを発行 し新しい鍵を指定します デバイスは Apple サーバーから証明書を取得し MDM サーバーに返送します 次に MDM サーバーがその証明書を評価します

しかし 注意してください DeviceInformation 認証はMDM サーバーに 「プロパティを持つデバイス が存在する」と宣言しますが MDM サーバーが現在通信して いるデバイスを同じものだと 証明するものではありません そのためには ACMEペイロード認証が必要です

ACME ペイロード認証は デバイスの ID を証明する 最も強力な証拠を提供します ACME ペイロードを含む プロファイルを導入すると デバイスは組織の ACMEに証明書を要求します SCEP ペイロードの導入とよく似ています デバイスは ACME サーバーに 証明書を提供します デバイス ID のこの強力な証拠に基づいて ACME サーバーは新しい顧客証明書を発行し 組織の他のサーバーがそれを信頼します この 2 つの新機能は認証証明書を使用して いくつかのことを証明します デバイスが Apple 純正の ハードウェアであること デバイスが特定のデバイスであること デバイスが特定のプロパティを持つこと デバイスに秘密鍵がバインド されていることなどです そして異なるサーバーに対し同じデバイスと 通信していることを証明します この証明はどのような 利益をもたらすでしょうか？ 認証は主にセキュリティ機能なので 認証がどのように脅威を軽減 するかについて説明します

まず 侵害されたデバイスは プロパティに嘘をつきます そのため Apple はプロパティを証明します OS が侵害されても 認証の信頼性には影響しません Secure Enclave が無傷で あることのみが必要です または 侵害されたデバイスがその後変更された プロパティの古い証明書を提供します 認証のノンスは事実が 最新であることを保証します ACME ペイロード認証は他の脅威を軽減します 侵害されたデバイスは MDM サーバーと通信する際に 異なるデバイスの識別子を送信します Apple はデバイスが TLS接続の認証に使用する 顧客 ID に関連する方法で デバイス識別子を証明します これは MDM サーバーや他の組織のサーバーに どのデバイスと通信しているかを証明します

あるいは 攻撃者が正規の デバイスから秘密鍵を抽出し 鍵を使って正規のデバイスに なりすまして要求を行います Apple は秘密鍵が Secure Enclave での保護を証明し 秘密鍵のエクスポートやインポートに対して 非常に強力な保護機能があります 最後に 攻撃者は証明書要求を乗っ取り 別のデバイス用の証明書を 認証局に発行させます Apple は証明書要求と関連付ける形で 要求元のデバイスのID を証明します そのため 認証局は正規のデバイスにのみ 証明書を発行します 認証はセキュリティ上の脅威 を軽減する利点を提供します では 生活環境でどのように使用しますか？ 管理対象デバイス認証の実装 方法の詳細を見てみましょう まず DeviceInformationコマンドの強化です MDM サーバーはデバイスに このコマンドを発行できます 要求にはサーバーが知りたい プロパティリストを含みます DeviceProperties 認証の 新プロパティを追加しました クエリ配列に追加することはMDM サーバーが 承認を要求していることを意味します 認証が新しいことを確認する ために MDM サーバーは DeviceAttestationNonce鍵を使用できます これは要求の中でクエリキー と同じレベルで表示されます この鍵はオプションです 値はデータオブジェクトで 最大サイズは 32 バイトです これは認証要求の例です DeviceProperties 認証の 鍵はクエリ配列に含まれ 32 バイトのノンスがあります 認証の取得に成功すると DeviceProperties 認証の 鍵は応答に含まれています その値はデータオブジェクトの配列です 配列内の各要素は証明書 チェーン内の証明書です これは応答例です リーフ証明書は配列の最初に表示され カスタム OID でデバイスの プロパティを含んでいます 2 つの OID は識別属性の シリアル番号と UDID です MDM 登録がユーザー登録の 場合は証明書から省かれます 残りの OID は匿名ですべて の登録タイプで利用可能です sepOS 版はオペレーティングシステム版を指し Secure Enclave 上で動作します また ナンス OID に正しい値が存在することで 証明書が生成されたばかり であることを証明します MDM サーバーが証明書を受信すると 次の順序で慎重に検証する必要があります 証明書チェーンが期待されるApple 認証局で ルート化されることを確認します Apple 認証局は Apple Private PKI保管庫から入手できます リーフ証明書のノンスが指定されていれば DeviceInformation 要求のノンスと一致します 次に残りの OID を解析しその値を評価します 新しい認証の生成には デバイスの重要なリソースと Apple のサーバーが使用されます そのため 新しい証明書の 要求頻度には制限があります 現在 新しい証明書は7 日に 1 枚です 新しい証明書要求には新しい ノンスを指定してください ノンスを省略すると鮮度に 関心がないことを示します そのためデバイスは最新の 認証を返すことができます ノンスが指定されキャッシュ された認証と一致する場合 キャッシュされた認証が返されます MDM サーバーが認証のノンスを検証するとき 不一致のノンスを検出し それがキャッシュによる ものかどうかを判断します しかし それが速度制限 だからといって 7 日ごとに 新しい証明書を要求しないでください MDM サーバーがプロパティの 変更を迅速に検出するのを 遅らせるだけでリソースの 浪費は言うまでもありません DeviceInformation 属性に 関連する変更を監視します OS バージョンなどです このいずれかが変更されたら 新しい証明書を要求します これにより 認証は速度制限 が切れるのを待つのではなく 変更後できるだけ早く更新されます 万一デバイスが侵害され他の 属性に嘘をついている場合は 時折ランダムに認証の更新を要求し デバイスを正直に保つことができます 証明書の発行依頼は失敗することがあります その場合 デバイスは応答しますが 一部の情報は省略されます DeviceProperties 認証が応答から省略されるか 期待される OID またはその値が省略されます 失敗には潜在的理由が多くあります デバイスに認証サーバーで ネットワーク問題の発生です 100 % 常に稼働しているサーバーはありません Apple の認証サーバーに 問題がある可能性があります または ハードやソフト ウェアが侵害されていたり Apple の純正のハードウェア でない可能性もあります 最後の 3 つの場合ではApple の認証サーバーは 検証できないプロパティの 証明書の発行を拒否します 認証に失敗する原因は 無害なネットワーク問題から 積極的攻撃までさまざまです 残念ながら MDM サーバーが正確な原因を知る 信頼できる方法はありません 障害に関する唯一の情報源はデバイス自体であり デバイスが嘘をついている 可能性があるからです MDM サーバーはどう障害を 解釈すべきでしょうか？ 認証が失敗したときに最悪の 事態を想定しないでください ゼロトラストアーキテクチャ を採用している場合は 次のように処理することになります 組織はデバイスの信頼スコアを計算し 認証の失敗や予想外に古く なるとスコアが下がります 信頼スコアの低下はサービス へのアクセス拒否など さまざまな動作が発生します デバイスにフラグを立て手動で調査や デバイスを消去して証明書を 無効にするなどです これにより 認証の失敗に 適切な対応が保証されます ACME ペイロード認証の実装に移りましょう ACME ペイロードの導入には手順が必要です プロセスの参加者を説明し 次に各手順を説明します まず iPhone iPad またはAppleTV から始めます

ほとんどの場合 これは MDM サーバーで管理されています ACME サーバーがあります これは ACME プロトコルRFC8555 を実装します そのため 組織の認証局から 顧客証明書を発行できます その証明書を発行する Apple の認証サーバーがあります

最初の段階は MDM サーバー が ACME ペイロードを含む プロファイルをインストールすることです ペイロードはデバイスが生成 する鍵のプロパティや デバイスが要求する証明書のプロパティ および ACME サーバーから証明書を 要求する方法を指定します プロファイルのインストールを開始するには デバイスは要求されたタイプの鍵を生成します 認証使用には鍵がハードウェアにバインドされ ACME ペイロードは RSA と 鍵をサポートしますが バインドされた鍵の取得には ECSECPrimeRandom を使い ECSECPrimeRandom 384 ビットキーが最良の選択です 安全性が最高のハードウェア バインドキーだからです 鍵が作成されると ACME サーバーと最初に接続します

デバイスは DirectoryURLを要求し ACME サーバーとの通信の 残りのプロセスで使用する URL を指定します その後 2 つのシステムは アカウントと注文を作成し device-attest-01 検証型を サーバーは提供します 次に ACME サーバーはノンスを生成し トークンフィールドでデバイスに送信します ACME プロトコルは証明発行に使われます しかし ここで使用する検証型は ACME プロトコルの拡張を指定する IETF ドラフトで導入され 認証の受信と顧客証明書の発行のためです

証明書は任意です ペイロードが証明書を指定する場合 デバイスが Apple に認証を要求します これは DeviceInformation の認証とほぼ同じです 同じ OID を使用し デバイスを特定する OID は 利用者登録では省略されます しかし いくつかの違いがあります ノンスは証明書に埋め込む前 にハッシュ化されます ノンスは MDM サーバーでは なく ACME から取得されます そして 認証リーフ証明書と一致する秘密鍵は デバイスが生成したものです 認証証明書は秘密鍵と一致しますが その証明書は認証以外の 目的では使用できません デバイスは ACME サーバーに秘密鍵と一致する 別の証明書を要求し この証明書は TLS に適し

デバイスは証明書署名要求を提供します ペイロードからの証明書 要求プロパティを含みます これは認証連鎖を提供します また ACME ペイロードから ClientIdentifier を提供し 通常 これはチケットのように使用されます 単一の証明書の発行に適し 繰り返しの要求を防ぐためです ACME サーバーはこの順序で 証明書を発行する前に 慎重に要求を検証する必要があります ClientIdentifier が有効で 未使用であることの確認です 認証証明書は正しい Apple CA に接続します 認証リーフ証明書の公開鍵は CSR と一致する必要があり ノンスはサーバーが送信した ハッシュと一致すべきです そして ACME サーバーは 残りの OID を評価できます 認証が失敗する可能性がある ことを忘れないでください サーバーは証明書発行の際に 失敗を検討する必要があり DeviceInformation で認証に 失敗したレビューと同様です ここから急速に仕上げをします ACME サーバーは組織 CA から顧客証明書を発行し デバイスに返します

ACME サーバーは顧客証明書 発行の最終権限者です SubjectAltName など CSR のプロパティを尊重するか 上書きするかを選択できます デバイスは証明書をキーチェーンに格納し これで ACME ペイロードの インストールが完了します

これをすべて結びつけてみましょう サーバーは通信している デバイスが主張するものだと どのように認識するのでしょうか？ デバイスは同じ秘密鍵を 複数の方法で使用します Apple から認証を取得するとき ACME サーバーから顧客証明書を取得するとき TLS を使用して他のサーバー と通信するときです 鍵はハードウェアにバインドされているため 動作はすべて同じデバイスで 行われたことがわかります そして そのデバイスを説明 する認証証明書があります これを組み合わせることで組織サーバーは アクセスを許可するときに デバイス ID を信頼できます

証明書と SCEPペイロードと同様に プロファイル内の他のペイ ロードは証明書使用のために ACME ペイロードを参照できます MDM Wi-Fi VPN Kerberos Safari を使います このシステムはすべて 認証の恩恵を受けています

デバイスは最大 10 個のACME ペイロードを持ち 同時にインストールされた認証を使用します バインドされた鍵は管理対象 のバックアップを復元すると 同じデバイスに復元する場合でも 保存されないことに注意してください 管理対象デバイス認証で他に何もしない場合は MDM 顧客 ID にACME ペイロードを使用し サーバーがどのデバイスを 管理しているか確認できます 最後にまとめましょう 管理対象デバイス認証を使用 し 複数の脅威を修正します DeviceInformation 認証を活用し信頼性評価の デバイス ID コンポーネントを改善します ACME 認証により組織のリソースにアクセスする デバイスの ID を証明することができます 管理対象デバイス認証の 実装をお待ちしております デバイス導入のセキュリティ を一緒に向上させましょう WWDC をお楽しみください ありがとうございました