研究開発

株式会社セフティーアングルでは,現在下記の研究・開発を行っております。

  1. 携帯端末を活用した3者間認証
    1. ワンタイムパスワード(OTP)認証システム
    2. 共通1-dayパスワード認証システム
    3. 認証シャッター
    4. 情報連携
  2. 中間者攻撃対策

取得特許・特許出願について

はじめに

サービスシステムを利用(ログイン)するとき, その認証方法として現在最も普及しているのが 「ユーザとサービスシステムの2者間で《ユーザID》と《(固定)パスワード》を提示&検証する」 というものです。 (この方法を「(固定)パスワード認証」といいます。)

固定パスワード認証の場合,ユーザIDとパスワードさえわかってしまえば, 他者がなりすましてログイン&サービス利用することが可能となります。 ユーザIDとしてメールアドレスを採用するシステムも多く, ユーザIDは必ずしも秘匿情報とはならないので, なりすまし耐性は,ユーザ自身が定めたパスワードのみに依存する と言ってもいいでしょう。 実際,簡単なパスワードを設定しているために, 辞書攻撃やブルートフォース(総当たり)攻撃が成功してしまった事例は枚挙に暇がありません。 さらに近年は,いわゆる リバースブルートフォース攻撃 や, リスト型アカウントハッキング の脅威も指摘されています。 近年益々利用が拡大されてきているネットワーク上のサービスシステムの安全かつ健全な運用・利用のためには, より安全な認証方法の研究開発は急務であると言えましょう。

1. 携帯端末を活用した3者間認証

我々は,従来の固定パスワード認証が抱える問題点を解決するために, 携帯端末を用いた 【3者間認証】 の研究開発を進めています。 ユーザとサービスシステムの2者間での認証では導入コストがかかったり, システムそのものを再構築せざるをえなかったりすることがあっても, 3者間認証にすることで,それらのコストを削減したり, さらに,システムを跨ぐサービスの提供も比較的容易になります。

下記 1a, 1b, 1c で紹介する 「ワンタイムパスワード認証システム」 「共通1-dayパスワード認証システム」 「認証シャッター」 は,全て,以下の3者間認証が 【基本技術】 となっています。

基本技術

図1:3者間認証 図をクリックすれば,オリジナル画像が別画面で表示されます。 我々が研究開発を進めている3者間認証の構成は図1のようになっています。 【ユーザ】 はスマートフォンなど携帯電話機器で動作する専用アプリを用いて, サービスシステムにおける自身のアカウントに関する 【リクエスト※1【センター※2 に送ります。 センターは,この段階でユーザに対して 「記憶」「所有物(デバイス)」認証をかけます。 つまり,前述のリクエストが正当なユーザから送られてきたことを 2つの要素を用いて検証することになります。 センターは, ユーザからのリクエストに応じて, 対応する 【サービスシステム】 における当該ユーザアカウントに対するコマンドを送り, サービスシステムに設定させます。 サービスシステムが行った設定内容は,センターを介してユーザに通知されます。 ユーザはその通知に従ってサービスシステムを利用します。

ユーザに割り当てられるID情報

ユーザが,①リクエストを送り, 最終的にサービスシステムを利用(ログイン)するまでに, ユーザ,センター,サービスシステムは当該ユーザのID情報を使用します。 この3者が使用する当該ユーザのID情報を全て同一文字列にすると, センターやサービスシステムの内部不正者がユーザになりすましてリクエストを送るなど, セキュリティ上の問題が起こりえます。

図2:ユーザに割り当てられるID情報 図をクリックすれば,オリジナル画像が別画面で表示されます。 このことから,我々のシステムにおいては, 図2のように,ユーザ1人に対して,

以上,3種類のID情報※3を割り当てます※4。 つまり,1人のユーザには UID, AID, MID の3つが割り当てられます。 とはいえ, AID はユーザ所有の携帯端末(専用アプリ)で管理するものであり, MID はサービスシステムおよびセンターで管理するものなので, ユーザが意識して使用するID情報は, ユーザがサービスシステムにログインするときに用いる UID のみです。

以上を踏まえて,図1を説明すると, 「①リクエスト」では, ユーザ(の専用アプリ)は AID を送ることで自身のIDを指定し, 「②コマンド」では, センターは当該ユーザの MID を送ってアカウントを指定します。 その後,ユーザは UID を用いてサービスを利用することになります。

複数のサービスシステムに対する構成

図3:複数のサービスシステムがある場合 図をクリックすれば,オリジナル画像が別画面で表示されます。 我々のシステムにおいては, 1つのセンターに対して複数のサービスシステムを接続させることが可能です。 その場合,図3のように,ユーザはリクエストを送る際, 利用するサービスシステム(のシステムID)をリクエストに添えます。 つまり,必ずしも,サービスシステム毎にセンターを用意する必要はありません。

さらに, すでに構築されているシステム構成に, サービスシステムを追加したり解除したりすることも容易に可能です。

※1, ここでは一般的に「リクエスト」と記述していますが, 具体的には,後述する「ワンタイムパスワードの発行」, 「共通1-dayパスワードの発行」や「認証シャッターの操作」を意味します。

※2, ここでは「センター」と一般的な表記にしていますが, 以下に紹介する各システムにおいては, 「OTP発行センター」「共通1-dayパスワード発行センター」「認証シャッター制御センター」 などのように,その役割を明確にした名称を用います。

※3, 以後,簡単のため「ユーザID」,「アプリケーションID」,「管理マスタID」を, それぞれ UID,AID,MID と表記します。

※4, ユーザ自信は,自分に割り当てられている MID を知りませんし, 同様に サービスシステム/センター はそれぞれ AID/UID を知りません。 このように,3つのID情報に関して三竦みの状態を作ることにより, サービスシステムやセンターの不正を防ぐようにしています。

↑目次へ


1a. ワンタイムパスワード(OTP)認証システム

ワンタイムパスワード認証は, すでに一部,特に金融関係サイトやネットゲームなどのシステムで採用されていますが, 我々の提案するシステムは,従来のワンタイムパスワード認証方式のように「安全性の向上」を目的としていますが, さらに「導入・運用コストの軽減」および「ユーザの利便性の向上」を目指すものとなっています。

図4:OTP認証システム 図をクリックすれば,オリジナル画像が別画面で表示されます。 ユーザは, 図4のように, 利用したいサービスシステムを特定する 【システムID】 を, 【AID】【OTP発行リクエスト】 に添えてOTP発行センターに送ります。(①)

OTP発行センターは, OTP発行リクエストを送ってきたユーザに対して, 「記憶」「デバイス」の2要素認証をかけます。 正当なユーザであることを検証した後, 当該ユーザに対するワンタイムパスワード 【OTP】 を発行し, 利用するサービスシステムに 当該ユーザの【MID】 とともに,発行した OTP を送ります。 (②)

サービスシステムは,当該ユーザの OTP を設定した後, そのOTPの有効期限等の情報(info)も併せて,OTP発行センターに応答を送ります。 (③)

OTP発行センターは,発行したOTP,有効期限等の情報をユーザに通知します。 (④)

ユーザは,UID および, 通知された OTP を用いて,サービスシステムを利用します※5。 (⑤)

現在広く普及している「ハードトークン」を用いたOTP認証システムの場合, トークンの耐タンパー性(すなわち,OTPを生成するアルゴリズム(生成ロジック)の機密性)が非常に重要ですが, トークンを用いたOTP認証システムでは,その最高度の機密性を持つ情報を各ユーザに配付せざるを得ません。 しかし,我々のシステムの場合は,OTPの生成はOTP発行センター1カ所のみで行われるため, 生成ロジックをセンター外部に置く必要はなく,高い機密性が期待でき, さらにその更新も容易です。

※5, ユーザがサービスシステムにログインするときの認証を「OTPのみ」にしなければならないことはなく, 従来の固定パスワードを併用することも可能ですし, そうすることにより,さらに高い安全性を期待することができます。 また,運用環境によっては,ユーザ毎に認証方法を設定することも可能です。

↑目次へ


1b. 共通1-dayパスワード認証システム

【共通1-dayパスワード(Shared One-day Password, SOPw)】 認証システムは, 前述の「 OTP認証システム 」ほどの高い安全性があるわけではありませんが, ユーザの利便性を重視し,さらに従来の固定パスワードよりは高い安全性を期待できる認証システムです。

図5:共通1-dayパスワード認証システム 図をクリックすれば,オリジナル画像が別画面で表示されます。 同一ユーザであれば,ユーザとセンターで共有する AID を, サービスシステムに関わらず同一にして登録することにより, センターはリクエストとして送られてきた AID から,そのユーザが利用するサービスシステムを全て検出でき, その結果,ユーザが利用する全てのサービスシステムに対して一斉にパスワード設定(図1における「② コマンド」)を行うことができます※6

一般に,OTPは有効期限が数分程度に設定され,使用可能回数も(文字通り)1回であることが多いのですが, この有効期限を,例えば「1日※7」とすることで, ユーザは複数のサービスシステムに対して,パスワード発行日に限り,取得した同一パスワードでログインができるようになります。 また,リクエストを送る際,指定されなかったサービスシステムに対しては, パスワードの設定がなされないので,そのアカウントはロックされているのと同様になります。 つまり,そのサービスシステムにおける当該ユーザのアカウントは,後述の 認証シャッター が閉じた状態になり,どのようなパスワードも受け付けなくなります。

近年,インターネットにおけるサービス利用が拡大され, 多くのユーザは自分で記憶できる範囲を超えた「ユーザIDとパスワード」を持っているため, 「ユーザIDを忘れてしまう」ユーザも少なくありません。 その解決策として,

ことができます。 これにより,セキュリティ※8は多少犠牲になる可能性がありますが, ユーザの「ユーザ忘れ」を補完することも可能です。 しかし,この機能は利便性を上げる代わりに安全性を犠牲にする可能性があるので, 採用するかどうかは,サービスシステムの運用方針によるでしょう。

この「共通1-dayパスワード認証システム」のアイデアは, 「共通1-dayパスワード発行センタ構想 」というタイトルで, 経済産業省が平成26(2014)年度に主催した「ID連携トラストフレームワーク・ビジネスモデルコンテスト」に応募し, 平成27年3月13日に開催されたシンポジウム「ID連携トラストフレームワークが築く社会~ID連携による新ビジネス創出への挑戦~」 において奨励賞を受賞しました。

※6, AID を同一にすることは必須ではなく,基本技術を繰り返し実行することでも,複数サービスシステムに対して一斉にパスワード設定することが可能です。ただし,その場合,ユーザとセンター間の通信量が若干増えます。

※7, 「1日」というのは例であり,サービスシステムの運用方針に従って「発行日の23:59まで」 「発行時から24時間」等,ある一定期間を定めることができます。 この有効期限は,前述の OTP認証システム の場合と同様「③応答」において,サービスシステムがセンター伝えることで, そのままユーザに通知することができます。

※8, サービスシステムで設定している UID が,ユーザ自身で決定できる文字列のように, 他者に対して秘匿にすることができる場合, 他者はそのユーザになりすますためのユーザIDの取得が困難になり, これがセキュリティの1要素となり得ます。 しかし, 専用アプリに UID を表示させることで,UID が秘匿であっても, 携帯機器による(センターに対する)認証をパスされるだけで,このセキュリティ要素が消失します。

↑目次へ


1c. 認証シャッター

 共通1-DAYパスワード認証システムの中で、ワンタイムパスワードを発行せず、認証シャッターだけを有効にした方法です。

図7:シャッター施錠の流れ 図をクリックすれば,オリジナル画像が別画面で表示されます。 図6:シャッター開錠の流れ 図をクリックすれば,オリジナル画像が別画面で表示されます。

↑目次へ


1d. 情報連携

図8:情報連携 図をクリックすれば,オリジナル画像が別画面で表示されます。  複数のサービスシステム間の情報をユーザが主体で連携できる仕組みです。オンラインでサービス提供を受ける場合でも、本人確認の為の証明書類を紙に頼っているケースが多いのが実情です。また、事業者は、提出される本人確認書類の真偽を確認する手段が少ない。オンラインで即時確認できない等の問題があり、サービス提供までの時間がかかり、利用者、事業者双方が機会損失をしています。情報連携の仕組みは、上記課題を解決して、安全性を確保しつつ、且、ユーザが関係するサービスシステム間の情報連携ができる仕組みです。1対N N対1のいずれも対応可能です。

↑目次へ


2. 中間者攻撃対策

ネットワーク回線の間に割り込み盗聴・改ざんを行う中間者攻撃(Man In The Middle, MITM)」は, かつてからその問題が指摘されていて,その対策も講じられてきました。 信頼できる公開鍵証明書を用いたSSL/TLS通信(以下,簡単に「SSL」と表記します)はMITM対策案の1つで,現在も広く普及しています。 とりわけ,サービスシステムにログインする際のパスワード送信など, その通信内容が第三者に知られてはならない場合は, 必ずといってもいいほど,SSLが採用されています。

図6:通信路上の中間者攻撃(MITM) 図をクリックすれば,オリジナル画像が別画面で表示されます。 SSL通信においては,公開鍵を用いて ユーザ⇔サービスシステム 間でセッションキーを安全に共有し, ユーザがブラウザに入力した内容は,ブラウザ内のSSLエンジンにおいて(セッションキーで)暗号化されます。 そのため,通信を盗聴しただけでは,ユーザが入力・送信した情報や, サービスシステムからの応答内容は解りません。

しかし,ネットバンキングのサービスにおいて,SSLを介しているにも関わらず, 2013年頃から不正送金の被害額が急上昇しています。 その一因として挙げられているのが, 【中間者攻撃(Man In The Browser, MITB)】 です。 MITBが前述のMITMと大きくことなる点は 攻撃を行う者がユーザが使用しているブラウザに潜んでいる ということです。

図7:ブラウザ内における中間者攻撃(MITB) 図をクリックすれば,オリジナル画像が別画面で表示されます。 ユーザが入力した内容は,SSLエンジンで暗号化される前に,攻撃者の都合がいいように改ざんされます。 改ざんされたリクエストが(SSLで暗号化された上で)サービスシステムに送られ,サービスシステムは一度ユーザにリクエスト内容を確認させますが, その確認内容はユーザのブラウザ内SSLエンジン復号された後, 攻撃者によって元の(ユーザが入力した)内容に書き換えられた上で,ブラウザの画面に表示されます。 したがって,ユーザは攻撃に気づくことなく,そのまま[OKボタン]を押して実行させてしまいますが, 実際にサービスシステムで 実行される内容は,攻撃者によって改ざんされた偽のリクエスト です。

MITB対策の1つとして「トランザクション署名」があります。 これは,ユーザが入力した内容に対する電子署名を別デバイスで計算させ, リクエスト内容とともにその署名値もサービスシステムに送信するというものです。 つまり,リクエスト内容に認証をかけ,サービスシステムにその内容の正当性を証明するのです。

図8:MITB対策 図をクリックすれば,オリジナル画像が別画面で表示されます。 我々の提案する解決策は,電子署名をサービスシステム側で検証するというものではなく, リクエストを入力した(ユーザ所有の)デバイスだけではなく, 別デバイスでも,リクエスト内容をユーザに確認させる というものです。 ユーザが別デバイスでリクエスト内容を確認できるようにするためには,あらかじめ

などのことができるようにしておく必要があります。

このようにすることで,ユーザは 自身が入力・送信した情報を2回確認し,2回[OKボタン]を押す ことになります。 ユーザの利便性は落ちるかもしれませんが,MITBの被害を受けている多くがネットバンキングなどの金融システムであることを考慮すれば, 2回(またはそれ以上)確認させることは,悪いことだけではないかもしれません。

また,リクエスト内容の確認のために別デバイスを用いる場合は, その機器がウイルス等に感染していないことが大前提となります※9 一般的に, MITB対策には,ウイルス感染していないデバイスが少なくとも1つは必要 となります。

※9, 「トランザクション署名」による解決策も,署名生成を行うデバイスがウイルス感染しないことが安全性の必要条件となります。 しかし,トランザクション署名を採用する多くのシステムでは,署名生成は(OTP認証における)ハードトークンのような専用デバイスで行うようになっているので, この前提が守られていることになります。

↑目次へ


取得特許・特許出願について

上記研究開発に関して弊社が 取得した/申請中の 特許は以下の通りです。

【取得済/日本】

  1. 2005年, 特許第3678417号「個人認証方法及びシステム」(3者間認証に関する特許)
  2. 2010年, 特許第4583746号「個人認証方法及び個人認証システム」(上記 補完特許)
  3. 2012年, 特許第5279379号「認証システム及び認証方法」(分轄入力方法に関する特許)
  4. 2013年, 特許第5380583号「デバイス認証方法およびシステム」(携帯端末の機器認証に関する特許,千葉大学と共同出願)
  5. 2015年, 特許第5770354号「サーバーシステム及びリクエスト実行制御方法」(中間攻撃対応に関する特許 千葉大学と共同出願)
  6. 2017年, 特許第6199506号「認証システム及び認証支援システム」(1DAY共通パスワード&情報連携等に関する特許 千葉大学と共同出願)

【申請中/日本】

  1. 携帯端末機種変更対応特許(千葉大学と共同出願)
  2. 振り込め詐欺防止対応特許(千葉大学と共同出願)

【取得済/米国】

  1. 2011年, US8,060,918 [取得済/日本]の 1 に該当
  2. 2012年, US8,290,875 [取得済/日本]の 3 に該当
  3. 2014年, US8,886,928 [取得済/日本]の 4 に該当

【申請中/米国】

  1. 認証システム及び認証支援システム[取得済/日本]の6 に該当

↑目次へ