認証技術
1 Basic認証
Basic認証の別名:クリアテキスト認証、PLAIN認証、USER /PASS認証など
パスワード認証：特定の人やものを一意に識別できるシステムをつくり、ユーザIDとパスワードの組み合わせで認証する
Basic認証：ユーザIDとパスワードを平文で送信して認証する方法
・盗聴に弱い
・なりすまし対策ができない
・現在は、SSL/TTLによる暗号化を併用してBasic認証を利用
2 チャレンジ&レスポンス認証
チャレンジ&レスポンス認証：認証情報をネットワーク上に流さずに認証。
認証サーバは送られてきたレスポンスコードと認証サーバで生成したハッシュ値が一致するか確認
1 クライアントが認証要求し、IDを送る
2 認証サーバはIDと作成したパスを登録し、チャレンジコードを生成し、れチャレンジコードとパスワードでレスポンス（ハッシュ値）を生成し、クライアントに送る
3 クライアントはチャレンジコードとパスワードでレスポンスを生成し、認証サーバに送る
3 S/Key
ワンタイムパスワード認証：ログインするたびに異なるパスワードを利用することでセキュリティ強度を高める方法
S/Key：チャレンジ&レスポンス認証の一つで、マスターパスワード、シード、シーケンス番号を使ってワンタイムパスワードを生成する
シーケンス番号は、ワンタイムパスワードを生成すると1ずつ減少し、シーケンス番号が0になると、ワンタイムパスワードが生成できなくなる。
ハッシュ処理の計算回数はシーケンス番号によって定義
1 クライアントがマスターパスワードを登録し、認証サーバにIDをおっくて認証要求する
2 認証サーバがマスターパスワードとシーケンス番号を登録し、シーケンス番号とシード（乱数）でチャレンジコードを生成し、クライアントに送る
3 クライアントはマスターパスワードとシードを組み合わせて、シーケンス番号-1回分ハッシュ処理を行い、レスポンスを生成し、認証サーバに送る
4 認証サーバはチャレンジコードをハッシュ処理して生成したレスポンスと、送られてきたレスポンスをハッシュ処理したものを照合し、一致した場合は正規のクライアントであると判断する
4 時刻同期方式
時刻同期方式：トークンを使ってパスワードを一定時間で変更させる。
ワンタイムパスワードが一致した場合、正規のクライアントであると判断する。クライアントと認証サーバの時刻同期が重要である
1 時刻同期をする
2 クライアントがトークンコードを生成し、トークンコード+PINをハッシュ処理し、ワンタイムパスワードを生成し、認証サーバに送る
3 認証サーバはトークンコード+PINをハッシュ処理し、ワンタイムパスワードを生成し、送られてきたワンタイムパスワードを比較する
5 生体認証とリスクベース認証
生体認証：指紋、静脈、虹彩、顔などの生体情報に基づいて認証を行う技術。生体認証のメリットは利便性が高いこと。デメリットはパスワード認証のように完全な精度で認証できないこと
リスクベース認証：普段と異なる環境からアクセスした場合に追加で認証を行う仕組み。普段と異なる場合のみ追加認証を行うことで、利便性を確保しつつ、セキュリティを高める
本人拒否率（FRR）：本人なのに拒否する
他人受入率（FAR）：他人なのに受け入れてしまう
6 FIDO
FIDO：パスワードを使わずに高い安全率と利便性を提供する認証方式。FIDO Allianceが標準化を進めている技術。パスワードを使わずに認証することができる。生体認証以外の方法でも認証できる。パスワードレス認証とも呼ばれる
FIDO2：FIDO認証をブラウザ用に最適化したもの。デバイス側で認証を完了させるため、認証情報がネットワーク上に流れない
1 クライアントが公開鍵登録（公開鍵とユーザID）する
2 クライアントがオンラインサービスに認証要求する
3 認証サーバが認証開始する
4 認証サーバがオンラインサービスにチャレンジコードを送る
5 オンラインサービスがクライアントにチャレンジコードを送る
6 クライアントは生体認証を行い、認証を完了させる
7 チャレンジコードに秘密鍵を使ってデジタル署名する
8 レスポンスコードを認証サーバに送付する
9 認証サーバはクライアントの公開鍵を使ってレスポンスコードを照合する
7 リバースプロキシを使ったSSO
シングルサインオン（SSO）：一度の認証で複数のサーバやアプリケーションを利用できる仕組み
リバースプロキシサーバ：インターネット側からクライアントの接続を、待ち受けて内部ネットワークへの通信を代理する。インターネット側にいるクライアントはリバースプロキシサーバに接続し、ユーザ認証を行う。認証が成功すると、リバースプロキシサーバが内部サーバに代理で通信を行い、クライアントの通信を仲介する。内部サーバは、プロキシサーバからの通信は信頼できるものとしてサービスを提供する。クライアントはリバースプロキシサーバで一度認証すればよく、内部のサーバごとに認証する必要はない
リバースプロキシ方式の問題点：プロキシサーバはHTTP/HTTPSの通信を代理するため、接続先の内部サーバがWEBサーバでない場合は、リバースプロキシを使ったSSOを利用できない場合がある
8 ケルベロス認証を使ったSSO
ケルベロス認証：Microsoftのアクティブディレクトリで採用されることもある認証方式。レルムによってSSOの有効な範囲を定義し、レルム内で管理されるユーザ、サービス、ホストはプリンシパルとして定義する。KDC（Key Distribution Center）はレルム内の認証を行う。KDC内部は認証サーバの役割を持つASと、チケット認可サーバの役割を持つTGSが共存している場合が多い。クライアントは、ASで認証を行い、TGSからチケットを発行してもらうことで、対象のサーバを利用することができる
ケルベロス認証の流れ：
1 KDCに、KDCとクライアント間の通信で利用する共通鍵を設定する
2 クライアントはKDC内のASにアクセスし、認証情報を入力する
3 認証OKの場合、ASは、クライアントとTGS間で利用するセッションキーを発行する
（ここまでのやりとりは、KDCとクライアントの共通鍵で暗号化する）
4 クライアントはTGTを使いTGSにアクセスして、利用したいサービスのチケットを要求する
5 TGTに問題がなければ、TGSはサーバのサービスチケットと、利用したいサーバ間で利用するセッション鍵の情報を発行する
（ここでのやりとりは、TGSとクライアントの共通鍵で暗号化する）
6 クライアントはサービスチケットを使ってサービスを利用する。
（クライアントと利用したいサーバ間の通信は、TGSによって発行されたセッション鍵で暗号化する）
9 SAMLを使ったSSO
SAML（Security Assertion Markup Language）：インターネット上で異なるWEBサービス間で認証をするために、標準化団体OASISが考案したフレームワーク。アサーションというXMLの情報を使って認証情報のやり取りを行い、SSOを実現する。
アサーション：認証したサーバや認証時間を表す認証情報、利用者の名前や属性を表す属性情報、利用者がどのファイルにアクセスするのかを表す認可情報などの情報を含んでいる
SAMLの３つの構成要素：認可を行うアイデンディティプロバイダ（IdP）、実際のサービスを提供するサービスプロバイダ（SP）、サービスを受けるクライアント
SAMLを使ったSSOの流れ：
1 IdPとSPはあらかじめ信頼関係を結ぶ
2 クライアントはWebブラウザを使って、利用したいSPにアクセスする
3 SPは認証を行わず、クライアントに対してIdPにリダイレクトするように応答する
4 リダイレクトを受けてクライアントはIdPにアクセスし、認証を行う
5 認証OKの場合、IdPはクライアントにアサーションを発行する
6 クライアントはSPにリダイレクトされ、アサーションをSPに送る
7 アサーションを受け取ったSPはアサーションの内容を確認し、クライアントに応じたサービスを提供する
SAMLはSPとIdP間で認証情報のやり取りがない
リダイレクトを使って、クライアントのWEBブラウザがSPとIdPそれぞれのサーバに接続を行い、SSOを行う
10 OAuth2.0
OAuth2.0：リソースオーナーの認可に基づいてサービスのアクセス権を別のサーバに渡すことができる仕組み
OAuthの四つの構成要素：リソースオーナー、OAuthクライアント、認可サーバ、リソースサーバ
OAuthを利用することで、リソースサーバのリソースをOAuthクライアントに共有することができる
OAuth２.0の流れ
1 リソースオーナーが利用したいサービスは、OAuthクライアントとして、リソースサーバの認可サーバにアクセスする
2 認可サーバは、リソースオーナーにアクセス許可の確認をする
3 許可が出た場合、リソースオーナーは認可グラントを認可サーバに送り、認可サーバがOAuthクライアントに認可グラントを転送する
4 OAuthクライアントは認可サーバに認可グラントを提示する
5 認可サーバはOAuthクライアントの認証及び認可グラントの正当性を確認し、問題なければアクセストークンを発行する
6 OAuthクライアントはアクセストークンを提示することによって、リソースサーバのリソースを利用できるようになる
SAMLとOAuth２.0の違い
SAMLは認証と認可を行うが、OAuthは原則認可のみである。OAuth２.0の場合は別の手段で利用者の認証を行う仕組みが必要である
11 メッセージ認証符号「MAC」
メッセージ認証符号（Message Authentication Code:MAC）：メッセージの完全生を保証するために利用する
メッセージ認証符号の生成方法（代表的な生成方法HMACの場合）：
1 事前に、受信者、送信者は共通鍵をもっている
2 送信者は送りたいメッセージと共通鍵を含めハッシュ関数を使って計算し、HMAC値を求める
3 送信者は送りたいメッセージにHMACをつけて送る
4 受信者は発信者と同様の計算を行い、算出したHMACと送られてきたHMACが一致するかを確認する
5 HMACが一致した場合、メッセージの完全性が保証できる。HMACをつくることができるのは、共通鍵をもつ人だけなので通信先が正規の相手であると認証することもできる
MACはメッセージの作成者を判断できない
MACはメッセージの完全生を保証できるが、送信者と受信者が共通鍵暗号によって同じMACを生成できる特性上、メッセージの作成者を保証することなできない。メッセージの作成者を担保する（否認防止）には、公開鍵暗号方式を使ったデジタル署名を利用する
MACでわかるのは改ざんの有無
MACが不一致の場合、メッセージに改ざん（もしくは破損）があることを意味する
12 デジタル署名
デジタル署名：メッセージの改ざん有無と、メッセージの作成者を担保（否認防止）する仕組み
デジタル署名の流れ：
1 送信者は、公開鍵暗号方式を利用して鍵ペアを作成する
2 送信時は送りたいメッセージにハッシュ処理を行い、ハッシュ値を取得する
3 そのハッシュ値を送信者の秘密鍵で暗号化する。（暗号化されたハッシュ値は、デジタル署名になる）
4 送りたいメッセージとデジタル署名を受信者に送る
5 受信者は、デジタル署名を送信者の公開鍵を使って復号する
6 受信者が算出したハッシュ値と、複合して算出したハッシュ値が一致していれば、そのメッセージは改ざんがされていないことになり、秘密鍵をもつ送信者が作成したメッセージであると判断することもできる（否認防止）
MACとデジタル署名の使い分け：
デジタル署名は公開鍵暗号方式を利用するので、処理速度が遅くなる特徴がある。そのため、否認防止が必要な場合にデジタル署名を利用する。否認防止を必要としない場合は、共通鍵暗号方式を利用したメッセージ認証符号（MAC）を利用することで処理速度を優先させる
MACとデジタル署名の違い：
共通鍵暗号方式を利用するMACによって担保できるのは、改ざんの有無、通信相手の認証である。処理が軽いので高速な処理ができる。
公開鍵暗号方式を利用するデジタル署名によって担保できるのは、改ざんの有無、通信相手の認証、メッセージ作成者（否認防止）である。主にメッセージ作成者を担保したい場合に利用される
13 デジタル証明書
デジタル証明書（公開鍵証明書、電子証明書、サーバ証明書ともいう）：正当性を証明する電子的な証明書。
デジタル署名は秘密鍵を使ってできているため、検証には公開鍵が必要であり、公開鍵はデジタル証明書を使って正当性を保証する
デジタル証明書には公開鍵の情報も入っている：
デジタル証明書はX.509で規格化されている。
とりわけ、デジタル証明書の中に公開鍵の情報が入っており、さらにデジタル証明書には、有効期限の情報も入っている。
また、HTTPS通信を行うために、WEBサーバにデジタル証明書を導入する必要があり、そのデジタル証明書は、サーバ証明書と呼ばれる。
サーバ証明書はクライアントに対してサーバの公開鍵を配布するとともに、サーバの正当性およおび公開鍵の正当性を保証する
CN項目はFQDNを指定する：
デジタル証明書の所有者名には、CNの情報も含まれる。たとえばサーバ証明書として利用される場合、CN項目はWEBサーバのFQDNを指定する
14 サーバ証明書の種類
サーバ証明書：保証範囲に合わせて、DV証明書、OV証明書、EV証明書の３つに分かれる
DV証明書：利用者がドメインを保持していることを保証する。
審査が簡単で、料金は無料もしくは低価格で作成できる。ただし、企業の実在性や業務実態は審査しないので補償対象外。
DV証明書を利用することで、HTTPS通信ができるようになるが、サーバの信頼性は担保できない
OV証明書：利用者のドメインの保持と実在生を保証する。
審査には公的書類の提出などが必要で、DV証明書と比べると費用は高くなるが、サーバの信頼性を高めることができる。
CN（サイトのURL）にはワイルドカードを使用することができ、複数のサーバでOV証明書を共有することができる
EV証明書：ドメインの保持、実在生、業務実態まで審査を行なって保証する。
国際的な認定基準に基づいて審査を行なって発行されるため、最も信頼度が高いサーバ証明書であるが、審査項目が多く、発行するまでに手間がかかり、発行料金が高い。
ワイルドカードを使用することができないので、複数のサーバでEV証明書を共有することはできない
ワイルドカード証明書：サーバ証明書のCN欄にワイルドカード文字（* )
を含めると、複数のサーバでサーバ証明書を共有できる
15 PKI
PKI（Public KEy Infrastracture）：公開鍵と秘密鍵の対応関係を保証する仕組み。信頼できる第三者機関が、公開鍵と秘密鍵の対応関係を保証する
認証局（CA）：公開鍵の信頼性を保証する機関。認証局はルート認証局を頂点とした階層構造になっていて、上位認証局と下位認証局は信頼関係を築く
認証局は階層構造で信頼関係を作っている：
1 クライアントがHTTPS対応のWEBサーバにアクセスする
2 WEBサーバからデジタル証明書（サーバ証明書）が送られる
3 クライアントはデジタル証明書の正当性を確認するために、デジタル証明書を発行した認証局のデジタル署名を検証する
（デジタル署名を検証するには、そのデジタル証明書を発行した認証局の公開鍵が必要である。
無数に存在する認証局の公開鍵を事前にクライアントにインストーすることはできないため、クライアントは階層構造の上位にある認証局の公開鍵の情報をルート証明書としてインストールしておく。
通常、信頼できる認証局の公開鍵は、ルート証明書としてWEBブラウザやOSに組み込まれている）
認証局は階層構造になっており、信頼できる認証局配下の認証局が発行したデジタル証明書は信頼できる仕組みになっている
証明書チェーン：階層構造を校正している認証局のリストを証明書チェーン、または認証パスという。WEBサーバはデジタル証明書（サーバ証明書）を渡すときに、証明書チェーン内を校正する各認証局のデジタル証明書をクライアントに渡すことで効率的に検証できるようにしている
16 デジタル証明書の検証方法
デジタル証明書の検証方法：クライアントは、受け取ったデジタル証明書の正当性を検証する。問題がないことが確認してできれば、デジタル証明書内の情報や公開鍵を信頼することができる
1 階層構造の下位に位置するCAが発行したデジタル証明書をサーバ証明書として利用する場合、WEBサーバはクライアントに自身のサーバ証明書と、証明書チェーンを校正する認証局（CA4, CA1）のデジタル証明書を送る
2 受け取ったサーバ証明書は、CA4のデジタル署名が付与され、CA4のデジタル証明書はCA1のデジタル署名が付与されており、CA1のデジタル証明書はルートCAのデジタル署名が付与されている
3 クライアントは事前に入手しているルートCAのデジタル署名を利用して、CA1のデジタル証明書を検証し、CA1の公開鍵を取り出す
4 取り出したCA1の公開鍵を使ってCA4のデジタル証明書を検証し、CA4の公開鍵を取り出す
5 取り出したCA4の公開鍵によって、サーバ証明書を検証する
CAが信頼関係を結んだ階層構造になっているので、クライアントは必要最低限のルート証明書のみでデジタル証明書を検証することができる
自己署名証明書：自分の秘密鍵でデジタル証明書を自己証明書という。ルートCAは上位にCAが存在しないので、自分の秘密鍵を使ったデジタル署名を行い、自己署名証明書としてデジタル証明書を利用する
17 CRLとOCSP
証明書失効リスト（CRL）：秘密鍵の情報が流失してしまった場合などは、有効期限内であってもデジタル証明書を失効させる必要がある。有効期限内のデイ時たる証明書は証明書失効リストに掲載することで失効扱いにすることができる。
CRLはデジタル証明書と同じく、X.509のフォーマットによって定義されており、デジタル証明書の検証時にCRLを確認することでデジタル証明書の執行状態を確認できる
OCSP（Online Certificate Status Protocol）：デジタル証明書の執行状態を確認したするためのプロトコル。
CRLのダウンロードのタイミングによっては、最新の執行情報を参照することができないが、OCSPを利用すれば、リアルタイムにデジタル証明書の失効状態を調べることができる。
OCSPレスポンダ：認証局が運営しているOCSPサーバで、認証局が運営している。
OCSPレスポンダからのレスポンスが遅い場合、遅延が発生する。
OCSPステープリング：遅延を解消する技術で、サーバが事前にOCSPクライアントとしてOCSPレスポンダからの情報を取得しておき、デジタル証明書と一緒にOCSPによって得られた情報を送る仕組み
期限切れのデジタル署名はCRLから削除される：CRLには、有効期限内で失効させたいデジタル証明書の情報が記載される。CRLに記載された失効状態のデジタル証明書の有効期限が過ぎた場合、そのデジタル証明書の情報はCRLから削除される
この記事が気に入ったらサポートをしてみませんか？