モバイル開発におけるセキュリティ：定義、脅威、防御方法

主要な脅威：OWASP Mobile Top 10

OWASP Mobile Top 10とは？

OWASP（Open Web Application Security Project）は、最も危険なモバイルセキュリティ脆弱性のランキングを公開する非営利組織です。OWASP Mobile Top 10は、開発者が最初に何に焦点を当てるべきかを理解するためのリストです。2024年版では、安全でない保存、弱い認証、安全でないネットワーク通信に関する問題がランキングの上位を占めています。

M1：安全でないデータ保存 — 最も一般的な問題：パスワード、トークン、個人データが暗号化されずにSharedPreferences、NSUserDefaults、またはローカルファイルに残ります。M2：弱い認証 — サーバー側の検証の欠如、弱いパスワード。M3：安全でないネットワーク通信 — HTTPSの欠如または不正なSSL証明書検証。M4とM5は、暗号化と誤ったAPI使用に関連しています。

M6：安全でない認可 — ユーザーがリクエスト内のIDを置き換えることで別のユーザーのデータにアクセスできます。M7：コードインジェクション（SQLインジェクション、XSS）。M8：アプリ操作 — リパッケージング、コード置換。M9とM10 — サードパーティライブラリを通じたデータ漏洩とリバースエンジニアリング。これらの脅威のそれぞれに対して実証済みの対策があり、IT Sectrでは2017年からすべてのプロジェクトでこれらを適用しています。

Man-in-the-Middle（MITM）攻撃

MITM攻撃は、攻撃者がアプリケーションとサーバー間のトラフィックを傍受するときに発生します。これは、DNSスプーフィング、ARPスプーフィング、または保護されていないWi-Fiネットワークへの接続を通じて可能です。保護にはSSL/TLS証明書とCertificate Pinningが使用されます。

Certificate Pinningは、アプリケーションがサーバー証明書がアプリケーションコードに事前保存されたものと一致することを検証するメカニズムです。攻撃者がプロキシ（Burp Suiteなど）を介して証明書を置き換えても、アプリケーションは接続を拒否します。Pinningには、公開鍵ピンニング（Public Key Pinning）と証明書ハッシュピンニング（Certificate Hash Pinning）の2種類があります。

暗号化とハッシュ化：AES、RSA、SSL/TLS

対称暗号化：AES

AES（Advanced Encryption Standard）は対称暗号化アルゴリズムであり、デバイス上のデータセキュリティの基盤です。AESはデータの暗号化と復号に同じキーを使用します。AESは128、192、または256ビットのキーをサポートしています。モバイル開発では、AES-256がデバイス上のデータ（ファイル、キャッシュ、ローカルデータベースのレコード）の暗号化に使用されます。

AESモード：GCM（推奨）— データ認証を提供、CBC — ブロックチェーンを使用した基本モード、ECB — 安全でないため使用しないでください。iOSでは、AESはCommonCrypto（CCOptions）を介して利用可能で、AndroidではJava Cryptography Architecture（JCA）のCipherを介して利用可能です。重要：暗号化キーはアプリケーションコードに保存してはいけません — Keychain/Keystoreを使用してください。

非対称暗号化：RSA — 公開鍵と秘密鍵のペアを使用します。RSAは少量のデータの暗号化に使用されます — 通常はクライアントとサーバー間で対称キーを交換するためです。最小RSAキー長は2048ビット（4096推奨）です。iOSでは、RSAはSecurity Framework（SecKeyCreateRandomKey）を介して利用可能で、AndroidではAndroid KeystoreのKeyPairGeneratorを介して利用可能です。

ハッシュ化とSSL/TLS

ハッシュ化（SHA-256、SHA-3）は、データを固定長の文字列に不可逆的に変換するものです。ハッシュはデータ整合性の検証とパスワード保存に使用されます。パスワードには必ずbcrypt、scrypt、またはArgon2を使用してください — 通常のSHA-256はレインボーテーブル攻撃に対して脆弱です。SSL/TLSは、クライアントとサーバー間のネットワークトラフィックを暗号化するプロトコルです。最新の標準はTLS 1.3で、Perfect Forward Secrecy（PFS）を提供します。

TLS 1.3は以前のバージョンよりも高速です：ハンドシェイクは2回ではなく1ラウンドトリップで完了します。Androidでは、最小TLSバージョンはSSLSocketを介して構成され、iOSではATS（App Transport Security）を介して構成され、デフォルトでTLS 1.2以上が必要です。ATSは特定のドメインに対してのみ正当な理由をもって無効化できます。

安全な保存：KeychainとKeystore

iOS：Keychain

Keychain（キーチェーン）は、iOS / macOSにおけるパスワード、暗号化キー、証明書、トークンのための安全な保存領域です。Keychain内のデータは、各デバイスに固有のハードウェアキーで暗号化されます。KeychainへのアクセスはSecurity Framework（SecItemAdd、SecItemCopyMatching）を介して制御されます。Keychainはデバイスがロックされると自動的にロックされ、Secure Enclaveを使用して暗号化されます。

Android：Keystore

Android Keystoreは、アプリケーションから分離された暗号化キーのためのシステム保存領域です。Android 6.0（API 23）以降、Keystoreはセキュリティチップを搭載したデバイスでハードウェアサポート（TEE — Trusted Execution Environment）を使用します。Keystore内のキーは保護領域から外に出ることはなく、アプリケーションは暗号化および署名操作のためのハンドルのみを受け取ります。

SharedPreferencesとNSUserDefaultsは機密データの保存用に設計されていません — 平文で情報を保存します。データ保護には、EncryptedSharedPreferences（Android）を使用するか、UserDefaults（iOS）に保存する前にデータを暗号化してください。IT Sectrでは、アクセストークンとパスワードには常にKeychainとKeystoreを使用しています。

認証：OAuth 2.0、JWT、生体認証

OAuth 2.0とOpenID Connect

OAuth 2.0は、パスワードを送信せずにユーザーリソースへの安全なアクセスを提供する委任認可プロトコルです。モバイルアプリケーションでは、PKCE（Proof Key for Code Exchange）を使用したAuthorization Code Flowが最も一般的に使用されます。PKCEは認可コードの傍受を防ぎます — これはモバイルアプリケーションの必須要件です。

OpenID Connect（OIDC）は、ユーザー認証のためのOAuth 2.0上の拡張機能です。OIDCは、ユーザー情報（名前、メール、ID）を含むJWT形式のID Tokenを追加します。OAuth 2.0 + OIDCフローには以下が含まれます：ユーザーをログインページにリダイレクト、認可コードの取得、コードをトークン（access + refresh + id）と交換、APIリクエストにアクセストークンを使用。

JWT：アクセストークン、リフレッシュトークン、セッショントークン

JWT（JSON Web Token）は、JSON形式のクレームを含むコンパクトでURL安全なトークン形式です。JWTは3つの部分で構成されます：ヘッダー（タイプと署名アルゴリズム）、ペイロード（データ）、署名。アクセストークンは、APIアクセスのための短命なトークン（15〜60分）です。リフレッシュトークンは、再ログインせずに新しいアクセストークンを取得するための長命なトークン（日/週）です。

セッショントークンは、サーバーがデータベースまたはRedisにセッションを保存し、クライアントがランダムな識別子を受け取る従来のアプローチです。モバイル開発ではJWTが好まれます：サーバー側のセッション保存が不要で、すべての情報を内部に含み、検証が容易です。ただし、JWTは即座に無効化できません — これはアクセストークンの短い有効期間とリフレッシュトークンの使用によって解決されるトレードオフです。

生体認証

iOSのFace IDとTouch ID、Androidの指紋認証 — ユーザーのユニークな身体的特徴を使用する生体認証方法です。iOSでは、生体認証はLocalAuthentication（LAContext）を介して動作し、AndroidではBiometricPrompt（Android 9+）またはFingerprintManager（非推奨）を介して動作します。生体認証は、アプリのロック解除、支払い確認、保護されたデータへのアクセスに使用されます。

重要な注意点：生体認証は便利なUXですが、サーバー認証の代替ではありません。生体認証の成功後、アプリケーションはサーバーからアクセストークンを取得する必要があります。Androidでは、デバイスがカメラベースの顔認識（クラス1）ではなく、クラス3（強）の生体認証を使用していることを確認してください。

コード保護：ProGuard、R8、Root Detection

難読化：ProGuardとR8

ProGuardは、Android向けのJavaバイトコードの難読化、圧縮、最適化ツールであり、リバースエンジニアリングに対するコードのセキュリティを向上させます。R8はその後継で、Android Studio 3.4以降Gradleに組み込まれています。R8は4つのタスクを実行します：圧縮（未使用のクラスとメソッドを削除）、最適化（メソッドのインライン化、コードの簡略化）、難読化（クラスとメソッドを短い名前に変更）、事前検証（バイトコードのチェック）。

DexGuardは、拡張保護機能を備えたProGuardの商用バージョンです：文字列暗号化、リソース難読化、リパッケージング防止、APK整合性制御。ほとんどのプロジェクトではR8で十分ですが、金融および銀行アプリケーションでは、DexGuardが追加のセキュリティ層を提供します。R8はbuild.gradleを介して有効にします：minifyEnabled = trueとproguardFiles。

Root検出とJailbreak検出

Root Detection（Android）とJailbreak Detection（iOS）は、デバイスでスーパーユーザー権限が取得されたかどうかをチェックする仕組みです。改ざんされたデバイスでは、プロセスメモリの読み取り、トラフィックの傍受、コードの置換が可能です。Androidでの確認には、SUバイナリファイルの存在、テスト署名キー、非標準のビルドフラグが使用されます。

RASP（Runtime Application Self-Protection）は、実行中にアプリケーションを保護する技術です。RASPはデバッグ、リパッケージング、コードインジェクションの試みを検出し、脅威が検出されるとアプリケーションを終了します。RASPソリューションの例：Dexter、Guardsquare、Promon。RASPは実行時に動作し、異常に反応します — 実行前にコードを保護する静的難読化とは異なります。

リバースエンジニアリングは、コンパイルされたアプリケーションからソースコードを復元するプロセスです。ツール：JADX（APKデコンパイラ）、Ghidra、IDA Pro、Hopper。リバースエンジニアリングに対する保護は、難読化、文字列暗号化、整合性チェック、Root Detectionの組み合わせです。完全な保護は存在しません — 目標は、攻撃者にとってリバースエンジニアリングを十分に高価にすることです。