はじめに
とりあえずの情報源
・ガイドラインの目的
・指針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/
現状の課題
- 開発者が必要だと考えても、経営側が許さない (確率的な話しで費用対効果、損益に関わる)
- 売切りビジネスとは整合性が悪い (サポート、フォロー費用を予め想定する必要がある)
- アップデート機能が脆弱性を引き起こす (製品設計と同レベルでOTAは考えないといけない)
- 既存HWでは太刀打ちできないことが多い (RoTが無い機器はもう無理)
- 中途半端なセキュリティはセキュリティの世界ではやらない方がマシ (独自暗号、独自セキュリティ機構、メンテナンスフリーセキュリティ、はあり得ない)
- 実装に長けたセキュリティ専門家がいない ((過去経験の)セキュリティ評論家はそれなりに多い。)
- セキュリティがらみのプレイヤーが自身の観点で語ってしまう (セキュリティ部分機能の提供者)
開発側の現状 (※開発と言っても範囲が広い。ここでは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ページ
- 概要
- Trusted Boot プロセスの概要 (Firmware Codeの認証、復号化) ※非対象鍵暗号
- ソフトウェアアーキテクチャ
- ハードウェアアーキテクチャ
- Trusted Bootの要件表