web-dev-qa-db-ja.com

PSD2準拠の2要素認証

PSD2によれば、多要素認証の要素は独立している必要があるため、1つの要素の侵害によって他の要素が侵害されることはありません。

これはディレクティブからの記事です：

*第9条

要素の独立性、

  1. 支払いサービスプロバイダーは、第6条、7条、および8条で言及されている強力な顧客認証の要素の使用が、技術、アルゴリズム、およびパラメーターに関する措置の対象となることを保証するものとします。他の要素の信頼性を損なう。
  2. 強力な顧客認証の要素または認証コードが携帯電話やタブレットなどの多目的デバイスを介して使用される場合、決済サービスプロバイダーはセキュリティ対策を採用して、多目的デバイスの侵害によるリスクを軽減するものとします。
  3. パラグラフ2の目的のために、緩和策には以下のそれぞれが含まれるものとする。（a）多目的デバイス内にインストールされたソフトウェアによる、分離された安全な実行環境の使用。 （b）ソフトウェアまたはデバイスが支払人または第三者によって変更されていないことを保証するメカニズム、または変更が行われた場合にそのような変更の影響を軽減するメカニズム。*

問題は、この場合、独立していると考えられるものは何ですか？

次のシナリオを想像してみましょう：

顧客は自分の電話のブラウザーを使用して、オンラインバンキングのWebサイトにアクセスします。認証には、パスワードと別の要素（所有に基づく）が必要です。

2番目の要素がSMSを介して電話に送信されるワンタイムパスワードである場合、1つのマルウェアで電話を危険にさらし、キーロガーをインストールしてパスワードを盗み、=を盗みます。 SMS届き次第。

SMSを介したこのOTPに基づくことはできません。

ここで、SMS OTPがプッシュ通知に置き換えられていると仮定します（お客様は以前に銀行のモバイルアプリケーションをインストールする必要があります）。正確な実装にはいくつかの可能性があります。

  • oTPはプッシュ経由で送信されます

  • 承認ウィンドウがポップアップし、ユーザーは承認ボタンをタップする必要があります（Googleが行うように）

  • cAPTCHAがポップアップし、ユーザーはそれを解決する必要がある

  • ソフトトークンを使用したOTP生成

  • 等.

上記のソリューションのいずれかの場合、攻撃者が電話のOSの脆弱性を悪用してroot権限を取得できる場合、攻撃者は顧客のパスワードを盗み、少なくとも理論的には2番目の認証要素でトランザクションを検証することができます（一種のリモートアクセスツール）。

ユーザーエクスペリエンスの理由から、ハードトークンも使用できません。

AndroidとiOSの両方で使用される別個のサンドボックスは、ディレクティブの次の部分を満たす安全な実行環境と見なされますか？

多目的デバイス内にインストールされたソフトウェアによる、分離された安全な実行環境の使用

規制を満たし、顧客にとっても便利な効果的なソリューションは何ですか？

authenticationmulti-factorbanksregulation
9
Richard Leonard Kirner

tl; dr;誰も確かに言うことはできません、そしてこれは非常に議論の余地があります

少し歴史：「信頼された実行環境」から「安全な実行環境」への変更がありました。それはここに文書化されています： https://www.eba.europa.eu/documents/10180/1761863/Final+draft+RTS+on+SCA+and+CSC+under+PSD2+（EBA-RTS-2017 -02）.pdf

（私が知っている）業界のほとんどは、これがハードウェアベースのTEEが要件ではないことを意味することに同意します。そのドキュメントにはいくつかの理由があります。

記事6(2)（現在の記事9(2))は分離を参照せず、2.2.bのみを参照しています。コメント[10]と[11]そのため、EBAは条項に変更を加えていませんが、コメントi）に関して、EBAはPSPが能力の範囲内のリスクのみを軽減できることに同意します。EBAは条項に変更を加えました6(3)（現在の記事9(3))は、がハードウェア自体ではなく、PSP。

EBAは、複数の要求を拒否して、実行環境の分離を実現する方法をより具体的に示しました。このことから、適切なソフトウェアの実装のみを気にする必要があることがわかりますが、それはどういう意味ですか？掘り下げてみましょう。

曖昧な言葉の少ないこの古いドキュメントがあります： https://www.eba.europa.eu/documents/10180/1548183/Consultation+Paper+on+draft+RTS+on+SCA+and+CSC+ ％28EBA-CP-2016-11％29.pdf

  1. さらに、認証手順では、認証コードの生成、送信、使用を含む認証手順のすべてのフェーズを通じて、支払者に表示される情報の機密性、信頼性、および完全性を確保する必要があります。そのため、トランザクションの金額と受取人に関する情報が表示されるチャネル、デバイス、またはモバイルアプリケーションは、チャネル、デバイス、またはモバイルアプリケーションから独立している、または分離されている必要があります支払いの開始に使用されます。これは、たとえば、独立したチャネルを介して行うことができ、支払いトランザクションの開始プロセスを通じてトランザクションの詳細が操作されるのを防ぎます。

これらすべてを考慮すると、プラットフォームサンドボックスの使用は完全に準拠したソリューションであると私は思います。それは最も安全なものではないかもしれません。モバイルプラットフォームの話をすると、それはすべて理にかなっています。サンドボックスがないため、Web環境はさらに混乱します。

3
Dissimilis