第 204 号・2024 年 1 月

住友電工テクニカルレビュー

特集

車載イーサネットのセキュリティ拡張
プロトコルの提案

A Proposal of Security Extension Protocol for Automotive Ethernet
＊

上田

浩史

井上

雅之

Hiroshi Ueda

Masayuki Inoue

＊

倉地

亮

上口

翔悟

Ryo Kurachi

高田

広章

和田

健冶

Hiroaki Takada

Shogo Kamiguchi

Kenya Wada

近年、自動車の電子制御システムにもイーサネットの搭載が進んでおり、自動車の電子制御システムに適したサービス指向プロトコルとして SOME/IP（Scalable service-Oriented MiddlewarE over IP）プロトコルが採用されてきている。SOME/IP プロトコル
ではサービスを探索するためのプロトコルである SOME/IP-SD（Service Discovery）プロトコルを実行した後、サービスを受信することが可能となる。しかしながらその一方で、SOME/IP-SD プロトコルの保護が十分でなくセキュリティリスクがあることが課題となっている。このため、本稿では SOME/IP-SD プロトコルに対する保護を実施するための拡張プロトコルについて提案する。
さらに、提案プロトコルを評価し、他のプロトコルよりも優位であることを示す。

Ethernet and SOME/IP (Scalable service-Oriented MiddlewarE over IP) have been increasingly applied to modern
vehicles. Although SOME/IP serves as an automotive middleware solution for control message transmission, it lacks
security measures, making it vulnerable to various attacks. To address this issue, we present a security extension protocol
for automotive Ethernet. Furthermore, we evaluate the protocol and demonstrate its effectiveness.
キーワード：自動車セキュリティ、車載ネットワーク、車載イーサネット、SOME/IP

1.

緒

言

2.

近年、自動車に搭載される機能が増加するにつれ、自動

2－1

SOME/IP プロトコルとその関連研究
SOME/IP プロトコル

車内の電子制御システムは複雑化し、ECU（Electronic

SOME/IP プ ロ ト コ ル は、自 動 車 の ソ フ ト ウ ェ ア プ

Control Unit）と呼ばれる制御用コンピュータが多数搭載

ラ ッ ト フ ォ ー ム を 標 準 化 す る 業 界 団 体 の AUTOSAR

されるようになっている。また、自動車に搭載されるセン（AUTomotive Open System ARchitecture）により仕様

サが高機能化されるにつれ、大容量の通信プロトコルが必が策定された通信プロトコルである。この通信プロトコル

要となり、車載イーサネットが注目されている。車載イーの特徴は、サーバクライアント通信を想定しており、クラサネット通信では、リアルタイム性を確保するために、物イアントが動的にサービスを実行するサーバを探索し、接理層や MAC（Media Access Control）層を拡張した様々

続することにより通信チャネルを確立するプロトコルであなプロトコルが提案されている。さらに、その上位層のプる。このサービス探索のためのプロトコルを SOME/IP-SD

ロトコルとして、より柔軟な制御システムを構成するためプロトコルと呼ぶ。サーバとクライアントの通信チャネルに、SOME/IP プロトコルが提案されている 。従来の電子が確立した後は、サーバがクライアントに対して図1に示

制御システムでは静的に配置された機能が、各ノードからす SOME/IP メッセージを送信することによりサービスがブロードキャストされるデータを受信することにより実現開始される。

（1）

されている。その一方で、SOME/IP プロトコルでは電子制御システム上の機能配置を柔軟にするため、動的にノード

SOME/IP
Headerに配置された機能からサービスを受信することを前提としている。従って、SOME/IP 通信を開始する前に、SOME/
IP-SD を実行する（2）。しかしながら、SOME/IP-SD による

PayloadMessage ID (Service ID /Method ID) [32bit]する。このため、本稿では2つのノード間の通信を安全な

SOME/IP-SD

方法で確立するための拡張プロトコルを提案する。また、
本稿では様々なセキュリティプロトコルとの比較を行い、提案プロトコルの必要性を議論する。

Length [32bit]
Request ID (Client ID / Session ID) [32bit]
ProtocolVersion [8bit]

Flags [8bit]

InterfaceVersion [8bit]

Message Type
[8bit]

Return Code
[8bit]

Reserved [24bit]
Length of Entries Array [32bit]
Entry Array
Length of Options Array [32bit]
Options Array

図1

Covered by Length

SOME/IP

動的な接続を確立する場合、セキュリティ上の課題が存在

SOME/IPメッセージのフォーマット
車載イーサネットのセキュリティ拡張プロトコルの提案

28（1）住友電工テクニカルレビュー
2－2

第 204 号・2024 年 1 月

SOME/IP-SD プロトコルとにより、各サービスをどのノードが実行しているのかを

SOME/IP-SD プロトコルでは、サーバ、クライアントの把握することができる。このため、SOME/IP-SD プロトコ

いずれのノードも起動時に実行するシーケンスが定義されルに対して、秘匿性を確保する手段が必要と考えられる。

ている。クライアントは起動後、サービス ID を指定し Find

（攻撃方法2）中間者攻撃

メッセージを送信しサーバからの応答を待つ。サーバはク

SOME/IP-SD では任意のメッセージを事前の認証なし

ライアントからの Find サービスが、自身が実行するサービに送信することができるため、ネットワークに接続する攻ス ID が指定される場合には、Offer サービスによりクライ

撃者によって、データやコマンドを注入され、悪用される

アント側にサーバへの接続情報を付与して応答する。Offer

可能性がある。この具体的な攻撃方法としては図4に示す

サービスを受信したクライアントは Offer サービスにて通知

ような中間者攻撃が挙げられる。正規のサーバから送信さされたサーバの接続情報を利用し、Subscribe メッセージをれる Offer サービスを攻撃者のノードの情報に書き換えて送信し接続を要求する。サーバは、Subscribe Eventgroup

送り付けることにより、クライアントを攻撃者が制御する

Ack あるいは Subscribe EventGroup Nack を用いて接サーバに接続させ、異常なデータを送り付けることが可能に

続の可否を応答する。このとき、Subscribe Eventgroupなる。

Ack が返れば、SOME/IP-SD での接続が完了したものとして扱われ、以降は SOME/IP メッセージにてサービスを受

Attacker(MITM)

Client

信することができる。この動作については図2に示すとおりであり、Subscribe Eventgroup Ack が返却されるまで

ServerFind (optional)
Offer

が SOME/IP-SD プロトコルであり、以降は SOME/IP メッ

Offer

セージにてデータの送信が行われる。

Subscribe
Subscribe Ack
SOME/IP Message

ClientServer

図4

SOME/IP-SD

Find Service (optional)

SOME/IP-SD における中間者攻撃

Offer Service
Subscribe Eventgroup
Subscribe Eventgroup Ack（攻撃方法3）コピーキャット攻撃
論文（3）にて、コピーキャット攻撃と呼ばれる攻撃方法

SOME/IPSOME/IP Messageが言及されている。コピーキャット攻撃は、正規のサーバ
図2

が Offer サービスを送信するのを待ち、その後すぐに攻撃

SOME/IP-SD のシーケンス

者が自身のエンドポイント情報を含む Offer サービスを送信することにより実現される攻撃であり、クライアントが後から送信された Offer サービスを実行する性質を利用し

2－3

SOME/IP-SD プロトコルの脅威て、攻撃者の偽サーバに誘導する攻撃方法である。この攻SOME/IP-SD プロトコルは、前述するような動的に接続

撃では、前述する（攻撃方法1）と（攻撃方法2）の組み合確立が要求される通信プロトコルであるため、以下の攻撃

わせにより実現され、攻撃者は正規サーバの Offer サービ

方法が想定される。

スを盗聴した上、偽サーバになりすますことで、クライア（攻撃方法1）不正なクライアントによる盗聴

ントに異常なデータを送り付けることが可能になる。

もし攻撃者がネットワークに接続している場合、攻撃者

2－4

は SOME/IP-SD プロトコルで通知される情報を盗聴するこ脅威の対抗策と関連研究

また、SOME/IP に対する脅威を排除するために、以下のような対抗策が議論されている。

Client（対抗策1）メッセージ認証子による保護

Server

Attacker

SOME/IP-SD

Find (optional)
Offer

Offer
Subscribe

Subscribe
Subscribe Ack
SOME/IP Message

図3

Subscribe Ack

SOME/IP Message

SOME/IP-SD における盗聴

AUTOSAR では SecOC（Secure Onboard

Communication）と呼ばれる仕様が規定されており（4）、
従来の車載制御ネットワークでも既に利用されている。このため、車載イーサネットに関しても SecOC に対応し MAC（Message Authentication Code）を付与することで各メッセージを保護する手法が考えられている。しかしながら、この方法では安全な場所にて事前に書き込まれた共通鍵を保持することが前提であり、この共通鍵が漏洩する場
車載イーサネットのセキュリティ拡張プロトコルの提案

29（2）住友電工テクニカルレビュー

第 204 号・2024 年 1 月

合には効果がない。つまり、通信オーバーヘッドが最も少3.

ないという利点を持つが、共通鍵が漏洩した場合は効果が提案方式ないことが課題である。

本章では、SOME/IP のための安全なノード間通信チャ（対抗策2）TLS による保護

ネルを確立するためのプロトコルを提示する。我々の提案

セキュアなノード間の通信を確立するために、民生機器
では TCP に対して TLS、UDP に対して DTLS

方式では、サーバとクライアント間で通信を確立する際にが用い実行される SOME/IP-SD に着目し、サーバクライアント間られることが多い。しかしながら、TLS はサーバとクライ

での通信保護を実現するものである。以降では、その要件

アントの両方に相応の計算処理を課すため、計算機資源のを述べ、設計したプロトコルの概要について述べる。

限られた組み込み機器には計算量が大きすぎる可能性があ

3－1

※1

※2

る。さらに、高いリアルタイム性が要求される自動車のようなアプリケーションにおいて、SOME/IP-SD を実行する

要件

車載制御システムならではの幾つかの要件が存在する。
（要件1）少ない通信オーバーヘッド

他に、TLS で接続を確立しなければならない場合には、ア

車載制御システムは分散制御システムであるため、起動時

プリケーションが開始するまでの時間が長すぎることが課の通信は混みあうことから、起動時の通信オーバーヘッド

題である。

を低減することは重要である。このため、セキュリティをさらに、既存研究として、以下のような対抗策が議論されている。

担保するための通信が多数行われると通信確立までの時間が長くなることが懸念される。したがって、通信オーバー

まず、福田らは、車載制御システムにセッション管理サー
バを立てることによりセッション管理サーバが代理で認証

ヘッドが極力低減できる方式が必要となる。
（要件2）Find サービスの保護する方式を提案している 。この方式では、セッション管

クライアントは起動後、マルチキャストにて Find サービ

理が一元化され、それらのログを管理することが容易であスを実行することでサーバからの応答を待つ。特に、サーる一方で、セッション管理サーバが動作しない場合にはすバからの Offer サービスの受信を待ち続けるよりも、Find

べての通信が確立できなくなる可能性があるうえ、通信確サービスを用いる方が通信確立までの時間を短くできる可

立までに時間がかかるという課題がある。

能性が高い。このため、Find サービスをマルチキャストで（5）

次に Iorio らは、SOME/IP メッセージを保護するための実行することを前提とした保護方法が必要となる。

認証プロトコルを提案している 。この手法は、クライア（要件3）セキュリティレベルを設定可能であること（6）

ント証明書とサーバ証明書を用いて、すべてのクライアン

従来の車載制御システムでは、ノード間の通信をすべて暗トとサーバの間でユニキャストによるハンドシェイクを実号化することは行われていない。このため、暗号化したい施することを前提としており、Find メッセージをブロード通信と暗号化しなくてもよい通信に分類できると考える。

キャスト（あるいはマルチキャスト）しない。このため、ゆえに、それぞれのサービスごとにセキュリティレベルを

サービス数やノード数が増加するとメッセージが多くなる

定義し、暗号化の有無や暗号方式を変更できる仕組みが必ことが課題である。

要と考えられる。

Zelle らは、SOME/IP プロトコルのセキュリティ分析を

3－2

セキュアな通信チャネルの設計行い、改良プロトコルを提案している 。この手法では、TLS または DTLS を SOME/IP に適用する場合、いくつか

Offer サービスに対して、起動後セッション開始前に Offerの課題がある。まず、SOME/IP のハンドシェイクでは、

サービス通知側で生成されたセッション鍵（共通鍵）を共クライアントからのマルチキャストによりサービスを実行有することにより実現される。また、この手法ではグルーするサーバがどこに配置されているのか探索する必要があ

プ鍵を用いることで、Offer サービスを保護することを可る。この時、クライアントはサービス ID などのサービスグ

能にしている。しかしながら、毎回起動時にセッション鍵

ループ情報を暗号化せずに配信する。

（3）の共有を行うまでは通信を開始できないことと、クライア

このため、攻撃方法1であげるような盗聴により、システントからの Find サービスに対応していないため、サーバのム上の構成情報が漏洩することが懸念される。さらに、盗Offer サービスの定期送信頻度を上げないと、接続開始が聴されたサービスグループ情報を用いて、攻撃方法2にある

遅くなることが課題である。

中間者攻撃で、クライアントに偽のメッセージを送信する

こ の よ う に、様 々 な 手 法 が 提 案 さ れ て い る も の の、SOME/IP-SD プロトコルに完全に互換し、セキュリティ

ことが可能になり、攻撃方法3であげられるコピーキャッ
ト攻撃が実行される恐れがある。

強度を高める手法はこれまでに提案されていない。このた

次に、静的な秘密鍵（共通鍵）を各ノードに持たせるこめ、本稿では SOME/IP-SD プロトコルに互換したうえで、とにより、MAC を使って SOME/IP メッセージの安全性をより通信オーバーヘッドを低減しつつセキュリティ上の安確保する方法もある。このような場合、SOME/IP メッセー

全性を高める通信方式を提案する。

ジの改ざんに対しては保護できるものの、サービスの内容が漏洩する恐れがある。また、前述したように、共通鍵を静的に保持し続ける方法では、漏洩後の安全性が確保でき
車載イーサネットのセキュリティ拡張プロトコルの提案

30（3）住友電工テクニカルレビュー

第 204 号・2024 年 1 月

ない。このため、サーバ証明書やクライアント証明書を用

3－4

いて、送信元を認証・認可することも必要と考える。

提案プロトコル本提案プロトコルは、基本的にはハイブリッド暗号方式

さらに、SOME/IP プロトコルとの完全な互換性を実現を採用し、SOME/IP-SD に適用したプロトコルである。しするため、ユニキャストメッセージに加えてマルチキャス

かしながら、Find サービスを保護するために、事前に共有

トメッセージも保護する必要がある。特定のサービスイン

された鍵を用いることが他のプロトコルと大きく異なる。

スタンスに属するメッセージを保護するため、事前に共有

より具体的には、以下のようなプロトコルである。

される共通鍵を用いる。この1つの共通鍵はセッション確

図5に示すように、まずクライアントは Find サービスを立前にすべてのノードの安全な場所で共有されることを想送信する際、クライアント証明書を付与した上、事前共有

定する。この事前に共有された共通鍵を使用し、Find サー

鍵を用いて暗号化を行った上で MAC を付与することで盗ビスを保護することで、安全性が増し、既存手法に比べて聴と改ざんから保護する。Find サービスを受信するサーバ

サービス確立までの時間を短縮することができる。

は事前共有鍵を用いて MAC の検証と復号を行い、クライ以上を踏まえ、我々の提案するプロトコルでは、事前共アント証明書が信頼できるルートにより発行されたかどう

有された共通鍵とサーバ証明書、クライアント証明書を用かを検証し、正しいクライアントからの要求であることをいる方式を提案する。この提案プロトコルの特徴は、従来確認する。

の SOME/IP プロトコルに完全に互換し、Find サービスや

次に、サーバは要求してきたクライアントに対し Offer

Offer サービスを保護することである。以降では提案方式

サービスを通知する前に、クライアントが要求するサービの鍵の管理について説明したうえで、提案するプロトコル

スを提供可能か事前に与えられたリストに従い確認した上を説明する。

で、セッション鍵（共通鍵）を生成する。このセッション

3－3

鍵をクライアント証明書に付与される公開鍵を用いて暗号鍵の管理

共通鍵、サーバ証明書あるいはクライアント証明書を各化し、クライアントに Offer サービスを応答する。この手

ノードに事前に配布することを前提としている。このため、順により、対応する秘密鍵の所有者であるクライアントのこれらの初期鍵は工場などの安全性の高い場所にて書き込

みが復号できることが保証され、セッション鍵の機密性がまれる必要がある。その上で、SOME/IP-SD プロトコルの確保される。

実行時、Find サービスの保護のために共通鍵を用いる。まさらに、Offer サービスには、その真正性と完全性を保た、証明書を用いて相互認証することにより、サーバおよ証するため、応答全体に対するデジタル署名を付与する。

びクライアントのなりすましから保護することを目的とす

次にクライアントが Offer サービスを受信すると、送信さる。従って、図5に示すように、各ノードにはクライアント

れてきたサーバ証明書を検証し、正規のサーバであることとサーバのいずれかの役割が割り当てられており、各ノーを確認する。最後に、サーバ証明書から抽出した公開鍵をドは秘密鍵とそれに対応する証明書（サーバ証明書あるい用いてデジタル署名の有効性を確認し、一致した場合ははクライアント証明書）を保持しているものとする。

自身の秘密鍵を用いてセッション鍵を復号し、以降の通さらに、共通鍵の更新については、接続が確立された後、信で利用する。Subscribe Eventgroup および Subscribe

各ノードにて更新することを想定する。このため、この共

Eventgroup Ack は秘匿性を持たせるため、セッション鍵

通鍵は SOME/IP-SD にて接続が確立される度に更新され、により暗号化し送信するものとする。

不揮発メモリに保存される。

3－5

サービスの保護レベル

一方、SOME/IP-SD によるセッション確立後、通常のSOME/IP メッセージで送信する場合、サービス単位で保護レベルを設定することができるものとする。保護レベルについては、基本的には、クライアント証明書内に対応可ServerClient

能な保護レベルを記載することにより実現されるが、サー

SOME/IP-SD

Find (optional)

バが保持する事前に与えられたリストにより制御されるこ

Offer: digital certificate

Subscribe
Subscribe ACK: private key: digital signature

SOME/IP Message: generate symmetric key: pre-shared symmetric key

図5とも想定する。このため、攻撃などにより通信が不安定な場合にはサーバから保護レベルを変更することも可能となる。サービスの保護レベルについての一例を表1に示す。

表1

本提案手法における鍵の管理とシーケンスの概要

保護レベル

サービスの保護レベルの一例

サービス保護策

0

なし

1

メッセージ認証コードによる改ざん防止

2

暗号化と改ざん防止

3

暗号化とデジタル署名による保護

車載イーサネットのセキュリティ拡張プロトコルの提案

31（4）住友電工テクニカルレビュー

4.

評

第 204 号・2024 年 1 月とサーバ認証（観点2）について、対抗策1（MAC）では考価

慮されていないことが課題である。次に、他ノードの鍵漏

本稿では、2つの観点での評価を実施する。まず、実機洩の影響（観点3）については、共通鍵をベースとする対抗を用いて通信オーバーヘッドを測定する。次に前述する対策1（MAC）では他ノードから漏洩した鍵により自ノード

抗策や関連研究との比較について述べる。

になりすましをされてしまう可能性があるため、セキュリ

4－1

ティ上の安全性は相対的に低いといえる。さらにセッショ

評価環境

評価環境は図6に示すとおりであり、2台の Raspberry

ン確立時間（観点4）については、前述した評価結果より、

Pi と1台のスイッチングハブを用いた。なお、プロトコル

対抗策2（TLS）では相対的に長くなることが課題である。

は、vsomeip

これらの結果から、提案手法は他の対抗策と比較し、十分を用いて実装を行った。

（7）に優位であると結論付けられる。

SerialClient(Raspberry Pi)
Ethernet

表3

SerialServer(Raspberry Pi)

観点

対抗策1
（MAC）

対抗策2（TLS）

提案手法

1.クライアント認証

×
（なし）

○
（あり）

○
（あり）

2.サーバ認証

×
（なし）

○
（あり）

○
（あり）

3.他ノードの鍵漏洩

×（影響あり）○（影響なし）○（影響なし）

4.セッション確立時間

○
（短い）

×
（長い）

△
（比較的短い）Ethernet
Switch

図6

4－2

対抗策1，2と提案手法の比較

PC

評価環境の構成

評価結果1：通信オーバーヘッドの評価

次に、他の関連研究との比較として、論文（6）と論文評価としては、実機上でのスループットを測定し、通信（3）の手法との比較を述べる。表4に示すとおり、いずれオーバーヘッドについて考察した。比較対象としては対抗の手法も、クライアント証明書、サーバ証明書を用いるこ策1. メッセージ認証による保護（MAC）と対抗策2.TLS にとが想定されており、観点3までは大差がないと考える。

よる保護（TLS）を想定する。測定は各クライアント側か

一方、観点4については Find サービスの扱いに差がある。

らの Find サービスと Offer サービスによる応答を受信す

より具体的には、論文（6）では Find メッセージをブロードるまでの時間とした。なお、対抗策1（MAC）では Find

キャストできないため、サービスを実行する可能性のあるサービスと Offer サービス以降の手続きがない点、対抗策2

ノードに対してユニキャストで Find サービスを送信する必（TLS）については事前に TLS の通信保護手続きを行う必要要がある。このとき、すべてのサーバの候補とのセッショがあることから、通信オーバーヘッドが大きくなる点に注ンが確立している必要があり、サーバの候補が多数存在す

意されたい。そのうえで、各方式に対して100回計測し、る場合には通信量が膨大になることが課題である。また、

その平均、最小値、最大値を記載している。

論文（3）では Find サービスは保護せずに使用しないものと測定結果については表2に示すように、従来手法と比べ考えられる。この場合、サーバからの Offer サービスによて、十分に低い通信オーバーヘッドで実行できているといり通信が開始される場合のみが想定され、高い頻度で Offer

える。

サービスを送り続けなければならないため、通信オーバー
ヘッドが大きくなる可能性がある。このため、提案手法がFind サービスに対応しつつ、相対的に短い時間でセッショ

表2

SOME/IP-SD のセッション確立時間（ms）の比較

計測時間

対抗策1
（MAC）

対抗策2
（TLS）

提案手法

最小

25.99095.78445.164平均

26.77895.98346.552

最大28.20699.24548.655ンが確立できると考える。従って、セキュリティとリアル
タイム性のトレードオフとしては最適なレベルであると考えられる。
最後に、既存手法との差異として、表4に挙げられる観点5と観点6について説明する。まず、Find サービスの保護（観点5）については、論文（6）ではユニキャストを用いることにより保護されているが、論文（3）では Find サー

4－3

評価結果2：既存する対抗策や関連研究との比較

ビスを使用しない。SOME/IP プロトコルの仕様上、Find

まず、既存する対抗策である対抗策1（MAC）と対抗策

サービスはオプションであるものの、クライアントが必要

2（TLS）の2つと提案方式を比較した。比較結果についてとするサービスグループ情報の漏洩につながるため、Findは、表3に示すとおりである。クライアント認証（観点1）

サービスを保護することは重要である。また、通信の接続
車載イーサネットのセキュリティ拡張プロトコルの提案

32（5）住友電工テクニカルレビュー

第 204 号・2024 年 1 月

開始の起点としても Find サービスは重要であるため、保護

用 語 集 ーーーーーーーーーーーーーーーーーーーーーーーーーーーー

すべきと考える。一方、Offer サービス以降の保護手法に※1

ついては、ほぼ同様の保護を行っており、いずれも差がな

Transport Layer Security：インターネットなどのコン

いと考えらえる。つぎに保護レベルの変更（観点6）につピュータネットワークにおいてセキュリティを要求される通いては、本提案手法以外に言及される論文はなく、事前に信を行うためのプロトコルで、認証・暗号化・改ざんの検与えられたサービス保護レベルにて保護することが想定さ出の機能を提供する。多くの場合、コネクション型のトラれている。しかしながら、SOME/IP のサービスごとに保ンスポート層プロトコル（通常は TCP）とアプリケーショ

護レベルを変えたり、クライアントや通信路の状態に応じン層の間で使われる。

TLSて、保護レベルと動的に変更させることは有効と考える。
これらの結果より、セキュリティとリアルタイム性のト

※2

DTLS

レードオフを保ちつつ、SOME/IP-SD を保護する手法としDatagram Transport Layer Security：TLS に基づくプロて、本稿で提案する手法が有効であると結論付ける。

トコルであり、トランスポート層が UDP の場合にも TLS と同様のセキュリティを確保する目的で設計された。

表4

既存研究との比較

観点

論文（6）

論文（3）

提案手法

1. クライアント認証

○
（あり）

○
（あり）

○
（あり）

2. サーバ認証

○
（あり）

○
（あり）

○
（あり）

3. 他ノードの鍵漏洩○（影響なし）○（影響なし）○（影響なし）

4. セッション確立時間

×（長い）

5. Findサービスの保護△（ユニキャスト）

×
（なし）

○
（あり）

6. 保護レベルの変更

×
（なし）

×
（なし）

○
（あり）

5.

考

△
○
（比較的長い） （比較的短い）察

本稿で言及した SOME/IP-SD プロトコルの保護手段の他にも、いくつかの手段が存在する。例えば、IPSecやMACSec

・Raspberry PiはRaspberry Pi 財団の登録商標です。なお、本文および図中では「®」は明記しておりません。

参 考 文 献（1）
	SOME/IP Protocol Specification, AUTOSAR FO R22-11（2022）（2）
	SOME/IP Service Discovery Protocol Specification, AUTOSARFO R22-11（2022）（3）	D. Zelle, et al.,“Analyzing and Securing SOME/IP Automotive
Services with Formal and Practical Methods,”The 16th
International Conference on Availability, Reliability andSecurity, Vienna, Austria（2021）（4）	Specification of Secure Onboard Communication Protocol,
AUTOSAR FO R20-11（2020）（5）	福田 ほか、「セッション管理サーバによるSOME/IPセキュリティの検討」、
ETNET2021、pp1-8（2021）（6）	M. Iorio, et al.,“Protecting In-Vehicle Service : Security-Enabled
SOME/IP Middleware,”IEEE Vehicular Technology Magazine,
Vol. 15, No.3, pp.77-85（2020）（7） vsomeip https://github.com/COVESA/vsomeipを用いた保護手段が考えらえる。IPSec や MACSec を用いる場合、車載要件を満たしたスイッチなどが必要であり、コスト制約の厳しい車載制御システムへの適用は比較的遠い将来になるのではないかと考えられる。しかしながらその一方で、コストを追加することにより、より安全にできる可能性も有る。このため、今後の課題として、本稿では述べられなかった他の保護手段との比較が挙げられる。

6.

結

言

本稿では、セキュリティとリアルタイム性の良いトレードオフを実現するため、SOME/IP-SD の拡張プロトコルを提案した。Find サービスと Offer サービスのシーケンスに対して適切な保護策を施し、既存手法よりも通信オーバー
ヘッドを低減した方式である。さらに、通信を保護するためのサービス保護レベルを導入することにより、様々な保護手段を動的に変更できることを示した。
今後は、実車への適用、他の保護手段との比較についても議論する予定である。
車載イーサネットのセキュリティ拡張プロトコルの提案

33（6）住友電工テクニカルレビュー

第 204 号・2024 年 1 月

執 筆 者 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
上田浩 史＊ ：㈱オートネットワーク技術研究所
グループ長

倉地

亮＊ ：名古屋大学
特任准教授
博士（情報科学）高田広 章 ：名古屋大学
センター長・教授
博士（理学）

井上雅 之 ：㈱オートネットワーク技術研究所主幹

上口翔 悟 ：㈱オートネットワーク技術研究所

和田

健 冶 ：㈱オートネットワーク技術研究所

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー＊主執筆者

車載イーサネットのセキュリティ拡張プロトコルの提案

34（7）