電子署名 ― 文書と署名鍵の結び付きを確かめる

文書・ハッシュ・秘密鍵・署名・公開鍵を追って、改ざん検知とMACの違いを理解します。

文書を隠すより、改ざんを見つけたい

「会議は10時」という案内が届きました。本当にアオイさんの署名鍵で作られたか、途中で「11時」に書き換わっていないかを確かめたいとします。

ここで扱うのは暗号技術による電子署名（デジタル署名）です。手書きサインの画像を貼ることとは違います。文書を隠すことが主な目的でもありません。NIST FIPS 186-5

図の署名マークは説明のための記号です。本物の署名値は、署名アルゴリズムが生成するデータです。

署名方式では、文書からハッシュを計算するなどの処理を使って、内容に結び付いた署名を作ります。ハッシュは文書の特徴を短い値で表す道具です。

ただし、ハッシュを添えるだけでは署名になりません。文書を書き換えた人は、書き換え後のハッシュも計算できるためです。

図では文書から短い指紋を取り出します。実際の処理のどこでハッシュを取るかは署名方式によって違います。APIへ渡す前に自己流で二重にハッシュ化しないでください。

アオイさんは、自分の秘密鍵を使って文書に対応する署名値を作ります。秘密鍵は署名者の手元に残ります。

受信者へ渡すのは文書と署名値です。「秘密鍵で暗号化したので、公開鍵で文書を復号する」と説明すると、RSA-PSSやECDSAなどの署名方式の動きを誤解させます。RSAの署名方式

署名は「秘密鍵を持つ側だけが作れる検証用データ」と捉えると、暗号化と混同しにくくなります。

ボブさんは、受信した文書・署名・アオイさんの公開鍵を検証処理へ渡します。結果は成功または失敗です。図ではこの三つが検証の箱へ集まります。

成功は、その公開鍵に対応する署名と文書が整合していることを示します。公開鍵が本当にアオイさんのものかという確認は、証明書や信頼できる鍵の配布経路が支えます。

署名が有効でも、文書の記述が事実であることや、署名者にその操作の権限があることまで保証されるわけではありません。

攻撃者が案内を「会議は11時」へ変え、元の署名をそのまま付けて送ったとします。受信者は変更された文書で検証するため、元の署名とは整合しません。

図では文書だけが変化し、署名カードは同じまま残ります。この関係が、改ざん検知のポイントです。

署名は文書のバイト列に結び付きます。JSONの空白や並びを変えてもよいのかなど、何を署名対象にするかは形式ごとの規約が必要です。JWSでは、ヘッダーとペイロードを所定の形式で結び付けます。JWS署名入力

方式	作る鍵	検証する鍵	検証者も同じ証拠を作れる？
MAC	共通鍵K	共通鍵K	同じ鍵があれば作れる
電子署名	秘密鍵	公開鍵	公開鍵だけでは作れない

この違いは、JWTのHS256とRS256・ES256などを理解するときにも役立ちます。共通鍵を渡す相手は検証だけでなく生成もできる、と考える必要があります。JWSの鍵に関する考慮事項

図では署名用の秘密鍵は一人に残り、検証用の公開鍵だけが複数の読者へ広がります。

答えはいいえです。電子署名だけでは内容を隠しません。秘匿も必要なら、適切な暗号化と組み合わせます。

また、署名の信頼性は秘密鍵の管理と、公開鍵の持ち主の確認に支えられます。秘密鍵が漏れれば、攻撃者も署名を作れるようになります。

署名を見るときは、「どのバイト列に対する署名か」「どの公開鍵で検証したか」「その鍵をなぜ信頼できるか」をたどりましょう。ここで扱うのは技術的な検証で、法的効力の判断ではありません。