LoginSignup
28
34

シーケンス図で「暗号技術」と「認証」を理解する【情報処理安全確保支援士 試験対策】

Last updated at Posted at 2024-03-17

はじめに

◆この記事は何?
この記事では、シーケンス図を使って暗号技術と認証について説明します。

◆対象
暗号や認証を学びたい人、試験対策で覚えたい人

◆この記事のねらい
暗号技術と認証について、シーケンス図を使って覚えやすくする

共通鍵暗号方式

暗号化と復号化に同じ鍵を使うのが共通鍵暗号方式です。

共通鍵暗号方式
sequenceDiagram
    autonumber
    participant 送信者
    participant 受信者
    送信者 ->> 受信者 : 事前に「共通鍵」を共有する
    送信者 ->> 送信者 : 暗号化(「暗号文」ができる)
    送信者 ->> 受信者 : 「暗号文」を渡す
    受信者 ->> 受信者 : 復号化

鍵の数は、n*(n-1)/2となります。nC2で求められます。

共通鍵暗号方式は、共通鍵を安全に相手に渡せない「鍵の配送問題」があります。
「鍵の配送問題」を解決するのが公開鍵暗号方式です。

公開鍵暗号方式

公開鍵と秘密鍵のペアを使うのが公開鍵暗号方式です

公開鍵暗号方式
sequenceDiagram
    autonumber
    participant 送信者
    participant 受信者
    受信者 ->> 受信者 : 「秘密鍵」と「公開鍵」のペアを作成する
    受信者 ->> 送信者 : 「公開鍵」を渡す
    送信者 ->> 送信者 : 「公開鍵」で暗号化(「暗号文」ができる)
    送信者 ->> 受信者 : 「暗号文」を渡す
    受信者 ->> 受信者 : 「秘密鍵」で復号化

公開鍵暗号方式では、鍵の数は2nになります。

鍵の配送問題を解決できますが、共通鍵暗号方式と比較して処理時間が遅くなります。

ハイブリッド暗号方式

共通鍵暗号方式と公開鍵暗号方式のメリットを組み合わせたのがハイブリッド暗号方式です。

ハイブリッド暗号方式

sequenceDiagram
    autonumber
    participant 送信者
    participant 受信者
    
    受信者 ->> 受信者 : 「秘密鍵」と「公開鍵」のペアを作成する
    受信者 ->> 送信者 : 「公開鍵」を渡す
    送信者 ->> 送信者 : 「セッション鍵」を作成する
    Note right of 送信者 : 乱数によってセッション鍵を生成
    
    送信者 ->> 送信者 : 「セッション鍵」で平文を暗号化(「暗号文」ができる)
    送信者 ->> 送信者 : 「公開鍵」で「セッション鍵」を暗号化
    送信者 ->> 受信者 : 「暗号文」と「暗号化されたセッション鍵」を渡す
    受信者 ->> 受信者 : 「秘密鍵」で「セッション鍵」を取り出す
    受信者 ->> 受信者 : 「セッション鍵」で「暗号文」を復号化

「セッション鍵」の情報はそのまま暗号化して送っていましたが、DH法を使うことで、セッション鍵自体を送らずに、鍵の素を送ることでセッション鍵を生成できます。

DH法(Diffie-Hellman法)

DH法は安全に共通鍵を共有する仕組みです。
「離散対数問題が困難であること」を根拠に、安全に共通鍵を共有するアルゴリズムの一つです。

DH法(Diffie-Hellman法)
sequenceDiagram
    autonumber
    actor Aさん
    actor Bさん
    Note over Aさん,Bさん: 「素数p」と「pより小さい整数q」を共有
    Aさん ->> Aさん : 乱数Aを生成する
    Aさん ->> Aさん : 公開値Xを計算する(qのA乗 mod p)
    Bさん ->> Bさん : 乱数Bを生成する
    Bさん ->> Bさん : 公開値Yを計算する(qのB乗 mod p)
    Aさん ->> Bさん : 公開値Xを共有する
    Bさん ->> Aさん : 公開値Yを共有する
    Aさん ->> Aさん : 共通鍵を計算する( YのA乗 mod p)
    Bさん ->> Bさん : 共通鍵を計算する( XのB乗 mod p)
    Note over Aさん,Bさん: 共通鍵を使用可能

DH法は鍵交換の仕組みであり、認証の仕組みはありません。そのため中間者攻撃に弱く、対策としてはデジタル署名などを使います。

チャレンジ&レスポンス認証

ユーザーIDとパスワードを平文で送信して認証する方法を「ベーシック認証」と言います。暗号化されていないため、盗聴に弱いという特徴があります。

対して、認証情報をネットワークに流さないのがチャレンジ&レスポンス認証です。

チャレンジ&レスポンス認証
sequenceDiagram
    autonumber
    participant クライアント
    participant 認証サーバ
    認証サーバ ->> 認証サーバ : 事前にIDとパスワードを登録しておく
    クライアント ->> 認証サーバ : 認証要求(IDを送る)
    認証サーバ ->> 認証サーバ : 「チャレンジコード」(乱数)生成
    認証サーバ -->> クライアント : 「チャレンジコード」を送る
    クライアント ->> クライアント : 「レスポンス(A)」を生成
    Note right of クライアント : チャレンジコードとパスワードでレスポンス(ハッシュ値)を生成
    クライアント ->> 認証サーバ :  「レスポンス(A)」を送る
    Note right of クライアント : ここでリプレイ攻撃(盗聴して再利用)ができる
    認証サーバ ->> 認証サーバ : 「レスポンス(B)」を生成
    認証サーバ ->> 認証サーバ : 「レスポンス(A)」「レスポンス(B)」を比較して一致していれば認証OK
    認証サーバ -->> クライアント : 認証OK

クライアントから送信されるレスポンスを盗聴して、そのまま利用する「リプレイ攻撃」を実行できます。
対策は、チャレンジコードを毎回ランダムに変化させることです。

S/Key

S/Key方式はチャレンジ&レスポンス認証の一つです。

マスターパスワード、シード、シーケンス番号を使ってワンタイムパスワードを生成します。
ワンタイムパスワード認証は、ログインするたびに異なるパスワードを利用することでセキュリティ強度を高める方法です。

S/Key
sequenceDiagram
    autonumber
    participant クライアント
    participant 認証サーバ
    認証サーバ ->> 認証サーバ : 事前にマスターパスワードとシーケンス番号を登録しておく
    クライアント ->> クライアント : 事前にマスターパスワードを登録しておく
    クライアント ->> 認証サーバ : 認証要求(IDを送る)
    認証サーバ ->> 認証サーバ : 「チャレンジコード」生成
    認証サーバ -->> クライアント : 「チャレンジコード」を送る
    クライアント ->> クライアント : 「レスポンス(A)」を生成
    Note right of クライアント : マスターパスワード、シードを組み合わせて、シーケンス番号-1回分のハッシュ処理を実施
    クライアント ->> 認証サーバ :  「レスポンス(A)」を送る
    Note right of クライアント : レスポンスはワンタイムパスワードなので再利用できない
    認証サーバ ->> 認証サーバ : 「レスポンス(A)」をハッシュ処理
    Note right of 認証サーバ : 最後の1回のハッシュ処理
    認証サーバ ->> 認証サーバ : 「レスポンス(B)」を生成
    認証サーバ ->> 認証サーバ : 「レスポンス(A)」「レスポンス(B)」を比較して一致していれば認証OK
    認証サーバ -->> クライアント : 認証OK

シーケンス番号は、ハッシュ処理の回数を表します。

認証サーバに設定したシーケンス番号は、ワンタイムパスワード生成ごとに減少するため、シーケンス番号が0になると使用できなくなります。再度、S/Keyを用いた認証をしたい場合は登録をやり直す必要があります。

また、マスターパスワードの登録には注意が必要です。SSH接続や機器に直接接続するなどの盗聴対策が大切です。

時刻同期方式

時刻同期方式は、ワンタイムパスワード方式の一つです。

時刻同期方式
sequenceDiagram
    autonumber
    participant クライアント
    participant 認証サーバ
    Note over クライアント, 認証サーバ:事前に時刻を同期
    クライアント ->> クライアント : 事前にPIN番号を登録しておく
    認証サーバ ->> 認証サーバ : 事前にPIN番号を管理
    クライアント ->> クライアント : トークンコード生成
    クライアント ->> クライアント : ワンタイムパスワード(A)生成
    Note right of クライアント : トークンコード+PINハッシュ処理でワンタイムパスワード生成
    クライアント ->> 認証サーバ : ワンタイムパスワード(A)を送る
    認証サーバ ->> 認証サーバ : ワンタイムパスワード(B)生成
    認証サーバ ->> 認証サーバ : ワンタイムパスワード(A)とワンタイムパスワード(B)を比較
    認証サーバ -->> クライアント : 認証OK

時刻同期方式は、チャレンジコードのやり取りがないため、認証のための通信が少なくなります。

FIDO認証(Fast IDentity Online認証)

FIDOはパスワードを使わずに認証ができます。FIDOの代表が生体認証です。

FIDO認証
sequenceDiagram
    autonumber
    participant クライアント
    participant オンラインサービス
    participant 認証サーバ
    クライアント ->> クライアント : 事前に公開鍵と秘密鍵のペアを作成
    クライアント ->> 認証サーバ : 事前に公開鍵を登録
    クライアント ->> オンラインサービス : 認証要求
    オンラインサービス ->> 認証サーバ : 認証開始
    認証サーバ ->> オンラインサービス : チャレンジ送付
    オンラインサービス ->> クライアント : チャレンジ送付
    クライアント ->> クライアント : 生体認証
    クライアント ->> クライアント : レスポンス生成
    Note right of クライアント : レスポンス生成:チャレンジコードに秘密鍵を使ってデジタル署名する
    クライアント ->> 認証サーバ : レスポンス送付
    認証サーバ ->> 認証サーバ : レスポンス照合
    認証サーバ -->> オンラインサービス : 認証OK
    オンラインサービス ->> クライアント : サービス提供

FIDOは、デバイス側で認証を完了させるため、パスワードなどの認証情報がネットワーク上に流れることはありません。
安全性が高く、利便性も高い手法です。

ケルベロス認証

ケロベロス認証は、SSO(シングルサインオン)方式の一つです。
同一ドメイン内でよく利用されます。

ケルベロス認証
sequenceDiagram
    autonumber
    box レルム
    participant クライアント
    participant サーバ
    end
    box KDC(Key Distribution Center)
    participant AS as AS(Authentication Server)
    participant TGS as TGS(Ticket Granting Server)
    end

    Note over クライアント, AS : クライアントとKDCの共通鍵で暗号化通信
    クライアント ->> AS : 認証要求
    AS -->> クライアント : OKなら「TGT(Ticket Granting Ticket)」と「セッション鍵」を送付

    Note over クライアント, TGS : クライアントとTGSの共通鍵で暗号化通信
    クライアント ->> TGS : 「TGT」を送付
    TGS -->> クライアント : OKなら「ST(Service Ticket)」と「セッション鍵」を送付

    Note over クライアント, サーバ : クライアントとサーバの共通鍵で暗号化通信
    クライアント ->> サーバ : 「ST」を送付
    サーバ ->> クライアント : OKならサービス提供
    

次の接続先と利用する鍵の情報を渡すことで暗号通信ができています。

SAML認証

SAMLは、Security Assertion Markup Languageの略です。
異なるwebサービス間でSSO(シングルサインオン)を実現します。

SAML認証
sequenceDiagram
    autonumber
    participant クライアント as クライアントWebブラウザ 
    participant SP as SP(サービスプロバイダ)
    participant IdP as IdP(アイデンティティプロバイダ) 

    Note over SP, IdP : 信頼関係
    クライアント ->> SP : サービス要求
    SP -->> クライアント : リダイレクト応答
    クライアント ->> IdP : 認証要求
    IdP ->> IdP : 認証
    IdP ->> IdP : 認証OKならアサーション(XML)作成
    IdP -->> クライアント : アサーション発行/リダイレクト応答
    クライアント ->> クライアント : アサーション取得
    クライアント ->> SP : アサーション提示
    SP ->> SP : アサーションOKならサービス開始
    SP -->> クライアント : サービス提供

アサーションはXML形式です。
アサーションに含まれる情報は、認証情報・属性情報・認可情報の三つです。

SAMLはSPとIdP間で認証情報のやり取りがありません。リダイレクトを使って、クライアントからSPとIdPにそれぞれ接続してSSOを行います。

OAuth2.0

SAMLは認証と認可を行う一方で、OAuth2.0は原則認可のみです。

用語についてはこちらの記事の解説がわかりやすかったです。

OAuth2.0
sequenceDiagram
    autonumber
    participant リソースオーナー
    participant OAuthクライアント
    participant 認可サーバ
    participant リソースサーバ

    リソースオーナー ->> リソースサーバ : アカウント情報登録
    リソースオーナー ->> OAuthクライアント : OAuth2.0をリクエスト
    OAuthクライアント ->> 認可サーバ : OAuth2.0をリクエスト
    認可サーバ ->> リソースオーナー : 認可情報
    リソースオーナー ->> リソースオーナー : 認可
    リソースオーナー ->> リソースオーナー : 認可グラントの作成
    リソースオーナー ->> 認可サーバ : 認可グラントの付与
    認可サーバ ->> OAuthクライアント : 認可グラントの転送
    OAuthクライアント ->> 認可サーバ : 認可グラント提示
    認可サーバ ->> 認可サーバ : 認可グラント認証
    認可サーバ ->> 認可サーバ : アクセストークン作成
    認可サーバ ->> OAuthクライアント : アクセストークン付与
    OAuthクライアント ->> リソースサーバ : アクセストークン提示
    リソースサーバ ->> OAuthクライアント : アカウント情報の取得
    

HMACを使った改ざん有無の確認

HMACは、代表的なメッセージ認証符号(MAC:Message Authentication Code)の生成方法です。

共通鍵を使います。HMACは送信者と受信者の両方が作成できます。

HMACを使用する目的は、改ざんの有無の検知です。

HMACを使った改ざん有無の確認
sequenceDiagram
    autonumber
    participant 送信者
    participant 受信者

    Note over 送信者,受信者 : 事前に共通鍵/ハッシュ関数を共有
    送信者 ->> 送信者 : HMAC(a)を作成
    Note right of 送信者 : メッセージと鍵をハッシュ関数を使ってハッシュ値(HMAC)にする
    送信者 ->> 受信者 : 「メッセージ」と「HMAC(a)」を送信
    受信者 ->> 受信者 : 「HMAC(b)」を作成
    受信者 ->> 受信者 : HMACが同じ値になるか確認
    
    

MACでわかるのは改ざんの有無です。
MACが不一致の場合、メッセージに改ざんや破損があることを意味します。
MACは作成者を判断できません。作成者を判断するためにはデジタル署名が必要です。

HMACの活用例は次のようなものがあります。

PKI

PKIは、Public Key Infrastructureの略で、公開鍵と秘密鍵の対応関係を保証する仕組みです。

公開鍵の信頼性を保証する機関を認証局(CA)といいます。

PKI
sequenceDiagram
	participant 証明書所有者
	participant クライアント as 正当性を確認したいクライアント
	participant CA(認証局)
	autonumber

    証明書所有者 ->> 証明書所有者 : 鍵ペア(公開鍵と秘密鍵)の作成
    証明書所有者 ->> CA(認証局) : 「公開鍵」と申請情報を送付
    CA(認証局)  ->> 証明書所有者 : 「デジタル証明書」を発行
    証明書所有者  ->> クライアント : 「デジタル証明書」を送付
    CA(認証局)  ->> クライアント : 「デジタル証明書」の正当性を保証
 

デジタル署名

デジタル署名はメッセージの完全性を保証すると共にメッセージの作成者を担保できます。

デジタル署名
sequenceDiagram
	participant 送信者
	participant 受信者
	participant CA(認証局)
	autonumber
    送信者 ->> 送信者 : 鍵ペアを作成
	送信者 ->> CA(認証局) : 事前に電子証明書を発行してもらう
	CA(認証局) -->>送信者 : 電子証明書
	送信者 ->> 送信者 : 「データ」をハッシュ関数でハッシュ化して「ダイジェスト(別名:フィンガープリント)」を作成
	送信者 ->> 送信者 : 「ダイジェスト」を秘密鍵で暗号化して「署名」を作成
	送信者 ->> 受信者 : 「データ」と「署名」を送信
	送信者 ->> 受信者 : 電子証明書(「公開鍵」「CAの署名」)を送信
	受信者 ->> 受信者 : 「CAの署名」を検証
	 Note right of 受信者: 検証が必要
	受信者 ->> 受信者 : 電子証明書内の「公開鍵」で署名を復号して「ダイジェスト(b)」を作成
	受信者 ->> 受信者 : 受け取った「データ」からハッシュ関数で「ダイジェスト(a)」を作成
	受信者 ->> 受信者 : ダイジェストを比較して照合する。データが送信者によるものと分かる

秘密鍵を持っているのは送信者だけです。電子証明書をつくれるのは送信者だけです。
公開鍵で復号できたということは、鍵ペアを持っている人によって作られたデータであることがわかります。

電子証明書の有効性を検証する必要があります。検証で使われるのがOCSPです。

参考

OCSP

OCSPは、Online Certificate Status Protocolの略です。
電子証明書が失効しているかどうかを確認するためのオンラインによる電子証明書検証手順です。

①OCSPの利用

失効情報を提供するOCSPサーバーは認証局が運営しており、OCSPレスポンダと言われます。

OCSPの利用
sequenceDiagram
	participant クライアント
	participant OCSPレスポンダ
	autonumber
		クライアント ->> OCSPレスポンダ : OCSP問い合わせ
		OCSPレスポンダ -->> クライアント : OCSP応答

OCSPレスポンダからの応答が遅い場合は通信に遅延が発生します。
そこで使われるのがOCSPステープリングです。

②OCSPステープリングの利用

OCSPステープリング
sequenceDiagram
	participant クライアント
    participant 接続先webサーバー
	participant OCSPレスポンダ
	autonumber
		OCSPレスポンダ ->> 接続先webサーバー : 事前に「CRL(証明書失効リスト, Certificate Revocation List)」を入れておく
		接続先webサーバー ->> クライアント : デジタル証明書
		クライアント ->> 接続先webサーバー : OCSP問い合わせ
		接続先webサーバー -->> クライアント : OCSP応答

クライアントはOCSPレスポンダに接続する必要がなくなり、効率的にデジタル証明書の失効状態を確認できます。

おわりに

この記事では、暗号と認証分野で使われる技術についてシーケンス図を使って紹介しました。

シーケンス図を書いてみることで、内容を周りの方に説明できるくらいには理解が深まりました。
良い勉強法だったと思います。

参考書の説明等とシーケンス図を比較してみると、より分かりやすくなると思います。
参考になれば幸いです。

参考

「ゼロからスタート! 教育系YouTuberまさるの情報処理安全確保支援士1冊目の教科書」

「2024 情報処理安全確保支援士「専門知識+午後問題」の重点対策」

28
34
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
28
34