Amazon FreeRTOSだそうです。ルネサスさんのRXは参加しないのかな?

こんにちは。NoMaYです。

ライセンスはMIT Licenseでした。TLSとしてmbed TLSが使用されていました。サポートされているボードの写真を見ていたら、どれにも有線LANコネクタが無いことに気付きました。時代の流れでしょうか、、、

Getting Started with Amazon FreeRTOS
aws.amazon.com/freertos/getting-started/

Amazon FreeRTOS
aws.amazon.com/freertos/

Amazon FreeRTOS ソースコード
github.com/aws/amazon-freertos

[関連リンク]

FreeRTOS - freertos.org
www.freertos.org/

FreeRTOS - sourceforge.net
sourceforge.net/projects/freertos/files/

FreeRTOS kernel自体はCC-RXにも対応
github.com/aws/amazon-freertos/tree/master/lib/FreeRTOS/portable/Renesas

Amazon FreeRTOSはTLSにmbed TLSを使用
github.com/aws/amazon-freertos/tree/master/lib/third_party/mbedtls

[ニュース]

組み込み業界に大インパクト「Amazon FreeRTOS」の衝撃 - 大原雄介,MONOist
monoist.atmarkit.co.jp/mn/articles/1712/28/news011.html

アマゾン「AWS IoT」は何が衝撃的なのか - 大原雄介,MONOist
monoist.atmarkit.co.jp/mn/articles/1510/21/news026.html

(2018/01/01 : 記事を選び直しました。)

[追記]

もしかしたら、オープンソースライセンスのドライバライブラリが用意されていないから、ルネサスさんはアマゾンさんに相手にして貰えないのかも、、、

ちなみに、FreeRTOS kernel自体のライセンスがV10からModified GPLからMIT Licenseに変わったようです。

Parents
  • こんにちは。NoMaYです。

    ニュースサイト巡りをしていたら以下の記事が出ていたのですが、1年程前にはFreeRTOS/Amazon FreeRTOSでも脆弱性の話が出ていたこと(その当時に修正完了済み)を思い出しました。以下のzimperiumの2つ目のブログを読むと、TCP/IPスタックの不具合によって正しくないメモリ操作が行われ、ケースバイケースで、Denial of Service、information leak、remote code executionが引き起こされるようですが、前2つはともかく、3つ目に至る経緯が当時も今も分かりません。今回のVxWorksの記事にもremote code executionの話が出ているのですが、なぜそういう話に至るのか、やはり分からなくて首を傾げているところです。。。ですが、ひょっとしたら、プログラムを外付けの記憶デバイス/記憶装置からRAMへ展開して動作させるシステムというのが暗黙の了解になっていて、それで、正しくないメモリ操作によるメモリ内容破壊(書き換え)が可能≒remote code executionのリスクあり、なのかな、と今しがた思ったのでした、、、それならば、内蔵フラッシュメモリ上でプログラムを実行しているシステムでは、かなり話が小さくなるのかな???

    VxWorksの脆弱性「URGENT/11」が浮き彫りにしたTCP/IPスタックの“残念な実装”
    monoist.atmarkit.co.jp/mn/articles/1909/26/news007.html

    FreeRTOS TCP/IP Stack Vulnerabilities Put A Wide Range of Devices at Risk of Compromise: From Smart Homes to Critical Infrastructure Systems
    blog.zimperium.com/freertos-tcpip-stack-vulnerabilities-put-wide-range-devices-risk-compromise-smart-homes-critical-infrastructure-systems/

    FreeRTOS TCP/IP Stack Vulnerabilities – The Details
    blog.zimperium.com/freertos-tcpip-stack-vulnerabilities-details/

    Amazon Freertos : Vulnerability Statistics
    www.cvedetails.com/product/51624/Amazon-Freertos.html?vendor_id=12126

    あと、脱線しますが、脆弱性とセキュリティは基本的には別概念なのですね、、、zimperiumの2つ目のブログを読んだ後に以下のスライドを読んだら実感しました、、、

    IoT におけるセキュリティ
    www.slideshare.net/AmazonWebServicesJapan/iot-122553904
     

Reply
  • こんにちは。NoMaYです。

    ニュースサイト巡りをしていたら以下の記事が出ていたのですが、1年程前にはFreeRTOS/Amazon FreeRTOSでも脆弱性の話が出ていたこと(その当時に修正完了済み)を思い出しました。以下のzimperiumの2つ目のブログを読むと、TCP/IPスタックの不具合によって正しくないメモリ操作が行われ、ケースバイケースで、Denial of Service、information leak、remote code executionが引き起こされるようですが、前2つはともかく、3つ目に至る経緯が当時も今も分かりません。今回のVxWorksの記事にもremote code executionの話が出ているのですが、なぜそういう話に至るのか、やはり分からなくて首を傾げているところです。。。ですが、ひょっとしたら、プログラムを外付けの記憶デバイス/記憶装置からRAMへ展開して動作させるシステムというのが暗黙の了解になっていて、それで、正しくないメモリ操作によるメモリ内容破壊(書き換え)が可能≒remote code executionのリスクあり、なのかな、と今しがた思ったのでした、、、それならば、内蔵フラッシュメモリ上でプログラムを実行しているシステムでは、かなり話が小さくなるのかな???

    VxWorksの脆弱性「URGENT/11」が浮き彫りにしたTCP/IPスタックの“残念な実装”
    monoist.atmarkit.co.jp/mn/articles/1909/26/news007.html

    FreeRTOS TCP/IP Stack Vulnerabilities Put A Wide Range of Devices at Risk of Compromise: From Smart Homes to Critical Infrastructure Systems
    blog.zimperium.com/freertos-tcpip-stack-vulnerabilities-put-wide-range-devices-risk-compromise-smart-homes-critical-infrastructure-systems/

    FreeRTOS TCP/IP Stack Vulnerabilities – The Details
    blog.zimperium.com/freertos-tcpip-stack-vulnerabilities-details/

    Amazon Freertos : Vulnerability Statistics
    www.cvedetails.com/product/51624/Amazon-Freertos.html?vendor_id=12126

    あと、脱線しますが、脆弱性とセキュリティは基本的には別概念なのですね、、、zimperiumの2つ目のブログを読んだ後に以下のスライドを読んだら実感しました、、、

    IoT におけるセキュリティ
    www.slideshare.net/AmazonWebServicesJapan/iot-122553904
     

Children
  • NoMaYさん

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

    チップワンストップの記事紹介ありがとうございます。
    写真の背が低い方がシェルティです。背が低いと言っても一応180cmあります。坊主の人がさらにでかいです。

    RX65Nクラウドキットについてですが、いったんリリースはできましたが、
    まだまだ改善できるところが多く、今後も継続して後継品などの開発を行ってまいります。
    改善できるところとしてもっとも重要なのがセキュリティ実装です。
    NoMaYさんのコメントにありますが、脆弱性とセキュリティの概念は別ですが密接に関連してます。

    たとえばですが、RAM上の任意アドレスに任意データを注入し、プログラムカウンタをそこに飛ばせるような形でソフトウェアがバグっていたと仮定します。
    (通信系のソフトウェアで、受信バッファポインタ操作の設計を誤るとこのようなバグり方をする可能性があります)

    この状態で、①RAM上にフラッシュ書換用のコードを転送、②RAM上にリセットベクタを書き換えるコードを転送、③RAM上に②で書き換えるリセットベクタの先に配置するウイルスコードを転送、④RAM上に③のウイルスコードを②で書き換えるリセットベクタの先に転送するコードを転送、
    ソフトウェアの不具合を利用して、①②③④の順に実行していく、
    そうすると、リセット直後にウイルスが起動します。

    これを防ぐため、リセットベクタを含むシステム起動直後のコードに以下2機能を入れることが「セキュアブート」と呼ばれます。
    ①セキュアブート以外の領域が正しい状態を保っているか署名検証を行う
    ②セキュアブートが書き換えられないようにプロテクトをかける

    Amazonが定義しているブートシーケンスの要件とRX65Nでの推奨実装方法を以下に記します。
    github.com/.../OTAの活用

    このように、多くのセキュリティインシデントは、ソフトウェア脆弱性により引き起こされます。
    従ってソフトウェア脆弱性はソフトウェアのアップデートにより克服できなければなりません。
    ソフトウェアのアップデートは、実はセキュリティ要件でもあるのです。
    そして、ソフトウェア脆弱性はゼロにできないことを前提とし、いかなる状況においても、リセットベクタおよびリセットベクタの先にあるセキュアブートのコードは書き換えられてはならないのです。

    まとめますと、IoT機器の真のセキュリティ対策は以下の2点になります。
    ①不変なセキュアブートコード
    ②ソフトウェアアップデート

    組み込み機器をネットワーク対応する流れが「IoT」という流行りの言葉と共に出来上がってきていて、
    漠然と「ネットワークに繋がるからセキュリティを強化しなければならない」という危機感を持っている人が多くなってきているが現状です。
    ところが、セキュリティ対策は、それを施しやすい素地のある(つまりはLinux OSが動いているルータ製品等)モノに "ファイアウォールのソフトを入れる" といった対策しか施されず、さらにそれ以前の話である「パスワード未設定」などの "分かりやすいがテクノロジ的な視点からは全く無意味な" セキュリティインシデントが新聞沙汰になるにつけ、殊更、末端のデバイス(汎用マイコンが組み込まれるようなシステム)における "テクノロジベースの" セキュリティ対策、セキュアブート・ソフトウェアアップデートは限られた開発予算が主要因となり無視され、未実装となる傾向にあります。

    いまはそういった機器も脆弱性が生まれやすい通信系は閉じたもの、かつ、単純なものである場合が多く、問題が表面化していないだけです。
    ところがそういった機器をインターネットに繋ぐ機能を追加した途端、複雑怪奇なTCP/IPの処理機構のうち受信処理部分に潜んでいるかもしれない脆弱性を起点にウイルスを注入されてしまうリスクが増大します。
    これがIoT機器にはなんとなくセキュリティを実装しなければならない、と皆さんが漠然と感じている危機感の正体です。

    金融、ゲーム機、スマホ、車載といった「セキュリティ」でデバイスが守られていて当たり前の世界でようやく
    "テクノロジベースの"セキュリティ対策であるセキュアブート・ソフトウェアアップデートが一般化し、これから産業・民生機器もセキュアブート・ソフトウェアアップデートが一般化していきます。

    ■「電気通信事業法に基づく端末機器の基準認証に関するガイドライン(第1版)」(案)についての意見募集の結果及びガイドラインの公表
    www.soumu.go.jp/.../01kiban05_02000179.html
     ⇒提出された御意見及びこれに対する総務省の考え方(別紙1PDF)
      ⇒1-12 サイバートラスト社の指摘に対する総務省見解は「ソフトウェアの安全な更新を担保する仕組みについては、今後の検討課題とさせていただきます。」とのことから、
       現時点(2019/09/27)では推奨ではあるが、(おそらく今後)セキュアブートが必須という定義に変わっていくものと予想しております。
       現に、車載やヘルスケア分野などの安全性が求められる分野の安全規格においてセキュアブートは必須となっている場合が多いです。
       金融はお金を守ること、ゲーム機はコンテンツを守ることから、セキュリティの要求が強く
       これまたセキュアブートは当たり前のように実装されます。

    なるべく皆さまが、実際にセキュアブート・ソフトウェアアップデートを検討しないといけなくなったときに、
    汎用マイコンでそれを実現するための素地を先んじて整備しておくことが、今の私の役割のひとつだと考えております。

    以上です