特開2022-28727 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ オラクル・インターナショナル・コーポレイションの特許一覧

特開2022-28727多様なソースからのエントロピの収集

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022028727

(43)【公開日】2022-02-16

(54)【発明の名称】多様なソースからのエントロピの収集

(51)【国際特許分類】

G06F 7/58 20060101AFI20220208BHJP

G09C 1/00 20060101ALI20220208BHJP

【ＦＩ】

G06F7/58 620

G09C1/00 650B

【審査請求】有

【請求項の数】1

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2021180373

(22)【出願日】2021-11-04

(62)【分割の表示】P 2019510302の分割

【原出願日】2017-03-06

(31)【優先権主張番号】62/377,488

(32)【優先日】2016-08-19

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/395,961

(32)【優先日】2016-09-16

(33)【優先権主張国・地域又は機関】US

(71)【出願人】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】デール，ポール・ティモシー

(72)【発明者】

【氏名】ガウティエ，ピィ・デニス

(57)【要約】（修正有）

【課題】擬似乱数発生器および他のエントロピ消費機器のためにエントロピを生成するための方法、装置及びシステムを提供する。
【解決手段】方法は、第１の繰り返しタイマを第１の周波数に設定するステップと、第２の繰り返しタイマを第２の周波数に設定するステップと、予め定められた数の第１のビットを第１のエントロピソースから上記第１の周波数で収集するステップとを含む。予め定められた数は、第１のエントロピソースに起因するビット当たりのエントロピの量に基づく。方法はさらに、第１のビットを擬似乱数発生器に提供するステップと、特定の数の第２のビットを第２のエントロピソースから第２の周波数で採集するステップと、を含む。特定の数は、第２のエントロピソースに起因するビット当たりのエントロピの量に基づく。方法はさらに、第２のビットを擬似乱数発生器に提供するステップを含む。
【選択図】図１

【特許請求の範囲】

【請求項1】

コンピューティングデバイスにおいてエントロピを生成するための方法であって、
第１の繰り返しタイマを第１の周波数に設定するステップと、
第２の繰り返しタイマを第２の周波数に設定するステップと、
予め定められた数の第１のビットを第１のエントロピソースから前記第１の周波数で収集するステップとを備え、前記予め定められた数は、前記第１のエントロピソースに起因するビット当たりのエントロピの量に基づき、前記方法はさらに、
前記第１のビットを擬似乱数発生器に提供するステップと、
特定の数の第２のビットを第２のエントロピソースから前記第２の周波数で採集するステップとを備え、前記特定の数は、前記第２のエントロピソースに起因するビット当たりのエントロピの量に基づき、前記方法はさらに、
前記第２のビットを前記擬似乱数発生器に提供するステップを備え、
それによって、前記第１および第２のビットを使用して前記擬似乱数発生器をシード処理することができる、方法。

【請求項2】

前記第１の周波数を定期的に調節するステップをさらに備える、請求項１に記載の方法。

【請求項3】

前記第１の周波数を調節するステップは、前記擬似乱数発生器からの出力に基づく、請求項２に記載の方法。

【請求項4】

前記調節するステップは、前記第１の周波数の最大５％まで加算または減算するステップを含む、請求項２に記載の方法。

【請求項5】

第１の周波数の調節の周期性は、ランダム化される、請求項２に記載の方法。

【請求項6】

第１の周波数の調節の周期性は、５秒から６０秒の範囲内である、請求項２に記載の方法。

【請求項7】

前記擬似乱数発生器からの出力に基づいて前記第２の周波数を定期的に調節するステップをさらに備える、請求項２に記載の方法。

【請求項8】

前記収集するステップの際に前記第１のビットをアキュムレーションバッファに受け入れるステップと、
前記アキュムレーションバッファがフルになると前記第１のビットを前記アキュムレーションバッファから前記擬似乱数発生器に提供するステップと、
それによって、第１のビットの単一の収集におけるサドンエントロピよりも多くの量のサドンエントロピを提供するステップとをさらに備える、請求項１に記載の方法。

【請求項9】

収集された連続する第１のビット間のハミング距離を計算するステップと、
前記計算されたハミング距離が最小値を超えたことに基づいて、前記収集された第１のビットを前記アキュムレーションバッファに受け入れるステップとをさらに備える、請求項８に記載の方法。

【請求項10】

第１のビットの連続的な収集間のハミング距離と、前記アキュムレーションバッファのコンテンツに起因するエントロピの累積値とを合計するステップと、
前記エントロピの累積値を前記擬似乱数発生器に提供するステップとをさらに備える、請求項８に記載の方法。

【請求項11】

後続の収集の前に前記アキュムレーションバッファを空にするステップをさらに備える、請求項８に記載の方法。

【請求項12】

前記アキュムレーションバッファは、第１のアキュムレーションバッファであり、前記方法はさらに、
前記採集するステップの際に前記第２のビットを第２のアキュムレーションバッファに受け入れるステップを備え、前記第２のアキュムレーションバッファは、前記第１のアキュムレーションバッファのサイズとは異なるサイズを有し、前記方法はさらに、
前記第２のアキュムレーションバッファがフルになると前記第２のビットを前記第２のアキュムレーションバッファから前記擬似乱数発生器に提供するステップを備える、請求項８に記載の方法。

【請求項13】

第１または第２の周波数は、０．１２８７秒に１回、０．１３秒に１回、０．１３７０秒に１回、０．１５秒に１回、０．２５秒に１回、０．７１５秒に１回、０．７５１秒に１回、０．７５３秒に１回、１．１３秒に１回、１．２７秒に１回、１．６６２６秒に１回、２秒に１回、２．２２２秒に１回、２．２４２７秒に１回、４．４秒に１回、４．９秒に１回、５．９秒に１回、９．８１秒に１回、１０．０００秒に１回、１１．９１３秒に１回、および１５秒に１回からなる群から選択される、請求項１に記載の方法。

【請求項14】

前記第１または第２のエントロピソースは、瞬間的または累積的な中央処理装置（ＣＰＵ）使用量；物理的または仮想メモリ使用量；ネットワークトラフィック量；高解像度クロックの最下位時間値；入力／出力（ＩＯ）統計；Intel x86 RDRAND命令；Intel x86 RDSEED命令；Intel Itanium ar.itcレジスタ；UNIXまたはLinux /dev/randomファイル；UNIXまたはLinux /dev/urandomファイル；OpenBSD, SolarisまたはLinux getentropyシステ
ムコール；SolarisまたはLinux getrandomシステムコール；Microsoft Windows CryptGenRandom関数；Linux /proc/diskstatsファイル；Linux /proc/interruptsファイル；Linux
/proc/meminfoファイル；Linux /proc/net/devファイル；Linux /proc/timer_listファ
イル；Linux/S390 /dev/prandomファイル；BSD Unix /dev/srandomファイル；Microsoft Windows win_processesモジュール；およびユーザインターフェイス情報ソースからなる
群から選択される、請求項１に記載の方法。

【請求項15】

前記第１のビットまたは第２のビットに基づいて前記擬似乱数発生器を介して乱数を生成するステップをさらに備える、請求項１に記載の方法。

【請求項16】

前記第１のタイマまたは前記第２のタイマを設定するステップは、システムコールを行うステップを含む、請求項１に記載の方法。

【請求項17】

前記予め定められた数の第１のビットを収集するステップおよび前記特定の数の第２のビットを採集するステップは、それぞれの前記タイマのイベントを作動させると行われる、請求項１に記載の方法。

【請求項18】

前記擬似乱数発生器は、数字、文字および他の記号を生成するように構成される、請求項１に記載の方法。

【請求項19】

擬似乱数発生器においてエントロピをシード処理するための方法であって、
異なる周波数の非同期タイマを設定するステップと、
前記非同期タイマのうちの第１のタイマに従って、予め定められた数の第１のビットを第１のエントロピソースから収集するステップと、
収集された連続する第１のビット間のハミング距離を計算するステップと、
前記ハミング距離が最小値を超えたことに基づいて前記第１のビットを第１のアキュム
レーションバッファに受け入れるステップと、
第１のビットの連続的な収集間のハミング距離と、前記第１のアキュムレーションバッファのコンテンツに起因するエントロピの累積値とを合計するステップと、
前記第１のアキュムレーションバッファのコンテンツを擬似乱数発生器に提供するステップと、
前記非同期タイマのうちの第２のタイマに従って、特定の数の第２のビットを第２のエントロピソースから採集するステップと、
前記第２のビットを第２のアキュムレーションバッファに受け入れるステップとを備え、前記第２のアキュムレーションバッファは、前記第１のアキュムレーションバッファのサイズとは異なるサイズを有し、前記方法はさらに、
前記第２のアキュムレーションバッファのコンテンツを前記擬似乱数発生器に提供するステップを備える、方法。

【請求項20】

前記非同期タイマの周波数にジッターを生じさせるステップをさらに備える、請求項１９に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、２０１６年９月１６日に出願された米国仮出願番号第６２／３９５，９６１号および２０１６年８月１９日に出願された米国仮出願番号第６２／３７７，４８８号の利益を主張し、これらの内容は、全ての目的で全文が引用によって本明細書に援用される。

【0002】

背景
１．発明の分野
本願は、一般に電気的なデジタルデータ処理に関し、具体的には乱数もしくは擬似乱数発生器のシード処理または他の目的のためにエントロピを採集する技術に関する。

【背景技術】

【0003】

２．関連技術の説明
ＯｐｅｎＳＳＬエントロピモデルは、いくつかの方面で弱いと考えられている。現状では、それは、いかなる新たな連邦情報処理標準（Federal Information Processing Standards：ＦＩＰＳ）証明書についてもエントロピについての警告を生じさせることはないであろう。さらに、アメリカ国立標準技術研究所（National Institute of Standards and Technology：ＮＩＳＴ）は、ＦＩＰＳ認証の一部としてエントロピソースへの関心を高めており、将来のある時点で妥当なエントロピモデルが義務付けられることになる可能性が高い。いくつかのプラットフォーム、特にＳｏｌａｒｉｓ（登録商標）オペレーティングシステム、上でのＯｐｅｎＳＳＬのエントロピが他のものよりもはるかに優れていることは注目に値する。特に、オラクルフュージョンミドルウェアおよびデータベース構成は、一般に、さまざまなプラットフォーム上で高いレベルのセキュリティを必要とする。ＯｐｅｎＳＳＬにおけるエントロピの向上は、他の構成のためにもなり得る。

【0004】

ＦＩＰＳモードでは、ＯｐｅｎＳＳＬは内部エントロピを持たない。それは、ホスティングアプリケーションにそのエントロピの全てを提供するように完全に依拠する。何かが提供されたことを確認するためのチェックはあるが、ＯｐｅｎＳＳＬは、エントロピの品質に関与することはなく、内部擬似乱数発生器（pseudorandom number generator：ＰＲ
ＮＧ）を再シード処理することはなく、これらはユーザの問題とされている。ユーザはさまざまであるので、供給されるエントロピの品質もさまざまである。ユーザがエントロピソースを適切に評価するための十分な時間または専門知識を持っていないということは十分あり得る。

【0005】

ＦＩＰＳモード以外では、ＯｐｅｎＳＳＬは、/dev/urandomから３２バイト－２５６ビット－のエントロピを読み出し、それを内部ＰＲＮＧのためのシードとして使用する。名目上、それがＰＲＮＧを再シード処理することはないが、ユーザがアプリケーションプログラミングインターフェイス（application programming interface：ＡＰＩ）を呼び出
してそれを行う場合がある。ＮＩＳＴは、/dev/urandomをゼロエントロピを提供するものとして評価しているが、実際には無いよりはましという程度である。

【0006】

ＯｐｅｎＳＳＬは、接続の数またはスレッドの数に関わらず、その存続期間全体にわたって単一のグローバル擬似乱数発生器を有する。これは、ＰＲＮＧのセキュリティ侵害の場合にＯｐｅｎＳＳＬがフォワードセキュリティをほとんどまたは全く提供しないことを意味する。それにひきかえ、他のＴＬＳ（トランスポートセキュリティ層）パッケージは、各々がグローバル乱数発生器からシード処理される複数の乱数発生器を維持し、このような保護を提供する。

【0007】

ＯｐｅｎＳＳＬバージョン１．１は、アドホックベースではあるがいくらかのエントロピを内部で生成しようとするが、品質または生成する量を定量化しようとする試みはなされていないように思われる。当該エントロピモデルの残りの部分は、ＯｐｅｎＳＳＬバージョン１．０と変わらない。

【0008】

ＯｐｅｎＳＳＬのデフォルトエントロピモデルがその擬似乱数発生器ストリームを再シード処理することがなく、分離することもないので、ＰＲＮＧのセキュリティを侵害する攻撃者は、後続の全ての接続を切断することができる。理論的には、十分なリソースを持つ攻撃者は、暗号化された通信を保管し、１年かけて秘密通信の最初の部分を解読して、その時点以降は何もかも読み出すことができるようになる。このような情報の遅れ（lag in intelligence）は、予想される秘密存続期間の範囲内に十分に収まるであろう。言い
換えれば、前方秘匿性には再シード処理が必要とされ得る。

【0009】

暗号化および他の用途のためにさらに優れた、よりエントロピ的なＰＲＮＧのシード処理が当該技術分野において必要である。

【発明の概要】

【課題を解決するための手段】

【0010】

簡単な概要
コンピューティングデバイスにおける擬似乱数発生器および他のエントロピ消費機器のためにエントロピを生成するための方法、装置およびシステムが概して記載されている。タイマイベントを繰り返しトリガするように複数のソフトウェアタイマが設定される。各タイマは、ハードウェアソースかソフトウェアソースかに関わらず、異なるエントロピソースに対応する。タイマイベント中に、予め定められた数のビットがエントロピソースから収集または採集される。予め定められた数は、エントロピソースからのビット当たり予想されるエントロピの量に基づき、理論的に導き出されるか、または実験的に測定されてもよい。ビットは、シードとして擬似乱数発生器に提供される。他のエントロピソースも同様にポーリングされる。

【0011】

タイマの周波数は、擬似乱数発生器からの出力に基づいてジッターを生じさせられ得る。エントロピビットは、より大きな塊で擬似乱数発生器に送信される前に、バッファに蓄積され得る。

【0012】

本願のいくつかの実施形態は、コンピューティングデバイスにおいてエントロピを生成するための方法に関する。上記方法は、第１の繰り返しタイマを第１の周波数に設定するステップと、第２の繰り返しタイマを第２の周波数に設定するステップと、予め定められた数の第１のビットを第１のエントロピソースから上記第１の周波数で収集するステップとを含み、上記予め定められた数は、上記第１のエントロピソースに起因するビット当たりのエントロピの量に基づき、上記方法はさらに、上記第１のビットを擬似乱数発生器に提供するステップと、特定の数の第２のビットを第２のエントロピソースから上記第２の周波数で採集するステップとを含み、上記特定の数は、上記第２のエントロピソースに起因するビット当たりのエントロピの量に基づき、上記方法はさらに、上記第２のビットを上記擬似乱数発生器に提供するステップを含む。上記第１および第２のビットを使用して上記擬似乱数発生器をシード処理することができる。上記第１および第２の周波数は、互いに異なっていてもよい。さらに、それらは、異なっていてもよく、互いの整数倍ではない（すなわち、調和していない）。

【0013】

上記第１の周波数は、定期的に調節されてもよい。上記第１の周波数は、上記擬似乱数発生器からの出力に基づいて調節されてもよい。上記調節するステップは、上記第１の周
波数の最大５％まで加算または減算するステップであってもよい。第１の周波数の調節の周期性は、ランダム化されてもよい。第１の周波数の調節の周期性は、５秒から６０秒の範囲内であってもよい。上記第２の周波数は、上記擬似乱数発生器からの出力に基づいて定期的に調節されてもよい。

【0014】

上記方法は、上記収集するステップの際に上記第１のビットをアキュムレーションバッファに受け入れるステップと、上記アキュムレーションバッファがフルになると上記第１のビットを上記アキュムレーションバッファから上記擬似乱数発生器に提供するステップと、それによって、第１のビットの単一の収集（collection）におけるサドンエントロピ（sudden entropy）よりも多くの量のサドンエントロピを提供するステップとをさらに含んでもよい。上記方法は、収集された連続する第１のビット間のハミング距離を計算するステップと、上記計算されたハミング距離が最小値を超えたことに基づいて、上記収集された第１のビットを上記アキュムレーションバッファに受け入れるステップとをさらに含んでもよい。上記方法は、第１のビットの連続的な収集間のハミング距離と、上記アキュムレーションバッファのコンテンツに起因するエントロピの累積値とを合計するステップと、上記エントロピの累積値を上記擬似乱数発生器に提供するステップとを含んでもよい。上記方法は、後続の収集の前に上記アキュムレーションバッファを空にするステップを含んでもよい。上記アキュムレーションバッファは、第１のアキュムレーションバッファであってもよく、上記方法はさらに、上記採集するステップの際に上記第２のビットを第２のアキュムレーションバッファに受け入れるステップを含んでもよく、上記第２のアキュムレーションバッファは、上記第１のアキュムレーションバッファのサイズとは異なるサイズを有し、上記方法はさらに、上記第２のアキュムレーションバッファがフルになると上記第２のビットを上記第２のアキュムレーションバッファから上記擬似乱数発生器に提供するステップを含んでもよい。

【0015】

【0016】

上記第１または第２のエントロピソースは、瞬間的または累積的な中央処理装置（ＣＰＵ）使用量；物理的または仮想メモリ使用量；ネットワークトラフィック量；高解像度クロックの最下位時間値；入力／出力（ＩＯ）統計；Intel x86 RDRAND命令；Intel x86 RDSEED命令；Intel Itanium ar.itcレジスタ；UNIX（登録商標）またはLinux（登録商標） /dev/randomファイル；UNIXまたはLinux /dev/urandomファイル；OpenBSD, Solarisまた
はLinux getentropyシステムコール；SolarisまたはLinux getrandomシステムコール；Microsoft Windows（登録商標） CryptGenRandom関数；Linux /proc/diskstatsファイル；Linux /proc/interruptsファイル；Linux /proc/meminfoファイル；Linux /proc/net/dev
ファイル；Linux /proc/timer_listファイル；Linux/S390 /dev/prandomファイル；BSD Unix /dev/srandomファイル；Microsoft Windows win_processesモジュール；およびユー
ザインターフェイス情報ソースからなる群から選択されてもよい。

【0017】

上記方法は、上記第１のビットまたは第２のビットに基づいて上記擬似乱数発生器を介して乱数を生成するステップを含んでもよい。上記第１のタイマまたは上記第２のタイマを設定するステップは、システムコールを行うステップを含んでもよい。上記予め定められた数の第１のビットを収集するステップおよび上記特定の数の第２のビットを採集するステップは、それぞれの上記タイマのイベントを作動させると行われてもよい。上記擬似乱数発生器は、数字、文字および他の記号を生成するように構成されてもよい。

【0018】

いくつかの実施形態は、擬似乱数発生器においてエントロピをシード処理するための方法に関してもよい。上記方法は、異なる周波数の非同期タイマを設定するステップと、上記非同期タイマのうちの第１のタイマに従って、予め定められた数の第１のビットを第１のエントロピソースから収集するステップと、収集された連続する第１のビット間のハミング距離を計算するステップと、上記ハミング距離が最小値を超えたことに基づいて上記第１のビットを第１のアキュムレーションバッファに受け入れるステップと、第１のビットの連続的な収集間のハミング距離と、上記第１のアキュムレーションバッファのコンテンツに起因するエントロピの累積値とを合計するステップと、上記第１のアキュムレーションバッファのコンテンツを擬似乱数発生器に提供するステップと、上記非同期タイマのうちの第２のタイマに従って、特定の数の第２のビットを第２のエントロピソースから採集するステップと、上記第２のビットを第２のアキュムレーションバッファに受け入れるステップとを含んでもよく、上記第２のアキュムレーションバッファは、上記第１のアキュムレーションバッファのサイズとは異なるサイズを有し、上記方法はさらに、上記第２のアキュムレーションバッファのコンテンツを上記擬似乱数発生器に提供するステップを含んでもよい。上記非同期タイマは、互いに調和しない異なる周波数を有してもよい。

【0019】

上記方法は、上記非同期タイマの周波数にジッターを生じさせるステップを含んでもよい。

【0020】

さらに他の実施形態は、上記の方法を実行するシステム、および、上記の方法のための命令を利用または格納する機械読取可能な実体的記憶媒体に関する。

【0021】

この概要は、クレームされている主題の主要なまたは不可欠の特徴を特定することを意図したものではなく、単独で使用してクレームされている主題の範囲を決定することを意図したものでもない。主題は、本特許の明細書全体、任意のまたは全ての図面、および各請求項の適切な部分を参照することによって理解されるべきである。

【図面の簡単な説明】

【0022】

【図1】実施形態に係るエントロピモジュールの図である。

【図2】実施形態に係る盗聴者を阻止する図である。

【図3】実施形態に係るシーケンス図である。

【図4】実施形態に係る２つのエントロピソースサンプリング周波数を有するタイミング図である。

【図5】実施形態に係るプロセスを示すフローチャートである。

【図6】実施形態に係るプロセスを示すフローチャートである。

【図7】本発明のさまざまな実施形態が実現され得る例示的なコンピュータシステムの図である。

【発明を実施するための形態】

【0023】

詳細な説明
実施形態は、多様なプラットフォームセットのために多くのエントロピソースを統合するためのフレームワークとして設計されたエントロピモジュールに関する。実現例では、さまざまなエントロピ生成レート（rate）を有する複数のソースをどのようにしてセキュリティ保護された態様で組み込むかを慎重に検討する。当該設計は、大量の高品質のエントロピの必要性と、優れた性能および小さなメモリフットプリントに対する要求とのバランスを取る。

【0024】

それは、多様なプラットフォームセットのために多くのエントロピソースを統合するためのフレームワークとして設計される。実現例では、さまざまなエントロピ生成レートを
有する複数のソースをどのようにしてセキュリティ保護された態様で組み込むかを慎重に検討する。当該設計に重要であるのは、エントロピを取り巻く信用の問題を考慮することである。

【0025】

図面
図１は、システム１００におけるエントロピモジュールの図である。エントロピモジュール１０６において、タイマ１０８および１１０がセットアップされて、第１のエントロピソース１０２または第２のエントロピソース１０４からそれぞれエントロピ（すなわち、ランダムビットまたはそうでなければ当該技術分野において公知のもの）を定期的にポーリングする、またはそうでなければ収集もしくは採集する。エントロピソースに対するポーリングの周波数は、互いに異なっている。一方の周波数は、採集と採集との間が０．７５１秒であってもよく、他方の周波数は、採集と採集との間が３．３秒であってもよい。

【0026】

３個以上のエントロピソースが確実に設けられ得る。たとえば、３個、４個、５個、または１０個、２０個、または数百個のエントロピソースがポーリングされてもよい。タイマイベントが発生したときにエントロピソースからデータを収集するようにコードが実行されるように、イベントタイマが各エントロピソースに関連付けられ得る。

【0027】

タイマのうちの少なくとも２つのタイマの周波数は、互いに調和していない。すなわち、一方のタイマの周波数は、他方のタイマの整数倍ではない。たとえば、タイマは、周波数が１／１．２７秒および１／０．７１５秒であってもよい。しかし、それらは、１／１．１２７秒、および、ちょうど２分の１である１／２．２５４秒ではない。

【0028】

第１のエントロピソース１０２からの前回のエントロピと比較される第１のエントロピソース１０２からのエントロピ１１８の修正ハミング距離１２６（インフラを参照）が閾値未満である場合、このエントロピは拒絶される。閾値以上である場合、このエントロピはビット１３０として第１のエントロピソース１０２から受け入れられる。当該エントロピは、収集されるとすぐにビット１３６として擬似乱数発生器（ＰＲＮＧ）１４２に転送される。

【0029】

第２のエントロピソース１０４からの前回のエントロピと比較される第２のエントロピソース１０４からのエントロピ１２０の修正ハミング距離１２８が、第１のエントロピソースの閾値とは異なっていてもよい閾値未満である場合、それは拒絶される。そうでない場合、それはビット１３２としてアキュムレーションバッファ３３４に受け入れられる。アキュムレーションバッファ３３４がフルになった後にのみ、アキュムレーションバッファ３３４はビット１３８としてＰＲＮＧ１４２にフラッシュ（flush）される。アキュム
レーションバッファは、たとえばバッファに割り当てられたメモリ全体がビットで満たされているとき、カウントが特定の数を上回るとき、次の未使用のビットへのポインタが指定のバッファサイズを超えるとき、またはそうでなければ当該技術分野において公知のときに、「フル」であり得る。

【0030】

いくつかの実施形態では、エントロピモジュールからのビットは、ＰＲＮＧ１４２のシード記憶場所１４４の代わりに、白色化アルゴリズムに転送されてもよい（１４０）。

【0031】

ＰＲＮＧ１４２の出力１４６は、ランダム化されたビット１５０を、暗号鍵生成、アプリケーションプログラムなどを含むさまざまな用途に送信する。また、ＰＲＮＧの出力１４６は、タイマ１１２によって決定された間隔でランダムビット１４８としてポーリングされる。ランダムビット１４８は、タイマ１０８および１１０を増減させる、またはそうでなければジッターを生じさせるために使用される。当該ジッターは、±１％、２％、３
％、４％、５％、７％、１０％、１５％、２０％、２５％、３０％、３３％、またはそうでなければ当該技術分野においてタイマとしての「ジッター」によって理解されるものなどの、±数％であってもよい。これは、エントロピソースポーリングタイマ１０８および１１０の周波数が変化するためである。

【0032】

ランダムビットは、タイマの次のポーリングまでの時間に加算されたり減算されたりする。たとえば、ＰＲＮＧの出力は、（０から３２，７６７までの範囲の中からの）数字７８９であってもよい。最大±１２％だけ時間にジッターを生じさせる場合、次の周期は((789 / 32767) * 2 - 1) * 0.12 * nominal_interval_periodによって調節され得る。

【0033】

図２は、典型的な使用事例において盗聴者を阻止する図である。エントロピソース２０２は、所定のエンティティによってセキュリティ侵害されている。たとえば、ハードウェアベースのエントロピ発生器２０２の製造者は、当該エントロピ発生器がわずかにスキュー（skew）されていることを示すデータを政府に譲ってもよい。政府は、司法手段または他の手段によってエントロピ発生器をスキューすることを積極的に強要することができるであろう。

【0034】

エントロピソース２０４は、セキュリティ侵害されていない。それは、エントロピ発生器２０２のセキュリティ侵害に関与する政府の管轄外のエンティティによって製造されてもよい。これらのエントロピソースは、タイマ２０８および２１０によって設定された異なる周波数または周期でＰＲＮＧ２４２にポーリングされる。ＰＲＮＧ２４２は、暗号鍵２５２を作成するためにコンピュータ２６０によって使用される。暗号鍵２５２は、ドキュメント２５４を暗号化するために使用される。暗号化されたドキュメント２５４は、ネットワーク２５８を介してコンピュータ２６２に送信される。

【0035】

コンピュータ２６２は、復号鍵２５６を用いてドキュメント２５４を復号する。復号鍵２５６は、暗号鍵２５２と同一である場合もあれば、そうでない場合もある。

【0036】

盗聴者は、ネットワーク２５８上でドキュメント２５４を傍受できるが、ドキュメントを解読することはできない。暗号鍵２５２は、ＰＲＮＧ２４２からのランダムビットから作成された。しかし、鍵が作成された時点で、ＰＲＮＧ２４２は、セキュリティ侵害されていないエントロピソース２０４から部分的にシード処理された。

【0037】

たとえ暗号鍵がソース２０２などのセキュリティ侵害されたエントロピソースから生成されるランダムビットから作成され、盗聴者がドキュメントを解読することができたとしても、セキュリティ侵害されたソースからは次の暗号鍵を生成することはできない。したがって、１つのエントロピソースを解読したに過ぎない盗聴者は、コンピュータ２６０から送信されるありとあらゆるメッセージに対して自由かつ十分な明確性を持つことはできない。図に示されるようにエントロピソースが２つである場合、盗聴者は、セキュリティ侵害されていないソース２０４からのシードが使用されるまではコンピュータからのメッセージを解読するつもりでいるだけでよい。当該シードは、それ以降、新たなエントロピをプロセスに追加する。盗聴者は、他方のソースのセキュリティを侵害することに時間とリソースとを費やさなければならない。

【0038】

３個以上のエントロピソースからエントロピを採集することは、盗聴者の手間をさらに複雑にする可能性がある。エントロピソースの数が増大することにより、盗聴者がセキュリティ侵害しなければならないソースの数が増大することになり、それによって、傍受されたメッセージを読み出すことができる確率が減少する。

【0039】

さまざまなエントロピソースのための収集／採集タイマにジッターを生じさせることは
、盗聴者の作業をさらに複雑にする。盗聴者は、各エントロピソースがいつシード処理されるかを知るのに苦労することになる。暗号鍵が１０秒±いくらかのジッター時間ごとに変更される場合には、ジッター時間内に暗号化されたメッセージまたはメッセージの一部はいずれも、盗聴者によって適切に解読されるとは限らない。いつメッセージが適切に解読されないかはテキスト通信では容易に明らかであり得るが、数値の表またはビットマップの詳細において判断を行うことはより困難であろう。

【0040】

図３は、システム３００のためのシーケンス図であり、ここでは時間は上から下に進む。最初に、ソース３０２は、エントロピ３１８ａをエントロピコレクタ３０６に供給する。当該エントロピは、すぐにシード３３６ａとしてＰＲＮＧ３４２に転送される。その後、周期的な時間間隔で、すなわち周波数３０８で、エントロピソース３０２からのエントロピ３１８ｂ，３１８ｃ，３１８ｄ，３１８ｅ，３１８ｆ，３１８ｇ，３１８ｈ…は、３３６ｂ，３３６ｃ，３３６ｄ，３３６ｅ，３３６ｆ，３３６ｇ，３３６ｈ…としてＰＲＮＧ３４２に転送される。

【0041】

エントロピソース３０２からのエントロピ収集とインターリーブされるのは、エントロピソース３０４からの収集（すなわち、他の収集）である。最初に、エントロピソース３０４は、エントロピ３２０ａをエントロピコレクタ３０６に供給する。当該エントロピは、アキュムレーションバッファ３３４においてバッファリングされる。その後、周期的な時間間隔で、すなわち周波数３１０で、エントロピソース３０６からのエントロピ３２０ａ，３２０ｂ，３２０ｃ，３２０ｄおよび３２０ｅは、アキュムレーションバッファ３３４に格納される。アキュムレーションバッファ３３４がフルになると、例示的な例ではエントロピ３２０ｅがアキュムレーションバッファ３３４に受け入れられると、バッファは、シード３３８としてＰＲＮＧ３４２に送信される、または送られる。次いで、アキュムレーションバッファ３３４は、パージまたはそうでなければリセットされる。

【0042】

ソース３０２がセキュリティ侵害されると、攻撃者は、セキュリティ侵害されていないソース３０４からのエントロピがＰＲＮＧ３４２に送信される時点まで、ＰＲＮＧ３４２からの出力によって暗号化された全てのメッセージを読み出すことができるかもしれない。すなわち、シード３３８がＰＲＮＧ３４２に送られる（または、引き寄せられる）と、ＰＲＮＧ３４２の出力に基づく暗号化は妨害されなくなる。

【0043】

周波数３０８および３１０の周期的な時間間隔は、厳密に周期的でないようにジッターを生じさせられ得る。もっと正確に言えば、それらの周期性は、厳密な周期性を中心としてよりカオス的である。

【0044】

図４は、実施形態に係る２つのエントロピソースサンプリング周波数を有するタイミング図である。第１のタイマ４０８の説明が図の上部に示されている。どの立ち上がりまたは立ち下がりもタイマイベントを表わしている。名目上、第１のタイマ４０８は、垂直線ごとに作動する。図では、第１のタイマ４０８のパルスは、ランダムジッター４１４によって遅延または加速される。当該遅延または加速の量は、擬似乱数発生器の出力によって決定される。

【0045】

第２のタイマ４１０の説明が図の下部に示されている。名目上、第２のタイマ４１０は、第１のタイマ４０８とは異なる非調和周波数である垂直線ごとに作動する。図では、ジッターは、名目周期からのずれとしてだけでなく、代替的により大きなまたは小さな「パルス」幅としても示されている。

【0046】

「タイマ」は、多くの一般的なコンピュータオペレーティングシステムにおいて繰り返し作動するまたはイベントを生じさせるように設定可能なイベント駆動型タイマを含む。
たとえば、以下のコードによってＪａｖａ（登録商標）でタイマを作成してもよい。

【0047】

【数1】

【0048】

結果として生じるイベントは、通常プロセスに割り込むか、新たなスレッドを開始するか、またはそうでなければ当該技術分野において公知のコードを実行し得る。

【0049】

「周波数」は、タイマに関連付けられ、イベント間のタイマの名目周期の逆数である。すなわち、ｆｒｅｑ＝１／Ｔである。タイマは、Ｔ秒ごとに繰り返すように設定可能である。

【0050】

ソース
エントロピモジュールは、複数のソースから寄せ集まる。以下の表では、少なくとも１つが高速である最低３個のソースに対して、各プラットフォームについてテストが行われた。この目標は、全てのプラットフォームで達成され、いくつかのプラットフォームでは十分に上回っていた。

【0051】

【表1】

【0052】

ソースの実現例は、モジュール式であり、新たなソースを迅速に追加することは簡単明瞭である。たとえば、オープンソースエントロピライブラリlibhavegeを動的にロードし
て使用するソースを作成するのに数時間の手間しかかからなかった。

【0053】

シード処理
エントロピソースに加えて、初期化時およびフォーク（２）が検出された後に複数の場所からシード材料を採集するモジュールが作成された。当該シード材料は、エントロピモジュールのさまざまなインスタンスを区別するためにエントロピプールに供給される。シード材料のいずれについてもエントロピは全くカウントされない。

【0054】

【表2】

【0055】

フレキシブル
単純な構成システムを用いて、初期化中にエントロピモジュールの挙動を変更することができる。エントロピソースおよびシードソースは、個々にイネーブルにされたりディスエーブルにされたりすることができる。エントロピソースは、それらの調整パラメータを変更させて、エントロピ生成レートを変化させたり、システム負荷を減少させたり、内部バッファサイズを変更したり、または推定エントロピ品質を更新したりすることができる。

【0056】

例示的なアプリケーション
エントロピモジュールをアプリケーションに統合するために必要とされる変更の、最小限であるかもしれないスレッド型の例は、以下の通りである。

【0057】

【数2】

【0058】

モジュールをＯｐｅｎＳＳＬに統合する場合、外部の方を向いているＡＰＩをさらに簡略化することができる。

【0059】

ＯｐｅｎＳＳＬへの統合
エントロピモジュールまたは派生物は、インターネットのセキュリティを向上させることを支援する目的で、ＯｐｅｎＳＳＬの配布の一部として含まれるように提供され得る。

【0060】

エントロピモジュールは、それをＯｐｅｎＳＳＬに統合するためにいくつかの変更を必要とするであろう。

【0061】

・現行のＡＰＩは、グローバル符号のための名前空間としてＮＳＥおよびｎｓｅプレフィックスを使用する。これらは、ＯｐｅｎＳＳＬ命名規則に準拠するように変更されなければならないかもしれない。

【0062】

・モジュールは、それ自体の代わりにＯｐｅｎＳＳＬの内部効用関数を使用するように変更されなければならないかもしれない。主なものは、メモリ割り当ておよび構成管理であり、これらは両方ともＯｐｅｎＳＳＬインターフェイスと同様であるように設計された。

【0063】

・ハードウェア抽象化のうちのいくつかは、ＯｐｅｎＳＳＬの等価物を使用するように更新される必要があるかもしれない。

【0064】

・モジュールは、ＯｐｅｎＳＳＬ構築インフラストラクチャに統合される必要があるかもしれない。

【0065】

・モジュールがＯｐｅｎＳＳＬによって定期的に点検修理（service）されるようにフ
ックを配置する必要があるかもしれない。

【0066】

ＦＩＰＳ状態
このモジュールは、ＦＩＰＳ規格を念頭に置いて設計された。サポートされるプラットフォームのために広範囲にわたるデータ収集が引き受けられ、出力がＳＰ８００－９０Ｂ第一稿エントロピテストにかけられた。次いで、これらのテストの結果は、エントロピソース調整パラメータにフィードバックされた。

【0067】

設計検討事項
ソフトウェアエントロピモジュールの設計は、３つの主な検討事項を考慮に入れるべきである：
１．ＯｐｅｎＳＳＬエントロピモジュールにおける既存の制約
２．セキュリティ原則、および
３．マシンリソース。

【0068】

ＯｐｅｎＳＳＬの制約
セキュリティ
高品質のエントロピを提供し、多様性を提供し、適切に集約するようにソフトウェアモジュールを設計する際に、指針となる２つのセキュリティ原則が遵守され得る。これらは両方とも、信頼できる、セキュリティ保護されたエントロピフィードを提供するために必要とされ得る。

【0069】

多様性を提供
第１の原則は、ソースが多い方がよいというものである。１つのソースだけに依拠することは、エントロピシステムを壊すためにセキュリティを侵害する必要があるソースが１つだけであることを意味する。優れたエントロピのソースが２つあれば、それらのうちの一方が壊されてもエントロピシステムの動作が劣化することはない。

【0070】

適切に集約
第２の原則は、エントロピがＯｐｅｎＳＳＬのＰＲＮＧに送信される前に妥当なサイズの塊にバッファリングされるべきであるというものである。ここでの根拠は、一度に数ビットのエントロピを与えることにより、攻撃者が総当たり予測によってＯｐｅｎＳＳＬの擬似乱数発生器のセキュリティ侵害を先延ばしにすることを可能にするだろうというものである。エントロピをバッファリングして一度に比較的多くの量を放出することによって、これは実現不可能になる。

【0071】

リソースインパクト
最後の指針は、過剰な量の中央処理装置（ＣＰＵ）またはメモリを使用しないというものである。エントロピサブシステムがＣＰＵを独り占めしてはならない。それは、ユーザの所望の作業を行っているシステムの他の部分とうまくやらなければならない。リソース剥奪攻撃を軽減するために、初期化時にリソース割り当てが行われるべきである。これにより、折り悪しき割り当て失敗の可能性が減少し、通常動作中のエラー処理のうちのいくらかが不要になる。これに対する当然の結果として、情報漏洩のいかなる可能性も防止するために、割り当てられたバッファを使用直後に除去するように気を付けるべきである。特に、エントロピバッファは常に、そのコンテンツがどこかに転送された後に除去されなければならない。

【0072】

エントロピモジュールの概要
１つの目的は、高品質のエントロピを生成し、かつ、ＯｐｅｎＳＳＬを定期的に再シード処理するソフトウェアモジュールを作成することである。当該モジュールは、フージョンミドルウェア構成によって使用されるプラットフォームセットにわたって一貫してそうすることができなければならない。エントロピソースは、２つの局面で動作する。

【0073】

１．初期化：この局面では、システム情報が、拾い集められ、呼び出し元に転送され、類似しているが別個のオペレーティング環境を区別するために使用される。たとえば、マシン上の２つのプロセスは、それらのプロセスＩＤがプールに追加されなければ同一のエントロピを有しているだろう。しかし、この初期化データはいずれも、エントロピを所有しているものとは考えられない。

【0074】

２．収集：この局面では、エントロピが収集され、呼び出し元に転送される。
エントロピソースの各々は、数ビットのエントロピを定期的に生成する。生成の品質および速度は、明らかにソース間で異なり、設計ではこれを考慮に入れなければならない。生成したエントロピの品質は、推定され、ソース当たりのバッファに蓄積される。アキュムレーションバッファの中に十分な推定エントロピがあると、それは出力キャッシュに転送され、出力キャッシュは、当該エントロピを白色化して圧縮する。出力キャッシュ内のエントロピは、呼び出しアプリケーションによって要求され得て、キャッシュがフルになると、過剰なエントロピを出力キャッシュまたは呼び出しアプリケーションにエクスポートするためのオーバーフロー機構も存在する。ここで、いくつかの実施形態にとっての重要な点は、各エントロピソースがその他の全てのエントロピソースから独立して動作し、少なくともアプリケーションが使用できる状態になるまでは、任意の２つのソースからのエントロピが混ざり合うことはないということである。これは、以下で詳述するように、タイミングおよび品質差に基づいて潜在的な攻撃を軽減することに役立つ。

【0075】

エントロピモジュール設計検討事項
複数の独立したソースを多様化する
スケジューラを使用する
前方秘匿性のために再シード処理に対応する
どのソースも異なるエントロピ生成レートを有し、そのことが、適切なポーリング間隔およびいつアプリケーションのプールに送るかを決定する
性能：あなたのシステムを欠乏させない
条件付け
エントロピソースの各々は、数ビットのエントロピを定期的に生成する。生成の品質および速度は、明らかにソース間で異なり、設計ではこれを考慮に入れるべきである。生成したエントロピの品質は、推定され、ソース当たりのバッファに蓄積される。アキュムレーションバッファの中に十分な推定エントロピがあると、それは、提供されたコールバックを用いて出力キャッシュまたは呼び出しアプリケーションの擬似乱数発生器に転送される。これらの実施形態では、各エントロピソースは、その他の全てのエントロピソースか
ら独立して動作することができ、少なくともアプリケーションが使用できる状態になるまでは、任意の２つのソースからのエントロピが混ざり合うことはない。これは、以下で詳述するように、タイミングおよび品質差に基づいて潜在的な攻撃を軽減することに役立つ。

【0076】

エントロピモジュールは、調整された最小タイミング周期に基づいて各エントロピソースの実際の実行を処理するスケジューラも含む。デフォルトで、これは固定ポーリング間隔を表わす。スケジューラは、全ての採集作業が期限が来るまでは実行されることがないことを確実にし、それらが公正で公平な態様で実行されることを確実にし、エントロピモジュールがＣＰＵリソースをあまり多く消費しないようにすることを確実にしなければならない。

【0077】

エントロピモジュールの最後の構成要素は、出力キャッシュからの融合され白色化されたエントロピを使用してタイミング間隔にジッターを生じさせる任意のフィードバックループである。これは、生成したエントロピの品質を向上させるのではなく、他の点では完全に決定性の生成タイミングで攻撃を軽減する。マイナス面は、これによって異なるソース間にいくらかの相関関係が導入されることになるというものである。しかし、白色化段階後にエントロピが抽出されるため、これはありそうにない攻撃ベクトルであるように思われる。ここで、いくつかの実施形態における重要な側面は、エントロピモジュールが、それ自体の存在理由を無にしないように、供給しているよりもはるかに少ないエントロピをこの目的でアプリケーションから抽出すべきであるということである。

【0078】

エントロピ推定
データ収集がランダムであることを証明することは、現在のところ数学的に不可能である。しかし、データ収集が場合によってはランダムでないことを自信を持って主張することは可能である。どのぐらいのエントロピがデータのブロックの状態で所与のソースから生成されるのか、および、どのぐらい速く当該ソースがエントロピを送り出すのかを控えめに推定する方法が必要である。これを達成するために、我々は、ソース当たりのプラットフォーム当たりのデータを収集することから始め、次いでいくつかのエントロピ推定ツールを用いて、所与のポーリング間隔で、収集されたエントロピを推定する。

【0079】

ポーリング間隔は、プラットフォームのリソースが限られることを考慮に入れて、ソースにとって適切であるものに従って選択される。タイトなループでエントロピをポーリングすることは、非効率であり、妥当な量のエントロピを蓄積するのに十分なポーリング間の時間をシステムに与えない。これの直接的な結果として、エントロピ推定制限を厳しくしなければならず、非常に控えめな限界になる。さらに、これは、より多くの時間およびリソースをエントロピを採集することに費やすことを必要とし、システムリソースの独占になるであろう。その代わりに、我々は、適度なレートでエントロピを収集して、クライアントのＰＲＮＧ機構によって対処されるある程度の自己相関を認める。

【0080】

モジュールは、ハミング距離メトリックの修正バージョンを使用して、ビットが変化しており、妥当なレートでそうしていることを確認する。このメトリックからの出力は、前回のサンプリングからの変化量の推定量として使用され、ソースから取得可能な要求されたエントロピを制限するために使用される。

【0081】

設計詳細
アーキテクチャ詳細を示す前に具体的に言及および説明するに値するいくつかのさらに細かい点がある。

【0082】

再シード処理が必要である場合がある
ＯｐｅｎＳＳＬが起動時にそのＰＲＮＧを一度だけシード処理するので、前方秘匿性のために再シード処理を繰り返すことが必要である場合がある。この時点では、ＮＳＥチームは、ＯｐｅｎＳＳＬソースコードベースに変更を加える許可を有していないため、エントロピは、シード処理ＡＰＩを用いていくらかをＯｐｅｎＳＳＬに定期的に送り込むことによって追加される。

【0083】

エントロピソースの各々は、それ自体のローカルバッファを有し、当該ローカルバッファは、相当量になるまでこのソースからエントロピを蓄積する。次いで、蓄積されたエントロピは、単一のブロックの状態でＯｐｅｎＳＳＬに放出される。これにより、少なくとも１つのソースがセキュリティ侵害されない限り、擬似乱数発生器に対する総当たり攻撃が防止される。詳細については以下に記載する。

【0084】

デーモンは、利用可能なソースがそれらのローカルバッファをいっぱいにすると、利用可能なソースの各々によって採集されたエントロピを放出する。これは、初期化中にエントロピモジュールに提供されたコールバックを呼び出すことによってなされる。一般に、これは、RAND_addまたはFIPS_rand_add ＯｐｅｎＳＳＬＡＰＩコールである。

【0085】

このモデルの下では、エントロピソースのうちのいずれか１つが攻撃者に抵抗しても、いくらかの保護が残る。なぜなら、高品質のエントロピが依然として取得されており、バッファがフルであることが呼び出しアプリケーションに放出されると、攻撃者は、アプリケーションのエントロピについて何も知らない状態になるからである。攻撃者は、このエントロピモデルを壊すために全てのエントロピソースおよびＯｐｅｎＳＳＬ自体のセキュリティ侵害を行う。

【0086】

性能上の理由から、ソースは、エントロピが利用可能になるのを待つことを妨害してはならない。むしろ、ソースは、定期的にチェックを行って、すぐに利用可能である任意のエントロピを内部プールに送り込むべきである。各ソースの周期は、データ収集および統計分析によって実験的に決定される入来エントロピのレートに基づくべきである。

【0087】

ソースのポーリング周期を異ならせて、主に互いに素であるようにすることによって、より長い時間間隔にわたってはかなり予測可能なものであるが、ある程度の非周期性が達成される。サンプリングにおける非周期性は、必須ではないが、一見したところ切り離されている２つ以上のソースが実は相互に関連している状況では有益であろう。

【0088】

初期化休止
システムが起動したとき、システムがハードウェアランダム性ソースを持たないかまたは前回のシャットダウンからエントロピを格納していなければ、そのエントロピ状態は一般にかなり低品質である。同じことがエントロピモジュールにも当てはまり、速やかな解決策はない。システムは、速やかに、エントロピが利用可能である動作の定常状態になるため、早い段階で再シード処理を行うことが重要である。

【0089】

埋め込み型デバイスは、しばしば、ゼロに近いエントロピの状態から鍵および他の暗号化材料を生成し、その結果、さまざまなデバイスにわたる反復性の暗号化材料がもたらされる。この脆弱性を部分的に軽減するために、複数のシステム設定および構成を使用して、さまざまなホストおよびプロセスを区別する初期変化を提供することができる。エントロピは、これらのシステム設定および構成に起因しない。

【0090】

バッファリングが優れている
上記のように、少量のエントロピをシステムプールに送信することは、総当たり攻撃の機会を残すことになる。たとえば、８ビットのエントロピを１６バイトのプールに追加す
ることは、当該新たなビットの場所が既知である場合には２^８回で総当たりされる可能性があり、そうでない場合には２^８・^１２８Ｃ_８≒２^４８回で総当たりされる可能性がある。これらは両方とも、プール全体を総当たりするのに必要な２^１２８回よりも大幅に容易である。新たなビットの場所が既知でないので、２^１２８ビットのエントロピを含むプールを提供してこの攻撃ベクトルから保護することは、厳密には不要であるように思われるかもしれない。しかし、セキュリティのために難読化に依拠することはわなであるため、エントロピモジュールは、新たなビットの場所が攻撃者に知られるようになる可能性を警戒すべきである。

【0091】

非常にさまざまなレートでエントロピを生成するソースの存在下では、同様の問題が起こる。すなわち、高速ソースがセキュリティ侵害されると、低速ソースは非エントロピデータによって圧倒されて、そのささやかな貢献が上記の総当たり攻撃にさらされるようになる。この攻撃ベクトルの軽減は、各ソースからのエントロピをそれ自体のローカルアキュムレーションバッファにバッファリングし、アキュムレーションバッファがフルになったときにのみエントロピをシステムプールに放出するというものである。

【0092】

いくつかのエントロピソースは、アキュムレーションバッファを必要としない十分な速度および品質を有する。これらのソースは、迅速に、ブロッキングなしに、高品質のエントロピのフルバッファを生成することができるべきである。このようなソースは、収集されたエントロピを呼び出しアプリケーションに直接転送することができるが、呼び出しアプリケーションがそのように要求する場合にはローカル収集バッファをサポートするための備えをすべきである。

【0093】

白色化およびＣＲＮＧＴ
エントロピソースの白色化は、ランダムビットストリーム発生器の一部として不可欠であり得るが、これを提供することは、必ずしもエントロピモジュールの仕事ではない。白色化サービスおよび連続テストを含む代わりに、呼び出しアプリケーションに依拠して、エントロピが呼び出しアプリケーションに転送された後にこれらの動作を実行してもよい。ＯｐｅｎＳＳＬの場合、これらの機能は、擬似乱数発生器モジュールの一部として必須である。エントロピモジュールにそれらも引き受けさせることにより、必要な手間が倍増し、何の利益もない。ＯｐｅｎＳＳＬとは別にバックエンドが必要とされる場合には、任意の白色化およびＣＲＮＧＴ（連続乱数発生器テスト）モジュールが追加され得る。

【0094】

各エントロピソースは、その出力を白色化しようとする手段を回避すべきである。なぜなら、そうすることは、生成されるエントロピの品質を低下させるだけであり、白色化単独でより多くのエントロピを作成することは一般に不可能であるからである。ビットをシャッフルして再配置することは、統計的エントロピ推定テストに関するよりよい結果を得ることに役立ち得るが、根底にあるエントロピを向上させることは通常できないため、回避されるべきである。許される例外は、一連の排他的論理和演算を使用して大きなデータ構造をより小さなデータ構造にすることである。

【0095】

タイミングジッター
エントロピソースの各々がポーリング周期（サンプリング間の間隔）を定義するとしても、最大パーセントまで全てのポーリング周期を確率的に増加させるようにグローバル構成が設定され得る。当該オプションは、ポーリング周期を減少させることはないため、取得されるエントロピも推定される生成レートおよび品質も低下させることはない。しかし、それは、厳密にいつエントロピソースがサンプリングされたかおよびそれが何を含んでいたかの判断を攻撃者にとってより難しくする。

【0096】

より詳細なアーキテクチャ
エントロピモジュールは、全体管理モジュールおよび複数のエントロピソースモジュールで構成される。

【0097】

管理モジュール
エントロピモジュールの制御部分は、さまざまなソースを管理し、時間順キューイング機構を提供し、出力キャッシュまたは呼び出しアプリケーションへのエントロピ転送を処理し、さまざまなエントロピソースにデフォルト設定を供給する。

【0098】

初期化
エントロピモジュールは、きれいに作成されて破壊される機能を有していなければならない。ＡＰＩセクションは、呼び出しアプリケーションのためのインターフェイスの詳細を詳述する。内部で、初期化コードは、構成ベースのカスタマイゼーションを処理し、各ソースについてこれらの構成値を提供し、さまざまなエントロピソースにわたって反復し、実行可能な全てのものをスケジューリングしなければならない。最後に、初期化コードは、各々の利用可能なソースからエントロピを採集して、これを出力キャッシュまたは呼び出しアプリケーションに供給しようとすべきであり、これにより、少量ではあるがいくらかの量のエントロピが利用可能になる。

【0099】

内部には、１つの初期化インターフェイス（nse_seed_entropy_source）があってもよ
く、当該初期化インターフェイスは、エントロピがないと考えられるがシステムおよびプロセス間の差別化要因（differentiator）を提供するシステム依存のシード情報を採集しようとする。このインターフェイスは、メインライブラリ初期化中に呼び出されるものとする。

【0100】

エントロピソース情報
メインモジュールは、全てのプラットフォームについて全てのエントロピソースのローカルリストを維持する。それは、モジュールを初期化して破壊するためにこのリストを必要とする。モジュールの実際の実行は、時間順キューイングモジュールによってなされる。

【0101】

また、メインモジュールは、初期化前にどのモジュールが利用可能であり得るか、およびどのモジュールが実際に使用可能であるか、およびそれらについての他の情報を照会するために、アクセスすることができるより情報的性質のリストを構築して維持しなければならない。これらのリストは両方とも、ＡＰＩコールを介して公開される。

【0102】

時間順キューイング
ソースが半周期的にエントロピを採集しているので、必要なときに各ソースを実行できる能力を提供することが必要である。これは、時間順キューを意味する。これは、効率のためにヒープを使用する優先度付きキューを用いて実現される。必要とされるかもしれない唯一のインターフェイスは、以下の通りである：
・新たなタスクレススケジューラを作成する（nse_new_scheduler）
・スケジューラおよび全てのそのタスクを破壊する（nse_free_scheduler）
・新たな繰り返しタスクをスケジューリングする（nse_schedule）、および
・期限が来ると第１のタスクを実行する（nse_run_schedule）。

【0103】

エントロピ採集動作が反復する性質があるので、タスク実行コールは、タスクを実行した後にタスクをスケジューリングし直す。最初は必要とされなくても、実行中にキューが変更される場合にはここでいくらかの注意が必要である。任意のモジュールのエントロピ採集コードの物理的実行時間によりスキューイングを軽減しようとする試みはなされない。

【0104】

タスクインターフェイスの明確な除去がないことにも注目されたい。タスクのスケジューリング間隔をゼロに設定することにより、次回それが実行された後にそれが事実上除去される。採集コールバックにおいて間隔をゼロに設定することにより、それはすぐに除去される。

【0105】

さらなるルーチンは、現在のタイムスキュー係数に基づいてソースのスケジューリング間隔を変更するメイン管理モジュール（nse_time_skew_factor）によって提供される。このコールは、時間キューイングによって使用されてスケジューリングにわずかにジッターを生じさせる。ジッター係数の実際の決定は、出力キャッシュからいくらかのエントロピを読み出すことによってなされる。このエントロピは、次の期間にスキュー係数になる均一なランダム変量を生成するために使用される。各エントロピソースが呼び起こされるごとに新たなタイムスキュー係数を生成することが望ましいであろう。しかし、これは、呼び出しアプリケーションから多くのエントロピを消費することになり、エントロピモジュールの趣旨にそぐわない。

【0106】

呼び出しアプリケーションは、規則正しくエントロピモジュールを点検修理することを担当し、この点検修理は、時間順スケジューリングキューディスパッチ機構に対する相当に無駄のないラッパーである。

【0107】

エントロピプール管理
管理モジュールは、作成時に与えられるコールバックを介してエントロピのブロックを出力キャッシュまたは呼び出しアプリケーションに転送することを担当する。また、それは、エントロピバイトのソース当たりの融合を管理する。これら両方の場合のインターフェイスは、エントロピソースの観点から同一であり、管理モジュールは、主に構成設定に基づいて、いつエントロピブロックを出力キャッシュまたは呼び出しアプリケーションに送信するかを決定する。

【0108】

利用可能なコールは、以下の通りである：
・生の（raw）バイトのブロックを宛先に追加する（nse_add_entropy_pool）、および
・十分に変化した場合には、データを宛先に追加する（nse_copy_entropy_pool_if_sufficient）。

【0109】

前者のコールは、戻る前にそれに渡されたメモリを消去する。後者は、新たなバッファを除去する前に新たなバッファを古いバッファにコピーする。

【0110】

ファイルベースのエントロピソース
便宜上、根底にあるシステム擬似ファイルに依拠するエントロピソースを支援するために、複数のユーティリティおよびサポートルーチンが利用可能にされる：
・新たなファイルベースのエントロピソースを作成する（nse_file_source）、
・ファイルベースのエントロピソースを破壊する（nse_file_source）、および
・ファイルベースのソースからエントロピを取得する（nse_get_file_source）。

【0111】

getrandom(2)およびgetentropy(2)のためのラッパー
エントロピモジュールは、getrandom(2)およびgetentropy(2)システムコールのための
内部ラッパーを提供する。これらは、それぞれnse_getrandomおよびnse_getentropyコー
ルである。それらは両方とも、渡されたバッファに追加されたエントロピのバイト数を返す。これらのシステムコールをサポートしないシステムでは、これらの関数は常にゼロを返す。

【0112】

特定のハードウェアプラットフォームのためのヘルパ関数
マシン、プラットフォームおよびコンパイラから独立した態様でいくつかの特定のハードウェア特徴へのアクセスを提供する複数の関数が利用可能である。これらは、以下の通りである：
・命令カウンタをチェックする（nse_have_instruction_counter）、
・可能な場合は、命令カウンタに照会する（nse_read_instruction_counter）、
・擬似乱数発生器ハードウェアをチェックする（nse_have_rdrand）、
・真性乱数発生器ハードウェアをチェックする（nse_have_rdseed）、
・可能な場合は、擬似乱数発生器に照会する（nse_rdrand）、および
・可能な場合は、ハードウェア真性乱数発生器に照会する（nse_rdseed）。

【0113】

これらの最後４つは表向きはｘ８６に特有の命令であるが、これらのうちのいくつかは他のアーキテクチャのためにサポートされる可能性がある。

【0114】

エントロピソースモジュール
エントロピソースの各々は、３つのインターフェイスコールを提供する：
１．初期化、
２．終了処理、および
３．採集。

【0115】

初期化は、ソースが実行中のホストにとって適切であるか否かを判断し、適切であれば、ソースが採集に必要とするであろう任意のメモリを割り当てて、いかなるパラメータも非デフォルト値に設定することを含むその他の初期化タスクを実行するために要求されるかもしれない。

【0116】

終了処理は、任意の割り当てられたメモリおよび初期化段階によって作成された他のリソースを一掃するために要求されるかもしれない。

【0117】

採集コールは、オペレーティングシステムからエントロピを拾い集めて、これを管理モジュールに送って、蓄積または転送する作業を実際に行う。

【0118】

循環エントロピバッファ
全てのエントロピは、循環バッファに蓄積される。排他的論理和演算を用いてバイト単位でこれらのバッファにデータが追加される。また、これらのバッファは、バッファが含んでいるエントロピのビット数の推定値を維持すべきである。生データにおいてエントロピの量を推定することは困難であるので、各エントロピソースは、追加されるエントロピの量に関してそれ自体の評価を提供する。個々のソースは、その追加知識を活用して、関連する統計の複雑さを軽減することができる。

【0119】

バッファは、作成され、破壊され、除去され得る。また、それらは、追加された生データまたはエントロピデータも有し得る。２つのデータ追加コール間の違いは、エントロピデータはバイトが含んでいるエントロピの大きさ（measure）も蓄積するのに対して、生
データは蓄積しないということである。

【0120】

また、以下のことに利用可能ないくつかのユーティリティインターフェイスがある：
・初期化時に提供されるコールバックを介して、エントロピバッファのエントロピを親アプリケーションにフラッシュすること、
・バッファ内のバイト数を判断すること、
・バッファ内の生のバイトへのポインタを取得すること、
・あるエントロピバッファのコンテンツを別のエントロピバッファにコピーすること、
および
・２つのエントロピバッファ間の修正ハミング距離を計算すること。

【0121】

メモリ割り当て
ダイナミックメモリの割り当ては全て、エントロピモジュールの作成中に行われるべきである。これは、リソーススタベーション攻撃の影響を緩和することに役立つ。モジュールの通常動作中はメモリ割り当てがないので、故障する可能性があるものはない。

【0122】

エントロピデータのためのさまざまな収集プールの状態を判断しようとする攻撃を部分的に軽減するために、エントロピを含む全てのメモリ割り当ては、直接的または間接的にメモリ内にロックされるべきである。これにより、通常は、強制的にページアウトされた後にスワップファイルまたはパーティションからこのようなデータを読み出そうとする攻撃が防止される。しかし、これは、通常、バーチャルマシンに対するこのような攻撃からの保護を提供せず、他のメモリスヌーピング攻撃に対する保護を提供しない。

【0123】

エントロピ推定
各ソースモジュールのエントロピの推定は、主にＮＩＳＴＳＰ８００－９０ＢＰｙｔｈｏｎスクリプトを用いて引き受けられる。より鋭いテストが利用可能であるが、はるかに多くのエントロピデータを収集する必要があり、使用されるソースの多くは、妥当な時間内にこれを達成するには速度が遅すぎる。理想的には、各エントロピソースは、ＮＩＳＴＩＩＤテストに合格するべきであり、エントロピのレベルは、バイト当たり８ビットに近づく。残念ながら、これは、白色化があって初めて全てのソースで可能であるため、非ＩＩＤテストによって推定されるより低いレベルのエントロピが必要に応じて使用される。ソース当たりのエントロピプーリングを義務付けていたのは、これらの低品質のエントロピソースである。

【0124】

修正ハミング重み
サンプリングの際にエントロピの推定量として従来のハミング重みを使用するのではなく、多数のビット反転を低エントロピとして扱う修正メトリックを使用する。これは、ＧＦ（２）にわたって今回のサンプリングと前回のサンプリングとを加算し、結果およびその補数の両方についてハミング重みを求めて、低い方の値を使用することによってなされる。

【0125】

以下に含まれる例は、同一の事例においてハミングメトリックが修正メトリックの出力を提供および提示する過大評価を示す。依然として実際の変化を過大評価しているが、修正ハミングメトリックは、過大評価の度合いが少なくなっているため、より保守的なアプローチである。

【0126】

【表3】

【0127】

ここでは、１を加算することにより、１ビットの変化が生じている。この事例は、全ての加算のうちの半分を占める。

【0128】

【表4】

【0129】

ここでは、１を加算することにより、２ビットの変化が生じている。この事例は、全ての１の加算のうちの４分の１を占める。

【0130】

【表5】

【0131】

ここでは、１を加算することにより、５ビットの変化が生じている。ハミング距離は、当該変化を過大評価している。一方、修正ハミングメトリックは、より現実的な結果を生成している。その包含が正当化されるのはこのような場合である。

【0132】

サンプリングにおいてエントロピを決定する
よりゆっくりと実行されかつより低品質のソースでは、前回のサンプリングと今回のサンプリングとの間の距離を使用して、要求されるエントロピおよびエントロピ自体の推定値の両方に対する制限を提供する。

【0133】

下限はソース当たり指定され、少なくともこの多くのビットが変化したことをメトリックが示さない場合、ソースはこの間隔を変化させていないと見なされて、サンプリングが無視される。変化した各ビットについては変化していない見込みもあるだろうという想定のもとに、使用されるエントロピ推定値は、計算された距離メトリックの２倍になる。上限は、サンプリング当たり要求可能なエントロピの最大量を制限する。

【0134】

下限および上限は、実験によるデータに基づいてエントロピソース当たり設定される。限界を緩めることができるべきであり、各ソースのための採集間隔およびエントロピ品質を適切に調整できるほどに十分なデータをさまざまなオペレーティングシステムおよびアーキテクチャから取得することができる場合には、考えようによってはこれらの制限を完全に除去することができるべきである。これらの場合、各サンプリングで生成されるビット数に関して信頼できる推定値を有し得る。

【0135】

ＡＰＩ
ＡＰＩは、単一のヘッダファイルからもたらされる。

【0136】

【数3】

【0137】

エントロピモジュールからの全ての外部インターフェイスは、ＮＳＥ＿から始まる名前を有することになる。内部であるがパブリックな全てのインターフェイスは、ｎｓｅ＿から始まる名前を有することになる。ローカル名は、無制限であり、隠されているべきである。

【0138】

NSE_ENTROPY_VERSIONからのバージョン情報
この定数は、エントロピモジュールバージョン番号を保持する。それは、ＶＶＶＭＭｍｍｅｅというフォーマットの符号なし１０進整数である。ＶＶＶはライブラリリビジョンであり、ＭＭは主要なリビジョンであり、ｍｍは小さなリビジョンであり、ｅｅは追加／緊急リビジョンである。

【0139】

以下を使用して初期化する

【0140】

【数4】

【0141】

初期化関数は、全てのエントロピソースをセットアップし、現在行われている使用に備えて何もかもを準備する。また、それは、いくらかの初期シード処理を提供して、リーパ（reaper）のさまざまなインスタンスを区別する。それは、渡された構成から非デフォルト設定を読み出し、当該設定は、このコールが戻るとすぐに削除され得る。ヌルが構成に渡される場合、デフォルトが使用される。

【0142】

オーバーフロー引数は、リーパの出力キャッシュがフルになるとエントロピを呼び出しアプリケーションのエントロピプールに送るようにコールバックを提供する。通常動作では、この引数は、ＯｐｅｎＳＳＬからのＲＡＮＤ＿ａｄｄまたはＦＩＰＳ＿ｒａｎｄ＿ａｄｄであってもよい。この引数はヌルであってもよく、その場合、過剰なエントロピは廃棄される。エントロピの量は、この関数を呼び出すときにはバイト単位で測定され、ライブラリの残りの部分全体にわたっては、エントロピはより自然なビット単位で測定される。

【0143】

エントロピモジュールの複数のインスタンスを作成することが可能であるが、そうすることは抑制される。複数のインスタンスによって生成されるエントロピストリームが相互に関連しているであろうということを確信するにはもっともな理由がある。したがって、２つ以上のインスタンスは、１つよりも多くのエントロピを生成することはできないかもしれない。

【0144】

以下を使用してエントロピを取得する

【0145】

【数5】

【0146】

これらの関数は、内部出力キャッシュからエントロピを得て、それを渡されたバッファに入れる。エントロピ要求全体が満たされるまで、第１のコールはブロックする。第２のコールは、ブロックせず、エントロピが蓄積されるのを待ち、部分的な返しが可能である。これらのコールは両方とも、コピーされるエントロピのバイト数を返すか、またはエラー時には－１を返す。

【0147】

以下を定期的に呼び出す

【0148】

【数6】

【0149】

更新関数は、ノンブロッキングの態様で内部エントロピプールを更新し、可能ならばフルのプールをＯｐｅｎＳＳＬに渡す。それは、点検修理を必要とする次のエントロピイベントまでの秒数を返す。戻り値が示すよりも多少頻繁にこれを呼び出すことが無難であるが、この値を利用することにより、呼び出し元は、エントロピを点検修理する間にスリープすることが可能になる。

【0150】

以下により終了および破壊する

【0151】

【数7】

【0152】

この関数は、エントロピモジュールを破壊し、割り当てられたメモリを解放し、全ての消費されたリソースをオペレーティングシステムに返す。エントロピモジュールを終えてそれを除去したいときにこれを呼び出す。これは、一般にプログラム終了時であろう。

【0153】

以下によりヘルスチェックを再度実行させる

【0154】

【数8】

【0155】

この関数は、パワーオンヘルスチェックを再度実行させる。ソースがこれらのチェックを終えるまでは、当該ソースによってエントロピは生成されない。これは通常、ある程度の時間、すなわち数分から数時間かかる。

【0156】

直近の引数がゼロでない場合、速やかにヘルスチェックを受けることができる比較的少数のソースがすぐにチェックされる。これは、現時点では実行を少しの間遅延させるが、エントロピの生成の完全な中断を防止する。しかし、残りのエントロピソースが自身のヘルスチェックに合格するまでは、少ないソースでエントロピリーピングが実行される。リーパが再びフル能力で実行されるまで数時間かかるであろう。

【0157】

照会および更新関数
エントロピリーパの挙動を調査および変更することを可能にする複数の照会および更新関数がある。いくつかの実施形態では、変更は、作成と初期化との間でのみ実行され得る。調査はいつでも行うことができる。

【0158】

デフォルト設定は、エントロピリーパの大半の用途に適しており、これらのＡＰＩは、不要であるかもしれない。

【0159】

リーパ設定
エントロピリーパのための複数のグローバル設定がある。アクセスＡＰＩについてここ
で説明する。

【0160】

バッファサイズ

【0161】

【数9】

【0162】

これらの関数は、理想的な内部バッファサイズをリーパに設定することを可能にする。デフォルトで、このサイズは３３バイトであり、エントロピの各出力は、３３×８＝２６４ビットのエントロピを提供しようとする。全てのエントロピソースがこのような柔軟性を提供できるとは限らないが、大半が提供する。

【0163】

出力キャッシュ

【0164】

【数10】

【0165】

これらの関数は、出力キャッシュおよび白色化を制御する。前者の関数は、白色化がイネーブルであれば非ゼロを返し、任意にバイト単位の出力エントロピキャッシュのサイズおよび使用されているダイジェストアルゴリズムを返す。後者の関数は、白色化か否か、（ゼロであり得る）出力バッファのサイズ、および出力を白色化するために使用するダイジェストの名前を指定する。ヌルがダイジェストに渡される場合には、デフォルトが使用される。

【0166】

レートパラメータは、エントロピをダイジェストする際になされるべきオーバーサンプリングのレベルを指定する。１未満の値は無視される。

【0167】

デフォルト設定は、デフォルトアルゴリズム（ＳＨＡ５１２）、１０２４バイトバッファおよび２というオーバーサンプリングレートを用いて白色化するというものである。

【0168】

タイムスキューイング

【0169】

【数11】

【0170】

前者のコールは、タイムスキュワモジュールの状態を照会する。それは、タイムスキューイングがイネーブルであれば非ゼロを返す。また、渡されたポインタがヌルでない場合には、間隔（秒単位）および割合スキューも返される。

【0171】

第２のコールは、タイムスキュワモジュールを構成することを可能にすることができる。イネーブルにされた設定も課せられるが、渡された値がマイナスでなければ間隔（秒単位）および割合設定のみが課せられる。

【0172】

デフォルトで、タイムスキューイングは、１２秒という間隔および５％というスキューでイネーブルにされる。

【0173】

ヘルスチェック

【0174】

【数12】

【0175】

前者の関数は、起動および連続ヘルステストが実行される場合に非ゼロを返す。第２のコールは、テストをイネーブルにすることを可能にする。

【0176】

デフォルトで、ヘルスチェックはディスエーブルにされる。
詳細さ

【0177】

【数13】

【0178】

第１の関数は、リーパが実行されている詳細度を照会する。当該度合いが高くなればなるほど、その出力は詳細になる。第２のコールは、詳細度を指定することを可能にする。ゼロという度合い、すなわちデフォルト、は、詳細な出力がないことを意味する。全ての他の度合いは未定義である。

【0179】

ソース設定

【0180】

【数14】

【0181】

これらの照会関数は、さまざまな未加工のエントロピソースについての情報を返す。エントロピソースの数は、NSE_entropy_source_countコールを用いて照会可能である。各ソ
ースの名前は、NSE_entropy_source_nameコールを用いてアクセス可能であり、範囲外の
インデックスに対してはヌルが返される。

【0182】

初期化が完了した後にソースが使用されているか否かをチェックするために、NSE_entropy_source_query_usableコールがなされる。対象のソースが使用されていれば、関数は
非ゼロを返す。

【0183】

アクティブソース

【0184】

【数15】

【0185】

これらの関数は、ソースのアクティブフラグの判断および設定を可能にする。アクティブソースは、初期化時に起動されるが、必ずしも全てのアクティブソースがどのマシンでも使用できるとは限らないため、アクティブソースが使用できないことも起こり得る。後者を判断するためにNSE_entropy_source_query_usableコールが使用される。

【0186】

バッファサイズ

【0187】

【数16】

【0188】

これらの関数は、ソースの収集バッファをサイズ決めして照会することを可能にする。大半のソースでは、収集バッファは任意のサイズを有し得るが、いくつかのソースでは、収集バッファは、イミュータブルであり、これらのコールを介してなされるいかなる変更も無視される。

【0189】

プールサイズ

【0190】

【数17】

【0191】

これらの関数は、エントロピプールバッファサイズをソース当たり指定することを可能にする。ゼロというプールサイズは、余分なバッファリング段階がないことを意味する。マイナスのプールサイズは、システムに、グローバルターゲットバッファサイズおよびソースのエントロピ品質に基づいてプールサイズを計算させる。プラスのプールサイズは、収集バッファと出力白色化段階との間の二次的な着陸点として使用される。

【0192】

エントロピ品質

【0193】

【数18】

【0194】

これらのコールは、ソースからの品質出力を照会および変更することを可能にする。品質パラメータは、［０，１］の範囲内の実数である。０という値は、ビット当たりエントロピがないことを意味し、１という値は、ビット当たりエントロピがフルである。

【0195】

全てのソースが、示されるエントロピの大きさとして品質パラメータを使用するとは限らず、この目的で以下の制限も使用することができる。

【0196】

スケジューリング間隔

【0197】

【数19】

【0198】

スケジューリング間隔は、エントロピソースのサンプリング間の名目時間である。各ソースは、一般に、それ自体の固有のスケジューリング間隔を有する。これらの関数は、特定のソースのスケジューリング間隔を照会および更新することを可能にする。

【0199】

エントロピ制限

【0200】

【数20】

【0201】

いくつかのエントロピソースは、更新時にそれらが受け入れるエントロピの量を制限する。具体的には、変化したビットの数は、少なくとも低閾値でなければならず、高閾値にトリミングされる。これらのコールは、これらの制限を照会および指定することを可能にする。前者のコールでは、ポインタ引数のいずれかがヌルであり得て、その場合には当該パラメータは返されない。後者のコールは、制限を調節することを可能にする。制限に対してゼロ値を渡すことにより、設定は元のままにされる。

【0202】

高速ヘルスチェック

【0203】

【数21】

【0204】

この照会関数は、指定のエントロピソースがファストパス起動ヘルスチェックを行うことができれば非ゼロを返す。ファストパスヘルスチェックを行うことができるソースは、すぐに使用可能である。ファストパスヘルスチェックを行うことができないソースは、実行中のエントロピ収集に貢献する前に、必要な４０９６個のサンプルをゆっくりと生成しなければならない。

【0205】

シード処理
初期化時、リーパは、低エントロピシステム区別情報を採集しようとする。これに使用されるソースは、選択的またはグローバルにディスエーブルにされ得る。全ての初期化パラメータと同様に、それらは、リーパ初期化の前にのみ変更可能である。

【0206】

グローバルシード処理設定

【0207】

【数22】

【0208】

前者のコールは、現在のシード処理状態を照会する。非ゼロ戻り値は、シード処理が実行されることを示す。後者のコールは、状態が非ゼロである場合にはシード処理をグローバルにイネーブルにし、状態がゼロである場合にはシード処理をディスエーブルにすることを可能にする。

【0209】

デフォルトで、シード処理はイネーブルにされる。
シードソースの照会

【0210】

【数23】

【0211】

前者のコールは、利用可能なシードソースの数を返す。後者のコールは、特定の番号付けされたシードの名前を返す。パラメータが範囲外であれば、ヌルを返す。

【0212】

シードソースの活性化

【0213】

【数24】

【0214】

前者のコールは、示されるシードが現在アクティブであれば非ゼロを返す。後者のコールは、示されるシードをイネーブルまたはディスエーブルにすることを可能にする。

【0215】

デフォルトで、全てのシードソースはイネーブルにされる。
モジュールの使い方
エントロピモジュールは、別のアプリケーションに統合するのに簡単明瞭であり非侵襲的であるように設計される。それは、それ自体のスレッドによって点検修理される場合に最も良く動作し得るが、非スレッド環境でも問題なく動作する。

【0216】

単一のプロセス内でエントロピモジュールの複数のインスタンスを作成することも可能であり、各インスタンスは、異なるエントロピプールを供給する。しかし、結果として生じる出力の相関関係について保証はない。

【0217】

スレッド化
別のスレッドからエントロピサブシステムを点検修理するために、この線に沿ったコードがあるべきである。

【0218】

【数25】

【0219】

非スレッド化
非スレッド環境でエントロピモジュールを使用するために、スレッド化の例と同一のコールを行う必要があるが、これらはアプリケーションのイベントループに統合される必要がある。NSE_entropy_updateから返される待ち時間を遵守する必要はなく、しばしばこれを呼び出すことは自由であるが、規則正しく呼び出さなければならない。最小コードセットは、以下の通りである。

【0220】

【数26】

【0221】

このコードは、NSE_entropy_updateから返される時間に基づいてスリープしないため、場合によってはかなり非効率である。

【0222】

スレッドの例のスモールワーキングコード
呼び出しコードは、NSE_configサブシステムを完全に回避し、その代わりにデフォルトに依拠し得る。

【0223】

【数27】

【0224】

勧告
１．エントロピデーモンは、カーネルに送り込まれる場合に実行されるべきである。デーモンの厳密な選択は、不特定のままである。理想的には、いくつかが並行して実行されるであろう。

【0225】

２．ＣＰＵハードウェアにおいて乱数ソースをサポートするが、デフォルトでそれらをディスエーブルにすべきである。これらのソースは非常に高速であり、膨大な量のエントロピを生成することができるが、それらの信頼性について心配する人々もいる。ブラックボックスソースに信頼を置くか否かの判断は、エンドユーザに委ねられる。

【0226】

３．/dev/randomも/dev/urandomも、利用可能であればサポートされるものとする。/dev/randomは、そのブロッキング性質によりデフォルトでディスエーブルにされるが、十分なハードウェアエントロピが利用可能であるシステムではイネーブルにされるべきである。その代わり、速い生成レートのために/dev/urandomがデフォルトで使用されるが、呼び出しアプリケーションによって無効にされない限り、このソースから生じるものとしてカウントされるエントロピはない。コールをサポートするシステム上では、getentropy(2)
およびgetrandom(2)は、それぞれ/dev/randomおよび/dev/urandomの代替品として同じよ
うに使用される。

【0227】

エントロピソース
エントロピデーモンは、複数の異なる個々のエントロピソースを提供し、これらの各々は、混合および白色化のためにＯｐｅｎＳＳＬに転送されるエントロピプールを生成する。ソースの各々は、その挙動の微調整および大規模な変更を可能にするいくつかのオプションを有する。

【0228】

プールが十分なエントロピを含むと、ＯｐｅｎＳＳＬに転送され、エントロピ推定値はエントロピ品質パラメータ分の１に減少する。

【0229】

グローバル

【0230】

【表6-1】

【表6-2】

【0231】

ＣＰＵ情報
このソースは、入手可能なＣＰＵ状態情報に基づいてエントロピを返す。それは、Ｓｏｌａｒｉｓ、ＨＰ－ＵＸおよびＡＩＸシステムに有用である。それは、他のデバイスに対しては何もしない。Ｌｉｎｕｘは、その代わりに/proc/timer_listおよび/proc/interruptsソースを使用する。

【0232】

【表7】

【0233】

ここで、可変のパラメータは実験により求められ、それらのデフォルト値はホスティングオペレーティングシステムに基づく。

【0234】

【表8】

【0235】

ここで、数字は全て同一である。これは、システムに特有のさらなる調整が必要であるかもしれないことを意味する。

【0236】

現在のところ、単一のオペレーティングシステムのさまざまなバージョンが全く同じに扱われている。これが理想的でないことを今後のデータが示す場合には、特殊化が必要で
あるかもしれない。

【0237】

メモリ情報
このソースは、ＡＩＸおよびＦｒｅｅＢＳＤプラットフォームのために定義され、瞬間的な物理および仮想メモリ使用量を調べる。Ｌｉｎｕｘは、/proc/meminfoソースを使用
して同様の情報を採集する。

【0238】

【表9】

【0239】

ここで、可変のパラメータは実験により求められ、それらのデフォルト値はホスティングオペレーティングシステムに基づく。

【0240】

【表10】

【0241】

単一のオペレーティングシステムのさまざまなバージョンを全く同じに扱うことができる。これが理想的でないことを今後のデータが示す場合には、特殊化が必要であるかもしれない。

【0242】

現状では、このソースは、ＦｒｅｅＢＳＤマシンにとって価値のあるものであるようには思われない。しかし、このデータは、他の場合にはアイドルである仮想マシン上での洗練されていない部分的収集からのものである。改善を進める余地は十分にある。

【0243】

ネットワーク情報
セクションネットワーク
このソースは、ＦｒｅｅＢＳＤプラットフォームのために定義され、ネットワークインターフェイス上のトラフィック統計を調べる。Ｌｉｎｕｘは、/proc/net/devソースを使
用して同様の情報を採集する。

【0244】

【表11】

【0245】

時間
セクション時間
このソースは、高解像度クロックに基づいてエントロピを返す。それは、全てのプラットフォームで有用であり、使用されるクロックは、プラットフォーム当たり変化する。全てのプラットフォーム上で、このソースは、サンプリング当たり１バイトを放出する。

【0246】

【表12】

【0247】

ここで、可変のパラメータは実験により求められ、それらのデフォルト値はホスティングオペレーティングシステムに基づく。

【0248】

【表13】

【0249】

現在のところ、単一のオペレーティングシステムのさまざまなバージョンが全く同じに扱われている。これが理想的でないことをデータが示す場合には、特殊化が必要であるかもしれない。「その他」の列は、clock_gettime(2)システムコールをサポートせず、その結果、代わりに低解像度gettimeofday(2)コールに戻るシステムのためのものである。

【0250】

ＩＯ
ＡＩＸ、ＨＰ－ＵＸ、ＳｏｌａｒｉｓおよびＷｉｎｄｏｗｓのために定義される。Ｌｉｎｕｘは、その代わりに/proc/diskinfoソースを使用する。

【0251】

【表14】

【0252】

ここで、可変のパラメータは実験により求められ、それらのデフォルト値はホスティングオペレーティングシステムに基づく。

【0253】

【表15】

【0254】

現在のところ、単一のオペレーティングシステムのさまざまなバージョンが全く同じに扱われている。これが理想的でないことをデータが示す場合には、特殊化が必要であるかもしれない。

【0255】

ＰＲＮＧ
ＲＤＲＡＮＤ命令を使用するＩｎｔｅｌｘ８６プラットフォームのために定義される
。それは、ＲＤＲＡＮＤ命令に対する懸念によりデフォルトでディスエーブルにされる。これらの懸念は２つある。すなわち、要求しているにもかかわらず命令が高品質のエントロピを生成しない可能性があること、および、命令が動作の一部としてプール内の既存のエントロピを損なう可能性があることである。しかし、これは、マシン上で利用できる群を抜いて高速のエントロピソースであるため、エントロピに対する要求が非常に高く、エントロピのブラックボックス性を気にしない場合には、このソースをイネーブルにする。

【0256】

【表16】

【0257】

ＨＲＮＧ
ＲＤＳＥＥＤ命令を使用するＩｎｔｅｌｘ８６プラットフォームのために定義される。それは、ＲＤＳＥＥＤ命令に対する懸念によりデフォルトでディスエーブルにされる。ＲＤＲＡＮＤの場合と全く同じ懸念が当てはまる。我々が行っているようにＰＲＮＧのためにエントロピプールをシード処理する目的では、ＲＤＲＡＮＤよりもＲＤＳＥＥＤが推奨される。したがって、イネーブルにされるなら、ＲＤＲＡＮＤよりもＲＤＳＥＥＤが好まれるべきである。

【0258】

【表17】

【0259】

命令カウンタ
このモジュールは、ＴＳＣ命令を用いるＩｔａｎｉｕｍおよびＳＰＡＲＣプラットフォームならびにｘ８６プロセッサでのみ有用であろう。ＩｔａｎｉｕｍのＩＴＣレジスタもｘ８６のＴＳＣレジスタも命令サイクルカウンタを提供する。オペレーティングシステムおよび他のタスクが存在する状態で、これは、下位ビットの適量のエントロピを提供する。

【0260】

【表18】

【0261】

ここで、可変のパラメータは実験により求められ、それらのデフォルト値はホスティングオペレーティングシステムに基づく。

【0262】

【表19】

【0263】

【0264】

/dev/random
ソースは、ＵＮＩＸおよびＬｉｎｕｘカーネルエントロピプールから読み出す。このプールがしばしばブロッキングであるので、デフォルトは、非常にまれに非常に少量のエントロピを読み出すに過ぎないというものである。ホストシステムがこのソースを介して、たとえばハードウェア乱数発生器またはhavegedを介して、大量の高品質のエントロピを
提供するように構成される場合には、バッファサイズは著しく増加し得て、間隔は短くなり得る。

【0265】

【表20】

【0266】

/dev/urandom
このソースは、ＬｉｎｕｘおよびＵＮＩＸシステム上で擬似乱数発生器を提供する。このソースの根底をなすエントロピプールの品質については保証がないので、それはエントロピを供給する性質を持つとは考えられない。

【0267】

【表21】

【0268】

/dev/srandom
ＢＳＤに特有のソースは、カーネルエントロピプールから読み出す。このプールがしばしばブロッキングであるので、デフォルトは、非常にまれに非常に少量のエントロピを読み出すに過ぎないというものである。ホストシステムがこのソースを介して、たとえばハードウェア乱数発生器またはhavegedを介して、大量の高品質のエントロピを提供するよ
うに構成される場合には、バッファサイズは著しく増加し得て、間隔は短くなり得る。

【0269】

【表22】

【0270】

/dev/prandom
このソースは、Ｌｉｎｕｘ／Ｓ３９０システム上で擬似乱数発生器を提供する。このソースの根底をなすエントロピプールの品質については保証がないので、それはエントロピを供給する性質を持つとは考えられない。

【0271】

【表23】

【0272】

getentropy
このソースは、ＯｐｅｎＢＳＤ、ＳｏｌａｒｉｓおよびＬｉｎｕｘ上で利用可能なgetentropy(2)システムコールである。

【0273】

【表24】

【0274】

getrandom
このソースは、ＳｏｌａｒｉｓおよびＬｉｎｕｘ上で利用可能なgetrandom(2)システムコールである。それは、/dev/randomおよび/dev/urandomソースと同一のエントロピプー
ルから得られる。

【0275】

【表25】

【0276】

CryptGenRandom
このＷｉｎｄｏｗｓ専用ソースは、CryptGenRandom暗号品質乱数発生器を使用する。

【0277】

【表26】

【0278】

/proc/diskstats
ディスクＩＯサブシステム統計を使用するＬｉｎｕｘに特有のソース。

【0279】

【表27】

【0280】

/proc/interrupts
ＣＰＵ割り込み統計を使用するＬｉｎｕｘに特有のソース。

【0281】

【表28】

【0282】

ここで、可変のパラメータは実験により求められ、それらのデフォルト値はホスティングプロセッサアーキテクチャに基づく。

【0283】

【表29】

【0284】

現在のところ、プロセッサのさまざまなバージョンが全く同じに扱われている。これが理想的でないことをデータが示す場合には、特殊化が必要であるかもしれない。

【0285】

/proc/meminfo
システムメモリ情報を使用するＬｉｎｕｘに特有のソース。

【0286】

【表30】

【0287】

ここで、可変のパラメータは実験により求められ、それらのデフォルト値はホスティングプロセッサアーキテクチャに基づく。

【0288】

【表31】

【0289】

【0290】

/proc/net/dev
ネットワークインターフェイス統計を使用するＬｉｎｕｘに特有のソース。

【0291】

【表32】

【0292】

ここで、可変のパラメータは実験により求められ、それらのデフォルト値はホスティングプロセッサアーキテクチャに基づく。

【0293】

【表33】

【0294】

【0295】

/proc/timer_list
カーネルタイマ統計を使用するＬｉｎｕｘに特有のソース。

【0296】

【表34】

【0297】

Ｗｉｎｄｏｗｓプロセス情報
このＷｉｎｄｏｗｓに特有のソースは、現在実行中のプロセスのうちの必ずしも全てではないがいくらかを読み出し、各々からタイミング、メモリサイズおよびＩＯ詳細を抽出して、そのエントロピを作成する。

【0298】

【表35】

【0299】

ユーザインターフェイス情報
Ｗｉｎｄｏｗｓプラットフォーム上で、カーソル位置および現在注目されているウィンドウのようなユーザインターフェイスのさまざまな局面を使用するソースが検討された。このようなソースは、ヘッドレスサーバ上では意味のあるエントロピを生成することはできない。しかし、ワークステーション上ではいくらかのエントロピを生成することができる。それは人間の速度で動作しなければならないので、生成レートは遅い。

【0300】

生成レートおよび生成されるエントロピの品質を定量化することは極めて困難であるので、このソースは、最終的に検討から除外された。このソースを分析しようとする試みがなされ、１週間にわたるデータ収集の後、６４キロバイト未満の生データが生成されたが、これは意味のある統計を生成するには不十分である。品質の妥当な推定値がなければ、モジュールは、ソースがゼロエントロピを生成していると控えめに想定しなければならない。非常に遅く、信頼できるエントロピを生成しないソースは、ひいき目に見ても大したものではない。したがって、このようなソースを含まない判断をした。

【0301】

シードソース
最初のシード処理は、システムのさまざまな部分から情報を募り、それらをエントロピバッファに送り込む。これらは、一般に、優れたエントロピソースではなく、デバイスを区別するのに役立つ。これを説明するために、この段階の間にゼロエントロピが受け取られると仮定する。初期化中に真のエントロピソースも使用していくらかのエントロピを有しようとするが、それらは、多くの場合、有効になるのにある程度時間がかかる可能性がある。

【0302】

Ｕｎｉｘシードソース

【0303】

【数28】

【0304】

Ｗｉｎｄｏｗｓシードソース

【0305】

【数29】

【0306】

シードソースの構成
構成システムは、シードセクションにおける値を設定することによって、より大きな、より時間のかかるシードソースを選択的にディスエーブルにすることを可能にする。一般に、シードソースのデフォルト設定を変更する必要はない。

【0307】

また、ディスエーブルにすることができない軽量高速シードソースが複数ある。これらは、時刻、高速タイマ、システムのホスト名、さまざまなシステムおよびプロセスＩＤを含む。

【0308】

【表36-1】

【表36-2】

【表36-3】

【0309】

カーネルエントロピソース
オペレーティングシステムのエントロピプールに直接入力されるエントロピを採集するために複数の異なるソースが利用可能である。これらのソースのうちの１つまたはいくつかを実行して、カーネルが通常提供するエントロピソースを超えてさらなるエントロピソースを提供することは有益である。より多くのソースを有していても害はなく、それらは役立つに過ぎないであろう。これらのソースは全て、低リソース使用である。

【0310】

ＨＡＶＥＧＥ
ＨＡＶＥＧＥは、高速タイマによって、未知であるが知ることのできる内部ＣＰＵ状態からエントロピを取得する。これは、プロセスを成功裏に起動できる場合には、全てのプラットフォーム上でエントロピソースとして使用されるべきである。我々は、/dev/randomを介して、またはプロセスへの直接的なパイプを介して、フィードを取得することがで
きる。一般に、前者はよりよい選択肢である。なぜなら、それはエントロピを必要とするシステム上の全てのものにエントロピを提供するからである。

【0311】

現在のところ、ＨＡＶＥＧＥは、ｘ８６、ｉａ６４、ＰｏｗｅｒＰＣ、ＩＢＭＳ３９０およびＳＰＡＲＣのために直接サポートされている。他のプラットフォーム上では、それは、依然として機能的であるがそれほど効率的であるとは思えないgettimeofday(2)を
使用することになる。

【0312】

ＨＡＶＥＧＥの拡張部分が出力を白色化することが、根底にある品質に関わらずそれを真のエントロピと区別がつかなくするということに関して懸念が提起されてきた。ＴｅｓｔＵ０１からのクラッシュおよびビッグクラッシュテストは、１０^９バイトのサンプルサイズで提供されたときに、変更されたＨＡＶＥＧＥの出力を純粋なエントロピと区別することができる。当該変更は、高速タイマを、定数を返す機能と置換する。結論は、拡張が暗号品質白色化を生じさせないということである。

【0313】

しかし、ＨＡＶＥＧＥは、それがタイマから受取るエントロピを拡張している。各々の
３２バイトの出力について、ＨＡＶＥＧＥアルゴリズムは、タイマを一度サンプリングする。さらに、タイマは、立て続けにサンプリングされるため、２．４ビットのサンプル当たり比較的低いエントロピを生成する。したがって、出力の各バイトは、０．０６２５ビットよりもわずかに多いエントロピを有する。

【0314】

ＣＰＵジッター乱数発生器
ＣＰＵジッター乱数発生器は、ＨＡＶＥＧＥと同様の原理で動作し、現代のＣＰＵの複雑な隠し内部状態に依拠してタイミングジッターを提供し、当該タイミングジッターは、エントロピを生成するために使用される。これら２つの間の主な違いは、ＨＡＶＥＧＥがコードおよびデータキャッシュ、分岐予測因子ならびにトランスレーション・ルックアサイド・バッファを能動的に実行しようとすることである。その代わりに、ＣＰＵジッター乱数発生器は、ＣＰＵ内部状態を受動的に測定する。

【0315】

ＴＵＲＢＩＤ
Ｔｕｒｂｉｄは、オーディオ装置上でフローティング入力からエントロピを生成する。それは、ジョンソンナイキストノイズに基づいて、証明可能な最低レベルのエントロピを有する。我々は、このデーモンからの直接入力は受け入れず、その代わりに、それがエントロピを/dev/randomに送り込むことに依拠するであろう。未使用の音声入力を有する全
てのシステム上でこのデーモンを実行することが推奨される。それが駄目な場合は、可能なら他のフローティング音声入力エントロピソースのうちの１つが使用されるべきである。

【0316】

ＭＡＸＷＥＬＬ
Ｍａｘｗｅｌｌは、短時間のスリープ後にタイミングジッターからエントロピを生成する。それは、非常に軽量で保守的に設計されており、生成されたエントロピを/dev/randomに出力する。このソースは、存在する真のエントロピを曖昧にする可能性を有する、ソ
ースが出力するビットを混合して白色化しようとする。このデーモンまたは別のタイムジッターベースのソースを全ての適切なシステム上で実行することが推奨される。

【0317】

ＲＡＮＤＯＭＳＯＵＮＤ
Ｒａｎｄｏｍｓｏｕｎｄは、上記のＴｕｒｂｉｄと同様に、フローティング音声入力からエントロピを採集する。しかし、得られる最低レベルのエントロピを定量化しようとする試みはなされない。当然のことながら、依然として証明可能な最低レベルは存在するが、カーネルに提供される推定値は数学的基礎に基づかない。

【0318】

クロックランダム性採集デーモン
クロックランダム性採集デーモンは、異なる物理的な高周波数クロック間の変動を使用してエントロピを生成する。タイムベースの各々がおそらく独立してジッターを生じさせることを考慮すると、これは単一のタイムソースよりも優れたエントロピソースであろう。このデーモンのためのソースコードは行方不明になったように見え、このプロジェクトはおそらく終わっている。

【0319】

音声エントロピデーモン
音声エントロピデーモンは、ＲＡＮＤＯＭＳＯＵＮＤおよびＴＵＲＢＩＤのようなフローティングアナログ音声入力を使用する別のソースである。ＲＡＮＤＯＭＳＯＵＮＤのように、生成されるエントロピ最小値を理論的に定量化しようとする試みはなされない。

【0320】

タイマエントロピデーモン
タイマエントロピデーモンは、ＭＡＸＷＥＬＬと同様に、スリープの間中タイミングジッターを使用してエントロピを生成する。このデーモンは、ＭＡＸＷＥＬＬよりもさらに
一層軽量であり、小さな計算をすることによって気分転換しようとはせず、むしろgettimeofday(2)サンプリングによってラップされる１００μｓスリープのみを使用する。

【0321】

映像エントロピデーモン
映像エントロピデーモンは、ビデオキャプチャ装置からのフレーム間の差をエントロピソースとして使用する。エントロピの品質は、ビデオキャプチャのターニング（turning
）およびビデオキャプチャがアナログであるかデジタルであるかに左右される。理想的には、デチューンされたアナログキャプチャが使用されるが、デジタルテレビが支配的になっている状態では、このようなハードウェアは、音声入力と同一の商品レベルには到達しそうにない。

【0322】

ノイズ
ノイズエントロピソースは、白色化および混合ステップを有するさまざまな割り込みソース（キー押し、ディスクＩＯ...）の高解像度タイミングを使用する。このソースは、
ｘ８６アセンブリコードで完全にコード化され、ＤＯＳシステムのためのデバイスドライバとして書き込まれた。それは、実用化には古過ぎると考えられる。

【0323】

オペレーティングシステムによるソース
各オペレーティングシステムのための一次および二次エントロピソースを以下に列挙する。各ソースの個々の構成に関するより具体的な詳細については先に詳述している。

【0324】

Ｌｉｎｕｘ

【0325】

【表37】

【0326】

Ｓｏｌａｒｉｓ

【0327】

【表38】

【0328】

Ｗｉｎｄｏｗｓ

【0329】

【表39】

【0330】

他のＵｎｉｘ

【0331】

【表40】

【0332】

用語集

【0333】

【表41-1】

【表41-2】

【表41-3】

【0334】

フローチャート
図５は、実施形態に係るプロセス５００を示すフローチャートである。当該プロセスは、プロセッサにおいて命令を実行することによって、またはその他の方法でコンピュータによって実行することができる。動作５０１において、繰り返しタイマを第１の周波数に設定する。動作５０２において、第２の繰り返しタイマを第２の周波数に設定し、第２の周波数は、第１の周波数とは異なっており、この場合には第１の周波数と調和していない。動作５０３において、予め定められた数の第１のビットを第１のエントロピソースから第１の周波数で収集し、予め定められた数は、第１のエントロピソースに起因するビット当たりのエントロピの量に基づく。動作５０４において、第１のビットを擬似乱数発生器に提供する。動作５０５において、特定の数の第２のビットを第２のエントロピソースから第２の周波数で採集し、特定の数は、第２のエントロピソースに起因するビット当たりのエントロピの量に基づく。動作５０６において、第２のビットを擬似乱数発生器に提供する。第１および第２のビットを使用して擬似乱数発生器をシード処理することができる。動作５０７において、擬似乱数発生器からの出力に基づいて第１および／または第２の周波数を定期的に調節する。

【0335】

図６は、実施形態に係るプロセス６００を示すフローチャートである。当該プロセスは、プロセッサにおいて命令を実行することによって、またはその他の方法でコンピュータによって実行することができる。動作６０１において、この場合互いに調和していない、互いに異なる周波数の非同期タイマを設定する。動作６０２において、非同期タイマのう
ちの第１のタイマに従って、予め定められた数の第１のビットを第１のエントロピソースから収集する。動作６０３において、収集された連続する第１のビット間のハミング距離を計算する。動作６０４において、ハミング距離が最小値を超えたことに基づいて、第１のビットを第１のアキュムレーションバッファに受け入れる。動作６０５において、第１のビットの連続的な収集間のハミング距離と、第１のアキュムレーションバッファのコンテンツに起因するエントロピの累積値とを合計する。動作６０６において、第１のアキュムレーションバッファのコンテンツを擬似乱数発生器に提供する。動作６０７において、非同期タイマのうちの第２のタイマに従って、特定の数の第２のビットを第２のエントロピソースから採集する。動作６０８において、第２のビットを第２のアキュムレーションバッファに受け入れ、第２のアキュムレーションバッファは、第１のアキュムレーションバッファのサイズとは異なるサイズを有する。動作６０９において、第２のアキュムレーションバッファのコンテンツを擬似乱数発生器に提供する。

【0336】

コンピューティング機器
図７は、本発明のさまざまな実施形態が実現され得る例示的なコンピュータシステム７００を示す。システム７００は、上記のコンピュータシステムのうちのいずれかを実現するよう用いられてもよい。図に示されるように、コンピュータシステム７００は、多数の周辺サブシステムとバスサブシステム７０２を介して通信する処理ユニット７０４を含む。これらの周辺サブシステムは、処理加速ユニット７０６、Ｉ／Ｏサブシステム７０８、ストレージサブシステム７１８および通信サブシステム７２４を含んでもよい。ストレージサブシステム７１８は、有形のコンピュータ読取可能な記憶媒体７２２およびシステムメモリ７１０を含む。

【0337】

バスサブシステム７０２は、コンピュータシステム７００のさまざまなコンポーネントおよびサブシステムに想定通りに互いに通信させるための機構を提供する。バスサブシステム７０２は単一のバスとして概略的に示されているが、バスサブシステムの代替的実施形態は、複数のバスを利用してもよい。バスサブシステム７０２は、さまざまなバスアーキテクチャのうちのいずれかを用いるメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、このようなアーキテクチャは、業界標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、エンハンストＩＳＡ（Enhanced ISA：ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（Video Electronics Standards Association：ＶＥＳＡ）ローカルバス、およびＩＥＥＥＰ１３８６．１規格に従って製
造される中二階バスとして実現され得る周辺コンポーネントインターコネクト（Peripheral Component Interconnect：ＰＣＩ）バスを含んでもよい。

【0338】

１つ以上の集積回路（たとえば、従来のマイクロプロセッサまたはマイクロコントローラ）として実現可能な処理ユニット７０４は、コンピュータシステム７００の動作を制御する。１つ以上のプロセッサが処理ユニット７０４に含まれてもよい。これらのプロセッサは、シングルコアプロセッサを含んでもよく、またはマルチコアプロセッサを含んでもよい。特定の実施形態では、処理ユニット７０４は、シングルコアまたはマルチコアプロセッサが各処理ユニットに含まれる１つ以上の独立した処理ユニット７３２および／または７３４として実現されてもよい。他の実施形態では、処理ユニット７０４は、２つのデュアルコアプロセッサを単一のチップに統合することによって形成されるクアッドコア処理ユニットとして実現されてもよい。

【0339】

さまざまな実施形態では、処理ユニット７０４は、プログラムコードに応答してさまざまなプログラムを実行することができ、複数の同時に実行されるプログラムまたはプロセスを維持することができる。任意の所与の時点で、実行されるべきプログラムコードの一
部または全ては、プロセッサ７０４、および／または、ストレージサブシステム７１８に常駐することができる。好適なプログラミングを介して、プロセッサ７０４は、上記のさまざまな機能を提供することができる。コンピュータシステム７００は、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、特殊目的プロセッサなどを含み得る処理加速ユニット７０６をさらに含んでもよい。

【0340】

Ｉ／Ｏサブシステム７０８は、ユーザインターフェイス入力デバイスおよびユーザインターフェイス出力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを有する音声入力デバイス、マイクロフォン、および他のタイプの入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、たとえば、ジェスチャおよび話し言葉コマンドを用いて、ナチュラルユーザインターフェイスを介して、ＭｉｃｒｏｓｏｆｔＸｂｏｘ（登録商標）３６０ゲームコントローラなどの入力デバイスをユーザが制御して対話することを可能にするＭｉｃｒｏｓｏｆｔＫｉｎｅｃｔ（登録商標）モーションセンサなどのモーション感知および／またはジェスチャ認識デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、ユーザから目の動き（たとえば、写真を撮っている間および／またはメニュー選択を行なっている間の「まばたき」）を検出し、アイジェスチャを入力デバイス（たとえば、ＧｏｏｇｌｅＧｌａｓｓ（登録商標））への入力として変換するＧｏｏｇｌｅＧｌａｓｓ（登録商標）瞬き検出器などのアイジェスチャ認識デバイスも含んでもよい。また、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを介して音声認識システム（たとえば、Ｓｉｒｉ（登録商標）ナビゲータ）と対話することを可能にする音声認識感知デバイスを含んでもよい。

【0341】

ユーザインターフェイス入力デバイスは、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびにスピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザレンジファインダ、および視線追跡デバイスなどの聴覚／視覚デバイスも含んでもよいが、それらに限定されるものではない。また、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影、磁気共鳴撮像、ポジションエミッショントモグラフィー、医療用超音波検査デバイスなどの医療用画像化入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力デバイスも含んでもよい。

【0342】

ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイスなどの非ビジュアルディスプレイなどを含んでもよい。ディスプレイサブシステムは、陰極線管（cathode ray tube：ＣＲＴ）、液晶ディスプレイ（liquid crystal display：ＬＣＤ）またはプラズマディスプレイを使うものなどのフラットパネルデバイス、投影デバイス、タッチスクリーンなどであってもよい。一般に、「出力デバイス」という語の使用は、コンピュータシステム７００からユーザまたは他のコンピュータに情報を出力するための全ての考えられ得るタイプのデバイスおよび機構を含むよう意図される。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイスおよびモデムなどの、テキスト、グラフィックスおよび音声／映像情報を視覚的に伝えるさまざまな表示デバイスを含んでもよいが、それらに限定されるものではない。

【0343】

コンピュータシステム７００は、現在のところシステムメモリ７１０内に位置しているものとして示されているソフトウェア要素を備えるストレージサブシステム７１８を備え
てもよい。システムメモリ７１０は、処理ユニット７０４上でロード可能および実行可能なプログラム命令と、これらのプログラムの実行中に生成されるデータとを格納してもよい。

【0344】

コンピュータシステム７００の構成およびタイプによって、システムメモリ７１０は、揮発性であってもよく（ランダムアクセスメモリ（ＲＡＭ）など）、および／または、不揮発性であってもよい（リードオンリメモリ（ＲＯＭ）、フラッシュメモリなど）。ＲＡＭは、一般に、処理ユニット７０４にすぐにアクセス可能であり、および／または、処理ユニット７０４によって現在動作および実行されているデータおよび／またはプログラムモジュールを含む。いくつかの実現例では、システムメモリ７１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの複数の異なるタイプのメモリを含んでもよい。いくつかの実現例では、起動中などにコンピュータシステム７００内の要素間における情報の転送を助ける基本的なルーティンを含むベーシックインプット／アウトプットシステム（basic input/output system
：ＢＩＯＳ）は、一般に、ＲＯＭに格納されてもよい。一例として、限定を伴うことなく、システムメモリ７１０は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）などを含んでもよいアプリケーションプログラム７１２、
プログラムデータ７１４およびオペレーティングシステム７１６も示す。一例として、オペレーティングシステム７１６は、ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（登録商標）、ＡｐｐｌｅＭａｃｉｎｔｏｓｈ（登録商標）および／もしくはＬｉｎｕｘオペレーティングシステム、さまざまな市販のＵＮＩＸ（登録商標）またはＵＮＩＸのようなオペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、ＧｏｏｇｌｅＣｈｒｏｍｅ（登録商標）ＯＳなどを含むがこれらに限定されない）、ならびに／または、ｉＯＳ、Ｗｉｎｄｏｗｓ（登録商標）Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ（登録商標）ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標）１０ＯＳ、およびＰａｌｍ（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムのさまざまなバージョンを含んでもよい。

【0345】

ストレージサブシステム７１８は、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能な記憶媒体も提供してもよい。プロセッサによって実行されたときに上記の機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、ストレージサブシステム７１８に格納されてもよい。これらのソフトウェアモジュールまたは命令は、処理ユニット７０４によって実行されてもよい。ストレージサブシステム７１８は、本発明に従って使用されるデータを格納するためのリポジトリも提供してもよい。

【0346】

ストレージサブシステム７００は、コンピュータ読取可能な記憶媒体７２２にさらに接続可能なコンピュータ読取可能記憶媒体リーダ７２０も含んでもよい。システムメモリ７１０とともに、およびオプションとしてシステムメモリ７１０との組み合わせで、コンピュータ読取可能な記憶媒体７２２は、コンピュータ読取可能な情報を一時的および／またはより永久的に収容、格納、伝送および検索取得するための、遠隔の、ローカルな、固定された、および／またはリムーバブルなストレージデバイスに記憶媒体を加えたものを包括的に表わしてもよい。

【0347】

コードまたはコードの一部を含むコンピュータ読取可能な記憶媒体７２２は、記憶媒体および通信媒体を含む、当該技術分野において公知であるまたは使用されるいずれかの適切な媒体も含んでもよく、当該媒体は、情報の格納および／または伝送のための任意の方法または技術において実現される揮発性および不揮発性の、リムーバブルおよび非リムーバブルな媒体などであるが、これらに限定されるものではない。これは、ＲＡＭ、ＲＯＭ
、電気的に消去可能なプログラム可能ＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学式ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または他の有形のコンピュータ読取可能な媒体などの有形の非一時的なコンピュータ読取可能な記憶媒体を含んでもよい。特定される場合、これは、データ信号、データ伝送、または所望の情報を伝送するために使用可能でありコンピューティングシステム７００によってアクセス可能であるその他の媒体などの無形の一時的なコンピュータ読取可能な媒体も含んでもよい。

【0348】

一例として、コンピュータ読取可能な記憶媒体７２２は、非リムーバブル不揮発性磁気媒体に対して読み書きするハードディスクドライブ、リムーバブル不揮発性磁気ディスクに対して読み書きする磁気ディスクドライブ、ＣＤＲＯＭ、ＤＶＤおよびブルーレイ（登録商標）ディスクなどの、リムーバブル不揮発性光ディスクに対して読み書きする光ディスクドライブ、または他の光学式媒体を含んでもよい。コンピュータ読取可能な記憶媒体７２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digital：ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでもよいが、これらに限定されるものではない。コンピュータ読取可能な記憶媒体７２２は、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（solid-state drive
：ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭなどの揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（magnetoresistive RAM：ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組み合わせを使用するハイブリッドＳＳＤも含んでもよい。ディスクドライブおよびそれらの関連付けられたコンピュータ読取可能な媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュールおよび他のデータの不揮発性ストレージをコンピュータシステム７００に提供してもよい。

【0349】

通信サブシステム７２４は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム７２４は、他のシステムとコンピュータシステム７００との間のデータの送受のためのインターフェイスとして働く。たとえば、通信サブシステム７２４は、コンピュータシステム７００がインターネットを介して１つ以上のデバイスに接続することを可能にしてもよい。いくつかの実施形態では、通信サブシステム７２４は、（たとえば、セルラー電話技術、３Ｇ、４ＧもしくはＥＤＧＥ（グローバル進化のための高速データレート）などの先進データネットワーク技術、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー規格、もしくは他のモバイル通信技術、またはそれらのいずれかの組み合わせを用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）送受信機コンポーネント、グローバルポ
ジショニングシステム（global positioning system：ＧＰＳ）受信機コンポーネント、
ならびに／または、他のコンポーネントを含んでもよい。いくつかの実施形態では、通信サブシステム７２４は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続（たとえば、イーサネット（登録商標））を提供することができる。

【0350】

また、いくつかの実施形態では、通信サブシステム７２４は、コンピュータシステム７００を使用し得る１人以上のユーザの代わりに、構造化されたおよび／または構造化されていないデータフィード７２６、イベントストリーム７２８、イベント更新情報７３０などの形式で入力通信を受信してもよい。

【0351】

一例として、通信サブシステム７２４は、ソーシャルメディアネットワーク、および／または、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新情報
、ＲｉｃｈＳｉｔｅＳｕｍｍａｒｙ（ＲＳＳ）フィードなどのウェブフィード、および／もしくは１つ以上の第三者情報源からのリアルタイム更新情報などの他の通信サービスのユーザからリアルタイムでデータフィード７２６を受信するように構成されてもよい。

【0352】

さらに、また、通信サブシステム７２４は、連続データストリームの形式でデータを受信するように構成されてもよく、当該連続データストリームは、明確な終端を持たない、本来は連続的または無限であり得るリアルタイムイベントのイベントストリーム７２８および／またはイベント更新情報７３０を含んでもよい。連続データを生成するアプリケーションの例としては、たとえば、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などを挙げることができる。

【0353】

また、通信サブシステム７２４は、構造化されたおよび／または構造化されていないデータフィード７２６、イベントストリーム７２８、イベント更新情報７３０などを、コンピュータシステム７００に結合される１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するよう構成されてもよい。

【0354】

コンピュータシステム７００は、手持ち式の携帯デバイス（たとえば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえば、ＧｏｏｇｌｅＧｌａｓｓ（登録商標）頭部装着型ディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、さまざまなタイプのもののうちの１つであり得る。

【0355】

常に変化するコンピュータおよびネットワークの性質のため、図に示されるコンピュータシステム７００の記載は、単に具体的な例として意図される。図に示されるシステムよりも多くのコンポーネントまたは少ないコンポーネントを有する多くの他の構成が可能である。たとえば、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素が、ハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組み合わせで実現されてもよい。さらに、ネットワーク入力／出力デバイスなどの他のコンピューティングデバイスへの接続が利用されてもよい。本明細書における開示および教示に基づいて、当業者は、さまざまな実施形態を実現するための他の態様および／または方法を理解するであろう。

【0356】

上記の明細書では、本発明の局面についてその具体的な実施形態を参照して説明しているが、本発明はそれに限定されるものではないということを当業者は認識するであろう。上記の発明のさまざまな特徴および局面は、個々にまたは一緒に用いられてもよい。さらに、実施形態は、明細書のさらに広い精神および範囲から逸脱することなく、本明細書に記載されているものを超えて、さまざまな環境およびアプリケーションで利用することができる。したがって、明細書および図面は、限定的ではなく例示的であると見なされるべきである。

【図1】