値が6毎に偏る問題は解決できなかったので、とりあえずカウント値を6で割って、奇数(1)か偶数(0)かを乱数ビットとして取り込んでみました。
12ビットタイマー(ITCMP)の値による連続同値の分布をみたところ 測定時間が0.915msec(14+1x0.061msec)より短いとFIPS(20000bit毎に発生する連続同値の頻度)に適合できないようです。 特に連続1～3ビット同値になる規格に不適合です。
ということで、256msecあれば256ビットの真性乱数を生成することができました！
↑ 黒線が頻度上限、赤線が頻度下限
グラフから測定時間が短いと同値が連続する傾向が読み取れますね。(6ビット以上連続して同じ値になる確率があり得ないほど高いです)
クロック差を利用した乱数生成のサンプルプログラムをアップしてみました。(CS+for CA版ですけど) japan.renesasrulz.com/.../385
次は、A/D入力を使った乱数生成です。
端子をオープンにした状態でA/D変換すると、ANI0はVDDレベル(3FFh)、ANI1はGNDレベル(000h)に張り付いてしまうので、ANI2を使ったところ変換時間に関わらず変換値は±5以内に収束してしまいました。A/D端子オープン状態の入力インピーダンス(10MΩ程度?)による熱雑音にしてはバラツキが大きいので、ESD保護用のショットキーダイオードなどから発生する1/fノイズ由来のバラツキみたいですね。
とりあえず、AD変換値の最下位1ビットを乱数列とした場合、真性乱数にはなりませんでした。 1と0の総数に偏り(5%以上)が出ていて、連続同値の成績が悪いです。
変換時間が2.3usec、38usec共にFIPSの規格(黒と赤の範囲)から食み出しています。残念！
入力インピーダンスが高いANI16以降のチャンネルを使うと更に状況悪くなって、0/1の偏りが20%以上になるようです。>_< ちなみに、内部基準電圧や温度センサーを変換対象にすると偏りか99%を超えます。
Kirin様 お世話になっております。 大変参考になるデータの公開、ありがとうございます。 自分が使うようなケースだと、 初期値設定でクロック差による乱数、メイン処理実行時にA/Dポート式と 使い分けるのがいう感じがよさそう・・・
シェルティさん
通信関連が得意なシェルティさんコメントいただけて嬉しいです。 RX231のセキュアブートとかいいですよね。
私もいつの頃からか暗号に携わるようになって、AESをRL78にインプリしたりしてますけど、 ローエンドマイコン中心なので低コスト・低消費を意識しながら処理しなくてはいけなくて色々苦労しています。 だいたいお金のないケチケチ・プロジェクトなので、ライブラリなどを購入できずに自作が多いです。 (ライブラリ買ってきた方が工数換算で全然安いハズなんですけども、、、)
でも、シェルティさんのご指摘どおり、セキュリティは全体的な思想が大切なので 暗号化を入れれば完成ってもんじゃないんですよね。 ISO26262などでは物理的な機能安全は規定されてますけどセキュリティは規定されていなので、 自動車を含めほぼ全てのIoT機器にはまともなセキュリティが実装されていない可能性が高いのかなと思います。 セキュリティ意識は2020年に向けてこれから加速しそうですね。
シェルティさんマイコン上で実行するコード自体の真正性を担保するのって中々むずかしくて、セキュアブートみたいに最初から標準で提供してくれると助かります。Iot機器の場合は、OTAアップデートとか下手にバージョンアップする経路があると装置を乗っ取られるリスクができるのでコードサイニングなどを使って正しくアップデートしないなら、むしろバージョンアップしないほうが安全だったりしますし。 3G/LTEを含め外部とつながりがある時点で、常時接続していなくてもアタックの対象になったり、マンインザ・ミドル的な攻撃もありますからね。 OSを載せる場合、telenet,FTPとか不要な(セキュリティリスクになる)機能は外しておいたり、ポートを閉めておいたり、いろいろ考えないといけなかったりしますよね。
セキュリティのプリミティブなところで、オンチップデバッグやフラッシュ書き込みIFからのハッキングで、機密性の高いROMコードを吸い出される可能性とかも考慮しないといけなかったりするので マイコンメーカーの提供するハード機能であっても社内でタンパテストの検証の対象にしていますし、出荷製品のセキュリティ設定が正しくなっているかとかの運用も大切ですね。
IPAでも、会社方針・開発・運用・廃棄までトータルで考えなさいよって言ってますから業界全体がセキュリティ意識を持てればと思います。
シェルティさんさすがですね。①②③が揃うと完璧ですね。やっぱりRX231のように１チップで、鍵にアクセスするために特別な手続きが必要なシステムの方がいいですよね。ATECC508A(暗号ハードウェアアクセラレーター)みたいものがありますけれども、秘密鍵がチップの外に出ないとは言うものの、マイコンと２チップ構成にするとコストやチップ間I/Fの心配がありますから。それにしてもアップルのセキュリティ仕様すごいですね。iPhone向けソフト開発の事務手続きがハンパないのも頷ける?!
そうそうARMマイコンのセキュリティを使うのはかなりハードルが高くて、ビジネス(売り上げ)にならなければ相手しないというスタンスのところが多いですね。 メーカーを口説くのが大変でNDA取り交わしまでたどり着くのも一苦労^^;
いまのところ第三者機関に認証を依頼している案件(企業)は限られているみたいですね。JCMVPの公開リストみても国絡みの調達とかだけみたいですし。 シェルティさんのおっしゃるとおり、「いまはシステム開発者が限られた予算内でできる限りのセキュリティ対策を施しておく、というのが良い手段なのだと思います。」ですね！
閑話休題、乱数の品質を見てみます。連続ビットとかの指標だと品質が見た目で分からないので、いわゆるポーカーテストをしてみました。乱数列を4ビットずつに分けて、4ビットの数値がどのくらいバラつくか、です。(サンプル数15000個)すると、ADコンバータから取れる乱数は同じパターンの繰り返しが多く、特定の値に偏っていることが分かります。一方LOCOを使った乱数は特定の値に偏ることなく均一なバラつきを示し、非常に品質がいいことが分かります。
シェルティさん教えていただいたSP800-22Aは知りませんでしたけれども、16種類も色々な尺度から検定を行なっているんですね。母分散の検定や推定に使われているχ(カイ)二乗検定が大活躍です。NISTの検定ソフトが必須ですね。
乱数を極めれば極めるほど、乱数の揺らぎの中に心地よさを感じていくのかな^-^
CC版でタイマーを使ったサンプルプログラムとアプリケーションノートを作成しました。japan.renesasrulz.com/.../411
下のA/Dポート版よりも時間は掛かりますけれども、性能は折り紙付きです。japan.renesasrulz.com/.../410
両方サンプル共に乱数品質を自己確認できるように真性乱数換算の有効ビット数を算出する関数を加えました。
気づけば、RL78/G1H(サブギガ無線マイコン)にAIS31準拠のTRNGがハード機能としてはじめから搭載されていました。
AIS31を調べてみるとFIPS140-2の元になった文章のようですね。(AIS31自体はドイツ語ですけど)monobit test、poker test、run testなどなど、どこかで見たことのあった?!9種類のテストで構成されていました。乱数品質の測定にエントロピーの考え方が入っていて、なるほどー(そだねー)と思いました。
AIS 31 -> ISO/IEC18031 -> NIST SP 800-90C , SP 800-22A
AIS31をパスするには、万一ハードウェア乱数生成器が故障しても、AIS20相当の高品質な擬似乱数を出力できれば良いみたいな感じで規定されていました。RL78/G1Hは凄い！(まぁ暗号機能の詳細は、例によってNDAを交わさないと仕様が出てこないみたいですけど、TRNGもAESもソフトコーディングできるからいいもんねー／笑)