UIDAIがmAadhaarを終了、新「Aadhaar」アプリへ——“選択的データ共有”を軸にKYCの常識が書き換わるタイミングです

今日の深掘りポイント

• 「選択的データ共有」は“全部見せる身分証”から“必要最小限の属性提示”へ舵を切る動きです。検証側（バンキング、通信、フィンテック）は、受け取るデータが減る前提でワークフロー・監査証跡・詐欺対策ロジックを再設計する必要があります。
• 移行期は攻撃者の好機です。「KYC再登録」「mAadhaar終了に伴う更新」を装うフィッシング、偽アプリ、QRコード悪用が確実に増えます。広報・詐欺対策・SOCの横断連携を前倒しで回すべき局面です。
• 技術的リスクの主戦場はAPIから“QR・深いリンク・モバイルSDK・生体ロック運用”に移ります。Android App Links / iOS Universal Linksの厳格化、QR署名検証、SDKサプライチェーン管理を最優先で固めるべきです。
• 信頼性・実現性は高く、短期の行動がそのままサービス継続性に直結します。日本企業でも、インド子会社・現地パートナーを通じたKYCや労務・福利厚生の本人確認に波及するため、現地の依存関係を棚卸ししておくと被害を避けやすいです。
• “顔認証＋バイオメトリック・コントロール”の強化で不正アクセスは減らせますが、実務の落とし穴は“利用者に解除させる”社会工学と“共有端末”です。人と端末、両輪での統制設計が鍵になります。

はじめに

インドのUIDAIが長年のmAadhaarアプリを段階的に終息させ、新たな「Aadhaar」アプリへ移行する方針を打ち出しました。新機能の核は、取引ごとに本当に必要な属性だけを相手に提示する“選択的データ共有”、そしてQRベースのアイデンティティ共有や顔認証、バイオメトリック・ロックなどの本人確認強化です。十億人規模のデジタルID基盤のUXとセキュリティ・モデルが変わるということは、KYCやアカウント開設、SIM発行、補助金配賦など官民の基幹プロセスが再設計を迫られることを意味します。

足元では、この移行が現実的かつ短期で波及する可能性が高く、機能面の改善も期待できます。一方で、移行期特有のリスク（偽アプリ、意図しない互換性崩れ、SDKのサプライチェーン問題、利用者の混乱に乗じた詐欺）は、SOCと事業部の両方に負荷をかけます。いま手を打てば被害は減らせます。後回しにすれば、KYC断や不正口座開設の増加でコストが跳ねます。

本稿では、公開情報に基づく事実の整理と、現場で効く示唆を掘り下げます。

参考情報:

• Biometric Updateによる報道（UIDAIの移行と機能概要、ダウンロード動向）https://www.biometricupdate.com/202605/uidai-shifts-aadhaar-users-to-new-app-with-selective-data-sharing

深掘り詳細

いま公表されている事実（報道ベース）

• UIDAIはmAadhaarアプリを廃止し、新しい「Aadhaar」アプリへの移行を進めていると報じられています。新アプリは“選択的データ共有”を核に、QRコードを用いたアイデンティティ共有、顔認証、バイオメトリック・コントロール（ロック/アンロック等）を備えるとされています。
  出典: Biometric Update報道 [リンク上掲]
• 利用者は特定の取引に必要な情報のみを共有でき、個人情報の露出を抑える設計が示されています。とくに共有端末での不正アクセス抑止を狙った機能が強調されています。
  出典: 同上
• 新アプリは公開から短期間で数千万規模のダウンロードがあったと報じられており、利用者の関心が高いことがうかがえます（報道は3カ月で2,100万超のダウンロードと伝達）。
  出典: 同上

※上記はメディア報道に基づく事実整理です。公式ドキュメント・仕様の細部は今後の公表で変動する可能性があります。

編集部のインサイト（示唆と難所）

• データ最小化の本格導入が“検証側”の責任を増やす
  選択的データ共有は、過剰情報の提示（生年月日・住所フルセット等）に依存した“ゆるいKYC”を是正できます。ただし、検証側は「どの属性が目的達成に必要十分か」をリスクベースで定義し、監査可能な形で同意・検証・保存期間を設計し直す必要があります。属性が減るほど、プロセスの脆弱個所（同姓同名・属性の組合せ爆発）に表面化するので、ルールベース/機械学習の詐欺検知の特徴量も刷新が必要になります。
• 攻撃面の重心は“モバイルUX”と“SDK”へ
  従来のAadhaar連携はAPIやOTP中心でしたが、QRやアプリ間連携、顔認証の導入で、攻撃者の投資先は“偽アプリ”“オーバーレイ”“権限悪用”“SDKの混入/置換”に寄ります。特にインテント/ディープリンクの取り扱いとQR署名検証の実装品質が成否を分けます。
• 生体ロックは万能ではない
  生体を「ユーザーが自分でロック/解除」できるのは強力ですが、現実には「解除させる」社会工学に晒されます。家族で端末を共有するケースも多く、本人意思に反する解除も起こり得ます。プロセス面の二段階承認や、解除後のハイリスク取引クールダウン（時限制限）といった非技術的統制が効いてきます。
• 移行の“隙”をどう埋めるか
  実装の断絶やバージョン非互換は、KYC中断や再登録詐欺を誘発します。BFSI/通信の現場では「旧/新フローの併存」「フェールクローズの明示」「移行時専用のモニタリング・ダッシュボード」を用意し、異常率の上振れを可視化して短期で潰す体制が肝要です。

脅威シナリオと影響

以下は編集部の仮説に基づく想定シナリオです。MITRE ATT&CKの戦術カテゴリに沿って記述します（技術名は代表例です）。

• シナリオ1: 「mAadhaar終了」を餌にしたKYC再登録フィッシング
  • 想定手口: SMS/WhatsApp/メールで偽の“新Aadhaarアプリ”やKYC更新サイトに誘導。偽アプリにQRスキャン機能や顔認証風UIを仕込み、属性やワンタイムコード、生体画像を収集。
  • ATT&CK整合: Initial Access（モバイル・フィッシング/悪性アプリ配布）、Credential Access（オーバーレイ/入力情報の取得）、Collection（機密情報収集）、Exfiltration（アプリ層での送信）。
  • 影響: アカウント乗っ取り、偽口座開設、SIMスワップ、ローン不正申請の増加。
• シナリオ2: QRコードの中間者/リレー攻撃
  • 想定手口: 攻撃者が“検証端末”を装い、ユーザーに正規アプリでQRを提示・読み取りさせた後、トークン/属性を別の依頼者にリレー。署名検証が甘いと通過。
  • ATT&CK整合: Adversary-in-the-Middle（セッション仲介）、Defense Evasion（検証不備の悪用）、Exfiltration。
  • 影響: 正規ユーザーの同意をすり抜けた属性流用、本人なりすましの横行。
• シナリオ3: モバイルSDKのサプライチェーン汚染
  • 想定手口: Aadhaar検証/QR読み取り/顔認証のサードパーティSDKに悪性コードが混入。ビルド工程や更新チャネルを狙い、検証側アプリから広域にデータ流出。
  • ATT&CK整合: Supply Chain Compromise、Defense Evasion（コード署名悪用/難読化）、Exfiltration（正規チャネル偽装）。
  • 影響: 大量のPII流出、KYC不正のスケール化、規制対応コストの急増。
• シナリオ4: 生体ロックの社会工学的解除と時間差悪用
  • 想定手口: サポート詐称で「解除しないとサービス停止」と脅し、ユーザーに生体ロックを解除させた直後に高額取引を実行。解除イベントの通知が機能しても、即時処理で逃げ切る。
  • ATT&CK整合: Social Engineering（影響/操作）、Impact（不正送金/契約）。
  • 影響: 高額不正・口座開設の成功率上昇。対策が遅いとブランド毀損が拡大。
• シナリオ5: 共有端末・越境データ残留による“意図せぬ同意”
  • 想定手口: 家族、業務用共有端末での自動ログインやキャッシュにより、意図しないデータ共有が発生。アプリ間のディープリンク設定不備で別アプリがトークンを横取り。
  • ATT&CK整合: Credential Access（セッションハイジャック/トークン奪取）、Defense Evasion（権限乱用）。
  • 影響: 低コスト反復のアカウント乗っ取り、低額・多数回の不正起票。

インパクトの幅は広いですが、共通する要諦は「利用者の混乱」と「検証側の実装揺らぎ」を突く点です。移行初期に集中しやすいため、短期の観測と封じ込めが効果的です。

セキュリティ担当者のアクション

• 事業・法務・詐欺対策の即時連携
  • 自社/子会社/委託先でAadhaar連携が絡むフロー（口座開設、KYC再確認、SIM、ローン、助成）を棚卸しし、旧/新アプリ両対応の暫定ルールとフェールクローズ戦略を策定します。
  • 属性最小化に合わせ、同意管理・保存期間・利用目的の再定義と監査証跡（誰が・どの属性を・何の目的で・いつ検証したか）をログに落とし込みます。
• エンジニアリング（モバイル/バックエンド）
  • QR/トークンの検証を“厳格に”実装し、署名・有効期限・スコープを必須化します。ディープリンクはAndroid App Links / iOS Universal Linksに限定し、カスタムURLスキームは撤廃または高リスク取扱いにします。
  • 新旧SDKの差分をセキュリティレビューし、SBOMの取得、コード署名/更新チャネルの検証、テスト用証明書残存チェックを行います。ビルドパイプラインに依存するサプライチェーン検査（依存関係固定、整合性検証）を組み込みます。
  • RASP/Frida/Magisk等の計測器検知、ルート/Jailbreak検知、オーバーレイ防御、画面録画制御など、モバイル耐タンパ性を引き上げます。
• SOC/検知運用
  • 「KYC再登録/アプリ移行」を鍵語にしたSMS/メール/WhatsAppのキャンペーン監視を強化し、ドメイン/短縮URL/証明書フィンガープリントのハンティングプレイブックを整備します。
  • アプリ内でのQRスキャン失敗率・再試行回数・深いリンク起因の異常遷移・生体ロック解除直後の高リスク行動をユースケース化し、しきい値ベースの一時ブロックや追加検証を自動適用します。
• フロント対応と教育
  • 正規の移行手順と“しないことリスト”（非公式ストアからのダウンロード禁止、電話越しの生体ロック解除指示に従わない等）を、プロダクト内メッセージとオウンドメディアで周知します。
  • 共有端末利用者向けに「終了時の強制ログアウト」「PIN再認証」「ロック解除後のクールダウン」をUXとして実装し、誤操作・意図せぬ同意を抑制します。
• レジリエンスと危機管理
  • 新アプリ障害時のKYC継続策（オフラインKYCや代替本人確認）を決め、詐欺対策の緩和条件を明文化します。移行週は有人審査の増勢に備え、審査SLAとリジェクト基準を調整します。
  • インシデント・コミュニケーションの雛形（KYC再登録詐欺への注意喚起、偽アプリ報告窓口、補償方針の骨子）を事前に用意します。

最後に、今回の動きは“ユーザーが見せるものを選べる”という健全な方向性です。ただし、価値は実装と運用で初めて立ち上がります。移行期の混乱を最小化し、長期での不正コスト削減に繋げるために、プロダクト・詐欺対策・SOCの三位一体で先手を打つことが、もっとも費用対効果の高い一手になります。