Protecting SOMEIP Communication Via Authentication

sensors
Article
Protecting SOME/IP Communication via Authentication Ticket
Seulhui Lee , Wonsuk Choi and Dong Hoon Lee *
School of Cybersecurity, Korea University, Seoul 02841, Republic of Korea; hoisulhi@korea.ac.kr (S.L.);
beb0396@korea.ac.kr (W.C.)
* Correspondence: donghlee@korea.ac.kr
Abstract: Designed using vehicle requirements, Scalable service-Oriented MiddlewarE over IP

(SOME/IP) has been adopted and used as one of the Ethernet communication standard protocols
in the AUTomotive Open System Architecture (AUTOSAR). However, SOME/IP was designed
without considering security, and its vulnerabilities have been demonstrated through research. In
this paper, we propose a SOME/IP communication protection method using an authentication server
(AS) and tickets to mitigate the infamous SOME/IP man-in-the-middle (MITM) attack. Reliable
communication between the service-providing node and the node using SOME/IP communication is
possible through the ticket issued from the authentication server. This method is relatively light in
operation at each node, has good scalability for changes such as node addition, guarantees freshness,
and provides interoperability with the existing SOME/IP protocol.
Keywords: SOME/IP; in-vehicle network; automotive Ethernet; security; authentication ticket
1. Introduction
A vehicle comprises many electronic control units (ECUs) developed by various com-
panies. Each electronic control unit is responsible for its dedicated functions, such as engine
control, brake control, steering control, infotainment system, etc. When necessary, ECUs
communicate with each other through the network. In recent years, the requirements
Citation: Lee, S.; Choi, W.; Lee, D.H. for software installed in vehicles have become much more advanced based on functions
Protecting SOME/IP Communication such as advanced driver assistance systems (ADAS), infotainment, and over-the-air (OTA)
via Authentication Ticket. Sensors software updates. Following this trend, software complexity has risen accordingly, and
2023, 23, 6293. https://doi.org/ either vulnerabilities or the number of attack surfaces of the entire system could increase.
10.3390/s23146293 In this situation, standardization and development of automotive software frameworks
Academic Editors: Nicola Zannone,
like the standardized automotive software reference architecture AUTOSAR have many ad-
Giuseppe Piro and Savio
vantages, including reducing the complexity of software installed in vehicles, maintaining
Sciancalepore software quality, and reducing research and development costs.
In the AUTOSAR platform, high-bandwidth Ethernet communication is utilized to
Received: 27 May 2023 enable seamless communication between various functionalities within a vehicle, requiring
Revised: 29 June 2023
fast processing of large amounts of data. (However, because bus communication like
Accepted: 6 July 2023
the Controller Area Network (CAN) protocol has specific advantages, it is still used for
Published: 11 July 2023
control messages where real time and reliability are essential). To this end, AUTOSAR
adopted Scalable service-Oriented MiddlewarE over IP (SOME/IP) as an Ethernet middle-
ware protocol [1–6]. SOME/IP is designed for service-oriented middleware (SOM) based
Copyright: © 2023 by the authors.
on automotive requirements and is used to transmit vehicle control messages between
Licensee MDPI, Basel, Switzerland.
multiple electronic control devices. SOME/IP is flexible and scalable, supporting various
This article is an open access article communication methods and data types. In addition, it has many other advantages, like
distributed under the terms and not depending on the platform and being economical because it transmits data only when
conditions of the Creative Commons the receiver needs the data. Since the data exchanged through SOME/IP in the vehicle
Attribution (CC BY) license (https:// are mainly vehicle control messages, it cannot be emphasized enough how vital SOME/IP
creativecommons.org/licenses/by/ communication security is. A vehicle control message that has been maliciously manipu-
4.0/). lated by an attacker causes the vehicle’s control system to operate in a way the driver does
Sensors 2023, 23, 6293. https://doi.org/10.3390/s23146293 https://www.mdpi.com/journal/sensors

Sensors 2023, 23, x FOR PEER REVIEW 2 of 20
communication security is. A vehicle control message that has been maliciously manipu-
Sensors 2023, 23, 6293 lated by an attacker causes the vehicle’s control system to operate in a way the driver 2does of 19
not want, which can lead to life-threatening consequences for the driver and passengers.
It does not happen only in movies or the imagination, as demonstrated in the Fiat Chrysler
remote hacking
not want, which demonstration by Charlie Miller
can lead to life-threatening and Chris
consequences for Valasec
the driver[7,8].
andThere are alsoIt
passengers.
well-known attacks and studies in the automotive industry [9,10], not
does not happen only in movies or the imagination, as demonstrated in the Fiat Chrysler only through wired
communication,
remote hacking demonstration by Charlie Miller and Chris Valasec [7,8]. There are and
but also through wireless, including but not limited to intercepting also
replaying
well-known keyless
attacksentry
and system
studies signals, compromising
in the automotive control
industry systems
[9,10], for through
not only unauthorized
wired
manipulation,
communication, andbut
exploiting GPS systems
also through wireless,for trackingbut
including or falsifying
not limited vehicle location data.
to intercepting and
Therefore, the security
replaying keyless entry of SOME/IP
system signals,is considered
compromising essential
controland is a task
systems that must be
for unauthorized
solved.
manipulation, and exploiting GPS systems for tracking or falsifying vehicle location data.
Man-in-the-middle
Therefore, the security of(MITM)
SOME/IP attacks that canessential
is considered be appliedandto is SOME/IP
a task thatasmustwellbeassolved.
rele-
vant mitigation methods have been introduced in other studies. We considered
Man-in-the-middle (MITM) attacks that can be applied to SOME/IP as well as relevant these at-
tacks and the
mitigation limitations
methods haveofbeen
otherintroduced
studies. The inmain
othercontributions of the presented
studies. We considered thesescheme
attacks
in this
and thepaper are: of other studies. The main contributions of the presented scheme in this
limitations
paper
1. are:
Protection against MITM attacks by allowing only authenticated end nodes to com-
1. municate
Protection using an authentication
against MITM attacks ticket released
by allowing by authenticated
only an authentication endserver
nodes to com-
2. Efficient
municate operations for secure communication
using an authentication ticket released viaby
a symmetric key
an authentication server
3.
2. High portability
Efficient for security
operations for secureexpansion when the
communication viacurrent SOME/IP
a symmetric keyprotocol is used
3. Scalability
4. High portability
of nodefor security
changes byexpansion
reducing when the current
the number SOME/IP
of required updateprotocol
pointsis used
4. Prevention
5. Scalability of replay
node changes
attacks by reducing
verifying thethe number
freshness oftoken
required update points
5. Section
Prevention of replay attacks
2 summarizes by verifying
the primary contentsthe freshness
and token of SOME/IP, and Sec-
characteristics
tion 3Section
reviews2 related
summarizesworks.the primary
Section contents
4 details the and characteristics
proposed scheme, andof SOME/IP, and
Section 5 ana-
Section
lyzes its 3security,
reviewsincluding
related works.
ProVerif.Section 4 details scheme
The proposed the proposed scheme,
is evaluated and Section
in Section 6, and5
analyzes
the its security,
conclusion of this including ProVerif.inThe
study is presented proposed
Section 7. scheme is evaluated in Section 6,
and the conclusion of this study is presented in Section 7.
2. SOME/IP
2. SOME/IP
2.1. SOME/IP
2.1. SOME/IP
First, we overview SOME/IP and how it works. SOME/IP is an automotive Ethernet
First, we overview SOME/IP and how it works. SOME/IP is an automotive Ethernet
middleware communication protocol optimized to transmit vehicle control messages of
middleware communication protocol optimized to transmit vehicle control messages of
various sizes and formats on different operating systems for each device. As shown in
various sizes and formats on different operating systems for each device. As shown in
Figure 1, SOME/IP is implemented in OSI Layer 5–7 and has the advantages of being a
Figure 1, SOME/IP is implemented in OSI Layer 5–7 and has the advantages of being
protocol
a protocol optimized
optimized for for
vehicle requirements
vehicle requirements and and
being readily
being applicable
readily to various
applicable plat-
to various
forms
platforms and limited-resource environments. AUTOSAR has designated SOME/IPau-
and limited-resource environments. AUTOSAR has designated SOME/IP as an as
tomotive Ethernet
an automotive communication
Ethernet standard
communication middleware.
standard While While
middleware. traditional vehiclevehicle
traditional CAN
communication
CAN communication is static, SOME/IP
is static, communication
SOME/IP is dynamic
communication and service-oriented
is dynamic and service-orientedbe-
cause it is designed based on service-oriented architecture (SOA). SOME/IP
because it is designed based on service-oriented architecture (SOA). SOME/IP is capable is capable of
various types of communication, such as publish/subscribe, fire/forget, notification
of various types of communication, such as publish/subscribe, fire/forget, notification of of spe-
cific events
specific or subscription,
events and general
or subscription, request/response
and general communication.
request/response Only the
communication. client
Only the
that needs
client a particular
that needs serviceservice
a particular can receive data by
can receive requesting
data a service.
by requesting a service.
Figure 1. SOME/IP based on OSI 7 layer.

Sensors 2023, 23, 6293 3 of 19
2.2. SOME/IP-SD
The OfferService message is multicast or unicast to the clients to deliver information
about the service provision. If the client does not receive the required OfferService message
within the valid time, it sends a FindService message to find its provider. These messages
are SOME/IP-SD (Service Discovery) [11]. SOME/IP-SD enables flexible communication of
SOME/IP, such as searching for and subscribing to necessary services. Through SOME/IP-
SD, only clients who need data for a specific service can receive data to communicate
economically. Economic communication refers to the practice of not transmitting unnec-
essary data. However, even though SOME/IP-SD messages are mostly multicast, there
is no way to trust the endpoint because there is no separate verification method for the
transmitted endpoint. The advantage of flexible communication of SOME/IP, though, can
be a security vulnerability. As a result, researchers have revealed several feasible MITM
attacks related to SOME/IP communication [12,13]. Since the importance of protecting ve-
hicle control and messages is very high, a secure SOME/IP communication method that is
both robust against possible attacks while maintaining the advantages of the SOME/IP-SD
protocol is required.
2.3. SOME/IP MITM Attack

SOME/IP-SD makes flexible service provision and searches possible. It is no exagger-
ation to say that a feasible MITM attack related to SOME/IP originates from information
sharing on services transmitted through multicasted SOME/IP-SD messages. If an attacker
can come within the range of a network that is capable of receiving multicast messages, or
if they succeed in infecting a normal node, the attacker can easily find information about
which instance provides a particular endpoint for a specific service. When SOME/IP-SD
messages are transmitted and received, there is no procedure or policy that can verify
consistency between each endpoint and service, making various attacks possible.
Figure 2 shows a representative SOME/IP MITM attack [12]. If a server (192.168.0.2)
sends an OfferService message for its service (the service ID is 0x1234, and the instance ID
is 0x5678) by multicast, both a legitimate client (192.168.0.3) and an attacker (192.168.0.4),
who has successfully invaded an in-vehicle network, can receive the message. The attacker
changes the message’s endpoint to their own and re-sends it via multicast. Now, the client
wants to use the service and sends a request. Depending on the SOME/IP implementation,
the client can request the service to the first or last offered endpoint. Suppose the client
sends it to the last provided endpoint, that is, the client sends a Request message to the
attacker. Then, the attacker forwards it by changing its endpoint to the attacker’s. When
a server receives a Request message from an attacker, it sends a Response message, and
then the attacker can read and change the data as they want and re-send the message to
the client. In this way, an MITM attack can occur. A detailed description of representative
MITM attacks is explained in the blog [12] written by Shir Mousseri from ARGUS cyber
security. Zelle et al. [13] present various MITM attack scenarios that can occur in SOME/IP,
as well as the feasibility of the attacks in detail. Since actual vehicle control messages can
create hazardous situations when attacked, a method that mitigates MITM attacks and does
not affect the vehicle’s requirements is needed. Several proposals have been published as a
result of these studies.
Sensors 2023,
Sensors 23, x6293
2023, 23, FOR PEER REVIEW 4 4ofof20
19
Figure 2. A representative SOME/IP MITM attack.

Figure 2. A representative SOME/IP MITM attack.
3. Related Works
To ensure
3. Related Worksthe secure usage of SOME/IP, there are various papers [13–17] available.
Among them, I have compared two early papers with my own research.
To ensure the secure usage of SOME/IP, there are various papers [13–17] available.
Among them,
3.1. Secure I have compared two early papers with my own research.
SOME/IP
3.1. Secure
Among SOME/IP
the papers suggesting methods that mitigate SOME/IP MITM attacks, Iorio
et al.Among
[14,15] presented
the papersan additionalmethods
suggesting handshake thatbefore
mitigateactual SOME/IP
SOME/IP MITM communication
attacks, Iorio
between
et the presented
al. [14,15] server using
anSOME/IP
additionalcommunication
handshake before andactual
all clients with acommunication
SOME/IP specific service.
This SOME/IP
between communication
the server using SOME/IP protocol introduced aand
communication process to establish
all clients with a each session
specific and
service.
subsequently was configured to proceed. The tasks carried out in the added
This SOME/IP communication protocol introduced a process to establish each session and handshake are
as follows:
subsequently was configured to proceed. The tasks carried out in the added handshake
are
1. asMutual
follows:node authentication through the public key infrastructure (PKI) method
1. Mutual check
2. Policy among nodes through
node authentication for the service listed
the public keyin the certificates
infrastructure (e.g.,
(PKI) a service
method
providing
2. Policy check availability
among nodesor service subscription
for the availability)
service listed in the certificates (e.g., a service
3. providing
Sharing the SOME/IP communication security level
availability or service subscription availability) to be used
3. Sharing the SOME/IP communication security level to SOME/IP
4. Sharing the security material (e.g., key value, etc.) for be used communication
For this to
4. Sharing thebesecurity
possible, each node’s
material (e.g., private key etc.)
key value, and certificate
for SOME/IP hadcommunication
to be configured first
in allForECUs
this to be possible, each node’s private key and certificate hadlevels
in advance. The security level would be divided into three to beaccording
configuredto
the security level exchanged during the handshake process. One level was
first in all ECUs in advance. The security level would be divided into three levels accord- “nosec”, which
wastothe
ing thesame as the
security existing
level exchangedSOME/IP
duringmessage and would
the handshake mean
process. Onenolevel
action
waswas taken
“nosec”,
on the actual SOME/IP message after the handshake. Another
which was the same as the existing SOME/IP message and would mean no action was was “integrity”, which
provided only message integrity, and the last was “confidentiality”, which guaranteed
taken on the actual SOME/IP message after the handshake. Another was “integrity”,
message confidentiality. In the handshake process, one message was exchanged from
which provided only message integrity, and the last was “confidentiality”, which guaran-
Client to Server, and Server to Client. Compared to the SOME/IP protocol, two message
teed message confidentiality. In the handshake process, one message was exchanged from
transmissions would be added to authenticate the node and exchange security materials
Client to Server, and Server to Client. Compared to the SOME/IP protocol, two message
for secure communication from that point.
transmissions would be added to authenticate the node and exchange security materials
In this existing method, the server providing the service had to conduct a 1:1 hand-
for secure communication from that point.
shake with each client and maintain the session. Therefore, even a node that did not need
In this existing method, the server providing the service had to conduct a 1:1 hand-
to subscribe to a service or request data would immediately have to maintain a session
shake with each client and maintain the session. Therefore, even a node that did not need
by performing a handshake. From the viewpoint of economical communication, which
to subscribe to a service or request data would immediately have to maintain a session by
was the advantage of the SOME/IP protocol, this was not ideal. In addition, since an
performing a handshake. From the viewpoint of economical communication, which was
asymmetric key-based operation was involved, the protocol performed relatively heavy
the advantage
operations, so of
at the SOME/IP
times it would protocol, this to
be difficult was not ideal.process
smoothly In addition, since an asymmet-
the operations for nodes
ric key-based operation was involved, the protocol performed
with limited resources. In addition, a replay attack could be possible here relatively heavy operations,
because secure
so at times it
SOME/IP would be difficult
communication to smoothly
neither suggested process the operations
a re-keying mechanism for nodes with limited
for a long-running
resources.
service, norIndid addition,
it includea replay attack
processing forcould
messagebe possible
freshness.here because secure SOME/IP
communication neither suggested a re-keying mechanism for a long-running service, nor
did
3.2. itSESO-RC,
include processing
SESO-AS for message freshness.
Zelle et al. [13] presented several SOME/IP MITM attack scenarios and showed the
3.2. SESO-RC,
feasibility SESO-AS
of actual MITM attacks using the revealed attack procedures. The authors
Zelle ettwo
suggested al. security
[13] presented several
extensions as SOME/IP MITM
MITM attack attack scenarios
mitigation methods.and showed the
SESO-RC, the
feasibility of actual
first proposed MITM
method, attacksa using
adopted the revealed
PKI-based attack procedures.
mutual authentication The similar
method authorstosug-
the
gested two security extensions as MITM attack mitigation methods. SESO-RC, the first
Sensors 2023, 23, 6293 5 of 19
secure SOME/IP [14,15] in Section 3.1, but unlike the latter, it did not have an additional
handshake process. In the message exchange process using the SOME/IP protocol, the DH
key exchange was applied to create a session key. Also, SESO-RC was not a fine-grained
policy, as it had keys and policies per ECU. Having per-end node policies is preferred
because multiple SOME/IP services can be provided in one ECU. Similarly to secure
SOME/IP, SESO-RC also used asymmetric key operations. Because of this, a security
extension operation could be restricted if a process operated on an ECU with limited
resources. The policies among the nodes would be specified in the certificate in both secure
SOME/IP [14,15] and SESO-RC [13]. After verifying certificates, the nodes would check
service provision/subscription availability based on the policies written in the received
certificate. Note that this method is inflexible to node change. This means that, if a new
node providing a SOME/IP service were added to a vehicle through a software upgrade
and existing nodes wanted to use the new service, they would have had to adopt all
relevant ECU software updates since the certificates needed to be re-issued to have a new
policy. Therefore, changing a node or service would entail a lot of additional overhead,
such as revoking and managing the existing certificate and updating the related ECU’s SW
to obtain a certificate.
In SESO-AS, the second security extension proposed in the same paper [13], an addi-
tional authentication server was introduced. SESO-AS assumed that the symmetric key
and policy for each ECU were set in the authentication server in advance. When the server
transmitted the OfferService message, including the session key, to the authentication server
with the message MAC value [18], the authentication server would first verify the MAC
with the pre-set server key and then check the policy. Afterward, the authentication server
played a role in distributing OfferService messages and a session key to ECUs that were
able to subscribe to this service. In this process, the session key was encrypted with the
pre-configured long-term key for each ECU receiving OfferService messages. A so-called
“container” with the encrypted session key and MAC were created per receiving ECU. The
authentication server would configure a new data structure called an OS, which included
containers, and multicast it to receiving clients. From the perspective of one client ECU,
unnecessary data would have been received because containers for other ECUs must first
be obtained. From the standpoint of the authentication server, unnecessary containers must
be created even for clients not presently subscribed, assuming they had permission. For
these reasons, SESO-AS is inefficient in many respects.
3.3. Comparison
Table 1 shows the comparison among various schemes introduced so far in this
paper. “Scalability” means that a scheme experiences a few changes when integrating a
new node. We can know whether a scheme’s policies and keys are fine-grained through
“Granularity”. “Overhead” tells how much cryptographic operational overhead occurs
when the scheme is applied, and we can know whether or not a scheme is compatible
with the current SOME/IP protocol by looking at “Compatibility”. Finally, “Efficiency”
shows if the required additional operation is applied only for a node that needs it. Ticket-
based SOME/IP indicates the novel scheme we are proposing in this paper. Ticket-based
SOME/IP and SESO-AS support high scalability thanks to the leveraging of an additional
server. As ticket-based SOME/IP and Secure SOME/IP manage keys and policies per node;
they are fine-grained granularity. For the overhead aspect, Secure SOME/IP and SESO-RC
have high overhead because of public key cryptography operation. Ticket-based SOME/IP
and Secure SOME/IP can select whether a security expansion applies or not per service,
which assures compatibility with the current SOME/IP protocol. Secure SOME/IP makes a
1:1 connection with every node if it can use SOME/IP. SESO-AS’s authentication server
makes containers for every node that can use the service. For these reasons, “Efficiency” is
marked as “Low” for Secure SOME/IP and SESO-AS.
Sensors 2023, 23, 6293 6 of 19
Table 1. Comparison table showing various schemes.
Scheme Scalability Granularity Overhead Compatibility Efficiency

Ticket-based SOME/IP High Fine-grained Low Supported High
Secure SOME/IP Low Fine-grained High Supported Low
SESO-RC Low Coarse grained High Not Supported High
SESO-AS High Coarse grained Low Not Supported Low
We found that “Granularity” is crucial because if policies and keys are not fine-grained,
SOME/IP MITM and other attacks can occur. This is because, if an attacker can compromise
one node, they can disguise all nodes in the same ECU since they share keys and policies.
Therefore, we evaluated our scheme only with Secure SOME/IP.
Considering these points, we suggest a flexible scheme that expands with a minimum
SW update when changing nodes, mutually trusts the server and client, selectively performs
only services that require additional security expansion, and minimizes overhead for each
node.
4. Proposed Scheme
4.1. Prerequisites
Our proposal includes SOME/IP communication that can be operated by checking the
services and node consistency through mutual server and client authentication as well as
service policy verification [19] via an authentication server (AS) and authentication tickets
issued from the server. The basic concept of this method is similar to Kerberos [20], but it
is applied to the existing SOME/IP protocol and configured in a more simplified way in
consideration of performance. The node mentioned in this paper refers to the end node
process that provides and uses actual services. The node could be a functional cluster or
application. Before describing our proposed method, we first outline the limitations:
(1) All SOME/IP end nodes have a cryptographically secure long-term key, and
policies are defined for service provision/availability between all endpoints. Keys and
policies for each node must be provisioned in advance in an AS and in a secure manner.
(2) Time sync must be ensured among all ECUs in the vehicle.
(3) Since both node-to-node authentication and policy verification are performed in the
AS, it is assumed that the AS is trustworthy. A system (including the key, policy, etc.) must
be safely managed through various security solutions such as secure boot and hardware
security module, and an SW update must also be controlled through reliable methods.
Note that the detailed techniques for this are outside the scope of this paper and will not be
discussed in detail.
(4) We assume that the database for keys and policies managed by the AS is configured
in a way that allows secure and fast operation according to the situation of each server.
Note that database management and optimization are outside the scope of this paper and
will not be discussed in detail.
4.2. Attack Models

The attack models considered for this paper are listed below. These attack models
are well-known attacks that can be launched against the in-vehicle network, and they are
attacks that could cause serious consequences if they occurred during the delivery of a
vehicle control message:
(1) Man-in-the-middle attack: An attacker can intercept an original message and send
a modified one.
(2) Replay attack: An attacker can gain unauthorized access or cause a malfunction by
reading, recording, and replaying legitimate messages transmitted between two nodes.
(3) DoS attack: An attacker can prevent a client node from operating normally by
replaying the Response message.
(4) Spoofing attack: An attacker can send and receive messages illegitimately by
pretending to be a legitimate device in the in-vehicle network.
Sensors 2023, 23, x FOR PEER REVIEW 7 of 20
Sensors 2023, 23, 6293 (4) Spoofing attack: An attacker can send and receive messages illegitimately by7pre-
of 19
tending to be a legitimate device in the in-vehicle network.
4.3. Overall Flow

4.3. Overall Flow
The
The schematic
schematic flow
flow of
of the
the method
method proposed in this
proposed in this paper is shown
paper is in Figure
shown in Figure 33 below.
below.
Figure 3.
Figure Overall SOME/IP
3. Overall SOME/IPcommunication
communicationflow
flowfor
forproposed
proposedscheme
scheme((a)
((a)original
originalflow,
flow,(b)
(b)addi-
addi-
tional flow).
tional flow).
In general
In general SOME/IP communication, the
SOME/IP communication, the Server
Server S1
S1 multicasts/unicasts OfferService
multicasts/unicasts OfferService
messages to
messages to clients.
clients. In
Inthe
theproposed
proposed method,
method, the
the OfferService
OfferService message
message is
is transmitted
transmitted with
with
a flag that indicates that the service requires an authentication ticket corresponding
a flag that indicates that the service requires an authentication ticket corresponding to the to
the importance of the provided service. Assume that Client A receives the OfferService
importance of the provided service. Assume that Client A receives the OfferService mes-
message and wants to subscribe to this service. First, our method verifies whether the
sage and wants to subscribe to this service. First, our method verifies whether the corre-
corresponding service requires a ticket. If it is not needed, it immediately responds in
sponding service requires a ticket. If it is not needed, it immediately responds in the orig-
the original communication method (e.g., Request message). This is shown in process
inal communication method (e.g., Request message). This is shown in process “a” of Fig-
“a” of Figure 3. After this, our method additionally performs process “b” to obtain an
ure 3. After this, our method additionally performs process “b” to obtain an authentication
authentication ticket if necessary. The formulas under the directed edge for each step
ticket if necessary. The formulas under the directed edge for each step represent the rough
represent the rough composition of added data when a ticket is required. Table 2 shows the
composition of added data when a ticket is required. Table 2 shows the used notation in
used notation in the figure and corresponding detailed descriptions, which can be found
the figure and corresponding detailed descriptions, which can be found starting in Section
starting in Section 4.4 of this paper. In process “b”, two messages are added: a RequestTicket
4.4 of this paper. In process “b”, two messages are added: a RequestTicket message, which
message, which requests an authentication ticket from the AS, and a ReturnTicket message,
requests an authentication ticket from the AS, and a ReturnTicket message, which returns
which returns the requested authentication ticket. The proposed scheme consists of four
the requested authentication ticket. The proposed scheme consists of four phases: Offer-
phases: OfferService, RequestTicket, ResponseTicket, and Request.
Service, RequestTicket, ResponseTicket, and Request.
Table 2. Notations for the proposed scheme’s overall flow in Figure 3.
Table 2. Notations for the proposed scheme’s overall flow in Figure 3.
Notation Description
OfferService
OfferService Original
Original OfferService
OfferService payload
payload
Request
Request Original
Original Request Request
payloadpayload
SD SD ServerData
ServerData that isthat is configured
configured by a server
by a server
Ks Pre-configured server’s symmetric key shared with an AS
Ks Pre-configured server’s symmetric key shared with an AS
Kc Pre-configured client’s symmetric key shared with an AS
Kc Pre-configured client’s symmetric key shared with an AS
H (key, value) HMAC calculated value for ‘value’ by ‘key’
H (key, value)
CD HMAC ClientData
calculated value
that isfor ‘value’ byby‘key’
configured a client
CD AST ClientData that is configured by a clientby an AS
AuthServerTicket that is configured
AST ACT AuthServerTicket that isthat
AuthClientTicket configured by anby
is configured ASan AS
ACT FT AuthClientTicket that that
FreshnessToken is configured by an
is configured byASa client
FT FreshnessToken that is configured by a client
4.4. OfferService Phase
This message is sent as a multicast or unicast message to notify the client that the server
provides a specific service. In this phase, the server can set a flag to indicate whether or
not an authentication ticket is required to use the service, which can be selectively applied
depending on the importance of the service. In actual implementation, this flag is set using
unused bits in the message types of SOME/IP messages. When creating an OfferService
4.4. OfferService Phase
4.4. OfferService Phase
This message is sent as a multicast or unicast message to notify the client that the
This
server message
provides is sent as
a specific a multicast
service. or unicast
In this phase, message
the server cantosetnotify
a flag the client that
to indicate the
whether
Sensors 2023, 23, 6293 server provides a specific service. In this phase, the server can set a flag
or not an authentication ticket is required to use the service, which can be selectively ap-to indicate whether
8 of 19
orplied
not an authentication ticket is required to use the service, which
depending on the importance of the service. In actual implementation, this flag is can be selectively ap-
plied depending
set using unusedonbits theinimportance
the message of types
the service. In actual
of SOME/IP implementation,
messages. this flag
When creating is
an Of-
set using unused
ferService
message message
that bitsthat
requests in athe message
requests
ticket types
fora ticket
the ofthe
for
service SOME/IP
inservice messages. When
in theServerData
the server, server, creating
ServerData an Of-
is addi-
is additionally
ferService
tionally message
configured, that
as requests
shown ina ticket
Figure for
4 the
below, service
after in
thethe server,
original
configured, as shown in Figure 4 below, after the original OfferService message payload ServerData
OfferService is addi-
message
tionally
part. Forconfigured,
payload apart.
detailed as showndescription
For adescription
detailed inofFigure 4ofbelow,
the notation the usedafter
in the
notation original
used
Figure in OfferService
Figure
4, refer to4, refer3.tomessage
Table Table 3.
payload part. For a detailed description of the notation used in Figure 4, refer to Table 3.
Figure4.4.Data
Figure Dataadded
addedbehind
behindananOfferService
OfferServicemessage
messagewhenwhenaaservice
servicerequires
requiresaaticket.
ticket.
Figure 4. Data added behind an OfferService message when a service requires a ticket.
Table 3. Descriptions of notations for the refined OfferService message data in Figure 4.
Table 3. Descriptions of notations for the refined OfferService message data in Figure 4.
Table 3. Descriptions of notations for the refined OfferService message data in Figure 4.
Notation Notation Description
OfferService OriginalDescription
OfferService payload
OfferService
IDs OfferService Original
An identifier that can uniquely Original
OfferService
identify a service OfferService
payload payload
instance (ServiceID||InstanceID)
IDs
ServerEndPoint An identifier that
IP can
address and An
uniquely identifier
portidentify
numberathat canservice’s
service
of the uniquely
instance identifyserver
a service instance
(ServiceID||InstanceID)
current
IDs
ServerEndPoint IP address andduring
port number (ServiceID||InstanceID)
TicketValidPeriod Period which of
thethe service’s
issued current
ticket is validserver
TicketValidPeriod ServerEndPoint IP address
PeriodData
during whichand
theport number
issued ticketofisthe service’s current server
valid
ServerData from IDs to TicketValidPeriod
TicketValidPeriod Period during which the issued ticket is valid
HMACServerData
(Ks, ServerData) Data from IDs tomade TicketValidPeriod
ServerDataHMAC value for ServerData Data from with
IDsa to
long-term server key
TicketValidPeriod
HMAC (Ks, ServerData) HMAC
HMAC (Ks, ServerData)
value for ServerData made with a long-term server key
HMAC value for ServerData made with a long-term server key
When a ticket is required, the parts that need to be added/changed in the existing
When a ticket
OfferService messageis required, the parts
are the setting of that
a flag need
bit to be added/changed
indicating that the servicein therequires
existing a
When
OfferService a ticket is
message are of required, the
theServerData,parts
setting of aand that need
flagthe to be
bitadditional added/changed
indicatingHMAC that the(hash-basedin the existing
service requires a
ticket, the configuration message
OfferService
ticket, message
the configuration are the setting
of ServerData, of a flag bit indicating that the service requires a
authentication code) value created withand the additional
a long-term serverHMAC
key. By(hash-based
sending themessage
identifier
ticket, the
authentication configuration
code) of ServerData, and the additional HMAC (hash-based message
that can identify thevalue
service created
and the with a long-term
endpoint server
providing thekey. By sending
service, the identifier
it is possible to secure
authentication
that can identify code)
the value and
service created
the with a long-term
endpoint providing server
the key. Byitsending
service, is the to
possible identifier
secure
the endpoint of the current service during future communication.
thatendpoint
the can identify
of thethecurrent
serviceservice
and theduring
endpoint providing
future the service, it is possible to secure
communication.
the endpoint of the current service during future communication.
4.5. RequestTicket Phase
4.5. RequestTicket Phase
If a client receives
4.5. RequestTicket Phase an OfferService message transmitted by the server and wants to
use Ifthe
a client receives
If a client receives if
service, check an OfferService
anthe ismessage
ticket flag message
OfferService set in thetransmitted
messageby
transmitted
by the
first,
theand
server
serverif not, and wants to
andcommunicate
wants to use
use
in the
an service,
existing check
way. If if
thethe ticket
ticket is flag is
needed, seta in the message
RequestTicket first,
message
the service, check if the ticket flag is set in the message first, and if not, communicate and isif not, communicate
transmitted to an AS
in an
in an existing
as formatted
existing way.
way. in If
Figure
If the the
ticket ticket
5. For is needed,
a detailed
is needed, a RequestTicket
description ofmessage
a RequestTicket message
notations, is
is refertransmitted to an
to Tableto4.an AS as
transmitted AS
as formatted
formatted inin Figure
Figure 5. 5. For
For a detailed
a detailed description
description ofof notations,
notations, refer
refer to to Table
Table 4. 4.
Figure 5. Data configured when a client needs to request a ticket from an AS.
Dataconfigured
Figure5.5.Data
Figure configuredwhen
whenaaclient
clientneeds
needstotorequest
requestaaticket
ticketfrom
froman anAS.
AS.
Table 4. Descriptions of notation for RequestTicket message data in Figure 5.
Table
Table4.4.Descriptions
Descriptionsofofnotation
notationfor
forRequestTicket
RequestTicket message
message data
data in
in Figure
Figure 5.5.
Notation
ServerData Notation ServerData received Description
from a serverDescription
through OfferService
ServerData
HMAC (Ks, ServerData) HMAC value for ServerData received from a serverOfferService
ServerData received from a server through through OfferService
ServerData ServerData received from a server through OfferService
HMAC (Ks,IDc
ServerData) HMAC value for ServerData
Identifier received
that canvalue
uniquely from a server
identify through
a client OfferService
(ClientID)
HMAC for ServerData received from a server through
IDc
ClientEndPoint HMAC (Ks, ServerData)
Identifier that can uniquely identify
Client’s current IP address and a client (ClientID)
port number
OfferService
ClientEndPoint
ClientData IDc Client’s
Data current
from IP that
address
ServerData
Identifier and port number
cantouniquely
ClientEndPoint
identify a client (ClientID)
HMACClientData
(Kc, ClientData) ClientEndPoint Datafor
HMAC value from ServerData
ClientData
Client’smade to ClientEndPoint
currentwith a long-term
IP address and client key
port number
HMAC (Kc, ClientData) ClientDataHMAC value for ClientData Datamade
from with a long-term
ServerData client key
to ClientEndPoint
HMAC (Kc, ClientData) HMAC value for ClientData made with a long-term client key
In the RequestTicket message, the client configures ClientData by adding IDc, which
is designated SOME/IP client ID, and ClientEndPoint after ServerData and its HMAC.
Then, the client computes HMAC (Kc, ClientData). The message created in this way sets
the message type to a value representing a RequestTicket message and transmits it to the
AS as a SOME/IP Request message.
Sensors 2023, 23, 6293 AS as a SOME/IP Request message. 9 of 19
AS as a SOME/IP Request message.
4.6. ReturnTicket Phase
4.6. ReturnTicket Phase
When an AS
4.6. ReturnTicket receives the RequestTicket message, the following occurs:
Phase
When an AS receives the RequestTicket message, the following occurs:
(1) The AS finds the IDc from the transmitted packet in ClientData and a long-term
(1) TheanAS
When ASfinds the IDc
receives from the transmitted
the RequestTicket message, packet in ClientData
the following occurs:and a long-term
key Kc corresponding to that IDc in the AS database. The AS uses Kc to calculate the
key (1)
Kc The corresponding
AS finds theto IDcthat
from IDctheintransmitted
the AS database.packet inThe AS usesand
ClientData Kc atolong-term
calculatekey the
HMAC value of ClientData and then compares the HMAC with the HMAC of the trans-
HMAC
Kc value of ClientData
corresponding to that IDcand in thethen AScompares
database.the The HMAC
AS uses withKc the HMAC of
to calculate thethe trans-
HMAC
mitted packet, which the client calculated. If the two HMACs do not match, a “client ver-
mittedofpacket,
value ClientDatawhichand thethen
clientcompares
calculated. theIf HMAC
the two with HMACs do not match,
the HMAC of the atransmitted
“client ver-
ification fail” error code is set, and the operation stops; if they match, the process proceeds
ificationwhich
packet, fail” error codecalculated.
the client is set, and the operation
If the two HMACs stops;do if they
not match, athe process
“client proceeds
verification
to (2).
fail” error code is set, and the operation stops; if they match, the process proceeds to (2).
to (2).
(2) The AS finds the IDs, which is a unique identifier for a service instance, in Serv-
(2)
(2)TheTheAS ASfinds
findsthe theIDs,
IDs,whichwhichisisa aunique
uniqueidentifier
identifierfor fora aservice
service instance,
instance, inin
Server-
Serv-
erData and a long-term key Ks corresponding to that IDs in the AS database and calculates
Data
erData and anda long-term
a long-term keykeyKsKs corresponding
corresponding totothat
thatIDsIDsininthe
theAS ASdatabase
databaseand andcalculates
calculates
the HMAC value
the value ofServerData
ServerData withKs. Ks. Then, the the AS compares
compares that HMAC HMAC with the the
the HMAC
HMAC value of of ServerData with with Ks. Then,Then, the AS AS compares that that HMAC with with the
HMAC ofthe
HMAC the transmittedpacket, packet, whichthe the servercalculated.
calculated. If thetwo two HMACsdo do not
HMAC of of thetransmitted
transmitted packet,which which theserver server calculated. IfIf the the two HMACs
HMACs donot not
match,
match, a “server verification fail” error code is set, and the operation stops; if they match,
match,aa“server“server verification
verification fail”fail” error
error code
code is is set,
set, and
and thethe operation
operation stops;
stops; ifif they
they match,
match,
the processproceeds
the proceeds to(3). (3).
theprocess
process proceedsto to (3).
(3)
(3) Based on the IDs and theIDc, IDc, policyviolations
violations betweennodes nodes arechecked
checked inthe the
(3)Based
Basedon onthe
theIDsIDsandandthe the IDc,policy
policy violationsbetween between nodesare are checkedin in the
AS
AS policy data. For example, in a relationship where the service cannot be provided or is
ASpolicy
policydata. data. For
For example,
example, in in aarelationship
relationship where wherethe theservice
servicecannot
cannot be beprovided
providedor orisis
not provided,aa“policy
not “policy denied”error error codeisisset set inthethe validationcode, code, andthe the operation
notprovided,
provided, a “policydenied” denied” errorcode code is setin in thevalidation
validation code,and and theoperation
operation
stops.
stops. In the case of a valid relationship, the process proceeds to (4).
stops. In In the
the case
caseofofaavalid
valid relationship,
relationship,the theprocess
processproceeds
proceedsto to(4).
(4).
(4) If thereisisno
(4) no problemfrom from (1)to to (3),aa“verification
“verification success” code code is set set in the
the
(4) IfIf there
there is no problem
problem from(1) (1) to(3),(3), a “verification success”success” code is is set inin the
validation
validation code.
validationcode. code.
If the
IfIf the validation code code in Section
Section 4.6 contains
contains an error, error, theAS AS generatesan an HMAC
the validation
validation code in in Section 4.6 4.6 contains an an error,the the ASgenerates
generates an HMAC HMAC
valuerelating
value relatingto tothe
theerror
errorcodecodewith withthe theclient’s
client’slong-term
long-termkey keyKcKcandandsends
sendsititto tothe
the client
value relating to the error code with the client’s long-term key Kc and sends it to theclient client
as a ReturnTicketmessage,
as message, asshown shown inFigure Figure 6. If thevalidation
validation codeisis“verification
“verification
as aa ReturnTicket
ReturnTicket message, as as shownin in Figure6.6. IfIfthe the validation code code is “verification
success”, theAS
success”, AS isformatted
formatted as shown shown in FigureFigure 7. For For a detailed description
description of notation,
notation,
success”,the the AS isis formatted as as shown in in Figure 7. 7. For aa detailed
detailed description of of notation,
refer
refer to Table 5. The session key is generated as a cryptographically secure random value
referto toTable
Table5.5.The
Thesession
sessionkey keyisisgenerated
generatedas asaacryptographically
cryptographicallysecure securerandom
randomvalue value
afterconfirming
after confirmingthethe kind kind of service
of service in theinAS. theThe AS. The overall
overall configuration
configuration of the Re-
of the ReturnTicket
after confirming the kind of service in the AS. The overall configuration of the Re-
turnTicket
message is message is divided
divided mainly into mainly into AuthServerTicket,
AuthServerTicket, which is which
used for is used for verification
verification in the
turnTicket message is divided mainly into AuthServerTicket, which is used for verification
in the server,
server, and AuthClientTicket,
and AuthClientTicket, which is which
used is forused for verification
verification in the client.
in the client.
in the server, and AuthClientTicket, which is used for verification in the client.
Figure 6. ReturnTicketstructure
structure thatisisconfigured
configured whenaavalidation
validation codehas
has anerror.
error.
Figure6.6.ReturnTicket
Figure ReturnTicket structurethat
that is configuredwhen
when a validationcode
code hasan
an error.
Figure 7. ReturnTicket structure that is configured for a successfully generated ticket from an AS.
Figure7.7.ReturnTicket
Figure ReturnTicketstructure
structurethat
thatisisconfigured
configuredfor
foraasuccessfully
successfullygenerated
generatedticket
ticketfrom
froman
anAS.
AS.
Table 5. Descriptions of notations for ReturnTicket message data in Figure 7.
ValidationCode
Notation Validity result code checked by an AS in Section 4.5, such as peer authority and policy checks
ValidationCode Validity result code checked by an AS inDescription
Section 4.5, such as peer authority and policy checks
Time taken for the AS to perform ticket issuance plus the TicketValidPeriod delivered by the
ValidTime
ValidationCode Time taken
Validity resultfor the checked
code AS to perform
by an ASticket issuance4.5,
in Section plus theasTicketValidPeriod
such delivered
peer authority and by the
policy checks
ValidTime server in OfferService
Time taken for the AS to perform ticket issuance
server plus the TicketValidPeriod delivered by the
in OfferService
ValidTime
IDc Client ID
IDc server in OfferService
Client ID
ClientEndPoint
IDc Client’s current IP address
Client and port number
ID and
ClientEndPoint Client’s current IP address port number
E(Ks’, SessionKey)
ClientEndPoint Encrypted session
Client’s key
current with the
IP addressderived server
and port encryption key
number
E(Ks’, SessionKey) Encrypted session key with the derived server encryption key
AuthServerTicket
E(Ks’, SessionKey) Data
Encrypted from ValidationCode
session to E (Ks’,
key with the derived SessionKey)
server encryption key
AuthServerTicket Data from ValidationCode to E (Ks’, SessionKey)
AuthServerTicket Data from ValidationCode to E (Ks’, SessionKey)
HMAC (Ks, AuthServerTicket) HMAC value of AuthServerTicket generated with a long-term server key
ServerEndPoint Server’s IP address and port number
E (Kc’, SessionKey) Encrypted session key with the derived client encryption key
AuthClientTicket Data from AuthServerTicket to E (Kc’, SessionKey)
HMAC (Kc, AuthClientTicket) HMAC value of AuthClientTicket generated with a long-term client key
HMAC
HMAC (Ks,
(Ks, AuthServerTicket)
AuthServerTicket) HMAC
HMAC value
value of
of AuthServerTicket
AuthServerTicket generated
generated with
with aa long-term
long-term server
server key
key
ServerEndPoint
ServerEndPoint Server’s IP address and port number
Server’s IP address and port number
E
E (Kc’,
(Kc’, SessionKey)
SessionKey) Encrypted
Encrypted session
session key
key with
with the
the derived
derived client
client encryption
encryption key
key
AuthClientTicket
AuthClientTicket Data from AuthServerTicket to E (Kc’, SessionKey)
Data from AuthServerTicket to E (Kc’, SessionKey)
HMAC
HMAC (Kc,
(Kc, AuthClientTicket)
AuthClientTicket) HMAC
HMAC value
value of
of AuthClientTicket
AuthClientTicket generated
generated with
with aa long-term
long-term client
client key
key
Sensors 2023, 23, 6293 10 of 19
When
When the the validity
validity code
code is
is “verification
“verification success”,
success”, the
the ASAS creates
creates aa ReturnTicket
ReturnTicket mes-
mes-
sage
sage that
that becomes
becomes formatted
formatted as as shown
shown in in Figure
Figure 7,
7, sets
sets it
it as
as the
the type
type ofof the
the ReturnTicket
ReturnTicket
When the sends
message, validity code is “verification success”, the AS creates a ReturnTicket message
message, and and sends itit to
to the
the client
client as
as aa SOME/IP
SOME/IP Response
Response message.
message. In In the
the ReturnTicket
ReturnTicket
that becomes formatted as shown in Figure 7, sets it as the type of the ReturnTicket message,
message,
message, aa session
session key
key between
between thethe client
client and
and the
the server
server isis distributed
distributed by by the
the AS.
AS. Since
Since
and sends it to the client as a SOME/IP Response message. In the ReturnTicket message, a
the
the session key is encrypted with a key derived from the long-term key of each node and
session key is encrypted with a key derived from the long-term key of each node and
session key between the client and the server is distributed by the AS. Since the session key
then
then transmitted,
transmitted, only
only the
the owner
owner can
can obtain
obtain the
the session
session key.
key. The
The session
session key
key is
is used
used to
to
is encrypted with a key derived from the long-term key of each node and then transmitted,
verify
verify freshness
freshness to
to prevent
prevent aa replay
replay attack
attack and
and can
can also
also be
be used
used in
in future
future studies
studies to
to evalu-
evalu-
only the owner can obtain the session key. The session key is used to verify freshness to
ate
ate the
the confidentiality
confidentiality of
of messages.
messages. Details
Details relating
relating to the
the replay attack will be
be discussed
prevent a replay attack and can also be used in future tostudies replay attackthe
to evaluate willconfidentiality
discussed
later.
later.
of messages. Details relating to the replay attack will be discussed later.
4.7. Request Phase
4.7. Request
4.7. Phase
Phase
After
After the
After the client
theclient receives
clientreceives
receives thethe
the ReturnTicket
ReturnTicket
ReturnTicket message
message
message delivered
from from
delivered
delivered from
the AS, the
the AS, it
it first
AS, checks
it first first
checks
checks
the HMAC the
the HMAC
HMAC part
part corresponding
corresponding
part corresponding to
to AuthClientTicket
AuthClientTicket
to AuthClientTicket usingusing
using
its keyits key
itsto
key to
to check
check check whether
whether
whether the
the
the message
message
message has
has been
has been been falsified
falsified
falsified or
or altered.
altered.
or altered. If
If there
If there is nois
there no
no problem,
isproblem,
problem,
the AS the AS
AS confirms
theconfirms
confirms the
the va-
the validity va-
lidity
lidity code
code to
to verify
verify the
the authentication
authentication and
and mutual
mutual relationship
relationship
code to verify the authentication and mutual relationship between the server and itself between
between the
the server
server and
and
itself
itself through
through through ValidationCode
ValidationCode
ValidationCode in
in AuthServerTicket.
AuthServerTicket.
in AuthServerTicket. If this
this isis successful,
If successful,
If this is successful, the
the AS
the AS gets thegets
AS gets
sessionthe
the
session
session
key key by decrypting
key by decrypting
by decrypting E (Kc’, SessionKey)
E (Kc’, SessionKey)
E (Kc’, SessionKey) with
with key with key Kc’
key Kc’from
Kc’ derived derived
derived from its long-term
from its long-term
its long-term key Kc. After key
key
Kc.
Kc. After
this, this,
this, FreshnessToken
FreshnessToken
After is created, is
FreshnessToken is created,
as shown inas
created, shown
shown8. in
asFigure Figure
Figure 8.
FreshnessToken
in 8. FreshnessToken
is encryptedis
FreshnessToken en-
iswith
en-
crypted
the session
crypted with
keythe
with session
after
the key
key after
attaching
session IDc and
after attaching
CurTime,
attaching IDc and
and CurTime,
IDcwhich is the time
CurTime, which
whenis
which the
the time
time when
isFreshnessToken when
FreshnessToken
was created. This was
FreshnessToken created.
created. This
FreshnessToken
was This FreshnessToken
is added is
is added
added after
after AuthServerTicket’s
FreshnessToken after AuthServerTicket’s
HMAC and is sent to
AuthServerTicket’s
HMAC and
ServerEndPoint, is sent
as to ServerEndPoint,
shown in Figure 9. as shown
HMAC and is sent to ServerEndPoint, as shown in Figure 9. in Figure 9.
Figure
Figure 8. FreshnessToken
8. FreshnessToken
Figure 8. format.
FreshnessTokenformat.
format.
Figure
Figure 9.9. Request
Requestoror
9.Request SubscribeEventGroup
orSubscribeEventGroup
SubscribeEventGroup structure
structure that aa client configures to pass
pass AuthServer-
Figure structure thatthat client
a client configures
configures to AuthServerTicket
to pass AuthServer-
Ticket
Ticket and
and FreshnessToken
FreshnessToken to
to a
a server.
server.
and FreshnessToken to a server.
The server
The server
The receiving
server receiving this
receiving this message
this message calculates
message calculates the
calculates the HMAC
the HMAC
HMACvalue value
valueofof AuthServerTicket
ofAuthServerTicket
AuthServerTicket
with its
with its
with key
its key
key toto check
to check message
check message freshness.
message freshness.
freshness. TheThe server
The server decrypts
server decrypts FreshnessToken
decrypts FreshnessToken
FreshnessToken with with the
with the
the
acquired
acquired session
session key
key and
and checks
checks whether
whether the
the message
message was
was created
created and
and
acquired session key and checks whether the message was created and transmitted within transmitted
transmitted within
within
the valid
the valid
the time
valid time using
time using CurTime.
CurTime. If
using CurTime. If the
the transmitted
transmitted timetime is
is valid,
valid, the
the IDc in
IDc in Freshness
in Freshness
Freshness is is
is
checked
checked to
checked to see
to see if it matches
see ifif itit matches the
matches the IDc
the IDc
IDc inin the
in the ticket.
the ticket. If
ticket. If it matches,
If it matches, the
matches, the server
the server sends
server sends a Response
sends aa Response
Response
message
message to
message to the
to the client
the client endpoint
client endpoint
endpoint inin the
in the ticket
the ticket or
ticket or registers
or registers the
registers the client
the client endpoint
client endpoint
endpoint as as
as aaa service
service
service
subscriber (SubscribeEventGroupAck).
5.
5.
5. Security
Security Analysis
Analysis
5.1.
5.1. Considering
Considering the
5.1. Considering the Replay
the Replay Attack
Replay Attack
Attack
AA session
A session key
session key distribution
key distribution and
distribution and freshness
and freshness verification
freshness verification using
verification using the
using the key
the key are
key are added
are added because
added because
because
the
the server uses the client’s endpoint listed in the ticket after checking the validity between
the server
server uses
uses the
the client’s
client’s endpoint
endpoint listed
listed in
in the
the ticket
ticket after
after checking
checking thethe validity
validity between
between
nodes
nodes based on AuthServerTicket. Suppose a malicious user stole aa valid authentication
nodes based
based on
on AuthServerTicket.
AuthServerTicket. Suppose
Suppose aa malicious
malicious user
user stole
stole a valid
valid authentication
authentication
ticket
ticket and repeatedly sent messages including the ticket to the server. In that case, the server
ticket and
and repeatedly
repeatedly sent
sent messages
messages including
including thethe ticket
ticket to
to the
the server.
server. In In that
that case,
case, the
the
would
server continue to send a Response message to a victim client because it is a valid ticket,
server would continue to send a Response message to a victim client because it is aa valid
would continue to send a Response message to a victim client because it is valid
and a distributed denial of service (DDoS) attack could occur in the client node. Therefore,
before the server sends a response, the logic that verifies whether a legitimate ticket has been
delivered is added to prevent a ticket replay attack. Also, since FreshnessToken includes
the current time, it can limit the valid time of the used session key and ticket compared to
the valid time in the authentication ticket. This is a one-way authentication method using a
challenge–response approach, where the prover and verifier utilize a pre-shared symmetric
key to verify an unforgeable timestamp.
Sensors 2023, 23, 6293 11 of 19
Through this method, our suggested scheme can prevent manipulation of the end-
point, which provides and subscribes to services and is at the heart of SOME/IP MITM
attacks. Thus, even if ticket freshness is guaranteed, replay attacks on tickets are rendered
impossible.
5.2. Benefits and Concerns of Using an AS

To ensure secure communication between IoT devices, the use of an Authentication
Server is often proposed as a method [21]. The proposed method also adopts a way of
using an AS. There are well-known concerns about having two additional messages that
need to be sent and received using an AS. Before looking into these concerns, we explain
the following advantages first:
(1) As the operation arising from the extension of SOME/IP security functions is
shared in the AS, operational overhead on the end nodes is relatively small, even when the
node on the ECU has limited resources.
(2) Since key and policy management are performed in the AS, when a node is changed
(e.g., node addition/modification/deletion), only the AS needs to be updated for the related
nodes except for the node that changed. Therefore, using an AS is advantageous in terms
of scalability.
With these two advantages, we adopt the model using the AS. The proposed method
is rather similar to current in-vehicle architectures (not only to the central processing
architecture used by Tesla and Waymo but also to the Zonal architecture that traditional
automotive OEMs see as next-generation vehicle architecture). These structures make it
possible to perform SW updates for segregated security functionality quickly and easily
through the network. Through this, using the AS, it is easy to introduce nodes that provide
new functions and advantageous for vehicle security because the area to be protected is
clear. However, since a large volume of data needs to be processed at one point, a critical
problem such as a single point of failure (SPOF) could occur. As such, this process requires
high computing performance and high-speed communication technology. In this regard,
manufacturers should design and test the system to be widely available and fault-tolerant.
It also should incorporate redundant systems or fail-safe mechanisms to ensure that if one
component or system were to fail, there would be a backup to prevent a catastrophic failure.
Since the advantages and disadvantages of the introduced vehicle architecture are nearly
identical to those proposed in this paper for the security expansion of SOME/IP, we expect
that the methods offered as a supplement to address the concerns caused by the overall
architecture of the vehicle can mitigate our method’s drawbacks.
5.3. Formal Verification

To analyze our method’s security properties, we used ProVerif, an automated tool for
formally verifying security protocols, as it is designed to help security researchers identify
and eliminate security vulnerabilities in cryptographic protocols. Security properties are
typically secrecy, authenticity, and integrity. For these properties, the tool automatically
generates attack scenarios that expose weaknesses in the protocol. As it already supports a
variety of cryptographic primitives and protocol specifications, we were able to analyze
our protocol easily and quickly. For details about ProVerif, refer to article [22], and note
that the manual can be found in [22,23] and also online at [24].
We defined three processes for the execution processes of the server, the client, and the
AS along with eight events for sending, identifying, and verifying each node following the
secure scheme shown in Figure 3. The eight events are:
Events:
• event offer_service: This event denotes that a server sent an OfferService message
with its HMAC to a client. It is set after the OfferService message has been sent from a
server to a client.
the AS along with eight events for sending, identifying, and verifying each node following
the secure scheme shown in Figure 3. The eight events are:
Events:
• event offer_service: This event denotes that a server sent an OfferService message
Sensors 2023, 23, 6293 with its HMAC to a client. It is set after the OfferService message has been sent12 of 19
from
a server to a client.
• event request_ticket: This event denotes that a client sent a RequestTicket message
• with
eventtheir HMAC to the
request_ticket: AS.
This It is denotes
event set after that
the RequestTicket message has been
a client sent a RequestTicket sent
message
from
with atheir
client to an AS.
HMAC to the AS. It is set after the RequestTicket message has been sent
• event
from averify_node:
client to an AS. This event confirms the validity of a target node. It is set after
• validating a node’s HMAC
event verify_node: and policies.
This event confirms the validity of a target node. It is set after
• validating
event a node’s HMAC
return_ticket: This event anddenotes
policies.that an AS sent a ReturnTicket message that
• includes
event return_ticket: This event denotes
server and client tokens as well as that an AS sent
encrypted a ReturnTicket
session message
key containers that
via their
includes server and client tokens as well as encrypted session key containers via their
keys.
• keys. verify_ticket: This event confirms the validity of a node’s authentication ticket
event
• andevent verify_ticket:
obtains a session This
key.event
It is confirms
set after the validity
ticket sentof afrom
node’s
an authentication
AS is validatedticket
and
and obtains
decrypted anda session key.key
the session It isisset after the ticket sent from an AS is validated and
obtained.
• decrypted
event andThis
request: the session key is obtained.
event denotes that a client sent a Request message that includes
• FreshnessToken
event request: This event denotes
and AuthServerTicket that a client
to thesent a Request
server’s message
endpoint, that includes
configured in
FreshnessToken and AuthServerTicket to the server’s endpoint,
AuthClientTicket. It is set after a Request message is sent from a client to a server. configured in Auth-
• ClientTicket.
event It is set after a Request
server_verify_freshness: message
This event is sent the
confirms fromvalidity
a client of
to FreshnessToken
a server.
• from
eventaserver_verify_freshness:
client’s Request message.This It isevent confirms
set after the validityisof
FreshnessToken FreshnessToken
validated using a
from a client’s
session key. Request message. It is set after FreshnessToken is validated using a
• session key.
event response: This event denotes that a server sent a Response message to a client.
• Itevent
is setresponse: This event
after a Response denotes
message hasthat
been a server
sent fromsentaaserver
Response message to a client.
to a client.
It is set after a Response message has been sent from a server to a client.
We also set eight queries to confirm the security properties of the proposed security
We also
protocol. set 10
Figure eight
showsqueries to confirm
the result of thethe security
secrecy properties
analysis of keysof the
usedproposed security
for this scheme
protocol. Figure
for an attacker. 10 shows the result of the secrecy analysis of keys used for this scheme for
an attacker.
Figure10.
Figure Theresult
10.The resultof
ofsecurity
securityanalysis
analysisvia
viaProVerif.
ProVerif.
Queries:
Queries:
•• Query not
Query not attacker:secretA[]:
attacker:secretA[]:This Thisquery
queryinvestigates
investigateswhether
whetherorornot
not aa pre-defined
pre-defined
server key shared with an AS has been leaked by an attacker. In Figure 10, ititreturned
server key shared with an AS has been leaked by an attacker. In Figure 10, returned
true, which
true, which means
means the
the key
key is
is secure.
secure.
•• Query not attacker:secretB[]:
Query not attacker:secretB[]: This Thisquery
queryinvestigates
investigateswhether
whetheror ornot
not aa pre-defined
pre-defined
client key shared with an AS has been leaked by an attacker. In Figure 10, ititreturned
client key shared with an AS has been leaked by an attacker. In Figure 10, returned
true, which means the key is secure.
true, which means the key is secure.
•
•
Query not attacker:secretK_2[]: This query investigates whether or not a session key
Query not attacker:secretK_2[]: This query investigates whether or not a session key
distributed by an AS has been leaked or not. In Figure 10, it returned true, which
distributed by an AS has been leaked or not. In Figure 10, it returned true, which
means the key is secure from an attacker.
means the key is secure from an attacker.
• Query evinj:verify_node(x) ==> evinj:verify_node(y): This query investigates whether
• Query evinj:verify_node(x) ==> evinj:verify_node(y): This query investigates whether
or not client verification occurred before server verification occurred. It returned true,
or not client verification occurred before server verification occurred. It returned true,
which means a server node verification was always performed after a client node
which means a server node verification was always performed after a client node
verification. Combined with the following query, the return_ticket event should occur
after verifying both nodes.
• Query evinj:return_ticket(x,y) ==> evinj:verify_node(x): This query investigates whether
or not server verification occurred before the return_ticket event occurred. It returned
true, which means the return_ticket event was always sent after server node verification.
• Query evinj:request(x) ==> evinj:verify_ticket(y): This query investigates whether or
not a client ticket verification occurred before the request event occurred. It returned
true, which means the request event always happened after client ticket verification.
Sensors 2023, 23, 6293 13 of 19
• Query evinj: verify_ticket(y) ==> evinj:verify_freshness(x): This query investigates

whether or not a ticket freshness verification occurred before a server ticket verification.
It returned true, which means the verify_ticket event for the server always happened
after freshness verification.
• Query evinj: response(x) ==> evinj:verify_ticket(y): This query investigates whether
or not a server ticket verification occurred before a response event. It returned true,
which means the response event always happened after server ticket verification.
Following the listed queries, an attacker cannot modify an endpoint because the
endpoint is included in each authentication ticket from an AS, and the messages are sent
after verification of the tickets. By doing this, MITM and spoofing attacks are mitigated.
As part of a suggested process, a client may encrypt FreshnessToken with a shared key
via an AS, which ensures that the ticket’s freshness is verified before sending a response
from the server. This provides mitigation of replay and DDoS attacks. To sum up, the
result of ProVerif shows that our suggested security scheme has the secrecy of a session
key, can authenticate nodes, and mitigates various attacks. Please refer to Appendix A for
the detailed result of running ProVerif.
6. Evaluation
Verification was carried out through three Raspberry Pi 4 Model b+ units and one
gateway with Ubuntu loaded, as shown in Figure 11, for the configuration of the server,
client, and AS. We used GENEVI’s SOME/IP open source, vsomeip [25], for SOME/IP
security extension implementation and compared it to another solution that called secure-
vsomeip (implementation of Secure SOME/IP), which is available on GitHub. For a fair
comparison, we tested on the same devices, and in the case of a symmetric algorithm, both
solutions were set to operate with the AES-GCM-128 algorithm using OpenSSL. The testing
Sensors 2023, 23, x FOR PEER REVIEW
security level of secure-vsomeip was set to “authentication” to provide a security14level
of 20
similar to that of our proposed model.
Figure11.
Figure 11. Experimental
Experimental environment.
environment.
Forconvenience,
For convenience,we werefer
refertotoour
ourimplementation
implementation as as “ticket-based
“ticket-based vsomeip”.
vsomeip”. Figure
Figure 12
12 shows
shows the the
totaltotal
timetime
takentaken to send
to send a Request
a Request message
message to a specific
to a specific service
service and receive
and receive a Re-
a Response
sponse messagemessage afterclient
after one one app
client apptostarts
starts run. to
Therun. Therepresents
result result represents the value
the average average
of
value
100 of In
tests. 100the
tests.
caseInof the case of secure-vsomeip,
secure-vsomeip, we measuredwe themeasured
time to runthethe
time to run the re-
request_response
quest_response
client app in its client app inand
benchmark its benchmark
receive an and receive
actual an actual
response. response.
While While
the client nodethewas
cli-
ent node was running, it also performed an additional asymmetric key operation to hand-
shake with the server node. Ticket-based vsomeip performed symmetric key operations
and included additional communication overhead with the AS. The result shows that the
ticket-based vsomeip performed slightly faster than or similarly to secure-vsomeip. Please
note that these measurement data represent the total Round Trip Time (RTT) and include
For convenience, we refer to our implementation as “ticket-based vsomeip”. Figure
12 shows the total time taken to send a Request message to a specific service and receive
a Response message after one client app starts to run. The result represents the average
Sensors 2023, 23, 6293 value of 100 tests. In the case of secure-vsomeip, we measured the time to run the 14 ofre-
19
quest_response client app in its benchmark and receive an actual response. While the cli-
ent node was running, it also performed an additional asymmetric key operation to hand-
shake with the server node. Ticket-based vsomeip performed symmetric key operations
running, it also performed an additional asymmetric key operation to handshake with the
and included additional communication overhead with the AS. The result shows that the
server node. Ticket-based vsomeip performed symmetric key operations and included
ticket-based vsomeip performed slightly faster than or similarly to secure-vsomeip. Please
additional communication overhead with the AS. The result shows that the ticket-based
note that these measurement data represent the total Round Trip Time (RTT) and include
vsomeip performed slightly faster than or similarly to secure-vsomeip. Please note that
the time required for the operations on all nodes. CPU usage refers to how many resources
these measurement data represent the total Round Trip Time (RTT) and include the time
the processor consumes to perform a given task. Therefore, we proceeded to measure the
required for the operations on all nodes. CPU usage refers to how many resources the
CPU usage as well. When measuring the CPU on the server side, using secure-vsomeip,
processor consumes to perform a given task. Therefore, we proceeded to measure the CPU
we observed
usage as well.anWhen
average value of 25.546%.
measuring the CPU In
oncomparison, ticket-based
the server side, vsomeip showed
using secure-vsomeip, wea
usage of 6.67%,
observed indicating
an average valuea reduction of approximately
of 25.546%. In comparison,76%. This difference
ticket-based in CPU
vsomeip showedusagea
can be attributed to the way each method processes the task and the complexity
usage of 6.67%, indicating a reduction of approximately 76%. This difference in CPU usage of the
algorithms
can involved.
be attributed to the way each method processes the task and the complexity of the
algorithms involved.
Figure 12. Total elapsed time to obtain a response from a server, including each security extension
Sensors 2023, 23, x FOR PEER REVIEWFigure 12. Total elapsed time to obtain a response from a server, including each security extension
15 of 20
operation.
operation.
Since this proposed method performs most of the core operations for security expan-
Since
sion in thisitproposed
an AS, method performs
reduces overhead caused bymost of security
added the coreimplementations
operations for security
on the expan-
server
server
sion and
in an the
AS, client.
it Since overhead
reduces ticket requests
causedfrom
by multiple
added nodes can
security be demanded simul-
implementations on the
and the client. Since ticket requests from multiple nodes can be demanded simultaneously,
taneously, it is necessary to verify the processing capacity of the AS according to the in-
it is necessary to verify the processing capacity of the AS according to the increase in
crease in client ticket requests. Figure 13 illustrates the average measurements corre-
client ticket requests. Figure 13 illustrates the average measurements corresponding to the
sponding to the number of clients over 100 tests.
number of clients over 100 tests.
Figure 13. Evaluated elapsed time to handle all RequestTicket messages on an AS.
All clients
All clientsreceive
receiveananOfferService
OfferServicemessage
message thatthat
requires a ticket
requires provided
a ticket by theby
provided server
the
and want to use the service, then send RequestTicket messages to the AS.
server and want to use the service, then send RequestTicket messages to the AS. The meas-The measured
time time
ured is theistotal timetime
the total taken by by
taken thethe
ASASto to
transmit
transmitReturnTicket
ReturnTicketmessages
messagesto to all
all clients
clients
(see
(see Figure
Figure 13,
13, which
which shows
shows a a linear increase in
linear increase in the
the elapsed time in
elapsed time in relation
relation to
to increasing
increasing
numbers of
numbers of clients).
clients). Due
Due toto parallel
parallel processing,
processing, the
the actual
actual measured
measured results
results show
show aa speed
speed
increase that is less than the anticipated linear growth based on increased client
increase that is less than the anticipated linear growth based on increased client nodes. As nodes. As
such, using an AS is a feasible method.
such, using an AS is a feasible method.
7. Conclusions
7. Conclusions
As the automotive industry continues to evolve and the demand for data increases,
As the automotive industry continues to evolve and the demand for data increases,
Ethernet technology is poised to play an increasingly important role in vehicle communi-
Ethernet technology is poised to play an increasingly important role in vehicle communi-
cation. In this context, the security of SOME/IP, an Ethernet standard protocol, is crucial
for ensuring safety, privacy, and cybersecurity in modern vehicles. The proposed method
mitigates known MITM attacks on SOME/IP using a ticket that guarantees end node end-
points from an AS. Compared to methods proposed in other studies, our approach offers
Sensors 2023, 23, 6293 15 of 19
cation. In this context, the security of SOME/IP, an Ethernet standard protocol, is crucial
for ensuring safety, privacy, and cybersecurity in modern vehicles. The proposed method
mitigates known MITM attacks on SOME/IP using a ticket that guarantees end node end-
points from an AS. Compared to methods proposed in other studies, our approach offers an
advantage in terms of scalability, requiring only minimal additional work to accommodate
changes such as adding or deleting nodes. This is thanks to the fact that key changes and
policy changes due to node changes are possible only with an AS software update. Addi-
tionally, the proposed method can be implemented and used without significantly affecting
the existing SOME/IP protocol, making it compatible with current systems. Furthermore,
as it relies only on symmetric key operations, the operation of our method is relatively light.
Through the session key distributed by the AS and FreshnessToken protected by the key,
the server can self-verify the freshness of a ticket, effectively preventing replay attacks. We
proved the security properties of the proposed method through ProVerif and confirmed
feasibility in our evaluation. In future research, we plan to consider the use of a distributed
session key to ensure message confidentiality based on the importance of the service.
Author Contributions: Writing—review & editing, W.C.; Supervision, D.H.L.; Project administration,
S.L. All authors have read and agreed to the published version of the manuscript.
Funding: This work was supported by the Institute for Information and Communications Technology
Promotion (Development of Security Primitives for Unmanned Vehicles) under Grant 2020-0-00374.
Institutional Review Board Statement: Not applicable.
Informed Consent Statement: Not applicable.
Data Availability Statement: There is no additional data.
Conflicts of Interest: The authors declare no conflict of interest.
Appendix A
The result of running the ProVerif
Process 0 (that is, the initial process):
{1}new kA;
{2}new kB;
{3}let hostA = host(kA) in
{4}let hostB = host(kB) in
{5}out(c, hostA);
{6}out(c, hostB);
(
{7}!
{8}new SD;
{9}event offer_service(hostB);
{10}out(c, (hostA,hostB,SD,keyhash((hostA,hostB,SD),kA)));
{12}in(c, (=hostA,hostB1,Ea1,h31,ft));
{13}if (h31 = keyhash((hostA,hostB1,Ea1),kA)) then
{14}event verify_ticket(hostA);
{15}let (=hostA,=hostB,secretK) = decrypt(Ea1,kB) in
{16}let (=hostB,t2) = decrypt(ft,secretK) in
{17}event verify_freshness(hostB1);
{18}event response(hostB1)
)|(
{19}!
{20}new CD;
{21}in(c, (hostA1,=hostB,SD1,h1));
{22}out(c, (hostA1,hostB,SD1,h1,CD,keyhash((hostA1,hostB,SD1,h1,CD),kB)));
Sensors 2023, 23, 6293 16 of 19
{23}event request_ticket();
{24}in(c, (hostA2,=hostB,Ea,h3,Eb1,h4));
{25}if (h4 = keyhash((hostA2,hostB,Ea,h3,Eb1),getkey(hostB))) then
{26}let (=hostB,=hostA,secretK_1) = decrypt(Eb1,kB) in
{27}new t1;
{28}event verify_ticket(hostB);
{29}out(c, (hostA2,hostB,Ea,h3,encrypt((hostB,t1),secretK_1)));
{30}event request(hostA2)
)|(
{31}!
{32}in(c, (hostA2_1,hostB1_1,SD12,h12,CD12,h22));
{33}if (h22 = keyhash((hostA2_1,hostB1_1,SD12,h12,CD12),getkey(hostB))) then
{34}event verify_node(hostB);
{35}if (h12 = keyhash((hostA2_1,hostB1_1,SD12),getkey(hostA))) then
{36}event verify_node(hostA);
{37}new k;
{38}out(c, (hostA2_1,hostB1_1,encrypt((hostA2_1,hostB1_1,k),getkey(hostA)),key-
hash((encrypt((hostA2_1,hostB1_1,k),getkey(hostA))),getkey(hostA)),encrypt((hostB1_1,ho-
stA2_1,k),getkey(hostB)),keyhash((encrypt((hostA2_1,hostB1_1,k),getkey(hostA)),keyhash
((encrypt((hostA2_1,hostB1_1,k),getkey(hostA))),getkey(hostA)),encrypt((hostB1_1,hostA2
_1,k),getkey(hostB))),getkey(hostB))));
{39}event response_ticket(hostA2_1,hostB1_1)
)
-- Process 1 (that is, process 0, with let moved downwards):
{1}new kA;
{2}new kB;
{3}let hostA = host(kA) in
{5}out(c, hostA);
{4}let hostB = host(kB) in
{6}out(c, hostB);
(
{7}!
{8}new SD;
{10}out(c, (hostA,hostB,SD,keyhash((hostA,hostB,SD),kA)));
{12}in(c, (=hostA,hostB1,Ea1,h31,ft));
{13}if (h31 = keyhash((hostA,hostB1,Ea1),kA)) then
{14}event verify_ticket(hostA);
{15}let (=hostA,=hostB,secretK) = decrypt(Ea1,kB) in
{16}let (=hostB,t2) = decrypt(ft,secretK) in
{17}event verify_freshness(hostB1);
{18}event response(hostB1)
)|(
{19}!
{20}new CD;
{21}in(c, (hostA1,=hostB,SD1,h1));
{22}out(c, (hostA1,hostB,SD1,h1,CD,keyhash((hostA1,hostB,SD1,h1,CD),kB)));
{23}event request_ticket();
{24}in(c, (hostA2,=hostB,Ea,h3,Eb1,h4));
{25}if (h4 = keyhash((hostA2,hostB,Ea,h3,Eb1),getkey(hostB))) then
{26}let (=hostB,=hostA,secretK_1) = decrypt(Eb1,kB) in
{27}new t1;
{28}event verify_ticket(hostB);
Sensors 2023, 23, 6293 17 of 19
{29}out(c, (hostA2,hostB,Ea,h3,encrypt((hostB,t1),secretK_1)));
{30}event request(hostA2)
)|(
{31}!
{32}in(c, (hostA2_1,hostB1_1,SD12,h12,CD12,h22));
{33}if (h22 = keyhash((hostA2_1,hostB1_1,SD12,h12,CD12),getkey(hostB))) then
{34}event verify_node(hostB);
{35}if (h12 = keyhash((hostA2_1,hostB1_1,SD12),getkey(hostA))) then
{36}event verify_node(hostA);
{37}new k;
{38}out(c, (hostA2_1,hostB1_1,encrypt((hostA2_1,hostB1_1,k),getkey(hostA)),key-
hash((encrypt((hostA2_1,hostB1_1,k),getkey(hostA))),getkey(hostA)),encrypt((hostB1_1,ho-
stA2_1,k),getkey(hostB)),keyhash((encrypt((hostA2_1,hostB1_1,k),getkey(hostA)),keyhash
((encrypt((hostA2_1,hostB1_1,k),getkey(hostA))),getkey(hostA)),encrypt((hostB1_1,hostA2
_1,k),getkey(hostB))),getkey(hostB))));
{39}event response_ticket(hostA2_1,hostB1_1)
)
-- Query not attacker:secretA[]; not attacker:secretB[]; not attacker:secretK_2[] in pro-
cess 1.
Translating the process into Horn clauses...
Completing...
ok, secrecy assumption verified: fact unreachable attacker:kA[]
ok, secrecy assumption verified: fact unreachable attacker:kB[]
Starting query not attacker:secretA[]
RESULT not attacker:secretA[] is true.
Starting query not attacker:secretB[]
RESULT not attacker:secretB[] is true.
Starting query not attacker:secretK_2[]
RESULT not attacker:secretK_2[] is true.
-- Query evinj:verify_node(x) ==> evinj:verify_node(y) in process 1.
Completing...
Starting query evinj:verify_node(x) ==> evinj:verify_node(y)
goal reachable: begin:verify_node(host(kB[])),@occ34_1 -> end:@occ36_1,verify_node
(host(kA[]))
The hypothesis occurs strictly before the conclusion.
Abbreviations:
SD_1 = SD[!1 = @sid]
CD_1 = CD[!1 = @sid_1]
@occ36_1 = @occ36[h22 = keyhash((host(kA[]),host(kB[]),SD_1,keyhash((host(kA[]),
host(kB[]),SD_1),kA[]),CD_1),kB[]),CD12 = CD_1,h12 = keyhash((host(kA[]),host(kB[]),SD_1),
kA[]),SD12 = SD_1,hostB1_1 = host(kB[]),hostA2_1 = host(kA[]),!1 = @sid_2]
@occ34_1 = @occ34[h22 = keyhash((host(kA[]),host(kB[]),SD_1,keyhash((host(kA[]),
goal reachable: attacker:hostA2_2 & attacker:SD12_1 & attacker:h12_1 -> end:@occ34_1,
verify_node(host(kB[]))
The 1st, 2nd, 3rd hypotheses occur before the conclusion.
Abbreviations:
CD_1 = CD[!1 = @sid]
@occ34_1 = @occ34[h22 = keyhash((hostA2_2,host(kB[]),SD12_1,h12_1,CD_1),kB[]),CD12
= CD_1,h12 = h12_1,SD12 = SD12_1,hostB1_1 = host(kB[]),hostA2_1 = hostA2_2,!1 = @sid_1]
Sensors 2023, 23, 6293 18 of 19
RESULT evinj:verify_node(x) ==> evinj:verify_node(y) is true.

-- Query evinj:response_ticket(x,y) ==> evinj:verify_node(x) in process 1.
Completing...
Starting query evinj:response_ticket(x,y) ==> evinj:verify_node(x)
goal reachable: begin:verify_node(host(kA[])),@occ36_2 & begin:verify_node(host(kB[])),
@occ34_2 -> end:@occ39_1,response_ticket(host(kA[]),host(kB[]))
The 1st, 2nd hypotheses occur strictly before the conclusion.
Abbreviations:
SD_1 = SD[!1 = @sid]
CD_1 = CD[!1 = @sid_1]
@occ39_1 = @occ39[h22 = keyhash((host(kA[]),host(kB[]),SD_1,keyhash((host(kA[]),host
(kB[]),SD_1),kA[]),CD_1),kB[]),CD12 = CD_1,h12 = keyhash((host(kA[]),host(kB[]),SD_1),
@occ36_2 = @occ36_1[h22 = keyhash((host(kA[]),host(kB[]),SD_1,keyhash((host(kA[]),
@occ34_2 = @occ34_1[h22 = keyhash((host(kA[]),host(kB[]),SD_1,keyhash((host(kA[]),
RESULT evinj:response_ticket(x,y) ==> evinj:verify_node(x) is true.
-- Query evinj:request(x) ==> evinj:verify_ticket(x) in process 1.
Completing...
Starting query evinj:request(x) ==> evinj:verify_ticket(x)
RESULT evinj:request(x) ==> evinj:verify_ticket(x) is true.
-- Query evinj:response(x) ==> evinj:verify_freshness(x) in process 1.
Completing...
Starting query evinj:response(x) ==> evinj:verify_freshness(x)
RESULT evinj:response(x) ==> evinj:verify_freshness(x) is true.
References
1. AUTOSAR. Specification of Service Discovery—CP Released R22-11. 2022. Available online: https://www.autosar.org/fileadmin/
standards/classic/22-11/AUTOSAR_SWS_ServiceDiscovery.pdf (accessed on 9 January 2023).
2. AUTOSAR. Specification of SOME/IP Transformer—CP Released R22-11. 2022. Available online: https://www.autosar.org/
fileadmin/standards/classic/22-11/AUTOSAR_SWS_SOMEIPTransformer.pdf (accessed on 9 January 2023).
3. AUTOSAR. Specification of SOME/IP Transport Protocol (SOME/IP-TP)—CP Released R22-11. 2022. Available online: https://www.
autosar.org/fileadmin/standards/classic/22-11/AUTOSAR_SWS_SOMEIPTransportProtocol.pdf (accessed on 9 January 2023).
4. AUTOSAR. SOME/IP Protocol Specification—FO Released R22-11. 2022. Available online: https://www.autosar.org/fileadmin/
standards/foundation/22-11/AUTOSAR_PRS_SOMEIPProtocol.pdf (accessed on 9 January 2023).
5. AUTOSAR. SOME/IP Service Discovery Protocol Specification—FO Released R22-11. 2022. Available online: https://www.
autosar.org/fileadmin/standards/foundation/22-11/AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol.pdf (accessed on 9
January 2023).
6. AUTOSAR. Specification of Communication Management—AP Released R22-11. 2022. Available online: https://www.autosar.
org/fileadmin/standards/adaptive/22-11/AUTOSAR_SWS_CommunicationManagement.pdf (accessed on 9 January 2023).
7. Miller, C.; Valasek, C. Adventures in automotive networks and control units. In Proceedings of the DEFCON, Las Vegas, NV,
USA, 1–4 August 2013; Volume 21, pp. 260–264.
8. Miller, C.; Valasek, C. Remote Compromise of an Unaltered Passenger Vehicle; Black Hat: San Francisco, CA, USA, 2015; p. 91.
Sensors 2023, 23, 6293 19 of 19
9. Cai, Z.; Wang, A.; Zhang, W.; Gruffke, M.; Schweppe, H. 0-Days & Mitigations: Roadways to Exploit and Secure Connected BMW Cars;
Black Hat: San Francisco, CA, USA, 2019.
10. Nie, S.; Liu, L.; Du, Y. Free-Fall: Hacking Tesla from Wireless to CAN Bus. Briefing; Black Hat: San Francisco, CA, USA, 2017; pp. 1–16.
11. Seyler, J.; Navet, N.; Fejoz, L. Insights on the Configuration and Performances of SOME/IP Service Discovery. SAE Int. J. Passeng.
Cars Electron. Electr. Syst. 2015, 8, 124–129. [CrossRef]
12. Shir Moussenri. Hijacking SOME/IP Protocol with Man in the Middle Attack. 2020. Available online: https://argus-sec.com/
blog/cyber-security-blog/some-ip-protocol-man-in-the-middle-attack/ (accessed on 15 May 2022).
13. Zelle, D.; Lauser, T.; Kern, D.; Krauß, C. Analyzing and Securing SOME/IP Automotive Services with Formal and Practical
Methods. In Proceedings of the 16th International Conference on Availability, Reliability and Security (ARES 2021), Vienna,
Austria, 17–20 August 2021; ACM: New York, NY, USA, 2021. [CrossRef]
14. Iorio, M.; Buttiglieri, A.; Reineri, M.; Risso, F.; Sisto, R.; Valenza, F. Protecting In-Vehicle Services: Security-Enabled SOME/IP
Middleware. IEEE Veh. Technol. Mag. 2020, 15, 77–85. [CrossRef]
15. Iorio, M.; Reineri, M.; Risso, F.; Sisto, R.; Valenza, F. Securing SOME/IP for In-Vehicle Service Protection. IEEE Trans. Veh. Technol.
2020, 11, 13450–13466. [CrossRef]
16. Ma, B.; Yang, S.; Zuo, Z.; Zou, B.; Cao, Y.; Yan, X.; Zhou, S.; Li, J. An Authentication and Secure Communication Scheme for
In-Vehicle Networks Based on SOME/IP. Sensors 2022, 22, 647. [CrossRef] [PubMed]
17. Du, J.; Tang, R.; Feng, T. Security Analysis and Improvement of Vehicle Ethernet SOME/IP Protocol. Sensors 2022, 22, 6792.
[CrossRef] [PubMed]
18. Paar, C.; Pelzl, J. Message authentication codes (MACs). In Understanding Cryptography: A Textbook for Students and Practitioners;
Springer: Berlin/Heidelberg, Germany, 2010; pp. 319–330.
19. Hamad, M.; Nolte, M.; Prevelakis, V. A framework for policy based secure intra vehicle communication. In Proceedings of the
IEEE Vehicular Networking Conference (VNC), Torino, Italy, 27–29 November 2017; pp. 1–8.
20. Kâafar, M.A.; Benazzouz, L.; Kamoun, F.; Males, D. A Kerberos-Based Authentication Architecture for Wireless LANs. In
Networking 2004; Mitrou, N., Kontovasilis, K., Rouskas, G.N., Iliadis, I., Merakos, L., Eds.; Lecture Notes in Computer Science;
Springer: Berlin/Heidelberg, Germany, 2004; Volume 3042. [CrossRef]
21. Wardana, A.A.; Perdana, R.S. Access Control on Internet of Things based on Publish/Subscribe using Authentication Server
and Secure Protocol. In Proceedings of the 10th International Conference on Information Technology and Electrical Engineering
(ICITEE), Bali, Indonesia, 24–26 July 2018; pp. 118–123. [CrossRef]
22. Blanchet, B. Automatic Verification of Security Protocols in the Symbolic Model: The Verifier ProVerif. In Foundations of Security
Analysis and Design VII. FOSAD FOSAD 2013 2012; Aldini, A., Lopez, J., Martinelli, F., Eds.; Lecture Notes in Computer Science;
Springer: Cham, Switzerland, 2014; Volume 8604. [CrossRef]
23. Blanchet, B.; Smyth, B.; Cheval, V.; Sylvestre, M. ProVerif 2.04: Automatic Cryptographic Protocol Verifier, User Manual and
Tutorial. 2021. Available online: https://bblanche.gitlabpages.inria.fr/proverif/manual.pdf (accessed on 23 April 2023).
24. Blanchet, B. ProVerif: Cryptographic Protocol Verifier in the Formal Model. Available online: https://bblanche.gitlabpages.inria.
fr/proverif/ (accessed on 23 April 2023).
25. BMW AG. vSomeIP 3.3.0. 2023. Available online: https://github.com/COVESA/vsomeip (accessed on 15 May 2023).
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual
author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to
people or property resulting from any ideas, methods, instructions or products referred to in the content.

Protecting SOMEIP Communication Via Authentication

Uploaded by

Copyright:

Available Formats

You might also like

Protecting SOMEIP Communication Via Authentication

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Protecting SOMEIP Communication Via Authentication

Uploaded by

Copyright:

Available Formats

sensors

Abstract: Designed using vehicle requirements, Scalable service-Oriented MiddlewarE over IP

Keywords: SOME/IP; in-vehicle network; automotive Ethernet; security; authentication ticket

Sensors 2023, 23, 6293. https://doi.org/10.3390/s23146293 https://www.mdpi.com/journal/sensors

Figure 1. SOME/IP based on OSI 7 layer.

2.3. SOME/IP MITM Attack

Figure 2. A representative SOME/IP MITM attack.

Table 1. Comparison table showing various schemes.

Scheme Scalability Granularity Overhead Compatibility Efficiency

4.2. Attack Models

4.3. Overall Flow

5.2. Benefits and Concerns of Using an AS

5.3. Formal Verification

• Query evinj: verify_ticket(y) ==> evinj:verify_freshness(x): This query investigates

similar to that of our proposed model.

RESULT evinj:verify_node(x) ==> evinj:verify_node(y) is true.

You might also like