値が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でも、会社方針・開発・運用・廃棄までトータルで考えなさいよって言ってますから業界全体がセキュリティ意識を持てればと思います。