前回まででhttpsのプロトコル（通信手順）についての解説は終わりました。ここまでは、httpsの中のTLSハンドシェイクという手順を中心に解説をしてきました。ここまでのhttpsの内容も十分にマニアックでしたが、今回はいきがけの駄賃といいますか、いくつかここまでに触れることができなかった内容について解説します。1. TLS1.3－－－－－以前も書いたように、https＝http＋SSL/TLSです。そのTLSの最新バージョンであるTLS1.3が2018年8月に発表されました。この連載の最初にも書きましたが、SSL/TLSは今までにいくつものバージョンが発表されています。SSLには３つのバージョンがあり、いずれも使命を終えています。内容は下記の通りです。　1.0：これはすぐにバグが見つかったので実際には未使用　2.0：初期にはよく使われたが、脆弱性（文末参照）が見つかり　　　 3.0に移行。2011年に使用禁止となった。　3.0：2.0の後に長く使われたが、脆弱性が見つかりTLS1.0に移行　　　 2015年に使用禁止となった。このSSLの後継ぎがTLSです。このTLSのバージョンは次の通りです。　1.0：SSL3.0のバグ修正版。それ以外はほぼSSL3.0と同等　　　 2018年6月末時点で非推奨となった。（使用禁止ではない）　1.1：新たな攻撃方法に対する対策などを包含したバージョン　　　 これも1.0と同様の脆弱性が見つかっている　1.2：使用できる暗号化方法の追加などが行われた　1.3：2019年現在の最新版。古い暗号化方法の廃止、通信手順の　　　 変更などが行われた上ではサラリと書いていますが、TLS1.3にて通信手順が大巾に改訂されました。これまでの解説でもわかるように、https(TLS)では実際の通信を行う前にいろんなことを決めます。使う暗号の種類を決める、鍵の交換を行う、などのTLSハンドシェイクと呼ばれる手順が必要です。このTLSハンドシェイクに時間が取られることがTLSの大きな課題でした。にも関わらずSSL2.0の時代からTLS1.2に至るまでここには大きな変更はされず、手つかずでした。TLSの課題はそのままhttpsの課題です。TLS1.3は、TLSハンドシェイクの課題解消に取り組むことで、httpsの課題解消まで目指した意欲的な新バージョンなのです。具体的には、初回のTLSハンドシェイクで決めたことを次回以降も再利用できるようになりました。httpsは、一度サーバに接続しても１つのデータ（ファイル）を送受信すると「さよなら」（クローズ）するルールになっています。一般的に１つのWebページを表示するには数十のファイルが必要ですから、何十回ものTLSハンドシェイクが必要です。通信相手が同じ限り、何回TLSハンドシェイクしても同じ結果になりますから、何度もやるのは無駄でしかありません。TLS1.3では、２回目以降は「いつもの」と言うだけでTLSハンドシェイクを行わずに済むようになりました。なじみのお店で「いつもの通りで」と言えば通じるのと似た感じですね。こうすれば、同じTLSハンドシェイクを毎回毎回毎回毎回繰り返すのを省略できるわけで、トータルでは時間をグッと縮めるられるというワケです。詳細は省略しますが、ハンドシェイク手順をより安全にするための改訂も行われていて、ずいぶんと盛り沢山なバージョンになっています。なお、TLS1.3の実装（実際に動くプログラム）はすでにあちこちで提供されていて、主要なブラウザは対応済ですし、多くのサーバプログラムも既に提供されています。とはいえ、通信には相手がいます。相手がTLS1.3に対応できていなければ、今まで通りの手順を使う他ありません。その意味で、TLS1.3が普通に使われるまでには、まだまだ時間がかかりそうです。2. HTTP/2－－－－－現在多くのサイトで使われているHTTPはバージョン1.1です。これは1999年に定められた意外に古いプロトコルです。その16年ぶりの改訂版がこのHTTP/2という規格です。名前はHTTP/2 ですが、HTTPとHTTPSの２つのプロトコルの定義が含まれています。HTTP1.1では、一度サーバに接続すると１つのデータ（ファイル）だけをやりとりして、「さよなら」（クローズ）するルールでした。これが決められた1990年代はそれでも良かったんです。１つのWebページの構成要素は今よりもずっとシンプルでしたから。ですが、現代では上で書いたように１つのページを表示するにも何十ものファイルが必要になっていますから、明らかに当時とは想定がズレてきています。これを防ぐため、上述のTLS1.3は「いつもの」と伝えれば前回と同じ方式とするルールを追加しました。HTTP/2はそれとは違ったアプローチをとりました。１つのデータ（ファイル）のやりとりが終わっても、すぐにサーバと「さよなら」（クローズ）せず、そのまま次のデータのやりとりを続けられるルールを追加したのです。TLS1.3にしてもHTTP/2にしても、毎回TLSハンドシェイクを繰り返すムダを避けるのは同じなのですね。なお、HTTP/2はGoogleが自主的に開発していたSPDY（スピーディ）という実験用プロトコルを標準化したものです。ちなみに、HTTPと大文字で書く場合とhttpと小文字で書く場合があります。プロトコルとしてはHTTPと大文字で書くことが多く、URLに書く時はhttpと小文字で書くことが一般的ですが、どちらも意味は同じです。さらに余談ですが、メールアドレスも大文字と小文字は区別されないルールになっています。ですから、メールアドレスの大文字小文字を間違ってもちゃんと相手には届きます。3. HTTP/3－－－－－上のHTTP/2は2015年に定められた規格で、まだまだ一般化していると言えない状態ですが、さらにその次世代のHTTP/3の標準化が進んでいます。HTTP/2からさらなる高速化を目指して、内部構造を大きく見直しています。ただ、HTTP/2にしても、HTTP/3にしても、一般利用者からは今までのHTTP1.1と違いを意識しなくても良いように設計されています。利用者にとっては、ブラウザを使うときにキビキビと素早く動けばいいわけで、内部構造がどうであろうと関係ないですからね。なお、このHTTP/3もHTTP/2の時と同様、Googleの実験用プロトコルであるQUIC（クイック）を標準化したものです。4. httpsが複数の方式から選択させる理由－－－－－－－－－－－－－－－－－－－－前回までに述べたように、httpsでは複数の手法からどれかを選ぶという場面がよく出てきます。例えば、次のようなものがあります。・TLSバージョンの選択・暗号方式の選択・鍵交換の方法の選択どうせなら、最強の方式を一つだけにすれば、TLSハンドシェイクもシンプルにできますし、よさそうなものです。そうしていないのには理由があります。規格を定めた時点で最強の方式を選んだとしましょう。でも、１種類に固定すると、いつか最強じゃなくなります。数年もすればさらに強力な方式が登場するのは明らかですから。強力な方式が登場するたびに、規格を改訂するようではむしろ混乱を招くだけです。ですが、それよりもはるかに深刻な問題があります。それは、その最強の方式に欠陥が見つかると、https自体が使えなくなるというものです。最初から複数の方式を選べるようにすれば、一つの方式に欠陷が見つかってもその方式を避けることで、httpsは使い続けることができますよね。httpsの目的は「安全な通信」です。絶対に欠陥のないものは人類には作れません。だから、欠陥が見つかっても使い続けられるという前提で設計がされているのです。この点からも、httpsは非常に丁寧に考えられた仕組みといえます。今回は以上です。次回もお楽しみに。

今回は、httpsの通信手順（プロトコル）解説の４回目です。繰り返しになりますが、通信手順といっても難しいことをやるわけではありません。コンピュータ同士でのチャットのようなものです。チャットと言ってわかりにくければ携帯電話のショートメッセージによる会話と言えばイメージしやすいでしょうか。そのチャットを通してお互いに必要な情報をやりとりします。httpsの場合であれば、「あんただれ？」とか「俺は暗号方式○○か△△が使えるんだけど、そっちは？」などというやりとりをするわけです。これを専門用語でプロトコルと呼ぶにすぎません。今回はサーバ証明書の確認の次のステップである鍵交換について解説します。そうそう、最初に用語定義をしておきます。クライアント： 　今からサーバにつなぎたいコンピュータ。　一般的には家庭にあるＰＣのブラウザがクライアントとなります。　以下の図中ではこれを[ク] と記載します。サーバ：　一般的にサーバとは単体で使うことを目的とせず、他の利用者や　コンピュータにサービスを提供するコンピュータのことです。　ここでは、httpsでの通信を提供しているコンピュータを指し、　多くの場合、ブラウザでアクセスする先のWebサイトとなります。　以下の図中ではこれを[サ] と記載します。1. 鍵交換－－－－－鍵交換というのは、暗号化と複合に使う鍵を第三者に知られないように相手に渡す方法を言います。普通に考えれば、相手には伝わって、それ以外の人にはわからないようにする方法なんてなさそうに思います。実際、鍵を安全に受け渡しする方法は長い間見つかっていませんでした。それを数学的アプローチで解決する方法を見出したのが、デフィーとヘルマンによるDH法と呼ばれる鍵交換の方法でした。その詳細はこの連載の「https その３（鍵交換）」で解説しましたので、詳しくはそちらをご覧いただきたいのですが、ものすごくおおざっぱに言えば、サーバ側とクライアント側で交換した値を元にして、第三者には計算できない値を得る方法です。3. 鍵交換の手順－－－－－－－－では、実際にはどんな手順で鍵交換を行うのでしょうか？1. [サ]→[ク]　ServerKeyExchange2. [ク]→[サ]　ClientKeyExchange最初にサーバ側は、ServerKeyExchangeのメッセージとしてDH法の計算に必要なサーバ側の値を送信します。次に、クライアント側は、ClientKeyExchangeのメッセージとして、同様にクライアント側の値を送信します。（厳密にはもう少し複雑ですが、解説が煩雑になるので省略します）これで互いに相手の値が得られたので、後はDH法に従って計算をすることで、鍵交換ができました。互いに値をあけっぴろげに送っているのに、第三者は計算できない？と不思議に思われた方はこの連載の「https その３（鍵交換）」を再読ください。https://archives.mag2.com/0001678731/20181029064000000.htmlなお、鍵交換は上記のDH法以外にもRSA方式などいくつかの方法がありますが、長くなりすぎますので省略します。4. プリマスターシークレットから共有鍵へ－－－－－－－－－－－－－－－－－－－－では、これで鍵交換ができたのだから、その値を使ってhttpsの暗号鍵に...、とはなりません。httpsではさらにもうひと手間をかけます。ここまでは以前も書いた内容ですが、ここからが、httpsの共有鍵を求めるキモとなります。上記の鍵交換で得た値をプリマスターシークレットと言います。この値を元に、マスターシークレットという値の得る計算をします。わざわざ再計算するのは理由があります。というのは、鍵交換の方式によってプリマスターシークレットの形式というのは違っているのです。もし、このままの形式で計算を続けようとすると、プリマスターシークレットの種別毎に別々の計算式を用意しなければなりません。例えば、鍵交換の方式が３種、暗号化の方式が５種の場合、１５通りの計算式を個別に用意する必要があるわけで、さすがに効率が悪すぎます。そこで、マスターシークレットという統一形式の値を再計算して求めておけば、その後は同じ手順ひとつだけで済むわけです。なるほど、じゃあそのマスターシークレットがhttpsの暗号鍵に...、といいたいところですが、これも違います。今度は、鍵の大きさが暗号方式によってまるで違うことが問題になります。マスターシークレットだけでは、鍵として使える量に足りない場合があるのです。そのため、マスターシークレットを元に、キーブロックという別のデータを再生成します。このキーブロックというのはいくらでも必要なだけの量のデータを得られる計算式ですので、暗号鍵に必要なサイズのデータを取り出せるわけです。そして、ようやく、このキーブロックから取り出した値がhttpsの暗号用の鍵として使える値になるのです。httpsって恐ろしく面倒臭い計算をしているのですね。5. 暗号による通信の開始－－－－－－－－－－－－以上の手順で暗号用の鍵を得ますと、いよいよ暗号化による通信が始まります。上記で得た暗号用の鍵をセッション鍵と言います。セッション鍵は名前の通り、セッションの期間中だけ有効です。ですが、httpsのセッション寿命って非常に短いのです。どのくらい短いかというと多くの場合１秒以下という短さです。試しに、Googleのページ（https://www.google.co.jp)を表示したところ、12個のセッションが開かれていました。あれだけ手間がかかる手順を、Googleのようなシンプルな画面を表示するだけでも12回もやりとりするわけです。普段何気なく使っているhttpsですが、実際にはこれだけの大変な手間をかけて、実現しているのですね。6. つまりhttpsとは？－－－－－－－－－－－さて、長い連載になったhttpsの解説ですが、まとめれば次の３つのことを行っていると言えます。・暗号化の手順を規定することで、最新の暗号を使いやすくする。・証明書を確認することで、通信相手が正しいことを確認する。・経路を暗号化することで、通信内容をわかりにくくする一般的には３つ目の効用が大きく取り上げられますが、それだけではないということは、ここまでの解説を読んだ皆さんならご理解いただけると思います。たとえば、「証明書が適切ではない」などというエラーはなぜ出るのか？「バージョンが違う」とか「利用できる暗号方式がない」などと言われて接続できないのはなぜか？といったことも（なんとなくでも）理解できるようになったのではないかと思います。さて、しつこいですが、httpsについては、もう少し補足したい点もあります。次回はhttpsの番外編として、これまで触れなかった事項について解説したいと思います。次回もお楽しみに。

今回は、httpsの通信手順（プロトコル）解説の３回目となります。前回の繰り返しですが、通信手順といっても難しいことをやるわけではありません。コンピュータ同士でのチャットのようなものです。チャットと言ってわかりにくければ携帯電話のショートメッセージによる会話と言えばイメージしやすいでしょうか。そのチャットを通してお互いに必要な情報をやりとりします。httpsの場合であれば、「あんただれ？」とか「俺は暗号方式○○か△△が使えるんだけど、そっちは？」などというやりとりをするわけです。これを専門用語ではプロトコルと呼んでいるにすぎません。さて、前回はサーバから送られてきたデータを検証する内容の途中でしたので、その続きからとなります。なお、この記事では、証明機関・サーバ証明書・署名といった用語を説明なく使っています。この連載の以前の記事（httpsその１～その１０）ではこういった用語についても詳しく解説していますので、未読の方はそちらに目を通してから読んでいただければ、わかりやすいかと思います。1. TLSハンドシェイク（再掲載）－－－－－－－－－－－－－－－前回と同じ内容ですが、httpsでは次の順でやりとりを行います。1. TLSハンドシェイク　1.1 ご挨拶　1.2 サーバ証明書の検証　1.3 （クライアント証明書の検証）　1.4 鍵交換　1.5 暗号化通信への移行2. 暗号化した状態でのhttpこのうち、「1.1 ご挨拶」を前々回に、「1.2 サーバ証明書の確認」の一部を前回解説しました。今回はその続きと、「1.3 （クライアント証明書の検証）」を解説します。2. サーバ証明書の検証－－－－－－－－－－－サーバ証明書はサーバが自己の身元保証のためにクライアント側に送るデータです。その内容はおおむね次の通りです。１）サーバ証明書を発行した証明機関名２）サーバ証明書の署名３）サーバ証明書の有効期間４）サーバの所属する組織名５）サーバのドメイン名このうち、１と２については前回のメルマガで解説しましたので今回はその続きです。3. サーバ証明書の有効期間の確認－－－－－－－－－－－－－－－－次に、サーバ証明書の有効期間を確認し、現時点で有効かどうかを確認します。有効期間内であっても、例えば秘密鍵が漏出してしまったなどの理由で無効としたい場合がありますので、証明機関から失効した証明書リストを取り寄せて確認を行います。4. サーバのドメインの確認－－－－－－－－－－－－－次に、アクセスしようとしているURLのドメイン名と実際のドメイン名が合っていることを確認します。ドメイン名というのは、サーバがどこにあるかを示す住所のようなものです。例えば、次のようなURLを考えてみます。https://example.com/index.htmlこのうち、exmaple.com の部分がドメイン名になります。サーバ証明書にはこのドメイン名が含まれています。クライアントは、実際にアクセスしているURLとサーバ証明書のドメイン名を比較し、一致していることを確認します。実際にアクセスしても、証明書のドメインが食い違っていれば、ヨソの証明書という意味ですから、全く信頼が置けません。この場合は、「他のサイトの証明書です」といったエラーになり、やはり通信は行われません。さて、ここで注意していただきたいのは、以上の確認はあくまで技術的に正しい証明書であることを証明しているに過ぎないことです。いくらサーバ証明書が正しくて、httpsとして正しくても、そのサイトが善良であることなど証明できるはずがありません。あくまで、サーバ証明書に書かれた内容と実際のサイトの情報が一致していることを証明しているに過ぎません。あたりまえですが、httpsだからといって接続先が善意のサイトとは限らないということです。さて、以上の手続きに全て合格すれば晴れて証明書の確認が終わりです。証明書の確認だけで、これだけのことを行わなければ安全は確保できないんです。httpsという仕組みが複雑になるのはこういった手間をかけないと安全とは言えないからなんですね。5. クライアント認証－－－－－－－－－－さて、ここまで説明してこなかったのですが、TLSハンドシェイクの表に、次のようなカッコ付きの行があります。　1.3 （クライアント証明書の検証）これがカッコ付きになっているのは、これがオプション機能であまり使われていない機能だからです。なので、ここでもサラリとだけ触れるに留めておきます。これは、サーバ証明書とは全く逆に、クライアントの身元保証の仕組みです。例えば、重要な情報を保持しているページなどであれば、IDとパスワード以外にも接続できるクライアントを限定したいケースがあります。そのための方法としてhttpsではクライアント証明書を用います。内容は、サーバ証明書とほぼ同じで、確認する内容も同様です。ただ、クライアント側から提示して、サーバ側が検証するという形になり、主従が入れ換わる形になります。ただ、クライアント証明書というのはインストール作業が結構難しく、一般の方には手に負えない場合が多いのです。技術的には非常にスジの良い方式なのですが、活用するハードルが高いため、あまり活用されていないのが実情です。技術的に良いからといって広く利用されるとは限らない例と言えます。なお、httpsにこだわらなければ、他にも接続元を限定する方法はいろいろと存在しています。今回はhttpsにフォーカスしていますので、ここでは触れませんが機会があれば、別記事にて解説をしたいと思います。6. 暗号化のための鍵交換（予告編）－－－－－－－－－－－－－－－－－さて、ここまででTLSハンドシェイクのうち、以下の３つの解説を行いました。　1.1 ご挨拶　1.2 サーバ証明書の検証　1.3 （クライアント証明書の検証）後、大きなテーマとして残っているのは 鍵交換となります。次回はこの鍵交換の具体的な方法と暗号化通信への移行について解説をします。長かったhttpsのシリーズですが、次回が最終回の予定です。もう少しだけおつきあいください。次回もお楽しみに。

今回は、httpsの通信手順（プロトコル）解説の続きとなります。通信手順といってもそんな難しいことをやっているわけではありません。いつも言っているようにコンピュータ同士でチャットのようなものです。チャットと言ってわかりにくければショートメッセージによる会話のようなものです。そのチャットの中でお互いに必要な情報をやりとりします。httpsの場合であれば、「あんただれ？」とか「俺は暗号方式○○か△△が使えるんだけど、そっちは？」などというやりとりをするわけです。このやりとりが終われば、実際に取り決めた内容に応じて目的の通信を始めます。この前段のやりとりの部分は「TLSハンドシェイク」と呼ばれhttpsのキモとなる部分なのですね。1. TLSハンドシェイク－－－－－－－－－－－前回のおさらいになりますが、httpsでは次の順でやりとりを行います。1. TLSハンドシェイク　1.1 ご挨拶　1.2 サーバ証明書の検証　1.3 （クライアント証明書の検証）　1.4 鍵交換　1.5 暗号化通信への移行2. 暗号化した状態でのhttpこのうち、「1.1 ご挨拶」を前回解説しました。httpsは「安全なhttp」が目的です。安全を担保するには通信の方式や暗号化の方式を決めるだけではなく、通信相手がホンモノかどうかを見極めなければなりません。今回は通信相手を見極めるための「1.2 サーバ証明書の検証」について解説します。2. サーバ証明書の検証－－－－－－－－－－－前回と同じですが、用語の確認です。クライアント： 　今からサーバにつなぎたいコンピュータ。　一般的には家庭にあるＰＣのブラウザがクライアントとなります。　以下の図中ではこれを[ク] と記載します。サーバ：　一般的にサーバとは単体で使うことを目的とせず、他の利用者や　コンピュータにサービスを提供するコンピュータのことです。　ここでは、httpsでの通信を提供しているコンピュータを指し、　多くの場合、ブラウザでアクセスする先のWebサイトとなります。　以下の図中ではこれを[サ] と記載します。httpsでご挨拶が終わり、どんな暗号方式を使うのかといったやりとりが終わると、次にサーバからサーバ証明書がクライアントに送られます。そのやりとりはものすごくシンプルで、サーバからクライアントにServerCertificateというメッセージを送るだけです。サーバ証明書を受け取ったクライアント側は、その内容が正しいかどうかを検証します。3. サーバ証明書－－－－－－－－サーバ証明書というのは、要は電子証明書です。電子証明書については、httpsその７～１０の４回に分けて解説しました。とまあ、マジメに書くと４回分位になるややこしいものですが、端的に書くと、「サーバ側から伝えたい情報（公開鍵やURLなど）に対して、証明機関という民間の組織が「署名」という行為を行って作られた小さなデータ」です。公開鍵ってナニ？とか証明機関ってナニ？署名って？という方は以下のバックナンバーをご覧ください。httpsその５（公開鍵暗号方式１）  https://archives.mag2.com/0001678731/20181112064000000.htmlhttpsその６（公開鍵暗号２）  https://archives.mag2.com/0001678731/20181119064000000.htmlhttpsその７（電子証明書１）  https://archives.mag2.com/0001678731/20181126064000000.htmlhttpsその８（電子証明書２）  https://archives.mag2.com/0001678731/20181203064000000.htmlhttpsその９（電子証明書３）  https://archives.mag2.com/0001678731/20181210064000000.htmlhttpsその１０（電子証明書４）  https://archives.mag2.com/0001678731/20181217064000000.htmlちなみに「がんばりすぎないセキュリティ」ではバックナンバーは全て公開しています。ホントは１年以上前の情報は古すぎて時代に合わない可能性が高くなるため、古い記事は非公開としたいところですが、そういうことはできませんので、全公開としています。さて、サーバ証明書というのは、形式は上述のとおり電子証明書そのものです。その中には、１）サーバが使う公開鍵暗号の公開鍵２）サーバが自己申告する情報３）上記の２つが改竄（かいざん）されていないことの署名　　※署名とは、手書きのサインのことではなく、特定の計算を　　　行った値のことです。の３つのデータが入っています。サーバ証明書の検証とは、サーバが自己申告する情報を検証することに他なりません。4. サーバが自己申告する情報の検証－－－－－－－－－－－－－－－－－さて、サーバが自己申告する情報は以下が典型的です。１）サーバの所属する組織名２）サーバのドメイン名また、証明機関が付加した以下の情報も検証に使います。１）サーバ証明書を発行した証明期間名２）サーバ証明書の署名３）サーバ証明書の有効期間確認することはいろいろありますので、順に説明します。なお、それぞれの詳細な解説は上述のバックナンバーで行っていますので、そちらをご参照ください。5. 証明機関の確認－－－－－－－－－最初にクライアントが知っている証明機関かどうかを確認します。各ブラウザにはあらかじめ、著名な証明機関の証明書（ルート証明書またはルートCA証明書）が組み込まれています。ここに含まれていない証明機関による署名が付いている場合は、そのままでは信頼して良いのかどうかが判断できませんので、通常は「信頼できない証明書です」といったエラーになります。ここで問題がなければ、次の署名の確認を行います。6. 署名の確認－－－－－－－署名の正しさを確認する方法については、電子証明書の解説で書きましたが、おさらいしておきます。証明書はデータ部と署名部の二部構成となっています。署名部にはデータ部を特定の方法でかきまぜてハッシュ値という値を求め（ハッシュ関数というもので生成します）それを証明機間の秘密鍵で暗号化したデータが入っています。データ部を変更した時は、署名も変更が必要です。データ部は誰でも変えられますが、署名には証明機関の秘密鍵が要りますから、証明機関でないと変えられません。ですから、署名が正しければデータ部が変更されていないと言えるわけです。署名を確認する方法ですが、署名を作る時と同じ方法でハッシュ値を得ます。次にサーバ証明書にある署名を証明機関の公開鍵（これはあらかじめブラウザに登録されています）を使って暗号を解きます。この両者が一致していれば、データ部が改竄されてないと言えるというわけです。署名が一致しなければ、証明書として信頼できませんから、httpsとしての通信は行えません。ブラウザでは「不適切な証明書です」といったエラーとなります。署名が確認できれば、次はサーバが自己申告した情報の確認を行います。もう少しサーバ証明書の確認については解説することがあるのですが、さすがに長くなってきましたので、途中ですが、今回はここまでといたします。次回はこの続きと、クライアント証明書の解説をします。次回もお楽しみに

今回は今までの解説の内容を踏まえながら、いよいよhttpsの通信手順（プロトコル）解説を始めます。通信手順といってもそんな難しいことをやっているわけではありません。いわばコンピュータ同士のチャットのようなものです。これは、以前解説したメール転送プロトコルのSMTPやハイパーテキスト転送プロトコルのHTTPなどと同じです。※次号配信日のお知らせ　毎週月曜日に配信しています「がんばりすぎないセキュリティ」　ですが、次週の月曜日(12/31)が年末となるため、お休みとさせて　いただきます。　次回配信は２週間後の2019/1/7となります。1. httpsとhttpやSMTPはどうちがう？－－－－－－－－－－－－－－－－－－たとえば、SMTPでは目的のコンピュータに接続すると、接続元がご挨拶を送るところから始まりました。※以下は「メール転送プロトコル」(2018年9月17日配信)から抜粋 1送： helo mail.yyy.co.jp 2受： 250 mail.xxx.co.jp Hello mail.yyy.co.jp [x.x.x.x], pleased to meet you  3送： mail from: alice@yyy.co.jp 4受： 250 2.1.0 alice@yyy.co.jp... Sender okhttpsも同じなのですが、SMTPに比べると30年ほど新しいプロトコルですし、上のようなチャット風ではなく、決められた値をやりとりする形となっています。例えば、最初の接続時に１を送り、その返信として２が返されれば正しい、といった具合です。（実際には、この値だけでなく付加情報を同時に送ります）ただ、これでは設計する人にとっても実際にhttpsのプログラムを作る人にとってもわかりづらすぎます。なので、それぞれのやりとり（メッセージタイプと言います）に呼び名がつけられています。上の例なら、最初の接続時にClientHello を送り、その返信がServerHello であれば正しい、という方がはるかにマシですから。というわけで、この解説でも以降ではこの呼び名を使います。2. httpsはどんな手順でナニを決めるのか？－－－－－－－－－－－－－－－－－－－－－httpsでの通信はおおむね、次のように進められます。1. TLSハンドシェイク　1.1 ご挨拶　1.1 サーバ証明書の検証　1.2 （クライアント証明書の検証）　1.3 鍵交換　1.4 暗号化通信への移行2. 暗号化した状態でのhttp最初のハンドシェイクというのは握手という意味です。この握手をすることで、　どんな暗号方式を使うのか？　相手を信頼しても大丈夫か？　共有鍵は何を使うのか？といったことを決めてるのです。つまり、httpsの本質はTLSハンドシェイクの部分にあり、その後の暗号化通信自体は、暗号を解けば単にhttpのやりとりと同じものだということです。個々の手順について以下で解説をしていきます。今までに解説してきたことがらが、どのように使われるかをご理解いただけると嬉しく思います。なお、以下の解説ではhttpsプロトコルの細かい点は大幅に略しています。またここに書いた以外にも、オプションや拡張仕様は山ほどありますがそれも省略です。（筆者ごときでは全てを解説できません）というか、これを全部書いてるとフツーの人がわかっておいた方が良いという「がんばりすぎないセキュリティ」が目指すレベルをはるかに越え、プロ向けの「httpsのすべて」ってメルマガになってしまうからです。そうそう、最初に用語定義をしておきます。クライアント： 　今からサーバにつなぎたいコンピュータ。　一般的には家庭にあるＰＣのブラウザがクライアントとなります。　以下の図中ではこれを[ク] と記載します。サーバ：　一般的にサーバとは単体で使うことを目的とせず、他の利用者や　コンピュータにサービスを提供するコンピュータのことです。　ここでは、httpsでの通信を提供しているコンピュータを指し、　多くの場合、ブラウザでアクセスする先のWebサイトとなります。　以下の図中ではこれを[サ] と記載します。では、始めましょう。3. httpsでのご挨拶－－－－－－－－－－さて、httpsでも最初にするのはご挨拶です。クライアントがサーバに接続すると、次のような通信を行います。1. [ク]→[サ]　ClientHello2. [サ]→[ク]　ServerHello最初に、クライアント側からClientHelloというメッセージを送ります。名前はCLientHelloですが、クライアントからのあいさつだけでなく、クライアントが使えるSSL/TLSのバージョン、暗号法式の伝達や、共有暗号鍵のネタになる数値の送付も兼ねています。次にサーバ側はクライアントから渡された情報を元にServerHelloの返信をします。あたりまえですが、互いに理解できるバージョンや暗号化方式を選んでおかないと、実際の通信が行えません。それを行うのが、この「あいさつ」の大きな目的です。例えば、クライアントがTLS1.1だよ、と申告してきた時、サーバがTLS1.0以降を受け付けるのであれば、TLS1.1の接続になります。ですが、クライアントがTLS1.1だったのに、サーバ側がTLS1.2以降しか使えない設定にしていると、相互に使えるバージョンがないため、接続は成立しません。ブラウザ上では「このページは表示できません」とか「安全な接続ができませんでした」といったエラーとなります。ところで、httpsは鍵交換の方式や共有鍵暗号の方式、ハッシュ関数の方式などが選べるようになっています。これが選べることでいくつか利点が出てきます。一つはTLSの仕組みを変えなくても強力な暗号化方式に変更可能な点、もう一つは特定方式に問題が見つかっても、スグに他の方式に切換えできる点、です。実際、ClientHelloの中には、クライアントが使える暗号方式を一覧形式で送ることになっています。ClientHelloを受け取ったサーバは、自分が使えるTLSのバージョンや暗号化方式などと合致するかどうかを確認して、ServerHelloをクライアントに送り返します。この中には、使うTLSのバージョンや暗号化方式などを入れて返すルールとなっています。それを受け取ったクライアントは、次のサーバ認証の手続きに進むわけです。と、盛り上がってきたところですが、今回はここまでとします。この後のサーバ認証の仕組み、実際の鍵交換などは次回以降となります。次回もお楽しみに。

今回も前回に続き電子証明書の解説です。ここまでで、電子証明書の構造などについて解説を行いました。今回は、発行した電子証明書が有効かどうかの確認方法と、発行済みの証明書を無効化する方法について解説します。1. httpsで使う電子証明書の種類－－－－－－－－－－－－－－－－httpsでの電子証明書には、各サーバが自身の証明に使うサーバ証明書と各利用者が自身の証明に使うクライアント証明書があります。また、証明書が正しいかどうかの確認に用いるルート証明書（ルートCA証明書）がブラウザの中にあらかじめ組み込まれています。結局、　１）サーバ証明書　２）クライアント証明書　３）ルート証明書（ルートCA証明書）の３種類がhttpsで使われています。このうち、クライアント証明書は、e-TAX（国税庁が運営している確定申告用のサイト）のように確実な本人確認を必要とする場合に使用されています。とはいえ、サーバ証明書と構造は同じで、使い方が違うために呼称が違っているにすぎません。これはルート証明書も同様です。2. 証明書の有効期限－－－－－－－－－－電子証明書には必ず有効期限というものがあります。具体的には、いつからいつまで有効だという日付が入っています。一般的に、サーバ証明書の有効期限は１年というのが多いようです。有効期限切れとならないように、そのサイトの運営担当者が新しい証明書に定期的に交換しています。クライアント証明書の有効期限はサーバ証明書よりは長い期間とすることが多いようです。最後のルート証明書はもっとも期限が長く、20年や30年の有効期間とするのが通常です。どうして、より大事なはずのルート証明書が長い間、更新しないのに、サーバ証明書は毎年更新するのでしょうか？これは、サーバ証明書の方が秘密鍵を使う回数が極端に多いためです。一般に、大量の暗号文が手に入ると、秘密鍵の解読は行いやすくなります。当然ながら、httpsは日々のショッピングやオンラインバンキングで使われますから、正しい暗号文は日々作成され、大量の暗号文を入手することも容易です。それに対して、ルート証明書の暗号鍵を使って作られた暗号文はそれこそ電子証明書くらいしかありません。大規模な証明機関でも、年に数万や数十万の証明書しか発行しないわけですから、ルート証明書の秘密鍵を使った暗号文は意外に入手しづらいですし、新たな暗号文の入手は非常に難しいわけです。そのため、ルート証明書は有効期限を長くしても安全は脅かされないという理屈なのですね。3. 鍵がバレたら？－－－－－－－－－そうはいっても、何らかの理由で秘密鍵がバレたらどうするのでしょうか？鍵の解読は非常に困難とはいえ、可能性はゼロではありません。とすれば、鍵がバレた時にも対応できなければ、仕組みとしては失格です。電子証明書を使った認証手順では、このような鍵がバレてしまった状態の対応も考慮されています。なお、鍵がバレた状態のことを危殆化（きたいか）と呼びます。サーバ証明書を発行する証明機関にとって、証明書の危殆化対応も重要な業務です。何らかの理由でサーバ証明書に含まれた公開鍵と対になる秘密鍵が知られてしまった場合、もはやそのサーバ証明書は使い物になりません。このため、サーバ証明書を発行する証明機関では、必ず失効リスト（CRL:Certificate Revocation List）というのを公開しています。これは、有効期限に至る前に証明書が無効であることを宣言するものになります。証明機関では、毎日のようにこの失効リストを更新しています。httpsの手順では、サーバからサーバ証明書を受け取ると、失効リストに含まれていないことをチェックします。そのリストに入っていなければ、その証明書は使えるものとして、httpsの通信を始めるわけです。とはいえ、証明機関ごとに失効リストがありますし、失効リストを毎回確認したりするのも大変ですので、失効リストの確認だけを専門に行うサーバを用意する場合もあります。これにはOCSPという方式を使うのですが、ここでは省略します。電子証明書の解説については以上となります。4. おまけ：ソフトバンクの通信障害について－－－－－－－－－－－－－－－－－－－－－2018/12/6にソフトバンクの携帯網が広い範囲で使えなくなるという大変なトラブルが発生しました。ユーザの方々はさぞ大変だっただろうと思います。この原因の一つが電子証明書の期限切れであったと機器メーカ側から発表されています。あまりにタイムリーだったので、少しだけ解説をしておきます。（注：この号の配信は2018年12月17日でした）なお、この原因の詳細はまだ公開されていませんので以下は筆者の憶測であることをお断わりしておきます。証明書には、上述の通り有効期限というのが入っています。今回のトラブルでは、内部で使用しているソフトウェア用のサーバ証明書の有効期限が2018/12/6となっていたことが原因といわれています。内部で使うソフトウェアでもより安全とするため、httpsを使う場面は増えています。内部利用を前提とする場合、そのソフトウェアは外部との接続ができない設定としますので、サーバ証明書が取られたり、攻撃を受けたりするリスクは非常に低くなります。そのため、そのようなソフトウェアに添付するサーバ証明書は製品寿命よりも長い（数年程度）くらいの有効期限とするのが一般的です。今回もまさにこのパターンなのですが、ソフトバンクが2018年3月時点でインストールしたバージョンには2018年12月6日に有効期限を迎えるサーバ証明書がインストールされてしまったようです。おそらくは、提供元の内部管理ミスで古い証明書を製品に含んで出荷してしまったのではないかと思われます。その意味で、ソフトバンクの運営が悪いわけではなく、避けようのないトラブルだったと言えます。今回は以上です。次回からは今までの話を踏まえて、httpsのプロトコル解説を行います。

今回のhttpsのシリーズは予想通り長い連載となっていますので、少々整理しておきます。httpsのプロトコル（文末参照）を解説するにあたり、以下の要素技術の概要を解説してきています。　・TLS/SSL（その１、その２）　・鍵交換方式（その３）　・一方向性関数（その４）　・公開鍵暗号方式（その５、その６）　・電子証明書（その７、その８、その９、その１０（予定））どれも一般にはなじみの薄いコトバですので、これらを事前に解説しないことには、httpsの解説ができません。あと少しで本題に辿り着きますので、もう少しおつきあいください。一般にhttpsは、「httpsの通信内容を暗号化した安全なもの」というイメージが強いかと思います。ですが、実際には暗号化のみならず、上記のような要素技術を統合した大変に複雑な技術だと言えます。さて、今回は電子証明書の署名の確認手順として、ルートCA証明書と中間証明書について解説します。1. 署名者の確認－－－－－－－－さて、証明書は署名を確認することで、データ部分が改竄（かいざん）されていないことを保証します。ですが、署名というのはハッシュ値という計算結果を秘密鍵で暗号化したものにすぎません。秘密鍵というと非常に特別なものに思えるかもしれませんが、公開鍵暗号の回に解説した通り、これを作るのは誰でもできることです。となるとここで疑問が出てきます。つまり、署名によってデータ部の改竄を抑止できるのはわかった。でも、その署名をした組織が信用できるかどうか？はどうやればいいのか？という疑問です。実際、悪意を持ったサイト運営者と悪意のある証明機関がチームを組めば、技術的にはなんの問題もない証明書が発行できます。だからといって、そのような悪意のあるサイトが適正であるかのように扱われるのは不合理です。電子証明書には署名した組織の情報が入っています。確かにこの情報を使えば署名者が信用できるかどうかをチェックできます。2. 信用できるかどうかはどうやって決めるの？－－－－－－－－－－－－－－－－－－－－－－とはいえ、信用できるかどうかはどうやって決めれば良いのでしょうか？証明機関は世の中に何百、何千とあります。どれが信用でき／どれが信用できないかなんて誰にもわかりません。信用できる／できないを判断するための第三者機関を設ける方式も規定はされていますが、現状では一部（官公庁など）を除いて機能していません。かといって、それを利用者がいちいと確認しなければいけないとなると、面倒臭くてたまりませんし安全とも言えません。ですが現実には、ブラウザでhttpsはフツーに使えていますし、時には「このサイトの証明書は信頼できない」といった警告も出してくれたりもします。一体、ブラウザは何を基準に決めているのでしょうか？答えは意外に単純で、ブラウザの中にルートCA証明書と呼ばれる電子証明書が最初から入っているのです。お使いのブラウザで設定を見ると「証明書」などという項目があるはずです。その中の「ルートCA証明書（ルート証明書）」というところに数十の証明書が入っているのがわかると思います。ですが、上記に書いたように証明機関というのは世の中にゴマンとあります。たった、数十の証明書でそれを補えるというのはどういう理屈なのでしょうか？そのための仕掛けとして「証明書チェーン」があります。3. 証明書チェーン－－－－－－－－－証明書チェインとも呼ばれます。これは、証明書自身を他の証明書で証明してもらうという考え方です。例で説明しましょう。登場人物は次の３名です。　証明機関Ａ：ブラウザに登録済のルートCA証明書の発行元　証明機関Ｂ：サイトＣの証明書を発行する機関　サイトＣ：　httpsを使いたいサイト証明書１）証明機関Ａ　が　証明機関Ａの公開鍵　に署名証明書２）証明機関Ａ　が　証明機関Ｂの公開鍵　に署名証明書３）証明機関Ｂ　が　サイトＣ　の公開鍵　に署名ここでは３つの証明書が登場します。この３つの中であからさまに怪しいのが証明書１です。だって自分で自分の鍵に署名してるんです。これがＯＫなら何でもＯＫになってしまうように見えます。この証明書１は特別扱いでルートCA証明書と呼ばれます。何が特別かというと、ルートCA証明書だけは無条件で信じてよいことになっているのです。なんだか理不尽ですが、どこかの時点で無条件に信頼できるポジションを設定しておかないと全てが信頼できないことになってしまうからです。その意味でブラウザに登録されるルートCA証明書は非常に慎重に選択され、大丈夫かどうかを十分に吟味した上で登録されています。さて、証明書１を無条件に信じて良いという前提に立つと、証明機関Ａは大丈夫なのがわかっていますから、次の証明書２の署名も問題ないと言えます。さらに、証明書２が問題ないのであれば、同じ理由で証明書３も問題ないと言えます。このようにルートCA証明書から辿っていくことで、証明書３が正しいと言えるわけです。このように複数の証明書を辿って最終的に受け取った証明書を信じる方式を証明書チェーンと呼ぶのです。なお、証明書２は中間の橋渡しをする証明書なので中間証明書と呼ばれたりします。今回はルートCA証明書と中間証明書の解説をしました。次回は、この続きで証明書の期限と無効化について解説します。－－－－－－－－今回登場した用語－－－－－－－－○プロトコル　コンピュータ間で何らかのデータのやりとりを行うための　通信手順のルールのこと。　元々は「外交辞令」という意味で、交渉相手とやりとりを　して課題を解決するというところから転じてコンピュータ　間でのデータのやりとりをする方法を示すようになった。　プロトコルは一種類ではなく、その目的に応じて専用の手　順を用いる。例えば、インターネット上のWebページの転送　にはHTTP(Hyper Text Transfer Protocol)を、メール転送　にはSMTP(Simple Mail Transfer Protocol)を、メールの　受信にはPOP3(Post Office Protocol version 3)やIMAP　(Internet Message Access Protocol)を、という風に、　目的に応じて様々なプロトコルを使い分ける。

このhttpsシリーズは今回で８回目、予想通り恐ろしく長い連載になっています。今回は前回に続き、電子証明書の話を続けます。1. 証明機関ってナニ？－－－－－－－－－－－前回の解説で、証明機関というものが、証明書の正しさを証明すると書きました。ですが、そもそも証明機関って何なのでしょうか？証明機関というのは、証明書を発行し、その署名が正しいことを保証する組識です。「内容が正しい」ではなく「署名が正しい」であることに注意してください。つまり、データ部の改竄（かいざん）が行われていないことを証明しているに過ぎません。証明機関の多くは普通の会社です。全能の神様ではありませんから、証明書の発行依頼元に悪意があるかどうかなんてわかりようがありません。ですので、多少の審査は行いますが、基本的には申請されたデータを元に署名をして証明書を発行します。ここで言う署名は前回お話したように、データ部のハッシュ値（文末参照）を計算し、その結果を証明機関の秘密鍵で暗号化したものを指します。このようにして発行された証明書は、署名を公開鍵で復号し、ハッシュ値を再計算すれば検算ができます。検算結果が合致していれば、データ部が改竄（かいざん）されていないと言い切れます。何度も書きますが、証明機関が保証してくれるのは、「署名が正しい点」だけです。内容が正しいことを証明してくれるわけではありません。仮に悪意のある組織が認証機関に電子証明書の発行を依頼してきたとしても、証明機関は原則として証明書の発行を行います。httpsでは、電子証明書を必ず使いますが、だからといって接続先が悪意のない優良サイトだとは言い切れないのです。2. 署名が正しいってことは？－－－－－－－－－－－－－－では、署名が正しいと何が嬉しいのでしょうか？署名が正しければ、データ部が無変更だと言い切れます。データ部を変更すると、署名に使うハッシュ値の内容がまるで違うものになるからですね。電子証明書のデータ部はhttpsでの最初のやりとりでも使います。ここでの目的は次の２つです。　１）サーバの公開鍵を利用者に渡す　２）サーバが正当であることの確認（これ以外にもいろいろありますが話が発散するので略します）一つ目の「公開鍵」は、それ以降の暗号化の手続きで必要となります。この使い方については、httpsのプロトコル解説で説明します。（数回後になる予定です）二つ目の「サーバの正当さの確認」には、データ部に入っている、組織名やURLを使います。この組織名やURLが接続しようとしているサイトと一致していれば、その証明書は正しいと言えます。だから、アクセスしても安心だと言えるわけです。なお、ここでの電子証明書は、サーバの正しさを証明するものですので特に「サーバ証明書」と呼びます。3. それなら悪用もできるのでは？－－－－－－－－－－－－－－－－でも、サーバ証明書はそのサイトを使えば、誰でも入手できます。悪意のある人が、まるで自分の証明書であるかのようにそれをコピーして使うことはできるのでしょうか？使うことはできます。ですが、すぐにバレます。どのブラウザでも、httpsで接続する時は証明書の内容を確認します。問題のあるサーバ証明書を使っている時は例えば次のようなエラーメッセージが表示されます。見たことがある！という方もおられるのではないでしょうか。　・他のサイトの証明書です。　・証明書の有効期限が過ぎています。　・信頼できない認証局の署名がなされた証明書です。これらはいずれも証明書がおかしい時に表示されます。上記のようにヨソの証明書をコピーして使った場合は「他のサイトの証明書です」と出ます。これは、証明書のデータ部にあるURLと実際のサイトのURLが違っているためです。URLまで同じにすると、通常の利用者はホンモノのURLにアクセスし、悪意のあるサイトに来てくれません。では、サーバ証明書をどこかの認証機関に発行してもらって、それを使えばどうでしょうか？実はこの方法だと悪意のあるサイトであっても正しいサイトと扱われます。証明書は最初に書いたように「内容の正しさ」を証明するのではないからです。これを技術的に防ぐことは難しいのです。httpsだからといって常に安心と考えてはいけないのです。マルウェア対策ソフト（特にインターネットセキュリティと銘打たれたもの）であればこのテの怪し気なサイトのアクセスでも警告をしてくれます。これも対策ソフト側で怪し気なサイトのリストを更新しているわけであって、人力である点は変わりません。まだ、証明書についてはもう少し解説すべき点があるのですが、今回はここまでとします。次回は、ルート証明書と中間証明書について解説を行います。

前回と前々回で、公開鍵暗号とはどんなものかというのを解説しました。そして、httpsでの暗号化というのは、この公開鍵暗号と共有鍵暗号を併用して行っているということも解説しました。さて、httpsというのは、http にsecure（＝安全性）を加えたものです。ですが、httpsの安全性というのは、何も暗号化だけを示すのではありません。現在の通信相手がホンモノであることを保証するというのもhttpsの大切な仕事です。実際、詐欺サイトの中にはホンモノにしか見えないサイトも少なくありません。見た目を信用できないとすれば、何を信じれば良いのでしょうか？今回から、それを支える仕組みである電子証明書の解説をします。1. 電子証明書とは？－－－－－－－－－－実はこの話は以前（2017年7月)にも解説しています。とはいえ、当時からこのメルマガを読んでおられる方は少ないですし、以前の記事には誤記に近い省略をしてしまったため、改めて解説をしたいと思います。電子証明書というのは、極めて偽造しづらい特殊なデータのことです。電子証明書はデジタルデータですので「電子」が最初につきます。また、電子証明書はそのデータの所有者が間違いないことを保証すものですので「証明書」と呼びます。我々は海外に行く時にパスポートを携帯します。パスポートを紛失すると大変です。ですが、パスポートを悪用して本人のフリをするのは意外に大変です。パスポートには写真が貼ってありますから、写真の提示を求められるとバレてしまいます。ですから、パスポートは素人では簡単に偽造できません。電子証明書の場合は写真の代わりに本人を証明するデータ（ID番号や公開鍵など)が入っています。ここで疑問に思われませんか？デジタルデータは簡単にコピーや変更ができます。偽造パスポートと違って特殊な技術も要りません。IDや公開鍵だけを入れ替えれば、簡単に偽造できそうなものです。「偽造しにくい」とはどういうことなのでしょう？2. 電子証明書の内部構造－－－－－－－－－－－－電子証明書には目的のデータ（ID番号や公開鍵）の他に「署名」と呼ばれるデータが組み込まれています。つまり、電子証明書はデータ部と署名部の二部構成で、この「署名」部の存在が電子証明書の偽造を極めて難しいものにしているのです。この署名部はいわゆるサインの意味ではなく、とある計算結果が入ります。その計算というのは、　１）データ部の内容をハッシュ関数で計算してハッシュ値を得る　２）そのハッシュ値を証明機関の秘密鍵で暗号化する（RSA方式)の二つを行うことです。ここで、ハッシュ関数、証明機関という聞き慣れないコトバが出てきました。ハッシュ関数については、この後で解説します。もう一つの証明機関については、証明書の正しさを保証するための第三者機関となります。実は「その第三者機関が正しいことは誰が証明するんだ？」と言われると非常に面倒な話になるのですが、それはまた次回に解説しますので、今はそういう組織があるんだということにしておいてください。さて、関数だなんてまた数学がらみの話っぽいですね。そうなんです。この署名というのも実は数学的な計算なんです。そうそう、今回は計算式は出てこないです。だったら安心ですね。（にっこり）このハッシュ関数というのは、元のデータに復雑な計算を行って、元のデータとはかけはなれたデータを得る計算方法のことです。さらにそれを秘密鍵で暗号化していますから、秘密鍵を持っていない限り、暗号化はできません。この２重の仕掛けがあるため、署名部の偽造は極めて難しいのです。3. ハッシュ関数－－－－－－－－ハッシュ関数というのはデータを（ルールに従って）かきまぜて複雑な計算をほどこすことです。計算ですので、同じデータを与えれば、必ず同じ結果になります。逆に１文字でも違っていれば、全く異なった値となるのが特徴です。代表的なハッシュ関数であるSHA1（シャーワンと読みます）で試してみましょう。まず、次の文をSHA1で計算してみます。「がんばりすぎないセキュリティはえがおIT研究所が提供する　メールマガジンです。」結果はこんな値になります。　fa9f0b174151a8e87f6af80f316d92a8be1b1a02次に、末尾を「。」から「．」に変えてみます。「がんばりすぎないセキュリティはえがおIT研究所が提供する　メールマガジンです．」すると、今度はこうなります。　2026467ced1c98ef4a5ca43d984a44c3e44f755d次に、途中に「、」を入れてみます。「がんばりすぎないセキュリティは、えがおIT研究所が提供する　メールマガジンです。」今度はこうです。　cc5b3899b4dba1cff80bd72172fd31f8fcbaa1a1どうでしょう。たった１文字しか変えていないのに、どれも全く似ても似つかない結果となっているのがわかります。データを少しでも変更すれば、署名は全く違った値になります。つまり、データだけを偽造するというのは極めて難しいことがわかると思います。もちろんデータと署名をどちらも変更すれば、辻妻の合うデータは作れます。ですが、それだと次に述べるように秘密鍵による暗号化ができません。4. 秘密鍵による暗号化－－－－－－－－－－－上記で得られたハッシュ値を次に秘密鍵で暗号化します。ここで「あれ？」と思った方はかなり鋭いです。前々回の公開鍵暗号の中では「公開鍵」で暗号化し、「秘密鍵」で復号する例を出していました。内容を秘密にしたい時にはこの方式を使います。ですが、ここでは「秘密鍵」で暗号化していますから、「公開鍵」を持つ人、つまり誰でもが復号できます。余談（※本筋からはズレるので、読み飛ばしてもらってＯＫです）　細かい話になりますが、上記の話はRSA方式に限ります。　つまり　　公開鍵で暗号化　→　秘密鍵で復号 も、　　秘密鍵で暗号化　→　公開鍵で復号 　もどちらもできる公開鍵暗号方式というのは意外に少数派です。　全ての公開鍵暗号方式ができるわけではありません。秘密にできない暗号化なんて意味あるのでしょうか？もちろん意味はあります。ここでは内容を秘密にするのが目的ではなく、証明機関がこの署名を計算したことを示すためなのです。つまり、秘密鍵を持っている証明機関しか署名はできませんから、署名が正しいということは確かに証明機関が署名したと言い切れるわけです。次回は、今回触れなかった証明機関についての解説をしたいと思います。