WO2024098429A1

WO2024098429A1 - Method for accessing service and related products

Info

Publication number: WO2024098429A1
Application number: PCT/CN2022/131561
Authority: WO
Inventors: Rehana YASMIN; Zhuo WEI; Yanjiang YANG; Tianfu Fu
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-11-11
Filing date: 2022-11-11
Publication date: 2024-05-16
Anticipated expiration: 2025-05-11
Also published as: CN120188450A; EP4612873A1

Abstract

A method and an apparatus for accessing a service and a vehicle are provided in embodiments of the present disclosure. A method for accessing a service includes: receiving a first service call message from a second Ethernet device, where the first service call message carries a first Ethernet service identifier and a first token, the first Ethernet service identifier is used to identify the first Ethernet service software component running on the first Ethernet device, and the first token is obtained based on the first Ethernet service identifier and a first secret key shared between the first Ethernet device and the second Ethernet device; performing verification on the first token based on the first service call message and the first secret key; acquiring, when the verification passes, a first application identifier corresponding to the first Ethernet service identifier based on a preset service correspondence, where the first application identifier is used to identify the application running on the first non-Ethernet device, and the preset service correspondence is used to indicate a correspondence between the first Ethernet service identifier and the first application identifier; and performing access to the application running on the first non-Ethernet device based on the first application identifier. Through the above solution, security and efficiency of service access can be ensured.

Description

METHOD FOR ACCESSING SERVICE AND RELATED PRODUCTS

TECHNICAL FIELD

The present disclosure relates to the technical field of security technologies, and in particular, to a method for accessing a service and related products.

BACKGROUND

In service access technologies, vehicle services are taken as an example, an illegitimate service access is not only a threat for information security but also can result in harmful operations, for example, braking on a busy road, unlock the door while the car is driving at high speed, etc., ultimately causing a threat to human lives.

In general, the vehicle service access depends on Service-Oriented Architecture (SOA) based communication. In SOA based communication, a service provided by a service provider (e.g. a server) is subscribed and consumed by a service consumer (e.g. a client) . A service ID uniquely identifies a service offered by a server. A client, subscribed to use a service, accesses that service using the service ID.

To ensure vehicle security, it is vital to prevent illegitimate access to vehicle services and allow the client to perform only legitimate access according to its access privileges. It thus raises the need of an access control mechanism for the vehicle services.

This background information is provided to reveal information believed by the applicant to be of possible relevance to the present disclosure. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present disclosure.

SUMMARY

Embodiments of the present disclosure provide a method for accessing a service and related products.

The foregoing and other objects are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

A first aspect of the present disclosure provides a method for accessing a service, where the service is implemented based on a first Ethernet service software component running on a first Ethernet device and an application running on a first non-Ethernet device, the method is applied in the first Ethernet device and includes:

receiving a first service call message from a second Ethernet device, where the first service call message carries a first Ethernet service identifier and a first token, the first Ethernet service identifier is used to identify the first Ethernet service software component running on the first Ethernet device, and the first token is obtained based on the first Ethernet service identifier and a first secret key shared between the first Ethernet device and the second Ethernet device;

performing verification on the first token based on the first service call message and the first secret key;

acquiring, when the verification passes, a first application identifier corresponding to the first Ethernet service identifier based on a preset service correspondence, where the first application identifier is used to identify the application running on the first non-Ethernet device, and the preset service correspondence is used to indicate a correspondence between the first Ethernet service identifier and the first application identifier; and

performing access to the application running on the first non-Ethernet device based on the first application identifier.

In the method for accessing the service provided by the present disclosure, since before acquiring the application identifier corresponding to the first Ethernet service identifier, the verification on the first token is performed first, where the first token is obtained based on the first Ethernet service identifier and the first secret key shared between the first Ethernet device and the second Ethernet device, therefore, the authorization of the second Ethernet device is verified directly by the receiving end of the first token (that is, the first Ethernet service) , and communication security between the first Ethernet device and the second Ethernet device is thus ensured; in addition, the first application identifier corresponding to the first Ethernet service identifier is acquired based on the preset service correspondence through the first Ethernet service, thus the access to the application running on the first non-Ethernet device can be performed based on the first application identifier, that is, the access process for a service is totally based on the original architecture of a vehicle, no more devices is required to perform the access to the application running on the first non-Ethernet device, thereby improving communication efficiency and ensuring real-time communication.

In a possible implementation, the performing verification on the first token based on the first service call message and the first secret key includes:

determining whether the second Ethernet device and/or a service software component running on the second Ethernet device is permitted to access the service based on the first service call message and a first pre-stored access permission list, where the first pre-stored access permission list is used to indicate a correspondence between an access permission of an Ethernet device and/or a service software component running on that Ethernet device and an Ethernet service identifier; and

upon determining that the second Ethernet device and/or the service software component running on the second Ethernet device is permitted to access the service, performing verification on the first token based on the first service call message and the first secret key.

In a possible implementation, the determining whether the second Ethernet device and the service software component running on the second Ethernet device is permitted to access the service based on the first service call message and a first pre-stored access permission list includes:

checking whether the first pre-stored access permission list includes an entry of the second Ethernet device based on an origination indicated by the first service call message;

when the first pre-stored access permission list includes the entry of the second Ethernet device, determining a to-be-checked access permission of the second Ethernet device based on an interface of the service software component running on the second Ethernet device called by the first service call message;

comparing an access permission in the entry of the second Ethernet device with the to-be-checked access permission; and

when the access permission in the entry of the second Ethernet device is as same as the to-be-checked access permission, determining that the second Ethernet device is permitted to access the service.

Through this determining manner, calculating amount for the first Ethernet device will be reduced at some extent.

calculating a first local token based on the first service call message and the first secret key;

comparing the first local token with the first token; and

determining that the verification passes when the first local token is as same as the first token.

In a possible implementation, the performing access to the application running on the first non-Ethernet device based on the first application identifier includes:

sending a service request message to the first non-Ethernet device, where the service request message carries the first application identifier and a second token obtained based on a second secret key, and the second secret key is shared between the first Ethernet device and the first non-Ethernet device.

In a possible implementation, the first non-Ethernet device is a controller area network CAN device, and the performing access to the application running on the first non-Ethernet device based on the first application identifier includes:

sending a service request message to the first non-Ethernet device, where the service request message is a CAN frame, and the CAN frame carries a CAN frame identifier corresponding to the first application identifier and a second token obtained based on a second secret key, and the second secret key is shared between the first Ethernet device and the first non-Ethernet device.

In a possible implementation, the method further includes:

sending a status request message to a second non-Ethernet device;

receiving a status response message from the second non-Ethernet device, where the status response message is used to indicate a status of a system on which the service runs; and

determining whether the service is permitted to be accessed based on the status of the system;

where the sending a service request message to the first non-Ethernet device includes:

upon determining that the service is permitted to be accessed, sending the service request message to the first non-Ethernet device.

Through the above implementation, the security can be ensured in combination with detecting the status of the system on which the service runs.

In a possible implementation, the sending a service request message to the first non-Ethernet device includes:

calculating the second token based on the first application identifier, the second secret key and a timestamp; and

sending the calculated second token to the first non-Ethernet device.

In a possible implementation, calculating the second token based on the first application identifier, the second secret key and a timestamp includes:

calculating the second token based on the first application identifier, the second secret key, the timestamp, and at least one of an access type of the service and a validity.

In a possible implementation, the first Ethernet service identifier is configured based on a service oriented architecture SOA application layer protocol.

In a possible implementation, the first application identifier is obtained based on an application identifier and a CAN frame identifier.

A second aspect of the present disclosure provides a method for accessing a service, where the service is implemented based on a first Ethernet service software component running on a first Ethernet device and an application running on a first non-Ethernet device, the method is applied in a second Ethernet device and includes:

obtaining a first token based on a first Ethernet service identifier and a first secret key, where the first Ethernet service identifier is used to identify the first Ethernet service software component running on the first Ethernet device, and the first secret key is shared between the first Ethernet device and the second Ethernet device; and

sending a first service call message to the first Ethernet device, where the first service call message carries the first Ethernet service identifier and the first token.

In a possible implementation, the service is further implemented based on a second Ethernet service software component running on a second Ethernet device;

the method further includes:

receiving a second service call message from an external device, where the second service call message carries a second Ethernet service identifier and a third token, the second Ethernet service identifier is used to identify the second Ethernet service software component running on the second Ethernet device, and the third token is obtained based on the second Ethernet service identifier and a third secret key shared between the second Ethernet device and the external device; and

performing verification on the third token based on the second service call message and the third secret key.

In this implementation, service access is triggered through the external device, thus, a user can flexibly select a remote triggering mode to the service access.

In a possible implementation, the performing verification on the third token based on the second service call message and the third secret key includes:

determining whether the external device is permitted to access the service based on the second service call message and a second pre-stored access permission list, where the second pre-stored access permission list is used to indicate a correspondence between an access permission of an Ethernet device and an Ethernet service identifier; and

upon determining that the external device is permitted to access the service, performing verification on the third token based on the second service call message and the third secret key.

In a possible implementation, the obtaining a first token based on a first Ethernet service identifier and a first secret key includes:

calculating a hash value by using the first Ethernet service identifier, the first secret key and a timestamp to obtain the first token.

A third aspect of the present disclosure provides an apparatus for accessing a service, the apparatus includes various modules configured to execute the method according to the first aspect or any possible implementation in the first aspect.

A fourth aspect of the present disclosure provides an apparatus for accessing a service, the apparatus includes various modules configured to execute the method according to the second aspect or any possible implementation in the second aspect.

A fifth aspect of the present disclosure provides a vehicle, including: a first Ethernet device, a second Ethernet device and a CAN device, where the first Ethernet device is configured to execute the method according to the first aspect or any possible implementation in the first aspect, the second Ethernet device is configured to execute the method according to the second aspect or any possible implementation in the second aspect, and the CAN device is configured to implement, based on an application running thereon, a service which is called by the second Ethernet device.

A sixth aspect of the present disclosure provides a system, including: a first Ethernet device, a second Ethernet device and a non-Ethernet device, where the first Ethernet device is configured to execute the method according to the first aspect or any possible implementation in the first aspect, the second Ethernet device is configured to execute the method according to the second aspect or any possible implementation in the second aspect, and the non-Ethernet device is configured to implement, based on an application running thereon, a service which is called by the second Ethernet device.

A seventh aspect of the present disclosure provides a computer readable storage medium, where the computer readable storage medium stores computer execution instructions, and when the computer execution instructions are executed by a processor, the method according to the first aspect or any possible implementation in the first aspect is implemented.

An eighth ninth aspect of the present disclosure provides a computer readable storage medium, where the computer readable storage medium stores computer execution instructions, and when the computer execution instructions are executed by a processor, the method according to the second aspect or any possible implementation in the second aspect is implemented.

A ninth tenth aspect of the present disclosure provide a computer program product including computer execution instructions, where when the computer execution instructions are executed by a processor, the method according to the first aspect or any possible implementation in the first aspect is implemented.

A tenth aspect of the present disclosure provide a computer program product including computer execution instructions, where when the computer execution instructions are executed by a processor, the method according to the second aspect or any possible implementation in the second aspect is implemented.

The present disclosure provides a method for accessing a service and related products. The second Ethernet service sends the first service call message which carries the first Ethernet service identifier and the first token to the first Ethernet device. The first Ethernet device performs verification on the first token based on the first service call message and the first secret key. When the verification passes, the first Ethernet device acquires the first application identifier corresponding to the first Ethernet service identifier, and performs access to the application running on the first non-Ethernet device based on the first application identifier. The verification on the first token is performed first, where the first token is obtained based on the first Ethernet service identifier and the first secret key shared between the first Ethernet device and the second Ethernet device, therefore, the authorization of the second Ethernet device is verified directly by the receiving end of the first token (that is, the first Ethernet service) , and communication security between the first Ethernet device and the second Ethernet device is thus ensured; in addition, the first application identifier corresponding to the first Ethernet service identifier is acquired based on the preset service correspondence through the first Ethernet service, thus the access to the application running on the first non-Ethernet device can be performed based on the first application identifier, that is, the access process for a service is totally based on the original architecture of a vehicle, no more devices is required to perform the access to the application running on the first non-Ethernet device, thereby improving communication efficiency and ensuring real-time communication.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings are used to provide a further understanding of the present disclosure, constitute a part of the specification, and are used to explain the present disclosure together with the following specific embodiments, but should not be construed as limiting the present disclosure.

FIG. 1 illustrates a block diagram of in-vehicle devices arranged in zonal architecture.

FIG. 2 illustrates message format of SOME/IP protocol which is one of the Ethernet application layer service-oriented communication protocol.

FIG. 3 illustrates a schematic diagram of OAuth protocol flow.

FIG. 4 illustrates a schematic diagram of categories of in-vehicle devices according to an embodiment of the present disclosure.

FIG. 5 illustrates a schematic flowchart of a method for accessing a service according to an embodiment of the present disclosure.

FIG. 6 illustrates a schematic diagram of Global SIDs.

FIG. 7 illustrates a service access control solution according to an embodiment of the present disclosure.

FIG. 8 illustrates a schematic flowchart of a method for accessing a service according to another embodiment of the present disclosure.

FIG. 9 illustrates a schematic diagram of a service access control solution according to another embodiment of the present disclosure.

FIG. 10 illustrates a schematic flowchart of interaction among different entities for implementing the method for accessing a service according to an embodiment of the present disclosure.

FIG. 11 illustrates a schematic flowchart of a method for accessing a service according to yet another embodiment of the present disclosure.

FIG. 12 illustrates a schematic flowchart of a method for accessing a service according to still another embodiment of the present disclosure.

FIG. 13 illustrates a schematic diagram of a service access control solution according to yet another embodiment of the present disclosure.

FIG. 14 illustrates a schematic flowchart of interaction among different entities for implementing the method for accessing a service according to another embodiment of the present disclosure.

FIG. 15 illustrates a block diagram of an apparatus for accessing a service according to an embodiment of the present disclosure.

FIG. 16 illustrates a block diagram of an apparatus for accessing a service according to another embodiment of the present disclosure.

FIG. 17 illustrates a schematic structural diagram of a system according to an embodiment of the present disclosure.

FIG. 18 illustrates a schematic structural diagram of an Ethernet device according to an embodiment of the present disclosure.

DESCRIPTION OF EMBODIMENTS

In the following description, reference is made to the accompanying figures, which form part of the application, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and include structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

In Service-Oriented Architecture (SOA) based communication, a service provided by a service provider (referred to as a server) is subscribed and consumed by a service consumer (referred to as a client) . A service ID uniquely identifies a service offered by the server. The client, subscribed to use a service, accesses that service using the service ID.

In a vehicle, SOA services are running on in-vehicle devices. The in-vehicle devices, known as ECUs (electronic control units) , are embedded systems in automotive electronics that control one or more of electrical systems or subsystems in a vehicle. There are a variety of ECUs inside the vehicle, arranged in E/E (Electrical/Electronic) architecture. In zonal E/E architecture, powerful vehicle devices such as an ADAS (Advanced Driving Assistance System) , a TCU (Telematics Control Unit) , an IVI (In-Vehicle Infotainment) , etc., and ZCs (Zone Controllers) are connected via Ethernet, forming a powerful backbone (shown as Type 1 devices in FIG. 1) . The zone controllers are in turn connected to other ECUs through CAN (Controller Area Network) or a CAN-FD (Controller Area Network-Flexible data) cable, known as CAN ECU devices (shown as Type 2 devices in FIG. 1) .

Automotive SOA services are typically implemented in an in-vehicle Ethernet network where both software components of the client and software components of the server are running on devices connected via Ethernet (Type 1 devices) . The automotive SOA services are usually realized via application layer service-oriented communication protocol (s) such as SOME/IP (Scalable Service-Oriented Middleware over IP) , DDS (Data Distribution Service) , etc. The SOME/IP protocol is a service-oriented communication solution mainly designed for automotive use case. This protocol is standardized by the AUTOSAR (Automotive Open System Architecture) . FIG. 2 shows the SOME/IP header which includes a service ID field apart from other fields.

Typically, a service/function inside a vehicle is not necessarily constrained to a single ECU. A functionality which is perceived as a single service by a driver (e.g., automatic cruise control) is in fact, realized by a large number of software components that are running on physically distributed ECUs across in-vehicle communication networks, for example, on Ethernet and CAN networks. Interfaces of SOA based services are although provided at Ethernet devices, they finally may be accomplished by non-SOA applications running on CAN ECUs, for example, services related to vehicle control.

Taking a vehicle door unlock service as an example, this service may be implemented differently by different OEMs (Original Equipment Manufacturer) . Usually, the CAN ECUs control vehicle door lock/unlock operations. A door unlock message is first received by, for example, an IVI system when a button is pressed on vehicle screen. IVI itself is not directly connected to a door unlock CAN ECU. SOA based door unlock service interface (or server software component) may actually be on a zone controller device directly connected to the door unlock CAN ECU. Hence, IVI will call that service on a zone controller using a service ID of application layer protocol (e.g., SOME/IP) . The zone controller in turn will send a door unlock command (for example, a CAN frame) to the door unlock CAN ECU to finally accomplish a service request, that is, to open the door.

It should be noted that, CAN communication is signal-oriented communication, and not a service-oriented communication. CAN ECU devices/applications are not aware of SOA based services. Hence, in automotive SOA, a service can be realized by service software components of the client and the server, or by a hierarchical structure of service software components (e.g., a service in turn calling other services to accomplish the service request) , or by a combination of service software components and CAN ECU applications (e.g., a service in turn involving other CAN ECU applications to accomplish the service request) .

A client’s access to a service may be either Read only or Write/Execute. Read access will permit the client to read some data at the corresponding server side, for example, reading DTC (Diagnostic Trouble Code) , a signal (e.g., speed) value, etc., provided by the server. Write/Execute access, on the other hand, allows a client to change/update data or run a procedure at the server side, for example, firmware update, execute a diagnostics function, run a command, etc. To ensure vehicle safety, it is vital to prevent illegitimate access to vehicle services and allow a client to perform only legitimate action (s) according to its access privileges. It thus raises the need of a service access control mechanism that determines the identity (i.e., service access authentication) and permission check (i.e., service access authorization) of a service access by the client based on the service ID.

For example, an attribute-based access control mechanism for SOA services running on automotive AUTOSAR adaptive systems defines access policy for each service and allows a client to access services based on the access policy. For another example, according to OAuth (Open Authorization) 2.0 Authorization Framework standard for online authorization of web services, authorization tokens are used to authorize a client to use a service/resource provided by a server. As shown in FIG. 3, the flow is as follows:

(A) A client requests authorization from a resource owner.

(B) The client receives an authorization grant, which is a credential representing the resource owner's authorization.

(C) The client requests an access token by authenticating itself to an authorization server and presenting the authorization grant.

(D) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.

(E) The client requests a protected resource from the resource server and authenticates itself by presenting the access token to the resource server.

(F) The resource server validates the access token, and if valid, serves the request.

AUTOSAR’s attribute-based access control solution can be used only on the AUTOSAR adaptive systems which does not cover legacy CAN ECU devices. Moreover, it only checks the permission rights based on the defined access policy stored on the system and, hence, doesn’t provide client authentication.

While in OAuth protocol, the resource owner gives authentication credentials to the client and the authorization server, on successful authentication, issues authorization tokens to a client to access a service. The presence of the authorization server and the resource server in vehicle architecture is not a practical assumption. Moreover, each token is sent to the authorization server for validation, which doesn’t suit the real-time in-vehicle communication. Thus, this approach will generate additional traffic for each token verification.

The present disclosure aims at solving the above problems. Since the service software components are implemented in the Ethernet network only, to identify a service globally across the networks, service software components running on Ethernet devices may be correlated with final answering applications running on destination CAN ECU devices. It’s challenging as service software components on powerful vehicle Ethernet devices (such as a TCU and an IVI) are not aware of destination CAN ECU applications and the destination CAN ECU applications are not aware of service IDs in the Ethernet devices. One possible solution may be to provide a global correspondence (e.g., a global vehicle wide service ID) between the service software components running on the Ethernet devices and the final answering applications running on destination CAN ECU devices (or referred to as CAN ECU applications) . In addition, the other problem to handle is to control service access for such service, i.e., the service called by a client running on an Ethernet device and is finally answered by an application running on a CAN ECU. It requires access control management among service software components and CAN ECU applications. This is also a challenging problem as the final answering (e.g., door unlock) CAN ECU is not able to authenticate a service call initiated by a client running on an Ethernet device (e.g., IVI) .

Keeping in mind the security requirements of the in-vehicle devices and challenges to design a security solution for these devices, the motivation behind the present disclosure is to design an in-vehicle service access control solution. The present disclosure aims to design a secure service access control solution according to capabilities of the in-vehicle devices while keeping the efficiency requirements in mind.

The present disclosure aims to design a token-based service access control solution according to the architecture and capabilities of the devices in a system, for example, in-vehicle devices, there may be devices of other types in different systems, which are not limited herein. Another motivation is to configure a global correspondence (e.g., a global service ID) for a functionality perceived as a single service by a user but achieved by multiple ECUs distributed in different networks. It should be noted that the following simply takes related concepts in vehicles for description, however, the solution of the present disclosure can also be applied in other systems in a similar way.

In the present disclosure, a global correspondence (e.g., a global service ID) is configured for a service accomplished by the service software components running on the Ethernet devices together with the applications running on a non-Ethernet device (such as a CAN ECU) and furthermore controls the access to these services based on the global service ID.For that, the in-vehicle devices are categorized into three categories based on their connectivity with other in-vehicle devices. Powerful devices (such as a TCU, an IVI, an ADAS, etc. ) connected to zone controllers via Ethernet make category 1 (e.g., Cat 1 in FIG. 4) devices. Zone controllers which are connected via Ethernet form category 2 (e.g., Cat 2 in FIG. 4) devices. CAN ECUs connected to zone controllers are category 3 (e.g., Cat 3 in FIG. 4) devices, as shown in FIG. 4.

A zone controller plays the role of transferring a service call from a Cat 1 device to Cat 3 devices. To control access to a service, authorization tokens are used where a first authorization token (referred to as a first token in the following embodiments) is used between Cat 1 and Cat 2 devices whereas a second authorization token (referred to as a second token in the following embodiments) is used between Cat 2 and Cat 3 devices. The zone controller also stores the access policy (also referred to as an access permissions list in the following embodiment) which defines the access permission for that service based on the global service ID.

It should be noted that the present disclosure assumes that each Cat 1 device has a secret key shared with the Cat 2 device (a zone controller) with which it’s connected. This secret key is shared between that zone controller and the Cat 1 device only. Moreover, the zone controller has a secret key shared with a Cat 3 device. This secret key is shared between that zone controller and the Cat 3 device only. The present disclosure does not limit a detailed solution for establishing these secret keys between Cat 1 and Cat 2 devices and between Cat 2 and Cat 3 devices for the zonal architecture shown in FIG. 4.

FIG. 4 also shows an example architecture of the in-vehicle communication network including multiple in-vehicle devices. The most powerful devices such as a TCU, an IVI, an ADAS, etc., are connected via Ethernet cable, and they form the Cat 1 devices. Then, there are the Cat 2 devices that are zone controllers which are powerful devices. They are connected to other zone controllers and the Cat 1 devices through Ethernet cables. The zone controllers have several ECU devices connected to them via CAN and CAN-FD buses, forming the Cat 3 devices. The main role of a zone controller is switching traffic from one end to another end.

In a possible implementation, a Cat 1 device may be connected to multiple Cat 2 devices, and the number of the Cat 2 devices may be two or more, which is not limited in the present disclosure. In this case, the Cat 1 device may send a corresponding service call message to a particular Cat 2 device according to configuration of the OEM. For example, an IVI may send different service call messages to corresponding ZCs. Specifically, the IVI may send a service call message to a ZC, send another service call message to another ZC, and send yet another service call message to yet another ZC. The service call messages may be sent simultaneously or in a preset sequence, which is not limited in the present disclosure.

It should be noted that, there may be different number of such devices with different names or they may be connected to each other in a different topology in different vehicles. FIG. 4 is just an example architecture.

The above describes possible application scenarios of the embodiments and motivation of the present disclosure, and then the embodiments of the present disclosure will be elaborated with reference to accompanying figures.

The present disclosure provides a method for accessing a service, where the service is implemented based on a first Ethernet service software component running on a first Ethernet device and an application running on a first non-Ethernet device, the method is applied in the first Ethernet device. The first non-Ethernet device may be a controller area network (CAN) device, a local interconnect network (LIN) device, and devices of other types. Reference may be made to FIG. 5, the method for accessing the service may include the following steps.

Step 501: receiving a first service call message from a second Ethernet device.

The first service call message carries a first Ethernet service identifier and a first token, the first Ethernet service identifier is used to identify the first Ethernet service software component running on the first Ethernet device, and the first token is obtained based on the first Ethernet service identifier and a first secret key shared between the first Ethernet device and the second Ethernet device. In a possible implementation, the first Ethernet service identifier is configured based on a service oriented architecture (SOA) application layer protocol, for example, SOME/IP, DDS, etc. In a possible implementation, the first Ethernet device may be a zone controller as shown in FIG. 4, and the second Ethernet device may be an in-vehicle infotainment (IVI) as shown in FIG. 4. The specific obtaining process of the first token will be described later. Correspondingly, the service may be, for example, the above mentioned SOA service implemented based on a service software component running on the IVI and an application running on a CAN ECU. The service may be in-vehicle services, and may also be services of other types in different systems, which are not limited herein.

Step 502: performing verification on the first token based on the first service call message and the first secret key.

The verification is used by the first Ethernet device to verify whether the second Ethernet device is authorized to access the service, and the verification can be performed based on the first secret key shared between the first Ethernet device and the second Ethernet device, thereby ensuring communication security between the first Ethernet device and the second Ethernet device. The specific verifying process of the first token will be described in the following.

An Ethernet device may refer to a hardware device, and a service software component is a software running on the hardware device. The first Ethernet device, for example, the ZC, pre-stores an access permission list (i.e. the access policy mentioned above) which may indicate the correspondence between an access permission of an Ethernet device and/or a service software component running on that Ethernet device and an Ethernet service identifier. The access permission may indicate whether the Ethernet device and/or the service software component running on the Ethernet device is permitted to access the first Ethernet device and/or a specific access type. The specific access type may be a type of Read/Write/Execute.

For example, still taking it as an example where the first Ethernet device is the ZC, first whether there is an IVI entry is checked, if there is an IVI entry, then whether there is an entry corresponding to a service software component running on IVI is determined. If there is no IVI entry, it is not necessary to continue a next permission determining step of an interface; and if there is an IVI entry, the next permission determining step of the interface is continued. Through this determining manner, calculating amount for the first Ethernet device will be reduced at some extent.

In another implementation, the verification may also be performed based on the second Ethernet device or the service software component running on the second Ethernet device. That is, taking it as an example where the first Ethernet device is the ZC, checking whether there is an IVI entry or an entry corresponding to a service software component running on the IVI directly. The preset disclosure does not limit the specific implementation.

comparing the first local token with the first token; and

The first local token is calculated by the first Ethernet device while the first token is calculated by the second Ethernet device. The verification on the first token is performed through determining whether tokens calculated by different entities (that is, the first Ethernet device and the second Ethernet device) are the same.

Step 503: acquiring, when the verification passes, a first application identifier corresponding to the first Ethernet service identifier based on a preset service correspondence.

The first application identifier is used to identify the application running on the first non-Ethernet device, and the preset service correspondence is used to indicate a correspondence between the first Ethernet service identifier and the first application identifier. The first Ethernet service pre-stores the correspondence between the first Ethernet service identifier and the first application identifier, for example, a first Ethernet service identifier SID10 corresponds to a first application identifier SID11. It should be noted that the first Ethernet device may pre-store different correspondences between different Ethernet service identifiers and application identifiers, and the specific correspondence between the first Ethernet service identifier and the first application identifier would be obtained with the first Ethernet service identifier.

In one implementation, the service correspondence may be embodied through translation/conversion of a Global Service ID (SID) . As shown in FIG. 6, a global SID is assigned to a service accomplished by service software components and applications running on CAN ECUs, including the following two ingredients.

SID10 (the first Ethernet service identifier mentioned above) : this part is to describe a service among service software components. For this part, SOA service components of a client and a server can use the service ID set by the SOA application layer protocol which they are running, for example, SOME/IP Service ID, DDS Service ID, etc. This part of the global service ID will identify the service between Cat 1 and Cat 2 devices.

SID11 (the first application identifier mentioned above) : this part is to describe a service/function provided by applications running on CAN ECUs. For this part, a service can be distinguished by using the application ID (APP ID) of an answering CAN ECU application together with the CAN frame ID. For example, (APP ID, CAN ID) . This part of the global service ID will identify the service between Cat 2 and Cat 3 devices.

Zone controllers store a global service ID table which may be signed by the OEM to avoid manipulation. A zone controller performs conversion/translation of a global service ID SID1 from SID10 to SID11 for a service call from a Cat 1 device which is finally accomplished by a CAN ECU application. Reference may be made to FIG. 6 or FIG. 7, the global service ID table may include a correspondence between an Ethernet service identifier and an application identifier for each global service ID. For example, an Ethernet service identifier SID 10 corresponds to an application identifier SID 11 for the global service ID SID 1, an Ethernet service identifier SID 20 corresponds to an application identifier SID 21 for a global service ID SID 2, and an Ethernet service identifier SID 30 corresponds to an application identifier SID 31 for a global service ID SID 3. Thus, in a case where a first Ethernet service identifier (e.g., SID30) is acquired, based on the preset service correspondence (e.g., the above global service ID table) , a first application identifier corresponding to the first Ethernet service identifier (e.g., SID 31) is determined.

Authorization tokens for service access control protect the complete path of the services expanded across networks. The Cat 1 devices (e.g., an IVI, an ADAS, a TCU, etc., ) have secret keys shared with the corresponding zone controllers with which they are directly connected. For example, as shown in FIG. 7, the IVI has a secret key SK10 established with the ZC1. Similarly, the ZC1 has a secret key SK11 established with the destination CAN ECU device. In addition, secret keys between the in-vehicle devices are different. The present disclosure does not limit the secret key establishment.

Step 504: performing access to the application running on the first non-Ethernet device based on the first application identifier.

When the first application identifier is determined, the application running on the first non-Ethernet device corresponding to the first application identifier can be determined, thus, the access to the application can be performed. In a possible implementation, the first application identifier is obtained based on an application identifier and a CAN frame identifier.

For example, the application running on the first non-Ethernet device corresponding to the first application identifier SID11 may be an application running on a CAN ECU which controls vehicle door lock/unlock operations.

There may be two implementations to perform access to the application running on the first non-Ethernet device based on the first application identifier, which will be described in the following.

The communication between the first Ethernet device and the first non-Ethernet device is implemented based on the second secret key, thereby ensuring communication security. The access to the application running on the first non-Ethernet device may be performed in a form of the service request message. Since the service request message carries the first application identifier, when the first non-Ethernet device receives the service request message, it will identify which application should be called based on the application identifier.

The communication between the first Ethernet device and the first non-Ethernet device is implemented based on the second secret key, thereby ensuring communication security. The access to the application running on the first non-Ethernet device may be performed in the form of a CAN frame. When the first non-Ethernet device receives the CAN frame sent by the first Ethernet device, it will identify which application should be called based on the CAN frame identifier according to a preset correspondence between a CAN frame identifier and a first application identifier.

In the method for accessing the service provided by the present disclosure, since before acquiring the application identifier corresponding to the first Ethernet service identifier, the verification on the first token is performed first, where the first token is obtained based on the first Ethernet service identifier and the first secret key shared between the first Ethernet device and the second Ethernet device, therefore, the authorization of the second Ethernet device is verified directly by the receiving end of the first token (that is, the first Ethernet service) , and communication security between the first Ethernet device and the second Ethernet device is thus ensured; in addition, when the verification passes, the first application identifier corresponding to the first Ethernet service identifier is acquired based on the preset service correspondence through the first Ethernet service, thus the access to the application running on the first non-Ethernet device can be performed based on the first application identifier, that is, the access process for a service is totally based on the original architecture of a vehicle, no more external devices is required to perform the access to the application running on the first non-Ethernet device, thereby improving communication efficiency and ensuring real-time communication.

In a possible implementation, as shown in FIG. 8, the method for accessing a service includes:

step 801: receiving a first service call message from a second Ethernet device;

step 802: performing verification on a first token based on the first service call message and a first secret key;

step 803: acquiring, when the verification passes, a first application identifier corresponding to a first Ethernet service identifier based on a preset service correspondence;

step 804: sending a status request message to a second non-Ethernet device;

step 805: receiving a status response message from the second non-Ethernet device, where the status response message is used to indicate a status of a system on which the service runs;

step 806: determining whether the service is permitted to be accessed based on the status of the system; and

step 807: upon determining that the service is permitted to be accessed, sending a service request message to a first non-Ethernet device.

sending the calculated second token to the first non-Ethernet device.

That is, the second token may be calculated based on the above three parameters. In addition to the above three parameters, the second token may also be calculated further based on an access type of the service and/or a validity, where the specific access type may be a type of Read/Write/Execute, and the validity specifies effectiveness of a secret key (which may be represented by a time duration) . Specifically, the calculating manner may be as follows: calculating a hash value by using the first application identifier, the second secret key and the timestamp to obtain the second token; or, calculating a hash value by using the first application identifier, the second secret key, the timestamp, as well as the access type of the service and/or the validity to obtain the second token. The hash value is obtained through the hash algorithm, since the hash algorithm is irreversible, the calculated second token is well-protected. Besides the calculating manner of the hash algorithm, there may be other calculating manners, which are not limited herein.

With regard to the implementations of steps 801 to 803 are similar to steps 501 to 503 respectively, which are not described herein.

The status request message is used to request status information of the system, for example, a speed value of a vehicle. In a situation when the service is finally accomplished by more than one calls to CAN ECU applications requiring to send more than one CAN messages to CAN ECU (s) . For example, before actually unlocking a vehicle door, it may be important to check the vehicle status like driving, parked, etc. In this case, the first non-Ethernet device may be a door unlock CAN ECU, and the second non-Ethernet device may be a CAN ECU configured to provide a vehicle status. Before sending an actual door unlock message to the door unlock CAN ECU, ZC1 may send additional messages to that CAN ECU to collect a vehicle status. Depending on the CAN ECU providing the vehicle status, ZC1 computes a token using a secret key shared with that CAN ECU and send it together with a status request message to that particular CAN ECU. If the detected vehicle status permits a door unlock operation, ZC1 sends a door unlock request message to the door unlock CAN ECU together with a token computed using a secret key shared with the door unlock CAN ECU. Thus, the vehicle security can be ensured in combination with detecting the status of the vehicle on which the vehicle service runs.

For example, the CAN ECU receives the status request message and performs a vehicle status detection, when it is detected that the vehicle is not in a parked status (e.g., the speed value is not 0) , ZC1 will not send the door unlock request message to the door unlock CAN ECU, thus, the door unlock operation will not be performed by the door unlock CAN ECU.

It should be noted that, for efficiency purposes, an authorization token may be included only with that part of the service which involve safety critical messages. For instance, in the above implementation, the authorization token may only be used with the door unlock request message which is used to request the door unlock CAN ECU to perform the door unlock operation, while an authorization token may not be used with the status request message which is used to request a CAN ECU to provide the vehicle status. In addition, a vehicle status detection is not necessary in some cases, for instance, when the first service call message is used to call a window close service, there is no need to perform the vehicle status detection.

In the following, an example is taken where the first Ethernet service is a ZC1, the second Ethernet service is an IVI, and a client running on the IVI may call a service running on the ZC1, e.g., the door unlock service. This embodiment will be elaborated with reference to FIG. 9 and FIG. 10, where FIG. 9 illustrates a schematic diagram of a service access control solution, and FIG. 10 illustrates a schematic flowchart of interaction among different entities for implementing the method for accessing a service. The steps of secure service access are as follows.

1. To call a service running on the ZC1, the client running on the IVI computes an authorization token T10 (referred to as the first token mentioned above) using a secret key SK10 ( (referred to as the first secret key mentioned above) shared with the ZC1 and a hash function H () as T10 = H ( (SID10, TS, Interval, Read) , SK10) . The token T10 includes Service ID (for example, SID10) , Timestamp (TS) , and Access type (Read, Write/Execute) . Validity/Expiry (Interval) may also be included in T10, where the validity/expiry specifies effectiveness of a secret key.

2. The IVI sends the token T10 to a server running on the ZC1 in a service call message (referred to as the first service call message mentioned above) . The first two steps may correspond to step 501 in the embodiment of FIG. 5 or step 801 in the embodiment of FIG. 8.

3. The ZC1 stores access policy (referred to as the first pre-stored access permission list mentioned above) which defines access permissions of a particular client for a service based on global service IDs. The ZC1 checks the access policy to verify access permissions of the client running on the IVI against that service. This step may correspond to step 502 in the embodiment of FIG. 5 or step 802 in the embodiment of FIG. 8.

4. If the client is permitted to access that service and the access type matches the permissions in the access policy, the ZC1 verifies the token T10 using the secret key shared with the IVI, that is, SK10, and the hash function. For verification, the ZC1 computes a token T10’ using secret key SK10 and the hash function on its side and matches T10’ with the received token as T10 = T10’.

5. On successful verification of the token T10, the ZC1 translates the SID10 to SID11 with the help of a global service ID table (referred to as the preset service correspondence mentioned above) . The ZC1 computes a new token T11 (referred to as the second token mentioned above) using a secret key SK11 (referred to as the second secret key mentioned above) shared with a destination CAN ECU (referred to as the first non-Ethernet device mentioned above) , and the hash function as T11 = H ( (SID11, TS, Interval, Read) , SK11) . The token T11 includes Service ID (for example, SID11) , Timestamp (TS) , and Access type (Read, Write/Execute) . Validity/Expiry (Interval) may also be included in T11, where the validity/expiry specifies effectiveness of a secret key. This step may correspond to step 503 in the embodiment of FIG. 5 or step 803 in the embodiment of FIG. 8.

6. The ZC1 sends a service request (CAN command) together with T11 to the CAN ECU. This step may correspond to step 807 in the embodiment of FIG. 8, where the service request may also be referred to as the service request message in step 807.

7. The CAN ECU verifies the token T11 using the secret key SK11 shared with the ZC1 and the hash function. For verification, the CAN ECU computes the token using secret key SK11 and the hash function on its side and matches it with the received token. On successful verification of the token, the CAN ECU processes the service request.

It should be noted that tokens for a service may be computed when a vehicle first starts and/or on the expiration of token validity or before each service call. For the services running completely on Ethernet devices without involvement of CAN ECU applications, the first token will be enough to ensure access control. For efficiency reasons, the solution may be used for selected use cases, for example, diagnostics use case, body control, etc.

The present disclosure further provides a method for accessing a service, where the service is implemented based on a first Ethernet service software component running on a first Ethernet device and an application running on a first non-Ethernet device, the method is applied in a second Ethernet device, and as shown in FIG. 11, the method includes:

step 1101: obtaining a first token based on a first Ethernet service identifier and a first secret key, where the first Ethernet service identifier is used to identify the first Ethernet service software component running on the first Ethernet device, and the first secret key is shared between the first Ethernet device and the second Ethernet device; and

step 1102: sending a first service call message to the first Ethernet device, where the first service call message carries the first Ethernet service identifier and the first token.

The implementation of step 1102 is similar to step 501, which is not described herein. The first Ethernet device may be a ZC, and the second Ethernet device may be a TCU. In a possible implementation, the obtaining a first token based on a first Ethernet service identifier and a first secret key includes: calculating a hash value by using the first Ethernet service identifier, the first secret key and a timestamp to obtain the first token. In addition to the above three parameters, the hash value may also be calculated further based on an access type of the service and/or a validity, the calculation process is similar to the calculation of the second token, which is not described again. The hash value is obtained through the hash algorithm, since the hash algorithm is irreversible, the calculated first token is well-protected.

In the method for accessing the service provided by the present disclosure, since before acquiring the application identifier corresponding to the first Ethernet service identifier, the verification on the first token is performed first, where the first token is obtained based on the first Ethernet service identifier and the first secret key shared between the first Ethernet device and the second Ethernet device, therefore, the authorization of the second Ethernet device is verified directly by the receiving end of the first token (that is, the first Ethernet service) , and communication security between the first Ethernet device and the second Ethernet device is thus ensured; in addition, when the verification passes, the first application identifier corresponding to the first Ethernet service identifier is acquired based on the preset service correspondence through the first Ethernet service, thus the access to the application running on the first non-Ethernet device can be performed based on the first application identifier, that is, the access process for a service is totally based on the original architecture of a vehicle, no more devices is required to perform the access to the application running on the first non-Ethernet device, thereby improving communication efficiency and ensuring real-time communication.

In the process for accessing a service corresponding to FIG. 9 and FIG. 10, service access may be triggered through corresponding operations on a screen of a system. Besides, the service access may be triggered by means of an external device, such as a mobile and cloud, in this case, when to accomplish a functionality, a SOA service calls another SOA service which in turn is accomplished by CAN ECU applications. A user can flexibly select a triggering mode to the service access since the above two implementations are used to access the same service, for example, the door unlock service of a vehicle. The final answering CAN ECU applications are the same, while the difference lies in that different Ethernet devices respond to the corresponding triggering actions. Specifically, when a user presses a function button on a vehicle screen or calls for a functionality by means of voice control, an IVI will respond to that triggering action; and when the triggering action is initiated by the user through the external device, a TCU will take actions to respond. The triggering mode by means of the external device will be described in the following.

In a possible implementation, the service is implemented based on a first Ethernet service software component running on a first Ethernet device and an application running on a first non-Ethernet device, and is further implemented based on a second Ethernet service software component running on a second Ethernet device, as shown in FIG. 12, the method for accessing a service includes:

step 1201: receiving a second service call message from an external device, where the second service call message carries a second Ethernet service identifier and a third token, the second Ethernet service identifier is used to identify the second Ethernet service software component running on the second Ethernet device, and the third token is obtained based on the second Ethernet service identifier and a third secret key shared between the second Ethernet device and the external device;

step 1202: performing verification on the third token based on the second service call message and the third secret key;

step 1203: obtaining, when the verification passes, a first token based on a first Ethernet service identifier and a first secret key, where the first Ethernet service identifier is used to identify the first Ethernet service software component running on the first Ethernet device, and the first secret key is shared between the first Ethernet device and the second Ethernet device; and

step 1204: sending a first service call message to the first Ethernet device, where the first service call message carries the first Ethernet service identifier and the first token.

The implementations of

steps

1203 and 1204 are similar to

steps

1101 and 1102 respectively, which are not described herein.

The second access permission list pre-stored in the second Ethernet device is similar to the first access permission list pre-stored in the first Ethernet device, the detailed implementation is not described herein.

In the above implementation, a mobile phone or cloud calls a SOA service running on a TCU, which in turns calls another SOA service running on a ZC1, which is finally accomplished by the CAN ECU, e.g., remote diagnostics on a CAN ECU, over-the-air software update on a CAN ECU. A mobile phone will have secret key shared with the TCU as SK20. The TCU has a secret key SK10 established with ZC1. Similarly, ZC1 has a secret key SK11 established with the destination CAN ECU device. The present disclosure does not limit the secret key establishment.

SOA services running between Ethernet devices will be calling to each other following the Ethernet application layer protocol, for example, using service IDs assigned by SOME/IP. This avoids making any changes in the working of application layer protocol. For the service part from a zone controller to a CAN ECU, a global service ID will be used.

The above implementation will be further elaborated with reference to FIG. 13 and FIG. 14, where FIG. 13 illustrates a schematic diagram of a service access control solution, and FIG. 14 illustrates a schematic flowchart of interaction among different entities for implementing the method for accessing a service. The steps of secure service access will be as follows.

1. To call a service running on the TCU, a client running on the Mobile computes an authorization token T20 (referred to as the third token mentioned above) using a secret key SK20 (referred to as the third secret key mentioned above) shared with the TCU and a hash function as T20 = H ( (SID20, TS, Interval, Read) , SK20) . The token T20 includes Service ID (SID20) of a service on the TCU, Timestamp (TS) and Access type (Read, Write/Execute) . In addition, Validity/Expiry (Interval) may also be included in T20, where the validity/expiry specifies effectiveness of a secret key.

2. The mobile sends the token T20 to a server running on the TCU to call the service (SID20) in a service call message (referred to as the second service call message in step 1201) . The first two steps may correspond to step 1201 in the embodiment of FIG. 12.

3. The TCU stores the access policy which defines access permissions of a client for a service based on the service ID SID20. The TCU checks the access policy to verify access permissions of the client running on the mobile against that service, where the access policy here may refer to the second pre-stored access permission list mentioned above.

4. If the client is permitted to access the service SID20 and the access type matches the permissions in the access policy, the TCU verifies the token T20 using the secret key shared with the mobile, that is, SK20, and the hash function. For verification, the TCU computes a token using secret key SK20 and the hash function on its side and matches it with the received token T20. Steps 3 and 4 may correspond to step 1201 in the embodiment of FIG. 12.

5. On successful verification, the TCU checks the access policy to make sure if the service SID20 is allowed to access the service SID10.

6. If it’s allowed, the TCU computes a new token T10 (referred to as the first token mentioned above) using the secret key (referred to as the first secret key mentioned above) shared with the ZC1. This step may correspond to step 1101 in the embodiment of FIG. 11 or step 1203 in the embodiment of FIG. 12.

7. The TCU sends the token T10 to the server running on the ZC1 to call a service (SID10) in a service call message (referred to as the first service call message mentioned above) . This step may correspond to step 1102 in the embodiment of FIG. 11 or step 1204 in the embodiment of FIG. 12, and may also correspond to step 501 in the embodiment of FIG. 5 or step 801 in the embodiment of FIG. 8.

8. The ZC1 stores the access policy (referred to as the first pre-stored access permission list mentioned above) which defines access permissions of a particular client for a service based on global service IDs. The ZC1 checks the access policy to verify access permissions of the client running on the TCU against that service. This step may correspond to step 502 in the embodiment of FIG. 5 or step 802 in the embodiment of FIG. 8.

9. If the client is permitted to access that service and the access type matches the permissions in the access policy, the ZC1 verifies the token T10 using a secret key shared with TCU, that is, SK10, and the hash function. For verification, the ZC1 computes the token T10’ using secret key SK10 and the hash function on its side and matches T10’ with the received token as T10 = T10’.

10. On successful verification of the token T10, the ZC1 translates the SID10 to SID11 with the help of a global service ID table (referred to as the preset service correspondence mentioned above) . The ZC1 computes a new token T11 (referred to as the second token mentioned above) using a secret key SK11 (referred to as the second secret key mentioned above) shared with the destination CAN ECU (referred to as the first non-Ethernet device mentioned above) , and the hash function as T11 = H ( (SID11, TS, Interval, Read) , SK11) . The token T11 includes Service ID (for example, SID11) , Timestamp (TS) , and Access type (Read, Write/Execute) . Validity/Expiry (Interval) may also be included in T11. This step may correspond to step 503 in the embodiment of FIG. 5 or step 803 in the embodiment of FIG. 8.

11. The ZC1 sends a service request (CAN command) together with T11 to the CAN ECU. This step may correspond to step 807 in the embodiment of FIG. 8, where the service request may also be referred to as the service request message in step 807.

12. The CAN ECU verifies the token T11 using the secret key SK11 shared with the ZC1 and the hash function. For verification, the CAN ECU computes the token using secret key SK11 and the hash function on its side and matches it with the received token. On successful verification of the token, the CAN ECU processes the service request.

Next, embodiments of products related to the method for accessing a service will be described.

FIG. 15 illustrates a block diagram of an apparatus 1500 for accessing a service according to an embodiment of the present disclosure. The service is implemented based on a first Ethernet service software component running on the apparatus 1500 and an application running on a first non-Ethernet device. As shown in FIG. 15, the apparatus 1500 includes:

a receiving module 1501, configured to receive a first service call message from a second Ethernet device, where the first service call message carries a first Ethernet service identifier and a first token, the first Ethernet service identifier is used to identify a first Ethernet service software component running on the apparatus 1500, and the first token is obtained based on the first Ethernet service identifier and a first secret key shared between the apparatus 1500 and the second Ethernet device;

a verifying module 1502, configured to perform verification on the first token based on the first service call message and the first secret key;

an acquiring module 1503, configured to acquire, when the verification passes a first application identifier corresponding to the first Ethernet service identifier based on a preset service correspondence, where the first application identifier is used to identify the application running on the first non-Ethernet device, and the preset service correspondence is used to indicate a correspondence between the first Ethernet service identifier and the first application identifier; and

an accessing module 1504, configured to perform access to the application running on the first non-Ethernet device based on the first application identifier.

In a possible implementation, the verifying module 1502 is further configured to:

determine whether the second Ethernet device and/or a service software component running on the second Ethernet device is permitted to access the service based on the first service call message and a first pre-stored access permission list, where the first pre-stored access permission list is used to indicate a correspondence between an access permission of an Ethernet device and/or a service software component running on that Ethernet device and an Ethernet service identifier; and

upon determining that the second Ethernet device and/or the service software component running on the second Ethernet device is permitted to access the service, perform verification on the first token based on the first service call message and the first secret key.

check whether the first pre-stored access permission list includes an entry of the second Ethernet device based on an origination indicated by the first service call message;

when the first pre-stored access permission list includes the entry of the second Ethernet device, determine a to-be-checked access permission of the second Ethernet device based on an interface of the service software component running on the second Ethernet device called by the first service call message;

compare an access permission in the entry of the second Ethernet device with the to-be-checked access permission; and

when the access permission in the entry of the second Ethernet device is as same as the to-be-checked access permission, determine that the second Ethernet device is permitted to access the service.

calculate a first local token based on the first service call message and the first secret key;

compare the first local token with the first token; and

determine that the verification passes when the first local token is as same as the first token.

In a possible implementation, the accessing module 1504 is further configured to:

send a service request message to the first non-Ethernet device, where the service request message carries the first application identifier and a second token obtained based on a second secret key, and the second secret key is shared between the apparatus 1500 and the first non-Ethernet device.

In a possible implementation, the first non-Ethernet device is a controller area network CAN device, and the accessing module 1504 is further configured to:

send a service request message to the first non-Ethernet device, where the service request message is a CAN frame, and the CAN frame carries a CAN frame identifier corresponding to the first application identifier and a second token obtained based on a second secret key, and the second secret key is shared between the apparatus 1500 and the first non-Ethernet device.

In a possible implementation, the apparatus further includes a status acquiring module, configured to:

send a status request message to a second non-Ethernet device;

receive a status response message from the second non-Ethernet device, where the status response message is used to indicate a status of a system on which the service runs; and

determine whether the service is permitted to be accessed based on the status of the system;

where the accessing module is further configured to:

upon determining that the service is permitted to be accessed, send the service request message to the first non-Ethernet device.

calculate the second token based on the first application identifier, the second secret key and a timestamp; and

send the calculated second token to the first non-Ethernet device.

calculate the second token based on the first application identifier, the second secret key, the timestamp, and at least one of an access type of the service and a validity.

FIG. 16 illustrates a block diagram of an apparatus 1600 for accessing a service according to another embodiment of the present disclosure. The service is implemented based on a first Ethernet service software component running on a first Ethernet device and an application running on a first non-Ethernet device. As shown in FIG. 16, the apparatus 1600 for accessing a service includes:

an obtaining module 1601, configured to obtain a first token based on a first Ethernet service identifier and a first secret key, where the first Ethernet service identifier is used to identify the first Ethernet service software component running on the first Ethernet device, and the first secret key is shared between the first Ethernet device and the apparatus 1600; and

a sending module 1602, configured to a first service call message to the first Ethernet device, where the first service call message carries the first Ethernet service identifier and the first token.

In a possible implementation, the apparatus further includes a responding module, configured to:

receive a second service call message from an external device, where the second service call message carries a second Ethernet service identifier and a third token, the second Ethernet service identifier is used to identify a second Ethernet service software component running on the apparatus 1600, and the third token is obtained based on the second Ethernet service identifier and a third secret key shared between the apparatus 1600 and the external device; and

perform verification on the third token based on the second service call message and the third secret key.

In a possible implementation, the responding module is further configured to:

determine whether the external device is permitted to access the service based on the second service call message and a second pre-stored access permission list, where the second pre-stored access permission list is used to indicate a correspondence between an access permission of an Ethernet device and an Ethernet service identifier; and

upon determining that the external device is permitted to access the service, perform verification on the third token based on the second service call message and the third secret key.

In a possible implementation, the obtaining module 1601 is further configured to:

calculate a hash value by using the first Ethernet service identifier, the first secret key and a timestamp to obtain the first token.

It should be understood by a person skilled in the art that, the relevant description of the above modules in the embodiments of the present application may be understood with reference to the relevant description of the method for accessing a service in the embodiments of the present application.

The present disclosure further provides a computer readable storage medium, where the computer readable storage medium stores computer execution instructions, and when the computer execution instructions are executed by a processor, the above mentioned method for accessing a service is implemented.

The present disclosure further provides a computer program product including computer execution instructions, where when the computer execution instructions are executed by a processor, the above mentioned method for accessing a service is implemented.

The present disclosure further provides a vehicle, including: a first Ethernet device a second Ethernet device and a CAN device, where the first Ethernet device and the second Ethernet device are configured to execute the method for accessing a service, and the CAN device is configured to implement, based on an application running thereon, a service which is called by the second Ethernet device. The first Ethernet device may be the above mentioned ZC, the second Ethernet device may be the above mentioned IVI. The CAN device may be the above mentioned first CAN device, and may also include the above mentioned first CAN device and second CAN device.

The present disclosure further provides a system, as shown in FIG. 17, the system includes: a first Ethernet device 1701, a second Ethernet device 1702 and a non-Ethernet device 1703, where the first Ethernet device 1701 and the second Ethernet device 1702 are configured to execute the method for accessing a service, and the non-Ethernet device 1703 is configured to implement, based on an application running thereon, a service which is called by the second Ethernet device 1702. The first Ethernet device 1701 may be the above mentioned ZC, the second Ethernet device 1702 may be the above mentioned IVI. The non-Ethernet device 1703 may be the CAN device, for example, the above mentioned first CAN device, and may also include the above mentioned first CAN device and second CAN device.

Both the first Ethernet service and the second Ethernet device belong to an Ethernet service, and as shown in FIG. 18, the Ethernet service 1800 may include may include a memory 1801 and a processor 1802, where a computer program is stored in the memory 1801, and configured to be executed by the processor 1802 to implement the corresponding steps described in the method embodiments. The relevant description of the steps may be understood with reference to the relevant description of the method for accessing a service in the embodiments of the present disclosure. In addition, the Ethernet device 1800 may further include a communication interface 1803 for communicating with other devices. The computer program (also known as programs, software, software applications, or codes) include machine instructions for a programmable processor, and may be implemented using high-level procedural and subtended programming languages, or assembly/machine languages.

The term “a” or “an” is not intended to specify one or a single element, instead, it may be used to represent a plurality of elements where appropriate.

In the embodiments of the present disclosure, expressions such as “exemplary” or “for example” are used to indicate illustration of an example or an instance. In the embodiments of the present disclosure, any embodiment or design scheme described as “exemplary” or “for example” should not be interpreted as preferred or advantageous over other embodiments or design schemes. In particular, the use of “exemplary” or “for example” is aimed at presenting related concepts in a specific manner.

In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this application. A computer program product may include a computer-readable medium.

Finally, it should be noted that the foregoing embodiments are merely intended for describing the technical solutions of the present invention other than limiting the present invention. Although the present invention is described in detail with reference to the foregoing embodiments, a person of ordinary skill in the art should understand that he may still make modifications to the technical solutions described in the foregoing embodiments, or make equivalent replacements to some technical features thereof, without departing from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

A method for accessing a service, wherein the service is implemented based on a first Ethernet service software component running on a first Ethernet device and an application running on a first non-Ethernet device, the method is applied in the first Ethernet device and comprises:

receiving a first service call message from a second Ethernet device, wherein the first service call message carries a first Ethernet service identifier and a first token, the first Ethernet service identifier is used to identify the first Ethernet service software component running on the first Ethernet device, and the first token is obtained based on the first Ethernet service identifier and a first secret key shared between the first Ethernet device and the second Ethernet device;

performing verification on the first token based on the first service call message and the first secret key;

acquiring, when the verification passes, a first application identifier corresponding to the first Ethernet service identifier based on a preset service correspondence, wherein the first application identifier is used to identify the application running on the first non-Ethernet device, and the preset service correspondence is used to indicate a correspondence between the first Ethernet service identifier and the first application identifier; and

performing access to the application running on the first non-Ethernet device based on the first application identifier.
The method according to claim 1, wherein the performing verification on the first token based on the first service call message and the first secret key comprises:

determining whether the second Ethernet device and/or a service software component running on the second Ethernet device is permitted to access the service based on the first service call message and a first pre-stored access permission list, wherein the first pre-stored access permission list is used to indicate a correspondence between an access permission of an Ethernet device and/or a service software component running on that Ethernet device and an Ethernet service identifier; and

upon determining that the second Ethernet device and/or the service software component running on the second Ethernet device is permitted to access the service, performing verification on the first token based on the first service call message and the first secret key.
The method according to claim 2, wherein the determining whether the second Ethernet device and the service software component running on the second Ethernet device is permitted to access the service based on the first service call message and a first pre-stored access permission list comprises:

checking whether the first pre-stored access permission list comprises an entry of the second Ethernet device based on an origination indicated by the first service call message;

when the first pre-stored access permission list comprises the entry of the second Ethernet device, determining a to-be-checked access permission of the second Ethernet device based on an interface of the service software component running on the second Ethernet device called by the first service call message;

comparing an access permission in the entry of the second Ethernet device with the to-be-checked access permission; and

when the access permission in the entry of the second Ethernet device is as same as the to-be-checked access permission, determining that the second Ethernet device is permitted to access the service.
The method according to any one of claims 1 to 3, wherein the performing verification on the first token based on the first service call message and the first secret key comprises:

calculating a first local token based on the first service call message and the first secret key;

comparing the first local token with the first token; and

determining that the verification passes when the first local token is as same as the first token.
The method according to any one of claims 1 to 4, wherein the performing access to the application running on the first non-Ethernet device based on the first application identifier comprises:

sending a service request message to the first non-Ethernet device, wherein the service request message carries the first application identifier and a second token obtained based on a second secret key, and the second secret key is shared between the first Ethernet device and the first non-Ethernet device.
The method according to any one of claims 1 to 4, wherein the first non-Ethernet device is a controller area network CAN device;

the performing access to the application running on the first non-Ethernet device based on the first application identifier comprises:

sending a service request message to the first non-Ethernet device, wherein the service request message is a CAN frame, and the CAN frame carries a CAN frame identifier corresponding to the first application identifier and a second token obtained based on a second secret key, and the second secret key is shared between the first Ethernet device and the first non-Ethernet device.
The method according to claim 5 or 6, further comprising:

sending a status request message to a second non-Ethernet device;

receiving a status response message from the second non-Ethernet device, wherein the status response message is used to indicate a status of a system on which the service runs; and

determining whether the service is permitted to be accessed based on the status of the system;

wherein the sending a service request message to the first non-Ethernet device comprises:

upon determining that the service is permitted to be accessed, sending the service request message to the first non-Ethernet device.
The method according to any one of claims 5 to 7, wherein the sending a service request message to the first non-Ethernet device comprises:

calculating the second token based on the first application identifier, the second secret key and a timestamp; and

sending the calculated second token to the first non-Ethernet device.
The method according to claim 8, wherein the calculating the second token based on the first application identifier, the second secret key and a timestamp comprises:

calculating the second token based on the first application identifier, the second secret key, the timestamp, and at least one of an access type of the service and a validity.
The method according to any one of claims 1 to 9, wherein the first Ethernet service identifier is configured based on a service oriented architecture SOA application layer protocol.
The method according to any one of claims 1 to 10, wherein the first application identifier is obtained based on an application identifier and a CAN frame identifier.
A method for accessing a service, wherein the service is implemented based on a first Ethernet service software component running on a first Ethernet device and an application running on a first non-Ethernet device, the method is applied in a second Ethernet device and comprises:

obtaining a first token based on a first Ethernet service identifier and a first secret key, wherein the first Ethernet service identifier is used to identify the first Ethernet service software component running on the first Ethernet device, and the first secret key is shared between the first Ethernet device and the second Ethernet device; and

sending a first service call message to the first Ethernet device, wherein the first service call message carries the first Ethernet service identifier and the first token.
The method according to claim 12, wherein the service is further implemented based on a second Ethernet service software component running on a second Ethernet device;

the method further comprises:

receiving a second service call message from an external device, wherein the second service call message carries a second Ethernet service identifier and a third token, the second Ethernet service identifier is used to identify the second Ethernet service software component running on the second Ethernet device, and the third token is obtained based on the second Ethernet service identifier and a third secret key shared between the second Ethernet device and the external device; and

performing verification on the third token based on the second service call message and the third secret key.
The method according to claim 13, wherein the performing verification on the third token based on the second service call message and the third secret key comprises:

determining whether the external device is permitted to access the service based on the second service call message and a second pre-stored access permission list, wherein the second pre-stored access permission list is used to indicate a correspondence between an access permission of an Ethernet device and an Ethernet service identifier; and

upon determining that the external device is permitted to access the service, performing verification on the third token based on the second service call message and the third secret key.
The method according to any one of claims 12 to 14, wherein the obtaining a first token based on a first Ethernet service identifier and a first secret key comprises:

calculating a hash value by using the first Ethernet service identifier, the first secret key and a timestamp to obtain the first token.
An apparatus for accessing a service, wherein the service is implemented based on a first Ethernet service software component running on the apparatus and an application running on a first non-Ethernet device;

wherein the apparatus comprises:

a receiving module, configured to receive a first service call message from a second Ethernet device, wherein the first service call message carries a first Ethernet service identifier and a first token, the first Ethernet service identifier is used to identify a first Ethernet service software component running on the apparatus, and the first token is obtained based on the first Ethernet service identifier and a first secret key shared between the apparatus and the second Ethernet device;

a verifying module, configured to perform verification on the first token based on the first service call message and the first secret key;

an acquiring module, configured to acquire, when the verification passes, a first application identifier corresponding to the first Ethernet service identifier based on a preset service correspondence, wherein the first application identifier is used to identify the application running on the first non-Ethernet device, and the preset service correspondence is used to indicate a correspondence between the first Ethernet service identifier and the first application identifier; and

an accessing module, configured to perform access to the application running on the first non-Ethernet device based on the first application identifier.
The apparatus according to claim 16, wherein the verifying module is further configured to:

determine whether the second Ethernet device and/or a service software component running on the second Ethernet device is permitted to access the service based on the first service call message and a first pre-stored access permission list, wherein the first pre-stored access permission list is used to indicate a correspondence between an access permission of an Ethernet device and/or a service software component running on that Ethernet device and an Ethernet service identifier; and

upon determining that the second Ethernet device and/or the service software component running on the second Ethernet device is permitted to access the service, perform verification on the first token based on the first service call message and the first secret key.
The apparatus according to claim 17, wherein the verifying module is further configured to:

check whether the first pre-stored access permission list comprises an entry of the second Ethernet device based on an origination indicated by the first service call message;

when the first pre-stored access permission list comprises the entry of the second Ethernet device, determine a to-be-checked access permission of the second Ethernet device based on an interface of the service software component running on the second Ethernet device called by the first service call message;

compare an access permission in the entry of the second Ethernet device with the to-be-checked access permission; and

when the access permission in the entry of the second Ethernet device is as same as the to-be-checked access permission, determine that the second Ethernet device is permitted to access the service.
The apparatus according to any one of claims 16 to 18, wherein the verifying module is further configured to:

calculate a first local token based on the first service call message and the first secret key;

compare the first local token with the first token; and

determine that the verification passes when the first local token is as same as the first token.
The apparatus according to any one of claims 16 to 19, wherein the accessing module is further configured to:

send a service request message to the first non-Ethernet device, wherein the service request message carries the first application identifier and a second token obtained based on a second secret key, and the second secret key is shared between the apparatus and the first non-Ethernet device.
The apparatus according to any one of claims 16 to 19, wherein the first non-Ethernet device is a controller area network CAN device;

the accessing module is further configured to:

send a service request message to the first non-Ethernet device, wherein the service request message is a CAN frame, and the CAN frame carries a CAN frame identifier corresponding to the first application identifier and a second token obtained based on a second secret key, and the second secret key is shared between the apparatus and the first non-Ethernet device.
The apparatus according to claim 20 or 21, wherein the apparatus further comprises a status acquiring module, configured to:

send a status request message to a second non-Ethernet device;

receive a status response message from the second non-Ethernet device, wherein the status response message is used to indicate a status of a system on which the service runs; and

determine whether the service is permitted to be accessed based on the status of the system;

wherein the accessing module is further configured to:

upon determining that the service is permitted to be accessed, send the service request message to the first non-Ethernet device.
The apparatus according to any one of claims 20 to 22, wherein the accessing module is further configured to:

calculate the second token based on the first application identifier, the second secret key and a timestamp; and

send the calculated second token to the first non-Ethernet device.
The apparatus according to claim 23, wherein the accessing module is further configured to:

calculate the second token based on the first application identifier, the second secret key, the timestamp, and at least one of an access type of the service and a validity.
The apparatus according to any one of claims 16 to 24, wherein the first Ethernet service identifier is configured based on a service oriented architecture SOA application layer protocol.
The apparatus according to any one of claims 16 to 25, wherein the first application identifier is obtained based on an application identifier and a CAN frame identifier.
An apparatus for accessing a service, wherein the service is implemented based on a first Ethernet service software component running on a first Ethernet device and an application running on a first non-Ethernet device;

wherein the apparatus comprises:

an obtaining module, configured to obtain a first token based on a first Ethernet service identifier and a first secret key, wherein the first Ethernet service identifier is used to identify the first Ethernet service software component running on the first Ethernet device, and the first secret key is shared between the first Ethernet device and the apparatus; and

a sending module, configured to a first service call message to the first Ethernet device, wherein the first service call message carries the first Ethernet service identifier and the first token.
The apparatus according to claim 27, wherein the apparatus further comprises a responding module, configured to:

receive a second service call message from an external device, wherein the second service call message carries a second Ethernet service identifier and a third token, the second Ethernet service identifier is used to identify a second Ethernet service software component running on the apparatus, and the third token is obtained based on the second Ethernet service identifier and a third secret key shared between the apparatus and the external device; and

perform verification on the third token based on the second service call message and the third secret key.
The apparatus according to claim 28, wherein the responding module is further configured to:

determine whether the external device is permitted to access the service based on the second service call message and a second pre-stored access permission list, wherein the second pre-stored access permission list is used to indicate a correspondence between an access permission of an Ethernet device and an Ethernet service identifier; and

upon determining that the external device is permitted to access the service, perform verification on the third token based on the second service call message and the third secret key.
The apparatus according to any one of claims 27 to 29, wherein the obtaining module is further configured to:

calculate a hash value by using the first Ethernet service identifier, the first secret key and a timestamp to obtain the first token.
A vehicle, comprising: a first Ethernet device, a second Ethernet device and a CAN device, wherein the first Ethernet device is configured to execute the method according to any one of claims 1 to 11, the second Ethernet device is configured to execute the method according to any one of claims 12 to 15, and the CAN device is configured to implement, based on an application running thereon, a service which is called by the second Ethernet device.
A system, comprising: a first Ethernet device, a second Ethernet device and a non-Ethernet device, wherein the first Ethernet device is configured to execute the method according to any one of claims 1 to 11, the second Ethernet device is configured to execute the method according to any one of claims 12 to 15, and the non-Ethernet device is configured to implement, based on an application running thereon, a service which is called by the second Ethernet device.
A computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions, and when the computer execution instructions are executed by a processor, the method according to any one of claims 1 to 11 or the method according to any one of claims 12 to 15 is implemented.
A computer program product comprising computer execution instructions, wherein when the computer execution instructions are executed by a processor, the method according to any one of claims 1 to 11 or the method according to any one of claims 12 to 15 is implemented.