パネルディスカッション_株式会社アーティファクト

Copyright 2007-2019 Artifact Inc. All rights reserved. PageDocument ID : AFT1900_TR00_191021_100
高橋正志（たかはしまさし）
株式会社アーティファクト代表取締役社長
株式会社シーエスサービス CTO
ICカード開発に従事し、2007年からITセキュリティに特化した会社を起業し現在に至る。
なお、同社ではEAL 4+以上に対応した製品開発が主たる事業領域の一つ。
1
自己紹介

IoT / CPSに要求されるセキュリティ
2

標準化組織
3
TCG
Trusted Computing Group
TPM標準
NIST
National Institute of Standards and Technology
米国政府調達要件に関連する標準
ECDSAに関するX9.62等
FIPS PUB
Federal Information
Processing Standards
Publication
SP
Special Publication
ISO / IEC
International Organization for Standardization /
International Electrotechnical Commission
IS
International Standard
ANSI
American National Standards Institute
米国内工業標準
IETF
Internet Engineering Task Force
インターネット関連標準
RFC
Request for Comments
SEC
Standards for Efficient Cryptography
Certicomを中心とする標準化団体
PKCS
Public-Key Cryptography Standards
RSAを中心とする標準化団体
Domain Parameter不整合
OSCCA[国家商用暗号管理弁公室]
Office of State Commercial
Cryptography Administration
中国独自標準
実質的なGlobal standard
ISO/IEC 15408で規定されるEAL取得時には、次の
PPが最も厳しく、セキュリティセンシティブな製品
の参照資料となります。
BSI-CC-PP-0084-2014 Security IC Platform
Protection Profile with Augmentation Packages
備考：BSIはBundesamt für Sicherheit in der
Informationstechnikの略Family2.0からは準拠の傾向
TPMはFIPS PUB 140に準拠した
一実装形態とも言えます
OSCCA標準をTCG Algorithm Registryに追加
RSAの買収以降、影響力は弱い
情報セキュリティに関する主要な標準化組織の関係は次の通りで、NIST標準はUSの国内標準でありながら、実質的に世界的な影響力を有しています。
なお、FIPSではアルゴリズム等の基本技術が、またSPでは暗号利用モード等の利用技術が対象となります。
他にIR［internal report］等も存在

標準化動向
4
ここまでの標準化動向を時系列的に見ると、 NIST SP 800-193及び総務省令第12号に見られるように2016年のDyn社に対するBotnetを利用したDDoS攻撃が標準化を牽
引してきたことがご理解頂けるかと思います。
ただし、その他にも多くの攻撃が知られていますから、セキュリティ事故が発生した場合の逸失利益［有形 / 無形］が大きな用途では、これら標準を参照し、リスク対策
を講じることが必要です。
Dyn社に対する大規模DDoS攻撃
October 2016
NIST SP 800-183
Network of 'Things'
July 2016
NIST IR 8114
Report on lightweight
cryptography
March 2017
NIST SP 800-193
Platform Firmware Resiliency
Guideline
May 2018
ファームウェアの障害耐性を確保す
るためには以下が必要。
・protection
・detection
・recovery
NIST IR 8228
IoTにおけるprotect対象を規定。
・device security［要脆弱性管理］
・data security
・individuals' privacy
NIST IR 8228
Considerations for Managing IoT
Cybersecurity and Privacy Risks
July 2019
FIPS PUB 140-3
Security requirements for
cryptographic modules
March 2019
総務省令第12号
端末設備等規則及び電気通信主任技
術者規則の一部を改正する省令
FIPS PUB 140-3
non-invasive attack対策の重要性が
増大したことで、ソフトウェア暗号
モジュールの認定取得可能レベルが
制約された
ISO/IEC 19790を参照
NoTの構成要素をprimitiveに分類し、
信頼性とセキュリティに関する主要
な問題点を提示
⇒ 以降の関連標準へリンク
FIPS PUB 140-2[May 2001]
信頼境界防御のためには、暗号境界
が必要で、その基本的な要件を定義
IoT関連の主要標準
主要規定
lightweight ≠ 脆弱では困る…
NIST SP 1900-202
Cyber-physical systems and
internet of things
March 2019
CPSとIoTのコンセプト
FIPS PUB 46
Data encryption standard
January 1977
FIPS PUB 197
Specification for the advanced
encryption standard (AES)
November 2001
FIPS PUB 186
Digital signature standard
November 1993
2016年 2017年 2018年 2019年2016年以前

NIST発行文書
5
NIST［national institute of standards and technology（US国立標準技術研究所）］は、科学技術分野における計測と標準に関する研究を行う米国商務省に属する政府機関です。
NIST内には、情報技術に関する研究を行っているITL［information technology laboratory］があり、情報技術に関して6つの分野［security、information access、
mathematics and computational science、software testing、networking research、statistical engineering］の研究を行っており、ITLでコンピュータセキュリ
ティに関して研究を行う部門が主に以下の4種類の文書を発行するCSD［computer security division］となります。
■ FIPS［federal information processing standards］
米国商務長官の承認を受けて、NISTが発行した情報セキュリティ関連の標準で、SP 800シリーズからFIPSとなったものもあります。
主なターゲットは米国政府ですが、推奨する管理策や要求事項、暗号化やハッシュ化、認証、デジタル署名及びLANのセキュリティ等、分野別に、詳細な基準や要求事項
とガイドラインを示し、政府機関のみならず民間企業にとっても、情報セキュリティ対策を考える上で有用な文書です。
■ Special Publications［SP 800シリーズ］
SP 800シリーズは、CSDが発行するコンピュータセキュリティ関係の文書です。
米国の政府機関がセキュリティ対策を実施する際に利用することを前提として策定された文書ですが、内容的には、セキュリティマネジメント、リスクマネジメント、セ
キュリティ技術、セキュリティの対策状況を評価する指標、セキュリティ教育、及びインシデント［注1］対応等、セキュリティに関して幅広く網羅しており、政府機関、
民間企業を問わず、セキュリティ担当者にとって有益な文書となります。
■ NIST IRs［NIST interagency reports］
NISTの各内部機関がまとめたレポートです。
■ ITL Security Bulletins
不定期に発行されるCSDの会報で、CSDの活動やCSD発行の文書に関する概要や枠組みが解説されています。
注1 ： ISO 22300 SECURITY AND RESILIENCE – VOCABULARYでは、”Situation that might be, or could lead to, a disruption, loss, emergency or crisis”［中断・阻害、損失、緊急事態、危機に、なり得る、また
はそれらを引き起こし得る状況］と規定されています。

NIST発行文書の調査方法
6
内容の精度はさておき、NIST刊行物についてはweb系のニュースでも取り上げられますが、どうしても遅延が発生します。
非効率的な方法ですが、弊社ではNISTのSearch Publicationsで定期的にリリースされた文書を調査し、先ずは斜め読みしています。
同ページでは、対象文書も選択可能ですので、先ずは"Federal Inf. Process. Stds. (NIST FIPS)"と"Special Publication (NIST SP)"を調査すれば十分かと思います。
https://www.nist.gov/publications/search?combine_1=&title=&field_publication_authors_value=&field_nist_pub_series_tid=8701&field_nist_org_tid=All&field_date_value%5Bmin%5D%5Bdate%5D=&field_
date_value%5Bmax%5D%5Bdate%5D=&field_report_number_value=&sort_by=field_date_value&sort_order=DESC&items_per_page=25

NIST SP 1900-202 Cyber-Physical Systems and Internet of Things［1］
7
cyber-physical system（CPS）とinternet of things（IoT）という用語の意味とそれらの関係にフォーカスした文書で、複雑なCPS / IoTアプリケーションの確実な設計
と運用のために、関連技術と標準基盤を統一することを目的としています。
なお、SP 1900シリーズの出版物は、物理コンポーネントと計算コンポーネントが相互作用するネットワークを含むスマートシステムとして定義されるCPSのコミュニ
ティをターゲットとした文書です。
FIGURE 4. IoT ARTICLE TRENDS
FIGURE 1. CPS ARTICLE TRENDS
■ 歴史
internet of thingsという用語は、一般的には1999年にMIT Auto-ID CenterのKevin AshtonがP&Gへのプレゼンテーション等で使用し
たとされています。
その概念はRFID［radio-frequency identification］コミュニティから生まれ、最初は、特にサプライチェーンでTrackable Objectsと
Data Objectsにフォーカスしていました。
一方、cyber-physical systemという用語は、2006年にNational Science Foundation（NSF）のHelen Gillが初めて使用し、その時点
から現在のIoTのコンセプトに近く、Interactive ObjectsとSmart Objectsまでが含まれ、メカトロニクス、組み込みシステム、及び
pervasive computingコミュニティで利用されるようになりました。
CPSとIoTと言う用語の認知度ですが、これら用語がタイトルに含まれる記事の出現件数をGoogle Scholarで調査した結果は右図の通り
で、一般的な認知度はIoTの方が圧倒的に高いと言えます。
なお、両者の関係には様々な説がありますが、最近のIoTの定義は、CPSの定義とほぼ等価となっています。
■ 領域の広汎性
機能によって定義された4カテゴリのオブジェクトが存在します。
・Trackable Objects（TO）：一意に識別可能で、物理的な場所が認識可能な可動であるモノ［mobile things］
・Data Objects（DO）：センサまたはその現在のプロパティ / 状態からデータを生成するモノ
・Interactive Objects（IO）：環境変数を測定するか、環境を変更するか、またはその両方を行うことで、それらが置かれ
た環境との相互作用を可能にするモノ
・Smart Objects（SO）：取得または受信したデータにある程度の処理を適用し、それに応じて動作可能なインタラク
ティブなモノ

NIST SP 1900-202 Cyber-Physical Systems and Internet of Things［2］
8
■ CPSとIoT関連の技術と標準基盤を統一する意義
2025年には9種類のIoTアプリケーションで潜在的な経済的影響が年間11.1兆ドルに達すると見込まれる市場の育成に向けて、モジュール性［modularity］と相互運用性の標
準を通じて関連技術の革新を加速することが目的で、その主要な対象として通信プロトコル、リファレンスアーキテクチャ、データモデル等のオープンでコンセンサス
ベースの標準が挙げられています。
■ モジュール性
代表的なプロファイルとして composability［構成可能性］とcompositionality［構成性］が挙げられています。
・ composability 既存のコンポーネントから新しいモノを構築する能力で、既存のセンサ、ネットワーク、分析、及び他インフラストラクチャを組み合わせて、
過去の投資を回収する新しいアプリケーションが構築可能です。
・ compositionality システムのプロパティはコンポーネントのプロパティとコンポーネント間の相互作用の関数であるというcomponents-based engineeringの
原理として定義され、新規または既存のコンポーネント、または既存システムの変更で構築された複雑なシステムが、安全性、セキュリティ、
障害耐性、信頼性、及びプライバシー保護面で信頼可能であることを保証する手段を提供します。
■ 相互運用性
最大の利益を得るには真の価値を生み出す場所を理解し、相互運用性を含む一連のシステムの問題にうまく対処することが必要で、相互運用性は、最大の価値を獲得する
ために非常に重要となります。
なお、平均して、IoTアプリケーション全体の潜在的な価値の40%、一部では60%に近い相互運用性が必要とされています。

NIST SP 800-183 Networks of ‘Things’
9
Figure 3 : Decision trigger
IoTにおけるセキュリティ課題に早期にアドレスした標準で、5. Reliability and Security Primitive Scenariosで構成要素について、次の課題を提示しています。
■ センサ
スマートビルディングの温度センサは簡単にアクセス可能で、そのシステムがファームウェアの完全性検証手段を提供していない場合、攻撃者がファームウェアをリモー
トコマンドに応答するように置き換えると、これらセンサはbotnetの一部となり、分散型サービス拒否（DDoS）攻撃につながります。
⇒ 物理的な改ざんやファームウェア変更の例。
■ アグリゲータ
攻撃者は偽の読み出しを行う不正なセンサをネットワークに導入した場合、バッファオーバーフロー攻撃によってミドルウェアインフラストラクチャ（ゲートウェイ）全
体へのルートアクセスの取得につながります。
⇒ インジェクション攻撃またはバッファオーバーフローの例。
■ 通信チャネル
wearable activity trackerは、人の手首に取り付けられ、心拍数と血圧を測定し、BLE［Bluetooth low
energy］を使用して着用者のスマートフォンと通信し、データを医師に転送します。
BLEがデバイスのMACアドレスをランダム化する機能を実装していない場合、高利得アンテナを備え
た攻撃者は、群衆の中の着用者の存在を追跡し、動線プロファイルを作成することが可能です。
⇒ 通信チャネルに対する盗聴の例。
■eUtility
スマートホームには、フロントドアに設置されたセキュリティカメラがあり、ドアでの動きが検出さ
れた後、通知及びビデオフッテージを住宅所有者のデバイスに転送対応するクラウドアプリケーショ
ンにデータを送信します。
攻撃者はアプリケーションプロバイダのサーバに対して2時間DDoS攻撃を行うことで、ユーザには
通知されずに家に侵入することができます。
⇒ DDoS攻撃の例。
■ 決定トリガ
悪意のある入力を受け入れる、またはトリガ出力が正当な所有者に知られていない競合他社に盗聴さ
れます。
⇒ データ改ざんとデータ完全性損失の例。

標準で明示された要件
10

NISTIR 8228 Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks
11
強制力を有する標準文書ではありませんが、NISTIR 8114 Report on lightweight cryptography同様、次世代の技術動向を予測する際の有益な情報で、ここで規定さ
れた内容は、NIST SP 800-53 Security and Privacy Controls for Information Systems and Organizations［Revision 5、draft］にフィードバックされる可能性が
あります。
備考：対象となるNIST SP 800-53自体もサプライチェーン関連で話題ですが、今回のdraftでは現行版［Revision 4］のタイトルから”Federal”が消えている点に留
意が必要です。
本報告書では、4 Challenges with Cybersecurity and Privacy Risk Mitigation for IoT Devicesで規定された次のリスク軽減策のゴールで、今後、IoT機器ではこれら
リスク軽減策に関連する要件が強化されることが予想されます。
■ デバイスセキュリティ［device security］の保護
他組織に対するDDoS攻撃への参加、ネットワークトラフィックの傍受、または同じネットワークセグメント上の他デバイスの危殆化等、デバイスが攻撃に使用されるこ
とを防ぐことで、全IoTデバイスに適用されます。
また、ここでは脆弱性管理が実現手段として規定されている点にも留意が必要です。
Vulnerability Management: Identify and eliminate known vulnerabilities in IoT device software and firmware in order to reduce the likelihood and ease of
exploitation and compromise.
■ データセキュリティ［data security］の保護
IoTデバイスによって収集、保存、処理、またはIoTデバイスから送信されたデータ（PII［注1］を含む）の機密性、完全性、及び / または可用性の保護で、保護が必要な
データがない場合を除き、全IoTデバイスに適用されます。
■ 個人のプライバシー［individuals’ privacy］の保護
デバイス及びデータのセキュリティ保護を通じて管理されるリスクを超えて、PII処理によって影響を受けるプライバシーの保護で、PIIを処理する、または個人に直接ま
たは間接的に影響を与える全てのIoTデバイスに適用されます。
注1： personally identifiable information［一般的な用語ではありません］で、USでは同定防止［動線分析防止］が重視されます。

NIST SP 800-193 Platform Firmware Resiliency Guidelines
12
2018年5月にリリースされた文書で、プラットフォームレベルでsystem resiliency及びcyber resiliencyをサポートするためのセキュリティガイドラインが規定されます。
・ system resiliency International Council of Systems Engineering［INCOSE］の定義では、『中断［disruption］前、中断中、及び中断後に中断の影響を吸収し、
許容可能なパフォーマンスレベルまで復旧し、許容可能な期間そのレベルを維持するための特定の特性を有するシステムの能力』
・ cyber resiliency サイバーリソースを含むシステムに対する悪条件、ストレス、攻撃、またはセキュリティの危殆化［compromise］を予測すると共に耐性を有し、
復旧及び適応する能力
具体的には、潜在的で破壊的な攻撃に対するプラットフォームのレジリエンシーをサポートするために、次の3原則に基づく技術ガイドラインが提供されています。
保護［protection］ファームウェア更新の真正性と完全性を保証する処理等、プラットフォームのファームウェアコードと重要データ［注1］が完全性の維持された
状態［state of integrity］にあり、破損から保護されることを保証するメカニズム
検出［detection］プラットフォームのファームウェアコードと重要データが破損した際に検知するメカニズム
復旧［recovery］ファームウェアコードまたは重要データの破損が検知された場合、もしくは認可されたメカニズムを利用して強制復旧する場合、プラッ
トフォームのファームウェアコードと重要データを完全性の維持された状態に復元するメカニズムで、対象は、ファームウェアコードと重
要データに限定されます。
なお、同標準の2.1 Platform Devicesで、TPMが『TPMは、暗号鍵とプラットフォーム状態の測定値を安全に格納し、使用可能とするセキュリティコプロセッサです。
これらの機能は、システムに格納されたデータの安全性維持、強力なデバイスIDの提供、及びシステム状態を証明するために使用可能です。全てのプラットフォームが
TPMを含むか、TPMを使用するシステムではありませんが、TPMが組み込まれて使用されるシステムでは、プラットフォームの信頼性を確保する上でのTPMの重要性を考
慮して、ファームウェアを保護する必要があります』と取り上げられたことで、各方面で注目を集めています。
注1 ：原文では’critical’で、通常のSP 800シリーズであれば『機密』と訳しますが、コンフィギュレーション関連のデータが含まれるため『重要』としています。

実装時に留意すべき課題
13

信頼境界と暗号境界
14
システム
■ 信頼境界［trust boundary］ ← Microsoft等も使用する一般的な技術用語
信頼可能なアセット［データ及びサブシステム（NIST SP 800-193では重要データとファームウェア）］から構成される領域の境界で、信頼防御を行う境界となります。
なお、この場合の『信頼』とは『完全性が維持された状態』に相当します。
インジェクション攻撃等のセキュリティ問題の大半は、信頼境界線を越えて入出力される情報に起因し、その際にはアセットにアクセスするパス［インタフェース及び
API］が攻撃対象になることから、それらのパスはattack surfaceと呼ばれます。
なお、ITセキュリティ製品では危険を回避するためにattack surfaceを最小化すること［attack surface reduction］が必要となります。
■ 暗号境界［cryptographic boundary］ ← FIPS PUB 140で規定された技術用語
暗号モジュールとして定義される機能を含む領域で、信頼境界線を越えて入出力される情報の機密性と完全性を暗号技術を応用することで保護することが目的です。
通常グレードのデバイスで構成される信頼境界とは異なり、様々な攻撃から暗号境界内部のsensitive security parameter［SSP］を保護することが要求されます。
暗号を実装する場合、アルゴリズム自体に脆弱性が存在しなくても、実装起因の脆弱性に留意することが必要で、暗号境界の物理的な安全性を確保することが極めて重要
で、攻撃の再現性［reproducibility］が容易なサイドチャネル攻撃［side channel attack］耐性には特に留意が必要です。
なお、暗号境界実装時に必要とされるsecure codingは、機能安全［注1］と親和性が良くない技術であるため、別デバイスであるTPMまたはSE［security element］として実装
することは有効な解決策となります。
信頼境界線
信頼境界
暗号境界
Sensitive Security Parameter
アセット
I/OまたはAPI
attack surface
sensitive security parameter［SSP］
セキュリティに関連する情報で、次の2種類の情報から構成されます。
1］critical security parameter［CSP］
漏洩 / 変更がセキュリティ喪失につながる秘密情報
2］public security parameter［PSP］
変更がセキュリティに影響を与え得るセキュリティ関連の公開情報
注1：自動車向け機能安全規格であるISO 26262 Road vehicles – Functional safety等。

FIPS PUB 140-3 Security requirements for cryptographic modules
15
2019年3月にリリースされた標準で、ISO/IEC 19790:2012/Cor. 1 Information technology - Security techniques - Security requirements for cryptographic
modulesを参照する形態となっています。
本標準の対象は、承認されたセキュリティ機能または鍵の確立メカニズムを有するモジュールが対象で、本標準における『セキュリティ機能』とは、暗号利用モードを含
む暗号アルゴリズム、ハッシュ関数、及び乱数生成方式等で、その内部では露呈時にシステムとしてのセキュリティ喪失をもたらすCSP［critical security parameters］、及び変
更時にシステムとしてのセキュリティ喪失をもたらす公開鍵等のPSP［public security parameters］から構成されるSSP［sensitive security parameter］が利用されます。
なお、『承認されたセキュリティ機能』とは、技術的にはNIST SP 800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic
Algorithms and Key Lengthで規定されたセキュリティ強度112 bit以上の暗号アルゴリズムに相当しますが、近年のトレンドから判断すると、実装時にはセキュリティ
強度128 bitのアルゴリズムを選定することが妥当と判断されます。
本標準では、モジュールに必要な次の11技術領域に対して最大4レベル［最高がLevel 4］のセキュリティ要件を規定しており、最も評価が低い領域のレベルがモジュール
全体としてのセキュリティレベルとなります。
・暗号モジュール仕様［cryptographic module specification］
・暗号モジュールI/F［cryptographic module interfaces］
・役割［role］、サービス［services］、及び認証［authentication］ ⇒ 2019年3月1日に発行された総務省令第12号の技術的背景
・ソフトウェア / ファームウェアセキュリティ［software/firmware security］ ⇒ NIST SP 800-193の保護及び検出実装時には有用
・動作環境［operating environment］
・物理的セキュリティ［physical security］
・非侵入脅威に対するセキュリティ［non-invasive security］
・SSP［sensitive security parameter］管理
・セルフテスト［self-test］
・ライフサイクル保証［life-cycle assurance］
・他の攻撃の軽減策［mitigation of other attacks］
旧版［2019年9月22日までは最新版］であるFIPS 140-2ではソフトウェア実装でもLevel 4が取得可能と規定されていましたが、本標準では明確に上限がLevel 2に制約
されます。

暗号アルゴリズムのセキュリティ強度
16
■公開鍵暗号：以下の名称は安全性に関する数学的な根拠がベースです
・FFC［finite field cryptography］ Lは公開鍵長でNは秘密鍵長
・IFC［integer factorization cryptography］ kは法ｎ長［3k bit以上の鍵生成はセキュアMCUのパフォーマンスでは非現実的］
・ECC［elliptic curve cryptography］ fはベースポイントGの位数［乱数を秘密鍵dとし、[d]Gを公開鍵とします］
■ハッシュ：電子署名及びハッシュ単体利用とその他用途［HMAC、鍵多様化、DRBG］でセキュリティ強度が異なります。
・SHA-2 SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、 SHA-512/256が規定されています。
なお、SHA-512/224、SHA-512/256は、他アルゴリズムとの親和性を確保するために出力長を縮約したアルゴリズムです。
・SHA-3 秘密鍵暗号の考え方を応用したハッシュ関数ですが、現時点でもSHA-2の脆弱性が報告されていないため、一般的には利用されていません。
Security Strength
< 112
Applying
Processing
Disallowed
Legacy use
Acceptable
Disallowed
Legacy use
112
in bits
Through
2030
2031 and
beyond
128
Applying
Processing
Applying / Processing Acceptable Acceptable
192 Applying / Processing Acceptable Acceptable
256 Applying / Processing Acceptable Acceptable
共通鍵暗号
FFC IFC［RSA］ ECC 電子署名等 HMAC等
公開鍵暗号［鍵共有を含む］
2TDEA
3TDEA
L = 1,024
N = 160
L = 2,048
N = 224
L = 3,072
N = 256
L = 7,680
N = 384
対応NIST標準無し
L = 15,360
N = 512
k = 1,024
k = 3,072
k = 7,680
k = 15,360
160 ≦ f ≦ 223
384 ≦ f ≦ 511
512 ≦ f
ハッシュ
N / A
SHA-224
SHA-512/224
SHA3-224
SHA-384
SHA3-384
TPM 2.0
SHA-512
SHA3-512
TPM 2.0
SHA-224
SHA-512/224
SHA3-224
SHA-256
SHA-512/256
SHA3-256
ApprovedAllowedNISTでの扱い
太罫線はTPM 2.0でサポート
AES-256
TPM 2.0
AES-192
TPM 2.0
AES-128
TPM 2.0
256 ≦ f ≦ 383
TPM 2.0
224 ≦ f ≦ 255
TPM 2.0
SHA-1
TPM 1.2、2.0
k = 2,048
TPM 1.2、2.0
SHA-256
SHA-512/256
SHA3-256
SHA-1
TPM 1.2、2.0
暗号アルゴリズムのセキュリティ強度はNIST SP 800-57 Part 1 Recommendation for Key Management, Part 1 General ［注1］で下表のように規定されており、
112 bit未満のアルゴリズムを利用してUS官公庁向けシステムを新規開発することをNISTでは既に禁止しています。
注1： 2010年問題の契機となった標準で、現在はNIST SP 800-131A NIST_SP 800-131A Transitions : Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Length を推奨します。

考慮すべき最近の攻撃方法［1］
17
数多く存在しますので、以下に代表的な脅威だけを記載します。
■Spectre
2017年に発表されたハイパフォーマンスCPUで採用されている投機的実行［speculative execution］と、その背景となる分岐予測［branch prediction］を利用
した攻撃で、以降も亜種が多く発表され、今年もサイドチャネル攻撃と組み合わされた新手法が公開されており、未だに根本的に解決される見通しは
ありません。
・CVE-2017-5753、Variant 1［注1］： bounds check bypass［http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753］
・CVE-2017-5715、Variant 2 ： branch target injection［http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715］
・CVE-2017-5754、Variant 3 ： meltdown［http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754］
・CVE-2018-3640、Variant 3a ： rogue system register read［http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3640］
・CVE-2018-3639、Variant 4 ： speculative store bypass［http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639］
■RAMBleed攻撃
2019年に公表されたRAMBleedは、2010年代中盤に話題となったDRAMの完全性に対する攻撃であるRowhammer攻撃［最初の論文は2014年］を機
密性侵害に応用した攻撃で、本質的な脆弱性はプロセス進化に伴って逆の電荷を有する隣接したコンデンサが寄生電流を誘導する現象に起因していま
す。
この攻撃で注目すべき点は、筆者の多くが現在も亜種が多数報告されているSpectre攻撃の研究者であり、今回もハードウェアとソフトウェアに内在
する潜在的な脆弱性を組み合わせた内容で、MITIGATIONSで規定されるように確実に効果を発揮する対策が現時点では存在しない点にあります。
攻撃の詳細は、発見者のHP［https://rambleed.com/］から取得可能で、既にRAMBleedに含まれるメモリマッサージ技術が次の脆弱性として登録されてい
ます。
・CVE-2019-0174
注1： CVE［common vulnerabilities and exposures］はMITRE社が管理する脆弱性情報データベース。

考慮すべき最近の攻撃方法［2］
18
■ToRPEDO
2019年2月に発表された4G / 5Gに対する動線分析攻撃で、サイドチャネル情報を応用。
SOURCE： http://homepage.divms.uiowa.edu/~comarhaider/publications/LTE-torpedo-NDSS19.pdf
■Modチップ
2018年10月にBloombergが報じた米中貿易摩擦のトリガの一つでもあるModチップ［注1］疑惑で、Two Sigma InvestmentsのSVP［senior vice-president］であるTrammel
Hudson氏が自身の経験と知識をベースに実現性について精査した次の資料が参考になります。
Trammel Hudson’s Project
SOURCE： https://trmm.net/Modchips
ハードウェアを対象とした脅威で、同氏の予想ではBMCファームウェア転送時に0603［インチ表示なので、JIS表記なら1608］になりすましたModチップでファーム
ウェアを改ざんするとしています
注1：ゲーム機等で開発元が想定していない機能を追加するためのチップで、MODはMODIFICATION、MODIFYの頭文字。

BSI-CC-PP-0084-2014 Security IC Platform Protection Profile with Augmentation Packages
19
前述した脅威に対応したデバイスとしては決済カード等で使用されているSecure MCUが知られており、本セキュリティ要件では極めて厳密な機能及び保証要件が要求さ
れ、結果的に現在までに同PPに準拠した製品が破られたという事例は報告されていません。［注1］
ただし、これらデバイスではattack surface reductionの原則が採用されているため、メモリリソース及びI/O数等の制約が大きく、その用途は限定されます。
O.Malfunction
O.Phys-Probing
Basic internal transfer protection
消費電力、電磁波、音等の漏洩情報を測定してデータや
動作を特定
O.Leak-Inherent
TOE Security Functional and Assurance RequirementsObjective
バスをマイクロプロービングし、データを盗聴
O.Phys-Manipulation
定格を超えた温度、電圧、クロック、電磁波等を与え、
誤動作を引き起こして不正を図る
物理的なメモリへのアクセス、または回路改ざんによる
情報漏洩を図る
O.Leak-Forced 暗号関連回路等を攪乱し、誤動作による情報漏洩を図る
O.Abuse-Func 製品機能の悪用［例えばテスト機能の悪用］
O.Identification
乱数生成器を攪乱し、低品質の乱数を出させてセッショ
ン鍵等の品質を悪化させる
O.Authentication 偽物を本物としてすりかえる［T.Masquerade_TOE］
FDP_ITT.1
FPT_ITT.1 Basic internal TSF data transfer protection
FDP_IFC.1 Subset information flow control
Authentication proof of identity
Stored data integrity monitoring and action
FDP：user data protection
FDP_SDC.1 Stored data confidentiality
FPT_PHP.3 Resistance to physical attack
FPT：protection of TSF Data
FRU_FLT.2 Limited fault tolerance
FPT_FLS.1 Failure with preservation of secure state
FRU：resource utilisation
FDP_SDI.2
FPT_PHP.3 Resistance to physical attack
O.Leak-Inherent全要件
FMT_LIM.1 Limited capabilities
3及び4関連の次要件
想定脅威
FRU_FLT.2 FPT_FLS.1 FPT_PHP.3
FMT_LIM.2 Limited availability
1
ID
2
3
4
5
FDP_ITT.1 FPT_ITT.1 FDP_IFC.1 FPT_PHP.3 FRU_FLT.2
FPT_FLS.1
これらはattack surface reduction適合
6
O.RND
脅威ではなくセキュリティポリシー依存 FAU_SAS.1 Audit storage7
8
FCS_RNG.1
1～5関連の次要件
FDP_ITT.1 FPT_ITT.1 FDP_IFC.1 FPT_PHP.3 FRU_FLT.2
FPT_FLS.1
Quality metric for random numbers
FIA：identification and authenticationFIA_API.19
FAU：security audit
FCS：cryptographic support
FMT：security management
備考
1～5関連の次要件
注1： SCP02の仕様で採用された認証付き暗号方式であるE&M［Encrypt-and-MAC］の脆弱性を利用したPadding Oracle Attack等は除外します。
Non-invasive security対策
invasive security及びDFA
［differential fault analysis］対策
Mod chip対策

Secure MCU実装例［弊社製品例］
20
TPMあるいはSEで利用されるSecure MCUは、物理的な安全性を確保するために下図に示すソフトウェア、ハードウェア及びファームウェアを実装したデバイスです。
FIPS PUB 140-3ではHARDWAREモジュールに相当し、更に製品への組み込み時の負荷的要件が最も少ない実装形態であるシングルチップモジュールとして実装されて
います。
TPMは、基本的なIP問題が担保され、更に第三者機関で評価されたTamper resistant deviceに相当します。
AES Accelerator
Keys
in FLASH
Secure MCU
HARDWAREFIREWALL
RSA / ECC Accelerator
(ie. Montgomery Engine)
Unauthorizedaccess
［Key/ObjectCode］
CryptoAPI
Key Handler
API
DPA / DEMA PROTECTION
DFA PROTECTION
invasive & non-invasive attack
TRNG
［entropy source］
SHA
［SHA-1,SHA-256,SHA-3］
Self-Tests［EFP（Environmental Failure Protection）を含む］
■ 記載方法
ファームウェア
ハードウェア
CONDITIONALACCESS
DRBG
［Hash / CTR_DRBG］
DES Accelerator
CRYPTO-1［custom］
Code Signature /
Security step counter
上記混成Illegal Environment
SM2, 3, 4［custom］

実装時のヒント
21
一般的に、セキュリティ対策立案時には先ず脅威モデリングを行い、その結果に応じて下表記載のコスト順に方策を決定します。
⇒ 前出のFIPS PUB 140-3でも規定されているように、要求されるセキュリティレベルは『使用される環境』と『取り扱う情報の価値』に依存します。
IoT / CPSの対象は広汎で一概に要件を規定することは困難ですし、お客様によってもリスクの捉え方は異なります。
⇒ セキュリティセンシティブなお客様では風評被害等の無形な逸失利益までを考慮されるために『技術的な救済』が採用される機会は多いのですが、その比率は国内で
はまだ低いと思われます。
また、次の原則についてもお客様に依存することが多いかと思います。
・セキュリティとパフォーマンスは背反する
・セキュリティとテスタビリティは背反する
ただし、前出のNIST SP 800-183及びNISTIR 8228で規定された同定防止を含むプライバシー保護については、今後注目を集める可能性が高いと弊社では予測していま
す。
何もしない
製品から機能を排除する
備考Level
機能をオフにする
ユーザに対して警告を出力する
1
HPのMFPで多用されている対策で、デフォルトでは全機能利用可能とし、セキュリティ・センシティブなユーザ
向けに機能の排除 / 停止オプションを提供しています
対策コスト >> リスクである場合に採用します
2
3
4
技術的な対策による救済5
対策

パネルディスカッション_株式会社アーティファクト

Recomendados

Recomendados

Más contenido relacionado

Similar a パネルディスカッション_株式会社アーティファクト

Similar a パネルディスカッション_株式会社アーティファクト (20)

Más de Trainocate Japan, Ltd.

Más de Trainocate Japan, Ltd. (20)

Último

Último (7)

パネルディスカッション_株式会社アーティファクト