Android KeystoreのKey Attestation：その「鍵」は本当にハードウェアの中にいるのか？
エンジニアの諸君、お疲れ様。今日は「Android Keystore」の核心、特にKey Attestation（鍵の証明）という、一見地味だが極めて強力なセキュリティ機能について語ろうと思う。
我々の現場では、APIを叩くクライアントが「本物のデバイス」なのか、それとも「エミュレータや改ざんされたOS上のスクリプト」なのかという問いは、インシデントの9割を左右する分岐点になる。いくらサーバーサイドで強固な暗号化を施しても、入り口であるデバイスが不正なクローンであれば、すべては砂上の楼閣だ。
Key Attestationが解決する「信頼の根源」
Android KeystoreのKey Attestationとは、端的に言えば「その暗号鍵が、本当にTEE（Trusted Execution Environment）やStrongBoxといった物理的なハードウェア内で生成され、外部から抽出不可能であること」をGoogleの認証局（CA）が署名付きで証明してくれる仕組みだ。
攻撃者は、root化やエミュレータ上のフックツール（Fridaなど）を使って、暗号鍵をメモリから抜き取ろうとする。あるいは、別のデバイスで生成した鍵を流用しようと試みる。これらに対する防波堤となるのが、この「Attestation Certificate（証明書）」だ。
攻撃者の視点：どこが狙われるか
攻撃者は、Attestationの結果を偽装するために、以下のようなPoCを仕掛けてくる。
1. 証明書チェーンの偽造: Googleのルート証明書を信頼したふりをして、偽のAttestationレスポンスを返す。
2. ハードウェア・プロパティの偽装: ソフトウェア生成の鍵を、ハードウェア生成であるかのようにフラグを書き換える（これを防ぐのがAttestationの署名検証だ）。
3. リプレイ攻撃: 本物のデバイスから取得したAttestationデータを横取りし、別の端末で再利用する。
これらを防ぐには、サーバーサイドでの「証明書チェーンの検証」と「KeyUsageの厳密なチェック」が必須だ。
実装の肝：サーバーサイドでの検証（Python例）
クライアントから送られてきたAttestation証明書チェーンを検証する際、単に「署名が正しいか」を見るだけでは不十分だ。Googleが発行した証明書内の keyDescription 拡張領域（OID: 1.3.6.1.4.1.11129.2.1.17）をパースし、securityLevel が TrustedEnvironment（または StrongBox）であることを確認する必要がある。
以下に、Pythonで証明書をパースし、ハードウェア保証されているかを確認するロジックの断片を記す。
from cryptography import x509
from cryptography.hazmat.backends import default_backend
def verify_attestation_certificate(cert_der_bytes):
# DER形式の証明書をロード
cert = x509.load_der_x509_certificate(cert_der_bytes, default_backend())
# Android Key Attestationの拡張OID (1.3.6.1.4.1.11129.2.1.17)
extension = cert.extensions.get_extension_for_oid(x509.ObjectIdentifier("1.3.6.1.4.1.11129.2.1.17"))
# 実際の実務では、このextensionの中身（ASN.1構造体）をパースする必要がある
# securityLevel: 1=Software, 2=TrustedEnvironment, 3=StrongBox
# 以下の処理で、ハードウェアレベルが2以上であることを必須条件とする
attestation_info = parse_attestation_extension(extension.value.value)
if attestation_info.security_level < 2:
raise ValueError("セキュリティ警告: 鍵はハードウェア内で生成されていません！")
print("検証成功: 鍵の真正性が確認されました。")
# ※注意: parse_attestation_extensionはASN.1パーサーを用いて実装すること現場で守るべき「鉄の掟」
1. 証明書チェーンの完全検証: サーバー側でGoogleのルート証明書を保持し、必ずチェーンの最後まで辿ること。中間証明書が偽装されていないかを厳密にチェックせよ。
2. Nonce（ナンス）の活用: Key Attestationリクエスト時にサーバーから生成したランダムな値（Nonce）を必ず含め、Attestationのレスポンス内にも同じNonceが含まれているかを確認せよ。これにより、リプレイ攻撃を完全に封殺できる。
3. 信頼の失効: もしデバイスがroot化を検知したという情報（Attestation内の teeEnforced 項目などで確認可能）があれば、即座にその鍵を使用不可にする、あるいはトークンを無効化するフローを実装すること。
セキュリティチーフからの助言
多くのエンジニアが「暗号化しておけば安全」と考えがちだが、暗号化は「鍵」が守られて初めて機能する。Key Attestationは、その鍵の生存環境を証明する唯一の手段だ。
「面倒だから」とソフトウェア生成の鍵で済ませるのか、それとも数行の検証コードを書いて強固な防壁を築くのか。その選択が、数年後の大規模インシデントの有無を分けることになる。
実装で迷ったら、まずはAndroidの公式ドキュメントにある「Attestation Statement」の構造をASN.1レベルで眺めてみてほしい。セキュリティは、コードの行数ではなく、プロトコルの隅々にある「検証の不備」を突いた時にこそ、その真価が試されるのだから。
次回のブログでは、この認証基盤と組み合わせた「JWTの署名検証」の更なる深化について解説する予定だ。腕に覚えのあるエンジニア諸君、今のうちにこの基礎を完璧にしておいてくれ。
コメント