HOME»情報処理安全確保支援士掲示板»令和3年秋 午後2 問2 設問6
投稿する
基本的なことを記述するため、長文となり失礼します。
公開鍵技術についての認識が曖昧のようです。
公開鍵技術では公開鍵・秘密鍵の鍵ペアを作成し、
・公開鍵:他人に見られても問題ない
・秘密鍵:絶対に秘密にする
という基本ルールのもとに利用・運用されます。
公開鍵技術は以下の2つに利用されます。
・公開鍵暗号(データ暗号化に利用される)
データを公開鍵で暗号化、秘密鍵で復号
・ディジタル署名(主に認証などに利用される)
署名対象を秘密鍵で暗号化、公開鍵で復号できたら署名は本物
この2つを明確に区別することが重要です。
あと、暗号化通信とディジタル署名の使い分けも曖昧のようです。
サーバとの通信はHTTPSで行われますが、この時利用されるのは
使い捨ての共通鍵を利用した共通鍵暗号(AESなど)です。鍵交換には
DH鍵交換アルゴリズムなどが利用されます。
公開鍵暗号は利用しません。
クライアント証明書は、クライアント認証時のディジタル署名の
署名(秘密鍵)・検証(公開鍵)のみに使われます。
サーバ証明書も同様の原理になります。
一般的に
・暗号化通信:共通鍵(鍵交換)
・ユーザー認証:秘密鍵・公開鍵
といった複数の技術を利用した暗号技術をハイブリッド暗号と呼びます。
リアルタイムの通信にはハイブリッド暗号が利用されます。
よく疑問であがるのが、なぜリアルタイム通信で公開鍵暗号を利用しないか
という質問です。
理由ですが、公開鍵暗号は複雑なアルゴリズムを利用するため、共通鍵暗号に
比べて処理が数倍から数百倍以上重いです。
それ故に、リアルタイム通信ではとても間に合いません。
リアルタイム通信では処理の軽い共通鍵暗号を使い捨ての鍵を利用する
ことによって処理の重さを軽減し、機密性を保持しています。
公開鍵暗号は1つのファイルを暗号化してメールで送付して、あとで復号
するような、リアルタイム性が必要なく、あとで復号する用途に適しています。
まとめると
・共通鍵暗号 (動的な)通信を暗号化する
・公開鍵暗号 (静的な)データを暗号化する
という認識でよいかと思います。
クライアント認証が完了するのは、サーバ側でクライアント証明書の検証ではなく、
クライアントからのディジタル署名の検証が終了した段階です。
この後は、DH(ECDH)鍵交換によって暗号化通信に利用する使い捨ての共通鍵が
共有され、共通鍵暗号(AESなど)で暗号化通信が開始されます。
令和3年秋 午後2 問2 設問6 [0827]
こつばんまさん(No.1)
また質問させてください。
クライアント認証についてです。
設問6(1)の問題で、個人用の端末からの接続を防ぐために、クライアント認証のセキュリティ設定が従業員によって無効にされないために行う設定は何かという問があります。
解答としては
秘密鍵を持ち出せないようにすること、とありますが、クライアントの認証をするための公開鍵(ディジタル証明書)については考慮する必要はないのでしょうか?
私の理解では、クライアント端末に、保存されていた公開鍵をサーバに送付し、サーバ側で公開鍵(デジタル証明書)の検証を行い、クライアントの正当性を確認する。
実際の通信において通信内容をクライアント側の秘密鍵で暗号化してサーバ側へ送信する。
という流れだと思っています。
公開鍵が利用者個人用の端末にインストールされた場合、要件2を満たさなくなるのではと考えましたが、どこか考え方が誤っている部分がありますでしょうか?
ご回答よろしくお願いいたします
クライアント認証についてです。
設問6(1)の問題で、個人用の端末からの接続を防ぐために、クライアント認証のセキュリティ設定が従業員によって無効にされないために行う設定は何かという問があります。
解答としては
秘密鍵を持ち出せないようにすること、とありますが、クライアントの認証をするための公開鍵(ディジタル証明書)については考慮する必要はないのでしょうか?
私の理解では、クライアント端末に、保存されていた公開鍵をサーバに送付し、サーバ側で公開鍵(デジタル証明書)の検証を行い、クライアントの正当性を確認する。
実際の通信において通信内容をクライアント側の秘密鍵で暗号化してサーバ側へ送信する。
という流れだと思っています。
公開鍵が利用者個人用の端末にインストールされた場合、要件2を満たさなくなるのではと考えましたが、どこか考え方が誤っている部分がありますでしょうか?
ご回答よろしくお願いいたします
2022.03.21 00:15
pixさん(No.2)
★SC ダイヤモンドマイスター
Windows OSの機能で証明書のエクスポート時に秘密鍵を一緒に
エクスポートさせないという設定が標準であります。
本問はこの機能を知っているか否かだと思われます。
証明書は外部に持ち出されても特に問題ないので、エクスポートを
制限する機能はないです。
秘密鍵については本問の要件どおり、持ち出されては困る場合、
インポート時にエクスポートさせないように設定します。
エクスポートさせないという設定が標準であります。
本問はこの機能を知っているか否かだと思われます。
証明書は外部に持ち出されても特に問題ないので、エクスポートを
制限する機能はないです。
秘密鍵については本問の要件どおり、持ち出されては困る場合、
インポート時にエクスポートさせないように設定します。
2022.03.21 01:42
こつばんさん(No.3)
pixさん
ご回答ありがとうございます
そういった昨日があるんですね、調べてみます
制限する機能はないです。
こちらについてもう少し詳しくお聞きしたいです
証明書を外部に持ち出されて問題ないというのはなぜでしょうか?
公開鍵(の検証)だけでは暗号化した通信を開始できない?等あるのでしょうか?
また、それはサーバ証明書の場合も同様でしょうか?
お手数ですが、ご教授ください
よろしくお願いいたします
ご回答ありがとうございます
そういった昨日があるんですね、調べてみます
>証明書は外部に持ち出されても特に問題ないので、エクスポートを
制限する機能はないです。
こちらについてもう少し詳しくお聞きしたいです
証明書を外部に持ち出されて問題ないというのはなぜでしょうか?
公開鍵(の検証)だけでは暗号化した通信を開始できない?等あるのでしょうか?
また、それはサーバ証明書の場合も同様でしょうか?
お手数ですが、ご教授ください
よろしくお願いいたします
2022.03.21 08:50
pixさん(No.4)
★SC ダイヤモンドマイスター
>証明書を外部に持ち出されて問題ないというのはなぜでしょうか?
>公開鍵(の検証)だけでは暗号化した通信を開始できない?等あるのでしょうか?
>また、それはサーバ証明書の場合も同様でしょうか?
基本的なことを記述するため、長文となり失礼します。
公開鍵技術についての認識が曖昧のようです。
公開鍵技術では公開鍵・秘密鍵の鍵ペアを作成し、
・公開鍵:他人に見られても問題ない
・秘密鍵:絶対に秘密にする
という基本ルールのもとに利用・運用されます。
公開鍵技術は以下の2つに利用されます。
・公開鍵暗号(データ暗号化に利用される)
データを公開鍵で暗号化、秘密鍵で復号
・ディジタル署名(主に認証などに利用される)
署名対象を秘密鍵で暗号化、公開鍵で復号できたら署名は本物
この2つを明確に区別することが重要です。
あと、暗号化通信とディジタル署名の使い分けも曖昧のようです。
サーバとの通信はHTTPSで行われますが、この時利用されるのは
使い捨ての共通鍵を利用した共通鍵暗号(AESなど)です。鍵交換には
DH鍵交換アルゴリズムなどが利用されます。
公開鍵暗号は利用しません。
クライアント証明書は、クライアント認証時のディジタル署名の
署名(秘密鍵)・検証(公開鍵)のみに使われます。
サーバ証明書も同様の原理になります。
一般的に
・暗号化通信:共通鍵(鍵交換)
・ユーザー認証:秘密鍵・公開鍵
といった複数の技術を利用した暗号技術をハイブリッド暗号と呼びます。
リアルタイムの通信にはハイブリッド暗号が利用されます。
よく疑問であがるのが、なぜリアルタイム通信で公開鍵暗号を利用しないか
という質問です。
理由ですが、公開鍵暗号は複雑なアルゴリズムを利用するため、共通鍵暗号に
比べて処理が数倍から数百倍以上重いです。
それ故に、リアルタイム通信ではとても間に合いません。
リアルタイム通信では処理の軽い共通鍵暗号を使い捨ての鍵を利用する
ことによって処理の重さを軽減し、機密性を保持しています。
公開鍵暗号は1つのファイルを暗号化してメールで送付して、あとで復号
するような、リアルタイム性が必要なく、あとで復号する用途に適しています。
まとめると
・共通鍵暗号 (動的な)通信を暗号化する
・公開鍵暗号 (静的な)データを暗号化する
という認識でよいかと思います。
2022.03.21 09:31
こつばんさん(No.5)
pixさん
詳細な回答ありがとうございます。
ご指摘の通り、
で、このあたり毎回混乱してしまいます。
その理由として
ができていませんでした。
今回の問題においては、
るため、暗号化通信には公開鍵暗号を使用しないということで理解できました。
(その理由についても詳細に解説いただき、ありがとうございます。)
上記と回答いただいた内容を踏まえ、証明書(公開鍵)を持ち出されても問題ないという点について、以下の通り考えました。
クライアント証明書のうち
・秘密鍵を他の端末にコピーできた場合は、ディジタル署名が生成できるので、サーバ側の公開鍵をクライアント側で認証が可能。
・公開鍵をほかの端末にコピーしても、ディジタル署名の生成はできず、サーバ側の公開鍵の検証ができない。(このあたりの細かい表現がうまくできていないのが理解が曖昧な部分ではありますが、、)
独学で学習しているところもあり知識不足も多分にあるため、理解が誤っているところがあればご指摘いただければと思います。
よろしくお願いいたします
詳細な回答ありがとうございます。
ご指摘の通り、
>公開鍵技術についての認識が曖昧
で、このあたり毎回混乱してしまいます。
その理由として
>この2つ(公開鍵暗号とディジタル署名)を明確に区別すること
ができていませんでした。
今回の問題においては、
>クライアント証明書は、クライアント認証時のディジタル署名の署名(秘密鍵)・検証(公開鍵)のみに使われ
るため、暗号化通信には公開鍵暗号を使用しないということで理解できました。
(その理由についても詳細に解説いただき、ありがとうございます。)
上記と回答いただいた内容を踏まえ、証明書(公開鍵)を持ち出されても問題ないという点について、以下の通り考えました。
クライアント証明書のうち
・秘密鍵を他の端末にコピーできた場合は、ディジタル署名が生成できるので、サーバ側の公開鍵をクライアント側で認証が可能。
・公開鍵をほかの端末にコピーしても、ディジタル署名の生成はできず、サーバ側の公開鍵の検証ができない。(このあたりの細かい表現がうまくできていないのが理解が曖昧な部分ではありますが、、)
独学で学習しているところもあり知識不足も多分にあるため、理解が誤っているところがあればご指摘いただければと思います。
よろしくお願いいたします
2022.03.21 11:24
pixさん(No.6)
★SC ダイヤモンドマイスター
度々の長文失礼いたします。
公開鍵技術は4つの鍵の区別が非常に重要です。
登場人物:A,B
鍵:Aの秘密鍵、Aの公開鍵、Bの秘密鍵、Bの公開鍵
この4つの鍵の組み合わせで公開鍵暗号、ディジタル署名を実現します。
公開鍵暗号:AがBに暗号化したデータを送信するケース
※利用する鍵はBの公開鍵・秘密鍵です。Aの鍵は利用しません。
1.AがBの公開鍵でデータを暗号化する
2.BはBの秘密鍵でデータを復号化する
ディジタル署名:AがBに署名を送信するケース
※利用する鍵はAの秘密鍵・公開鍵です。Bの鍵は利用しません。
1.AがAの秘密鍵で署名を作成する
2.BはAの公開鍵で署名を検証する
ここまでの鍵の組み合わせは公開鍵技術の理解で必須になります。
この組み合わせをすぐに思い浮かべられるようにならないといけません。
この知識をもとに、認証技術にはさらに証明書(CAによってディジタル
署名された公開鍵)の技術がプラスされます。
つまり、サーバ&クライアント認証技術には
・公開鍵技術
・証明書技術
(プラス TLS)
の両方の理解が必要になります。
サーバ側の公開鍵をクライアント側で認証というのが不明です。
いろいろ曖昧になっているようです。
秘密鍵をコピーされた場合、秘密鍵をインストールしたPC以外でも
ディジタル署名が生成されてしまいます。
微妙にクライアント認証を正しくとらえてない気がします。
クライアント認証は正規のクライアント機器(PC)かどうかを認証します。
不正な機器(PC)を判別するためですので、秘密鍵が不正な機器(PC)に
インストールされてしまったら、不正な機器(PC)でディタル署名が
生成されてしまうので、当初の目的から外れてしまいます。
クライアントの秘密鍵で生成したディジタル署名を検証できるのは
クライアントの公開鍵(証明書)のみです。
サーバの公開鍵(証明書)は関係ないです。
同上です。
クライアント認証に必要なのは
・クライアントの秘密鍵
・クライアントの公開鍵(証明書)
のみで、サーバ側の公開鍵は関係ありません。
TLSで接続した際のサーバ認証・クライアント認証のフローを簡単にまとめます
・サーバ認証
1.サーバ -> クライアント:サーバ証明書(公開鍵)が渡される
2.クライアントはサーバ証明書(公開鍵)が本物かどうか
証明書チェーンの検証(正規のルートCAから発行されたものか)を
確認する。
※この時点では証明書が本物であることのみ確認できます。
サーバが本物かは次の段階になります。
3.サーバ -> クライアント:サーバはサーバの秘密鍵でディジタル署名を
生成し、クライアントに渡す。
4.クライアントはサーバ証明書(公開鍵)でディジタル署名を検証する。
この段階まできて、サーバが本物である確認が終わります。
通常のTLSセッションならばサーバ認証が終わった段階で認証は完了です。
クライアント認証はこの後、クライアントが本物かどうか検査するために
オプションとして発生します。
・クライアント認証
クライアント認証はサーバ認証のフローのサーバとクライアントの
役割を入れ替えて同様の事を行います。
公開鍵技術は4つの鍵の区別が非常に重要です。
登場人物:A,B
鍵:Aの秘密鍵、Aの公開鍵、Bの秘密鍵、Bの公開鍵
この4つの鍵の組み合わせで公開鍵暗号、ディジタル署名を実現します。
公開鍵暗号:AがBに暗号化したデータを送信するケース
※利用する鍵はBの公開鍵・秘密鍵です。Aの鍵は利用しません。
1.AがBの公開鍵でデータを暗号化する
2.BはBの秘密鍵でデータを復号化する
ディジタル署名:AがBに署名を送信するケース
※利用する鍵はAの秘密鍵・公開鍵です。Bの鍵は利用しません。
1.AがAの秘密鍵で署名を作成する
2.BはAの公開鍵で署名を検証する
ここまでの鍵の組み合わせは公開鍵技術の理解で必須になります。
この組み合わせをすぐに思い浮かべられるようにならないといけません。
この知識をもとに、認証技術にはさらに証明書(CAによってディジタル
署名された公開鍵)の技術がプラスされます。
つまり、サーバ&クライアント認証技術には
・公開鍵技術
・証明書技術
(プラス TLS)
の両方の理解が必要になります。
>上記と回答いただいた内容を踏まえ、証明書(公開鍵)を持ち出されても
>問題ないという点について、以下の通り考えました。
>クライアント証明書のうち
>・秘密鍵を他の端末にコピーできた場合は、ディジタル署名が
>生成できるので、サーバ側の公開鍵をクライアント側で認証が可能。
サーバ側の公開鍵をクライアント側で認証というのが不明です。
いろいろ曖昧になっているようです。
秘密鍵をコピーされた場合、秘密鍵をインストールしたPC以外でも
ディジタル署名が生成されてしまいます。
微妙にクライアント認証を正しくとらえてない気がします。
クライアント認証は正規のクライアント機器(PC)かどうかを認証します。
不正な機器(PC)を判別するためですので、秘密鍵が不正な機器(PC)に
インストールされてしまったら、不正な機器(PC)でディタル署名が
生成されてしまうので、当初の目的から外れてしまいます。
クライアントの秘密鍵で生成したディジタル署名を検証できるのは
クライアントの公開鍵(証明書)のみです。
サーバの公開鍵(証明書)は関係ないです。
>・公開鍵をほかの端末にコピーしても、ディジタル署名の生成はできず、
>サーバ側の公開鍵の検証ができない。(このあたりの細かい表現が
>うまくできていないのが理解が曖昧な部分ではありますが、、)
同上です。
クライアント認証に必要なのは
・クライアントの秘密鍵
・クライアントの公開鍵(証明書)
のみで、サーバ側の公開鍵は関係ありません。
TLSで接続した際のサーバ認証・クライアント認証のフローを簡単にまとめます
・サーバ認証
1.サーバ -> クライアント:サーバ証明書(公開鍵)が渡される
2.クライアントはサーバ証明書(公開鍵)が本物かどうか
証明書チェーンの検証(正規のルートCAから発行されたものか)を
確認する。
※この時点では証明書が本物であることのみ確認できます。
サーバが本物かは次の段階になります。
3.サーバ -> クライアント:サーバはサーバの秘密鍵でディジタル署名を
生成し、クライアントに渡す。
4.クライアントはサーバ証明書(公開鍵)でディジタル署名を検証する。
この段階まできて、サーバが本物である確認が終わります。
通常のTLSセッションならばサーバ認証が終わった段階で認証は完了です。
クライアント認証はこの後、クライアントが本物かどうか検査するために
オプションとして発生します。
・クライアント認証
クライアント認証はサーバ認証のフローのサーバとクライアントの
役割を入れ替えて同様の事を行います。
2022.03.21 18:48
こつばんさん(No.7)
pixさん
度々丁寧なご回答ありがとうございます。
また、具体的なフローについても記載頂き、ありがとうございます。イメージわきました。
公開鍵暗号(通信の暗号化)
とディジタル署名(認証)
の各に使われる鍵の理解と、表現のしかたが誤っていたことがわかりました。
こちらについて、私が『サーバ側の公開鍵』と記載していた部分が誤りで、(冗長な書き方になりますが)
『クライアント端末の秘密鍵が、他の端末にコピーされた場合、
・コピーした秘密鍵を用いて他のクライアント端末で生成したディジタル署名をサーバに送る
・事前にサーバ側にわたされたクライアント証明書(公開鍵)を用いてディジタル署名の検証を行うことが可能
であるため、クライアント検証が成功する』
が正しい表現であると理解しました。
クライアント証明書(公開鍵)をコピーしても上記処理を実施できないため問題ないということで最初の疑問も解決したと思います。
※ちなみにクライアント認証が完了するのは、サーバ側でクライアント証明書の検証が成功した段階となりますでしょうか?
度々丁寧なご回答ありがとうございます。
また、具体的なフローについても記載頂き、ありがとうございます。イメージわきました。
公開鍵暗号(通信の暗号化)
とディジタル署名(認証)
の各に使われる鍵の理解と、表現のしかたが誤っていたことがわかりました。
>秘密鍵をコピーされた場合、秘密鍵をインストールしたPC以外でもディジタル署名が生成されてしまいます。クライアント認証は正規のクライアント機器(PC)かどうかを認証します。
>クライアントの秘密鍵で生成したディジタル署名を検証できるのはクライアントの公開鍵(証明書)のみで、サーバの公開鍵(証明書)は関係ない
こちらについて、私が『サーバ側の公開鍵』と記載していた部分が誤りで、(冗長な書き方になりますが)
『クライアント端末の秘密鍵が、他の端末にコピーされた場合、
・コピーした秘密鍵を用いて他のクライアント端末で生成したディジタル署名をサーバに送る
・事前にサーバ側にわたされたクライアント証明書(公開鍵)を用いてディジタル署名の検証を行うことが可能
であるため、クライアント検証が成功する』
が正しい表現であると理解しました。
クライアント証明書(公開鍵)をコピーしても上記処理を実施できないため問題ないということで最初の疑問も解決したと思います。
※ちなみにクライアント認証が完了するのは、サーバ側でクライアント証明書の検証が成功した段階となりますでしょうか?
2022.03.21 22:13
pixさん(No.8)
★SC ダイヤモンドマイスター
>※ちなみにクライアント認証が完了するのは、サーバ側でクライアント証明書の
>検証が成功した段階となりますでしょうか?
クライアント認証が完了するのは、サーバ側でクライアント証明書の検証ではなく、
クライアントからのディジタル署名の検証が終了した段階です。
この後は、DH(ECDH)鍵交換によって暗号化通信に利用する使い捨ての共通鍵が
共有され、共通鍵暗号(AESなど)で暗号化通信が開始されます。
2022.03.21 22:36
こつばんさん(No.9)
そうですね、失礼しました
クライアント認証が完了するのは、サーバ側で、クライアント証明書を用いて(クライアント側で生成された)ディジタル署名の検証が完了した時点 ですね
pixさん
初歩的な部分から丁寧にご説明いただき、たいへん助かりました。自分なりに納得することができました。
ご回答本当にありがとうございました。
クライアント認証が完了するのは、サーバ側で、クライアント証明書を用いて(クライアント側で生成された)ディジタル署名の検証が完了した時点 ですね
pixさん
初歩的な部分から丁寧にご説明いただき、たいへん助かりました。自分なりに納得することができました。
ご回答本当にありがとうございました。
2022.03.22 11:57