認証するということ(3)ワンタイムパスワード

認証するということ(3)ワンタイムパスワード

途中で、金融庁の中間とりまとめに対する解説を含めたので、認証することに対する記事が中断していました。今回から再開します。

 

日本で使われているワンタイムパスワード認証には、大きく2つの種類があります。ひとつは、トークンと呼ばれるキーホルダ型のものと(以下の画像では2個写っている、アーモンド型のようなものがそれです)、クレジットカードサイズでテンキーのついているようなハードウエア(以下の画像では中央にあるのがそれです)、またはスマホのアプリが生成するワンタイムパスワードと、メールやSMSで数文字のパスワードがその都度通知されるものです。

 

NIST(アメリカ国立標準技術研究所)のガイドラインでは、この2つは明確に区分されていて、前者のキーホルダ型のハードウエア、またはアプリが生成するものが「ワンタイムパスワード」で、後者のメールやSMSによる通知型は「アウトオブバンド」となっています。ただし、アウトバウンドはメールやSMS通知に限った認証方式ではありません。

それでは「ワンタイムパスワード」について、NISTのガイドラインと、FISC安全対策基準の違いを見ていきましょう。

 

1.単一要素ワンタイムパスワード

まず、「単一要素」というキーワードを説明する必要があります。ワンタイムパスワードを入手するためには「ひとつ」あればよい(それはキーホルダであったり、スマートフォンのアプリだったりします)ことから、単一要素、という言い方になっています。

 

よく使われる例としては、Google認証システムです。QRコード(ここにワンタイムパスワードを計算するためのパラメータが含まれています)を読み込むことで、アプリの起動時にワンタイムパスワードを計算して表示してくれます。アプリの起動にあたっての制約はなく、起動すればワンタイムパスワードが表示されます。

利用者が、スマートフォンにパスワードや指紋認証を登録している場合もありますが、ソフト側で要求しているものではなく、パスワードや指紋認証を設定しなくても、アプリは動きます。ここで重要なのは、「単一」というのは、サービス提供者が求めている要素が「ひとつ」であるということと理解してください。つまり、スマートフォンそのもののセキュリティを高めたとしても、キーホルダを生体認証の金庫にいれて保管していたとしても、それはサービス提供者が要求しているものではないので、「単一」ということになります。

単一の他に、「複数要素」であるMulti-Factor というのもあります。これは、例えば指紋認証を通過しないとワンタイムパスワードが表示されないとか、専用のUSBメディアを接続しないとワンタイムパスワードが表示されないといった、「複数の要素」を入手しなければワンタイムパスワードが手に入らないことを指します。こちらも、サービス提供者が要求することで複数要素ということになります。つまり、単一要素認証を、どのように管理するかは利用者に任されているので、それが机の上に放置されていても、生体認証の金庫に入れていても、サービス提供者から見れば、単一要素に代わりはないということです。

 

生成プロセスにおける基準を見てみましょう。こちらも、抄訳は筆者によって行われています。必ず原文を確認してください。

5.1.4.1 Single-Factor OTP Authenticators

  • 秘密鍵とそのアルゴリズムは、少なくとも112ビット以上の最低限のセキュリティ強度を提供すること。
  • デバイスが利用可能な期間にわたって、デバイスの各動作に対して一意であることを保証するのに十分な長さのワンタイムパスワードが発行できること。
  • ワンタイムパスワード発行機、特にソフトウェアベースのワンタイムパスワード生成ソフトは、秘密鍵の複製が容易にできるようになってはならない。
  • ワンタイムパスワードは、承認されたブロック暗号またはハッシュ関数を使用して、キーとノンス(一度きりの使い捨ての数字)を安全に組み合わせることによって得られること。
  • ワンタイムパスワードの出力は、6桁の小数点以下(約20ビットの情報量)に切り捨てられてもよい。
  • ワンタイムパスワードを生成するために使用されるノンスがリアルタイムクロックに基づいている場合、ノンスは少なくとも2分ごとに1回変更されること。
  • 与えられたノンスに関連するワンタイムパスワードは一度だけ受け入れられること。

こちらの基準は、残念ながらFISC安全対策基準には載っていません。かろうじて、伝送データの暗号化に関する基準(つまりSSL通信)で、「128ビット以上の鍵長を使用する」という記載に留まっていて、これはパスワードや暗号鍵に関する基準ではありません。

いわゆるハードウエアトークンを利用している場合、(NISTのガイドラインを知らなくても)結果として満たせているでしょうし、ソフトウエアを利用するワンタイムパスワードであっても、汎用的なソフトウエア(例えばGoogle認証システム)であれば、作成者に問い合わせてみて、充足しているという回答であれば問題はないものと思われます。ただし、ワンタイムパスワードアプリを、独自に作成するような場合(※)については、上記の基準を満たす必要があります。

※独自に作成する要件としては、先ほど取り上げている「複数要素」として、パスワードを入れないとワンタイムパスワードが発行されないようなソフトウエアにしたい、といった場合や、どうしてもロゴマークを入れたい、といったものが考えられます。ただし、上にあるような条件を満たしているソフトを利用できるのであれば、独自にワンタイムパスワードを発行するようなアプリを作成する必要は必ずしもありません。

 

次に、検証する場合の基準についても見てみます。例によって抄訳は筆者によって行われています。必ず原文を確認してください。

5.1.4.2 Single-Factor OTP Verifiers

  • 単一要素のワンタイムパスワードを検証する場合は、認証機器によって使用されるワンタイムパスワードを生成するプロセスを効果的に複製する。したがって、サービス提供者によって使用される対称鍵は、危殆化から強く保護されること。
  • 単一要素のワンタイムパスワード発行機が加入者アカウントに関連付けられている場合、サービス提供者は、利用者の入力したワンタイムパスワードを複製するのに必要な機密情報を生成し、交換するか、または取得するために承認された暗号を使用すること。
  • サービス提供者は、盗聴と中間者攻撃(MitM攻撃)に抵抗するために、ワンタイムパスワードを収集する際に承認された暗号化と認証された保護されたチャネルを使用すること。
  • 時間ベースのワンタイムパスワードは、発行機が有効期間内に示しつづける時刻と、ワンタイムパスワードが転送されるネットワーク遅延と、ユーザの入力にかかる時間によって決定される、有効期間を有すること。
  • ワンタイムパスワードを再利用する攻撃に対する耐性を提供するために、検証者は有効期間中に1度だけ与えられた時間ベースのワンタイムパスワードを受け入れること。
  • 発行されたワンタイムパスワードが64ビット未満の情報量の場合、検証者は利用者のアカウント上で行われる認証失敗試行回数を効果的に制限する仕組みを実装すること。

こちらも、FISC安全対策基準に明確な記載があるのは、ワンタイムパスワードの入力画面にSSLを使用すること(これはパスワード全般に言えます)と、認証失敗が一定の回数を超えた場合にアカウントの利用を制限する仕組みを設けること、という2点だけでした。

おそらく、ワンタイムパスワードを導入している企業では、自社開発ではなく、パッケージソフトやパッケージモジュールを利用しているものと思いますので、こういった条件を満たしていることを確認することが必要です。特に、ワンタイムパスワードの有効期限内に2回以上の操作(例えば、ログイン)が行われたような場合、初回の操作を受け入れ、2回目以降の操作を拒否するような仕組みは、重要な取引を行う場合には、確実に導入する必要があるでしょう。

 

2.複数要素ワンタイムパスワード

こちらは、「単一要素」が「複数要素」になっただけで、「何かをするとワンタイムパスワードが表示される」というだけです。単一要素に関する記載と重複する部分も多いので、差分だけご紹介します。抄訳は筆者によって行われています。必ず原文を確認してください。

 

5.1.5.1 Multi-Factor OTP Authenticators

  • 複数要素ワンタイムパスワード発行機は、ワンタイムパスワードを取得するためにパスワードの入力または生体情報を必要とすることを除いて、単一要素ワンタイムパスワード発行機と同様の方法で動作すること。
  • ワンタイムパスワードを発行するために発行機に入力するパスワードは、長さが少なくとも6桁の数字または、パスワードに関する要求事項に定められたパスワードであること。
  • 生体認証は、連続した認証失敗回数の制限を含む生体認証に関する基準を満たすこと。

 

5.1.5.2 Multi-Factor OTP Verifiers

  • 複数要素ワンタイムパスワードの検証にあたっては、ワンタイムパスワード以外の要素が提供される必要はないこと。
    • したがって、使用される対称鍵は、危殆化から強く保護されること。
  • 複数要素ワンタイムパスワード発行機が加入者アカウントに関連付けられている場合、サービス提供者は、入力されたワンタイムパスワードを検証するために必要な秘密を生成し、交換するか、または取得するために承認された暗号を使用すること。
  • サービス提供者は、発行機が複数要素に対応していることを確認すること。
  • 複数要素に対応しているという信頼できる情報がない場合、サービス提供者は単一要素として扱うこと。

 

サービス提供者側が、複数要素ワンタイムパスワードを求めることは、現状ほとんどないものと見られます(実態としては、アウトバウンド認証を使っていることが多いからだと思います)。FISC安全対策基準では、アウトバウンド認証についての記載も一部にはありますが、それについては別の記事で取り上げることにしましょう。