組み込み技術者向けTLS1.3基礎解説（後編）：IoTでTLS1.3を活用すべき3つの理由：IoTセキュリティ基礎解説（2/3 ページ）

3．前方秘匿性の徹底

　TLS1.3では、鍵共有に使用するアルゴリズムはDHE、ECDHEに限定されており、前編で紹介したDH、ECDHは非対応となっている。DHE、ECDHEの最後にある「E」は「Ephemeral（一時的な）」を意味しており、一定期間だけ有効な鍵ペアを使用したDH、ECDHを意味している。具体的には、セッション開始時に鍵共有を行う際、クライアントとサーバの双方で異なる鍵ペアを使用し、それらを使ってセッションで使用する共通鍵を導出する。通信が終わるときはこれらの鍵ペアとセッション鍵は廃棄し、次回セッションでは新しい鍵ペアを使用して鍵共有を行う。

　こうすると、仮にある時点の鍵ペアの秘密鍵が漏えいしたとしても、過去のセッションで通信した暗号文は解読することができない。このような性質のことを前方秘匿性（Forward secrecy）と呼ぶ（図1）。前方秘匿性の採用は鍵の危殆化への有効な対策になるが、通信毎に鍵共有が必要になるので、処理負荷が高まるのは避けられない。これに対しては鍵の生成タイミングを早めるなどの対策もあり、遅延が大きい通信の場合は鍵生成を並列に処理できることもあるので、通信時間全体への影響は一概には判断できない。性能面で支払うべきコストはあるが、より高い水準の安全性を確保するためには必要なコストと捉えるべきだろう。

図1　前方秘匿性（Forward secrecy）（クリックで拡大）

4．効率的で安全なハンドシェイク

　TLS1.3の最大の特徴は、ハンドシェイクが大きく変更されたことだ。アプリケーションデータの暗号化通信を開始するまでにハンドシェイクでやりとりするメッセージの往復回数をRTT（Round Trip Time）と言うが、TLS1.2のセッション開始時のハンドシェイク（フルハンドシェイク）はパラメータの合意／サーバ認証と鍵共有で2回の往復があるので2-RTTとされる。

　TLS1.3では、この往復を短縮し1-RTTで暗号化通信を開始できるようになった。2回が1回になったと言うと大したことはないように聞こえるが、基地局を経由するモバイルネットワークなどメッセージが相手に到達するまでの遅延が大きい場合、往復回数が半分になる影響は無視できない。図2を使ってシーケンスで流れを追ってみよう。

図2　TLS1.3のメッセージシーケンス例（クリックで拡大）

　TLS1.3のハンドシェイクは従来のシーケンスと同じくClientHelloで始まる。このときTLS1.2と異なり、鍵共有で使う一時的な公開鍵をClientHelloに乗せていきなり送ることができる。「暗号スイートが決まっていないのに鍵共有できるのか」という疑問が沸くが、

• クライアントは鍵共有アルゴリズムをあらかじめ選んで鍵ペアを生成する
• サーバでそのアルゴリズムが使えない場合HelloRetryRequestで差し戻してやり直す

という考え方で割り切っている。

　サーバは、ServerHelloに鍵共有用の公開鍵を乗せて返せば、直ちに一時的な共通鍵を計算できるようになり、次のメッセージから暗号化が可能になる。ServerHelloの後は、暗号化したEncryptedExtensionsで合意したパラメータを送り、CertificateやCertificateVerifyでサーバ認証に必要な証明書や署名の情報を送付する。

　最後にハンドシェイクの改ざん検知のためFinishedを送信する。サーバは必要であればこの直後から暗号化したアプリケーションデータを送信することもできる（0.5-RTT）。

　図2にはクライアントのリクエストから開始する典型的ケースを記載した。ServerHello後のメッセージは暗号化されているので、どのようなパラメータや署名が送信されているのかは第三者には分からなくなった。クライアントはサーバ認証のメッセージを受け取ると署名の検証を行うが、このとき認証に失敗した場合は自分のアプリケーションデータを送ることなく通信を遮断すればよい。検証に成功したらFinishedを送信し、クライアントもすぐにアプリケーションデータの送信を開始できる。