応用情報技術者 試験情報＆徹底解説

https://www.ap-siken.com/kakomon/24_aki/q36.html

答えのリバースプロキシを使ったシングルサインオンの場合，利用者認証においてパスワードの代わりにディジタル証明書を用いることができるとのことですが、これって仮にディジタル署名でも正解になるのでしょうか。もし不正解となるなら、なぜなのか理由を教えてほしいです。
私の認識としてはデジタル署名はかいざんの有無と本人確認ができるとおもっていたのですが。
それともデジタル署名の複号には公開鍵の情報が必要→公開鍵の情報はデジタル証明書にあるということで、
デジタル署名を複号する場合にデジタル証明書（公開鍵の情報）が必要だから、
答えが【最終的に必要となるデジタル証明書】になっているということでしょうか
ここらへんがあやふやなので詳しい方教えてください。

一般的に「認証要素」は3種類（知識情報・所持情報・生体情報）あります。
・知識情報：パスワード、パターンなど
・所持情報：デジタル証明書（公開鍵証明書）、セキュリティトークンなど
・生体情報：指紋、顔など

問は認証要素としてのパスワードの代替となるものを問うております。
そのため、認証要素として所持情報であるデジタル証明書（公開鍵証明書）が
解答となります。
デジタル署名は認証要素ではないので不正解になります。

その他用語の解説です。
デジタル証明書（公開鍵証明書）とは認証局によって署名された公開鍵です。

公開鍵を用いた「技術」は2種類あります。
・公開鍵暗号：データの暗号化・復号を行う
・デジタル署名：データの改ざん検知・本人確認を行う

まとめると、リバースプロキシでのシングルサインオンの場合は
・認証要素として、所持情報の「デジタル証明書（公開鍵証明書）」を
・クライアント証明書として用い
・デジタル署名技術を利用して本人確認を行う
となります。

暗号技術については「暗号技術入門 第3版 秘密の国のアリス」に
詳しい内容が載っています。

> デジタル署名はかいざんの有無と本人確認ができる

デジタル署名は、署名した人を確認できるだけで、
デジタル署名を所持している人を認証することはできないと思います。

なんらかのデジタルデータに署名するわけですが、
そもそも何に署名する前提なのでしょうか
いきなりデジタル署名が登場するので、そこからおかしいと思います。

>・認証要素として、所持情報の「デジタル証明書（公開鍵証明書）」を
>・クライアント証明書として用い
>・デジタル署名技術を利用して本人確認を行う

デジタル証明書が正しいか確認できるだけではないでしょうか
証明書に署名しているのは認証局ですよね。

ご指摘頂きありがとうございます。

>・デジタル署名技術を利用して本人確認を行う
純粋なデジタル署名技術は「改ざん検知」と「否認防止」でした
訂正いたします

本人確認は
・認証局によって署名されたデジタル証明書（公開鍵証明書）
・デジタル証明書（公開鍵証明書）情報を事前にクライアント証明書として
  サーバ側で情報の保持
・デジタル署名を利用してデジタル証明書（公開鍵証明書）と対になる
  秘密鍵の所持者を確認
のように複数の要素を用いることによって実現しています。

デジタル署名は認証中にデジタル証明書（公開鍵証明書）所有者を正規のユーザか
判断するために利用されます。
デジタル証明書（公開鍵証明書）自体は認証局によって署名されていますが、
公開鍵なので盗聴などで簡単に窃取されてしまいます。

そのため、TLSハンドシェイク中にCertificateVerifyが行われます。
ハンドシェイクのメッセージをユーザの秘密鍵でデジタル署名し、サーバ側で
ユーザのデジタル証明書（公開鍵証明書）で検証を行います。
これによりサーバ側でユーザがデジタル証明書（公開鍵証明書）と対になる秘密鍵を
所有していることが確認できます。

どうしても、公開鍵技術とそれを利用した機能は複雑で、説明が長くなって
しまいます。このあたりが学習者が混乱する原因と思われます。

いまだにやはりあやふやです。
勉強いたします。ありがとうございます。

「デジタル署名」だけでは、不正解になると思われます。
なぜならば、デジタル署名単体では本人確認ができないためです。
そもそも、デジタル署名で使用された秘密鍵・公開鍵がAさんのものである、ことを証明するために、認証局がデジタル証明書を発行しています。
つまり、デジタル証明書によってAさんのものであると保証されたデジタル署名、であれば、ユーザー認証の条件を満たしますが、
単なるデジタル署名だけでは、使用された秘密鍵・公開鍵がAさんのものかどうかわからないので、ユーザー認証の条件を満たしません。

追記です。
では、デジタル証明書によってユーザー認証をするとは何か、という話になりますね。
デジタル証明書には認証局の署名がついており、これを認証局の公開鍵を使って検証することで、本人確認をすることができます。
なので、わざわざデジタル証明書で補償されたデジタル署名を行わなくても、デジタル証明書を持っている=認証条件を満たしているので、ユーザー認証には十分ということです。

ただ、じゃあデジタル証明書が流出してた場合に、上記の方法だけだとなりすましされてしまいます。そのため、おそらくですが、デジタル証明書で補償されたデジタル署名によるユーザー認証をする方法も行われていると思います。(この場合ですと、デジタル証明書の他に秘密鍵も知らないと行けないので、セキュリティの強度が高まります。)
復号のコストをかけてもセキュリティを高めるか、デジタル証明書だけでコストを抑えるか、いろんな手法があるのではと思います。

失礼いたします。
説明を訂正させていただきます。
>なので、わざわざデジタル証明書で補償されたデジタル署名を行わなくても、
>デジタル証明書を持っている=認証条件を満たしているので、ユーザー認証には
>十分ということです。

この点は誤りです。
TLS認証シーケンスでは、クライアント認証時には
１．(Certificateメッセージ)
  ユーザはデジタル証明書をサーバに送信。 
  サーバはデジタル証明書に付与されているデジタル署名をCAの公開鍵で
  検証し、デジタル証明書が本物か確認します。
  この段階では「デジタル証明書は本物・所有者は未確認」です。

２．(CertificateVerifyメッセージ)
  ユーザは秘密鍵を利用してハンドシェイクメッセージのデジタル署名を生成。
  そのデジタル署名をサーバに送信。
  サーバはデジタル証明書内の公開鍵でデジタル署名を検証する。
  これにより、公開鍵と秘密鍵が正しい鍵ペアであることが確認され、これにより
  ユーザが正規のデジタル証明書の所有者であることが確認される。
という２段階の手順を踏みます。

理由はもちろん、１.だけでは悪意ある人物にデジタル証明書を窃取された場合、
なりすましが行われてしまうからです。

pixさん、訂正ありがとうございます。
現場畑の人間でない為、デジタル証明書における厳密な内部やりとりがわからず、TLS認証シーケンスをぼかした形で、「デジタル証明書によって証明されたデジタル署名」とぼかした言い方になってました。
TLS認証の場合は、サーバー側がデジタル証明書を持っており、クライアントの要請に応じてデジタル証明書を送信しておりましたが、
リバースプロキシによる利用者認証では、クライアント側にもデジタル証明書があり、双方のデジタル証明書の検証を行って、認証が行われるという理解であってますでしょうか？

デジタル証明書自体が秘匿性の高いものであれば、物理的な鍵の用に扱えるのではないかと思っていたのですが、現実はそう甘くないということですかね。

TLSの認証は２段階あります。
１．サーバ確認のために、サーバのデジタル証明書を
  クライアントに送信し、クライアント側で検証（必須）
２．クライアント確認のために、クライアントのデジタル証明書を
  サーバに送信し、サーバ側で検証（オプション）
です。

通常のWebアプリケーションでは１．のサーバ確認が行われております。
リバースプロキシなどによる利用者認証では２．も併せて行われます。

デジタル証明書自体は秘匿性は高くありません。あくまで公開鍵を
CAによって正規のものであると保証しているのみになります。

公開鍵は公開されることを前提として運用されるものです。対になる
秘密鍵が秘匿されることによって公開鍵と秘密鍵の鍵ペアの真正性が
保証されます。

常々感じますが、以下の知識はAPの上のSCの学習者でも知識が曖昧な
ケースが多々あります。
・公開鍵技術とその応用技術
  公開鍵暗号
  デジタル署名
・デジタル証明書（公開鍵証明書）とその利用形態
  サーバ証明書
  クライアント証明書
・TLSの処理フロー
APの段階では、基本的な概要を押さえておけば十分と思います。

pixさん、丁寧な回答ありがとうございます。

こちらでもいくつか調べてみたのですが、デジタル証明書はクライアントとなるPCやUSBに直接紐づいており、その本体が盗まれない限り、偽装が困難なのではないでしょうか？
軽く調べた程度ですが，デジタル証明書を添付するためには、デジタル証明書の実データがあるpc・USBが存在し、デジタル証明書発行用のアプリーケーションでしか、証明書を添付できないようになっておりました。
ここまでセキュリティを高めていれば、デジタル証明書を添付できること=信用できる筋からの通信であり、あくまでシングルサインオンで求められている「ユーザー認証」においては、デジタル証明書を確認するだけで正当性は確認できるのではないかと思うのですが、やはり、実際は不可としているところが多いのでしょうか？

もしよろしければご教授いただけますと幸いです。

この投稿は投稿者により削除されました。(2023.02.12 23:07)

多分になりますが、ここで言われているデジタル証明書とは
「デジタル証明書と秘密鍵のセット」を指しているのではないでしょうか？

まずは公開鍵技術の背景にある以下の原則が基本になります
・公開鍵は他人に知られても問題ない
  ネットワーク上に流れて、盗聴・窃取されても問題は発生しない
  むしろ暗号化に利用される公開鍵は積極的に公開されてもよい
・秘密鍵は決して他人に知られてはいけない
  秘密鍵を格納した媒体から外部に流出しては絶対にいけない
です。この原則は非常に重要となります。

Windowsの仕様になりますが、一旦PCにインポートされたクライアント
証明書用の秘密鍵はOSによって保護され、外部に取り出せなくなります。
これによりPCと秘密鍵が強固に結びつきます。さらに秘密鍵とデジタル証明書は
デジタル署名を利用することによって鍵ペアであることを保証できます。
「その本体が盗まれない限り、偽装が困難なのではないでしょうか？」という
技術的裏付けは以上のようになっております。

逆を言えば秘密鍵がインポートされたPCが窃取された場合は、利用者認証も
窃取されたことになります。

解説などではデジタル証明書とありますが、正確には「デジタル証明書と
秘密鍵のセット」を暗黙的に指している場合があります。
解説を読むときはデジタル証明書という言葉が「デジタル証明書自体」か
「デジタル証明書と秘密鍵のセット」かを意識して読み解かないと
正しく理解するのは難しいと思います。

pixさん、何度も丁寧に回答いただきありがとうございます。
どうしてもリバースプロキシサーバ上で行われているデジタル証明書によるユーザー認証の流れが、明確に想像しづらいですね。
秘密鍵で暗号化したデータとデジタル証明書を提示する
→証明書を検証し、Aさんのものであるとお墨付きを得た公開鍵をゲットする
→ゲットした公開鍵で送られてきたデータを複合する(この時点で、本人認証ができたことになる)
ということなのでしょうか。つまりデジタル証明書単体ではなく、デジタル証明書を利用した一連の流れでユーザー認証を行う。
私が気になったのは、この場合、ユーザー認証のためにわざわざダミーのデータを作って本人確認なんてするのだろうか？と思ったところです。
たとえTLSの通信を行う際に同時に上記のユーザー認証を行なっている、とすればID/パスワードの代わりにデジタル証明書を利用する、と言う記述では雑な感じがしています。
実際は実務をやらないとわからないんでしょうね。
長文失礼、何度も回答ありがとうございました！

最後に補足いたします。
>私が気になったのは、この場合、ユーザー認証のためにわざわざダミーのデータを
>作って本人確認なんてするのだろうか？と思ったところです。

ダミーのデータではないです。ここでやり取りするフローも情報も厳密に
定義されています。
TLSフローのCertificateVerify(クライアント証明書の検証）メッセージで
・暗号化通信に使用する共有鍵暗号の暗号化鍵の元となるマスタシークレット
・このフローで送信しているメッセージ自体
のハッシュ値に対してデジタル署名を生成し、サーバ側へ送信するという
決まりになっています。

つまり、ユーザ認証とは「CAによって本物と確認されたデジタル証明書と対になる
秘密鍵の所有者であることを証明する」手順に他ならないです。

TLSのフローについては「暗号技術入門 第3版 秘密の国のアリス」に
詳しい内容が載っています。