アカウント名:
パスワード:
ここまでお間抜けな実装を、誰一人おかしいと思わなかったんですかね？クラックされちゃまずいシステムにバックドアとか付けないでしょう、普通。暗証番号がTOSHIBAって、馬鹿じゃないの？もうね、わざとやってるとしか思えない感じです。
でもなぁ、世の中「故意としか思えないほどの、底抜けの馬鹿」って実際いるしなぁ。そろいもそろって馬鹿だらけだったのか。トップに馬鹿がいてゴリ押しされたのか。あるいは、本当にわざとなのか。
松下と東芝の両方でバックドアが用意されていた、その経緯が知りたいところです。失敗知識データベースに載せて後世に語り継ぐべき。
何度でも成功するまで VERIFY (00 20) を実行できてしまう [marumo.ne.jp]ということなので総当りで余裕ですねそういう部分まで含めて『甘い設計』だったとバックドアを残したのが問題ではなくてそのロックの甘さが原因でしょうPINを数回間違えば機能停止(自爆)にしておいても問題なかったはず
例のPINを使うところは、UNLOCK/VERIFY以前の話です("通常のモードから特別なモードに移行"の部分)。なので、総当たりで余裕というわけではないです。
ちなみに例のPINは、旧型の東芝製B-CAS(T002)でも使えますが、こちらは次に実行するUNLOCKがエラー0x6982(権限が不十分)でできません。何故新型はこれがそのまま通ってしまうので、真の問題はこのUNLOCKコマンドの脆弱性です。例のPINはひどいものですが、その後の部分が固いため、T002等の古い東芝製B-CASは現在も陥落していません。なんでこうなった？と言いたくなるような話です。
なお、PINは平文で処理してたっぽい感じなので、memcmp的な比較してたのなら時間測れば見つけられるかと
クラックする方はFIB装置を使えるのに、製造元は障害調査を容易にするために穴を作るって、知的なレベルが違いすぎない？
# これではクラックされてもしょうがない。
そんなんじゃCC認証 [ipa.go.jp]なんて雲の上の存在だな。
納品時点の初期パスワードをそのまま更新せずリリースするなんてよくある話
つうか、「パスワードで認証する」という仕様だけある開発初期にファーム屋あたりが「仮で、とりあえず」設定したもろもろが量産時、出荷時になって「え、あのツールもこのあれも差し替え…、めんどくせぇ」ってことでなし崩し的にそのまま、ってことは良くある。
と思う。
バックドアが無い事なんて、動作試験のしようがないので要求仕様に載せられんのよ。# コードレビュー？なにそれ？
その割には割れるまで12年もかかってますが。
今回の件は、故意なんですよ。B-CAS廃止は決まったものの、いつまでたっても後継方式が確定しない状況を打破するために、意図的にリークされただけ。
B-CASの初期ならともかく、2000年代後半もそのままだったなんて酷いと思う。が、量産に乗って、当時の開発者が離れてしまったか、無駄な工数を割けなくなったかで、変更出来なかったんだろうな。（動いているものに手を入れるなというのもあるだろう）
ここ数年の話なら、耐タンパのために開発用と量産用は別仕様にして、内部の関係者でも開発用を持ってこないと手が出せないレベルのハードにするのが常識。（これでも中国なんかの模造品製造業者相手だと安心できないのだが）そもそも、耐タンパの特許はうんざりするほど出ていて、その特許の従来例にはいかに今までのものが危ないかとうとうと書いてあるのだから、B-CAS製造者が知らなかったでは済まされない。
ICカードにアクセスできる一般人なんかいるはずがないという慢心があったのは確かだと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
不思議 (スコア:5, すばらしい洞察)
ここまでお間抜けな実装を、誰一人おかしいと思わなかったんですかね？
クラックされちゃまずいシステムにバックドアとか付けないでしょう、普通。
暗証番号がTOSHIBAって、馬鹿じゃないの？
もうね、わざとやってるとしか思えない感じです。
でもなぁ、世の中「故意としか思えないほどの、底抜けの馬鹿」って実際いるしなぁ。
そろいもそろって馬鹿だらけだったのか。
トップに馬鹿がいてゴリ押しされたのか。
あるいは、本当にわざとなのか。
松下と東芝の両方でバックドアが用意されていた、その経緯が知りたいところです。
失敗知識データベースに載せて後世に語り継ぐべき。
Re:不思議 (スコア:1)
正規の手段でアクセスさせると、最終製品で使う暗号鍵が出荷テストとか故障解析する関係者に漏れるから、別の手段を用意するというのはよくある話です。
量産出荷時に無功化するのが一番良いのですが、量産出荷で不良になった製品の原因を探るのには、機能は生かしておいた方が都合が良いです。
あと、例えばヒューズを切って無効にするやり方は、やる気と設備（あるいは業者に依頼する金）があれば、ICをむき身にして、FIB装置を使って切れたヒューズを繋ぐ事も可能です。ヒューズを切る行程も増えるので、コストが掛かります。
等と色々勘案してバックドアは残したんじゃないでしょうかね。
TOSHIBA（の電話キーで押して得られた東芝USA？の電話番号）って、判ってしまえばなんて単純な物を設定していたんだと思いますが、どうやってこれを見つけたのかが非常に興味あります。
恐らくこれが乱数列だったとしても解析されたんじゃないかな？
Re: (スコア:0)
何度でも成功するまで VERIFY (00 20) を実行できてしまう [marumo.ne.jp]ということなので総当りで余裕ですね
そういう部分まで含めて『甘い設計』だったと
バックドアを残したのが問題ではなくてそのロックの甘さが原因でしょう
PINを数回間違えば機能停止(自爆)にしておいても問題なかったはず
Re:不思議 (スコア:1)
例のPINを使うところは、UNLOCK/VERIFY以前の話です("通常のモードから特別なモードに移行"の部分)。
なので、総当たりで余裕というわけではないです。
ちなみに例のPINは、旧型の東芝製B-CAS(T002)でも使えますが、こちらは次に実行するUNLOCKがエラー0x6982(権限が不十分)でできません。
何故新型はこれがそのまま通ってしまうので、真の問題はこのUNLOCKコマンドの脆弱性です。
例のPINはひどいものですが、その後の部分が固いため、T002等の古い東芝製B-CASは現在も陥落していません。
なんでこうなった？と言いたくなるような話です。
なお、PINは平文で処理してたっぽい感じなので、memcmp的な比較してたのなら時間測れば見つけられるかと
Re: (スコア:0)
クラックする方はFIB装置を使えるのに、製造元は障害調査を容易にするために穴を作るって、知的なレベルが違いすぎない？
# これではクラックされてもしょうがない。
Re: (スコア:0)
FIBは時間がかかるから、使わずに故障解析出来ればそれにこした事無いですからね。
多分中の人もリスクに気がついていたはず。
でもこの手のセキュリティ責任の所在って曖昧だし、自分でわざわざ行程を増やしたがる人はあんまり居ない。だからダンマリしてたんだろう。
ICカードだけでなく、半導体ベースでセキュリティを担保しているデバイスは似たような事が多いから、中の人はこれから色々大変だな。
Re: (スコア:0)
そんなんじゃCC認証 [ipa.go.jp]なんて雲の上の存在だな。
Re: (スコア:0)
納品時点の初期パスワードをそのまま更新せずリリースするなんてよくある話
Re: (スコア:0)
つうか、「パスワードで認証する」という仕様だけある開発初期に
ファーム屋あたりが「仮で、とりあえず」設定したもろもろが
量産時、出荷時になって「え、あのツールもこのあれも差し替え…、
めんどくせぇ」ってことでなし崩し的にそのまま、ってことは良くある。
と思う。
Re: (スコア:0)
バックドアが無い事なんて、動作試験のしようがないので要求仕様に載せられんのよ。
# コードレビュー？なにそれ？
Re: (スコア:0)
その割には割れるまで12年もかかってますが。
今回の件は、故意なんですよ。
B-CAS廃止は決まったものの、いつまでたっても後継方式が確定しない状況を打破するために、意図的にリークされただけ。
Re: (スコア:0)
B-CASの初期ならともかく、2000年代後半もそのままだったなんて酷いと思う。
が、量産に乗って、当時の開発者が離れてしまったか、無駄な工数を割けなくなったかで、変更出来なかったんだろうな。
（動いているものに手を入れるなというのもあるだろう）
ここ数年の話なら、耐タンパのために開発用と量産用は別仕様にして、内部の関係者でも開発用を持ってこないと手が出せないレベルのハードにするのが常識。（これでも中国なんかの模造品製造業者相手だと安心できないのだが）
そもそも、耐タンパの特許はうんざりするほど出ていて、その特許の従来例にはいかに今までのものが危ないかとうとうと書いてあるのだから、B-CAS製造者が知らなかったでは済まされない。
ICカードにアクセスできる一般人なんかいるはずがないという慢心があったのは確かだと思う。