電子署名による認証(身分証明)

はじめに

暗号技術のなかでも、公開鍵暗号(広義)に分類されるものとして、電子署名があります。
これは、PKI ( 認証局、SSL/TLS証明書、…etc. ) という文脈で説明されているのは見かけるのですが、何者であるかを証明する「認証」という役割での説明は、なかなか見ないように思います。
ということで今回、認証に絞って説明ができないかどうか、試みとして書いてみようと思います。

なお、前提知識として電子署名の基礎知識に目を通しておくことをお勧めします。

電子署名による認証へのアプローチ

認証とは?

電子署名を認証(身分証明)に使うというのがこの記事のテーマなわけですが、そもそも認証というのは何でしょうか。

日常生活においては、例えば自身の身分証明書なり、予め取り決めたパスワード・暗証番号なりを提示して本人であることを立証することが該当するかと思います。
つまりは本人しか持ち得ない/知り得ないモノ・情報を提示することを以て本人の証とするわけです。そのため、相手 ( もしくは判定に使う機械等 ) は、何らかその正当性を判断する手段を持っているか、あるいは本人しか知り得ない情報を予め共有していることが前提になります。

加えて、提示した情報が悪用されないことも重要です。例えば身分証の場合、原本をすぐ返還してさえもらえれば、よしんばコピーを取られていたとしてもそこから偽造はされないだろうという信頼の元に使用するものですし、パスワード等の場合も、相手(機械)と自分以外には漏れない運用になっているからこそ成り立つ方式です。

しかし、今ここで考えているのはデジタルデータがネットワークを通じて遣り取りされる世界での認証の話です。一旦送り出したデータは、どこで幾らコピーが取られても不思議がありませんし、原本とコピーを区別する術もありません。パスワード情報を共有しておく方式はもちろんあり得ますが、運用できる範囲が極端に狭まります。なので、電子署名を使う上では、この辺の問題を解消しておきたい所です。

電子署名を活用するには

では、電子署名を活用するとなった場合ですが、検証鍵(公開鍵)が公開され、署名鍵(秘密鍵)は署名者以外には秘匿されているという点を考慮する必要があります。
そこでまず、前提としては次の通りになります。

• ある検証鍵(公開鍵)が確かに当人の所有する署名鍵(秘密鍵)と対になっていると正しく認知されている状況で、
• 本人が対になっている署名鍵(秘密鍵)を、確かに所有していることを示す。

前者の「正しく認知されている」というのは重要な前提です。もし、正しく認知されていない ( 例えば攻撃者によって歪めて伝えられている ) としたら、認証の結果自体、信用できないものになってしまうからです。
この点を解決するために例えばPKI等の仕組みがあったりするわけですが、この記事では深くは触れません。いずれにせよゼロから信頼を作り出すことはできなくて、認証とは別の枠組みで、信頼の起点となるものを築いておく必要があります。
逆にこの前提をクリアしていれば、検証鍵(公開鍵)というのは一般に公開しているわけですから、パスワードを事前共有するような、適用範囲の狭さの問題は解消できます。

今度は後者の「所有していることを示す」、こちらについては考慮が必要になります。なぜなら、所有していることを示すために署名鍵(秘密鍵)そのものを提示したとしたら、本来当人のみが所有するという電子署名自体の前提を裏切ることになってしまうからです。
実際問題として、当人のみが所有するからこそ署名が本人のものだと信頼できるわけで、提示することでもし第三者の手に署名鍵(秘密鍵)が渡ってしまったら、どのように悪用されるか分からず、ひいては署名自体の信頼が保てなくなります。

そのため、そのデータ自体を提示せず所有していることを示すために、署名鍵(秘密鍵)を提示するのではなく何らかの署名を提示するというアプローチをとります。署名鍵(秘密鍵)を持つ当人だけが正当な署名を作れるという電子署名の性質から、正当な署名を作れたのだから ( そのことが公開されている検証鍵(公開鍵)で検証できたから )、正しく署名鍵(秘密鍵)を所有していると判断できる、という理屈です。

このアプローチの問題点

しかし、単純に署名を作って送れば ( そして検証して貰えば ) 終わり、とは行きません。幾つか重大な問題点をクリアする必要があるのです。

署名対象のデータ

その1つは、何のデータに対して署名を作成するかです。

例えば、適当に「自分は○○です」というようなデータを用意して署名すれば十分でしょうか?

確かに、当人はそれで認証されるかもしれませんが、その署名は途中の経路で第三者に盗聴される可能性があります。というより、なにも機器を中継せずに相手に直結したネットワークというのは非現実的ですから、幾らでもコピーを作られると見た方が良いです。そうすると、デジタルデータの特性上原本とコピーを区別することはできませんから、盗聴者も同じように認証を通ってしまいます。
何より、署名を手渡した相手に悪意があれば、更に別の相手への認証に流用される危険性もあります。

このことから分かるのは、署名者が任意に署名対象データを選ぶ方式はダメということです。

ではじゃあ、検証者に署名対象のデータを用意して貰えば良いでしょうか? いわゆるチャレンジ-レスポンスってやつです。相手に好きなデータを送ってもらって、何であれ署名してあげると。
…世間一般ではそれ、めくら判って言いますよね。認証してもらいたいがためとは言え、相手の好きに署名を渡してしまう、論外です。

ということで、検証者が任意に署名対象データを選ぶ方式もダメです。

それなら、署名者・検証者で用意したデータを混ぜれば ( 例えば繋ぎ合わせれば ) どうでしょうか? 片一方のみの欠点は解消しているのではないでしょうか。

※署名を送る際、署名対象の「つなげたデータ」まで送る必要はないのですが、絵面を合わせるために一緒に送るイメージで描いています。

しかしこの方式であっても、通信に介入する攻撃者がいるとなりすましを防げません。一種の中間者攻撃が成立してしまいます。

署名者が意図した相手へ認証して貰うがために作った署名、それを別人に対するなりすましに流用されてしまうのです。

困りました。署名対象データは、どちらか一方が用意しても、お互いに用意して混ぜ合わせてもダメということです。
※もちろん、これは単純化した話だから、であってこの後対策が出てくるわけですが。ただ、時刻情報だとか何らかの識別子を混ぜる位だと、脅威を軽減できるにしても、根本的な解決にはなりません。

認証が通った後の話

また、そもそもの話があります。

たとえ、何とかちゃんとした認証方式を確立できたとしても、その後の通信を乗っ取られるようだと意味がありません。

つまり、認証だけでなく、その後の通信の保護もセットで考える必要があるということです。

ちなみに、認証後の通信も全て署名して改ざんを防げば…という考えはアリなのですが、そもそも電子署名自体が大量に署名作成するには向いていないこと ( 公開鍵暗号方式共通の特性 )、電子メール等まとまったデータに署名するのと違って、細切れになっている通信データを保護すること ( データの並び替え等への対策 ) を考慮せざるを得ず、実現へのハードルがかなり高くなることから、ここでは考えないことにします。

署名方式以外に必要なこと

前項では主な問題点を2点挙げました。これらを解決する必要があります。

署名対象データの問題は、たとえ両者のデータを混合したとしても、中間者によってデータが悪用される可能性が排除できないことに起因しています。

また、認証後の通信の保護、これには電子署名が適さないとすると、同じ改ざん検知の機能を持ち、かつ大量の処理に向いたMAC ( HMAC-SHA256等の鍵付きハッシュ、Poly1305等 ) を使うことが考えられます。こちらは電子署名と異なり、MACの作成のためには予め秘密裡に鍵を共有する方式です。

ということで、必要なものをまとめます。

• 中間者や検証者に流用/悪用されない、署名対象データの作成方式
• 認証成立後の通信を保護するMACに必要な鍵を秘密裡に共有する方式

なお、後者が実現するのであれば、共通鍵暗号( AESやChaCha20等 ) 用の鍵も秘密裡に共有できることを意味しますから、同時に通信の秘匿も行うことができます。
※或いは、両方の性質を兼ね備えたAES-GCM等の方式を使うことも考えられます。

鍵交換との併用

ということで、どのように解決するか。ここで鍵交換という方法が出てきます。

鍵交換というのは、次の図のようにそれぞれ公開情報・秘密情報のペアを作って公開情報のみ交換し、互い違いに公開情報・秘密情報を組み合わせることで、共通の秘密情報を作り出す方式です。

もし盗聴されたとしても、公開情報同士の組み合わせからは、共通の秘密情報が作り出せません。
いや、互い違いなのに同じ情報が作れるとか、そんな都合の良い話があるのか? と思われるかも知れませんが、これであれば、

• 両者がデータ作成に関わっていることで流用が効かない、かつ公開情報だけでは悪用できない
• 秘密裡に共有するデータを作り出せる

ということで、一挙に問題が解決できるというわけです。

鍵交換とは

電子署名によって認証を実現するという話でしたが、実は電子署名単独では無理で、鍵交換も併用するという話になりました。そこで今度は鍵交換に絞ってみていきます。

鍵交換の実現方法

鍵交換のイメージを再掲します。

特徴としては次の通りです。

• 両者で公開情報・秘密情報のペアを生成すること
• 公開情報を交換すること
• 互い違いの公開情報・秘密情報の組み合わせから同一のデータが生成されること
• 対になる秘密情報を公開情報から推定すること、生成されるデータを公開情報のみで推測することが共に困難であること

これを実現するための方法を、主に2通り紹介します。

べき乗の数的構造の利用

実は、「互い違いなのに同一の結果が得られる」これは皆さん、中学や高校の数学で習っているはずです。
それは、べき乗における指数法則です。次のように、a乗とb乗、順序を入れ替えても同じ結果が得られるというものです。

({x^a})^b=({x^b})^a=x^{a\times b}

具体例としては次のようになります。べき乗の結果を公開情報、指数を秘密情報とすれば、互い違いで同じデータを生成できているのです。

2^3=2\times 2\times 2=8,~ ~8^4=8\times 8\times 8\times 8=4096=2^{12} \\
2^4=2\times 2\times 2\times 2=16,~ ~16^3=16\times 16\times 16=4096=2^{12} \\
\therefore (2^3)^4=(2^4)^3=2^{3\times 4}=2^{12} \\
(a,A)=(3,8),~(b,B)=(4,16)\Rightarrow A^b=B^a

いやいや、そうは言っても 8→3 や 16→4 というのは、指数の逆である対数関数(log)の計算をすればすぐに分かるから、「対になる秘密情報を公開情報から推定すること」が困難になってないじゃないか、と。確かにこの例ではそうなのですが、ではその「指数の逆」の計算が困難で、かつ同じような数的構造を持ったモノがあればどうでしょうか。

という発想で編み出されたのが、DHの鍵交換という方式です。特定の有限群での演算を使ったべき乗の逆、離散対数が困難であることを利用した方式です。
オリジナルのDHは巨大整数におけるmoduloの世界での乗算を元にしたべき乗を使いますが、それを楕円曲線上で定義できる有限群と加算を元にしたべき乗(スカラ倍算)に替えたECDHという方式もあります。

(狭義)公開鍵暗号の利用

もう一つ、(狭義)公開鍵暗号を利用した方法を紹介します。
なお、「狭義」とつけているのは、単に公開鍵暗号と言った場合、公開情報・秘密情報をペアで使用する電子署名、DHの鍵交換等を含んだ暗号方式全般と誤解される可能性を懸念してです。
ここで言う公開鍵暗号は、情報を秘匿する目的で、データの暗号化に公開鍵、復号に秘密鍵を用いる方式を指します。有名どころとしてはRSA暗号があります。

次の図に示すように、両者で用意するデータが非対称になりますが、公開情報A,Bの交換により秘密情報sを共有することができます。

なお、図中の攪乱というのは、ハッシュを計算すると捉えて頂ければ良いかと思います。
秘密情報の共有のみが目的であれば、この攪乱操作は必ずしも要るわけではありませんが、電子署名による認証のため署名対象データとして利用するのであれば、「検証者に流用されない」という観点から必要と言えます。

一時的な鍵と固定鍵

電子署名にせよ鍵交換にせよ、検証鍵/公開情報と署名鍵/秘密情報と、非対称な鍵ペアを用意するという点では共通ですが、鍵の取り扱いには実は違いが見られます。
それは、作成した鍵のペアを長期的に使い回す(固定鍵)か、使い捨てにする(一時的)か、です。

電子署名の場合、誰が署名したかという情報が重要ですから、身元情報と紐づいている鍵をころころ作り直すわけには行きません。つまり、電子署名では固定鍵しか考えられません。一般生活で携帯電話番号やメールアドレスをそうそう変更できないのと同じ理屈です。

一方で鍵交換の場合、目的は秘密情報の共有ですから、別段鍵が固定であることに拘る理由はありません。つまり、一時的な鍵と固定鍵どちらかを選択する余地があります。
※DH,ECDHに関しては、一時的な鍵を用いる場合に DHE,ECDHE (Eは“Ephemeral”を意味する)として区別することがあります。

しかし、一時的な鍵と固定鍵ではやはり違いが出てきます。そこで以下では、それぞれでどのような影響があるかを見ていきます。

一時的な鍵に対する中間者攻撃

まずは一時的な鍵を使う場合です。
この時は中間者攻撃のことを考えねばなりません。

次の図のように、お互いが公開情報を交換するところに介入し、公開情報を攻撃者のものに差し替えるという手法です。

公開情報が差し替えられたとは言え、鍵交換そのものは成立します。しかし、当事者間でのみ共有するはずの秘密情報が攻撃者にバレていますから、通信データを保護(暗号化およびMAC付与)したつもりでも盗聴・改ざんは防げません。
面白いのは、鍵交換でできたs1,s2が別々のデータであるにも関わらず、攻撃者が仲介して保護し直すことで、当事者にはあたかも保護されたまま通信が成り立っているかのように認識されることです。

この中間者攻撃が成立するには、両者の公開情報を差し替えること、それから鍵交換でできたs1,s2の違いに気付かせないことです。そのため、以下の対策が考えられます。

1.どちらか一方が固定鍵を使い、その固定鍵の公開情報の内容を、予め正しく認知して貰う
2.共有する秘密情報(を含んだデータ)の署名を一方から送り、もう一方に検証して貰う
3.公開情報を送る段階で、一方が公開情報(を含んだデータ)の署名を添付し、もう一方に検証して貰う

1.はそもそも固定鍵ですから公開情報を差し替える余地がありません。攻撃成功には両方の公開情報を差し替える必要がありますから、一方を阻止するだけで十分となります。ただ、片方が差し替えられた場合、攻撃者が把握できるのは片方だけであるとは言えs1,s2のずれは発生しますから、後でずれの有無を確認する必要はあります。なお、一時的な鍵の場合、もちろんこの手法は使えません。

2.は、中間者攻撃の際にs1,s2と共有する秘密情報にずれができることに着目した対策です。攻撃者は署名鍵を持ちませんから、対象データのずれに合わせて署名を作り替えることができません。そのため、署名検証によって攻撃を検出することができます。
しかもこれは、認証のための署名の送付・検証と兼ねることができます。つまり、鍵交換は認証のための署名データ作成として、署名は鍵交換への中間者攻撃対策として、お互いを補う形になるのです。

3.は、1.と別方向で公開情報の差し替えを防ぐ方法です。こちらも、攻撃者は署名鍵を持ちませんから、公開鍵を差し替えたとしても、署名を合わせて作り替えることができません。なお、s1,s2のずれの有無を確認する必要があるのは1.と同様です。
そしてこの3.も、2.と同様に認証のための署名の送付・検証と兼ねることができます。公開情報(を含むデータ)の署名を第三者が入手したしても、対になる秘密情報までは手に入らず、鍵交換を成立させるには至らないからです。つまり、流用される懸念を解消していると言えます。

固定鍵による認証の実現

続いて固定鍵を使う場合です。

ここで一時的な鍵の説明の中で、「固定鍵の公開情報の内容を、予め正しく認知して貰う」というのが中間者攻撃への対策として挙げてあったかと思います。

しかしこの対策、実は電子署名で認証を行う際の前提そのものです。違いは検証鍵か鍵交換の公開情報かというところだけ。そして、認知して貰うことで、公開情報とその所有者が紐付けられますから、これも十分認証として使えます。鍵交換が成立した時点で、同時に認証も成立していると見做せます。

つまり、電子署名の認証の前提を満たせるなら固定鍵による鍵交換でも認証になるということです。

前方秘匿性(Forward Secrecy)

前項の固定鍵の話からすると、わざわざ一時的な鍵を使って電子署名で認証と中間者攻撃対策をしなくても、固定鍵による鍵交換で認証も兼ねてしまえばいいんじゃないか? となりかねないのですが、ちゃんと一時的な鍵には存在意義があります。

それは、固定鍵の流出があった場合のリスクの問題です。
ここで言っている鍵とは、鍵交換における公開情報と対になる秘密情報、或いは一時的な鍵を使っている場合は電子署名の方の固定鍵、つまり署名鍵を指します。本来、所有者以外に漏れることがあってはならないものですが、もし流出したとしたらどのような影響があるでしょうか。

まず、流出した鍵を入手した者は認証をパスできるようになりますから、堂々となりすましが行えます。その被害拡大を防ぐため、折角認知して貰っている情報に対して、今度は失効情報を認知して貰わなければなりません。ただこれは固定鍵による鍵交換でも、一時的な鍵+電子署名でも、どちらでも同様です。

それ以外に影響はないでしょうか? ここで、鍵交換の場合、片側の秘密情報さえあれば、逆の公開情報と組み合わせて、2者でのみ共有していた秘密情報を復元できてしまうことに注意が必要です。
つまり、過去の通信データを保存しておけば、当時は保護が破れなかった暗号データが、復元された秘密情報で解読されてしまうのです。

これは情報の秘匿も行いたいという立場からは、とてつもなく大きなリスクになります。その時に通信を保護できていたとしても、固定鍵を持ち続ける限りいつでも覆される危険性がつきまとうからです。
一方で、この問題は署名鍵の流出の場合は無関係です。鍵交換の際に使われた鍵は一時鍵として使い捨てにされており、共有していた秘密情報はもはや復元されないからです。

つまり一時的な鍵を用いる方式には、過去に遡って保護を破られないという大きなメリットがあるということです。これを**前方秘匿性 ( Forward Secrecy 或いは Perfect Forward Secrecy )**と呼びます。

ということを考えると、結局は、鍵交換では固定鍵ではなく一時的な鍵を用いるべきだ、ということになるでしょう。

固定鍵と一時的な鍵を併用する鍵交換

さて実は、上では固定鍵・一時的な鍵、一方しか使わない前提で話をしてきましたが、両者を併用する鍵交換の方式であれば、電子署名を併用しなくても前方秘匿性を確保しつつ認証も実現できるのではないでしょうか?

という観点で提唱された認証付き鍵交換として、MQV(ECMQV)という方式があるのですが、ただこの方法には弱点があるということで、更にHMQVという方式が提案されています。
尤も、このHMQVにもまだ弱点があるらしく、今の所この延長上に実用になっている方式があるのかは調査できていません。

実プロトコルでの認証実装

以上で、電子署名を利用した認証方式を説明してきました。どちらかというと鍵交換の方が主役のような気もしますが気にしないことにします。以下では、実際の暗号プロトコル上でどのように認証が行われているか紹介したいと思います。

SSL/TLS

かつてはSSL今ではTLSは、Webのhttps等で使われる、最もメジャーな暗号方式と言えるでしょう。鍵交換、認証、共通鍵暗号、MACを組み合わせたハイブリッド暗号です。

TLS1.2でのサーバ認証

SSL/TLSでの認証は、Kerberosのような認証方式を用いる方法や、そもそも認証を行わない方法もありますが、一般にはサーバ認証を指します。つまり、クライアントから見て、接続しているサーバが、その証明書に含まれる公開鍵/検証鍵と対になる秘密鍵/署名鍵の正当な所有者かどうかを判定するわけです。

2018年2月現在流通しているTLS1.2において、以下の方式があります。

• RSA鍵交換
  広く使われてきたメジャーな方式であり、公開鍵暗号であるRSA暗号を鍵交換兼認証として、固定鍵で用いる方式です。
• static-DH/ECDH
  プロトコル上は存在するものの、おそらく超マイナーであり、ほぼ実用されていない方式です。その名前の通りDH/ECDH鍵交換を固定鍵で用います。static-DHに関しては、以前static-DHによるSSL/TLSで説明しています。
• DHE/ECDHE+電子署名
  一時的な鍵による、DHまたはECDH鍵交換に、電子署名(RSA/DSA/ECDSA/EdDSA)を組み合わせた方式です。

前方秘匿性の観点からは、前2つの方式は好ましくはないのですが、(最近知って驚いたのは)白書:TLSにおけるForward Secrecyの利用に関する実証的研究調査によると、2014年時点ですら、RSA鍵交換が相当広く使われていたということです。

現在では流石に最後の方式が主流だと思われますが…。興味深いのは、SSL/TLSに用いるサーバ証明書として広く用いられるRSAアルゴリズムは、RSA鍵交換、DHE/ECDHE+RSA署名の両方に使えるため、サーバ・クライアント双方で無意識の内にRSA鍵交換を選びかねないところです。

とあるWebサイトにhttpsでアクセスしたところ、ブラウザのデフォルト設定ではRSA鍵交換になるところ、無効化するとECDHE+RSA署名になるのが観測されました。これは、折角後者が使える状態にあったのに、サーバの暗号方式の優先順位の設定が不適切になっていることで、わざわざRSA鍵交換が選ばれてしまった例と言えるでしょう。

なお、DHE/ECDHEを用いる場合、ハンドシェイク(セッション開始時の遣り取り)にServerKeyExchangeというサーバからのメッセージが追加され、そこで鍵交換用の公開情報が、署名付きでクライアントに送られます。
固定鍵による鍵交換も含め、共有される秘密情報にずれがないかどうかは、最後のFinishedの段階でチェックされます。

TLS1.2でのクライアント認証

SSL/TLSの場合、サーバから要求を出し、クライアントが保持する証明書を提示しクライアントの認証を行うことがあります。

プロトコル上は、電子署名を使う方式と、固定鍵の鍵交換を使う方式があるようです。

電子署名を使う場合、ハンドシェイクの中では、ClientKeyExchangeを送って鍵交換が完了している段階で、鍵交換で生成された秘密情報を元に署名を作成しClientVerifyとしてサーバに送ります。
それに先立ちサーバに送られているClientCertificateに含まれる検証鍵によって、サーバ側が検証を行うということになります。

固定鍵の鍵交換を使う方式は…。実際に使われる例があるんでしょうか? ちょっとこの部分は調査できていません。

TLS1.3では

2018年2月現在、次のバージョンであるTLS1.3が策定中です。
そちらについては私自身良く分かってないのですが、ただ、前方秘匿性の観点から、固定鍵による鍵交換方式は廃止となるそうです。

SSH(SSHv2)

Linux/UNIXサーバに遠隔接続する手段として標準的に用いられる方式であり、SSL/TLSと同じく、鍵交換、認証、共通鍵暗号、MACによるハイブリッド暗号です。SSHv1ではRSA暗号を前提とした設計になっていましたが、こちらはもはや廃れており、SSHv2では一時的な鍵による鍵交換と電子署名(RSA/DSA/ECDSA/EdDSA)による認証が軸となっています。

ホスト認証

SSHでは、各サーバがホスト鍵という電子署名の鍵ペアを保持し、クライアントは接続時に、そのサーバが正当な鍵の所有者かどうかをチェックします。これをホスト認証と呼んでいます。

ホスト認証に意味を持たせるには、予めクライアント側でホスト鍵の内、検証鍵/公開鍵を認知しておく必要があります。「known_hostsファイルに鍵を登録」と言うのがそれです。( あるいはSSL/TLSと同じようにサーバ側で証明書を使うことでも代替できます )

…使う側の利便性のためか、予めホスト鍵を認知していなくても認証をパスしたり、或いはホスト鍵の情報に差異があっても接続を拒否しない設定も可能となっていますが、セキュリティの面からは、中間者攻撃を受けるリスクを背負っていることを意識した方が良いと思います。

ホスト認証はDHE/ECDHE ( あるいは最近だとCurve25519も使用可 ) による鍵交換と共に行われます。つまり、サーバから鍵交換用の公開情報を送付する時に、一緒にホスト鍵(公開鍵)と署名も提示します。

公開鍵認証

今度は公開鍵認証について、です。これは接続してくるユーザを認証するための手段の1つであり、やはり電子署名を使います。

こちらは、予めサーバ側に、ユーザ情報と紐づける形で検証鍵/公開鍵を登録しておき、接続時にクライアントから署名を送る形を取ります。署名対象データとしては、既に成立している鍵交換によって作成された秘密情報を元にしたものです。

ホストベース認証

もう1つの電子署名を使った認証として、ホストベース認証というのもあります。
こちらも接続してくるユーザを認証するための手段の1つですが、公開鍵認証と違い、個々のユーザ毎に認証情報を管理するのではなく、接続元のホスト単位で管理するという豪快な方式です。
どういうことかというと、予め信頼するホスト群をサーバ側で登録しておいて、そのホスト群から接続してきたユーザは、その自己申告の通りのユーザとして受け入れてしまうということです。

このような性質であることから、登録したホストに悪意があればサーバ側は広範に被害を受けることになりますし、そもそも両者で同一のユーザ体系がないと成り立ちません。
そのため、同一システム内に所属するマルチユーザ利用が前提のサーバクラスタの内部で、各ユーザが同一の権限で各サーバを使えるように、認証を簡略化するという使い方が主となります。

このホストベース認証の際には、ホスト認証の時と同じように、クライアントホスト上のホスト鍵が使われます。実際、メジャーな実装であるOpenSSHの場合は、SSHサーバとしてホスト認証に使う鍵が、そのままホストベース認証に流用されます。
なお、ホスト認証の時と違い既に鍵交換が済んでいる状態ですから、署名対象データは公開鍵認証の時のように、鍵交換によって作成された秘密情報を元にしたものになります。

さてホスト鍵を使うということですが、一介の利用者がホスト鍵の署名鍵/秘密鍵の方に無制限にアクセスできてしまっては困る(ホストのなりすましに悪用されうる)という点と、サーバ接続時に申告するユーザ情報を騙られてしまっては困るという点から、認証の核となる部分(ユーザ情報チェックと署名操作)を代行する特権プログラムの仲介が必要になります。OpenSSHの場合、ssh-keysignというツールがこれに該当します。

終わりに

まとめ

• 電子署名による認証
  • 署名できる能力を示すことで、署名鍵(秘密鍵)の所有者であることを示す
  • しかし電子署名単独では問題がある
  • 鍵交換を組み合わせることでその問題をクリアする
• 鍵交換について
  • べき乗の持つ性質(指数法則)と同一の構造を活かした鍵交換(DH,ECDH等)がある
  • DH, ECDH は離散対数問題の困難性によって安全性を確保している
  • RSA暗号のような公開鍵暗号(狭義)を利用して鍵交換を行う方式も作ることができる
  • 鍵交換の場合、一時的な鍵か固定鍵か選択の余地がある
    • 一時的な鍵の場合、鍵交換単独では中間者攻撃を防げない
    • 固定鍵の場合、鍵交換単独で認証も行えるが、前方秘匿性を確保できない
    • そのため一時的な鍵を用いて鍵交換を行い、電子署名で中間者攻撃を防ぐのが第一選択となる