TLS(トランスポート層セキュリティ)とTLS 1.3ハンドシェイク

1. 概要

A. 定義および登場背景

TLS(Transport Layer Security、トランスポート層セキュリティ)とは、TCPのような信頼性のあるトランスポート層の上で、二つの通信主体の間に機密性・完全性・認証を提供する暗号プロトコルであり、かつてネットスケープが作ったSSL(Secure Sockets Layer)をIETFが標準化して発展させた規格である。要約すれば、TLSは「相手が本当にそのサーバであるか(認証)を公開鍵証明書で確認し、その過程で安全に共有したセッション鍵で以降のデータを暗号化(機密性)し、メッセージの改ざんを検出(完全性)する」ようにしてくれる、アプリケーションとトランスポート層の間のセキュリティ層である。今日、HTTPSの「S」、すなわちWeb・API・メール・VPNの暗号化は事実上すべてTLSの上で動作する。

TLSが登場した根本的な背景は、「インターネットの基盤プロトコルであるTCP/IPが平文(plaintext)伝送を前提として設計された」という点にある。初期のWebではログインパスワード・クレジットカード番号がそのままネットワークを流れ、中間者(man-in-the-middle)がパケットを傍受すればそのまま露出した。1994年にネットスケープがSSL 2.0を出したが設計上の欠陥が多く、まもなくSSL 3.0(1996)に置き換えられ、1999年にIETFがこれを基にTLS 1.0(RFC 2246)を標準化し、商標・ガバナンスを中立化した。その後TLS 1.1(2006)、TLS 1.2(2008、RFC 5246)を経て、10年ぶりにTLS 1.3(2018、RFC 8446)が制定された。1.3は単なるバージョンアップではなく、それまで蓄積された脆弱性(BEAST・POODLE・ダウングレード等)と遅いハンドシェイクを根本的に取り除いた再設計に近い。

B. 必要性

TLSの必要性は、セキュリティの三本柱である機密性・完全性・認証(CIAのうちC・Iと認証)で説明される。第一に、機密性は公開ネットワークでの盗聴を防ぐ。公衆Wi-Fiのように物理的に共有される媒体では、TLSなしにはセッションクッキー・認証トークンがそのまま窃取されアカウントが掌握される。第二に、完全性は中間者が応答本文や伝送中の金額を改ざんすることを検出する。第三に、認証は利用者が接続した相手が「本物のその銀行サーバ」であることを証明書で保証し、フィッシング・なりすましサーバへの接続を遮断する。

これに加えてTLSは、規制・コンプライアンスの基盤統制としても必要である。個人情報保護法・[[isms-p]]・PCI-DSSは伝送区間の暗号化を明示的に要求し、ブラウザ業界はHTTPサイトに「安全でない」警告を表示し、HTTP/2・HTTP/3をTLSの上でのみ許可することで、事実上の全面暗号化(HTTPS Everywhere)を強制してきた。韓国でも電子政府・金融サービスがTLS 1.2以上のみを許可し、脆弱なSSL 3.0/TLS 1.0を無効化するよう指針を示しており、TLSは選択ではなく基本前提となった。

C. 中核的な特徴

TLSの特徴は三つに圧縮される。第一はハイブリッド暗号構造であり、遅い公開鍵演算([[symmetric-asymmetric-encryption]]の非対称)はセッション鍵の合意・サーバ認証にのみ用い、実際の大量データは速い対称鍵(AES等)で暗号化する[[digital-envelope]]式の結合をとる。第二は交渉(negotiation)に基づく柔軟性であり、ハンドシェイクで双方が共通して対応するバージョン・暗号スイート(cipher suite)・鍵交換方式を選んで合わせるため、老朽化したアルゴリズムは交換が可能である。第三は層独立性であり、TLSはHTTP・SMTP・IMAP等の上位プロトコルと無関係に動作し、一つのセキュリティ層で多様な応用を保護する。この三つの特徴が結合してTLSは「交渉で柔軟に、ハイブリッドで効率的に、層分離で汎用的に」機能するインターネットセキュリティの事実上の標準となっている。

2. TLSの全体構造と構成要素

TLSは単一の手続きではなく、下位のRecord Protocol(すべてのデータを暗号化・断片化して運ぶ運搬層)と、その上で動作する上位サブプロトコル(Handshake・Alert・ChangeCipherSpec・Application Data)から成る階層的構造として理解すべきである。以下はTLSのプロトコルスタックと構成要素間の関係を示した全体構造図である。

flowchart TB
  subgraph APP["アプリケーション層"]
    HTTP["HTTP/SMTP/IMAP等"]
  end
  subgraph TLS["TLS層"]
    subgraph SUB["上位サブプロトコル"]
      HS["Handshake(鍵合意·認証)"]
      AL["Alert(警報·終了)"]
      AD["Application Data(暗号化伝送)"]
    end
    REC["Record Protocol(断片化·圧縮·MAC·暗号化)"]
    SUB --> REC
  end
  subgraph NET["トランスポート·ネットワーク層"]
    TCP["TCP(信頼性伝送)"]
    IP["IP"]
  end
  HTTP --> HS
  HTTP --> AD
  REC --> TCP --> IP

この構造の核心は、Record Protocolがすべての上位メッセージをレコード単位に分割し、順序番号・認証タグとともに暗号化するという点である。ハンドシェイクメッセージすら、鍵が合意された以降はレコード層で暗号化されて伝達され、応用データも同じレコード形式で保護される。すなわちHandshakeは「どの鍵で保護するかを合意する制御プレーン」、Recordは「実際の保護を執行するデータプレーン」として役割が分離されている。

A. Record Protocol — データプレーン

Record Protocolは上位から降りてきたバイトストリームを一定サイズ(最大2^14バイト)のレコードに断片化し、各レコードに順序番号を含む認証・暗号化を適用した後TCPへ降ろす。TLS 1.2までは「MAC-then-Encrypt」の組み合わせとAEADが混在したが、TLS 1.3はAEAD(Authenticated Encryption with Associated Data)のみを許可し、機密性と完全性を一つの演算で同時に保証する。AEADは暗号化と認証タグ生成を一つのアルゴリズム(AES-GCM、ChaCha20-Poly1305)に束ね、過去のパディング・MAC処理順序の微妙な差を悪用した攻撃(POODLE・Lucky13)の余地を除去した。

実務的にRecord Protocolの設計は性能に直結する。レコードが大きすぎると最初のバイト到達までの遅延が大きくなり、小さすぎるとヘッダ・タグのオーバーヘッドが増える。そこでCDN・Webサーバは初期に小さなレコードで素早く最初の画面を表示し、徐々にレコードを大きくする「レコードサイズ適応」の技法を用いる。例えばネットフリックス・グーグルは動的レコードサイジングで映像ストリーミングの体感遅延を下げる。

さらに、レコードごとに付くAEAD認証タグ(AES-GCMの場合16バイト)とレコードヘッダは、小さなメッセージが多い通信で相対的オーバーヘッドが大きくなる。例えば数十バイトのIoTセンサーデータをレコードごとに個別伝送すると、タグ・ヘッダの比重が本文を超えうるため、制約された組込み環境ではメッセージを束ねて送るか軽量プロファイルを用いる等の設計考慮が必要である。このようにRecord層のパラメータ選択は、帯域幅・遅延・電力という非機能要求と絡んで決定される。

B. Handshake Protocol — 制御プレーン

Handshake Protocolは、バージョン・暗号スイート交渉、鍵交換、サーバ(必要時クライアント)認証、セッション鍵導出を担当するTLSの心臓である。TLS 1.3ではこの過程が大幅に単純化され、1-RTT(往復1回)で終わる。以下の詳細図で段階ごとに説明する。残りのサブプロトコルであるAlertはエラー・セッション終了通知(例:close_notify)を、ChangeCipherSpecはTLS 1.2まで暗号切替信号を担当したが、TLS 1.3では互換性目的のダミーとしてのみ残った。

暗号スイート(cipher suite)の名称表記も二つのバージョンで意味が変わったという点が実務的に重要である。TLS 1.2のTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256は「鍵交換(ECDHE)+認証(RSA)+対称暗号(AES-128-GCM)+ハッシュ(SHA256)」を一つの文字列にすべて詰め込み、組み合わせの数が爆発し、そのうち脆弱な組み合わせが紛れ込む余地が大きかった。これに対しTLS 1.3は鍵交換・認証を暗号スイートから分離し、supported_groups・signature_algorithms拡張で別途交渉し、暗号スイート文字列にはTLS_AES_128_GCM_SHA256のようにAEADアルゴリズムとハッシュのみを残した。この分離のおかげで交渉される組み合わせが単純化され、「安全なデフォルト」から外れにくくなった。

3. TLS 1.3ハンドシェイクの手続き

TLS 1.3ハンドシェイクの最大の革新は、クライアントが最初のメッセージで直ちに鍵交換材料(key_share)を一緒に送ることで、TLS 1.2の2-RTTを1-RTTに縮めた点である。以下は典型的な1-RTTフルハンドシェイクの詳細な流れ図である。

sequenceDiagram
  participant C as "クライアント"
  participant S as "サーバ"
  C->>S: ClientHello(対応バージョン·cipher suites·supported_groups·key_share)
  Note over S: 共通パラメータ選択 + 自身のkey_share生成
  S->>C: ServerHello(選択cipher·key_share)
  Note over C,S: ECDHE共有秘密を算出 → HKDFでハンドシェイク鍵を導出
  S->>C: {EncryptedExtensions · Certificate · CertificateVerify · Finished}
  Note over C: 証明書チェーン検証 + CertificateVerify署名確認
  C->>S: {Finished} (+ 任意のクライアント証明書)
  Note over C,S: アプリケーショントラフィック鍵の導出完了
  C->>S: Application Data(暗号化)
  S->>C: Application Data(暗号化)

A. ClientHelloとServerHello — 交渉の始まり

ハンドシェイクはクライアントがClientHelloを送って始まる。ここには対応可能なTLSバージョンの一覧、好む暗号スイート(cipher suite)の一覧、鍵交換に使う楕円曲線グループ(supported_groups、例:X25519・secp256r1)、そしてそのグループに対する公開鍵材料(key_share)が含まれる。TLS 1.2ではサーバ応答を受けてから鍵材料を交換したが、1.3ではクライアントが「この曲線を使うと仮定して」あらかじめ材料を投げることで往復を一つ減らす。

鍵交換材料のほかにも、ClientHelloには複数の拡張(extension)が載る。そのうちSNI(Server Name Indication)は、一つのIP・ポートで多数のドメインをホスティングする仮想ホスティング環境で「どのドメインの証明書をよこせ」と知らせる必須拡張であり、ALPN(Application-Layer Protocol Negotiation)はHTTP/2・HTTP/3のような上位プロトコルをハンドシェイク段階であらかじめ合意し、追加の往復をなくす。問題はSNIが平文で露出し、「どのサイトに接続するか」が盗聴者・検閲装置にそのまま見えるという点であり、後述するECHがまさにこの最後の平文メタデータを暗号化しようとする試みである。

サーバはServerHelloで応答し、受け取った一覧のうち共通して対応するバージョン・暗号スイートを一つずつ確定し、自身のkey_shareを返す。もしクライアントが送ったグループをサーバが対応していなければ、HelloRetryRequestで別のグループを指定してもう一度往復するが、ほとんどの現代クライアントはX25519を既定で送るためこの再交渉はまれである。この段階でバージョンダウングレード防御が重要であり、TLS 1.3はServerHelloの乱数(random)末尾に特定の定数を埋め込み、「私は上位バージョンに対応するが下位へ引き下げられた」という事実をFinished段階で検出するよう設計され、過去のFREAK・Logjamのような強制ダウングレード攻撃を遮断する。

B. 鍵交換と鍵導出 — ECDHEとHKDF

TLS 1.3は鍵交換方式をECDHE(楕円曲線ディフィー・ヘルマン、Ephemeral)のような(EC)DHE系に事実上単一化し、過去の静的RSA鍵交換を完全に廃止した。これが1.3の最も重要なセキュリティ改善の一つである。静的RSA方式ではサーバの秘密鍵一つが漏洩するだけで、過去に収集しておいたすべてのトラフィックを遡及的に復号できた。これに対しECDHEはセッションごとに使い捨ての鍵ペアを生成して破棄するため、前方秘匿性(PFS、Perfect Forward Secrecy)が保証され、サーバ秘密鍵が将来漏洩しても過去のセッションは安全である。

双方は相手のkey_shareと自身の秘密を組み合わせて同一の共有秘密(shared secret)を算出した後、それをそのまま使わずHKDF(HMACに基づく鍵導出関数)に通して用途別の鍵(ハンドシェイク鍵、アプリケーショントラフィック鍵、再開用PSK等)を段階的に派生させる。HKDFは「抽出(extract)」と「拡張(expand)」の二段階でエントロピーを正規化し、ラベル別に鍵を分離して、一つの鍵が露出しても他用途の鍵に波及しないようにする鍵分離(key separation)の原則を実装する。ハンドシェイクの相当部分がこのハンドシェイク鍵で早期に暗号化されることも1.3の特徴であり、サーバ証明書まで暗号化されて盗聴者へのメタデータ露出が減る。

C. 証明書検証とFinished — 信頼の確定

サーバはCertificate(X.509証明書チェーン)とCertificateVerifyを送る。CertificateVerifyはサーバがこれまでのハンドシェイク全体に対して自身の秘密鍵で署名した値であり、クライアントはこの署名を証明書の公開鍵で検証することで、「証明書を提示した相手がその秘密鍵を実際に保有する本物のサーバ」であることを確認する。クライアントは証明書チェーンを信頼ルート([[pki]]のRoot CA)まで遡って検証し、ドメイン名(SAN)の一致・有効期間・失効有無(OCSP/CRL)を確認する。この検証が失敗したり緩かったりすると中間者攻撃が成立するため、モバイルアプリでは特定の証明書・公開鍵を固定する証明書ピンニング(certificate pinning)で防御を強化することもある。

証明書検証の実務的含意は決して軽くない。2011年に認証局DigiNotarが侵害され、グーグルドメインに対する偽造証明書が発行され、イランで数十万人のGmailトラフィックが中間者攻撃に露出した事件は、「TLSの信頼が結局CAエコシステム全体の健全性に懸かっている」という事実を刻み込んだ。この教訓から証明書透明性(Certificate Transparency、CT)ログが導入され、発行されたすべての証明書を公開ログに記録・監視することで不正発行を早期に検出できるようになった。すなわちTLSの認証信頼はプロトコルの一点ではなく、CA・CT・ブラウザのルートストアが共に支えるエコシステム的信頼であると理解すべきである。

最後に双方はFinishedメッセージを交換する。Finishedはこれまで送受信したすべてのハンドシェイクメッセージのハッシュに対するMACであり、交渉過程が途中で改ざんされていないことを相互に確証する。この時点以降、アプリケーショントラフィック鍵が活性化され、実際のデータが暗号化されて流れる。サーバがクライアントも認証すべき相互認証(mTLS)環境では、サーバがCertificateRequestを送り、クライアントが自身の証明書とCertificateVerifyを追加で提示するが、これは[[zero-trust]]アーキテクチャのサービス間認証で中核的に用いられる。

D. セッション再開と0-RTT — 性能最適化

TLS 1.3は一度ハンドシェイクした相手と再接続する際に全過程を繰り返さないよう、PSK(Pre-Shared Key)に基づくセッション再開を提供する。最初の接続後にサーバが発行した再開用チケット(NewSessionTicket)をクライアントが保管し、次の接続時に提示すると非対称演算なしに素早くセッションを復元する。さらに0-RTT(Zero Round-Trip Time)は、クライアントが再接続時にClientHelloに実際のアプリケーションデータを一緒に載せて送り、往復遅延を事実上0にする。

ただし0-RTTには本質的な危険がある。0-RTTで送った初期データは再送(replay)攻撃に脆弱であり、攻撃者が同じ要求を再生するとサーバが重複処理しうる。したがって0-RTTは照会(GET)のような冪等([[idempotency]])な要求にのみ許可し、決済・状態変更のような非冪等要求には適用しないようサーバが統制すべきである。これは「遅延短縮」と「再送安全性」が相反する典型的なトレードオフであり、CDN・大型サービスは0-RTTを選択的にのみ有効化する。

4. TLS 1.2とTLS 1.3の比較

二つのバージョンの違いを「なぜそう変わったのか」の観点で見れば、1.3は「安全でない選択肢をそもそも除去する」方向で設計された。1.2は数十種の暗号スイートとRSA・DHE・ECDHE・静的/動的鍵交換をすべて許可して柔軟だったが、その柔軟性がすなわち「脆弱な組み合わせを選びうる余地」となり、ダウングレード・弱い暗号攻撃の温床となった。1.3は暗号スイートをAEAD 5種程度に大幅縮小し、鍵交換を(EC)DHEに限定し、再交渉・圧縮を除去することで、設定ミスそのものが不可能になるよう「安全なデフォルト」を強制した。

区分	TLS 1.2	TLS 1.3
ハンドシェイク往復	2-RTT	1-RTT(再開時0-RTT)
鍵交換	RSA·DHE·ECDHE(静的RSA許可)	(EC)DHEのみ — PFS強制
対称暗号	CBC(MAC-then-Encrypt)·AEAD混在	AEAD専用(GCM·ChaCha20)
暗号スイート数	数十種(脆弱な組み合わせ多数)	5種程度に縮小
再交渉/圧縮	許可(攻撃面)	除去
ハンドシェイク暗号化	平文が多数(証明書露出)	早期暗号化(証明書保護)

性能面の実務的含意は明確である。1-RTTに縮まったハンドシェイクは、モバイル・高遅延環境で体感応答速度を大きく改善する。例えば往復遅延が100msのモバイル回線で一度の往復を減らせば最初の接続ごとに100msが節約され、多数のリソースを読み込むWebページではこの効果が累積する。実際にグーグル・クラウドフレアはTLS 1.3への移行後にハンドシェイク遅延が半分程度に減ったと報告した。セキュリティ面でもPFS強制・弱い暗号除去で事故面が構造的に縮小された。

とはいえ移行には現実的な制約も伴う。企業環境にはTLSを終端・検査する中間装置(ミドルボックス)が多く、これらが1.3を正しく認識できずハンドシェイクを壊す「プロトコル硬直化(ossification)」の問題が現れた。TLS 1.3がChangeCipherSpecのダミーレコードを残し、バージョン表記を拡張(supported_versions)に移したのも、旧式ミドルボックスにパケットを「1.2のように」見せて互換性を確保しようとする設計だった。また金融業界のように静的RSAに基づく受動的復号でトラフィックを監査していた組織は、PFS強制でその方式が不可能になり、監査アーキテクチャを端点エージェントやTLS終端プロキシ基盤へ再設計せざるを得なかった。これはセキュリティ改善が運用慣行の変更を強制した代表的な事例である。

5. 深化 — 主要な攻撃と最新動向

TLSの歴史はすなわち攻撃と防御の歴史である。ダウングレード攻撃(FREAK・Logjam)は交渉過程を操作して弱い輸出用暗号へ引き下げる技法であり、POODLEはSSL 3.0のCBCパディング処理の欠陥を、BEASTはTLS 1.0のCBC IVの予測可能性を悪用した。2014年のHeartbleedはTLSプロトコル自体ではなくOpenSSLのHeartbeat拡張の実装バグ(境界検査の欠落)でサーバメモリが漏洩した事件であり、「プロトコルが安全でも実装が間違っていれば致命的」という教訓を残した。TLS 1.3はこれらのうちプロトコルレベルで防げるもの(CBC・再交渉・圧縮・ダウングレード)を設計で除去し、Heartbleed類の実装欠陥はライブラリパッチ・メモリ安全言語(Rustベースのrustls等)の採用で対応する流れである。

一方、ハンドシェイクの平文特性を逆利用したTLSフィンガープリンティング(JA3/JA3S)も実務で活発に用いられる。ClientHelloに載る拡張の一覧・順序・暗号スイートの組み合わせは実装体ごとに固有のパターンを持つため、これをハッシュ化すればトラフィックが暗号化されていても「この接続が正常なブラウザか、既知のマルウェア/ボットか」を識別できる。セキュリティ監視・ボット遮断ではこれを検出信号として活用し、逆に攻撃者は正常なブラウザを模倣(fingerprint spoofing)して検出を回避しようとする。これは「暗号化が内容は隠してもメタデータのパターンは残す」という点を示す代表的な事例であり、ECHが志向するメタデータ保護の必要性を逆説的に裏付ける。

最新動向で最も注目すべきは量子耐性暗号(PQC)への移行である。大規模量子コンピュータはECDHEが依拠する離散対数問題を破りうるため、「今収集しておいて後で復号(Harvest Now, Decrypt Later)」する脅威が現実化している。これに対しグーグル・クラウドフレアは2023〜2024年から既存のX25519と格子ベースのアルゴリズムを結合したハイブリッド鍵交換(X25519+ML-KEM、旧Kyber)をクローム・エッジのトラフィックに大規模適用し始めた([[post-quantum-crypto]]参照)。またClientHelloのSNI(接続ドメイン)まで暗号化するECH(Encrypted Client Hello)が標準化・配備され接続メタデータのプライバシーを強化しており、UDPベースの[[quic-http3]]はTLS 1.3ハンドシェイクをトランスポート層に内在化して接続確立をさらに短縮した。mTLSは[[zero-trust]]・サービスメッシュの既定の通信セキュリティとして定着した。

6. 考慮事項および示唆点

TLSを技術士の観点で設計・運用する際に考慮すべき事項は次のとおりである。

適用戦略(安全なデフォルトの強制): 新規システムはTLS 1.3を既定とし、1.2を下位互換としてのみ残し、SSL 3.0・TLS 1.0/1.1とCBC・RC4等の脆弱な暗号スイートは全面無効化する。サーバ設定は推測ではなくMozilla SSL Configuration Generator・SSL Labsのような検証ツールで「Aグレード」を目標指標として標準化し、HSTSヘッダで平文接続そのものを禁止する。
トレードオフ(性能対安全性): 0-RTTは遅延を劇的に減らすが再送の危険を伴うため、冪等な要求にのみ許可し非冪等なAPIには無効化する選別方針が必要である。同様に、セッション再開チケットの寿命・鍵回転周期は「再接続性能」と「PFS弱化の危険」の間で均衡を取らねばならず、チケット暗号化鍵(STEK)を定期的に交換しなければ再開区間の前方秘匿性が損なわれる。
実装・運用セキュリティ(証明書の寿命周期): TLS事故の相当数はプロトコルではなく期限切れ証明書、弱い秘密鍵の保管、緩いチェーン検証から生じる。証明書はACME(Let's Encrypt)で自動発行・更新して期限切れ事故を根本的に遮断し、秘密鍵はHSM/KMSに保管し、内部のサービス間通信には短い寿命の証明書を自動循環(SPIFFE/SPIRE等)する体系を備える。実装欠陥(Heartbleed類)に備えてライブラリのCVEを常時追跡・パッチする。
可視性と規制の衝突(復号運用): 全面暗号化はプライバシーを高めるが、セキュリティ監視([[siem]]・IDS)や障害分析でトラフィックの可視性を下げる。したがって組織は境界でのTLS終端(termination)・再暗号化地点を設計し、復号範囲を個人情報・規制と衝突しないよう最小化し、復号鍵・ログのアクセス統制を厳格にすべきである。可視性の確保とプライバシー保護を同時に設計することが核心である。
展望および連携技術(量子移行ロードマップ): 「Harvest Now, Decrypt Later」の脅威に対応し、長期の機密性が要求されるデータ(医療・国家機密)から優先してハイブリッドPQC鍵交換へ先制的に移行する暗号俊敏性(crypto-agility)のロードマップを策定すべきである。アルゴリズムを設定で容易に交換できるよう抽象化し、証明書・ライブラリのPQC対応状況を定期点検するガバナンスが今後10年の核心課題となる。

参考資料

IETF, "RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3": https://datatracker.ietf.org/doc/html/rfc8446
IETF, "RFC 5246: The TLS Protocol Version 1.2": https://datatracker.ietf.org/doc/html/rfc5246
Cloudflare, "A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)": https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/
Mozilla, "Security/Server Side TLS": https://wiki.mozilla.org/Security/Server_Side_TLS
Cloudflare, "The TLS Post-Quantum Experiment": https://blog.cloudflare.com/post-quantum-for-all/

一言まとめ: TLSはTCPの上でハイブリッド暗号により機密性・完全性・認証を提供するインターネットセキュリティの事実上の標準であり、TLS 1.3はハンドシェイクを1-RTTに縮め(EC)DHE・AEADのみを残して前方秘匿性を強制する再設計で安全性と性能を同時に高めたが、今や課題は0-RTT再送の統制・証明書の寿命周期自動化・量子耐性暗号への移行である。