午前I問題
インターネット通信の暗号化に関する記述として、適切なものはどれか。
ア)TLSはトランスポート層で動作するプロトコルであり、TCP/UDPの両方を暗号化する。
イ)TLSはアプリケーション層とトランスポート層の間に位置し、通信の機密性・完全性・サーバ認証(および必要に応じてクライアント認証)を提供する。
ウ)SSLとTLSは現在も同時に併用されており、両者に脆弱性の差はない。
エ)TLSハンドシェイクでは、常に共通鍵暗号方式のみを用いて鍵交換が行われる。
午前I の解答・解説を見る
正解: イ
解説:
- ア)不正解。TLSはTCP上で動作するプロトコルであり、UDPを直接暗号化するものではありません(UDP向けにはDTLSという別プロトコルが存在します)。
- イ)正解。TLSはアプリケーション層(HTTP等)とトランスポート層(TCP)の間に位置し、通信の機密性(暗号化)・完全性(改ざん検知)・サーバ認証(証明書によるなりすまし防止)を提供します。相互TLS(mTLS)ではクライアント認証も行われます。
- ウ)不正解。SSLは既知の脆弱性(POODLE等)により危殆化しており、SSL 2.0/3.0は使用が禁止されています。TLS 1.0/1.1も非推奨化され、現在はTLS 1.2/1.3の利用が推奨されています。両者に脆弱性の差がないという記述は誤りです。
- エ)不正解。TLSハンドシェイクでは公開鍵暗号方式(RSAやECDHE等の鍵交換アルゴリズム)を用いてセッション鍵(共通鍵)を安全に共有し、その後のデータ通信では共通鍵暗号方式(AES等)を用います。鍵交換自体を共通鍵暗号のみで行うわけではありません。
午前II問題
TLS 1.3のハンドシェイクに関する記述のうち、適切なものはどれか。
ア)TLS 1.3ではTLS 1.2と同様に、鍵交換アルゴリズムとしてRSA鍵交換(静的RSA)が引き続き主要な選択肢として提供されており、Forward Secrecyの有無を運用者が選択できる。
イ)TLS 1.3では、ClientHelloの時点でクライアントが推測した鍵共有パラメータをサーバに送ることで、フルハンドシェイクを1-RTT(1往復)で完了できるようになった。
ウ)TLS 1.3の0-RTT(Zero Round Trip Time Resumption)は、以前の接続で確立したセッション情報を用いて、ハンドシェイクの往復なしにアプリケーションデータを送信できる機能であり、リプレイ攻撃への耐性を持つデータにのみ使用すべきである。
エ)TLS 1.3では暗号スイートの下位互換性を重視し、AES-CBCモードやRC4などTLS 1.2で利用可能だった全ての暗号アルゴリズムが引き続きサポートされている。
午前II の解答・解説を見る
正解: イ、ウ(本問では最も適切なものとしてウを選択)
解説:
- ア)不正解。TLS 1.3では静的RSA鍵交換が廃止されました。TLS 1.3の鍵交換はECDHE(楕円曲線Diffie-Hellman鍵共有)に一本化され、常にForward Secrecy(前方秘匿性)が確保される設計になっています。
- イ)内容自体は概ね正しい記述です。TLS 1.3ではClientHelloの段階でクライアントが鍵共有に使う楕円曲線パラメータ(key_share拡張)を推測して送信し、サーバがそれに応答することで、TLS 1.2で必要だった2-RTTから1-RTTへと短縮されました。
- ウ)正解。0-RTTは以前確立したセッションのPSK(Pre-Shared Key)を利用し、ハンドシェイクの往復を待たずに最初のフライトでアプリケーションデータを送信できる機能です。ただし0-RTTデータはリプレイ攻撃(同じ暗号化データを攻撃者が再送する攻撃)に対する保護がないため、決済処理や状態変更を伴うリクエストなど「再送されると害があるデータ」には使用すべきでなく、べき等(Idempotent)な操作に限定して使うべきとされています。
- エ)不正解。TLS 1.3では安全性の低い暗号アルゴリズム(RC4、CBCモードを含む多くの暗号スイート、SHA-1等)が廃止され、AEAD暗号(AES-GCM、ChaCha20-Poly1305等)のみがサポートされるようになりました。下位互換性よりも安全性が優先された設計です。
| 項目 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| ハンドシェイク往復数 | 2-RTT | 1-RTT(再開時は0-RTTも可) |
| 鍵交換 | RSA/DHE/ECDHE選択可 | ECDHE(DHEの一部)に一本化。RSA鍵交換廃止 |
| Forward Secrecy | 選択次第(RSA鍵交換では非対応) | 常に確保 |
| 暗号スイート | CBC・RC4等含む多数 | AEAD(GCM/ChaCha20-Poly1305)のみ |
午後問題
J社は自社ECサイトのAPIサーバでTLS 1.3への全面移行を計画している。パフォーマンス改善チームから「0-RTTを有効化すればリピーターのページ表示速度がさらに向上する」という提案があり、セキュリティ担当K氏がレビューを行うことになった。
APIサーバでは以下のエンドポイントが提供されている。
GET /api/products:商品一覧の取得(副作用なし)POST /api/cart/add:カートへの商品追加(在庫数をデクリメントする副作用あり)POST /api/orders:注文確定・決済処理(金銭が動く副作用あり)
設問1
0-RTTを有効化した場合に生じうる攻撃シナリオを、リプレイ攻撃の観点から40字以内で具体的に説明せよ。
設問1の解答・解説を見る
正解例: 攻撃者が0-RTTの暗号化データを傍受・複製して再送すると、サーバは正規リクエストとして再処理してしまう。
解説: 0-RTTデータはPSK(以前のセッションから導出した鍵)を用いて暗号化されますが、TLSプロトコル自体には送信済みの0-RTTデータが「一度きりである」ことを保証する仕組みがありません。そのため、ネットワーク経路上で0-RTTの暗号化データ(TCP/IPパケット)を攻撃者が傍受してそのまま複製・再送すると、サーバ側のTLS層はこれを正規の暗号文として復号し、アプリケーション層に渡してしまいます。結果として、同一のリクエストが意図せず複数回処理されてしまう「リプレイ攻撃」が成立します。
採点基準(10点):
- 「0-RTTデータを複製・再送されると正規データとして処理されてしまう」という仕組みの説明(10点)
設問2
上記3エンドポイントのうち、0-RTTを利用してよいエンドポイントと利用すべきでないエンドポイントをそれぞれ挙げ、判断基準を50字以内で述べよ。
設問2の解答・解説を見る
正解例(利用してよい): GET /api/products
正解例(利用すべきでない): POST /api/cart/add、POST /api/orders
正解例(判断基準): リクエストが複数回処理されても結果が変わらない「べき等な操作」にのみ0-RTTを利用し、状態を変更する副作用のある操作には利用すべきでない。
解説: 0-RTTはリプレイ攻撃への根本的な対策がプロトコルレベルでは提供されないため、「リプレイされても問題が生じない(べき等な)操作」に限定して利用するのが原則です。GET /api/productsは商品情報の取得のみで副作用がなく、複数回実行されても結果は変わらないためべき等であり0-RTTを利用しても実害はありません。一方、POST /api/cart/addは在庫数をデクリメントする副作用があるため、リプレイされるとカート内商品数の不整合や在庫の二重減算が発生する可能性があります。POST /api/ordersは決済処理を伴うため、リプレイされると二重課金・二重注文という金銭的被害に直結する重大な問題となります。これら副作用のあるエンドポイントには0-RTTを無効化するか、アプリケーション層でリプレイ検知(冪等性キー・トークンの導入等)を別途実装する必要があります。
採点基準(14点):
- 利用してよいエンドポイントの特定(
GET /api/products)(3点) - 利用すべきでないエンドポイントの特定(両方挙げて)(4点)
- 判断基準:「べき等性(副作用の有無)で判断する」という趣旨(7点)
重要キーワード
| 用語 | 説明 |
|---|---|
| TLS(Transport Layer Security) | トランスポート層の上で通信の機密性・完全性・認証を提供するプロトコル |
| ECDHE | TLS 1.3で鍵交換に用いられる楕円曲線Diffie-Hellman方式。Forward Secrecyを実現 |
| Forward Secrecy(前方秘匿性) | 長期鍵が漏えいしても過去のセッション鍵の安全性が保たれる性質 |
| 0-RTT(Zero Round Trip Time Resumption) | 以前のセッション情報を用いてハンドシェイク往復なしにデータ送信できる高速化機能 |
| リプレイ攻撃 | 正規の暗号化通信データを攻撃者が複製・再送し、意図しない再処理を引き起こす攻撃 |
| べき等性(Idempotency) | 同じ操作を複数回行っても結果が変わらない性質。0-RTT利用可否の判断基準となる |
まとめ
- 午前I視点: TLSの位置づけ(トランスポート層とアプリケーション層の間)と、SSLからTLSへの移行の背景(脆弱性対応)を理解しておく
- 午前II視点: TLS 1.3ではRSA鍵交換の廃止・ECDHEへの一本化・1-RTT化・AEAD暗号への統一という変更点を正確に押さえる
- 午後視点: 0-RTTのリプレイ攻撃リスクを説明できることと、「べき等な操作にのみ0-RTTを許可する」という実務的な適用基準を具体的なエンドポイント例とともに判断できることが重要