ขนาดวิดีโอ: 1280 X 720853 X 480640 X 360
แสดงแผงควบคุมโปรแกรมเล่น
เล่นอัตโนมัติ
เล่นใหม่
ディジタル証明書！今日やったことだ！分かりやすくて毎回助かってます！
もろこし23 さんお久しぶりのコメントですね。ありがとうございます(^^)タイムリーな技術で参考になっているようなのでうれしいです。今後も動画更新していきますので引き続きよろしくお願いいたします☆彡
いつも拝見しております。以下にてよければ回答頂けないでしょうか。エの利用者が暗号化に使用する、という選択肢は何が間違っているのでしょうか？通信の際に利用者側の送信データを暗号化するにはサーバの公開鍵が必要となると思ったのですが。。よろしくお願いします。
(初学者なので間違ってるかもしれませんが)サーバの公開鍵で暗号化するのは(※1)共通鍵で、秘匿データを暗号化する際に使うのは(※1の)共通鍵だから、でしょうか？
ディジタル証明書の正当性を確かめるのは認証局の鍵ですが、実際に通信に利用する鍵は"通信相手のサーバーの共通鍵"で、認証局の公開鍵は使わないから不正解なのだと思います。ディジタル証明書の中には、通信相手(今回でいうとサーバー)の公開鍵も含まれており、クライアントはサーバーの公開鍵を基に共通鍵を暗号化して送付します。受け取ったサーバーは自身の秘密鍵で共通鍵を複合し、以降共通鍵でクライアントとサーバーは暗号化通信を行います。
今回問われているのは認証局の公開鍵を利用して行うことです。A社のWebサーバで利用しているデジタル証明書は、Webサーバの公開鍵に関して認証局の秘密鍵で署名を受けることで作成されています。認証局の公開鍵では対となる認証局の秘密鍵で暗号化された情報を復号可能ですし認証局の秘密鍵で暗号化された情報を対となる公認証局の開鍵で復号可能です。この例では認証局が認証局の秘密鍵で暗号化(署名)したA社の公開鍵に関するデータをクライアントが検証するために、認証局の公開鍵を使って署名を復号し復号したデータとデジタル証明書からクライアント自身が計算するデータを比較し一致すれば検証成功、正当な認証局で発行された正当なデジタル証明書であると確認できます。上記の流れであるため不正解とはなりますが仮にエであった場合どう不都合があるかといえば、認証局の公開鍵で暗号化された秘匿データは対となる認証局の秘密鍵でしか復号できません(A社Webサーバは認証局の秘密鍵は入手できません)実際通信したいのはA社のWebサーバであり、これではA社のWebサーバは秘匿データを受け取れません。また仮にデジタル証明書の検証を行わずにWebサーバに対し秘匿データを送信する場合などは偽サーバに対して通信を行ってしまった場合にそのまま送信してしまうことになります。そのため問題のように認証局の公開鍵を使って、デジタル証明書を検証し正規のwebサーバの公開鍵であることを確認した上で、webサーバの公開鍵を利用して鍵交換を行います。また仕組みの問題として、デジタル証明書を受けとった段階ではまだTLSハンドシェイクの最中であり、実際にwebサーバと通信するセッション鍵は生成されておらずHTTPのアプリケーションデータは送信されていません。鍵交換が終わりChange Cipher Specメッセージを交換してからHTTPの通信が始まります。
xxs308giwさんコメントありがとうございます。皆様も返信にてコメントありがとうございます。私はこの問題は”ディジタル証明書を検証してる”事を理解しているか？を問う問題だと思っています。問題文にあるようにサーバのディジタル証明書を入手した後にはそのディジタル証明書の正当性を検証する必要があります。暗号通信の話は”検証の後”です。まずはディジタル証明書の検証を行い正当性を確認できたら暗号通信のための動きに移ります。参考になりそうなWEBサイトがあったので共有させていただきます。www.sc-siken.com/kakomon/23_aki/am2_3.html参考になりますと幸いです😊
皆様コメント有難う御座います。実際に暗号化するのがどの段階か、を理解できていませんでした。丁寧にご教示頂きまして有難う御座いました！
本動画の説明では、ハッシュの一方向性が保たれていないように思いますがいかがでしょうか？以下理由となります。6:56上記にて、署名前証明書をハッシュアルゴリズムを利用してハッシュ化するその後秘密鍵で暗号化(署名)してから送付。ユーザは受信した署名を認証局の公開鍵で復号。8:24 ここが問題ですが、上記にて、署名前証明書を同じようにハッシュアルゴリズムを利用してハッシュ化するとおっしゃられています。しかし、6:56の時点署名前証明書は既にハッシュ化されているため、ユーザは署名前証明書を見ることもできなければ、ハッシュアルゴリズムを知る由もないはずです。それがここでわかっているということは、何らかの方法でハッシュ化を解読したことになり、一方向性に反しているかと思います。
抹茶クッキーさんいつもコメントありがとうございます。8:24 の部分について動画でうまく説明できておらず申し訳ございません。＞署名前証明書は既にハッシュ化されているため、デジタル署名をつけるために署名前証明書をハッシュ化するだけでユーザがデジタル証明書を入手した時は、署名前証明書はハッシュ化されておりません。ぜひ一度、実際のサーバ証明書をご覧いただくとイメージが湧くと思いますfaq.sakura.ad.jp/s/article/000001099参考になれば幸いです。
6:08 個人的ブックマーク まさるさんありがとうー
きんくまさんこちらこそ、コメントありがとうございます！試験も近づいてきましたね😊きんくまさんが良い結果を得られることを願っております
まさるさん素晴らしい動画です！わかりやすすぎてとて参考になりました。ありがとうございます。
¿¿¿¿ ¿¿¿¿¿¿さんコメントありがとうございます。動画がお役にたてて嬉しいです☺️全然コメントとは関係ありませんがお名前が？の反対向きというなので疑問じゃない状態、つまり理解した状態という事なのかなぁ…と勝手に思いふけりました（笑）素敵なお名前ですね♪
むずい
T Y さんコメントありがとうございます。難しいですよね…ディジタル証明書は様々な要素が絡んでくるので何かと理解が難しくなりがちです。もし何が分からないのか分かったら再度コメント頂けましたら参考になりそうなサイトなどを紹介させていただきます！
令和4年春期試験午前Ⅱ 問15では"デジタル証明書"になっているんですよね
ほんとだー！！田中電気さん貴重な情報ありがとうございます個人的にはこのまま脱”ディジタル”して、”デジタル”にして欲しいです(^^)
3Dセキュアはネットショッピングで使ったことがあるので、問題には答えられましたが、背景がわかって大変ためになりました。
Josui Kurodaさんコメントありがとうございます。動画がお役にたててうれしいです(^^)
デジタルに統一して欲しいですね（ディジタルは書くのが面倒）
Marcos Kasahara さんコメントありがとうございます。同感です。私も”デジタル”に統一して欲しいと思っています(*_*)
8:06署名前証明書のハッシュ値が一致しないケースはあるのでしょうか。「認証局の秘密鍵で暗号化されたものは認証局の公開鍵でのみ複合できる」という観点から考えると、データの改竄の心配はないような気がしています。仮に通信の途中で攻撃者が介入し、公開鍵で復号化・改竄したとしても、攻撃者は秘密鍵を持っていないため、再度暗号化できないためです。書いているうちに思いつきましたが、暗号化されたままのデータが別の値に書き換えられてしまったケースを想定したチェックでしょうか。それが可能なのかは分かりませんが、シリアル番号などを任意の値に書き換えることはできなくても、通信を妨害するには十分なので。
5:48信頼性のある認証局にサーバ証明書を作ってもらわないと意味ないとのことですが、他方で、証明書自体の種類にも信頼性のレベルがあるかと思います。その上で、信頼性のない認証局に信頼性の強いEV証明書を作ってもらっても、それは信頼性の「ない」証明書になるのでしょうか？
抹茶クッキーさんいつもコメントありがとうございます！＞信頼性のない認証局に信頼性の強いEV証明書を作ってもらっても、＞それは信頼性の「ない」証明書になるのでしょうか？はい、信頼性のない証明書として扱われます。現実社会ですが、自称鑑定士の鑑定書のついた高級時計を買うかどうかで考えるとイメージしやすいかもしれません。鑑定書はついてるけど、自称鑑定士なのでその鑑定書は信頼しませんよね？いくらEV証明書でも、発行した認証局が信頼できなければその証明書は信頼できません。実際にはブラウザで”信頼できない証明書”という警告が出る事になると思います。
![#24 [Quick study for support staff measures] How PKI works](http://i.ytimg.com/vi/KOp90QN2QZY/mqdefault.jpg)
ディジタル証明書！今日やったことだ！分かりやすくて毎回助かってます！
もろこし23 さん
お久しぶりのコメントですね。
ありがとうございます(^^)
タイムリーな技術で
参考になっているようなのでうれしいです。
今後も動画更新していきますので
引き続きよろしくお願いいたします☆彡
いつも拝見しております。
以下にてよければ回答頂けないでしょうか。
エの利用者が暗号化に使用する、という選択肢は何が間違っているのでしょうか？
通信の際に利用者側の送信データを暗号化するにはサーバの公開鍵が必要となると思ったのですが。。
よろしくお願いします。
(初学者なので間違ってるかもしれませんが)
サーバの公開鍵で暗号化するのは(※1)共通鍵で、
秘匿データを暗号化する際に使うのは(※1の)共通鍵だから、でしょうか？
ディジタル証明書の正当性を確かめるのは認証局の鍵ですが、実際に通信に利用する鍵は"通信相手のサーバーの共通鍵"で、認証局の公開鍵は使わないから不正解なのだと思います。
ディジタル証明書の中には、通信相手(今回でいうとサーバー)の公開鍵も含まれており、クライアントはサーバーの公開鍵を基に共通鍵を暗号化して送付します。受け取ったサーバーは自身の秘密鍵で共通鍵を複合し、以降共通鍵でクライアントとサーバーは暗号化通信を行います。
今回問われているのは認証局の公開鍵を利用して行うことです。
A社のWebサーバで利用しているデジタル証明書は、Webサーバの公開鍵に関して
認証局の秘密鍵で署名を受けることで作成されています。
認証局の公開鍵では対となる認証局の秘密鍵で暗号化された情報を復号可能ですし
認証局の秘密鍵で暗号化された情報を対となる公認証局の開鍵で復号可能です。
この例では認証局が認証局の秘密鍵で暗号化(署名)したA社の公開鍵に関するデータを
クライアントが検証するために、認証局の公開鍵を使って署名を復号し
復号したデータとデジタル証明書からクライアント自身が計算するデータを比較し
一致すれば検証成功、正当な認証局で発行された正当なデジタル証明書であると確認できます。
上記の流れであるため不正解とはなりますが仮にエであった場合
どう不都合があるかといえば、認証局の公開鍵で暗号化された秘匿データは
対となる認証局の秘密鍵でしか復号できません(A社Webサーバは認証局の秘密鍵は入手できません)
実際通信したいのはA社のWebサーバであり、これではA社のWebサーバは秘匿データを受け取れません。
また仮にデジタル証明書の検証を行わずにWebサーバに対し秘匿データを送信する場合などは
偽サーバに対して通信を行ってしまった場合にそのまま送信してしまうことになります。
そのため問題のように認証局の公開鍵を使って、デジタル証明書を検証し
正規のwebサーバの公開鍵であることを確認した上で、webサーバの公開鍵を利用して鍵交換を行います。
また仕組みの問題として、デジタル証明書を受けとった段階では
まだTLSハンドシェイクの最中であり、実際にwebサーバと通信するセッション鍵は生成されておらず
HTTPのアプリケーションデータは送信されていません。
鍵交換が終わりChange Cipher Specメッセージを交換してからHTTPの通信が始まります。
xxs308giwさん
コメントありがとうございます。
皆様も返信にてコメントありがとうございます。
私はこの問題は
”ディジタル証明書を検証してる”
事を理解しているか？
を問う問題だと思っています。
問題文にあるように
サーバのディジタル証明書を入手した後には
そのディジタル証明書の正当性を検証する必要があります。
暗号通信の話は”検証の後”です。
まずはディジタル証明書の検証を行い
正当性を確認できたら
暗号通信のための動きに移ります。
参考になりそうな
WEBサイトがあったので共有させていただきます。
www.sc-siken.com/kakomon/23_aki/am2_3.html
参考になりますと幸いです😊
皆様コメント有難う御座います。
実際に暗号化するのがどの段階か、を理解できていませんでした。
丁寧にご教示頂きまして有難う御座いました！
本動画の説明では、
ハッシュの一方向性が保たれていないように思いますがいかがでしょうか？
以下理由となります。
6:56
上記にて、署名前証明書をハッシュアルゴリズムを利用してハッシュ化する
その後秘密鍵で暗号化(署名)してから送付。
ユーザは受信した署名を認証局の公開鍵で復号。
8:24
ここが問題ですが、
上記にて、署名前証明書を同じようにハッシュアルゴリズムを利用してハッシュ化するとおっしゃられています。
しかし、6:56の時点署名前証明書は既にハッシュ化されているため、
ユーザは署名前証明書を見ることもできなければ、ハッシュアルゴリズムを知る由もないはずです。
それがここでわかっているということは、何らかの方法でハッシュ化を解読したことになり、
一方向性に反しているかと思います。
抹茶クッキーさん
いつもコメントありがとうございます。
8:24 の部分について
動画でうまく説明できておらず申し訳ございません。
＞署名前証明書は既にハッシュ化されているため、
デジタル署名をつけるために
署名前証明書をハッシュ化するだけで
ユーザがデジタル証明書を入手した時は、
署名前証明書はハッシュ化されておりません。
ぜひ一度、実際のサーバ証明書をご覧いただくとイメージが湧くと思います
faq.sakura.ad.jp/s/article/000001099
参考になれば幸いです。
6:08 個人的ブックマーク まさるさんありがとうー
きんくまさん
こちらこそ、コメントありがとうございます！
試験も近づいてきましたね😊
きんくまさんが良い結果を得られることを
願っております
まさるさん素晴らしい動画です！
わかりやすすぎてとて参考になりました。ありがとうございます。
¿¿¿¿ ¿¿¿¿¿¿さん
コメントありがとうございます。
動画がお役にたてて嬉しいです☺️
全然コメントとは関係ありませんが
お名前が？の反対向きというなので
疑問じゃない状態、つまり理解した状態という事なのかなぁ…と
勝手に思いふけりました（笑）
素敵なお名前ですね♪
むずい
T Y さん
コメントありがとうございます。
難しいですよね…
ディジタル証明書は様々な要素が絡んでくるので
何かと理解が難しくなりがちです。
もし何が分からないのか分かったら
再度コメント頂けましたら
参考になりそうなサイトなどを紹介させていただきます！
令和4年春期試験午前Ⅱ 問15では"デジタル証明書"になっているんですよね
ほんとだー！！
田中電気さん貴重な情報ありがとうございます
個人的には
このまま脱”ディジタル”して、”デジタル”にして欲しいです(^^)
3Dセキュアはネットショッピングで使ったことがあるので、問題には答えられましたが、背景がわかって大変ためになりました。
Josui Kurodaさん
コメントありがとうございます。
動画がお役にたててうれしいです(^^)
デジタルに統一して欲しいですね（ディジタルは書くのが面倒）
Marcos Kasahara さん
コメントありがとうございます。
同感です。
私も”デジタル”に統一して欲しいと思っています(*_*)
8:06
署名前証明書のハッシュ値が一致しないケースはあるのでしょうか。
「認証局の秘密鍵で暗号化されたものは認証局の公開鍵でのみ複合できる」
という観点から考えると、データの改竄の心配はないような気がしています。
仮に通信の途中で攻撃者が介入し、公開鍵で復号化・改竄したとしても、
攻撃者は秘密鍵を持っていないため、再度暗号化できないためです。
書いているうちに思いつきましたが、
暗号化されたままのデータが別の値に書き換えられてしまったケースを想定したチェックでしょうか。
それが可能なのかは分かりませんが、
シリアル番号などを任意の値に書き換えることはできなくても、通信を妨害するには十分なので。
5:48
信頼性のある認証局にサーバ証明書を作ってもらわないと意味ないとのことですが、
他方で、証明書自体の種類にも信頼性のレベルがあるかと思います。
その上で、
信頼性のない認証局に信頼性の強いEV証明書を作ってもらっても、
それは信頼性の「ない」証明書になるのでしょうか？
抹茶クッキーさん
いつもコメントありがとうございます！
＞信頼性のない認証局に信頼性の強いEV証明書を作ってもらっても、
＞それは信頼性の「ない」証明書になるのでしょうか？
はい、信頼性のない証明書として扱われます。
現実社会ですが、自称鑑定士の鑑定書のついた高級時計を買うかどうかで考えるとイメージしやすいかもしれません。
鑑定書はついてるけど、自称鑑定士なのでその鑑定書は信頼しませんよね？
いくらEV証明書でも、発行した認証局が信頼できなければ
その証明書は信頼できません。
実際にはブラウザで”信頼できない証明書”という警告が出る事になると思います。