iOS Ad Hoc配布における端末認証と技術的証拠力
本人確認、パスキー等のログイン認証、UDID、コード署名、配布ログおよび同意記録を組み合わせた場合の評価
1. 結論
ただし、「指定端末だけにファイルを配布した」と「指定端末だけがアプリを実行できる」は同じではない。IPAファイル自体は複製可能だが、通常の非脱獄iOS端末では、Provisioning Profileに登録されていないUDIDの端末でインストール・起動することは困難である。
したがって、証明文には次の表現が適している。
本人確認済み利用者に紐付けた特定UDIDのiOS端末だけで、正規署名されたアプリをインストール・実行できるよう制限し、その申請、配布、ダウンロード、初回起動および同意の記録を保存した。
2. 証拠を構成する仕組み
| 証明したい事項 | 使用する仕組み | 主な記録 |
|---|---|---|
| 誰に許可したか | 本人確認、利用者ID | 確認方法、確認日時、利用者ID |
| 本人が認証操作したか | パスキー、OTP、多要素認証 | 認証方式、成功日時、認証イベントID |
| どの端末を許可したか | UDID登録 | UDIDまたはその保護値、申請・承認履歴 |
| どのアプリを対象としたか | IPAのSHA-256 | ファイル名、バージョン、ハッシュ値 |
| 正規のアプリか | Apple Distribution証明書によるコード署名 | Team ID、証明書フィンガープリント |
| 指定端末だけで実行可能か | Ad Hoc Provisioning Profile | Profile UUID、App ID、許可UDID、有効期限 |
| いつ配布・取得されたか | 認証付き配布サーバ | 発行・アクセス・ダウンロードログ |
| 端末で起動されたか | 初回起動時のサーバ照合 | 初回起動日時、アプリ版、案件ID |
| 何に同意したか | 同意画面と操作記録 | 規約版、表示内容のハッシュ、同意日時 |
| ログが後から変えられていないか | ログのハッシュ化・署名・外部保管 | 日次ハッシュ、署名値、保管先記録 |
3. 配布から同意までの推奨フロー
全段階に共通の「配布案件ID」を割り当てる。これにより、本人確認、UDID登録、署名済みIPA、ダウンロード、初回起動、同意記録を一つの証拠系列として追跡できる。
4. Ad Hoc配布が直接保証する範囲
Ad Hoc Provisioning Profileは、App ID、Team ID、配布証明書、許可されたUDID、Entitlements、有効期限などを結び付ける。iOSはコード署名とProfileを検証し、条件に合わない端末での実行を拒否する。
| 項目 | Ad Hocで確認できること | Ad Hocだけでは確認できないこと |
|---|---|---|
| 配布元 | 特定のApple Developer Teamに対応する鍵で署名されたこと | 実際にソースコードを書いた個人 |
| アプリ | 署名後に署名対象部分が変更されていないこと | アプリ内容が法的・業務的に適切であること |
| 端末 | 実行端末のUDIDが許可リストに含まれること | その端末を現在操作している人物 |
| 利用者の意思 | 対象外 | 契約や規約への本人の同意 |
| ファイル経路 | 対象外 | IPAが第三者にコピーされなかったこと |
5. 複製・改ざん・なりすましの可能性
5.1 IPAファイルの複製
IPAはデジタルファイルなので複製そのものを完全には防止できない。ただし、複製先がProfileに登録されていない端末であれば、通常のiOS環境ではインストールまたは起動できない。
5.2 アプリの改ざん
実行ファイル、Framework、署名対象リソース、Entitlements、Provisioning Profileなどを変更すると、コード署名との整合性が崩れる。iOSは署名を検証するため、正規署名を維持したまま改ざんアプリを通常端末で実行することは困難である。
ただし、アプリが後から取得するHTML、画像、設定データ、AIモデルなどは、コード署名の対象外になることがある。これらにはHTTPS、署名付きマニフェスト、SHA-256照合などを別途適用する。
5.3 配布元・利用者へのなりすまし
配布元へのなりすましは、Apple Developerアカウントまたは配布用秘密鍵が盗まれた場合に現実化する。利用者へのなりすましは、本人確認や認証方式が弱い場合、または認証済みセッションが盗まれた場合に起き得る。
| 想定行為 | 通常環境での結果 | 評価 |
|---|---|---|
| IPAを未登録端末へコピー | 通常はインストール・起動不可 | 実行成功の可能性は低い |
| IPAの内容を変更 | 署名不一致 | 正規署名の維持は困難 |
| Profile内のUDIDを書き換え | Profileの署名が無効 | 通常は使用不可 |
| 第三者の証明書で再署名 | 正規配布元と異なる署名になる | 証拠上識別可能 |
| 正規秘密鍵を窃取して再署名 | 正規配布元になりすませる可能性 | 重大。鍵管理が必須 |
| 脱獄端末で検証を回避 | 通常の前提を外れる | 利用規約・検知・拒否が必要 |
6. 残存リスクと対策
| 残存リスク | 推奨対策 |
|---|---|
| Apple Developerアカウントの乗っ取り | 多要素認証、Account Holder/Adminの最小化、操作履歴の定期確認 |
| 配布用秘密鍵の窃取 | 限定Macまたは保護されたCIで管理、エクスポート制限、失効手順の整備 |
| 管理者による不正なUDID追加 | 二者承認、追加・削除履歴、定期棚卸し |
| 端末の貸与・譲渡・盗難 | アプリ起動時の利用者再認証、端末・利用者のサーバ側失効 |
| ダウンロードURLの漏えい | 短時間・一回限りのURL、認証済みセッションへの紐付け |
| ログの事後改変 | 追記専用ログ、ハッシュチェーン、署名、別管理主体または外部ストレージへの保管 |
| 脱獄端末 | 利用禁止規定、端末健全性の確認、異常時のアクセス拒否 |
7. 保存すべき監査記録
- 配布案件ID、利用者ID、本人確認方法・確認日時
- パスキー、OTP等の認証方式、認証成功日時、イベントID
- UDIDの保護値、端末登録申請・承認日時
- App ID、Bundle ID、Team ID、アプリバージョン
- Provisioning Profile UUID、作成日、有効期限
- IPAのSHA-256ハッシュ
- 署名証明書のシリアル番号またはSHA-256フィンガープリント
- 配布URL発行、アクセス、ダウンロード完了日時
- 初回起動日時、サーバ照合結果
- 表示した規約の版番号・本文ハッシュ、同意日時
- 記録全体または日次ログのハッシュ、電子署名、保管記録
UDIDは端末識別情報であるため、不要な平文保存を避け、用途に応じて暗号化またはHMAC等による保護値として保存する。単純なハッシュだけでは、候補値を把握している者による照合を防げない場合がある。
8. 最終評価文
本人確認、強固なログイン認証、UDIDとの紐付け、Ad Hocコード署名、認証付き配布、初回起動確認および同意記録を一連の監査証跡として保存することで、指定した本人の指定端末だけにアプリの実行を許可したことを、高い技術的確度で立証できる。
IPA自体の複製は理論上可能であるが、通常の非脱獄iOS端末と適正な鍵・アカウント管理を前提とすれば、未登録端末での実行、署名を維持した改ざん、正規配布元へのなりすましは困難である。
ただし、本方式は単独で利用者本人の法的な電子署名を成立させるものではない。本人性および意思表示は、本人確認、認証、同意操作および改変防止された監査ログとの組合せによって説明する。
No responses yet