アカウント名:
パスワード:
セルフチェックでパスできる仕組なら、誰が何を認証するためのものなのだ？という話ですよ。「合言葉を言え。その際、符号に合致するかは自分で確認して結果を知らせろ。OKなら入れてやる。」って、そんなん何のチェックにもなってないじゃん。
磁気カードも当初はカードに暗証番号を持っていてそれと入力値を突き合わせる仕組みだったのが、それじゃ意味無いジャンと言うことでゼロ暗証になったはず。
ちょっと違う。読み取り端末がユーザから暗証番号の入力を受けとり、ICカードに対して、
「起動せよ。起動の暗証番号はXXXXだ」
と命令する。暗証番号が正しければICカードは起動し、違ったら起動しない。その後、
「合い言葉を言え」
と続く。起動していなかったら、もちろん返事は無い。
磁気カードの場合は、そももそカードがどんな状態だろうと全情報を読み出せる。
暗証番号含めた全認証情報がクレカに保存されている時点で問題があると思うなぁ…ネットワーク前提なんだしクレカがオフラインで認証を完了する必要はない。ICの耐タンパだって限界がある。ドングル/トークンに比べると圧倒的に弱い。
耐タンパを破らなくても何らかの方法でクレカから暗証番号の抜き取りも出来る可能性があるし、クレカにそれを保存しておく必然性が無いと思う。RFIDの電子マネー類とかなら応答時間の為にプロトコルを整理する必要もあるが、それに比べりゃクレカなんて許容応答時間くっそ長いし幾らでもリモートと連携できる。
まあ、しょせんは当時の技術力で実現可能な妥当な方法というレベルなので。前提をアップデートして作り直したら、より良い物になるでしょ。
あと、
>耐タンパを破らなくても何らかの方法でクレカから暗証番号の抜き取りも出来る可能性があるし、
ここがちょっとよく分からない。B-CASカードがそうだったように、実装によってはセキュリティーホールがあるかも? ってこと?セキュリティーホールが無ければ、抜き取れる可能性は、物理攻撃、つまり、耐タンパ破りしかないので。
万が一、実装がショボくても大丈夫なように設計すべき、というのは理想だけど無理があるなぁ。
> 実装によってはセキュリティーホールがあるかも? ってこと?そう。例えばの話リトライ回数見て無ければ(内臓のRTCなど無理だから)桁数的に直ぐぬけるし、リトライ回数加算が認証失敗後であるなら、加算前に電力抜いて消費電力等でサイドチャネル攻撃出来る余地がある。
耐タンパを破るほどではないが挙動に介入できる程度に物理攻撃できるなら、変えた挙動を元にサイドチャネル攻撃を組み合わせるとかも考えられる。
…関連記事見てみたらこのクレカにはAVRとEEPROMが載ってるようだけど、攻撃検知の機能がAVR側で完結してない(AVRのEEPROMを普段書き換えない動作の)場合、AVR側に持った情報でEEPROMが暗号化されててもEEPROMを複製することで総当りできそうだし。# ていうかAVRなのねー…こんなところでもお目にかかれるとは！
そもそもAVR(AT90S8515A)ってデータシートは見た目ふっつーのAVRだけど、対タンパが強いチップなんだろうか。ICカード用のカスタム…なのかなぁ…？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
そもそも、暗証番号を自前でチェックするという仕組み自体がおかしい (スコア:0)
セルフチェックでパスできる仕組なら、誰が何を認証するためのものなのだ？という話ですよ。
「合言葉を言え。その際、符号に合致するかは自分で確認して結果を知らせろ。OKなら入れてやる。」
って、そんなん何のチェックにもなってないじゃん。
磁気カードも当初はカードに暗証番号を持っていてそれと入力値を突き合わせる仕組みだったのが、それじゃ意味無いジャンと言うことでゼロ暗証になったはず。
Re:そもそも、暗証番号を自前でチェックするという仕組み自体がおかしい (スコア:1)
ちょっと違う。読み取り端末がユーザから暗証番号の入力を受けとり、ICカードに対して、
「起動せよ。起動の暗証番号はXXXXだ」
と命令する。暗証番号が正しければICカードは起動し、違ったら起動しない。その後、
「合い言葉を言え」
と続く。起動していなかったら、もちろん返事は無い。
磁気カードの場合は、そももそカードがどんな状態だろうと全情報を読み出せる。
Re: (スコア:0)
暗証番号含めた全認証情報がクレカに保存されている時点で問題があると思うなぁ…
ネットワーク前提なんだしクレカがオフラインで認証を完了する必要はない。
ICの耐タンパだって限界がある。ドングル/トークンに比べると圧倒的に弱い。
耐タンパを破らなくても何らかの方法でクレカから暗証番号の抜き取りも出来る可能性があるし、
クレカにそれを保存しておく必然性が無いと思う。
RFIDの電子マネー類とかなら応答時間の為にプロトコルを整理する必要もあるが、
それに比べりゃクレカなんて許容応答時間くっそ長いし幾らでもリモートと連携できる。
Re: (スコア:0)
まあ、しょせんは当時の技術力で実現可能な妥当な方法というレベルなので。
前提をアップデートして作り直したら、より良い物になるでしょ。
あと、
>耐タンパを破らなくても何らかの方法でクレカから暗証番号の抜き取りも出来る可能性があるし、
ここがちょっとよく分からない。B-CASカードがそうだったように、実装によってはセキュリティーホールがあるかも? ってこと?
セキュリティーホールが無ければ、抜き取れる可能性は、物理攻撃、つまり、耐タンパ破りしかないので。
万が一、実装がショボくても大丈夫なように設計すべき、というのは理想だけど無理があるなぁ。
Re: (スコア:0)
> 実装によってはセキュリティーホールがあるかも? ってこと?
そう。
例えばの話リトライ回数見て無ければ(内臓のRTCなど無理だから)桁数的に直ぐぬけるし、
リトライ回数加算が認証失敗後であるなら、加算前に電力抜いて消費電力等でサイドチャネル攻撃出来る余地がある。
耐タンパを破るほどではないが挙動に介入できる程度に物理攻撃できるなら、
変えた挙動を元にサイドチャネル攻撃を組み合わせるとかも考えられる。
…関連記事見てみたらこのクレカにはAVRとEEPROMが載ってるようだけど、
攻撃検知の機能がAVR側で完結してない(AVRのEEPROMを普段書き換えない動作の)場合、
AVR側に持った情報でEEPROMが暗号化されててもEEPROMを複製することで総当りできそうだし。
# ていうかAVRなのねー…こんなところでもお目にかかれるとは！
そもそもAVR(AT90S8515A)ってデータシートは見た目ふっつーのAVRだけど、
対タンパが強いチップなんだろうか。ICカード用のカスタム…なのかなぁ…？