届いた案内は本当にアオイが作ったのか、途中で書き換わっていないか。ハッシュや MAC では足りない理由から、秘密鍵で作り公開鍵で確かめる電子署名の仕組みと、署名で分かること・分からないことを図の動きで追います。
第4章では、公開鍵と秘密鍵という対になった鍵で、相手にだけ読める形にして送る方法を見ました。この章では同じ鍵の組を、別の目的に使います。
ボブのもとに、アオイから「会議は10時」という案内が届きました。社内の誰が知ってもよい内容なので、秘密にする必要はありません。ボブが知りたいのは、これを本当にアオイが作ったのか、そして途中で誰かが「11時」に書き換えていないか、の二つです。
この二つを確かめる仕組みが 電子署名（デジタル署名）です。図の上に浮かんだ二つの問いに、文書に添えた短いデータで答えます。紙のサインと名前は似ていますが、中身はまったく別物です。次のページで、その違いから見ていきましょう。
紙の書類なら、手書きのサインが「本人が書いた」ことの手がかりになります。では手書きサインを画像にして文書に貼ればよいかというと、デジタルの世界ではうまくいきません。画像はただのデータなので、そのままコピーできるからです。
図では、アオイのサインの画像が「会議は11時」という別の文書へ写されています。写した画像は元と寸分違わないので、見た目からは偽物と区別できません。サインの画像は、文書の中身と何のつながりも持っていないのです。
暗号技術の電子署名はここが違います。署名の値は文書のバイト列（コンピューターが扱う 0 と 1 の並び）から計算されるので、文書が1文字でも変われば合わなくなります。そして、その値を作れるのは特定の鍵を持つ人だけです。まずは、これまでの章で見た道具で同じことができないかを試してみます。
第2章のハッシュ関数を思い出してください。文書から短い「指紋」（ハッシュ値）を計算でき、文書が少しでも変わると指紋もまったく別の値になりました。それなら、文書に指紋を添えて送れば改ざんが分かりそうです。
ところが図の真ん中の書き換える人は、文書を「11時」に変えたあと、新しい文書の指紋を自分で計算し直して添えています。ハッシュ関数は誰でも使える公開された計算なので、これを止める手段はありません。受け取ったボブが指紋を計算して照らし合わせると、ぴったり一致してしまいます。
ハッシュ値は「この文書とこの指紋が対応している」ことは示せても、「誰がその指紋を作ったか」は示せません。足りないのは、特定の人にしか作れないという性質です。
第3章の MAC（メッセージ認証コード）は、この弱点を補いました。アオイとボブだけが知る共通鍵 K でタグを計算するので、K を持たない書き換える人には正しいタグを作れません。二人のあいだで改ざんを見つけるだけなら、MAC で十分に役立ちます。
困るのは、二人以外の人に示したいときです。図の下の第三者から見ると、K はアオイもボブも持っているので、タグを作ったのがどちらなのか区別できません。ボブがあとから自分で「会議は11時」にタグを付けても、アオイが作ったものと見分けがつかないのです。
さらに、第三者自身にタグを確かめてもらうには、その人にも K を渡す必要があります。K を受け取った人は、確かめるだけでなく、正しいタグを作ることもできてしまいます。確かめる力と作る力が同じ一本の鍵に入っていることが、MAC の限界です。
そこで、第4章の鍵の組を使います。アオイは、自分だけが持つ 秘密鍵（図の赤い鍵）と、誰に見せてもよい 公開鍵（青い鍵）の組を用意しておきます。
案内に署名するとき、アオイは文書と秘密鍵を署名の処理に入れます。すると図の右に、紫色の 署名値 が出てきます。署名値は数十〜数百バイトほどのデータで、文書の中身と秘密鍵の両方から決まります。多くの方式では、処理の内部で文書のハッシュ値を計算してから鍵を使います。どこでハッシュを使うかは方式ごとに決まっているので、プログラムを書くときは自分でハッシュを足したりせず、ライブラリーの決まった使い方に従います。
よく使われる方式は、米国の標準 NIST FIPS 186-5 にまとめられた RSA、ECDSA、EdDSA などです。どの方式でも、秘密鍵はアオイの手元から一度も出ていきません。
アオイがボブに送るのは、案内の文書と、それに添えた署名値の二つです。図では、二つがそろってボブのそばへ移りました。文書そのものは暗号化していないので、途中で見た人にも「会議は10時」と読めます。
アオイの公開鍵は、これとは別に前もってボブへ渡してあります。公開鍵は名前のとおり公開してよい鍵なので、ウェブサイトに載せても、メールに書いて送っても構いません。図の下で、青い鍵がアオイからボブへ移っているのがそれです。
一方、赤い秘密鍵はアオイのそばに残ったままです。署名の仕組みでは、秘密鍵を誰かに渡す場面が一度もありません。二人で同じ鍵を分け持つ MAC との大きな違いがここにあります。
ボブは、届いた文書・署名値・アオイの公開鍵の三つを 検証 の処理に入れます。図の箱の中に三つが集まり、右に「成功」が出ました。検証の処理が返すのは、成功か失敗かのどちらかだけです。
成功が意味するのは、「この公開鍵と組になった秘密鍵で、まさにこの文書に対して作られた署名値だ」ということです。秘密鍵を持っているのはアオイだけなので、ボブは、案内がアオイの手で署名され、そのあと書き換えられていないと判断できます。
検証では、ボブの側に何の秘密も要らない点にも注目してください。使ったのは、誰でも手に入る公開鍵だけです。ですから、同じ確認はボブ以外の人にもできます。次のページでは、確かめる人を増やしてみます。
図では、ボブのほかに検証者が二人増え、三人ともアオイの公開鍵で同じ署名値を確かめています。公開鍵は何人に配っても、署名の安全性は下がりません。公開鍵から秘密鍵を計算で求めることは、現実的な時間ではできないように作られているからです。
そして公開鍵を持つ人は、検証はできても新しい署名値を作ることはできません。確かめる力と作る力が、別々の鍵に分かれているわけです。MAC と並べると、違いがはっきりします。
| 作る鍵 | 検証する鍵 | 検証する人も作れるか | |
|---|---|---|---|
| MAC | 共通鍵 K | 共通鍵 K | 作れる |
| 電子署名 | 秘密鍵 | 公開鍵 | 作れない |
この違いは、第8章の JWT で出てくる方式名にもそのまま表れます。HS256 は共通鍵を使う MAC（HMAC）で、RS256 や ES256 は秘密鍵と公開鍵を使う署名です（RFC 7518）。検証する相手が多い場面や、相手に作る力を渡したくない場面では署名が選ばれます。
今度は書き換える人が、案内を「会議は11時」に変え、アオイの署名値はそのまま付けてボブへ送ったとします。図では文書の文字だけが変わり、紫の署名値は元のままです。
ボブが同じように検証すると、結果は「失敗」に変わります。署名値は「10時」と書かれたバイト列に対して作られたものなので、「11時」のバイト列とは組み合わないのです。書き換える人が署名値も作り直そうとしても、それにはアオイの秘密鍵が要ります。ハッシュだけのときは書き換える人が指紋を作り直せましたが、署名値は作り直せません。
変わったのが1文字でも、空白ひとつでも、結果は同じく失敗です。どこが変わったかまでは教えてくれませんが、「署名されたときのままではない」ことは確実に分かります。
署名について、「秘密鍵で暗号化し、公開鍵で復号するのが署名だ」という説明を見かけることがあります。教科書に載る素朴な RSA の計算が、暗号化と署名でたまたま似た形をしていることから広まった言い方です。
実際に使われる RSA の署名方式（RFC 8017 の RSA-PSS など）は、暗号化とは別の手順で値を整えてから計算します。楕円曲線を使う ECDSA や Ed25519（RFC 8032）では、そもそも署名値を「復号して元の文書に戻す」という操作がありません。検証の処理は、文書と署名値と公開鍵がつじつまの合う組かどうかを調べるだけです。
ですから署名は、図の下の紫のカードのように「秘密鍵の持ち主だけが作れて、公開鍵を持つ誰もが確かめられる値」と覚えておくのが安全です。暗号化は中身を隠すため、署名は作った人と無改ざんを確かめるためのもので、目的も手順も別物です。
署名値は、文書の「意味」ではなく「バイト列」に結び付きます。図の上の二つの JSON は、どちらも「10時に会議室A」を表していて意味は同じです。けれども項目の並び順が違うので、バイト列としては別物になり、署名値も別の値になります。空白や改行を一つ足しただけでも同じことが起きます。
そのため署名を使う形式では、「どのバイト列を署名の対象にするか」を前もって決めておく必要があります。決まりがないと、送る側が整形し直したり、受け取る側が読み込み直して並べ替えたりしただけで、正しい文書なのに検証が失敗してしまいます。
第8章で扱う JWT の署名（JWS、RFC 7515）では、ヘッダーと中身をそれぞれ Base64URL という文字列に直し、点でつないだものを署名の対象と決めています。受け取った側はその文字列をそのまま検証するので、JSON の空白や並び順で迷うことがありません。図の下の流れがそれです。
検証が成功したときに確かに言えるのは、図の左側のことです。この公開鍵と組になった秘密鍵で、このバイト列に対して署名が作られた。言い換えれば、その秘密鍵の持ち主が署名し、そのあと文書は変わっていない、ということです。
一方、図の右側のことは署名からは分かりません。案内の内容が事実かどうか、アオイに会議の時間を決める権限があるかどうかは、署名とは別の問題です。署名は文書を隠しもしないので、内容を秘密にしたければ第5章までに見た暗号化を組み合わせます。
そして見落としやすいのが、手元の公開鍵が本当にアオイのものかという点です。なりすます人が自分の公開鍵を「アオイの鍵です」と言って渡していたら、その人が作った署名も検証に成功してしまいます。これを確かめる仕組みが、次の章で扱う証明書です。また、アオイの秘密鍵が漏れれば誰でもアオイとして署名できてしまうので、秘密鍵は厳重に守る必要があります。
この章では、届いた案内が誰の手で作られ、途中で変わっていないかを確かめる電子署名を見てきました。ハッシュ値だけでは誰でも作り直せ、MAC では鍵を持つ二人のどちらが作ったかを示せませんでした。電子署名は、作る力を秘密鍵に、確かめる力を公開鍵に分けることでこれを解決します。秘密鍵はアオイの手元から出ず、公開鍵は何人に配っても構いません。
では、有効な署名が付いていれば、文書は秘密になるのでしょうか。答えはいいえです。図の盗み見る人のように、途中で文書を見た人には「会議は10時」がそのまま読めます。署名が守るのは「誰が作ったか」と「変わっていないか」で、中身を隠すのは暗号化の役目です。両方が必要なら、署名と暗号化を組み合わせて使います。
最後に、図の右下の問いが残りました。ボブの手元の公開鍵は、本当にアオイのものでしょうか。次の章では、公開鍵とその持ち主を結び付ける証明書と認証局を見ていきます。
