5GMF 白書
5G ユースケースにおけるセキュリティ
第 1.1 版
2024 年 3 月 11 日

注意事項
1.

本文書の著作権は、第5世代モバイル推進フォーラム(5GMF)が所有します。

2.

本文書のいかなる部分も、5GMFの事前の承諾なしで、いかなる形・方法によっても、出版、翻訳、他のウェブサイトへの転載等を行うことはできません。

目次
1.

はじめに（報告概要） ......................................................................................................... 1

2.

セキュリティ調査研究委員会活動の目的 ............................................................................ 1

3.

用語....................................................................................................................................... 2

4.

5Gセキュリティの標準化動向 ............................................................................................. 4
4.1. はじめに ............................................................................................................................... 4
4.2. 5Gの標準化と導入スケジュール.......................................................................................... 4
4.3. NSAのセキュリティ ............................................................................................................ 6
4.4. 5G phase 1のセキュリティ.................................................................................................. 7
4.4.1.

トラストモデルの変化 ................................................................................................. 7

4.4.2.

鍵階層........................................................................................................................... 8

4.4.3.

プライバシー保護の強化 ........................................................................................... 10

4.4.4.

Primary / Secondary Authentication....................................................................... 10

4.4.5.

On-demandセキュリティ .......................................................................................... 10

4.4.6.

Security Assurance ................................................................................................... 10

4.5. Release 16以降のセキュリティ強化.................................................................................. 11
4.6. 他団体における5Gセキュリティ検討 ................................................................................ 114.7. 5Gセキュリティ標準化動向まとめ .................................................................................... 135.

5Gセキュリティの検討 ...................................................................................................... 14
5.1. ユースケース IoTセキュリティ......................................................................................... 14
用語 ............................................................................................................................ 14
IoTセキュリティ関連文書概説 .................................................................................. 14
課題の抽出 ................................................................................................................. 17
5Gにおける新規セキュリティ機能まとめ................................................................. 20
5Gセキュリティ機能による課題への対応可能性 ...................................................... 21
5.1.6.

IoT課題に対する具体的対策案検討結果 ................................................................... 24

5.1.7.

3GPPにおける関連作業項目概要 .............................................................................. 36

5.1.8.

5GMF白書「5Gユースケースにおけるセキュリティ 第1.1版」における課題解決
可能性......................................................................................................................... 37
3GPPリリース18関連動向......................................................................................... 42

5.1.10. 3GPPリリース19関連動向......................................................................................... 46
5.1.11. ユースケース IoTセキュリティまとめ ..................................................................... 49i5.2. ユースケース Connected Vehicle セキュリティ ............................................................. 51
5.2.1. 概要 ................................................................................................................................ 51
5.2.2. Connected Vehicle セキュリティに関連する標準 ........................................................ 52
5.2.3. Connected Vehicleにおけるセキュリティ..................................................................... 85
5.2.3.1. Connected Vehicleにおけるセキュリティ要件......................................................... 85
5.2.3.2. トラストモデル........................................................................................................... 97
5.2.3.3. ネットワークスライシング ........................................................................................ 98
5.2.3.4. MEC ......................................................................................................................... 104
5.2.3.5. C-V2X ...................................................................................................................... 114
5.2.3.6. 認証機能.................................................................................................................... 123
5.2.4. むすび .......................................................................................................................... 125
5.3. ユースケース Fintechセキュリティ ................................................................................. 126
5.3.1. はじめに....................................................................................................................... 126
5.3.2. 5GにおけるFintechサービス ....................................................................................... 126
5.3.3. Fintech企業及び関連団体との連携 ............................................................................. 128
5.3.4. 5Gにおける金融サービスとセキュリティ検討ポイント ............................................. 131
5.3.5. サービス事業者間認証における課題と運用者要考慮事項 .......................................... 132
5.3.6. リアルタイム認証におけるセキュリティ課題と運用者要考慮事項............................ 137
5.3.9. 追加調査・検証によるFintechセキュリティのまとめ ............................................... 142
6.

参照文献 ........................................................................................................................... 144
6.1. ユースケース IoTセキュリティ....................................................................................... 144
6.2. ユースケース Connected Vehicle セキュリティ ........................................................... 146
6.3

ユースケース Fintechセキュリティ.............................................................................. 150

7.

まとめ ............................................................................................................................... 151

Annex

IoT課題まとめ ................................................................................................................. 152

改定履歴 ......................................................................................................................................... 168ii

1. はじめに（報告概要）
2019 年度、5G セキュリティの検討要求が各方面から多かったため、5GMF において、「セキュリティ AdHoc」を「セキュリティ調査研究委員会」に昇格させ、本格的に検討を開始した。
本白書は、セキュリティ調査研究委員会において検討した内容をまとめたものである。
2020 年 7 月に 5GMF 白書「5G ユースケースにおけるセキュリティ 第 1.0 版」を公開した。
第 1.0 版の公開後、各検討項目（標準化、IoT、Connected Vehicle、Fintech）における調査活動の結果を第 1.1 版として反映した。

2. セキュリティ調査研究委員会活動の目的
2019 年 7 月の総会にて承認され、「セキュリティ調査研究委員会」が設置された。
設置目的は、5G 時代のサービスのセキュリティに関する検討組織の立ち上げに向けて、国内外の「5G セキュリティ」に関する調査検討、情報の共有や発信、推進団体との連携等を図ることとした。
主に参加委員の意見などから、全体に共通の 5G セキュリティ標準化動向を踏まえて、①
IoT、②Connected Vehicle、③Fintech を検討項目とし、関連したセキュリティ検討項目を抽出することを目的とした。
参加メンバーは、募集等の準備を経て 2019 年 9 月に 21 名にて本格的な活動を開始した。
以下のユースケースにおけるセキュリティ課題の抽出を実施した。
–

計算リソースに制限のある IoT デバイス、多量の IoT デバイス（認証技術等）–

Connected Vehicle（自動運転、運転支援）–

Fintech 関連サービス（モバイルコマース関連）

13. 用語
3GPP: Third Generation Partnership Project
5GAA: 5G Automotive Association
ACEA: European Automobile Manufacturers' Association
AECC: Automotive Edge Computing Consortium
AF: Application Function
AMF: Access and Mobility management Function
AUSF: Authentication Server Function
CN: Core Network
CR: Compliance Rules
CRL: Certificate Revocation List
C-V2X: Cellular V2X
DDoS: Distributed Denial of Services
DoS: Denial of Services
DRM: Digital Rights Management
DSRC: Dedicated Short Range Communications
ECU: Electronic Control Unit
ENISA: The European Union Agency for Cybersecurity
eSIM: embedded Subscriber Identification Module
ETSI: European Telecommunications Standards Institute
EVITA: E-safety vehicle intrusion protected applications
GSMA: GSM Association
GUTI：Global Unique Temporary Identifier
HDCP: High-bandwidth Digital Content Protection
HDMI: High-Definition Multimedia Interface
HIS: The Hersteller Initiative Software
IMSI: International Mobile Subscriber Identity
IRN: Infrastructure/Roadside Network
ITS-S: ITS Station
ITS-SCU: ITS Station Communication Unit
ITS-SU: ITS Station Unit
IVN: In-Vehicle Network
LDP: Local Dynamic Map
MEC: Mobile Edge Computing/Multi-access Edge computing
NAS: Non-Access Stratum

2

NESAS: Network Equipment Security Assurance Scheme
NEF: Network Exposure Function
NF: Network Function
NRF: Network Repository Function
NS: Network SliceNSSAI: Network Slice Selection Assistance Information
NSSF: Network Slice Selection Function
OBU: Onboard Unit
OTA: Over the Air
PKI: Public Key Infrastructure
PVS: Prove Vehicle Systems
QoS: Quality of Service
RAN: Radio Access Network
RR: Robustness Rules
RSU: Road Side Unit
SAE International: Society of Automotive Engineers
SBA: Service Based Architecture
SCAS：Security Assurance Specifications
SCN: Sensor and Control Network
SMF: Session Management Function
SUCI: Subscription Concealed Identifier
TCG: Trusted Computing Group
TEE: Trusted Execution Environment
TFCS: Task Force on Cyber Security
TLS: Transport Layer Security
UE: User Equipment
UNECE: United Nations Economic Commission for Europe
UPF: User Plane Function
URLLC: Ultra-Reliable and Low Latency Communications
V2D: Vehicle-to-nomadic Devices
V2I: Vehicle-to-Infrastructure
V2N: Vehicle-to-Network
V2P: Vehicle-to-Pedestrian
V2V: Vehicle-to-Vehicle
V2X: Vehicle-to-Everything34. 5G セキュリティの標準化動向
4.1. はじめに本章では、3GPP においてセキュリティとプライバシー関連の標準化の議論を担当している
SA3 ワーキンググループでの活動を中心に、5G セキュリティに関する標準化動向を概観する。
まず、5G の標準化と導入スケジュールについて述べた後、3GPP Release 15 で規定され、5G 導
入初期に用いられるノンスタンドアローン（NSA）構成の 5G におけるセキュリティ、スタンド
アローン（SA）構成における LTE とのセキュリティの違い、Release 16 以降のセキュリティ関連仕様のアップデート状況について説明する。
4.2. 5G の標準化と導入スケジュール
モバイル通信システムの国際標準（IMT：International Mobile Telecommunications）を扱う
ITU（国際電気通信連合）と 3GPP（3rd Generation Partnership Project）で標準化活動が進められてきた 5G では、超高速（eMBB：Enhanced Mobile Broadband）、超低遅延（URLLC：Ultra
Reliable and Low Latency Communication））、多数同時接続（mMTC：massive Machine Type
Communications）サービスが実現される。

図 4.1

IMT-2020 のビジョン勧告で規定する 5G ユースケース

4G から 5G への移行については、2020 年に 5G 用の新しい周波数帯を用いた eMBB サービスの提供が始まっているが、これは、新たな無線技術（NR: New Radio)に対応した基地局が、LTE基地局と連携する NSA（Non-Standalone）構成での 5G の導入であった。2021 年から 2023 年にかけては、国内主要キャリアがネットワークスライシング等に対応した 5G コアネットワークを導入し、SA（Standalone)構成の NR 基地局の運用が開始され、既存周波数帯域への NR 導入が進展している。これにより 5G の目指す超高速、多数同時接続、高信頼・低遅延などの要求条
4

件に対応した 5G サービスの実現が進んでいる。

図 4.2

総務省資料（4G から 5G 移行説明部分）

3GPP SA3 における 5G セキュリティの標準化活動のこれまでの経緯と計画を以下に示す。
2017 年 6 月（Release 14）

5G において考慮すべき 17 のセキュリティ領域を定めて課題と対策を整理



その後の検討のためのメモ的な位置づけであり標準ではない

2019 年 6 月（Release 15）

5G security study

5G phase 1 security

トラストモデル、鍵階層、事業者間セキュリティ、プライバシー保護等



メインのユースケースは eMBB

2020 年 6 月（Release 16）

5G phase 2 security

5G phase 2 でサポートされる Cellular IoT、URLLC、Non-Public Networks 等のユースケース関連するセキュリティ仕様の規定・強化

フルレートの U-Plane 改ざん検知



無線バックホールのセキュリティ

2022 年 3 月（Release 17）

5G の更なる進化Proximity based Service や産業 IoT のセキュリティ等のユースケースに関連する
セキュリティ仕様の規定・強化



U-Plane 改ざん検知の LTE へのバックポート
52024 年 Q1（Release 18）

5G-Advanced システムの最初のリリース


5G コアネットワークを含め、より一層のセキュリティ強化を推進

5G の無線方式である「5G NR（New Radio）」の標準仕様が「3GPP Release 15」であり、Release 15 では、コアネットワークや基地局など無線ネットワークを構成する機器すべてに 5G専用のものを使用して構成する SA の仕様が策定されている。5G NR のうち、LTE と NR の組
み合わせで運用するケースの基本仕様（現行の LTE との連携部分）を規定する NSA は、2017
年 12 月に標準策定が完了しており、2020 年頃からの 5G のサービス導入初期においては、このNSA の構成が用いられている。Release 16 で規定される 5G phase 2 は mMTC や URLLC をカバーする完全な 5G 仕様であり、3GPP SA3 においては、5G コアの各ネットワーク機能のSCAS（Security Assurance Specification）、ネットワークスライスのセキュリティ、mMTC、
URLLC をカバーするセキュリティ強化、バーティカルや LAN サービスのセキュリティ等についての仕様が規定されるとともに、Release 15 では 64kbps を超える通信レートでは必須としていなかった U-Plane の改ざん検知をフルレートで必須とする修正が行われている。Release 17
では、U-Plane の改ざん検知が LTE にバックポートされ、LTE サービスや、NSA 5G サービス
でも U-Plane の改ざん検知がサポートされるようになっている。また、Proximity Service や産業 IoT などのユースケースにおけるセキュリティ仕様の規定や強化が行われている。以下では、
まず、Release 15 で規定された内容を中心に基本的な 5G のセキュリティ仕様について説明する。
4.3. NSA のセキュリティ
NSA は、LTE（4G）のネットワークコア（EPC: Evolved Packet Core）を利用して 5G の導入を進めるためのアーキテクチャであり、以下の図 4.3 に示す通り、端末と基地局部分のみが 5G 化され、5G 無線を利用した高速大容量通信が可能となる。

6

図 4.3 ノンスタンドアローン構成の 5G
NSA は、LTE の高速大容量化のために複数基地局間での LTE キャリアの同時通信を行う仕様として TS 33.401 の Annex E で定められている Dual Connectivity を 5G に拡張し、LTE 基地局
をマスタ、5G 基地局をセカンダリとして利用可能にすることで実現されている。セキュリティの
手順は LTE の Dual Connectivity をほぼ流用しており、NSA においては、セキュリティに関して LTE との大きな違いはなく、次節以降で述べる通り、SA への移行により 5G のセキュリティ
は LTE よりも強化されることになる。しかしながら、ネットワークコアが 5G 化した後も、LTE
基地局をマスタ、5G 基地局をセカンダリとして利用する、もしくは、5G 基地局をマスタ、LTE
基地局をセカンダリとして利用する形で 5G と LTE の併存が続くと想定されているため、各ユー
スケースにおけるセキュリティ検討においては、5G エリア外への移動や LTE 接続へのダウング
レード攻撃などの可能性を考慮する必要があると考えられる。なお、Release 17 において U-Planeの改ざん検知が LTE にバックポートされたことにより、LTE サービスや NSA 5G のセキュリテ
ィも強化が図られている。
4.4. 5G phase 1 のセキュリティ
4.4.1.

トラストモデルの変化

5G においては、コアから遠ざかるに従いトラストが低下するとみなす考えに基づいてセキュリティが設計されている。このため、例えば RAN においては基地局が Distributed Units (DU)とCentral Units (CU)に分離され、物理的に安全性の低い場所に配備される DU には鍵を保持させず、U-Plane のセキュリティは CU で終端される。また、図 4.4 に示す通り、事業者間でのロー
ミングにおいては、ローミング先(vPLMN)での認証結果をホームネットワーク(hPLMN)における認証処理を担う AUSF（AUthentication Server Function）が検証することで Home Control の強化を図る。また、図 4.5 に示す通り、事業者間の C-Plane の通信を保護するためにローミング
先(vPLMN)とホームネットワーク(hPLMN)との接続点において Security Edge Protection Proxy
7

(SEPP)の導入などが行われている。

図 4.4 5G の認証手順と Home Control

図 4.5 ローミング時のアーキテクチャ
4.4.2.

鍵階層

LTE と同様に、5G においても USIM とコアネットワークに保持された長期秘密鍵（K）がセキュリティの基点となる。5G では、モバイルネットワークサービスにアクセスするためにすべてのデバイスが実行する Primary Authentication と、外部データネットワーク（DN）が要求する場 合 に 行 わ れ る DN と の Secondary Authentication の 2 種 類 の 認 証 が あ る 。 UE (User
Equipment)とネットワークとの間の Primary Authentication が成功した後、サービングネット
ワーク固有のアンカー鍵（K SEAF）が K から導出される。アンカー鍵から、CK (Cipher Key) とIK (Integrity Key) が導出される。K から始まる鍵の階層を図 4.6 に示す。

8

図 4.6 鍵の階層（Key hierarchy）
鍵の階層には K、CK、IK、K AUSF、K SEAF、K AMF、K NASint、K NASenc、K N3IWF、K gNB、 K RRCint、
K RRCenc、K UPint、KUPenc が含まれる1。
-

K AUSF は、5G AKA を通じて、CK および IK から端末と ARPF 各々で導出される。

-

EAP をサポートする無線アクセス技術を介した認証に 3GPP クレデンシャル K が使用される場合、K AUSF は、EAP AKA '仕様に従って ME および AUSF によって導出される。

-

K AUSF から、AUSF および ME はアンカー鍵 K SEAF を導出し、K SEAF は ME および SEAFによって K AMF を導出するために使用される。

-

K ' AMF は、UE が、ある AMF から別の AMF に移動するとき、以前の K AMF から ME お
よび AMF によって導き出すことができる鍵である。

-

K NASint と K NASenc は NAS シグナリング保護のために、K AMF から ME および AMF によって導出される。

-

K gNB は、K AMF から ME および AMF によって導出される。K gNB は、移動の際に、中間
キーK gNB * を使用して、ME および移動元 gNB によって導出される場合もある。

AUSF: Authentication Server Function, SEAF: Security Anchor Function, AMF: Access
Management Function, NAS: Non-Access Stratum, gNB: Next generation NodeB, RRC:
Radio Resource Control, UP: User Plane

1

9

-

AS の完全性および機密性キー、すなわち UP（K UPint および K UPenc）および RRC（K RRCint
および K RRCenc）は、K gNB から ME および gNB によって導出される。UP の完全性保護
は、IoT（Internet of Things）サービスのために拡張である。中間鍵 NH は、ハンドオー
バ中における forward secrecy を担保するために、ME および AMF によって導出される。

4.4.3. プライバシー保護の強化
4G までのネットワークにおいては加入者 ID（IMSI）の保護が不十分であり、IMSI キャッチャー等を用いた加入者の追跡等が可能であった。5G では加入者 ID の保護を強化するため、ホーム
ネットワークの公開鍵を用いた加入者 ID の暗号化が行われる。
5G における加入者 ID は Subscription Permanent Identifier (SUPI)と称し、Mobile Country
Code (MCC)、Mobile Network Code (MNC)、Mobile Subscriber Identification Number (MSIN)から構成される。端末は、緊急通報等の場合を除いて、必ずホームネットワークの公開鍵を用いて MSIN 部分を暗号化した Subscription Concealed Identifier (SUCI) を用いてネットワークに接続する。SUCI はホームネットワークの ARPF において SUPI に戻されて以降の認証手順が進められる。
4.4.4. Primary / Secondary Authentication
先に述べた通り、5G では、モバイルネットワークサービスにアクセスするためにすべてのデバイスが実行する Primary Authentication と、外部データネットワーク（DN）が要求する場合に行われる DN との Secondary Authentication の 2 種類の認証がある。Primary Authentication は
アクセスネットワーク非依存であり、Wi-Fi 等の非 3GPP アクセスネットワークを介した接続にも利用される。認証と鍵導出には 5G-AKA もしくは EAP-AKA’が用いられる。Home Control 強化のため、ローミング先ネットワークでの認証結果をホームネットワーク側で検証する手順が組み込まれている。
Secondary Authentication は外部データネットワーク（DN）が要求した場合に行われる認証で、EAP を利用して行われる。SMF が EAP の Authenticator として振る舞い、外部の認証サーバ（DN－AAA）を利用して端末を認証する。前提として、端末は Primary Authentication により
AMF とのセキュリティコンテキストを確立している必要がある。
4.4.5. On-demand セキュリティ
5G は様々な分野やサービスで利用されるため、デバイスやアプリケーションなどによって異なる
セキュリティ要件や、制約を持っている場合が想定される。このため、U-Plane の暗号化や改ざん検知の有無、暗号強度などが選択可能であり、gNB（基地局）は AMF 経由で SMF から入手したセキュリティポリシと gNB と UE 双方の capability に基づいてアルゴリズムを選定し UE に通知する。
4.4.6.

Security Assurance

5G セキュリティの確保には、セキュリティ仕様の規定だけでなく、ネットワーク機器が仕様に従ってセキュリティ機能を正しく実装していることが必要である。ネットワーク機器のセキュリテ
ィ的な安全性をチェックするための仕組みを確立するための取り組みとして、3GPP と GSMA が連携する Network Equipment Security Assurance Scheme (NESAS) の確立が進められており、
10

3GPP では、NESAS で用いる Security Assurance Specification (SCAS) の策定を担当している。

図 4.7 Network Equipment Security Assurance Scheme Overview – GSMA

4.5. Release 16 以降のセキュリティ強化
5G セキュリティの基本的な仕様は Release 15 で規定されており、Release 16 以降では、Cellular
IoT、URLLC、Non-Public Networks 等のユースケースに関連する認証や認可などのセキュリテ
ィ仕様の追加や強化が行われている。一例として Release 17 では 5G NR による近接端末同士の直接通信やリレー通信を可能とする Proximity based Services (ProSe)に関するセキュリティ仕様が規定されており、セキュリティとプライバシーを保護しながら端末同士の発見や通信を行うことが可能になっている。Release 15 で導入された U-Plane 改ざん検知については、Release 16
でフルレート化され、Release 17 で LTE にバックポートされている。
5G-Advanced システムの最初のリリースとなる Release 18 では、Security Enablers for Verticals、Security Enhancement in 5G Core Network、Security Assurance、Security Function Evolution、
ecurity Enhancement in RAN の 5 つのキーエリアにおいて一層のセキュリティ強化に向けた検討が進められている。また、Release 19 に向けた Study Item には、将来の量子コンピュータの脅威に備えるため、256 ビット暗号のサポートに関する課題も追加されている。

4.6. 他団体における 5G セキュリティ検討
3GPP 以外の標準化団体や業界団体における 5G セキュリティ関連のアクティビティについて簡単に紹介する。
ITU-Tセキュリティ関連の検討を行っている Study Group 17 において 5G セキュリティに関する勧告作成を他の標準化団体とリエゾンを取りながら進めている。2023 年 12 月時点

11

では課題 2（Q2/17）において以下の Work Item について議論されている。


Guidelines of built-in security framework for telecommunications networkSecurity Requirements for the Operation of 5G Core Network to Support
Vertical Services



Security capabilities of network layer for 5G edge computing

Guidelines and Technical Requirements for 5G Network Asset Security Risk
AnalysisSecurity controls for operation and maintenance of IMT-2020/5G network
systemsGSMA

通信機器のセキュリティ認証フレームワークとして NESAS（Network Equipment
Security Scheme） を構築している。NESAS は 3GPP の TS33 シリーズで規定される試験仕様（SCAS：Security Assurance Specifications）に基づく機器試験や、第 3 者監
査などにより構成される。5G ネットワークのセキュリティ確保に向けて、GSMA はNESAS を欧州 ネットワーク情報セキュリティ庁(ENISA)に提案中である。これは、欧州委員会の 5G サイバーセキュリティ対策「EU Toolbox」を補完するものであり、現在欧州各国は 5G ネットワークのセキュリティ対策の実装を進めているところである。

2018 年 11 月に 5G Security Task Force (5GSTF) が立ち上げられ、実装や運用の観点から標準のギャップを埋めるための議論が行われている。5G セキュリティに関連する承認済みの文書としては以下が発行されている。


FS.34 Key Management for 4G and 5G Inter-PLMN Security

FS.35 Security Algorithm Deployment Guidance (メンバー外非公開)

FS.36 5G Interconnect Security (メンバー外非公開)

FS.39 5G Fraud Risks Guide (メンバー外非公開)

FS.40 5G Security Guide

IR.77 - Inter-operator IP Backbone Security Req. for Service and Inter-operator
IP Backbone Providers (メンバー外非公開)



NG.113 - 5G Roaming Guidelines

NG.116 - Generic Network Slice Template

NGMN

5G セキュリティに関する以下のレポートを発行している


5G Security Recommendations Package #1: Access Network / DoS

5G Security Recommendations Package #2: Network Slicing



5G Security – Package 3: Mobile Edge Computing / Low Latency / Consistent User
Experience

NGMN 5G Network Security Capability Framework for Verticals



Security Considerations for 5G Network Operation



Security Aspects of Network Capabilities Exposure in 5G
12

5G Mobile Network Sharing Security V1.02

4.7. 5G セキュリティ標準化動向まとめ
5G は、加入者 ID 保護、U-Plane の改ざん検知、Home Control の強化、SEPP の導入、DU-CU
分離等の様々なセキュリティ強化により、LTE よりも安全なネットワークになるよう仕様が規定されている。一方で、SBA、仮想化、ネットワークスライスなど、5G で導入される新たな仕組みに起因するセキュリティ脅威についての懸念は存在し、これらについては、3GPP だけでなく、GSMA 等の業界団体における、実装や運用者視点での議論についても注視していく必要がある。
また、Release 16 以降、様々なユースケースへの対応のための仕様の追加や強化が行われており、ユースケース毎のセキュリティ検討においては、関連する仕様をより詳細に確認する必要がある。

13

5. 5G セキュリティの検討
5G セキュリティ全般から 3 つのユースケース(IoT, Connected Vehicle ,Fintech)を検討対象とした調査、検討過程及びユースケース毎の検討範囲の検討結果をまとめた。
5.1. ユースケース IoT セキュリティ
5GMF における課題を検討するに当たっては、国内外の各種団体が発行している IoT セキュリ
ティ関連文書の記載内容を精査し、文書中で記述されている課題項目の中から 5G がセキュリテ
ィ改善のために貢献できそうな課題、ならびに、現状の 5G では直ちに貢献はできないものの、
5G 仕様策定も含めた将来的方向性として貢献できる可能性のある課題を抽出することとした。
用語(1) エンドポイント(EP) エンドポイントは接続されたネットワークを介して双方向通信を行なう遠隔計算機器のことであり、例としてはデスクトップ/ノート PC、スマートフォン、
タブレット、サーバ、ワークステーション等がある。
(2) ピア 「同等の者」を意味する語であり、クライアント-サーバ・モデルのような非対称関係
ではなくすべてのエンドポイントが対等な関係にあるネットワーク・モデルにおける端末を指す。
IoT セキュリティ関連文書概説
まず、使用した IoT セキュリティ関連文書に関する概要を記述する。
5.1.2.1. IoT セキュリティガイドライン[2]
経産省/総務省/IoT 推進コンソーシアム(IOTAC)によって 2016 年 7 月に発行された文書であり、IoT 特有の性質と IoT でのセキュリティ対策の必要性を踏まえて、IoT 機器やシステム、サービ
スについて、セキュリティ・バイ・デザインを基本原則としつつ、セキュリティ確保等の観点から求められる基本的な取組を明確化するためのガイドライン。
方針 / 分析 / 設計 / 構築・接続 / 運用・保守の 5 つの指針と一般利用者ルールとから構成されている。
5.1.2.2. 安全な IoT システムのためのセキュリティに関する一般的枠組[3]内閣サイバーセキュリティセンターによって 2016 年 8 月に発行された文書。IoT セキュリテ
ィの考え方を全ての IoT システムに関わる一般要求事項と個々の分野の特性を踏まえた分野固
有の要求事項の 2 段階とし、一般要求事項について前者についてのセキュリティ要件の基本的要素をセキュリティ・バイ・デザインに基いて明らかにしたもの。
5.1.2.3. IoT セキュリティ総合対策[4]
総務省によって 2017 年 10 月に発行された文書であり、[3]で示された枠組に基づき、脆弱性対策、研究開発、民間での対策促進、人材育成、国際連携の 5 項目について国の具体的施策を示したもの。
5.1.2.4. サイバー・フィジカル・セキュリティ対策フレームワーク(案)[5]
経済産業省によって 2018 年 4 月に発行された文書であり、IoT や AI によって実現される「Connected Industries」に必要なセキュリティの確保に向けて、産業に求められ「Society5.0」、
14

る対策の全体像を整理したもの。
CPS に必要な対策要件／対策例を米国国立標準技術研究所発行の NIST Cybersecurity
Frameworks と対応付けた形で定義している。
5.1.2.5. IoT 開発におけるセキュリティ設計の手引き[6]情報処理推進機構 (IPA)が 2016 年 5 月に発行し 2018 年４月に改訂が行なわれた文書。IoT 開発のセキュリティ設計において行う、脅威分析・対策検討・脆弱性への対応方法を解説する、IoT
システムのセキュリティ設計を担当する開発者に向けた手引きとなっている。
5.1.2.6. IoT セキュリティ評価検証ガイドライン[7]重要生活機器連携セキュリティ協議会(CCDS)によって 2017 年 6 月に発行された文書。スマー
トホームシステムに対するセキュリティ評価検証を元に、IoT セキュリティガイドライン等の評
価検証項目における具体的なプロセスを示しており、IoT 機器全般を対象に具体的なセキュリテ
ィの評価検証プロセスが記述されている。
5.1.2.7. IoT セキュリティガイド 標準／ガイドライン ハンドブック[8]日本ネットワーク・セキュリティ協会(JNSA)によって 2018 年 5 月に発行された文書。国内外の関連団体が公開している IoT セキュリティ指針／標準／規格等の文書に関して解説を行なったもの。
5.1.2.8. IoT セキュリティチェックシート[9]
企業が IoT を導入する際の、利用側としてのセキュリティ面の検討項目を、 IoT セキュリティ
ガイドラインを参考にチェックシートとして整理したもの。
5.1.2.9. Draft NISTIR 8200 [10]米国国立標準技術研究所(NIST)によって 2018 年 2 月に発行された文書。IoT 向け国際的サイバーセキュリティの標準化状況に関する米政府機関間報告書であり、既存／制定中の各種標準文書と IoT の実状との照合に基づくギャップを明確化することが目的である。
11 のサイバーセキュリティコア領域について説明し、関連する標準の例を示すとともに、IoTの一般的なアプリケーションと IoT の 5 つのアプリケーションのそれぞれの分野について、IoT
サイバーセキュリティの目的、リスク、及び脅威を分析している。
5.1.2.10. Baseline Security Recommendations for IoT in the context of Critical Information
Infrastructures [11]欧州ネットワーク・情報セキュリティ機関(ENISA) によって 2017 年 11 月に公開された文書。
欧州で運用される IoT 向けセキュリティベースライン設定を目指した文書であり、パラダイム／
脅威＆リスク分析／対策＆良実践／ギャップ分析／高水準推奨事項を提示している。
5.1.2.11. Security Guidance for Early Adopters of the Internet of Things [12]クラウド・コンピューティングのセキュリティを実現するための最良実践推奨のための国際的活動を展開する非営利法人である Cloud Security Alliance (CSA)によって 2016 年 2 月に公開された文書。IoT 早期採用者向けに作成されたセキュリティ・ガイダンスであり、目的／個人・組織
への IoT 脅威／セキュアな IoT 配備へのチャレンジ／推奨されるセキュリティ制御／将来的努力
事項を提示している。

15

5.1.2.12. OWASP IoT Top 10[13]ウェブ・アプリケーション・セキュリティに関する無償の技術文書策定を目的としたオンライ
ン・コミュニケーションである The Open Web Application Security Project (OWASP)によって2014 年に公開され、 2018 年 12 月には改訂版が公開された文書。IoT デバイスで留意すべき 10個の脆弱性が提示されており、2014 年版では内容の多くが IoT 固有ではなく Web アプリケーシ
ョンと一致したものであったが、2018 年版では構成が大きく見直されており、より IoT 固有の記述が増加した文書となっている。
5.1.2.13. Technical Specification TS-0003 Security Solutions [14]M2M 技術および IoT 技術に対する要件、アーキテクチャ等の策定を行なっている国際的組織である OneM2M によって 2018 年 4 月に発行された M2M グローバル標準におけるセキュリティソリューション技術仕様書。OneM2M におけるセキュリティアーキテクチャ、認証、認可、ID管理やセキュリティフレームワーク、プライバシー保護等の仕様が定義されている
5.1.2.14. IoT Security Guidelines [15]
世界 200 ヶ国以上で展開されている移動体通信事業者および関連企業からなる業界団体である
GSM アソシエーションによって 2017 年 10 月に発行された文書。同団体が提言する IoT セキュ
リティガイドラインであり、概要、サービス、エンドポイント、ネットワークの 4 書からなっている。IoT システムの可用性、ID、プライバシーとセキュリティの各課題に対し、モバイルネッ
トワークが解決に寄与する事が提言されている。
5.1.2.15. 5GMF 白書「5G ユースケースにおけるセキュリティ 第 1.1 版」における再調査
2021 年度に改めて上述の文書群に改訂版が発行されているかの調査を行なった。その結果、改訂されたのは国内版 2 件1と国外版 3 件2のみであり、修正量も少なかったため、前回と同じくGSMA IoT Security Guidelines and Assessment に記述された課題項目を IoT 課題として採用することにした。GSMA IoT Security Guidelines and Assessment 自体の改訂は小規模であり、課題項目自体まったく以前のままであった。
また 2022 年度にも前段と同様に上述の文書群に対する改訂が行われたか否かを調査したところ、国内版／国外版ともにごく僅かの改訂がなされたのみであったため、2022 年度版でも GSMA IoT
Security Guidelines and Assessment に記述された課題項目を IoT 課題として採用した。
5.1.2 節で用いたセキュリティ文書群と 2022 年度版で用いたセキュリティ文書群との修正内容
を表 5.1.1 国内版セキュリティ文書修正内容および表 5.1.2 国外版セキュリティ文書修正内容に示した。いずれも修正はなされていないか、もしくはごく僅かであることが判明している。

(JSSEC) IoT セキュリティ CS および 総務省 IoT セキュリティ総合対策
GSMA IoT Security Guidelines and Assessment、NISTIR 8200 Interagency Report on the
Status of International Cybersecurity Standardization for the Internet of Things (IoT)、
OneM2M TS-0003-V3.8.0 Security Solutions
16

1
2

表 5.1.1 国内版セキュリティ文書修正内容
Version

セキュリティ文書名

修正内容概略IoT セキュリティチェックシート

第 2.1 版

第 2.1 版

IoT セキュリティ標準/ガイドラインハンド

V1.0

V1.0

Rev1.0Rev1.0

ブック 2017 年版
IoT セキュリティ評価検証ガイドライン
IoT 開発におけるセキュリティ設計の手引き

改版なし

内外関連活動動向反映

ver1.0

ver1.0

IoT・5G セキュリティ総合対策 2020

2020

2020

内閣サイバーセキュリティセンター

版情報なし

IoT セキュリティガイドライン ver1.0

ver1.0

サイバー・フィジカル・セキュリティ対策フ
レームワーク（CPSF）

ver1.0

表 5.1.2 国外版セキュリティ文書修正内容
Version

セキュリティ文書名
GSMA IoT Security Guidelines and

修正内容概略

v2.2

v2.2

Final

Final

Baseline Security Recommendations for

NOVEMBERNOVEMBER

IoT

2017

2017

CSA SG 4 Early Adopters of the IoT

April 2015

April 2015

OWASP IoT Top 10 Project

2018

2018

OneM2M TS-0003 Security Solutions

V3_15_0

V3_16_0

Assessment
NISTIR 8200 Interagency Report on the
Status of International Cybersecurity
Standardization

for

the

InternetofThings (IoT)

ごく僅か

課題の抽出
5.1.1 節で列挙した日本国内/国外の各種組織から発行された IoT セキュリティ関連文書には、それぞれの文書の作成目的を反映して記述レベルに相違が見られる。たとえば[3]は安全な IoT シ
ステムが具備すべき一般要求事項としてのセキュリティ要件基本要素を明らかにするという大所高所の立場からの記述を行なっているのに対して、[14]では OneM2M という IoT の構成要素の一つである M2M システムを提供するための具体的なシステム実装である OneM2M におけるセキュリティソリューションを定義した実装に大きく依存する記述となっている。
5GMF セキュリティ検討アドホックでは 5G との連携が必要な IoT を中心として検討課題を探るという方針が[16]で示されている。したがって 5.1.2 節記載の文書の中では IoT システムのセキ
17ュリティ課題に対してモバイルネットワークを用いた解決を探るというスタンスで記載された
GSM アソシエーション発行の IoT Security Guidelines [15]が最も親和性が高いと考えられる。
そのため、課題に関しては[15]をベースとして検討を行なうこととし、他文書からの課題については付録で示したとおり[15]の課題へ割り付けを実施した。
5.1.3.1. GSMA IoT Security Guidelines 記載の課題
GSMA IoT Security Guidelines の概要編である GSMA IoT Security Guide CLP11-v2.0 では、
IoT セキュリティに対するチャレンジとなる項目を


可用性



識別・認証



プライバシー

セキュリティ

の 4 種類の観点からまとめている。
5.1.3.2. 可用性
可用性に対するチャレンジとしては以下が列挙される。
1.

如何にして Low Power Wide Area (LPWA) ネットワーク (たとえば NB-IoT ないし LTEM) を伝統的なセルラ・システムと同一のレベルのセキュリティで運用することが可能と
なるのか？

2.

IoT エンドポイントがネットワーク境界をまたがって移動する際に、如何にして複数のモ
バイルオペレーターが同一レベルのネットワーク・セキュリティを提供できるのか？

3.

如何にしてゲートウェイ・エンドポイントに通信を依拠するキャピラリ・エンドポイント
に対してネットワークの信頼をフォワードすることが可能となるのか？

4.

如何にしてセキュアな通信環境を用いることができるように軽量エンドポイントの電力制限を回避できるのか？

5.1.3.3. 識別・認証
識別・認証に対するチャレンジとしては以下が列挙される
1.

エンドポイントを操作する利用者をエンドポイントのアイデンティティに対して強力に連想付けることは可能なのか？

2.

如何にしてサービスとピアはエンドポイントのアイデンティティを検証することでエンド・ユーザのアイデンティティも検証することができるようになるのか？

3.

如何にしてエンドポイントのセキュリティ技術はピアおよびサービスを安全に認証することができるのか？

4.

悪意あるサービスおよびピアは正規のサービスおよびピアになりすますことは可能なのか？

5.

如何にしてデバイスのアイデンティティをタンパリングもしくは操作から保護することができるのか？

6.

如何にしてエンドポイントおよびネットワークは IoT サービスが当該エンドポイントに対してアクセスすることが許可されていると保証できるのか？
18

5.1.3.4. プライバシー
プライバシーに対するチャレンジとしては以下が列挙される
1.

エンドポイントのアイデンティティは認可されていない利用者に披瀝されるのか？

2.

ユニークなエンドポイントないし IoT サービスの識別子を利用することでエンド・ユーザ
もしくはエンドポイントを物理的にモニタリングないしトラッキングできるのか？

3.

エンドポイントもしくは IoT サービスから放出されるデータは、物理的なエンド・ユーザの属性 (位置、行動、ないし、睡眠中/覚醒中のような状態)を示唆ないし直接的に提示するか？

4.

暗号文に存在するパターンが観察できないほど十分な機密性と完全性を備えた暗号化方式が用いられているか？

5.

製品もしくはサービスは利用者特有の個人識別可能情報 (PII) をどのように保存したり取扱ったりしているか？

6.

エンド・ユーザは IoT サービスないし製品における PII の保存および利用に関して制御権を保持しているか？

7.

データをセキュアにするために用いられるセキュリティ鍵およびセキュリティ・アルゴリ
ズムは新しくすることができるか？

5.1.3.5. セキュリティ
セキュリティに対するチャレンジとしては以下が列挙される。
1.

セキュリティ最良実践はプロジェクト開始時から製品およびサービスに対して組み込まれ
ているか？

2.

セキュリティ・ライフサイクルがソフトウェアおよび製品開発ライフサイクルに組み込まれているか？

3.

サービスと組み込みシステムで動作するアプリケーションに対してアプリケーション・セ
キュリティが適用されているか？

4.

エンドポイントおよびサービス・エコシステムに信頼コンピューティング・ベース (TCB)が実装されているか？

5.

如何にして TCB はアプリケーション・イメージおよびサービスの自己検証を強制するか？

6.

エンドポイントないし IoT サービスは構成もしくはアプリケーションに異常があることを検出できるか？

7.

如何にしてエンドポイントで悪意ある振舞が行なわれていることを示す異常の検出が行え
るのか？

8.

どのように認証とアイデンティティが製品ないしサービスのセキュリティ・プロセスに結び付けられているのか？

9.

危殆化を示す異常が検出された場合のためにどのようなインシデント対応計画が定義されているか？

10. 危殆化が迅速かつ効率的に閉じ込められるためにサービスおよび資源はどのようにセグメ
ント化されているか？
11. どのように危殆化後のサービスおよび資源の再開が達成されるか？
1912. 攻撃は発見できるか？
13. 危殆化したシステム・コンポーネントは発見できるか？
14. 如何にして顧客はセキュリティ的懸念を報告できるか？
15. エンドポイントは脆弱性を除去するために更新ないし修正することができるか？
5G における新規セキュリティ機能まとめ
4G-LTE 以前と比較すると 5G には多くの新規セキュリティ機能が導入されている。別章で詳細は述べられているが、課題抽出を補助するため、本節では[17]に即して 5G で導入された新規セキュリティ機能を再度まとめている。
5.1.4.1. プライマリ認証
4G-LTE 以前では UE とモバイルネットワークとの間の相互認証は常に AKA (Authentication
And Key Agreement) と呼ばれる単一の機構によってのみ行なわれていたが、5G ではこれをカ
スタマイズ可能としており、従前の AKA を拡張した 5G-AKA に加えて EAP (Extensible
Authentication Protocol) の枠組で動作する EAP-AKA’が利用可能となっている。これにより従来は WiFi 等の非 3GPP アクセスを用いる場合に 3GPP アクセスとは異なる別立ての認証メカニ
ズムをサポートする必要があったのが、5G では 3GPP アクセス利用時と非 3GPP アクセス利用
時とで同じ認証メカニズムを用いることが可能になっている。
さらにプライベート・ネットワーク等の特別なケースでは EAP-AKA’以外の EAP メソッドを用いた認証メカニズムを用いることも可能とされた。
5.1.4.2. クレデンシャル・ストレージ
AKA で用いられる秘密鍵 K のような高い機微性を持ったクレデンシャルを安全に格納するた
めに従来は UICC が用いられていたが、5G では UICC 以外のセキュアなハードウェア・ストレージ・プラットフォームにクレデンシャルを格納するというオプションも提供可能となった。
5.1.4.3. セカンダリ認証
セカンダリ認証はモバイルネットワークに認証された UE に対してモバイルネットワーク外に存在するデータ・ネットワークに対する認証を提供する機構である。セカンダリ認証ではモバイ
ルネットワーク内の機能が UE に対する Authenticator となってデータ・ネットワークに EAPAKA’とは別の EAP メソッドによる認証フローを実行することで実現される。
5.1.4.4. オペレータ間セキュリティ
従来のオペレータ間通信を実現するために用いられていた SS7 ないし Diameter に脆弱性が発見されたことを受けて、5G ではオペレータ間通信を安全に実行可能とするための SEPP (Secure
Edge Protection Proxy) と呼ばれる新規機能が導入された。
5.1.4.5. プライバシー
4G-LTE 以前ではモバイルネットワーク契約者を一意に特定可能な IMSI を平文のままで通信しなければならない機会が存在したため、トラッキング等のプライバシーに対する被害を受ける可能性を排除できていなかったのだが、5G では 4G-LTE 以前の IMSI に相当する SUPI
(Subscription Permanent ID)をネットワーク・オペレータの公開鍵によってランダム暗号化した結果である SUCI (Subscription Concealed ID)を用いることで、プライバシーへ配慮することが20

可能となった。
5.1.4.6. サービス・ベース・アーキテクチャ (SBA)
5G ではコア・ネットワークで用いられる各種サービスに基づいたアーキテクチャを採用することで、十分なセキュリティを導入可能となっている。
5.1.4.7. Central Unit (CU) - Distributed Unit (DU)
5G では安全でない位置に基地局を配備するユースケースも想定されているため、基地局を CUと DU の二つのエンティティとして実現し、機微情報の流通は CU までで留めることで、そのよ
うなユースケースへの対応を可能とせしめている。
5.1.4.8. 鍵階層
前項と同様の意味で、5G における鍵階層も従来とは異なる形態となっている。
5.1.4.9. モビリティ
5G においてもモビリティ自体は 4G-LTE と同様なのだが、コア・ネットワークのアンカーが安全ではない場所に置かれる可能性があることから、5G ではアンカー・ポイント間のセキュアな
モビリティもプロビジョニングされる必要が生じることとなっている。
5.1.4.10. ネットワーク・スライス
5G ではモバイルネットワークに対する要求条件の多様化傾向に対処するために、ネットワーク
を分割し、分割された個々の部分（スライス）を顧客に対して専有可能とすることで、同一モバ
イルネットワークに存在する他の部分に影響することなしに適切なセキュリティ環境を提供することが可能となっている。
5G セキュリティ機能による課題への対応可能性
本節では 5.1.4 節で紹介した 5G 新規セキュリティ機能を用いることで 5.1.3.1 節で述べた
GSMA Security Guidelines が提示した課題に対して対応の可能性がある項を検討していく。
5.1.3.1 節でも示した通り、他の文書から抽出された課題についても GSMA Security Guidelines
課題に割り付けを実施したため、関連文書から抽出された課題については網羅されていると考える。
本節で可能性ありと考えられた課題を中心に、今後 5G ネットワークにおける IoT セキュリテ
ィの検討を進めていきたい。
5.1.5.1. 可用性
1.

如何にして Low Power Wide Area (LPWA) ネットワーク (たとえば NB-IoT ないし LTEM) を伝統的なセルラ・システムと同一のレベルのセキュリティで運用することが可能となるのか？
4G までのモバイルネットワークでは同一のセキュリティ機能が要請されたが、5G では独立したスライスへの分割が可能となったため、他に影響を与えることなしに LPWA を必要とするようなローエンド・デバイスへの柔軟な対応が可能となる可能性がある。 [5.1.4.10]

2.

IoT エンドポイントがネットワーク境界をまたがって移動する際に、如何にして複数のモ
バイルオペレーターが同一レベルのネットワーク・セキュリティを提供できるのか？
5G に お け る オ ペ レ ー タ 間 モ ビ リ テ ィ 関 係 構 築 に よ り 実 現 で き る 可 能 性 が あ る21[5.1.4.4][5.1.4.9]
3.

如何にしてゲートウェイ・エンドポイントに通信を依拠するキャピラリ・エンドポイント
に対してネットワークの信頼をフォワードすることが可能となるのか？計算資源の乏しい
ローエンド・デバイスであっても 5G への直接アクセスを可能となる可能性がある 。
[5.1.4.10]
仮に GW に頼らなければならない EP が今後も残るのであれば、EP⇔GW 間の保護策提供
方法も引き続き課題となる。

4.

如何にしてセキュアな通信環境を用いることができるように軽量エンドポイントの電力制限を回避できるのか？
5G では電力制限がある軽量エンドポイントデバイスについてもネットワーク・スライシン
グにより対応できる可能性がある。 [5.1.4.10]

5.1.5.2. 識別・認証
1.

エンドポイントを操作する利用者をエンドポイントのアイデンティティに対して強力に連想付けることは可能なのか？
エンドポイント利用者＝ネットワーク契約者である場合にはネットワーク内で連想付を行
なえる可能性がある。[5.1.4.3]
ただし特に IoT ではエンドポイント利用者とネットワーク契約者が異なるケースも多いと考えられ、そのようなケースへの対応は引き続き課題となる。

2.

如何にしてサービスとピアはエンドポイントのアイデンティティを検証することでエンド・ユーザのアイデンティティも検証することができるようになるのか？
1.項に同じ3.

如何にしてエンドポイントのセキュリティ技術はピアおよびサービスを安全に認証することができるのか？
5G ではエンドポイントと正規ピア/サービスとの間ではセカンダリ認証による相互認証が活用できる可能性がある。[5.1.4.3]

4.

悪意あるサービスおよびピアは正規のサービスおよびピアになりすますことは可能なのか？
3.項に同じ5.

如何にしてデバイスのアイデンティティをタンパリングもしくは操作から保護することができるのか？
5G ではクレデンシャル・ストレージ機能により UICC 以外のセキュア・ストレージを利用することが可能であり、これを活用できる可能性がある。 [5.1.4.2]

6.

如何にしてエンドポイントおよびネットワークは IoT サービスが当該エンドポイントに対してアクセスすることが許可されていると保証できるのか？
5G ではモバイルネットワーク外に存在する IoT サービスと UE との間でのセカンダリ認
証による相互認証を実施することで解決できる可能性がある。[5.1.4.3]

5.1.5.3. プライバシー
1.

エンドポイントのアイデンティティは認可されていない利用者に披瀝されるのか？
22

5G では契約者識別のために用いられる 4G-LTE における IMSI に相当する SUPI を秘匿するために、オペレータ公開鍵でランダム暗号化した結果である SUCI を常に用いることが可能となったため、モバイルネットワーク内でのエンドポイント・アイデンティティ漏
洩が回避できる可能性がある。 [5.1.4.5]
2.

ユニークなエンドポイントないし IoT サービスの識別子を利用することでエンド・ユーザ
もしくはエンドポイントを物理的にモニタリングないしトラッキングできるのか？
1.項に同じ [5.1.4.5]

3.

エンドポイントもしくは IoT サービスから放出されるデータは、物理的なエンド・ユーザの属性 (位置、行動、ないし、睡眠中/覚醒中のような状態)を示唆ないし直接的に提示するか？
5G ネットワーク内においては、モバイルネットワーク全区間での安全性を考慮された暗号化方式が利用されていることを活用できる可能性がある。

4.

暗号文に存在するパターンが観察できないほど十分な機密性と完全性を備えた暗号化方式が用いられているか？
5G ネットワーク内においては、安全性を考慮された暗号化方式が利用されていることを活用できる可能性がある。

5.

製品もしくはサービスは利用者特有の個人識別可能情報 (PII) をどのように保存したり取扱ったりしているか？
製品ないしサービスが PII をどのように保存/処理するかに依存するため、5G 課題として検討することは困難と考えられる。

6.

エンド・ユーザは IoT サービスないし製品における PII の保存および利用に関して制御権を保持しているか？
6.項に同じ7.

データをセキュアにするために用いられるセキュリティ鍵およびセキュリティ・アルゴリ
ズムは新しくすることができるか？
5G フェーズ 2 では長期有効鍵 (UICC とコア・ネットワークで共有される K)の更新可能化方式に関して検討予定であり、これを活用できる可能性がある

5.1.5.4. セキュリティ
1.

セキュリティ最良実践はプロジェクト開始時から製品およびサービスに対して組み込まれているか？
サービスにおける本課題は検討範囲外と考えられる。なお、５G コアの機能を提供する各機能要素におけるセキュリティ最良実践に関しては３GPP SCAS (Security Assurance
Specification) の枠組を用いた取組が行なわれている。

2.

セキュリティ・ライフサイクルがソフトウェアおよび製品開発ライフサイクルに組み込まれているか？
1.項に同じ3.

サービスと組み込みシステムで動作するアプリケーションに対してアプリケーション・セ
キュリティが適用されているか？
23

1.項に同じ。ただし 5G ネットワーク経由でアプリケーション・セキュリティの状態に関する検査機能を提供するという検討はあり、それが適用できる可能性はある
4.

エンドポイントおよびサービス・エコシステムに信頼コンピューティング・ベース (TCB)が実装されているか？
3.項に同じ5.

如何にして TCB はアプリケーション・イメージおよびサービスの自己検証を強制するか？
3.項に同じ6.

エンドポイントないし IoT サービスは構成もしくはアプリケーションに異常があることを検出できるか？
3.項に同じ7.

如何にしてエンドポイントで悪意ある振舞が行なわれていることを示す異常の検出が行えるのか？
3.項に同じ8.

どのように認証とアイデンティティが製品ないしサービスのセキュリティ・プロセスに結び付けられているのか？
1.項に同じ9.

危殆化を示す異常が検出された場合のためにどのようなインシデント対応計画が定義されているか？
1.項に同じ10. 危殆化が迅速かつ効率的に閉じ込められるためにサービスおよび資源はどのようにセグメ
ント化されているか？
1.項に同じ11. どのように危殆化後のサービスおよび資源の再開が達成されるか？
1.項に同じ
12. 攻撃は発見できるか？
1.項に同じ13. 危殆化したシステム・コンポーネントは発見できるか？
1.項に同じ
14. 如何にして顧客はセキュリティ的懸念を報告できるか？
1.項に同じ15. エンドポイントは脆弱性を除去するために更新ないし修正することができるか？
1.項に同じ5.1.6. IoT 課題に対する具体的対策案検討結果
本章では前章までで特定された IoT 課題に対する具体的な対策案をまとめる。
5.1.6.1. 可用性 1：LPWA ネットワークの安全な配備・運用
課題: 如何にして Low Power Wide Area (LPWA) ネットワーク (たとえば NB-IoT な
いし LTE-M) を伝統的なセルラ・システムと同一のレベルのセキュリティで運用する
24

ことが可能となるのか？
省電力広域ネットワークである LPWA (Low Power Wide Area) 実現のためには、Km 単位の広域を低消費電力でカバー可能な無線通信技術が必要となる。そのような LPWA を配備・運用するための要件としては、バッテリーにより 15 年間駆動可能な機器を収容可能な通信環境を提供するというものが挙げられており、省電力に対する強い要請が存在している。そのような要請の下でネットワーク・セキュリティを実現するためには、軽量暗号などの低電力消費アルゴリズムの使用といったことも必要となってくるだろう。しかしながら、4G までは UE とコア・ネットワーク間での通信保護は常に同一の暗号アルゴリズムが用いられていたため、IoT で必要とされる
省電力を提供することは難しかった。

図 5.1.1 5G における既定 4 スライス達成目標値[18],[19]5.1.6.1.1. 5G による対策
5G ではネットワーク・スライシングが導入されており、ネットワークを仮想的独立したスライスに分割し、個々のスライスでは他スライスに悪影響を与えることなく利用アルゴリズムを変更することが可能となっている。たとえば 5G における既存のユースケースとしては
1.

eMBB

2.

URLLC

3.

mMTC

4.

V2X

の 4 種類が存在しており(図 5.1.1)、この中では mMTC が LPWA 向けに事前定義されたスライ
ス設定ということになる。
25

5.1.6.1.2. IoT プラットフォーム運用者要考慮事項
IoT プラットフォームを運用する事業者にとって本項目のために必要となるのは、同事業者が提供している応用に適したスライス設定が存在すること、もしくは事業者によって適切に設定可能となっていることの確認である。
5.1.6.2. 可用性 2：複数オペレータ間ローミング・セキュリティ
課題: IoT エンドポイントがネットワーク境界をまたがって移動する際に、如何にして複数のモバイルオペレーターが同一レベルのネットワーク・セキュリティを提供でき
るのか？
4G 以前でオペレータ間ローミング実施時に利用されていた Diameter プロトコルに契約者情報を漏洩するなどの脆弱性が存在することが 2018 年に発覚している[20]。具体的な脆弱性としては


契約者情報漏洩

ネットワーク情報漏洩



詐欺



契約者 DoSなどの被害発生の可能性が存在した。
5.1.6.2.1. 5G による対策
5G では上述した脆弱性対策として SEPP (Secure Edge Protection Proxy）と呼ばれる新規ネットワーク機能が導入された。SEPP は各オペレータ・ネットワークのエッジに配備され、以下のような機能が提供されるようになった。
異なるオペレータ間で交換されるシグナリング・トラフィックの機密性・完全性保護



トポロジー隠蔽Fire Wall ベースのフィルタリング機能

さらに、5G ではプライマリ認証で 3GPP アクセスと WiFi 等の非 3GPP アクセスのいずれにおいても 5G-AKA/EAP-AKA’によりホーム・オペレータが常に認証可能な環境が確立されたため、ローミング・シナリオでの詐欺を防止することが可能になったというメリットも生じている。
5.1.6.2.2. IoT プラットフォーム運用者要考慮事項
本項は 3GPP オペレータ間での動作に閉じているため、IoT プラットフォーム運用事業者にとって必要な事項は存在しない。
5.1.6.3. 可用性３：キャピラリ・エンドポイントへの信頼フォワード
課題: 如何にしてゲートウェイ・エンドポイントに通信を依拠するキャピラリ・エンド
ポイントに対してネットワークの信頼をフォワードすることが可能となるのか？
ここで言う『キャピラリ・エンドポイント』とはクラウドとの通信を直接実行することができず、ゲートウェー等による媒介を必要とする機器のことである。そのような構成を取る場合、ク
ラウドのネットワークで確立されている信頼をゲートウェーの先に存在するキャピラリ・エンド
26

ポイントまで波及させるためのソリューションを提供する必要がある。
5G では低性能/省電力エンドポイントであっても前出の LPWA ネットワーク等を経由して機器
自身が直接クラウドにアクセスできるという構成を想定しているため、基本的にはそのような状況に至らずに済むことが期待されている。
ただし、ゲートウェーを必要とするシナリオが低性能/省電力以外に実在するのであれば、キャ
ピラリ・エンドポイントに信頼を波及させるためのソリューションが必要となる可能性は残される。
5.1.6.3.1. IoT プラットフォーム運用者要考慮事項
ターゲットとする応用がゲートウェーを必要とするシナリオである場合にネットワーク側で確立された信頼をゲートウェーの先へ波及させるためのソリューションの策定が必要となる。
5.1.6.4. 可用性４：セキュアな通信環境における軽量エンドポイントの電力制約対策
課題：如何にしてセキュアな通信環境を用いることができるように軽量エンドポイン
トの電力制限を回避できるのか？
5.1.6.4.1. 3GPP における 5G 一般機能検討中の軽量エンドポイント向け電力制約対策
3GPP では 5G における CIoT サポートに関する主要問題と可能なソリューション検討作業を実施しており[21]、その中で電力制約解決に関する以下の現行主要問題が定義されている。


5.4 Key Issue 4: Power Saving Functions



5.5 Key Issue 5: UE TX Power Saving Functions

そして、これらに対するソリューションとしては以下が検討されている。


Solution 8: Enhancing MICO for Mobile terminated data/signaling

Solution 9: Enhanced MICO mode with Active Time

Solution 22: eDRX for CM-IDLE state in 5GS

Solution 23: MICO Mode Management for Expected Application Behaviour

Solution 32: MO Data Buffering in the UESolution 33: Delayed Paging Response

Solution 34: Provisioning of UE TX power saving parameters

Solution 38: eDRX RRC_INACTIVE STATE in 5GS

Solution 41: Combining RRC-INACTIVE and 5G UP optimization

27

RRC CONNECTED

Connection
Establishment/Inactivation

Connection
Establishment/Release

RRC INACTIVERRC IDLE

図 5.1.2 5G NR RRC 状態遷移図
また、5G では 4G までの RRC IDLE 状態と RRC CONNECTED 状態に加えて RRC INACTIVE
状態が新規に定義されている(図 5.1.2)。RRC INACTIVE 状態では UE と基地局/CN では RRC
および NAS のコンテキストを保持しながら UE 内部状態としてはほぼ RRC_IDLE 同様の省電力状態が維持できるように図られている。
5G におけるセキュリティ関連検討を担当する 3GPP SA3 では上述した 5G 一般機能を実現するためのセキュリティソリューションとして以下の仕様を定義している。
1.

RRC_INACTIVE⇔RRC_CONNECTED 遷移時のセキュリティ手続 (TS33.501 6.8.2.1
節)

2.



INACTIVE 遷移時の SC 保存手続と CONNECTED 遷移時の SC 回復方法



遷移時の gNB: 同/異ケース

RRC_INACTIVE 中モビリティ時の鍵処理 (TS33.501 6.8.2.2 節)

構成済 RNA (RAN based Notification Area)離脱時等の UE によるネットワークへの通知を実現

5.1.6.4.2. IoT プラットフォーム運用者要考慮事項
本節で解説した電力制約解決対策の基本的な処理は gNB/ng-eNB⇔通信プロセッサ間でなされると期待されるが、以下の UE 動作実現のためにアプリケーション・プロセッサ (AP) による補助が必要となる可能性はあるかもしれないため、AP の仕様を確認した上で対処が必要となる。
RRC CONNECTED⇒RRC INACTIVE 遷移は gNB/ng-eNB 主導で実施されるので、UE では
遷移指示に従って 33.501 6.8.2.1.2 節に従って RRC INACTIVE への状態遷移処理を実施
28



RRC INACTIVE 状態から RRC CONNECTED 状態に遷移する場合、UE は 33.501
6.8.2.1.3 節に従った状態遷移処理を実施

5.1.6.5. 識別・認証 1： EP 操作ユーザと当該 EP アイデンティティとの強力な連想付可能？
課題：エンドポイントを操作する利用者をエンドポイントのアイデンティティに対して強力に連想付けることは可能なのか
エンドポイント操作ユーザが同エンドポイントへのサービス提供 MNO 契約者であり、かつ、
自身のスマートフォンを介してエンドポイントの操作を行なうというユースケースであれば、当該 MNO が管理する DB (5G コアにおける UDR 機能) を活用することで連想付を行なうことが可能である。
それ以外のケースでは現行の 5G コアでは提供されていないなんらかのソリューションの利用が必要となる。
5.1.6.5.1. ソリューション例：セカンダリ認証の利用

図 5.1.3 5G セカンダリ認証概略
5G セカンダリ認証は、通常の UE⇔5GC 間を認証するためのプライマリ認証が成功した後に、UE と DN が運用する AAA サーバとの間での認証を実現可能とするための機能である。
エンドポイントが同機能を利用することにより、EP と DN AAA 間で任意の EAP 認証が実行可能であるため、当該 EAP 認証処理中にエンドポイント操作ユーザに対して適切な認証クレデ
ンシャルの提示を求めることで、ユーザとエンドポイントとを強力に連想付けることが可能となる。
29

5.1.6.5.2. IoT プラットフォーム運用者要考慮事項
IoT プラットフォーム運用者が 5.1.6.5.1 節に述べたようなソリューションを運用する場合、以下のような考慮が必要である。


エンドポイント操作ユーザ認証方式決定実装 EAP 方式決定

5.1.6.6. 識別・認証２：エンドポイントのセキュリティ技術による、ピアとサービスの安全な認証は可能か
課題：エンドポイントのセキュリティ技術はピアおよびサービスを安全に認証することができるのか
ここで言うようなエンドポイントのセキュリティ技術によるピア/サービスの安全な認証を扱う場合、それらのエンドポイントがどのような形態でピア/サービスと通信するのかということを考慮しなければならない。
IoT において一般的に用いられる形態は以下の 2 種類に大別できる (図 5.1.4)。
1.

サーバ経由間接通信


2.

EP 間の通信は一旦中継サーバを経由した上で目的 EP へ届けられるローカル NW 経由直接通信
EP 間の通信は WiFi / Bluetooth / Zigbee 等のローカル NW を介して直接実施される

中央サーバ

中継サーバ

EP1

EP1

EP2

EP3

EP4

中継サーバ

EP2

EP3

間接通信型

直接通信型

図 5.1.4 典型的エンドポイント間通信形態
1.の中継サーバ経由間接通信を採用した IoT 規格の代表例は OneM2M[22]である。また、AWSや Azure 等のクラウド・サービス・プロバイダが提供する IoT サービスもクラウド上のサービスを介してエンドポイント間通信を実現する方式を基本としている。
2.の直接通信型サービスを採用した IoT 規格の代表例は IETF ACE[23]である。また、米Alphabet 傘下の Nest Labs が開発した規格である Weave[24]では主として直接通信型でのエンドポイント間通信がサポートされている。
30

エンドポイントとピア/サービスとの間での安全な認証を実現するための仕組として、5G が提供しているセカンダリ認証と AKMA という 2 つの方式が利用可能と考えられる。
5.1.6.6.1. セカンダリ認証
セカンダリ認証を用いることで、図 5.1.3 に示されている通りエンドポイントである UE とク
ラウド上の DN (データ・ネットワーク)上に存在する AAA サーバとの間での任意の EAP 機構を用いた安全な認証を実現することが可能である。
さらに、OneM2M のようなサーバ経由間接通信型の IoT プラットフォームでは、当該 AAA サーバが中央サーバないし中継サーバに対する PEP / PDP の役割を果たすことで、サービスに対するアクセス制御ポリシに基づく安全なアクセス可否判断を一元管理することが可能となる。
5.1.6.6.2. AKMA
AKMA (Authentication and Key Management for Application Functions)は、4G 以前から存在する GBA (Generic Bootstrapping Architecture)の 5G 向け拡張として 3GPP SA3 によって標準化作業が行われている機能である。

HSS

Zh

AV+GUSS

Dz
SLF

Zn

②

BSF

①

UE

NAF

Ua

Ub

③

図 5.1.5 GBA における UE⇔NAF 間鍵共有方式概要
4G 以前における AKMA 同等品である GBA における UE と NAF (Network Access Function)との間での秘密鍵共有手法を図 5.1.に示した。UE は BSF (Bootstrapping Function)との間で 4G
AKA に基づく認証を行なうことで新たな共有鍵を生成し、NAF は BSF からその新たに生成された共有鍵の提供を受けることで UE と NAF との間での鍵共有に成功する。
5G では図示された HSS や BSF 等の役割を果たす 5G コア部分の機能が 4G からは大幅に変更されているため、図 5.1.とは異なるアーキテクチャとなる可能性があるものの、同等の機能が
31

AKMA として提供される予定であるため、同機能を用いることでエンドポイントとピア/サービスとの間での安全な認証が実現できる。サービス側では中央サーバによる中央集権的機能を持たない直接通信型の IoT プラットフォームに適した形態である。
セカンダリ認証では DN 上の AAA サービスが PEP/PDP の役割を果たすことで認証とアクセス管理とを同時に実現することができたが、AKMA では図 5.1.5 に示された GUSS (GBA User
Security Setting) を利用して NAF への共有鍵提供可否を BSF が判断することでアクセス管理を実現することが可能である。
5.1.6.6.3. IoT プラットフォーム運用者要考慮事項
IoT プラットフォーム運用者が提供する IoT プラットフォームにおけるエンドポイント間通信
形態に適したエンドポイント ⇔ピア/サービス間認証方式の実装検討が必要である。
5.1.6.7. 識別・認証３：デバイス・アイデンティティ解析/操作に対する防止方法
課題：デバイスのアイデンティティをタンパリングもしくは操作から保護することができるのか
IoT デバイスは物理的な保護が提供できない誰からでもアクセスできる開かれた場所に設置されることも想定されているため、そのようなデバイスに対しては分解等の物理的な手段で解析/操作が実施される可能性を否定できない。
GSM 以来の流れを受けた 3G、4G では携帯電話のネットワーク接続時認証に用いる秘密鍵 Kを耐タンパ性を備える IC カードに格納することでそのような物理的攻撃に対する耐性を実現していた。それを 5G では物理的攻撃への耐性を備えたストレージとして一般化したセキュア・ス
トレージという概念を導入している。
セキュア・ストレージは 5G セキュリティを定義した TS 33.501 5.2.4 節によって以下のような
5G ネットワーク・アクセスに利用する契約クレデンシャルの保存および処理に対する要件としてまとめられている。


契約クレデンシャルは耐タンパ・セキュア HW コンポーネントにより完全性保護契約クレデンシャル中の長期有効鍵(K)は耐タンパ・セキュア HW コンポーネントにより機密性保護

契約クレデンシャル中の長期有効鍵は耐タンパ・セキュア HW コンポーネント外に平文で持ち出せないこと

契約クレデンシャルを利用する認証アルゴリズムは耐タンパ・セキュア HW コンポー
ネント内でのみ実行

5.1.6.7.1. IoT プラットフォーム運用者要考慮事項
IoT プラットフォーム運用者が提供する IoT デバイスに関しても、独自のクレデンシャル情報の下で機器の管理・運用を行なう場合、5G と同様の物理的攻撃耐性を備えるストレージにて管理することが望ましい。そのようなストレージ実装方式としては以下の二つが選定候補となるだろう。
1.

SoC 提供機能利用

Cortex-M Trust Zone 等
32

2.

独立暗号認証デバイス利用

スマートカード

ATECC508/608 等

5.1.6.8. プライバシー1：EP のアイデンティティは非認証ユーザに対して披歴されるか？
課題：エンドポイントのアイデンティティは認可されていない利用者に披瀝されるのか
4G 以前では永続識別子によるトラッキング防止のため、基本的に IMSI の替わりとなるランダ
ム値 TMSI (Temporary Mobile Subscriber Identity) が用いられるように配慮されているが、一定の条件下で IMSI を平文で送信する場面が存在していたため、エンドポイントのアイデンティ
ティを披瀝する可能性が残されていた。
5G では SUPI を平文では送信せず、常にホームネットワーク公開鍵でランダム暗号化した形(SUCI (Subscription Concealed Identifier)) でのみ送信する形での運用が可能となったため、5Gレベルでのエンドポイントのアイデンティティが非認証ユーザに対して披瀝されない形での運用が実現できるように改善されている。
5.1.6.8.1. IoT プラットフォーム運用者要考慮事項
IoT プラットフォームにつながるエンドポイントやサービス等に 5G とは異なる独自アイデンティティの割当/利用を行なう場合、本課題解決のためには 5G が実施しているものと同様の配慮
を IoT プラットフォーム運用者が考慮することが必要となる。
1.

アイデンティティの送信は常に TLS 等の安全な暗号通信下でのみ実施

2.

アイデンティティの平文での通信が必要な場合には上記した 5G 方式同等の保護策を適用

5.1.6.9. プライバシー２：EP ないし IoT サービスから放出されるデータを位置情報等のエンド・ユーザ属性に連想付けることは可能か？
課題：エンドポイントもしくは IoT サービスから放出されるデータは、物理的なエンド・
ユーザの属性 (位置、行動、ないし、睡眠中/覚醒中のような状態)を示唆ないし直接的に提示するか
ネットワーク全区間でデータに対する安全な機密性/完全性保護が適用されていることを保証することによりこのような状況の防止は実現可能である。5G における機密性/完全性保護アルゴ
リズムは以下のように定義されている。


機密性保護
1.

NEA0


2.

非暗号化 (鍵ストリーム≡0 と平文との XOR 演算)

128-NEA1
Lund University の T. Johansson と P. Ekdahl により考案されたストリーム暗号
SNOW 3G

3.

128-NEA2

4.

CTR モード 128bit AES

128-NEA333

16 ステージ LFSR ( Linear Feedback Shift Register) 構成ストリーム暗号 ZUC

完全性保護
1.

NIA0


2.

128-NIA1


3.

SNOW 3G により 32bit MAC を生成

128-NIA2
4.

非完全性保護 (メッセージ≡0 に対して 32bit MAC を生成)

CMAC モード 128bit により 32bit MAC を生成

128-NIA3ZUC により 32bit MAC を生成

図 5.1.6 5G コア概念図
本課題を解決するためには機密性/完全性ともにオプション 2.以上のアルゴリズムを用いなければならない。なお、これらの保護が適用されるのは 5G 内部のみであるため、ユーザ・プレーンの通信は UE から UPF までしか保護されない点に注意が必要である(図 5.1.6)。
5.1.6.9.1. IoT プラットフォーム運用者要考慮事項
前節で説明したように、UPF から N6 IF を介して接続される外部データ・ネットワーク(DN)との間の通信には IoT プラットフォーム運用者によって別途保護が講じられる必要がある。そのような保護を与える実現オプションとして以下を例示する。
UE⇔DN 間での E2E セキュア・セッション構築
IPsec, TLS 等による34

5G 提供保護機能は無用に同上 /w 5G 補助

セカンダリ認証 or AKMA で UE⇔DN が共有する共通鍵ベース IKE or TLS HS

UPF⇔DN 間通信保護



UPF⇔DN 間にセキュア・セッションを構築


SSH Port Forwarding 等

UPF＆DN を物理的に近接配備

エッジコンピューティング的方向性

5.1.6.10. プライバシー３：暗号文からなんらかのパターンが観察できないことが保証できるように十分安全な形で機密性/完全性保護が適用されているか？
課題：暗号文に存在するパターンが観察できないほど十分な機密性と完全性を備えた暗号化方式が用いられているか
5.1.6.9 節で説明した 5G ネットワークで定義されている 2.〜4.の機密性保護アルゴリズムない
しその同等品をネットワーク全体で提供することで解決可能。
5.1.6.10.1. IoT プラットフォーム運用者要考慮事項
5.1.6.9.1 節に同じ
5.1.6.11. プライバシー４：データをセキュアにするために用いられるセキュリティ鍵およびセキュリティ・アルゴリズムは新しくすることができるか
課題：データをセキュアにするために用いられるセキュリティ鍵およびセキュリティ・
アルゴリズムは新しくすることができるか
5.1.6.11.1. セキュリティ鍵更新
本件に関しては 3GPP SA3 において研究課題 LTKUP として議論されているが、現時点では以下の２方式をソリューション候補としている旨が TR 33.935-010 に述べられている。
1.

Diffe-Hellman based Key agreement over SIM OTA

2.

Multiple sets of parameters on the USIM

5.1.6.11.2. セキュリティ・アルゴリズム更新
前述の通り、3GPP SA3 では現在時点で性格の異なる複数の機密性/完全性保護アルゴリズムを定義している。


完全性: NIA1〜NIA3



機密性: NEA1〜NEA3

3G の時点からこれまでにアルゴリズムの追加/変更作業は何回か実施されていることから、
3GPP において今後必要に応じてアルゴリズムを更新することは問題なく実施可能と判断できる。
5.1.6.11.3. IoT プラットフォーム運用者要考慮事項
IoT プラットフォーム運用者が自身のプラットフォーム独自の暗号鍵/アルゴリズムを用いているのであれば、それらの更新に対して同様の配慮が必要である。
5.1.6.12. セキュリティ 1：プロジェクト開始時点から製品/サービスに対してセキュリティ最良実
35

践が組み込まれているか？
課題：セキュリティ最良実践はプロジェクト開始時から製品およびサービスに対して組
み込まれているか5G の策定主体である 3GPP では通信事業者によって用いられるネットワーク製品のセキュリ
ティ保証を実現するための取組として SCAS/SECAM と呼ばれる活動が存在している。
SCAS および SECAM ではそれぞれ以下のような作業が行なわれている。


SCAS


3GPP ネットワーク製品の特徴および同製品に対する脅威モデルを検討し、ネットワ
ーク製品のセキュリティ保証実現のための方法論を検討



SECAM


ネットワーク製品毎の SCAS 策定



ネットワーク製品セキュリティおよびネットワーク製品開発とネットワーク製品ライ
フサイクル管理に関するコンプライアンスの評価

これらの作業を通じて 3GPP では 5G コア・ネットワーク内部で用いられる製品が開発過程を通じて最良のセキュリティ実践を組み込まれたものとなるようにとの配慮がなされていると考えられるだろう。
5.1.6.12.1. IoT プラットフォーム運用者要考慮事項
自 身 の IoT プ ラ ッ ト フ ォ ー ム で 用 い ら れ る 製 品 お よ び サ ー ビ ス に 対 し て も 3GPP のSCAS/SECAM と同等の配慮が必要である。
5.1.7. 3GPP における関連作業項目概要
5.1.7.1. AKMA
AKMA に関する研究項目において承認目的で SA#86 会合に送付された TR 33.835-200 が承認され、同研究項目は完了となった。今後は TR 33.835-200 に記された結論に基づく必須化作業(TS 化) が開始される予定であり、作業項目名は“Authentication and key management for
applications based on 3GPP credential in 5G” [8]となった。承認された TR の結論に基づき作成される TS の目的は以下となっている。
Specify security architecture enhancements for 5G system to support AKMASpecify AKMA authentication proceduresSpecify AKMA key management proceduresSpecify the security related interfaces and corresponding protocols
5.1.7.2. LTKUPLTKUP に関する研究項目においては 2019 年 4 月にほぼ骨子レベルの TR 33.935 草稿が作成された段階である
5.1.7.3. SCAS
SCAS は 2012/12/20〜2013/12/20 に 3GPP SA3 によって実施された研究課題項目であり、3GPP ネットワーク製品の特徴および同製品に対する脅威モデルを検討し、ネットワーク製品のセキュリティ保証実現のための方法論候補である以下の 2 種類に対する分析が行なわれた。
36

1.

Common Criteria (ISO 15408)準拠

2. 独自方式


対象製品を評価する上で必要と考えられる特徴/機能の完全なリストを作成し、脅威分析結果に基づくセキュリティ要件との適合性を評価

ネットワーク製品(クラス)毎に SCAS (Security Assurance Specification)を作成

結論としては 2.の独自方式を採用するが、評価過程では CC が定める方法論を適宜流用することとなっている。
5.1.7.4. SECAM
SECAM が担当するタスクは以下の二つである。


セキュリティ要件および試験仕様である SCAS の策定



ネットワーク製品セキュリティ評価およびベンダのネットワーク製品開発とネットワーク
製品ライフサイクル管理に関するコンプライアンス評価

SECAM 認定主体と呼ばれる主体が認定および統治・維持を担当することで 3GPP 活動を補助することとされているが、SECAM 認定主体は現行では GSM Association (GSMA)のみである。
SECAM 認定主体は以下に対する要件および手続きを定義することとなっている。


ベンダ・ネットワーク製品およびネットワーク製品ライフサイクル管理プロセス認定

試験ラボ (ベンダ所有ないし第三者) 認定



紛争解決

5.1.8. 5GMF 白書「5G ユースケースにおけるセキュリティ 第 1.1 版」における課題解決可能性
本節では 2021 年度以降に 3GPP で行なわれている検討活動に基づいて課題解決の可能性について報告する。
後述するが 3GPP 活動には
1.

もうすぐ現時点での最新版となるリリース 18 に関するもの

2.

まもなく正式な検討が始まるリリース 19 に関するものの二つが該当する。
5.1.8.1. 可用性 1：複数オペレータ企業間ローミング・セキュリティ
課題: IoT エンドポイントがネットワーク境界をまたがって移動する際に、如何にして複数のモバ
イルオペレーターが同一レベルのネットワーク・セキュリティを提供できるのか？
解決策 1: 3GPP リリース 18 によって提供される FS PIN Sec と呼ばれる機能が本課題に対する解決策として利用可能である。FS PIN Sec の“PIN”とは Personal IoT Network を意味しており、そのようなローカルに構築される IoT 環境に対する付加機能として、ゲートウェー機能ないし/および管理機能を提供する 3GPP UE を組み込むことで、ローカル環境から外部環境へ安全な通信を可能とする枠組が実現される。3GPP リリース 18 で提供される同枠組を用いることで伝統的セルラ・システム同等のセキュリティ・レベルでの運用が実現可能となる。

37

図 5.1.7 FS PIN Sec 概要
解決策 2: 3GPP リリース 18 によって Study on Security of Edge Computing phase 2 と呼ばれる拡張 Edge computing 機能が提供されるため、同機能を用いることで複数オペレータ間での同一レベルでのローミング・セキュリティが実現可能となる。

図 5.1.8 Study on Security of Edge Computing phase 2 手続き概要
解決策 3: 3GPP リリース 18 によって FS_eNPN_Ph2 (Non Public Network Phase2)と呼ばれる
拡張 NPN 機能が提供されるため、同機能を用いることで複数オペレータ間での同一レベルでのローミング・セキュリティが実現可能となる。
38

図 5.1.9 ホスティング NW 提供ローカル化サービス利用例
5.1.8.2. 可用性 2：キャピラリ・エンドポイントへの信頼フォワード
課題: 如何にしてゲートウェイ・エンドポイントに通信を依拠するキャピラリ・エンドポイントに対してネットワークの信頼をフォワードすることが可能となるのか？
解決策: 5.1.8.1 節で説明した 3GPP リリース 18 によって提供される FS PIN Sec と呼ばれる機能が本課題に対する解決策としても利用可能である。FS_PIN では、ローカルに構築された IoT
環境に対する付加機能として、ゲートウェー機能ないし/および管理機能を提供する 3GPP UE を
組み込むことで、ローカルな環境から外部環境へ安全な通信を可能とする環境が実現されるが、同機能はキャピラリ・エンドポイントへの信頼フォワード機能としても有効活用可能である。
5.1.8.3. 可用性 3：セキュアな通信環境における軽量エンドポイントの電力制約対策
課題: 如何にしてセキュアな通信環境を用いることができるように軽量エンドポイントの電力制限を回避できるのか？
解決策: 5.1.8.1 節で説明した 3GPP リリース 18 によって提供される FS PIN Sec と呼ばれる機能が本課題に対する解決策としても利用可能である。FS PIN Sec では、ローカルに構築された IoT
環境に対する付加機能として、ゲートウェー機能ないし/および管理機能を提供する 3GPP UE を
組み込むことで、ローカルな環境から外部環境へ安全な通信を可能とする環境が実現されるが、同機能は軽量エンドポイントの電力制約としても有効活用可能である
5.1.8.4. 識別・認証 1：エンドポイント操作ユーザと当該 EP アイデンティティとの強力な連想付
可能？
課題：エンドポイントを操作する利用者をエンドポイントのアイデンティティに対して強力に連想付けることは可能なのか
39

5.1.8.5. 識別・認証 2：サービスとピアはエンド・ユーザのアイデンティティを検証することでEP のアイデンティティをも検証可能か？
課題：エンド・ユーザのアイデンティティを検証することでサービスないしピアがエンドポイン
トを検証することは可能か？
5.1.8.6. 識別・認証 3：エンドポイントのセキュリティ技術による、ピアとサービスの安全な認証は可能か
課題：エンドポイントのセキュリティ技術はピアおよびサービスを安全に認証することができるのか？
5.1.8.7. 識別・認証 4：悪意あるサービスとピアによる正規サービス・ピアへのなりすまし
課題：悪意サービスおよびピアによる正規サービスおよびピアへなりすますことは可能か？
5.1.8.8. 識別・認証 5：EP およびネットワークはどのようにして IoT サービスが EP へのアクセスを許容されていることを保証可能か
課題: エンドポイントおよびネットワークはどのようにして IoT サービスがエンドポイントへのアクセスを許容されていることを保証可能か？
解決策: 以上 5 件の識別・認証問題に対する解決策としては 3GPP リリース 18 によって提供される FS Resident で WWC (Wireline / Wireless Convergence)、LAN-5G 統合、小屋内基地局に対するセキュリティ拡張機能が提供される。同機能は CPN (Customer Premises Network)、eRG(Evolved Residential Gateway)、PRAS (Premises Radio Access Station)等の HW により訪問者
等の実利用者のアイデンティティによる連想付けが可能となっていることから、これらの課題に対する解決策として利用可能である。

図 5.1.10 FS Resident 概要
5.1.8.9. 識別・認証 6: エンドポイントおよびネットワークによるアクセス許可された IoT サ

40

ービスの確認方法
課題: エンドポイントおよびネットワークはどのようにして IoT サービスがエンドポイントへのアクセスを許容されていることを保証可能か？
5.1.8.9 節の課題に関しては 3GPP リリース 18 における新規対策可能機能は見受けられなかったため、利用可能な対策はリリース 17 以前の機能のみとなっている。
5.1.8.10. プライバシー1：エンドポイントのアイデンティティの非認可利用者への開示防止
課題:エンドポイントのアイデンティティは認可されていない利用者に披瀝されるのか
5.1.8.11. プライバシー2；エンドポイントないし IoT サービスの一意識別子によるエンド・ユー
ザないしエンドポイントの監視/トラッキングは可能か
5.1.8.12. プライバシー3：エンドポイントないし IoT サービスから放出されるデータを位置情報
等のエンド・ユーザ属性に連想付けることは可能か？
5.1.8.13. プライバシー4：暗号文からなんらかのパターンが観察できないことが保証できるように十分安全な形で機密性/完全性保護が適用されているか？
5.1.8.14. プライバシー5：エンドポイントないし IoT サービスからの物理エンド・ユーザ情報の漏洩
5.1.8.15. プライバシー6：IoT サービスないし製品における PII 保存・利用に対するエンド・ユーザによる制御は可能か？
5.1.8.16. プライバシー7：データをセキュアにするために用いられるセキュリティ鍵およびセキュリティ・アルゴリズムは新しくすることができるか
5.1.8.10 節から 5.1.8.16 節までの 7 件の課題に関しては 3GPP リリース 18 によって提供される
FS_UC3S_Ph2 において検討中の利用者合意関連データの取得・通知・破棄に対する統合された
フレームワークを用いることで対策が行なえる可能性がある。同統合フレームワークによって対策できない項目に関して利用可能な対策はリリース 17 以前の機能のみとなっている。
5.1.8.17. セキュリティ
セキュリティ関連課題に関しては


第 1 課題：セキュリティ最良実践はプロジェクト開始時から製品およびサービスに対して組み込まれているかという課題に対する既存対策が存在

それ以外の課題に関してはセキュリティ関連課題サービス主体が自身のアプリケーション／サービスを開発・運用する際に実施すべき項目であるため、5G としてなんらかの貢献が可能な状況にはないと考えられるという状況であり、これらに対して対策を提供できるリリース 18 における新規機能は見出せな
かった。

41

3GPP リリース 18 関連動向

図 5.1. 11 リリース 18 タイムライン
実のところリリース 18 に関する検討活動はまだ完了していない。図 5.1.11 に示されている通り、リリース 18 の最終フリーズ時期は 2024 年第 2 四半期末となっている。そのため、2024 年
第 2 四半期末までは 3GPP の中で検討活動が続けられる可能性がある。
以上のことから本節では 2023 年度に SA WG3 で続けられているリリース 18 関係検討活動状
況に関する最新状況を報告する。
まず、3GPP においては
1.

コア・ネットワーク＆ターミナル (CT)2.

ラジオ・アクセス・ネットワーク (RAN)

3.

サービス&システム様相 (SA)という三つの技術仕様策定グループが存在し、それぞれのグループはさらに専門的な技術策定メンバーから成るサブ・グループに分けられることになっている3。
CT, RAN, SA の技術仕様策定グループは 3 ヶ月に 1 回召集される全体会合において議論することにより、そこで検討された技術仕様が承認されていくという構成が採られている。
本書執筆時点では 2023 年 9 月 11 日～15 日にかけて開催された 3GPPSA#101 が直近の SA 全体会合であるため、ここでは同会合においてどのような議論がなされどのように仕様策定が行なわれたかについて説明する。
5.1.9.1. 3GPPSA#101 会合における SA WG3 関連動向
本書では IoT におけるセキュリティ関連動向を調査しているため、本節でも SA WG3 において検討活動が行なわれている多数のプロジェクトの中から IoT との関連性が深いプロジェクトにおける技術動向を見ていく。
ここで改めてリリース 18 における IoT 関連プロジェクトをまとめると表 5.1.3 の通りとなる。
3

たとえばセキュリティ&プライバシーに関する技術策定を担当するのが SA WG3 といった要領
42

表 5.1.3 SA WG3 IoT 関連ワークプラン一覧
最新 Tdoc

検討状況

FS PIN Sec

3GPP TR 33.882 V18.0.1 (2023-07)

5 月実施の SA WG3 会合でほぼ完成

FS Resident

3GPP TR 33.887 V18.0.1 (2023-06)

8/10 メールで SA3#112 会合にて必該当ワークプラン

須作業を終結可能という宣言あり
FS_eNPN_Ph2

3GPP TR 33.858 V18.0.1 (2023-06)

SA3#111 会合にて TR33.858 草稿が承認された旨の宣言あり
ただし、その後、以下の新たな問題が．発生
・Procedure for Security of NSWO support in SNPN
using CH with AAA server via 5GC
・Resolve one Editor’s Note in the procedure fortrusted non-3GPP access

FS_EDGE_Ph2

3GPP TR 33.739 V1.0.0 (2023-09)

・EDGE TR 草稿の電子承認
・TS 33.558 および TS33.501 へのEdge 関連 CR の電子メール承認

FS_UC3S_Ph2

3GPP TR 33.896 V18.0.1 (2023-06)

5/30～6/2 のメールで SA3#111 会合にて必須作業が承認されたという宣言あり

まとめると、FS PIN Sec, FS Resident, FS_UC3S_Ph2 の 3 ワークプランは概ね順調に作業が進められていると考えられる。しかしながら、


FS_eNPN_Ph2 は SA3#111 会合にて TR 草稿が承認された旨の宣言ありと書かれている
ものの、2 件の作業が未完となっていた。



FS_EDGE_Ph2 は EDGE TR 草稿の電子承認および TS 33.558 および TS33.501 へのEdge 関連 CR の電子メール承認が実施された。

ということで 3GPPSA#101 会合における上記 5 件の Tdoc は 5 日間の会期のなかですべて承認を得ることに成功し、FS_EDGE_Ph2 のバージョンも他と並んで V18 となったことから、IoT プロジェクトは 3GPP リリース 18 における最終期限である 2024 年 3 月には完成させる可能性が高くなったと考えている。
5.1.9.2. 3GPPSA#101 会合における新規項目まとめ
本節では表 5.1.3 に示した 5 個のワークプランについて 3GPPSA#101 会合において新たに付け加えられた内容を示すことで、2023 年 3 月期からどのような機能が追加されたのかをまとめる。
5.1.9.2.1. FS PIN Sec
FS PIN Sec について、2023 年 3 月時点では
1.

主要問題#1 PINE 向け認証および認可方式
43

2.

主要問題#2 PINE ケーパビリティ向け認可方式の二つが課題となっており、それぞれの主要問題に対するソリューションのうちどの候補を選択するかのみが課題であると考えていたのだが、2023 年 4 月に主要問題#2 への新規ソリューションが提案され、それが UDM4を用いる等の具体性を備えるという優位性を持つ有望なソリューシ
ョンであると感じられた。
しかし、3GPPSA#101 会合の結論では、主要問題#1 に対して『PINE の認証は PIN によって5GC との通信なしで実施され、PEGC によって、もしくは PIN からアクセス可能な認証サーバ
によって実施される』という記述のみとなっており、主要問題#1 については必須化作業も必要なしとされている。
一方、主要問題#2 については審議時間の関係等の理由で 3GPPSA#101 会合では承認に至らなかった。前述の通り、SA WG3 が SA 全体会合で承認を受ける機会は 2023 年 12 月開催の3GPPSA#102 会合と 2024 年 3 月開催の 3GPPSA#103 会合の 2 回が残されているので、主要問
題#2 についても十分な審議が行なえることが期待される。
5.1.9.2.2. FS_5WWC_Ph2_Sec
FS_5WWC_Ph2_Sec について、2023 年 2 月時点で 5 件の主要問題および 13 件のソリューシ
ョンがまとめられており、2023 年 2 月に実施された SA WG3#110 会合において承認された内容がそのまま 2023 年 5 月に実施された SA#100 会合で承認された。そのため、結果的に
FS_5WWC_Ph2_Sec は 2023 年 3 月時点と同じとなったことから、2023 年 3 月より新しい追加
機能は存在していない。
5.1.9.2.3. FS_eNPN_Ph2
FS_eNPN_Ph2 については、主要問題#1 SNPN への非 3GPP アクセス、そして主要問題#2 ホスティング・ネットワークへの UE アクセス時認証の 2 件が課題となっていたが、前者に対しては 11 件、後者に対しては 6 件のソリューションが提示されていたため、2023 年 3 月時点では
FS_eNPN_Ph2 はほぼ完成の域に達していたのだが、その後、主要問題#1 に関する複数の未解決問題が発生したため、WG SA3 では 4 月にアドホック会合を開催した上で 6 月の定例会合で以下に記す対策をまとめ、その結果として SNPN で必要となる新規アクセス方式すべてをカバーできる環境を以下の通り実現できた。
1.

SNPN への非信頼 N3GPP (Non-3GPP) アクセス可能化のために：(ア) すべての鍵生成 EAP メソッドのサポート(イ) オンボーディングのサポート(ウ) 匿名 SUCI (Subscription Concealed Identifier) 利用のサポート

2.

SNPN への信頼 N3GPP アクセス可能化のために：(ア) すべての鍵生成 EAP メソッドのサポート(イ) 匿名 SUCI 利用のサポート(ウ) オンボーディングのサポート

3.

SNPN への N5CW デバイス (Non-5G-Capable over WLAN) アクセス可能化のために：

Unified Data Management。5GC における加入者データ、移動機在圏情報、セッション情報
等を格納および情報提供を行なう機器
444

(ア) すべての鍵生成 EAP メソッドのサポート(イ) 匿名 SUCI 利用のサポート(SUCI 構成方法が 3GPP 定義とは異なっており、かつ EAP
メソッドがプライバシーを保証している場合)(ウ) SNPN Id (PLMN Id and NID) が NAI により運ばれる(エ) クレデンシャルホルダーがプライマリ認証に AAA サーバを利用(オ) クレデンシャルホルダーがプライマリ認証に AUSF および UDM を利用
4.

SNPN への NSWO (Non-Seamless WLAN Offload) サポート(ア) 匿名 SUCI 利用のサポート(SUCI 構成方法が 3GPP 定義とは異なっており、かつ EAP
メソッドがプライバシーを保証している場合)(イ) AUSF/UDM を持つ SNPN 向け NSWO サポートのためにソリューション#9 を選択①

あらゆる鍵生成 EAP 方式の利用が可能な SNPN での NSWO サポートを提供(ウ) 匿名 SUCI のケースで UDM がどのように認証方式を選択するかは必須化作業で特定(エ) CH (Credential Holder) と AUSF/UDM を用いる SNPN で NSWO をサポートする
ために、ソリューション#14 を選択①

CH AUSF/UDM (Authentication Server Function / Unified Data Management)を用いるあらゆる鍵生成 EAP 方式の利用が可能な SNPN での NSWO サポート(オ) SNPN クレデンシャルを CH AAA から取得する SNPN で NSWO をサポートするた
めに、ソリューション#15 を選択①

CH AAA (Authentication Authorization Accounting サーバ) から取得されたSNPN クレデンシャルを利用する NSWO をサポート

5.1.9.2.4. FS_EDGE_Ph2
FS_EDGE_Ph2 については、Edge コンピューティング向け 5G システム拡張関連の主要問題
である#1.1 と#1.2、そして、Edge アプリケーション有効化向け拡張アーキテクチャ関連の主要問
題#2.1～#2.7 が特定されている。
1.

主要問題#1.1(ア) VPLMN 内 EHE へのアクセスのために PDU セッションがローカル・トラフィック・
ルーティングをサポートすることをどうすれば承認できるか

2.

主要問題#1.2(ア) VPLMN 内 V-EASDF による EAS 発見手続きのセキュリティ

1.

主要問題#2.1(ア) ECS/EES による EEC/UE の認証および認可

2.

主要問題#2.2(ア) EEC および ECS/EES 間の認証機構選択3.

主要問題#2.3(ア) V-ECS および H-ECS 間認証および認可方式

4.

主要問題#2.4(ア) EDGE10 インタフェースに対するトランスポート・セキュリティ

5.

主要問題#2.545

(ア) AC および EEC 間認証および認可方式
6.

主要問題#2.6(ア) 複数 EES 間認可方式

7.

主要問題#2.7(ア) EEC 提供情報検証

これら 9 件の主要問題のうち、2023 年 4 月以降に提示されたのは主要問題#2.7 のみであるが同主要問題は 3GPPSA#101 では合意できなかったため、同主要問題に対するソリューションが確定するのは 2023 年 12 月の 3GPPSA#102 以降となる。
5.1.9.2.5. FS_UC3S_Ph2
FS_UC3S_Ph2 については、4 件の主要問題が提示されている。
1.

eNA (enablers for Network Automation) におけるローミング・ケース向けユーザ合意

2.

NTN (Non-Terrestrial Network) 向けユーザ合意

3.

データ取得・通知・破棄に関するユーザ合意向け統一されたフレームワーク策定

4.

ユーザ合意強制に関するガイダンス
これら 4 件の主要問題のうち、主要問題#1 は肯定的な結論を提示しつつ、基本的には関連する PLMN が決定すべきとされ、主要問題#2 および#3 は必須仕様策定なしとされている。主要問題#4 は結論が提示されていないため、FS_EDGE_Ph2 同様、結果が提示されるのは 2023 年
12 月の 3GPPSA#102 以降ということになる。
5.1.10. 3GPP リリース 19 関連動向
本節ではリリース 19 に関する動向をまとめておく。
5.1.10.1. リリース 19 初動向
2023 年 8 月下旬、3GPP ウェブサイトに初めて Rel-19 ページが登場した。
活動期間としては 2023 年末から 2025 年末までとなっており、新型コロナ以降 F2F 会合の実施が難しくなったリリース 17 以降と比較すると大幅なスピードアップが実現されたことになる。

46

図 5.1. 12 リリース 19 タイムラインおよびコンテンツ
2023 年 12 月に実施される全体会合において Rel-19 コンテンツが確定される予定となっており、そのための作業は RAN1, RAN2/3/4, SA, CT の各グループによって実施される。
まだ未確定ではあるが 8 月 9 日に公開された『Work Plan 3GPP R-19 version August 9th 2023』
を以下に示す(表 5.1.4)。
表 5.1.4 Work Plan 3GPP R-19 version August 9th 2023

表 5.1.4 に盛り込まれたワークプランから IoT に関連性がありそうなものを挙げると以下のよ
うになる。
47

1. Study on Ambient power-enabled Internet of Things
2. Study on Interconnect of SNPN
3. Edge Computing for Industrial Scenarios
4. NPN security considerations
5. Lawful Interception Rel-19
ただしリリース 19 のコンテンツが確定するのは前述の通り 2023 12 月全体会合となるので、IoT 関連項目を特定できるのはもう少し先の話となると思われる。
5.1.10.2. 3GPP WG SA3 によるリリース 19 向けセキュリティ関連動向
5.1.10 節の最後に紹介するのは 2023 年 11 月 27 日～28 日にかけてオンライン会合で実施された
3GPP WG SA3 によるリリース 19 向けセキュリティ機能検討状況である。
表 5.1.5 リリース 19 向けセキュリティ機能全貌

5.1.10 節に記述した通り、2023 年 12 月に実施される全体会合向け Rel-19 コンテンツは RAN1,
RAN2/3/4, SA, CT によって作成されているところであるが、いよいよ 3GPP WG SA3 でもリリ48

ース 19 のセキュリティに関する検討が本格的に開始されたことが明らかとなった。
同会合には 68 件の寄書が寄せられ、その中で取り下げられた寄書 4 件を除くすべてが検討された結果、25 件の寄書が承認ないし合意されている(表 5.1.5)。また、表 5.1.5 に記載された寄書の種類は以下の通りとなっている。
議題

議論

新規研究項目

新規作業項目

1件

26 件

39 件

3件

以下では表 5.1.5 で検討されたワークプラン項目の中で IoT に関連があると考えられる項目について概要を説明する。
1.

Study of ACME for Automated Certificate Management in SBA
5G SBA (Service Based Architecture) では SBA コンポーネントと関連する NF (Network

Function) の通信を、証明書により安全化する方式を採用しているが、いわゆる CNE (Cloud
Native Environment) を利用して複数ベンダから提供される NF (Network Function) を展開し、さらには独立した CA (Certification Authority) から安全通信用証明書提供を受ける環境が存在するため、そのような環境で人手による証明書管理を行なうは事実上不可能となる。
リリース 18 では SBA 向け証明書管理方式として CMPv2 が採用されているが、上述したように CNE 環境に対応するには力不足気味となったため、より新しい証明書管理方式として ACME
(Automated Certificate Management Environment) と CMPv2 とを混合可能とする証明書管理方式を実現することが必須となっている。
2.

Discussion on security for PLMN hosting an NPN
PLMN による NPN ホスティングを同 PLMN のセキュリティを危殆化させることなく実現可能とする方式が 5G システムには必要であるとの要件が与えられており、WG SA3 では
PLMN が顧客敷地内に専用 NF (Network Function) を含む NPN をホストする場合のセキュ
リティに関する研究が必要であるとの提案が行なわれる予定

3.

Distributed Authentication for Non-Public Networks (NPNs)
NPN の現在状況としては共通鍵ベースの中央集権型セキュリティアーキテクチャとなっているが、これを分散型認証アーキテクチャへと変更するために、中央集権型ではないインフラネッ
トワークにユーザを収容することを可能にしなければならない。そのために必要となるのは NPN
向け分散型認証の実現であり、5G システムはデバイス向け PKI 認証を開始しようとしている
4.

Study on Security Aspects of Enhancement of Support for Edge Computing in 5GC —phase 3
5G で EDGE コンピューティングを実現する際に必要とされるセキュリティ要件の洗い出しおよび潜在的セキュリティ対策の評価を実施することが必要
5.1.11. ユースケース IoT セキュリティまとめ
国内外の IoT セキュリティ関連文書を調査し、GSMA の文書を軸とした課題抽出、5G で検討すべき課題の抽出を 2020 年度に第 1.0 版として作成してから、その後 2021 年から 2023 年に渡って追加の調査・検討結果を以下に示す。

49

5.1.11.1. 5GMF 白書「5G ユースケースにおけるセキュリティ第 1.0 版」
2020 年度に実施した検討活動における方向性を大きくまとめると、5G で新たに追加された


ネットワーク・スライシング機能

セカンダリ認証機能

プライバシー考慮機能を活用することで IoT セキュリティ課題を解決できる可能性があることが判る。
5.1.11.2. 2021 年度から 2023 年度までの追加調査検討結果
3 年間に渡り実施した検討活動における方向性を大きくまとめると、5G で新たに追加された


拡張サービス・ベースド・アーキテクチャ機能

拡張エッジコンピューティング機能

拡張 NPN (非公衆ネットワーク)機能

3GPP サービスへのユーザ合意取得関連拡張機能



FS PIN Sec5機能

ワイアライン／ワイアレス・コンバージェンス拡張、固定 LAN と 5GLAN 統合拡張、小屋内基地局拡張を提供する FS Resident 機能

拡張エッジコンピューティング機能

SBA (サービス・ベースド・アーキテクチャ)での自動証明書管理機能



NPN (非公衆ネットワーク) 向け分散認証機能



拡張エッジコンピューティング_Ph3 機能を活用することで IoT セキュリティ課題を解決できる可能性があることが判る。

FS PIN Sec の“PIN”は Personal IoT Network を意味し、個人ないし小規模企業が運用する
IoT ネットワークに関するセキュリティを実現するための機能を示す語彙50

55.2. ユースケース Connected Vehicle セキュリティ
5.2.1. 概要
5G 時代に実現するサービスのひとつとして、ネットワークへ接続する機能を備えた自動車が、他の車両や信号等の交通インフラといった様々な対象とつながる、Connected Vehicle が注目されている。Connected Vehicle により、交通の高度化や、セーフティ、新しいサービスが創出されることが期待される。Connected Vehicle においては、インフォテイメントやセーフティなど、様々な分野に関して、新たなサービスの創出や発展が見込まれている。その一方、つながることにより、従来は想定されなかった脅威が現実のものとなり、その対策としてセキュリティに留意する
ことが重要となる。
こうした状況を受け、2018 年 7 月、5GMF の企画委員会の配下に、セキュリティ検討 AdHocが設置され、一年間の準備期間を経て、2019 年 7 月に、セキュリティ調査研究委員会が設置された。その活動目的は、5G 時代に想定されるサービスのセキュリティに関する検討組織の立ち上げに向けて、IoT、Connected Vehicle、および Fintech の各分野を対象とした調査と検討を通じて、
セキュリティ課題を抽出することであり、2020 年 7 月にこれらの調査結果をまとめた 5GMF 白
書「5G ユースケースにおけるセキュリティ 第 1.0 版」を公開した。本報告は、第 1.0 版の公開
後、Connected Vehicle 分野における調査活動の最新状況を第 1.1 版として反映したものである。
具体的には、Connected Vehicle において実現される各種サービスに対するセキュリティの課題を整理し、5G で検討すべきセキュリティ要件を明確化する（図 5.2.1）。以下、本章の構成を示す。本節にて全体概要を、5.2.2 節において、Connected Vehicle のセキュリティに関連する標準化団体、業界団体の標準文書やガイドラインを調査した結果をまとめ、各文書の関係を整理する。
また、5.2.3 節においては、5.2.2 節の各種団体で整理されたセキュリティ要件を踏まえ、5G ネッ
トワークを用いて Connected Vehicle を実現する幾つかの技術要素に着目し、そのセキュリティ
課題を整理する。

51

図 5.2.1 本報告書の検討プロセス
5.2.2. Connected Vehicle セキュリティに関連する標準
5.2.2.1. UNECE/WP.29
国連欧州経済委員会(UNECE)配下の国連自動車基準調和世界フォーラム(WP.29)の ITS/AD（自動運転分科会）において、Task Force on Cyber security and OTA(Over The Air)が設立され、2016 年 12 月より活動を開始している。
サイバーセキュリティ及びデータ保護に対するガイドラインが規定されている。本ガイドライン
では、表 5.2.1 に示す通り、一般原則に加えて、パーソナルデータに対するデータ保護、機能安
全やフェールセーフ等のセーフティ、不正アクセスや盗聴、データ改ざんを防止するセキュリテ
ィに対する、ハイレベルな要求条件を規定している[1] (2016)。また、上記の中でも特にサイバーセキュリティとソフトウェアアップデートに焦点を充てた検討がなされ、以降の 2 節がRegulation 案の位置づけでガイドラインとしてまとめられている(2018,2019 改訂)。

52

表 5.2.1 サイバーセキュリティ及びデータ保護に対するガイドラインの概要

5.2.2.1.1. Proposal for a Recommendation on Cyber Security [2]前者のガイドラインでは、クルマの製造業者と対象とし、クルマあるいはネットワークやクラウドも含むシステム全体に対するセキュリティの基本方針、脅威とその対策、さらに、開発、製品化、製品終了時の各フェーズでのセキュリティ管理の手法等を規定している。このなかで、補遺 A は、サイバーセキュリティに対する国連における Regulation 案が記載されている（図5.2.2 参照）。
ここでは、3 章の基本方針と 4 章の脅威について概説する。3 章の基本方針では、経営トップ層によるガバナンス、サプライチェーン、多層防御の考え方、攻撃に対する防御・検知・分析機
能やセキュリティ評価など一般的な指針が網羅的に規定されている（表 5.2.2 サイバーセキュ
リティ勧告の基本指針）。また、脅威に関しては、クルマの構成要素を意識した分類がなされている（表 5.2.3 参照及び表 5.2.4～表 5.2.9）。特にソフトウェアの更新や外部との接続性に関する脅威は、クルマを意識したものとなっている。この中で、通信・ネットワークの関連性がある
項目としては、通信チャネルや外部接続性に対する脅威が相当する（表 5.2.5、表 5.2.8 参照）。これらの対策としては、秘匿、認証・認可、改ざん防止、否認防止等の一般的なセキュリ
ティ対策が規定されている。

53

図 5.2.2 サイバーセキュリティ勧告の目次
表 5.2.2 サイバーセキュリティ勧告の基本指針

表 5.2.3 クルマに対する脅威表 5.2.4 バックエンドサービスに対する脅威

54

表 5.2.5 通信チャネルに対する脅威表 5.2.6 ソフトウェア更新手続きに対する脅威表 5.2.7 意図しない人間の行動に対する脅威表 5.2.8 外部接続性に対する脅威表 5.2.9 十分に保護、強化しない場合に悪用される脆弱性

55

5.2.2.1.2. Recommendation on Software Updates of the Task Force on Cyber Security andOver-the-air issues [3]
クルマの電子化が進むにつれて、利用されているソフトウェアの更新の重要性が増し、新たな機能の付加、性能の改善、不備の修正などソフトウェアを更新する必要性が増してきている。このためサイバーセキュリティタスクフォース(TFCS)において、クルマ製造業者を対象として、
ソフトウェア更新のためのガイダンスと、Regulation について検討を行っている。
本構成を図 5.2.3 に示す。本文では、ソフトウェア更新の手順および、セーフティとセキュリ
ティに関する要求条件、更新されるソフトウェアの識別に関するガイダンスが規定されている。
一方、補遺においては、ソフトウェア更新およびクルマ製造業者によって定義される専用の識別子(RXSWIN)のための Regulation 案が規定されている。
ここで、5 章はセーフティおよびセキュリティ要件を規定しており、そのうちセキュリティ要件は、表 5.2.10 のとおり、更新するソフトウェアに対する改ざんや、更新処理自体に対する攻撃を防止できることとなっている。またこれらの要件が確保できていることをオーソリティが確認できる能力や、オーソリティが確認する際に必要となる情報（ドキュメント）を規定している。
本 Regulation の検討に呼応して、国内では、ソフトウェア更新（一部サイバーセキュリティ
要件を含む）の実施に関する国内法令（道路運送車両法第 99 条の３（特定改造））の整備が2019 年 5 月に完了している（施行は 1 年 5 か月後） [4]

図 5.2.3 ソフトウェア更新のためのガイドラインの目次

56

表 5.2.10

ソフトウェア更新のセキュリティ要件

5.2.2.1.3. UNR155[5], UNR156[6]WP.29 の ITS/AD（自動運転分科会）において、UNR155 ”Uniform provisions concerning theapproval of vehicles with regards to cyber security and cyber security management system”、及び UNR156”Uniform provisions concerning the approval of vehicles with regards tosoftware update and software updates management system”が制定された(2020.06)。いずれも、
自動車 OEM およびサプライヤに対して、サイバーセキュリティ及びソフトウェアアップデートの適切さを担保するための業務管理システムを確保することが要求される。
5.2.2.1.3.1. UNR155
UNR155 の構成と概要を図 5.2.4 に示す。UNR155 では、自動車 OEM およびサプライヤに対して、開発フェーズ、製造フェーズ、運用フェーズからなる製品ライフサイクル全般を通じて、サイバーセキュリティ管理システム（CSMS）に基づく、セキュリティプロセス構築とセキュリテ
ィ対策の実施を義務づけており、この CSMS 適合に基づく車両の型式認証の申請の枠組みを規定している。本 UNR155 7 節においては具体的な CSMS に関する要件、CSMS の枠組みを用いて開発・運用される車に対するサイバーセキュリティの要件、さらには、その報告に関する要件が規定されている。上記 CSMS を実践する際に必要なプロセスとして、以下が規定されている。
・組織がサイバーセキュリティを管理するプロセス、・車に対するリスクを識別するプロセス、・識別されたリスクを分類し、評価するプロセス、・識別されたリスクが適切に管理されているかを検証するプロセス、・リスク評価が最新であることを検証するプロセス、・車に対する脅威、脆弱性、サイバー攻撃に対して、監視及び検知、対応するプロセス
・また、新たな脅威に対して、対策が有効であることを確認するプロセス
・サイバー攻撃やその試みを分析するデータが提供されるプロセス
また、Annex 5 に CSMS を実践するために必要となるサイバーセキュリティの脅威とそれに対応する対策例が記載されている。

57

5.2.2.1.3.2. UNR156
UNR156 の構成と概要を図 5.2.5 に示す。UNR156 では、車両に搭載された ECU（Electronic
Control Unit）のソフトウェアを安全にアップデートすることを目的として、プロセス認可と車両の型式認可に必要な要件が一般仕様として規定されている。特に 7 節においては、ソフトウェ
アアップデート管理システム(SUMS: Software Update Management System)を実践する際に必要な 12 のプロセス、特定の車両に対してソフトウェア更新を行う際に記録・保存すべき情報、ソフトウェアアップデートに対するセキュリティ対策、OTA を含むソフトウェアアップデートにおける要件が規定されている。ここで、ソフトウェアアップデート管理システム(SUMS: Software
Update Management System)を実践する際のプロセスとしては、例えば、初期および更新された
ソフトウェアバージョンに関する情報、および型式承認されたシステムに関連するハードウェア
コンポーネントを一意に識別できるプロセスや、車両メーカーがソフトウェアアップデートの対
象車両を特定できるプロセス、ソフトウェアアップデートが型式承認済みシステムに影響を与えるかどうかを評価、識別、記録するプロセスなどである。

図 5.2.4 UNR 155 の構成と概要

58

図 5.2.5 UNR 156 の構成と概要
5.2.2.2. ISO TC 22 (Road vehicles)
ISO/TC22 では、2021 年に ISO/SAE21414（Road vehicles — Cybersecurity engineering）
を策定した。本規格は、クルマのライフサイクル全般、すなわち、エンジニアリング（例：コン
セプト、設計、開発）、生産、運用、保守、および廃止措置全体を通して、クルマ、その構成要
素およびインタフェースのサイバーセキュリティリスク管理の要件を規定している。また、ステークホルダー間でサイバーセキュリティリスクを伝達・管理するためのプロセスと共通言語のフレームワークを定義している。プロセスを定義することで攻撃が成功する可能性を削減、損失を削減でき、絶えず変化する脅威に対する明確な対策を提供できる。グローバルな業界全体で一貫性を確保し、意思決定を促進できる。本規格は、WP29 のサイバーセキュリティ基準から引用される規格となる [7]。
本規格の規定項目を図 5.2.6 にまた、その全体構成を図 5.2.7 に示す。本規格の構成は [8]に要約されている。その内容は以下の通りである。
6 章のリスク管理手法では、リスク管理を行うために必要な定義、および、資産分析、脅威分
析、リスク評価を実施する際の要件を定義している、８章の開発プロセスでは、クルマの企画段
階から開発完了までに、必要なサイバーセキュリティ活動の要件を定義している。特に、コンセ
プト、システム、ハードウェア、ソフトウェアのクルマ特有の水平分業に対応している、9 章では、生産、運用、破棄では、開発完了から破棄に至るまで必要なサイバーセキュリティ活動の要件を定義している。脆弱性情報の収集、インシデント対応、インシデント対策、破棄時の要件が含まれる。10 章のサイバーセキュリティ管理では、クルマのライフサイクルに関連するサイバ
ーセキュリティ管理要件、組織のサイバーセキュリティ戦略を確立するための組織固有のルー
ル、プロセスの要件を定義している。
ここで、開発プロセス時のサイバーセキュリティ活動の概要を記す（図 5.2.8 参照）。本プロ
セスでは機能安全の標準 ISO26262 で規定されたセーフティに関するトリプル V プロセスを参考にしている。トリプルとはシステム、ソフトウェア、ハードウェアの 3 つの構成要素を対象と
している。
59

一方、本規格は、サイバーセキュリティ活動の要件やプロセスの定義、方法論に関する規格であり、以下の内容は含まない。
・具体的なサイバーセキュリティ技術やソリューションの適用
・具体的な改善施策に関する要件の包含
・通信システムのための要件の包含・バックオフィスのための要件の規定
・EV 充電のための要件の規定
・自動運転車固有の要件の規定
以上、ISO/SAE 21434 は、設計、開発、運用、破棄のすべてのプロセスでのサイバーセキュリ
ティ管理が規定されている点が特徴である。

図 5.2.6 ISO/SAE21434 の目次と概要

図 5.2.7 ISO/SAE21434 の構成

60

図 5.2.8 開発プロセス時のサイバーセキュリティ活動の概要
5.2.2.3. ISO TC204（Intelligent Transport Systems）
ITS に関する標準化を対象とする委員会であり、交通に関する情報、通信、および制御システ
ムの標準化を対象とする [9]。ISO TC204/WG16（通信分科会）は、ITS における通信の規格を対象としている [10]。このなかで、セキュリティに関する規格として、ISO21217 [11]および
ISO16461 [12]がある。また、ISO TC204/WG18（協調システム分科会）におけるセキュリティに関する規格としては、ISO/TS21177 [13]、ISO/TS21185 [14]がある（表 5.2.11）。
表 5.2.11

TC204 におけるセキュリティ関連の規格

ISO21217 は、ITS の通信ネットワークを目的として設計された ITS 基地局ユニットと呼ばれるノードの通信参照アーキテクチャを規定している。ITS の通信ノード間の様々な ISO ネット
ワーク上で 1 対 1 の通信をするための通信ノードを規定している。本規格での規定内容を図5.2.9 に、規定する参照アーキテクチャを図 5.2.10 に示す。セキュリティの構成においては、侵入検知のためのファイアウォール、認証、認可プロファイル管理、SMIB におけるネットワーク
セキュリティ管理、ハードウェアセキュリティモジュール（HSM）の構成要素を規定している。

61

図 5.2.9 ISO21217 の目次

図 5.2.10

ISO21217 CALM reference architecture

ISO16461 は、プローブ車両情報サービスのプライバシーに関するサービス提供者が考慮すべき評価基準を規定している（図 5.2.11 参照）。ISO16461 は、PVS（Prove Vehicle Systems）
に関する規格で、以下の内容を規定している。ここで、PVS とは、個々のクルマからプローブ
データを集めて、統計的な処理を行うことにより、様々な利用者に対して有益な情報を提供する
ためのシステムである。本規格では以下の内容を規定している。
・PVS でデータの完全性の保護と匿名性を確保するためのアーキテクチャ
・PVS のデータ完全性保護とプライバーを確保するためのセキュリティ評価基準や要件・プローブデータの適切で匿名化されたデータの生成と扱いに関する要件

62

図 5.2.11 ISO16461 の目次
ISO/TS21177 は、ITS 基地局に関して、トラステッドデバイス間で、認証、秘匿、データ完全性を確保するための仕様である（図 5.2.13 参照）。図 5.2.12 に示す通り、2 つのデバイスが協調し信頼関係を構築し、保護された情報を双方向に交換する。ISO 21217 の定義に基づき、ITS
基地局(ITS-S)機能の物理実装である ITS 基地局ユニット(ITS-SU)は、トラステッドデバイスである。さらに、ITS 基地局ユニットは、ITS 内部ネットワークで相互接続される複数の ITS 基地
局通信ユニット(ITS-SCU)から構成される。すなわち、ITS 基地局通信ユニットは、トラステッ
ドデバイスの最小単位となる（図 5.2.14 参照）。ここで、ITS 基地局は、クルマ内のネットワー
ク(IVN)や路側のネットワーク(IRN)からセキュアにデータにアクセスする必要がある（図5.2.15、図 5.2.16）。従って、以下の ITS アプリ間の信頼関係を確立するための ITU-S のセキュリティサービスを規定している。ITS アプリは、以下の 3 つのケースで信頼関係を確立する。
・ITS-SU 内の異なる ITS-SCU の ITS アプリ間・異なる ITS-SU の ITS-SCU 間の ITS アプリ間・ITS-SU とセンサーや制御ネットワーク（SCN)間
図 5.2.17 に示す通り、セキュアセッションが提供する TLS セキュリティプロトコルの上で、セキュリティアダプター層として、認証・認可、秘匿とプライバシー、データ完全性、否認防止のセキュリティサービスを ITS アプリに提供するサービスである。

図 5.2.12

TS21177 における基本構成

63

図 5.2.13

図 5.2.14

図 5.2.15

TS21177 の目次

ITS サービスの信頼性関係

ITS-SU が非標準な IRN と接続する例

64図 5.2.16

ITS-SU が非標準な IVN と接続する例

図 5.2.17

TS21177 における論理アーキテクチャ

ISO/TS21185 は、標準化されたトラステッドデバイス間の通信プロトコルに基づく ITS-S 通
信プロファイルを定義するための方法論について規定している（図 5.2.18 参照）。トラステッド
デバイス間で、異なる構成において、セキュアで低遅延での情報交換を可能とするプロファイルを規定する。

図 5.2.18

TS21185 の目次

655.2.2.4. ITS ForumITS 情報通信システムの普及促進を図るため、ITS 情報通信システムに関する研究開発及び標準化の調査研究、関係機関との連絡調整、情報の収集、啓発活動等を行うことを目的とする団体である。また、ITS を普及・促進するため、各種ガイドラインを策定し公開している。
Connected Vehicle のセキュリティに関わるものとしては、車車間・路車間通信情報におけるセキュリティガイドラインを規定した「ITS Forum RC-009 運転支援通信システムに関するセキュ
リティガイドライン」(2011) [15]と、本推進会議の高度化専門委員会セルラーシステム TG と
5GMF Connected Vehicle アドホック会合が共同で作成した「セルラー通信技術を用いた ITS・
自動運転の高度化に向けた課題調査報告書」(2019, 2021 改定) [16]がある。
5.2.2.4.1. ITS Forum RC-009 運転支援通信システムに関するセキュリティガイドライン
図 5.2.19 に上記ガイドラインの構成を示す。

図 5.2.29

ITS Forum RC-009 運転支援通信システムに関するセキュリティガイドライン

本ガイドラインの検討対象を図 5.2.20 に示す。本分析対象の車車間・路車間での通信部分であり、ブロードキャスト通信が対象である。ここでは、一般車両が偽の優先車両の情報を配信し、優先車両になりすます、偽の路側器から偽の情報を配信するなど、サービスに紐づいた脅威を想定し、そのセキュリティ対策を規定している。

66

図 5.2.20

ITS Forum RC-009 ガイドラインの検討対象

また、リスク分析結果の例を表 5.2.12 に示す。これらのリスク分析に基づく具体的なセキュリテ
ィ対策として、車車間、路車間の通信情報に対するメッセージ認証コードを用いたメッセージの真正性や、電子署名を用いた発信元の認証などの暗号メカニズムを規定している。
表 5.2.12

リスク分析結果の例

5.2.2.4.2. セルラー通信技術を用いた ITS・自動運転の高度化に向けた課題調査報告書
本報告書は、セルラーV2X を用いた ITS・自動運転の高度化に向けた課題を整理し、今後国内でセルラーV2X の有効性検証や課題の具体化・対応検討を加速化させることを目的としている。
67

本報告書のなかには、セルラーV2X における情報流通に関するセキュリティ・プライバシーの課題を整理している。
2019 年版においては、具体的には、V2X の 5 つのユースケース（１：衝突回避・緊急ブレー
キ、２：交差点通過支援・ジレンマゾーン回避/赤信号注意喚起、３：車線変更支援/ルート選定、
４：車両退避支援、５：経路再探索）について、送受される情報に関する課題を整理している（図5.2.21、図 5.2.22 参照）

図 5.2.21

図 5.2.22

情報流通の課題（情報入手）

情報流通の課題（受信車両での情報利用）

また、狭域通信（V 2V/V2I/V2P）および広域通信（V2N）に関し、前者は、PKI を用いたセキュリティ・プライバシー確保の可能性や課題について、後者は、無線区間の暗号化や TLS の利用可能性を踏まえたセキュリティ・プライバシーの課題について言及している。

68

5.2.2.5. ITU-T
ITU-T においては、Study Group 16（SG16: Multimedia）における課題 27（Vehicle gateway
platform for telecommunication/ITS services and applications）において Connected Vehicle の通信に関わる標準化を行っており、Study Group 17（SG17: Security）の課題 13（Security aspects
for Intelligent Transport System）において、Connected Vehicle やその通信システムに関わるセキュリティの標準化を行っている。本節では、SG17 課題 13 の活動状況と勧告化された文書の内容について説明する。特に、5GMF 白書「5G ユースケースにおけるセキュリティ 第 1.0 版」の公開以降、次節に示す通り Connected Vehicle に関して、非常に多岐にわたる勧告や勧告草案が作成されているが、ここでは、先出の UNR155 および UNR156 と密接に関係する X.1371 および X.1373、加えて、V2X 通信システムの包括的なセキュリティガイドラインと位置付けられる
X.1372 に焦点を当てその概要を示す。
5.2.2.5.1. SG17 課題 13 で作成された勧告文書、および、議論中のワークアイテム
表 5.2.13

勧告一覧に SG13 課題 13 において作成され、勧告として発行された文書を示す。
表 5.2.13

勧告番号

タイトル

X.1373

Securecapability

勧告一覧

概要
softwarefortransportation

update 車両に搭載された電子機器のソフトウェアを安intelligent 全に更新するための手順について規定
systemcommunication devices
X.1372forV2V （ Vehicle-to-Vehicle ）、 V2I （ Vehicle-to-

Vehicle-to-Everything (V2X)

Infrastructure ）、 V2D （ Vehicle-to-nomadic

communication systems

Devices）、V2P（Vehicle-to-Pedestrian）の通信

Security

guidelinesを対象としたセキュリティガイドライン。V2X 通
信の脅威（盗聴、パーソナル情報の漏洩、信用情報／センサー情報／アプリケーションの改ざん、
DoS 攻撃、デバイスハッキング、不正アクセス等の脅威を列挙し、これらに対応するためのセキュ
リティ要件と対策を提示している。
X.1374

Security requirements for

リモート・キーレス・エントリーや検査ツール等

external device with vehicle の車両に接続する外部機器のセキュリティ要件
access capabilityを規定した文書。外部機器接続によるセキュリテ
ィ上の脅威を列挙し、一般的なセキュリティ要件
とともに、ワイヤレス機器（Bluetooth、モバイル、
WiFi）、リモート・キーレス・エントリー、充電シ
ステムに対するセキュリティ要件を規定している。Approved on 2020-10-29

X.1375

Methodologies for intrusion

車両内のネットワーク（CAN 等）上での不正な振69

detection

systemonin-vehicle system

る舞いを検知する侵入検知システムの適用方法について規定する文書。標準的な侵入検知システ
ムのフレームワークや検知手順を示すとともに、ネットワーク上において脅威となる挙動（盗聴、なりすまし、不正コマンド送付、リプレイ攻撃、等）を示している。Approved on 2020-10-29

X.1371

Security

threatstoconnected vehicles

コネクテッド・カーにおけるセキュリティ上の脅
威を示すもので、他の ITS セキュリティ関連のリ
ファレンスとして用いられることを想定した文書。コネクテッド・カーのモデルを規定し、そのモデルにおけるセキュリティ上の脅威を列挙している。Approved on 2020-05-29

X.1376

Security-related

多くのコネクテッド・カーから収集したデータ

misbehaviour detection（Big Data）を解析し、その中からセキュリティ

mechanism based on bigに関連する不審な挙動を検知する仕組みについdata analysis for connectedて規定した文書。不審な挙動を検知する仕組みのvehicles

モデルを規定し、収集できるデータの種類と複数の検知方法について説明を行っている。
Approved on 2021-01-07

X.1383

Security requirements forV2X 通信で使われるデータを複数のタイプに分

categorized data in V2X

類し、各データタイプのセキュリティレベルを定

communication

義する文書。V2X で扱われるデータのライフサイ
クルについて説明し、データの種類（車両の状態、環境情報、車両制御、アプリケーションサービス
データ、機密データ、等）に対して、セキュリティレベル 1～3 に属するデータ例を提示している。
また、分類されたデータに対するセキュリティ要件を規定する。
Approved on 2023-03-03

X.1380

Security guidelines for

車両から得られるデータをクラウドに送付してcloud-based data recorders蓄積する EDR（Event Data Recorder）、DSSAD

in automotive environment（Data Storage System for Automated Driving）のセキュリティガイドライン。EDR、DSSAD の特徴から、セキュリティ上の脅威を明確にし、セキュリティ要件（セキュア・ブート、ログ、通信の暗号化、アクセス制御、等）を規定している。
また、セキュリティを考慮した実装方法についても規定している。Approved on 2023-03-03
70

X.1381

Security guideline for

イーサネットをベースとした車両内ネットワー

Ethernet-based in-vehicle

クのセキュリティガイドライン。車両向けイー

networks

サネットの説明を従来のネットワークとの比較
を含めて行い、セキュリティ上の脅威を明確にし、セキュリティ要件（機密性／完全性／可用性／真正性に関連する項目）を規定している。
また、セキュリティを考慮したイーサネットの実装についても規定している。Approved on
2023-03-03

X.1373rev

Secure software update

X.1373 の改訂版。UNECE WP29 での検討結果

capability for intelligentと、OEM ベンダーからの実装に関する意見の反transportation system

映を目的に改訂作業を行う。Target Date 2024.4

communication devices
X.1377

X.1382

X.1379

Guidelines for an intrusion

車内システムへの侵入を防御するための仕組み

prevention system forのフレームワークと攻撃の検知・防御方法を規connected vehicles

定する文書。Approved on 2022-10-14

Guidelines for sharing

コネクテッド・カーのためのセキュリティ脅威

security threat information

情報を共有するためのフレームワークと共有手

on connected vehicles

順を規定した文書。Approved on 2023-03-03

Security requirements for

V2I（Vehicle-to-Infrastructure）通信で利用さ

roadside units in intelligent

れる RSU（Road side unit）のセキュリティ要transportation systems

件を規定する文書。RSU の概要とセキュリティ
上の脅威を示し、ハードウェア、ファームウェ
ア／OS、アプリケーション、データセキュリテ
ィ要件を規定している。Approved in 2022-0714

表 5.2.14 に、SG13 課題 13 で議論中（2023 年 12 月現在）のワークアイテムを示す。
表 5.2.14

ワークアイテム一覧

識別名

タイトル

概要

X.itssec-5

Security guidelines for

車両がエッジコンピューティング機能を使う際のセキ

vehicular edgeュリティガイドライン。脅威分析を行うとともに、脅威

computingに対応するためのセキュリティ要件と 3 つのユースケースにおけるセキュリティ上の注意点を示している。
Target Date 2023.9

X.af-sec

Evaluation

自律走行車における顔画像を用いた匿名化技術の概要

methodologies forと、匿名化の成熟度を向上させるための評価手法を提71anonymization

供する。Target Date. 2026-09

techniques using face
images in autonomousvehicles
車両 ID を使用する電気自動車のプラグ＆チャージサ

X.evpnc-

Security guidelines forsecelectric vehicle plug and ービスのセキュリティ ガイドラインを簡単に説明す
charge (PnC) services る。このモデルに対する脅威を特定し、セキュリティ要using vehicle identity

件を提供する。Target Date. 2024-09(VID)
X.evtol-

Security guidelines for

都市部の航空モビリティ環境におけるコネクテッド電

secelectric vertical take-off

動垂直離着陸 （eVTOL）のセキュリティガイドライン

and landing (eVTOL)の標準化を目的とする。eVTOL システムの概要、セキ

vehicle in an urban air

ュリティ脅威分析、様々な接続性を備えた eVTOL シ

mobility environment

ステムのセキュリティ要件を提供する。Target Date.
2024-03

X.fod-sec

Security guidelines for

FoD とは、ユーザがオンラインで必要な機能を選択的

a feature on demandにダウンロードしてコネクテッド・カーにインストー(FoD) service in a

ルできるサブスクリプションベースのサービスを意味

connected vehicle

する。本勧告は FoD サービスにおけるセキュリティ脅

environment

威分析を提供し、加入者の認証などの緩和方法を含む
セキュリティ要件を規定する。さらに、本勧告は、セキュリティ要件を満たすための緩和方法の実装方法を提供する。
Target Date. 2026-09

X.idseEvaluation

本勧告草案は、IVIDS（車載侵入検知システム）をそ

methodology for in-の性能、有効性等の観点から評価するための方法論を

vehicle intrusion

提供する。本勧告で対象とする IVIDS は、主に勧告

detection systems

X.1375 で規定されているものである。Target Date.
2024-09

X.ota-sec

Implementation and

本勧告草案では、X.1373、X.1373rev、X.1371 に基evaluation of security

づき、OTA 更新機能に対するセキュ リティ脅威分析

functions to supportとセキュリティ要件を追加している。Target Date.

over-the-air (OTA)

2025-09

update capability inconnected vehicles
X.sup-

Supplement to X.1813 -X.1813 の補足 -URLLC 機能をサポートするセルラー

cv2x-sec

Security deployment

車々間通信 C-V2X サービ スのセキュリティ展開シナ

scenarios for cellular

リオ。さらに、本勧告草案では、X.1373、
72

vehicle -to-everything

X.1373rev、X.1371 に基づき、OTA 更新機能に対す(C-V2X) services

るセキュリティ脅威分析とセキュリティ要件を追加しsupporting ultra-ている。Target Date. 2024-09

reliable and low latency
communication(URLLC)

5.2.2.5.2. X.1371:Security threats to connected vehicles [17]
本勧告の構成と概要を図 5.2.23 に示す。本勧告は、コネクテッド・カーにおけるセキュリティ
上の脅威を示すもので、他の ITS セキュリティ関連のリファレンスとして用いられることを想定した文書である。6 節において、コネクテッド・カーのモデルを規定し（図 5.2.24 参照）、7節において、そのモデルにおけるセキュリティ上の脅威を列挙している。脅威については、Connected Vehicle や Connected Vehicle を含む全体のエコシステムに対する脅威、攻撃の対象
や動機、さらに、その脅威に関連する潜在的な脆弱性について列挙している。具体的な脅威については、バックエンドサーバ、通信チャネル、ソフトウェア更新、人による意図しない行為、外部との接続に分類されており、UNR155 との整合性を持たせている。また、Appendix では、脆弱性や脅威に対する攻撃手法の事例が列挙されているが、これらも、UNR155 を参照し再構成されており、UNR155 との整合性が確保されている。

図 5.2.23

X.1371 の構成と概要

73

図 5.2.24

Connected Vehicle の概念(vehicle ecosystem)

5.2.2.5.3. X.1373: Secure software update capability for intelligent transportation systemcommunication devices [18]
この勧告は、ITS（intelligent transportation system）通信機器を対象とした安全なソフトウェ
ア更新手順を提供することを目的としている。ソフトウェア更新の基本的なモデル、ソフトウェ
ア更新のセキュリティ制御、更新ソフトウェアモジュールの抽象データフォーマットの仕様も含まれている。

図 5.2.25

車両に組み込まれている基本的なモジュール（勧告文書より）

図 5.2.25 は、車両に組み込まれている ECU 等のモジュールと更新ソフトウェアを提供するサプ
ライヤとの接続形態を示している。更新ソフトウェアは、車両製造会社に渡され、そこから各車両に組み込まれたゲートウェイを介して更新が必要となる ECU 等の機器に送られることになる。

74

図 5.2.26

ソフトウェア更新プロセスのモデル

図 5.2.26 は、基本的なソフトウェア更新手順のモデルである。このモデルに従ってソフトウェア
更新手順の仕様とメッセージフォーマットが規定されている。
5.2.2.5.4. X.1372: Security guidelines for Vehicle-to-Everything (V2X) communication systems
この勧告は、V2X（Vehicle-to-Everything"）通信のセキュリティガイドラインとなっている。
V2X 通信には、V2V（Vehicle-to-Vehicle）、V2I（Vehicle-to-infrastructure）、V2D（Vehicle-tonomadic Devices）、V2P（Vehicle-to-Pedestrian）が含まれている。V2X のセキュリティ上の脅
威、セキュリティ要件、セキュリティ機能を具備した V2X 通信の実装について規定している。
脅威については、機密性、完全性、可用性、否認拒否、真正性、責任追跡性、認証の観点で分類されており、それぞれの項目について脅威を列挙している。

75

図 5.2.27

機密性に関する脅威

図 5.2.27 は、機密性に関する脅威を示しており、盗聴とパーソナル情報の漏洩が対象となっている。

図 5.2.28

完全性に関する脅威

図 5.2.28 は、完全性に関する脅威を示しており、経路メッセージの改ざん、資格情報の改ざん、センサー情報の改ざん、デバイス上のアプリケーションの改ざんが対象となっている。

76

図 5.2.29

可用性に関する脅威

図 5.2.29 は、可用性に関する脅威を示しており、V2X 通信チャネルに対する妨害／DDoS 攻撃、
OBU に対する DDoS 攻撃、タイミング攻撃、センサーのハッキングが対象となっている。

図 5.2.30

否認拒否に関する脅威

図 5.2.30 は、否認拒否に関する脅威を示しており、証明書データベースの改ざん、資格情報への不正アクセスが対象となっている。

77

図 5.2.31

真正性に関する脅威

図 5.2.31 は、真正性に関する脅威を示しており、経路テーブル／LDP（Local Dynamic Map）への改ざん攻撃、なりすまし攻撃、Sybil 攻撃（複数 ID 攻撃）、仮名解析攻撃、証明書データベースの改ざんが対象となっている。

図 5.2.32
責任追跡性に関する脅威

図 5.2.32 は、責任追跡性に関する脅威を示しており、デバイスの不正な複製、車両／RSU の不正な複製が対象となっている。
78

図 5.2.33

認証に関わる脅威

図 5.2.33 は、認証に関する脅威を示しており、車両内の安全性に変わる情報への不正アクセス、車両に組み込まれた機能への不正アクセスが対象となっている。
勧告では、上記の各項目に対応したセキュリティ要件が規定され、V2X 通信に関わるユースケー
スに対してどのセキュリティ要件への対応が必要となるかが示されている。また、セキュリティ
要件に沿った実装を行うための事例として、エンティティ認証とメッセージの機密性確保を目的とした暗号の利用、緊急情報のメッセージの完全性検証、隊列走行におけるエンティティ認証、
PKI の利用、の各ユースケースが示されている。
5.2.2.6. TTC（一般社団法人情報通信技術委員会）
TTC においては、セキュリティ専門委員会とコネクテッド・カー専門委員会において車両関連のセキュリティを取り扱っており、セキュリティ専門委員会の関係メンバーがコネクテッド・カー
専門委員会に参加し、連携した活動を行っている。本節では、コネクテッド・カー専門委員会で作成を行っている文書について説明する。
5.2.2.6.1. 自動車の遠隔更新技術の標準化動向と実用化課題
テクニカルレポートとして 2017 年 12 月に発行された文書で、この時点における各種団体でのソフトウェアの遠隔更新技術の検討状況、標準化文書の作成状況について説明が行われている。また、2019 年 10 月に、UNECE WP.29 の情報を追加するとともに、更新作業が行われ、第 2 版として発行された。本文書は、一般公開されており、TTC のホームページからダウンロード可能となっている。
車両に搭載された ECU 等のデバイスに搭載されたソフトウェアの更新の作業は、従来は作業車が診断ツールを車両に有線で接続して実施していた。近年、ネットワーク経由で遠隔から（専門79作業者を介することなく）ソフトウェア更新する遠隔ソフトウェア更新（OTA リプログラミング）が注目されており、本文書では、このソフトウェア更新のユースケースに着目し、国内外の政府機関、 学術団体、業界団体、NPO 等での、活動状況に関して調査を行っている。
OTAサーバ
セルラー回線(3G/LTEなど)
車載ネットワーク（CANなど）
TCU

ﾅﾋﾞ

ECU1

ECU2

HUD

G/W

OBDⅡ

CANなど

診断
ツール

図 5.2.34

リプログラミングの例（レポートより）（赤色：従来の有線リプログラミング、黄色：OTA リプログラミング）
調査対象とした関連団体は、以下の通りである。
・5GAA（5G Automotive Association）
・ACEA（欧州自動車工業会）
・SAE International（Society of Automotive Engineers）
・UNECE WP.29 GRVA TFCS・Bluetooth SIG
・IEEE 802・ISO TC22（Road vehicles）
・ISO TC204（Intelligent transport systems）
・ITS 情報通信システム推進会議（ITS 情報フォーラム）・ITU-T FG-VM（ITU-T Focus Group on Vehicular Multimedia）
・ITU-T SG16（Multimedia）
・ITU-T SG17（Security）
・oneM2M
・W3C
・Wi-Fi Alliance・第 5 世代モバイル推進フォーラム（5GMF）
・EVITA（E-safety vehicle intrusion protected applications）
・HIS（The Herstellerinitiative Software）
・TCG（Trusted Computing Group）

80

5.2.2.6.2. その他
コネクテッド・カー専門委員会では、新たに、自動運転のセキュリティに関わるレポート作成に着手することとした。これに関連して、2020 年 1 月 31 日に「自動運転に関するセキュリティ課
題」と題する勉強会を外部から講演者を招いて実施した。
5.2.2.7. GSMA
モバイル通信関連の業界団体である GSMA では、以下の IoT セキュリティガイドラインを作成
し、ホームページを通じて一般公開している。英語以外の言語にも翻訳されており、日本語版も存在する。


IoT Security Guidelines: Overview Document



IoT Security Guidelines for Service Ecosystems



IoT Security Guidelines for Endpoint Ecosystems



IoT Security Guidelines for Network Operators



IoT Security Assessment

GSMA では、IoT セキュリティガイドラインの一環として、Automotive IoT Security の取り組
みについて検討を開始したが、自動車業界との連携が難しかったことと、賛同者が集まらなかったため、本格的な取り組みへ移行せずに終了した。
GSMA の IoT セキュリティのプロジェクトは、上記の IoT セキュリティガイドラインの作成を含めて様々な取り組みを行っていたが、2020 年 3 月に、活動を中止することとなった。車関連の取組としては、eSIM の活動において、自動車における eSIM 活用の検討が行われており、新たなグループ設立の要否を検討している。
（2020 年 3 月時点）
また、GSMA では通信機器のセキュリティ認証フレームワークとして NESAS（Network
Equipment Security Scheme） [19]を構築している。NESAS は 3GPP の TS33 シリーズで規定される試験仕様（SCAS：Security Assurance Specifications）に基づく機器試験や、第 3 者監査などにより構成される。

図 5.2.35

GSMA

NESAS と 3GPP SCAS の関係

5G ネットワークのセキュリティ確保に向けて、GSMA は NESAS を欧州 ネットワーク情報セキ
ュリティ庁(ENISA)に提案中である [20]。これは、欧州委員会の 5G サイバーセキュリティ対策
81

「EU Toolbox」 [21]を補完するものであり、現在欧州各国は 5G ネットワークのセキュリティ対策の実装を進めているところである。
5.2.2.8.

自工会/部工会

一般社団法人自動車工業会（略称：自工会）及び一般社団法人日本自動車部品工業会（略称：部工会）は、自動車メーカーやサプライチェーンを構成する各社に求められる自動車産業固有のサ
イバーセキュリティリスクを考慮した、向こう 3 年の対策フレームワークや業界共通の自己評価基準を明示し、自動車産業全体のサイバーセキュリティ対策のレベルアップや対策レベルの効率的な点検を推進することを目的としたサイバーセキュリティガイドライン V2.1 を公開した(2023.09.01) [22]。
本ガイドラインでは、自動車産業に関わる各企業が達成する項目に基づき、最終到達点として目指す項目群であるレベル３、標準的な項目群のレベル２、最低限実施すべき項目群のレベル１にレベルを定義し、２４に分類したラベルに基づき、トータル 153 個のチェック項目を規定している（図 5.2.36、表 5.2.15 参照）。

図 5.2.36

自工会/部工会・サイバーセキュリティガイドラインで規定するセキュリティレベル82

表 5.2.15

要求事項と達成条件の例（一部の項目を抜粋）

ラ
ベ
ル

目的

要求事項

No.

レベ
ル

達成条件

達成基準

17
通
信
制
御

サーバー
等の重要
機器への
不正操作
による情
報漏洩、
改ざん、
システム
停止を防
ぐ

サイバー
攻 撃、
内部情報
漏えいを
防止 す
るため、
情 報シ
ステム・
情報機器
や不 正
な Web
サイ ト
への通信
制 御を
行ってい
ること

103

Lv2

インターネットと社内ネットワークとの 境界にファイアウォー
ルを設置し、通信 を制限している【規則】
・社内と社外のネットワーク通信を制限する仕組みを導入すること[導入場所]-社内外ネットワークの境界[制限する項目]-接続元および接続先の IP アドレス
-通信ポート

104

Lv2

ファイアウォー
ルのフィルタリ
ング設定 (通信の許可・遮断設定)を記録し、不要 な設定がない
か定期的に確認
している【規則】
・社内外ネットワーク通信のフィルタリ
ング設定を記録すること・定期的に不要なフィルタリング設定がないか確認すること・不要なフィルタリング設定を削除する
こと【記録する項目】
・申請者、接続元および接続先の IP ア
ドレス、通信方向、プロトコル、
ポート番号、利用用途、登録日、有効期
限【確認頻度】
・1 回/年

105

Lv2

リモートアクセスの ID を管理し、不要 な IDがないか定期的に確認している【規則】
・リモートアクセスの ID の発行・変更・削除は申請・承認制にすること
・定期的に不要な ID がないか確認する
こと
・不要な ID を削除すること【確認頻度】
・1 回/年

表 5.2.15 のように、分類の大項目として「通信制御」などの 24 個のラベルが定義され、中項目
は、「ファイアウォールの設置」など 153 個の機能が達成条件として定義され、小項目として規則や対象、確認の頻度など達成基準が規定されている。広義な観点で通信に関わるラベル（大項目）としては、「外部への接続状況の把握（14）」、「社内接続ルール(15)」、「通信制御(17)」、「「認証・認可(18)」、「不正アクセスの検知(23)」がある。ここで、括弧内の数字はラベルの番号を表す。
現在、自工会の Web サイトにて、各加盟企業に対してセルフチェックが求められている。
5.2.2.9. 各標準の関係
本節においては、5.2.2.1～5.2.2.8 節で紹介した各団体およびその活動を要約しその関係性を整理する（表 5.2.16）。
UNECE/WP.29 のサイバーセキュリティタスクフォースでは、クルマあるいはネットワークやクラウドも含むシステムのライフサイクル全般（開発、製品化、製品終了時）にわたるサイバー
セキュリティの基本方針、および、具体的なサービスの事例として、リモート環境でのソフトウェアアップデート(リモートリプログラミング、OTA)に関する手順および、セーフティとセキュリ
ティに関する要求条件、更新されるソフトウェアの識別に関するガイダンスとおよびその基本となる Regulation が規定されている。UNECE/WP.29 で規定されるサーバーセキュリティの基本
83

方針は、ISO/SAE 21434 を参照する形となっており、ISO/SAE 21434 は、ISO と SAE が共同開発を行っており、上記 UNECE/WP.29 の基本方針に従い、クルマのライフサイクル全般を通じて、
サイバーセキュリティリスク管理の要件、サイバーセキュリティリスクを伝達・管理するためのプロセスと共通言語のフレームワークを規定している。クルマの製造業者や、部品の供給業者（サプライヤ）は、ISO/SAE 21434 に準拠することにより、UNECE/WP.29 のサイバーセキュリティに関する Regulation に従っていることのエビデンスとなる。また、ソフトウェアアップデートについては、ISO/SAE 24089 が Regulation に従う標準の位置づけでとなるが、まだ検討が始まったばかりである。
TC204 は ITS に係る標準化団体であり特に、WG16（通信分科会）および/WG18（協調システ
ム分科会）において、ITS における基地局とクルマの間の通信の規格を対象としている。セキュリティに関しては、通信機器間で実現すべき認証、秘匿などのセキュリティ対策およびプローブ
情報のプライバシー保護に関する対策を規定している。
ITS Forum は、ITS 情報通信システムの普及促進を図るため、ITS 情報通信システムに関する研究開発及び標準化の調査研究、関係機関との連絡調整、情報の収集、啓発活動等を行うことを目的とする国内の団体であり、セキュリティに関しては、これまで、運転支援通信システムに関するガイドラインを策定している。
ITU-T では、SG16 課題 27 において Connected Vehicle の通信に関わる標準化 SG17 課題 13
において、Connected Vehicle やその通信システムに関わるセキュリティの標準化を行っている。
これまで、リモート環境でのセキュアなソフトウェアアップデートの手順や、V2X におけるセキュリティガイドラインなどの標準化を行っている。
TTC では、セキュリティ専門委員会とコネクテッド・カー専門委員会において車両関連のセキュリティを取り扱っており、セキュリティ専門委員会の関係メンバーがコネクテッド・カー専門委員会に参加し、連携した活動を行っている。
GSMA では、IoT セキュリティガイドラインの一環として、Automotive IoT Security の取り組みについて検討を開始したが、自動車業界との連携が難しかったことと、賛同者が集まらなかったため、本格的な取り組みへ移行せずに終了した。車関連の取組としては、eSIM の活動において、自動車における eSIM 活用の検討が行われており、新たなグループ設立の要否を検討している。
自工会、部工会では、自動車産業におけるサイバーセキュリティ対策フレームワークや自己評
価基準の検討を行っている。

84

表 5.2.166 各標準の関係
団体略称

組織説明（階層、関係など）

概要

UNECE/WP.29

国連(UN)/欧州経済委員会(ECE)

自動車の安全・環境基準の国際調和、政府

配下のによる自動車の認証の国際的な相互承認

国連自動車基準調和世界フォーなどの国際基準 (ラム(WP.29)
ISO TC22

国 際 標 準 化 機 構 (ISO) と 米 国
Society

2016 年 9 月より ISO と SAE が ISO/SAE

Automotive 21434 を共同開発 [7]ofEngineers(SAE) に よ る ジ ョ イ

車両サイバーセキュリティに関する国際

ント組織

標準
WP.29 国際基準で参照される見込み

ISO TC204

国際標準化機構(ISO)配下の技 ITS に係る国際標準を担当
自動運転に係る内容は ISO/SAE21434 が術委員会(TC204)

主導 [23]ITS Forum

ITS 情報通信システム推進会議

ITS 情報通信システムの普及促進目的とする国内の団体。ITS を普及・促進するため、各種ガイドラインを策定し公開。

ITU-T SG17

国際電気通信連合(ITU)電気通

電気通信に係る国際標準化

信標準化部門(T) 配下の研究グ

課題 13 で ITS セキュリティの標準化

ループ(SG17)
TTC

一般社団法人

情報通信技術委

日本国内の情報通信ネットワーク標準化
自動車関係のセキュリティについては、動員会(TTC)

向調査・報告を実施
GSMA

GSM アソシエーション

機器セキュリティ認証フレームワーク

移動体通信事業者や関連企業か

NESAS を構築 [24]らなる国際業界団体

自動車 IoT セキュリティについては現在
活動なし

自工会

部工会

日本自動車工業会（JAMA）

部工会とともに自動車産業におけるサイ

自動車を生産するメーカーで構

バーセキュリティ対策フレームワークや成される国内の業界団体

自己評価基準を検討

日本自動車部品工業会（JAPIA） 自工会とともに、自動車産業におけるサイ
自動車部品に関する国内の業界

バーセキュリティ対策フレームワークや団体

自己評価基準を検討

5.2.3. Connected Vehicle におけるセキュリティ
5.2.3.1. Connected Vehicle におけるセキュリティ要件
5.2.2 節においては、Connected Vehicle に関連する標準について整理を行い、各標準で規定して85

いる内容およびそれぞれの標準の関係を明確化し、Connected Vehicle に求められる共通のセキ
ュリティ要件を洗い出した。これらの Connected Vehicle の標準は、クルマやクルマ製造業者を起点に、クルマ内部のセキュリティ要件に加え、路側器やクラウドも含めたエコシステムにおけるセキュリティ要件も対象となっている。すなわち、クルマやクルマ製造業者を起点に、セキュリティの対策方針やセキュリティ管理のための方法論から、Connected Vehicle システムの構成要素である ITS 基地局間でのセキュアな通信サービスやプロトコルに至るまで、非常に広範囲にセキュリティ要件が検討されている。
一方、Connected Vehicle に関わるサービスは、自動走行支援、インフォテイメント、カーラ
イフサポート、エージェントなど様々なユースケースが想定され、これらのサービスのセキュリティを確保するためには、クルマやクルマ製造業者に加えて、Connected Vehicle に関わるサービスを実現するためのステークホルダー、すなわち、サービス事業者、クラウド事業者、通信事業者などに対するセキュリティ要件も考慮する必要がある。例えば、通信事業者に対しては、
ISO27011（ITU-T X.1051） [25]、また、クラウド事業者に対しては、ISO27017(ITU-T
X.1601) [26]への適合を考慮することにより通信あるいはクラウドサービスにおける安全性が保障される。
本章では、対象とする Connected Vehicle のユースケースを整理し、これらの安心・安全なサービスを実現するためのサービス要件を整理する。次に、In-Vehicle を含まないネットワークとして 5G を用いた場合を想定し、上記サービス要件を満たすための 5G ネットワークの機能を抽出する。さらに次章において、抽出した 5G のネットワーク機能に関するセキュリティの課題を整理する。
5.2.3.1.1. Connected Vehicle のユースケース概要
Connected Vehicle の普及に対しては、移動手段の効率化・高度化を達成することのみならず、
従来は自動車が直接的には関係しなかった様々な分野に対して、新たな産業やサービスを創出することにも、大きな期待が寄せられている。したがって、5G 時代に想定される Connected Vehicle
分野のセキュリティ課題を抽出する場合は、はじめに、その検討対象となる分野を明確化することが重要である。
本報告では、Connected Vehicle に関係して提供されるサービスの類型として、総務省主催の「Connected Car 社会の実現に向けた研究会」 [27]が取りまとめた 4 分野に注目して、以降の議論を進めることとする。以下に、その 4 分野を整理する。


セーフティ分野


道路状況や交通状況などを、車両や運転手に伝達し、必要に応じて警告を発したりする
ことにより、安全運転を支援するサービス。



カーライフサポート分野


車両の状態や位置、運転手の運転の特徴などの情報を外部に送信、分析することにより、車両や運転手の状況に合わせたサービスを提供する。



インフォテイメント分野


インターネットへ接続することにより、動画の視聴や VR（仮想現実）など、様々なエン86

ターテイメントを車内に提供するサービス。


エージェント分野


事故や災害などの緊急時に役立つサービス。

また、ここでは、一般性を損なわない範囲でユースケースを具体化してセキュリティ要件を明確化するためそれぞれのサービスにおいて、総務省の報告書「Connected Car 社会の実現に向けた研究会」において検討されているユースケースについて、セーフティ分野については、運転支援（安全運転
支援・自動運転支援・ドライバモニター・高齢ドライバーサポート）（UC-1 とする）を、カーラ
イフサポートについては、車両管理・運行管理・インフラ管理・自動車保険サービス（UC-2 とする）を、インフォテイメント分野については、ネット系エンタメサービス（UC-3 とする）
を、エージェント分野については、緊急通報・ロードアシスタントサービス（UC-4 とする）と対象とする。各ユースケースの通信要件や通信形態などは以下の通りである。

図 5.2.37

UC-1: 安全運転支援・自動運転支援・ドライバモニター・
高齢ドライバー支援サービスの概要 [27]87

図 5.2.38

UC-2: 車両管理・運行管理・インフラ管理・自動車保険サービスの概要 [27]図 5.2.39

図 5.2.40

UC-3: ネット系エンタメサービスの概要 [27]

緊急通報・ロードアシスタントサービスの概要 [27]88

（１）ネットワーク要件
ここでは、UC-1～UC-4 について、それぞれ求められるネットワークの要件を整理する（表 5.2.17 参照）。
表 5.2.177 各種ユースケースとネットワーク要件

UC-1 のダイナミックマップの地図情報、自動走行支援のための車両制御情報、あるいは、動画情報などのデータ量に関して表 5.2.18 に示す [28]。動画、静止画、ECU データいずれも、ネットワーク上を多量のデータが流れるため MEC などを利活用した効率的な転送技術が必要となる。
表 5.2.188 Connected Vehicle におけるサービスで転送されるデータ量

表 5.2.19 は、各種 V2X サービスにおけるネットワーク要件を表す。遅延についてはデータの授受に基づき自動的に運転制御される自動運転が１ms と低遅延に関して最も厳しい条件が要求される。また、遠隔運転については、人がリアルタイム操作性を損なわない程度の遅延処理として20ms 以下が要求される。さらに、表 5.2.20 は、インフォテイメント分野におけるコンテンツ89

視聴やオンラインゲームに対するネットワーク要件を表す。特に、マルチプレーヤによるオンラ
インゲームにおいては、7.5ms 以下の応答性が要求される。
表 5.2.199

表 5.2.20

V2X サービスにおけるネットワーク要件 [29]インフォテイメント分野

UC-3 でのネットワーク要件 [30]

その他、自動追い越しシステムでは、各メッセージ交換で約 10 ms 以下の応答性が必要とされる [31]。5G の URLLC における無線部分のネットワーク遅延は 1ms を想定しているが、上記のユースケースにおいては、エンド―エンドで 1ms～20ms 程度のリアルタイム応答性を実現する必要がある。このため、URLLC のセキュリティで検討される認証の高速化や MEC の利活用など 5G の機能を活用することにより上記のネットワーク要件を考慮する必要がある。
（２）セキュリティ要件
上述の Connected Vehicle サービスにおけるセキュリティ要件について考察する。ここでは、個別のユースケースの要件の考慮しつつ、ユースケース共通のセキュリティ要件を整理する。
まず、サービスレイヤでの下記のセキュリティ要件の明確化を目的として、クルマ、ネットワ
ーク、クラウド、そして、サービスアプリケーションを対象として、その脅威を整理する。
サービスレイヤでの脅威
サービス利用者のなりすまし90

サービスで利用されるデータへの不正アクセス
サービス上のデータの漏洩
サービス上のデータの改ざん
サービスへの DoS 攻撃
マルウェア感染
ここでは、上記のサービスレイヤでのセキュリティ脅威を踏まえ、サービスを構成するクルマ、
クラウド、ネットワークのシステム構成に対する各々セキュリティ要件を明確化し、その後、
5G ネットワークを想定した場合の着目すべきセキュリティ機能とそのセキュリティ課題を整理する。


なりすましによる不正なサービス利用
利用者が契約している Connected Vehicle に関するサービスを不正に利用することにより不当な利益をえる。事例としては、インフォテイメントサービスにおけるコンテンツ視聴やオンラインゲーム(UC-3)、交通事故情報などの緊急通報サービス（UC-4）などの不正な利用が想定される。これらの脅威は、クルマの利用者へのなりすましにより実現の可能性がある。
この対策として、サービスレベルの利用者の認証が必要となる。
 クラウド、クルマに蓄積されたデータを改ざん
Connected Vehicle サービスにおいて利用され、蓄積されるデータを不正にアクセスし、改ざんすることにより、不当な利益を得る、あるいは、他人に損害を与える。事例としては、自動車保険サービスの運転履歴を改ざんし、保険の料率を変更する（UC-2）、ダイナミックマップにおけるハザードマップを不正に改ざんに他のクルマに事故を誘発させる(UC-1)。車両管理（ソフトウェア更新）における脆弱性のあるソフトウェアや不正な処理を挿入したソフトウェアを更新させる(UC-2)。
これらの脅威は、クラウド、クルマに不正にアクセスして、データを改ざん、あるいは、ネッ
トワーク上の転送される関連データを改ざんすることにより実現の可能性がある。
この対策として、クラウドや車に蓄積されるデータや、ネットワーク上を流れるデータに対して改ざん検知コード（メッセージ認証子）を付与する方法がある。
 クラウド、クルマに蓄積されたデータ、ネットワーク上のデータを盗聴して不正入手
Connected Vehicle サービスで利用されるデータを不正にアクセスし、奪取する。あるいは、
ネットワーク上を転送されるデータを盗聴することにより、不当な利益を得る、あるいは、他人のプライバシーを侵害する。事例としては、ドライバーモニター(UC-1)や車両運行管理(UC-2)におけるクルマの移動情報を不正に入手する。これらの脅威は、クラウドや、クルマへの不正アク
セス、ネットワーク上のデータの盗聴により可能となる。
この対策として、クラウドやクルマに蓄積されるデータや、ネットワーク上を流れるデータを暗号化する手法がある。
91

 クラウド、クルマ、ネットワークに過負荷をかけて、サービス停止（DoS 攻撃）
Connected Vehicle サービスを実現するシステム（クラウド、クルマ、ネットワーク）に大量のトランザクション（処理）を発生させることにより、サービスを停止させる。すべてのユース
ケース（UC-1～UC-4）に対して、DoS 攻撃は想定されるが、サービス自体を停止される脅威と、特定のクルマのサービスを停止させる脅威など、攻撃者の狙いにより、攻撃対象が変わる。
この対策として、攻撃の対象となる通信路を監視して、DoS を検知し、該当トラフィックを破棄する手法がある。
 マルウェア感染、不正アクセスによるサービスへの攻撃
不正なプログラムをクラウド、クルマ、ネットワークのシステムに感染させ、動作させることにより、上記の攻撃につながるような攻撃者の意図する任意の動作をさせる可能性がある。また、クラウド、クルマに不正にアクセスすることによりシステムの構成や設定を変え、様々な攻撃が可能となる。
この対策として、マルウェアを検知する機能を導入する、あるいは、不正アクセスに対しては、アクセス管理を行う手法がある。
 クラウド、クルマが連携して動作するサービスの仕様や実装の不備による脆弱性に対する攻撃
Connected Vehicle サービスの UC-1～UC-4 に対して、各々のサービス仕様に対する不備や実装するユースケースを実現するハードウェア・ソフトウェアの実装の不備による脆弱性
が、悪用される、あるいは、設定ミスなど誤用の可能性がある。例えば、個人データに対す
るアクセス制限が不十分なため、利用者が、他の利用者のプライバシー情報を取得できる、
あるいは、サービス利用の履歴を変更できるなど脅威が想定される。
この対策として、ソフトウェア設計、開発プロセスにおいて、不正プログラムや仕様の不備を排除するための開発プロセスを導入する。
上記のセキュリティ要件に対して、WP29 のクルマに対するサイバーセキュリティにおける脅威との関係を表 5.2.21 に示す。上記の表では、各セキュリティ要件に対する WP29 Proposal fora Recommendation on Cyber Security の対応する節を記載している。WP29 では、これらの脅威に対する具体的な対策例を Annex A に規定する。

92

表 5.2.201 Connected Vehicle サービスのセキュリティ要件とWP29 で規定された脅威との関係

図 5.2.41

Connected Vehicle のシステム全体とその脅威、対応する標準の関係図

5.2.3.1.2. UC-3:インフォテイメント分野のディジタルコンテンツに関するセキュリティ課題
インフォテイメント分野のユースケースにおいては、動画、音声、ゲームなどのエンタメ情報が利用される。ディジタルコンテンツについては情報自体の扱いと、その配信方法が含まれる
が、付加価値の高いコンテンツが扱われるため、前者のディジタルコンテンツ自体に対して、コ
ンテンツの盗聴や不正コピーなどの不正利用に対するセキュリティ対策が課題となる。上記の課
題を解決するために、DRM 技術の利用が想定される。DRM 技術については、ネットワークに依存しないサービスレイヤの技術であり、後述の 5G とは独立しているため、本節においてその課題を整理する。
93

DRM は不正なディジタルコンテンツの複製、変更などの防止を目的として、インターネット
上でプレミアムデジタルコンテンツを配信するためのよく知られた技術である。DRM は暗号技術ではなく、デジタル権利管理システムの略である。 DRM の要点は、許可された人物/デバイ
スのディジタルコンテンツの使用規則を記述する。
前述の通り、DRM は WAN（LTE / 5G）/ WiFi などのベアラに依存しない。すなわち、DRM
はベアラの機能を使用しない。もちろん、コンテンツの所有者やプロバイダーがコピーを防止したい場合は、暗号化技術が使用される。 このような使用法は、許可された各人物/デバイスの各DRM スキームの「ライセンス」データで定義される。 DRM は多くの特許と方法で実現されているので、図 5.2.42 は概念のみを示す。

図 5.2.42

プレイバックのフロー

Google の Widevine DRM、Microsoft の PlayReady、Apple の FairPlay、Marlin Trusted
Management Org の Marlin など複数の DRM 規格が存在する。コンテンツプロバイダーやアグ
リゲーターは通常、サービスに 1 つの DRM テクノロジーを使用する。 すなわち、クライアン
トシステム（プレーヤー）がサービスに接続するために DRM をサポートする必要がある。 Car
OEM が複数のコンテンツサービスのサポートを希望する場合、Car OEM はいくつかの DRM
テクノロジーを実装する必要がある。
通常、DRM テクノロジーは、DRM ライセンサーとライセンス契約により提供される。 ライ
センス契約では、ライセンサーは、DRM で保護されたコンテンツ（DRM 処理されたコンテンツ）を処理/再生するために、RR および CR に従うようライセンシーに要求するケースがある。
RR (Robustness Rules)
RR はロバストネスルールの略である。 RR は、DRM 保護されたコンテンツプレーヤーとしてのクラッキングアクティビティを防止するためにはハードウェアとソフトウェアを準備する方法を記載している。 例えば 安全なメディアバスを使用することにより、復号化およびデコードされたビデオデータを処理し、ビデオデータを盗聴するためのデバッガーによるアクセスを防止する。
94

CR (Compliance Rules)
CR はコンプライアンスルールの略である。 CR は、データが DRM 保護されたコンテンツプレーヤーからモニターを含む他のデバイスに送信される場合のデータの処理方法を記載している。
HDCP は、HDMI および WiFi ディスプレイのコンテンツ保護技術として知られている（本技
術は「リンク保護」と呼ばれることもある）。 CR では、DRM 保護されたコンテンツプレーヤーに対して、リンク保護テクノロジーの機能が必要になる場合がある。
Production
DRM ライセンサーは、より強固な DRM スキームを実現するために、工場で各 DRM 保護された機器にデバイス固有の鍵を事前設定するようにライセンシーに依頼することがある。工場での主要な処理フローも RR で定義される。
Service
コンテンツホルダー/アグリゲーターが OEM に、RR / CR および再生品質を直接満たす方法を示すよう依頼する場合がある。 これは、CR / RR を満たすだけでは十分な OEM ではないことを意味する。
スマートフォンのようなモバイルデバイスの場合、DRM により管理されるコンテンツのオフラ
イン再生用のストリーミングとキャッシュなどの使用は非常に簡易になってきている。主なサー
ビスが昨今ではネット上で「ストリーミング」されているためである。ほとんどの DRM スキー
ムには認証スキームがあるが、ユーザ認証は含まれていないため、ユーザは DRM 機能を使用してサービスにログインし、デバイスをサービスに紐づける必要がある。
For Car
特にヘッドユニット（DRM による管理されるコンテンツのレシーバー）からバックヘッドのス
クリーンなどの AV 信号処理には、標準バスの使用が推奨される。それ以外の場合、各自動車
OEM は、コンテンツホルダー/アグリゲーターと独自のテクノロジーについて交渉する必要が生じる。
自動車 OEM は、どのユーザ認証方式を採用するかを考慮する必要がある。例えば、モバイルデバイスで用いられる ID /パスワードや SIM 認証システムを使用してサービスにログインできる。
5.2.3.1.3. Connected Vehicle における 5G セキュリティの検討対象
5G におけるセキュリティは、無線アクセス（RAN）およびコアネットワーク（CN）において、その仕様が 3GPP SA3 において検討されている。
本節では、前節のネットワーク要件を実現するための以下の 5G 機能について検討対象を明確化し、その 5G 機能に対して、前節で明確化したセキュリティ要件を踏まえ課題を整理する。
 トラストモデル
95

前節のユースケースにおいては、Connected Vehicle のサービスの利用者、サービス事業者、クルマ製造業者、ネットワーク事業者など異なる役割を持った様々なプレーヤが想定される。これらの 5G は、プレーヤがどのような信頼関係を構築するかを明確化する必要がある。
 Network Slicing
前節のユースケースにおいて、異なるネットワークの品質が要求される。5G においては、
ネットワークスライシングにより、5G の共通基盤上で、RAN および NC において、品質の異なるネットワークを複数提供可能である。この際、ネットワークスライシングにおいて、前節のセキュリティ要件を考慮した課題を明確化する必要がある。
 MEC
前節の高いスループットや低遅延を実現するためには、MEC（Mobile Edge Computing/Multiaccess Edge Computing）により、コンテンツのキャッシュによるネットワーク負荷の軽減、処理をエッジで行うことによる遅延の低減を実現できる。この際、MEC において前節のセキュリテ
ィ要件を考慮した課題を明確化する必要がある。
 C-V2X
走行支援などのユースケースを実現するためには、車車間、路車間などの多数の機器との通信を行う必要があり、5G においても C-V2X の利用が想定される。この際、C-V2X において前節のセキュリティ要件を考慮した課題を明確化する必要がある。
 認証・認可
上記トラストモデルにおけるサービスの利用者、サービス事業者、クルマ製造業者、ネットワーク事業者に加え、ネットワークスライスの提供者や、MEC 上のサービス事業者、C-V2X のサービス提供者などサービスレベルでの認証・認可の課題を明確化する必要がある。

図 5.2.43

Connected Vehicle のネットワーク要件に基づく 5G 機能

96

5.2.3.2. トラストモデル
Connected Vehicle サービスの実現においては、様々なプレーヤが関与することが想定される。ここでは、前節で選択した４つのユースケースにおいて、サービスレベルからの視点でそれぞれのプレーヤ間や、そこで扱われる様々なデータに関する信頼関係について整理する。
Connected Vehicle サービスにおいては、利用者、クルマ、ネットワーク、クラウドがプレーヤとなる。WP.29 のサイバーセキュリティ対策の観点からは、通信チャネルに対する攻撃を想定した対策としては、それぞれのプレーヤ間での信頼関係の確立し、セキュアな関係（コネクション）を確立する。信頼関係を構築する対象としては、接続先の相手(Peer Entity)及び、そのプレーヤ間で授受されるデータとなる（図 5.2.44 参照）。

図 5.2.44

トラストモデル

表 5.2.212 ユースケースで授受される情報

ここで、各プレーヤ間は、Connected Vehicle サービス形態に固有の信頼関係を構築する。
利用者は、クルマの所有者、あるいはその家族、レンタルでの利用者、カーシェアリングでの利用者などが想定される。前提としては、Connected Vehicle サービスは、クルマが具備する機能
によって利用可能なサービスが決定される。例えば、一般的に高級なクルマは、付加サービスが豊富である。すなわち、Connected Vehicle サービスは、利用者ではなくクルマに紐づくサービスと考えるのが現実的である。
このようなビジネスモデルを前提とした各プレーヤの信頼関係は以下の通りである。
・利用者によるクルマの認証
クルマ製造業者は、社会的な信頼性があり、現在、利用者がクルマの信頼性を確認する必要性が見出されていない。
・利用者によるネットワーク認証
Connected Vehicle サービスでは、クルマがネットワークを認証するため、利用者がネットワークを認証する必要はない。
・利用者によるクラウドサービスの認証
97Connected Vehicle サービスでは、クルマがクラウドサービスを認証するため、利用者がネッ
トワークを認証する必要はない。
・クルマによる利用者の認証
現在、利用者の認証は物理的な鍵（キー）により行われるが、自動車保険サービスなど、今後、ドライバーを識別したサービスも想定されるため本人を確認する技術も想定される。
・クルマによるネットワークの認証
Connected Vehicle サービスでは、クルマがネットワークを認証するため、利用者がネットワークを認証する必要はない。
（インフラによっては認証できないケースもある）
・クルマによるクラウドサービスの認証
Connected Vehicle サービスでは、クルマが提供するサービスと想定されるため、クルマがク
ラウドサービスを認証
・ネットワークによる利用者の認証
Connected Vehicle サービスでは、ネットワークは、接続されるクルマを認証するため利用者の認証は不要・ネットワークによるクルマの認証
Connected Vehicle サービスでは、ネットワークは、接続されるクルマを認証する
・ネットワークによるクラウドサービスの認証
Connected Vehicle サービスでは、ネットワークは、接続されるクラウドサービスを認証する
・クラウドによる利用者の認証
Connected Vehicle サービスでは、クラウドは、接続されるクルマを認証するため利用者の認証は不要
・クラウドによるクルマの認証
Connected Vehicle サービスでは、クラウドサービスは、接続されるクルマを認証する
・クラウドによるネットワークの認証
Connected Vehicle サービスでは、クラウドがネットワークを認証する。（インフラによっては認証できないケースもある）
これらの信頼関係を表 5.2.23 にまとめる。
表 5.2.223 各プレーヤの信頼関係

5.2.3.3. ネットワークスライシング
Connected Vehicle サービスにおいて、各ユースケースにおいて必要となるネットワークの要件が異なるため、これらの異なる要件に適合する論理的なネットワークを利用する可能性があ98

る。
例えば、UC-1 の自動運転支援においては、ダイナミックマップのクラウドからクルマに対するデータ転送には、高スループットなネットワークが必要となるのに対し、車両制御情報をクラウ
ド側でクルマに通知する場合には、低遅延なネットワークが要求される。これらのそれぞれの異なるネットワーク要件に従って、ネットワークの QoS を管理する仕組みが必要となる。ここで、5G の特徴として、ネットワークの仮想化にともなう、ネットワークスライシングの機能が利用できる。
5.2.3.3.1. 5G ネットワークスライシング機能におけるセキュリティ
3GPP SA3 Phase2 においてネットワークスライシングのセキュリティについて検討を行っている。ネットワークスライシングのセキュリティに関する検討項目は以下の通りである(3GPP
TR 33.813) [32]。
・ネットワークスライス認証・認可
不正な端末のアクセスにより、ネットワーク資源の消費や DoS 攻撃などを防止するためスラ
イス認証、認可の仕組みを提供する。スライス認証は、プライマリ認証と組み合わせで利用する。
・ネットワークスライシングにおける鍵の分離
スライス別の鍵を管理し、鍵の漏洩に対して他のスライスに影響を及ぼさないようにすること、鍵の更新に対して、フォワードセキュリティを効率的に保証するための仕組みを提供すること。
・スライスの提供者は、スライスの利用者に対して、利用者ごとにサービスをカスタマイズして提供すること。具体的にはネットワークの特性（無線アクセス技術、通信帯域、遅延、信頼性等）とセキュリティレベルなど。セキュリティレベルについては、スライスの利用者に対して提供するセキュリティ機能をその機能の提供方法を規定する必要がある。
・スライス認証・認可については、モバイル通信事業者の加入者情報とは異なる ID や認証情報（Credential）を管理する必要がある。上記セキュリティを確保するためには、UE（通信端末）でのスライス認証・認可のための ID や認証情報の安全な保管方法と、第 3 者が提供するスライス認証のネットワーク機能と 5G コアのネットワーク機能（AMF, SMF or NSSF）な
どとの安全な通信が必要となる。
・ネットワークスライスへのアクセストークンは、NRF によって発行される。スライス利用者
は共有スライスに対するトークンを用いて、同じタイプのネットワークサービス提供者(NF
service producer)によって提供されるサービスにアクセスすることができる。
NS-1 (NS-Producer-1)
NS-2 (NS-Producer-2)

shared slice level

access token

NS-3 (NS-Producer-3)
・プライバシー保護のために、NSSAI 情報を保護する。具体的には、セキュアセッションが確
99

立するまで、初期の NAS 情報として NSSAI 情報を送らない。
・一度拒否された NSSAI を UE(通信端末)が後にアクセスすることができるように、無効なNSSAI を取り消す手段の提供
プライマリ認証およびスライス認証の手順を図 5.2.45 に示す。

図 5.2.45

プライマリ認証およびスライス認証の手順概要

上記の TR 33.813 の検討結果に基づき、新たに技術仕様 TS33.501(security Architecture)

Release 18[33]の 15 節（Management security for network slices）、新規 16 節（Security
procedures for network slices）として仕様化されている。さらに、Release 18 により、新たに、技術報告 TR33.874(Study on enhanced security for Network Slicing Phase 2)[34]および、技術報告 TR33.886(Study on enhanced security for Network Slicing Phase 3)[35]が検討されている 。 ま た 、 技 術 仕 様 TS33.326[36] で は 、 ネ ッ ト ワ ー ク ス ラ イ ス の 認 証 ・ 認 可 機 能 の
NSSAAF(Network Slice Specific Authentication and Authorization Function)特有のセキュリ
ティ要件とその試験項目が記載されている。以下、各々を概説する。
TS33.501 の 15 節では、スライスのインスタンス（実態）を生成、運用、廃止するためのネット
ワークスライス管理サービスのセキュリティについて規定しており、具体的には、スライス管理
サービスとその利用者間の相互認証、データの完全性、リプレイ攻撃の防止、機密性の確保を TLSにより実現することが規定されている。加えて、相互認証の後に、サービス管理サービスが利用者を認可する手順が規定されている。
また、TS33.501 16 節では、UE がネットワークスライスにアクセスするための、プライマリ認証と認可の関係を規定している。まず、プライマリ認証により、UE が認証されると、UE が利用可
100

能なネットワークスライシングの ID リスト(S-NSSAI)が提示される。その後、指定したネットワークスライスに対して、ネットワークスライシング認証・認可のプロセスが実行される。

図 5.2.46

プライマリ認証と NSSAA との関係

また、ネットワークスライシング認証は、外部の認証サーバを用いることも可能である。この場
合は、3GPP の加入者に対するクレデンシャル（認証情報）とは別のクレデンシャルを用いる。
認証サーバ（AAA）との間の認証・認可は、EAP のフレームワークが利用される。また、ネット
ワークスライシングの安全かつ効率的な利用を想定して、認証サーバ(AAA)から、再認証・再認可を行う手続きや、認証の停止する手続きも規定されている。
一方、新たな検討項目である TR33.874 では、スライス情報の同報によるプライバシー漏洩に対する対策、新たな NSAC(Network Slice Admission Control)手順に関する DoS 対策、AF 認証・認可が検討されている。
技術報告 TR 33.874 では、特定のネットワークスライスの高速セル選択とセル再選択をサポートするために、スライス関連情報を同報する検討がされており、これがプライバシー漏洩につながる可能性がある。
また、技術仕様 TS23.501 および TS23.502 で導入された NSAC(Network Slice Admission
Control)手順は、特定のネットワークスライスに登録された UE の数を監視して、規定値以上になる場合は、新たな UE による利用を拒否する仕組みとなっており、UE が複数のスライスを利用する場合、スライスの割り当てを占有する DoS 攻撃となる可能性がある。
さらに、AF 認証・認可は、ネットワークスライスを利用する UE 数や、PDU セッション数などを監視する機能を有するため、不正な AF に対しては、情報がネットワークスライスの管理情報が漏洩するリスクがある。
技術報告 TR33.886 では、以下の検討を行なっている。
・ローミング中の UE が、他のネットワークからそのエリアで利用可能なネットワークスライス
101

を必要とするために、UE に VPLMN のスライス情報を提供するためのセキュアな手順
・ネットワークスライスが停止しても UE がアクセスできる、あるいは、ネットワークスライスのライフタイム情報が適切に UE に提供されないために UE がネットワークスライスにアクセスできないといった問題を考慮し、ライフタイムが短い時限的なネットワークスライスをサポートする認可手順とスライスサービスエリアの認可手順・リリース１７で規定された NSAC をリリース１８で拡張する際のセキュリティ検討。具体的には、UE の振る舞いに対するネットワーク制御の改善と、複数の NSACF への対応に対するセキュリティ検討
技術仕様 TS33.326 では、NSSAAF に関する以下のセキュリティアシュアランス仕様（SCAS）
が規定されている。
・特定の S-NSSAI に対するネットワークスライスの認証・認可のメッセージを、H-PLMN のAAA の場合は直接 AAA サーバ（AAA-S）へ、外部の AAA サーバの場合は AAA プロキシ（AAAP）経由でメッセージを送受するため、メッセージの振り分けを行う必要がある。この振り分けための試験項目と、セキュリティ要件の基準を規定している。
・NSSAF が、AAA サーバ（AAA-S）が再認証および再認可の権限を有するかどうかを確認する
試験項目とそのセキュリティ要件の基準を規定している。
・eNodeB 固有の堅牢化要件の適応と関連する試験項目。
・NSSAAF 特有の脆弱性検査の要件と関連する試験項目
5.2.3.3.2. Connected Vehicle におけるネットワークスライシングのセキュリティ課題
安全な走行を確保するためには、他のネットワークと分離し、車両制御情報等を、高信頼、低遅延で送受する必要があり、自動運転支援専用の 5G ネットワークスライシングが想定される。
このような（ある種公共性をもった）専用ネットワークスライシングの必要性や要求されるセキュリティプロファイルを規定するとともに、ネットワーク要件（遅延、サービスエリア等）を検討する必要がある。本節では、最新のネットワークスライスの検討状況を踏まえ、Connected
Vehicle におけるネットワークスライスのセキュリティ要件を以下に考察する（図 5.2.47 参照）。ここで、ネットワークスライシングの管理主体は、Connected Vehicle のサービス事業者、あるいは、通信事業者のいずれかの可能性がある。
（１）ユーザセントリックな認証及び認可
ネットワークスライシングは、モバイルネットワーク上で構築される仮想定期な通信ネットワークであり、例えば、自動運転支援専用の仮想ネットワークを想定した場合、本仮想ネットワー
ク（スライス）の提供者は、自動運転支援サービスの提供者であると考えられる。従って、スライス認証・認可は、自動運転支援サービスの提供者が、自動運転支援サービスの利用契約を行った利用者を認証および、そのアクセス権を認可する必要がある。このように自動運転支援サービ
スは、モバイル通信基盤の上で実現されるモバイル通信事業者とは独立サービスも可能である。
このように、Connected Vehicle のサービス事業者が、ネットワークスライシングの管理主体となる場合は、外部の認証サーバ（AAA）が、ユーザを認証すると想定される。この場合は、技術
102

仕様 TS33.501 で規定された外部サーバによるスライス認証・認可の手順が適用可能である。
また、上記の仮想ネットワーク上のサービスを安全に利用するために、3GPP TR 33.813 で検討されるように、UE(通信端末)においては、スライス認証のための ID や認証情報（Credential）を一定のセキュリティレベルで保管・管理する必要がある。例えば、SIM や
TEE 等のハードウェア耐タンパーモジュールを用いることも想定される。加えて、UE においてプライマリ認証とスライス認証の状態を管理する必要も生じる。例えば、プライマリ認証が確立している状態で、スライス認証手順が動作するなど。
他に、複数のモバイル通信事業者を経由した Connected Vehicle サービスも想定され、Connected Vehicle サービスで利用されるスライス認証も含めたローミングの仕組みを検討する必要が生じる。
（２）Connected Vehicle サービス提供者によるセキュアなネットワークスライス管理
Connected Vehicle のサービス事業者が、ネットワークスライシングの管理主体となる場合は、技術仕様 TS33.501 の 15 節で規定されたネットワークスライスの管理インタフェースにおける、TLS に基づく相互認証、完全性、リプレイ攻撃防止、機密性の機能を活用できる。一方、通信事業者がネットワークスライスの管理主体となる場合は、Connected Vehicle サービス事業者による、ネットワークスライスの制御は不可能であるので、通信事業者と Connected Vehicle サービ
ス事業者間によるアウトバンドでの制御インタフェースが必要となる。
（３）CV サービスのためのセキュリティプロファイルの最適化
Connected Vehicle のサービスが要求するセキュリティのレベルに応じて、ネットワークスライ
スを利用する際の利用者（UE）の認証のレベル規定する必要がある。3GPP TR 33.813 で検討されるように、スライスの提供者は、スライスの利用者に対して、利用者ごとにサービスをカスタマイズして提供する。具体的には、各 Connected Vehicle サービスで想定されるスライスに対するネットワークの特性とセキュリティレベルを規定する必要がある。下記にそのパラメタ例を示す。
ネットワーク品質の要件： 遅延、誤り率、ジッタ
セキュリティレベル：暗号方式、鍵長、鍵管理方式（鍵の更新頻度、Perfect Forward

Security 等）（４）複数のネットワークスライスにアクセスするためのモバイルデバイスでの ID と認証情報のセキュアな管理
複数のモバイル通信事業者を経由した Connected Vehicle サービスも想定され、Connected
Vehicle サービスで利用されるスライス認証も含めたローミングの仕組みを検討する必要が生じる。

103

図 5.2.47

Connected Vehicle1 における５G ネットワークスライシングのセキュリティ要件
概要図

5.2.3.4. MEC
5.2.3.4.1. MEC 概要
MEC は、低遅延やネットワークの負荷を軽減が期待されるアーキテクチャであり、Connected
Vehicle においてもその利用が想定される。MEC の技術については、図 5.2.48 に示すとおり、
ETSI MEC、3GPP および Connected Vehicle での適用について 5GAA で検討されている[37]。ETSI MEC では、MEC の参照アーキテクチャや様々なユースケースを想定した API の標準化を進めている。また、3GPP では、5G のアーキテクチャの一機能として MEC の概念を取り込むための検討をすすめている。また、AECC においても、自動車製製造業者と通信事業者
が、Connected Vehicle サービスを目的とし、複数の通信事業者にまたがるエッジコンピューテ
ィングを想定した分散クラウド環境の実現するためのネットワークデザインの検討を進めている[38]。

図 5.2.48 MEC の検討に関する 5GAA、ETSI、3GPP の関係図
104

ETSI、3GPP において検討されている 5G システムアーキテクチャと MEC の関係を図5.2.49 に示す [39][40]。ここでは、5G コアの SBA のアーキテクチャに基づくインタフェース
を介して MEC の機能が実現される。すなわち、MEC は、3GPP の他のネットワーク機能が提供するサービスを利用する AF(Application Function)上に位置づけられ、5G コアのNEF(Network Resource Function)を介して、認証機能（AUSF）、ネットワークスライシング（NSSF）、5G のトラフィックを MEC への誘導（UPF）など 5G コアで提供される様々なネットワーク機能(NF)を利用し構築される。

図 5.2.49 5G Service Based Architecture と MEC Architecture の関係図
5.2.3.4.2. 5G MEC 機能におけるセキュリティ
Release 17 技術仕様 TS33.839[41]において、５G コアにおいて EC（Edge Computing）をサポートするセキュリティの仕様が規定された。
図 5.2.50 に EC のアーキテクチャを示す。ここで、ECS(Edge Configuration Server)は、EC に必要な設定を管理する機能、EEC（Edge Enabler
Client）は、端末側で EC サービスを実現するための機能、EES(Edge Enabler Server)は、サー
バ側で EC サービスを実現するための機能、EAS(Edge Application Server(s))は、サーバ側の EC
サービスアプリの機能、AC（Application Client(s)）は、端末側のアプリで、サーバ側の EC サービスアプリを利用する機能を、各々提供する。技術仕様 TS33.839 では、以下の機能が検討されている。
・Key Issue No.1：EEC と EES 間の認証・認可機能・Key Issue No.2：EEC と ECS 間の認証・認可機能・Key Issue No.3：EES と ECS 間の認証・認可機能・Key Issue No.4：EDN の認証・認可機能・Key Issue No.5：EDN の利用者 ID と認証情報の保護
・Key Issue No.6：図中 EDGE 1-9 のインタフェースにおけるトランスポートレイヤのセキュリ
ティ・Key Issue No.7：低遅延のローカルアプリケーションに対してネットワークに関する情報を設105

定するためのセキュリティ
・Key Issue No.8：EES の EAS への機能提示の際の認証・認可・Key Issue No.9：EAS サービス発見手続きのセキュリティ
・Key Issue No.10：EDN(Edge Data Network)の変更に伴う認証

図 5.2.50

EC のアーキテクチャ

さらに、上記の機能を実現するため、３１項目のセキュリティの技術仕様(Solution)が規定されている。ここでは、以下の２つの例を述べる。
・Solution No.2: プライマリ認証の基づく EEC-ECS 間の認証
EEC-ECS 間の認証手順は以下の通りである（図 5.2.51 参照）。
① プライマリ認証の結果、によりユーザ端末（UE）と認証サーバ（AUSF）間で、鍵 KAUSFが共有される。本 TR33.839 では、共有鍵の生成方法も規定される。
② この共有鍵と端末識別子を基に、ユーザ端末と認証サーバ双方は、クリデンシャル（認証情報とその ID）を作成する。
③ ユーザ端末は、クリデンシャルを添え、ECS に、認証要求を行う。
④ ECS は、NEF 経由で、認証サーバにクリデンシャルの正当性確認を依頼し、その結果に基づいて、ユーザ端末に認証応答を返す。

106

図 5.2.51

プライマリ認証の基づく EEC-ECS 間の認証手順

・Solution No.4: プライマリ認証の基づく EEC-EES 間の認証・認可フレームワーク
EEC-EES 間の認証・認可手順は以下のとおりである（図 52 参照）。本手順は、エッジコンピューティング環境のコンテクストのもと、ECS がセカンダリ認証の AAA サーバとして EEC を認証するとともに、OAuth2.0 に基づく認可サーバとして、EEC（クライアント）が EES（エッジサーバ）のアクセストークンの発行・検証の役割を果たしている点に特徴がある。
① ユーザ端末（UE）がプライマリ認証により、ネットワークにアクセスする。
② ユーザ端末（UE）は、ECS とサービスプロビジョニング手続きを起動し、PDU セッションを確立する。本セッションは、AMF が SMF／PSA を選択し、ECSP が提供する DNAAA サーバへのコネクションを提供するとともに、セカンダリ認証を実行する。ここで、ECS は、DN-AAA サーバとして動作できる。
③ DN-AAA サーバによりセカンダリ認証が成立した後、ユーザ端末は、EEC のプロビジョニ
ングのため、ECS のアドレスを確認の上、接続し、EES に EEC を登録する。EDGE-4 のインタフェースにより、EEC と ECS 間で T LS のセキュアセッションを確立後、OAuth2.0
に従い、EEC は、ECS に対して、アクセストークンを含むプロビジョニング要求を行う。
ECS がアクセストークンを検証し、正しければ EEC に対するアクセストークンを生成し、EEC にプロビジョニング応答を返す。
④ EDGE-1 のインタフェースにより、EEC は、TLS により EES を認証する。ユーザ端末は、③で得たアクセストークンを含む EES に対する EEC の登録手続きを起動する。EES はECS にアクセストークンの検証を依頼し、アクセストークンを検証することにより EEC 登
録手続きに対する認可を行う。

107

⑤ EEC は、アクセストークンを用いて EES に対してサービス要求(ディスカバリ)を行う。
EES は、ECS によるアクセストークンの署名を検証し、正しければ、EES サーバは、アクセストークンに記載された認可情報に従い、EEC のサービス要求を許可する。
⑥ ユーザ端末（あるいは AC）は、EES から得たアクセストークンを用いて、EAS のサービスを享受する。EAS はアクセストークンの検証サービスを、EES を介して ECS により提供される。アクセストークンが正しく検証された場合に、ユーザ端末は EAS のサービスを享受できるようになる。
（注）AC と EAS 間の認証・認可サービスは、３GPP の規定外であること。すなわち⑥は参考情報であることに留意

Application
ClientUE
Edge Enabler
ClientUE Preconfiguration

OAuth Server
MT

ECS

AMF/SMF

Edge Enabler
ServerEDGE Application
Server

1. Network Access Authentication
procedure
2. PDU Session Establishment
2. Secondary Authentication with ECS or ECSP AAA Server

3.A. Initial Provisioning Request
3.b.. Initial Provisioning Response (Token)
4.a. Secure session establishment: SSL using server certificate
4B. EEC registration request (Token)
4C. Token validation
4D. Retrieve EEC’s Context
4.e. EEC registration response
5.a. Edge Application server discovery request (Token)

6. Token

5.D. Edge Application discovery response (Token)

図 5.2.52
Release 18

セカンダリ認証に基づく EEC-EES 間の認証・認可フレームワーク

技術仕様 TS33.558[42]では、5G のエッジアプリケーションを実現するためのアーキテクチャをサポートするセキュリティ機能とメカニズム、すなわち、インタフェースのセキュリティ、アプリケーション・アーキテクチャのエンティティ間の認証と認可の手順、および EES
機能の公開手順について規定する。
また、技術報告 TR33.739 では、技術報告 TR33.839 および技術仕様 TS33.558 の結果に基づき、
5G システムにおけるエッジコンピューティングのサポートに関する作業（技術報告 TR 23.70048[43]の「エッジコンピューティングのための 5G システム拡張」、および 技術報告 TR 23.70098 の「エッジアプリケーションを有効にするための拡張アーキテクチャ」）の継続から生じる新しい機能や手順に関連するセキュリティの側面について検討を進めている。
5.2.3.4.3. Connected Vehicle サービスにおける MEC のセキュリティ要件
MEC のアーキテクチャのセキュリティについては、現状、検討が進められている状況である[44][45]。
108

ここで、Connected Vehicle のユースケースの機能の一部が、MEC 基盤上でアプリケーションとして動作する際に、Attack surface としては、ネットワークからの攻撃、MEC 基盤上で動作する
他のアプリケーションからの攻撃、MEC 基盤からの攻撃、アプリ自体の不正プログラムの混入などが想定される。そのアプリケーションに対する脅威は、図 5.2.41 の表のクラウドの位置づけと同様に、なりすまし、データの改ざん、データの漏洩、DoS がある。図 5.2.41 で規定したセキュ
リティ対策が必要となる。

図 5.2.53 MEC アプリの Attack Surfaces
上記のなりすまし対策として MEC 基盤による利用者の認証が考えられる。利用者認証においては、5G コアの認証機能（AUSF）を活用できる。また、MEC 上の各アプリの利用については、
MEC 基盤において、MEC アプリ利用者の認証・認可の機能が必要となる。具体的な手順は今後の検討課題であるが（セカンダリ認証が利用できる等）、例えば、自動運転支援による MEC 活用を想定した場合、MEC アプリの提供者は、自動運転支援サービスの提供者であると考えられる。
従って、MEC アプリの利用者認証は、自動運転支援サービスの提供者が、自動運転支援サービスの利用契約を行った利用者を認証および、そのアクセス権を認可する必要がある。
複数のモバイル通信事業者を経由した自動運転支援サービスも想定され、自動運転支援サービス
で利用されるローミングの仕組みを検討する必要が生じる。加えて、ローミング時にサービスやユーザに紐づくセキュリティポリシーについて一貫性を保ちながら引き継ぐ仕組みが必要となる。
自動運転支援などの MEC アプリは、通信事業者から見た第三者アプリであり、MEC アプリとして登録、運用する際には、アプリケーションの安全性評価について、一定の基準を設ける必要がある。
上記の検討に基づく Connected Vehicle サービスにおける MEC のセキュリティ要件を図 54 に示す。なお、複数モバイル事業者をまたがる Connected Vehicle に関する検討は、後述の５GAAでの動向を紹介する。
（１）ユーザセントリックな認証及び認可
不正な Application Client による、EAS(Edge Application Server)のアクセスを防止するために、Application Client の認証・認可を考慮する必要がある。Release 17 技術報告 TR33.839 において、MEC 環境における認証・認可のフレームワークが規定されている。AC と EAS 間の認証・109

認可は、３GPP の対象外であるが、認可サーバの役割を有する ECS(Edge Configuration Service)のアクセストークン管理サービスを EAS が利用する可能性が指摘されている。（先出の技術報告
TR33.839 Solution No.4 参照）（２）MEC アプリケーションの登録, アップデート 及び検証
Connected Vehicle のサービス事業者が、MEC アプリケーションの管理主体となる場合は、MEC
アプリケーションの登録, アップデート 及びアプリケーションの正当性の検証をセキュアに行う管理インタフェースを提供する必要がある。一方、通信事業者が MEC アプリケーションの管理主体となる場合は、Connected Vehicle サービス事業者による、MEC アプリケーションの管理は不可能であるので、通信事業者と Connected Vehicle サービス事業者間によるアウトバンドでの管理インタフェースが必要となる。
（３）他の MEC やクラウドとの安全な連携
外部の MEC やクラウドと安全に接続するための相互認証、機密性、完全性、リプレイ攻撃対策の機能が提供される必要がある。
（４）アプリケーションデータのプライバシー保護
MEC アプリケーションで扱われる機微情報については、MEC のプラットフォームに情報が漏洩しない技術的な対策が必要となる場合がある。

図 5.2.54

Connected Vehicle1 における 5G MEC のセキュリティ要件 概要図

5.2.3.4.4. 5G Automotive Association(5GAA)におけるエッジ活用の検討調査
5GAA は、 2016 年 9 月に創設. 自動車、テクノロジー、通信業界(ICT)の企業が参加する業界
110横断的な組織で、将来のモビリティおよび輸送サービスのためのエンドツーエンドのソリューシ
ョンの開発を目的とする。５GAA において、複数の通信事業者が連携する MEC のシステムモデ
ルとそのセキュリティを検討した白書「MEC for Automotive in Multi-Operator Scenarios（2021.03)」[46]が公開されている。本節では、上記白書をセキュリティの観点にフォーカスして概説する。
5.2.3.4.4.1

複数の通信事業者が介在する MEC の参照アーキテクチャ

上記の白書では、図 55 の参照アーキテクチャに示す通り、AF の機能として実現される MEC 基
盤(MEC Platform)とその上で稼働する MEC アプリケーション(MEC App)があり、各通信事業者
が、MEC 基盤及び MEC アプリケーションの提供するシナリオを以下の３つに分類し規定している。

図 5.2.55

Connected Vehicle の MEC 活用における参照アーキテクチャ

・２つの異なる通信事業者（MNO-1,2）が MEC 基盤と MEC アプリケーションを保有
本シナリオでは、車体が、通信事業社１から２のエリアに移動する際、利用する MEC アプリケーションも通信事業社１から２に遷移する。したがって、車体と MEC アプリケーションの最短経路が確保されるため、低遅延の通信が可能となる。
・２つの異なる通信事業者（MNO-1,2）が MEC 基盤を、MNO-1 が MEC アプリケーションを保有
本シナリオでは、車体が、通信事業者１から２のエリアに移動する際、通信事業者１の MEC ア
プリケーションと接続する必要がある。この際、双方の通信事業者の MEC が、制御プレーンにより相互に接続し、通信事業者２のエリア内の車体と通信事業者１の MEC アプリケーション間のデータプレーンを確立する。このデータプレーンを用いて車体と MEC アプリケーションが通
信を行う。
111

・MNO-１のみが、MEC 基盤および MEC アプリケーションを保有
本シナリオでは２つのケースが想定される。
車体が、通信事業者１から２のエリアに移動する際、通信事業者２のエリア内の車体が、ローミングにより通信事業者１の MEC アプリケーションと接続するケース
車体が、通信事業者１から２のエリアに移動する際、通信事業者２のエリア内の車体が、通信事業者２の UPF を経由して通信事業者１のデータネットワーク（DN）へオフロードして接続するケース（２）MEC におけるセキュリティ境界
MEC は、通信事業者 MNO、MEC テナント・アプリケーション・プロバイダー、アプリケーションユーザが、プレーヤになる。本白書では、MEC が提供しないテナントアプリケーションとサービスは、MEC の責任範囲外であり、アプリケーションユーザと MEC テナントアプリケーショ
ンプロバイダーが責任と管理を引き受ける。従って、前節のシナリオに基づくセキュリティ境界を以下のように定義する。
・図 5.2.56 に示すような１通信事業者と１MEC 基盤のケースは、MEC 基盤および MEC アプ
リケーションをセキュリティの境界とする。

図 5.2.56 2 通信事業者がそれぞれ、MEC 基盤と MEC アプリケーションを有するケース
・図 5.2.57 に示すような複数の通信事業者に MEC 基盤と MEC アプリケーションがまたがる
場合は、車体が属するエリアの通信事業者の MEC 基盤と他の通信事業者に存在する MEC ア
プリケーションへの接続経路をセキュリティ境界とする。

112

図 5.2.57 2 通信事業者が MEC 基盤を保有、1 通信事業者のみが MEC アプリケーションを保有するケース
・図 5.2.58 に示すような１通信事業者が、MEC 基盤と MEC アプリケーションが存在し、他の通信事業者からローミングする場合は、MEC 基盤、MEC アプリケーションおよび通信事業者間を接続する DN をセキュリティ境界とする。

図 5.2.58

１通信事業者のみが MEC 基盤と MEC アプリケーションを保有するケース（３）セキュリティ分析
前節で規定したセキュリティ境界を対象とし、欧州 ENISA のガイドラインに基づき、米国 NIST
サイバーセキュリティフレームワークの５項目（Identity, Protect, Detect, Respond, Recover)にGDPR を考慮した privacy の６項目の視点でセキュリティ要件を整理している（表 24 参照）。

Identity

表 5.2.234 MEC のセキュリティ要件
概要（一部抜粋）
EntityMNO が MEC の機能を実現するための車両、データ、人員、デManagement
バイス、システム、及び設備は、事業目的及び MNO のリスク戦略に対する相対的な重要性に応じて識別され、管理される。
Risk Assessment MNO は、MEC の業務（サービス、機能、サービスの可用性を含む）、MNO の資産、及び個人に対するサイバーセキュリティ
リスクを理解している。
113

Protect

DetectRespond

RecoverPrivacy

AccessControl

アクセス・コントロール - MNO および MEC の物理的・論理
的資産および関連施設に対するもの。すべての MEC のアクセ
スおよび管理について、最小特権の方針が実施されなければな
らない。
Data Security
情報及び記録（データ）は、情報の機密性、完全性及び可用性を保護するために、MNO のリスク戦略、プライバシーポリシー及び適用法に準拠して管理される。
Information
セキュリティポリシー、プロセス、手順がキャリアにより維持
Protection
され、 情報システム及び資産の保護管理に使用される。消費者のプライバシーに関連する情報は、適用される法律又は携帯通信キャリアのプライバシーに関するガイダンスに沿ったレベルで保護されなければならない。
Anomalies and 異常な活動は適時に検知され、イベントの潜在的な影響は理解
Eventsされるものとする。MNO の MEC プロバイダーは、プライバシーの制約を考慮しつつ、可能な限り、MEC がホスティングするサービスに対する不正使用や悪意のある行動を検知しなければならない。
Security
MEC と関連する資産は、サイバーセキュリティ上の事象を特定
Continuous
し、保護手段の有効性を 検証するために、個別の間隔で監視さ
Monitoring
れる。MNO/MEC のベストプラクティスは、重大でない攻撃や悪意のある活動に対して自動化された監視を提供することである。
Response
MNO MEC の対応プロセスと手順は、検出されたサイバーセキ
Planning
ュリティ事象に対す るタイムリーな対応を確保するために実行され、維持される。サイバーセキュリティのベストプラクテ
ィスは、MNO MEC 共有責任のパラダイムの現実を認識したセキュリティインシデント対応計画を持つことである。
Response
レスポンス活動は、適宜、社内外の組織（OEM や加入者）と調Communications 整され、政府機関による外部支援も含まれる。
Mitigation
MNO MEC のサイバーセキュリティ活動は、イベントの拡大を防止し、その影響を緩和し、インシデントを根絶するために実施される。し、インシデントを根絶する。
Response
MNO MEC のサイバーセキュリティ復旧プロセスと手順は、サ
Planning
イバーセキュリティ事象の影響を受けたシステムまたは資産をタイムリーに復旧させるために実行され、維持される。
MEC のプライバシー・セキュリティ・サービスは、場所や MNO によって異なるかもしれないが、特定のプライバシー管理に関する広範な合意を考えると、特定のMEC のプライバシー保護機能を提供することが賢明である。GDPR や、CCPA のような GDPR に触発された法律は、ほとんどの MNO の MEC 事業者がプライバシーの指針として依拠すべきモデルと考えられている。
GDPR
GDPR および GDPR に触発されたその他のガイダンスによるプライバシー原則に準ずる
Anonymity
MNO MEC は、法令または MEC のサービス（例：セーフティ
Services
メッセージ）に基づき、匿名化 サービスを提供する。
Personal Privacy MNO は、加入者がプライバシーデータを管理するための仕組み
Dataを（法令に基づき適用される場合には）認めるものとする。
Management
Do Not Track MNO は、（法律で定められている場合）契約者が追跡を防止す
Services
るためのサービスを利用できるようにしなければならない。

5.2.3.5. C-V2X
5.2.3.5.1. C-V2X の概要
C-V2X は、セルラー通信により車車間、車両と路側器との通信を行う手段として、5G などの標準仕様が 3GPP で規格化されている。このなかでも、V2V（車車間）、V2I（路車間）、V2P（歩114

車間）の境域通信は、無線のインタフェース規格 PC5 が用いられる。また、モバイル通信網を介する広域通信として V2N（車両ネットワーク間）が規定されている。5G の検討においては、3GPP
Release1５において V2N（参照点：Uu）が規定され、Release16 において、V2I、V2V(参照点：
PC5)が規格化されている [47]。データの転送手法としては、unicast, groupcast, multicast の 3つの方式が規定されている。

図 5.2.59 3GPP Release16 における 5G システムアーキテクチャ内の V2X アーキテクチャ[48]
5.2.3.5.2

5G C-V2X 機能におけるセキュリティ

また、PC5 の参照点（モバイルネットワークを介さない通信）におけるセキュリティについては、
3GPP SA3 TS33.836[49]において、Layer 2 ID やソース IP アドレスのプライバシー保護を対象として、以下の機能が検討されている [50]。


PC5 上でのユニキャストメッセージにおけるプライバシー保護
機器の ID（L2-ID）を定期的に更新して、トレーサビリティやリンカビリティを排除

PC 上での eV2X のユニキャストメッセージにおけるセキュリティ
機器間でセキュリティのアソシエーション（セッション）を確立



PC5 上でのマルチキャストメッセージにおけるプライバシー保護
マルチキャストセッションにおいて、発信元 ID（L2-ID）の追跡を防止

グループ通信の ID に関するプライバシー保護グループ ID から機器の ID（L2-ID）を紐づけされないよう保護

マルチキャスト通信の設定に関するセキュリティ
マルチキャスト通信を行う際に、L2 のシグナリングを用いるため、そのプロトコルへの攻撃（MitM 等）
115

を防止


機器のサービス認可や破棄に関するセキュリティ
機器のサービス認可や、破棄のプロトコルに対して、秘匿、改ざん防止、リプレイ攻撃の防止

Cross－RAT(LTE と 5G)のサービス認可に関するセキュリティ

また、上記、技術報告 TR33.836 に基づき、Release17 において、技術仕様 TS33.536[51]が検討されている。
5.2.3.5.3. Connected Vehicle における C-V2X のセキュリティ要件
C-V2X については、5.2.2.4 節の「セルラー通信技術を用いた ITS・自動運転の高度化に向けた
課題調査報告書」にセキュリティの課題がまとめられている。上記の報告書における各ユースケースでの共通のセキュリティ課題は、以下の通りである。以下抜粋「情報の真正性の保証、その責任所在が重要になる。本ユースケースでは、情報提供元の機関の起点での認証が必要である。認証されていない機関からの情報の改ざんされた情報が配信されないよう、例えば、配信情報への電子署名埋め込みや、情報の提供元・情報配信サーバ・情報受
信車両でのセキュアな接続を利用することが考えられる。また、配信制御のための車両トラッキングによるプライバシー課題の検討も必要である。
」
・ここで、C-V2X におけるアプリケーションデータのセキュリティ仕様は、3GPP の対象外としており、狭域通信 PC5 における機器間のセキュリティアソシエーションの仕様については、IEEE DSRC(WAVE) の 仕 様 で あ る IEEE 1609-2 Security Services for application andManagement Messages の PKI ベースのメカニズムを参考としている。IEEE1609-2 においては、メッセージの秘匿、完全性、認証・認可を提供する。
・C-V2X は、UC-1 の周辺車両走行状態を車車間や路車間の通信により低遅延に情報を得る必要がある。一方、上記報告書においても同課題が指摘されているとおり、IEEE1609-2 の PKI の証明書によるデータの真正性を確認する場合、処理性能が課題となる。特に、証明書の署名検証の処理負荷、失効リスト（CRL）の確認処理、証明書のデータ量に起因する通信遅延処理などを効率的に行う検討が必要となる。
・プライバシー課題については、前述の 3GPP SA3 TS33.836 において、Layer 2 ID やソース IP
アドレスの定期的な変更を行うプロトコルが規定されている。さらに、アプリケーションデー
タの暗号化が行われない場合、証明書に記載される対象者等の情報によるトレーサビリティの問題が発生する。
・C-V2X において、アプリケーションデータの送信者と、物理的なクルマや路側器との対応関係について整理が必要となる。例えば、路側器の機器認証は、ユースケースに依存しないが、ク
ルマと路側器間の授受されるアプリケーションデータは、各ユースケースを利用できる契約者
のみがデータを取り扱えるなど、認証の対象が異なることになる。
・C-V2X で規定されるダイレクト通信を実現する PC5 インタフェースでは、グループキャスト
やマルチキャストの機能が提供されるが、これらの接続形態でのアプリケーションデータに対して、秘匿性を要求する場合には、複数の通信相手間でセキュアに暗号化の鍵を共有・更新す116

るためのブロードキャストモードやグループキャストモードに対するグループ鍵管理方式を新たに規定する必要がある。
上記の要件を図 5.2.60 参照に示す。

図 5.2.60

Connected Vehicle1 における 5G C-V2X のセキュリティ要件

概要図

5.2.3.5.4. 5G Americas における C-V2X セキュリティ検討
5G Americas は、大手通信サービスプロバイダーやメーカーで構成される業界団体であり、同団体の目的は、アメリカ大陸におけるエコシステムのネットワーク、サービス、アプリケーション、
コネクテッドデバイス全体を通じて、5G とその先の進歩を提唱し、促進することである。上記 5G
Americas において白書「Privacy by Design Aspects of C-V2X」(2020.10)[52]および 「VehicularConnectivity: C-V2X & 5G」(2021.09)[53]が公開されている。本節では、これらの白書に記載されたセキュリティ要件について概説する。
「Privacy by Design Aspects of C-V2X」(2020.10)では、C-ITS(Cooperative ITS)で規定され、自動車から定期的に同報される自動車の位置や、スピードを含むメッセージとして、Cooperative
Awareness Message (CAM)、Decentralized Environmental Notification Messages(DENM)に焦点を当て、そのメッセージの保護とプライパシについて要件をまとめている。プライバシーの要件は以下のとおりである。
・必要最小限の情報提示
ユーザが通信で明らかにする情報量は最小限にとどめるべきである。
・条件付きの匿名性
個々の車両は、潜在的な参加者の集合内で匿名であるべきである。
117

・非リンク性
特定の車両の異なる仮 名を相互にリンクできないようにする。
・前方及び後方プライバシー
クレデンシャルの失効は、以前に署名されたメッセージのリンク不能性には影響しない。また、攻撃者が特定のクレデンシャルの送信者の身元を回復しても、同じ送信者によって署名された他のメッセージのプライバシーに影響を及ぼすべきではない。
さらに上記のプライバシー要件を実現する技術要件が以下の表 5.2.25 のとおり整理されている。
表 5.2.245 プライバシー要件を実現する技術要件
プライバシー要件

技術要件

必要最小限の情報提示

明示的に車両を識別しない
疑似識別子は一時的なものにする
車両識別情報（車両寸法など）は丸める

条件付きの匿名性システムは、不正な車両を特定し、適切に措置するべきである。

リンク不能性仮名変更特性：仮名は一定期間使用されるべきであり、仮名の変更を可能にするために、車両は複数の仮名を利用できるべきである。
仮名が変更された場合、下位レイヤーの伝送動
作が変更されるべきである。

前方及び後方プライバシー

現在および将来の期間の証明書は失効する。
過去の期間に署名されたメッセージはリンクできない。

また、仮名 ID を用いたプライバシーのソリューションについては、自動車 OEM コンソーシアムと米国運輸省（USDOT）が提案したセキュリティ・クリデンシャル管理システム（SCMS）、欧
州標準化委員会（CEN）と欧州電気通信標準化機構（ETSI）が開発した協調 ITS 証明書管理シ
ステム（CCMS）を参照している。本件については、次節にて詳述する。
「Vehicular Connectivity: C-V2X & 5G」(2021.09)においても、以下に示すセキュリティ要件が記載されている。
（１） サンドボックス
C-V2X で不正なデータの受信による攻撃を防止するために、機器が受け付けるデータの種類を意図的に制限する。具体的には、アプリケーション ID（AID）を標準化し、送信時に AID に対応するアプリケーションのみがデータを受け付ける。各メッセージは特定のアプリケーション用であり、そのアプリケーションによってのみ処理されるため、他のアプリケーションや車両内の他のコンポーネントへの波及を防ぐことができる。ここ118

で、AID は、米国では Provider Service Identifier（PSID）、ETSI/ISO システムではIntelligent Transportation Systems Application Identifier（ITSAID）を用いる。
（２） 認証C-V2X において、メッセージ認証は PKI に基づき行われるが、個別の機器の数は膨大で、即時の認証が困難となるため、個々の機器を認証せず、アプリケーション（AID）
を認証する方式を用いる（図 61 参照）。これにより、正当なアプリケーションから生成されたデータを確認するとともに、個々の機器が認証時に追跡が可能となるプライバシ
ーの課題を回避できる。
（３） 認証に用いる暗号技術
C ~V2X では、通信帯域が限られているため IEEE1609.2 では、楕円曲線暗号に基づく
コンパクトな形式を用いる。
（４） 誤動作検知
誤動作検知は、アプリケーショ ンに対するすべての受信メッセージが適切であることを確認するプロセスである。メッセージがセンサー・データ、同じ送信者からの他のメッ
セージ、あるいは他のセンサーからのメッセージと一致しない場合、拒否される。
（５） プライバシー保護
メッセージ内に利用者 ID を含めず、利用権限のみを用いることで、利用者のプライバシーを確保することができる。また、車両の追跡を防止するために複数の証明書を発行し利用する場合がある。欧州では、１週間で 60 から 100 枚の証明書を発行する。

図 5.2.61

C-V2X における AID を用いたメッセージ認証

5.2.3.5.5. V2X におけるデータの信頼性とプライバシー保護の海外動向調査
本節では、白書の課題で指摘した V2X で送信されるメッセージの信頼性確保や、プライバシー
保護技術に関する海外動向について述べる。V2X のメッセージの信頼性を確保するため、PKI によるメッセージ認証を用いることが可能である。しかしながら、PKI の証明書自身には、証明書
119の保有者などの情報が含まれるため、特定の車両の位置情報を追跡することが可能となる（図 62参照）。このような PKI の利用において、内包するプライバシーの問題を解決する技術として、短期間の仮名を用いる方式が検討されている。各車両は、頻繁に更新される複数の仮名を使用することで、位置情報のプライバシーが保護される。このような手法は、複数の組織で検討が進められている。例えば、自動車 OEM コンソーシアムと米国運輸省（USDOT）が提案したセキュリ
ティ・クリデンシャル管理システム（SCMS）[54], [55]、欧州標準化委員会（CEN）と欧州電気通信標準化機構（ETSI）が開発した協調 ITS 証明書管理システム（CCMS）、CCSA(China
Communications Standards Association)が開発した中国の C―SCMS などがある。いずれの仕様もプライバシー保護を実現するため有効期限が短い仮名証明書(pseudonym certificate)を利用、定期的に更新することで、追跡を困難にする。しかしながら、車両は、大量の証明書を保存する
ことや、バックエンドに頻繁に接続することが困難な場合がある。従って、大量の仮名証明書の管理（発行、保管、失効管理）の課題手法を解決する必要がある。

図 5.2.62

CV で電子証明書を用いる際のプライバシー課題

図 5.2.63 に、PKI に基づく V2X クリデンシャル管理システムの基本構成と手順を示す。
(1) 車両を登録して、登録用認証局に、登録証明書を発行してもらう。（図中①、②）(2) 仮名証明書認証局(PCA)に、仮名証明書を発行してもらう（図中③、④）(3) 車両（送信側）が、仮名証明書を用いて V2X メッセージに署名を行い、送信（図中⑤、⑥）(4) V2X メッセージを受信した車両（受信側）が、仮名証明書を用いて、メッセージを検証（図中⑦）(5) 一定期間の後、車両（送信側）が、仮名証明書を更新（図中⑧）(6) 車両（受信側）が、不正な仮名で署名されたメッセージを受信した場合、不正利用用認証
局(MBA)に通知、不正利用用認証局(MBA)は、不正利用の情報を失効用認証局(RA)に転送する。失効用認証局(RA)は、仮名の失効要求を仮名証明書認証局(PCA)に通知し、その返信として ID 情報を取得し、失効リストを更新する（図中⑨-12）。
120

(7) 車両（受信側）は、適宜、失効用認証局(RA)から、失効リストを入手する（図中 13）。
上記の手順においては、５つの認証局を運用する必要があり、システム全体が複雑化することが指摘されている。

図 5.2.63

PKI に基づく V2X クリデンシャル管理システムの基本構成と手順

上述のような多数の仮名証明書を車載器で管理することは、現実的ではない。このため米国運輸(USDOT)では、車載器で、任意の数の公開鍵を効率的に生成できる Butterfly Key Expansion という方式を提案している。本方式は、公開鍵暗号における１組の秘密鍵と公開鍵のペアから、複数の秘密鍵と公開鍵の拡大鍵のペアを作成できるアルゴリズムである。本方式により多数の仮名証明書(OBE Certificate)を効率的に発行できるようになる。すなわち、図 5.2.64 に示すように車載器においては、オリジナルの秘密鍵を、秘密鍵シードを用いて拡大し、複数の秘密鍵を作成する。一方、オリジナル秘密鍵に対応するオリジナルの公開鍵と公開鍵シードを登録局に送付する。
登録局では、秘密鍵シードに対応する公開鍵シードを用いて車載器から送られてきた公開鍵を複数の公開鍵に拡大する。この拡大された複数の公開鍵に対して仮名認証局が署名を行い複数の仮名証明書を発行する。本方式により、車載器と登録局間の制約のある通信帯域においても効率的に任意の数の仮名証明書を作成することが可能となる。

図 5.2.64

多数の仮名証明書の発行手法(Butterfly Key Expansion)
121

また、SCMS では、多量に発行した仮名証明書の失効管理の課題を解決する手法として、仮名証
明書にリンク値（Linkage Values）を挿入する方式を提案している。本方式は、図 5.2.65 に示す
通り、ハッシュチェーンを用いて、リンク値に連鎖と順序性を与えることにより、ある時点の仮名証明書をさせると、その仮名証明書に埋め込まれたリンク値に連鎖するその後の全ての仮想証
明書を効率的に失効させることが可能となる。

図 5.2.65

仮名証明書を一括して失効する方法（Hash Chain ）非中央集権的なメッセージの信頼性およびプライバシー保護方式
先述の通り、図 5.2.63 に示す PKI に基づく、中央集権的な仮名証明書の方式は、システムが複雑になる課題が指摘されている。本課題を解決するため、車載器に TC（Trusted Computer）を
信頼の起点（Root of Trust）として導入することによる非中央集権的な仮名の管理方式が検討されている。本アーキテクチャの基本概念は、DAA (Direct Anonymous Authentication)と呼ばれる方式に基づく。DAA は、リモート認証プロセスにおける利用者のプライバシー強化のためのグ
ループ署名を用いた暗号プロトコルであり、TCG（Trusted Computing Group)で採用された。本
技術を V2X 環境に適用することにより、複雑で中央集権的な PKI ベースのバックエンド基盤から、信頼の起点を車両に TC を搭載して車両自体にシフトする分散型アプローチが検討されている[56]。
図 5.2.66 に示す通り、非中央集権的な仮名の管理方式は以下の手順となる。

図 5.2.66

非中央集権的なメッセージの信頼性確保及びプライバシー保護方式の概要

122

(1) セットアップ・参加に手順により、発行者は、TC の正当性を確認し、後に仮名を作成する
ためのクレデンシャルを生成する。このクレデンシャルに車両の情報は一切含まれない。また、TC の署名鍵は車両とリンクされておらず、発行者によってブラインドで認証されるため、検証車両が仮名を TC の身元、すなわち車両の長期的な EC（Enrollment Certificate）とリンクさせることは不可能である。（図中①、②）(2) 車両は、失効用認証局(RA)に登録された後、仮名を使用することができる。（図中③、④）(3) 車両（送信側）が、仮名を用いて V2X メッセージに署名を行い、送信する（図中⑤）(4) V2X メッセージを受信した車両（受信側）が、仮名に対応するグループ公開鍵を用いて、メッセージを検証する（図中⑦）(5) 車両（受信側）が、不正な仮名で署名されたメッセージを受信した場合、不正利用用認証局(MBA)に通知、不正利用用認証局(MBA)は、不正利用の情報を失効用認証局(RA)に転送する。失効用認証局(RA)は、仮名の失効要求を TC に通知し、TC 内にある該当する仮名を失効する（図中⑥-⑧）
本方式の匿名性は、DAA のグループ署名方式に基づく、図 5.2.67 に示す通り、グループ署名とは、グループに所属する車体が作成する署名には、署名者を特定する情報は含まれず、かつ、その署名が、グループに所属する正しい署名者によって作成されたことを、署名の受信者がグルー
プ公開鍵を用いて検証できる方式である。

図 5.2.67

グループ署名の鍵管理イメージ図 56

従来の PKI ベースの方式ともう一つの重要な違いは、大規模な証明書失効リスト（CRL)が不要
な失効プロセスを実現している点である。具体的には、仮名は、失効用認証局(RA)に登録され、かつ失効されていない限り TC は、仮名を使用できない。また、RA により仮名を失効するとその情報が車側に通知され、該当する仮名の状態を更新する（失効させる）。このように、仮名の使用可否は、RA が管理する仮名の失効状態と完全に同期しており、TC による仮名の使用可否が、厳密に制御できる。従って、本方式により、PKI に必要となる CRL の配布・管理が不要となり、大規模なシステムへの適用が可能となる。さらに、仮名は、登録時にハッシュ化されるため、例え、TC が２つの仮名を使用しても、RA はその 2 つの仮名の紐付けは困難となる。
5.2.3.6. 認証機能
5.2.3.2 節から 5.2.3.5 節にかけて、Connected Vehicle のユースケースにおいて、5G の機能に着目してセキュリティの課題を整理しているなかで、共有のセキュリティ課題として認証がある。
123

本節では、上記の検討におけるセキュリティ課題を認証の視点でまとめる（図 5.2.68 参照）。


クルマによる認証
クルマが、ドライバー及び同乗者を認証する。



モバイル通信事業者による認証
モバイル通信事業者が、モバイル網に接続するクルマを認証する。ここでは、クルマの利用者（ドライバー及び同乗者）は、クルマが認証することを想定しており、クルマに装備された通信モジュールをモバイル事象者が認証することを想定している。



ネットワークスライス提供者による認証
ネットワークスライス提供者が、ネットワークスライスの利用者を認証する。Connected
Vehicle のユースケース（サービス）毎に求められるネットワークやセキュリティの品質が異なるためネットワークスライス提供者は、サービス事業者の可能性がある。また、Connected Vehicle のユースケースは、クルマの機種に依存する可能性があるため、ネットワ
ークスライス提供者がクルマを認証する。



MEC 基盤による認証
MEC 基盤提供者が、MEC 基盤の利用者を認証する。また、Connected Vehicle のユースケー
スは、クルマの機種に依存する可能性があるため、MEC 基盤提供者がクルマを認証する。



MEC アプリ提供者による認証
MEC 基盤提供者が、MEC 基盤の利用者を認証する。また、Connected Vehicle のユースケー
スは、クルマの機種に依存する可能性があるため、MEC 基盤提供者がクルマを認証する。



クルマ（V2V）/路側器（V2I）/歩行者（V2P）による認証
V2X は、クルマ、路側器、歩行者がクルマを認証する。

サービス提供者による認証
サービス提供者が利用者を認証する。サービスは、クルマの機種に依存する可能性があるた
め、サービス提供者がクルマを認証する。

124

図 5.2.68 Connected Vehicle における各認証のイメージ図
サービス提供者は、サービス特有のネットワークやセキュリティの品質を提供するためにネットワークスライスを利用、MEC アプリを提供する可能性がある。この場合は、サービス提供
者、ネットワークスライス提供者、MEC アプリ提供者が同一のケースが想定される。
5.2.4. むすび
以上、Connected Vehicle におけるセキュリティについて、関連標準やフォーラムでの検討を踏まえ、5G ネットワークでのセキュリティの課題について整理を行った。3GPP や ETSI で検討されている 5G のセキュリティ機能については、現在進行形であり、今後、変更や仕様の具体化が想定される。これらの進捗を踏まえてセキュリティ課題の具体的な対策を検討していく予定である。

125

5.3. ユースケース Fintech セキュリティ
5.3.1. はじめに
5G の進展でこれまでの営業窓口を主体とした金融サービスから、Fintech 企業などの異業種と、既存の金融機関がネットワーク上で連携した新たな Fintech サービスの創出や発展が見込まれている。
その一方、多くのプレイヤーが連携することにより各事業者間の相互認証・認可や事業者が変わる都度、ユーザ認証を求められるケースが想定されるため、ユーザの利便性を留意しながら、
セキュリティを検討することが重要となる。
本章では、Fintech において実現される各種サービスに対するセキュリティ課題を整理し、5Gにて検討すべきセキュリティ要件を明確化する。
5.3.2. 5G における Fintech サービス
本節では、Fintech におけるセキュリティ課題の検討に先立って、現状の Fintech サービスを調査し、5G における Fintech サービスの全体像を明らかにする。
5.3.2.1. 主な Fintech サービス
図 5.3.1 で示す通り、Fintech サービスは、大きく個人向けサービスと企業向けサービスでの分類と、金融商品サービスと決済サービスとで分類することができる。

図 5.3.1 主な Fintech サービス
5.3.2.2. 5G における金融サービス
これまでの金融サービスは、金融機能の一部機能を Web など活用することで、ユーザの利便性を向上させる取り組みに限られてきた。
例えば、以下のサービスがそれに相当する。

126

・銀行窓口の対応にインターネットバンキングを導入し、インターネット上で残高照会、振込み、送金サービス・物理的なカードでの店舗決済からモバイル端末を活用した店舗・ネット決済サービス
・ロボットアドバイザを活用した資産管理サービス
今後、5G の進展に伴い、図 5.3.2 で示す通り、異業種間サービス連携し、異業種のデータを活用した新たなサービス創出と、ユーザ毎に最適なサービス提供の拡大が期待されている。
例えば、今後、以下のサービスが想定される。
・利用・行動データに基づく本人認証サービス
・決済情報からの融資サービス
・運転状況に応じた保険サービス
・保険と連携し、健康生活で健康食品の割引サービス
・使用量・時間に応じた課金サービスなど

図 5.3.2 5G における Fintech サービス

127

5.3.3. Fintech 企業及び関連団体との連携
5G における Fintech サービスへの期待等について Fintech 企業及び関連団体にヒアリングを行った。
5.3.3.1. 株式会社 ACSiON
セブン銀行系の認証サービスベンターの株式会社 ACSiON は、以下の事業を提供している。
・本人確認プラットフォーム事業「proost（プルースト）」
顔写真付本人確認書類の撮影データと本人の写真データを画像処理技術により照合する仕組みを提供。その他取得可能な情報と組み合わせることで厳格な本人確認を実施。
・プラットフォーム事業「Detecker（ディテッカー）」
AI を用いたビッグデータ分析により、不正申込みや不正アクセスを 24 時間 36
5 日監視、検知する仕組みを構築。
(1)サービス概要：プラットフォーム事業「Detecker（ディテッカー）」
セブン銀行のノウハウなどを活用。利用企業がエンドユーザーに提供する商品・サービスへの入会から利用まで、各取引段階に応じた不正検知を知らせるサービスとなる。

出典：株式会社 ACSiON の Web サイト
図 5.3.3 サービスイメージ
a.目指すもの・不正アカウント開設等の不正検知の共通プラットフォームとして、利用企業間で情報を共有
し、安心・安全なサービス提供を全社横断
・利用企業各社の不正利用を検知・防止するとともに、その事例を蓄積することで、より強固なプラットフォームの構築

128

b.取り扱う不正の事例•

Web 申込み（口座開設、カード入会等）における虚偽申込み•

会員サイトにおける不正利用（なりすまし等）•

インターネットバンキングにおける不正利用（アカウントの第三者利用等）•

EC サイトにおける不正購買(2)5G への期待
本当の本人であるかを検証する仕組みとして顔認証以外に以下の認証を組み合わせることでより強固な認証の実現。
・5G の低遅延の特性を活かし、行動をモニタリングや端末間の高速な認証データのやり取り
・5G の高周波数 28ＧＨｚの電波指向性を活かした正確な位置把握

図 5.3.4 5G における強固な本人認証

129

5.3.3.2. 一般社団法人 Fintech 協会との連携(1)一般社団法人 Fintech 協会の概要
a.概要
国内外の関連諸団体、関係省庁等との情報交換や連携・協力、活動を通じて、オープンイノ
ベーションを促進させ、新たな Fintech サービスが生まれやすい環境を整え、健全な業界の発展と Fintech エコシステムの活性化、および世界の金融 IT 業界における日本のプレゼンス向上に貢献することをミッションとしている。協会には、様々なジャンルの Fintech スタートア
ップ約 130 社及び、金融機関、通信事業者、製造業など約 270 社が参加している。
b.分科会
以下のような分科会がある。
表 5.3.1 Fintech 協会 分科会一覧

出典：Fintech 協会の Web サイト(2)5G への期待
今回、第20回API・セキュリティ分科会に出席し、「第一部5GとFintechについて」プレゼンテーション及ぶ、パネルデスカッションに参加。株式会社 企 クロサカタツヤ氏からは、センサ
ーと5Gが連携することで、ヒト、活動、場所・環境をリアルタイムにデータ化し、ヒトを含めたデジタルツイン化が図られる。それにより、Fintech分野におけるビジネス機会として、リア
ルタイムデータによる「スコアリング」サービス、キャッシュレスから、人が意識しないで決済される「ペイレス」サービス、通信とファイナンスが連携した本人認証サービス、人から物の認証による新たなファイナンスサービスなどが想定されるなど、説明がありました。

130出典:(Fintech協会API・セキュリティ分科会第20回,「5GとFintech」, 株式会社 企, クロサカタツヤ

図 5.3.5 5G におけるサービスイメージ
5.3.4. 5G における金融サービスとセキュリティ検討ポイント
ここでは、5G で想定される金融サービスを示す。
5G で想定される金融サービスとして、車との連動した金融サービスなどを提供する「異業種連携取引分野」、個人の日々の行動に応じて金融サービスが変化する「パーソナライズされたよりき
め細かいプライベート取引分野」、実際の「使用量に応じた柔軟な決済分野」、株取引などにおける「高速取引分野」などがあげられる。
表 5.3.2 5G で想定される金融サービス
金融サービス#1

異業種連携取引分野
例1)コインパーキングに⾞を⽌める・移動で⾃動⽀払い
例2)⾞の使⽤頻度、運転状況に応じたIoT保険

2

パーソナライズされたよりきめ細かいプライベート取引分野
例1)⽇々の買い物、利⽤頻度、健康度などに応じたダイナミックプライシングの実現やアドバイス
例2)⾛⾏距離に応じたガソリン価格変動
例3)ロボット・アドバイザーサービス(例︓スマホで⽇々の⽣活データからポートフォリオ管理や投資アドバイスなどのデジタル⾦融窓⼝)

3

使⽤量などに応じた柔軟な決済分野
実際に利⽤した時間などでチャージ。本のページ数での課⾦など
例1)使⽤頻度ではなく、時間・感動で料⾦を払う
例2)服を着ただけ払う

4

⾼速取引分野例1)株取引などにおける⾼速取引

これらのサービスを実現するためには、図 5.3.6 で示すセキュリティ検討ポイントで示す通り、異業種サービス・データ（API）連携を実現する「サービス事業者間認証」や、利用者端末とネットワーク上で異業種との「リアルタイム連携できる個人認証」の仕組みが必要となる。

131

図 5.3.6

セキュリティ検討ポイント

5.3.5. サービス事業者間認証における課題と運用者要考慮事項
5.3.5.1. 金融機関のサービスモデルの変化
従来、金融機関は垂直統合型で均一的な顧客サービスを自行で提供してきたが、マネーフォワードなどユニークなサービスを展開する Fintech 企業などの異業種が登場し、改正銀行法の施行があり、多くの金融機関が API を公開するようになってきた。

図 5.3.7

金融機関のサービスモデルの変化

5.3.5.2. 改正銀行法
2017 年 5 月 26 日「銀行法等の一部を改正する法律」が成立し、2018 年 6 月 2 日に公布された。背景として、Fintech 企業は顧客の同意の上で、顧客から入手した情報を用いて金融機関の口座にアクセスし、情報を取得しているが、以下のような問題点がある。
・セキュリティ上の問題
132

ID/パスワードといった個人認証に関する情報を金融機関以外の事業者が保持して金融機関のサービスにアクセス
・口座情報取得の技術的な問題
金融機関から口座情報を照会する際の API が公開されていないため、Fintech 企業は金融機関の Web サイトを解析して情報を取得
・オープンイノベーションにおける問題
Fintech 企業の法的位置付けが不明確なため、金融機関にとってセキュリティ面の不安や、
Fintech 企業に金融機関が高いセキュリティレベルを要求されるなど、提携が進まない・オープンAPIの体制整備に努める
FinTech企業などとの連携・協動にかかる⽅針・基準の策定・講評

連携・協動が進み難い

代理ログイン

サービス利⽤を申請サービス連携取り決め

FinTech企業

FinTech企業
ID、PWは預けない
ID、PWを預ける

ID・PW

法的位置付けが曖昧

責任が曖昧

安全なサービス
環境提供

施⾏前

・登録制
・情報の適正管理・業務管理体制の整備など

施⾏後

図 5.3.8 改正銀行法
5.3.5.3. 金融オープン API に用いられる認可プロセス例
オープン API を安全に活用するため、ユーザが金融機関にアクセスする権限を Fintech 企業に認可を与える。次に、金融業界などでは、オープン API の認可を行う仕組みとして「OAuth2.0」のプロトコルが推奨される。

図 5.3.9

金融オープン API で用いられる認可プロセス（OAuth2.0）のフロー例

133

5.3.5.4. 現行の金融 API 対象業界
現在、金融 API を活用している業界を以下に示す。基本、個人が利用するパソコン、スマートフォン向けのサービスとなる。
表 5.3.3 金融 API 利用状況

134

5.3.5.5. IoT デバイスにおける金融サービス例
今後、5G が普及することで自動車、家電など向けに金融サービスが提要されることが想定される。
表 5.3.4 5G で想定される Fintech サービスと IoT デバイス

5.3.5.6. IoT デバイスにおける金融オープン API のセキュリティ課題
5G における IoT デバイスを考慮すべき、主なセキュリティ課題について、金融オープン APIの認証プロセスを参考とし、示す。
(1) IoT デバイスへの攻撃：不正アクセス、改ざんと成りすましなど(2) エンティティ間での通信路上の攻撃：通信データの盗聴・改ざんなど(3) Fintech 企業及び、金融機関システムへの攻撃：システム、ネットワーク機器の脆弱性、
DDoS 攻撃など

図 5.3.10 金融オープン API におけるセキュリティ考慮ポイント135

5.3.5.7. セキュリティ考慮ポイントに対する運用者要考慮事項(1)IoT デバイスへの攻撃①クレデンシャル情報等の漏えい、改ざん
IoT デバイスの場合、誰からでもアクセスできる環境に設置されているケースが考えられるため、物理的な手段での解析/操作の可能性が増す。通信事業者は、ネットワークの接続時の認証に用いる契約クレデンシャルは、耐タンパ性を備えたクレデンシャルストレージ機能を活用し、セキュア・ストレージに格納している。運用者は、独自のクレデンシャル情報を IoT デバイスで管理・運用する際は、同様に耐タンパ性を備えた認証デバイスに格納することが望ましい。
②IoT デバイスの長期利用
携帯電話、スマートフォン等は、数年おきに機種変更されるため、その際に SIM カードの交換ができるが、5G の「超多数接続」という特徴を活かして普及が見込まれる IoT デバイスの運用期間が長く、SIM カードの交換自体が困難なケースが想定される。現在、SIM カードには、ユーザ認証のための秘匿鍵が格納されているが、これまでは SIM カードの製造時に書き込んでおり、書き換えることはできなかった。そのため、セキュリティリスクが発生した際には SIM カードを交換する必要があった。そのため、このような背景から 5G の SIM カードでは、オンラインでの書き換えが可能となっている。
(2)エンティティ間での通信路上の攻撃
5G ではネットワークスライシングが導入され、ネットワークを仮想的に独立したスライスに分解し、個々のスライスでは他スライスに悪影響を与えることなく利用できるようになり、サービスに適した暗号アルゴリズムを適用できる。例えば、IoT デバイスの場合、バッテリーによる長期間の稼働が必要となる場合があるため、軽量暗号など低電力消費アルゴリズム等の活用が可能となる。
なお、ネットワークスライシングのセキュリティについては、3GPP SA3 Phase2 にて検討を行っており、セキュリティに関する検討項目は、4.2.4.3.1.節の通りである。
(3)Fintech 企業及び、金融機関のシステムへの攻撃
プレイヤーに対するアプリケーションレイヤー及びネットワークレイヤーにおける認証/認可やサービスで集積された各種データのアクセス制御の検討が必要となる。5G においては、セカ
ンダリ認証を用いることでサービスに対するアクセス制御ポリシーに基づく安全なアクセス可否判断を一元管理することが可能となる。中央集権的機能を持たない直接通信型の通信形態に関しては AKMA を用いることで安全な認証を実現できる。
また、Society5.0 の実現に向けて、サイバー空間の自由で安心・安全なデータの流通を実現する
ためには、データの信頼性を確保する仕組みとして、データの改ざんや送信元のなりすまし等を防止するトラストサービスが不可欠である。金融オープン API サービスにおいては、利用者、
IoT デバイス、ネットワーク、Fintech 企業などのサービス提供事業者、金融機関がプレイヤーとして想定される。サイバーセキュリティ対策の観点から、通信チャネルに対する攻撃を想定した対策として、それぞれのプレイヤー間で信頼関係を構築し、セキュアネットワークを通じたデータ授受を実現する必要がある。
現在、総務省では、「プラットフォームサービスに関する研究会」の下に「トラストサービス
検討ワーキンググループ」を設置し、2019 年（平成 31 年）１月から、以下のようなトラストサービスに関する現状や課題について検討が進められている。
・人の正当性を確認できる仕組み（電子署名）
・組織の正当性を確認できる仕組み（組織を対象とする認証、ウェブサイト認証）
・IoT デバイス等のモノの正当性を確認できる仕組み
・データの存在証明・非改ざんの保証の仕組み（タイムスタンプ）・データの送達等を保証する仕組み（e デリバリー）

136

5.3.6. リアルタイム認証におけるセキュリティ課題と運用者要考慮事項
5.3.6.1.

これまでの認証方式の課題

従来の個人認証では ID/パスワードや署名、近年では、生体情報等が求められる。しかし、これらの情報を入力することはユーザにとって負担となる。例えば、医療従事者、設備機器の保守従事者等が該当する。また、生体認証の場合、個人が携帯している媒体に認証に必要となる生体情報が保持しているケースが多く、クローズドなサービスに限定され、5G のような多様な事業者間データ連携するケースには、不向きである。そのため、ユーザの利便性から、携帯電話、ICカードなどに格納されたユニークな ID を利用するケースが増えている。一方でこのような認証方法は、ユーザにとって利便性が高いが容易に成りすまされる可能性がある。
5.3.6.2.

5G における本人認証の可能性

5G によって、高速・大容量化でセンサー、GPS、購買データなどの行動の認識・特定や、画像認識によるオンラインでの人物の認識・特定が可能になると想定される。例えば、東京大学大学院情報理工学系研究科ソーシャル ICT 研究センターでは、“MITHRA”プロジェクトとして、
スマートフォンやウェアラブル端末の位置情報等のビックデータを解析することで、ユーザを認証するライフスタイル認証の研究・検討を進めている。

参考資料：東京大学「ライフログを利用したライフスタイル認証技術」の Weｂサイト
図 5.3.11 入出力系から見たライフスタイル解析イメージ
5.3.6.3.

ライフスタイル認証におけるセキュリティ課題

ライフスタイル認証を実現する上で以下のセキュリティ課題が想定される。
(1)エッジでの大容量の行動データの収集・解析
ライフスタイル認証を行うには、位置情報や、映像データなど膨大なデータを効率的に収集し、分析する必要がある。そのため、すべてのデータをクラウドに送信して処理するのではなく、ネットワークエッジ（ユーザに近い場所）でデータを収集、分析することで遅延が減り、広帯
域幅アプリケーションをリアルタイムで、実行する必要がある。この技術の規格の一つとして、
ETSI が標準化を進めている Multi-access Edge Computing(MEC)がある。MEC は、クラウド上のサーバの代わりにエリアごとに MEC プラットフォームを置き、そのエリアにある IoT デバイスへのレスポンスを早くするものである。MEC プラットフォーム上でデータ処理することで、IoT デバイスへのレスポンス時間の短縮化を図る。また、クラウドに上げるデータを最小限に限定できるため、データ通信量の減少にもつながるメリットがある。 一方で、アクセスネ
137

ットワークの境界に、コンピュータ資源やデータストレージを配備し、クラウドで処理する手間を MEC プラットフォーム段階で処理を行うため、IoT デバイスと MEC プラットフォーム
間でのネットワークや、複数プレイヤーの MEC プラットフォームへのアクセスに起因するセキュリティリスク（MEC プラットフォーム上の他プレイヤーのアプリケーションや、MEC プ
ラットフォームからの攻撃など）が想定される。
なお、MEC については、ETSI 以外に 3GPP にて検討を行っており、概要については、
5.2.3.4.節の通りである。
(2)端末識別子のトレーサビリティ防止
端末識別子によるトラッキング防止のため、IMSI に代わる TMSI が用いられるようになってきたが、IMSI を平文で送信する場合も損じしており、位置の特定や追跡される可能性が問題となっている。
(3)本人認証精度
GPS の位置情報等を解析することで、本人らしさを示すことができる。今後、更に 5G の進展に伴い、様々な行動データを収集・解析することで、本人性を向上させることが期待できる。
一方で、金融サービスにおける本人認証においては、より高い本人認証が求められる。
5.3.6.4. セキュリティ考慮ポイントに対する運用者要考慮事項(1)エッジ（MEC プラットフォーム）活用時のセキュリティ
MEC プラットフォームにおいては、なりすまし、データの改ざん、データの漏洩など、クラウド基盤と同様のセキュリティ対策が必要となる。例えば、IoT デバイスが直接、クラウドとの通信を行わず、MEC プラットフォームを経由するため、4.3.5.7 と同様にプレイヤーに対する
アプリケーションレイヤー及びネットワークレイヤーにおける認証/認可やサービスで集積された各種データのアクセス制御の検討が必要となる。
また、IoT デバイスから行動データをクラウド又は、MEC プラットフォームに対し、転送、更に IoT デバイスにそのアクションを返答する際には低遅延、高スループットなネットワークが要求される。５G の特徴であるネットワークスライシング機能を利用することで、これらネットワーク要件に適合する論理的なネットワークを安全に活用することも可能となる。
(2)端末識別子のトラッキング防止
5G では、IMSI に相当する「SUPI」という識別番号が SIM カードに登録されており、これをネットワーク・オペレータの公開鍵によってランダムに暗号化した「SUCI」で認証を行うことで、プライバシーの配慮がなされている。また、認証が完了した端末の識別番号には「GUTI」というテンポラリな ID が使われるが、移動体通信事業者によっては、長期の更新
がなされないケースがあり、5G では、定期的に変更するようより厳格に仕様で定められている。
(3)本人認証精度の向上
顔や指静脈認証などの生体認証との組み合わせが想定される。ただし、生体認証を利用に際して、以下の課題が残されている。
a.複数のサービス間の共通利用
138これまでの生体認証システムは、指紋、静脈、瞳の虹彩などの生体情報を単一のシステム内で管理して安全性を確保。複数のシステムで共通の生体認証を使うには、システムごとに生体情報を登録する必要があり、登録の煩雑さが生体認証の普及を阻害する要因となっている。
b.生体情報のプライバシー・セキュリティの確保
生体情報は、人種、民族、健康状態などの特定の可能性があるセンシティブな情報のため、プライバシー保護の観点から、厳重な管理が求められる。生涯不変で破棄・更新できない情報であり、ひとたび漏えいして生体偽造などの脅威が発生した場合、安全性の回復が非常に困難である。このような脅威から利用者を守るため、生体情報の漏えい防止が大きな課題となる。
このような課題解決の一つとして、日立製作所のテンプレート公開型生体認証基盤（PBI）を活用が想定される。生体認証に用いる静脈や指紋などの生体情報を、元データに復元できない公開鍵の形に変換し、生体情報を用いた電子署名により本人認証を行う仕組み。従来の PKI(Public Key Infrastructure)による認証システムでは、IC カードなどに電子証
明書を鍵情報として格納していたため、これを厳重に管理する必要があった。本技術を用いたシステムでは、生体情報に対して一方向性変換(順方向の変換は容易に計算可能だが、逆方向の変換は計算困難である変換関数)をした情報を認証時につど生成して鍵情報として使うため、ユーザは鍵情報の管理が必要なく、生体情報を復元することは不可能となる。
また、従来、生体情報の安全性を確保するためにクローズドな環境で個別に構築していた認証機能について、PBI を適用することにより、クラウド上に配置し複数の業務サービスで共通利用することが可能となる。

出典：日立製作所の Web サイト
図 5.3.12

テンプレート公開型生体認証基盤（PBI）概要
139

5.3.7. リアルタイム認証のユースケースに関する追加の調査と検証結果
現在、行動データによる認証を研究・開発している企業などと連携し、課題や５G におけるニーズを調査すると共に、2020 年度のユースケースの検討結果に対し、評価・検証を行った。
5.3.7.1. ユースケースの追加の調査
a.東京大学大学院情報理工学系研究科ソーシャル ICT 研究センターと、ライフスタイル認証関する社会連携講座を設置している日立製作所とデスカッションを実施した。
現状の課題としては、日頃の生活の中での認証であれば、活用できるが旅先などで日頃と異なる行動を行った場合（出張、旅行）は、認証が難しい。その場合、生体認証や本人しか知り得ない情報を使った本人認証が必要となる。また、行動が似ている人同士。例えば、勤務先が同じで、住まいが同じ寮の場合、認証が難しくなる。
５G の活用として、持ち歩きながら、一定間隔でリアルタイムによる本人かどうかを確認する必要があるネットバンキング中などのケースが想定される。また、IoT 工場において、正しく製品が作られているか。作業員の特定、設計書通りにモノが作られているか、試験・検査など
ブロックチェーン上に保管するケースが想定される。
b. 株式会社 AnchorZ とのデスカッションを実施した。株式会社 AnchorZ の DZ Security®
は、バックグラウンド認証®という、ログイン後も同一の本人が使用し続けているかどうかを判定する認証技術である。具体的には、スマートフォン利用時に自然に習得することができる
顔や声の生体情報に、ふるまい情報（デバイス利用時のクセ）などを付け加え、複数の要素をバックグラウンドで随時認識する。デバイス利用者が登録者本人かどうかを随時適宜、認証し続け、ログインにとらわれることなく「なりすまし」の脅威を防ぐことができる。ふるまい情報としては、デバイスと目の距離、デバイスの傾け方などの個人特有のクセが使用されている。また、認証に使われる複数のデータはすべて利用者端末内に保持されるため、サービス提
供者側で個人情報の保持が不要となっている。
※「DZ Security®」、「バックグラウンド認証®」は、株式会社 AnchorZ の商標または登録商標です。
※参照元：株式会社 AnchorZ の Web サイト
5.3.7.2. 行動データにおけるプライバシー問題
GPS データなどを活用することでプライバシー問題に抵触しないかの問題がある。そこで、位置情報を活用したサービスを行っている企業を調査した。現在、図 5.3.13 で示す通り、多くの企業が位置情報サービスに参入している。
また、これらの位置情報提供サービス会社が、外部企業に提供するデータは、事業者によって異なるが、位置情報以外に性別、年齢層、居住地、通勤先などが含まれている。その際、居住地、通勤先などは、GPS データによる推測となる。なお、それらのデータは、個人を特定しないように匿名加工されたものとなっている。

140出典：X-locations の Web サイト
図 5.3.13

ロケーションサービス企業一覧

5.3.7.3.検証結果
東京大学のライフタイル認証の結果から、現状、GPS データだけで本人認証は難しく、バッ
クグラウンド認証®にも使われている生体情報との複合した認証による本人認証精度を上げる必要がある。

また、バックグラウンド認証®にて使用されているスマートフォン利用時のふるまい情報は、本人認証する上で有効な情報の一つと言える。GPS データ以外にも生体認証やふる
まい情報など複数の認証を組みわせることで利用時の継続的な本人認証の精度向上が可能となる。
更に、今後、Beyond５G においては、GPS データ以外にも購買データなど様々なデータを付加することで精度向上が期待される。
なお、行動データの活用に関するプライバシーの問題については、新型コロナウイルス感染症（COVID-19)の際、密回避の参考情報として、主要地点の人出をＧＰＳデータから、ビックデー
タ分析が行われ、テレビなどを通じて国民に広く情報提供された。この分析に使用されるデータは匿名加工化されており、本人を特定するものではないため、個人の位置情報サービスの活用への抵抗感は過去と比較し、薄れてきている。また、合わせて本人の同意なく、本人認証以外への利用を制限するなどの対応も重要となる。
5.3.8. 決済・認証の標準化動向におけるモバイル通信の関係整理
5.3.8.1. FIGI(Financial Inclusion Global Initiative)による標準化動向調査
FIGI は、経済活動に必要な金融サービスをすべての人々が利用できるようにすることを目的に
ITU、世界銀行、国際決済銀行が連携し、金融全般のセキュリティ、金融サービスのデジタル ID、
電子決済取引に関する調査、テクニカルツール、および提言を行っている。その中のワーキングの一つである SIT(Security Infrastructure and Trust)ワーキングでは、モバイルにおける DFS(Digital Fintech Service)の脅威について調査を進めている。
141出典：FIGI の Web サイト

図 5.3.14

DFS エコシステムの脅威(ITU)概要

ITU(International Telecommunication Union)による USSD、SMS、IVR、STK、および NSDTに基づく DFS アプリケーションの脅威を図 5.3.15 に示す。

出典：ITU, Digital Financial Services security assurance framework
図 5.3.15 USSD、SMS、IVR、STK、及び NSD における DFS に対する脅威
5.3.9. 追加調査・検証による Fintech セキュリティのまとめ
これまで、5G における Fintech サービスについて、金融オープン API、ライフスタイル認証に関して、Fintech 企業、関連団体にヒアリングを行い、セキュリティの課題、セキュリティ考慮ポイントに対する運用者要考慮事項を整理した。本 5GMF 白書「5G ユースケースにおけるセキュリティ 第 1.0 版」発行後において、リアルタイム認証に関するユースケースの調査・検証、決済・認証の標準化動向の調査として FIGI のモバイルにおける DFS の脅威について調査
を行った。
142

政府は、サイバー空間と現実空間が一体化した社会(CPS(Cyber Physical Systems))を構築
し、経済発展と社会的課題の解決(Society 5.0)を実現する人間中心の社会を目指している。それには、サイバー空間と現実空間をシームレスでつなぐ安心・安全な決済・本人認証が不可欠である。現実空間では物理的なカギがあり、サイバー空間では一般的に ID やパスワードを使われている。それぞれの空間で複数のカギを使い分けていたのでは、シームレスな融合は、困難である。そのため、これまで検討してきた行動データなどによる本人らしさの認証と生体認証の複合認証がスムーズな認証・決済が有効となる。今後は、更にサイバー空間での行動など多岐にわたる行動データが収集・分析の対象にも含まれるため、認証精度の向上につながると考えている。
その際、ＮＦＴ、仮想通貨、ウォレットなどへの適用が期待される。
※NFT(Non-Fungible Token、非代替性トークン)：ブロックチェーンを基盤にして作成された代替不可能なデジタルデータのこと

143

6. 参照文献
6.1. ユースケース IoT セキュリティ[1] 5G における IoT セキュリティ, 5GMF セキュリティ検討アドホック資料, 2018 年
10 月[2] IoT セキュリティガイドライン, 経産省/総務省/IoT 推進コンソーシアム(IOTAC),
2016 年 7 月[3] 安全な IoT システムのためのセキュリティに関する一般的枠組, 内閣サイバーセキュ
リティセンター, 2016 年 8 月[4] IoT セキュリティ総合対策, 総務省, 2017 年 10 月
[5] サイバー・フィジカル・セキュリティ対策フレームワーク(案), 経産省, 2018 年 4 月[6] IoT 開発におけるセキュリティ設計の手引き, 情報処理推進機構(IPA), 2016 年 5 月& 2018 年４月改訂[7] IoT セキュリティ評価検証ガイドライン, 重要生活機器連携セキュリティ協議会(CCDS), 2017 年 6 月[8] IoT セキュリティガイド 標準／ガイドライン ハンドブック, 日本ネットワークセキ
ュリティ協会(JNSA), 2018 年 5 月[9] IoT セキュリティチェックシート, 日本スマートフォンセキュリティ協会(JSSEC),
2018 年 3 月[10] Draft NISTIR 8200 - Interagency Report on Status of International Cybersecurity
Standardization for the Internet of Things, 米国国立標準技術研究所(NIST), 2018年2月
[11] Baseline Security Recommendations for IoT in the context of Critical Information
Infrastructures, 欧州ネットワーク・情報セキュリティ機関(ENISA), 2017 年 11 月
[12] Security Guidance for Early Adopters of the Internet of Things, Cloud Security
Alliance (CSA), 2016 年 2 月[13] OWASP IoT Top 10, The Open Web Application Security Project (OWASP), 2018 年
12 月改訂[14] Technical Specification TS-0003 Security Solutions, OneM2M, 2018 年 4 月[15] IoT Security Guidelines, GSMA, 2017 年 10 月
[16] セキュリティ検討アドホック2018 年度活動について, セキュリティ検討アドホック事務局, 2018 年 11 月
[17] Key Points of 5G Security, Anand R. Prasad, NEC Corporation, 2018 年 7 月
http://pop.riverpublishers.com/opinions.php?id=19144

[18] 3GPP TR 38.913, “Study on Scenarios and Requirements for Next Generation
Access Technologies; (Release 15)”[19] 3GPP TR 22.186, “Enhancement of 3GPP support for V2X scenarios; Stage 1(Release 16)”[20] Catalin Cimpanu, “Newer Diameter Telephony Protocol Just As Vulnerable As
SS7,”

2018.07.02,

https://www.bleepingcomputer.com/news/security/newer-

diameter-telephony-protocol-just-as-vulnerable-as-ss7/[21] 3GPP TR 23.724, “Study on Cellular Internet of Things (CIoT) support andevolution for the 5G System (5GS) (Release 16)”[22] oneM2M - Home, https://www.onem2m.org/[23] Ace (Authentication and Authorization for Constrained Environments) Status
Pages, https://tools.ietf.org/wg/ace/[24] Open Weave, https://openweave.io/[25] SP-190711, “New WID Authentication and key management for applications basedon 3GPP credential in 5G”[26] 3GPP TR 33.805, “Study on Security Assurance Methodology for 3GPP network
products”[27] 3GPP TR 33.916, “Security Assurance Methodology (SCAS) for 3GPP network
products”

145

6.2. ユースケース Connected Vehicle セキュリティ[1]“Proposal for draft guideline on cyber security and data protection,”
WP29,2016.

[2]“Proposal for a Recommendation on Cyber Security,” WP29, 2020.

[3]“Draft Recommendation on Software Updates of the Task Force on Cyber
Security and Over-the-air issues,” WP29, 2018.

[4]“TTC TR-068 自動車の遠隔更新技術の標準化と実用化動向,” 2019.10.

[5]“Uniform provisions concerning the approval of vehicles with regards to cybersecurity and cyber security management system,” WP29, 2021.

[6]“Uniform provisions concerning the approval of vehicles with regards tosoftware update and software updates management system,” WP29, 2021.

[7]“自動走行システムにおけるサイバーセキュリティ対策,” 自動走行ビジネス検討会,
2019.

[8]

“Status of the Development of ISO/SAE 21434,” 25th European Conference,
EuroSPI 2018, 2018.

[9]“ITS の標準化 2018 ,” 自動車技術会

発行, 2018.

[10] CEN TC278 WG16 - CO-OPERATIVE SYSTEMS.
[11] “ISO21217: Intelligent transport systems - Communications access for land
mobiles (CALM) - Architecture,” 2014.
[12] “ISO16461: Intelligent transport systems — Criteria for privacy and integrity
protection in probe vehicle information systems,” 2018.
[13] “ISO21177: ITS station security services for secure session establishment andauthentication between trusted devices,” 2019.
[14] “TS21185: Intelligent transport systems — Communication profiles for secureconnections between trusted devices,” 2019.
[15] “ITS Forum RC-009 運転支援通信システムに関するセキュリティガイドライン,”
2011.
[16] “セルラー通信技術を用いた ITS・自動運転の高度化に向けた課題調査報告書,”
ITS 情報通信システム推進会議, 2019.
[17] “ITU-T X.1371: Security threats to connected vehicles,” 2020.
[18] “ITU-T X.1373: Secure software update capability for intelligent transportation
system communication devices,” 2019.
[19] “Network Equipment Security Assurance Scheme Overview Version 0.3,”

146

GSMA, 2016.
[20] “The GSMA will work with ENISA to secure 5G networks,” GSMA, 2020.
[21] “Cybersecurity of 5G networks - EU Toolbox of risk mitigating measures,” EU,
2020.
[22] “自工会/部工会・サイバーセキュリティガイドライン V2.1,” 自工会/部工会, 2023.
[23] 香月伸一, “ISO/TC204 における ITS の国際標準化動向,” JARI Research Journal,
2017.
「Network Equipment Security Assurance Scheme (NESAS)」,” GSMA.
[24] “[25] “ISO27011（ITU-T X.1051）Information technology — Security techniques —Code of practice for Information security controls based on ISO/IEC 27002 fortelecommunications organizations,” 2016.
[26] “ISO27017 (ITU-T X.1601) Information technology — Security techniques —Code of practice for information security controls based on ISO/IEC 27002 forcloud services,” 2015.
[27] Connected Car 社会の実現に向けた研究会, 総務省.
[28] “General Principle and Vision White Paper Ver 1.0.0,” AECC, 2017.
[29] Claudia Campolo, Antonella Molinaro, Antonio Iera, Francesco and Menichella
Antonella, “5G Network Slicing for Vehicle-to-Everything Services,” IEEE
Wireless Communications, 2017.
[30] “TR22.891, 3rd Generation Partnership Project; Technical Specification Group
Services and System Aspects; Feasibility Study on New Services and Markets
Technology Enablers; Stage 1 (Release 14),” 3GPP, 2016.
[31] Maria A. Lema, Andres Laya, Toktam Mahmoodi, Maria Cuevas, Joachim
Sachs, Jan Markendahl and Mischa Dohler, “Business Case and Technology
Analysis for 5G Low Latency Applications,” IEEE Access, March 2017.
[32] “TR33.813, Study on security aspects of network slicing enhancement,” 3GPP,
2020.
[33] “TS33.501, Security architecture and procedures for 5G system,” 3GPP, 2023.
[34] “TR33.874, Study on enhanced security for Network Slicing Phase2,” 3GPP,
2022.
[35] “TR33.886, Study on enhanced security for Network Slicing Phase 3,” 3GPP,
2023.
[36] “TS33.326 Security Assurance Specification (SCAS) for the Network Slice-147

Specific Authentication and Authorization Function (NSSAAF) network
product class,” 3GPP, 2023.
[37] “Toward fully connected vehicles: Edge computing for advanced automotive
communications: White Paper,” 5GAA, 2017[38] “AECC General Principle and Vision, White Paper,” 2018.
[39] “MEC in 5G networks,” ETSI White Paper No.28, 2018.
[40] “ETSI MEC: An Introduction (almost) everything you want to know about ETSI
MEC,” 2023.
[41] “TS33.839, Study on security aspects of enhancement of support for edge
computing in the 5G Core (5GC),” 3GPP, 2022.
[42] “TS33.558, Security aspects of enhancement of support for enabling edge
applications; Stage 2,” 3GPP, 2023.
[43] “TR23.700.98, 5G System Enhancements for Edge Computing; Phase 2,” 3GPP,
2022.
[44] “Cloud and MEC security,” 2018.
[45] “5G security package 3: Mobile Edge Computing/Low Latency/Consistent User
Experience,” NGMN, 2018.
[46] “MEC for Automotive in Multi-Operator Scenarios,” 5GAA, 2021.
[47] “TS23.285: Architecture enhancements for V2X services (Release 16),” 3GPP,
2019.
[48] Karthikeyan Ganesan, Prateek Basu Mallick, Joachim Lohr and Dimitrios
Karampatis, “5G V2X Architecture and Radio Aspects,” IEEE Conference onStandards for Communications and Networking (CSCN), 2019.
[49] “TS33.836, Study on security aspects of 3GPP support for advanced Vehicle-toEverything,” 3GPP, 2020.
[50] “TR33.836: Study on Security Aspects of 3GPP support for Advanced V2XServices (Release 16),” 3GPP, 2019.
[51] “TS33.536, Security aspects of 3GPP support for advanced Vehicle-toEverything (V2X) services,” 3GPP, 2022.
[52] “Privacy by Design Aspects of C-V2X,” 5G Americas, 2020.
[53] “Vehicular Connectivity: C-V2X & 5G,” 5G Americas, 2021.
[54] “Security Credential Management System (SCMS),” USDOT, 2018.
[55] Benedikt Brecht, Dean Therriault, Andre ́ Weimerskirch, William Whyte,

148

Virendra Kumar, Thorsten Hehn, and Roy Goudy, “A Security Credential
Management System for V2X Communications,” IEEE Transactions onIntelligent Transportation Systems, 2018.
[56] Anna Angelogianni, Ioannis Krontiris, and Thanassis Giannetsos, “Comparative
Evaluation of PKI and DAA-based Architectures for V2X Communication
Security,” IEEE Vehicular Networking Conference (VNC), 2023.

149

6.3 ユースケース Fintech セキュリティ[1] “5G と Fintech” 第 20 回 Fintech 協会 API・セキュリティ分科会,2019.12.03.
[2] “オープン API のあり方に関する検討会報告書－ オープン・イノベーションの活性化に向けて －,” オープン API のあり方に関する検討会, 2017.7.13.
[3] “日銀レビュー 金融分野におけるオープン API の活用～セキュリティへの影響と対策～,”Bank of Japan Review, 2018.6．3[4] “日立評論:Digital Solutions to Innovate Society,デジタルソリューションの基盤技
術と先端事例 汎用カメラ指静脈認証技術とその将来展望,” 2018 vol.100 No.3,2018.3[5] 株式会社ACSiON https://www.acsion.co.jp/[6] 一般財団法人 Fintech 協会 https://www.fintechjapan.org/members[7] 国立大学法人東京大学大学院情報理工学系研究科ソーシャル ICT 研究センター
http://www.sict.i.u-tokyo.ac.jp/research/lifestyle.html

150

7. まとめ本白書は、セキュリティ調査研究委員会において検討した内容をまとめたものである。主に参加委員の意見などから、全体に共通の 5G セキュリティ標準化動向を踏まえて、①IoT、②Connected Vehicle、③Fintech を検討項目とした。
2020 年 7 月に 5GMF 白書「5G ユースケースにおけるセキュリティ 第 1.0 版」を公開した。第 1.0 版の公開後、各検討項目（標準化、IoT、Connected Vehicle、
Fintech）における調査活動の結果を第 1.1 版として反映した。

151

AnnexIoT 課題まとめ
表 Annex 1

GSMA IoT Security Guide CLP11-v2.0

GSMA I oT Secur i t y Gui de CLP11-v2. 0

ャ

チ

レ
可用性
ン
ジ
1

ャ

チ

レ
識別・認証
ン
ジ
2

5G適用可能性

4Gまでのモバイル・ネットワークでは同一のセキュリティ機能が要請さ
How can Low Power Wide Area (LPWA) networks (e.g. NB-IoT and LTE-M)
れたが、5Gでは独立したスライスへの分割が可能となったため、他に
be deployed and operated with a similar level of security to traditional
影響を与えることなしにLPWAを必要とするようなローエンド・デバイス
cellular systems?
への柔軟な対応が可能となるという方向で検討
How can multiple mobile operators support the same level of network
5Gにおける一般的なオペレータ間モビリティ関係構築により実現可能
security as IoT Endpoints migrate across network boundaries?
という方向で検討
計算資源の乏しいローエンド・デバイスであっても5Gへの直接アクセスを可能としたことにより解決するとという方向で検討
How can network trust be forwarded to capillary Endpoints that rely on
GWに頼らなければならないEPが残るのであれば (たとえば人体植込
Gateway Endpoints for communication?
型ヘルスケア・デバイス等) にはEP⇔GW間の保護策は残存課題となる
5Gではバッテリにより15年間駆動可能なEPデバイスを収容するユー
How can the power constraints of Lightweight Endpoints be addressed in
スケースにも対応可能
secure communications environments?
技術的にはSBAの利用 (UPFとMEC (Mobile Edge Computing) をデバ
イス近傍へ配置) という方向で検討
エンドポイント利用者もMNO契約者である場合にはMNO内で連想付
Can the user operating the Endpoint be strongly associated with theを行なうことは可能という方向で検討
Endpoint’s identity?
IoTではMNO契約者以外のユーザがEPを操作するユースケースも多数存在するため、そのようなユーザへの対応は残存課題となる
How can services and peers verify the identity of the end-user by verifying
同上
the identity of the Endpoint?
Will Endpoint security technology be capable of securely authenticating
5GではEPと正規ピア/サービスとの間ではセカンダリ認証による相互peers and services?
認証を強制可能という方向で検討
Can rogue services and peers impersonate authorized services and peers? 同上
5Gではクレデンシャル・ストレージ機能によりUICC以外のセキュア・ス
トレージを利用することが可能という方向で検討
How can the Endpoint and Network ensure that an IoT Service is permitted 5Gではモバイル・ネットワーク外に存在するIoTサービスとUEとの間でto access the Endpoint?
のセカンダリ認証をサポート可能という方向で検討
5Gでは4GまでのIMSIとは異なり、UEの長期有効識別子を漏洩させな
Is the identity of an Endpoint exposed to unauthorized users?
い手法が導入されたため、それを利用可能という方向で検討
How is the identity of a device secured from tampering or manipulation?

Can uni que Endpoi nt or I oT Ser vi ce i dent i f i er s al l ow an enduser or Endpoi nt t o be physi cal l y moni t or ed or t r acked?

ャ

チ

レ
プライバシ
ン
ジ
3

同上

I s dat a emanat i ng f r om an Endpoi nt or I oT Ser vi ce i ndi cat i ve of
モバイル・ネットワーク全区間での安全な暗号化方式の利用により対or di r ect l y associ at ed wi t h physi cal end-user at t r i but es such
応可能という方向で検討
as l ocat i on, act i on, or a st at e, such as sl eepi ng or awake?
I s conf i dent i al i t y and i nt egr i t y empl oyed wi t h suf f i ci ent
secur i t y t o ensur e t hat pat t er ns i n t he r esul t ant ci pher -t ext
cannot be obser ved?

How does the product or service store or handle user-specific PersonallyIdentifiable Information (PII)?
Can the end-user control the storage or use of PII in the IoT Service or
product?
Can the security keys and security algorithms used to secure the data be
refreshed?

同上
製品ないしサービスがPIIをどのように保存/処理するかに関しては5G
では関知できない
同上

5Gフェーズ2では長期有効鍵 (UICCとコア・ネットワークで共有されるK)の更新可能化方式に関して検討予定
5Gコアに関連する機能要素に関しては3GPP SCAS (Security
Are security best practices incorporated into the product or service at the
Assurance Specification) の枠組を用いた取組が存在するので、それstart of the project?
を利用するという方向で検討
Is the security life-cycle incorporated into the Software or Product
同上
Development Life Cycle?
Is application security being applied to both services and applications
running on the embedded system?

現時点では5Gセキュリティの取り扱う範疇にないと考えられるが、検討することが必要。
[残存課題] 5Gネットワーク経由でアプリケーション・セキュリティの状態に関する検査機能を提供するという可能性はあるか？

Is a Trusted Computing Base (TCB) implemented in both the Endpoint and同上
the Service Ecosystem?

ャチ

How does the TCB enforce self-verification of application images andservices?

同上Can the Endpoint or IoT Service detect if there is an anomaly in its
configuration or application?

同上レ
セキュリティ
ン
How are Endpoints monitored for anomalies indicative of malicious
behaviour?
ジ
4
How is authentication and identity tied to the product or service security
process?

同上
5Gコアに関連する機能要素に関しては3GPP SCAS (Security
Assurance Specification) の枠組を用いた取組が存在

What incident response plan is defined for detected anomalies indicative of 現時点では5Gセキュリティの取り扱う範疇にないと考えられるが、検a compromise?
討することが必要
How are services and resources segmented to ensure a compromise canbe contained quickly and effectively?

同上

How are services and resources restored after a compromise?

同上Can an attack be spotted?
Can a compromised system component be spotted?
How can customers report security concerns?

同上
同上
同上
更新データの安全な配布方式部分に関してはOTA更新機構の利用可能性があるという方向で検討

Can Endpoints be updated or patched to remove vulnerabilities?

152

表

Annex 2

IoT セキュリティガイドライン
5G適用可能性I oT セ キュ リ テ ィ ガ イ ド ラ イ ン

経営者は、「サイバーセキュリティ経営ガイドライン」を踏まえた経営者がIoT セ
対応を行う。IoT セキュリティの基本方針を企業として策定し社
方 指針１
要点1 キュリティにコミッ
内に周知するとともに、継続的に実現状況を把握し、見直してい
針 IoT の性質をトする
く。また、そのために必要な体制・人材を整備する。
・ 考慮した基①IoT の安全を脅かす内部不正の潜在可能性を認識し、対策を管 本方針を定
内部不正やミスに 検討する。
要点2
理 める
備える
②関係者のミスを防ぐとともに、ミスがあっても安全を守る対策を検討する。
① IoT の安全安心の観点で、守るべき本来機能や情報などを守るべきものを特 特定する。
要点3② つなげるための機能についても、本来機能や情報の安全安定する心のために、守るべきものとして特定する。
①クローズドなネットワーク向けの機器やシステムであっても、
つながることによ
IoT 機器・システムとして使われる前提でリスクを想定する。
要点4 るリスクを想定す②保守時のリスク、保守用ツールの悪用によるリスクも想定するる。
指針２①セキュリティ上の脅威や機器の故障の影響が、他の機器とつ分つながりで波及す
IoTのリスク
ながることにより波及するリスクを想定する。
要点5 るリスクを想定す
析 を認識する②特に、対策のレベルが低い機器やシステムがつながると、影る響が波及するリスクが高まることを想定する。
①盗まれたり紛失した機器の不正操作や管理者のいない場所
物理的なリスクを での物理的な攻撃に対するリスクを想定する。
要点6②中古や廃棄された機器の情報などの読み出しやソフトウェア
認識するの書き換え・再販売などのリスクを想定する。
① パソコン等のICT の過去事例から攻撃事例や対策事例を学
過去の事例に学
要点7ぶ。
ぶ② IoT の先行事例から攻撃事例や対策事例を学ぶ。
①外部インタフェース経由／内包／物理的接触によるリスクに外部IFを5Gとすることにより他技術を用いるよりも強固なセ
個々でも全体でも 対して個々のIoT 機器・システムで対策を検討する。
キュリティを実現可能
要点8
守れる設計をする ②個々のIoT 機器・システムで対応しきれない場合は、それらをGSMA IoT SG：プライバシ#3に同じ含む上位のIoT 機器・システムで対策を検討する。
つながる相手に迷UPFとMEC (Mobile Edge Computing) をデバイス近傍へ配①IoT 機器・システムの異常を検知できる設計を検討する。
要点9 惑をかけない設計
置することによりデバイスのログ情報収集を省力化②異常を検知したときの適切な振る舞いを検討する。
をする
技術的にはSBAの利用：GSMA IoT SG: 可用性#4に追記
指針３
安全安心を実現
設 守るべきも①安全安心を実現するための設計を見える化する。
する設計の整合
要点10
のを守る設
計
②安全安心を実現するための設計の相互の影響を確認する。
性をとる
計を考える
不特定の相手とつなげられても安全 ① IoT 機器・システムがつながる相手やつながる状況に応じて要点11
安心を確保できる つなぎ方を判断できる設計を検討する。
設計をする
安全安心を実現①つながる機器やシステムは、IoT ならではのリスクも考慮して要点12 する設計の検証・
安全安心を実現する設計の検証・評価を行う。
評価を行う
機器等がどのよう ① 機器等の状態や他の機器との通信状況を把握して記録する UPFとMEC (Mobile Edge Computing) をデバイス近傍へ配な状態かを把握 機能を検討する。
置することによりデバイスのログ情報収集を省力化
要点13し、記録する機能 ② 記録を不正に消去・改ざんされないようにする機能を検討す ログ情報のMECからクラウドへの安全な退避を設けるる。
技術的にはSBAの利用：GSMA IoT SG: 可用性#4に追記① 機能及び用途に応じてネットワーク接続の方法を検討し、構機能及び用途に築・接続する。
5Gにより認証・暗号化・完全性保護等の機能を適用
構
要点14 応じて適切にネッ② ネットワーク接続の方法を検討する際には、IoT 機器の機
GSMA IoT SG：プライバシ#3に同じ
築 指針４
トワーク接続する
能・性能のレベルも考慮する。
ネットワーク・ 上での対策① IoT システム・サービスの構築・接続時や利用開始時にセ接 を考える初期設定に留意キュリティに留意した初期設定を行う。
要点15
続
する
② 利用者へ初期設定に関する注意喚起を行う。
① IoT システム・サービス全体でセキュリティの確保を実現する
認証機能を適用する。
5Gによる認証機能適用可能性② IoT 機器の機能・性能の制約を踏まえた適切な認証方式を GSMA IoT SG：識別・認証#3に同じ使用する。
出荷・リリース後も ① IoT システム・サービスの提供者等は、IoT 機器のセキュリ
5GによるOTA機能適用可能性
要点17 安全安心な状態 ティ上重要なアップデート等を必要なタイミングで適切に実施す
GSMA IoT SG：セキュリティ#15に同じる方法を検討し、適用する。
を維持する① 脆弱性情報を収集・分析し、ユーザや他のシステム・サービ
出荷・リリース後もスの供給者・運用者に情報発信を行う。
IoTリスクを把握② セキュリティに関する重要な事項を利用者へあらかじめ説明要点18 し、関係者に守っする。
てもらいたいこと③ 出荷・リリース後の構築・接続、運用・保守、廃棄の各ライフ
を伝える
運 指針５
サイクルで関係者に守ってもらいたいことを伝える。
用 安全安心な
つながることによ
状態を維持① 不用意なつなぎ方や不正な使い方をすると、自分だけでなく、るリスクを一般利・ し、情報発
他人に被害を与えたり、環境に悪影響を与えたりするリスクや要点19
用者に知ってもら保 信・共有を行守ってもらいたいことを一般利用者に伝える。
う
守 う
IoT システム・サー
ビスにおける関係 ① IoT 機器メーカやIoT システム・サービス提供者及び一般利要点20者の役割を認識 用者の役割を整理する。
する① ネットワーク上でIoT 機器を把握する仕組みを構築し、脆弱脆弱な機器を把性を持つIoT 機器の特定を行う。
要点21 握し、適切に注意② 脆弱性を持つIoT 機器を特定した場合には、該当するIoT 機
喚起を行う器の管理者へ注意喚起を行う。
要点16

認証機能を導入
する

153

表

Annex 3 安全な IoT システムのためのセキュリティに関する一般的枠組

安全な I oT シ ス テ ムのた めのセ キュ リ テ ィ に 関する 一般的枠組

5G適用可能性

・ITと物理的システムが融合したシステムであるIoTでは従来の情報セキュリティ確保に加えて新たに安全確
大所高所に立つ観点からの枠組の記述であるため、5Gを目 保が重要利用してIoTセキュリティを向上させるという技術的問題に対的 ・すべてのIoTシステムの設計/構築/運用に求められる一般的要求事項となるセキュリティ要件基本要素を しての貢献は見受けられなかった
明らかにすることが本文書の目的

検 ・IoTシステムはモノ同士がインターネットで接続されることにより新たな価値を創出
討 ・モノが接続されるため、物理的安全性の考慮が必要の ・IoTシステム同士が相互に接続されることでさらに新たな価値を生み出し得るが、一つのIoTシステムのリス
視 クが他のIoTシステムに波及する可能性もあるため、『システムのシステム』として捉えることが必要
点 ・IoTセキュリティ一般的枠組においては安全性/機密性/完全性/可用性の４要件の確保が前提
・モノとネットワークが連携したシステムで全体としてのセキュリティ確保のための要件としては基本方針の設計、リスク評価、システム設計、システム構築、運用・保守の各段階で求められる要件定義が必要であり、以下の各項目の明確化が必要
基 a) システムについての範囲、対象を含めた定義の明確化およびリスクを踏まえたシステム特性に基づく分
本 類原 b) 情報の機密性/完全性/可用性確保およびモノの動作に係る安全性確保要件の明確化
則 c) 確実な動作の確保および障害発生時の迅速なサービス回復に必要な要件の明確化d) モノとネットワークに求められる安全確保水準の明確化e) 故障およびサイバー攻撃実施等で機密性/完全性/可用性/安全性が確保されること
f) 責任分界点/情報所有権を含めたデータ取扱の在り方の明確化
要求事項の明確化

1．法令・規制要求事項、2. 非明示要求事項、3.業界等判断の追加要求事項の各事項について明確化

IoT システムのモデル 多層的なIoTシステム構成の適切なモデル化ならびにモデルを参照にしたセキュリ
化
ティ要件検討リスクに応じた対応

モノの接続によってもたらされるメリットとリスクを客観的に捉え、採るべきセキュリ
ティ対策/実装方法等を明確化

取性能要求と仕様要求
普遍的な性能要求と採り得る有効な具体的手段を示す仕様要求の2つから構成
組 の適切な適用
方
段階的・継続的アプ
基本的な機能要件定義とそれに対する段階的・継続的な進化を可能とする
針 ローチ
役割分担及び連携した対処のあり方の明
確化

IoTシステムに関連する者の役割分担を明確化し、各主体の連携・協調によるセキュリティ確保の在り方/各主体間の責任分界点の明確化

その他運用ルールの検討

IoTシステム運用に係るその他の事項についての社会的ルールの具体化を図り、機器認証の在り方について主体の在り方や運用ルールを明確化

留 本枠組は現時点で想定されるIoT システムを前提として策定されたものであり、技術革新等によるIoT シス
意 テムの機能の高度化等に併せ、適宜見直しを図ることとする。その際、広く国内外を含めた関係者(マルチ事 ステークホルダー)の意見や議論を踏まえたものとする。
項 また、既にある国内外のガイドライン2や基準等及びそれらの策定団体との連携・協調を図る

154

表

Annex 4

IoT セキュリティ総合対策

I oTセ キュ リ テ ィ 総合対策

5G適用可能性・IoTシステムのセキュリティについては安全な『IoT システムのためのセキュリティに関する一般的枠組』を踏まえた総合的視点に立った対策構築が必要

基 ・同枠組で提唱された機器、ネットワーク、認証等のプラットフォーム、サービス等のレイヤーに分けての分析・
具体的施策としては脆弱性対策に係る体制整備、研究開
本 検討を行うため、各レイヤーに分けて想定課題を抽出
的 a) サービス層：IoTシステム動作が正しいデータに基づくことが必須要件でありデータ真正性担保のための対 発の推進、民間企業等におけるセキュリティ対策の促進等の体制整備的な側面からの文書であり、5Gを利用してIoT
考 策強化が必要
セキュリティを向上させるという技術的問題に対しての貢献
え b) プラットフォーム層： 異なるシステム間の運用基準共通化/異システム間での情報共有耐性強化が必要
は見受けられなかったc) ネットワーク層： 機器層とプラットフォームとを繫ぐデータ転送役割を担い、IoT機器で主として用いられる無方 線ネットワークにおける脆弱性最小化が必要
d) 機器層： IoT機器管理、脆弱性検知・措置・切断等を関係者が連携して実現可能な体制構築が不可欠

脆
弱
性
対
策
に
係
る
体
制
整
備

設計・製造段階

セキュリティ・バイ・デザイン等の意識啓発・支援の実施
設計・製造段階においては、所有者・運用者・利用者による安全な設定が行われる
よう、ID/パスワード設定、ファームウェアのアップデート及びWi-Fi設定の仕様を設
計時に盛り込むなど、製造業者におけるセキュリティ・バイ・デザインの考え方をいかに浸透させるかが重要

販売段階

認証マークの付与及び比較サイト等を通じた推奨
一定のセキュリティ要件を満たすIoT 機器への認証マーク付与や、比較サイト等を通じて認証マークが付与された機器が推奨される仕組の構築

設置段階

IoT セキュアゲートウェイ
機器の設置(ネットワークへの接続)段階において、脆弱性を有する機器が存在する
ことを前提としたセキュアなシステム構築が実現できる仕組作り

セキュリティ検査の仕組作り
機器の脆弱性に係る接続試験を行うテストベッドの構築を含む継続的な安全性を確保するためのセキュリティ検査の仕組作りおよび対策が不十分なIoT 機器への対運用・保守段階 応についての検討が必要
簡易な脆弱性チェックソフトの開発等
IoT 機器利用者に対して簡易に脆弱性をチェックできるソフトを開発して配布する取組や、脆弱性を調査する民間サービス実施の促進を検討
利用段階

利用者に対する意識啓発の実施や相談窓口等の設置
従来の端末機器以上に利用者による十分な対応が重要となることを踏まえ、利用者に対する意識啓発を推進していくことが必要
重要IoT 機器に係る脆弱性調査

脆弱性調査の実 サイバー攻撃の踏み台となるおそれがある機器に係る脆弱性調査
施
被害拡大を防止するための取組の推進
IoT 機器に関する脆弱性対策に関する実施体制の整備

具
体
的
施
策

研
究
開
発
の
推
進

ュ

民
間
企
業
等
に
お
け
る
セ
キ

基礎的・基盤的な研究開発等の推進
広域ネットワークスキャンの軽量化
ハードウェア脆弱性への対応
スマートシティのセキュリティ対策の強化
衛星通信におけるセキュリティ技術の研究開発
AI を活用したサイバー攻撃検知・解析技術の研究開発
民間企業のセキュリティ投資等の促進
IoT 産業等の関連産業等の成長を見据えて企業におけるセキュリティ投資を促進するため、高レベルのサイバーセキュリティ対策に必要なシステムの構築やサービスの利用に対して、税制優遇措置を講ずる方向での検討が必要
セキュリティ対策に係る情報開示の促進
任意の情報開示であることを前提としつつ、企業のセキュリティ対策に係る情報開示に関するガイドラ
インの策定について検討することが必要
事業者間での情報共有を促進するための仕組みの構築
解析・対処能力が事業者間で一様ではないことを踏まえ、情報共有の目的・利点・手順、必要とされる情報を明確化するとともに、平時・非常時などの状況に応じた提供すべき情報の範囲及び提供先の範囲等を明確化することが重要
情報共有時の匿名化処理に関する検討
情報の秘匿性を担保する観点から情報の匿名化処理の導入を検討する必要があるため、その際、どのような方法で、どの程度まで情報を匿名化するべきかについての評価指標やガイドラインの整備の
検討が必要

対
策
の
促
進

公衆無線LAN のサイバーセキュリティ確保に関する検討
普及が進む公衆無線LAN のサービスにおいて、セキュリティに対する配慮に欠けるものも多く、これらのサービスを踏み台にした攻撃や情報漏洩などのインシデントが発生することが考えられるため、公衆無線LAN におけるサイバーセキュリティ上の課題を整理し、今後必要な対策について検討することが必要

人
材
育
成
の
強
化

実践的サイバー防御演習（CYDER）の充実

ィ

リ
テ

国
際
連
携
の
推
進

2020 年東京大会に向けたサイバー演習の実施
若手セキュリティ人材の育成の促進
IoT セキュリティ人材の育成
ASEAN 各国との連携
国際的なISAC 間連携
国際標準化の推進
サイバー空間における国際ルールを巡る議論への積極的参画

155

表

Annex5

サイバー・フィジカル・セキュリティ対策フレームワーク(案)サイ バー・ フ ィ ジ カ ル・ セ キュ リ テ ィ 対策フ レ ームワ ーク ( 案)は ・Society5.0とConnected Industriesが実現する社会においてはサイバー空間とフィジカル空間とを高度に融合させることで多様なニーズにきめ細やかに寄り添うモノやサービスを提供可能な超スマート社会の実現がじ期待されているめ ・同時にサイバー攻撃による脅威が増大することが懸念されており、そうした脅威の増大および新たな脅威に の出現に対する防御を可能にするための新たな対策フレームワークが必要

5G適用可能性・サイバー空間とフィジカル空間が高度に融合した産業社会における産業分野のサイバーセキュリティの在

コ り方ン 1) サイバー空間とフィジカル空間が高度に融合した産業社会における「Society5.0」型サプライチェーン
セ “価値創造過程（バリュークリエイションプロセス）”への対応
プ 2) 価値創造過程（バリュークリエイションプロセス）のセキュリティを確保するための信頼性
ト （trustworthiness）の基点を設定するためのモデル －三層構造アプローチと６つの構成要
3) 価値創造過程（バリュークリエイションプロセス）におけるリスク源とそれに対応する方針の整理

ー・リスク源の洗い出しと対策要件の特定
1) 分析対象の明確化(三層構造モデルへの落とし込み)
リスクアセスメントにおける分析対象の明確化について、(1) 実施プロセス、(2) 実施上の留意点を記述
2) 想定されるセキュリティインシデント及び事業被害レベルの設定
ポ 明確化された分析対象に対して重大な影響を及ぼすセキュリティインシデントの整理および事業への影響
リ の整理を記述
シ 3) リスク分析の実施
１) & ２) の内容を踏まえ、セキュリティインシデントに繋がる攻撃シナリオの検討、被害レベル、リスク源の評価等を実施4) リスク対応の実施
3) の結果得られたリスクに対して回避／低減／移転／保有のいずれの対応をとるかを想定される被害の大きさ等に基づき検討
資産管理

企業等が事業目的を達成することを可能にするデータ、ヒト、モノ、システム、それらが管理される場所等の特定および重要性に応じた管理の実現

ビジネス環境自組織のミッション、目標、利害関係者、活動を理解し、優先順位付けを実施

ガバナンス

自組織に対する規制、法律、リスクと、自組織の環境、運用上の要求事項を管理しモニタリングするためのポリシー、手順、プロセスを理解し、サイバーセキュリティリ
スクの管理者に伝達

リスク評価

自組織の業務（ミッション、機能、イメージ、評判を含む）、資産、個人に対するサイバーセキュリティリスクを把握

リスク管理戦略

自組織の優先順位、制約、リスク許容度、想定を定め、運用リスクの判断に利用ッメ サプライチェーンリスク 優先順位、制約、リスク許容値、および想定を、サプライチェーンリスク管理に関連するリスクの決定を支援するために確立し、利用する管理
ソ
アイデンティティ管理、 資産およびそれが管理される場所への論理的・物理的アクセスを、承認されたソシ5Gによる認証機能の適用
認証およびアクセス制 キ、ヒト、モノ、プロシージャに限定し、承認された活動およびトランザクションに対す
GSMA IoT SG：識別・認証#3に同じ
ド 御る不正アクセスのリスクの大きさに合うよう管理ュ

：
職員およびパートナーに対して、関連するポリシー、手順、契約に基づいた、サイ
意識向上及びトレーニ
バーセキュリティに関連する義務と責任を果たすために、サイバーセキュリティ意識
セ ング
向上教育と、訓練を実施
キ
データセキュリティ

データと記録をデータの機密性、完全性、可用性を保護するために定められた自組 5Gによる暗号化・完全性保護等の機能を適用
織のリスク戦略に従って管理
GSMA IoT SG：プライバシ#3に同じ

ィリ
テ 情報を保護するため（目的、範囲、役割、責任、経営コミットメント、組織間の調整を扱う）セキュリティポ
リシー、プロセス、手順を維持し、システムと資産の保護の管理に使用

対 保守策
要 保護技術件と 異常とイベント
対 セキュリティの継続的策 モニタリング例
集 検知プロセス

産業用制御システムと情報システムの構成要素の保守と修理をポリシーと手順に従って実施のプロセス及び手順

関連するポリシー、手順、契約に基づいて、システムと資産のセキュリティとレジリエ
ンス、セーフティを確保するための、技術的なソリューションを管理
異常な活動を検知し、事象がもたらす可能性のある影響を把握
セキュリティ事象を検知し、保護対策の有効性を検証するために、システムと資産をモニタリング
異常なセキュリティ事象を正確に検知するための検知プロセスおよび手順を維持
し、テスト

対応計画

検知したセキュリティインシデントに対応し、適切に自組織の事業を継続しつつ、影響を受ける資産やシステムを復元できるよう、対応・復旧のプロセスおよび手順を
実施&維持

伝達

法執行機関のような組織からの支援を得られるよう、内外の利害関係者(例えば、取引先、JPCERT/CC、他組織のCSIRT、ベンダー)との間で対応・復旧活動を調整

分析

効率的な対応を確実にし、復旧活動を支援するために、分析を実施

低減

セキュリティ事象の拡大を防ぎ、その影響を緩和し、セキュリティインシデントを解消するための活動を実施

改善

現在と過去の意思決定／対応活動から学んだ教訓を取り入れることで、自組織の対応・復旧活動を改善

156

表 Annex 6

IoT 開発におけるセキュリティ設計の手引き I

Ｉ ｏ Ｔ 開発に お け る セ キュ リ テ ィ 設計の手引き

5G適用可能性・IoTのセキュリティ現状と課題
IoT固有の課題：(1) ネットに繋がる脅威を考慮していない機器の接続、(2) 生命に関わる機器やシステムの接続を想定、(3) 「モノ」同士の無線等での自律的な接続を想定、(4) 「モノ」のコストの観点から、不十分なセ
キュリティ対策が想定、(5) ネットを介して収集される情報の用途は、「モノ」側では制御が困難であり、バックは エンドシステム側での管理範囲となる、(6) つながる世界を拡げていくためには、「モノ」同士の技術的（通信 基本的にIoT機器開発者としての立場で機器のセキュリティ
じ プロトコル、暗号、認証等）、およびビジネス的な約束事が不可欠
設計をどうすべきかというスタンスの文書であるため、5Gを利用してIoTセキュリティを向上させるという技術的問題に対め ・本書のねらいに 1) IoT の全体像をモデル化し、各々の構成要素を定義、2) IoT のセキュリティ設計において行うべき、脅威 しての貢献は見受けられなかった
分析・対策検討・脆弱性への対応について解説、3) セキュリティを検討する上で参考となる、IoT 関連のセキュリティガイドを紹介、4) いくつかの例題をもとに、IoT システムにおける脅威分析と対策検討の実施例を示す、5) IoT システムのセキュリティを実現する上で根幹となる暗号技術の重要性を説明し、実装した暗号技術の安全性を客観的に評価するためのチェックリストを添付

I IoT構成要素の定義
o ・サービス提供サーバ・クラウド
T ・中継機器の ・システム (中継機器経由でネットワークに接続される複数の機器で構成されたシステムのこと)
定 ・デバイス・直接相互通信を行うデバイス
義・一般にIoT製品やサービスのセキュリティ設計を行う場合は以下の手順を実施
Step1： 対象とするIoT 製品やサービスのシステム全体構成を明確化
Step2： システムにおいて、保護すべき情報・機能・資産を明確化
Step3： 保護すべき情報・機能・資産に対して、想定される脅威を明確化【脅威分析】
Step4： 脅威に対抗する対策の候補（ベストプラクティス）を明確化【対策検討】
I Step5： どの対策を実装するか、脅威レベルや被害レベル、コスト等を考慮して選定
・IoT のセキュリティ設計における脅威分析と対策検討、セキュリティ対策の一つとして必要不可欠な脆弱性
o への対応について記述

ュ

T
の
脅威分析
セ
キ

セキュリティ対策検討

ィ

リ
テ

設
計

脆弱性への対応対象となるシステム全体/構成要素に対して想定される脅威を明確化し、脅威に対する脆弱性評価および脅威に起因するリスクの評価を行なう攻撃ツリー型脅威分
析手法を用いてネットワークカメラに対して評価した結果を事例紹介
脅威分析の結果に基づき必要なセキュリティ対策を検討する。前項で例示した脅威分析結果に対して対策検討した結果を紹介
脆弱性への対応として以下を記述
a) 開発段階での対応
脆弱性の新たな作り込み排除、既知脆弱性解消、残留脆弱性の検出/解消、製品出荷後に発見される新規脆弱性への準備b) 運用段階での対応
脆弱性対策情報の継続的収集、更新SW/FW を含む脆弱性対策情報の作成、脆弱性対策情報の利用者への通知、更新SW/FWの製品への適用
c) IPA提供コンテンツ活用
脆弱性対策情報データベース：JVN iPedia、脆弱性届出制度、IoT製品・サービス脆弱性対応ガイドI
o IoTセキュリティ検討にあたって参考となる国内外において様々な機関・団体から公表されたIoT関連セキュ
T リティに関するガイドライン等をIPA/国内機関・団体/国外機関・団体に分類して紹介し、以下の3団体に関する活動と同団体公表ガイドラインに関する紹介がなされている
関 a) OWASP（Open Web Application Security Project）
連 b) OTA（Online Trust Alliance）
S c) GSMA（GSM Association）
G
脅
威分
析 IoTのセキュリティ設計章で示したセキュリティ設計の手順に従い1)デジタルテレビ、2)ヘルスケア機器と/ クラウドサービス、3)スマートハウス、4)コネクテッドカーを題材としたIoT システムに対して以下を実施
対 a) 対象IoT システム／サービスの全体構成図の作成
策 b) 保護すべき情報・機能・資産の明確化
検 c) 想定される脅威の明確化
d) 対策候補（ベストプラクティス）の明確化
討
実
施
例

157

表

Annex 7

IoT セキュリティ評価検証ガイドライン

I oT セ キュ リ テ ィ 評価検証ガ イ ド ラ イ ン

5G適用可能性

I 組込み機器メーカの課題：
o ・製品の競争力向上のためには、通信ネットワーク連携による高度化が必要であるが、そのためには具体T 的なセキュリティ基準の策定が必要
基本的に組込機器開発者としての立場で機器のセキュリの ・同時にセキュリティ検査ツールや、検査、認証基準の整備を行い、セーフティで実施されているような第三 ティ評価検証のために実施する評価検証手法を説明すると
現 者による客観的、定量的な検査・検証が行われる仕組みづくりが必要
いうスタンスの文書であるため、5Gを利用してIoTセキュリ
ティを向上させるという技術的問題に対しての貢献は見受状 本文書の位置づけ：と 本文書はいくつかの団体より発行されたセキュリティガイドラインの評価検証に関する項目に対して、スマー けられなかった
脅 トホーム分野での実例を取り入れつつ、IoT 機器全般を対象に、具体的なセキュリティの評価検証プロセス
威 を更に掘り下げた内容として策定

ュセ 評価検証手法はプログラムの実行を伴わずにロジックの評価検証を行う静的な検証手法と、実際にプログ
キ ラムを動作させた上で挙動を確認する動的な検証手法に大別される
a) 静的検証手法

ィリ ・設計ドキュメントレビュー
各種設計ドキュメントに対して、「セキュリティバイデザイン」の考え方に基づき、必要なセキュリティ対策が組
テ み込まれているかどうかをレビューによって確認する。
・ソースコードレビュー(解析)、コーディング規約検証

評 ソースコードに対して、セキュリティ上の脆弱性の検証や、コーディング規約に基づく実装が行われているか
価 どうかの検証を行う。ソースコードに対する検証は各種静的検証ツールによる検証の自動化が主流であり、検 業務効率化のためにも有効に活用することが望ましいb) 動的検証手法
証 ・既知の脆弱性検証手法の 脆弱性スキャンチェック、脆弱性情報に基づくペネトレーションテスト
手 ・未知の脆弱性検証手法
法 ファジングテスト
セキュリティ評価検証の実行は、自動化されたツールを用いた場合でも評価検証内容の組み合わせによっ

評 て、実行処理完了までに時間を要する可能性がある。ツールの実行所要時間については、事前に把握して価 おくことが望ましい。
検 ツールによる検証完了後の出力結果については、ツールが出力した結果に対して、ログ情報等をもとに、結証 果の正当性を評価検証者が解析し、結果判定を行う必要がある。また評価検証者が正しい判定を行うため
実 には、DUT 側のプログラムに関する知識や、ツール側の結果判定ロジックについても理解しておくことが必要となる
行 評価検証者が結果判定を行うために必要な情報やナレッジを記載

158

表 Annex 8

IoT セキュリティ標準／ガイドライン ハンドブック

I oTセ キュ リ テ ィ 標準／ガ イ ド ラ イ ン ハン ド ブ ッ ク
は セキュリティ課題が最も多いと考えられたコンシューマIoT向けセキュリティ提言をまとめた報告書を2016年
じ に発行したが、その後コンシューマ向けのみならず多数の業種／産業向けIoTセキュリティに関する整理が多くの組織・団体によりなされた結果、多数の指針／標準が発行されたという現状を踏まえて、それら多数
め の文書を読み解くことが容易となるように主要文書の目的／対象読者／特徴などをまとめた文書が本ハンに ドブックである
・STRATEGIC PRINCIPLES FORSECURING THE INTERNET OF THINGS（IoT)

U.S. Department of Homeland Securityによって発行されたIoTの安全性確保のための戦略的原則と推奨される最良実践を記述した文書

・Security and Resilience of Smart Home
Environments
・Security and Resilience of Inteligent
Public Transport good practices andrecommendations
・Cyber Security for Smart Cities
IoTとスマートインフラにおけるセキュリティおよびレジリエンスに・Cyber security and resilience for Smart 関して実務家と専門家によるWG/会議体による調査・分析結果
HospitalsをまとめたENISAによる公開文書群
・Securing Smart Airports
・Cyber Security and resilience of smart
掲 cars載 ・Baseline Security Recommendations for
IoT

ュ

I
o
・Internet of things Privacy &Security in IoTでのプライバシー問題を中心とした法制化へ向けた専門家か
T a Connected World FTS Staff Report
らなるパネリストによる議論の結果をまとめたU.S. FTCによる公セ JAN 2015
開文書
キ・Best Current Practices for Securing
リ Internet of Things (IoT) Devices

ィテ・IoTセキュリティガイドライン

IoTデバイス・ベンダが開発中およびアップデートを作成する際にそれらのデバイスが関与するセキュリティ・インシデントの頻度と重大性を減少させるために考慮が必要な最小限の要件をまとめたIETFネットワークWGによる公開文書
IoT推進コンソーシアムによる公開資料 (本Excel Sheet #1)

標 ・IoT開発におけるセキュリティ設計の手引
準 き
IoTセキュリティに関する手引き （本Excel Sheet #4） およびフ／ ・つながる世界の開発指針
レームワークを記述したIPAによる公開資料
・安全なIoTシステムのためのセキュリティ
ガ に関する一般的枠組
イ
IoTに取り組む組織が考慮すべき重要な事項を9つの質問というド ・INTERNET OF THINGS： RISK AND
形で提示したISACAによる公開資料。IoTのビジネス的価値とリ
ラ VALUE CONSIDERATIONS
スクという両面からの考慮がなされている点が特徴的
イン
システムのセキュリティ・エンジニアリングの概念から各ライフサ
概
イクルでどのようにセキュリティを組み込むべきか等を記述した
・SP800−160 Systems Security
NISTによる公開文書。全体的にはセキュリティというものは単独
要 Engineeringで考える要件にはあらず、システム全体の中で考慮／検討されるべきという考え方を示す

・ITU-T Recommendation Y.4806
IoTがもたらすセキュリティ的脅威を分類してそれぞれが安全に
Secyruty capabilities supporting safety of 対してどのような影響をもたらすかを検討したITU-Tによる公開
the Internet of Things
文書

・OTA IoT Trust Framework (V2)OTA (Online Trust Alliance) によるIoT向けセキュリティ機能のフ
レームワークを記述した公開文書

・OWASP IoT Security Guidance

IoTのセキュリティに関して (1) 製造者、(2) 開発者、(3) 消費者という3種類の対象者別に作成されたOWASPによるセキュリティ・
ガイダンス文書159

5G適用可能性表Annex 9 JSSEC IoT セキュリティチェックシート 1/3

JSSEC I oT セ キュ リ テ ィ チ ェ ッ ク シ ート
方 指針１
針 IoT の性質
・ を考慮した
管 基本方針を
理 定める

分 指針２
IoTのリスク析 を認識する

指針３

設 守るべきも計 のを守る設計を考える

5G適用可能性

企業へIoT機器を導入しネットワークに接続する時に検討すべき内容を方針として明確にする
経営者がIoT セ ・指針2のIoTのリスクを認識し、経営層に提言し現状のセキュリ
要点1 キュリティにコミッ ティポリシーの見直しをする
トする
・IoTの特性（数が多い、機器と一体、持ち出しやすい、人への安全に関わる等）を考慮する □・必要な体制を整備し、人材を確保して育成する□IoT機器について内部不正やミスの対策を検討する
内部不正やミスに・重大な事故や障害につながる行為に対しルールなどを定め
要点2
備える
る
□守りたい機能と守りたい情報を明確にする
・守るべき機能（人に被害を与えないなど）を明確にする □・守るべき情報（蓄積情報、流れる情報、設定情報など）を明確にする □
守るべきものを特
要点3□信頼出来るIoT機器（認証や実績）、IoTシステム、サービスか
定する
確認をする
・実績多い信頼性の高いサービスを検討する□
・第三者による評価や監査を受けている信頼性の高い機器やサービスの利用を検討する□つながることにより攻撃を受けるリスクを想定する・ソフトウェアやハードウェアの設定の不備（ミス）による外部からの攻撃を想定する □- 設定情報やプログラムの改ざんなど
つながることによ- 情報の漏洩や機能の悪用、機能停止など
要点4 るリスクを想定す- 社内や外部への攻撃の踏み台など
る・保守ポートからの攻撃を想定する
・不正な相手に接続するリスク（乗っ取りを含む）を想定する□保守作業時のリスクを想定する・保守員の悪意を想定する
・保守ツールからのウイルス感染を想定する□つながることで異常が伝播し意図せず攻撃するリスクを想定する・ソフトウェアやハードウェアの設定の不備（ミス）による外部への攻撃を想定する□
- 機能停止など- 攻撃の踏み台などつながりで波及す
要点5 るリスクを想定す □脆弱なIoT機器がつながることで異常が伝播するリスクを想定する
る・連携する機器やシステムに影響をあたえるリスクを想定する□・ウイルスなどが波及するリスクを想定する □・既存機器（セキュリティ対策が不十分な組込系など）へ影響をあたえるリスクを想定する□IoT機器の盗難・紛失・破壊などのリスクを想定する・盗難・紛失時のリスクを評価し、対策が必要な場合には検討する
物理的なリスクを □IoT機器の破棄や転売時に情報を読み出されるリスクを想定
要点6
認識する
する
・個人情報・秘密情報などが漏洩するリスクを想定する□中古のIoT機器購入のリスク（不正な設定など）を想定する・ウイルスや不正なソフトが組み込まれているリスクを想定する□パソコン等、ICT におけるセキュリティ対策を参考にする
過去の事例に学・不要なインターネット接続をしない、ファイアウォールの設置、
要点7
ぶ
初期設定の変更などを参考にする□守るべきデータが暗号化されているか確認する
個々でも全体でも外部IFを5Gとすることにより他技術を用いるよりも強固なセ
要点8
・IoT機器やIoTシステムに保管されている情報が暗号化されて守れる設計をする
キュリティを実現可能いるか確認する
つながる相手に迷①IoT 機器・システムの異常を検知できる設計を検討する。
UPFとMEC (Mobile Edge Computing) をデバイス近傍へ配
要点9 惑をかけない設計②異常を検知したときの適切な振る舞いを検討する。
置することによりデバイスのログ情報収集を省力化をする
安全安心を実現①安全安心を実現するための設計を見える化する。
要点10 する設計の整合②安全安心を実現するための設計の相互の影響を確認する。
性をとる
不特定の相手とつなげられても安全 ① IoT 機器・システムがつながる相手やつながる状況に応じて要点11
安心を確保できる つなぎ方を判断できる設計を検討する。
設計をする
安全安心を実現①つながる機器やシステムは、IoT ならではのリスクも考慮して要点12 する設計の検証・
安全安心を実現する設計の検証・評価を行う。
評価を行う

160

表 Annex 10 JSSEC IoT セキュリティチェックシート 2/3
・UPFとMEC (Mobile Edge Computing) をデバイス近傍へ配□IoT機器の必要なログが取れるか確認する
・故障やエラー情報（セーフティ解析用）が取れるか確認する 置することによりデバイスのログ情報収集を省力化
・動作環境の情報（リライアビリティ解析用）が取れるか確認す ・ログ情報のMECからクラウドへの安全な退避る- データが送られて来ない、大量のデータが送られるといっ
たIoT機器異常を検知するなど・攻撃や認証の情報、アクセス履歴（セキュリティ解析用）が取機器等がどのよう れるか確認する・保管期間など方針を検討する
な状態かを把握要点13
し、記録する機能 □IoT機器の不要なログが取られてないか確認する
・センシティブな情報のログ出力をしない（センシティブな情報をを設ける
含む場合は暗号化する）□IoT機器の必要なログが安全に保管されるか確認する
・不正アクセス対策がされていること（改ざん・消去対策）を確
認する
・ログへのアクセス権限の設定を確認する
・ログの暗号化を確認する
・保管場所を確認する□IoT機器の機能及び用途に応じてネットワークへ接続する方針
や条件を検討する・IoT機器のインターネットへの接続が必要か否か検討する（閉・5G Network Slicingによる閉域網の提供
域網の検討） □・IoT機器をネットワークへ接続する際には、認証および暗号化
・5Gにより認証・暗号化・完全性保護等の機能を適用
によるセキュリティ対策を実施する
・セキュリティ対策が不十分なIoT機器を直接インターネットに・5G CNのみに留める
接続しないように留意する□IoT機器の接続、IoTシステムのゲートウェイ経由の接続などの機能及び用途に環境に応じた暗号化を検討する
要点14 応じて適切にネッ・Wi-Fiネットワークへの接続を設定する際には、より強い暗号
トワーク接続する方式を使用する（例、WPA2） □・可能な場合、有線での接続も検討する
・Telnetログインを無効にし、可能な限りSSHを利用する□
・IoT機器に格納するデータの暗号化を検討する
構・5Gではクレデンシャル・ストレージ機能によりUICC以外の□セキュリティの確保が難しいIoT機器を導入する際は別途セ指針４
築
キュリティ製品を導入するなど、全体でセキュリティを確保をする セキュア・ストレージを利用することが可能
ネットワーク・ 上での対策・セキュリティ対策が困難なIoT機器は、セキュアなゲートウェ
接 を考える
イを経由する・データ暗号化、DBファイアウォールなどを実施する
続□IoT機器、IoTシステム、サービスの管理者権限・利用者権限 ・5Gで認証用クレデンシャル等の安全な提供を行なえる可
能性は？
のIDとパスワードの設定及び管理を適切に行う
・IDとパスワードを初期設定のままとせず、適切に変更（変更後の文字数、文字種別等にも留意）する□
・第三者に知られないよう厳重に管理する□
・IDとパスワードを権限のないユーザと共有しない□
- 管理者の権限（監視、制御、設定変更など）と利用者権限を分割する□IoT機器、IoTシステムの不要なサービスやポートは停止するな
ど必要最小限の設定を行う
・デフォルトで有効になっている不要な機能やサービスは無効
初期設定に留意
要点15
にする□
する
・サービスに必要のない不要なポートは停止する□
□IoT機器の導入時点で最新のファームウェアにアップデートする
・IoT機器のファームウェアを最新のバージョンにアップデートする□□IoT機器への外部からの不正アクセスを防止する
・ファイアウォールなどにより外部からのアクセス制御を行う□設定情報が改ざんや変更されないようにする
・管理者以外によるIoT機器、IoTシステム、サービスの設定変更を禁止する□

要点16

認証機能を導入する□IoT機器、IoTシステム、サービスに対して適切な認証機能を利用する
・IoT機器の認証を検討する（電子証明書、IoT機器識別子な ・5Gによる認証機能適用可能性
ど）
・利用者（ユーザ）の認証を検討する（ID/パスワード、ICカー ・利用者所有5G端末経由の認証可能性
ド、生体認証など）
・IoTシステム、サービス（クラウド等）の認証を検討する（電子 ・5Gセカンダリ認証
証明書など）
・ファームウェアを更新する場合、ファームウェアの真贋判定機 ・5GによるOTA更新機能の適用可能性
能を検討する

161

表 Annex 11 JSSEC IoT セキュリティチェックシート 3/3□IoT機器、IoTシステム、サービスの使用期間とサポート期間を確認する
・IoT機器、IoTシステムやサービスのサポート期限（EOL/EOSL）が提示される/されているか確認する□
・アップデート可能な期間を確認する□
□IoT機器のアップデート手順を確認する
・アップデート情報やアップデートファイルの入手方法を確認する。□
出荷・リリース後も ・アップデート手順を確認する□
要点17 安全安心な状態
・アップデート時の安全性（認証機能やアップデートファイルのを維持する
暗号化など）を確認する□IoT機器のアップデート手順を策定する
・アップデートする判断基準を定める□
・安全にアップデートする手順とアップデート完了確認手順を策定する□
・運用可能なアップデート手順（リモート経由 or 媒体の利用な・5GによるOTA更新機能の適用可能性ど）を策定する□
・アップデート後の動作確認手順を策定する□
・アップデートの不具合があった時の戻し手順を策定する□
□IoT機器、IoTシステム、サービス提供者の基本的な構成情報を把握、管理する・ハードウェア、ソフトウェアの情報を管理する□
・設置場所、台数、使用用途、稼動有無を管理する□
□IoT機器メーカーやJPCERT/CC、ISAC 等が発信している脆弱性情報の収集・分析を行う
・不具合や脆弱性などの情報がを、Webサイトやメール等で確認する。
・上記の情報に記載されている影響範囲や重要度、対応予定
日等を把握する。
・IPA等の機関と連携した情報の場合は、連携先の情報も確認
しておく
出荷・リリース後も □構成情報と脆弱性情報がマッチングした場合、暫定対策や社
IoTリスクを把握 内利用者への情報発信を検討する
要点18 し、関係者に守っ ・利用制限などの暫定対策を検討する
・異常があった時の緊急対処方法を検討する□
てもらいたいこと・アップデートなど恒久対策の予定を検討する
を伝える
運 指針５
□インシデント情報をIoT 機器メーカーや提供者に連絡する
安全安心な用・メーカーのサポート窓口（連絡先）を管理する□
状態を維持□重要な事項がWeb、マニュアル等に記載されているか確認す
・ し、情報発る（契約書など）
保 信・共有を・個人情報やプライバシーを取り扱う場合は保護などが記載さ守 行うれているかを確認する□
・集めた情報の使われ方や第三者提供および利用目的などを確認する□
・サポート期間、問い合わせ先などを確認する□
□IoT機器の廃棄や再利用時の対策を行う
・個人情報・秘密情報を完全に消去する□
・初期化する□リスクを社内利用者へ周知する・禁止事項（機器が壊れるなど、「この様な使い方はしない」こ
つながることによるリスクを一般利 と） □要点19
用者に知ってもら ・重要な説明事項（個人情報やプライバシーに関わること、生う
命や重大事故につながること） □・システム全体に影響を及ぼす事項□□関係者の役割を把握し周知する
IoT システム・サー ・IoT機器メーカーやサービス提供企業の役割□
ビスにおける関係 ・IoT機器、IoTシステム運用保守担当の役割□
要点20
・IoT機器、IoTシステムのサービス利用者の役割□
者の役割を認識する
・CSIRT、またはインシデント対応関係部署の定義と役割（IoT
機器などインシデント発生時の連携先）□設置したIoT機器の脆弱性の影響と対応が管理できるしくみを検討する・メーカーから通知が行われた脆弱性の影響（自社利用への影響）を特定する□
・脆弱性の影響を受ける可能性のあるIoT機器（設置場所を含
む）を特定する□
・IoT機器の脆弱性情報を調査する（脆弱性情報データベース
脆弱な機器を把 （http://jvndb.jvn.jp/）など）
要点21 握し、適切に注意 ・脆弱性検出（ファジング）ツールによるIoT機器の脆弱性を調
査する
喚起を行う
・脆弱性の影響が確認できた場合、パッチの適用、ネットワー
クからの切り離しなどを実施する□IoT機器や、IoTシステムの異常を把握する
・IoT機器のログやインベントリ情報などから IoT機器の異常を検知する
・ネットワーク機器や IoTシステムを監視することで異常を検知する仕組みを検討する

162

表

Annex 12 Draft NISTIR 8200

Dr af t NI STI R 8200 I nt er agency Repor t on St at us of I nt er nat i onal
Cyber secur i t y St andar di zat i on f or t he I nt er net of Thi ngs ( I oT)

5G適用可能性・IoTの概念；ネットワーク化された主体（センサ／アクチュエータ／情報資源／ヒト）を用いて物理的世界と相互運用するシステムを作成すること
・以下の2つの基盤概念から成る
I−IoTコンポーネントは コンポーネントの間で潜在的に多対多関係性を提供するネットワークで接続される
o −いくつかのIoTコンポーネントはセンサ／アクチュエータにより物理的世界と相互運用可能
T ・構成要素概 −コンポーネント
念 −IoTコンポーネント−システム−IoTシステム−IoT環境

基本的にIoT利用者としての立場でセキュアな環境を実現するための阻害要因となる標準間のギャップを明らかにするというスタンスの文書であるため、5Gを利用してIoTセキュ
リティを向上させるという技術的問題に対しての貢献は見受けられなかったーIoT
応 5Gクレデンシャルを利用可能であれば解決
・セカンダリ認証による実現可能性
用 GSMA IoT SG：識別・認証#3に同じ
の
例
示
サ
イ
バ 各分野においてIoTで用いられる標準規格を解説したもの
・暗号技術
・サイバー・インシデント管理ュ

セ ・ハードウェア保証
キ ・アイデンティティ＆アクセス管理
・ISMS

ィ

リ ・ITシステム・セキュリティ評価
テ ・ネットワーク・セキュリティ

・セキュリティ・オートメーション＆継続的モニタリング (SACM)
・ソフトウェア保証と ・サプライ・チェーン・リスク管理
I ・システム・セキュリティ・エンジニアリングoT
概要

1．サイバーセキュリティ・オブジェクティブ、2. リスク、3. 脅威の各事項について概要
を記述

ー

I
o
T
サ
イ
バ

コネクテッド・ヴィーク
ル

ュ

・
セ
キ

ィ

リ
テ

ェ

・
オ
ブ
ジ

消費者IoT

ヘルスIoT & 医療機器 それぞれの応用例に関してセキュリティ・オブジェクティブ／リスク／脅威を分析

ィ

ク
テ

ブ
ス
／
リ
ス
ク
／
脅
威

スマート・ビルディング

スマート製造業

標 前出のサイバーセキュリティとIoT章で記述した各項目（暗号技術、サイバー・インシデント管理、ハードウェ
準 ア保証、アイデンティティ＆アクセス管理、ISMS、ITシステム・セキュリティ評価、ネットワーク・セキュリティ、化 セキュリティ・オートメーション＆継続的モニタリング (SACM)、ソフトウェア保証、サプライ・チェーン・リスク管景 理、システム・セキュリティ・エンジニアリング）に関して、様々な団体において策定されている標準化作業の
観 現況、市場へのインパクト、潜在的標準化ギャップに関する分析を記述

163

表

Annex 13 ENISA Baseline Security Recommendations for IoT

ENI SA Basel i ne Secur i t y Recommendat i ons f or I oT

5G適用可能性・IoTデバイス／システム／サービスに関連した脅威およびリスクは多岐に渡り急速に進化しており、市民の安
全／セキュリティ／プライバシに対する大いなるインパクトをもたらすものであることから、IoTに関連する脅威
景観は極度に広範囲なものとなっているため、IoTをサイバー脅威から保護するために何をセキュアにするべ
イ きかを理解し、どのようなセキュリティ機能を開発する必要があるかを理解することが重要である。その準備とン して以下を述べる
ト a) 目的ロ b) スコープc) EUおよび国際的ポリシー文脈d) ターゲット読者
e) 構成

IoT要素

・モノ
・知的決断作成
・センサおよびアクチュエータ
・組込システム・通信・超巨大攻撃表面
・限定的デバイス資源
・複雑なエコシステム
・標準および規制のフラグメンテーション
・広範な配備Io セキュリティ要考慮事項 ・セキュリティ統合
・安全性側面
T・低コスト
パ・熟練性不足・セキュリティ更新
ラ・非セキュアなプログラミング
ダ・不明瞭な責任関係

イ
ム 水平的ベースラインセ

ユースケース／利用アプリケーション／利用シナリオに依存して異なるセキュリティ
キュリティ・メジャー定義 対策／異なる資産の重要度に応じて異なる脅威インパクトのためにIoTセキュリティ
に関するチャレンジ
を水平的に研究することは極めて困難

アーキテクチャ

IoTソリューションは特有のアプリケーションに着目した特有の技術により開発されるため、標準化を欠いておりフラグメント化した異種アーキテクチャとなり易いため、複数の既存IoTアーキテクチャを研究することでハイレベルの参照モデルを抽出

資産分類

・以下の各グループに属する個別の資産を特定
IoTデバイス／その他のIoTエコシステム構成デバイス／通信／インフラ／プラット
フォーム&バックエンド／決断作成／アプリケーション＆サービス／情報

脅 セキュリティ・インシデント
2009年以降に発生した主要なIoTセキュリティ・インシデントのいくつかに関して分析を実施
威
お 脅威分類よ 実際のIoTシステムに対して実施された攻撃のいくつかに注目して作成された脅威分類を提示
び
IoTサイバーセキュリティ攻撃シナリオ例の提示
リ センサ⇔アクチュエータ間への攻撃／センサの読取値書換攻撃／アクチュエータへの設定変更／IoT管理シス ステムへの攻撃／プロトコル脆弱性徴発／デバイスへのコマンド投入／飛び石攻撃／IoTボットネットによる
ク DDoS／電力源操作／ランサムウェア
分 重大な攻撃シナリオ
析 前項で記述した攻撃シナリオに対する重大性を評価した結果の提示
ポリ シ

S.b.D ／ P.b.D ／ 資産管理 ／リスクおよび脅威識別および評価
エンド・オブ・ライフのサポート ／ 証明されたソリューション ／ セキュリティ脆弱性および/もしくはインシデント ／ 人的資源セキュリティ訓練/意識向上 ／ サードパー
組織・ ヒ ト ・ プ ロ セ
ティとの関係性セ
キ

・5Gではクレデンシャル・ストレージ機能により物理的保護を提供可能だが、クレデンシャル・ストレージ外に保存されたデータに対する保護提供が残存課題
GSMA IoT SG：識別・認証#5に同じ

ュ

HWセキュリティ

ィ

リ
テ

分
析
お
よ
技術
び
最
良
実
践

信頼および完全性管理
強力なデフォルト・セキュリティ＆プライバシ
データ保護およびコンプライアンス
システム・セーフティおよび信頼性・安全な配布方式部分に関してはOTA更新機構の利用可
能性
GSMA IoT SG：セキュリティ#15に同じ・セカンダリ認証による実現可能性
GSMA IoT SG：識別・認証#3に同じ

セキュアSW / FW更新
認証
認可
アクセス制御 − 物理的および環境セキュリティ

・データ転送部分に関しては5Gで保護可能だが、保存／使用状態での保護提供が残存課題
GSMA IoT SG：プライバシ#3に同じ
・5Gにより提供可能
GSMA IoT SG：プライバシ#3に同じ

暗号技術
セキュアかつ信頼できる通信
セキュアなインターフェースおよびネットワーク・サービス
セキュアな入出力取扱
ロギング
モニタリングおよび監査

ャッ

ギ

プ
分
析

ハ
イ
レ
ベ
ル
推
奨

G1

既存セキュリティ・アプローチと規制との間の分断

G2

認識および知識の欠如

G3

非セキュア設計 および/もしくは 開発

G4

異なるIoTデバイス/プラットフォーム/フレームワークを跨る相互運用性の欠如

G5

経済的インセンティブの欠如

R1

IoTセキュリティのイニシアティブおよび規制の調和の促進

R2

IoTサイバーセキュリティの必要性に関する認識の向上

R3

IoT向けのセキュアなSW/HW開発ライフサイクルの定義

R4

IoTエコシステム間での相互運用性に関する合意の形成

R5

IoTセキュリティに関する経済的および管理的なインセンティブの醸成

R6

セキュアIoT製品/サービス・ライフサイクル管理の確立

R7

IoT利害関係者間での責任の明確化

164

表

Annex 14 Security Guidance for Early Adopters of the Internet of Things (IoT)

Secur i t y Gui dance f or Ear l y Adopt er s of t he I nt er net of Thi ngs ( I oT)

5G適用可能性・本書はIoTをベースとしたシステムのセキュアな実装に関するガイダンスを提供するものであり、術語定義
等をITU-T Y.2060に負っている
イ ・IoTには以下のような特徴があるため、伝統的なエンタープライズ向けセキュリティ・ソリューションは十分な 基本的に大所高所に立って安全なIoTアプリケーションを実現するために必要となるセキュリティ制御を明らかにするとン 効果を持ち得ない-増加するプライバシ的懸念
いうスタンスの文書であるため、5Gを利用してIoTセキュリ
ト-プラットフォーム・セキュリティ限界
ティを向上させるという技術的問題に対しての貢献は見受
ロ -定常的なモビリティ
けられなかった-量的膨大さ-クラウド・ベースの操作
・消費者セクタにおける広範なIoTの採用が見られている・ビジネスおよび公共セクタ向けは若干遅れているが、B2B IoT接続も2011年〜2020年まで年次28％の増加が予測されている
目 ・スマート・シティ実現を目指す市政機関でも採用が進むことが推測
的 ・多くの産業セクタが独自のニーズを満たすためにIoTを用いる場合、個々のユニークな実装に対してセキュ
リティ脆弱性の評価が必要
・本書はIoTの一般的セキュリティ制御のセットを記述するが、個々のIoT実装の文脈においてはいくらかのカスタム化が必要となるだろう

個
人/
悪意あるアクタが利用することが想定される新規脅威および攻撃ベクタに関する例示
組 ・制御システム、車両、さらには人体までもがアクセスおよび操作の対象として被害を被る
織 ・改竄されたヘルス情報ないしセンサ・データに基づく不適切な診断/治療の実施
へ ・個人宅/事務所等への物理的アクセス方法の取得の ・内部バスへのDoS攻撃による車両制御の喪失
I ・IoTセンサに対するDDoS攻撃による生命に危害を与えるような重大な情報の喪失
・人の位置情報/振舞情報等に対する無権限でのトラッキングの実現
o ・小規模IoTデバイスが提供する遠隔モニタリング機能を利用した非合法サーベイランス
T
脅
威
ュ

セ
キ

ャ

ア
な IoTによって新たに生まれるセキュリティ・エンジニアリングへのチャレンジI ・複雑な構成を必要とする多くのプロトコル/技術を利用することで多くのIoTシステムは貧弱な設計/実装とo なりがち・成熟したIoT技術およびビジネス・プロセスの欠如
T ・IoTデバイス向けライフサイクル維持および管理に関する限定的なガイダンス
配 ・ユニークな物理的セキュリティ懸念の導入
備 ・複雑かつ気付かれ難いプライバシ的懸念に ・IoT開発者向けに得られる限定的な最良実践
関 ・IoTエッジ・デバイス向け認証/認可標準の欠如
・IoTベースのインシデント対応活動に関する最良実践の欠如
す ・IoTコンポーネント向け監査/ロギング標準の不存在
る ・IoTデバイスとセキュリティ・デバイス/アプリケーションの間で用いられるインターフェースが限定的
チ ・マルチ・テナンシをサポートする仮想化IoTプラットフォーム構成のためのセキュリティ標準が未成熟
レン
ジ
IoT開発/配備における利害関係者へのプライバシ・インパクトの分析およびPrivacy-by-Designアプローチ

ュ

推 の採用
奨
新規IoTシステムのアーキテクティングおよび配備におけるセキュア・システム・エンジニアリングの採用される IoT資産防御のための層的セキュリティ保護の実装
セ
キ 機微情報保護のためのデータ保護最良実践の実装
ィリ IoTデバイス向けライフサイクル・セキュリティ制御の定義
テ
組織によるIoT配備のための認証/認可フレームワークの定義および実装

制
御 組織IoTエコシステム向けロギング/監査フレームワークの策定
標準

将
来 IoTセキュリティ心構えに関する状況的認識
的
努 情報共有力
項 SDPとIoT
目
IoT環境におけるプライバシ

165

表

Annex 15 OWASP IoT Top 10 Project for 2018

OWASP I oT Top 10 Pr oj ect f or 2018

5G適用可能性"弱い、推測可能、もしくはコードに組み込まれ変更できないパスワード
I 容易に力任せ試行可能、公開された、ないし修正できないクレデンシャルを1 利用する。配備されたシステムへの無認可アクセスを可能とするFWないしク
ライアントSWに含まれたバックドアも含む""非セキュアなネットワーク・サービス

I 特にインターネットに接続されているデバイス自体に不要ないし非セキュアな ・製品/サービス提供者の開発体制次第・利用する既存製品やOSSまで含めて考えると実現は極め
2 ネットワーク・サービスが動作しており、情報の機密性、完全性/真正性、可 て困難か
用性を損なう、ないし無認可遠隔制御を可能にする"
非セキュアなエコシステム・インターフェース

I デバイス外のエコシステムに存在する非セキュアなウェブ/バックエンドAPI/
クラウド/モバイルへのインターフェースが存在することにより、デバイスもしく 同上
3 はその関連コンポーネントの危殆化が発生。よくある問題は認証/認可の欠如、弱いもしくは無暗号化、入力および出力フィルタリングの欠如
セキュアな更新機構の欠如

I デバイスを安全に更新する能力の欠如。デバイスでのFW検証の欠如、安全 ・安全な配布方式部分に関してはOTA更新機構の利用可
能性
4 な配布方式の欠如（非暗号化経路）、耐ロールバック機構の欠如、更新に起 GSMA IoT SG：セキュリティ#15に同じ因するセキュリティ的変更に関する通知の欠如などを含む
非セキュアな、もしくは旧コンポーネントの利用

I デバイスの危殆化を招く非推奨ないし非セキュアなSWコンポーネント/ライブ ・製品/サービス提供者の開発体制次第・利用する既存製品やOSSまで含めて考えると実現は極め
5 ラリの利用。OSプラットフォームの非セキュアなカスタム化、危殆化したサプ て困難か
ライ・チェーンからのサードパーティ性SW/HWコンポーネントの利用を含む

I 不十分なプライバシ保護
デバイスないしエコシステムに保存された利用者個人情報の非セキュア/不 同上
6 適切/無許可利用
I 非セキュアなデータ転送/保存
保存中/転送中/使用中の各状態を含むエコシステム内のどこかで機微
7 データに対する暗号化ないしアクセス制御の欠如

・データ転送部分に関しては5Gで保護可能だが、保存／使用状態での保護提供が残存課題
GSMA IoT SG：プライバシ#3に同じ・製品/サービス提供者の開発体制次第
I デバイス管理の欠如
製品として配備されたデバイスに対するセキュリティ・サポートの欠如。資産 ・利用する既存製品やOSSまで含めて考えると実現は極め
8 管理、更新管理、廃止、システム・モニタリング、対処機能を含むて困難か
非セキュアなデフォルト設定

I デバイスないしシステムの非セキュアなデフォルト設定による、ないし、シス同上
9 テムをよりセキュアにするための操作者による構成変更防止機構が欠けた状態での出荷物理的頑健化の欠如

・5Gではクレデンシャル・ストレージ機能により物理的保護を取得可能化GSMA IoT SG：識別・認証#5に同じ

I 物理的な頑健化方法が欠如することにより、潜在的攻撃者に対して将来的 を提供可能だが、クレデンシャル・ストレージ外に保存されA な遠隔攻撃ないしデバイスのローカル制御簒奪を可能とせしめる機微情報 たデータに対する保護提供が残存課題

166

表 Annex 16 OneM2M TS-0003-V3.8.0 Security Solutions

OneM2M TS-0003-V3. 8. 0 Secur i t y Sol ut i ons

5G適用可能性

OneM2Mでは利用する具体的なネットワーク技術はNSEで5 Security Architecture
OneM2Mセキュリティ・アーキテクチャに関する概要説明、セキュリティ・レイヤに関する説明、OneM2M全体 抽象化されており、その上のセキュリティ機能はOneM2M自章 的アーキテクチャにおけるセキュリティ・アーキテクチャの統合に関する説明を記述
身によってE2Eで提供されるため、5Gの出る幕はなし

6 Security Services and Interactions
OneM2Mにおけるイベント・フローにどのようにセキュリティが統合されているのかの説明、セキュリティ・サー
章 ビス・レイヤの説明、セキュア環境抽象化レイヤの説明を記述
７ Authorization
OneM2Mシステムでサポートされているアクセス制御方式の一般的記述および動的認可 / RBAC / 分散認
章 可などの特徴的機能に関する記述
８ Security Frameworks
M2Mアプリケーションで用いられる可能性がある多様な配備シナリオを収容するためにサポートされている
章 M2Mシステムのセキュリティ・プロビジョニングおよび設立のための多様な方式に関する記述
９ Security Framework Procedures and Parameters
セキュリティ・アソシエーション設立フレームワークおよびリモート・サービス・プロビジョニング・フレームワー
章 クで用いられる手続およびパラメータを記述
1 Protocol and Algorithm Details
0 証明書ベース・セキュリティFW / TLS&DTLS詳細 / 鍵エクスポート＆導出詳細 / クレデンシャルID詳細 /章 KpsaID / KmIDフォーマット / Enrolment Expiry を記述
1 Privacy Protection Architecture using Privacy Policy Manager（PPM)
1 M2Mサービス契約者のプライバシ嗜好およびサービスのプライバシ・ポリシを用いた分散認可プライバシ保章 護アーキテクチャであるプライバシ・ポリシ・マネージャのアーキテクチャを記述
Security-Specific oneM2M Data Type Definitions

1 OneM2Mセキュリティ仕様でのみ用いられるデータ型の定義を行なう
2 -Simple Security-Specific oneM2M Data Types
章 -Enumerated Security-Specific oneM2M Data Types-Complex Security-Specific oneM2M Data Types

167

改定履歴
版数

年月日

内容

1.0

2020 年 7 月 29 日

第 1 版発行

1.1

2024 年 3 月 11 日

〔項目追加〕（5.1. ユースケース IoT セキュリティ）
5.1.2.15. 5GMF 白書「5G ユースケー
スにおけるセキュリティ 第 1.1 版」における再調査5.1.9. 3GPP リリース 18 関連動向
5.1.10. 3GPP リリース 19 関連動向
5.1.11. ユースケース IoT セキュリティ
まとめ（5.2. ユースケース Connected
Vehicle セキュリティ）5.2.2.1.3. UNR155[5], UNR156[6]（5.3. ユースケース Fintech セキュリ
ティ）
5.3.7. リアルタイム認証のユースケー
スに関する追加の調査と検証結果
5.3.8. 決済・認証の標準化動向におけるモバイル通信の関係整理〔一部更新または変更された項目〕
1. はじめに（報告概要）（4. 5G セキュリティの標準化動向）
4.1. はじめに
4.2. 5G の標準化と導入スケジュール
4.3. NSA のセキュリティ
4.4. 5G phase 1 のセキュリティ
4.5. Release 16 以降のセキュリティ強化
4.6. 他団体における 5G セキュリティ
検討
4.7. 5G セキュリティ標準化動向まとめ
168

備考

（5.1. ユースケース IoT セキュリティ）
5.1.8. 5GMF 白書「5G ユースケースにおけるセキュリティ 第 1.1 版」における課題解決可能性（5.2. ユースケース Connected
Vehicle セキュリティ）5.2.1. 概要
5.2.2.2. ISO TC 22 (Road vehicles)
5.2.2.4.2. セルラー通信技術を用いた
ITS・自動運転の高度化に向けた課題調
査報告書
5.2.2.5. ITU-T
5.2.2.8. 自工会/部工会
5.2.2.9. 各標準の関係
5.2.3.3. ネットワークスライシング
5.2.3.4. MEC
5.2.3.5. C-V2X（5.3. ユースケース Fintech セキュ
リティ）
5.3.9. 追加調査・検証による
Fintech セキュリティのまとめ（6.参照文献）
6.2. ユースケース Connected
Vehicle セキュリティ（AnnexIoT 課題まとめ）

表 Annex 9

JSSEC IoT セキュリ

ティチェックシート 1/3

169