Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

RL78で真性乱数生成器(TRNG)

本家でも度々話題に出るRL78で真性乱数生成器(TRNG)の研究をしてみます。
 
JCMVP/CMVPの試験にパスできるレベルの乱数にするべく、
米国連邦政府情報処理標準FIPS PUB 140-2規格を満足できるかチャレンジ!
 
まずは、。評価ボード(QB-R5F104PJ-TB)を使って内蔵発振器の位相ノイズ(ジッター)を使った乱数の味見をしたところ、
エンベロープ的には正規分布っぽいですけれども、6の倍数の値が顕著になっています。
 
・LOCOで測定した2msec毎の、HOCOカウント値の分布 
 
 
 
 FIPS140-2で要求されている20,000ビットの乱数列に対する連続同値の出現頻度の規定(0と1それぞれに適用)
  • 値が6毎に偏る問題は解決できなかったので、とりあえずカウント値を6で割って、奇数(1)か偶数(0)かを乱数ビットとして取り込んでみました。

    12ビットタイマー(ITCMP)の値による連続同値の分布をみたところ
    測定時間が0.915msec(14+1x0.061msec)より短いとFIPS(20000bit毎に発生する連続同値の頻度)に適合できないようです。
    特に連続1~3ビット同値になる規格に不適合です。

    ということで、256msecあれば256ビットの真性乱数を生成することができました!

    ↑ 黒線が頻度上限、赤線が頻度下限

    グラフから測定時間が短いと同値が連続する傾向が読み取れますね。(6ビット以上連続して同じ値になる確率があり得ないほど高いです)

  • In reply to Kirin:

    クロック差を利用した乱数生成のサンプルプログラムをアップしてみました。(CS+for CA版ですけど)
    japan.renesasrulz.com/.../385

  • In reply to Kirin:

    次は、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%を超えます。

  • In reply to Kirin:

    以上の結果から、ハードウェア乱数発生源の選択肢として
    高速さを意識するならA/Dポートを使用した乱数、
    乱数品質を意識するなら2つのクロック差を利用した乱数ということになりますね。
  • In reply to Kirin:

    Kirin様
    お世話になっております。

    大変参考になるデータの公開、ありがとうございます。

    自分が使うようなケースだと、
    初期値設定でクロック差による乱数、メイン処理実行時にA/Dポート式と
    使い分けるのがいう感じがよさそう・・・

  • In reply to Kirin:

    Kirinさん

    シェルティです、こんにちは。

    貴重な実験データとサンプルコードご提示ありがとうございます。
    私もRL78で乱数が必要なことがあったら使ってみたいと思います。
    汎用の回路でもここまで乱数性を高めることができるのですね。これは凄いと思います。

    最近だと乱数器や暗号器が搭載された汎用マイコンが増えてきていますね。
    RX231に真性乱数発生器とAESの回路が搭載されています。

    RX231はNISTのFIPS140-2の暗号アルゴリズム試験(CAVP)も通っていますね。

    AES
    csrc.nist.gov/.../aesval.html

    DRBG(疑似乱数)
    csrc.nist.gov/.../drbgnewval.html

    ⇒真性乱数発生回路は別途NIST SP800-22の検定を第三者機関に依頼し実施して
     乱数性に問題ないことを確認しているとのことでした。
     ユーザが使う乱数は、真性乱数発生回路の出力を乱数種とし、
     上記DRBGに通したものとのことです。

    FIPS140-2は私も注目しています。
    セキュリティというと単に暗号通信を実装しておけばよいという考えが先に来ますが
    FIPS140-2をよくよく読むと、怪しいファームが実行されないように
    リセットベクタからジャンプした先ですぐにファームの完全性を確認せよ、とか、
    暗号通信につかう鍵データは然るべき方法で安全な状態で保持せよ、とか、
    アタック検知したら鍵データをゼロ化せよ、とか様々なセキュリティの一般要件が
    まとめて書いてあり参考になります。汎用マイコンを使ったシステムで
    どこまでセキュリティ性を求め、実装していくかという、
    コストパフォーマンスの問題はクリアしていく必要はありますが、
    セキュリティが必要な装置が究極的にはどのように実装されるべきか、
    というお手本として参照し、コストパフォーマンスの問題をクリアしつつ
    セキュリティ性も必要最低限だけ維持できる妥協点を探るのに
    とても良い情報源なのでは、と考えています。

    以上です
  • In reply to Sugachance:

    Sugachanceさん
    確かに、用途別に乱数生成法を変えて使うとパフォーマンスがよくなりますね^^
    乱数による自局アドレスの決定などは高品質の乱数、ふつうに使うのは高速な乱数とか、適材適所で。
  • In reply to シェルティ:

    シェルティさん

    通信関連が得意なシェルティさんコメントいただけて嬉しいです。
    RX231のセキュアブートとかいいですよね。

    私もいつの頃からか暗号に携わるようになって、AESをRL78にインプリしたりしてますけど、
    ローエンドマイコン中心なので低コスト・低消費を意識しながら処理しなくてはいけなくて色々苦労しています。
    だいたいお金のないケチケチ・プロジェクトなので、ライブラリなどを購入できずに自作が多いです。
    (ライブラリ買ってきた方が工数換算で全然安いハズなんですけども、、、)

    でも、シェルティさんのご指摘どおり、セキュリティは全体的な思想が大切なので
    暗号化を入れれば完成ってもんじゃないんですよね。
    ISO26262などでは物理的な機能安全は規定されてますけどセキュリティは規定されていなので、
    自動車を含めほぼ全てのIoT機器にはまともなセキュリティが実装されていない可能性が高いのかなと思います。
    セキュリティ意識は2020年に向けてこれから加速しそうですね。

  • In reply to Kirin:

    Kirinさん

    シェルティです、こんにちは。

    私は通信中心にそれなりにノウハウを持っているつもりですが、
    すこし得意分野を外れると勉強が必要なことばかりです。
    Kirinさんや、みなさまの投稿を読んでいつも勉強させていただいております。

    さておき、ローエンドでのセキュリティはコスト・消費電力との闘いになりますね。
    現状セキュリティは直接エンドユーザへの価値にならず、「保険」的な意味合いが
    強いので開発側もなかなか投資に踏み切れない現状があるようです。
    ですが、人命にかかわる、車・ヘルスケアの分野を中心に安全規格面から
    セキュリティ要件(特にセキュアブート/ファームアップデート(セキュリティホール塞ぎ))が
    挙がり始めていますね。
    ja.ulstandards.ul.com/.../

    FIPS140-2というと米国政府の調達要件でしたので、一般製品の要件として挙げられることは
    軍事・金融系の製品を除いてあまりなかったようですが、昨今、組み込み機器のネットワーク対応が進み、
    セキュリティ要件のターゲット範囲も広がり、特定分野毎の安全規格に
    FIPS140-2に書いてあるようなセキュリティ要件が取り込まれるようになってきたものと推測します。

    こうした安全規格にセキュリティ要件が取り込まれて本格化してこれば、必然、
    暗号通信、ストレージデータの暗号化はもとより、セキュアブートやファームアップデート機能が
    必要機能となってくることが予想されますね。

    以上です
  • In reply to シェルティ:

    シェルティさん
    マイコン上で実行するコード自体の真正性を担保するのって中々むずかしくて、セキュアブートみたいに最初から標準で提供してくれると助かります。
    Iot機器の場合は、OTAアップデートとか下手にバージョンアップする経路があると装置を乗っ取られるリスクができるので
    コードサイニングなどを使って正しくアップデートしないなら、むしろバージョンアップしないほうが安全だったりしますし。
    3G/LTEを含め外部とつながりがある時点で、常時接続していなくてもアタックの対象になったり、マンインザ・ミドル的な攻撃もありますからね。
    OSを載せる場合、telenet,FTPとか不要な(セキュリティリスクになる)機能は外しておいたり、ポートを閉めておいたり、いろいろ考えないといけなかったりしますよね。

    セキュリティのプリミティブなところで、オンチップデバッグやフラッシュ書き込みIFからのハッキングで、機密性の高いROMコードを吸い出される可能性とかも考慮しないといけなかったりするので
    マイコンメーカーの提供するハード機能であっても社内でタンパテストの検証の対象にしていますし、出荷製品のセキュリティ設定が正しくなっているかとかの運用も大切ですね。

     

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

  • In reply to Kirin:

    Kirinさん

    シェルティです、こんにちは。

    コメントありがとうございます。まさに仰る通りと思います。
    セキュアブートが標準でマイコン機能としてあるとユーザは助かりますね。
    この方向になるよう方々働きかけていきたいと考えています。

    突き詰めると①セキュアブートで使用するコード検証用の鍵データを
    マイコン内でどう保持するか、②セキュアブートがいかに改ざんされないか、課題になります。

    アタッカはソフトウェア不具合を利用し任意コードをRAMに流し込みそこに
    プログラムカウンタを飛ばし、任意コードによりメモリプロテクト設定を変更し、
    セキュアブートを改ざんしたりもしてきます。Androidの「脱獄」といわれている操作ですね。
    また、任意コード実行によりROMの中にある重要なデータ(鍵データなど)を読みだそうとします。
    このへんをどうやって守り切るかが、真の組み込みセキュリティと認識しています。

    iPhoneのホワイトペーパーが非常に参考になりますね。
    RX231に搭載のセキュリティIPの考え方はこれに近いので、
    単なる暗号処理アクセラレータとはひと味違う回路ということになりますね。
    images.apple.com/.../iOS_Security_Guide.pdf

    あとは、③上記のようなソフトウェア不具合はゼロにできない、という考え方のもと、
    セキュリティ要件として、ファームウェアアップデート機能が必要となっているようです。

    ①~③の課題に対する組み込みセキュリティ対策は以下の通りと思っています。

    ①セキュリティIP内で鍵データを安全に保存する仕掛け
    ②絶対改ざんできないROM領域にセキュアブートを配置
    ③ファームアップデート機能

    ファームアップデート機能は開発者メリット(機能・性能UP)に目がいきがちですが、
    セキュリティ要件でもある点に注意が要ると思います。

    閑話休題で乱数器の話ですが、乱数性もセキュリティ要件の重要な要素ですね。
    Kirinさん設計の考え方で生成された乱数値はNISTの基準値を満たしますので、
    乱数のパターンからシステムの脆弱性が暴かれるリスクは極小であるといえます。

    セキュリティはこのようにありとあらゆるアタック手法を考慮にいれて設計する
    必要があり、何もないところから作ろうとすると非常に労力が要りますね。
    デバイスレベルでこのあたりを包含できて、第三者認証機関により
    お墨付きが得られている(それこそFIPS140-2の検定(CMVP)に合格)デバイスが
    IoT機器の心臓部として選定対象に挙がりやすくなってくるものと予想します。

    いまはシステム開発者が限られた予算内でできる限りの
    セキュリティ対策を施しておく、というのが良い手段なのだと思います。

    ARM陣営も着々と組み込みセキュリティ強化の準備を進めている様子がうかがえますね。
    www.arm.com/.../trustzone-cryptocell
    ⇒Security Certification and Compliance 参照

    以上です
  • In reply to シェルティ:

    シェルティさん
    さすがですね。①②③が揃うと完璧ですね。
    やっぱりRX231のように1チップで、鍵にアクセスするために特別な手続きが必要なシステムの方がいいですよね。
    ATECC508A(暗号ハードウェアアクセラレーター)みたいものがありますけれども、秘密鍵がチップの外に出ないとは言うものの、マイコンと2チップ構成にするとコストやチップ間I/Fの心配がありますから。
    それにしてもアップルのセキュリティ仕様すごいですね。iPhone向けソフト開発の事務手続きがハンパないのも頷ける?!

    そうそうARMマイコンのセキュリティを使うのはかなりハードルが高くて、ビジネス(売り上げ)にならなければ相手しないというスタンスのところが多いですね。
    メーカーを口説くのが大変でNDA取り交わしまでたどり着くのも一苦労^^;

    いまのところ第三者機関に認証を依頼している案件(企業)は限られているみたいですね。JCMVPの公開リストみても国絡みの調達とかだけみたいですし。
    シェルティさんのおっしゃるとおり、「いまはシステム開発者が限られた予算内でできる限りのセキュリティ対策を施しておく、というのが良い手段なのだと思います。」ですね!

  • In reply to Kirin:

    閑話休題、乱数の品質を見てみます。
    連続ビットとかの指標だと品質が見た目で分からないので、いわゆるポーカーテストをしてみました。
    乱数列を4ビットずつに分けて、4ビットの数値がどのくらいバラつくか、です。(サンプル数15000個)
    すると、ADコンバータから取れる乱数は同じパターンの繰り返しが多く、特定の値に偏っていることが分かります。
    一方LOCOを使った乱数は特定の値に偏ることなく均一なバラつきを示し、非常に品質がいいことが分かります。

  • In reply to Kirin:

    Kirinさん

    シェルティです、こんにちは。

    素晴らしい結果ですね。
    いただいたサンプルコード、大事に保存させていただいております。

    乱数検定はSP800-22Aという規格が代表例でよく聞きますね。

    リファレンス:
    nvlpubs.nist.gov/.../nistspecialpublication800-22r1a.pdf

    NISTのページにはこれに対応した乱数検定用のプログラムコードがあるようですね。
    csrc.nist.gov/.../documentation_software.html

    また、私はまだ試していないですが、上記をWindows用に移植した無料ツールもあるようです。
    無料ツール:
    dnki.co.jp/.../

    以上です
  • In reply to シェルティ:

    シェルティさん
    教えていただいたSP800-22Aは知りませんでしたけれども、16種類も色々な尺度から検定を行なっているんですね。
    母分散の検定や推定に使われているχ(カイ)二乗検定が大活躍です。NISTの検定ソフトが必須ですね。

    乱数を極めれば極めるほど、乱数の揺らぎの中に心地よさを感じていくのかな^-^

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page