はじめに

毎週日曜日の11時から、@Vengineer氏が半導体、CPUがらみのトピックの雑談会をされており、時々(最近はしょっちゅう)聴かせてもらっていた。質問したりしているウチに、何かテーマで喋ってって言われたので、ここ最近コンサル業務で関わっていた、IoTセキュリティ関連の話をさせてもらうことにした (2023年2月12日(日)予定)。
 

とりあえずの情報源

日本発信のIoTセキュリティに関わる情報源としては、まずは下記の2件を観ておいた方が良い。
 

・ガイドラインの目的

・指針1〜5 (①基本設計(経営者コミット、リスク備える)、②リスク認識、③設計の指針、④ネットワークでの対策、⑤出荷・リリース後の情報発信、共有)

・一般利用者のルール (①サポート無い機器を避ける、②初期設定、③使わない機器の電源断、④機器を手放す場合のデータ消去)

・IoTセキュリティの現状と課題

・本書の狙い

・IoTのセキュリティ設計 (脅威分析、対策の検討、脆弱性対応(開発時、運用時))

・IoT関連のセキュリティガイド (OWASP, Framework, ガイドライン)

・脅威分析と対策検討例

 

これまで大きく話題になっているセキュリティの問題

・DDoS攻撃の踏み台

・Webカメラで覗かれる

「中華ウェブカメラ」のセキュリティについて https://r00tapple.hatenablog.com/entry/2017/08/12/050252

・初期PWから変わっていないWebカメラが世界中で観られている(た)

 SHODAN https://www.shodan.io/

 

現状の課題

  1. 開発者が必要だと考えても、経営側が許さない (確率的な話しで費用対効果、損益に関わる)
  2. 売切りビジネスとは整合性が悪い (サポート、フォロー費用を予め想定する必要がある)
  3. アップデート機能が脆弱性を引き起こす (製品設計と同レベルでOTAは考えないといけない)
  4. 既存HWでは太刀打ちできないことが多い (RoTが無い機器はもう無理)
  5. 中途半端なセキュリティはセキュリティの世界ではやらない方がマシ (独自暗号、独自セキュリティ機構、メンテナンスフリーセキュリティ、はあり得ない)
  6. 実装に長けたセキュリティ専門家がいない ((過去経験の)セキュリティ評論家はそれなりに多い。)
  7. セキュリティがらみのプレイヤーが自身の観点で語ってしまう (セキュリティ部分機能の提供者)

開発側の現状 (※開発と言っても範囲が広い。ここではChip(SoC)開発)

・セキュリティ業界では、「Security by Design」と言われるが、真面目にすると開発費、開発期間が倍増する

・セキュリティ専門家が多く無い (セキュリティ評論家は多い)

・「Security by Design」の手引き書がほとんど無い → Arm社のドキュメントが一番進んでいる?

 

SoC関連のセキュリティトピック

SoCのセキュリティ対応のドキュメント "Trusted Board Boot Requirements CLIENT (TBBR-Client) Armv8-A"

・TrustZoneのSecure Applicationは、この要件を満たしていないとセキュリティ的に辛い

・2018年(5年前)のArmv8-A を使ったSoCのTEEの考え方に基づくBootプロセスについて書かれたガイドラインのドキュメント

・PDF 49ページ

  1. 概要
  2. Trusted Boot プロセスの概要 (Firmware Codeの認証、復号化) ※非対象鍵暗号
  3. ソフトウェアアーキテクチャ
  4. ハードウェアアーキテクチャ
  5. Trusted Bootの要件表

TrustedFirmware-A (TF-A)

OP-TEE

TBBR-Clientの概要

Software Architecture

TBBR-Clientで説明しているセキュリティシステムの構成。
Exception LevelがEL0〜3、S-EL0,1に分けられて、それぞれ、Trusted World, Non-Trusted World領域の重なりで機能がラベル付けされている。
 
 

Trusted Base System Architecture の例

TBBR-Clientのドキュメントでは例として図が提示されるだけで、内部の詳細の説明は無い。
エンジンとかあれば、セキュリティ領域の定義に従ってDMAとかに関わるセキュリティ構成は自前でちゃんと考えなければならない。
 
 
 

Trusted Boot Processの概要

Power On後 (Cold RESET後)は Trusted World での処理が行われる。
Trusted Boot Processの各ステップで、信頼の連鎖が拡張される。
Trusted Boot ROMの段階で、OTAに関わる機能は実装しておかないといけない。
 
 

終わりに

IoTセキュリティの取っかかりとして、SoCが持っているハズの Secure Bootに関して、Arm社のTBBR-Clientドキュメントの図をトレースしていった。
IoTセキュリティは、それを司る人達でいろいろなアピール、アプローチがなされているが、統合的にソリューションとして情報がそれなりにまとまっているのはTBBR-Clientぐらいだろう。
しかしながら日本でこのドキュメントの知名度はあまり高く無いように思われる。