生体認証とセキュアエンクレーブ

生体認証は「本人確認」ではなく「鍵の解錠条件」である

Face IDやTouch ID、Androidの指紋認証を「サーバーに顔や指紋を送って本人か確かめる仕組み」と捉えると、設計を誤ります。モバイルの生体認証が実際にやっているのは、端末内に保管された鍵へのアクセスを、生体照合の成否というローカルなゲートで制御することです。照合はネットワークを介さず端末内で完結し、生の生体データは外に一切出ません。ここを起点に、なぜ鍵が抜き取れないのか、生体認証と鍵アクセスがどう結び付いているのかを内部動作から見ていきます。

Secure EnclaveとTEE：メインOSから隔離された実行環境

鍵と生体照合を守る土台は、メインのアプリケーションプロセッサ（AP）とは分離された安全な実行環境です。AppleはこれをSecure Enclave（専用コプロセッサ）として実装し、Androidの多くの端末はArmのTrustZoneが提供するTEE（Trusted Execution Environment、信頼された実行環境）や、独立した専用チップ（GoogleのTitan M系など）として実装します。

TrustZoneはCPUを「セキュアワールド」と「ノンセキュアワールド」に時分割で切り替え、セキュアワールドでのみアクセスできるメモリ・周辺機器を物理的に区切ります。Secure Enclaveはさらに徹底しており、独自のブートROM・暗号化されたメモリ・AESエンジンを持つ独立したコプロセッサとして、メインCPUがバグや脆弱性で乗っ取られても内部状態に到達できない設計です。要点は、機密資産（生体テンプレートと鍵）をリッチ側のソフトウェアが原理的に触れない場所へ隔離していることにあります。この隔離思想はモバイル特有ではなく、/embedded/ で扱うハードウェア分離や信頼の起点（Root of Trust）の考え方と地続きです。

生体テンプレートはどこへも出ない

指紋センサーや顔認識カメラが取得した生データは、リッチ側のOSを経由せず、セキュア側へ直接（またはセッション鍵で暗号化した経路で）渡されます。セキュア側は初回登録時に生データから数理的な特徴量（テンプレート）を抽出して暗号化保存し、認証時にはその場でセンサー入力とテンプレートを比較して、返すのは一致／不一致という真偽値だけです。

この設計により、仮にアプリやOSが侵害されても、攻撃者が得られるのは「認証成否のフラグ」までで、生体データそのものは漏れません。生体情報はパスワードと違って変更できないため、「そもそも外に出さない」ことが唯一の実効的な防御になります。

Keychain／Keystoreと鍵の非エクスポート性

生体認証と対になるのが、iOSのKeychainとAndroidのKeystoreが管理する鍵です。ここで決定的に重要なのが非エクスポート性（non-exportability）という性質です。

ハードウェアに支えられた鍵は、Secure Enclave／TEEの内部で生成され、その境界の外へは平文の鍵素材として一切取り出せません。アプリが手にできるのは鍵そのものではなく、鍵を指し示すハンドル（参照）だけです。データを暗号化・復号したり署名したりしたいとき、アプリは平文と操作内容をエンクレーブに渡し、エンクレーブが内部で鍵を使って処理し、結果だけを返します。

[アプリ側（リッチ側）]                [Secure Enclave / TEE]
  key = ハンドル(参照)      -- 操作依頼 -->   実体の鍵で暗号化/署名
  暗号文/署名 <-------------- 結果のみ -----   （鍵は外に出さない）

非エクスポート性が成り立つと、鍵は端末という物理デバイスに束縛されます。端末を丸ごと複製しない限り鍵を持ち出せないため、認証情報の盗用が「デバイスの物理的奪取」まで難易度が跳ね上がります。この鍵の帰属は、コード署名で作者の同一性を担保する/mobile-development/mobile-app-signing-provisioning/ の秘密鍵管理とも問題意識が共通しています。

生体認証と鍵アクセスの「結合」

ここまでの2つ——生体照合と非エクスポートな鍵——を結び付けるのが、鍵に付与するアクセス制御条件です。鍵を生成する際、「この鍵を使うには生体認証の成功を要する」という制約を鍵の属性として刻み込めます。

• iOSではSecAccessControlに.biometryCurrentSetや.userPresenceを指定し、Keychainアイテムや鍵の利用条件として生体認証を要求します。
• AndroidではKeystore鍵生成時にsetUserAuthenticationRequired(true)を設定し、鍵を「認証で解錠されている間だけ使える」状態にします。

結合の実体はこうです。アプリが鍵で暗号操作をしようとすると、エンクレーブは「この鍵は生体認証を要求する」という属性を確認し、直前の生体照合が成功して解錠フラグが立っているかを検証します。フラグが立っていなければ操作は拒否されます。つまり生体認証の成功が鍵の解錠フラグを立て、その結果としてエンクレーブが暗号操作を許可する、という因果です。認証と鍵利用の判断がどちらも同じセキュア境界の内側で行われる点が肝で、リッチ側のアプリが「認証OKだったことにする」偽装を差し込む余地がありません。

フォールバックと解錠状態の寿命

生体認証は万能ではありません。センサーが濡れている、顔が認識されない、連続失敗でロックアウトされる、といった状況が必ず起きます。そこでフォールバックとして、パスコード／PIN／パターンという知識要素へ退避する経路が用意されます。設計上重要なのは、フォールバック先が生体照合と同格以上の強度を持つ独立した認証経路であり、これも同じエンクレーブが検証する点です。生体を回避してパスコードへ抜けても、鍵の解錠は依然としてセキュア境界内で判断されるため、防御が弱いバイパス路にはなりません。

横にスクロール

もう一つ実務で誤解が多いのが、解錠フラグ（認証済み状態）の寿命です。

AndroidのsetUserAuthenticationParametersでは解錠の有効時間（timeout）と、生体・デバイス認証情報のどちらを許可するか（authentication type）を分けて指定できます。有効時間をゼロにすれば操作ごとに必ず認証を挟む厳格モードになり、正の値にすればその秒数内は再認証なしで鍵を使えます。この寿命の長さは、利便性と、端末を短時間奪われたときの被害範囲との綱引きで決めます。なお、これらの解錠状態はアプリのライフサイクルとも関わり、バックグラウンド遷移で無効化する設計が一般的です（アプリの状態遷移そのものは /mobile-development/ios-app-lifecycle-states/ を参照）。

まとめ

モバイルの生体認証は、Secure EnclaveやTEEというメインOSから分離された実行環境の中で生体照合を完結させ、生の指紋・顔データを一切外へ出さない設計です。その照合結果は、Keychain／Keystoreが管理する非エクスポートな鍵のアクセス制御条件として使われ、認証成功が解錠フラグを立てることで初めて暗号操作が許可されます。鍵はエンクレーブの外に出ないため、操作を依頼する形でしか使えず、端末という物理デバイスに束縛されます。生体セット変更での自動無効化、独立したフォールバック経路、解錠状態の寿命管理といった仕組みは、いずれも「認証と鍵利用の判断を同じセキュア境界の内側に閉じ込める」という一貫した原則から導かれます。この鍵保護は権限モデル（/mobile-development/mobile-app-sandbox-permissions/）と組み合わさって端末内の機密を守っており、より広い暗号・認証設計の一般論は /security/ と合わせて理解すると全体像がつかめます。