暗号化すれば全て安全？——鍵の向き・証明書の検証・TLS・鍵管理を午後の問われ方で読む｜支援士解説3の1

この記事の重要度：Sランク（午後で繰り返し主役になる最重要の分野）

この記事で分かること：

• 暗号化・ハッシュ・MAC・デジタル署名の目的と、鍵の向き（誰のどの鍵を使うか）

• サーバ証明書の検証で確かめる4点と、TLSのハンドシェイクで何を確かめているか

• 鍵の保管・移送・HSMについて、解答欄に書く「原因」と「対策」の型

シラバスとの対応：小項目3-1「暗号利用及び鍵管理」。ネットワーク上の装置でのTLSの終端は支援士解説3の5、パスワードの保存や証明書ピンニングなどの実装は支援士解説2の4、証拠のハッシュ値は支援士解説4の4で扱います。

暗号は、午後のさまざまな大問の土台です。暗号そのものが主題になる大問もあれば、認証、マルウェア、サプライチェーンの大問の中で「なぜ署名なのか」「なぜ証明書の検証が要るのか」と問われることもあります。

この記事では、何を守りたいのか（目的）と、誰がどの鍵を持つのか（鍵の向き）の二つを軸に整理します。この二つが分かれば、暗号化・署名・MAC・証明書・TLS・鍵管理の設問で、何を書けばよいかが決まります。

1. 暗号化だけで、全部は守れない

平文・暗号文・鍵・アルゴリズム

暗号化する前の情報を平文、暗号化した情報を暗号文と呼びます。平文は文章に限らず、画像、データベースの値、プログラムなどでも構いません。暗号文から元の情報を取り出す処理が復号です。

アルゴリズムは処理の方式、鍵はその処理に使う重要なパラメータです。同じ方式でも、鍵が違えば暗号化の結果は変わります。

安全性を「処理方法を誰にも教えないこと」だけへ依存させるのではなく、公開された方式を評価し、必要な鍵を適切に守る考え方が基本です。Base64のような符号化は、表現を変える処理であり、秘密の鍵による保護とは異なります。文字化けして見えるだけでは暗号化の証拠になりません。

まず、目的を分ける

申請ファイルを第三者に読ませたくないなら、機密性を守る暗号化が関係します。ファイルが書き換えられていないか確認したいなら、完全性の確認が必要です。誰が作成・送信したものか確かめたいなら、出所の確認も必要になります。

例えば、暗号化された振込データの一部を攻撃者に変更できるとします。暗号方式によっては、平文を読めなくても復号結果へ影響を与えられます。「読めない」と「変えられない」は別です。

改ざん検出には、MAC、デジタル署名、認証付き暗号などを目的に応じて使います。暗号化と改ざん検出を独自につぎはぎするのではなく、適切に設計された標準的な方式や実装を使います。

暗号化とアクセス制御も別

データベースの保存ファイルを暗号化しても、正規のアプリケーションが利用時に復号するなら、そのアプリケーションの権限を奪った人に情報を読まれる可能性があります。

端末のディスク暗号化も、電源を切った端末から記憶装置を取り外して読む攻撃への対策と、ログイン済み端末で動くマルウェアへの対策は同じではありません。

暗号化が有効に働く条件を明確にし、その外側を認証、アクセス制御、端末対策、ログなどで補います。

午後で暗号化の設問を読むときは、最初に「何を」「どこからどこまで」「誰から」守りたいのかを書き出します。通信の途中の第三者から守りたいのか、記憶装置を盗んだ人から守りたいのか、正規の管理者からも見えなくしたいのかで、答えが変わります。

2. 共通鍵暗号と公開鍵暗号——誰が何を持つか

共通鍵暗号は、同じ秘密を共有する

共通鍵暗号は、暗号化と復号に同じ鍵を使います。対称暗号とも呼ばれます。代表例はAESです。

一般に、共通鍵暗号は公開鍵暗号と比べて高速に処理できます。大量のデータや、常時流れる通信を保護する用途に向いています。

ここで困るのは、相手とどう安全に鍵を共有するかです。暗号化したファイルと鍵を、同じ誰でも読める場所に置いたら、保護の意味が薄れます。

人数が増える場合も条件を確認します。全員が互いに通信し、組ごとに異なる共通鍵を1つ共有する前提なら、n人の異なる鍵の数はn(n−1)/2個です。例えば6人なら15個です。これは特定のモデルの計算であり、実際のすべてのシステムがその個数の固定鍵を保管するわけではありません。

公開鍵暗号は、公開鍵と秘密鍵を使い分ける

公開鍵暗号では、対応する公開鍵と秘密鍵の組を使います。相手だけが読めるように送る場合、送信者は受信者の公開鍵で暗号化し、受信者が自分の秘密鍵で復号します。

ここで公開してよいのは公開鍵です。秘密鍵を相手へ送るのではありません。また、公開してよいことと、誰の鍵か確かめなくてよいことは別です。

公開鍵が攻撃者のものへすり替わっていれば、送信者は攻撃者が復号できるように暗号化してしまいます。そのために、後で説明する電子証明書などの仕組みが必要になります。

公開鍵を使う技術にも、役割の違いがある

RSAには暗号化の方式と署名の方式がありますが、実際には適切な符号化等を組み合わせた方式として使います。数学上の計算をそのまま業務の暗号へ流用するものではありません。

楕円曲線を使う技術でも、ECDHは鍵共有、ECDSAやEdDSAは署名に用います。DSAも署名の方式です。「公開鍵技術だから、どれもデータを暗号化できる」とまとめないようにします。

公開鍵と秘密鍵が一対であることを、「どちらの鍵でも同じように暗号化して、もう一方で復号する」と一般化するのも不適切です。特に署名を理解するときに、この混同を避けます。

代表的な方式の特徴

• AES：共通鍵暗号の代表。ブロック長は128ビットで、鍵長は128・192・256ビットから選ぶ。データを決まった長さのブロック単位で処理するブロック暗号

• ChaCha20：データを1ビット（1バイト）単位で順に暗号化するストリーム暗号。認証のPoly1305と組み合わせて、TLS 1.3でも使われる

• RSA：大きな数の素因数分解が難しいことを安全性の根拠にする公開鍵の方式

• 楕円曲線暗号：楕円曲線上の離散対数問題の難しさを根拠にする。RSAより短い鍵長で、同程度の安全性を得られる

共通鍵暗号の課題は、相手と鍵を安全に共有すること（鍵配送問題）です。公開鍵暗号の課題は、処理が重いことと、公開鍵が本当に相手のものかを確かめる必要があることです。この二つを組み合わせるのが、5節のハイブリッドな使い方です。

3. ハッシュとMAC——データの比較と、秘密を使った確認

ハッシュは、復号するためのものではない

暗号学的ハッシュ関数は、入力から一定長の値を計算する仕組みです。SHA-256なら出力は256ビットです。同じ入力を同じ関数へ与えれば、同じ値が出ます。

ただし、異なる入力が絶対に同じ値にならないわけではありません。入力の種類は出力の種類より多いので、同じ出力になる組合せ、つまり衝突は存在します。安全性として重要なのは、そのような組を現実的な計算量で見つけにくいことです。

区別したい性質は3つあります。

• 原像計算困難性：あるハッシュ値から、それに対応する入力を見つけにくいこと。

• 第二原像計算困難性：ある入力が与えられたとき、同じハッシュ値になる別の入力を見つけにくいこと。

• 衝突発見困難性：同じハッシュ値になる異なる入力の組を見つけにくいこと。

ハッシュは暗号文ではないので、復号鍵で元へ戻す処理はありません。ハッシュ関数は、任意の長さのデータを、決まった長さの値に要約する仕組みだと考えると分かりやすいでしょう。一方、入力候補が少なければ、候補を計算して照合できます。短いパスワードや取り得る値が限られた番号は、この点に注意が必要です。よく使われるパスワードの一覧からハッシュ値を計算して照合するのが辞書攻撃、ハッシュ値と元の値の対応をあらかじめ大量に計算して表にしておくのがレインボーテーブルです。ソルトを加えると、同じパスワードでも利用者ごとにハッシュ値が変わるので、作っておいた表が使えなくなります。

パスワード保存には、単に高速なSHA-256を1回計算するだけでなく、ソルトと、パスワード向けに計算コストを調整できる方式を使います。ソルトは同じパスワードが同じ保存値になりにくくするための値であり、秘密の暗号鍵とは役割が異なります。

ハッシュ値の使い道

• 改ざんの検出：保存しておいた値と、今のデータから計算した値を比べる。ただし、比べる値そのものを守る必要がある（次の項）

• パスワードの保存：パスワードそのものではなく、ソルトを加えてハッシュ化した値を保存する（支援士解説2の4）

• デジタル署名の前処理：多くの署名方式は、データのハッシュ値に対して署名を計算する（4節）

• 証拠の同一性の確認：調査のために複製したデータが、元と同じであることを示す（支援士解説4の4）

• ブロックチェーン：前のブロックのハッシュ値をつなぎ、改ざんを検出しやすくする（13節）

代表的なハッシュ関数はSHA-256などのSHA-2と、SHA-3です。MD5やSHA-1は衝突を見つける攻撃が知られており、改ざんの検出や署名に新しく使う方式ではありません。

ハッシュ値も一緒に差し替えられたらどうなるか

例えば、自治体が公開する申請様式にハッシュ値を添えたとします。受信側はダウンロードしたファイルの値を計算して照合できます。

ただ、攻撃者がファイルと掲載ハッシュ値の両方を変更できれば、照合が一致しても正しい配布物とは限りません。基準となるハッシュ値を、どう信頼するかが必要です。

MACは、共通の秘密を使って確認する

MACはMessage Authentication Code、メッセージ認証コードです。メッセージと秘密の共通鍵から確認用の値を作り、受信側も同じ鍵で確認します。ハッシュ関数を利用するHMAC、ブロック暗号を利用するCMACなどがあります。

適切な方式と鍵管理の下で、鍵を知らない第三者による改ざんや偽造の検出に使えます。ただし、鍵を持つ受信者も同じMACを生成できます。そのため、第三者に対して「この送信者だけが作った」と示す用途では、デジタル署名と性質が異なります。

また、正しいMACが付いた古いメッセージを、そのまま再送する攻撃は別問題です。メッセージ番号、時刻、有効期限、一度だけ使う値などを、認証されるデータへ含めて検証する設計が必要です。

4. デジタル署名——誰の秘密鍵で作り、誰の公開鍵で確かめるか

署名者の秘密鍵で作る

デジタル署名は、署名者の秘密鍵を使って生成し、対応する公開鍵で検証します。署名対象の変更の検出や、鍵の持主との対応の確認に使います。

例えば、自治体が公開する更新プログラムへ署名するなら、署名する側が自分の秘密鍵を管理し、受け取る側は対応する公開鍵で検証します。暗号化のように、受信者の公開鍵で署名するのではありません。

多くの署名方式ではハッシュ処理が関わりますが、署名方式ごとに処理は異なります。「ハッシュを秘密鍵で暗号化したもの」とだけ覚えると、ECDSAやEdDSAなどを正しく説明できなくなります。署名生成と署名検証という専用の処理として理解します。NIST FIPS 186-5、デジタル署名標準

大まかな流れは次のとおりです。

1. 署名者は、文書のハッシュ値を計算し、自分の秘密鍵を使う署名の処理で署名を作る

2. 文書と署名を送る

3. 検証者は、受け取った文書のハッシュ値を計算し、署名者の公開鍵を使う検証の処理で、署名と照らし合わせる

4. 一致すれば、文書が改ざんされていないことと、その秘密鍵の持ち主が署名したことを確かめられる

署名者の公開鍵が本当にその人のものかは、電子証明書で確かめます（7節）。また、証明書には有効期限があるので、長い年月の後でも署名を検証できるように、署名した時刻をタイムスタンプで証明する長期署名の仕組みもあります（電子署名の法的な扱いは支援士解説3の11）。

署名しても、本文は隠れない

署名だけを付けた文書は、通常、その内容を読むことができます。内容も隠したいなら暗号化が別に必要です。

また、有効な署名があるプログラムに脆弱性がないとは限りません。署名は、機能や安全性をすべて審査したという証明ではないからです。

否認防止にも、運用上の前提がある

デジタル署名は、署名者が関与したことを後から示す仕組みに利用できます。ただし、秘密鍵が複数人に共有されていたり、漏えいしていたりすれば、誰が操作したかという説明は弱くなります。

署名の検証だけで、本人の意思や法的な効力が無条件に確定するわけではありません。本人確認、鍵の管理、署名時点、記録保存、適用制度なども関わります。本稿では暗号技術としての働きを中心に扱います。

鍵の向きを並べて整理する

• 秘密に送りたい：受信者の公開鍵で暗号化し、受信者の秘密鍵で復号。

• 自分が署名したことを確認してほしい：署名者の秘密鍵で署名し、署名者の公開鍵で検証。

• MACで確認したい：生成側と確認側が同じ共通鍵を利用。

混乱したときは、「秘密にしている鍵を持つべき人は誰か」から考えると整理できます。

午後での問われ方

• 令和7年度秋期 午後問2：暗号資産の取引に使う署名鍵の管理を題材に、暗号技術の基礎がそのまま問われました。共通鍵を使って改ざんを検出する技術を答える空欄の答えは「メッセージ認証符号」です。

採点講評で指摘されたつまずき

• 令和7年度秋期 午後問2の設問3(2)の空欄aでは、「デジタル署名」と答えた受験者が多かったと指摘されています。共通鍵で作るのはMAC（メッセージ認証符号）、署名者の秘密鍵で作るのがデジタル署名です。

• 平成31年度春期 午後I問2では、デジタル署名で公開鍵と秘密鍵を取り違えた解答が散見されたと指摘されています。

記述の型

• 改ざんの検出だけでなく、誰が作ったかを第三者に示したい：「MACではなくデジタル署名を用いる」

• 鍵の向き：暗号化は「受信者の公開鍵」で行い、署名は「署名者の秘密鍵」で作る

• ハッシュ値も一緒に差し替えられる場合：「照合しても改ざんに気付けないので、ハッシュ値を別の経路で入手するか、署名を検証する」

• パスワードの保存：「ソルトを加えてハッシュ化し、ストレッチングを行う」（実装は支援士解説2の4）

5. ハイブリッド暗号と鍵共有——本文の保護と鍵の準備を分ける

本文は共通鍵、鍵の準備には公開鍵技術

公開鍵技術だけで大きなファイルを丸ごと暗号化するより、本文は共通鍵暗号で処理し、その鍵を安全に共有する部分へ公開鍵技術を使う構成が一般的です。これがハイブリッドな使い方です。

基本例として、送信側で作った共通鍵を受信者の公開鍵で暗号化し、本文の暗号文と一緒に渡す方式があります。受信側は秘密鍵で共通鍵を取り出し、本文を復号します。

ただし、すべての通信がこのように共通鍵そのものを送るわけではありません。

Diffie-Hellmanは、秘密をそのまま送らず共有する

Diffie-Hellman（DH）や楕円曲線を用いるECDHは、双方が自分の秘密の値と相手から受け取った公開情報を使い、共通する秘密を計算するための方式です。その秘密から、用途別の暗号鍵等を導出します。

一時的な鍵を使う方式はDHE、ECDHEなどと表されます。ただし、鍵共有だけでは、相手が本当に目的の相手かは確かめられません。認証されていない鍵共有では、中間者が双方との間に別々の通信を作る危険があります。署名・証明書や事前共有秘密等による認証を組み合わせます。たとえば、攻撃者が通信の間に入り、利用者とは攻撃者自身の鍵共有の値で、サーバとも別の値で鍵を共有すれば、双方の通信を復号して中継できてしまいます。TLSでは、サーバが鍵共有の値を含むやり取りに証明書の秘密鍵で署名し、クライアントがそれを検証することで、この中間者攻撃を防ぎます。

前方秘匿性は、過去の通信を守る性質

前方秘匿性は、後から長期の認証用秘密鍵が漏れても、記録されていた過去の通信を、それだけで復号できないようにする性質です。一時的な鍵共有情報を適切に使い、不要になった秘密を消すことなどが前提になります。

通信中の端末が侵害されて平文を読まれることや、その時点の通信鍵が奪われることまで防ぐものではありません。鍵を定期更新することと同義でもありません。

6. 暗号利用モード——AESだけでは、使い方が決まらない

ブロック暗号を長いデータへ適用する

AESは一定長のブロックを処理する暗号です。長いデータをどのように分割し、つなげ、必要な初期値等を与えるかを決めるのが、暗号利用モードです。

XORは、同じビットなら0、異なるビットなら1となる演算です。暗号のモードでは、データと計算結果を組み合わせるために使われます。

ECB——同じブロックが同じ結果になる

ECBは各ブロックを独立に暗号化します。同じ鍵の下では、同じ平文ブロックから同じ暗号文ブロックができます。

例えば、同じ定型項目が多数並ぶデータでは、繰返しの構造が暗号文にも現れます。鍵そのものを直ちに解読できるという意味ではありませんが、隠したい情報の特徴が漏れるため、一般的な機密データの暗号化をECBで安易に設計しません。

CBC——前の暗号文を次の処理へつなぐ

CBCでは、平文ブロックと前の暗号文ブロックをXORしてから暗号化します。最初のブロックにはIV、初期化ベクトルを使います。CBCのIVは、暗号化前に予測できないことが重要です。

CBCだけで改ざんを検出するわけではありません。末尾をブロック長に合わせるパディングの処理や、そのエラー応答などを通じて情報が漏れる実装も問題になります。「CBCなら強い」「CBCはすべて解読済み」と、方式名だけで一括りにしないようにします。

CFB・OFB・CTR——暗号の出力を平文と組み合わせる

CFBでは前の暗号文側の情報を、OFBでは暗号処理の出力を、次の処理へ戻して使います。CTRではカウンタ値等を暗号化して得た列を、平文とXORします。

ここでは、CBCのように平文をつないで暗号化する形との違いを押さえます。CTRなどで同じ鍵の下の鍵ストリームを再利用すると、複数の平文の関係が漏れる危険があります。カウンタの重複や巻戻りも考慮します。

これらのモードを使うだけでは、メッセージの改ざん検出は自動的には付きません。

GCM——暗号化と認証タグを組み合わせる

GCMは、関連データ付き認証暗号、AEADの方式です。AES-GCMのように使い、暗号化した本文に加えて、改ざん等の確認に用いる認証タグを生成します。暗号化せずに完全性だけを確認したい付加情報、AADも扱えます。NIST SP 800-38D、GCMの概要

例えば、本文は秘匿しつつ、暗号化せずに扱う識別情報も認証の対象へ含める、といった使い方です。AADは暗号化されないので、隠したい情報をそこへ入れないようにします。

特に重要なのは、同じ鍵でnonceを再利用しないことです。nonceは、その用途で使い回さないための値です。必ず秘密である必要はなく、必ず無作為でなければならないという一般則でもありません。方式が要求する一意性等を満たす必要があります。IETF RFC 5116、認証暗号のnonceの条件

認証タグの検証に失敗したデータは、正しい平文として処理してはいけません。タグを付ける側だけでなく、受信側が検証し、失敗時に利用を止めるところまでが対策です。

XTS——記憶装置向けの保護

XTSは、記憶装置のデータ単位を暗号化する用途に使われます。位置等に対応する調整値を使いますが、XTS自体がデータの完全性や相手認証を提供するわけではありません。

GCMとXTSは、どちらが一律に上位かという関係ではなく、目的と性質が違います。用途、モードの条件、実装の対応を合わせて選びます。

記述の型

• ECBを使わない理由：「同じ平文ブロックが同じ暗号文ブロックになり、データのパターンが漏れる」

• GCMの注意点：「同じ鍵でnonceを再利用しない」

• 認証付き暗号の利点：「暗号化と同時に、改ざんを検出できる」

• CBCのIVの条件：「暗号化の前に予測できない値にする」

• CTRの注意点：「同じ鍵の下でカウンタの値を重複させない」

7. PKIと電子証明書——公開鍵を誰のものとして信頼するか

証明書は、公開鍵と対象を結び付ける

PKIはPublic Key Infrastructure、公開鍵基盤です。電子証明書の発行、利用、検証、失効などを支える仕組みです。

証明書には、公開鍵、対象を識別する情報、有効期間、用途等が含まれ、発行者の署名が付けられます。証明書に秘密鍵を入れて配るわけではありません。IETF RFC 5280、証明書と認証パスの基本

認証局CAは、証明書を発行します。登録局RAは、申請内容の確認等を担います。実際の役割分担は基盤によって異なります。CSRは証明書の発行を求める申請データで、公開鍵等を含みますが、秘密鍵を認証局へ提出するためのものではありません。

ルートまでたどるだけでは足りない

サーバ証明書が中間CAによって発行され、中間CAの証明書がさらに上位のCAへつながる場合があります。検証側は、信頼する基点、トラストアンカーへつながる認証パスを確認します。

ルート証明書が自分自身で署名されていることだけが、信頼の根拠ではありません。OSやブラウザ、組織の管理によって、どの基点を信頼するかをあらかじめ定めています。相手から渡されたルート証明書を無条件に追加すれば、信頼の前提を変えてしまいます。

署名のつながりに加え、有効期間、用途、制約、対象名等も確認します。HTTPSなら、アクセスしたホスト名と証明書の対象名の対応が重要です。正しく発行された証明書でも、別サイトのものなら目的の相手の証明にはなりません。

CRL・OCSP——期限前に使えなくなった証明書

秘密鍵の漏えいなどにより、期限前でも証明書を失効させる場合があります。CRLは失効した証明書の一覧、OCSPは証明書の状態を問い合わせるための仕組みです。

有効期限内だから常に有効、とは限りません。一方、すべてのアプリケーションが毎回同じ方法でオンライン照会するわけでもありません。失効情報をどう入手し、確認できなかった場合にどう扱うかは、利用環境や方針を確認します。

なお、証明書の失効は、流出した秘密鍵の複製を消すことではありません。すでに流出した暗号文の保護が自動的に回復するわけでもありません。

証明書の透明性（CT）

認証局が誤って、あるいは攻撃を受けて、本来の持ち主以外に証明書を発行してしまう事故も起きてきました。そこで、発行したサーバ証明書を、誰でも確認できる公開のログに記録する仕組み（Certificate Transparency）が使われています。ドメインの持ち主は、ログを監視して、自分のドメインに身に覚えのない証明書が発行されていないかを確かめられます。

サイトの内容の正しさは、別の問題

証明書が適切でHTTPS接続ができても、そのサイトの説明や商取引が正しいとは限りません。ドメイン等に関する証明と、サービス内容の信頼性を混同しないようにします。

証明書の期限切れを直すときも、検証を無効化して接続を通すのではなく、対象名、証明書の組合せ、更新手順を確認して修正します。

証明書の種類：DV・OV・EV

サーバ証明書は、認証局が申請者をどこまで確かめたかで分かれます。

• DV（ドメイン認証）証明書：申請者がそのドメインを管理していることだけを確かめる

• OV（組織認証）証明書：ドメインに加えて、申請した組織が実在することを確かめる

• EV証明書：決められた厳格な基準で、組織の実在と申請の正当性を確かめる

DV証明書でも通信は暗号化され、接続先のドメインは確かめられます。しかし、そのサイトを運営している組織が誰かまでは分かりません。

サーバ証明書の検証：4つの確認

HTTPSで相手を確かめられるのは、クライアントが証明書を正しく検証したときだけです。検証では、次の4点を確かめます（図4）。

1. 信頼する認証局から発行されているか：認証パスが、端末が信頼するルート証明書までつながるか

2. 有効期限内か

3. 失効していないか：CRLを取得するか、OCSPで問い合わせて確かめる

4. 証明書のサーバ名（FQDN）が、接続先と一致するか

検証でエラーが出ても無視して通信を続ける実装では、攻撃者が通信の間に入る中間者攻撃によって、通信を盗聴・改ざんされます。テストのために通信を解析したいときも、検証を無効にするのではなく、解析ツールのルート証明書をテスト用の端末に入れて信頼する設定にします。暗号化された通信を機器で復号して検査するTLSインスペクションも、同じ仕組み（検査装置の認証局のルート証明書を端末に信頼させる）で成り立っています。

午後での問われ方

• 令和5年度秋期 午後問2：来客用の無線LANがある環境で、偽のサイトにつながったときにブラウザが示すサーバ証明書の警告の内容が問われました。解答例は「信頼された認証局から発行されたサーバ証明書ではない」「証明書に記載されているサーバ名は、接続先のサーバ名と異なる」の2点です（無線LANの環境は支援士解説3の5）。

• 令和7年度春期 午後問3：スマートフォンのアプリが、サーバ証明書の検証でエラーがあっても通信を続けてしまう脆弱性が題材でした。解答例には、通信解析ツールのプライベート認証局のルート証明書を端末にインストールし、信頼する設定を行うことが示されています。

• 平成29年度秋期 午後I問3：SSL/TLSの安全性が題材でした。解答例には、秘密鍵が危殆化したときに関係するサーバ証明書の利用を停止して失効させること、古いSSL 3.0を利用しない設定にすること、そして「ドメイン認証証明書ではサーバの運営者がC社であることを確認できないから」という、証明書の種類の違いを踏まえた解答が示されています。

採点講評で指摘されたつまずき

• 令和4年度秋期 午後I問1では、HTTPSを使って偽のファームウェアをダウンロードさせない実装を問われ、「暗号化を行う」とだけ答えたり、サーバ証明書の確認に触れなかったりする解答が散見されたと指摘されています。HTTPSの価値は、暗号化だけでなく、証明書の検証で相手を確かめることにあります。

• 令和7年度春期 午後問3では、プライベート認証局のルート証明書をインストールして検証エラーを解消させる方法の正答率が低く、TLSインスペクションも同様の方法で成り立つと指摘されています。

記述の型

• 証明書の検証を怠った場合のリスク：「中間者攻撃によって、通信が盗聴・改ざんされる」

• 確認すべき事項：「信頼する認証局からの発行」「有効期限」「失効の有無」「証明書のFQDNとアクセス先の一致」

• 失効の確認方法：「CRLを取得して確認する」「OCSPで問い合わせる」

• テストで通信を解析したいとき：「解析ツールのルート証明書を端末にインストールし、信頼する設定にする」（検証を無効にしない）

8. TLS——通信の保護と、接続先の確認を組み合わせる

証明書で本文を丸ごと暗号化するわけではない

TLSは、通信の盗聴、改ざん、偽造等への対策を提供するプロトコルです。HTTPSは、HTTPをTLSで保護して使います。

証明書を用いるTLS 1.3の基本的な通信では、相手の認証、鍵共有、通信に使う鍵の導出、実データの保護を組み合わせます。証明書の公開鍵で全通信データを直接暗号化する、という構造ではありません。

本文の通信には、AES-GCM等の認証付き暗号を使います。サーバの秘密鍵は、証明書に対応する鍵の保有を示す署名等へ関わります。鍵共有に使う一時的な鍵とは、役割が違います。

TLS 1.3には事前共有鍵PSKを使う構成もあるため、すべての接続で同じ証明書のやり取りがあるとは限りません。PSKだけを用いる場合や0-RTTのデータには、前方秘匿性等について別の条件があります。0-RTTは再接続時等に早くデータを送る仕組みですが、再送攻撃への配慮が必要です。IETF RFC 8446、TLS 1.3、2章・8章・付録F

TLS 1.3のハンドシェイク

TLS 1.3で、ブラウザがサーバに接続するときの流れは次のとおりです（図5）。

1. ClientHello：クライアントが、使える暗号スイートの候補と、鍵共有のための値（ECDHEなどの一時的な公開値）を送る

2. ServerHello：サーバが、選んだ暗号スイートと、自分の鍵共有の値を返す。ここで双方が共通の秘密を計算し、以降の通信を暗号化する鍵を導く

3. Certificate・CertificateVerify：サーバが証明書を送り、その証明書に対応する秘密鍵で、それまでのやり取りに署名する。クライアントは、証明書を4つの確認で検証し、署名を証明書の公開鍵で検証する

4. Finished：双方が、やり取り全体が改ざんされていないことを確かめる

5. アプリケーションデータ：導いた共通鍵とAES-GCMなどの認証付き暗号で、HTTPの通信を保護する

役割を分けて押さえます。証明書は相手の確認、一時的な鍵共有は通信の鍵の準備（前方秘匿性につながる）、共通鍵暗号は実際のデータの保護です。

暗号スイートは、鍵共有、認証、データの暗号化、ハッシュの方式の組合せです。古いTLSのバージョン（SSL 3.0、TLS 1.0・1.1）や、危殆化した方式を含む暗号スイートは無効にします。攻撃者が、弱い方式を使うように交渉を誘導するダウングレード攻撃にも注意します。

TLS 1.2と1.3の違い

• TLS 1.3では、サーバの秘密鍵で鍵を運ぶ方式（RSAによる鍵交換）がなくなった。証明書を使う通常の接続では、毎回一時的な鍵を使うECDHEなどで鍵を共有するので、前方秘匿性が得られる（事前共有鍵PSKだけを使う構成は別）

• 安全性に問題が見つかった古い方式（RC4、CBCモードの暗号スイートなど）が外され、データの保護は認証付き暗号（AES-GCM、ChaCha20-Poly1305など）に限られた

• ハンドシェイクの途中から暗号化されるので、サーバ証明書も暗号化されて送られる

• 往復の回数が減り、再接続のときに最初の要求からデータを送れる0-RTTもある。ただし、0-RTTのデータは再送攻撃に注意が必要

SSL 3.0、TLS 1.0、TLS 1.1は、既知の弱点があるため使いません。サーバ側の設定で無効にします。

記述の型

• HTTPSで偽のサーバを防げる理由：「サーバ証明書を検証し、接続先が正規のサーバであることを確認できるため」

• 前方秘匿性の効果：「サーバの秘密鍵が後で漏えいしても、過去の通信は復号されない」

• 古いプロトコルへの対策：「SSL 3.0やTLS 1.0・1.1を無効にし、TLS 1.2以上だけを許可する」

HTTPSへの接続を強制するHSTSは支援士解説2の5、スマートフォンのアプリが特定の証明書だけを受け入れる証明書ピンニングは支援士解説2の4で扱います。

TLSが終わる場所を確認する

例えば、住民のブラウザから中継装置まではHTTPSでも、中継装置から申請サーバまでは別の通信になります。中継装置で復号する構成なら、そこで平文を扱います。

その先を再びTLSで保護する場合も、通信は二つの区間です。ブラウザから保存先まで、誰にも復号できない一続きの暗号化になっているとは限りません。

仕様書では、接続元と接続先、TLSの終端、内部通信、ログ、保存先を追います。外部向けURLがHTTPSであることだけで、システム内部の通信まで確認したことにはなりません。

相互TLSと利用者の権限

通常のサーバ認証に加え、クライアントも証明書で認証する構成を、相互TLS、mTLSと呼びます。システム間接続等で、接続する側の識別に使えます。

ただし、クライアント証明書が有効だから、すべての住民情報へアクセスしてよいという意味ではありません。接続主体の確認と、どのデータを操作できるかという認可は別です。クライアント証明書は、無線LANのEAP-TLSによる端末の認証（支援士解説3の5）や、社内のサービスに接続できる端末を限定する用途にも使われます。どの場合も、対応する秘密鍵を端末から取り出せないように守ることが前提です。

9. 他のプロトコルも、保護の単位から見る

IPsec——IP通信を保護する

IPsecは、IP層で通信を保護する仕組みです。ESPは選択した方式に応じて暗号化や完全性・送信元の確認等を提供します。AHは完全性や認証に関わりますが、暗号化による秘匿は提供しません。

IKEは、相手の認証や鍵共有、保護条件の合意を行うために使います。トランスポートモードとトンネルモードでは保護・カプセル化の範囲が異なります。VPNへ接続した後の権限や、端末自体の安全性は別に確認します。VPNとしての使い方は支援士解説3の5で扱います。

SSH——サーバの鍵と、利用者の鍵を混同しない

SSHは、遠隔操作等の通信を保護するプロトコルです。サーバを識別するホスト鍵と、公開鍵認証で利用者が持つ鍵は別の役割です。

初回接続時の鍵や、いつもと違うホスト鍵への警告を無条件に受け入れると、接続先確認が機能しません。信頼できる別の経路で鍵の識別情報を確認するなど、運用を定めます。IETF RFC 4251、4.1節・ホスト鍵

SSHの公開鍵認証では、利用者が鍵ペアを作り、公開鍵をサーバに登録しておきます。接続のときは、利用者の端末が秘密鍵で署名を作り、サーバが登録された公開鍵で検証します。秘密鍵がサーバに送られることはありません。秘密鍵のファイルにはパスフレーズを付けて暗号化しておくと、ファイルを盗まれても、パスフレーズを知らない者には使えません。

令和3年度秋期 午後I問1では、保守用のPCからSSHでサーバに接続する場面で、秘密鍵にパスフレーズを設定する目的が問われました。解答例は「秘密鍵が盗まれても悪用できないようにするため」「保守員以外が不正に秘密鍵を利用できないようにするため」です。採点講評では、秘密鍵と公開鍵を混同した解答や、「秘密鍵のパスフレーズをSSHサーバに送信するため」という解答が散見されたと指摘されています。接続先のサーバを確かめるためのフィンガープリント（ホスト鍵の識別情報）の確認も、同じ大問で問われています。

S/MIME——メール本文の署名・暗号化

S/MIMEは、電子証明書等を使ってメールの署名や暗号化を行う方式です。暗号化なら受信者側の鍵、署名なら送信者側の鍵という整理は同じです。IETF RFC 8551、S/MIME 4.0、1.1節

メールサーバ間のTLSは通信区間を守るものです。S/MIMEで保護するメッセージとは保護の単位が異なります。署名・暗号化の対象外となる情報や、受信後に復号したデータも別途扱います。

認証プロトコルとリプレイ対策

チャレンジレスポンスでは、確認側がその都度異なる問いとなる値を送り、応答によって秘密の保有等を確認します。固定の応答だけを送る方式と比べ、過去の応答の再利用を防ぐ設計につながりますが、方式や実装の安全性は別途必要です。

Kerberosは、認証基盤から発行されるチケットとセッション鍵等を用いる認証方式です。チケットの有効期間や時刻の扱い、認証基盤とその鍵の保護が重要になります。

いずれも、認証の仕組みを選ぶだけで利用者の権限管理まで完成するわけではありません。認証全体の設計は支援士解説3の8で扱います。

10. 暗号解読と危殆化——計算以外の弱点も見る

総当たりと鍵長

鍵の候補を順に試す攻撃が総当たりです。理想化したkビットの鍵なら候補は2のk乗ですが、生成方法に偏りがあったり、人が選んだ短い文字列を安易に鍵へ変換していたりすれば、実際の候補が少なくなる可能性があります。

また、AESとRSAの鍵長を同じ数字で比較して、同じ強さだとは判断できません。攻撃方法と数学的な前提が異なるためです。

既知平文・選択平文・選択暗号文

既知平文攻撃は、平文と対応する暗号文を知る状況での解析です。選択平文攻撃は、自分が選んだ平文に対応する暗号文を得られる状況を考えます。選択暗号文攻撃は、選んだ暗号文に対する復号の結果や応答等を利用する状況を考えます。

どの情報や機能を攻撃者に利用されても安全であるべきか、という評価の前提の違いです。元のデータを一部知られたらすべての暗号が直ちに破れる、という意味ではありません。

サイドチャネルと乱数

計算時間、消費電力、電磁波など、処理の周辺情報から秘密を推測するのがサイドチャネル攻撃です。方式自体の数学的な強さとは別に、実装や装置の対策が必要です。令和7年度秋期 午後問2では、署名鍵を扱うPCを置いた施設に、サイドチャネル攻撃を防ぐ対策が施されているという設定で、防ぐべき攻撃の手法が問われました。解答例は「施設の外から、鍵管理PCの作動音や放出される電磁波を観測し、署名鍵を推測する」です。

乱数は、鍵や一時的な値の生成にも使われます。暗号用途に適した乱数生成器を使い、初期化や障害時の動作も確認します。プログラム言語が標準で用意する乱数の中には、統計的にばらついて見えても、過去の出力から次の値を予測できるものがあります。鍵やセッションID、トークンには、予測できないことを目的に設計された暗号論的擬似乱数生成器を使います。鍵長が長くても、同じ鍵が繰り返し生成されるような不備があれば意味がありません。

ECDSA等では、署名ごとの内部値の不適切な再利用が秘密鍵の漏えいにつながり得ます。ただし、適切な決定的生成方式もあるので、「署名には必ず毎回別の乱数装置が必要」と単純化しません。実装が仕様どおりの条件を満たすことが重要です。

危殆化と移行

新しい攻撃方法や計算能力の向上によって、必要な安全性を保てなくなることを危殆化といいます。古い方式が資料に載っていることと、新規採用に適していることは別です。

例えば、DESやRC4、衝突耐性が問題になる用途でのMD5・SHA-1などは、現在の新規設計で安易に選ぶ対象ではありません。用途と現行の公的な選定基準を確認します。日本では、CRYPTRECが、安全性と実装性を評価した電子政府推奨暗号リストなどを作成・公表しています。リストに載っていても、用途、鍵長、利用モードなどの条件を確かめて使います。

十分な能力の量子コンピュータが実現した場合、RSAや楕円曲線を利用する既存の公開鍵技術への影響が問題になります。耐量子計算機暗号PQCは、それに備える暗号技術です。量子通信を使う鍵配送と同じものではありません。

長期間秘密にしたい情報では、現在の通信を記録され、将来解読されるリスクも考えます。すべてを自己判断で直ちに置き換えるのではなく、利用箇所と保存期間を把握し、標準・製品・公的方針に沿って移行計画を立てます。PQCは将来の研究だけの話ではなく、NISTでは2024年に主要な三つの標準が公開され、移行に向けた取組が進んでいます。NIST「耐量子計算機暗号」・標準と移行

11. 鍵のライフサイクル——作る前から、捨てた後まで

何の鍵かを台帳で分かるようにする

暗号鍵には、保存データの暗号化、通信、署名、鍵自体の保護など、用途の違いがあります。鍵の識別子、用途、所有者、管理者、保管場所、利用システム、アルゴリズム、生成・更新時点、復旧方法を把握します。

鍵の値そのものを平文の一覧表へ集めるという意味ではありません。管理に必要な属性と、秘密の値を分けます。

生成と配付・登録

暗号用途に適した生成方法を使い、必要な鍵長を選びます。共通鍵を配付するなら、相手の確認と安全な配送経路が必要です。公開鍵を登録する場合も、持主との対応や改ざん防止を確認します。

生成した鍵を一時ファイルや作業ログへ残していないか、作業者が不要な複製を持っていないかも確認します。

保管と利用

秘密鍵や共通鍵を取り出せる権限と、その鍵を使う処理を呼び出せる権限は区別します。鍵を外へ出せなくても、誰でも復号処理を呼び出せるなら、平文を取得できる場合があります。

用途ごと、環境ごとに権限を限定し、重要な操作には複数人の確認等を組み合わせます。鍵の管理者とデータの利用者の分離も検討します。ログへ秘密の値を出すのではなく、誰がどの鍵で何をしたかを記録します。

更新と利用期間

鍵を使う期間は、用途、保護する情報、処理量、漏えい時の影響、方式の条件等に応じて決めます。すべての鍵を一律に一年ごとに変えればよい、という一般則ではありません。

更新後の鍵を新しい暗号化へ使っても、古いデータが自動的に新しい鍵で暗号化され直すとは限りません。古い暗号文と鍵の版を対応付け、必要なら再暗号化や鍵の包み直しを行います。特に、鍵を更新・削除する前には、古い鍵で暗号化したバックアップの保存期間を確かめます。必要な旧鍵を保管しておくか、新しい鍵で暗号化し直さないと、障害のときにバックアップを戻せなくなります。

バックアップと復旧

長期保存データの復号鍵を失えば、ファイルが残っていても使えなくなります。必要な鍵のバックアップと、管理者不在・装置故障時の復旧を準備し、実際に戻せるか確かめます。

一方、署名鍵を気軽に複製して関係者全員へ配れば、署名者の管理という前提が崩れます。通信の一時鍵も、過去の復号のためにすべて長期保存すれば、前方秘匿性の狙いと矛盾します。

すべての鍵を同じ方針でバックアップするのではなく、用途と保護要件に応じて決めます。鍵管理の一般的な論点は、NIST SP 800-57 Part 1 Rev.5にも整理されています。NIST「鍵管理に関する推奨事項」Part 1 Rev.5

証明書と鍵の期限を管理する

運用で起きやすい事故の一つが、証明書の期限切れです。サーバ証明書の有効期限が切れると、利用者のブラウザに警告が出たり、システム間の通信が止まったりします。

• 証明書と鍵の一覧（どこで使い、誰が管理し、いつ切れるか）を持ち、期限の前に通知が届くようにする

• 更新の手順を、担当者が替わっても実行できるように残す

• 期限が切れたからといって、検証を無効にして通信を通す応急処置はしない

鍵を運ぶとき：鍵と、それを開ける手段を一緒にしない

鍵を別の場所へ移すときは、鍵を暗号化して運んでも、その暗号を解くパスワードや鍵を同じ経路で運べば、両方を手に入れた人に鍵を取り出されます。

• 暗号化した鍵と、復号に必要なパスワードを、別の人・別の経路で運ぶ

• 受け取る側の公開鍵で暗号化して運べば、運ぶ途中の人は受け取る側の秘密鍵を持たないので、復号できない

• 鍵を使う作業は、担当者を複数名にして、互いに確かめながら行う（一人の不正を防ぐ）

令和7年度秋期 午後問2では、解答例に、パスワードで暗号化した署名鍵と、紙に書き留めたパスワードを一緒に移送している点が問題点として示され、受け取る側の鍵で暗号化して運べば、復号鍵がないので暗号化された署名鍵は復号できない、という考え方が示されています。担当者を複数名にして互いに確認しながら作業する手順への変更も、解答例に挙がっています。

漏えい、失効、廃棄

漏えいした鍵は、新たな利用を止め、対象の鍵や証明書を更新・失効し、影響範囲を調査します。旧鍵で暗号化したデータの再保護が必要か、偽の署名が作られた可能性があるかも検討します。

鍵を変えても、攻撃者がすでに取得した平文は戻ってきません。旧鍵と暗号文の複製を持っていれば、旧データへのリスクが残る場合もあります。

廃棄時は、利用中のデータやバックアップに必要な鍵を消さないようにしつつ、不要になった秘密を複製も含めて処理します。暗号消去は、鍵を消してデータを復号できなくする方法ですが、残った鍵、平文の複製、暗号化範囲などの条件を満たして初めて意味があります。

記述の型

• 鍵が漏えいしたときの対応：「当該鍵の利用を停止し、証明書を失効させ、影響範囲を調査する」

• バックアップを戻せなくなった原因：「鍵の更新時に、古いバックアップの復号に必要な旧鍵を削除した」

• 証明書の期限切れを防ぐ：「証明書の一覧と有効期限を管理し、期限の前に通知する」

12. KMS・HSM・TPM——管理する仕組みと、鍵を守る機構

KMS——鍵を管理し、利用を制御する

KMSはKey Management SystemまたはServiceとして、鍵の生成、保管、利用権限、更新、監査等を支える仕組みを指します。具体的な機能や鍵の保存方式は製品・サービスによって異なります。

KMSを使うから、アプリケーションが侵害されても絶対に復号されないとは限りません。そのアプリケーションが正規の復号権限を持っているなら、攻撃者がその権限を利用する可能性があります。

エンベロープ暗号化——データの鍵を、別の鍵で保護する

データを暗号化する鍵をDEK、その鍵を保護する鍵をKEKと呼ぶことがあります。大きなデータはDEKで暗号化し、DEKをKEKで保護して管理する構成です。

例えば、暗号文と保護されたDEKを保管し、KEKを使う権限を別の管理下へ置きます。ただし、KEKの利用権限を持つ主体は、条件次第でDEKを取り出し、データを復号できます。

KEKを更新してDEKを包み直すことと、データ本体を別のDEKで暗号化し直すことは違います。サービスの「鍵ローテーション」が何を変更するのかを確認します。クラウドのKMSでは、事業者が鍵を管理する方式のほかに、利用者が自分で作った鍵を持ち込む方式（BYOK）などもあります。どの方式でも、事業者側でどんな条件のときに復号の処理が動くのか、鍵を削除すると何が使えなくなるのかを、契約と仕様で確かめます。

HSM——秘密鍵を保護した境界で使う

HSMはHardware Security Moduleです。鍵や暗号処理を保護された境界内で扱うための装置・モジュールです。耐タンパ性、つまり不正な解析や操作への耐性等を備えますが、具体的な保護水準は製品や評価条件によります。

署名鍵を外へ取り出さず、内部で署名する構成などに使われます。装置がネットワーク接続型かどうかだけでHSMを定義するものではありません。

HSMでも、署名を要求できる権限が奪われれば、不正な内容に署名させられる可能性があります。装置の保護、APIの権限、署名対象の確認、バックアップと障害対策を組み合わせます。

TPM——端末の信頼の土台

TPMはTrusted Platform Moduleです。端末の鍵の生成・保護、起動時の状態の測定結果等に基づく保護などへ使われます。独立したチップに限らず、実装形態には違いがあります。

例えば、ディスク暗号化に関する鍵の保護を、端末や起動状態に結び付ける使い方があります。TPMがディスクの全データを高速に暗号化している、という意味ではありません。Microsoft「TPMの概要」

機器交換や起動状態の変更で通常の解除ができなくなることもあるため、承認された復旧手段を用意します。TPMがあるから復旧鍵は不要、という判断は危険です。

TPMは、端末の起動時の改ざんを検出する仕組み（セキュアブートや、起動するプログラムのハッシュ値を記録する測定）にも使われます。改ざんを確かめるための基準の値（ハッシュ値の一覧など）は、それ自体を書き換えられないように守る必要があります。

平成31年度春期 午後I問3では、機器の起動時にプログラムの改ざんを確かめるためのハッシュ値の一覧を、どう守るかが問われました。解答例は「ハッシュ値リストをTPMに保存する」です。採点講評では、一覧にデジタル署名を付けることだけを書き、署名に使う秘密鍵の保護を考えていない解答が散見されたと指摘されています。署名を付けても、秘密鍵が盗まれれば、改ざんした一覧に正しい署名を付けられてしまいます。

KMS、HSM、TPMは排他的な三択ではありません。KMSの鍵をHSMで保護する構成もあります。何を管理し、どこで秘密を保護し、誰が利用できるかを分けて理解します。

午後での問われ方

• 令和5年度秋期 午後問3：クラウドサービスで起きたインシデントの影響が題材でした。漏えいしたコード署名の鍵を作り直し、HSMに保管する場面で、HSMを使う利点が問われました。解答例は「秘密鍵が漏れないという利点」です。採点講評では、「秘密鍵が漏えいしても安全である」など、暗号技術の使い方を誤解した解答が散見されたと指摘されています。漏えいしても安全になるのではなく、漏えいしにくくなるのが利点です。

記述の型

• HSMに保管する利点：「秘密鍵が外部に漏れない」

• サイドチャネル攻撃の手法：「作動音や電磁波を外から観測し、鍵を推測する」

• 鍵の移送の問題点：「暗号化した鍵と、そのパスワードを一緒に移送している」

• 担当者の不正への対策：「担当者を複数名とし、互いに確認しながら作業する」

13. 暗号資産と署名鍵

暗号資産（仮想通貨）では、資産を移す取引に、持ち主の秘密鍵で署名します。署名鍵を持つ人が、資産を動かせる人です。そのため、暗号資産の管理は、署名鍵の管理そのものになります。

• 署名鍵は、インターネットから切り離した環境（コールドウォレット）に置き、取引に必要な分だけを接続した環境（ホットウォレット）で扱う

• 署名鍵を保管する装置、鍵を扱う施設、鍵を運ぶ手順、作業する人の不正を、それぞれ守る（11節・12節）

• 取引の記録は、ブロックチェーンという、前のブロックのハッシュ値をつないだ台帳に記録される。前のブロックを書き換えると後のハッシュ値が合わなくなるので、改ざんを検出しやすい

• 一つの署名鍵だけで資産を動かせると、その鍵の漏えいや担当者の不正がそのまま損失につながる。複数の鍵による署名がそろわないと取引できないようにする仕組み（マルチシグ）もある

14. 目的から技術を選ぶ

午後の設問で「どの技術を使うべきか」を問われたら、守りたいものから逆算します。

• 保存するデータを読ませたくない：共通鍵暗号（AESなど）。鍵はKMSやHSMで守る

• 通信の途中で読まれたくない・改ざんされたくない：TLS（相手の確認には証明書の検証が必須）

• メールの本文を受信者以外に読ませたくない：S/MIMEなど、本文の暗号化

• 改ざんを検出したい（相手と共通鍵を共有している）：MAC（HMACなど）

• 改ざんの検出に加えて、誰が作ったかを第三者に示したい：デジタル署名

• 配布するプログラムが本物か確かめさせたい：コード署名（ハッシュ値の掲載だけでは差し替えに弱い）

• パスワードを保存したい：ソルトを加えたハッシュ化とストレッチング

• 秘密鍵を盗ませたくない：HSM、TPMなど、鍵を取り出せない場所で使う

• 過去の通信を、後で鍵が漏れても守りたい：一時的な鍵共有（ECDHEなど）による前方秘匿性

証明書の設問の解き方

1. 誰の、何のための証明書かを確かめる：サーバ証明書か、クライアント証明書か、コード署名用か

2. 検証が行われているかを確かめる：検証を省いている、エラーを無視している、という記述は、中間者攻撃の入口

3. 信頼の起点を確かめる：どのルート証明書を信頼しているか。勝手にルート証明書を追加させる手順はないか

4. 秘密鍵の置き場所を確かめる：秘密鍵が漏れれば、証明書が正しくても偽装される。漏れたら失効させる

15. 午前II（科目A-2）で正誤を見分けるポイント

• 「公開鍵暗号で相手だけに読ませたいときは、自分の秘密鍵で暗号化する」→ 誤り。相手の公開鍵で暗号化する

• 「デジタル署名を付ければ、本文も秘匿される」→ 誤り。署名は本文を隠さない

• 「MACを使えば、送信者が誰かを第三者に証明できる」→ 誤り。鍵を共有する受信者も同じMACを作れる

• 「ハッシュ関数の出力から、元のデータを復号できる」→ 誤り。ハッシュは復号するものではない

• 「ECBモードは、同じ平文ブロックから同じ暗号文ブロックができる」→ 正しい

• 「AES-GCMでは、同じ鍵でnonceを再利用してもよい」→ 誤り。同じ鍵でのnonceの再利用は、平文の関係の漏えいと、認証タグの偽造につながる

• 「OCSPは、証明書の失効状態をその場で問い合わせる仕組み」→ 正しい

• 「n人がそれぞれの組ごとに異なる共通鍵を持つと、鍵はn(n−1)/2個必要」→ 正しい

• 「DV証明書で、サイトを運営する組織の実在を確かめられる」→ 誤り。DVはドメインの管理だけを確かめる

• 「TLS 1.3では、RSAによる鍵交換が使える」→ 誤り。RSAによる鍵交換は廃止され、通常は一時的な鍵共有（ECDHEなど）を使う

• 「楕円曲線暗号は、RSAより短い鍵長で同程度の安全性を得られる」→ 正しい

• 「公開鍵暗号を使えば、n人の間で必要な鍵の総数は2n個（各人の公開鍵と秘密鍵の組）で済む」→ 正しい

• 「証明書の発行を申請するCSRには、秘密鍵を含める」→ 誤り。CSRに含めるのは公開鍵。秘密鍵は申請者の手元から出さない

• 「データを暗号化しておけば、アクセス権の管理は不要」→ 誤り。正規に復号できる権限を奪われれば読まれる

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　相手だけに読ませる

公開鍵暗号で、データを相手だけが読めるように送りたい。暗号化する鍵と復号する鍵の組合せとして、適切なものはどれか。

• ア：送信者の公開鍵で暗号化し、送信者の秘密鍵で復号する

• イ：送信者の秘密鍵で暗号化し、受信者の公開鍵で復号する

• ウ：受信者の公開鍵で暗号化し、受信者の秘密鍵で復号する

• エ：受信者の秘密鍵で暗号化し、送信者の公開鍵で復号する

正解：ウ。相手の公開鍵で暗号化し、相手の秘密鍵で復号します。アは自分宛てになり、イは誰でも復号できます。エは、送信者が相手の秘密鍵を知っている前提になっています。

問2　署名の検証で分かること

受信者が、文書に付けられたデジタル署名の検証に成功した。このとき確かめられることとして、適切なものはどれか。

• ア：送信者の秘密鍵を持つ者が署名を作成し、文書が改ざんされていないこと

• イ：文書の内容が真実であること

• ウ：送信者のPCがマルウェアに感染していないこと

• エ：文書が通信の途中で盗聴されていないこと

正解：ア。イとウは、暗号技術だけでは保証できません。エの機密性は暗号化の役割で、署名だけでは本文は読めるままです。

問3　掲載されたハッシュ値

配布サイトに、ファイルと一緒にSHA-256のハッシュ値が掲載されている。攻撃者がWebサーバを改ざんできる状態にあるとき、利用者の判断として最も適切なものはどれか。

• ア：手元で計算したハッシュ値と掲載値が一致すれば、配布元が正しいと証明できる

• イ：ハッシュ値をSHA-512にすれば、サイトが改ざんされていても安全である

• ウ：ファイルと掲載値の両方を書き換えられるので、照合だけでは不十分で、コード署名の検証や別の経路での確認が必要である

• エ：掲載されたハッシュ値から元のファイルを復元して比べればよい

正解：ウ。攻撃者がファイルとハッシュ値の両方を差し替えれば、照合は一致してしまいます（ア・イ）。エは、ハッシュが元に戻せないことを誤っています。

問4　HSMとAPIの権限

重要な秘密鍵をHSMの内部に保管し、外部に取り出せない構成にした。しかし、HSMの署名APIを呼び出せる管理者アカウントのパスワードが漏えいした。適切な判断はどれか。

• ア：秘密鍵は取り出せなくても、正規のAPIを使って、不正なデータに署名させられるおそれがある

• イ：秘密鍵が保護されているので、不正な署名が行われる危険はない

• ウ：HSMを使っていれば、APIを呼び出す側の認証は不要である

• エ：HSMをTPMに置き換えれば、APIの不正利用は自動的に防げる

正解：ア。鍵を取り出せないことと、鍵を使う権限は別です。API呼出しの認証、複数人での確認、操作ログの監査を組み合わせます。

問5　共通鍵の個数

6つの組織が、組ごとに異なる共通鍵を1個ずつ共有して、互いに通信する。必要な共通鍵の総数はどれか。

• ア：6個

• イ：12個

• ウ：15個

• エ：30個

正解：ウ。n(n−1)/2 ＝ 6×5÷2 ＝ 15個です。エは、同じ組を二重に数えています。

実務と国・自治体では

実務で暗号の不備が残りやすいのは、方式の選定よりも運用です。証明書の期限切れ、検証の無効化、鍵の保管場所の不明、復旧に必要な旧鍵の削除、委託終了時の鍵の扱いなどです。調達では、通信の終端と保存データの暗号化の範囲、誰が鍵を生成・保管・更新・破棄し、復旧できるか、方式の危殆化に備えて差し替えられるか（暗号アジリティ）を仕様に書きます。

政府機関等の統一基準は、電子政府推奨暗号リストに基づいて方式・鍵長・プロトコルを定めることや、鍵の管理と危殆化への対応の手順を求めています。自治体向けのガイドラインも、暗号化の対象と鍵の管理を扱っています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• 目的と鍵の向きで整理する。 秘密にするなら受信者の公開鍵、署名は署名者の秘密鍵、MACは共有した共通鍵。

• HTTPSの価値は、証明書の検証にある。 信頼する認証局・有効期限・失効・サーバ名の4点を確かめ、エラーを無視しない。

• TLSは役割の組合せ。 証明書は相手の確認、一時的な鍵共有は鍵の準備、共通鍵暗号はデータの保護。

• 暗号の強さは鍵の扱いで決まる。 保管（HSM）、移送（鍵と解く手段を分ける）、作業（複数人）、復旧（旧鍵の保管）までを設計する。

さらに深く学ぶなら

この記事の範囲を超えて、仕組みをもっと深く知りたい人向けの本です（試験対策の本ではありません）。

• 共通鍵・公開鍵・ハッシュ・署名・証明書・SSL/TLSまで、暗号の仕組みを基礎から学べる

関連記事

• 前提：ネットワークを分ければ安全になる？｜支援士解説3の5（TLSの終端と検査装置）

• 次に読む：ログインできれば、その先まで見てもいい？｜支援士解説3の8（認証と鍵・証明書）

• あわせて読む：ログインできれば、安全なのか｜支援士解説2の4（パスワードの保存・証明書ピンニング）

2026年10月改訂：午後の出題例と記述の型、サーバ証明書の4つの確認、TLS 1.3のハンドシェイク、鍵の移送を加え、構成を見直しました。