ネット上で得た各種情報をもとに、 B-CAS カードの仕組み、不正使用関連の現状等について自分なりに理解した内容をまとめてみました。
正確性は保証しないのでそのつもりで。
参照した情報源は最下部に記載。

B-CAS カードの仕組み

Km

EMM を暗号化・復号するための鍵。
カード毎に異なり、 B-CAS ID から生成される。
B-CAS ID → Km の生成アルゴリズムは一般には非公開。 (※1)

EMM

Km を鍵として 契約情報 及び Kw を暗号化したもの。
契約情報 及び Kw を更新する際のみ、対象となる B-CAS カードに対して個別に送信される。
EMM の暗号化・復号アルゴリズムは一般には非公開。 (※1)
EMM の暗号化・復号アルゴリズムは変更可能だが、契約者に対し新カードを供給する必要がある。

Kw

ECM を暗号化・復号するための鍵。
放送局毎に異なり、適宜更新される。 (※2)
EMM に暗号化された形で各 B-CAS カードへ渡され、 B-CAS カード内に保存される。

ECM

Kw を鍵として Ks を暗号化したもの。
暗号化されたコンテンツとセットで常に送信される。
ECM の暗号化・復号アルゴリズムは一般には非公開。 (※1)
ECM の暗号化・復号アルゴリズムは変更可能だが、契約者に対し新カードを供給する必要がある。

Ks

コンテンツを暗号化・復号するための鍵。
適宜更新される。
ECM に暗号化された形で B-CAS カードへ渡され、復号した結果が受信機 (TV) へ返される。
コンテンツの暗号化・復号アルゴリズムは公開 (MULTI2) 。

B-CAS カードが行っていることは以下の通り。

• EMM を受け取り、復号して得た 契約情報・Kw を B-CAS カード内に保存。 (※3)
• ECM を受け取り、契約情報をチェックした上で、復号して得た Ks を受信機 (TV) に渡す。

受信機 (TV) 側は、放送波中の EMM・ECM を B-CAS カードへ渡し、 B-CAS カードから受け取った Ks を用いてコンテンツを復号する。

現状

※1 :

EMM・ECM の暗号化・復号アルゴリズムは既にソースコードの形で漏洩してしまっている。また、 B-CAS ID → Km の生成アルゴリズムも、一般には知れ渡っていないものの、一部業者は把握しているものと推測されている。

※2 :

本来 Kw は適宜変更が可能なものだが、未使用のカードで申込なしに (= 放送局側が B-CAS ID を把握していない状態で) 1週間無料視聴を実現するため、現状は

• 新規 B-CAS カードを Kw 書込済の状態で配布
• Kw 固定 (Kw を変更すると 1週間無料視聴の出来ないカードが出てくるため)

という運用になっている。

※3 :

特定の (といっても現在配布されているカードのうち大半の) カードにバックドアが見つかったため、当該バックドアを持つ B-CAS カード中の契約情報・Kw を直接書き換える方法が確立されてしまっている。

B-CAS 運用上の問題点

• 無料の地上デジタル放送にも B-CAS を適用した。
  • 解析の動機と解析対象を徒に拡げることになった。
  • 契約情報と紐付いていないカードが大量に存在することになり、全交換という手段が困難 (実質的に不可能) になった。 (有料契約者のみ全交換という手段は残されている。)
• 未使用状態から申込なしでの 1週間無料視聴を実現するため、 Kw 書込済の B-CAS カードを配布するという方法を取った。
  • 未契約者にも Kw が 配布されることになった。
  • 技術上は Kw の変更が可能であるのに、運用上変更できなくなった。

考えられる対策

http://www.marumo.ne.jp/db2012_3.htm#2 を参照。

情報源

• http://www.catv.or.jp/jctea/spec/standard/pdf/STD001.pdf 3ページ目の図
• http://www.marumo.ne.jp/tawagoto.htm
• http://d.hatena.ne.jp/essa/20120522/p1
• http://www.facebook.com/koyhoge/posts/463995473614977

素直にコーディングするなら、バッファに使う型は符号付きではなく符号なしの 8bit 整数の配列/ポインタにすると思うんだけど、なぜか某ライブラリの API は符号付き整数のポインタを要求するんだな…。

『API が要求する型にはなるべく合わせる』というポリシーから、当初はライブラリの方に合わせて符号付きの型でバッファを確保するようにコーディングしたのだけれど、『バッファから 2バイト分取り出して 16bit 整数値にする』処理で、符号拡張の影響で間違った値になってしまうバグを作り込んでしまった。

バッファは符号付きの型のままで、 16bit 整数値を取り出す処理の方で明示的に型変換をすることで対処しようかとも考えたけれど、『さすがにこれは API の仕様の方がおかしいだろう』と考え直し、バッファを符号なしにして、ライブラリの API の呼び出し時に符号なし→符号付きに型変換するようにした。

文字/文字列として使用する型を、 (typedef signed char my_char_t みたいに) signed/unsigned を指定して typedef しないで欲しい。

某組込向けライブラリがこれをやっていて、しかも char 型と符号の有無が異なるせいで、そのライブラリの API を呼び出す箇所で明示的に型変換しないと Warning が出る。

例として、気温・湿度・気圧・風向・風速の 5つの int 型のデータを 100回分保存するバッファを考える。

よく見かけるのが、

int weather_data[100][5];

という形で確保して、

weather_data[n][0] = temp;
weather_data[n][1] = hum;
…

という風に保存するという書き方。 (もっと酷いものだと int weather_data[5 * 100]; なんていうのもあるが…。)

これだと、『1回分のデータ配列中の何番目にどのデータ (気温・湿度…) が保存されているか』ということがソースコード上で明確でなくなってしまう。

配列のインデックスとデータを対応付ける #define を

#define TEMP_OFFSET 0
#define HUM_OFFSET  1
…

のように定義し、それを使用して

weather_data[n][TEMP_OFFSET] = temp;
weather_data[n][HUM_OFFSET ] = hum;
…

のようにすることで回避は出来る。 (しかし、それをちゃんと出来ていないソースコードもまた多い。)

もっと良い方法は、

typedef struct {
    int temperature;
    int humidity;
    int pressure;
    int wind_direction;
    int wind_speed;
} weather_data_t;

weather_data_t weather_data[100];

のように構造体を用いることである。

こうすることで、

weather_data[n].temperature = temp;
weather_data[n].humidity    = hum;
…

のように配列のインデックスではなく要素名を用いることになり、要素名からデータの内容も明確になる。

weather_data[n].temperature = hum;

のように誤った要素に保存するコードを書いてしまう可能性は

weather_data[n][0] = hum;

のように配列のインデックスに誤った値を直値で指定してしまう可能性と比較すれば極端に低く、よりバグを生みにくいコードであると言える。

某社から受け取ったソースコード。

main 関数では初期化処理のみを行い、主要な処理は main 関数を抜けた後に別の関数を呼ぶということを素でやっている…。

そういうのはネタだけにして欲しい…。

私の前に開発を担当していた人によると、そのソースコードは『後で直すつもりで雑な書き方のままの箇所が多く残っている』ということだったのですが、個人的にはこういうコーディングの進め方にはあまり賛同できない。

当初からきれいに書くことを意識していても、規模が大きくなるにつれて汚い部分が出てきてしまうことはままある。
まして最初から雑な書き方で進めていったら、後からの修正では雑な部分を取り除ききれなかったり、修正にかかる負担がかえって大きくなったりしてしまう。

さらに、とりあえず動作するコードを早急に書かなければならない場合でも、雑な分早く書くことが出来るかというと、あまりそうは思えない。むしろきれいに書くことを心がけた方が、見通しが良くなり早く完成させられるように思われる。

その1 : GUI 編

ある数値の表示にテキストボックスを使っていて…その数値を保存するときには…テキストボックスからテキストを取得して…文字列→数値変換をして…保存している…

さらに…そのテキストボックスはデータの表示に使うだけで…ユーザーがデータを入力する必要は無いもの…それなのに入力が禁止されていない…

その2 : DB (Access) 編

mdb ファイルが複数あって…複数の mdb ファイルにまたがるいくつかのテーブルで…オートナンバーで振られる ID の値が…一致する前提になっている…

つまり…DB にデータを追加する際は…作業者は ID が一致するように注意を払わなければならない…

殴り書きの設計書ではいくら内容が正しくても認めてもらえないのと同じように、殴り書きのソースコードもいくら動作が正しくても完成したと見なしちゃダメだよなぁ…。

前回の日記はプロジェクトの進め方等にかかわる部分でしたが、今度はプログラムの中身について。

そもそもこのプロジェクトの目的は、今までバラバラに作成されてきた、各種のターゲットに対する似たような処理を行うツール一式を、一つにまとめた上で、可能なところを自動化して効率を上げることと、今後の分析等のためにデータを蓄積することらしい。

ということで、本来ならば各種のターゲットに対する処理の共通点・相違点を一通り調査・理解し、メンテナンス性を考慮した設計が求められるところのはずが、どうやら特定のターゲットに対し動作するものを早急に要求されたこともあって、設計が不十分なままそのターゲットに対応する部分だけ動作するものを作ったっぽい。

さらに、データの蓄積のために Access を使っているのだけれど、データベースの使い方も、今までデータベース関連の開発などしたことがない私の目から見てもメチャクチャ。データ構造は『DB を Excel か何かと勘違いしてるんじゃ?』という感じだし、フィールド名も直観的でないし、不用意にデータを上書きしているところがあるし、そもそもDB以前のデータ分類整理の仕方がなっていないし。

という状況で引き継いだ上、スケジュールや費用を考えると大幅な修正を行うわけにもいかず、追加開発分も結局やっつけにやっつけを重ねるようなやり方でなんとか開発を進めている状況。

もし私がこのプログラムを分析して実用に堪えるかどうかを調べるだけの立場なら、間違いなく『こんなものは捨てて新規にちゃんとした設計で作り直すべき』と判断するところなんですが。

さらにまずいのは、お客さんはそんな内部設計のまずさまでは見ていなくて、とりあえずここまではそれなりにちゃんと開発できているように見えているであろうこと。
この状況でこれらの問題を取りざたしても、こちらの開発上の問題として、下手をすれば無償での対応を要求されかねない。そうなれば私が対応させられることも目に見えているわけで。 (より良い設計で新しく作り直せるのは、技術者的にある意味魅力的でもあるけれど。)
結局、追加開発が降ってくるたびにやっつけでの対応を繰り返しつつ、なんとか上手いことこの案件からフェードアウトしていくしかないような。

今やっているプロジェクトがそれはもう酷すぎてちょっと愚痴る。

受託開発の案件なんだけれど、そもそも要求仕様があまりにも不明瞭。

重要な部分の処理が『これまで使っていたソースコード/ツールがあるのでそれを流用してください。仕様書はありません』という。何か質問しても大抵『元のソースコード/ツールを見て下さい』と返される。

そのソースコード/ツールがちゃんと設計されて流用性も良いものなら良かったのだけれども、実際は元々ソフトウェア開発は専門外の人が片手間に作ったようなものらしく、設計もムチャクチャだしちょっと手を入れようものなら却ってバグが出てしまうような代物。

で、私がこのプロジェクトを引き継ぐ前の前任者は、そんな状況に加えて、開発中から仕様追加・変更等の要求がこちらのスケジュールを考えずに上がってくるのに辟易して、やっつけでとりあえず動くところまで作ったような状況でこのプロジェクトから離脱。

この時点でもう手を引いたほうが良かったのだけれども、追加開発を見込んで初期開発分を大安売りしちゃったせいで、営業的にはやめるにやめられない。

ちなみに肝心の追加開発は、こちらのスケジュールの都合がつかず (費用面の問題もあったか?) 結局一部 (というか大部分?) 他社に流れてしまったりしている。そもそも社内にソフトウェア開発者の手が不足しているのである。

で、私がその後を引き継いで (どう考えてもちゃんとした引き継ぎは行えていないけれど) 追加開発となったのですが、まずスタートが別プロジェクトの作業遅れに押されて遅れた上に、前任者のやっつけ仕事っぷりが想像以上で見積もり時の想定作業量を大幅にオーバー。追加要員も期待できず、残業と休日出勤でなんとか出来るところまでやろう、それでも納期に間に合うかどうかという状態。

一応私からは『このままじゃ無理!』というアラートは上げたのだけど、どうも対外的な立場もあってか営業から先へ上手く伝わらない感が。

このことから得られる教訓は、たくさんあると思うけどとりあえず…

• 何を作ればいいかはまず明確にする。そのために必要な作業時間や資料すら与えられないなら、そのプロジェクトには手を出さないか、早めに手を引く。
• 開発の規模が大きい場合やスケジュールがタイトな場合は社内のリソースをちゃんと考慮する。
• 追加開発を見込んで初期費用を値引きしない。
• 見積もり時点での想定作業量は切り詰めすぎず、何かあったときのためのバッファを確保しておく。
• ソースコード・資料は問題なく引き継ぎが行えるレベルまでちゃんと作る。

参考:『おごちゃんの雑文』より『ダメな仕事を受けないためのNGワード』。『今回は予算があまりないので小額になりますが、次回はしっかり払いますので』に、まさに嵌ってしまったという感じ。