How to reinforce password authentications

(1)

パスワード認証の強化策

How to reinforce password authentications

多田充

∗

Mitsuru Tada

千葉大学統合情報センター

Institute of Media and Information Technologies, Chiba University

〒

263-8522

千葉市稲毛区弥生町

1-33

Yayoicho 1-33, Inage, Chiba 263-8522, Japan

概要近年多くの大学では，さまざまな事務処理をWebインターフェース(ブラウザ)で行うようになってきている。構成員は，学内に設置された事務処理(サービス)システムがにログイン(認証)した上でそのサービスシステムを利用するが，多くの大学ではその認証方法として「ユーザID&固定パスワード」による方式を採用している。固定パスワードによる認証は導入が容易であり，すでにネットワーク上の大半のサービスシステムで採用されているためか馴染み深い反面，パスワードクラッキングなどセキュリティ上の問題を多く抱えている。本論文では，既存の固定パスワード認証システムを利用しつつ，学外からのアクセスに対しては「認証シャッター」を経た2要素認証にする方法を述べる。認証シャッターの考え方は2014年に[11]で提案されたもので，シャッターが閉じている間はたとえ正しいユーザIDとパスワードを送信しても，認証サーバへの照会を行わないというものである。これにより，四六時中なりすましログインの窓口を開けている固定パスワード認証システムの安全性を格段に高めることができる。本論文で提案するシステム構成は，ユーザおよびサービスシステムの他にシャッター制御センターを合わせた3者間認証になっており，シャッターを開けるためには，ユーザはシャッター制御センターに対して記憶および所有物の2要素認証をパスする必要がある。そのため，シャッターを開けてログインしたユーザ本人の確からしさ(認証レベル)を上げることができ，より安全にサービスシステムを運用できるようになる。 キーワード: 認証シャッター，3者間認証，2要素認証 ∗_{E-mail: [email protected]} 学術情報処理研究 No.19 2015 pp.40-49

(2)

1 はじめに

近年多くの大学では，さまざまな事務処理を行う際，紙媒体の書類を作成し事務に提出する代わりに，各構成員がWebインターフェース(ブラウザ)で処理を行うようになってきている。学内にその事務処理のための (サービス)サーバが設置され，構成員はそのサービスシステムにブラウザでアクセスして，各々の作業を行うのである*1_{。構成員がサービスシステムを利用するために} は，そのシステムにログイン(認証)する必要があるが，インターネット上のサービスシステムと同様，多くの大学では，その認証方法として「ユーザID＆固定パスワード」による方式を採用している。固定パスワードによる認証は導入が容易であり，すでにネットワーク上の大半のサービスシステムで採用されているためか馴染み深い反面，セキュリティ上の問題を多く抱えている。というのは，固定パスワード認証のなりすまし耐性は，構成員(ユーザ)自身が定めたパスワードのみに依存するからである。123456やpasswordなどは，よく使われるパスワードの代表格であり「弱いパスワード」と呼ばれることがある。実際，簡単なパスワードを設定していたために，辞書攻撃やブルートフォース(総当たり)攻撃が成功してしまった事例は枚挙に暇がない。さらに近年は，いわゆるリバースブルートフォース攻撃や，リスト型アカウントハッキングの脅威も指摘されている。ブルートフォース攻撃は，ユーザIDを固定してパスワードを可能な限り試すというものであるが，リバースブルートフォース攻撃は，パスワードを固定し，ユーザIDを可能な限り変えて試すというものである。大学内のシステムで職員番号や学籍番号(から簡単に割り出せる文字列)をユーザIDにしている場合，ユーザIDのリストを作成するのはそれほど困難なことではないので，リバースブルートフォース攻撃は容易となり得る。パスワードを(例えば123456とかに)固定して，ユーザIDリストを順番に試しことにより，そのパスワードを設定している構成員が1人でもいれば不正ログインが成功してしまう。もちろん，十分複雑なパスワードを設定している構成員は被害に遭わないが，システム運用側としては大きな問題となる。構成員自らが定めた(弱いかもしれない)パスワードで世界中からログインできてしまうこと，窓口をインターネット全体に広げることがセキュリティ上の問題点になりうるため，大 *1千葉大学においても，人事給与，購入・旅費請求，学生の履修登録その他のサービスシステムが設置されている。学内サービスシステムの多くは，大学内ネットワークからのみアクセス(ログイン)を可能にしている*2_。しかし，学外ネットワークからも学内サービスシステムにアクセスできるのが望ましいと考える構成員も多いであろう。とはいえ，固定パスワード認証のサービスシステムをそのまま世界中からアクセス可能にするのは危険なので，その解決策として学外ネットワークからアクセスした場合のみ，認証の強度を上げるということが考えられる。このような策は既にいくつかの大学でも実施されていて，具体的には • 学外からのアクセス(ログイン)の際，ワンタイムパスワード(OTP)認証を行うというものである。例えば，佐賀大学[9]では，ログインのためのOTPを既に登録されている電子メールアドレスに送付するようにしており，関西大学[3]ではパスロジ株式会社によるPassLogicを導入し，利便性とセキュリティの向上を図っている[8]。また，神戸学院大学[5] や南山大学[7]では，事前に配付してある暗号表(乱数テーブル)を用いてOTPを算出させており，慶応大学 [4]では，サイオステクノロジー株式会社によるOTP認証を採用しており[10]，これは，構成員自らが所有するスマートデバイス(iPad, iPhone, Android phone)で動作するソフトトークンを用いたものである。本論文では，固定パスワード認証はそのまま継続し，そのセキュリティを補強する「認証シャッター」の実現方法を提案する。認証シャッターの考え方は[11]で提案されたものであり，シャッターが開いているときのみ， ID&パスワード等によるログインを可能とし(図1)，閉じている場合はログインそのものを拒否する(図2)というものである。ユーザは自らがサービスシステムを利用しようとするとき，まず認証シャッターを開けてからログイン手続きを実行する。[11]では登録電子メールアドレスに認証シャッター操作のためのURLを送るものになっているが，本論文では[2]の3者間認証のアイデアを用いてシステムを構成する。実際には，認証シャッターを制御するサーバ(シャッター制御センター)を設置し，ユーザが外部ネットワーク(大学組織であれば学外ネットワークなど)からサービスシステムを利用するときは，自身が所有するスマートフォンやタブレットな *2メールシステムだけは，「大学内からのみアクセス可能」にしてしまうと構成員から不満が続出する可能性が高いので，インターネット全体，即ち，世界中からアクセス可能にしている大学がほとんどであろう。つまり，VPN など特殊なネットワーク対策をとらない限り，これらの攻撃を防ぐのは不可能であり，特にリバースブルートフォース攻撃は脅威となりうる。

(3)

図1 認証シャッターが開いているとき図2 認証シャッターが閉じているときどの携帯機器で動作する専用アプリを用いて，自身が設定した認証シャッターを操作するためのパスワード(認証シャッター制御パスワード*3₎_{による記憶認証}*4_，および，登録時に携帯機器に保存されている証明書(認証シャッター制御アプリケーションパス*5₎_{による所有物} 認証を経て認証シャッターを開け，その後，従来の固定パスワード認証によりログインする。つまり，学外からのアクセスに対しては(記憶および所有物の)2要素認証となっている。本論文は以下のように構成される。第2章では，学外からのアクセスに対して認証強度を上げるという同一の目的をもつ技術の1つであるワンタイムパスワード認証について紹介する。第3章において，提案システムの構成を述べ，第4章において，プロトコルの詳細を述べる。第5章において，提案システムの安全性および利便性に関する考察，従来方式との比較，既存システムへの導入方法，および，複数サービスシステムの場合のシステム構成について述べる。第6章は本論文のまとめである。 *3簡単のため，以降「シャッターパスワード」と表現する。 *4認証シャッターを開けた後，サービスシステムに対して従来の固定パスワードによる記憶認証をすることになるので，シャッターパスワードは必須ではなく，設定しない場合でも結果的には 2 要素認証にはなる。ただし，携帯機器の紛失/盗難時の安全性は下がる。 *5以降「制御アプリパス」と表記する。

2

3 提案システムの構成

本章では，認証シャッターを実現するための基本原理である3者間認証について述べる。まず，第3.1節でシステムの機器構成を述べ，第3.2節において各機器が保有する情報(データベース)について述べる。 3.1 機器構成 登場するエンティティはユーザ(U)，サービスシステム，シャッター制御センター(C)の3つであるが，ユーザはサービスを利用する(PCなどの)デバイス(UP)と認証シャッターを操作する(スマートフォンやタブレットなどの)スマートデバイス*6₍U_M₎_{を持ち，サービスシ} *6今後「携帯機器」と表現することにする。本論文では，携帯機器として主にスマートフォンを想定しているが，「携帯機器そのものが通信可能」で，かつ「専用アプリを動作させることができる」ものであればよい。また，ユーザがサービスシステムをステムは，ユーザにWebインターフェースを提供する Webサーバ(S)，(固定パスワードで)ユーザを認証する認証サーバ(A)，および認証シャッターの状態を管理するシャッター管理サーバ(M)からなる。図5に，システム全体の構成を示す。_Cと_Mの間はVPN等の安全図5 システム構成な通信回線とし，_Mは_Cおよび_S以外とは通信しないものとする。サービスシステムが複数ある場合でも，1つのシャッター制御センターに複数のサービスシステムを接続させ，すべてのサービスシステムのアカウントをシャッター制御センターで統合的に管理することができるのでシャッター制御センターは1つ設置するだけでよい。本論文では表記を簡潔にするため，サービスシステムは1 つとする*7 ユーザがサービスシステム_Sにログインするときの手続きの概要は以下の通りである。 (1) ユーザは登録時にシャッター制御センター_C から携帯機器_UMのデバイス認証に必要なファイルを受け取っているので，それを_UM(で動作する専用アプリ)を用いて_Cに送り，利用したいサービスシステム_Sの当該アカウントに対する認証シャッターを開けてもらう。 (2) シャッターを開けてもらった後，ユーザは_U_Pで通常のログイン手続きを行う。プロトコルの詳細については第4章で述べる。 3.2 各機器が保有する情報 一般的なサービスシステムがそうであるように，本論文においても，認証サーバ_Aには，ユーザが使用するロ利用するための_UPがUM自身であってもよい。 *7複数のサービスシステムがある場合の統合的な管理方法は [1] で述べられている。[1] は，1 つのセンターから複数のサービスシステムに一時的な共通パスワードを一括設定するシステムを提案しているが，同様の構成が認証シャッターのシステムでも可能である。この構成図については第 5.4 節で述べる。

(5)

グインID*8_{，ユーザが設定した固定パスワード}₍_またはそれを不可逆変換したもの)，および氏名やメールアドレス，所属などの属性情報が保存されているものとする。以下，認証シャッターを操作するための携帯機器(で動作する専用アプリ)UM，シャッター管理サーバ(M)およびシャッター制御センター(C)について述べる。 携帯機器専用アプリ(UM)： UMが保有必須となるのは， • sysID：利用するサービスシステムのID情報 • Pass：登録時にシャッター制御センターから送られてきた制御アプリパスであるが，利便性のため，サービスシステムの名称等があってもよい。また，第4.1節で述べる通り，Passには，シャッター制御センターがアカウントを識別するための管理ID(mID)が含まれている。 シャッター管理サーバ(M)： Mが保有必須となるのは， • uID：ユーザがサービスシステム_SにログインするためのユーザID • mID：当該ユーザが認証シャッターを操作するときに用いる管理ID • sst：認証シャッターの状態 • period：認証シャッターの閉門時刻/門限である。sst は open または closed の 2 値である。 periodは開いているシャッターが閉まる時刻であり， sst = openのときに限り意味を持つ。 シャッター制御センター(C)： Cが保有必須となるのは， • sn：シリアル番号 • mID：ユーザの管理ID • sysID：利用するサービスシステムのシステムID • ust：ユーザの状態 • hcpw：シャッターパスワード (を不可逆変換したもの) • key：制御アプリパス(Pass)をユーザに送るときに使用した暗号化/復号鍵である。ustはユーザが登録の途中か，登録が完了しているかを示す項目で，登録途中(halfway)，登録済(active) などの値*9_を持つ。_key_{は制御アプリパスをサービスシ} ステムに送るとき，および，ユーザがシャッター制御セ *8_{ここではログイン ID を，「ユーザ ID」と呼ぶことにする。} *9_{halfway, active 以外にもアカウントロックなどの状態があって} もよい。ンターに対して登録手続きをする際に必要となり，それ以降は不要となるので，破棄してもよい。またそれとは別に，_Cは制御アプリパスを生成・検証するので，そのために必要な電子署名生成鍵および検証鍵を持つ*10_。

4 各種手続き

ユーザ_U はすでにサービスシステム_S(が従来の固定パスワード認証に利用する認証サーバ_A)に登録されているものとする。組織内ネットワークから_Sにアクセスした場合は，図6のように，通常のパスワード認証が実行される。本章では，認証シャッターを導入したサービ図6 組織内ネットワークからのログインスシステムへの登録(第4.1節および第4.2節)，シャッター操作(第4.3節)，および外部ネットワークからのログイン(第4.4節)の各手続きについて述べる。 4.1 登録手続き(その1) ユーザ_U が組織内ネットワークから_Sにログインしているものとする。ユーザは外部ネットワークからも_S を利用できるようにしたい場合，まず，以下の手続きを実行する。 (R1) Uは，リクエストを_Sに送る。 (R2) Sは，そのシステムID(sysID)とともに，ユーザ追加リクエストを_Cに送る。 (R3) Cは一意的なmIDを生成し，対応するサービスシステムのシステムID(sysID)および当該アカウントに関する情報*11_{に対する電子署名}_σ_{を生成し認} 証シャッター制御アプリケーションパス(Pass = (mID, sysID, σ))を生成する。さらに，鍵keyを生

成しそれを用いてPassを暗号化する。暗号化した

ものをE(Pass)とする*12_{また，当該アカウントに}

対してust← halfwayとする。

*10制御アプリパスに含まれる電子署名は作成者と検証者が同一なので，署名そのものは汎用一方向性関数を用いた MAC(Message Authentication Code) でもよく，公開鍵暗号に基づくものである必要はない。

*11アカウント作成日時等，当該アカウントに関する不変の情報で

(6)

Cはsnに関連づけてmID, key, ustを保存する。 (R4) Cはsn, mIDおよびE(Pass)を_Sに送る。 (R5) Sは_Mのテーブルにデータを追加し，uID, mIDを登録するとともに，sst← closedならびにperiod← ⊥とする。その後，_Sはsn, E(Pass)をU に送る。以上の手続きを図7に示す。図7 登録手続き(その1) 4.2 登録手続き(その2) sn, E(Pass)を受け取ったU(UP)は，その情報を自身の携帯機器UM に入力する必要があるが，S がそれらをQRコード等，携帯機器で容易に読み取れる形式にしておくことで入力の煩わしさを解消できる。_U は sn, E(Pass)をUM(で動作する専用アプリ)に入力し，以下の手続きを行う。 (R6) Uは認証シャッター制御パスワード(cpw)を任意に選び_UMに入力する。 (R7) UMはsn, cpw, E(Pass)をCに送る。 (R8) Cはsnからアカウントを特定し，そのアカウント情報として登録されているustがhalfwayの場合に限り，当該アカウントのkeyを用いてE(Pass)を復号しPassを得る。その後，Passの正当性を検証し，正しい場合は不可逆変換hを用いてhcpw← h(cpw)，さらにust← activeとして登録する*13_。 (R9) CはPassをUMに返す。 (R10) UMは受け取ったPassを，機器固有の情報*14を鍵として暗号化した上で保存する。以上の手続きを図8に示す。 *12C が Pass を暗号化するのは，このときの一度きりで，しかも第 4.2 節で述べる通り，復号するのはC 自身であり，かつ，Pass 自体はそれほど大きなサイズにはならないので，key を使い捨ての鍵として Vernam 暗号を採用することも可能である。

*13_{すでに ust = active となっている場合や，Pass が正しくない}

場合は，登録失敗としてその時点で手続きを停止する。

*14_{機器固有の情報としては，MAC アドレスや UUID, IMEI, 携}

帯電話機器であれば電話番号などが考えられる。図8 登録手続き(その2) 4.3 認証シャッター操作手続き 認証シャッターを開ける/閉じるとき，ユーザはUM を用いて以下の操作を行う。 (C1) UMは機器固有の情報を用いて，Pass等，暗号化されているものを復号する。 (C2) U は認証シャッターを操作するサービスシステムのシステムID(sysID)，操作内容op∈ {open, close} cpwをUMに入力してPassとともにCに送る。 (C3) CはPassに含まれているmIDからアカウントを特定し，Passおよびcpwの正しさを検証する。 (C4) 正しい場合は_MにmIDおよびopを送る。 (C5) Mは，op = openであれば，シャッターを閉める時刻tを定めperiod = tとし*15_{，そうでなけれ} ばperiod = ⊥とする。その後sst, periodを更新し，periodをCに返す。 (C6) CはperiodをUMに送る。以上の手続きを図9に示す。図9 認証シャッターの操作 4.4 サービスシステムへのログイン手続き 組織内ネットワークからログインする場合は本章冒頭に示す図6のような通常の(固定)パスワード認証であるが，外部ネットワークからの場合は，以下のような認証シャッターの状態も考慮されたパスワード認証となる。 *15認証シャッターを開けるのは，ユーザがこれからサービスシステムを利用しようとしているときなので，数分程度で十分であると思われる。

(7)

(A1) Uは_UPを用いて，SでのユーザID(uID)およびパ

スワード(pw)を_Sに送る。

(A2) S はuIDをMに送り，当該ユーザに対する認証

シャッターの状態を照会する。

(A3) MはuIDをキーとしてsstおよびperiodを導出

し，時刻がperiodを過ぎていない場合は sst(= openまたはclosed)を，そうでなければclosedを_S に返す。また，uIDが存在しない*16_{ときや，存在し}

てもperiod =⊥となっている場合はclosedを_S に返す。

(A4) Sは_Mからopenが返ってきた場合のみ，(uID, pw)

を_Aに照会する。そうでない場合はログイン認証失敗として，手続きを終了する。

(A5) Aは(uID, pw)に応じてyesまたはnoを_Sに返す。

(A6) Sはyesが返ってきた場合のみ，_UP にサービスを提供する。多くのWebアプリケーションが，認証が成功した際，ユーザのブラウザにCookieを渡すように，認証シャッターも含めた場合でも，認証が成功した際 Cookieをユーザに渡せば，ユーザがサイト内を移動する度に認証手続きを実行する必要はない。そのため(A6)で認証が成功した場合，_Sが_Mに認証シャッターを閉じるリクエスト(closeShutter)を送ることにより，ユーザがログインした後は他者によるなりすましログインを完全に防ぐこともできる。以上の手続きを図10に示す。図10 外部ネットワークからのログイン

5 考察

第3章および第4章で述べた提案システムの安全性および利便性，従来手法との比較結果，および，既存の固定パスワード認証システムへの認証シャッターの導入方 *16_{uID が}M に存在しないケースは 2 通りある。1 つは元々 A に 登録されていない場合であり，もう 1 つは_{A に存在していて} も，そのユーザが第 4.1 節の登録手続きを実行していない場合である。法について述べる。 5.1 安全性および利便性 通常の固定パスワード認証システムは，ユーザのID およびパスワード，つまりユーザの記憶のみによる認証であり，これが他者に知られると不正アクセスを許すことになる。第 2章で紹介した方法はいずれも固定パスワード認証よりも安全性を高めることを目的としているが，マトリクス認証(第2.1節)は通信路の盗聴やショルダーハッキングの対策としては有効であるが，記憶のみの認証でありブルートフォース攻撃が可能である。乱数表方式(第2.2節)は一見所有物認証にも思えるが，実際には記憶認証と同等である。ハードトークンによる OTP認証(第2.3節)においては，そのトークンを持たない限り正しいパスワード(OTP)を生成できないので，この認証方式は所有物認証となる。ソフトトークンの場合は，そのトークンアプリをどのように登録するかによる。電子メールにOTPを送信する方法については，その電子メールシステムの認証方式による。ユーザ本人の携帯電話機器でないとアクセスできないのであれば所有物認証になるが，PC等からID&パスワードで利用できるようであれば記憶認証になる。提案システムは，登録時にシャッター制御センターから_UMに制御アプリパスPassが渡され，それが専用アプリにより機器の固有情報で暗号化保存される。したがって，機器に保存された情報が漏洩したとしても，それは他の機器では正しく復号されず使用できない。つまり，シャッター制御センターが正しいPassを受信すれば，それは正しい，つまり登録時と同一の機器から送られたことになり，これにより所有物認証になる。以上により，他者による不正ログインが可能となるのは，ユーザ所有の携帯機器_UMが不正使用され，シャッターパスワードおよびログインパスワードを知られたときとなる。一方，提案システムの利便性は，携帯機器で動作する専用アプリのユーザインターフェースによると思われる。_UMで行う処理は「登録」および「シャッターの操作 (open/close)」である。処理の流れを図11に示す。携帯図11 UMの動作

(8)

番号比較項目(略記) マトリクス乱数表ハードトークンソフトトークン提案手法 (i) 認証要素記憶所有物※a _所有物 _記憶※b _記憶 &所有物 (ii) 認証形態※c ₂_者間₁_要素 ₂_者間₂_要素※a ₂_者間₁_要素 ₃_者間₂_要素 (iii) 認証に必要な物体なし乱数表ハードトークンスマートデバイス (iv) (iii)の物体の複製 — 容易困難やや困難困難 (v) (iii)の物体の盗難に※d — 気づきにくい気づきやすい

(vi) (iii)の物体の不正使用※e

— 容易困難 (vii) (iii)の配付コスト※f — 高低表1 従来手法との比較機器の場合，テキストの入力は比較的煩わしい作業となるが，cpwは長くても8∼12文字程度であり，E(Pass) はQRコードを読み取るようにすればよく，しかも登録時のみなので，全体的にユーザにとってストレスとなるような作業は少ないと思われる。ハードトークンのような専用デバイスや紙媒体の表は紛失に気づきにくく，またそれを持ち歩く必要があるが，提案システムの場合は専用デバイスではない，ユーザが一般に携帯している，または携帯しやすいスマートデバイスを利用するので，そのような問題は起こりにくいと考えられる。 5.2 従来手法との比較 ここでは，(固定)パスワード認証の安全性を強化するために普及しているワンタイムパスワード(OTP)による従来の手法と，提案手法との比較を行う。ただし，従来手法においては • OTPを認証に用いる場合であっても，それまでの (固定)パスワードは継続して使用する (つまり認証の際，ユーザID，(固定)パスワード，ワンタイムパスワードの3つを用いる) ものとする。これにより，強化のために追加された要素のみを比較すればよいことになる。比較対象は，マトリクス方式(第2.1節)，乱数表方式(第2.2節)，ハード・ソフトトークン方式(第2.3節)とする。比較項目は (i) 認証要素 (ii) 認証形態 (iii) 認証に必要となる(物理的な)もの (iv) (iii)で必要なものの複製 (v) (iii)で必要なものが盗難された場合に気づくかどうか (vi) (iii)で必要なものが盗難された場合，不正使用されうるかどうか*17*18 *17_{ここでの「不正使用」とは「(iii) の物体に備わっている，認証} に必要な機能を利用すること」としている。つまり，乱数表で (vii) (iii)で必要なものの配付コストとし，比較結果を表1に示す。表1の内容については以下にご留意されたい。 ※a. 乱数表方式は，一般に「所有物認証」とされることが多いが，記載内容が不変(かつ有限)であることから，記憶認証と同様の弱点も持っていると考えられる。実際，乱数表(の内容)は複製が容易であり，覗き見された場合，人間が記憶することは困難であるが，写真等で保存するのは容易である。 ※b. ソフトトークンは，専用アプリのユーザ登録(有効化)のためにユーザIDおよび(固定)パスワードを送るものがほとんどであり，OTPの発行の際，デバイス(所有物)認証をしているわけではないので，記憶認証として分類している。そのため(iv)については，記憶情報のみで複製できることから，ハードトークンや提案手法ほどの困難性を持たないと考えられるので「やや困難」としている。 ※c. 従来手法は「ユーザ⇔サービスシステム」の2者間認証であるが，提案手法はシャッター制御センターも含めた3者間認証になっている。さらに提案手法は，シャッター制御センターがユーザの携帯機器 UMのデバイス(所有物)認証も行う。そのため，提案手法は従来手法に比べ，システム構成や認証プロトコルが複雑にならざるを得ない。 ※d. 乱数表やハードトークンはOTPを得るための専用物体であるため，盗難に気づくことは可能であるが，ユーザが所有しているスマートデバイスに比べ，盗難に気づきにくいと思われる。あればその内容を参照すること，ハード・ソフトトークンであれば，そのアプリケーションを起動し OTP を表示させることであり，さらに，提案手法であれば，認証シャッターを操作するリクエストを送信することである。 *18_{ここでは，(iii) の物体そのものにロックはかかっていない，ま} たは，ロック解除が容易であるとする。

(9)

※e. 乱数表やハードトークンは，(iii)の物体を持っているだけでその機能を利用でき，ソフトトークンについても，脚注18により，(iii)の物体を持っているだけで，その機能を利用できると考えられる。一方，提案手法については，認証シャッターの操作に認証シャッター制御パスワード(cpw)が必要なため， (iii)の物体を持っているだけでは，その機能を利用できない。以上の理由により，提案手法については「困難」とし，それ以外については「容易」とした。 ※f. ソフトトークンおよび提案手法は，それを使用できる状態にする(初期設定を行う)のはユーザ自身であり，システム管理側にとって配付そのもののコストは低いと思われる。それに対して，乱数表およびハードトークンについては，使用できる状態のものをサービスシステム管理者側が用意してユーザに安全に配付する必要があるため，配布コストが高くなると判断した。 5.3 既存システムへの導入方法 既に運用されている，固定パスワード認証を採用しているサービスシステム_Sおよびその認証サーバ_Aがあるとき，そのサービスシステムに認証シャッターを導入するためには，シャッター制御センター，シャッター管理サーバを新規で設置する必要があるが，既存のシステムへの変更は，図6と図10の違いのみである。つまり， Webサーバ_Sのスクリプトに， • 組織外ネットワークからのログインリクエストについては認証シャッターを適用すること； • ログイン画面を通じて送られてきたuIDをMに送り，シャッターの状態sstを照会すること； • Aからの結果authも併せて，ログイン認証の結果

を(auth = yes)∧ (sst = open)とすること； • ログインが成功した場合はシャッターを閉じるリクエストを_Mに送ること；を加筆・修正することである。認証サーバ_Aに変更を加える必要は全くない。 5.4 複数のサービスシステムの場合 一般に大学組織内には複数のサービスシステムが設置されており，しかも，それらの認証機能は同一の認証サーバに担わせていることが多い。組織内のサービスシステムのうち，複数のサービスシステムに認証シャッターを適用させる場合でも，シャッター制御センターおよびシャッター管理サーバは1つ設置すればよく，具体的には図12のように構成することが可能であり，認証サーバは共通であってもシャッター管理サーバはサービスシステム毎に独立させることも可能である。このとき，シャッター制御センターおよびシャッター管理サーバ内のアカウント構造(作り方/属性の種類)を工夫すれば，ユーザはサービスシステムを指定してそのシステムに対してのみシャッターを操作するなど，柔軟な認証コントロールが可能となる。図12 複数のサービスシステムの場合の構成例

6 まとめと今後の課題

本論文では，認証シャッターを適用した3者間-2要素認証システムの仕組みおよび実現方法を述べた。提案システムは，現在最も普及している固定パスワード認証の安全性を，既存システムの変更を極力減らした上で高めることを可能としており，昨今，大学組織等で望まれている「組織外ネットワークからの安全な利用」を実現するための仕組みの1つとなるであろう。昨今猛威を振るっている「リスト型攻撃」は，パスワードが漏洩した時点で，多くの不正ログインを成功させ，民間サイトでは10万件を超える不正アクセスを許した案件もあるが，大学組織で認証シャッターを構築すれば，たとえパスワードが漏洩したとしても，構成員がシャッターを開けた数分間以外，外部からの不正ログインを完全に防ぐことが可能なので，このような外部からの不正ログインの大多数を防ぐことが期待できる。実際に運用する際，問題となるのは， • ユーザが認証シャッター制御パスワード(cpw)を失念した/他者に知られた； • UMを機種変更/紛失した；場合の救済措置であるが，大学組織の場合は，大抵，組織内ネットワークからは通常の固定パスワード認証が採用されるので，内部からログインして_{M, C}に再登録することで解決できる。しかしこの方法は自明なものであ

(10)

り，ユーザが多くのサービスシステムに登録している場合，1つひとつのサービスシステムに対する手間は多くなくとも，全体としてその手間は決して少なくない。そこで，上記等の場合の救済措置プロトコルをユーザの利便性を重要視した上で構築する必要があるが，これについては今後の課題としたい。謝辞本研究の一部はJSPS科研費15K00181の助成を受けたものです。また，本論文を執筆するにあたり助言をいただいた，株式会社セフティーアングルの糸井正幸氏，および，ウィルフォート国際特許事務所の大槻昇氏に，この場を借りて心より感謝申し上げます。

参考文献

[1] 糸井，多田：「共通 1-day パスワード認証システム」，2015年暗号と情報セキュリティシンポジウム(SCIS2015), 2C1-1, 2015. [2] 垣野内，木下，多田，糸井，山岸：「プライバシーを考慮したワンタイムパスワード認証システムの実装」，2012年暗号と情報セキュリティシンポジウム (SCIS2012), 1E2-5, 2012. [3] 関西大学ITセンター：「利用者IDとパスワード」， http://www.itc.kansai-u.ac.jp/start /idpw.html [4] 慶應義塾ITC：「keio.jp におけるワンタイムパスワードについて」， http://www.itc.keio.ac.jp/ja /keiojp otp.html [5] 神戸学院大学情報支援センター：「学内システム一覧，学内情報サービス(在学生・教職員対象)」， http://www.kobegakuin.ac.jp/facility /ipc/system-lst.html

[6] L. Lamport: Password authentication with in-secure communication, Communications of the

ACM, vol.24, no.11, pp.770-772, 1981.

[7] 南山大学：「学外からの使いかた (Can@home)」， http://office.nanzan-u.ac.jp/CAN /can usage.html [8] パスロジ株式会社：「【導入事例】学校法人関西大学様」， http://www.passlogy.com/introduction /02-2 [9] 佐賀大学総合情報基盤センター：「シングルサインオン、セキュリティ強化のための多要素認証導入」， http://www.cc.saga-u.ac.jp/plan /webnews.php?num=365 [10] サイオステクノロジー株式会社：「サイオスが開発したワンタイムパスワード認証システム，慶應義塾の認証基盤に採用 ∼ Shibboleth(シボレス)認証用ワンタイムパスワードモジュールとワンタイムパスワード用秘密鍵発行システムを提供 ∼」， http://i.sios.com/news/press /20141022-otp.html [11] 高田：「Authentication shutter: 個人認証に対する攻撃を遮断可能する対策の提案」，コンピュータセキュリティシンポジウム(CSS)2014, 3C1-3, 2014.

How to reinforce password authentications

パスワード認証の強化策