WO2024098429A1 - Procédé d'accès à un service et produits associés - Google Patents

Procédé d'accès à un service et produits associés Download PDF

Info

Publication number
WO2024098429A1
WO2024098429A1 PCT/CN2022/131561 CN2022131561W WO2024098429A1 WO 2024098429 A1 WO2024098429 A1 WO 2024098429A1 CN 2022131561 W CN2022131561 W CN 2022131561W WO 2024098429 A1 WO2024098429 A1 WO 2024098429A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
ethernet
ethernet device
token
identifier
Prior art date
Application number
PCT/CN2022/131561
Other languages
English (en)
Inventor
Rehana YASMIN
Zhuo WEI
Yanjiang YANG
Tianfu Fu
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to PCT/CN2022/131561 priority Critical patent/WO2024098429A1/fr
Publication of WO2024098429A1 publication Critical patent/WO2024098429A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L27/00—Modulated-carrier systems

Definitions

  • the present disclosure relates to the technical field of security technologies, and in particular, to a method for accessing a service and related products.
  • 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.
  • the vehicle service access depends on Service-Oriented Architecture (SOA) based communication.
  • SOA Service-Oriented Architecture
  • a service provided by a service provider e.g. a server
  • 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.
  • Embodiments of the present disclosure provide a method for accessing a service and related products.
  • 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:
  • 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
  • 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
  • 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;
  • 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.
  • the performing verification on the first token based on the first service call message and the first secret key includes:
  • 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;
  • 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:
  • 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;
  • the performing verification on the first token based on the first service call message and the first secret key includes:
  • the performing access to the application running on the first non-Ethernet device based on the first application identifier includes:
  • 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 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 includes:
  • the service request message is a CAN frame
  • 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 further includes:
  • sending a service request message to the first non-Ethernet device includes:
  • the security can be ensured in combination with detecting the status of the system on which the service runs.
  • 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 includes:
  • the first Ethernet service identifier is configured based on a service oriented architecture SOA application layer protocol.
  • 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:
  • 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;
  • the service is further implemented based on a second Ethernet service software component running on a second Ethernet device;
  • the method further includes:
  • 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
  • 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
  • service access is triggered through the external device, thus, a user can flexibly select a remote triggering mode to the service access.
  • the performing verification on the third token based on the second service call message and the third secret key includes:
  • the obtaining a first token based on a first Ethernet service identifier and a first secret key includes:
  • 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.
  • 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.
  • SOA Service-Oriented Architecture
  • 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.
  • ECUs electronic control units
  • automotive electronics that control one or more of electrical systems or subsystems in a vehicle.
  • E/E Electronic/Electronic
  • 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.
  • 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) .
  • CAN Controller Area Network
  • CAN-FD Controller Area Network-Flexible data
  • 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.
  • 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.
  • 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
  • a functionality which is perceived as a single service by a driver 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.
  • a vehicle door unlock service As an example, this service may be implemented differently by different OEMs (Original Equipment Manufacturer) .
  • 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.
  • 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.
  • a door unlock command for example, a CAN frame
  • CAN communication is signal-oriented communication, and not a service-oriented communication.
  • CAN ECU devices/applications are not aware of SOA based services.
  • 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.
  • DTC Diagnostic Trouble Code
  • Write/Execute access 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.
  • 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.
  • 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 client requests authorization from a resource owner.
  • the client receives an authorization grant, which is a credential representing the resource owner's authorization.
  • the client requests an access token by authenticating itself to an authorization server and presenting the authorization grant.
  • the authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.
  • the client requests a protected resource from the resource server and authenticates itself by presenting the access token to the resource server.
  • the resource server validates the access token, and if valid, serves the request.
  • AUTOSAR 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.
  • 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) .
  • 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) .
  • a client running on an Ethernet device e.g., IVI
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the Cat 1 device may send a corresponding service call message to a particular Cat 2 device according to configuration of the OEM.
  • an IVI may send different service call messages to corresponding ZCs.
  • 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.
  • FIG. 4 is just an example architecture.
  • 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.
  • CAN controller area network
  • LIN local interconnect network
  • 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
  • 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.
  • the first Ethernet service identifier is configured based on a service oriented architecture (SOA) application layer protocol, for example, SOME/IP, DDS, etc.
  • SOA service oriented architecture
  • the first Ethernet device may be a zone controller as shown in FIG. 4
  • 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.
  • 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.
  • the performing verification on the first token based on the first service call message and the first secret key includes:
  • 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;
  • 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.
  • 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:
  • 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;
  • the first Ethernet device is the ZC
  • 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.
  • the performing verification on the first token based on the first service call message and the first secret key includes:
  • 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.
  • the service correspondence may be embodied through translation/conversion of a Global Service ID (SID) .
  • SID Global Service ID
  • 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.
  • 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.
  • a service can be distinguished by using the application ID (APP ID) of an answering CAN ECU application together with the CAN frame ID.
  • APP ID application ID
  • CAN ID CAN ID
  • 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.
  • the global service ID table may include a correspondence between an Ethernet service identifier and an application identifier for each global service ID.
  • 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
  • an Ethernet service identifier SID 30 corresponds to an application identifier SID 31 for a global service ID SID 3.
  • a first Ethernet service identifier e.g., SID30
  • the preset service correspondence e.g., the above global service ID table
  • the Cat 1 devices e.g., an IVI, an ADAS, a TCU, etc.,
  • the Cat 1 devices have secret keys shared with the corresponding zone controllers with which they are directly connected.
  • the IVI has a secret key SK10 established with the ZC1.
  • the ZC1 has a secret key SK11 established with the destination CAN ECU device.
  • 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.
  • 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.
  • the first application identifier is obtained based on an application identifier and a CAN frame identifier.
  • 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.
  • the performing access to the application running on the first non-Ethernet device based on the first application identifier includes:
  • 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 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 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 includes:
  • the service request message is a CAN frame
  • 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 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.
  • 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.
  • 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
  • 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.
  • step 807 upon determining that the service is permitted to be accessed, sending a service request message to a first non-Ethernet device.
  • the sending a service request message to the first non-Ethernet device includes:
  • the second token may be calculated based on 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) .
  • 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.
  • 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.
  • CAN ECU applications requiring to send more than one CAN messages to CAN ECU (s) .
  • the first non-Ethernet device may be a door unlock CAN ECU
  • the second non-Ethernet device may be a CAN ECU configured to provide a vehicle status.
  • ZC1 may send additional messages to that CAN ECU to collect a 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.
  • the vehicle security can be ensured in combination with detecting the status of the vehicle on which the vehicle service runs.
  • 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.
  • 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.
  • an authorization token may be included only with that part of the service which involve safety critical messages.
  • 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.
  • 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.
  • the first Ethernet service is a ZC1
  • the second Ethernet service is an IVI
  • a client running on the IVI may call a service running on the ZC1, e.g., the door unlock service.
  • FIG. 9 illustrates a schematic diagram of a service access control solution
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • the first token will be enough to ensure access control.
  • 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.
  • step 1102 is similar to step 501, which is not described herein.
  • the first Ethernet device may be a ZC
  • the second Ethernet device may be a TCU.
  • 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.
  • 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.
  • 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
  • service access may be triggered through corresponding operations on a screen of a system.
  • 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.
  • a TCU 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.
  • 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.
  • steps 1203 and 1204 are similar to steps 1101 and 1102 respectively, which are not described herein.
  • the performing verification on the third token based on the second service call message and the third secret key includes:
  • 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.
  • 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.
  • 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.
  • a global service ID For the service part from a zone controller to a CAN ECU, a global service ID will be used.
  • FIG. 13 illustrates a schematic diagram of a service access control solution
  • 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.
  • the token T20 includes Service ID (SID20) of a service on the TCU, Timestamp (TS) and Access type (Read, Write/Execute) .
  • Validity/Expiry may also be included in T20, where the validity/expiry specifies effectiveness of a secret key.
  • 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.
  • 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.
  • 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.
  • the TCU checks the access policy to make sure if the service SID20 is allowed to access the service SID10.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the verifying module 1502 is further configured to:
  • the second Ethernet device and/or a service software component running on the second Ethernet device determines 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;
  • the second Ethernet device and/or the service software component running on the second Ethernet device 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 verifying module 1502 is further configured to:
  • 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;
  • the verifying module 1502 is further configured to:
  • the accessing module 1504 is further configured to:
  • 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.
  • the first non-Ethernet device is a controller area network CAN device
  • the accessing module 1504 is further configured to:
  • the service request message is a CAN frame
  • 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.
  • the apparatus further includes a status acquiring module, configured to:
  • accessing module is further configured to:
  • the accessing module 1504 is further configured to:
  • the accessing module 1504 is further configured to:
  • the second token calculates 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 first Ethernet service identifier is configured based on a service oriented architecture SOA application layer protocol.
  • the first application identifier is obtained based on an application identifier and a CAN frame identifier.
  • 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.
  • 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;
  • 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.
  • the apparatus further includes a responding module, configured to:
  • 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
  • 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;
  • the responding module is further configured to:
  • 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
  • the obtaining module 1601 is further configured to:
  • 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.
  • 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.
  • 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
  • the computer program include machine instructions for a programmable processor, and may be implemented using high-level procedural and subtended programming languages, or assembly/machine languages.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)

Abstract

Des modes de réalisation de la présente divulgation concernent un procédé et un appareil pour accéder à un service et un véhicule. Un procédé d'accès à un service consiste à : recevoir un premier message d'appel de service provenant d'un second dispositif Ethernet, le premier message d'appel de service transportant un premier identifiant de service Ethernet et un premier jeton, le premier identifiant de service Ethernet étant utilisé pour identifier le premier composant logiciel de service Ethernet s'exécutant sur le premier dispositif Ethernet, et le premier jeton étant obtenu sur la base du premier identifiant de service Ethernet et d'une première clé secrète partagée entre le premier dispositif Ethernet et le second dispositif Ethernet ; effectuer une vérification sur le premier jeton sur la base du premier message d'appel de service et de la première clé secrète ; acquérir, lorsque la vérification réussit, un premier identifiant d'application correspondant au premier identifiant de service Ethernet sur la base d'une correspondance de service prédéfinie, le premier identifiant d'application étant utilisé pour identifier l'application s'exécutant sur le premier dispositif non Ethernet, et la correspondance de service prédéfinie étant utilisée pour indiquer une correspondance entre le premier identifiant de service Ethernet et le premier identifiant d'application ; et effectuer un accès à l'application s'exécutant sur le premier dispositif non Ethernet sur la base du premier identifiant d'application. Grâce à la solution ci-dessus, la sécurité et l'efficacité d'accès au service peuvent être assurées.
PCT/CN2022/131561 2022-11-11 2022-11-11 Procédé d'accès à un service et produits associés WO2024098429A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/131561 WO2024098429A1 (fr) 2022-11-11 2022-11-11 Procédé d'accès à un service et produits associés

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/131561 WO2024098429A1 (fr) 2022-11-11 2022-11-11 Procédé d'accès à un service et produits associés

Publications (1)

Publication Number Publication Date
WO2024098429A1 true WO2024098429A1 (fr) 2024-05-16

Family

ID=91031671

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/131561 WO2024098429A1 (fr) 2022-11-11 2022-11-11 Procédé d'accès à un service et produits associés

Country Status (1)

Country Link
WO (1) WO2024098429A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1954574A (zh) * 2003-12-08 2007-04-25 美国博通公司 以太网上的统一架构
CN101047446A (zh) * 2006-08-25 2007-10-03 华为技术有限公司 在无源光网络中配置以太网业务的装置、方法及管理实体
CN101552727A (zh) * 2009-05-12 2009-10-07 杭州华三通信技术有限公司 一种报文发送和接收方法及运营商边缘路由器
US20190097991A1 (en) * 2017-09-28 2019-03-28 Fortinet, Inc. Ethernet key
CN112087477A (zh) * 2019-06-14 2020-12-15 华为技术有限公司 建立非以太网业务的方法和网络设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1954574A (zh) * 2003-12-08 2007-04-25 美国博通公司 以太网上的统一架构
CN101047446A (zh) * 2006-08-25 2007-10-03 华为技术有限公司 在无源光网络中配置以太网业务的装置、方法及管理实体
CN101552727A (zh) * 2009-05-12 2009-10-07 杭州华三通信技术有限公司 一种报文发送和接收方法及运营商边缘路由器
US20190097991A1 (en) * 2017-09-28 2019-03-28 Fortinet, Inc. Ethernet key
CN112087477A (zh) * 2019-06-14 2020-12-15 华为技术有限公司 建立非以太网业务的方法和网络设备

Similar Documents

Publication Publication Date Title
KR102347659B1 (ko) 디바이스의 보안 프로비저닝 및 관리
US10104094B2 (en) On-vehicle communication system
JP2019009688A (ja) 保守システム及び保守方法
CN108512845B (zh) 接口调用的校验方法及装置
EP3982587A1 (fr) Procédé, dispositif et système d'authentification
WO2019056971A1 (fr) Procédé et dispositif d'authentification
CN112039878B (zh) 一种设备注册方法、装置、计算机设备及存储介质
CN112513844A (zh) 用于处理和认证数字密钥的安全元件及其操作方法
KR20220002455A (ko) Some/ip 통신 프로토콜을 사용하여 차량 내 데이터 또는 메시지들 전송 개선
US20160285843A1 (en) System and method for scoping a user identity assertion to collaborative devices
CN115442064A (zh) 一种车辆控制器诊断方法、装置、设备和介质
CN114372254A (zh) 认证方法、数据访问控制方法、服务器、设备和系统
US11783302B2 (en) Authorization of vehicle repairs
KR102075514B1 (ko) 차량용 네트워크 보안장치
WO2024098429A1 (fr) Procédé d'accès à un service et produits associés
US10298588B2 (en) Secure communication system and method
CN110138823B (zh) 一种远程车身控制方法及系统
CN113269931B (zh) 一种基于权能的共享汽车访问方法和装置
CN111404794B (zh) 一种基于虚拟化的can总线网络共享的系统及方法
CN114499981A (zh) 一种视频访问方法及装置
CN113806709A (zh) 车机服务的激活方法、车辆和可读存储介质
CN112738219B (zh) 程序运行方法、装置、车辆及存储介质
WO2021120678A1 (fr) Procédé, appareil et système de gestion de logiciel
WO2019174738A1 (fr) Procédé et système permettant d'établir une connexion entre un service de réseau de véhicule embarqué et une application externe
US20230129128A1 (en) Secure and documented key access by an application

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22964897

Country of ref document: EP

Kind code of ref document: A1