サーバが、1:1もしくは、特定小数間での通信で、互いに相手サーバを信用できるという条件がつきますが・・・
改ざん防止と成りすまし防止だけなら、双方で共有する秘密鍵を用いてハッシュ値を得て、
(または、本文のハッシュ値を秘密鍵を用いて暗号化して)
本文(平文)とともにハッシュ値(暗号化したハッシュ値)を送るだけで実現できるかと。
受けて側も、同じ秘密鍵を用いてハッシュ値を算出し、送られてきたハッシュ値と一致するなら、
改ざんも成りすましもされていないということになります。
要は、秘密鍵は通信相手しか持っていないことということが確実に保障されれば、公開鍵暗号を使う必要はありません。
秘密鍵をどうやって安全に送るのかという問題は残りますが、
大抵、郵便など物理的に(通信経路を通さずに)送ってしまうことが多いですかね。
但し、暗号化していないので、本文はダダ漏れだし、ハッシュアルゴリズムに適切な長さの秘密鍵とハッシュ値
を使わないと破られますけどね。
ご参考になれば
1. 署名以外の方法で改竄防止と成り済まし防止
実際のプロトコルでは無く、どのような暗号プリミティブがその機能を達成出来るのかという質問だと思ったので、そちらで答えます。
秘密鍵だけを使うものとしてMAC(メッセージ認証コード)があります。サーバ間で安全に秘密鍵が共有されている場合には、こちらの方が高速なので良くつかわれます。
等を参照ください。CRYPTRECの資料の1.3.1-1.3.2節はよくまとまった資料だと思います。
また、Signcryptionという暗号化と署名を同時に行う手法もあるので、これもまた署名以外と言えます。
2. 署名の構成方法
より正確に言うならば、
ハッシュ値を秘密鍵で暗号化したものが署名、公開鍵で署名を復号しハッシュ値と一致するかどうか検証
ということだと思います。教科書的RSA署名はこのタイプです。
もうひとつ有名なのが教科書的Rabin署名です。ハッシュ値を秘密鍵で復号したものが署名、公開鍵で署名を暗号化し、ハッシュ値と一致するかどうか検証という方式です。実は教科書的RSA署名も同じことをしています。実際には、元データに色々な情報を付加してからハッシュ値を計算することがよく行われます。RSA-PSSはその代表例と言えます。
他に知られている構成方法として、対話型認証方式を非対話に変形することによって署名を構成するというものがあります。
が参考になるかも知れません。
他にも色々と構成法はあるのですが、説明しやすいのはこの辺りまでです。他の署名方式では、安全性を適切な仮定の下で証明するために、より説明しづらい構成法を取っています。
コメント(0件)