本書において説明している Kerberos プロトコルは、ストリーム暗号技術を使用するように設計されていて、Data Encryption Standard [11] などの一般的に利用可能なブロック暗号技術をブロック チェーン化とチェックサム方式 [12] とともに使ってシミュレートできます。暗号化は、メッセージ交換に関係しているネットワーク エンティティの識別を証明するのに使用されます。各レルムの鍵配布センターは、秘密鍵を信頼性のある状態で格納することにおいて、そのレルムに登録されているすべてのプリンシパルによって信頼されています。プリンシパルの認証を検証する ために、この秘密鍵を知っているという証明が使用されます。
KDC は、プリンシパルの秘密鍵を使用するか (AS 交換で)、セッション鍵を共有して (TGS 交換で)、チケット要求に対する応答を暗号化します。つまり、秘密鍵またはセッション鍵を取得するためには、適切な鍵と KDC の識別を知っていなければならないことを意味します。プリンシパルは、KDC 応答を復号し、チケットと適切に形成した認証子 (KDC の応答のセッション鍵で生成した) をサービスに提出して、プリンシパルの識別を検証します。同様に、サービスは、チケットからセッション鍵を取り出して、応答でそれを知っていることを証明し、サービスの識別を検証します。
Kerberos プロトコルは、通常、使用している暗号化は暗号解読に対して安全であると想定します。ただし、場合によっては、いい加減に選んだ鍵による影響を最小限にするために、メッセージの暗号化部分のフィールドの順序が調整されることがあります。優れた鍵を選ぶことは重要です。ユーザーが入力したパスワードから鍵を取り出す 場合、より攻撃が難しくなるようにこれらのパスワードを吟味する必要があります。また、いい加減に選んだ鍵は、侵入者にとって簡単な標的になります。
以降の節では、Kerberos で現在定義されている暗号化とチェックサムのメカニズムについて説明します。それぞれの符合化、チェーン化、およびパディングの要件についても説明しています。暗号化方式については、メッセージの先頭部分にランダム情報 (コンファウンダ (混乱要素) とも呼ばれる) を配置しておくことが望まれます。コンファウンダの要件については、各暗号化メカニズムで指定されています。
暗号化システムのいくつかは、ブロック チェーン化方式を使用して、暗号文のセキュリティ特性を向上させています。ただし、これらのチェーン化方式は、復号での完全性チェックは提供していません。そのようなシステム (DES-CBC モード) は、復号で検証でき、改ざんや損傷を検出するのに使用できる平文のチェックサムで増大させる必要があります。そのようなチェックサムは、入力に含まれているバースト エラーを検出するのに優れています。損傷が検出された場合、復号ルーチンが、完全性（インテグリティ）チェックが失敗したことを示すエラーを返すはずです。各暗号化タイプは、適切なチェックサムを提供し、検証します。各暗号化方式の仕様は、チェックサムの要件について説明しています。
最後に、ユーザーのパスワードから鍵を取り出す場合に必要な、パスワードを適切なタイプの鍵に変換するアルゴリズムが含まれています。「文字列から鍵ヘ変換」機能は一方向であることが望ましく、異なるレルムではマッピングが異なっていることが望まれます。複数のレルムに登録されているユーザーは、ほとんどの場合すべてのレルムで同じパスワードを使用するため、これは重要です。また、あるレルムの Kerberos サーバーを攻撃した攻撃者が、他のレルムのユーザーの鍵を取得したり取り出せなくなることが望まれます。
Kerberos で使用可能な暗号化とチェックサム方式の完全性特性については、[13] を参照してください。
以下の ASN.1 定義は、すべての暗号化されたメッセージを表します。第 5 章で説明しているメッセージの暗号化されていない部分にある enc-part フィールドは、暗号化タイプ、オプションの鍵バージョン番号、暗号文で構成されているシーケンスです。
EncryptedData ::= SEQUENCE { etype[0] INTEGER, -- EncryptionType kvno[1] INTEGER OPTIONAL, cipher[2] OCTET STRING -- 暗号文 }
etype このフィールドは、暗号を暗号化するために使用する暗号化アルゴリズムを識別します。選択した暗号化タイプの詳細仕様については、この節の最後で説明します。
kvno このフィールドは、データを暗号化する鍵のバージョン番号を含んでいます。これは、プリンシパルの秘密鍵などの、有効期限の長い鍵で暗号化されたメッセージ内だけに存在します。
cipher このフィールドは、OCTET STRING として符合化された暗号化テキストを含みます。
cipher フィールドは、メッセージとアルゴリズム固有の入力で構成されているデータに、指定された暗号化アルゴリズムを適用することで生成されます。Kerberos で使用するように定義されている暗号化メカニズムは、平文の完全性（インテグリティ）を保証するために十分な評価を行わなければなりません。また、あらかじめ演算されているディクショナリへの攻撃に対する保護も、評価することをお勧めします。暗号化アルゴリズム自体は保護機能を持っていないため、チェックサムやコンファウンダを追加して保護を強化します。
推奨する暗号化データの形式は、コンファウンダ、チェックサム、符合化された平文、および必要なパディングを含みます。msg-seq フィールドは、第 5 章で説明したプロトコル メッセージの一部分を含んでいて、これを暗号化する必要があります。コンファウンダ、チェックサム、パディングは、すべてタグなしで、タイプ化されていません。それらの長さは適切な項目を保持するのに十分な長さになっています。タイプと長さは暗黙的で、使用されている特定の暗号化タイプ (etype) で指定されています。暗号化するデータの形式について、以下の図で説明しています。
コンファウンダ チェック msg-seq パッド
形式は、ASN.1 で表すことはできませんが、ASN.1 に類似した表記法で表すと以下のようになります。
CipherText ::= ENCRYPTED SEQUENCE { confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL, check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, msg-seq[2] MsgSequence, pad UNTAGGED OCTET STRING(pad_length) OPTIONAL }上記の仕様では、UNTAGGED OCTET STRING(length) は、タグと長さが取り除かれたオクテット文字列の表記法です。これは有効な ASN.1 タイプではありません。タグのビットと長さは、コンファウンダから取り除かなければなりません。これは、メッセージはランダム データで開始されるが、タグとその長さは固定されていることがコンファウンダの目的であるためです。他のフィールドでは、長さとタグは暗号化タイプで指定されるため、それらを入れると重複します。
適切な長さのランダムなコンファウンダを生成するには、confounder にそれを配置し、ゼロが不足している部分をチェックし、confounder、check、msg-seq に対して適切なチェックサムを計算し、結果を check に配置します。必要なパディングを追加し、指定した暗号化タイプと適切な鍵を使用して暗号化します。
特に指定しない限り、チェックサム、confounder フィールドの長さ、またはパディングのオクテット境界を指定する暗号化アルゴリズムの定義は、この暗号文形式を使用します (CipherText のフィールドの順序は重要です。また、この形式で符合化されているメッセージは、msg-seq フィールドの長さ部分を含んでいる必要があります。これによって、受領者はメッセージが切り詰められていないことを検証できます。長さが含まれていないと、攻撃者は選択した 平文への攻撃を使用して、切り詰められたメッセージを生成できます。この場合、チェックサムは変更しません。msg-seq が、ASN.1 SEQUENCE または OCTET STRING を符合化したものである場合、長さはその符合の一部分になります)。指定されていないフィールドは省略されます。
特定の暗号化タイプを使用しているすべての実装が、同じタイプを使用している他のすべてのものと通信できるようにするために、暗号化タイプの仕様では、暗号化処理の一部分として必要なあらゆるチェックサムを定義しています。代替のチェックサムを使用した 場合、新しい暗号化タイプを定義する必要があります。
いくつかの暗号化は、鍵と暗号化するデータのほかに追加の情報を要求します。たとえば、DES を暗号ブロック チェーン モードで使用した場合、初期ベクタが必要になります。これが要求された場合、各暗号化タイプの記述はそのような追加情報のソースを指定する必要があります。
以下のシーケンスは、暗号化鍵の符合化を表しています。
EncryptionKey ::= SEQUENCE { keytype[0] INTEGER, keyvalue[1] OCTET STRING }
keytype このフィールドは、この次の keyvalue フィールドで指定する暗号化鍵のタイプを指定します。複数のアルゴリズムが同じタイプの鍵を使用しますが、このフィールドは、ほとんどの場合 EncryptedData を生成するのに使用した暗号化アルゴリズムと対応します (マッピングは多対一です)。
たとえば、暗号化アルゴリズムが完全性チェックに代替チェックサム アルゴリズムを使用したり、異なるチェーン化メカニズムを使用した場合にこれが起こります。
keyvalue このフィールドは、オクテット文字列として符合化された鍵自体を含んでいます。
暗号化鍵タイプの負の値はすべて、ローカルでの使用のために予約されています。負以外のすべての値は、公式に割り当てられたタイプ フィールドと解釈用に予約されています。
暗号化を使用していない場合、暗号化システムはヌル暗号化システムと呼ばれます。ヌル暗号化システムでは、チェックサム、コンファウンダ、パディングはありません。暗号文は、単なる 平文です。ヌル暗号化システムでは、ヌル鍵が使用され、長さはゼロ オクテットで、keytype はゼロ (0) です。
des-cbc-crc 暗号化モードは、Data Encryption Standard [11] に従っている情報を、サイファー ブロック チェーン化モード [12] を使用して暗号化します。CRC-32 チェックサム (ISO 3309 [14] で説明している) がコンファウンダとメッセージ シーケンス (msg-seq ) に適用され、cksum フィールドに配置されます。DES ブロックは 8 バイトです。結果として、暗号化するデータ (コンファウンダ、チェックサム、メッセージを連結したもの) は、暗号化する前に 8 バイト境界になるようにパッドしなければなりません。このデータの暗号化の詳細は、des-cbc-md5 暗号化モードのものと同じです。
CRC-32 チェックサムは、耐衝突性がないため、コンファウンダが使用されていたとしても [13]、攻撃者は「確率的に選択された平文攻撃」を行って有効なメッセージを生成できます。そのような攻撃が重大な脅威となる場合には、耐衝突性のチェックサムを使用することをお勧めします。Kerberos v5 仕様 1 (特定の詳細については 9.1 節を参照のこと) の相互運用性要件により、CRC-32 をチケットや認証子のチェックサムとして必ず使用する必要はなくなりました。
des-cbc-md4 暗号化モードは、Data Encryption Standard [11] に従っている情報を、サイファー ブロック チェーン化モード [12] を使用して暗号化します。MD4 チェックサム ([15] で説明している) がコンファウンダとメッセージ シーケンス (msg-seq ) に適用され、cksum フィールドに配置されます。DES ブロックは 8 バイトです。結果として、暗号化するデータ (コンファウンダ、チェックサム、メッセージを連結したもの) は、暗号化する前に 8 バイト境界になるようにパッドされなければなりません。このデータの暗号化の詳細は、descbc-md5 暗号化モードのものと同じです。
des-cbc-md5 暗号化モードは、Data Encryption Standard [11] に従っている情報を、サイファー ブロック チェーン化モード [12] を使用して暗号化します。MD5 チェックサム ([16] で説明している) がコンファウンダとメッセージ シーケンス (msg-seq ) に適用され、cksum フィールドに配置されます。DES ブロックは 8 バイトです。結果として、暗号化するデータ (コンファウンダ、チェックサム、メッセージを連結したもの) は、暗号化する前に 8 バイト境界になるようにパッドされなければなりません。
平文と DES 暗号文は、8 オクテットのブロックに符号化され、DES アルゴリズム用の 64 ビットの入力になるように連結されます。最初のオクテットは、8 つの最上位ビットを供給し (オクテットの MSbit を DES 入力ブロックの MSbit として使用して)、2番目以降のオクテットは後続の 8 ビットを順に供給します。そして 8 番目のオクテットは 8 つの最下位ビットを供給します。
サイファー ブロック チェーン化を使用した DES に従った暗号化は、初期化ベクタの形式の追加入力を必要とします。特に指定されていない限り、初期化ベクタには 0 を使用します。Kerberos が DES を使用する場合、8 オクテットのコンファウンダを必要とします。
DES 仕様では、「弱い」鍵と「やや弱い」鍵を識別しています。これらの鍵は、Kerberos で使用する暗号化メッセージでは使用してはいけません。さらに、鍵がチェックサムの暗号化のために取り出される方法を考えた場合、定数 F0F0F0F0F0F0F0F0 で排他的論理和を行ったときに「弱い」鍵と「やや弱い」鍵を生成する鍵は使用してはいけません。DES 鍵は、keytype 1 の 8 オクテットのデータです。これは、56 ビットの鍵と、8 ビットのパリティ (オクテットあたり 1 ビット) で構成されています。鍵は、MSB 順序で記述された一連の 8 オクテットとして符号化されています。鍵内のビットも MSB 順序で符号化されています。たとえば、暗号化鍵が B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8 の場合 (B1 〜 B56 は MSB 順序の鍵ビットで、P1 〜 P8 はパリティ ビット)、鍵の最初のオクテットは B1,B2,...,B7,P1 になります (B1 を MSbit として)。[FIPS 81 の「はじめに」を参照のこと] DES 鍵をテキスト文字列 (パスワード) から生成する場合、テキスト文字列には通常レルムが含まれていなければならず、それにプリンシパルの名前の各構成要素が追加されます (場合によっては、互換性のために異なる「混ぜ合わせた」文字列を使用する必要があります。詳しくは、5.4.2 節の padata を参照してください)。その後、8 バイト境界まで ASCII のヌルでパッドされ、折りたたまれ、自分自身で排他的論理和を実行して 8 バイトの DES 鍵を形成します。パリティは鍵で補正され、初期文字列で DES CBC チェックサムを生成するのに使用されます (レルムと名前が追加されて)。次に、パリティは、CBC チェックサムで補正されます。結果が DES 仕様で説明している 「弱い」または「やや弱い」鍵と一致する場合、定数 00000000000000F0 で排他的論理和が実行されます。最後に、結果は鍵として返されます。擬似コードを以下に示します。
string_to_key(文字列,レルム,名前) {
odd = 1;
s = 名前 + レルム;
for(名前で表した各コンポーネント) {
s = s + コンポーネント;
}
tempkey = NULL;
pad(s); /* 8 バイト境界までヌルでパッドする */
for(8byteblock in s) {
if(odd == 0) {
odd = 1;
reverse(8byteblock)
}
else odd = 0;
tempkey = tempkey XOR 8byteblock;
}
fixparity(tempkey);
key = DES-CBC-check(s,tempkey);
fixparity(key);
if(is_weak_key_key(key))
key = key XOR 0xF0;
return(key);
}
以下は、チェックサムで使用している ASN.1 定義です。
Checksum ::= SEQUENCE { cksumtype[0] INTEGER, checksum[1] OCTET STRING }
cksumtype このフィールドは、添付されるチェックサムの生成に使用するアルゴリズムを示します。 checksum このフィールドは、オクテットの文字列として符号化されたチェックサムを含んでいます。
選択しているチェックサム タイプの詳細仕様は、この節の後半で説明しています。チェックサム タイプの負の値は、ローカルで使用するために予約されています。負以外のすべての値は、公式に割り当てられたタイプ フィールドと解釈用に予約されています。
Kerberos が使用するチェックサムは、耐衝突性があるかどうかと、鍵付きであるかどうかの 2つの状態によって分類できます。耐衝突性チェックサム用の同じチェックサム値を生成する 2つの平文を探すことは不可能です。鍵は、鍵付きチェックサム内のアルゴリズムを攪拌または初期化する必要があります。攻撃者によるメッセージ ストリーム修正を防止するためにも、鍵が付いていないチェックサムは、チェックサムとメッセージがあとで暗号化される場合だけ使用すべきです (たとえば、この節の最初で説明しているように、チェックサムが暗号化アルゴリズムの一部分として定義されている場合)。メッセージに入れる前にチェックサム値が暗号化されていれば、耐衝突性チェックサムに耐改ざん性を持たせることもできます。この場合、チェックサムと暗号化アルゴリズムの構成は、個別のチェックサム アルゴリズムとして考えられます (たとえば、DES を使用した RSA-MD5 暗号化は、タイプ RSA-MD5-DES の新しいチェックサム アルゴリズムです)。Kerberos は、耐衝突性チェックサムの暗号化された形式と、ほとんどの鍵付きチェックサムに対して、チェックサムが計算される前にコンファウンダを付加します。
CRC-32 チェックサムは、ISO 3309 [14] で説明しているように、巡回冗長検査に基づいてチェックサムを計算します。結果のチェックサムの長さは、4 オクテットです。CRC-32 は、鍵付きでも耐衝突性でもありません。このチェックサムを使用することはお勧めしません。[13] で説明している「確率的に選択された平文攻撃」を使用する攻撃者は、チェックサムを満足する代替メッセージを生成することができます。そのような攻撃が重大な脅威となる場合には、耐衝突性のチェックサムを使用することをお勧めします。
RSA-MD4 チェックサムは、RSA MD4 アルゴリズム [15] を使用してチェックサムを計算します。アルゴリズムは、任意の長さの入力と入力メッセージを受け付け、128 ビット (16 オクテット) チェックサムの出力を生成します。RSA-MD4 は、耐衝突性があると考えられています。
RSA-MD4-DES チェックサムは、鍵付きの耐衝突性チェックサムを次のように計算します。まず、テキストの前に 8 オクテットのコンファウンダを追加し、RSA MD4 チェックサム アルゴリズムを適用します。そして、変形鍵を使用して DES-CBC モードの暗号化を実行してコンファウンダとチェックサムを暗号化します。この変形鍵は、鍵と定数 F0F0F0F0F0F0F0F0 の排他論理和の結果です (変形鍵は、チェックサムを生成する機能をセッション鍵を使用して行う他の暗号化から切り離し、鍵の使用を特定の機能に制限する場合に使用します。定数 F0F0F0F0F0F0F0F0 を使用するのは、鍵のパリティが維持されるためです。DES の性質により、補数を使用する必要はありません。Privacy Enhanced Mail 標準の Message Integrity Check で同じ定数が同じ目的で使用されています)。初期化ベクタは 0 でなければなりません。結果のチェックサムの長さは 24 オクテットです (そのうち 8 オクテットは重複しています)。このチェックサムは、耐改ざん性があり、耐衝突性があると考えられています。
DES 仕様では、いくつかの「弱い」鍵を識別しています。これらの鍵は、Kerberos で使用する RSA-MD4 チェックサムの生成では使用してはいけません。
チェックサムの形式を以下の図に示します。
des-cbc(コンファウンダrsa-md4(コンファウンダ+メッセージ),key=var(key),iv=0)
この形式は ASN.1 では表せませんが、ASN.1 に類似した表記で表すと次のようになります。
rsa-md4-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { confounder[0] UNTAGGED OCTET STRING(8), check[1] UNTAGGED OCTET STRING(16) }
RSA-MD5 チェックサムは、RSA MD5 アルゴリズムを使用してチェックサムを計算します [16]。アルゴリズムは、任意の長さの入力と入力メッセージを受け付け、128 ビット (16 オクテット) チェックサムの出力を生成します。RSA-MD5 は、耐衝突性があると考えられています。
RSA-MD5-DES チェックサムは、鍵付きの耐衝突性チェックサムを次のように計算します。まず、テキストの前に 8オクテットのコンファウンダを追加し、RSA MD5 チェックサム アルゴリズムを適用します。そして、変形鍵を使用して DES-CBC モードの暗号化を実行してコンファウンダとチェックサムを暗号化します。この変形鍵は、鍵と定数 F0F0F0F0F0F0F0F0 の排他論理和の結果です。このチェックサムは、耐改ざん性があり、耐衝突性があると考えられています。
DES 仕様では、いくつかの「弱い」鍵を識別しています。これらの鍵は、Kerberos で使用する RSA-MD5 チェックサムの暗号化では使用してはいけません。
チェックサムの形式を以下の図に示します。
des-cbc ( コンファウンダrsa-md5 (コンファウンダ + メッセージ),key=var(key),iv=0)
この形式は ASN.1 では表せませんが、ASN.1 に類似した表記で表すと次のようになります。
rsa-md5-des-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { confounder[0] UNTAGGED OCTET STRING(8), check[1] UNTAGGED OCTET STRING(16) }
6.4.6. DES サイファー ブロック チェーン (Cipher Block Chained) チェックサム (des-mac) English
DES-MAC チェックサムは、次のように計算されます。まず、平文に 8 オクテットのコンファウンダを追加して、結果に対して鍵と初期化ベクタ 0 を使用して DES CBC モードの暗号化を実行します。暗号文の最後のブロックを取り出し、同じコンファウンダを追加して、変形鍵を使用して DES CBC モードの暗号化を実行してペアを暗号化します。この変形鍵は、鍵と定数 F0F0F0F0F0F0F0F0 の排他論理和の結果です。初期化ベクタは 0 でなければなりません。結果のチェックサムの長さは 128 ビット (16 オクテット) で、そのうち 64 ビットは重複しています。このチェックサムは、耐改ざん性と耐衝突性があります。
チェックサムの形式を以下の図に示します。
des-cbc(コンファウンダdes-mac(コンファウンダ+メッセージ, iv=0, key), key=var(key),iv=0)
この形式は ASN.1 では表せませんが、ASN.1 に類似した表記で表すと次のようになります。
des-mac-checksum ::= ENCRYPTED UNTAGGED SEQUENCE { confounder[0] UNTAGGED OCTET STRING(8), check[1] UNTAGGED OCTET STRING(8) }
DES 仕様では、「弱い」鍵と「やや弱い」鍵を識別しています。これらの鍵は、Kerberos で使用する DES-MAC チェックサムの生成では使用してはいけません。また、「弱い」変形鍵と「やや弱い」変形鍵も使用してはいけません。
RSA-MD4-DES-K チェックサムは、鍵付き耐衝突性チェックサムを次のように計算します。まず、RSA MD4 チェックサム アルゴリズムを適用し、その結果に対して DES 鍵を鍵と初期化ベクタとして使用して DES-CBC モードの暗号化を実行します。結果のチェックサムの長さは、16 オクテットです。このチェックサムは、耐改ざん性があり、耐衝突性があると考えられています。このチェックサムのタイプは、RSA-MD4-DES チェックサムを符号化する古い手法で、その使用はお勧めしません。
DES-MAC-K チェックサムは、平文に対して DES CBC モードの暗号化を実行し、暗号文の最後のブロックをチェックサム値として使用して計算されます。暗号化鍵と初期化ベクタで鍵付けされています。追加の初期化ベクタを指定しない場合、鍵と初期化ベクタの両方に鍵が使用されます。結果のチェックサムの長さは 64 ビット (8 オクテット) です。このチェックサムは耐改ざん性と耐衝突性があります。このチェックサムのタイプは、DESMAC チェックサムを符号化する古い手法であるため、使用することはお勧めしません。
DES 仕様では、いくつかの「弱い」鍵を識別しています。これらの鍵は、Kerberos で使用する DES-MAC チェックサムの暗号化では使用してはいけません。