IDPFがDRMについてのコメントを募集するのに作成した文書。EPUB3のDRMはここから始まる事になりそうだけど、文書がそれなりにボリュームがあるので忘れないように。
まずDRMの存在については肯定。
理由は
- 供給側の意図しない過剰な供給のあるていどの抑止力になるだろう
- DRMの存在する事によりコンテンツが著作権法等の保護を受けられるようになる
2番目の理由としてはDRMを施さないと保護してないと言われて裁判にならない場合もあるそうな。電子署名もコンテンツ保護には効果はあるけど、法の加護を得るには適切なDRMという事らしい。
現時点でのコンテンツ保護の適切な方法は"軽量DRM"だとしているようです。
で軽量DRMはどんなものかと言うと
- DRMを実現するコストを低くする
- ユーザの使いやすさを損なわない、または使用方法の制限が少ないようにしたい
みたいな感じでしょうか。PDFが良い例らしい。お金をかけてほぼ完全にクラックされない、クラックされても被害を最小限に抑えるようにするのも出来るけど、そのDRMの負担は誰がするのか？で良い答えが出ないんじゃないかと。
あと、ユーザビリティが損なわれてしまうのは避けたい。
ここで、上記を元に出されたEPUB LCPの機能要件をグーグル先生に毛が生えた程度に翻訳すると、
- 認証:
- 認証はユーザや端末に対してファイルをベースとする。しかしながら、他のモードの認証を追加する事もできる
- それぞれのファイルはそれぞれのパスワードが関連づけられます。パスワードはユーザに発行を求められる度にセットする。通常ではユーザがパスワードを入力するのは最初の1回目に彼がファイルを端末で開く時だけで、以後は無し。
- 他の端末で発行物を読む場合には、その他の端末で最も単純な方法でユーザはパスワードを入力しなければならない(例外は以後を参照)。他のユーザと発行物を共有する為に、パスワードは他のユーザと通信出来る物でなければならない。言い換えれば、他のユーザは正確にユーザが発行物を他のデバイスで読むのと同じようにできる共有です。他のケースは以下を参照。
- パスワードのフィールド名は各発行物のメタデータに含まれなければならない。("ユーザID"、"パスワード"、"ケンワート"、"図書カード番号"等)
- パスワードの意義はEPUB LCPでは定義されません。配信者の判断で設定するでしょう。例えば
- ユーザが各ファイルに設定できるようにする
- ユーザが一つのパスワードを全てのファイルに設定できるようにする
- ユーザが最低限の強度が要求されるように設定できるようにする(例えば、少なくともN文字や一つ以上の文字以外や数字以外など)
- 各ファイルを開いた時に再入力を要求するか選べるようにする
- 配信社がセットできるようにする(例えば、ユーザのEメールアドレスやユーザIDやクレジットカード番号等)
- パスワードは一方向ハッシュ形式のように不明瞭で回復不能な形式でクライアントのソフトウェアや端末に格納されるべきです。言い換えれば、パスワードスチールハッカーにはユーザが入力している不明瞭化されてたパスワードを掴ませるべきです。
- 使用制限の設定:
- タイトル毎に印刷自体、一度に急速に印刷可能な量、全量
- タイトル毎にクリップボードへのコピー、一度に急速にコピー可能な量、全量
- 編集の可否
- 利用の開始と終了の日時を設定(図書貸し出し等)、併せて分などの小さい粒度にも落とせる(提供されている図書館調査では貸し出し期間は時間単位)
- 編集とコピー/印刷等ののオプションに異なるパスワードを設定。
- コンテンツの保護:
- 最低でも1つのレベルの暗号化が必要:暗号化されたコンテンツの為の対称キー。加えて、転送やクライアントで全てのユースケースに必要とされるようなプロトココル(SSL等)やコンテンツ保護キーの為の非対称キーなどが必要とされるでしょう。
- コンテンツ暗号化の為のアルゴリズムはAESで最低でも128bitの強度が必要であり、オペレーショナルモードの実装があるべきです。2001年ベルギーで米政府の標準として紹介されたAESは仮想的な最新DRMの目的で使用されています。コードライブラりは広く存在しています。
- コンテンツキー保護のアルゴリズムはRSA-1024(安価)やECC-NIST-256(効率的)のような実装するのに標準的な効率的で安価な公開鍵/秘密鍵アルゴリズムであるべきです。
- キーの隠蔽方法は実装者に一任されます。
- キーの復元方法に家の番号が要求される事はサポートされない。
- サポート形式
- EPUB LCPはEPUB オープン・コンテナ・フォーマット(OCF)定義のencryption.xmlやrights.xml等に構築されることが期待されています。また、EPUB LCPはEPUBではない直接適用可能なフォーマットである事を予想していません。
- コードライブラリ:
- クライアント
- 最大限に携帯可能
- 電子読書アプリや端末に提案する為にAPIクライアントは良く文書化されている
- 多様なプログラム言語に呼び出される事が可能
- 実装者の選択する一般的プラットフォーム(Android、ios、Windows、Mac OS 等)で実装のリファレンス
- サーバ
- RESTfulウェブサービス
- WindowsやLinuxでの実装のリファレンス
- クライアント
ざっと読んだ感じだと簡易DRMは暗号化して、ユーザはパスワードを使って読めるようにしたらいんじゃないか？
って具合。"重量級DRM"はもっとごっつい事をやってますが、これならなんとなーく「それっぽいものは」できそうなレベル。
機能要件には無いけど、一番気になるクラックされた後の話は、、、
技術的保護手段を回避するような行為は（多くの国で）違法なので行政や法に委ねる。
を提案しています。 既にどこか知らない所で抜き取られたのを手にしたりばら撒いたりした場合も同様な手段を取るようになるんだろうと。
コンテンツの供給側と消費側の最初の妥協点が示された感じです。
どちらかと言うと消費側の権利を尊重するような内容に受取れるけど、、、供給側が賛同できるんだろうか。
0 件のコメント :
コメントを投稿