原文:
Font Embedding for Open Container Format Files
公開日:
2010-05-31
翻訳者:
ろす

Open Container Format ファイルへのフォントの埋め込み

OFC[1]はOPF/OPSに準拠した電子出版物をパッケージするのに適した技術であ る。OCFは基本的にはzipファイルであるため、手近なzip ツールを使えば暗号化 されていないあらゆるコンテンツをパッケージから取り出すことができる。シス テムによってはzipファイルを他の（例えばフォルダのような）ネイティブなコ ンテナのように見せることもあるだろう。こうした機能はとても有用であるた め、サードパーティのフォントを出版物に内包したいと考える著者にとっては 問題となる。多くの商用フォントは埋め込みを許可しているが、フォントの埋め 込みは出版物の総体を構成する部品とすることを意味するのであって、コンテン ツとともにオリジナルのフォントファイルを提供するものではない。現代の大抵 のオペレーティングシステムはzipをサポートしており、単にフォントファイル をzipアーカイブに格納するだけでは、フォントを他の状況で再利用されないよ うにするのに不十分である。この不安要素は OPF/OPSによって可能となった埋め 込みフォントの有用性を損ないうる。


フォントが再利用されないように、フォントベンダーは、フォントが出版物に何 らかの形で結び付けられているならば、フォントをOCFコンテナに格納すること を許可するかもしれない。つまり、デバイスに組み込まれたツールを利用して フォントファイルを直接オペレーティングシステムにインストールしたり、他の OPF/OPF出版物で直接に使用したり出来ないか、ということである。フォント ファイルのデジタル著作権管理や利用システムを提供することは本仕様の範囲で はない。その代わりに、OCFを手に入れた者が内包するフォントファイルにアク セスするには追加の手続が必要となるような、難読化の手法を提案する。これが フォントベンダーの要求に沿ったものであることをIDPFは希望する。しかしなが らIDPFでは、この文書が暗号化について定めたものでもなければ、フォントファ イルが著作権を侵害されないことを保証するものでもないという異議は生まれな かった。ここで提案するメカニズムは単に、フォントライセンスの詳細を認識し ていない人々への障害を用意するだけのものである。正規のユーザがフォントに アクセスすることを妨げるものではない。これが個々のフォントライセンスの要 件を満たすものであるかは、ライセンスの許諾者にとっても被許諾者にとっても 疑問が残る。


難読化アルゴリズム


フォントファイルを難読化するためのアルゴリズムは、フォントファイルの先頭 の1040バイト（~1KB）を変換することによって形成される。1040バイト未満の ファイルではファイル全体が変換される。このアルゴリズムのキーは出版物の一 意の識別子である20バイト（160ビット）のSHA-1 ダイジェスト[3] でなければ ならない。このキーの生成に関する詳細は "Generating the Obfuscation Key" のセクションで解説する。オリジナルのデータを難読化するために、元のファイ ルに排他的論理和または(XOR)を行った結果、キーの最初のバイトが埋め込み フォントファイルの最初のバイトに格納される。このプロセスは次のソースと キーの間でも行われ、キーが持つ全てのバイトが使用されるまで繰り返す。この ように1040バイト全てがエンコードされる（またはソースの末尾に達する）と、 残ったソースのデータは宛先にそのままコピーされる。以下に疑似コードによる アルゴリズムを示す。


set source to font file
set destination to obfuscated file
set keyData to key for font
set outer to 0
while outer < 52 and not (source at EOF)
    set inner to 0
    while inner < 20 and not (source at EOF)
        read 1 byte from source     //Assumes read advances file position
        set sourceByte to result of read
        set keyByte to byte inner of keyData
        set obfuscatedByte to (sourceByte XOR keyByte)
        write obfuscatedByte to destination
        increment inner
    end while
    increment outer
end while
if not (source at EOF) then
    read source to EOF
    write result of read to destination
end if 

オリジナルのフォントデータに戻すには、単にこのプロセスを逆に行うだけであ る。ソースファイルは難読化されたデータであり、出力ファイルには元のフォン トデータが格納される。

難読化キーの識別

フォントを特定の出版物に紐付けるには、その出版物が持つ一意のプロパティに 結びつけることが必要である。このような値はOPF 2.0仕様にて要求されてお り、2.1 "パッケージの一意性"のセクションに詳述されている。適合した全ての OPFファイルは出版物を一意に識別するdc:identifier要素を持つ。OPF 2.0仕様はパッケージファイルの package要素が持つunique- identifier 属性を調べることで、この要素を探し出すと詳述してい る。この要素は出版物に一意であるために必要な特性を与えるが、そのまま難読 化のキーとして利用するには適していない（例えば長さについて定義されていな い）。


出版物に紐付いた適切なキーを作成するために、一意の識別子の SHA-1ダイジェ ストはSecure Hash Standard[3]が指定する形で生成されるべきである。ダイ ジェストを生成する前に、XML 1.0 仕様書[4]のセクション2.3で定義されたホワ イトスペース文字は取り除かれる。具体的には、Unicodeのコードポイントが 0x20、0x09、 0x0D、0x0Aである文字はダイジェストを計算する以前に文字列か ら取り除かれる。このダイジェストは "難読化アルゴリズム" のセクションで述 べるアルゴリズムに直接使用される。


難読化されたリソースの指定

OCF仕様書のセクション3.5.5では、OCFのあらゆる暗号化されたデータは出版物 とともにencryption.xmlに記述されなければならない(must)としてい る。 EncryptedData要素の子要素であるEncryptionMethodo要素はAlgorithm属性 の値に "http://www.idpf.org/2008/embedding" を持たなければならない。この 属性の存在は本仕様書で述べたアルゴリズムが使用されていることを示す。この アプローチを使用して難読化されたすべてのリソースはCipherData要素の中に 記述されなければならない(must)。


encryptionファイルは以下のように見えるだろう：


<encryption 

xmlns="urn:oasis:names:tc:opendocument:xmlns:container" xmlns:enc="http://www.w3.org/2001/04/xmlenc#">

<enc:EncryptedData> 
<enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding"/>
<enc:CipherData> 
<enc:CipherReference URI="OEBPS/Fonts/BKANT.TTF"/> 
</enc:CipherData>
</enc:EncryptedData> 

</encryption>

埋め込みフォントが他の出版物に簡単にコピーされないために、キーは encryption.xmlの内部に明示されてはならない (must)。本仕様を実装し たリーディングシステムはパッケージの一意の識別子からキーを抽出しなけ ればならない(must)。

リファレンス

[1] OCF http://www.idpf.org/ocf/ocf1.0/index.htm 


[2] OPF: 最新ドラフトは http://www.idpf.org/doc_library/informationaldocs/OPS/OPF_2.0_0.7_draft.htm *1にて入手可能で ある。  


[3] SHA-1: http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf 


[4] XML 1.0: http://www.w3.org/TR/REC-xml/ 


訳者注
*1：
現在は http://www.idpf.org/2007/opf/OPF_2.0_final_spec.html として勧 告されている。