web-dev-qa-db-ja.com

同じチャレンジが複数回送信された場合、デビットカードはどのようにして異なる回答を提供できますか?

私は「PostFinance」デビットカードでのみ銀行業務を行っています。サインインプロトコルは次のように機能します。

  1. Webフォームにユーザー名とパスワードを入力します。
  2. ウェブサイトで9桁のチャレンジ番号を取得します。
  3. デビットカードを挿入したオフラインのスタンドアロンカードリーダーにチャレンジ番号を入力します。
  4. カードリーダーにPIN)と入力します。
  5. カードリーダーから9桁の応答番号を取得します。
  6. Webフォームに回答番号を入力します。

これはある種の非対称暗号化であり、暗証番号でロック解除された秘密鍵を含むカード、チャレンジ番号に「署名」し、銀行が「公開」(実際には公開ではない)鍵で署名を検証していると思いました。

しかし、それから私は、攻撃者/セキュリティ研究者が何度もチャレンジ「1」に挑戦することを最初に何であるかとぼんやりと思っていました。答えは毎回異なっていました:

最初の3桁の継ぎ目は、小さなステップ(〜10サンプル)で単調に増加します。他の6桁は、私が選んだパターンに従わなかった、つまりランダムに見えた。

誰かがこれがどのように機能するか知っていますか?

1
Nobody

ほとんどの場合、関連するカウンターがあります(または、カードまたはリーダーのいずれかに内部時計とバッテリー、タイムスタンプが装備されている場合はさらに良いです)。

ここに含まれる秘密鍵は、対称鍵または非対称鍵のいずれかである可能性があります。これによってここで何も変わることはないと思います(銀行がこの秘密を知らなくてもかまいません)。

ただし、疑問に思っていたように、この秘密鍵を使用してチャレンジを直接エンコードすると、攻撃者は事前に回答の山を生成するか、取得したチャレンジの回答をメモして再生し、別の支払いを要求することができます。同じチャレンジが受け入れられました。

ここでの目標は、同じ課題であっても、正解が常に異なる必要があることを確認することです。このために、秘密鍵を適用して回答を生成する前に、カウンター(安価なソリューション)またはタイムスタンプ(回答の有効期限が切れる可能性があるため、最も信頼性の高いソリューション)をチャレンジに追加します。

サーバー側:

  • カウンターが使用されている場合、同じ支払いまたは以前の支払いのいずれかで、提供した回答が以前に提供した回答よりも厳密に大きいカウンターを持っていることが保証されます。あなたの答えが有効であるように見えるが、カウンターが小さい場合、これはおそらくこの答えが再生され、あなたのカードで何か怪しいことが起こっていることを意味します(このようないくつかのイベントとあなたはあなたからの通知を受け取るかもしれません銀行、サービスのレベルに応じて)。
  • タイムスタンプが使用されている場合、サーバーは、チャレンジが送信された後に回答が生成されたことを確認するだけで、再生が試行されないことを確認できます。
1
WhiteWinterWolf