バイオメトリを使用して、アプリに特定の秘密を安全に保存する必要があります。BiometricPrompt を使用して、この秘密を暗号化および解読するために使用される CryptoObject を取得したかった (たとえば、ここで説明されているように: https://medium.com/androiddevelopers/using-biometricprompt-with-cryptoobject-how-and-why-aace500ccdb7 ) .
val promptCrypto = BiometricPrompt.CryptoObject(cipher)
biometricPrompt.authenticate(promptInfo, promptCrypto)
しかし、このメカニズムに既知の脆弱性はありますか? バイオメトリを使用せずにこの CryptoObject を取得するオプションはありますか (ルート化されたデバイスなど)? すべてのデバイスで安全ですか、それとも違いはありますか?
ご回答ありがとうございます。
Android: CryptoObject および BiometricPrompt セキュリティ。ハッキングは可能ですか？
ソフトウェアの場合、ハッキングできる可能性があります。時間と知識と努力の問題です。
しかし、このメカニズムに既知の脆弱性はありますか? バイオメトリを使用せずにこの CryptoObject を取得するオプションはありますか (ルート化されたデバイスなど)?
気づいていないというわけではありませんが、私はリバース エンジニアリングの専門家ではなく、攻撃者がモバイル アプリから秘密を抽出するためにこのセキュリティ メカニズムをバイパスする必要はないとあなたに伝えるのに十分な知識を持っている人です。
それがどのように可能であるかを理解するために読み続けてください...
バイオメトリを使用して、アプリに特定の秘密を安全に保存する必要があります。BiometricPrompt を使用して、この秘密を暗号化および解読するために使用される CryptoObject を取得したいと考えていました。
CryptoObject と BiometricPrompt を使用すると、シークレットが安全に暗号化され、Android ハードウェアに支えられた Keystore で知られている下線メカニズムで保存されます。
システム オン チップ (SoC) で信頼できる実行環境が利用できるようになったことで、Android デバイスはハードウェアに支えられた強力なセキュリティ サービスを Android OS、プラットフォーム サービス、さらにはサードパーティ アプリに提供できるようになります。
これをハッキングするのは非常に難しいかもしれませんが、賢い攻撃者はそれを破ろうとして時間を無駄にすることはありません。代わりに、攻撃者はモバイル アプリのバイナリをダウンロードし、静的分析を実行して、コード内で使用する関数を見つけます。暗号化が解除された後、インストルメンテーション フレームワークを使用して実行時にこの関数にフックし、彼が制御するコマンド アンド コントロール サーバーにシークレットを抽出し、抽出したシークレットを使用して攻撃を自動化できるようにします。シークレットがモバイル アプリの現在のユーザーに限定されている場合、この種の攻撃の到達範囲は制限されます。
最も人気のある計測フレームワークの 1 つはFridaです。
独自のスクリプトをブラック ボックス プロセスに挿入します。任意の関数をフックし、暗号 API をスパイし、プライベート アプリケーション コードをトレースします。ソース コードは必要ありません。編集して保存すると、すぐに結果が表示されます。コンパイル手順やプログラムの再起動は必要ありません。
ここでの結論は、シークレットをモバイル アプリにどれほど安全に保存したとしても、モバイル アプリをリリースした瞬間からシークレットをパブリックと見なす必要があるということです。
モバイル アプリ内からサード パーティの API に直接アクセスすることがよくあります。そのため、モバイル アプリはそれらにアクセスするためのシークレットを持っている必要があります。
このアプローチの問題は、攻撃者が秘密を盗まないことを保証できないと、このサービスの請求額が上限に達したときにのみ、秘密が侵害されたことを知る可能性があることです. 最悪の場合、データ侵害を受けたことを知らされて初めて秘密が漏えいしたことに気付くかもしれませんが、今ではあなたのビジネスの評判は深刻な影響を受けているか、取り返しのつかないほど傷ついています。ヨーロッパのGDPRなど、法律違反による支払い。
したがって、私のアドバイスは、サードパーティのサービス/API へのアクセスを制御することを常にバックエンドに委任することです。詳細については、私の記事 Using a Reverse Proxy to Protect Third Party APIs を参照してください。
この記事では、まずサード パーティ API とは何か、およびモバイル アプリ内からサード パーティ API に直接アクセスしてはならない理由を学習します。次に、リバース プロキシとは何か、モバイル アプリで使用されるサード パーティ API へのアクセスを保護するためにリバース プロキシを使用する必要がある場合とその理由について説明します。
このリバース プロキシにアクセスするにはまだシークレットが必要だと言うかもしれませんが、それは事実ですが、今では、すべての防御手段を適用できる、完全に制御できるバックエンドのモバイル アプリにシークレットを 1 つだけ含めています。不正使用を監視するか、抑制するか、完全にブロックすることが適切であると判断した場合。サード パーティのサービスや API に驚くような料金が発生することはもうありません。これらのサービスや API は、お客様が制御するこのバックエンドを介してアクセスされるようになったからです。
肝心なのは、モバイル アプリは、管理下にあるバックエンドとのみ通信する必要があり、サードパーティの API サービスへのアクセスは、管理下にある同じバックエンドによって行われる必要があるということです。このようにして、攻撃面を 1 か所だけに限定し、保護対象の価値と同じ数の防御層を採用します。
上記で、適切と思われる防御策を適用できることを述べました。モバイルアプリの API REST を保護する方法についての質問に対するこの回答を読むことをお勧めします。、特に「API サーバーを保護する」セクションと「考えられるより良い解決策」のセクションを参照して、いくつかのオプションを理解してください。
セキュリティに関する質問への回答では、常に OWASP 財団の優れた成果を参考にしたいと思っています。
OWASP API セキュリティ プロジェクトは、安全でない API の潜在的なリスクを強調し、これらのリスクを軽減する方法を示すことで、ソフトウェア開発者とセキュリティ評価者に価値を提供しようとしています。この目標を促進するために、OWASP API セキュリティ プロジェクトは、トップ 10 の API セキュリティ リスク ドキュメントと、API を作成または評価する際のベスト プラクティスのドキュメント ポータルを作成および維持します。
OWASP モバイル セキュリティ プロジェクト - 上位 10 のリスク
OWASP モバイル セキュリティ プロジェクトは、開発者とセキュリティ チームが安全なモバイル アプリケーションを構築および維持するために必要なリソースを提供することを目的とした集中型リソースです。このプロジェクトを通じて、私たちの目標は、モバイル セキュリティ リスクを分類し、それらの影響や悪用の可能性を減らすための開発制御を提供することです。
モバイル セキュリティ テスト ガイド (MSTG) は、モバイル アプリのセキュリティ開発、テスト、およびリバース エンジニアリングに関する包括的なマニュアルです。