この記事では，研究のサーベイをまとめていきたいと思います。ただし，全ての論文が網羅されている訳ではありません。また，分かりやすいように多少意訳した部分もあります。ですので，参考程度におさめていただければ幸いです。
間違えている箇所がございましたらご指摘ください。随時更新予定です。他のサーベイまとめ記事はコチラのページをご覧ください。
本記事の内容
大学で学習した「情報セキュリティ」の内容を網羅的にまとめていくものです。目次は以下の記事をご覧ください。
暗号と認証の必要性
情報セキュリティ<概要編>でもお伝えした通り，情報セキュリティには３つの要件があります。
【情報セキュリティの３要件】
●機密性（Confidentiality）
●完全性（Integrity）
●可用性（Availability）
その中でも，暗号と認証は機密性を維持するための手法として知られています。機密性とは，アクセスを許可されたものだけが情報を手に入れられることを指します。
復習
暗号の大別古典暗号では，暗号化のアルゴリズムや暗号鍵は秘密にしておくというアイディアに基づいていました。一方，現代暗号は，暗号化のアルゴリズムを公開しつつも，お互いに共通鍵を何かしらの形で共有するというアイディアに基づきます。
暗号と複合に同一の鍵を利用する方式を，共通鍵暗号化方式と呼びます。処理が高速な一方で，共通鍵をどのように交換するのかが問題でした。一方，暗号化の鍵を公開しながら，複合化の鍵は秘密にしておくことで暗号化を実現する方式を，公開鍵暗号化方式と呼びます。
公開鍵暗号化方式の中でも代表的なアルゴリズムに，RSAが挙げられます。詳しくは，以下で解説しています。
saltの利用
情報セキュリティ<暗号と認証その２>でもお伝えしている通り，ハッシュ関数はパスワードの保存に利用されています。パスワードを生の文字列で保存している場合，万が一，流出してしまえば一発アウトです。一方，ハッシュ値を保存しておけば，外部者はハッシュ関数を知らないため，その文字列からはパスワードは推測できないのです。
しかし，本当の悪者は，入力と出力のペアを大量に集めてデータベース化することで，ハッシュ値から入力を推定してしまうのです。一番愚直な方法としては，全ての文字列の組み合わせに対して，それぞれのハッシュ値を保存しておく方法です。
| パスワード | ハッシュ値 |
|---|---|
| password | f03881a88c6e39135f0ecc60efd609b9 |
| abcde | dff9959487649f5c7af5d0680a9a5d22 |
| qwerty | c2cb085c24f850986e55f1c44abe6876 |
| abc123 | e2cc4f546930ce0fcbce1246159cdb79 |
このように保存しておけば，ハッシュ値からもとのパスワードを推定することができてしまいます。しかし，今どきこのような分かりやすいパスワードを設定している人は多くないでしょう。そのため，攻撃者にとっては全ての文字列に対応するハッシュ値をデータベース化しておきたいと考えます。
しかし，現実的に全ての文字列との対応表を作成するのは難しいです。８文字の英数パスワードで12PBもの容量が必要になります。（1.5PBでFacebook上の100億枚の写真データに相当するらしいです。）
そこで考え出されたのが「レインボーテーブル」です。平文からハッシュ値から文字列に逆変換を施す「還元関数」を利用して，「平文→ハッシュ値→平文」の変換を繰り返して得られた最初と最後の平文を保存することで，データ量を節約しようという発想です。この手法を使えば，総当たりで攻撃するよりも高速に探索を行うことができます。
情報セキュリティを確保するためには，このようなレインボーテーブルを利用した攻撃にも耐性を持たせる必要があります。ここで利用されるのが「salt」です。「salt」は，ハッシュ関数に通す前に保存したいデータにくっつけられるランダムなデータのことを指します。ソルトはユーザーごとに毎回異なる値が利用されるため，ソルトを付加させることで，同じパスワードでも異なるハッシュ値を出力することが可能になります。
このようにすることで，攻撃者はレインボーテーブルを作成するのに「ユーザー数」というパラメータを考慮する必要が出てきます。ユーザー数を掛け合わせるだけで，計算量は実質不可能なオーダーまで持っていくことが可能になります。
他にも，クラッキングを防ぐ方法としては，ワンタイムパスワードや二段階認証があります。前者は，もしパスワードが漏洩したとしても，定期的にパスワードが更新されれば被害が抑えられるのではないかという発想に基づきます。後者は，異なるデバイスで認証を行うことにより，セキュリティを強化する方法です。
参考：Windowsの認証方式
Windowsでは，２つの認証方式が用いられています。
●LM方式
・パスワードは14文字までに制限
・7文字ごとに分割してハッシュ生成
・大文字小文字の区別なし
・ソルトなし
→総数：約7兆5千億
●NTLM方式
・パスワードは127文字まで
・分割なし
・大文字小文字の区別あり
・ソルトなし
→総数：無限大
脅威モデル
ソフトウェアやアプリが，どのような脅威に晒される危険性があり，どのような対策が必要なのかを定めたものを，脅威モデルと呼びます。例えば，以下のような脅威を考えます。
太郎さんからメアリーさんに情報を送るとき…
●盗聴
→メアリーさんに情報は届くが盗み聞きする
●なりすまし
→メアリーさんのフリをする
●偽造
→太郎君のフリをする
●改ざん
→太郎君からの情報を変えてしまう
●再送
→太郎君からの情報に加えて新しい情報を提供する
たとえば，非常に単純な例えですが，特に対策を施していないネットワーク越しに生のIDとパスワードをやりとりしてしまえば，「盗聴」「なりすまし」「偽造」「改ざん」「再送」の全てに脆弱性が認められることになります。
そこで，パスワードのみハッシュ化すれば，攻撃者はハッシュ値からパスワードを推定できないため，「盗聴」を通して「なりすまし」や「再送」に脆弱性をもつことになります。
もし，通信の冒頭に太郎君側からメアリーさん側に「始めますよ」という合図として毎回異なるnonce（使い捨てのランダム値）を利用した場合，どうでしょうか。メアリーさんは，太郎君から受け取ったnonceをハッシュ関数の入力に付け加えることで，太郎君が通信したい相手であることを証明できます。毎回値を変えるため，再送にも耐性があります。
このような認証方式を「チャレンジ＆レスポンス認証」と呼びます。さらにセキュアな通信にするには，メアリーさん側から太郎君側にもnonceを送ればよいのです。毎回異なる値を用いて，お互いにチャレンジ＆レスポンスを相互行うことで，脅威に耐性を持たせることができます。
このようなハッシュ関数を用いる対策以外にも，公開鍵暗号化方式（ディジタル署名）を利用した方法もあります。攻撃者は，送受信者の秘密鍵を知らなければ，暗号を複合することができないからです。
認証連携
複数の認証システムを連携させることで，一度IDとパスワードを使ってログインすれば，関連したサービスをログイン済みで利用可能であるようなしくみを，SSO（Single Sign On）と呼びます。SSOを利用することで，パスワードの使い回しを防いだり，ログインの手間を省いたりすることができます。
SSOを利用する最も大きなメリットの１つとして，ユーザーの認証を信頼度の高いシステムに任せることができる点が挙げられます。全てのシステムが安心・安全であるという訳ではないため，信頼性の高いシステムでログインを行えることは，ユーザーにとってメリットであるということです。
認証連携で登場するキャストは，主に以下の通りです。
●ユーザ
●SP（サービスプロバイダ）
●IdP（認証サーバ）
SAMLという規格に準じたSSOは，大まかに以下の流れで行われます。
１．ユーザーがSPにリクエスト
２．SPはIdPにリダイレクト（SAMLリクエスト付き）
３．IdPはユーザーのログイン処理（連携同意確認付き）
４．IdPはSPへリダイレクト（SAMLアサーション付き）
５．SPはIdPからの許可に基づき検証を行う
６．SPはユーザへレスポンス
このように，SSOでは多くのリダイレクトが行われます。それはSSOの仕組みに基づくもので，信頼できるシステムで認証を行うことや，パスワードの使い回しを防げるといった利点をユーザは享受することができるのです。
まとめ
情報セキュリティの暗号化についてお伝えしました。大学生であれば必ず使ったことのある認証連携ですが，内部の仕組みまで首を突っ込んだことはありませんでした。一方，まだまだ大まかな理解にすぎないため，もう少し詳しく知る必要があると感じています。
