コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

チェックサム

出典: フリー百科事典『ウィキペディア(Wikipedia)』
検査合計から転送)

チェックサム(検査合計[1][2][3]: checksum)とは、ワード列の各ワードの総和を利用した誤り検出符号の一種である。他の誤り検出符号と比べて信頼性は低いものの、単純計算[注釈 1]で99.6%以上の検出率があるうえに計算が簡単であることから、簡易な誤り検出に用いられる。

名称・用語

[編集]

「チェックサム」という名称は、チェックサムの符号値そのものを指すこともある。

また、誤り検出その他データの検証のための符号として広く使われてきた経緯から、俗に誤り検出符号自体の代名詞としても用いられる場合がある。例えばCRCの符号値やMD5のハッシュ値を、それぞれ「CRCチェックサム」「MD5チェックサム」と呼ぶことがある。これらは算出方法が異なりsumでもないため、「チェックサム」と呼ぶことは語義的には正確ではないものの、「(チェックサムよりも)信頼性の高い[注釈 2]誤り検出符号」程度の意味で使われる。

算出方法

[編集]

算出方法は非常に簡単で、もっとも単純なものはワード列の個々のワードの総和 (sum) の下位1ワードをそのまま符号値とするものであり、1ワードを何ビットとするかは実装によって異なる。

例えば、1ワードが8ビットの以下のワード列の総和は(十六進法で)78であるので、その検査合計は「78」となる。

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

総和のどのビット群を符号値とするか、符号値をどのように扱うかなどで、派生した種類がある。

ネットワークを利用してのデータ送信時、IPパケットにデータを分割した際のIPヘッダの検査における利用例を以下に示す。

  1. IPヘッダのチェックサム欄にゼロをセット
  2. IPヘッダを16ビット単位で加算
  3. 総和の下位16ビットの補数をIPヘッダのチェックサム欄にセット
  4. 送信
  5. 受信したらIPヘッダを16ビット単位で加算
  6. 総和がゼロならば正常

チェックサム欄にはチェックサム欄がゼロの場合におけるチェックサムの補数がセットされているので、総和 = チェックサム欄以外のチェックサム + チェックサム欄以外のチェックサムの補数 = ゼロ になれば正しい。

Intel HEXなどのROMデータの場合、8bit単位で加算して32bit表示を行う事が一般的である。例えば12 34 56 78場合のチェックサムは0x12+0x34+0x56+0x78=0x00000114となる。

バリエーション

[編集]

チェックサムの実装にはいくつかバリエーションが考えられる。以下にいくつか例を示すが、これらに限られない。

チェックサム欄に書き込む値

[編集]

チェックサム欄には、合計値をそのまま書く場合と、上記のIPヘッダの例のように補数を書き込む場合がある。 補数を書き込むようにすると、「チェックサム欄の値も含めて計算を行い、ゼロ(あるいはある特定の数値)になれば正常」という方法で検査ができる。このような設計では、受信側でデータの長さが事前に分からない場合でも、通信が終了するまで全部足し込んでしまえば良いので、検査を行うことができる。

初期値問題

[編集]

チェックサム欄を非ゼロ値で初期化してから加算を行う実装もある。この場合、0x00 .... 0x00 (すべてゼロ) というデータに対してチェックサムが非ゼロ値になる。言い換えるとデータとチェックサム欄を含めた全体がすべて 0x00 というのは、チェックサムが不正なデータとなる。なんらかの理由でデータを正常に読み出せず 0x00 を受信してしまった場合、チェックサム欄をゼロ初期化する実装では、これを正常なデータと区別がつかないが、非ゼロ初期化ならエラーとなる。

位置依存

[編集]

上記の単純なチェックサムでは、一般的な誤りを検出できないことがある。例えば、データワードの順序の変更、すべてのビットがゼロのワードの挿入・削除などである。実用的に使われているチェックサムアルゴリズム、例えば フレッチャーのチェックサム, Adler-32, and 巡回冗長検査 (CRCs) のようなものでは、各ワードの値だけでなく、シーケンス内での位置も考慮することで、これらの弱点に対処している。一般にこれらの特徴により、チェックサムの計算コストは増大する。

信頼性

[編集]

単純な加算であるため、ワードを保持したまま列の順序のみ変化した場合には同じ値を示す。また、それ以外の誤りに対しても、符号値が同じになる確率は決して低くなく、誤り検出の方式としての信頼性は高くない。

また、チェックサムをはじめとする誤り検出符号ハッシュ関数と異なり、暗号化や改ざん防止技術の用途は考慮されていない。そのため、偶発的な誤りに対する耐性を高めるだけであり、意図的な改竄(チェックサムは同じで異なる内容にする)に対する耐性はない。特にチェックサムは単純な加算であることから、同じ符号値になる異なる内容を探すことが容易である。例えば、前述の語列(→#算出方法)の前半後半を入れ替えた列「08 09 0A 0B 0C 0D 0E 0F 00 01 02 03 04 05 06 07」も、チェックサム値は同じ78である。

意図的な改竄の例

[編集]

元の語列を前述の「00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F」とする。

これとまったく別のワード列「70 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00」のチェックサム値は72であるが、最後のバイトを「00」から「06」にすれば元のワード列と同一のチェックサム「78」となる。こうして、意図的にチェックサムの整合性を取ることができる。もしも、ある一連の語列処理機構が受け取ったワード列の正当性をチェックサムでのみ保証していた場合、この機構はこの別のワード列を元のワード列として誤って認識してしまうことになる。

脚注

[編集]

注釈

[編集]
  1. ^ 1オクテットの検査合計の場合28 − 1/280.996094、2オクテットなら216 − 1/2160.999985
  2. ^ もっとも、現在の暗号解読技術の前ではCRCやMD5はもはや「ちょっと高級なチェックサム」程度の信頼性しかないという意見もある[要出典]

出典

[編集]
  1. ^ JIS X 9204:2004「高精細カラーディジタル標準画像 (XYZ/SCID)」日本産業標準調査会経済産業省)3節「定義」1項
  2. ^ JIS X 0008:1997「情報処理用語—セキュリティ」日本産業標準調査会経済産業省(旧)用語番号08.03.05
  3. ^ JIS TR X 0055:2002「インターネット利用者のための用語」日本産業標準調査会経済産業省(公布期間外)用語番号2.18

関連項目

[編集]