Appleデバイスの管理対象デバイスの認証
管理対象デバイスの認証は、iOS 16、iPadOS 16.1、macOS 14、tvOS 16以降の機能です。管理対象デバイスの認証では、信頼評価の一環として使用できる、デバイスのプロパティに関する強力な証拠が提供されます。このデバイスプロパティの暗号宣言は、Secure EnclaveとApple認証サーバのセキュリティに基づいています。
管理対象デバイスの認証は、以下の脅威に対する保護に役立ちます:
デバイスが攻撃されてプロパティが詐称される
デバイスが攻撃されて期限切れの認証が提供される
デバイスが攻撃されて別のデバイスの識別情報が送信される
不正なデバイスで使用するために秘密鍵が抜き取られる
攻撃者によって証明書要求が乗っ取られ、CAがだまされて攻撃者に証明書を発行する
詳しくは、WWDC22のビデオ「デバイス管理における新機能」（英語）をご覧ください。
管理対象デバイスの認証に対応しているハードウェア
認証は以下のハードウェア要件を満たしているデバイスのみに発行されます:
iPhone、iPadおよびApple TVデバイス: A11 Bionicチップ以降を搭載。
Macコンピュータ: Appleシリコンを搭載。
Apple WatchとApple Vision Proの管理対象デバイスの認証には、変更はありません。
ACME証明書登録要求での管理対象デバイスの認証
組織の発行CA（認証局）のACMEサービスによって、登録デバイスのプロパティの認証を要求できます。この認証により、デバイスのプロパティ（シリアル番号など）が正当であり、詐称されていないことが強力に保証されます。発行CAのACMEサービスでは、認証対象のデバイスプロパティの整合性を暗号学的に検証すること、およびオプションでそれらを組織のデバイスインベントリと照合することができ、検証に成功すると、そのデバイスは組織のデバイスであることが確認されます。
認証が使用される場合、ハードウェアにバインドされた秘密鍵は、証明書署名要求の一環としてデバイスのSecure Enclave内で生成されます。この要求の場合は、そのあとでACMEの発行CAがクライアント証明書を発行できます。この鍵はSecure Enclaveに紐づけられているため、特定のデバイスでのみ使用できます。これは証明書識別情報の仕様に対応する構成で、iPhone、iPad、Apple TV、およびApple Watchで使用できます。Macでは、ハードウェアにバインドされた鍵は、MDM、Microsoft Exchange、Kerberos、802.1Xネットワーク、内蔵VPNクライアント、内蔵ネットワークリレーによる認証に使用できます。
注記: アプリケーションプロセッサが攻撃された場合でも、Secure Enclaveは鍵の抜き取りを防ぐ強力な保護機能を備えています。
これらのハードウェアにバインドされた鍵は、デバイスを消去または復元すると、自動的に削除されます。鍵が削除されるため、復元後はそれらの鍵に依存する構成プロファイルが機能しなくなります。鍵を再作成するには、プロファイルが再適用する必要があります。
ACMEペイロード認証を使うと、MDMで、暗号学的に以下のことを検証できるACMEプロトコルを使用してクライアント証明書の識別情報を登録できます:
デバイスが正規のAppleデバイスであること
デバイスが特定のデバイスであること
デバイスが組織のMDMサーバで管理されていること
デバイスに特定のプロパティ（シリアル番号など）があること
秘密鍵がデバイスにハードウェア的にバインドされていること
MDM要求での管理対象デバイスの認証
MDMソリューションでは、ACME証明書登録要求時に管理対象デバイスの認証を使用する以外に、DevicePropertiesAttestationプロパティを要求するDeviceInformationクエリーを発行できます。MDMソリューションで新しい認証が必要な場合は、オプションのDeviceAttestationNonceキーを送信すると、強制的に新しい認証が取得されます。このキーを省略すると、キャッシュされた認証がデバイスから返されます。その後、デバイスの認証応答によって、カスタムOIDにデバイスのプロパティが含まれたリーフ証明書が返されます。
注記: ユーザ登録を使用する場合、シリアル番号とUUIDはどちらもユーザのプライバシー保護のために省略されます。ほかの値は匿名で、sepOSのバージョンやフレッシュネスコードなどのプロパティが含まれます。
次にMDMソリューションで、証明書チェーンのルート認証局が想定通りにApple Certificate Authority（Apple Private PKI Repositoryから取得可能）になっているかどうかを評価し、さらにそのフレッシュネスコードのハッシュがDeviceInformationクエリーで指定されたフレッシュネスコードのハッシュと同じかどうかを評価することで、応答を検証できます。
フレッシュネスコードを定義すると新しい認証が生成され、デバイスとAppleのサーバのリソースが消費されるため、現在、使用は1台のデバイスあたり7日につき1つのDeviceInformation認証に限定されています。MDMソリューションは、7日が経過するたびに新しい認証をすぐに要求するべきではありません。デバイスのプロパティが変わらない限り（例えば、オペレーティングシステムのバージョンのアップデートやアップグレードなど）、新しい認証を要求する必要はないと考えられます。さらに、新しい認証を不定期かつランダムに要求することで、攻撃されたデバイスがそれらのプロパティを詐称しようとしたときに検知するのに役立ちます。
失敗した認証の処理
認証の要求は失敗する場合があります。その場合も、デバイスはDeviceInformationクエリーまたはACMEサーバのdevice-attest-01チャレンジに反応しますが、一部の情報が省略されます。予想されたOIDまたはその値が省略されるか、認証が完全に省略されます。失敗の原因には以下のようなさまざまなものが考えられます:
Apple認証サーバと通信する際のネットワークの問題
デバイスのハードウェアまたはソフトウェアが攻撃されている可能性
デバイスが正規のAppleハードウェアでない
あとの2つのケースでは、Apple認証サーバが検証できないプロパティの認証を発行するのを拒否する場合があります。認証が失敗した正確な理由をMDMソリューションが知るための信頼できる方法はありません。これは、失敗に関する唯一の情報源がデバイス自体であり、攻撃されたデバイスが詐称している可能性があるためです。このため、デバイスからのレスポンスは失敗の原因を示すものではありません。
ただし、管理対象デバイスの認証がゼロトラストアーキテクチャの一部として使用される場合、組織はデバイスの信頼スコアを計算して、失敗した認証または予期せず古い認証の場合はスコアを低くできます。信頼スコアが低い場合、サービスへのアクセスを禁止する、デバイスに手動調査のフラグを立てる、必要に応じてデバイスをワイプして証明書を取り消すことによるコンプライアンスエスカレーションなど、さまざまなアクションがトリガされます。これによって、失敗した認証への適切なレスポンスが保証されます。