認証するということ(2)乱数表

認証するということ(2)乱数表

「認証するということ」の第二回は、前回のパスワードに続いて、乱数表はどのように管理されるべきなのか、NIST(アメリカ国立標準技術研究所)のガイドラインと、FISC安全対策基準の関係について確認することにしましょう。

 

パスワードが「記憶に頼る」認証方式であるとするならば、乱数表は「持ち物に頼る」認証方式と言っても良いでしょう。以前からインターネットバンキングで利用されている乱数表ですが、FISC安全対策基準では、「乱数表を使う」ということ以上に具体的な基準は確認できませんでした。

 

一般的に、乱数表には、再利用可能なものと、再利用不可能なものに大別されます。

 

再利用可能なものとしては、表形式になっているもので、銀行では、クレジットカードのような大きさで、プラスチックや、撥水加工された紙に、たとえば10桁だったり、表形式だったしますが、ランダムな英数字を出力して配布しています。振込時に、「3番目、7番目、9番目、10番目の数字を入れる」というものだったり、「A3、F2、G1、C4の数字を入れる」というものだったりします。これが再利用可能なものです。

 

逆に、再利用不可能なものとしては、Googleのアカウント認証やDropboxで使用される「緊急用コード」が代表例としてあげられます。1回の発行で10個までのコードが発行されますが、このコードは1回限りの使い捨てとなっていて、1回使用すると、そのコードは利用できなくなります(つまり、10個のコードのうち、1個を使った場合、残りの有効なコードは9個ということになります)。

 

FISC安全対策基準では、どちらの記載も例として取り上げられていますが、どちらについても、明確な技術的基準は定められていませんでした。

 

Digital Identity Guidelines –Authentication and Lifecycle Management–(NIST):https://pages.nist.gov/800-63-3/sp800-63b.html

 

NISTガイドラインの基準 判定 FISC安全対策基準の記載
生成フェーズ 乱数表を作成するサービス提供者は、承認された乱数生成装置を使用してリストを生成し、利用者に安全に配布すること。(5.1.2.1) × 記載なし
乱数表は少なくとも20ビットの情報量ーを持つこと。(5.1.2.1) 「十分に複雑な乱数表を用いる」という参考記載はあるが、具体的なレベルの記載なし。
配布フェーズ 乱数表は、サービス提供者によって直接配布されるか、利用者に郵便で送付されるか、またはオンラインで配布される。(5.1.2.1) 「発行、保管、交付、回収及び廃棄の管理方法を明確にする」ということだけは記載されている。
オンラインで配布されている場合、乱数表は要件に従って安全なチャネルで配布されるものとする。(5.1.2.1) × 記載なし
利用フェーズ 利用者が乱数表をリストから順に使用する場合、利用者は使用済みの秘密を廃棄することができるが、認証に成功した後にのみ行う。(5.1.2.1) × 記載なし
乱数表を検証する際は、利用者に対して特定の(例えば、番号付きの)乱数表の項目を要求するプロンプトを出すこと。(5.1.2.2) × 記載なし
サービス提供者から与えられた乱数表は、一度だけ使用されること。乱数表が表形式となっている場合、表中のセルは一度だけ使用されること。(5.1.2.2) 「一定期間経過または一定の取引回数ごとに乱数表を更新する」といった参考記載はあるが、本文中に明確な記載なし。
サービス提供者は、盗聴や中間者攻撃(MitM攻撃)に抵抗するために、乱数表の利用を要求する際に、承認された暗号化と認証された保護されたチャネルを使用すること。(5.1.2.2) パスワードの項目と同様、SSLを利用することについて記載がある。
64ビット未満の情報量を持つ乱数表の場合、サービス提供者は利用者のアカウント上で行われる認証失敗試行の回数を効果的に制限するレート制限メカニズムを実装すること。(5.1.2.2) 情報量に関係なく、認証失敗が一定回数を超えた場合のアカウント制限については記載あり。
保管フェーズ 検証者は、オフライン攻撃に耐えられるように乱数表を格納しなければならない。 × 乱数表の生成方法に関する記載なし。
少なくとも112ビットの情報量を持つ乱数表は、一方向関数でハッシュされること。 × 乱数表の生成方法に関する記載なし。
112ビット未満の情報量を持つ乱数表は、適切な一方向関数を使用してソルトされ、ハッシュされること。 × 乱数表の生成方法に関する記載なし。
ソルト値は、少なくとも32ビットの長さであり、格納されたハッシュ間のソルト値の衝突を最小限に抑えるために任意に選択されること。 × 乱数表の生成方法に関する記載なし。
ソルト値と結果のハッシュは、乱数表ごとに格納されること。(5.1.2.2) × 乱数表の生成方法に関する記載なし。

NISTガイドラインの抄訳とフェーズ分けは、筆者が行っています。誤訳の可能性は否定できませんので、必ず原文を参照いただくようにお願いします。

 

 

注意:ソルトとは、短いテキストに付加する「意味のないテキスト」のことです。一般的に、数文字のハッシュであれば、事前に計算結果を取得しておくことで、ハッシュから元のテキストを推測することができてしまいます。このため、元のテキストに「意味のないテキスト」を追加することで、ハッシュをより複雑なものにしておくのです。なお、「計算しておいたハッシュ値から元のパスワードを推測する攻撃のことをレインボー攻撃といいます。もちろん、ソルトはパスワードと同様にランダムな文字の方が良いです

 

 

FISC安全対策基準の次の版では、乱数表を利用する場合の基準というのも、明確に示される必要があるように思います。銀行によっては、10桁程度の数字のみを利用しているところもありますから、必須基準として桁数を明示することは難しいでしょうが、推奨レベルとして、やはりNISTレベル(つまり20ビット以上の情報量)を推奨することになるものと思われます。

 

ここで、情報量について、少しだけ触れておきます。簡単に言えば、「確率を2を底とする対数で表記したものの絶対値」です。つまり、確率がコインの裏表が当たる確率は0.5ということになりますから、\(log_{2}{0.5}=-1\)なので、絶対値は1ということになります。確率が0.25(\(\frac{1}{4}\))の場合は2、確率が0.125(\(\frac{1}{8}\))の場合は3が情報量ということになります。このため、情報量が20以上ということになると、\(2^{20}\)、つまり1,048,576パターン以上が存在することが条件となります。この数字だけを見ると大きな数に見えます。

 

次に、実際の乱数表の使用方法として、指定された4つの枠に示された文字を入力することを考えます。それぞれの枠には、0から9までの数字か、AからZまでのアルファベットが含まれていると仮定します。すると、1つの枠は10+26=36パターン存在しますから、4つの枠では\(36^{4}\)、つまり、4つの文字が完全に一致する確率は\(\frac{1}{1,679,616}\)です。この情報量を計算すると、\(-log_{2}{36^{4}}=20.68\)となります。これで、情報量20ビットを超えることになります。

 

これが、数字のみで情報量20ビットを超えようとすると、桁数はどうなるでしょうか。1つの枠には10パターンの文字が含まれることになりますから、\(-log_{2}{10^{7}}=23.25\)となるため、7桁以上の数字が必要ということになります(6桁だと、情報量は\(-log_{2}{10^{6}}=19.93\)なので不足することになります)。

手元にある乱数表から、情報量を計算してみました。

銀行 文字種 桁数 情報量
A銀行 英数字 50個 \(-log_{ 2 }{36^{50}}=258.49\)
B銀行 数字のみ 7個 \(-log_{2}{10^{7}}=23\)
C銀行 数字のみ 12個 \(-log_{2}{10^{12}}=39\)
D銀行 数字のみ 25個(ただし数字は2桁) \(-log_{2}{100^{25}}=166\)
E銀行 数字のみ 100個 \(-log_{2}{10^{100}}=332\)

 

当然といえば当然ですが、文字種が増えるほど、桁数が増えるほど、情報量は増えていくということになります。

 

もちろん、「表中のセルは一度だけ使用される」という原則がありますから、例えば英数字4文字や、数字7桁だけで構成された乱数表は、1回しか使えないことになります。このため、例えばA銀行の場合は、1回あたり4文字ずつ利用するような場合を考えると、12回分しかありません。D銀行の場合は1回あたり7文字使いますから、14回分しかない、ということになります。

 

そして、次に気になる「64ビット未満の情報量を持つ乱数表の場合、サービス提供者は利用者のアカウント上で行われる認証失敗試行の回数を効果的に制限するメカニズムを実装する」原則についても考えてみましょう。

 

FISC安全対策基準では、IDまたはパスワード誤りの回数が規定以上に達した場合は、取引を禁止することを定めています(余談ですが、暗証番号の場合はカードを使用禁止にする、という基準もあります)。なので、こちらはNISTよりも厳しい基準となっていると理解して良いでしょう。

 

他に、NISTの考え方と異なる部分としては、「乱数表」という記載はあるものの、もともと金融機関向けということもあり、「再利用可能なもの」を主眼においた記載が多く、「再利用不可能なもの」を想定しているような記載は2カ所のみでした。このため、「乱数表のすべての情報の入力は求められないこと」を利用者に周知するような基準がありました。これは、使い捨て型の乱数表はあまり利用されていないことから、このような記載になったものと推定されます(当然ですが、使い捨て型の乱数表であれば、1個のコードは1回ですべて入力される必要があります)。

 

パスワード、乱数表とみてきましたので、次回はワンタイムパスワードについて確認してみることにします。パスワード、乱数表、ワンタイムパスワードの使い分けについても、NISTには明確な基準があります。それも、追ってご紹介します。