English

CMSにおけるCamellia暗号化アルゴリズムの使用法
(Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS))

本書の位置づけ

本書は、インターネット・コミュニティに対して、 インターネット標準化過程プロトコルを定義し、 その向上のための議論や提案を求めるものである。 このプロトコルの標準化状況やステータスについては、 "Internet Official Protocol Standards" (STD 1)の最新版を参照のこと。 本書の配布は、制限されていない。

著作権表記

Copyright (C) The Internet Society (2004). All Rights Reserved.

要旨

本書は、Cryptographic Message Syntax (CMS：暗号メッセージ構文)での暗号化のためにCamellia暗号アルゴリズムを使う規定を定義する。

1. はじめに English

本書は、Cryptographic Message Syntax (CMS：暗号メッセージ構文)での暗号化のためにCamellia暗号アルゴリズム [CamelliaSpec] を使う規定を定義する。 関係するオブジェクト識別子(object identifiers (OID))と処理ステップも提示しており、それにより、Camelliaは、 コンテントとキーの暗号化に対して、 CMS仕様(RFC 3369、RFC 3370)での使用が可能となる。

注意：本書は、最初の著者がNTTに勤務している時に作成されたものである。

1.1. Camellia English

Camelliaは、2000年、NTTと三菱電機により共同で開発された。 Camelliaは、128bitのブロック・サイズと128、 192および256bitキー・サイズを定義する。 これは、AED (Advanced Encryption Standard)と同じインターフェースである。 Camelliaは、ソフトウェアとハードウェアの両方の実装に対する適性、 そして、高度なレベルのセキュリティが特徴である。 実用面からの観点から見ると、Camelliaは、 インターネットや多くのアプリケーションで広く使われている32bitプロセッサ、 スマート・カードで使われる8bitプロセッサ、暗号ハードウェア、 組み込みシステムなどでのソフトウェアおよびハードウェアの実装において柔軟性を確保するよう設計されている [CamelliaTech]。 さらに、そのキーセットアップ時間は特に優れており、 そのキーの「軽快さ」は、AESのものよりずっと優れている。

Camelliaは、 暗号アルゴリズムを検証するためのいくつかのプロジェクトで、 広範囲な暗号コミュニティにより精査されている。 特に、Camelliaは、EU NESSIE (New European Schemes for Signatures, Integrity and Encryption)プロジェクト [NESSIE] により「推薦暗号プリミティブ」として選択されており、また、 日本の電子政府システム(e-Government systems)に対する暗号技術のリストに含まれている。 (これらの技術は、Japan CRYPTREC (Cryptography Research and Evaluation Committees) [CRYPTREC])によって選択されているものである)。

1.2. 用語 English

本書における"MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"および"OPTIONAL"という (このように大文字で示されている)キー・ワードは 、 [RFC2119] において説明されているように解釈されるものとする。

2. コンテントおよびキーの暗号化用オブジェクト識別子 English

本項は、 CamelliaがCMSでコンテントとキーを暗号化するのに使う必要のあるOIDと処理情報を説明する。

Camelliaは、 2種類の異なるオブジェクト識別子(OID)を提供することによって、 CMSでの対称暗号アルゴリズム(オプション)セットに追加される。 ひとつのOIDクラスは、コンテント暗号化アルゴリズムを定義し、 もうひとつは、キー暗号化アルゴリズムを定義する。 したがって、CMSエージェントは、正しいオブジェクト識別子を選択し、 必要なパラメータを提供し、そして、 プログラム・コードを実行することによりコンテントを暗号化するか、 あるいは、キーを暗号化するためにCamelliaを適用することができる。

2.1. コンテント暗号化用 OID English

Camelliaは、 [CMSALG] で定義されている対称暗号アルゴリズムセットに追加される。 3種類の異なるキー・サイズに対して、 Camelliaのコンテント暗号化アルゴリズム(CBC(Cipher Block Chaining)モード)は、以下のオブジェクト識別子によって識別される。

id-camellia128-cbc OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) 392 200011 61 security(1)
         algorithm(1) symmetric-encryption-algorithm(1) camellia128-cbc(2) }

id-camellia192-cbc OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) 392 200011 61 security(1)
         algorithm(1) symmetric-encryption-algorithm(1) camellia192-cbc(3) }

id-camellia256-cbc OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) 392 200011 61 security(1)
         algorithm(1) symmetric-encryption-algorithm(1) camellia256-cbc(4) }
    

AlgorithmIdentifierパラメータ・フィールドは、 存在していなければならない(MUST)。 そして、このパラメータ・フィールドはIVの値を持っていなければならない(MUST)。

CamelliaCBCParameter ::= CamelliaIV -- 初期化ベクター

CamelliaIV ::= OCTET STRING (SIZE(16))
    

プレーン・テキストは、[CMS] の6.3節で指定されているようにパディングされる。

2.2. キー暗号化用OID English

key-wrap/unwrap(キー・ラップ／アンラップ)プロシジャは、 Camelliaキー暗号化キー(KEK)でCamelliaコンテント暗号化キー(CEK)を暗号化／復号に使われるが、 これらの手順は、3章において定義されている。 キー暗号化キーの生成と配布は、本書の範囲外である。

Camelliaキー暗号化アルゴリズムは、 以下のオブジェクト識別子をもっている。：

id-camellia128-wrap OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) 392 200011 61 security(1)
         algorithm(1) key-wrap-algorithm(3) camellia128-wrap(2) }

id-camellia192-wrap OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) 392 200011 61 security(1)
         algorithm(1) key-wrap-algorithm(3) camellia192-wrap(3) }

id-camellia256-wrap OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) 392 200011 61 security(1)
         algorithm(1) key-wrap-algorithm(3) camellia256-wrap(4) }
    

いずれの場合でも、 AlgorithmIdentifierのパラメータ・フィールドは「不在」でなければならない(MUST)。 なぜなら、キー・ラッピング・プロシジャ自体が、 IVをどのように使うか、いつ使うかを定義するからである。 OIDは 、KEKキー・サイズを指定するが、 ラップされたCamellia CEKのサイズに関して、いかなる指定も行わない。 実装は、異なるKEKおよびCEKサイズを使うことができる(MAY)。 実装は、同じ長さを持つCEKとKEKをサポートしなければならない。 もし、異なる長さがサポートされている場合、 KEKは、CEKの長さ以上でなければならない(MUST)。

3. キー・ラップ・アルゴリズム English

Camelliaキー・ラッピングおよびアンラッピングは、 AESキー・ラップ・アルゴリズム [RFC3394] に遵守して行われる。 なぜなら、CamelliaとAESは、 同じブロック・サイズとキー・サイズを持っている(つまり、 128bitのブロック・サイズおよび128bit、 192bit および256bitのキー・サイズ)からである。

3.1. 表記法と定義 English

キー・ラッピング・アルゴリズムの説明においては、 以下の表記法が使われる。：

キー・ラップ・アルゴリズムでは、 Camelliaコードブックへの128bitインプットを形成する場合、 64bit単位のデータを連結するのに連結(concatenation)関数が使われる。 Camelliaコードブックからの128アウトプットを2つの64bit単位のデータに分割するのに抽出(extraction)関数が使われる。

3.2. Camelliaキー・ラップ English

Camelliaでのキー・ラップは、 [RFC3394] の2.2.1節と同じであり、その場合、 "AES"を"Camellia"に置き換えて読むことができる。

キー・ラッピング・プロセスに対するインプットは、KEKと、 ラップされるプレーンテキストとなる。 プレーンテキストは、64bitブロックから構成され、それらのブロックは、 ラップされるキー・データを含んでいる。 キー・ラッピング・プロセスが以下で説明されている。

インプット： Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and Key, K (the KEK).
アウトプット： Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.

1) 変数を初期化する。

A[0]を初期値に設定する(参照：3.4 節)。
For i = 1 to n
  R[0][i] = P[i]
    

2) 中間値を計算する。

For t = 1 to s, where s = 6n
  A[t] = MSB(64, Camellia(K, A[t-1] | R[t-1][1])) ^ t
  For i = 1 to n-1
    R[t][i] = R[t-1][i+1]
  R[t][n] = LSB(64, Camellia(K, A[t-1] | R[t-1][1]))
    

3) 結果を出力する。

Set C[0] = A[t]
For i = 1 to n C[i] = R[t][i]
    

キー・ラップ・アルゴリズムを別に説明すると、 シフト(shifting)の代わりにインデックス(indexing)を使うことができる。 このアプローチは、ラップされたキーを特定の場所で計算するのを可能にし、 前述でのローテーションをしないようにすることができる。 これは、まったく同じ結果となり、 ソフトウェアでの実装がより簡単である。

インプット： Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and Key, K (the KEK).
アウトプット： Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.

1) 変数を初期化する。

A = IV(初期値)と設定する(参照： 3.4 節)。
For i = 1 to n
  R[i] = P[i]
    

2) 中間値を計算する。

For j = 0 to 5
  For i=1 to n
    B = Camellia(K, A | R[i])
    A = MSB(64, B) ^ t where t = (n*j)+i
    R[i] = LSB(64, B)
    

3) 結果を出力する。

Set C[0] = A
For i = 1 to n
  C[i] = R[i]
    

3.3. Camelliaキー・アンラップ English

Camelliaでのキー・アンラップは、 [RFC3394] の2.2.2節と同じであり、その場合、 "AES"を"Camellia"に置き換えて読むことができる。

アンラップ・プロセスへのインプットは、KEKと、 以前にラップされたキーから構成されている暗号テキスト(ciphertext)の(n+1) 個の64bitブロックである。 このプロセスは、 復号されたキー・データのn個の64bitブロックから構成されているプレーンテキストのn個のブロックを返却する。

インプット： Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}, and Key, K (the KEK).
アウトプット： Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}.

1) 変数を初期化する。

A[s] = C[0]と設定する(s = 6n)
For i = 1 to n
  R[s][i] = C[i]
    

2) 中間値を計算する。

For t = s to 1
  A[t-1] = MSB(64, Camellia-1(K, ((A[t] ^ t) | R[t][n]))
  R[t-1][1] = LSB(64, Camellia-1(K, ((A[t]^t) | R[t][n]))
  For i = 2 to n
    R[t-1][i] = R[t][i-1]
    

3) 結果を出力する。

A[0]が正しい初期値であれば(参照：3.4節)：
Then
  For i = 1 to n
    P[i] = R[0][i]
Else
  Return an error
    

アンラップ・アルゴリズムは、 計算を特定の場所で行うようにするのを可能にするインデックス・ベースのオペレーションとしても定義することができる。 ここでも、これは、レジスタ・シフト・アプローチと同じ結果を出す。

インプット： Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}, and Key, K (the KEK).
アウトプット： Plaintext, n 64-bit values {P[0], P[1], ..., P[n]}.

1) 変数を初期化する。

Set A = C[0]
For i = 1 to n
  R[i] = C[i]
    

2) 中間値を計算する。

For j = 5 to 0
  For i = n to 1
    B = Camellia-1(K, (A ^ t) | R[i]) where t = n*j+i
    A = MSB(64, B)
    R[i] = LSB(64, B)
    

3) 結果を出力する。

Aが正しい初期値であれば(参照：3.4節)：
Then
  For i = 1 to n
    P[i] = R[i]
Else
  Return an error
    

3.4. キー・データのインテグリティ：初期値 English

初期値(IV)は、 ラッピング・プロセスの最初のステップでの A[0] に割り当てられる値を意味する。 この値は、キー・データでのインテグリティ・チェックを得るために使われる。 アンラッピング・プロセスの最初のステップでは、 A[0] のリカバリーされた値が、A[0] の期待値と比較される。 それらが一致すると、キーは正しいものとして受け入れられ、 アンラッピング・アルゴリズムはそれを返却する。 それらが一致しない場合、キーは拒否され、 アンラッピング・アルゴリズムはエラーを返却する。

このインテグリティ・チェックにより達成される正確な特性というのは、 初期値の定義に依存する。 異なるアプリケーションは、ある程度異なる特性を必要とする。 例えば、 キー・データのライフサイクル全体でインテグリティを判断する必要あるか、 あるいは、キー・データがアンラップされる場合にのみ必要かである。 本仕様は、キー・データがラップされる間に、 そのキー・データのインテグリティをサポートするディフォルト初期値を定義する (3.4.1節)。 また、別の初期値をサポートするための設定も提供されている (3.4.2節)。

3.4.1. ディフォルト初期値 English

ディフォルト初期値(IV)は、HEX定数と定義されている。

A[0] = IV = A6A6A6A6A6A6A6A6
    

IVとして定数を使うことにより、キー・データがラップされている間、 そのキー・データでの強力なインテグリティ・チェックをサポートすることになる。 アンラッピングが、A[0] = A6A6A6A6A6A6A6A6を生成するのであれば、 キー・データが不正となる可能性は、2^-64となる。 アンラッピングがA[0]＝ 他の値 を生成する場合、そのアンラッピングは、 エラーを返却する必要があり、いかなるキー・データをも返却してはならない。

3.4.2. 別の初期値 English

キー・ラップが、 より大きなキー・マネジメント・プロトコルやシステムの一部として使われる場合、 データ・インテグリティに対して必要とされる範囲は、 キー・データ以上におよぶか、または、 キー・データがラップされる期間以上の期間が必要となる。 また、キー・データが単なるCamelliaキーではない場合、 そのキー・データは、常に、64bitの倍数になるとは限らない。 初期値の別の定義は、そのような問題に対処するのに使うことができる。 [RFC3394] によれば、NISTは、必要に応じて、 今後のキー・マネジメントの発表において別の初期値を定義するとしている。 今後多くなるであろう一連の別の初期値に対処するために、 アプリケーション特有でないキー・ラップ実装は、 初期値がどのように設定されテストされるかについてなんらかの柔軟性を必要とするであろう。

4. SMIMECapabilities 属性 English

S/MIMEクライアントは、それがサポートする一連の暗号関数を、 S/MIME capabilities属性を使って発表する必要がある(SHOULD)。 この属性は、暗号関数のOIDの部分的リストを提供し、 クライアントにより署名されなければならない(MUST)。 それらの関数のOIDは、 関数カテゴリーで論理的に分離されている必要があり(SHOULD)、 それらのプリファレンスに関して順列化されなければならない(MUST)。

RFC 2633 [RFC2633] の2.5.2節は、 SMIMECapabilities署名属性(SMIMECapabilities signed attribute)が、アルゴリズムの部分リストを定義するのに (SMIMECapabilitiesを発表するソフトウェアがサポートできると) 使われることを定義する(SMIMECapability SEQUENCEのSEQUENCEとして定義されている)。

S/MIMEクライアントが、 Camelliaで対称暗号をサポートすることと求められる場合、 capabilities属性は、その対称的アルゴリズムのカテゴリーで、 上記で定義された Camellia OID を含んでいなければならない(MUST)。 このOIDに関連付けられているパラメータは、 CamelliaSMimeCapabilityでなければならない(MUST)。

CamelliaSMimeCapabilty ::= NULL
    

Camelliaを表すSMIMECapabilityシーケンスは、 以下のHEX文字列としてDERエンコードされなければならない(MUST)。

送信側エージェントが、暗号化されたメッセージを作成する場合、 そのエージェントは、 どのタイプの暗号化アルゴリズムを使うかを決める必要がある。 通常、その決定プロセスは、 受信者から受け取ったメッセージに含まれているcapabilities(機能)リストから得られた情報や、 個々の合意、ユーザ・プリファレンス、 法律的規制などの他の情報が関与している。 ユーザが、対称暗号にCamelliaを求める場合、それは、 送信側と受信側の両方で、 S/MIMEクライアントによってサポートされなければならない(MUST)し、 そして、 それはユーザ・プリファレンスで設定されていなければならない(MUST)。

5. セキュリティについての考慮事項 English

本書は、CMSメッセージのコンテントを暗号化するための、そして、 CMSメッセージのコンテントを暗号化するために使われる対称キーを暗号化するためのCamelliaの使用を定義する。 そして、他のメカニズムは、既存のものと同じである。 したがって、CMS仕様 [CMS] [CMSALG] で説明されているセキュリティに関する事柄や、 AESキー・ラップ・アルゴリズム [RFC3394] は、 本書に適用することが可能である。 Camelliaでは、 いずれのセキュリティ問題は発見されていない [CRYPTREC][NESSIE]。

6. 知的財産権表記 English

IETFは、実装の特許申請、あるいは、本書に記述された以外の技術の利用、 もしくは、そのような権利のもとで利用可能／利用不可なライセンスの程度について主張される可能性があるいかなる知的財産権もしくは他の権利の正当性もしくは範囲について中立である。； また、そのような権利を識別するためのあらゆる努力をしてきたと表現するものではない。 スタンダードトラックと標準関連文書における権利に関するIETFの手順についての情報は、 BCP-11にある。 入手可能な権利の主張と、あらゆる入手可能なライセンスの証明、もしくは、 一般ライセンスを入手する試みの結果、もしくは、この仕様について、 そのような財産権を実装者またはユーザが使用する許可についてのコピーは、 IETF事務局から入手可能である。

IETFは、 この標準を施行するために要求される可能性がある技術にあたる可能性があるあらゆる著作権、 特許もしくは特許利用、あるいは他の財産権への注目を寄せる、 いかなる利益主体も受け付けている。 IETFエグゼクティブディレクター宛に情報を寄せていただきたい。

IETFには、本書に含まれている仕様の一部、または、 すべてに関して主張されている知的所有権について通知がなされている。 詳細は、主張されている権利のオンライン・リストを参照のこと。

7. 参考文献

7.1. 規範的参考文献

7.2. 参考文献

付録A ASN.1 Module

CamelliaEncryptionAlgorithmInCMS
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs9(9) smime(16) modules(0) id-mod-cms-camellia(23) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

-- Camellia using CBC-chaining mode for key sizes of 128, 192, 256

id-camellia128-cbc OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) 392 200011 61 security(1)
      algorithm(1) symmetric-encryption-algorithm(1) camellia128-cbc(2) }

id-camellia192-cbc OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) 392 200011 61 security(1)
      algorithm(1) symmetric-encryption-algorithm(1) camellia192-cbc(3) }

id-camellia256-cbc OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) 392 200011 61 security(1)
      algorithm(1) symmetric-encryption-algorithm(1) camellia256-cbc(4) }

-- Camellia-IV is the parameter for all the above object identifiers.

Camellia-IV ::= OCTET STRING (SIZE(16))

-- Camellia S/MIME Capabilty parameter for all the above object

-- identifiers.

CamelliaSMimeCapability ::= NULL

-- Camellia Key Wrap Algorithm identifiers - Parameter is absent.

id-camellia128-wrap OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) 392 200011 61 security(1)
      algorithm(1) key-wrap-algorithm(3) camellia128-wrap(2) }

id-camellia192-wrap OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) 392 200011 61 security(1)
      algorithm(1) key-wrap-algorithm(3) camellia192-wrap(3) }

id-camellia256-wrap OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) 392 200011 61 security(1)
      algorithm(1) key-wrap-algorithm(3) camellia256-wrap(4) }

END
    

著者・翻訳者の連絡先

盛合 志帆
株式会社ソニー・コンピュータエンタテインメント
電話： +81-3-6438-7523
Fax： +81-3-6438-8629
EMail： camellia＠isl.ntt.co.jp (Camellia team)
　　　　shiho＠rd.scei.sony.co.jp (Shiho Moriai)

加藤 明洋
NTT ソフトウェア株式会社
電話： +81-45-212-7934
Fax： +81-45-212-9800
EMail： akato＠po.ntts.co.jp

著作権表記全文

Copyright (C) The Internet Society (2004). All Rights Reserved.

この文章とその翻訳は、複製し他人に配布する事ができ、 またその実装についてのコメント、その他の方法を用いた説明、 その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含む事によって、 その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、 及び配布する事ができる。 しかしながら、インターネット標準化プロセスにて定義されている著作権のための手続きに従わなければならないような場合の中でインターネット標準を開発するという目的に必要である、 あるいは英語以外の言語に翻訳する必要があるという場合を除いて、 この文章自体を、その著作権表示や、 インターネット学会あるいは他のインターネット団体への参照を削除するような、 いかなる変更もできない。

上で認めた制限された許諾は、永続的なものであり、 インターネット学会及びその継承者や譲渡者によって取り消される事は無い。

この文書とここに含まれた情報は、 "そのまま {AS IS}"である事を基に提供され、インターネット学会、 及びIETFは、この中の情報の使用が、 商用利用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していないという保障への制限を含め、 明示的に又は暗黙的に、全ての保障を放棄する。

謝辞

RFCエディター機能に対する資金提供は、現在、 インターネット・ソサエティ(Internet Society)により提供されている。