【基本情報】セキュリティ計算、鍵は「何を数えるか」の確認です｜鍵数・総当たり・ALE・バックアップ

情報セキュリティ分野には、鍵数・候補数・確率・期待損失額・バックアップ世代など、条件を整理して計算する論点もあります。中身は、これまでの記事でやった組合せ・累乗・確率・期待値の応用なので、ここまで読んできた人には見覚えのある式ばかりのはずです。

ただしこの分野、式を選ぶ前に「何を数える問題なのか」の確認が重要です。鍵ペアの組数か合計本数か、パスワードは固定長か以下か、総当たりは最悪か平均か、発生「確率」か発生「頻度」か、バックアップは取得前か取得後か。同じ式でも、ここの読み違いで答えが変わります。順番に見ていきましょう。

鍵の本数：最初に通信構成を確認する

暗号通信で必要な鍵の数。方式と構成によって増え方がまったく違います。

共通鍵方式（全員が相互に通信する場合）：n人の全員が互いに直接通信し、2人の組ごとに固有の共通鍵を1本割り当て（送信・受信で同じ鍵）、グループ鍵・中央管理・セッション鍵は考えない——この単純モデルなら、「n人から2人を選ぶ組合せ」で、

共通鍵の本数 ＝ nC2 ＝ n ×（n−1）÷ 2

例題：8人が相互に共通鍵で通信するなら？

8 × 7 ÷ 2 ＝ 28本

順序を区別してn(n−1)と数えると、AとBの組・BとAの組を重複して数えることになり、8人では56本。双方向で同じ共通鍵を使う本例では、2で割って28本です。確率の記事、バブルソートの記事に続く、同じ組合せの式の登場です。

ただし、構成が変われば式も変わります。各人が鍵配送センタとだけ長期鍵を共有する中央管理ならn本、全員でひとつのグループ鍵を共有するなら1本、A→BとB→Aで別の鍵を使う設定ならn(n−1)本。「共通鍵方式なら常にn(n−1)÷2」ではなく、ペアごとに固有の鍵かを問題文で確認してください。なおここで数えているのは、問題文で指定された単純な構成における「異なる鍵」の本数です。実システムでは鍵更新・セッション鍵・認証用鍵などで保管される鍵は増えるので、全保管鍵数を表すものではありません。

公開鍵方式：1人が公開鍵と秘密鍵のペアを1組持てば足ります。ここで大事なのが、問われているものの区別です。

「2n」が正解になるのは合計本数を聞かれたとき。「公開鍵は何本？」ならn本が正解です（前提：1人1組で、認証局自身の鍵、暗号用と署名用の別鍵、更新前後の旧鍵、証明書の枚数は数えない。公開鍵は複数の相手にコピーして配布できますが、その配布コピーも鍵の種類数には数えません）。

人数が増えたときの差が、この話の中心です。200人なら、ペアごとの異なる共通鍵は19,900本。公開鍵方式は1人1組で200組、公開鍵と秘密鍵をあわせた異なる鍵の合計が400本。この「異なる鍵の本数」どうしを比べた差が19,500本です（保管コピー数や証明書数の比較ではありません）。共通鍵の本数はn(n−1)÷2＝(n²−n)÷2という二次式で、nが大きいときはおおむねn²÷2のペースで増えます。「鍵配送が大変」と暗記していた知識を、計算で確かめられるわけです。

ひとつ補足。公開鍵は秘密にする必要がありませんが、「その公開鍵が本当に本人のものか」の確認は必要で、そこを支えるのがPKI・認証局・デジタル証明書です。また実際の通信では、公開鍵技術による鍵共有・鍵合意と、大量データを処理する高速な共通鍵暗号を組み合わせる方式（ハイブリッド暗号）が一般的です。鍵数が少ないから公開鍵方式が常に優れている、という話ではありません。

パスワード候補数：固定長・文字種類・重複を確認する

例題：英大文字26種と数字10種の計36種で、ちょうど4文字のパスワード（各位置で36種すべてを独立に使え、同じ文字の繰り返しOK、先頭制限・必須文字・禁止文字列なし、すべての文字列を候補に数える）。何とおり？

36⁴ ＝ 1,679,616とおり（約168万）

確率の記事でやった重複あり並べそのものです。あわせて確認したいのが「1文字増やすと？」——1文字につき×36、2文字増やせば36²＝1,296倍。無作為に選ぶ単純モデルでは、文字数が1つ増えるごとに候補数が文字種類数倍になる、という構造です。

ただし問題文の条件で式が変わります。

• ちょうど4文字：36⁴ ＝ 1,679,616とおり
• 1文字以上4文字以下：36＋36²＋36³＋36⁴ ＝ 1,727,604とおり（空文字は含めず、各長さの候補は互いに重複しないので合計できる。「以下」が0文字を含む設定なら＋1）
• 同じ文字を使えない4文字：36P4 ＝ 36×35×34×33 ＝ 1,413,720とおり（各文字は一度だけ。文字種類数≧文字数が前提）

「ちょうど」「以下」「繰り返してよい」「一度だけ」——この言葉に丸をつけてから式を選んでください。

なお、実際のパスワードの安全性は候補数だけでは決まりません。人が選ぶパスワードは辞書語や規則的な文字列に偏るので、十分な長さ、推測されやすい値・漏えい済みの値の回避、サービス間の使い回し回避（パスワードマネージャの活用）、失敗試行のレート制限、多要素認証、そして保存側では一意なソルトを付けてパスワード保存向けの計算コストを調整できる方式でハッシュ化すること、なども効いてきます（暗号学的ハッシュを1回計算するだけでは不十分です）。試験の計算は「無作為・固定長の単純モデル」として解いてください。

総当たり時間：最悪と平均を分ける

候補数N、毎秒の試行回数rとして（正解がN個の候補集合に必ず含まれ、候補を重複なく試し、正解位置は一様、見つかった時点で停止、速度一定、並列化・ロックアウト等なしの単純モデル）、

最悪時間（全部試す） ＝ N ÷ r
平均試行回数 ＝（N＋1）÷ 2、よって 平均成功時間 ＝（N＋1）÷（2r）≒ N ÷（2r）（Nが十分大きい場合）

例題：候補総数36億とおり、毎秒100万回試せる装置なら？

最悪：36億 ÷ 100万 ＝ 3,600秒 ＝ 1時間
平均：≒ 1,800秒 ＝ 30分

平均が最悪の半分になるのは、「正解は探索の途中、平均すると真ん中あたりで見つかる」から。問題文が「すべて試すのに要する時間」なのか「平均」なのかで答えが2倍違うので、必ず確認してください。

もうひとつの前提確認がオンラインかオフラインか。実際のログイン画面に試行するオンライン攻撃では、レート制限・ロックアウト・CAPTCHA・多要素認証などがあるため、毎秒100万回のような速度は出ません。毎秒100万回のような速度が想定しやすいのは、漏えいしたパスワードハッシュを手元で解析するオフライン攻撃の文脈ですが、そこでの実際の速度もハッシュ方式・ソルト・反復回数（コストパラメータ）・ハードウェア・並列化などで大きく変わります。試験の計算では「問題文が与えた試行速度の単純モデル」として扱い、現実の全攻撃に一般化しないのが正確です。

補足：試行回数から成功確率を求める

各試行が互いに独立で、成功確率が毎回同じp（失敗しても次回のpが変わらない）とき、m回で1回以上成功する確率は、確率の記事でやった余事象そのもの。

1 −（1−p)^m

例：p＝0.000001で1,000回試行なら、1−(1−0.000001)^1000 ≒ 約0.09995%。「p×m＝0.1%」という掛け算は、pが小さく、かつmpも十分小さいときの近似です。mpが1に近づいたり超えたりする場合には、mpを確率としてそのまま使えません。

もうひとつ大事な区別を。この独立試行の式と、候補を重複なく調べる総当たりは別の確率モデルです。候補総数Nの中に正解が1個あり、重複なくm個（m≦N）の異なる候補を調べるなら、正解位置が一様のとき成功確率はm÷N。たとえばN＝100万から異なる候補を1,000個調べると、1,000÷1,000,000＝0.001＝0.1%。独立試行の約0.09995%と数値は近いですが、同じ式ではありません。問題文が「毎回無作為に選び直す」のか「候補を順に消し込む」のかを確認してください。

ハッシュ値のとおり数：出力bビットなら2^b

演習にも入れているハッシュの数え上げです。

ハッシュ値の候補数 ＝ 2^b（出力がbビットの場合）

128ビットなら2^128とおり、256ビットなら2^256とおり。これは出力として表現可能なビット列の総数であって、入力の数ではありません（限られた入力集合に対して全出力値が実際に現れるとも限りません）。入力可能な値の数が2^bを超える場合には、鳩の巣原理により、異なる入力が同じ出力になる衝突の組が必ず存在します（ハッシュは暗号化と違い、元に戻す操作を想定しない一方向の要約です。以下では暗号学的ハッシュ関数を想定します）。

既知の弱点や出力の偏りを考えない理想的なbビット暗号学的ハッシュへの攻撃量の目安は、与えられた特定の出力に対応する入力を探す原像探索が約2^b、同じ出力をもつ任意の異なる2入力を探す衝突探索が誕生日問題に基づき約2^(b/2)。2^(b/2)は「衝突が相当な確率で見つかる試行数の桁の目安」であって、必ずその回数で衝突するという意味ではありません。SHA-256なら理想モデル上、原像約2^256、衝突約2^128です。「2^256とおりだから2^256回で衝突する」ではなく、衝突のほうが指数が半分になる、という対比で覚えてください。

年間予想損失額：ALE ＝ SLE × ARO

リスクの金額評価は期待値の応用です。用語とセットで押さえます。

ALE ＝ SLE × ARO

例題：ある攻撃の年間発生頻度が0.2回/年（長期平均で5年あたり1回に相当。必ず5年ごとに1回起こるという意味ではありません）、起きたときの損失が5,000万円。年間予想損失額は？

5,000 × 0.2 ＝ 1,000万円/年

「確率0.2」と書かれることもありますが、年間発生確率がAROに一致するのは「1年間に起こるか起こらないか（最大1回）」というベルヌーイ型の単純モデルの場合。1年に複数回起こりうる設定では、「少なくとも1回起こる確率」とAROは一般に一致しないので、「年間の期待発生回数」で考えるのが明確です。

もうひとつ、ALEは期待値です。毎年必ず1,000万円の損失が出るという意味ではなく、実際の年次損失は0円の年もALEを上回る年もあります。長期的な期待値として、対策の比較などに使う指標です。

対策費の判断は「対策前後のALEの差」で

ALEは対策費を検討する材料の一つです。対策の経済的効果は、ALE全額とではなく、対策でどれだけALEが下がるかと対策費を比べます。

年間リスク低減額 ＝ 対策前ALE − 対策後ALE
正味の期待便益 ＝ リスク低減額 − 年間対策費
（初期導入費や複数年の運用費がある場合は、問題文の評価期間に合わせて年額換算するか総額で比較し、同じ期間どうしで比べます）

例題：対策前ALE1,000万円、対策を入れると対策後ALE200万円、年間対策費500万円なら？

リスク低減額 ＝ 1,000 − 200 ＝ 800万円
正味の期待便益 ＝ 800 − 500 ＝ ＋300万円（金銭的にはプラス）

ただし実際の対策判断は金額だけでは決まりません。法令・契約上の義務、人命・安全、信用、事業継続などの要素があり、対策後にも残留リスクは残ります。ALEは判断の物差しの一本、と位置づけてください。

バックアップ復旧：方式と「取得時点」を確認する

計算というより数え上げですが、時点の読みで答えが変わるので、条件確認が特に大事な分野です。

例題：日曜にフルバックアップを取得。月曜から水曜までは毎日業務終了後に、前回のバックアップ以降の変更分を増分バックアップとして取得した。水曜分の増分バックアップが正常に完了した後に障害が発生し、水曜バックアップ取得時点へ復旧する。必要なバックアップは何個？

日曜フル ＋ 月・火・水の増分 ＝ 4個

ここで数えている「個」は、復旧に必要なバックアップセット（バックアップファイル）の数です。物理媒体の本数やバックアップ内のファイル数ではありません。前提は、各バックアップが正常に取得され、チェーンに欠損がなく、トランザクションログ等の追加復旧は考えない、という単純モデルです。

増分バックアップが持っているのは「前回のバックアップ以降」の変更分だけ（毎日取れていれば結果的に前日からの分ですが、定義としては前回以降です）。だから復旧は最新のフル＋その後の増分を古い順にすべて。途中の1個が欠落・破損すると、それ以降の復旧に影響します。

そして時点の話。この例で4個なのは「水曜分の取得後に障害」だから。もし取得前に障害が起きて火曜取得時点へ復旧するなら、日曜フル＋月・火の3個が正解になります（バックアップセットだけを使い、指定された時点へ戻す単純モデルの話です。ログ等で直前まで復旧できる構成は別途）。「水曜に障害」とだけ書かれた問題では、取得時刻・障害時刻・どの時点へ戻すかを確認してください。

差分バックアップとの違いも整理しておきましょう。

水曜取得後への復旧なら、増分方式は4個、差分方式は日曜フル＋水曜差分の2個。日々のバックアップ量は増分が小さく、差分は日を追って膨らみやすい——という傾向はありますが、実際の所要時間はデータ量・媒体・実装で変わるので、無条件の断定はしません。

ついでにシラバス用語を2つ。RPOは「障害時点からどこまで過去へ遡った状態までならデータ損失を許容できるか」を時間で表した目標（RPO24時間なら、最大24時間分の更新損失を許容する目標）。RTOは「障害やサービス中断の発生後、業務・システムを許容できる状態まで復旧するための目標時間」です。RPOを復旧所要時間と、RTOを失ってよいデータ量と取り違えないように。1日1回のバックアップだけを使う単純モデル（毎回正常に完了し、他のログ保全等がない前提）では、障害のタイミングによっては直近バックアップ以降、最大約24時間分の更新を失う可能性があります。バックアップ頻度だけでRPOが確実に達成できるわけではない点も含めて、「どの時点へ戻るか・何を失ってよいか・何時間で戻すか」を区別してください。

補足：ログの保存容量

セキュリティ運用の計算としてログ容量も出ることがあります。データ量の記事の応用です。

ログ容量 ＝ 1件あたりサイズ × 1秒あたり件数 × 保存秒数

例：500バイト/件 × 200件/秒 × 86,400秒 × 30日 ＝ 259,200,000,000バイト。1GB＝10^9バイトとすれば259.2GB、2進接頭語なら259,200,000,000÷2^30≒約241.4GiBです（GBとGiBの取り違えに注意）。件数・サイズが一定で、圧縮・索引・複製・管理領域・安全余裕は考えない単純モデルなので、実際の基盤でこの値だけ確保すれば十分、という意味ではありません。

解く前の判定フロー

1. 鍵の問題：組数か、異なる鍵の本数か、合計か（保管コピー数ではない）。全員相互通信か中央管理か
2. パスワード：ちょうどか範囲か、重複・先頭・必須・禁止の条件、文字種類数
3. 総当たり：最悪か平均か成功確率か、オンラインかオフラインか
4. 成功確率：独立試行（1−(1−p)^m）か、重複なし探索（m÷N）か
5. ハッシュ：出力ビット数と、原像（約2^b）か衝突（約2^(b/2)）か——どちらも理想モデルの目安
6. ALE：SLEとARO（回/年）を拾う。対策費は前後のALE差と同じ評価期間で比較
7. バックアップ：方式（フル/増分/差分）と、取得時点・障害時点・復旧先時点。RPOとRTOを区別
8. GBかGiBか、問題文の接頭語定義を確認
9. 最後に単位（本・組・とおり・秒・円/年・バイト）を確認

代表的なミスまとめ

仕上げに演習10問どうぞ

演習では、鍵数・候補数・確率・リスク評価・バックアップなど、本記事に関連する計算を確認できます。シリーズの締めくくりにどうぞ。

今日のまとめ

• 共通鍵n(n−1)÷2は「全員相互・ペアごと固有鍵」の場合。中央管理ならn本、グループ鍵なら1本
• 公開鍵方式は問われる対象によりn組・n本・合計2n本。問われた単位に丸をつける
• パスワード候補数は長さ・文字種類・重複・制約条件で式が変わる
• 総当たりの最悪はN/r。重複なし探索の平均は(N＋1)/(2r)で、大きいNならN/(2r)に近い。オンラインとオフラインで前提が違う
• 成功確率は、独立試行なら1−(1−p)^m、重複なし探索ならm÷N。式が別物
• bビットハッシュの出力候補は2^b。理想モデルでは原像約2^b、衝突約2^(b/2)
• ALE＝SLE×AROで、実損失ではなく期待値。対策費は「対策前後のALEの差」と同じ期間で比較し、金額以外の要素も忘れない
• 増分復旧は「最新フル＋以後の全増分」、差分は「最新フル＋最新差分」。取得時点と復旧先時点を確認
• RPOは失ってよい時間幅、RTOは復旧目標時間。ログ容量ではGBとGiBの定義を確認

これで計算問題シリーズ全12回、完結です。本シリーズで選定した主要な計算テーマを、演習とあわせて振り返ってみてください。おつかれさまでした。

参考資料

• IPA「基本情報技術者試験（レベル2）シラバス Ver.9.2」
• NIST SP 800-63B-4「Digital Identity Guidelines: Authentication and Authenticator Management」
• NIST SP 800-34 Rev. 1「Contingency Planning Guide for Federal Information Systems」

本記事の例題は、基本情報技術者試験の出題範囲及び標準的な情報セキュリティの定義を参考に、当サイトで独自に作成したものです。

関連する問題

• 基本情報技術者 技術要素 択一式（応用） 第101問〜第105問
• 基本情報技術者 技術要素 択一式（応用） 第106問〜第110問