2012年8月27日月曜日

EPUB用自作DRMの挑戦 失敗編

[EPUB用自作DRMの挑戦 失敗編]

EPUB用にDRMが自力で実装できるか挑戦してみた。
が、表題の通りに失敗に終わる。

とりあえず、目標としてはEPUBの仕様に則り(個人的には則ったつもり)

  1. コンテンツを暗号化

  2. encryption.xmlの作成

  3. EPUB3に対応したビューアでコンテンツを読む

を目指してみた。
上記を順を追って以下につらつら書いていくが、結果的に失敗しているので、
どこが悪いのかまったくわからない
もしくは、悪そうなとこイメージできるが確証が持てない
言う状態。
闇雲にアプローチして来たけど、ちょっと目標を達成する算段が
つかないので、区切りを入れる為に失敗編を作成。
今後は成功編ができるように願うばかり。

1.準備


最初にsigilを使用して何でもいいのでepubファイルのワンセットを作成。
ここでは『drmtest.epub』という名前で保存。

で、保存されたファイルの拡張子をzipに変更し、解凍する。
すると以下の構成でフォルダが出来上がる。

drmtest/META-INF/container.xml
drmtest/OEBPS/content.opf
drmtest/OEBPS/toc.ncx
drmtest/OEBPS/Text/Section0001.xhtml

ここまでコンテンツの準備。

2.コンテンツを暗号化


ここではAES128-CBCでコンテンツを暗号化するのを考える。
encryption.xmlがW3CのXML暗号化仕様(XML Encryption Syntax and Processing)
に準拠している事からこの規格をサポートしているeclipse+XMLSecurityToolsプラグインを使ってコンテンツを暗号化する。
(encryption.xmlの定義はEPUB Open Container Format (OCF) 3.0で定義
されている。どういった内容なのかは一先ず触れずに放っておく。)

先ずはeclipseにコピー。ファイル名を『Section0001.xhtml』 -> 『Section0001.xml』に変更。
先ほどの『Section0001.xml』を右クリックして[XML-Security]->[Encryption]を選択
(選択すると凄い時間がかかる場合がある)


特に何も設定せず[次へ]



[Encryption and Cipher Algorithms]に「AES128」、「AES-128 Key Wrap」を設定
[Key File]に「AES」、「128」、ファイル名に「..\META-INF\example.key」を指定
[Encryption ID]に「example」を指定
設定したら[完了]
(完了すると凄い時間がかかる場合がある)


『example.key』と暗号化された『Section0001.xml』が出来上がり。


ここまでで、コンテンツの暗号化が完了

3.encryption.xmlの作成



META-INFフォルダに空の『encryption.xml』を作成する。
にある例の内容をコピー


a.『encryption.xml』の内容を暗号化した『Section0001.xml』から一部コピーして置き換える
b.[enc:EncryptedKey]内にある[enc:EncryptionMethod]の[Algorithm]属性に「http://www.w3.org/2001/04/xmlenc#kw-aes128」を設定
c.[enc:EncryptedData]内にある[enc:EncryptionMethod]の[Algorithm]属性に「http://www.w3.org/2001/04/xmlenc#aes128-cbc」を設定
d.[enc:EncryptedKey]内にある[enc:CipherData]の[enc:Ciphervalue]のに『Section0001.xml』の同値を設定
e.[enc:EncryptedData]内にある[enc:CipherData]の[enc:CipherReference]の[URI]属性に「OEBPS/TEXT/Section0001.xml」を設定

『Section0001.xml』のファイル名を『Section0001.xhtml』に変更
また、中身を暗号化されたデータのみにする為、[enc:EncryptedData]内にある[enc:CipherData]の[enc:CipherValue]の値以外を削除



ここまでで、encryption.xmlの作成が完了

4.EPUB3に対応したビューアでコンテンツを読む


ここではepubファイルの再構築、チェック、実際にビューアーで確認まで。

先ずはepubファイルの再構築は、EPUB3 チュートリアルを参考に作成。
特に『編集したファイルをEPUBにする』の章を参考に以下のコマンドで『drmtest.epub』を作成する


cd drmtest
zip -0 ..\drmtest.epub mimetype
zip -r ..\drmtest.epub * -x mimetype


ビューアで見る前にEPUBチェックツールのepubcheckで確認
結果は


Epubcheck Version 3.0b5
ERROR: drmtest.epub: Extra field length for first filename must be 0, but was 11
4
Validating against EPUB version 2.0
ERROR: drmtest.epub/OEBPS/Text/Section0001.xhtml(1,1): プロローグにはコンテンツ
を指定できません。
ERROR: drmtest.epub/OEBPS/Text/Section0001.xhtml: プロローグにはコンテンツを指定
できません。
Check finished with warnings or errors


encryption.xml以外でエラーが出る。どうやらxhtmlファイルの文書宣言の前にデータがあるのがダメらしい。どこかに仕様の矛盾か私のコンテンツに不正があると考えられる。
と思ったら、epubcheckのソースコードを覗いてみたらencryption関係は未実装部分が多くチェックをほとんどしていないみたい。複合化とか関係無しにxhtmlファイルとして解釈していたので、あんまり意味無かった。

で、強引にibooksで開いた場合には以下のようになる。

残念。失敗。


考察


とりあえず、今回の挑戦でダメそうな所を考えてみる。

  1. encryption.xmlの用途は正しいか?:暗号化する時の情報の一部を参考用に書くのが目的のファイルだったりすると、私の解釈が間違っている事になるかと。

  2. 鍵はどうした?:コンテンツを暗号化した時に「鍵」も「キーワード」も作成された。が、それはビューワで参照されているのか?
    現状では鍵をどうやって参照するように定義したらいいのか不明。『encryption.xml』のに定義すると思うんだが、イマイチ
    確信を持ってここだと定義する方法がわからない。一先ずの解釈では【にある】がを複合化する
    「鍵」で、を複合化する「鍵」をどこかに定義する必要があると考えられる。普通のviewrはどうしてんだろ?
    『encryption.xml』だけじゃ足りないんじゃないか??

  3. ビューワはencryption.xmlに対応しているのか?ibooksで提供されているファイルは『encryption.xml』が含まれており、Appleが提供している
    『fairplay』というDRMが定義されている。ただ、『fairplay』以外のDRMをサポートしているかが不明。用意したコンテンツが悪いのかibooksが対応して
    ないのかはわからない。両方かもしれん。あとreadiumを調べてみたけど対応しないし、する予定も無い(FAQより)らしい。
    まぁオプショナルだと言われると強気にはなれない。


今できそうなとこはこんくらいか。。。自力じゃさすがに限界が見えてきた。
あとはもう少し暗号化について調べるのと、ビューワーがどういう作りになってるか調べるぐらいかな。各ビューワでDRMの仕様を組むのは需要に応えた結果だとは思うんだけど、組む方法は提供してもらえないものなんだろうか?別に保障とかは求めて無いんだが。

2012年8月20日月曜日

梅湯葉ぶかっけ@すみた

前々から目を付けていた讃岐うどんのすみた(赤羽)でぶっかけうどんをいただく。
19時以降だったと思うけど、自分の組から後ろ2組ぐらいでうどんが無くなってし
まったので、お客さんをお断りしてました。
今回はギリギリ間に合った。

お店は綺麗な印象。席の数はテーブルが5,6ぐらいなので並ぶのは覚悟の上。
うどん以外にもおでんも食べれるようです。次は注文してみたい。

讃岐うどんならやはりぶっかけを味わってみたく「梅湯葉ぶっかけ」を注文。

だしは関西風(いや、讃岐風か?!)メンはコシがありプルっとした歯ごたえが
おいしい。梅は甘く酸味も程よい具合。

あぁご馳走様でした。
また行こう。


2012年8月15日水曜日

EPUB LCPのRFPをざっくり解釈

再度、今更ながら7/20にIDPFがEPUB LCP RFP(EPUB Lightweight Content Protection: Request for Proposals)
が発表されました。前回のユースケースと機能要件から細かい所の補足や追加は行われていますが、大きなコンセプトの変更はなさげ。
ちなみに追加で言うと


  1. コンテンツに関係の無い、注釈、ブックマークなどの他の機能は利用の制限の必要が無い



が機能要件に追加されてたりします。
まぁ「コンテンツ」の保護をするのに他のとこに制限かけるのは趣旨を間違える可能性があると思うので良いのではないかと。

今回の発表でスケジュールに具体的な日付が示されたので、以下のタイミングでチェックすると追跡しやすいと思う。


  1. 提案の最終提出期限は 2012年8月31日

  2. 提案者は2012年9月15日にIDPFからの応答を受取るのをわくわく想像する

  3. 2012年9月15日~10月15日の間に提案者はIDPTと詳細なフォローアッププレゼンテーションを含んだ次のステップのディスカッションをする約束をする準備をする



最後がだーいぶ怪しい翻訳ですが、こんなイメージ。まぁ今月の末から10月中ぐらい迄に動きがあるんじゃないかと思われる。近々では8/31~9月頭ぐらいにチェックかな。

2012年8月2日木曜日

EPUB LCPのユースケースと機能要件をざっくり解釈

今更ながらEPUB LCP(EPUB Lightweight Contents Protection)のユースケースと機能要件をざっくり解釈。
IDPFがDRMについてのコメントを募集するのに作成した文書。EPUB3のDRMはここから始まる事になりそうだけど、文書がそれなりにボリュームがあるので忘れないように。

まずDRMの存在については肯定。
理由は

  1. 供給側の意図しない過剰な供給のあるていどの抑止力になるだろう

  2. DRMの存在する事によりコンテンツが著作権法等の保護を受けられるようになる


2番目の理由としてはDRMを施さないと保護してないと言われて裁判にならない場合もあるそうな。電子署名もコンテンツ保護には効果はあるけど、法の加護を得るには適切なDRMという事らしい。

現時点でのコンテンツ保護の適切な方法は"軽量DRM"だとしているようです。
で軽量DRMはどんなものかと言うと

  1. DRMを実現するコストを低くする

  2. ユーザの使いやすさを損なわない、または使用方法の制限が少ないようにしたい


みたいな感じでしょうか。PDFが良い例らしい。お金をかけてほぼ完全にクラックされない、クラックされても被害を最小限に抑えるようにするのも出来るけど、そのDRMの負担は誰がするのか?で良い答えが出ないんじゃないかと。
あと、ユーザビリティが損なわれてしまうのは避けたい。

ここで、上記を元に出されたEPUB LCPの機能要件をグーグル先生に毛が生えた程度に翻訳すると、

  1. 認証:

    1. 認証はユーザや端末に対してファイルをベースとする。しかしながら、他のモードの認証を追加する事もできる

    2. それぞれのファイルはそれぞれのパスワードが関連づけられます。パスワードはユーザに発行を求められる度にセットする。通常ではユーザがパスワードを入力するのは最初の1回目に彼がファイルを端末で開く時だけで、以後は無し。

    3. 他の端末で発行物を読む場合には、その他の端末で最も単純な方法でユーザはパスワードを入力しなければならない(例外は以後を参照)。他のユーザと発行物を共有する為に、パスワードは他のユーザと通信出来る物でなければならない。言い換えれば、他のユーザは正確にユーザが発行物を他のデバイスで読むのと同じようにできる共有です。他のケースは以下を参照。

    4. パスワードのフィールド名は各発行物のメタデータに含まれなければならない。("ユーザID"、"パスワード"、"ケンワート"、"図書カード番号"等)

    5. パスワードの意義はEPUB LCPでは定義されません。配信者の判断で設定するでしょう。例えば

      1. ユーザが各ファイルに設定できるようにする

      2. ユーザが一つのパスワードを全てのファイルに設定できるようにする

      3. ユーザが最低限の強度が要求されるように設定できるようにする(例えば、少なくともN文字や一つ以上の文字以外や数字以外など)

      4. 各ファイルを開いた時に再入力を要求するか選べるようにする

      5. 配信社がセットできるようにする(例えば、ユーザのEメールアドレスやユーザIDやクレジットカード番号等)



    6. パスワードは一方向ハッシュ形式のように不明瞭で回復不能な形式でクライアントのソフトウェアや端末に格納されるべきです。言い換えれば、パスワードスチールハッカーにはユーザが入力している不明瞭化されてたパスワードを掴ませるべきです。



  2. 使用制限の設定:

    1. タイトル毎に印刷自体、一度に急速に印刷可能な量、全量

    2. タイトル毎にクリップボードへのコピー、一度に急速にコピー可能な量、全量

    3. 編集の可否

    4. 利用の開始と終了の日時を設定(図書貸し出し等)、併せて分などの小さい粒度にも落とせる(提供されている図書館調査では貸し出し期間は時間単位)

    5. 編集とコピー/印刷等ののオプションに異なるパスワードを設定。



  3. コンテンツの保護:

    1. 最低でも1つのレベルの暗号化が必要:暗号化されたコンテンツの為の対称キー。加えて、転送やクライアントで全てのユースケースに必要とされるようなプロトココル(SSL等)やコンテンツ保護キーの為の非対称キーなどが必要とされるでしょう。

    2. コンテンツ暗号化の為のアルゴリズムはAESで最低でも128bitの強度が必要であり、オペレーショナルモードの実装があるべきです。2001年ベルギーで米政府の標準として紹介されたAESは仮想的な最新DRMの目的で使用されています。コードライブラりは広く存在しています。

    3. コンテンツキー保護のアルゴリズムはRSA-1024(安価)やECC-NIST-256(効率的)のような実装するのに標準的な効率的で安価な公開鍵/秘密鍵アルゴリズムであるべきです。

    4. キーの隠蔽方法は実装者に一任されます。

    5. キーの復元方法に家の番号が要求される事はサポートされない。



  4. サポート形式

    1. EPUB LCPはEPUB オープン・コンテナ・フォーマット(OCF)定義のencryption.xmlやrights.xml等に構築されることが期待されています。また、EPUB LCPはEPUBではない直接適用可能なフォーマットである事を予想していません。



  5. コードライブラリ:

    1. クライアント

      1. 最大限に携帯可能

      2. 電子読書アプリや端末に提案する為にAPIクライアントは良く文書化されている

      3. 多様なプログラム言語に呼び出される事が可能

      4. 実装者の選択する一般的プラットフォーム(Android、ios、Windows、Mac OS 等)で実装のリファレンス



    2. サーバ

      1. RESTfulウェブサービス

      2. WindowsやLinuxでの実装のリファレンス







ざっと読んだ感じだと簡易DRMは暗号化して、ユーザはパスワードを使って読めるようにしたらいんじゃないか?
って具合。"重量級DRM"はもっとごっつい事をやってますが、これならなんとなーく「それっぽいものは」できそうなレベル。


機能要件には無いけど、一番気になるクラックされた後の話は、、、

技術的保護手段を回避するような行為は(多くの国で)違法なので行政や法に委ねる。

を提案しています。 既にどこか知らない所で抜き取られたのを手にしたりばら撒いたりした場合も同様な手段を取るようになるんだろうと。

コンテンツの供給側と消費側の最初の妥協点が示された感じです。
どちらかと言うと消費側の権利を尊重するような内容に受取れるけど、、、供給側が賛同できるんだろうか。