ruby 上での html parser の話。指定銘柄に対して最良気配値を証券会社の WEB ページから取得するスクリプトを昔書いたことがあり、その内部で Hpricot [URI] を使っていた。
サーバ移転後、このスクリプトが動作しなくなっていたのを放置していたのだけど、仕事の方がひと段落ついたので真面目に問題解決に向けて作業を始めてみた。
……のだが……まず、github から tar.gz を取得して rake install した Hpricot(string) が segmentation fault で死ぬ問題があり。余計なシステムを噛ますのは好きになれないのだけどと思いつつ、RubyGem [URI] 経由で入れようかと思っても最近の (1.4 辺りから？) RubyGem は CentOS の ruby-1.8.5 がサポート外になっていたり……。
考えるのが嫌になったので yum erase ruby ruby-devel ruby-libs してから ruby-1.9.2-p180.tar.gz を wget して展開 & ./configure; make; make install; へ (gem もデフォルトでインストールされた)。Hpricot に関しても結局先達の情報 [URI] に従い Nokogiri [URI] に逃げることにしてしまった。
Nokogiri で利用方法が大きく異なるようなら手直しの手間が増えるので嫌だなと思っていたのだけど、幸い Hpricot() を Nokogiri::HTML() に置き換えるだけでほぼ全て問題なく動作してくれたので助かった。
なんだか最近パッケージシステムを無視することで仕合せになれる例にぶち当たることが増えてるような気がするのは何でかなと。まあこの上に Rails 環境を構築しようとかすればパッケージを無視したことを後悔するのかもしれんが。
前回に引き続き会議開催から 2ヶ月経過と旬を外したネタではあるものの一応書くだけは書いておくことにした。既に総務省のサイトに資料 [URI] と議事録 [URI] が上がっているので興味がある人にはそちらの参照を推奨する。
この会議では「新コンテンツ権利保護方式推進委員会」の和知オブザーバが資料１「ライセンス発行・管理機関について(案)」を参照しながら新方式の管理機関の運用案を説明して、意見交換という名の消費者団体代表委員のガス抜きの場を設けて、村井主査が「第６次中間答申の基本的な方針に従って（消費者団体代表委員も賛同してたことだろ？）」と２・３回繰り返して「法人設立しないと物事が進まないよね」と合意に至るというやり取りが行われていた。とまあこのように、第二 B-CAS 設立と来年からの運用開始に向けての GO サインが出たわけだ。
質疑応答で少し興味を引いた点としては 伊能 美和子 委員 (NTT) が、第二 B-CAS の鍵管理センター等について「資料に『B-CAS と可能な限り共通にして』とあるように、コスト削減の面からも可能な限りデータセンター等設備を共通化して……」と発言していた (議事録 16 ページ) あたりかなと。発言内容自体は妥当だと思うのだけど、発言者の所属 (NTT) と、現在 B-CAS 社が鍵管理センターやコールセンターの管理運営を (2010年3月期で 9億6千万で) 委託してる先 (NTT データ) というあたりでどうしても深読みしてニヤニヤとしてしまうのを止められなかった。
この第二 B-CAS (と便宜上呼ぶことにする) では、今年 3 月に改定された ARIB STD-B25 第三部の技術仕様に従って、新しい ECM ストリームが放送 TS に追加挿入されるようになる。その辺の詳細については後で別に書く予定だけれども、5 月にあった NHK 技研公開の「次世代 CAS 方式」を NHK 以外の有料放送事業者が受け入れて本放送に使われるようになるとすると……。
第二 B-CAS とは別の技術方式なので、やっぱり第三 B-CAS とかがホイホイと追加設立されるんだろうなと予想できてしまうのだが……これが (そもそもコンテンツ保護方式と称して B-CAS を使うこと自体から始まって) 無駄の上に無駄を積み重ねてるように思えるのはきっと私の考えが足りないからなのだろう。
以前からちょろちょろ [URI] と書いて来たことではあるのだけど、デジコン委 第59回でソフトウェア方式の導入目標時期まで含めて GO サインが出ているようなので、既製受信機に満足できず、必要な機能を備えたテレビ受信機を自分で作りたいという人が注意しておくべき技術的内容を再度記述することにする。
まず、現行方式と新方式で技術的に何が変化するのかという点から。下の図は現行方式と新方式の内容を比較する為に作成したもので、JavaScript が有効の状態でマウスを上に乗せると新方式から現行形式に切り替わるようになっている。適当に切り替えて変更点を確認してほしい。
新方式が運用開始されても、物理的な電波は同じチャネルで送られてくる。また、視聴用データの暗号化アルゴリズムも MULTI2 のまま変化しないし、当然復号鍵 Ks も 2 秒毎に更新のままで変わらない。
現行方式で B-CAS カードが実行するのは、実質的に受信機側での ECM からの復号鍵 Ks の取りだし部分だけなのだけれども、新方式が運用開始された場合、B-CAS 向けの ECM とは別に新方式向けの ECM が追加で多重化されて送られてくる。
このように二つの ECM を送る理由は、新方式であるソフトウェア方式がハードウェア方式である B-CAS と比較してセキュリティ的に脆弱であると予想されているから。ソフトウェア方式でも B-CAS と同じ暗号アルゴリズムを使ってしまうと暗号方式等が秘密であることでセキュリティを担保している B-CAS の強度が大幅に低下してしまう。その結果 WOWOW 等の有料放送を危険にさらしてはいけないということから B-CAS とは異なる暗号アルゴリズムを使用し、同じ Ks を送るだけなのに異なる ECM を送るという状況になる訳だ。
上の図では受信機側で B-CAS 向けの ECM と新方式向けの ECM の両方から復号鍵 Ks を取りだしているけれども、実際には次の図のようにどちらかの ECM を選択（他方を無視）して片方だけから復号鍵 Ks を取得する形になる。マウスオーバーで「B-CAS カード方式受信機の処理」が表示され、マウスを外せば「ソフト方式受信機の処理」が表示されるようにしておいた。
現行の B-CAS 向け ECM しか存在しない放送データと比較すると、受信機側では自身の対応形式に応じて、ソフトウェア方式向けの ECM と B-CAS 向けの ECM から対応している方式を選択し、他方を無視するという処理が必須になる。
デジコン委でのプレゼンを聞く限りでは、最低でも法人でなければ新方式の技術仕様を開示するための契約を締結してもらえないそうなので個人で受信機を作ろうという場合には B-CAS 方式以外の選択肢はなく、自動的にソフトウェア方式向けの ECM を無視する形となる訳なのだが……。受信機作成側としては、当然「後から追加される運用なのだから、何もしなくても無視されるように配慮してソフトウェア方式向け ECM を多重化してくれるよね」と期待したくなることと思う。
……ARIB の仕様は一応その期待に応えてくれている。現行方式では B-CAS 向け ECM に対して一つの TS ストリーム (TS パケットID) が割り当てられていて、ECM のストリームは PMT (Program Map Table) 内の CA_descriptor で指定されることになっている。新方式が運用開始される場合、新方式向け ECM も同様に独立した TS ストリームが割り当てられて、そのストリームも PMT 内部の CA_descriptor で指定される。
つまり、新方式が運用開始された場合、PMT には二つの CA_descriptor が挿入されるので、受信機では対応している CA_descriptor のみを選択して、対応していない側を無視すればよい。対応の有無に関しては CA_descriptor 内部の CA_system_id で判別することができて、B-CAS 方式では 0x0005 が設定されることになっているので、その値を持つ CA_descriptor だけを参照すればよい。
何も問題はない、これらの仕組みに関しては ARIB TR-B14 ver. 4.4 第二分冊の第四編 4-207 ページ (PDF 上では 229 ページ) に記載されている。まともな受信機メーカであれば当然この通りの実装をしていることだろう。
以上が TR/STD から読み取れる ARIB の言い分。で、そういう蝶々が飛んでるお花畑な話は余所に置いといて、内部処理を確認可能な「ARIB STD-B25 仕様確認テストプログラム」と「Multi2Dec/b25decoder.dll」の実情はというと……。
私が作ってる ARIB STD-B25 仕様確認テストプログラムに関しては、2008年12月30日 更新の ver. 0.2.3 から対応した。つまり 0.2.2 までは対応していなかったので、PMT 内部に二つ以上の CA_descriptor が記載されていたら誤動作をしていた。
Multi2Dec/b25decoder.dll に関しては、2009年2月14日 更新の (多分) 最新版でも対応していなくて、PMT に複数の CA_descriptor が記載されていた場合、先頭のものだけを参照する。この為、放送事業者が新方式向けの CA_descriptor を PMT 内部で先に格納していたら Multi2Dec/b25decoder.dll では正常な ECM が取得できず、全パケットで MULTI2 復号に失敗することになる。
実運用が開始されるまで、まだ 1 年以上の余裕があるとはいえ、そろそろ対応した方が良いのではと中の人に直接コンタクトを取るべきかとか……メーカー製受信機でも同じような見落としをしてるモノがあるんじゃないかなーとかほんのちょっぴり心配している。
前回書いた内容は、今年 3 月の ARIB STD-B25 改定で追加された内容という訳ではない。B-CAS 方式と異なる内容の ECM を追加で送ることがありうるということ自体は 2002 年（地上デジタル放送開始 2 年前）の TR-B14 の ver. 1.1 から記載されていたし、ソフトウェア方式で送ることになる ECM の詳細についても 2007 年 3 月の STD-B25 ver. 5.0 から規定されていた。
なのになぜ、第６次中間答申 (2009年7月) からソフトウェア方式の管理主体となる法人の設立を目指すという方針が確定するまでこんなに時間がかかったのかということを推測してみる。STD-B25 ver. 6.0 の直前バージョン (ver. 5.1) からの差分を眺めてみると、一番大きな変更点は第四部が追加されたことなのだけれども……第四部はおそらくアナログ跡地を想定していると思われるモバイル向けの集約放送方式向けの内容なので、規格化を急ぐべき特段の事情があるわけではない。
もうひとつ ver. 6.0 で追加された内容として、第三部の EMM メッセージに関する規定がある。これは NHK が衛星放送で運用している受信確認メッセージの表示・消去を行う為の機構で、ver. 5.1 までは存在しなかったのだけれども、今回の改訂で追加されたものだ。第三部はソフトウェア方式の技術仕様なので、これさえもっと早く策定されていたらもちっと早い時期に管理機構設立に入れたのではと思うと……第６次中間答申策定段階での目標時期を守れなかったのはこれが原因だったのだろうなと思う。
2009年7月の第６次中間答申を出す際にもこの受信確認メッセージに関してかなり揉めていたのだけれども「時間・コストには影響しない（2009年中に技術仕様を策定して管理団体設立に移る）」という前提で第６次中間答申に組み入れられた。が、実際に EMM メッセージに対応した技術仕様を策定するだけでこんなに (期限を超過すること 1 年 3 ヶ月) 時間がかかっているのを見ると「時間・コストに影響しないので受信確認メッセージを仕様に入れる」という決断が間違ってたんじゃないかなぁと思わずにいられない。
まあ、受信確認メッセージを入れたところで喜ぶ放送事業者は NHK だけだし、入れない方が受信機を作るのは楽になるし、ライセンス管理機関の業務も軽くなることを思えば……そりゃ揉めるのも仕方がないよねと思う。なお、傍聴時の感想として、2009年7月13日に次の内容を記述していた。
ごく普通の技術屋的センスから言うと、管理対象の機械を、せいぜい万の単位で識別すればよいシステム(STD-B25 第三部方式)と、100億の単位で識別し、かつ、タイムリーに応答できるようにしておくシステム(検討中方式)ではライセンス管理機関の運営コストが桁違いになりそうに思えます。また、機器メーカの側でも1台毎に異なるIDを、ライセンス機関からの割り当てを受けたうえで割り振り、かつ、それを読み取って動作を変える必要があります。
製造その他で一定のコスト増が必ず発生することでしょう。ファームウェアやチャネルスキャン結果等で一定の保存領域をもうけなければいけませんから、そこでID程度であれば吸収できるのかもしれませんが、ない方がごく僅かとはいえ確実に安くできるはずです。それなのに何故、追加コストはないと言い切ってしまえるのか本当に疑問です。
まあそういったことはさておき、EMM メッセージを実現するためにどのような仕様になったのかということを STD-B25 から読み取ってみる。
まず、機器の製造コスト削減と、ライセンス管理機関の運用コストを削減するためだと思うのだけれども、受信機の製造時点でユニークな ID を割り当てる仕様にはなっていない。具体的には次のような仕組みで受信確認メッセージの表示・消去を行うらしい。
とまあこのように、ライセンス管理機関が受信機（メーカー）に対してユニークなIDを割り当てるという形にはなっていないので、必要コストは最小限になると考えているらしい。
また、EMM の機器識別用の ID が ver. 5.1 までは 56bit だったのに対して、今回の ver. 6.0 では 64bit になっているところから見て、乱数で生成される初期 ID では上位数ビット (多分 8bit) を固定しておき、放送局が ID を上書きする時は固定ビット部を別の値に置き換えるような形になっているのだろう。
個人的には、いくら 56 bit の乱数で初期 ID を生成するとは言っても、テレビ受信機の年間出荷台数 (国内で 1000 万台) を思えば、絶対 ID の衝突が起きるんだろうなと。真面目に計算はしてないけれども、ARIB の中の人はバースデーパラドックスとか聞いたことないのだろうかと心配になってしまう。