IoTサービスの安全な運用のために心がけたいセキュリティのポ … · サービスの安全な運用のために ... 各社のベストプラクティスの理解に加えて、セキュリティ開発プロセスの観点も必要

© 2019 Ubiquitous AI Corporation. All rights reserved.This presentation is for informational purposes only. Ubiquitous AI Corporation makes no warranties, express or implied, in this summary.

IoTサービスの安全な運用のために心がけたいセキュリティのポイント～最新の半導体セキュリティ技術の活用と、

IoT機器の継続的なセキュリティの実現～

代表取締役社長長谷川聡

株式会社ユビキタスAIコーポレーション

Agenda会社紹介

IoTセキュリティに関わる動向

IoTセキュリティを実現するための開発プロセス

弊社サービス・製品紹介

会社紹介

© 2019 Ubiquitous AI Corporation 3

会社概要会社名株式会社ユビキタスAIコーポレーション（UAC）所在地＜本社＞〒160-0023 東京都新宿区西新宿 1-21-1 明宝ビル６F

＜事業所＞五反田＜営業所＞大阪、名古屋沿革

– 2001年 5月元マイクロソフトのエンジニアを中心に株式会社ユビキタスを創業、組込みソフトウェア事業開始– 2005年大手ゲームメーカーに組込みネットワーク製品が採用– 2007年 11月 JASDAQ NEO市場に上場（現在はJASDAQ上場）– 2010年 3月 Ubiquitous QuickBootを発売開始– 2012年 12月株式会社村田製作所と資本・業務提携締結– 2016年 4月株式会社エイムを子会社化– 2017年 4月株式会社エーアイコーポレーションを子会社化– 2018年 7月株式会社エーアイコーポレーションを吸収合併

商号を株式会社ユビキタスAIコーポレーションに変更

資本金 14億8,272万円（2019年3月31日現在）代表取締役社長長谷川聡事業内容組込み機器関連ソフトウェア開発・輸入・販売 URL https://www.ubiquitous-ai.com/ グループ企業株式会社エイム https://www.aim-inc.co.jp/


組込みセキュリティに関する知見・経験

組込みシステムに最適な小フットプリント

ハードウェア性能を最大限引き出す実装力

「小さく」「軽く」「速い」、規格のベストインプリメーンテーション

OSとハードウェアの課題を理解した実装力

難解なセキュリティの理解と実装力コネク

ティビティ

セキュリティ

Linux / Android 高速起動

組込みデータベース

技術開発力：テクノロジーインベンター

多数の組込みセキュリティ製品開発実績

世界中に幅広く構築したパートナーネットワーク

30年以上の海外輸入商社としての歴史と経験

長年の多数のお客様とのお取引実績

時代のトレンドに即した最新ソフトウェアの発掘力

ブランド目利き

実績チャネル

技術・商材開拓力：テクノロジーブリッジ

多数の組込みセキュリティ製品取り扱い


2019.04.18 ユビキタスAIコーポレーション、IoT機器に最適化したセキュリティ検証サービスの提供を開始

2018.11.12 ユビキタスAIコーポレーションと凸版印刷、セキュアなIoTサービスを実現する「Edge Trust」を2019年3月より提供

2018.10.24 ユビキタスAIコーポレーションと米国Beyond Security社、IoT機器の脆弱性・セキュリティ検証のための新ツールの共同開発に合意

2018.07.06 ユビキタスAIコーポレーションの「Ubiquitous TPM Security」、約24億台の機器が利用するセキュリティ国際規格の最新仕様TPM 2.0に対応

2018.04.24 ユビキタス社、ルネサスエレクトロニクス社のセキュリティ機能搭載マイコンRX65N対応のセキュアIoT機器開発キットを発売

2017.10.24 サイバートラストとユビキタス、IoT機器向けの脆弱性診断サービスにおける協業を開始

2017.10.24 ユビキタス・AIコーポレーショングループ、IoT機器のサイバーセキュリティ対策とソフトウェア品質向上を実現する製品群と技術サービスを統合した事業を開始

IoTセキュリティ関連の主な取り組み

IoTセキュリティ

トータルソリューション

協業

セキュア実装

Trust Zone

セキュアIP

TPM2.0

フレーム開発

Edge Trust

ツール開発

ファジング

サービス開発

セキュリティ検証

IoTセキュリティに関わる動向


IoT機器のセキュリティに関する認識

Security COST


IoT機器のセキュリティに関する認識

Security MUST


COSTSecurity


MUSTSecurity


IoT機器の急速な普及とサイバー攻撃

出典:総務省平成30年版情報通信白書より抜粋

図表1-1-2-2分野・産業別のIoTデバイス数及び成長率予測

図表3-3-5-2宛先ポート番号別の年間観測パケット数割合


IoTセキュリティ関連の規制・ガイドライン整備状況

ガイドラインなど

FIPS140-3 SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULESSP 800-193 Platform Firmware Resiliency GuidelinesSP 800-183 Network of ‘Things’SP 800-121 BLE BluetoothSP 800-144 CloudSP 800-52 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) ImplementationsSP 800-63 Digital Identity GuidelinesSP 800-82 Guide to Industrial Control Systems (ICS) SecuritySP 800-160 Security Systems EngineeringSP 800-161 Supply Chain Risk ManagementNISTIR 8228 Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks NISTIR 8114 Report on Lightweight EncryptionNISTIR 8060 Software Assessment Management Standards and GuidelinesSP 1800-15 Securing Small Business and Home Internet of Things (IoT) Devices:NISC サイバーセキュリティ戦略本部サイバーセキュリティ 2019（案）経産省商務情報製作局サイバーセキュリティ課サイバー・フィジカル・セキュリティ対策フレームワークCCDS 製品分野別セキュリティガイドライン

認証など ISO/IEC 15408(CC), CMVP

開発プロセスなどISO 21434SAE J3061Secure by Design/ https://www.gov.uk/government/collections/secure-by-designSecurity by Design/ NISC

組織、団体など NIST、IPA、ISAC、総務省、NICT、CCDS、NISC, ETSI, IEEE, IoTSF…

既知の脆弱性情報など CVE/CVSS, CWE, MS Exploitability Index, 0day.today, cxsecurity.com…

法整備など世界初カルフォルニア州で IoT セキュリティに関する法律が成立：SB-327 Information privacy: connected devices.UK での関連法制定:https://www.gov.uk/government/news/plans-announced-to-introduce-new-laws-for-internet-connected-devices

https://www.gov.uk/government/news/plans-announced-to-introduce-new-laws-for-internet-connected-devices


主要プレイヤーのセキュリティベストプラクティス

Cloud

IoT Device

各社のベストプラクティスの理解に加えて、セキュリティ開発プロセスの観点も必要

ArmArm Security ManifestoArm Security Solutions

RenesasThe Renesas Security Mission

IAR SystemsSecurity Solutions

AWS IoT (Amazon Web Service) AWS Security releases IoT security whitepaperhttps://aws.amazon.com/jp/blogs/security/aws-security-releases-iot-security-whitepaper/

・設計/開発/導入工程におけるセキュリティ対応の作りこみ・セキュリティ対策の優先順位や影響に焦点を当てた対策・既知の(世界的に認められた)、IoTベストプラクティスの適用

Azure IoT (Microsoft) モノのインターネット (IoT) のセキュリティに関するベストプラクティスhttps://docs.microsoft.com/ja-jp/azure/iot-fundamentals/iot-security-best-practices

https://www.google.co.jp/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwjXz7mn2M7UAhWDVbwKHctTAkwQjRwIBw&url=https://www.kintaisystem.com/column/column03.html&psig=AFQjCNFgmicPmqH-t9nstJvCYAZ4xsmq-A&ust=1498125975057946


https://aws.amazon.com/jp/blogs/security/aws-security-releases-iot-security-whitepaper/

https://docs.microsoft.com/ja-jp/azure/iot-fundamentals/iot-security-best-practices

IoTセキュリティを実現するための開発プロセス


IoT機器の性質と脅威

• 脅威の影響範囲・度合いが大きい

• ライフサイクルが長い

• 監視が行き届きにくい

• ネットワーク側との環境や特性の差異が大きい（相互理解不十分）

• 機能・性能が限られている

• 想定外の接続の可能性

IoT機器に関する性質・課題

• 不正アクセス

• 不正利用

• マルウェア感染

• 不正な複製

IoT機器に関する脅威

• 送信データの傍受・改ざん

• 制御データの改ざん

開発プロセスにおいて、これらを「認識」することが重要

Cloud

IoT Device




セキュリティ企画

IoTサービス

“IoTセキュリティ” 実現のための開発プロセスのポイント

従来の V 字開発モデルの範囲

従来の V 字開発モデルとは異なる、運用・保守も企画段階から見据えた観点が必要

脆弱性インシデント

管理

ペネトレーション・

ファジングテスト

対策要件

脅威分析

リスク分析

設計・実装

コンポーネントテスト

システムテスト


開発現場のセキュリティーの実践

企画開発製造利用開始保守利用停止終了

Security by Design

• セキュリティ設計（すり合わせ）• セキュリティ実装• セキュリティ評価（脆弱性検査など）

セキュリティを事前に考慮

ベストプラクティス

• ある時点における最良、実践例• 実践例は、流動的で常に変化• ベストプラクティスの統合

常に学習し改善し続ける精神

PDCA

IoT機器のライフサイクル


サプライチェーンとIoT機器のライフサイクル

デバイスの鍵・証明書の管理

Root Of Trustの構築

製造管理セキュアな

デジタル証明書の書込

製造から廃棄に至るまでのライフサイクルを考慮した設計と開発

個々のIoT機器にユニークなデジタル証明書(クライアント証明書・機器ID・パスワード)

を埋め込み【キッティング作業】

デバイスの鍵・証明書管理

暗号化通信セキュアIPアクセス

デバイス管理

クラウドサービスへの確実なディアクティベート

デバイスやサービスへの利用開始手続きを実行（アクティベーション）

改ざん・盗聴の心配のない、セキュアなファームウェアアップデート

開発

製造

設置

運用

廃棄


“セキュリティ”開発プロセスでの我々の取り組み

分類我々の取り組みポイント

• Root of Trust/トラストアンカーを起点としたトラストチェーンの構築

• IoT 機器（デバイスとサービス）の特性を踏まえた安全なライフサイクルマネジメント

• IoT機器のライフサイクルでの定期的な脆弱性診断IoTサービス✔運用・保守

セキュリティ企画✔ポリシー✔要件（脅威）✔アーキテクチャ

Root of Trust/トラストアンカーを起点としたトラストチェーンの構築


トラストチェーンとは、信頼（トラスト）をチェーン状に連鎖させること

トラストチェーンを構築する目的は信頼境界を構築すること– 信頼境界：完全性が確保された状態を分ける境界

完全性が確保されている＝信頼できると証明できるということ– Root of Trust（Trust Anchor）を起点として、トラストチェーンをつないでいく

• Root of Trust ：アセットを含む信頼できるコンポーネント• Trust Anchor：信頼を築くことができるアセット（ルート証明書、ホワイトリストなど）

信頼境界・Trusted Boundary

トラストチェーンの構築

Root of TrustTrust Anchor

トラストチェーン

アセット


ゼロトラストという考え方信頼境界内を無条件に信頼するのではなく、そもそも信頼境界内にない“信

頼できるかどうか分からない”ものを信頼できるようにするという考え方– 働き方改革、テレワークの発展により、従来のように社内ネットワーク＝信頼境界とい

う考え方が通用しなくなり、ゼロトラストの考え方を導入するケースも増えている• Google BeyondCorp が代表例（世界中、どこからでもインターネット経由で社内サービスにアクセス可能

な仕組みを実現、つまり VPN を使用しない）– ゼロトラストの根幹は

• 徹底したID＆アクセス管理→ 自分が把握している ID から、以前と同じアクセスになっているか

• 緻密なデバイス管理→ 最新のセキュリティパッチがあたっているか、おかしなアプリがインストールされていないか

• 継続したふるまい分析と信頼度設定→ 予期しないネットワークトラフィックを発生させていないか、おかしな操作が行われていないか

IoT サービスはゼロトラストを前提に Root of Trust からトラストチェーンをつなぎ、信頼境界を広げることを考える


信頼境界外からアクセスされるアセットを保護するためにアクセスする相手を認証し、トラストチェーンを構築し、信頼境界を広げる

相手を認証するとは、ID、パスワードや証明書を暗号モジュールで正しいことを検証すること

信頼境界内のアセットにアクセスするには

信頼境界・Trusted Boundary

正しい相手

信頼境界 [Trusted Boundary]

アセット

暗号モジュール

アセットへのインターフェース

アセットにアクセスするのは信頼できる相手からによる信頼できる

インターフェースを介してのみ

認証

認証することでアクセス元を信頼する

暗号モジュール自体の脆弱性について考える必要がある

相手を認証


暗号境界 [Cryptographic Boundary] ：暗号モジュールとして定義される機能を含む領域を考える– Sensitive Security Parameter［SSP］：セキュリティに関連する情報と SSP を使用する機能で構成される

• Critical Security Parameter［CSP］漏洩 / 変更がセキュリティ喪失につながる秘密情報（秘密鍵、暗号鍵など）

• Public Security Parameter［PSP］変更がセキュリティに影響を与え得るセキュリティ関連の公開情報（公開鍵、証明書など）

暗号モジュールのセキュリティ

？？？

信頼境界 [Trusted Boundary]

アセット

暗号モジュール：暗号境界・ Cryptographic boundary

SSP

アセットへのインターフェース

認証

アタックサーフェス

信頼境界を越えてアクセスされる可能性があるパス [アタックサーフェス] がシステム全体の脆弱性になる可能性がある→ アタックサーフェスを削減することが重要

例：不要な機能は削除する、権限を限定させるなど

IoT 機器（デバイスとサービス）の特性を踏まえた安全なライフサイクルマネジメント


IoTサービスのライフサイクルへの対応デバイスのライフサイクル ▼修理・交換

サービスのライフサイクル

加入利用脱退サービスA

加入利用脱退サービスB

機器固有のID

クライアント証明書

クライアント証明書

削除更新追加削除

IoT機器のライフサイクルを通して、IoTサービスやシステムの入れ替え、サービスの追加を証明書ベースで管理

企画開発製造利用開始保守利用停止メンテナンス

終了リユース・廃棄

サービス開発サービス運用（バージョンアップ、メンテナンス）


機器側• 鍵、秘匿情報管理

• 安全な環境での鍵、秘匿情報の保存• アクティベーション

• ファームウェアの更新(FOTA)

IoT サービスのトラストチェーンとライフサイクルマネジメントを実現するソリューションクラウド側と機器側の機能連携

IoT CloudPlatform

IoT Service Provider

ServiceDevice Management

証明書によるデバイス認証

クライアント証明書発行

Management Console

FOTA : Firmware On-The-Air

Device

DeviceOS

ApplicationAgent

App.#1

App.#2

IoT

機器

Secure Hardware

Key Management

FOTADevice Service

クラウド側• デバイス管理

• クライアント証明書管理（発行・更新・無効化・削除）

• CA 証明書配布



Edge Trust セキュアなIoTサービスを実現するソリューション

IoT機器での秘匿情報管理– IoT 機器側へセキュアに鍵・証明書を書込み

クラウド側でのデバイスマネジメント– システムによる IoT 機器の

ライフサイクルを通じた証明書管理を実現

IoT サービスへの安全な通信– DLCM Service によって IoT 機器への事前のクラ

イアント証明書書込みが不要– クライアント証明書によるデバイス認証、サーバ

ー証明書によるサーバー認証を行い、サーバークライアント間で信頼境界を確立 DLCM Service

IoT機器


IoT 機器のライフサイクルマネジメントを実現するソリューション

セキュアな IoT サービスをサポートするエコシステムフレームワークを構築、パートナー企業様と連携し、安全な IoT 機器のライフサイクルマネジメントを実現

回収・廃棄サービス終了IoT サービス提供ファームウェア更新

アクティベーション

ファームウェア開発・書込システム設計

クラウドサービス(AWS)

クラウドサービスへのアクティベート

• システムと連動したIoT機器個別の鍵管理による効率的なRoot Of Trust構築

• セキュアハードウェアを利用した鍵管理• 固有IDの付与によるセキュアな生産・出荷管理

• 固有のクライアント証明書を鍵管理・デバイスID管理システムによって管理

• セキュアハードウェアを利用した鍵情報・秘匿情報の保護と鍵情報の更新または廃止による、盗難・紛失での秘匿情報漏えい防止

• 鍵管理・デバイスID管理システムによる鍵・証明書情報の廃止

• IoT機器でのセキュアな鍵管理により外部からの秘匿情報の抜出を防止

EOL

• 進化するインターネット技術に対しIoT機器を新たな脅威から守るための、定期的な脆弱性の検証

IoT 機器の脆弱性検証による新たな脅威への対策

IoT 機器セキュリティ検証サービス

DLCM AgentDLCM Service

デバイスのアクティベート

エコシステムフレームワーク

IoT機器のライフサイクルでの定期的な脆弱性診断


はじめに脆弱性

脆弱性対策情報データベースJVN iPediaの登録状況 [2019年第2四半期（4月～6月）]https://www.ipa.go.jp/security/vuln/report/JVNiPedia2019q2.html

*脆弱性対策の効果的な進め方（実践編）第 2 版https://www.ipa.go.jp/files/000071660.pdf

脆弱性対策の効果的な進め方（実践編）第 2 版*

「脆弱性は日々発見され、攻撃者が悪用できる新たな脆弱性は増え続ける。昨今では脆弱性の発見から攻撃に使われるようになるまでに掛かる時間は短くなっており、システムへの影響度が大きい脆弱性情報を早期に把握、対策を実施することの重要性は益々高くなっている。」


https://www.ipa.go.jp/security/vuln/report/JVNiPedia2019q2.html

https://www.ipa.go.jp/files/000071660.pdf


はじめに脆弱性診断


社内リソース対応の場合

• 非機能検証にリソースが回せない。• セキュリティ・プロトコル人材難

社外リソース活用の場合

• コンサル費用は包括的で、非常に高い• 属人的手法への依存が大きい

お客様の声

テーマ

Small Start

状況

提案

人

物

金

どんなツールを使えばいいのか？どれも、All-In-Oneではないですよね？

どこまで費用をかけられるか不明。ツール購入しても通年では使用しない。

人：社内リソース＋サービス利用の柔軟な運用物：未知の脆弱性、機器固有への柔軟な段階的対応金：サブスクリプションモデルの刷新


セキュリティテスト分類 Functional Testing

– セキュリティ関連機能の堅牢性と機能の正常な作動テスト Vulnerability Scan

– 既知の脆弱性に対してのスキャン Fuzzing

– 未知のセキュリティ脆弱性を見つけ出すテスト Penetration Testing

– 試験者が攻撃者を模倣してシステムへの侵入を試す

ファジングと侵入テストは、攻撃の可能性を網羅するのが極めて困難コスト、リソース、テスト範囲を決める（重要）


Fuzzing とは一般的な定義

– 想定外のデータによる機器の振る舞いをテストし未知の脆弱性を検出

– クラッカーがハッキング時に用いる手法を事前にテストすることでセキュリティ検証として有効

What is smart fuzzing?– Smart fuzzing means testing for where

you know the holes are.Noam Rathaus

ファズデータ

クラッシュ

不正パケット IoTデバイス


Fuzzing データ生成 -ツール利用- Attack Type

– データを生成するときの核となる最小のデータ単位

– Attack TypeはScale Typeによって拡張されAttack Vectorが作成される

Scale Type– Serial ( 1,2,3,4,,,,)– Base2 ( 2,4,8,16,,,, ) +/- 1– Base10 (10,100,1000,,,,) +/- 1

例ツールでのカスタム事例

コンフィグを調整して実行時間に合わせてFuzzingデータ生成

0 1 2 3

0

4 5 6 7 8 9 10 11

1

12 13 14 15 16 17 18 19

2

20 21 22 23 24 25 26 27

3

28 29 30 31

バージョンサービス種別全長ヘッダ長

フラグ断片位置識別子

プロトコルチェックサム生存時間

送信元アドレス

宛先アドレス

オプション

IPヘッダ

Attack Typeカスタム追加可能


Fuzzing データ生成 -エンジニアリング-特定フィールドの試験

– 各種OSSを利用して開発

オプションエリアの場合– オプション

• タイプ：security• レングス：0x00～0xFF

– 実行時間• 対象 2バイト：1時間弱• 対象 3バイト：1週間超

記述例


セキュリティ検証サービス


セキュリティ検証海外パートナー開発連携

– Beyond Security社との脆弱性検証ツール「beSTORM X」共同開発

新規検証サービス開始– be STORM X を活用したIoT機器のセキュリティ

に関する検証をサービスとして展開– 通信プロトコル・セキュリティ規格に精通した

エンジニアによるハイレベルなサービスの提供


beSTORM X Beyond Security

– 設立 1999年• HQ : 米国カリフォルニア州• R&D：イスラエル

– 主たる活動• セキュリティリサーチのサポート• セキュリティカンファレンス主催

beSTORM X特長– カスタマイズ

• XMLスクリプトで独自シナリオ作成• DLLインポートで独自プロトコル対応• エラー検知のモニター機能追加

– プロトコル• TCP/IP, Wi-Fi, Bluetoothなど、200種類以上

Small Start Security無償で検証トライアル! お求めやすい短期ライセンスも用

意しました！

検証ツール短期ライセンス

JITライセンス（1ヶ月～）beSTORM X

あらゆるプロトコル・機器へのファジングとペネトレーションをサポートするフレームワーク

検証サービス検証トライアルファジング1次診断検証報告書送付

ファジングからペネトレーションまで、エキスパートエンジニアによる脆弱性検証

ツールI/F

AttackVector

・ファジング・ペネトレーション対象機器

お客様FW セキュリティ検証環境

さいごに


IAR Systems 様とのコラボレーションデバイスのライフサイクル

企画開発製造利用開始保守利用停止メンテナンス

終了リユース・廃棄

Security from Inception Suite

IoT 機器のライフサイクルの起点は開発

サービスのライフサイクル

サービス開発サービス運用（バージョンアップ、メンテナンス）

ご清聴ありがとうございました

Documents

IoTサービスの安全な運用のために 心がけたいセキュリティのポ … · サービスの安全な運用のために ... 各社のベストプラクティスの理解に加えて、セキュリティ開発プロセスの観点も必要

IoTサービスの安全な運用のために心がけたいセキュリティのポ … · サービスの安全な運用のために ... 各社のベストプラクティスの理解に加えて、セキュリティ開発プロセスの観点も必要