Android IKEv2: ユーザー証明書と CA は別の役割を担う
片方は端末が誰かを証明し、もう片方はどのゲートウェイを信頼するかを決める。Android の IKEv2 プロファイルが両者を分けるのは、ハンドシェイクがそう要求するからだ。
Android の IKEv2 画面でユーザー証明書と CA 証明書の両方を求められると、同じものを二度求められているように見える。そうではない。IKEv2 は一つの交換の中で双方を両方向に認証し、端末は方向ごとに異なる役割を担う。自分が誰であるかを示すことと、どのゲートウェイを信じるかを決めることだ。ユーザー証明書は前者に答え、信頼された CA は後者に答え、どちらも他方を代われない。
一つの交換における二方向の認証
IKEv2 は二段階で制御チャネルを築く。第一段階はアルゴリズムと鍵を交渉し、第二段階の IKE_AUTH は双方から AUTH ペイロードを一つずつ、その識別子とともに運ぶ。ペイロードは交換に対する署名または MAC であり、受信側がすでに信頼するものと照合して検証される。
ゲートウェイは自身の証明書で自分を証明し、端末は信頼するルートまでの連鎖を検証し、証明書の識別子が到達しようとしたゲートウェイと一致するかを確かめる。端末は自身の資格情報で自分を証明し、ゲートウェイはそれをクライアント証明書を発行した CA と照合する。
これが二つの欄の背景にある仕組みのすべてだ。ユーザー証明書は端末が自分について述べるものであり、CA の欄は誰を信じるかという宣言である。片方だけのプロファイルは相互認証を完了できず、再試行しても変わらない。失敗の見え方も異なる。ユーザー鍵がなければ端末は署名自体を作れず、信頼のアンカーがなければゲートウェイの証明書を受け入れられない。
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Android のプロファイルビルダーが求めるもの
Android の IKEv2 プロファイルビルダー は、認証方式を一つの証明書モードとしてではなく個別に公開している。デジタル署名方式はユーザー証明書、秘密鍵、サーバーのルート CA を取る。他の方式はユーザー名とパスワード、または事前共有鍵を取る。
この署名をよく読むべきだ。上記の仕組みがそのまま表れている。ユーザー名とパスワード方式に秘密鍵の欄はなく、PSK 方式にゲートウェイの信頼アンカーの欄はない。証明する内容が違うからだ。証明書の欄にパスワードを貼り付けると、IKE_AUTH で失敗するプロファイルができ、そのメッセージはどちらにも触れない。
デジタル署名方式で文書化されている秘密鍵の種類は RSA だ。IPsec や証明書という名前のメニューは ECDSA 対応を意味せず、その前提で組んだプロファイルはネットワークに届く前にプラットフォームの API で失敗する。
公開ユーザー証明書だけでは足りない理由
AUTH ペイロードはクライアントの秘密鍵で交換に対して作る署名だ。公開証明書はゲートウェイが署名を確認できるようにするが、署名を作るには鍵が要る端末には何もしてくれない。.crt だけを取り込み 鍵を置き去りにする のが、この失敗の最も一般的な形である。
Android の鍵基盤もそれを映している。クライアント識別子の選択は KeyChain を通り、対応する秘密鍵へのアクセスを要求する。証明書の項目だけでは足りない。登録パッケージやデバイス管理が両者をまとめて導入するのが通常の道であり、ファイルを手で複製するのは普通ではない。
つまりプロファイルの二項目は証明書束とその複製ではない。一方はプラットフォームが署名に使える鍵ペアであり、他方は比較対象となる信頼のアンカーだ。二つの独立した事実として確認する。このプロファイルは署名できるか、誰を信じるかを知っているか。
信頼のアンカーはアプリに属し、端末には属さない
ユーザーストアにルートを入れても、すべての Android アプリがそれを信頼するわけではない。Android 7 以降、アプリはネットワークセキュリティ設定で自ら選ぶ必要があり、それ以前はユーザーが入れた CA がもっと広く受け入れられていた。信頼の設定はアプリごとに違い、信頼素材を自前で管理する VPN クライアントはユーザーストアを見ないこともある。だから同じ CA ファイルが一方のクライアントで機能し、他方では無視されたように見える。
そこから二つの所有モデルが生まれる。システム管理のプロファイルは端末の証明書インストールや管理者登録を使い、意図した CA を参照する。アプリ管理の VPN は自前の信頼素材と文書化された取り込み口を持ち、Android の設定画面とは完全に別でありうる。壊れた連鎖を直す場所もそこだ。
何かを取り込む前にどちらのモデルかを決め、その後に有効なプロファイルの信頼選択を確認する。事業者の指示とクライアントのメニューが食い違う場合、その導入ではクライアントの文書化された挙動が優先するが、CA は検証できる経路で事業者から来なければならない。ファイル名は発行者を示す証拠ではない。
先にモード、次にファイル
証明書モードにはクライアントの鍵ペア、ゲートウェイ側の発行 CA、ゲートウェイ証明書の信頼アンカー、そしてその証明書が持つべき識別子への期待が要る。ユーザー名とパスワードは鍵ペアを資格情報に置き換えるが、ゲートウェイへの信頼条件は残る。PSK は両方を共有秘密に置き換え、信頼モデルを単純化するのではなく変えてしまう。
どれを選んでも通常の検証は有効のままにする。検証しない設定は CA の欄が存在する理由の確認を外すだけで、欠けた信頼アンカーを直さない。接続がそれなしで通るからといって任意のサーバー証明書を受け入れるのも同じことだ。
そのうえで正しい場所で確認する。素材を取り込み、一度接続し、接続の詳細でゲートウェイの識別子が期待どおりで、意図した方式が報告されていることを確かめる。誤った方式でつながった接続はまだ理解できていない設定であり、事業者がポリシーを厳しくした時点で失敗する。