i have no idea

I have no idea

bibouroku

やる気の出ない情報セキュリティ5 「認証技術」

認証技術

会社で情報セキュリティをやることになったので、勉強がてらメモ
文献は「マスタリングTCP/IP 情報セキュリティ編」

認証技術は大事そうなので、頑張っていきたいところ。
Authとかよくいわれてますよね。それが全然わかんなくて、知ったかぶりをしています。

認証技術の基礎

「誰」に「どの」情報、リソースにアクセスさせるのかをあらかじめ決めておくことが重要です。
「誰」にアクセスさせるのかを決めて、確認することを「認証(Authentication)」
「どの」情報、リソースにどのようにアクセスさせるのかポリシーを決めることを「認可(Authorization)」といいます。
実際に作成したポリシー(ACL(Access Control List))にしたがってアクセス制御等を行います。

認証で一番身近なものは、IDとパスワードを用いるパスワード認証です。 サービスを使うときには誰もが使用するものであると言えますよね。
目の前のPC等にログインする際、パスワードは単純に目の前のPCに保存されます。が、
Amazon等のWebサービスの場合は、パスワードに対する脅威に対して、 注意を払う必要があります。それらへの対策をした認証を、認証プロトコルによる認証といいます。

認証

認証の実現方式には、以下の3つのカテゴリーがあります。

  • 主体の知識による認証
  • 主体の所持するものによる認証
  • 主体の身体的な特性による認証
    これらのカテゴリーを複数使って認証を行うことを、2要素認証、多要素認証と言ったりします。

主体の知識による認証は、パスワード認証、PIN(Personal Identification Number)を用いたものが上げられます。
パスワードデータは、認証する側のシステムにハッシュ化されて保存されます。パスワードが同じ人がいる場合の対策として、 UNIX OSでは利用者ごとに、塩(salt)という乱数値を用意し、それと併せてハッシュ化したりします。おいしそうですね。

Windows方式では、LM(LAN Manager)方式、NTLM方式という認証方式があります。NTLM方式では、大文字小文字の区別があったり安全性が高いのでそっちのほうが推奨されます。
パスワードクラックツール等が数多く存在するので、気をつけましょう。パスワードは単純な単語等にしないようにしなければ。

他にもよく使用される手法にワンタイムパスワード(OTP)があります。
ワンタイムパスワードは認証の際に一度だけ使用されるパスワードになります。
これはPFS(Perfect Forward Secrity)という、攻撃者に情報が奪われても、影響が少ないという考えを実現しているみたいです

ワンタイムパスワードシステムの代表格には、ハッシュ関数みたいな一方向性関数を用いたもの、時刻同期型のもの、2つがあります(むずかしいので詳細は省く)。
AWS等のMFAに使うGoogleの認証アプリみたいなやつは、時刻同期型に入るんですかね。。。?


主体の所持するものによる認証は、ICカード等の物理的デバイスを利用するものです。
ICチップにいろんな情報が記録されています。ICチップすげぇ。。

物理的デバイスは、紛失や盗難の可能性があるので、カードを拾った人が勝手に利用できないように、利用時にPIN等を打ち込むことで対策をします。


主体の身体的な特性による認証では、指紋や虹彩などを用いたものがあります。(生体認証・バイオメトリクス認証

指紋認証は、意外と低コストで実装でき広く普及されていますが、けがなどのトラブルへの対応が難しいことや、樹脂などを使って偽装ができてしまうこと等のデメリットがあります。

虹彩や静脈パターンなどを用いた認証も注目されています。

生体認証は、忘れることやなくすことへの心配がないですが、複製されると変更が難しいことなどが問題点として挙げられます。
また、他人を本人として受け入れてしまう「他人受け入れ」や、本人を拒否してしまう「本人拒否」が問題となり、評価指標としてこの2つの精度を評価するみたいです。


認証プロトコルの基礎

インターネット等の通信路での認証は、以下のような脅威が考えられます。

  • 盗聴
  • 改ざん、ハイジャック
  • なりすまし(スプーフィング)
  • 捏造
  • 再送

それらの脅威に対応するには、認証だけではなく暗号技術などを使う必要があります。そのために必要な複雑な手順を認証プロトコルといいます。

サーバとクライアント間のパスワード認証を考えたとき、まず平文でIDとパスワードをやり取りすることは、安全ではありません。盗聴されたりする恐れがあります。
なので、IDとパスワードをハッシュ関数でハッシュ化してやり取りするという考えがあります。

攻撃者はIDとパスワードはわかりませんが、ハッシュ化された値を盗むことで、次からそのハッシュ値を使って簡単にログインできてしまいます。(再送攻撃)

そこでさらに改善し、認証の際にサーバから毎回変わる乱数をクライアントに送信して、それをハッシュ値に含めるという考えがあります。(Challenge/Response方式)

毎回、変わる乱数値を使うことで、再送攻撃ができなくなります。IDパスワードも盗まれることはありません。これで安全な認証となります。(Challenge/Response認証と呼ばれる、CHAP(Challenge Handshake Authentication Protocol)と呼ばれることもある)

f:id:yabicon:20210511211049p:plain
Challenge/Response認証

一方向に認証するものであると、偽サーバにつながれる可能性もあるので、相互にChallenge/Responseで認証するという方法もあります


公開鍵のペアを用いて認証プロトコルを実現することもできます。認証に使う情報を相手の公開鍵で暗号化して送付する方法と、自分の秘密鍵ディジタル署名して送付する方法の、2つが考えられます。

サーバとクライアント間の相互認証を考えたとき、Challenge/Responseと同じように、クライアントが乱数を生成して、乱数とメッセージを相手の公開鍵で暗号化します。サーバは自分の秘密鍵で復号して 相手(クライアント)の共通鍵で暗号化したメッセージを返すといった内容となります。

f:id:yabicon:20210511211133p:plain
共通鍵を使うChallenge/Response

ディジタル署名を使って認証することもできます。ディジタル署名を用いた方法だと、メッセージが第3者に読み取られる可能性がありますので、DH鍵共有アルゴリズムを使用します。。。

ID連携

ID連携は、利用者のID情報及びそれに付随する属性情報を、別々のITサービス間で、連携して交換する仕組みのことを言います。
つまり、一つのIDでいろんなITサービスが使える用にする仕組みのことを言います。Twitterのアカウントでいろんなサービスを連携できるみたいな感じ?

複数のサービスに対して、各々のアカウント情報を入力してログインするのって不便ですが、それを解消するのにID連携を用いたシングルサインオン(SSO)というものがあります。
SSOでは、一つのサービスにログインすると、ほかの連携しているサービスでも一定時間ログアウトせずに認証操作なしに利用できるようになるというものです。

同様なことを実現する手段としては、各サーバのアカウント情報を同期させたり、LDAP(Lightweight Directory Access Protocol)を用いた認証や、Radiusを用いた認証を行う方法もありますが、 この方法では、各サーバにログイン作業が発生します。

そこで出てきたのがSSOです、SSOにもリバースプロキシ方式や、エージェント方式等が実現方式として挙げられていましたが、異なる組織をまたいだSSOの実現などは困難でした。
そこで出てきたのがID連携という技術です。

ID連携に基づくSSOの基本的な考え方は、連携する組織間であらかじめ連携のための情報を交換して置き、ある組織のITサービスにログインすると別の組織のITサービスも利用できる用にするというものです。


ID連携の標準技術には、主流なものとして、SAML(Security Assertion Markup Language)とOpenIDがあります。どちらもOSSです(誰でも使える)

SAMLは認証認可のプロトコルと、そこで利用する情報の表現についての標準仕様です。
じっそうには、ShibbolethやOpenSAMLというものがあるらしいです。

SAMLでは認証情報の交換によって、連携するWebサービス間での安全なSSOを実現することができます。また、2つのタイプの認可が実現されています。
1つめは属性情報(Authorization Assertion)の交換によるもの。2つめはアクセス制御情報(Authorization Decision Assertion)の交換によるものです。Assertionは利用者の認証情報、属性情報、リソースに関する認可権限情報のことを指します。

SAMLの構成要素には以下があります

  • IdP(identity Probider)
  • SP(service Provider)
  • トラストサークル
  • メタデータ
  • Name Identifier

具体的にやり取りされるメッセージ(SAMLリクエスト、SAMLレスポンス)はXMLアサーションという形で実現されます。

SAMLを用いたSSOのシーケンスには2種類あります。WebブラウザによるSPへのアクセスをトリガーとするもの、IdPへのアクセスをトリガーとするもの

SPへのアクセスをトリガーとするものの実施例
① 利用者がSPへアクセスする
② SPはSAMLリクエストを生成、IdPへHTTPリダイレクトします
③IdPはSAMLリクエストを検証し、利用者を認証します
④ 利用者が認証に成功すると、IdPはSAMLレスポンスを生成し、SPに転送します
⑤ SPはSAMLレスポンスをもとにアクセス制御を行いサービスを展開します。

f:id:yabicon:20210511211239p:plain
SAML

OpenIDは、インターネット上の様々なWebサイトにおける認証を一つのIDで実現します。
URL形式のIDを用いているのが特徴です。。。
認可を目的としたOAuthの機能を含めた次世代版としてOpenID Connectがあります。

構成要素には以下があります

  • OP(OpenID Provider)
  • RP(Relying Party)
  • User-Supplied Identifier
  • Claimed Identifier
  • OpenID AX(Attribute eXchange)(拡張仕様)

OpenIDを用いたSSOは以下の手順です
① 利用者はRPにアクセスし、User-Supplied Identifierとして、CClaimed Identifierを入力するか、OPIdentifierを入力します
② RPは、利用者より入力されたUser-Supplied Identifer からOPを決定し、アクセスします。
③ RPはDH鍵共有アルゴリズムを用いて、OPと暗号鍵を共有します。この暗号鍵はメッセージへの署名に使用されます
④ RPは利用者をOPにリダイレクトして認証を要求します
⑤ OPは利用者を認証します
⑥ OPは認証結果と利用者の情報をRPへリダイレクトします。
⑦ 認証が成功した場合、RPは利用者にサービスを提供します。

f:id:yabicon:20210511211302p:plain
OpenID