WO2022160124A1 - 一种服务授权管理方法及装置 - Google Patents

一种服务授权管理方法及装置 Download PDF

Info

Publication number
WO2022160124A1
WO2022160124A1 PCT/CN2021/073956 CN2021073956W WO2022160124A1 WO 2022160124 A1 WO2022160124 A1 WO 2022160124A1 CN 2021073956 W CN2021073956 W CN 2021073956W WO 2022160124 A1 WO2022160124 A1 WO 2022160124A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
vehicle
server
information
key
Prior art date
Application number
PCT/CN2021/073956
Other languages
English (en)
French (fr)
Inventor
王勇
陈幼雷
周铮
马涛
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2021/073956 priority Critical patent/WO2022160124A1/zh
Priority to CN202180000313.5A priority patent/CN112913209A/zh
Publication of WO2022160124A1 publication Critical patent/WO2022160124A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • the present application relates to the field of Internet of Vehicles and communication technologies, and in particular, to a service authorization management method and device.
  • the service provided by the service provider may be paid, or the service provided contains private data, etc.
  • the terminal wants to obtain the service from the resource server, it often needs to obtain the permission first, such as the permission to access the resource server, get service permissions, etc.
  • the embodiments of the present application disclose a service authorization management method and device, which improve the efficiency of service provision and the security of service use.
  • an embodiment of the present application discloses a service authorization management method, including:
  • the original equipment manufacturer OEM server receives a first message, where the first message includes identification information of a first terminal, and the first terminal is a terminal that needs to use the target service;
  • the OEM server determines first authority information according to the identification information of the first terminal, wherein the first authority information is used to indicate that the first terminal has the authority to use the target service;
  • the OEM server sends a second message to the first terminal, where the second message includes the first permission information.
  • the first terminal may be a vehicle, a robot, an unmanned aerial vehicle, or other intelligent device or a transportation tool.
  • the original equipment manufacturer (Original Equipment Manufacturer, OEM, or called the original manufacturer) server is the server corresponding to the manufacturer of the terminal.
  • the OEM server may store information corresponding to multiple terminals (including the first terminal).
  • the OEM server supports communication and connection with the terminals, and the OEM server is more credible to the terminals than other servers.
  • the OEM server when the OEM server acquires that the first terminal needs to use the target service, it can manage the service authorization process, complete functions such as authority determination, and issue authority information, and then the first terminal uses the authority issued by the OEM server.
  • the information access service improves the efficiency of service provision, improves the user experience of using the service, and improves the security of service use.
  • the first terminal obtains authorization by accessing the authorization server corresponding to the resource provider. If the authorization server is hijacked or the communication between the authorization server and the first terminal is hijacked, the first terminal may be subject to attack, thereby affecting the security of the first terminal. If the first terminal is the first vehicle, the attack on the first vehicle may threaten the personal safety of the driver or passenger.
  • the communication connection between the first vehicle and the OEM server is more reliable (for example, the OEM server can communicate with the first vehicle in advance in advance).
  • the authorization server needs to negotiate with the first vehicle to obtain the key), so using the OEM server for authorization management can reduce the interaction process in the process of establishing a communication connection, thereby improving the efficiency of service authorization.
  • the service provider to provide the server without additionally configuring the authorization server, which saves the service provider's cost of providing services.
  • the OEM server includes an over-the-air OTA task management module, and the method is applied to the OTA task management module.
  • the OEM server may further include an OTA authority management module, and the OTA authority management module is used to generate authority information.
  • the first message further includes indication information of the target service.
  • the first message may include indication information for the target service.
  • the indication information of the target service may indicate which service or services are required for authorization.
  • the OEM server correspondingly determines whether the first terminal has indication information for using the target service.
  • the first message may also contain multiple messages. For example, but not limited to, it includes a message A and a message B, wherein the message A includes the identification information of the first terminal, and the message B includes the target service indication information.
  • the first message may also not include the indication information of the target service.
  • the OEM server may generate rights information for all rights possessed by the first terminal, and the rights information may indicate that the first terminal possesses at least one kind of rights.
  • the second message further includes a first signature, where the first signature is used to verify the first permission information.
  • the method further includes:
  • the OEM server obtains the first signature according to the first permission information and a first key, where the first key is a first private key or is shared between the OEM server and the first terminal key.
  • the OEM server can sign the first permission information, carry the first signature in the second message and send it to the first terminal.
  • the first terminal may verify the first authority information according to the first signature. Since only the first public key of the OEM server or the shared key with the OEM can unlock the first signature, it is ensured that the first authority information obtained by the first terminal comes from the OEM server and has not been tampered with. security.
  • the target service is provided by a resource server, and the first permission information is used by the first terminal to request the target service from the resource server.
  • the method further includes:
  • the OEM server sends second permission information to the resource server, where the second permission information is used to indicate that the first terminal has the permission to use the target service.
  • the resource server also acquires corresponding permission information, which facilitates state synchronization between devices.
  • the resource server can also use the second authority information to verify the authority of the first terminal when receiving the request from the first terminal to use the target service, so as to facilitate the provision of services to the terminal with authority and improve the service provision process. safety.
  • the content of the permission information sent by the OEM server to the first terminal may be different from the content of the permission information sent by the OEM server to the resource server.
  • the permission information sent by the OEM server to the first terminal may be a token
  • the permission information sent by the OEM server to the first terminal may be a permission list.
  • the token and the permission list may be used to indicate the first terminal.
  • the terminal has permission to use the target service.
  • the method further includes:
  • the OEM server sends a second signature to the resource server, where the second signature is obtained by the OEM server according to the second permission information and a second key, and the second key is a second private key Or the shared key between the OEM server and the resource server.
  • the OEM server can sign the second authority information. After acquiring the second authority information and the second signature, the resource server may verify the second authority information according to the second signature. Since the second signature can only be unlocked through the second public key of the OEM server or the shared key with the OEM, it is ensured that the second authority information obtained by the resource server comes from the OEM server and has not been tampered with. security.
  • the target service is provided by the OEM server; after the OEM server determines the first permission information according to the identification information of the first terminal, the method further includes :
  • the OEM server provides the target service to the first terminal.
  • the OEM server not only completes the functions of determining permissions and issuing permissions, but also completes the function of providing services.
  • the user only needs to subscribe to the service from the OEM server, and the first terminal can receive the service provided by the OEM server without additionally requesting the service from the resource server, which reduces the interaction process and further improves the efficiency of service delivery.
  • the method further includes:
  • the OEM server checks the third authority information according to the first authority information.
  • the OEM server not only completes the functions of determining permissions and issuing permissions, but also completes the function of providing services.
  • the OEM may provide the target service to the first terminal after receiving the third message from the terminal and verifying the passing of the first authority information. Therefore, the first terminal can send a third message to the OEM server to request the OEM server to provide the target service when the target service is needed according to its own needs, which improves the user experience.
  • the method further includes:
  • the OEM server receives the permission status synchronized by the first terminal.
  • the first permission information indicates that the validity period for the first terminal to use the target service is 20 hours, and the first terminal synchronizes the validity period of the permission with the OEM server after starting to use the target service or using the target service.
  • the first terminal synchronizes the status of the authority to the OEM server, which facilitates the OEM to obtain changes in the status of the authority in time, maintains data consistency, and improves system stability.
  • an embodiment of the present application discloses a service authorization management method, including:
  • the first terminal receives a second message from the OEM server, where the second message includes first permission information, where the first permission information is used to indicate that the first terminal has the permission to use the target service;
  • the first terminal verifies the first permission information
  • the first terminal sends a fourth message to the resource server, where the fourth message includes the first permission information and the identification information of the first terminal;
  • the first terminal receives the target service provided by the resource server.
  • the first terminal includes an over-the-air OTA module, and the method is applied to the OTA module.
  • the OTA module (for example: OTA master module (OTAmaster), OTA group controller, etc.) is a module that supports communication with the OEM server based on the OTA technology.
  • the OEM server will also be configured with OTA related modules.
  • the first terminal communicates with the OEM server through the OTA module, which can reduce the process of establishing a connection through other communication technologies, and can improve communication security.
  • a first secure channel is established between the first terminal and the OEM server, the second message is transmitted through the first secure channel, and the The first secure channel includes at least one of a TLS secure channel, a DTLS secure channel, or an HTTPs secure channel.
  • a second secure channel is established between the first terminal and the resource server, the fourth message is transmitted through the second secure channel, and the The second secure channel includes at least one of a TLS secure channel, a DTLS secure channel, or an HTTPs secure channel.
  • the method before the first terminal receives the second message from the OEM server, the method further includes:
  • the first terminal sends a first message to the OEM server, where the first message includes identification information of the first terminal, and the identification information of the first terminal is used by the OEM server to determine the first authority information.
  • the second message further includes a first signature, where the first signature is used to verify the first permission information.
  • the first signature is obtained based on the first authority information and the first key; the first terminal verifies the first authority information, including :
  • the first terminal verifies the first authority information according to the first signature and a third key, where the third key is a decryption key of the first key.
  • the method further includes:
  • the first terminal synchronizes the permission status with the OEM server.
  • an embodiment of the present application discloses a service authorization management method, including:
  • the first terminal receives a second message from the OEM server, where the second message includes first permission information, where the first permission information is used to indicate that the first terminal has the permission to use the target service;
  • the first terminal receives the target service provided by the OEM server.
  • a first secure channel is established between the first terminal and the OEM server, and the second message and/or the third message passes through the A secure channel is used for transmission, and the first secure channel includes at least one of a TLS secure channel, a DTLS secure channel or an HTTPs secure channel.
  • the method before the first terminal receives the second message from the OEM server, the method further includes:
  • the first terminal sends a first message to the OEM server, where the first message includes identification information of the first terminal, and the identification information of the first terminal is used by the OEM server to determine the first authority information.
  • the second message further includes a first signature, where the first signature is used to verify the first permission information.
  • the first signature is obtained based on the first authority information and the first key; the first terminal verifies the first authority information, including :
  • the first terminal verifies the first authority information according to the first signature and a third key, where the third key is a decryption key of the first key.
  • the method further includes:
  • the first terminal synchronizes the permission status with the OEM server.
  • an embodiment of the present application discloses a service authorization management method, including:
  • the resource server receives a fourth message sent by the first terminal, where the fourth message includes identification information and first authority information of the first terminal, the first terminal is a terminal that needs to use the target service, and the first authority The information is used to indicate that the first terminal has the authority to use the target service, and the first authority information is determined by the OEM server;
  • the resource server verifies the first permission information
  • the target service is provided to the first terminal through the resource server.
  • the fourth message further includes indication information of the target service.
  • the above-mentioned indication information of the target service may also be included in the first permission information.
  • the method before the resource server verifies the first permission information, the method further includes:
  • the resource server receives second authority information from the OEM server, where the second authority information is used to indicate that the first terminal has the authority to use the target service.
  • the resource server checks the first permission information, including:
  • the resource server verifies the first permission information according to the second permission information.
  • the method before the resource server verifies the first permission information, the method further includes:
  • the resource server receives the second signature from the OEM server; the second signature is obtained by the OEM server according to the second authority information and the second key;
  • the resource server determines that the verification of the second authority information is passed according to the sixth key and the second signature, where the sixth key is a decryption key of the second key.
  • a second security channel is established between the first terminal and the resource server, and the first terminal and the resource server pass through the second security channel
  • the second secure channel includes at least one of a TLS secure channel, a DTLS secure channel or an HTTPs secure channel.
  • an embodiment of the present application discloses a service authorization management method, including:
  • the resource server receiving, by the resource server, a seventh message from the OEM server, where the seventh message includes first indication information, where the first indication information is used to indicate that the first terminal has the right to use the target service;
  • the resource server provides the target service to the first terminal.
  • the resource server determines the authority to the OEM server, which can reduce the interaction process of the first terminal, reduce the complexity of mutual communication control during the service authorization process, and improve the service. Authorized Efficiency.
  • the OEM server is a relatively secure server for the first terminal, which can also improve the security during the authorization service process.
  • the authorization management is performed through the OEM server, which can also save the cost of deploying the authorization server.
  • the resource server includes an OTA module, and the method is applied to the OTA module.
  • the OTA is a module that supports communication with the first terminal based on the OTA technology.
  • OTA-related modules are also configured in the vehicle, such as: OTA master module (OTAmaster), OTA group controller, etc.
  • the resource server can communicate with the first terminal through the OTA module, which can reduce the need for other communication. The process by which technology establishes a connection and can improve communication security.
  • the sixth message includes identification information of the first terminal and/or identification information of the target service.
  • the fifth message further includes identification information of the first terminal.
  • the above-mentioned indication information of the target service may also be included in the first permission information.
  • the seventh message further includes a third signature.
  • the third signature is obtained based on the first indication information and the fourth key; the method further includes:
  • the resource server verifies the first indication information by using the third signature and a fifth key, where the fifth key is a decryption key of the fourth key.
  • an embodiment of the present application discloses a service authorization management method, including:
  • the OEM server receives the sixth message sent by the resource server, where the sixth message is used to request permission information;
  • the OEM server sends a seventh message to the resource server, where the seventh message includes first indication information, and the first indication information is used for whether the first terminal has the right to use the target service.
  • the sixth message includes identification information of the first terminal and/or identification information of the target service.
  • the seventh message further includes a third signature, and the third signature is used to verify the first indication information.
  • the method further includes:
  • the OEM server obtains the third signature according to the first indication information and a fourth key, where the fourth key is a third private key or a shared secret between the OEM server and the resource server. key.
  • an embodiment of the present application discloses a service authorization management method, including:
  • the first terminal sends the fifth message to the resource server, and the fifth message includes the first authority information and the identification information of the first terminal;
  • the first terminal receives the target service provided by the resource server.
  • the fifth message further includes identification information of the first terminal.
  • the above-mentioned indication information of the target service may also be included in the first permission information.
  • an embodiment of the present application discloses a service authorization management apparatus, which includes a receiving unit, a processing unit, and a sending unit.
  • the service authorization management apparatus is configured to implement the method described in the first aspect or any possible implementation manner of the first aspect.
  • an embodiment of the present application discloses a service authorization management device, which includes a receiving unit, a processing unit, and a sending unit.
  • the service authorization management apparatus is configured to implement the method described in the second aspect or any possible implementation manner of the second aspect.
  • an embodiment of the present application discloses a service authorization management device, which includes a receiving unit, a processing unit, and a sending unit.
  • the service authorization management apparatus is configured to implement the method described in the third aspect or any possible implementation manner of the third aspect.
  • an embodiment of the present application discloses a service authorization management apparatus, which includes a receiving unit, a processing unit, and a sending unit.
  • the service authorization management apparatus is used to implement the method described in the fourth aspect or any possible implementation manner of the fourth aspect.
  • an embodiment of the present application discloses a service authorization management apparatus, which includes a receiving unit and a sending unit.
  • a processing unit may also be included.
  • the service authorization management apparatus is configured to implement the method described in the fifth aspect or any possible implementation manner of the fifth aspect.
  • an embodiment of the present application discloses a service authorization management apparatus, which includes a receiving unit and a sending unit.
  • a processing unit may also be included.
  • the service authorization management apparatus is configured to implement the method described in the sixth aspect or any possible implementation manner of the sixth aspect.
  • an embodiment of the present application discloses a service authorization management device, which includes a receiving unit and a sending unit.
  • a processing unit may also be included.
  • the service authorization management apparatus is used to implement the method described in any possible implementation manner of the seventh aspect or the eighth aspect.
  • the sending unit or the receiving unit in any one of the eighth aspect to the fourteenth aspect above may also be a transceiver, for sending and/or receiving the data in any one of the eighth aspect to the fourteenth aspect;
  • the processing unit may also be a processor for processing the data in any one of the eighth to fourteenth aspects above.
  • the present application provides a chip system, the chip system includes at least one processor for supporting the implementation of the functions involved in any one of the above-mentioned first to seventh aspects, for example, receiving Or process the data and/or information involved in the above-mentioned methods.
  • the chip system further includes a memory for storing program instructions and data, and the memory is located inside the processor or outside the processor.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • an embodiment of the present application further provides a service authorization management apparatus, where the service authorization management apparatus includes at least one processor and a communication interface, where the communication interface is used for sending and/or receiving data, the at least one The processor is configured to invoke a computer program stored in at least one memory, so that the service authorization management apparatus implements any one of the first to seventh aspects or any possible implementation of the first to seventh aspects method described.
  • an embodiment of the present application further provides a service authorization management system, where the service authorization management system includes an OEM server, a first terminal, and a resource server.
  • the OEM server is used to implement the method described in the first aspect or another possible implementation of the first aspect
  • the first terminal is used to implement the second aspect or a possible implementation of the second aspect.
  • the resource server is configured to implement the method described in the fourth aspect or any one of the possible implementation manners of the fourth aspect.
  • an embodiment of the present application further provides a service authorization management system, where the service authorization management system includes an OEM server, a first terminal, and a resource server.
  • the OEM server includes the service authorization management device described in the eighth aspect or any possible implementation manner of the eighth aspect
  • the first terminal includes the ninth aspect or any possible implementation of the ninth aspect.
  • the resource server includes the service authorization management apparatus described in the eleventh aspect or any possible implementation manner of the eleventh aspect.
  • the application further provides a service management system, the service management system includes an OEM server and a first terminal, wherein:
  • the OEM server is used to implement the method described in the first aspect or another possible implementation of the first aspect
  • the first terminal is used to implement the third aspect or the method described in another possible implementation of the third aspect. method described.
  • the present application further provides a service management system, the service management system comprising an OEM server and a first terminal, wherein:
  • the OEM server includes the service authorization management apparatus described in the eighth aspect or any possible implementation manner of the eighth aspect, and the first terminal includes the above tenth aspect or any possible implementation manner of the tenth aspect. Described service entitlement management device.
  • an embodiment of the present application provides a service management system, where the service authorization management system includes an OEM server, a first terminal, and a resource server.
  • the OEM server is used to implement the method described in the sixth aspect or any possible implementation manner of the sixth aspect
  • the resource server includes the fifth aspect or any possible implementation manner of the fifth aspect. the described method.
  • the first terminal is configured to implement the method described in the seventh aspect or any one of the possible implementation manners of the seventh aspect.
  • an embodiment of the present application provides a service management system, where the service authorization management system includes an OEM server, a first terminal, and a resource server.
  • an embodiment of the present application discloses a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program runs on one or more processors, the The methods described in the first aspect to the seventh aspect (or any possible implementation manner thereof) are implemented.
  • an embodiment of the present application discloses a computer program product, which, when the computer program product runs on one or more processors, implements the first to seventh aspects (or implements any one of them). possible implementations).
  • FIG. 1 is a schematic diagram of the architecture of a communication system shown in the present application.
  • FIG. 2 is a schematic diagram of the architecture of a service authorization management system provided by an embodiment of the present application.
  • FIG. 3 is a schematic diagram of the architecture of another service authorization management system provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of the architecture of still another service authorization management system provided by an embodiment of the present application.
  • FIG. 5 is a schematic flowchart of a service authorization management method provided by an embodiment of the present application.
  • FIG. 6 is a schematic flowchart of another service authorization management method provided by an embodiment of the present application.
  • FIG. 7 is a schematic flowchart of still another service authorization management method provided by an embodiment of the present application.
  • FIG. 8 is a schematic flowchart of still another service authorization management method provided by an embodiment of the present application.
  • FIG. 10 is a schematic flowchart of still another service authorization management method provided by an embodiment of the present application.
  • FIG. 11 is a schematic flowchart of still another service authorization management method provided by an embodiment of the present application.
  • FIG. 12 is a schematic structural diagram of a service authorization management apparatus provided by an embodiment of the present application.
  • FIG. 13 is a schematic structural diagram of another service authorization management apparatus provided by an embodiment of the present application.
  • FIG. 14 is a schematic structural diagram of still another service authorization management apparatus provided by an embodiment of the present application.
  • ordinal numbers such as “first” and “second” are used in the embodiments of the present application to distinguish multiple objects, and are not used to limit the order, sequence, priority or importance of multiple objects degree.
  • first message and the second message are only for distinguishing different message types, but do not indicate that the structures and importance levels of the two kinds of messages are different.
  • Over the Air is a technology for downloading data through a wireless network. It has been widely used in vehicles, smart homes (TVs, gateways, refrigerators, etc.), mobile terminals (mobile phones, tablet computers, etc.) , Set-top boxes and other equipment upgrades.
  • the OTA technology mainly performs automatic upgrade by downloading the OTA upgrade package (it also supports the upgrade by copying the OTA upgrade package to the SD card).
  • vehicle manufacturers OEM, or original equipment manufacturer
  • upgrade the relevant hardware or software of vehicles through OTA technology which helps manufacturers reduce recall costs, respond quickly to demand, and improve user experience.
  • the OTA module of the terminal may include an OTA master module (Master) and an OTA slave module (slave), the OTA master module can obtain information from the OEM server, and the OTA master module can also be connected with a or multiple OTA slave modules to communicate.
  • FIG. 1 is a schematic diagram of the architecture of a possible communication system exemplified in the present application, including an OEM cloud 101 (which may also be referred to as a server) and a vehicle 102 .
  • the vehicle 102 is a vehicle based on a vehicle electrical/Electronic Architecture (E/E) architecture, see area 103, the vehicle 102 may include at least one of the following components: Mobile Data Center (MDC, MDC) ), human-machine interaction (Human-Machine Interaction, HMI), gateway (gateway, GW), car box (Telematics BOX, Tbox or TCU), electronic control unit (Electronic Control Unit, ECU), etc.
  • the GW is the core component of the vehicle.
  • the GW can connect the Controller Area Network (CAN), Local Interconnect Network (LIN), multimedia data transmission (Media Oriented System Transport, MOST), FlexRay and other network data are routed in different networks.
  • MDC Controller Area Network
  • LIN Local Interconnect Network
  • MOST multimedia data transmission
  • FlexRay and other network data are routed in different networks.
  • MDC is the intelligent in-vehicle computing platform of the vehicle.
  • the T-BOX is mainly used to communicate with the outside of the vehicle, the background system and the mobile phone application (application, APP).
  • HMI is the information input, entertainment and interaction system of the vehicle.
  • the ECU is the controller within the vehicle.
  • an update master module (update master, which can be regarded as an OTA master) is deployed in the GW of the vehicle 102, and an update slave module (update slave, which can be regarded as an OTA) is deployed in multiple components of the vehicle 102 slave), the upgrade master module in the GW can communicate with the upgrade slave modules in other components, and can also communicate with the OEM server 101 .
  • the OTA main module may also be deployed in other components of the vehicle, or may be an independent module independent of other components, which is not limited in this embodiment of the present application.
  • the OEM server 101 Since the OEM server 101 is usually provided by the terminal's OEM, OEM and other manufacturers, the data transmission between the terminal and its OEM server is relatively safe.
  • Hash algorithm is also called hash function or hash algorithm.
  • a hash algorithm can output a piece of data (such as a string, a number, a file, etc.) as a hash value of a preset length (such as 80 bits, or 128 bits, etc.) (the hash value can also be called Hash value, digest value, etc.), and it is difficult to find the reverse rule.
  • Common hash algorithms include secure hash algorithm 1 (SHA-1), message digest (MD) algorithm (such as MD2, MD4 or MD5, etc.).
  • a public key and a private key are usually used, and the public key and the private key are a pair of keys that encrypt and decrypt each other.
  • the private key is stored privately, and the public key is open to the public.
  • use the public key to encrypt the plaintext to obtain the ciphertext and use the private key to decrypt the ciphertext to obtain the plaintext.
  • the workflow of signature and verification can be as follows (taking the two parties as node A and node B as an example): node A hashes the original text to obtain the first hash value; node A encrypts the first hash value with its own private key to obtain Signature value, send the original text and signature value to node B; node B decrypts the signature value with the public key to obtain the second hash value; node B hashes the original text to obtain the third hash value, and compares the second hash value with the third hash value
  • the hash value can verify whether the original text has been tampered with.
  • a digital certificate can be used to authenticate the public key.
  • a digital certificate also called a security certificate
  • CA Certificate Authority
  • Node B can determine that the public key is the public key of Node B through the digital certificate of the public key.
  • an authorization server can store permissions such as which client has which access rights to which resource server and under what conditions.
  • the terminal (specifically, the client in the terminal) using the service may include the following steps:
  • Step S1 the client (client) requests authorization from the resource owner (resource owner);
  • Step S2 The resource owner returns the authorization permission to the client
  • Step S3 the client sends an authorization request to the authorization server (authorization server);
  • Step S4 the authorization server returns an authorization response to the client; the authorization response may be an authorization verification success response or an authorization verification failure response, and the authorization verification success response carries the authorization verification certificate used to represent the verification result, if the authorization response is an authorization verification When the verification is successful, step S5 is also executed.
  • Step S5 the client sends a service request to the resource owner; the service request carries an authorization verification credential;
  • Step S6 The resource owner returns a resource access response to the client according to the authorization verification credential.
  • the client can use the target service based on the resource access response.
  • the authorization process may be managed by the OEM server.
  • FIG. 2 is a schematic diagram of the architecture of a service authorization management system provided by an embodiment of the present application, including an OEM server 201, a first terminal 202, and a resource server (server) 203, wherein:
  • the OEM server 201 is a device with data processing capability, which may be a physical device such as a host, a server, etc., or a virtual device such as a virtual machine, a container, and the like.
  • the OEM server 201 can transmit information with the terminal through the OTA technology.
  • the OEM server can be deployed with at least one of OTA interaction module, OTA rights management module, OTA task management module and other OTA related modules.
  • the OEM server can communicate with the terminal (for example, sending permission information, sending upgrade information).
  • the OEM server 201 is also referred to as an OEM cloud, an OTA cloud or an OTA server.
  • the OEM server 201 may receive a service request from the terminal for the target service, where the service request includes identification information of the first terminal 202, and optionally includes indication information of the target service.
  • the service request may be sent by the first terminal 202 to the OEM server 201 .
  • the vehicle sends a first message to the OEM server 201, which may be regarded as a service request.
  • the navigation software in the car or the component where the navigation software is located, such as HMI
  • the service request may also be sent by other terminals to the OEM server.
  • the car owner subscribes to the target service on the mobile phone, and the mobile phone sends the first message to the OEM server.
  • the OEM server 201 may generate authority information, and the generated authority information may be sent to the first terminal 202 .
  • the permission information may be one or more items of a token (Token), a license, an authorization letter, a permission list, etc., and is used to indicate that the first terminal 202 has the permission to use the target service.
  • the OEM server 201 may also send the permission information to the resource server 203 .
  • the content of the permission information sent 201 by the OEM server to the first terminal 202 may be different from the content of the permission information sent by the OEM server 201 to the resource server 203 .
  • the permission information sent by the OEM server 201 to the first terminal 202 may be a token
  • the permission information sent by the OEM server 201 to the first terminal 202 may be a permission list.
  • the above token and the above permission list can be used It indicates that the first terminal 202 has the right to use the target service.
  • the first terminal 202 is a component that needs to request the use of a target service, and the target service may be one or more of a map update service, a navigation system update service, a software download service, an automatic driving service, an assisted driving service, and the like.
  • the first terminal 202 may receive the permission information issued by the OEM server 201, and request the target service from the resource server 203 through the permission information.
  • the resource server 203 is a device with data processing capability, which may be a physical device such as a host, a server, etc., or a virtual device such as a virtual machine, a container, and the like. It should be noted that, for the convenience of description, it is referred to as a server, and in a specific implementation process, it may be a server, or other devices with data processing capabilities, or a module (eg, a chip or an integrated circuit) in the device.
  • the resource server 203 is a server that provides target services.
  • the resource server 203 is a server belonging to a service provider (service provider).
  • the resource server 203 may belong to a map cloud server of a map provider, and may provide map download, map update services, and the like.
  • the resource server 203 may receive a message from the first terminal 202 requesting to invoke the target service, where the message carries the permission information obtained by the first terminal 202 from the OEM server 201 . If the resource server 203 passes the verification of the authority information, it provides the target service to the first terminal 202 .
  • the OEM server when the first terminal needs to use the target service, the OEM server can manage the service authorization process, complete functions such as authority determination and issue authority information, and then the first terminal uses the OEM server to download
  • the permission information sent can obtain services from the resource service, improve the efficiency of service provision, improve the user experience of using the service, and improve the security of service use.
  • the first terminal obtains authorization by accessing the authorization server corresponding to the resource provider. If the authorization server is hijacked or the communication between the authorization server and the first terminal is hijacked, the first terminal may be subject to attack, thereby affecting the security of the first terminal. If the first terminal is the first vehicle, the attack on the first vehicle may threaten the personal safety of the driver or passenger.
  • the authorization management system shown in FIG. 2 since the OEM server is a more trusted device for the first terminal, the communication connection between the first terminal and the OEM server is more reliable (for example, in the OEM server A key can be configured with the first terminal in advance, but the authorization server needs to negotiate with the first terminal to obtain the key), so using the OEM server for authority management can reduce the interaction process in the process of establishing a communication connection, thereby improving the service The efficiency of authorization further improves the efficiency of the first terminal in obtaining services.
  • the service provider to provide the server without additionally configuring the authorization server, which saves the service provider's cost of providing services.
  • FIG. 3 is a schematic diagram of the architecture of another service authorization management system provided by an embodiment of the present application, including an OEM server 301, a first terminal 302, and a resource server (server) 303, wherein:
  • the OEM server 301 For the introduction of the OEM server 301 , reference may be made to the aforementioned OEM server 201 .
  • the authority possessed by the terminal can be acquired.
  • the OEM server 301 may receive a service request from the terminal for the target service, where the service request includes identification information of the first terminal 302, and optionally, the service request further includes indication information of the target service.
  • the service request may be sent by the first terminal 302 to the OEM server 301, or may be sent by other terminals to the OEM server.
  • the OEM server 301 may generate permission information corresponding to the first terminal 302 based on the service request.
  • the first terminal 302 is a component that needs to use the target service.
  • the first terminal may request the resource server 303 to use the target service.
  • the resource server 303 may receive a message from a terminal (such as the first terminal 302) requesting to use the target service, the resource server requests permission information from the OEM server 301, and determines whether the terminal has permission to use the target service according to the first indication information returned by the OEM server 301. If the terminal has the right to use the target service, the target service is provided to the terminal.
  • a terminal such as the first terminal 302
  • the resource server requests permission information from the OEM server 301, and determines whether the terminal has permission to use the target service according to the first indication information returned by the OEM server 301. If the terminal has the right to use the target service, the target service is provided to the terminal.
  • the OEM server when the first terminal needs to use the target service, the OEM server completes the work of determining the authority and returning the authority information. Since the OEM server can obtain the permission information, when the first terminal requests the resource server to call the target service, the resource server determines the permission from the OEM server, which can reduce the interaction process of the first terminal and reduce the communication control during the service authorization process. complexity, thereby improving the efficiency of service authorization. Further, the OEM server is a relatively secure server for the first terminal, which can also improve the security during the authorization service process. In addition, the authorization management is performed through the OEM server, which can also save the cost of deploying the authorization server.
  • FIG. 4 is a schematic structural diagram of still another service authorization management system provided by an embodiment of the present application, including an OEM server 401 and a first terminal 402, wherein:
  • the OEM server 401 can transmit information with the first terminal 402 through the OTA technology.
  • the OEM server can be deployed with at least one of an OTA interaction module, an OTA authority management module, and an OTA task management module. Through the OTA-related modules, the OEM server 401 can communicate with.
  • the OEM server 401 can acquire the authority possessed by the terminal. Further optionally, the OEM server 401 may generate permission information corresponding to the first terminal 402 . Optionally, the generated permission information may be delivered to the first terminal 402 .
  • the OEM server 401 may also provide various services, for example, the OEM server 401 may provide one or more of a map update service, a navigation system update service, a software download service, an automatic driving service, an assisted driving service, and the like.
  • the service provided by the OEM server 401 may be deployed on the OEM server 401 by a service provider (Service Provider).
  • Service Provider the OEM server 401 can also be used as an agent, and the services deployed by the service provider on other servers can be obtained through the OEM server 401 .
  • the first terminal 402 is a terminal that needs to request to use the target service.
  • the OEM server 401 receives a service request for the target service, and the service request includes the identification information of the first terminal 402, and optionally includes the indication information of the target service. If the first terminal 402 has the right to use the target service, the OEM server 401 provides the first terminal 402 with the target service.
  • the OEM server 401 receives a server request for the target service service, and the service request includes the identification information of the first terminal 402, and optionally includes the indication information of the target service.
  • the OEM server 401 generates authority information for the first terminal.
  • the first terminal 402 may send a service invocation request to the OEM server 401, where the service invocation request is used to request the target service. Further optionally, the service invocation request includes permission information. If the first terminal 402 has the right to use the target service, the OEM server 401 provides the first terminal 402 with the target service.
  • the OEM server 401 shown in FIG. 4 can also be replaced by a resource server.
  • an OTA module may be deployed in the resource server, and the resource server may perform data transmission between the OTA module and the OTA module in the vehicle.
  • the service authorization management system shown in FIG. 4 completes work such as authorization determination and service provision through the OEM server 401 .
  • the user only needs to subscribe the service to the OEM server, and the first terminal can receive the service provided by the OEM server without additionally requesting the service from the resource server, which reduces the interaction process and improves the efficiency of service delivery , which improves the user experience.
  • the OEM server is a relatively secure server for the terminal, and can also improve the security during the authorization service process.
  • the authorization management through the OEM server can also save the cost of deploying the authorization server and resource server.
  • FIG. 5 is a schematic flowchart of a service authorization management method based on an OTA technology provided by an embodiment of the present application.
  • the method may be implemented based on the architecture shown in FIG. 2 or FIG. 4 .
  • the method includes but is not limited to the following steps:
  • Step S501 The OEM server receives the first message.
  • the OEM server may be a server, a server cluster composed of multiple servers, or a distributed server.
  • the first message includes identification information of the first terminal.
  • the first terminal is a terminal that uses the target service, for example, but not limited to, the first terminal may be a vehicle, a robot, an unmanned aerial vehicle, and other intelligent devices or transportation tools.
  • the identification information of the first terminal may be the client ID (Client ID) in the first terminal, the ID of the component (or module) in the first terminal, the ID of the first terminal, the MAC address, domain name, domain name of the first terminal.
  • the address or other self-defined identifiers are also referred to as device identifiers, identity identifiers, etc. of the first terminal in some implementations.
  • the identification information of the first vehicle may be the vehicle identification number (Vehicle Identification Number, VIN) code of the first vehicle, a component in the first vehicle (such as HMI, MDC, etc. one or more of), the serial number of the central processing unit (CPU) in the first terminal, the client in the first vehicle (such as a navigation software client, a map client, etc. item or items) ID.
  • VIN Vehicle Identification Number
  • a component in the first vehicle such as HMI, MDC, etc. one or more of
  • the serial number of the central processing unit (CPU) in the first terminal such as a navigation software client, a map client, etc. item or items
  • the identification information of the first terminal when it is an ID, it may be a permanent ID (or called a real ID or a fixed ID) or a temporary ID.
  • the first message may further include indication information of the target service.
  • the target service may be various services, such as one or more of services such as map update, software download, book subscription, audio and video playback, application purchase, automatic driving service, service driving service, and the like.
  • the indication information of the target service may be one or more of the name of the target service (service name), the ID of the target service, and the like. It should be understood that the indication information of the target service may indicate to the OEM server which service or services are required for authorization by the first terminal. Correspondingly, the OEM server correspondingly determines whether the first terminal has the right to use the target service.
  • the first message may also contain multiple messages.
  • the first message includes message A and message B, where message A includes identification information of the first terminal, and message B includes target service indication information.
  • the first message may also not include the indication information of the target service.
  • the OEM server may generate authority information for at least one kind of authority possessed by the first terminal, and the authority information may indicate that the first terminal possesses at least one kind of authority.
  • the OEM server may also obtain the authorization of which service or services required by the first terminal in other ways. For example, the OEM server determines whether the first terminal has the right to the map update service by receiving the map update message sent by the map provider.
  • the first message may further include information of the subscriber (user), the scope and type of the target service to be subscribed, the validity period of the subscription, and the like.
  • the information of the subscriber may further include at least one of the ID of the subscriber, the description information of the subscriber (such as contact information, real name, location), the MAC address of the device used by the subscriber, and so on.
  • the first message may be sent by the first terminal to the OEM server, or may be sent by other terminals to the OEM server, or may be sent by a third-party device (eg, a network-side device) to the OEM server.
  • the OTA related module in the first terminal can communicate with the OEM server through the OTA technology, the first terminal can send the first message to the OEM server through the OTA related module, and correspondingly, the OEM server receives the first message sent by the first terminal. a message.
  • the user of the first terminal may subscribe the target service for the first terminal on the mobile terminal (eg, mobile phone, tablet computer), and the mobile terminal sends the first message to the OEM server.
  • the navigation application in the first terminal requests the map update service, so the navigation application indicates the demand to the OTA main module in the first terminal, and the OTA main module sends the request to the OEM server.
  • First news the navigation application in the first terminal (or the component where the navigation software is located, such as HMI) requests the map update service, so the navigation application indicates the demand to the OTA main module in the first terminal, and the OTA main module sends the request to the OEM server.
  • the first message may also be called a service request (or a service request message, service request information).
  • a service request or a service request message, service request information.
  • the various embodiments of the present application do not limit the name of the message or the information, and only provide an exemplary description and expression of the content of the message, and the name of the message can be arbitrarily replaced.
  • Step S502 The OEM server determines the first authority information according to the identification information of the first terminal.
  • the first permission information is used to indicate that the first terminal has the permission to use the target service.
  • the first authority information includes identification information of the first terminal, indication information of the target service, and validity period of the authority, so that the first terminal can be indicated to have the authority to use the target service.
  • the first authority information includes identification information of the first terminal and control item information for using the target service, so that it can be indicated that the first terminal has the authority to use the target service.
  • the permission information may be one or more items of a token (Token), a license (license), a permission list, a power of attorney, and the like.
  • the Token may include one or more of the following information: identification information of the first terminal (eg: Client ID), indication information of the target service (eg: Service name), expiration time (Expiration time), scope of authority (Scope) and other information.
  • License information may include one or more of target service indication information, control item information (resource control item and/or function control item), validity period, etc., and may also include device feature code, software manufacturer, signature, version and so on.
  • the resource control item is used to indicate the number of clients that the target service (or a certain function in the target service) is allowed to use;
  • the function control item is used to describe the functions allowed to be used by the target service;
  • the device feature code can be regarded as the first Indication information of the terminal, such as the MAC address of the first terminal, the serial number of the CPU, the serial number of the hard disk, and so on.
  • the permission information may also include information of subscribers who subscribe to the target service, and the subscriber information may refer to the description in step S501.
  • the optional OEM server determines the first authority information according to the identification information of the first terminal, and can have the following exemplary designs:
  • Design 1 The OEM server stores multiple terminal identification information and its corresponding permissions.
  • the OEM can query the authority of the first terminal according to the identification information of the first terminal to determine that the first terminal has the authority to use the target service, so as to generate the first authority information according to the identification information of the first terminal and the information of the target service.
  • the OEM server can obtain indication information from the storage device or the network side device through the interface, where the indication information is used to indicate that the first terminal has the right to use the target service. Further, in response to the indication information, the OEM server generates the first authority information according to the identification information of the first terminal.
  • the first terminal purchases the map service on the OEM server, and after paying the corresponding fee in the payment application, the OEM server can determine that the first terminal has the right to use the map service through the payment success result returned by the payment interface. Further, the OEM server generates the first authority information according to the identification information of the first terminal.
  • Design 3 The OEM server can determine whether the terminal meets the conditions for using the target service according to the identification information of the first terminal. First permission information. For example, a blacklist is stored in the OEM, and the terminal in the blacklist does not have the right to use the target service. If the first terminal is not in the blacklist, it has the right to use the target service, so that the first right information is generated according to the identification information of the first terminal.
  • First permission information For example, a blacklist is stored in the OEM, and the terminal in the blacklist does not have the right to use the target service. If the first terminal is not in the blacklist, it has the right to use the target service, so that the first right information is generated according to the identification information of the first terminal.
  • the OEM server may also determine the first authority information in other ways, which are not listed one by one in this application.
  • Step S503 The OEM server sends a second message to the first terminal, where the second message includes the first permission information.
  • the first permission information may be used by the first terminal to invoke the target service.
  • This application cites the following examples of permission information used to invoke target services:
  • Example 1 The target service is provided by the resource server.
  • the first terminal sends a service invocation request to the resource server, and the service invocation request carries the first permission information. Further, the resource server verifies the first authority information, so that the target service can be provided to the first terminal.
  • Example 2 The target service is provided by the OEM server.
  • the first terminal sends a service invocation request to the OEM server, and the service invocation request carries the first permission information. Further, the OEM server verifies the first authority information, so that the target service can be provided to the first terminal.
  • Example 3 The first terminal acquires an encrypted (or not yet activated) target service, and the first terminal can decrypt (or activate) the target service through the first permission information, so that the target service can be used normally.
  • the target service may be acquired from a resource server, or may be acquired from an OEM server, or may be acquired by other means (eg, copying through a computer storage medium).
  • the second message may also carry a first signature, where the first signature is used to verify the first authority information.
  • the first signature is obtained according to the first authority information and the first key.
  • S1 sign(hash(authorization), K1), where sign is the signature algorithm, hash is the hash algorithm, authorization is the first authority information, and K1 is the first key.
  • other parameters such as random numbers, freshness parameters
  • other operations may also be involved in the signing process. sign.
  • the first key may be a first private key or a shared key between the OEM server and the first terminal.
  • the first private key is a private key in a public-private key pair.
  • This application exemplifies a possible situation where the OEM server determines a first public-private key pair (including a first public key and a first private key), wherein the first public key is publicly disclosed (a digital certificate can also be generated by a CA, etc.
  • a public key for authentication) the first private key is stored privately (securely stored) by the OEM server.
  • the OEM server obtains the first signature by signing the first authority information with the first private key.
  • the OEM server carries the first authority information and the first signature in the second message, and optionally carries the first public key and the digital certificate. Subsequently, the first terminal may verify the first authority information according to the first signature.
  • the shared key between the OEM server and the first terminal may include a symmetric encryption key, a pre-shared key, and the like.
  • the OEM server signs the first authority information using the shared key, and the corresponding first terminal can use the shared key to verify the signature to verify the first authority information.
  • the second message may also be called a service request response, or a service request response message, service request response information, or the like.
  • a secure channel (referred to as a first secure channel for convenience of description) may be established between the first terminal and the OEM server, and the first message and/or the second message may be transmitted through the first secure channel.
  • the first terminal may establish a first secure channel with the OEM server before sending the first message, and transmit the first message (or and the second message) through the first secure channel.
  • the first terminal may establish a first secure channel with the OEM server before sending the second message, and transmit the second message through the first secure channel.
  • the first security channel may be a transmission channel based on a Secure Sockets Layer (SSL) protocol or a Transport Layer Security (Transport Layer Security, TLS) protocol, and is used for data security transmission.
  • the secure channel may include a Hypertext Transfer Protocol (Secure Hypertext Transfer Protocol, HTTPs) secure channel, a Transport Layer Security (TLS) secure channel, or a Datagram Transport Layer Security (DTLS) secure channel, etc. one or more of.
  • the first terminal when the first terminal establishes the first security channel with the OEM server, it may be necessary to perform relevant security configuration, so as to transmit information securely.
  • the first terminal and the OEM server can confirm one or more of the identity of the other party, and determine the public-private key pair for encryption and decryption, etc. through the certificate.
  • the OEM server sends the second message to the first terminal, and correspondingly, the first terminal receives the second message from the OEM server. Further, the first terminal may verify the first authority information based on the first signature in the second message. For example, the first signature is obtained based on the first authority information and the first key, and the first terminal can verify the first authority information by using the first signature and the third key, and the third key is the first key decryption key.
  • the first key may be the first private key determined by the OEM server, and the third key may be the first public key.
  • the first public key and the first private key are a key pair, which can be added to each other. decrypt.
  • the first terminal may also verify the legitimacy of the authority information. For example, the first terminal verifies whether the identification information of the first terminal in the authority information is consistent with its own identification information, so as to verify whether the authority information is legal.
  • the target service is subscribed by a subscriber (user), the authority information includes subscriber information, and the first terminal can verify whether the subscriber information is consistent with the user of the first terminal, thereby verifying whether the authority information is legal.
  • the OTA technology-based service authorization management method shown in FIG. 5 may further include one or more steps of step 601 to step S604 shown in 6 .
  • the embodiment shown in FIG. 6 may be implemented based on the architecture shown in FIG. 2 . Specifically, steps 601 to S604 are as follows:
  • Step S601 The first terminal sends a fourth message to the resource server.
  • the fourth message includes the identification information of the first terminal and the first authority information.
  • the fourth message may further include indication information of the target service, for example, the first permission information may include indication information of the target service.
  • the resource server is a device with data processing capability, which may be a physical device such as a host, a server, etc., or a virtual device such as a virtual machine, a container, and the like. It should be noted that, for convenience of description, it is referred to as a server here, and in a specific implementation process, it may be a server, or may be other devices with data processing capabilities.
  • a resource server is a server that provides target services.
  • the resource server is a server belonging to a service provider (Service Provider).
  • Service Provider the resource server may belong to the map cloud server of the map provider, and may provide services such as map download and map update.
  • the first authority information includes the identification information of the first terminal and the indication information of the target service.
  • the fourth message may not include the identification information and/or the first terminal. or an indication of the target service.
  • the fourth message may also be referred to as a service invocation request, or a service use request, a service invocation message, service invocation information, and the like.
  • the first terminal sends the fourth message to the resource server, and correspondingly, the resource server receives the fourth message from the first terminal.
  • Step S602 The resource server verifies the first permission information.
  • the fourth message carries the first permission information
  • the resource server can verify the first permission information. For example, one or more of checking whether the first authority information is valid, checking the correctness and integrity of the first authority information, and so on.
  • Implementation mode 1 After the OEM server determines the first permission information, it sends the first permission information to the resource server (for convenience and description, the first permission information sent by the OEM server to the resource server is called the second permission information).
  • the resource server compares the second authority information with the first authority information from the first terminal, and if both the second authority information and the first authority information indicate that the first terminal has the authority to use the target service, then verifies the first authority information pass. Further, when the second authority information is consistent with the first authority information, the verification of the first authority information is passed.
  • the OEM server also sends a second signature to the resource server, where the second signature is obtained according to the second permission information and the second key.
  • the second signature is used for the resource server to verify the second permission information.
  • S2 sign(hash(authorization), K2), where sign is the signature algorithm, hash is the hash algorithm, authorization is the first authority information, and K2 is the second key.
  • the second key may be a private key in a pair of public and private keys (including the second private key and the second public key), which is referred to as the second private key for convenience of description, wherein the second private key is the same as the second private key.
  • the public keys decrypt each other.
  • the second signature and the aforementioned first signature may be generated based on the same private key (that is, the first private key and the second private key may be the same private key).
  • the subsequent resource server may verify the second permission information according to the second signature.
  • the resource server verifies the second authority information according to the second signature and the sixth key, where the sixth key is a decryption key of the second key.
  • the second key is the second private key
  • the sixth key is the second public key.
  • the resource server can verify the correctness of the second permission information according to the signature, so as to prevent the attacker from sending false permission information to the resource server, ensure the privacy of the service authorization process, and avoid losses to the service provider.
  • the first key may also be a shared key between the OEM server and the resource server.
  • the shared key may include a symmetric encryption key, a pre-shared key, and the like.
  • the OEM server signs the second authority information using the shared key, and the corresponding resource server can use the shared key to verify the signature to verify the second authority information.
  • the fourth message also includes a fourth signature and a first signature, where the fourth signature is obtained by the first terminal based on the first signature and the fourth private key, wherein the first signature is the OEM based on the first private key and the fourth private key.
  • the first permission information is obtained.
  • the first server verifies the first authority information according to the fourth signature, the fourth public key, the first signature, and the first public key.
  • the fourth private key and the fourth public key are a public-private key pair determined or saved by the first terminal.
  • the first terminal receives the first signature from the OEM server, and the first terminal can obtain the fourth signature according to the first signature and the fourth private key.
  • the resource server may verify the first signature according to the fourth public key and the fourth signature, thereby determining that the first signature is sent by the first terminal to the server. Further, the resource server verifies the first authority information according to the OEM's first public key and the first signature. If the verification is successful, it means that the first authority information really comes from the OEM server and has not been tampered with, thereby ensuring service authorization. privacy of the process.
  • the OEM server also uses other methods to verify the first permission information, which will not be repeated here.
  • the resource server may not provide services to the first terminal. Further, the resource server may also send a reminder message to the first terminal for Indicates that it does not have usage rights or a permission message error.
  • Step S603 In response to passing the verification of the first authority information, the resource server provides the target service to the first terminal.
  • the resource server provides the target service to the first terminal.
  • the resource server may send a response message to the first terminal.
  • the response message may also be referred to as a service invocation request response.
  • the response message indicates that the resource server agrees to provide the target service to the first terminal.
  • the response message may further include an application programming interface (Application Programming Interface, API) for calling the target service, so that the first terminal can use the target service through the API.
  • API Application Programming Interface
  • a secure channel (referred to as a second secure channel for convenience of description) may be established between the first terminal and the resource server, and the fourth message (or the response message) may be transmitted through the second secure channel.
  • the second secure channel may be a transmission channel based on the SSL) protocol or the TLS protocol, which is used for secure data transmission.
  • the secure channel may include one or more of the Hypertext Transport Security Protocol (HTTPs) secure channel, the Transport Layer Security (TLS) secure channel, or the DTLS secure channel, and the like.
  • HTTPs Hypertext Transport Security Protocol
  • TLS Transport Layer Security
  • the first terminal when the first terminal establishes the second security channel with the resource server, it may be necessary to perform related security configuration, so as to transmit information securely.
  • the first terminal and the resource server can confirm one or more of the identity of the other party, and determine the public-private key pair for encryption and decryption, and so on, through the certificate.
  • the first terminal receives the target service provided by the resource server, and uses the target service according to the permission information. For example, use within the validity period of the permission in the permission information. For another example, taking the permission information as the license as an example, the first terminal uses the target service according to the license control item.
  • step S604 which is specifically as follows:
  • the first terminal may synchronize the permission status to the OEM server, where the permission status includes one or more items of information such as the validity period of the permission and the duration of the permission usage.
  • the first terminal synchronizes the status of the authority to the OEM server, so that the OEM can obtain the change of the authority status in time, which is beneficial to maintain the consistency of the data and improve the stability of the system.
  • the above-mentioned methods shown in FIG. 5 and FIG. 6 may be completed by a module in the OEM or a certain component (module) in the first terminal.
  • FIG. 7 is a schematic flowchart of a service authorization management method based on OTA technology provided by the implementation of the present application, and a process of obtaining a service by a first terminal is described by taking map update as an example.
  • the embodiment shown in FIG. 7 may be implemented based on the architecture shown in FIG. 2 .
  • the method includes at least the following steps:
  • Step S701 The interaction module of the OEM server obtains the information of the mobile phone or the HMI subscribed to the map service.
  • the interaction module of the OEM server can communicate with other devices. Therefore, information about the mobile phone or HMI subscribed to the map service can be obtained, such as one or more of subscriber information, identification information of the first terminal, indication information of the map service, validity period of the subscription, and the like.
  • the terminal can be a mobile terminal such as a mobile phone, a tablet computer, a notebook computer, a robot, a smart home device, etc.
  • a mobile terminal such as a mobile phone, a tablet computer, a notebook computer, a robot, a smart home device, etc.
  • vehicles such as vehicles, ships, etc.
  • the user subscribes to the map service through the HMI or the mobile phone, and the HMI or the mobile phone sends a first message to the OEM server, where the first message is used to indicate the information to subscribe to the map service.
  • the OEM server parses the first message, so as to obtain the information of the subscription map service.
  • Step S702 The interaction module of the OEM server generates permission information for using the map service.
  • the interaction module of the OEM server generates permission information (for example, one or more of a License file, Token, permission list, etc.) for the first terminal to use the map service according to the information of the subscription map service.
  • permission information for example, one or more of a License file, Token, permission list, etc.
  • the OEM server may generate information on the rights of the subscriber (user) and the first terminal to use the map service according to the information of the subscription map service.
  • the permission information for map usage includes the identification information of the first terminal and the map usage permission, and may also include one or more items of information such as subscriber information and validity period.
  • the OEM server may determine that the first terminal has the permission to use the map service. For example, after receiving the information about subscribed map service, the OEM server checks the payment status or whether it meets the conditions for using the map service. If the conditions for using the map service are satisfied or the payment is successful, it is determined that the first terminal has the right to use the map service.
  • the interaction module of the OEM server sends the permission information to the OTA permission management module, and then the OTA permission management module sends the permission information to the OTA task management module.
  • the transmission between the modules in the OEM server or the first terminal shown in FIG. 7 may be transmission through a bus, or transmission based on communication channels such as a limited link and a wireless link.
  • step S702 may also be completed by the OTA rights management module of the OEM server.
  • the interaction module of the OEM cloud sends the information that the user subscribes to the map service to the OTA authority management module, and the OTA authority management module generates authority information.
  • the OTA authority management module sends the authority information to the OTA task management module.
  • Step S703 The OTA task management module of the OEM server signs the authority information to obtain a first signature.
  • the first signature is obtained according to the authority information and the first key.
  • S1 sign(hash(authorization), K1).
  • the second message carries the permission information for using the map service and the first signature.
  • the OTA main module can also be replaced with a map OTA client.
  • the OEM server sends the second message to the OTA main module of the first terminal, and correspondingly, the OTA main module of the first terminal receives the second message from the first terminal.
  • Step S705 The OTA main module of the first terminal verifies the authority information according to the first signature.
  • the first terminal may verify the authority information according to the first signature and the first public key.
  • the OTA main module of the first terminal decrypts the first signature using the first public key, obtains the hash value of the permission information (called hash1), and then uses the permission information in the first message to generate the hash value (called hash2).
  • the permission information can be verified by comparing hash1 and hash2.
  • the OTA Master or the map OTA client sends the authority information to the authority management module.
  • Step S706 The authority management module of the first terminal verifies the validity of the authority information.
  • the authority management module verifies the validity of the authority information. For example: the rights management module compares the information of the subscribers (users) collected from the first terminal (for example, the rights management module can obtain the information of the subscribers through HMI), the identification information of the first terminal and the subscribers (users) in the rights information. ) and the information of the first terminal are consistent, so as to verify whether the authority information is legal.
  • the authority management module sends the authority information to the MDC.
  • Step S707 The MDC of the first terminal sends a map update request to the map cloud.
  • the MDC sends a map update request to the map cloud, which carries the permission information and the identification information of the first terminal.
  • the map update request further includes one or more of the model of the first terminal, hardware information, the version number of the client, and the like.
  • Step S708 the map cloud verifies the authority information.
  • Step S709 The MDC of the map cloud sends a map update response to the map cloud.
  • a map update response is sent to the MDC to update the map.
  • the map update response can include the map update API.
  • the first terminal can acquire the updated map according to the API.
  • Step S710 The MDC of the first terminal controls the use of the map service according to the permission information.
  • the MDC controls the use of the map according to the permission information. For example, if the permission information is License, MDC uses the map service according to the license control item.
  • the first terminal (specifically, the rights management module or MDC) synchronizes the map rights status (for example, map usage validity period information) to the OTA Master or the map OTA client.
  • the map rights status for example, map usage validity period information
  • the map service may also be a map OTA client or other components in the vehicle, which are only examples here.
  • the map OTA client in the first terminal uses the map service according to the resource control item and/or the permission control item in the license.
  • the OTA Master or the map OTA client synchronizes the map permission status to the OTA permission management module and the HMI.
  • the OTA technology-based service authorization management method shown in FIG. 5 may further include step S801 shown in FIG. 8 .
  • the embodiment shown in FIG. 8 can be implemented based on the architecture shown in FIG. 4 .
  • step S801 is as follows:
  • Step S801 The OEM server provides the target service to the first terminal.
  • the OEM server 401 acts both as a device for generating rights information and as a device for providing services.
  • the service provided by the OEM server 401 may be deployed on the OEM server by a service provider (Service Provider).
  • the OEM server 401 can also be used as an agent, and the services deployed by the service provider on other servers can be obtained through the OEM server 401 .
  • the OEM server may directly send the target service to the first terminal, or may provide the first terminal with an AP that uses the target service (for example, carried in a response message).
  • the OEM server provides the target service to the first terminal, and accordingly, the first terminal can use the target service.
  • the first terminal may use the target service according to the permission information.
  • the target service as the map service as an example
  • the MDC in the vehicle (only an example, it may also be other on-board components or on-board modules in the vehicle) can run the map service according to the license control item.
  • the first terminal may synchronize the permission status to the OEM server, for example, synchronize information such as the validity period of the permission information.
  • the first terminal synchronizes the validity period of the permission with the OEM server after starting to use the target service or using the target service.
  • the OEM server provides the target service to the first terminal, which may include one or more of steps S901 to S904 shown in FIG. 9 .
  • steps S901 to S904 are as follows:
  • Step S901 The first terminal sends a third message to the OEM server.
  • the third message includes the identification information of the first terminal and the first authority information.
  • the first permission information received by the OEM from the first terminal is referred to as third permission information.
  • the third message may further include indication information of the target service.
  • the first permission information includes the identification information of the first terminal and the indication information of the target service.
  • the third message may not include the identification information of the first terminal and/or or an indication of the target service.
  • the third message may also be called a service invocation request, or a service invocation message, service invocation information, and the like. It should be understood that the first terminal sends the third message to the OEM server, and correspondingly, the OEM server receives the third message from the first terminal.
  • Step S902 The OEM server verifies the third authority information according to the first authority information.
  • the third message includes third authority information
  • the resource server generates the first authority information for the first terminal, so the OEM can verify the third authority information according to the first authority information. For example, one or more of checking whether the first authority information is valid, checking the correctness and integrity of the first authority information, and so on.
  • the OEM server may store the first permission information.
  • the OEM server may compare the first authority information stored by itself with the third authority information from the first terminal, so as to verify whether the first authority information from the first terminal is correct and complete.
  • the OEM server provides the target server to the first terminal. If the verification of the third authority message fails, it indicates that the third authority information is incorrect or has been tampered with, and the OEM server may not provide services to the first terminal. Further, the OEM server may also send a reminder message to the first terminal for Indicates that it does not have usage rights or a permission message error.
  • Step S903 The OEM server provides the target service to the first terminal.
  • the OEM server provides the target service to the first terminal.
  • the OEM server may send a response message to the first terminal.
  • the response message may also be referred to as a service invocation request response.
  • the response message indicates that the OEM server agrees to provide the target service to the first terminal.
  • a first secure channel (referred to as a second secure channel for convenience of description) may be established between the first terminal and the OEM server, and the third message (or the response message) may be transmitted through the first secure channel.
  • a second secure channel for convenience of description
  • the third message or the response message
  • the first security channel reference may be made to the embodiment shown in FIG. 5 , and details are not repeated here.
  • step S904 which is specifically as follows:
  • Step S904 The first terminal synchronizes the permission status with the OEM server. For details, refer to the detailed description in step S604.
  • the method shown in FIG. 8 or FIG. 9 may be performed by a module in the OEM or a certain component (module) in the first terminal.
  • FIG. 10 is another possible situation provided by the embodiment of the present application:
  • Step S1001 the map cloud service module of the OEM server obtains the information that the mobile phone or the HMI subscribes to the map service.
  • the OEM server is a device that can communicate with the first terminal based on the OTA technology.
  • the OEM server can both generate authorization information and provide services. Therefore, the OEM server can also be seen as a resource server (such as a map cloud).
  • the map cloud service module of the OEM server can communicate with other devices. Therefore, information about the mobile phone or HMI subscribed to the map service can be obtained, such as one or more of the subscriber's information, the identification information of the first terminal, the indication information of the map service, the validity period of the subscription, and so on.
  • Step S1002 The rights management module of the OEM server generates rights information for using the map service.
  • step S1002 can also be completed by the map cloud service module of the OEM server.
  • the interaction module of the OEM cloud sends the information that the user subscribes to the map service to the OTA authority management module, and the OTA authority management module generates authority information.
  • the OTA authority management module sends the authority information to the OTA task management module.
  • a map update task can be triggered in the OTA task management module, and the OTA task management module can provide the first terminal with a map update service. In this way, the subsequent first terminal does not need to send a service call request to the map cloud, which reduces the interaction process.
  • the map update service can be provided to the first terminal first, but the first terminal still needs relevant permissions when using the map update service.
  • the OTA task management module can send a high-precision map data package to the first terminal, but the first terminal needs to provide corresponding permissions to use the high-precision map data package.
  • Step S1003 The OTA task management module of the OEM server signs the authority information to obtain a first signature.
  • Step S1004 the OTA task management module of the OEM server sends a second message to the OTA main module of the first terminal.
  • Step S1005 The OTA main module of the first terminal verifies the authority information according to the first signature.
  • Step S1006 The authority management module of the first terminal verifies the validity of the authority information.
  • step S1007 is further included: the OTA task management module of the OEM server provides a map service to the first terminal.
  • this step S1007 may also be performed after step S1002.
  • the map service module of the OEM can also provide the map service to the first terminal through the OTA task management module.
  • Step S1008 The MDC of the first terminal controls the use of the map service according to the authority information.
  • the MDC controls the use of the map according to the permission information.
  • the MDC uses the map service according to the license control item.
  • the first terminal (specifically, the rights management module or MDC) synchronizes the map rights status (for example, map usage validity period information) to the OTA Master or the map OTA client.
  • the map rights status for example, map usage validity period information
  • FIG. 11 is a schematic flowchart of still another OTA technology-based service authorization management method provided by an embodiment of the present application.
  • the method may be implemented based on the architecture shown in FIG. 3 .
  • the method includes but is not limited to the following steps:
  • Step S1101 The first terminal sends a fifth message to the resource server.
  • the fifth message includes identification information of the first terminal.
  • the fifth message further includes indication information of the target service.
  • the first terminal is a terminal using the target service.
  • the indication information of the target service, and the identification information of the first terminal reference may be made to the relevant description in step S501.
  • a resource server is a server that provides target services.
  • For the resource server please refer to the relevant description in step S501.
  • Step S1102 The resource server sends a sixth message to the OEM server.
  • the sixth message is used to request authorization information.
  • the OEM server can determine the authority corresponding to at least one terminal, so the resource server requests authorization information from the OEM server through the sixth message.
  • the permission information of the OEM server may be generated by the OEM server based on the message of subscribing to the target service.
  • the subscriber may subscribe to the target service through the terminal, and the OEM server generates permission information based on the message of subscribing to the target service.
  • This application exemplifies a possible scenario: the user subscribes to the map service through the HMI or the mobile phone, and the HMI or the mobile phone sends a message for subscribing to the target service to the OEM server.
  • the OEM server generates permission information for using the map service according to the message of subscribing to the target service.
  • the OEM server supports information transmission with the first terminal through OTA technology.
  • the sixth message may include identification information of the first terminal.
  • the resource server sends the sixth message to the OEM server, and correspondingly, the OEM server receives the sixth message from the resource server.
  • Step S1103 The OEM server sends a seventh message to the resource server.
  • the seventh message includes first indication information, where the first indication information is used to indicate whether the first terminal has the right to use the target service.
  • the first indication information includes a first field (which may be pre-configured, or mutually negotiated, or specified in a protocol, without limitation), and when the first field is a first preset value, it indicates that the first terminal Has permission to use the target service.
  • the first field is the second preset value, it indicates that the first terminal does not have the right to use the target service. For example, "1" in the first field indicates that the first terminal has the right to use the target service, and "0" in the first field indicates that the first terminal does not have the right to use the target service.
  • the first indication information is permission information of the first terminal or information that does not have permission. If the OEM server returns the permission information of the first terminal, it indicates that the first terminal has the permission to use the target service. If the first terminal returns information such as "false" and "no authority", it indicates that the first terminal does not have the authority to use the target service.
  • the seventh message further includes a third signature, where the third signature is used to verify the first indication information.
  • the third signature is obtained according to the first indication information and the fourth key. It should be noted that other parameters (eg, random numbers, freshness parameters) or other operations may also be involved in the signature process.
  • the fourth key is a third private key or a shared key between the OEM server and the resource server.
  • the OEM server sends the seventh message to the resource server, and accordingly, the resource server receives the seventh message from the OEM server.
  • Step S1104 In response to the first terminal having the right to use the target service, the resource server provides the target service to the first terminal.
  • the resource server can determine whether the first terminal has the right to use the target service according to the first indication information.
  • the resource server In response to the first terminal having the right to use the target service, the resource server provides the target service to the first terminal.
  • the resource server For a specific description, refer to the related content in S603, which will not be repeated here.
  • the seventh message further includes a third signature, where the third signature is used to verify the first indication information.
  • the third signature is obtained based on the first indication information and the fourth key, and the resource server can verify the first indication information through the third signature and the fifth key, and the fifth key is the The decryption key for the fourth key.
  • the fourth key may be the third private key determined by the OEM server, and the fifth key may be the third public key.
  • the third public key and the third private key are a key pair, which can be added to each other. decrypt.
  • the first terminal may use the target service according to the permission information.
  • the target service as the map service as an example
  • the MDC in the vehicle can run the map service according to the license control item.
  • the first terminal may synchronize the permission status to the OEM server, for example, synchronize information such as the validity period of the permission information.
  • the first terminal synchronizes the validity period of the permission with the OEM server after starting to use the target service or using the target service.
  • the OEM server completes work such as authority determination and return of authority information. Since the OEM server can obtain the authority information, when the first terminal requests the resource server to call the target service, the resource server determines the authority to the OEM server, which can reduce the interaction process of the first terminal and reduce the interaction between the service authorization process. reduce the complexity of communication control and improve the efficiency of service authorization. Further, the OEM server is a relatively secure server for the first terminal, which can also improve the security during the authorization service process. In addition, the authorization management is performed through the OEM server, which can also save the cost of deploying the authorization server.
  • the first terminal may be a smart car, and this solution provides a solution for service authorization management in the field of smart cars.
  • the smart car manages the service authorization through the OEM server, which improves the safety and comfort of the user using the service through the smart car.
  • FIG. 12 is a schematic structural diagram of a service authorization management apparatus 120 provided by an embodiment of the present application.
  • the service authorization management apparatus 120 may include a receiving unit 1201 , a processing unit 1202 , and a sending unit 1203 .
  • the service authorization device 120 is used to implement the aforementioned service authorization management method, for example, it can be used to implement the service authorization method shown in FIG. 5 , FIG. 6 , FIG. 7 , FIG. 8 , FIG. 9 or FIG. 10 .
  • the division of multiple units or modules is only a logical division based on functions, and is not intended to limit the specific structure of the apparatus.
  • some functional modules may be subdivided into more small functional modules, and some functional modules may also be combined into one functional module, but no matter whether these functional modules are subdivided or combined, service authorization management
  • the general process performed in the process is the same.
  • the receiving unit 1201 and the sending unit 1203 in the above-mentioned service authorization device 120 can also be combined into a communication unit or a transceiver, and the communication unit or the transceiver is used to realize the function of receiving and sending data.
  • each unit corresponds to its own program code (or program instruction), and when the program code corresponding to each of these units is executed on at least one processor, the unit executes the corresponding process to realize the corresponding function.
  • the service authorization management device 120 shown in FIG. 12 may be the OEM server in the embodiment shown in FIG. 5 , FIG. 6 , FIG. 7 , FIG. 8 , FIG. 9 or FIG. 10 , or the OEM server A device in a server, such as a chip or integrated circuit, etc.
  • the detailed description of each unit of the service authorization management apparatus 120 shown in FIG. 12 is as follows:
  • a receiving unit 1201 configured to receive a first message, where the first message includes identification information of a first terminal, and the first terminal is a terminal that needs to use a target service;
  • a processing unit 1202 configured to determine first authority information according to the identification information of the first terminal, wherein the first authority information is used to indicate that the first terminal has the authority to use the target service;
  • the sending unit 1203 is configured to send a second message to the first terminal, where the second message includes the first permission information.
  • the service authorization management apparatus further includes an OTA task management module (not shown in the figure). Further, an OTA rights management module (not shown in the figure) may also be included, and the OTA rights management module is used to generate rights information.
  • the first message further includes indication information of the target service.
  • the second message further includes a first signature, where the first signature is used to verify the first permission information.
  • the processing unit 1202 is further configured to obtain the first signature according to the first permission information and a first key, where the first key is a first private key or is the shared key between the original equipment manufacturer OEM server and the first terminal.
  • the first message further includes indication information of the target service.
  • the target service is provided by a resource server, and the first permission information is used for the first terminal to request the target service from the resource server.
  • the sending unit 1203 is further configured to send second permission information to the resource server, where the second permission information is used to indicate that the first terminal has access to the target service permission.
  • the sending unit 1203 is further configured to send a second signature to the resource server, where the second signature is the OEM server according to the second permission information and the second password
  • the second key is a second private key or a shared key between the OEM server and the resource server.
  • the target service is provided by an original equipment manufacturer OEM server
  • the sending unit 1203 is further configured to provide the target service to the first terminal.
  • the receiving unit 1201 is further configured to receive a third message from the first terminal, where the third message includes third permission information;
  • the processing unit 1202 is further configured to verify the third authority information according to the first authority information.
  • the receiving unit 1201 is further configured to receive the permission status synchronized by the first terminal.
  • a first secure channel is established between the service authorization management apparatus and the first terminal, and the second message is transmitted through the first secure channel;
  • the first security channel includes at least one of a transport layer security protocol TLS security channel, a data packet transport layer security protocol DTLS security channel or a hypertext transport security protocol HTTPs security channel.
  • a processing unit 1202 configured to verify the first permission information
  • a sending unit 1203, configured to send a fourth message to the resource server, where the fourth message includes the first permission information and the identification information of the first terminal;
  • the receiving unit 1201 is further configured to receive the target service provided by the resource server.
  • a first secure channel is established between the service authorization management device 120 and the OEM server, and the second message is transmitted through the first secure channel
  • the first secure channel includes at least one of a TLS secure channel, a DTLS secure channel or an HTTPs secure channel.
  • a second secure channel is established between the first terminal and the resource server, and the fourth message is transmitted through the second secure channel
  • the second secure channel includes at least one of a TLS secure channel, a DTLS secure channel or an HTTPs secure channel.
  • the sending unit 1203 is further configured to:
  • the second message further includes a first signature
  • the first signature is used to verify the first permission information.
  • the first signature is obtained based on the first authority information and a first key
  • the processing unit 1202 is configured to verify the first authority information according to the first signature and a third key, where the third key is a decryption key of the first key.
  • the sending unit 1203 is further configured to synchronize the permission status with the OEM server.
  • the service authorization management apparatus 120 shown in FIG. 12 may be the first terminal in the embodiment shown in FIG. 8 , FIG. 9 or FIG. 10 , or a device in the first terminal, such as chip or integrated circuit, etc.
  • the detailed description of each unit of the service authorization management device 120 shown in FIG. 12 is as follows:
  • a receiving unit 1201 configured to receive a second message from the OEM server, where the second message includes first permission information, and the first permission information is used to indicate that the first terminal has the permission to use the target service;
  • a processing unit 1202 configured to verify the first permission information
  • a sending unit 1203, configured to send a third message to the OEM server, where the third message includes the first permission information
  • the receiving unit 1201 is further configured to receive the target service provided by the OEM server.
  • a first secure channel is established between the service authorization management device and the OEM server, and the second message and/or the third message is sent through the first secure channel transmission, the first secure channel includes at least one of a TLS secure channel, a DTLS secure channel, or an HTTPs secure channel.
  • the sending unit 1203 is further configured to:
  • the sending unit 1203 is further configured to synchronize the permission status with the OEM server.
  • the service authorization management apparatus 120 shown in FIG. 12 may be the resource server in the embodiment shown in FIG. 5 , FIG. 6 or FIG. 7 , or a device in the resource server, such as a chip or integrated circuits, etc.
  • the detailed description of each unit of the service authorization management apparatus 120 shown in FIG. 12 is as follows:
  • a processing unit 1202 configured to verify the first permission information
  • the sending unit 1203 is configured to provide the target service to the first terminal in response to passing the verification of the first permission information.
  • the fourth message further includes indication information of the target service.
  • the above-mentioned indication information of the target service may also be included in the first permission information.
  • the receiving unit 1201 is further configured to receive second permission information from the OEM server, where the second permission information is used to indicate that the first terminal has the permission to use the target service .
  • the processing unit 1202 is configured to verify the first permission information according to the second permission information.
  • a second secure channel is established between the first terminal and the resource server, and the first terminal and the resource server perform information transmission through the second secure channel, so
  • the second secure channel includes at least one of a TLS secure channel, a DTLS secure channel or an HTTPs secure channel.
  • FIG. 13 is a schematic structural diagram of a service authorization management apparatus 130 provided by an embodiment of the present application.
  • the service authorization management apparatus 130 may include a receiving unit 1301 and a sending unit 1302 .
  • a processing unit 1303 may also be included.
  • the service authorization device 120 is used to implement the aforementioned service authorization management method, for example, it can be used to implement the service authorization method shown in FIG. 11 .
  • the service authorization management apparatus 130 shown in FIG. 13 may be the resource server in the embodiment shown in FIG. 11 , or a device in the resource server, such as a chip or an integrated circuit.
  • the detailed description of each unit of the service authorization management apparatus 130 shown in FIG. 13 is as follows:
  • a receiving unit 1301, configured to receive a fifth message sent by the first terminal, where the fifth message includes identification information of the first terminal, and the first terminal is a terminal that needs to use the target service;
  • a sending unit 1302 configured to send a sixth message to the OEM server, where the sixth message is used to request permission information
  • the receiving unit 1301 is further configured to receive a seventh message from the OEM server, where the seventh message includes first indication information, where the first indication information is used to indicate that the first terminal has the ability to use the target permissions to the service;
  • the sending unit 1302 is further configured to provide the target service to the first terminal.
  • the sixth message includes identification information of the first terminal and/or identification information of the target service.
  • the seventh message further includes a third signature, where the third signature is used to verify the first indication information.
  • the third signature is obtained based on the first indication information and the fourth key.
  • the apparatus further includes:
  • the processing unit 1303 is configured to verify the first indication information by using the third signature and a fifth key, where the fifth key is a decryption key of the fourth key.
  • the service authorization management apparatus 130 shown in FIG. 13 may be the OEM server in the embodiment shown in FIG. 11 , or a device in the OEM server, such as a chip or an integrated circuit.
  • the detailed description of each unit of the service authorization management apparatus 130 shown in FIG. 13 is as follows:
  • a receiving unit 1301, configured to receive a sixth message sent by the resource server, where the sixth message is used to request permission information
  • the sending unit 1302 is configured to send a seventh message to the resource server, where the seventh message includes first indication information, and the first indication information is used for whether the first terminal has the right to use the target service.
  • the sixth message includes identification information of the first terminal and/or identification information of the target service.
  • the seventh message further includes a third signature; the apparatus further includes:
  • the processing unit 1303 is configured to obtain the third signature according to the first indication information and a fourth key, where the fourth key is a third private key or a signature between the OEM server and the resource server. Shared key.
  • the service authorization management apparatus 130 shown in FIG. 13 may be the OEM server in the embodiment shown in FIG. 11 , or a device in the OEM server, such as a chip or an integrated circuit.
  • the detailed description of each unit of the service authorization management apparatus 130 shown in FIG. 13 is as follows:
  • a sending unit 1302 configured to send a fifth message to the resource server, where the fifth message includes first permission information and identification information of the first terminal;
  • the receiving unit 1303 is configured to receive the target service provided by the resource server.
  • the fifth message further includes identification information of the first terminal.
  • the above-mentioned indication information of the target service may also be included in the first permission information.
  • FIG. 14 is a schematic structural diagram of a service authorization management apparatus 140 provided by an embodiment of the present application.
  • the apparatus 140 may include at least one processor 1401 and a communication interface 1402 .
  • a bus 1403 may also be included.
  • at least one memory 1404 may also be included, wherein the processor 1401 , the communication interface 1402 and the memory 1404 are connected through a bus 1403 .
  • the communication interface 1402 is used to receive and/or send data to the outside, and may be a wired link interface such as an Ethernet cable, or a wireless link (Wi-Fi, Bluetooth, general wireless transmission, etc.) interface.
  • the communication interface 1402 may further include a transmitter (eg, a radio frequency transmitter, an antenna, etc.), or a receiver, etc., coupled with the interface.
  • the memory 1404 is used to provide storage space, and the storage space can store data such as operating systems and computer programs.
  • the memory 1601 may be random access memory (RAM), read-only memory (ROM), erasable programmable read only memory (EPROM), or portable read-only memory A combination of one or more of the memory (compact disc read-only memory, CD-ROM), etc.
  • the processor 1401 in the device 140 is configured to read the computer program stored in the memory 1404, to execute the aforementioned service authorization management method, such as FIG. 5, FIG. 6, FIG. 7, FIG. 8, FIG. 9, and FIG. 10. Or the service authorization management method described in any one of the embodiments in FIG. 11 .
  • the service authorization management apparatus 140 may be the OEM server in the embodiment shown in FIG. 5 , FIG. 6 , FIG. 7 , FIG. 8 , FIG. 9 or FIG. 10 , or a device in the OEM server , such as chips or integrated circuits.
  • the processor 1401 in the service authorization management device 140 is configured to read the computer program stored in the memory 1404, to perform the following operations:
  • the first message includes identification information of a first terminal, and the first terminal is a terminal that needs to use the target service;
  • the service authorization management apparatus further includes an OTA task management module (not shown in the figure). Further, an OTA rights management module (not shown in the figure) may also be included, and the OTA rights management module is used to generate rights information.
  • the first message further includes indication information of the target service.
  • the second message further includes a first signature, where the first signature is used to verify the first permission information.
  • the processor 1401 is further configured to obtain the first signature according to the first permission information and a first key, where the first key is a first private key or is the shared key between the original equipment manufacturer OEM server and the first terminal.
  • the first message further includes indication information of the target service.
  • the target service is provided by a resource server, and the first permission information is used for the first terminal to request the target service from the resource server.
  • processor 1401 is further configured to:
  • processor 1401 is further configured to:
  • the target service is provided by an original equipment manufacturer OEM server; the processor 1401 is further configured to:
  • the target service is provided to the first terminal through the communication interface 1402 .
  • processor 1401 is further configured to:
  • the third authority information is checked according to the first authority information.
  • processor 1401 is further configured to:
  • the permission status synchronized by the first terminal is received through the communication interface 1402 .
  • a first secure channel is established between the service authorization management apparatus and the first terminal, and the second message is transmitted through the first secure channel;
  • the first security channel includes at least one of a transport layer security protocol TLS security channel, a data packet transport layer security protocol DTLS security channel or a hypertext transport security protocol HTTPs security channel.
  • the service authorization management apparatus 140 may be the first terminal in the embodiment shown in FIG. 5 , FIG. 6 or FIG. 7 , or a device in the first terminal, such as a chip or an integrated circuit, etc. .
  • the processor 1401 in the service authorization management device 140 is configured to read the computer program stored in the memory 1404, to perform the following operations:
  • the target service provided by the resource server is received through the communication interface 1402 .
  • a first secure channel is established between the service authorization management device 140 and the OEM server, and the second message is transmitted through the first secure channel
  • the first secure channel includes at least one of a TLS secure channel, a DTLS secure channel or an HTTPs secure channel.
  • a second secure channel is established between the first terminal and the resource server, and the fourth message is transmitted through the second secure channel
  • the second secure channel includes at least one of a TLS secure channel, a DTLS secure channel or an HTTPs secure channel.
  • processor 1401 is further configured to:
  • the second message further includes a first signature
  • the first signature is used to verify the first permission information.
  • the first signature is obtained based on the first authority information and a first key
  • the processor 1401 is configured to verify the first authority information according to the first signature and a third key, where the third key is a decryption key of the first key.
  • processor 1401 is further configured to:
  • Permission status is synchronized with the OEM server through communication interface 1402 .
  • the service authorization management apparatus 140 may be the first terminal in the embodiment shown in FIG. 8 , FIG. 9 or FIG. 10 , or a device in the first terminal, such as a chip or an integrated circuit, etc. .
  • the processor 1401 in the service authorization management device 140 is configured to read the computer program stored in the memory 1404, to perform the following operations:
  • the target service provided by the OEM server is received through the communication interface 1402 .
  • a first secure channel is established between the service authorization management device and the OEM server, and the second message and/or the third message is sent through the first secure channel transmission, the first secure channel includes at least one of a TLS secure channel, a DTLS secure channel, or an HTTPs secure channel.
  • processor 1401 is further configured to:
  • the second message further includes a first signature
  • the first signature is used to verify the first permission information.
  • the first signature is obtained based on the first authority information and a first key
  • the processor 1401 is configured to verify the first authority information according to the first signature and a third key, where the third key is a decryption key of the first key.
  • processor 1401 is further configured to:
  • Permission status is synchronized with the OEM server through communication interface 1402 .
  • the service authorization management apparatus 140 may be the resource server in the embodiment shown in FIG. 5 , FIG. 6 or FIG. 7 , or a device in the resource server, such as a chip or an integrated circuit.
  • the processor 1401 in the service authorization management device 140 is configured to read the computer program stored in the memory 1404, to perform the following operations:
  • a fourth message sent by the first terminal is received through the communication interface 1402, where the fourth message includes the identification information and first permission information of the first terminal, the first terminal is a terminal that needs to use the target service, and the first terminal Permission information is used to indicate that the first terminal has the permission to use the target service, and the first permission information is determined by the OEM server;
  • the target service is provided to the first terminal through the communication interface 1402 .
  • the fourth message further includes indication information of the target service.
  • the above-mentioned indication information of the target service may also be included in the first permission information.
  • the processor 1401 is further configured to:
  • the first authority information is checked according to the second authority information through the communication interface 1402 .
  • the processor 1401 is further configured to:
  • the sixth key is the decryption key of the second key.
  • the service authorization management apparatus 140 may be the resource server in the embodiment shown in FIG. 11 , or a device in the resource server, such as a chip or an integrated circuit.
  • the processor 1401 in the service authorization management device 140 is configured to read the computer program stored in the memory 1404, to perform the following operations:
  • the seventh message includes first indication information, where the first indication information is used to indicate that the first terminal has the right to use the target service;
  • the target service is provided to the first terminal through the communication interface 1402 .
  • the sixth message includes identification information of the first terminal and/or identification information of the target service.
  • the seventh message further includes a third signature, where the third signature is used to verify the first indication information.
  • the third signature is obtained based on the first indication information and the fourth key; the processor 1401 is further configured to:
  • the first indication information is verified by the third signature and a fifth key, where the fifth key is a decryption key of the fourth key.
  • the service authorization management apparatus 140 may be the OEM server in the embodiment shown in FIG. 11 , or a device in the OEM server, such as a chip or an integrated circuit.
  • the processor 1401 in the service authorization management device 140 is configured to read the computer program stored in the memory 1404, to perform the following operations:
  • a seventh message is sent to the resource server through the communication interface 1402, where the seventh message includes first indication information, and the first indication information is used for whether the first terminal has the right to use the target service.
  • the sixth message includes identification information of the first terminal and/or identification information of the target service.
  • the seventh message further includes a third signature; the processor 1401 is further configured to:
  • the third signature is obtained according to the first indication information and a fourth key, where the fourth key is a third private key or a shared key between the OEM server and the resource server.
  • the service authorization management apparatus 140 may be the first terminal in the embodiment shown in FIG. 11 , or a device in the first terminal, such as a chip or an integrated circuit.
  • the processor 1401 in the service authorization management device 140 is configured to read the computer program stored in the memory 1404, to perform the following operations:
  • the target service provided by the resource server is received through the communication interface 1402 .
  • the fifth message further includes identification information of the first terminal.
  • the above-mentioned indication information of the target service may also be included in the first permission information.
  • An embodiment of the present application further provides a chip system, where the chip system includes at least one processor and a communication interface, where the communication interface is used for sending and/or receiving data, and the at least one processor is used for calling at least one memory A stored computer program, so that the device where the chip system is located implements the OEM server side, the resource server side or the first embodiment shown in FIG. 5, FIG. 6, FIG. 7, FIG. 8, FIG. 9, FIG. A terminal-side method.
  • the at least one processor can be a combination of one or more of processing modules such as CPU, GPU, MPU, ASIC, FPGA, CPLD, co-processor (to assist the central processing unit to complete corresponding processing and application), MCU, etc. .
  • processing modules such as CPU, GPU, MPU, ASIC, FPGA, CPLD, co-processor (to assist the central processing unit to complete corresponding processing and application), MCU, etc. .
  • Embodiments of the present application further provide a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium.
  • FIG. 5 and FIG. 6 are implemented. , FIG. 7 , FIG. 8 , FIG. 9 , FIG. 10 or the method described in the embodiment shown in FIG. 11 .
  • Embodiments of the present application further provide a computer program product, which, when the computer program product runs on one or more processors, implements FIG. 5 , FIG. 6 , FIG. 7 , FIG. 8 , FIG. 9 , FIG. 10 or FIG. The method described in the embodiment shown in 11.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted over a computer-readable storage medium.
  • the computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc., that includes one or more available media integrated.
  • Useful media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVDs), or semiconductor media (eg, solid state disks (SSDs)), among others.
  • the modules in the device embodiments of the present application may be combined, divided, and deleted according to actual needs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请实施例提供一种服务授权管理方法及装置，应用于通信技术、车联网领域，该方法包括：OEM服务器接收第一消息，第一消息包含第一车辆的标识信息，第一车辆为需要使用目标服务的终端；OEM服务器根据第一车辆的标识信息确定第一权限信息，其中，第一权限信息用于指示第一车辆具有使用目标服务的权限；OEM服务器向第一车辆发送第二消息，第二消息包含第一权限信息。本申请实施例可以提高服务提供的效率，提升用户使用服务的体验。

Description

一种服务授权管理方法及装置 技术领域
本申请涉及车联网、通信技术领域，尤其涉及一种服务授权管理方法及装置。
背景技术
随着计算机技术、网络技术等发展，终端的数量越来越多，人们对于终端的智能化要求、安全要求等也越来越高，终端越来越智能化和多媒体化。当前的终端中需要各种各样的服务，例如，手机中需要视频观看服务、音乐播放服务、文本阅读服务、导航服务等等，这些服务通常由服务提供商通过资源服务器来提供。例如，视频服务提供商可以支持用户上传视频、观看其它用户的上传的视频等服务。
由于服务提供商所提供的服务可能是付费的，或所提供的服务中包含隐私数据等等原因，终端要从资源服务器上获取服务时，往往需要先获得权限，如访问资源服务器的权限、获取服务的权限等。
随着优质的服务越来越多、涉及个人隐私的服务越来越多，对终端进行授权显得尤为重要。大多数服务提供商都单独配置有授权服务器，授权服务器用于进行权限认证和授权控制。但是，设置授权服务器后，终端(客户端)获取到服务器的过程变得更加繁琐，获取服务的效率受到影响，尤其在对安全性需求较高的终端中，如车辆、机器人等。例如，以车辆为例，车辆在访问授权服务器时，需要对与授权服务器之间的通信进行安全控制，而请求服务时，又需要对与授权服务器之间的通信进行安全控制，获取服务的过程复杂，影响了服务提供的效率，使得用户使用服务的体验较差。
因此，如何提高服务提供的效率是本领域技术人员亟待解决的技术问题。
发明内容
本申请实施例公开了一种服务授权管理方法及装置，提高服务提供的效率，提升服务使用的安全性。
第一方面，本申请实施例公开了一种服务授权管理方法，包括：
原始设备制造商OEM服务器接收第一消息，所述第一消息包含第一终端的标识信息，所述第一终端为需要使用目标服务的终端；
所述OEM服务器根据所述第一终端的标识信息确定第一权限信息，其中，所述第一权限信息用于指示所述第一终端具有使用所述目标服务的权限；
所述OEM服务器向所述第一终端发送第二消息，所述第二消息包含所述第一权限信息。
可选的，第一终端可以为车辆、机器人、无人机等等智能设备或运输工具。原始设备制造商(Original Equipment Manufacturer，OEM，或称为原厂商)服务器是终端的生产商所对应的服务器。OEM服务器中可以存储有多个终端(包含第一终端)对应的信息，OEM服务器中支持与终端进行通信连接，且OEM服务器对于终端来说相比其他服务器较为可 信。
本申请实施例中，OEM服务器获取到第一终端需要使用目标服务时，可以为对服务授权过程进行管理，完成权限确定、下发权限信息等功能，后续第一终端使用OEM服务器下发的权限信息访问服务，提高服务提供的效率，提升用户使用服务的体验，提高了服务使用的安全性。
考虑一种可能的情况：第一终端通过访问资源提供商所对应的授权服务器来获取授权，若授权服务器被劫持或授权服务器与第一终端之间的通信被劫持，则可能使第一终端受到攻击，从而影响第一终端的安全性。若该第一终端为第一车辆，第一车辆受到攻击可能会对司机或乘客的人身安全造成威胁。
本申请实施例中，一方面，由于OEM服务器对于第一车辆来说是较为可信的设备，第一车辆与OEM服务器之间的通信连接更为可靠(例如OEM服务器中可以预先与第一车辆之间配置有密钥，但是授权服务器则需要先与第一车辆协商得到密钥)，因此使用OEM服务器进行权限管理可以减少建立通信连接过程中的交互流程，从而提高服务授权的效率。
另一方面，由于OEM服务器往往具有较高的安全性，通过OEM服务器来管理服务授权，可以提高授权过程中的安全性。
此外，通过OEM服务器来进行授权管理，对于服务提供商来说还可以在提供服务器时无需额外配置授权服务器，节省了服务提供商提供服务的成本。
结合第一方面，在一种可能的实现方式中，所述OEM服务器包含空中下载OTA任务管理模块，所述方法应用于所述OTA任务管理模块。
进一步的，所述OEM服务器还可以包含OTA权限管理模块，所述OTA权限管理模块用于生成权限信息。
其中，OTA任务管理模块是支持与第一终端基于OTA技术进行通信的模块。一般来说，第一终端(例如第一车辆)中也会对应配置有OTA相关的模块，例如：OTA主模块(OTAmaster)、OTA组控制器等。OEM服务器通过OTA任务管理模块与第一终端进行通信，可以减少通过其他通信技术建立连接的流程，且可以提高安全性。
结合第一方面，在一种可能的实现方式中，所述第一消息还包含所述目标服务的指示信息。
上述说明的一种可能的第一消息的内容，第一消息中可以包含对于目标服务的指示信息。该目标服务的指示信息可以指示需要哪一项或哪几项服务的授权。相应的，OEM服务器对应的确定第一终端是否具有使用目标服务的指示信息。
应理解，第一消息也可以包含多条消息。例如但不限于，包含消息A和消息B，其中消息A中包含第一终端的标识信息，消息B中包含目标服务指示信息。
当然，第一消息中也可以不包含目标服务的指示信息。可选的，在这种情况下，OEM服务器可以将第一终端所具有的权限均生成权限信息，该权限信息可以指示第一终端所具有至少一种权限。
结合第一方面，在一种可能的实现方式中，所述第二消息还包括第一签名，所述第一签名用于校验所述第一权限信息。
结合第一方面，在一种可能的实现方式中，所述OEM服务器向所述第一终端发送第 二消息之前，所述方法还包括：
所述OEM服务器根据所述第一权限信息和第一密钥得到所述第一签名，所述第一密钥为第一私钥或为所述OEM服务器与所述第一终端之间的共享密钥。
可以看出，OEM服务器可以对第一权限信息进行签名，将第一签名携带在第二消息中发送给第一终端。第一终端获取第一权限信息后，可以根据第一签名校验第一权限信息。由于只有OEM服务器的第一公钥或与OEM的共享密钥可以解开第一签名，从而保证了第一终端获取的第一权限信息来源于OEM服务器且未被篡改，保证了服务授权过程中的安全性。
结合第一方面，在一种可能的实现方式中，所述目标服务由资源服务器提供，所述第一权限信息用于所述第一终端从所述资源服务器请求所述目标服务。
结合第一方面，在一种可能的实现方式中，所述方法还包括：
所述OEM服务器向所述资源服务器发送第二权限信息，所述第二权限信息用于指示所述第一终端具有使用所述目标服务的权限。
在上述实现方式中，资源服务器也获取了对应的权限信息，便于设备之间的状态同步。此外，资源服务器还可以在接收到来自第一终端的使用目标服务的请求时，使用第二权限信息校验第一终端的权限，便于向具有权限的终端提供服务，提高了服务提供过程中的安全性。
应理解，OEM服务器发送给第一终端的权限信息与OEM服务器发送给资源服务器的权限信息的内容可能不同。例如：OEM服务器发送给第一终端的权限信息可以为令牌，OEM服务器发送给第一终端的权限信息可以为权限列表，这种情况下，上述令牌与上述权限列表可以用于指示第一终端具有使用目标服务的权限。
结合第一方面，在一种可能的实现方式中，所述方法还包括：
所述OEM服务器向所述资源服务器发送第二签名，所述第二签名为所述OEM服务器根据所述第二权限信息和第二密钥得到的，所述第二密钥为第二私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
可以看出，OEM服务器可以对第二权限信息进行签名。资源服务器获取第二权限信息及第二签名后，可以根据第二签名校验第二权限信息。由于只有通过OEM服务器的第二公钥或与OEM的共享密钥可以解开第二签名，从而保证了资源服务器获取的第二权限信息来源于OEM服务器且未被篡改，保证了服务提供过程中的安全性。
结合第一方面，在一种可能的实现方式中，所述目标服务由所述OEM服务器提供；所述OEM服务器根据所述第一终端的标识信息确定第一权限信息之后，所述方法还包括：
所述OEM服务器向所述第一终端提供所述目标服务。
可以看出，OEM服务器既完成确定权限、下发权限的功能，也完成提供服务的功能。在这种情况下，用户只需要向OEM服务器订阅服务，则第一终端可以接收OEM服务器提供服务，而不需要额外向资源服务器请求服务，减少了交互的流程，进一步提高了服务发放的效率。
结合第一方面，在一种可能的实现方式中，所述OEM服务器向所述第一终端发送第二消息之后，所述OEM服务器向所述第一终端提供所述目标服务之前，还包括：
所述OEM服务器接收来自所述第一终端的第三消息，所述第三消息包含第三权限信息；
所述OEM服务器根据所述第一权限信息校验所述第三权限信息。
可以看出，OEM服务器既完成确定权限、下发权限的功能，也完成提供服务的功能。在提供服务时，OEM可以在接收来自终端第三消息，检验第一权限信息通过后向第一终端提供目标服务。从而可以使得第一终端可以根据自身的需求，在需要目标服务向OEM服务器发送第三消息以请求其提供目标服务，提升了用户的使用体验。
结合第一方面，在一种可能的实现方式中，所述OEM服务器向所述第一终端发送第二消息之后，所述方法还包括：
所述OEM服务器接收所述第一终端同步的权限状态。
例如，第一权限信息中指示第一终端使用目标服务的有效期为20小时，则第一终端开始使用目标服务或使用目标服务后，向OEM服务器同步权限的有效期。
在上述实现方式中，第一终端将权限的状态同步给OEM服务器，便于OEM及时获取权限状态的变更，利于维持数据的一致性，提高了系统稳定性。
第二方面，本申请实施例公开了一种服务授权管理方法，包括：
第一终端接收来自OEM服务器的第二消息，所述第二消息包含第一权限信息，所述第一权限信息用于指示所述第一终端具有使用目标服务的权限；
所述第一终端校验所述第一权限信息；
所述第一终端向资源服务器发送第四消息，所述第四消息包含所述第一权限信息和所述第一终端的标识信息；
所述第一终端接收所述资源服务器提供的所述目标服务。
结合第二方面，在一种可能的实现方式中，所述第一终端包含空中下载OTA模块，所述方法应用于所述OTA模块。
其中，OTA模块(例如：OTA主模块(OTAmaster)、OTA组控制器等)是支持与OEM服务器基于OTA技术进行通信的模块。一般来说，OEM服务器也会对应配置有OTA相关的模块。第一终端通过OTA模块与OEM服务器进行通信，可以减少通过其他通信技术建立连接的流程，且可以提高通信安全性。
结合第二方面，在一种可能的实现方式中，所述第一终端与所述OEM服务器之间建立有第一安全通道，所述第二消息通过所述第一安全通道进行传输，所述第一安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
结合第二方面，在一种可能的实现方式中，所述第一终端与所述资源服务器之间建立有第二安全通道，所述第四消息通过所述第二安全通道进行传输，所述第二安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
结合第二方面，在一种可能的实现方式中，所述第一终端接收来自OEM服务器的第二消息之前，所述方法还包括：
所述第一终端向所述OEM服务器发送第一消息，所述第一消息包含所述第一终端的标识信息，所述第一终端的标识信息用于所述OEM服务器确定所述第一权限信息。
结合第二方面，在一种可能的实现方式中，所述第二消息还包含第一签名，所述第一签名用于校验所述第一权限信息。
结合第二方面，在一种可能的实现方式中，所述第一签名为基于所述第一权限信息和第一密钥得到的；所述第一终端校验所述第一权限信息，包括：
所述第一终端根据所述第一签名和第三密钥校验所述第一权限信息，所述第三密钥为所述第一密钥的解密密钥。
结合第二方面，在一种可能的实现方式中，所述第一终端接收所述资源服务器提供的所述目标服务之后，所述方法还包括：
所述第一终端向所述OEM服务器同步权限状态。
本申请第二方面的技术方案与第一方面的技术方案部分一致，相关的有益效果可以参考第一方面的描述，此处不再赘述。
第三方面，本申请实施例公开了一种服务授权管理方法，包括：
第一终端接收来自OEM服务器的第二消息，所述第二消息包含第一权限信息，所述第一权限信息用于指示所述第一终端具有使用目标服务的权限；
所述第一终端校验所述第一权限信息；
所述第一终端向所述OEM服务器发送第三消息，所述第三消息包含所述第一权限信息；
所述第一终端接收所述OEM服务器提供的所述目标服务。
结合第三方面，在一种可能的实现方式中，所述第一终端与所述OEM服务器之间建立有第一安全通道，所述第二消息和/或所述第三消息通过所述第一安全通道进行传输，所述第一安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
结合第三方面，在一种可能的实现方式中，所述第一终端接收来自OEM服务器的第二消息之前，所述方法还包括：
所述第一终端向所述OEM服务器发送第一消息，所述第一消息包含所述第一终端的标识信息，所述第一终端的标识信息用于所述OEM服务器确定所述第一权限信息。
结合第三方面，在一种可能的实现方式中，所述第二消息还包含第一签名，所述第一签名用于校验所述第一权限信息。
结合第三方面，在一种可能的实现方式中，所述第一签名为基于所述第一权限信息和第一密钥得到的；所述第一终端校验所述第一权限信息，包括：
所述第一终端根据所述第一签名和第三密钥校验所述第一权限信息，所述第三密钥为所述第一密钥的解密密钥。
结合第三方面，在一种可能的实现方式中，所述第一终端接收所述资源服务器提供的所述目标服务之后，所述方法还包括：
所述第一终端向所述OEM服务器同步权限状态。
本申请第三方面的技术方案与第一方面的技术方案部分一致，相关的有益效果可以参考第一方面的描述，此处不再赘述。
第四方面，本申请实施例公开了一种服务授权管理方法，包括：
资源服务器接收第一终端发送的第四消息，所述第四消息包含所述第一终端的标识信息和第一权限信息，所述第一终端为需要使用目标服务的终端，所述第一权限信息用于指示所述第一终端具有使用所述目标服务的权限，所述第一权限信息为OEM服务器确定的；
所述资源服务器校验所述第一权限信息；
响应于校验所述第一权限信息，通过所述资源服务器向所述第一终端提供所述目标服务。
结合第四方面，在一种可能的实施方式中，所述第四消息中还包括目标服务的指示信息。
可选的，上述目标服务的指示信息还可以包含在第一权限信息中。
结合第四方面，在一种可能的实现方式中，所述资源服务器校验所述第一权限信息之前，所述方法还包括：
所述资源服务器接收来自OEM服务器的第二权限信息，所述第二权限信息用于指示所述第一终端具有使用所述目标服务的权限。
结合第四方面，在一种可能的实现方式中，所述资源服务器校验所述第一权限信息，包括:
所述资源服务器根据所述第二权限信息校验所述第一权限信息。
结合第四方面，在一种可能的实现方式中，所述资源服务器校验所述第一权限信息之前，所述方法还包括：
所述资源服务器接收来自OEM服务器的第二签名；所述第二签名为所述OEM服务器根据所述第二权限信息和第二密钥的得到的；
所述资源服务器根据第六密钥和所述第二签名确定所述第二权限信息校验通过，所述第六密钥为所述第二密钥的解密密钥。
结合第四方面，在一种可能的实现方式中，所述第一终端与所述资源服务器之间建立有第二安全通道，所述第一终端与所述资源服务器通过所述第二安全通道进行信息传输，所述第二安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
本申请第四方面的技术方案与第一方面的技术方案部分一致，相关的有益效果可以参考第一方面的描述，此处不再赘述。
第五方面，本申请实施例公开了一种服务授权管理方法，包括：
资源服务器接收所述第一终端发送的第五消息，所述第五消息包含所述第一终端的标识信息，所述第一终端为需要使用所述目标服务的终端；
所述资源服务器向OEM服务器发送第六消息，所述第六消息用于请求权限信息；
所述资源服务器接收来自所述OEM服务器的第七消息，所述第七消息包含第一指示信息，所述第一指示信息用于指示所述第一终端具有使用所述目标服务的权限；
所述资源服务器向所述第一终端提供所述目标服务。
在本申请实施例中，资源服务在提供服务时，由资源服务器向OEM服务器进行权限确定，可以减少第一终端的交互流程，降低服务授权过程中互相之间的通信控制的复杂度， 提高服务授权的效率。
进一步的，OEM服务器对于第一终端来说是相对安全的服务器，还可以提高授权服务过程中的安全性。此外，通过OEM服务器来进行授权管理，还可以节省部署授权服务器的成本。
结合第五方面，在一种可能的实现方式中，所述资源服务器包含OTA模块，所述方法应用于所述OTA模块。
其中，OTA是支持与第一终端基于OTA技术进行通信的模块。一般来说，车辆中也会对应配置有OTA相关的模块，例如：OTA主模块(OTAmaster)、OTA组控制器等所述资源服务器可以通过OTA模块与第一终端进行通信，可以减少通过其他通信技术建立连接的流程，且可以提高通信安全性。
结合第五方面，在一种可能的实施方式中，所述第六消息包含所述第一终端的标识信息和/或所述目标服务的标识信息。
结合第五方面，在一种可能的实施方式中，所述第五消息中还包含所述第一终端的标识信息。
可选的，上述目标服务的指示信息还可以包含在第一权限信息中。
结合第五方面，在一种可能的实施方式中，所述第七消息中还包括第三签名。
结合第五方面，在一种可能的实施方式中，所述第三签名为基于所述第一指示信息和第四密钥得到的；所述方法还包括：
所述资源服务器通过所述第三签名和第五密钥校验所述第一指示信息，所述第五密钥为所述第四密钥的解密密钥。
第六方面，本申请实施例公开了一种服务授权管理方法，包括：
OEM服务器接收资源服务器发送的第六消息，所述第六消息用于请求权限信息；
所述OEM服务器向所述资源服务器发送第七消息，所述第七消息包含第一指示信息，所述第一指示信息用于第一终端是否具有使用目标服务的权限。
结合第六方面，在一种可能的实施方式中，所述第六消息包含所述第一终端的标识信息和/或所述目标服务的标识信息。
结合第六方面，在一种可能的实施方式中，所述第七消息中还包括第三签名，所述第三签名用于校验所述第一指示信息。
结合第六方面，在一种可能的实施方式中，所述OEM服务器向所述资源服务器发送第七消息之前，所述方法还包括：
所述OEM服务器根据所述第一指示信息和第四密钥得到所述第三签名，所述第四密钥为第三私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
本申请第六方面的技术方案与第五方面的技术方案部分一致，相关的有益效果可以参考第一方面的描述，此处不再赘述。
第七方面，本申请实施例公开了一种服务授权管理方法，包括：
第一终端向资源服务器发送第五消息，所述第五消息包含第一权限信息和所述第一终 端的标识信息；
所述第一终端接收所述资源服务器提供的所述目标服务。
结合第七方面，在一种可能的实施方式中，所述第五消息中还包含所述第一终端的标识信息。
可选的，上述目标服务的指示信息还可以包含在第一权限信息中。
本申请第七方面的技术方案与第五方面的技术方案部分一致，相关的有益效果可以参考第一方面的描述，此处不再赘述。
第八方面，本申请实施例公开了一种服务授权管理装置，包括接收单元、处理单元和发送单元。所述服务授权管理装置用于实现第一方面或者第一方面的任意一种可能的实施方式所描述的方法。
第九方面，本申请实施例公开了一种服务授权管理装置，包括接收单元、处理单元和发送单元。所述服务授权管理装置用于实现第二方面或者第二方面的任意一种可能的实施方式所描述的方法。
第十方面，本申请实施例公开了一种服务授权管理装置，包括接收单元、处理单元和发送单元。所述服务授权管理装置用于实现第三方面或者第三方面的任意一种可能的实施方式所描述的方法。
第十一方面，本申请实施例公开了一种服务授权管理装置，包括接收单元、处理单元和发送单元。所述服务授权管理装置用于实现第四方面或者第四方面的任意一种可能的实施方式所描述的方法。
第十二方面，本申请实施例公开了一种服务授权管理装置，包括接收单元和发送单元。可选的还可以包含处理单元。所述服务授权管理装置用于实现第五方面或者第五方面的任意一种可能的实施方式所描述的方法。
第十三方面，本申请实施例公开了一种服务授权管理装置，包括接收单元和发送单元。可选的还可以包含处理单元。所述服务授权管理装置用于实现第六方面或者第六方面的任意一种可能的实施方式所描述的方法。
第十四方面，本申请实施例公开了一种服务授权管理装置，包括接收单元和发送单元。可选的还可以包含处理单元。所述服务授权管理装置用于实现第七方面或者第八方面的任意一种可能的实施方式所描述的方法。
上述第八方面至第十四方面中任一方面中的发送单元或接收单元也可以为收发器，用于发送和/或接收上述第八方面至第十四方面中任一方面中的数据；处理单元也可以为处理器，用于处理上述第八方面至第十四方面中任一方面中的数据。
第十五方面，本申请提供了一种芯片系统，该芯片系统包括至少一个处理器，用于支持实现上述第一方面至第七方面中的任一方面中所涉及的功能，例如，例如接收或处理上述方法中所涉及的数据和/或信息。
在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存程序指令和数据，存储器位于处理器之内或处理器之外。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
第十六方面，本申请实施例还提供一种服务授权管理装置，所述服务授权管理装置包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述服务授权管理装置实现如第一方面至第七方面中的任一方面或第一方面至第七方面中任意一种可能的实施方式所描述的方法。
第十七方面，本申请实施例还提供一种服务授权管理系统，该服务授权管理系统包括OEM服务器、第一终端和资源服务器。
其中，该OEM服务器用于实现上述第一方面或第一方面的又一种可能的实现方式所描述的方法，该第一终端用于实现上述第二方面或第二方面的一种可能的实现方式所描述的方法。进一步的，该资源服务器用于实现上述第四方面或第四方面的任意一种可能的实施方式所描述的方法。
第十八方面，本申请实施例还提供一种服务授权管理系统，该服务授权管理系统包括OEM服务器、第一终端和资源服务器。
其中，该OEM服务器包含上述第八方面或第八方面的任意一种可能的实施方式所描述的服务授权管理装置，该第一终端包含上述第九方面或第九方面的任意一种可能的实施方式所描述的服务授权管理装置。进一步的，该资源服务器包含上述第十一方面或第十一方面的任意一种可能的实施方式所描述的服务授权管理装置。
第十九方面，本申请还提供一种服务管理系统，该服务管理系统包含OEM服务器和第一终端，其中：
该OEM服务器用于实现上述第一方面或第一方面的又一种可能的实现方式所描述的方法，该第一终端用于实现上述第三方面或第三方面的一种可能的实现方式所描述的方法。
第二十方面，本申请还提供一种服务管理系统，该服务管理系统包含OEM服务器和第一终端，其中：
该OEM服务器包含上述第八方面或第八方面的任意一种可能的实施方式所描述的服务授权管理装置，该第一终端包含上述第十方面或第十方面的任意一种可能的实施方式所描述的服务授权管理装置。
第二十一方面，本申请实施例提供一种服务管理系统，该服务授权管理系统包括OEM服务器、第一终端和资源服务器。
其中，该OEM服务器用于实现包含上述第六方面或第六方面的任意一种可能的实施方式所描述的方法，该资源服务器包含上述第五方面或第五方面的任意一种可能的实施方式所描述的方法。进一步的，该第一终端用于实现上述第七方面或第七方面的任意一种可能的实施方式所描述的方法。
第二十二方面，本申请实施例提供一种服务管理系统，该服务授权管理系统包括OEM服务器、第一终端和资源服务器。
其中，该OEM服务器包含上述第十三方面或第十三方面的任意一种可能的实施方式所描述的服务授权管理装置，该资源服务器包含上述第十二方面或第十二方面的任意一种可能的实施方式所描述的服务授权管理装置。进一步的，该第一终端包含上述第十四方面 或第十四方面的任意一种可能的实施方式所描述的服务授权管理装置。
第二十三方面，本申请实施例公开了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在一个或多个处理器上运行时，实现第一方面至第七方面(或实现其任意一种可能的实施方式)所描述的方法。
第二十四方面，本申请实施例公开了一种计算机程序产品，当所述计算机程序产品在一个或多个处理器上运行时，实现第一方面至第七方面(或实现其任意一种可能的实施方式)所描述的方法。
应理解，本申请实施例装置侧的有益效果可以参考对应的方法侧，此处不再赘述。
附图说明
以下对本申请实施例用到的附图进行介绍。
图1是本申请示出的一种通信系统的架构示意图；
图2是本申请实施例提供的一种服务授权管理系统的架构示意图；
图3是本申请实施例提供的又一种服务授权管理系统的架构示意图；
图4是本申请实施例提供的再一种服务授权管理系统的架构示意图；
图5是本申请实施例提供的一种服务授权管理方法的流程示意图；
图6是本申请实施例提供的又一种服务授权管理方法的流程示意图；
图7是本申请实施例提供的再一种服务授权管理方法的流程示意图；
图8是本申请实施例提供的再一种服务授权管理方法的流程示意图；
图9是本申请实施例提供的再一种服务授权管理方法的流程示意图；
图10是本申请实施例提供的再一种服务授权管理方法的流程示意图；
图11是本申请实施例提供的再一种服务授权管理方法的流程示意图；
图12是本申请实施例提供的一种服务授权管理装置的结构示意图；
图13是本申请实施例提供的又一种服务授权管理装置的结构示意图；
图14是本申请实施例提供的再一种服务授权管理装置的结构示意图。
具体实施方式
下面结合本申请实施例中的附图对本申请实施例进行描述。需要说明的是，本申请中，“示例性的”或“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或“例如”等词旨在以具体方式呈现相关概念。
本申请中实施例提到的“至少一个”是指一个或多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a、b、或c中的至少一项(个)，可以表示：a、b、c、(a和b)、(a和c)、(b和c)、或(a和b和c)，其中a、b、c可以是单个，也可以是多个。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A、同时存在A和B、单独存在B这三种情况，其中A、B可以是单数或复数。字 符“/”一般表示前后关联对象是一种“或”的关系。
以及，除非有相反的说明，本申请实施例使用“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的顺序、时序、优先级或重要程度。例如，第一消息和第二消息，只是为了区分不同的消息类型，而并不是表示这两种消息的结构、重要程度等不同。
下面先对本申请实施例中涉及专业技术用语进行解释。
一、OTA技术
空中下载技术(Over the Air，OΤΑ)是一种通过无线网络进行数据下载的技术，现已被广泛应用于车辆、智能家居(电视、网关、冰箱等)、移动终端(手机、平板电脑等)、机顶盒等设备的升级。OTA技术主要通过下载OTA升级包进行自动升级(也支持通过拷贝OTA升级包到SD卡来升级)，OTA升级速度快、对数据的影响小，因此OTA升级成为了终端功能升级的主要方式。例如，对于车辆来说，车辆厂商(Original Equipment Manufacturer，OEM，或称为原始设备制造商)通过OTA技术升级车辆的相关硬件或软件，有利于厂商减少召回成本、快速响应需求、提升用户体验。
其中，OEM服务器是负责管理OTA升级过程的服务器(即OEM服务器，也称为OEM云端)，终端(车辆、电视、手机、平板电脑、机顶盒等设备)中配置有OTA模块(或称为OTA升级控制部件)，该OTA模块可以与OEM服务器进行信息传输，完成对终端上的零部件(既包括软件也包括硬件，还可以是整车)的升级。
本申请例举一种可能的情况：终端的OTA模块可以包括OTA主模块(Master)和OTA从模块(slave)，OTA主模块可以从OEM服务器获取信息，OTA主模块还可以与车内的一个或多个OTA从模块进行通信。请参见图1，图1是本申请例举的一种可能的通信系统的架构示意图，包括OEM云端101(也可以称为服务器)和车辆102。例如但不限于，车辆102是基于车辆电子电气(Electrical/Electronic Architecture，E/E)架构的车辆，参见区域103，车辆102可以包括以下部件中的至少一个：移动数据中心(Mobile Data Center，MDC)、人机交互(Human–Machine Interaction，HMI)、网关(gateway，GW)、汽车盒子(Telematics BOX，Tbox或称为TCU)、电子控制单元(Electronic Control Unit，ECU)等。其中，GW是整车的核心部件，其作为整车网络的数据交互枢纽，可将控制区域网络(Controller Area Network，CAN)、局域互联网络(Local Interconnect Network，LIN)、多媒体数据传输(Media Oriented System Transport，MOST)、FlexRay等网络数据在不同网络中进行路由。MDC是车辆的智能车载计算平台。T-BOX主要用于和车辆外部、后台系统和手机应用(application，APP)通信。HMI是车辆的信息输入、娱乐、交互系统。ECU是车辆内的控制器。
例如但不限于，在车辆102的GW中部署有升级主模块(update master，可以看作是OTA master)，车辆102的多个零部件中部署有升级从模块(update slave，可以看作是OTA slave)，GW中的升级主模块可以与其他零部件内的升级从模块进行通信，也可以与OEM服务器101进行通信。OTA主模块还可以部署在车辆的其它部件中，也可以为独立于其它部件之外的独立模块，本申请实施例对此不作限定。
由于OEM服务器101通常为终端的主机厂、整车厂等生产商提供，因此终端与其OEM 服务器之间的数据传输是相对安全的。
二、散列算法
散列算法又称为哈希(hash)函数或哈希算法。例如但不限于，散列算法可以将一段数据(例如字符串、数字、文件等)输出为一段预设长度(例如80位、或128位等等)的散列值(散列值也可以称为哈希值、摘要值等)，且很难找到逆向规律。常见的散列算法有安全散列算法(secure hash algorithm 1，SHA-1)、信息摘要(message digest，MD)算法(如MD2、MD4或MD5等)等。
三、签名与验签
签名的过程中通常会使用到公钥和私钥，公钥和私钥是一对互相加解密的密钥。其中，私钥私密存储，公钥对外公开。在使用时，使用公钥加密明文得到密文，使用私钥解密密文得到明文。或，使用私钥对原文进行签名，使用公钥和签名验证原文是否被篡改。
签名与验签的工作流程可以为(以双方分别为A节点和B节点为例)：A节点将原文进行hash，得到第一hash值；A节点用自己的私钥对第一hash值加密得到签名值，将原文、签名值发送给B节点；B节点用公钥将签名值进行解密，得到第二hash值；B节点将原文进行hash得到第三hash值，对比第二hash值与第三hash值则可以验证原文是否被篡改。
在使用过程中，为了确定公钥的来源，可以使用数字证书对公钥进行认证。其中，数字证书(也可以称为安全证书)是标志身份的一个数字认证，通常是由证书授权(Certificate Authority，CA)中心或受信任的第三方设备所颁发的一种较为权威与公正的证书。B节点可以通过公钥的数字证书确定公钥为B节点的公钥。
应理解，前述的关于算法以及签名过程的解释只是用于简单叙述实现的原理，并不限定使用时一定使用相同的参数进行实现。算法以及签名的具体实现过程中还可以有其他的改进和变体，本申请中提到算法可以为经过改进和变体后的算法。
另外需要说明的是，本申请各实施例中提到的“认证”、“校验”、“验证”，可以用于指示检查是否正确或合理、以及检查是否被篡改的意思。本申请各实施例中提到的“调用”，在一些具体的技术场景中，也可以描述为“使用”。
下面对本申请实施例的系统架构和业务场景进行描述。需要说明的是，本申请描述的系统架构及业务场景是为了更加清楚的说明本申请的技术方案，并不构成对于本申请提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本申请提供的技术方案对于类似的技术问题，同样适用。
近年来，随着计算机技术、网络技术等发展，终端中可以使用的服务的种类、数量越来越多。终端要从资源服务器上获取服务时，需要先获得权限，如访问资源服务器的权限、获取服务的权限等。
在一种可能的实施方式中，为了便于服务和权限管理进行解耦、提高服务使用的安全性，可以通过配置授权服务器来对权限进行管理。例如，授权服务器可以存储权限，如：哪个客户端对哪个资源服务器在什么条件下拥有哪些访问权限。在这种情况下，终端(具 体为终端中的客户端)使用服务可以包含如下的步骤：
步骤S1：客户端(client)向资源拥有者(resource owner)请求授权；
步骤S2：资源拥有者(resource owner)向客户端返回授权许可；
步骤S3：客户端向授权服务器(authorization server)发送授权请求；
步骤S4：授权服务器向客户端返回授权响应；授权响应可以为授权验证成功响应，也可以为授权验证失败响应，授权验证成功响应中携带用于表示验证结果的授权验证凭证，若授权响应为授权验证成功响应时，还要执行步骤S5。
步骤S5：客户端向资源拥有者发送服务请求；服务请求中携带授权验证凭证；
步骤S6：资源拥有者根据授权验证凭证向客户端返回资源访问响应。从而使得客户端可以基于该资源访问响应使用目标服务。
在又一种可能的实施方式中，可以通过OEM服务器对授权过程进行管理。
请参见图2，图2是本申请实施例提供的一种服务授权管理系统的架构示意图，包括OEM服务器201、第一终端202和资源服务器(server)203，其中：
OEM服务器201是具有数据处理能力的设备，可以是实体设备如主机、服务器等，也可以是虚拟设备如虚拟机、容器等。OEM服务器201能够通过OTA技术与终端进行信息传输，例如，OEM服务器可以部署有OTA交互模块、OTA权限管理模块、OTA任务管理模块等等OTA相关的模块中的至少一项。通过上述OTA相关的模块，OEM服务器可以与终端进行通信(例如发送权限信息、发送升级信息)。在一些具体的实施场景中，也将OEM服务器201称为OEM云端、OTA云端或OTA服务器。
OEM服务器201可以接收终端对目标服务的服务请求，该服务请求中包含第一终端202的标识信息，可选包含目标服务的指示信息。
可选的，该服务请求可以是第一终端202向OEM服务器201发送的。例如，车辆向OEM服务器201发送第一消息，该第一消息可以看作服务请求。再如，汽车内的导航软件(或者导航软件所在的部件，如HMI)需要进行地图更新服务，因此指示给车内的OTA主模块，OTA主模块向OEM服务器发送第一消息。可替换的，该服务请求也可以是其他终端向OEM服务器发送的。例如，车主在手机上订阅目标服务，手机则向OEM服务器发送第一消息。
OEM服务器201可以生成权限信息，生成的权限信息可以发送给第一终端202。该权限信息可以为令牌(Token)、许可证、授权书、权限列表等等中的一项或者多项，用于指示第一终端202具有使用目标服务的权限。
可选的，OEM服务器201也可以将权限信息发给资源服务器203。其中，OEM服务器发送201给第一终端202的权限信息与OEM服务器201发送给资源服务器203的权限信息的内容可能不同。例如：OEM服务器201发送给第一终端202的权限信息可以为令牌，OEM服务器201发送给第一终端202的权限信息可以为权限列表，这种情况下，上述令牌与上述权限列表可以用于指示第一终端202具有使用目标服务的权限。
第一终端202为需要请求使用目标服务的部件，目标服务可以为地图更新服务、导航系统更新服务、软件下载服务、自动驾驶服务、辅助驾驶服务等等服务中的一项或者多项。 第一终端202可以接收OEM服务器201下发的权限信息，通过权限信息向资源服务器203请求目标服务。
资源服务器203是具有数据处理能力的设备，可以是实体设备如主机、服务器等，也可以是虚拟设备如虚拟机、容器等。需要说明的是，此处为了便于描述称为服务器，具体实现过程中可以是服务器，也可以是其他具有数据处理能力的设备，或者是设备中的一个模块(例如芯片或集成电路)。资源服务器203为提供目标服务的服务器。可选的，资源服务器203为属于服务提供商(service provider)的服务器。例如，资源服务器203可以属于地图供应商的地图云服务器，可以提供地图下载、地图更新服务等等。
资源服务器203可以接收第一终端202请求调用目标服务的消息，消息中携带有第一终端202从OEM服务器201处获取的权限信息。若资源服务器203验证权限信息通过，则向第一终端202提供目标服务。
在图2所示的授权管理系统中，第一终端需要使用目标服务时，OEM服务器可以为对服务授权过程进行管理，完成权限确定、下发权限信息等功能，后续第一终端使用OEM服务器下发的权限信息可以从资源服务处获取服务，提高服务提供的效率，提升用户使用服务的体验，提高了服务使用的安全性。
考虑一种可能的情况：第一终端通过访问资源提供商所对应的授权服务器来获取授权，若授权服务器被劫持或授权服务器与第一终端之间的通信被劫持，则可能使第一终端受到攻击，从而影响第一终端的安全性。若该第一终端为第一车辆，第一车辆受到攻击可能会对司机或乘客的人身安全造成威胁。
而通过在图2所示的授权管理系统，一方面，由于OEM服务器对于第一终端来说是较为可信的设备，第一终端与OEM服务器之间的通信连接更为可靠(例如OEM服务器中可以预先与第一终端之间配置有密钥，但是授权服务器则需要先与第一终端协商得到密钥)，因此使用OEM服务器进行权限管理可以减少建立通信连接过程中的交互流程，从而提高服务授权的效率，进一步提高了第一终端获取服务的效率。
另一方面，由于OEM服务器往往具有较高的安全性，通过OEM服务器来管理服务授权，可以提高授权过程中的安全性。
此外，通过OEM服务器来进行授权管理，对于服务提供商来说还可以在提供服务器时无需额外配置授权服务器，节省了服务提供商提供服务的成本。
请参见图3，图3是本申请实施例提供的又一种服务授权管理系统的架构示意图，包括OEM服务器301、第一终端302和资源服务器(server)303，其中：
OEM服务器301的介绍可以参见前述OEM服务器201。OEM服务器301中可以获取终端具有的权限。可选的，OEM服务器301可以接收终端对目标服务的服务请求，该服务请求中包含第一终端302的标识信息，可选的，该服务请求还包含目标服务的指示信息。可替换的，该服务请求可以是第一终端302向OEM服务器301发的，也可以是其他终端向OEM服务器发送的。
进一步可选的，OEM服务器301可以基于服务请求生成第一终端302对应的权限信息。
第一终端302为需要使用目标服务的部件。第一终端可以向资源服务器303请求使用 目标服务。
资源服务器303的相关内容可以参考前述对资源服务器203的说明。资源服务器303可以接收终端(如第一终端302)请求使用目标服务的消息，资源服务器向OEM服务器301请求权限信息，根据OEM服务器301返回的第一指示信息确定终端是否具有使用目标服务权限。若终端具有使用目标服务权限，则向终端提供目标服务。
在图3所示的服务授权管理系统中，第一终端需要使用目标服务时，OEM服务器完成权限确定、返回权限信息等工作。由于OEM服务器可以获取权限信息，因此第一终端向资源服务器请求调用目标服务时，由资源服务器向OEM服务器进行权限确定，可以减少第一终端的交互流程，也可以减小服务授权过程中通信控制的复杂度，进而提高服务授权的效率。进一步的，OEM服务器对于第一终端来说是相对安全的服务器，还可以提高授权服务过程中的安全性。此外，通过OEM服务器来进行授权管理，还可以节省部署授权服务器的成本。
请参见图4，图4是本申请实施例提供的再一种服务授权管理系统的架构示意图，包括OEM服务器401和第一终端402，其中：
OEM服务器401能够通过OTA技术与第一终端402进行信息传输，例如，OEM服务器可以部署有OTA交互模块、OTA权限管理模块、OTA任务管理模块中的至少一项，通过OTA相关的模块，OEM服务器401可以与进行通信。
OEM服务器401中可以获取终端所具有的权限。进一步可选的，OEM服务器401可以生成第一终端402对应的权限信息。可选的，生成的权限信息可以下发给第一终端402。
OEM服务器401还可以提供多种服务，例如，OEM服务器401可以提供地图更新服务、导航系统更新服务、软件下载服务、自动驾驶服务、辅助驾驶服务等等服务中的一项或者多项。可选的，该OEM服务器401所提供的服务可以是服务提供商(Service provider)的部署在OEM服务器401上的。可替代的，也可以是OEM服务器401作为代理，经过OEM服务器401可以获取到服务提供商部署在其他服务器上的服务。
第一终端402为需要请求使用目标服务的终端。
在一种设计中，OEM服务器401接收对目标服务的服务请求，该服务请求中包含第一终端402的标识信息，可选包含目标服务的指示信息。若第一终端402具有使用目标服务的权限，则OEM服务器401向第一终端402提供目标服务。
在又一种可能的设计中，OEM服务器401接收对目标服务服务的服务器请求，该服务请求中包含第一终端402的标识信息，可选包含目标服务的指示信息。OEM服务器401为第一终端生成权限信息。可选的，第一终端402可以向OEM服务器401发送服务调用请求，该服务调用请求用于请求目标服务。进一步可选的，服务调用请求中包含权限信息。若第一终端402具有使用目标服务的权限，则OEM服务器401向第一终端402提供目标服务。
可替换的，图4所示的OEM服务器401也可以替换为资源服务器。进一步的，所述资源服务器内可以部署有OTA模块，所述资源服务器可以通过OTA模块与车辆中的OTA模块之间进行数据传输。
可以看出，图4所示的服务授权管理系统通过OEM服务器401完成权限确定、提供服务等工作。在这种情况下，用户只需要向OEM服务器订阅服务，则第一终端则可以接收OEM服务器提供的服务，而不需要额外向资源服务器请求服务，减少了交互的流程，提高了服务发放的效率，提升了用户体验。
进一步的，OEM服务器对于终端来说是相对安全的服务器，还可以提高授权服务过程中的安全性。此外，通过OEM服务器来进行授权管理，还可以节省部署授权服务器、资源服务器的成本。
下面对本申请实施例的方法进行详细说明。
请参见图5，图5是本申请实施例提供的基于OTA技术的服务授权管理方法的流程示意图。可选的，该方法可以基于图2或图4所示的架构来实现。该方法包括但不限于如下步骤：
步骤S501：OEM服务器接收第一消息。
具体的，OEM服务器的相关描述可以参看前述对OEM服务器201的描述。该OEM服务器可以是一个服务器，也可以是多个服务器组成的服务器集群，还可以是分布式的服务器。
可选地，第一消息包含第一终端的标识信息。第一终端为使用所述目标服务的终端，例如但不限于，第一终端可以为车辆、机器人、无人机等等智能设备或运输工具。第一终端的标识信息可以为第一终端中的客户端ID(Client ID)、第一终端中的部件(或模块)的ID、第一终端的ID、第一终端的MAC地址、域名、域地址或其他自定义的标识，部分实施情况下也称为第一终端的设备标识、身份标识等。例如，当第一终端为第一车辆时，第一车辆的标识信息可以为第一车辆的车辆识别号(Vehicle Identification Number，VIN)码、第一车辆中的部件(如HMI、MDC等等中的一项或者多项)的ID、第一终端中的中央处理器(central processing unit，CPU)序列号、第一车辆中的客户端(例如导航软件客户端、地图客户端等等中的一项或者多项)的ID。
可选的，当第一终端的标识信息为ID时，可以是永久ID(或称为真实ID、固定ID)，也可以是临时ID。
可选的，第一消息中还可以包含目标服务的指示信息。其中，目标服务可以是各种各样的服务，例如地图更新、软件下载、书籍订阅、音视频播放、应用购买、自动驾驶服务、服务驾驶服务等等服务中的一项或者多项。目标服务的指示信息可以为目标服务的名称(service name)、目标服务的ID等中的一项或多项。应理解，该目标服务的指示信息可以向OEM服务器指示第一终端需要哪一项或哪几项服务的授权。相应的，OEM服务器对应的确定第一终端是否具有使用目标服务的权限。
应理解，第一消息也可以包含多条消息。例如，第一消息包含消息A和消息B，其中消息A中包含第一终端的标识信息，消息B中包含目标服务指示信息。
当然，第一消息中也可以不包含目标服务的指示信息。在这种情况下，OEM服务器可以将第一终端所具有的至少一种权限生成权限信息，该权限信息可以指示第一终端所具有至少一种权限。可替代的，OEM服务器还可以通过其他方式获取第一终端需要哪一项或者 哪几项服务的授权。例如OEM服务器通过接收到地图供应商发送的地图更新消息，从而确定第一终端是否具有地图更新服务的权限。
可选的，第一消息中还可以包含订阅者(用户)的信息、订阅的目标服务的范围、类型、订阅的有效期等等信息。其中，订阅者的信息又可以包含订阅者的ID、订阅者的描述信息(如：联系方式、真实名称、位置)、订阅者所使用的设备的MAC地址等等信息中的至少一项。
可选的，该第一消息可以为第一终端发送给OEM服务器的，也可以是其他终端发送给OEM服务器的，还可以是第三方设备(例如网络侧设备)发送给OEM服务器的。例如，第一终端中的OTA相关模块可以通过OTA技术与OEM服务器进行通信，该第一终端可以通过OTA相关模块向OEM服务器发送第一消息，相应的，OEM服务器则接收第一终端发送的第一消息。又如，第一终端的用户可以在移动终端(例如手机、平板电脑)上为第一终端订阅目标服务，移动终端则向OEM服务器发送第一消息。再如，第一终端内的导航应用(或者导航软件所在的部件，如HMI)请求地图更新服务，因此导航应用将需求指示给第一终端内的OTA主模块，由OTA主模块向OEM服务器发送第一消息。
需要说明的是，第一消息也可以称为服务请求(或服务请求消息、服务请求信息)。本申请各个实施例中不对消息或信息的名称进行限定，仅对消息内容进行示例性的说明和表达，消息的名称可以进行任意地替换。
步骤S502：OEM服务器根据第一终端的标识信息确定第一权限信息。
具体的，第一权限信息用于指示所述第一终端具有使用所述目标服务的权限。例如，第一权限信息中包含第一终端的标识信息、目标服务的指示信息以及权限有效期，从而可以指示第一终端具有使用所述目标服务的权限。再如，第一权限信息包含第一终端的标识信息、使用目标服务的控制项信息，从而可以指示第一终端具有使用所述目标服务的权限。
可选的，权限信息可以为令牌(Token)、许可证(license)、权限列表、授权书等等中的一项或多项。其中，Token可以包括以下信息中的一项或多项：第一终端的标识信息(如：Client ID)、目标服务的指示信息(如：服务名称Service name)、有效期(Expiration time)、权限范围(Scope)等信息。License信息可以包含目标服务的指示信息、控制项信息(资源控制项和/或功能控制项)、有效期等等中的一项或多项，还可以包含设备特征码、软件生产厂商、签名、版本等等信息。其中，资源控制项用于指示目标服务(或者目标服务中的某一项功能)允许使用的客户端的数量；功能控制项用于说明目标服务允许使用的功能；设备特征码可以看作是第一终端的指示信息，例如第一终端的MAC地址、CPU序列号、硬盘序列号等等。
在一种可能的设计中，权限信息还可以包含订阅该目标服务的订阅者的信息，订阅者信息可以参见步骤S501中的说明。
可选的OEM服务器根据第一终端的标识信息确定第一权限信息，可以有以下几种示例性的设计：
设计一：OEM服务器中存储有多个终端标识信息及其对应的权限。OEM根据第一终端的标识信息可以查询第一终端的权限确定第一终端具有使用目标服务的权限，从而根据第一终端的标识信息以及目标服务的信息生成第一权限信息。
设计二：OEM服务器可以通过接口从存储设备或网络侧设备获取指示信息，该指示信息用于指示第一终端具有使用目标服务的权限。进一步的，OEM服务器响应于该指示信息，根据第一终端的标识信息生成第一权限信息。
例如，第一终端在OEM服务器上购买地图服务，在支付应用中支付对应的费用后，OEM服务器可以通过支付接口返回的支付成功结果确定第一终端具有使用地图服务的权限。进一步的，OEM服务器根据第一终端的标识信息生成第一权限信息。
设计三：OEM服务器可以根据第一终端的标识信息确定终端是否满足使用目标服务的条件，若满足使用目标服务的条件，则确定其具有使用目标服务的权限，从而根据第一终端的标识信息生成第一权限信息。例如，OEM中存储有黑名单，在黑名单中的终端则不具有使用目标服务的权限。若第一终端不在黑名单，则具有使用目标服务的权限，从而根据第一终端的标识信息生成第一权限信息。
当然，OEM服务器还可以通过其他方式确定第一权限信息，本申请不再一一例举。
步骤S503：OEM服务器向第一终端发送第二消息，第二消息中包含第一权限信息。
可选的，第一权限信息可以用于第一终端调用目标服务。本申请例举以下几种权限信息用于调用目标服务的示例：
示例1：目标服务由资源服务器提供。第一终端向资源服务器发送服务调用请求，在服务调用请求中携带第一权限信息。进一步的，资源服务器校验第一权限信息，从而可以向第一终端提供目标服务。
示例2：目标服务由OEM服务器提供。第一终端向OEM服务器发送服务调用请求，在服务调用请求中携带第一权限信息。进一步的，OEM服务器验证第一权限信息，从而可以向第一终端提供目标服务。
示例3：第一终端获取有经过加密的(或还未激活的)目标服务，第一终端通过第一权限信息可以解密(或激活)目标服务，从而可以正常使用该目标服务。可选的，在这种情况下，该目标服务可以是从资源服务器获取的，也可以是从OEM服务器获取的，还可以是通过其他方式(例如通过计算机存储介质拷贝)获取的。
可选的，第二消息中还可以携带第一签名，该第一签名用于校验第一权限信息。本申请例举一种可能的设计：第一签名为根据第一权限信息和第一密钥得到的。例如，第一签名S1满足如下式子：S1＝sign(hash(authorization)，K1)，其中，sign为签名算法，hash为哈希算法，authorization为第一权限信息，K1第一密钥。需要说明的，签名的过程中还可以涉及其他的参数(如：随机数、新鲜性参数)或其它运算，此处仅为示例性的说明基于第一权限信息和第一密钥可以得到第一签名。
可选的，第一密钥可以为第一私钥或为OEM服务器与第一终端的共享密钥。其中，第一私钥为一个公私钥对中的私钥。本申请例举一种可能的情况，OEM服务器确定第一公私钥对(包含第一公钥和第一私钥)，其中第一公钥对外公开(还可以通过CA等生成数字证书，对第一公钥进行认证)，第一私钥由OEM服务器私密存储(安全存储)。OEM服务器通过第一私钥对第一权限信息签名得到第一签名。OEM服务器在第二消息中携带第一权限信息和第一签名，可选携带第一公钥和数字证书。后续第一终端可以根据第一签名对第一权限信息进行校验。
OEM服务器与第一终端的共享密钥可以包括对称加密密钥、预共享密钥等等。OEM服务器使用共享密钥对第一权限信息进行签名，相应的第一终端可以使用共享密钥对签名进行验签从而校验第一权限信息。
可选的，第二消息也可以称为服务请求响应，或称为服务请求响应消息、服务请求响应信息等。
可选的，第一终端与OEM服务器之间可以建立安全通道(便于描述称为第一安全通道)，该第一消息和/或第二消息可以通过第一安全通道进行传输。在一种可能的设计中，第一终端可以与OEM服务器在发送第一消息之前建立第一安全通道，通过第一安全通道传输第一消息(或以及第二消息)。在又一种可能的设计中，第一终端可以与OEM服务器在发送第二消息之前建立第一安全通道，通过第一安全通道传输第二消息。
其中，第一安全通道可以是基于安全套接字(Secure Sockets Layer，SSL)协议或传输层安全(Transport Layer Security，TLS)协议的传输通道，用于数据安全传输。具体的，安全通道可以包括超文本传输安全协议(Secure Hypertext Transfer Protocol，HTTPs)安全通道、传输层安全协议TLS安全通道或数据包传输层安全协议(Datagram Transport Layer Security，DTLS)安全通道等等中的一个或多个。
进一步可选的，第一终端与OEM服务器建立第一安全通道时，可能需要执行相关安全配置，以便于安全的传输信息。例如，第一终端与OEM服务器可以通过证书确认对方的身份、确定进行加解密的公私钥对等等中的一项或多项。
应理解，OEM服务器向第一终端发送第二消息，相应的，第一终端则接收来自OEM服务器的第二消息。进一步的，第一终端可以基于第二消息中的第一签名校验第一权限信息。例如，该第一签名为基于第一权限信息和第一密钥得到的，第一终端可以通过第一签名和第三密钥校验第一权限信息，该第三密钥为第一密钥的解密密钥。例如，第一密钥可以为OEM服务器确定的第一私钥，此时第三密钥可以为第一公钥，所述第一公钥和第一私钥为一个密钥对，可以互相加解密。
可选的，第一终端还可以验证权限信息的合法性。例如，第一终端验证权限信息中的第一终端的标识信息是否与自身的标识信息一致，从而验证权限信息是否合法。再如，该目标服务为订阅者(用户)订阅的，该权限信息中包含订阅者的信息，第一终端可以验证订阅者的信息是否与第一终端的用户一致，从而验证权限信息是否合法。
在图5所示的实施例中，通过OEM服务器完成权限确定、下发权限信息等工作。由于OEM服务器本身支持与第一终端进行通信，因此使用OTA服务器进行授权管理，可以减小服务授权过程中通信控制的复杂度，提高服务授权的效率。进一步的，OEM服务器对于车辆来说是相对安全的服务器，还可以提高服务授权过程中的安全性。此外，通过OEM服务器来进行授权管理，还可以节省部署授权服务器的成本。
在一种可能的设计中，图5所示的基于OTA技术的服务授权管理方法，还可以包括6所示的步骤601-步骤S604中的一个或多个步骤。可选的，图6所示的实施例可以基于图2所示的架构来实现。具体的，步骤601-步骤S604如下：
步骤S601：第一终端向资源服务器发送第四消息。其中，第四消息包含第一终端的标 识信息和第一权限信息。可选的，第四消息中还可以包含目标服务的指示信息，例如第一权限信息中可以包含目标服务的指示信息。
具体的，资源服务器是具有数据处理能力的设备，可以是实体设备如主机、服务器等，也可以是虚拟设备如虚拟机、容器等。需要说明的是，此处为了便于描述称为服务器，具体实现过程中可以是服务器，也可以是其他具有数据处理能力的设备。
资源服务器为提供目标服务的服务器。可选的，资源服务器为属于服务提供商(Service provider)的服务器。例如，资源服务器可以属于地图供应商的地图云服务器，可以提供地图下载、地图更新等等服务。
第一权限信息、第一终端的标识信息和目标服务的指示信息可以参考前述描述，此处不再赘述。在一种可能的设计中，第一权限信息中包含了第一终端的标识信息和目标服务的指示信息，在这种情况下，第四消息中也可以不包含第一终端的标识信息和/或目标服务的指示信息。
可选的，第四消息也可以称为服务调用请求，或服务使用请求、服务调用消息、服务调用信息等。
应理解，第一终端向资源服务器发送第四消息，相应的，资源服务器则接收来自第一终端的第四消息。
步骤S602：资源服务器校验第一权限信息。
具体的，第四消息中携带有第一权限信息，资源服务器可以校验第一权限信息。例如，校验第一权限信息是否有效、校验第一权限信息的正确性以及完整性等等中的一项或多项。
本申请例举以下几种资源服务器校验第一权限信息的实现方式：
实现方式一：OEM服务器确定第一权限信息后，向资源服务器发送第一权限信息(为了便与描述，将OEM服务器向资源服务器发送的第一权限信息称为第二权限信息)。资源服务器将第二权限信息与来自第一终端的第一权限信息进行比对，若第二权限信息与第一权限信息均说明第一终端具有使用目标服务的权限，则校验第一权限信息通过。进一步的，当第二权限信息与第一权限信息比对一致，则校验所述第一权限信息通过。
可选的，OEM服务器还向资源服务器发送第二签名，该第二签名为根据第二权限信息和第二密钥得到的。该第二签名用于资源服务器校验第二权限信息。例如，第二签名S2满足如下式子：S2＝sign(hash(authorization)，K2)，其中，sign为签名算法，hash为哈希算法，authorization为第一权限信息，K2第二密钥。需要说明的，签名的过程中还可以涉及其他的参数或其它运算，此处仅为示例性的说明根据第二权限信息和第二密钥可以得到第二签名。
进一步可选的，第二密钥可以为一个公私钥(包含第二私钥和第二公钥)对中的私钥，为了便于描述称为第二私钥，其中第二私钥与第二公钥互相解密。可选的，该第二签名与前述的第一签名可以是基于同一个私钥生成的(也即是说第一私钥和第二私钥可以是同一个私钥)。
应理解，后续资源服务器可以根据第二签名对第二权限信息进行校验。例如，资源服务器根据第二签名和第六密钥校验第二权限信息，其中第六密钥为第二密钥的解密密钥。例如，第二密钥为第二私钥，则第六密钥为第二公钥。在这种情况下，资源服务器可以根 据签名验证第二权限信息的正确性，避免攻击者向资源服务器发送虚假的权限信息，保证了服务授权过程的私密性，避免对服务提供商造成损失。
可替代的，第一密钥还可以是OEM服务器与资源服务器之间的共享密钥。其中，共享密钥可以包括对称加密密钥、预共享密钥等等。OEM服务器使用共享密钥对第二权限信息进行签名，相应的资源服务器可以使用共享密钥对签名进行验签从而校验第二权限信息。
实现方式二：第四消息中还包括第四签名和第一签名，该第四签名为第一终端基于第一签名和第四私钥得到的，其中第一签名为OEM基于第一私钥和第一权限信息得到的。第一服务器根据第四签名、第四公钥、第一签名、第一公钥校验第一权限信息。
具体的，第四私钥与第四公钥是第一终端确定或保存的一个公私钥对。第一终端接收来自OEM服务器的第一签名，第一终端可以根据第一签名和第四私钥得到第四签名。资源服务器可以根据第四公钥、第四签名校验第一签名，从而确定第一签名为第一终端发送给服务器的。进一步的，资源服务器再根据OEM的第一公钥和第一签名校验第一权限信息，若校验成功，则说明第一权限信息确实来自于OEM服务器，没有被篡改，从而保证了服务授权过程的私密性。
当然，OEM服务器还以使用其他方式校验第一权限信息，此处不再赘述。
若校验第一权限消息不通过，表明第一权限信息不正确或遭到了篡改，资源服务器可以不向第一终端提供服务，进一步的，资源服务器还可以向第一终端发送提醒消息，用于指示其不具有使用权限或权限消息错误。
步骤S603：响应于校验第一权限信息通过，资源服务器向第一终端提供目标服务。
具体的，校验第一权限信息通过，说明第一终端具有使用所述目标服务的权限。因此资源服务器向第一终端提供目标服务。
可选的，若校验第一权限信息通过，资源服务器可以向第一终端发送响应消息。该响应消息也可以称为服务调用请求响应。进一步的，该响应消息指示资源服务器同意向第一终端提供目标服务。在一些可能的实施情况中，该响应消息中还可以包含调用目标服务的应用程序接口(Application Programming Interface，API)，便于第一终端从通过该API使用目标服务。
可选的，第一终端与资源服务器之间可以建立安全通道(便于描述称为第二安全通道)，该第四消息(或以及响应消息)可以通过第二安全通道进行传输。其中，第二安全通道可以是基于SSL)协议或TLS协议的传输通道，用于数据安全传输。具体的，安全通道可以包括超文本传输安全协议HTTPs安全通道、传输层安全协议TLS安全通道或DTLS安全通道等等中的一个或多个。
进一步可选的，第一终端与资源服务器建立第二安全通道时，可能需要执行相关安全配置，以便于安全的传输信息。例如，第一终端与资源服务器可以通过证书确认对方的身份、确定进行加解密的公私钥对等等中的一项或多项。
在一种可能的设计中，第一终端接收资源服务器提供的目标服务，根据权限信息使用该目标服务。例如，在权限信息中的权限有效期内使用。再如，以权限信息为license为例，第一终端根据license控制项来使用目标服务。
可选的，图6所示的实施例还包括步骤S604，具体如下：
步骤S604：第一终端向OEM服务器同步权限状态。
具体的，第一终端可以将权限状态同步给OEM服务器，权限状态包括权限有效期、权限使用时长等信息中的一项或多项。第一终端将权限的状态同步给OEM服务器，便于OEM及时获取权限状态的变更，利于维持数据的一致性，提高了系统稳定性。
例如，第一终端的第一权限信息中指示第一终端使用目标服务的有效期为20小时，则第一终端开始使用目标服务或使用目标服务后，向OEM服务器同步权限的有效期。
在一种可能的情况中，上述图5以及图6所示的方法，可以是由OEM中的模块、第一终端中的某一零部件(模块)来完成的。
请参见图7，图7是本申请实施提供的一种基于OTA技术的服务授权管理方法的流程示意图，以地图更新为例说明第一终端获取服务的流程。可选的，图7所示的实施例可以基于图2所示的架构来实现。该方法至少包括如下步骤：
步骤S701：OEM服务器的交互模块获取手机或HMI订阅地图服务的信息。
具体的，OEM服务器的交互模块可以与其他设备进行通信。因此可以获取手机或HMI订阅地图服务的信息，例如订阅者的信息、第一终端的标识信息、地图服务的指示信息、订阅的有效期等等中的一项或多项。
需要说明的是，此处仅以手机或HMI作为示例，本申请并不限定订阅目标服务的终端，该终端可以为移动终端例如手机、平板电脑、笔记本电脑、机器人、智能家居设备等，也可以为交通工具例如车辆、轮船等。
在一些具体实现过程中，用户通过HMI或手机订阅地图服务，HMI或手机则向OEM服务器发送第一消息，该第一消息用于指示订阅地图服务的信息。相应的，OEM服务器解析第一消息，从而获取订阅地图服务的信息。
步骤S702：OEM服务器的交互模块生成使用地图服务的权限信息。
具体的，OEM服务器的交互模块根据订阅地图服务的信息生成第一终端使用地图服务的权限信息(例如License文件、Token、权限列表等中的一项或多项)。
可选的，在订阅地图服务的信息中包含订阅者的信息的情况下，OEM服务器可以根据订阅地图服务的信息生成订阅者(用户)和第一终端使用地图服务的权限信息。在这种情况下，地图使用的权限信息包括第一终端的标识信息和地图使用权限，还可以包括订阅者的信息、有效期等信息中的一项或多项。
可选的，OEM服务器在生成使用地图服务的权限信息之前，可以确定第一终端具有使用地图服务的权限。例如，OEM服务器接收订阅地图服务的信息后，校验支付状态、或检验其是否满足使用地图服务的条件等。若满足使用地图服务的条件或支付成功，则确定第一终端具有使用地图服务的权限。
进一步的，OEM服务器的交互模块将权限信息发送给OTA权限管理模块，后续由OTA的权限管理模块将权限信息发送给OTA任务管理模块。需要说明的是，图7所示的OEM服务器或第一终端内部的模块之间发送可以为通过总线传输，也可以为基于有限链路和无线链路等通信信道的传输。
可选的，步骤S702也可以由OEM服务器的OTA权限管理模块来完成。具体的，OEM 云的交互模块将用户订阅地图服务的信息发送给OTA权限管理模块，由OTA权限管理模块生成权限信息。OTA权限管理模块将权限信息发送给OTA任务管理模块。
步骤S703：OEM服务器的OTA任务管理模块对权限信息进行签名，得到第一签名。
具体的，第一签名为根据权限信息和第一密钥得到的。例如，第一签名S1满足如下式子：S1＝sign(hash(authorization)，K1)，详细描述可以参考步骤S503中的具体说明，此处不再赘述。
步骤S704：OEM服务器的OTA任务管理模块向第一终端的OTA主模块发送第二消息。
其中，第二消息中携带使用地图服务的权限信息和第一签名。可选的，OTA主模块也可以替换为地图OTA客户端。关于第二消息的其他信息可以参考步骤S503中的具体说明，此处不再赘述。
应理解，OEM服务器向第一终端的OTA主模块发送第二消息，相应的，第一终端的OTA主模块则接收来自第一终端的第二消息。
步骤S705：第一终端的OTA主模块根据第一签名校验权限信息。
具体的，第一终端可以根据第一签名和第一公钥校验权限信息。例如，第一终端的OTA主模块使用第一公钥解密第一签名，得到权限信息的hash值(称为hash1)，然后使用第一消息中的权限信息生成哈希值(称为hash2)。通过比对hash1和hash2则可以校验权限信息。
可选的，若校验权限信息成功(如对比hash1和hash2一致)，则OTA Master或地图OTA客户端将权限信息发送给权限管理模块。
步骤S706：第一终端的权限管理模块验证权限信息的合法性。
具体的，权限管理模块对权限信息合法性进行校验。例如：权限管理模块比较从第一终端收集到的订阅者(用户)的信息(例如权限管理模块可以通过HMI获取订阅者的信息)、第一终端的标识信息和权限信息中的订阅者(用户)的信息、第一终端的信息是否一致，从而验证权限信息是否合法。
可选的，若权限信息合法，则权限管理模块将权限信息发送给MDC。
步骤S707：第一终端的MDC向地图云发送地图更新请求。
具体的，MDC向地图云发送地图更新请求，携带权限信息、第一终端的标识信息。可选的，地图更新请求中还包括第一终端的型号、硬件信息、客户端的版本号等等中的一项或多项。
步骤S708：地图云校验权限信息。
可选的，可以参考步骤S602中的相关描述。
步骤S709：地图云的MDC向地图云发送地图更新响应。
具体的，地图云校验权限信息通过，则向MDC发送地图更新响应以更新地图。可选的，地图更新响应中可以包含地图更新的API。第一终端可以根据该API获取更新后的地图。
步骤S710：第一终端的MDC根据权限信息控制地图服务的使用。
具体的，MDC根据权限信息控制地图的使用。例如，如果权限信息是License，MDC 根据License控制项使用地图服务。
可选的，第一终端(具体可以为权限管理模块或MDC)将地图权限状态(例如，地图使用有效期信息)同步给OTA Master或地图OTA客户端。
可替代的，使用所述地图服务的也可以是地图OTA客户端或者车内的其他部件，此处仅为示例。例如，第一终端中的地图OTA客户端根据license中的资源控制项和/或权限控制项使用所述地图服务。
可选的，OTA Master或地图OTA客户端将地图权限状态同步给OTA权限管理模块和HMI。
在一种可能的设计中，图5所示的基于OTA技术的服务授权管理方法，还可以包括图8所示的步骤S801。该图8所示的实施例可以基于图4所示的架构来实现。具体的，步骤S801如下：
步骤S801：OEM服务器向所述第一终端提供所述目标服务。
具体的，在这种情况下，OEM服务器401既作为的生成权限信息的设备，也作为提供服务的设备。可选的，该OEM服务器401所提供的服务可以是服务提供商(Service provider)部署在OEM服务器上的。可替代的，也可以是OEM服务器401作为代理，经过OEM服务器401可以获取到服务提供商部署在其他服务器上的服务。
可选的，OEM服务器可以直接向第一终端发送该目标服务，也可以向第一终端提供使用该目标服务的AP(例如携带在响应消息中)。
进一步的，OEM服务器向第一终端提供所述目标服务，相应的，第一终端则可以使用所述目标服务。
可选的，第一终端可以根据权限信息来使用目标服务。例如，以目标服务为地图服务为例，车辆中的MDC(仅为示例，也可以为车辆中的其他车载部件或者车载模块)可以根据License控制项，来运行地图服务。
具体的，第一终端可以将权限状态同步给OEM服务器，例如同步权限信息的有效期等信息。
例如，第一终端的第一权限信息中指示第一终端使用目标服务的有效期为20小时，则第一终端开始使用目标服务或使用目标服务后，向OEM服务器同步权限的有效期。
在又一种可能的设计中，OEM服务器向所述第一终端提供所述目标服务，可以包含图9所示的步骤S901-步骤S904中的一个或多个步骤。具体的，步骤S901-步骤S904如下：
步骤S901：第一终端向OEM服务器发送第三消息。其中，第三消息包第一终端的标识信息和第一权限信息。可选的，为了便于描述，将OEM收到的来自第一终端的第一权限信息称为第三权限信息。
可选的，第三消息中还可以包含目标服务的指示信息。
其中，目标服务的指示信息、第一终端的标识信息和第一权限信息可以参考前述描述，此处不再赘述。在一种可能的设计中，第一权限信息中包含了第一终端的标识信息和目标服务的指示信息，在这种情况下，第三消息中也可以不包含第一终端的标识信息和/或目标 服务的指示信息。
可选的，第三消息也可以称为服务调用请求，或服务调用消息、服务调用信息等。应理解，第一终端向OEM服务器发送第三消息，相应的，OEM服务器则接收来自第一终端的第三消息。
步骤S902：OEM服务器根据第一权限信息校验第三权限信息。
具体的，第三消息包含第三权限信息，资源服务器为第一终端生成了第一权限信息，因此OEM可以根据第一权限信息校验第三权限信息。例如，校验第一权限信息是否有效、校验第一权限信息的正确性以及完整性等等中的一项或多项。
可选的，由于第一权限信息为OEM服务器确定的，因此OEM服务器中可以存储有第一权限信息。OEM服务器可以将自身存储的第一权限信息和来自第一终端的第三权限信息进行比对，从而校验来自第一终端的第一权限信息是否正确、完整。
可选的，若校验第三权限信息通过，则表明第一终端具有使用目标服务的权限，因此OEM服务器向第一终端提供目标服务器。若校验第三权限消息不通过，表明第三权限信息不正确或遭到了篡改，OEM服务器可以不向第一终端提供服务，进一步的，OEM服务器还可以向第一终端发送提醒消息，用于指示其不具有使用权限或权限消息错误。
步骤S903：OEM服务器向第一终端提供目标服务。
具体的，第一权限信息校验通过，则说明第一终端具有使用所述目标服务的权限。因此OEM服务器向第一终端提供目标服务。
可选的，若一权限信息校验第通过，则OEM服务器可以向第一终端发送响应消息。该响应消息也可以称为服务调用请求响应。可选的，该响应消息指示OEM服务器同意向第一终端提供目标服务。
可选的，第一终端与OEM服务器之间可以建立第一安全通道(便于描述称为第二安全通道)，该第三消息(或以及响应消息)可以通过第一安全通道进行传输。关于第一安全通道的描述可以参考图5所示实施例，此处不再赘述。
可选的，图9所示的实施例还包括步骤S904，具体如下：
步骤S904：第一终端向OEM服务器同步权限状态。具体可以参见步骤S604中的详细描述。
可选的，上述图8或图9所示的方法，可以是由OEM中的模块、第一终端中的某一零部件(模块)来完成的。
请参见图10，图10是本申请实施例提供的又一种可能的情况：
步骤S1001：OEM服务器的地图云服务模块获取手机或HMI订阅地图服务的信息。
具体的，OEM服务器是可以与第一终端基于OTA技术进行通信的设备。该OEM服务器既可以生成权限信息、也可以提供服务。因此该OEM服务器也看可以作为资源服务器(例如地图云)。
OEM服务器的地图云服务模块可以与其他设备进行通信。因此可以获取手机或HMI订阅地图服务的信息，例如订阅者的信息、第一终端的标识信息、地图服务的指示信息、订阅的有效期等等中的一项或多项。
具体情况还可以参考步骤S701中的相关描述。
步骤S1002：OEM服务器的权限管理模块生成使用地图服务的权限信息。
具体情况还可以参考步骤S702中的相关描述。
在一种可能的设计中，步骤S1002也可以由OEM服务器的地图云服务模块来完成。OEM云的交互模块将用户订阅地图服务的信息发送给OTA权限管理模块，由OTA权限管理模块生成权限信息。OTA权限管理模块将权限信息发送给OTA任务管理模块。
进一步的，OTA权限管理模块将权限信息发送给OTA任务管理模块后，可以在OTA任务管理模块中触发地图更新的任务，OTA任务管理模块可以向第一终端提供地图更新的服务。这样一来，后续第一终端则无需再向地图云发送服务调用请求，减少了交互流程。
应理解，该地图更新服务可以先向第一终端提供，但是第一终端使用地图更新服务时仍然需要相关的权限。例如，以该地图为高精地图为例，OTA任务管理模块可以向第一终端发送高精地图的数据包，但是使用该高精地图数据包需要第一终端提供相应的权限。
步骤S1003：OEM服务器的OTA任务管理模块对权限信息进行签名，得到第一签名。
具体情况还可以参考步骤S703中的相关描述。
步骤S1004：OEM服务器的OTA任务管理模块向第一终端的OTA主模块发送第二消息。
具体情况还可以参考步骤S704中的相关描述。
步骤S1005：第一终端的OTA主模块根据第一签名校验权限信息。
具体情况还可以参考步骤S705中的相关描述。
步骤S1006：第一终端的权限管理模块验证权限信息的合法性。
具体情况还可以参考步骤S706中的相关描述。
可选的，还包括步骤S1007：OEM服务器的OTA任务管理模块向第一终端提供地图服务。
可选的，如前述，该步骤S1007也可以在步骤S1002之后执行。
在一种可能的设计中，也可以是OEM的地图服务模块可以将地图服务通过OTA任务管理模块提供给第一终端。
步骤S1008：第一终端的MDC根据权限信息控制地图服务的使用。
具体的，MDC根据权限信息控制地图的使用。例如，以权限信息是License为例，MDC根据License控制项来使用地图服务。
可选的，第一终端(具体可以为权限管理模块或MDC)将地图权限状态(例如，地图使用有效期信息)同步给OTA Master或地图OTA客户端。
可选的，OTA Master或地图OTA客户端将地图权限状态同步给OTA权限管理模块和HMI。
请参见图11，图11是本申请实施例提供的再一种基于OTA技术的服务授权管理方法的流程示意图。可选的，该方法可以基于图3所示的架构来实现。该方法包括但不限于如下步骤：
步骤S1101：第一终端向资源服务器发送第五消息。其中，第五消息包含第一终端的 标识信息。可选的，第五消息中还包含有目标服务的指示信息。
具体地，第一终端为使用所述目标服务的终端。关于第一终端、目标服务的指示信息、第一终端的标识信息可以参考步骤S501中的相关描述。
资源服务器为提供目标服务的服务器。关于资源服务器可以参考步骤S501中的相关描述。
步骤S1102：资源服务器向OEM服务器发送第六消息。其中，第六消息用于请求授权信息。
具体地，OEM服务器可以确定至少一个终端对应的权限，因此资源服务器通过第六消息向OEM服务器请求授权信息。
可选的，OEM服务器的权限信息可以是OEM服务器基于订阅目标服务的消息生成的。例如，订阅者可以通过终端订阅目标服务，OEM服务器基于订阅目标服务的消息生成权限信息。
本申请例举一种可能的场景：用户通过HMI或手机订阅地图服务，HMI或手机则向OEM服务器发送订阅目标服务的消息。相应的，OEM服务器根据订阅目标服务的消息，生成使用地图服务的权限信息。
可选的，所述OEM服务器支持通过OTA技术与所述第一终端进行信息传输。
可选的，第六消息中可以包含第一终端的标识信息。
可选的，第六消息中还包括目标服务的指示信息。其中，目标服务的指示信息和第一终端的标识信息可以参考前述描述，此处不再赘述。
应理解，资源服务器向OEM服务器发送第六消息，相应的，OEM服务器则接收来自资源服务器的第六消息。
步骤S1103：OEM服务器向资源服务器发送第七消息。其中，第七消息中包含第一指示信息，所述第一指示信息用于指示第一终端是否具有使用所述目标服务的权限。
可选的，第一指示信息用于指示第一终端是否具有使用所述目标服务的权限，至少有以下几种示例性的实现方式：
实现方式一：第一指示信息包括第一字段(可以是预先配置的、或互相协商的、还可以协议规定的，不做限定)，该第一字段为第一预设值时表明第一终端具有使用目标服务的权限。可选的，该第一字段为第二预设值时表明第一终端不具有使用目标服务的权限。例如，该第一字段为“1”指示第一终端具有使用目标服务的权限，该第一字段为“0”指示第一终端不具有使用目标服务的权限。
实现方式二：第一指示信息为第一终端的权限信息或不具有权限的信息。若OEM服务器返回第一终端的权限信息，则指示第一终端具有使用所述目标服务的权限。若第一终端返回“false”“无权限”等信息，则指示第一终端不具有使用目标服务的权限。
可选的，所述第七消息中还包括第三签名，该第三签名用于校验第一指示信息。在一种可能的设计中，该第三签名为根据第一指示信息和第四密钥得到的。需要说明的，签名的过程中还可以涉及其他的参数(如：随机数、新鲜性参数)或其它运算。
其中，第四密钥为第三私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
应理解，OEM服务器向资源服务器发送第七消息，相应的，资源服务器则接收来自 OEM服务器的第七消息。
步骤S1104：响应于第一终端具有使用所述目标服务的权限，所述资源服务器向所述第一终端提供所述目标服务。
具体的，由于第一指示信息用于指示第一终端是否具有使用所述目标服务的权限，因此资源服务器可以根据第一指示信息确定第一终端是否具有使用所述目标服务的权限。
响应于第一终端具有使用所述目标服务的权限，资源服务器向所述第一终端提供所述目标服务。具体描述可以参见S603中的相关内容，此处不再赘述。
可选的，第七消息中还包括第三签名，该第三签名用于校验第一指示信息。进一步的，该第三签名为基于第一指示信息和第四密钥得到的，资源服务器可以通过第三签名和第五密钥校验所述第一指示信息，该第五密钥为所述第四密钥的解密密钥。例如，第四密钥可以为OEM服务器确定的第三私钥，此时第五密钥可以为第三公钥，所述第三公钥和第三私钥为一个密钥对，可以互相加解密。
可选的，第一终端可以根据权限信息来使用目标服务。例如，以目标服务为地图服务为例，车辆中的MDC可以根据License控制项，来运行地图服务。
具体的，第一终端可以将权限状态同步给OEM服务器，例如同步权限信息的有效期等信息。
例如，第一终端的第一权限信息中指示第一终端使用目标服务的有效期为20小时，则第一终端开始使用目标服务或使用目标服务后，向OEM服务器同步权限的有效期。
在图11所示的实施例中，通过OEM服务器完成权限确定、返回权限信息等工作。由于OEM服务器可以获取权限信息，因此第一终端向资源服务器请求调用目标服务时，由资源服务器向OEM服务器进行权限确定，可以减少第一终端的交互流程，可以减小服务授权过程中互相之间的通信控制的复杂度，提高服务授权的效率。进一步的，OEM服务器对于第一终端来说是相对安全的服务器，还可以提高授权服务过程中的安全性。此外，通过OEM服务器来进行授权管理，还可以节省部署授权服务器的成本。
在一种可能的情况中，该第一终端可以为智能汽车，该方案提供了智能汽车领域的服务授权管理的方案。智能汽车通过OEM服务器来进行服务授权管理，提高了用户通过智能汽车使用服务的安全性和舒适度。
上述详细阐述了本申请实施例的方法，下面提供了本申请实施例的装置。
请参见图12，图12是本申请实施例提供的一种服务授权管理装置120的结构示意图，该服务授权管理装置120可以包括接收单元1201、处理单元1202和发送单元1203。该服务授权装置120用于实现前述的服务授权管理方法，例如可以用于实现图5、图6、图7、图8、图9或图10所示的服务授权方法。
应理解，本申请各个装置实施例中，对多个单元或模块的划分仅是一种根据功能进行的逻辑划分，不作为对装置具体的结构的限定。在具体实现中，其中部分功能模块可能被细分为更多细小的功能模块，部分功能模块也可能组合成一个功能模块，但无论这些功能模块是进行了细分还是组合，在实现服务授权管理的过程中所执行的大致流程是相同的。例如，上述服务授权装置120中的接收单元1201、发送单元1203也可以合并为通信单元 或者合并为收发器，该通信单元或者收发器用于实现接收和发送数据的功能。通常，每个单元都对应有各自的程序代码(或说程序指令)，这些单元各自对应的程序代码在至少一个处理器上运行时，使得该单元执行相应的流程从而实现相应功能。
在一种可能的设计中，图12中所示的服务授权管理装置120可以为图5、图6、图7、图8、图9或图10所示实施例中的OEM服务器，或为OEM服务器中的一个器件，例如芯片或集成电路等。其中，图12中所示的服务授权管理装置120各个单元的详细描述如下：
接收单元1201，用于接收第一消息，所述第一消息包含第一终端的标识信息，所述第一终端为需要使用目标服务的终端；
处理单元1202，用于根据所述第一终端的标识信息确定第一权限信息，其中，所述第一权限信息用于指示所述第一终端具有使用所述目标服务的权限；
发送单元1203，用于向所述第一终端发送第二消息，第二消息包含所述第一权限信息。
在一种可能的实施方式中，服务授权管理装置还包含OTA任务管理模块(图中未示出)。进一步的，还可以包含OTA权限管理模块(图中未示出)，所述OTA权限管理模块用于生成权限信息。
在一种可能的实施方式中，所述第一消息还包含所述目标服务的指示信息。
在又一种可能的实施方式中，所述第二消息还包括第一签名，所述第一签名用于校验所述第一权限信息。
在又一种可能的实施方式中，所述处理单元1202，还用于根据所述第一权限信息和第一密钥得到所述第一签名，所述第一密钥为第一私钥或为原始设备制造商OEM服务器与所述第一终端之间的共享密钥。
在又一种可能的实施方式中，所述第一消息还包含所述目标服务的指示信息。
在又一种可能的实施方式中，所述目标服务由资源服务器提供，所述第一权限信息用于所述第一终端从所述资源服务器请求所述目标服务。
在又一种可能的实施方式中，所述发送单元1203，还用于向所述资源服务器发送第二权限信息，所述第二权限信息用于指示所述第一终端具有使用所述目标服务的权限。
在又一种可能的实施方式中，所述发送单元1203，还用于向所述资源服务器发送第二签名，所述第二签名为所述OEM服务器根据所述第二权限信息和第二密钥得到的，所述第二密钥为第二私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
在又一种可能的实施方式中，所述目标服务由原始设备制造商OEM服务器提供；
所述发送单元1203，还用于向所述第一终端提供所述目标服务。
在又一种可能的实施方式中，所述接收单元1201，还用于接收来自所述第一终端的第三消息，所述第三消息包含第三权限信息；
所述处理单元1202，还用于根据所述第一权限信息校验所述第三权限信息。
在又一种可能的实施方式中，所述接收单元1201，还用于接收所述第一终端同步的权限状态。
在又一种可能的实施方式中，所述服务授权管理装置与所述第一终端之间建立有第一安全通道，所述第二消息通过所述第一安全通道进行传输；
所述第一安全通道包括传输层安全协议TLS安全通道、数据包传输层安全协议DTLS安全通道或超文本传输安全协议HTTPs安全通道中的至少一项。
需要说明的是，各个单元的详细实现还可以参照图5、图6、图7、图8、图9或图10所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，图12中所示的服务授权管理装置120可以为图5、图6或图7所示实施例中的第一终端，或为第一终端中的一个器件，例如芯片或集成电路等。其中，图12中所示的服务授权管理装置120各个单元的详细描述如下：
接收单元1201，用于接收来自OEM服务器的第二消息，所述第二消息包含第一权限信息，所述第一权限信息用于指示所述第一终端具有使用目标服务的权限；
处理单元1202，用于校验所述第一权限信息；
发送单元1203，用于向资源服务器发送第四消息，所述第四消息包含所述第一权限信息和所述第一终端的标识信息；
所述接收单元1201，还用于接收所述资源服务器提供的所述目标服务。
在一种可能的实施方式中，所述服务授权管理装置120与所述OEM服务器之间建立有第一安全通道，所述第二消息通过所述第一安全通道进行传输，
所述第一安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
在又一种可能的实施方式中，所述第一终端与所述资源服务器之间建立有第二安全通道，所述第四消息通过所述第二安全通道进行传输，
所述第二安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
在又一种可能的实施方式中，所述发送单元1203，还用于：
向所述OEM服务器发送第一消息，所述第一消息包含所述第一终端的标识信息，所述第一终端的标识信息用于所述OEM服务器确定所述第一权限信息。
在又一种可能的实施方式中，所述第二消息还包含第一签名，所述第一签名用于校验所述第一权限信息。
在又一种可能的实施方式中，所述第一签名为基于所述第一权限信息和第一密钥得到的；
所述处理单元1202，用于根据所述第一签名和第三密钥校验所述第一权限信息，所述第三密钥为所述第一密钥的解密密钥。
在又一种可能的实施方式中，所述发送单元1203，还用于向所述OEM服务器同步权限状态。
需要说明的是，各个单元的详细实现还可以参照图5、图6或图7所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，图12中所示的服务授权管理装置120可以为图8、图9或图10所示实施例中的第一终端，或为第一终端中的一个器件，例如芯片或集成电路等。其中， 图12中所示的服务授权管理装置120各个单元的详细描述如下：
接收单元1201，用于接收来自OEM服务器的第二消息，所述第二消息包含第一权限信息，所述第一权限信息用于指示所述第一终端具有使用目标服务的权限；
处理单元1202，用于校验所述第一权限信息；
发送单元1203，用于向所述OEM服务器发送第三消息，所述第三消息包含所述第一权限信息；
所述接收单元1201，还用于接收所述OEM服务器提供的所述目标服务。
在一种可能的实施方式中，所述服务授权管理装置与所述OEM服务器之间建立有第一安全通道，所述第二消息和/或所述第三消息通过所述第一安全通道进行传输，所述第一安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
在又一种可能的实施方式中，所述发送单元1203，还用于：
向所述OEM服务器发送第一消息，所述第一消息包含所述第一终端的标识信息，所述第一终端的标识信息用于所述OEM服务器确定所述第一权限信息。
在又一种可能的实施方式中，所述第二消息还包含第一签名，所述第一签名用于校验所述第一权限信息。
在又一种可能的实施方式中，所述第一签名为基于所述第一权限信息和第一密钥得到的；
所述处理单元1202，用于根据所述第一签名和第三密钥校验所述第一权限信息，所述第三密钥为所述第一密钥的解密密钥。
在又一种可能的实施方式中，所述发送单元1203，还用于向所述OEM服务器同步权限状态。
需要说明的是，各个单元的详细实现还可以参照图8、图9或图10所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，图12中所示的服务授权管理装置120可以为图5、图6或图7所示实施例中的资源服务器，或为资源服务器中的一个器件，例如芯片或集成电路等。其中，图12中所示的服务授权管理装置120各个单元的详细描述如下：
接收单元1201，用于接收第一终端发送的第四消息，所述第四消息包含所述第一终端的标识信息和第一权限信息，所述第一终端为需要使用目标服务的终端，所述第一权限信息用于指示所述第一终端具有使用所述目标服务的权限，所述第一权限信息为OEM服务器确定的；
处理单元1202，用于校验所述第一权限信息；
发送单元1203，用于响应于校验所述第一权限信息通过，向所述第一终端提供所述目标服务。
在一种可能的实施方式中，所述第四消息中还包括目标服务的指示信息。
可选的，上述目标服务的指示信息还可以包含在第一权限信息中。
在一种可能的实现方式中，所述接收单元1201，还用于接收来自OEM服务器的第二权限信息，所述第二权限信息用于指示所述第一终端具有使用所述目标服务的权限。
在一种可能的实现方式中，所述处理单元1202，用于根据所述第二权限信息校验所述第一权限信息。
在一种可能的实现方式中，所述接收单元1201，还用于接收来自OEM服务器的第二签名；所述第二签名为所述OEM服务器根据所述第二权限信息和第二密钥的得到的；
所述处理单元，还用于根据第六密钥和所述第二签名确定所述第二权限信息校验通过，所述第六密钥为所述第二密钥的解密密钥。
在一种可能的实现方式中，所述第一终端与所述资源服务器之间建立有第二安全通道，所述第一终端与所述资源服务器通过所述第二安全通道进行信息传输，所述第二安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
需要说明的是，各个单元的详细实现还可以参照图5、图6或图7所示实施例中的详细说明，此处不再赘述。
请参见图13，图13是本申请实施例提供的一种服务授权管理装置130的结构示意图，该服务授权管理装置130可以包括接收单元1301和发送单元1302。可选的，还可以包括处理单元1303。该服务授权装置120用于实现前述的服务授权管理方法，例如可以用于实现图11所示的服务授权方法。
在一种可能的设计中，图13中所示的服务授权管理装置130可以为图11所示实施例中的资源服务器，或为资源服务器中的一个器件，例如芯片或集成电路等。其中，图13中所示的服务授权管理装置130各个单元的详细描述如下：
接收单元1301，用于接收所述第一终端发送第五消息，所述第五消息包含所述第一终端的标识信息，所述第一终端为需要使用所述目标服务的终端；
发送单元1302，用于向OEM服务器发送第六消息，所述第六消息用于请求权限信息；
所述接收单元1301，还用于接收来自所述OEM服务器的第七消息，所述第七消息包含第一指示信息，所述第一指示信息用于指示所述第一终端具有使用所述目标服务的权限；
所述发送单元1302，还用于向所述第一终端提供所述目标服务。
在一种可能的实现方式中，所述第六消息包含所述第一终端的标识信息和/或所述目标服务的标识信息。
在一种可能的实现方式中，所述第七消息中还包括第三签名，所述第三签名用于校验所述第一指示信息。
在一种可能的实现方式中，所述第三签名为基于所述第一指示信息和第四密钥得到的。
在一种可能的实现方式中，所述装置还包括：
处理单元1303，用于通过所述第三签名和第五密钥校验所述第一指示信息，所述第五密钥为所述第四密钥的解密密钥。
需要说明的是，各个单元的详细实现还可以参照图11所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，图13中所示的服务授权管理装置130可以为图11所示实施例中的OEM服务器，或为OEM服务器中的一个器件，例如芯片或集成电路等。其中，图13 中所示的服务授权管理装置130各个单元的详细描述如下：
接收单元1301，用于接收资源服务器发送的第六消息，所述第六消息用于请求权限信息；
发送单元1302，用于向所述资源服务器发送第七消息，所述第七消息包含第一指示信息，所述第一指示信息用于第一终端是否具有使用目标服务的权限。
在一种可能的实现方式中，所述第六消息包含所述第一终端的标识信息和/或所述目标服务的标识信息。
在一种可能的实现方式中，所述第七消息中还包括第三签名；所述装置还包括：
处理单元1303，用于根据所述第一指示信息和第四密钥得到所述第三签名，所述第四密钥为第三私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
需要说明的是，各个单元的详细实现还可以参照图11所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，图13中所示的服务授权管理装置130可以为图11所示实施例中的OEM服务器，或为OEM服务器中的一个器件，例如芯片或集成电路等。其中，图13中所示的服务授权管理装置130各个单元的详细描述如下：
发送单元1302，用于向资源服务器发送第五消息，所述第五消息包含第一权限信息和所述第一终端的标识信息；
接收单元1303，用于接收所述资源服务器提供的所述目标服务。结合第十四方面，在第十四方面的又一种可能的实施方式中，所述第五消息中还包含所述第一终端的标识信息。
可选的，上述目标服务的指示信息还可以包含在第一权限信息中。
需要说明的是，各个单元的详细实现还可以参照图11所示实施例中的详细说明，此处不再赘述。
请参见图14，图14是本申请实施例提供的一种服务授权管理装置140的结构示意图，该装置140可以包括至少一个处理器1401和通信接口1402。可选的，还可以包含总线1403。进一步可选的，还可以包括至少一个存储器1404，其中，处理器1401、通信接口1402和存储器1404通过总线1403相连。
处理器1401是进行算术运算和/或逻辑运算的模块，具体可以是CPU、图片处理器(graphics processing unit，GPU)、微处理器(microprocessor unit，MPU)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程逻辑门阵列(Field Programmable Gate Array，FPGA)、复杂可编程逻辑器件(Complex programmable logic device，CPLD)等处理模块中的一种或多种的组合。
通信接口1402用于接收外部发送的数据和/或向外部发送数据，可以为包括诸如以太网电缆等的有线链路接口，也可以是无线链路(Wi-Fi、蓝牙、通用无线传输等)接口。可选的，通信接口1402还可以包括与接口耦合的发射器(如射频发射器、天线等)，或接收器等。
其中，存储器1404用于提供存储空间，存储空间中可以存储操作系统和计算机程序等 数据。存储器1601可以是随机存储记忆体(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmable read only memory，EPROM)、或便携式只读存储器(compact disc read-only memory，CD-ROM)等等中的一种或多种的组合。
该装置140中的处理器1401用于读取所述存储器1404中存储的计算机程序，用于执行前述的服务授权管理方法，例如图5、图6、图7、图8、图9、图10或图11中任意一个实施例所描述的服务授权管理方法。
在一种可能的设计中，该服务授权管理装置140可以为图5、图6、图7、图8、图9或图10所示实施例中的OEM服务器，或为OEM服务器中的一个器件，例如芯片或集成电路等。
该服务授权管理装置140中的处理器1401用于读取所述存储器1404中存储的计算机程序，用于执行以下操作：
通过通信接口1402接收第一消息，所述第一消息包含第一终端的标识信息，所述第一终端为需要使用目标服务的终端；
根据所述第一终端的标识信息确定第一权限信息，其中，所述第一权限信息用于指示所述第一终端具有使用所述目标服务的权限；
通过通信接口1402向所述第一终端发送第二消息，第二消息包含所述第一权限信息。
在一种可能的实施方式中，服务授权管理装置还包含OTA任务管理模块(图中未示出)。进一步的，还可以包含OTA权限管理模块(图中未示出)，所述OTA权限管理模块用于生成权限信息。
在一种可能的实施方式中，所述第一消息还包含所述目标服务的指示信息。
在又一种可能的实施方式中，所述第二消息还包括第一签名，所述第一签名用于校验所述第一权限信息。
在又一种可能的实施方式中，所述处理器1401，还用于根据所述第一权限信息和第一密钥得到所述第一签名，所述第一密钥为第一私钥或为原始设备制造商OEM服务器与所述第一终端之间的共享密钥。
在又一种可能的实施方式中，所述第一消息还包含所述目标服务的指示信息。
在又一种可能的实施方式中，所述目标服务由资源服务器提供，所述第一权限信息用于所述第一终端从所述资源服务器请求所述目标服务。
在又一种可能的实施方式中，所述处理器1401，还用于：
通过通信接口1402向所述资源服务器发送第二权限信息，所述第二权限信息用于指示所述第一终端具有使用所述目标服务的权限。
在又一种可能的实施方式中，所述处理器1401，还用于：
通过通信接口1402向所述资源服务器发送第二签名，所述第二签名为所述OEM服务器根据所述第二权限信息和第二密钥得到的，所述第二密钥为第二私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
在又一种可能的实施方式中，所述目标服务由原始设备制造商OEM服务器提供；所 述处理器1401，还用于：
通过通信接口1402向所述第一终端提供所述目标服务。
在又一种可能的实施方式中，所述处理器1401，还用于：
通过通信接口1402接收来自所述第一终端的第三消息，所述第三消息包含第三权限信息；
根据所述第一权限信息校验所述第三权限信息。
在又一种可能的实施方式中，所述处理器1401，还用于：
通过通信接口1402接收所述第一终端同步的权限状态。
在又一种可能的实施方式中，所述服务授权管理装置与所述第一终端之间建立有第一安全通道，所述第二消息通过所述第一安全通道进行传输；
所述第一安全通道包括传输层安全协议TLS安全通道、数据包传输层安全协议DTLS安全通道或超文本传输安全协议HTTPs安全通道中的至少一项。
需要说明的是，各个单元的详细实现还可以参照图5、图6或图7、图8、图9或图10所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，该服务授权管理装置140可以为图5、图6或图7所示实施例中的第一终端，或为第一终端中的一个器件，例如芯片或集成电路等。
该服务授权管理装置140中的处理器1401用于读取所述存储器1404中存储的计算机程序，用于执行以下操作：
通过通信接口1402接收来自OEM服务器的第二消息，所述第二消息包含第一权限信息，所述第一权限信息用于指示所述第一终端具有使用目标服务的权限；
校验所述第一权限信息；
通过通信接口1402向资源服务器发送第四消息，所述第四消息包含所述第一权限信息和所述第一终端的标识信息；
通过通信接口1402接收所述资源服务器提供的所述目标服务。
在一种可能的实施方式中，所述服务授权管理装置140与所述OEM服务器之间建立有第一安全通道，所述第二消息通过所述第一安全通道进行传输，
所述第一安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
在又一种可能的实施方式中，所述第一终端与所述资源服务器之间建立有第二安全通道，所述第四消息通过所述第二安全通道进行传输，
所述第二安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
在又一种可能的实施方式中，所述处理器1401，还用于：
通过通信接口1402向所述OEM服务器发送第一消息，所述第一消息包含所述第一终端的标识信息，所述第一终端的标识信息用于所述OEM服务器确定所述第一权限信息。
在又一种可能的实施方式中，所述第二消息还包含第一签名，所述第一签名用于校验所述第一权限信息。
在又一种可能的实施方式中，所述第一签名为基于所述第一权限信息和第一密钥得到的；
所述处理器1401，用于根据所述第一签名和第三密钥校验所述第一权限信息，所述第三密钥为所述第一密钥的解密密钥。
在又一种可能的实施方式中，所述处理器1401，还用于：
通过通信接口1402向所述OEM服务器同步权限状态。
需要说明的是，各个单元的详细实现还可以参照图5、图6或图7所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，该服务授权管理装置140可以为图8、图9或图10所示实施例中的第一终端，或为第一终端中的一个器件，例如芯片或集成电路等。
该服务授权管理装置140中的处理器1401用于读取所述存储器1404中存储的计算机程序，用于执行以下操作：
通过通信接口1402接收来自OEM服务器的第二消息，所述第二消息包含第一权限信息，所述第一权限信息用于指示所述第一终端具有使用目标服务的权限；
校验所述第一权限信息；
通过通信接口1402向所述OEM服务器发送第三消息，所述第三消息包含所述第一权限信息；
通过通信接口1402接收所述OEM服务器提供的所述目标服务。
在一种可能的实施方式中，所述服务授权管理装置与所述OEM服务器之间建立有第一安全通道，所述第二消息和/或所述第三消息通过所述第一安全通道进行传输，所述第一安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
在又一种可能的实施方式中，所述处理器1401，还用于：
通过通信接口1402向所述OEM服务器发送第一消息，所述第一消息包含所述第一终端的标识信息，所述第一终端的标识信息用于所述OEM服务器确定所述第一权限信息。
在又一种可能的实施方式中，所述第二消息还包含第一签名，所述第一签名用于校验所述第一权限信息。
在又一种可能的实施方式中，所述第一签名为基于所述第一权限信息和第一密钥得到的；
所述处理器1401，用于根据所述第一签名和第三密钥校验所述第一权限信息，所述第三密钥为所述第一密钥的解密密钥。
在又一种可能的实施方式中，所述处理器1401，还用于：
通过通信接口1402向所述OEM服务器同步权限状态。
需要说明的是，各个单元的详细实现还可以参照图8、图9或图10所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，该服务授权管理装置140可以为图5、图6或图7所示实施例中的资源服务器，或为资源服务器中的一个器件，例如芯片或集成电路等。
该服务授权管理装置140中的处理器1401用于读取所述存储器1404中存储的计算机程序，用于执行以下操作：
通过通信接口1402接收第一终端发送的第四消息，所述第四消息包含所述第一终端的标识信息和第一权限信息，所述第一终端为需要使用目标服务的终端，所述第一权限信息用于指示所述第一终端具有使用所述目标服务的权限，所述第一权限信息为OEM服务器确定的；
校验所述第一权限信息；
响应于校验所述第一权限信息通过，通过通信接口1402向所述第一终端提供所述目标服务。
在一种可能的实施方式中，所述第四消息中还包括目标服务的指示信息。
可选的，上述目标服务的指示信息还可以包含在第一权限信息中。
在一种可能的实现方式中，所述处理器1401，还用于：
通过通信接口1402接收来自OEM服务器的第二权限信息，所述第二权限信息用于指示所述第一终端具有使用所述目标服务的权限。
在一种可能的实现方式中，所述处理器1401，还用于：
通过通信接口1402根据所述第二权限信息校验所述第一权限信息。
在一种可能的实现方式中，所述处理器1401，还用于：
通过通信接口1402接收来自OEM服务器的第二签名；所述第二签名为所述OEM服务器根据所述第二权限信息和第二密钥的得到的；
根据第六密钥和所述第二签名确定所述第二权限信息校验通过，所述第六密钥为所述第二密钥的解密密钥。
在一种可能的实现方式中，所述第一终端与所述资源服务器之间建立有第二安全通道，所述第一终端与所述资源服务器通过所述第二安全通道进行信息传输，所述第二安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
需要说明的是，各个单元的详细实现还可以参照图5、图6或图7所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，该服务授权管理装置140可以为图11所示实施例中的资源服务器，或为资源服务器中的一个器件，例如芯片或集成电路等。
该服务授权管理装置140中的处理器1401用于读取所述存储器1404中存储的计算机程序，用于执行以下操作：
通过通信接口1402接收所述第一终端发送第五消息，所述第五消息包含所述第一终端的标识信息，所述第一终端为需要使用所述目标服务的终端；
通过通信接口1402向OEM服务器发送第六消息，所述第六消息用于请求权限信息；
通过通信接口1402接收来自所述OEM服务器的第七消息，所述第七消息包含第一指示信息，所述第一指示信息用于指示所述第一终端具有使用所述目标服务的权限；
通过通信接口1402向所述第一终端提供所述目标服务。
在一种可能的实现方式中，所述第六消息包含所述第一终端的标识信息和/或所述目标 服务的标识信息。
在一种可能的实现方式中，所述第七消息中还包括第三签名，所述第三签名用于校验所述第一指示信息。
在一种可能的实现方式中，所述第三签名为基于所述第一指示信息和第四密钥得到的；所述处理器1401，还用于：
通过所述第三签名和第五密钥校验所述第一指示信息，所述第五密钥为所述第四密钥的解密密钥。
需要说明的是，各个单元的详细实现还可以参照图11所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，该服务授权管理装置140可以为图11所示实施例中的OEM服务器，或为OEM服务器中的一个器件，例如芯片或集成电路等。
该服务授权管理装置140中的处理器1401用于读取所述存储器1404中存储的计算机程序，用于执行以下操作：
通过通信接口1402接收资源服务器发送的第六消息，所述第六消息用于请求权限信息；
通过通信接口1402向所述资源服务器发送第七消息，所述第七消息包含第一指示信息，所述第一指示信息用于第一终端是否具有使用目标服务的权限。
在一种可能的实现方式中，所述第六消息包含所述第一终端的标识信息和/或所述目标服务的标识信息。
在一种可能的实现方式中，所述第七消息中还包括第三签名；所述处理器1401，还用于：
根据所述第一指示信息和第四密钥得到所述第三签名，所述第四密钥为第三私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
需要说明的是，各个单元的详细实现还可以参照图11所示实施例中的详细说明，此处不再赘述。
在一种可能的设计中，该服务授权管理装置140可以为图11所示实施例中的第一终端，或为第一终端中的一个器件，例如芯片或集成电路等。
该服务授权管理装置140中的处理器1401用于读取所述存储器1404中存储的计算机程序，用于执行以下操作：
通过通信接口1402向资源服务器发送第五消息，所述第五消息包含第一权限信息和所述第一终端的标识信息；
通过通信接口1402接收所述资源服务器提供的所述目标服务。结合第十四方面，在第十四方面的又一种可能的实施方式中，所述第五消息中还包含所述第一终端的标识信息。
可选的，上述目标服务的指示信息还可以包含在第一权限信息中。
需要说明的是，各个单元的详细实现还可以参照图11所示实施例中的详细说明，此处不再赘述。
本申请实施例还提供了一种芯片系统，所述芯片系统包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述芯片系统所在的装置实现图5、图6、图7、图8、图9、图10或图11所示的实施例中OEM服务器侧、资源服务器侧或第一终端侧的方法。
进一步，所述至少一个处理器可以为CPU、GPU、MPU、ASIC、FPGA、CPLD、协处理器(协助中央处理器完成相应处理和应用)、MCU等处理模块中的一种或多种的组合。
本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在一个或多个处理器上运行时，实现图5、图6、图7、图8、图9、图10或图11所示的实施例所描述的方法。
本申请实施例还提供了一种计算机程序产品，当所述计算机程序产品在一个或多个处理器上运行时，实现图5、图6、图7、图8、图9、图10或图11所示的实施例所描述的方法。
在计算机上加载和执行该计算机指令时，可以全部或部分地实现本申请实施例所描述的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或其它可编程装置。该计算机指令可以存储在计算机可读存储介质中，或通过计算机可读存储介质进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或半导体介质(例如，固态硬盘(solid state disk，SSD))等。
本申请方法实施例中的步骤可以根据实际需要进行顺序调整、合并和删减。
本申请装置实施例中的模块可以根据实际需要进行合并、划分和删减。

Claims (70)

  1. 一种服务授权管理方法，其特征在于，包括：
    原始设备制造商OEM服务器接收第一消息，所述第一消息包含第一车辆的标识信息，所述第一车辆为需要使用目标服务的终端；
    所述OEM服务器根据所述第一车辆的标识信息确定第一权限信息，其中，所述第一权限信息用于指示所述第一车辆具有使用所述目标服务的权限；
    所述OEM服务器向所述第一车辆发送第二消息，所述第二消息包含所述第一权限信息。
  2. 根据权利要求1所述的方法，其特征在于，所述第一消息还包含所述目标服务的指示信息。
  3. 根据权利要求1或2所述的方法，其特征在于，所述第二消息还包括第一签名，所述第一签名用于校验所述第一权限信息。
  4. 根据权利要求3所述的方法，其特征在于，所述OEM服务器向所述第一车辆发送第二消息之前，所述方法还包括：
    所述OEM服务器根据所述第一权限信息和第一密钥得到所述第一签名，所述第一密钥为第一私钥或为所述OEM服务器与所述第一车辆之间的共享密钥。
  5. 根据权利要求1-4中任一项所述的方法，其特征在于，所述目标服务由资源服务器提供，所述第一权限信息用于所述第一车辆从所述资源服务器请求所述目标服务。
  6. 根据权利要求5中所述的方法，其特征在于，所述方法还包括：
    所述OEM服务器向所述资源服务器发送第二权限信息，所述第二权限信息用于指示所述第一车辆具有使用所述目标服务的权限。
  7. 根据权利要求6中所述的方法，其特征在于，所述方法还包括：
    所述OEM服务器向所述资源服务器发送第二签名，所述第二签名为所述OEM服务器根据所述第二权限信息和第二密钥得到的，所述第二密钥为第二私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
  8. 根据权利要求1-4中任一项所述的方法，其特征在于，所述OEM服务器根据所述第一车辆的标识信息确定第一权限信息之后，所述方法还包括：
    所述OEM服务器向所述第一车辆提供所述目标服务。
  9. 根据权利要求7所述的方法，其特征在于，所述方法还包括：
    所述OEM服务器接收来自所述第一车辆的第三消息，所述第三消息包含第三权限信息；
    所述OEM服务器根据所述第一权限信息校验所述第三权限信息。
  10. 根据权利要求1-9中任一项所述的方法，其特征在于，所述OEM服务器向所述第一车辆发送第二消息之后，所述方法还包括：
    所述OEM服务器接收所述第一车辆同步的权限状态。
  11. 根据权利要求1-9中任一项所述的方法，其特征在于，所述OEM云端与所述第一车辆之间建立有第一安全通道，所述第二消息通过所述第一安全通道进行传输；
    所述第一安全通道包括传输层安全协议TLS安全通道、数据包传输层安全协议DTLS安全通道或超文本传输安全协议HTTPs安全通道中的至少一项。
  12. 一种服务授权管理方法，其特征在于，包括：
    第一车辆接收来自OEM服务器的第二消息，所述第二消息包含第一权限信息，所述第一权限信息用于指示所述第一车辆具有使用目标服务的权限；
    所述第一车辆校验所述第一权限信息；
    所述第一车辆向资源服务器发送第四消息，所述第四消息包含所述第一权限信息和所述第一车辆的标识信息；
    所述第一车辆接收所述资源服务器提供的所述目标服务。
  13. 根据权利要求12中所述的方法，其特征在于，所述第一车辆与所述OEM服务器之间建立有第一安全通道，所述第二消息通过所述第一安全通道进行传输，所述第一安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
  14. 根据权利要求12或13中所述的方法，其特征在于，所述第一车辆与所述资源服务器之间建立有第二安全通道，所述第四消息通过所述第二安全通道进行传输，所述第二安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
  15. 根据权利要求13-14中任一项中所述的方法，其特征在于，所述第一车辆接收来自OEM服务器的第二消息之前，所述方法还包括：
    所述第一车辆向所述OEM服务器发送第一消息，所述第一消息包含所述第一车辆的标识信息，所述第一车辆的标识信息用于所述OEM服务器确定所述第一权限信息。
  16. 根据权利要求12-15中任一项中所述的方法，其特征在于，所述第二消息还包含第一签名，所述第一签名为基于所述第一权限信息和第一密钥得到的；所述第一车辆校验所述第一权限信息，包括：
    所述第一车辆根据所述第一签名和第三密钥校验所述第一权限信息，所述第三密钥为所述第一密钥的解密密钥。
  17. 根据权利要求12-16中任一项中所述的方法，其特征在于，所述第一车辆接收所述资源服务器提供的所述目标服务之后，所述方法还包括：
    所述第一车辆向所述OEM服务器同步权限状态。
  18. 一种服务授权管理方法，其特征在于，包括：
    第一车辆接收来自OEM服务器的第二消息，所述第二消息包含第一权限信息，所述第一权限信息用于指示所述第一车辆具有使用目标服务的权限；
    所述第一车辆校验所述第一权限信息；
    所述第一车辆向所述OEM服务器发送第三消息，所述第三消息包含所述第一权限信息；
    所述第一车辆接收所述OEM服务器提供的所述目标服务。
  19. 根据权利要求18所述的方法，其特征在于，所述第一车辆与所述OEM服务器之间建立有第一安全通道，所述第二消息和/或所述第三消息通过所述第一安全通道进行传输，所述第一安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
  20. 根据权利要求18-19中任一项所述的方法，其特征在于，所述第一车辆接收来自OEM服务器的第二消息之前，所述方法还包括：
    所述第一车辆向所述OEM服务器发送第一消息，所述第一消息包含所述第一车辆的标识信息，所述第一车辆的标识信息用于所述OEM服务器确定所述第一权限信息。
  21. 根据权利要求18-20中任一项所述的方法，其特征在于，所述第二消息还包含第一签名，所述第一签名为基于所述第一权限信息和第一密钥得到的；所述第一车辆校验所述第一权限信息，包括：
    所述第一车辆根据所述第一签名和第三密钥校验所述第一权限信息，所述第三密钥为所述第一密钥的解密密钥。
  22. 根据权利要求18-21中任一项所述的方法，其特征在于，所述第一车辆接收所述资源服务器提供的所述目标服务之后，所述方法还包括：
    所述第一车辆向所述OEM服务器同步权限状态。
  23. 一种服务授权管理方法，其特征在于，包括：
    资源服务器接收所述第一车辆发送的第五消息，所述第五消息包含所述第一车辆的标识信息，所述第一车辆为需要使用所述目标服务的终端；
    所述资源服务器向OEM服务器发送第六消息，所述第六消息用于请求权限信息；
    所述资源服务器接收来自所述OEM服务器的第七消息，所述第七消息包含第一指示信息，所述第一指示信息用于指示所述第一车辆具有使用所述目标服务的权限；
    所述资源服务器向所述第一车辆提供所述目标服务。
  24. 根据权利要求23所述的方法，其特征在于，所述第六消息包含所述第一车辆的标识信息和/或所述目标服务的标识信息。
  25. 根据权利要求23或24所述的方法，其特征在于，所述第七消息中还包括第三签名，所述第三签名为基于所述第一指示信息和第四密钥得到的。
  26. 根据权利要求25所述的方法，其特征在于，所述方法还包括：
    所述资源服务器通过所述第三签名和第五密钥校验所述第一指示信息，所述第五密钥为所述第四密钥的解密密钥。
  27. 一种服务授权管理方法，其特征在于，包括：
    OEM服务器接收资源服务器发送的第六消息，所述第六消息用于请求权限信息；
    所述OEM服务器向所述资源服务器发送第七消息，所述第七消息包含第一指示信息，所述第一指示信息用于指示第一车辆是否具有使用目标服务的权限。
  28. 根据权利要求27所述的方法，其特征在于，所述第六消息包含所述第一车辆的标识信息或所述目标服务的标识信息。
  29. 根据权利要求27或28所述的方法，其特征在于，所述第七消息中还包括第三签名，所述第三签名用于校验所述第一指示信息。
  30. 根据权利要求29所述的方法，其特征在于，所述OEM服务器向所述资源服务器发送第七消息之前，所述方法还包括：
    所述OEM服务器根据所述第一指示信息和第四密钥得到所述第三签名，所述第四密钥为第三私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
  31. 一种服务授权管理装置，其特征在于，包括：
    接收单元，用于接收第一消息，所述第一消息包含第一车辆的标识信息，所述第一车辆为需要使用目标服务的终端；
    处理单元，用于根据所述第一车辆的标识信息确定第一权限信息，其中，所述第一权限信息用于指示所述第一车辆具有使用所述目标服务的权限；
    发送单元，用于向所述第一车辆发送第二消息，第二消息包含所述第一权限信息。
  32. 根据权利要求31所述的装置，其特征在于，所述第一消息还包含所述目标服务的指示信息。
  33. 根据权利要求31或32所述的装置，其特征在于，所述第二消息还包括第一签名，，所述第一签名用于校验所述第一权限信息。
  34. 根据权利要求33所述的装置，其特征在于，所述方法还包括：
    所述处理单元，还用于根据所述第一权限信息和第一密钥得到所述第一签名，所述第一密钥为第一私钥或为原始设备制造商OEM服务器与所述第一车辆之间的共享密钥。
  35. 根据权利要求31-34中任一项所述的装置，其特征在于，所述目标服务由资源服务器提供，所述第一权限信息用于所述第一车辆从所述资源服务器请求所述目标服务。
  36. 根据权利要求35所述的装置，其特征在于，
    所述发送单元，还用于向所述资源服务器发送第二权限信息，所述第二权限信息用于指示所述第一车辆具有使用所述目标服务的权限。
  37. 根据权利要求36所述的装置，其特征在于，
    所述发送单元，还用于向所述资源服务器发送第二签名，所述第二签名为所述OEM服务器根据所述第二权限信息和第二密钥得到的，所述第二密钥为第二私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
  38. 根据权利要求31-34中任一项所述的装置，其特征在于，所述目标服务由原始设备制造商OEM服务器提供；
    所述发送单元，还用于向所述第一车辆提供所述目标服务。
  39. 根据权利要求38所述的装置，其特征在于，
    所述接收单元，还用于接收来自所述第一车辆的第三消息，所述第三消息包含第三权限信息；
    所述处理单元，还用于根据所述第一权限信息校验所述第三权限信息。
  40. 根据权利要求31-39中任一项所述的装置，其特征在于，
    所述接收单元，还用于接收所述第一车辆同步的权限状态。
  41. 根据权利要求31-40中任一项所述的装置，其特征在于，所述服务授权管理装置与所述第一车辆之间建立有第一安全通道，所述第二消息通过所述第一安全通道进行传输；
    所述第一安全通道包括传输层安全协议TLS安全通道、数据包传输层安全协议DTLS安全通道或超文本传输安全协议HTTPs安全通道中的至少一项。
  42. 一种服务授权管理装置，其特征在于，包括：
    接收单元，用于接收来自OEM服务器的第二消息，所述第二消息包含第一权限信息，所述第一权限信息用于指示所述第一车辆具有使用目标服务的权限；
    处理单元，用于校验所述第一权限信息；
    发送单元，用于向资源服务器发送第四消息，所述第四消息包含所述第一权限信息和所述第一车辆的标识信息；
    所述接收单元，还用于接收所述资源服务器提供的所述目标服务。
  43. 根据权利要求42所述的装置，其特征在于，所述服务授权管理装置与所述OEM服务器之间建立有第一安全通道，所述第二消息通过所述第一安全通道进行传输，
    所述第一安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
  44. 根据权利要求42或43所述的装置，其特征在于，所述第一车辆与所述资源服务器之间建立有第二安全通道，所述第四消息通过所述第二安全通道进行传输，
    所述第二安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
  45. 根据权利要求42-44中任一项所述的装置，其特征在于，所述发送单元，还用于：
    向所述OEM服务器发送第一消息，所述第一消息包含所述第一车辆的标识信息，所述第一车辆的标识信息用于所述OEM服务器确定所述第一权限信息。
  46. 根据权利要求42-45中任一项所述的装置，其特征在于，所述第二消息还包含第一签名，所述第一签名为基于所述第一权限信息和第一密钥得到的；
    所述处理单元，用于根据所述第一签名和第三密钥校验所述第一权限信息，所述第三密钥为所述第一密钥的解密密钥。
  47. 根据权利要求42-46中任一项所述的装置，其特征在于，
    所述发送单元，还用于向所述OEM服务器同步权限状态。
  48. 一种服务授权管理装置，其特征在于，包括：
    接收单元，用于接收来自OEM服务器的第二消息，所述第二消息包含第一权限信息，所述第一权限信息用于指示所述第一车辆具有使用目标服务的权限；
    处理单元，用于校验所述第一权限信息；
    发送单元，用于向所述OEM服务器发送第三消息，所述第三消息包含所述第一权限信息；
    所述接收单元，还用于接收所述OEM服务器提供的所述目标服务。
  49. 根据权利要求48所述的装置，其特征在于，所述服务授权管理装置与所述OEM 服务器之间建立有第一安全通道，所述第二消息和/或所述第三消息通过所述第一安全通道进行传输，所述第一安全通道包括TLS安全通道、DTLS安全通道或HTTPs安全通道中的至少一项。
  50. 根据权利要求48或49所述的装置，其特征在于，所述发送单元，还用于：
    向所述OEM服务器发送第一消息，所述第一消息包含所述第一车辆的标识信息，所述第一车辆的标识信息用于所述OEM服务器确定所述第一权限信息。
  51. 根据权利要求48-50中任一项所述的装置，其特征在于，所述第二消息还包含第一签名，所述第一签名为基于所述第一权限信息和第一密钥得到的；
    所述处理单元，用于根据所述第一签名和第三密钥校验所述第一权限信息，所述第三密钥为所述第一密钥的解密密钥。
  52. 根据权利要求48-51中任一项所述的装置，其特征在于，
    所述发送单元，还用于向所述OEM服务器同步权限状态。
  53. 一种服务授权管理装置，其特征在于，包括：
    接收单元，用于接收所述第一车辆发送第五消息，所述第五消息包含所述第一车辆的标识信息，所述第一车辆为需要使用所述目标服务的终端；
    发送单元，用于向OEM服务器发送第六消息，所述第六消息用于请求权限信息；
    所述接收单元，还用于接收来自所述OEM服务器的第七消息，所述第七消息包含第一指示信息，所述第一指示信息用于指示所述第一车辆具有使用所述目标服务的权限；
    所述发送单元，还用于向所述第一车辆提供所述目标服务。
  54. 根据权利要求53所述的装置，其特征在于，所述第六消息包含所述第一车辆的标识信息和/或所述目标服务的标识信息。
  55. 根据权利要求53或54所述的装置，其特征在于，所述第七消息中还包括第三签名，所述第三签名为基于所述第一指示信息和第四密钥得到的。
  56. 根据权利要求55所述的方法，其特征在于，所述装置还包括：
    处理单元，用于通过所述第三签名和第五密钥校验所述第一指示信息，所述第五密钥为所述第四密钥的解密密钥。
  57. 一种服务授权管理装置，其特征在于，包括：
    接收单元，用于接收资源服务器发送的第六消息，所述第六消息用于请求权限信息；
    发送单元，用于向所述资源服务器发送第七消息，所述第七消息包含第一指示信息，所述第一指示信息用于指示第一车辆是否具有使用目标服务的权限。
  58. 根据权利要求57所述的装置，其特征在于，所述第六消息包含所述第一车辆的标识信息和/或所述目标服务的标识信息。
  59. 根据权利要求57或58所述的装置，其特征在于，所述第七消息中还包括第三签名，所述第三签名为基于所述第一指示信息和第四密钥得到的。
  60. 根据权利要求59所述的装置，其特征在于，所述装置，还包括：
    处理单元，用于根据所述第一指示信息和第四密钥得到所述第三签名，所述第四密钥为第三私钥或为所述OEM服务器与所述资源服务器之间的共享密钥。
  61. 一种服务授权管理装置，其特征在于，所述服务授权管理装置包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述服务授权管理装置实现如权利要求1-11中任一项所述的方法。
  62. 一种服务授权管理装置，其特征在于，所述服务授权管理装置包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述服务授权管理装置实现如权利要求12-17中任一项所述的方法。
  63. 一种服务授权管理装置，其特征在于，所述服务授权管理装置包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述服务授权管理装置实现如权利要求18-22中任一项所述的方法。
  64. 一种服务授权管理装置，其特征在于，所述服务授权管理装置包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述服务授权管理装置实现如权利要求23-26中任一项所述的方法。
  65. 一种服务授权管理装置，其特征在于，所述服务授权管理装置包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述服务授权管理装置实现如权利要求27-30中任一项所述的方法。
  66. 一种服务授权管理系统，其特征在于，包括OEM服务器、第一车辆和资源服务器，其中：
    所述OEM服务器包含如权利要求31-41中任一项所述的服务授权管理装置；
    第一车辆包含如权利要求42-47中任一项所述的服务授权管理装置。
  67. 一种服务授权管理系统，其特征在于，包括OEM服务器和第一车辆，其中：
    所述OEM服务器包含如权利要求31-41中任一项所述的服务授权管理装置；
    第一车辆包含如权利要求48-52中任一项所述的服务授权管理装置。
  68. 一种服务授权管理系统，其特征在于，包括OEM服务器、第一车辆和资源服务器，其中：
    所述资源服务器包含如权利要求53-56中任一项所述的服务授权管理装置；
    OEM服务器包含如权利要求57-60中任一项所述的服务授权管理装置。
  69. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在一个或多个处理器上运行时，实现如权利要求1-30中任一项所述的方法。
  70. 一种计算机程序产品，其特征在于，当所述计算机程序产品在一个或多个处理器上运行时，实现如权利要求1-30中任一项所述的方法。
PCT/CN2021/073956 2021-01-27 2021-01-27 一种服务授权管理方法及装置 WO2022160124A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2021/073956 WO2022160124A1 (zh) 2021-01-27 2021-01-27 一种服务授权管理方法及装置
CN202180000313.5A CN112913209A (zh) 2021-01-27 2021-01-27 一种服务授权管理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/073956 WO2022160124A1 (zh) 2021-01-27 2021-01-27 一种服务授权管理方法及装置

Publications (1)

Publication Number Publication Date
WO2022160124A1 true WO2022160124A1 (zh) 2022-08-04

Family

ID=76109007

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/073956 WO2022160124A1 (zh) 2021-01-27 2021-01-27 一种服务授权管理方法及装置

Country Status (2)

Country Link
CN (1) CN112913209A (zh)
WO (1) WO2022160124A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117597907A (zh) * 2021-07-08 2024-02-23 华为技术有限公司 数据更新方法、装置以及系统
CN113806786B (zh) * 2021-11-18 2022-03-18 北京持安科技有限公司 一种软件授权管理方法、系统、设备及存储介质
CN117195216A (zh) * 2022-06-01 2023-12-08 华为技术有限公司 车辆校验方法、相关装置及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105491228A (zh) * 2015-11-24 2016-04-13 大连楼兰科技股份有限公司 分享车辆控制权的方法及系统
CN107967525A (zh) * 2016-10-19 2018-04-27 腾讯科技（深圳）有限公司 车辆业务数据处理的方法和装置
WO2020218810A1 (ko) * 2019-04-24 2020-10-29 현대자동차주식회사 Ev 사용자 인가 방법 및 시스템
CN111935200A (zh) * 2019-05-13 2020-11-13 华为技术有限公司 一种车辆控制方法及相关设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101005699A (zh) * 2006-01-22 2007-07-25 华为技术有限公司 管理终端开放平台权限信息的方法和系统
DE102009038035A1 (de) * 2009-08-19 2011-02-24 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Konfiguration von Infotainmentanwendungen in einem Kraftfahrzeug
CN106599621A (zh) * 2016-11-16 2017-04-26 深圳市异度信息产业有限公司 权限的激活方法及装置
CN110298936B (zh) * 2018-03-22 2021-04-20 比亚迪股份有限公司 车辆钥匙配置方法、系统及其设备
CN109104287A (zh) * 2018-07-27 2018-12-28 众安信息技术服务有限公司 在区块链中进行通信的方法和装置
CN109284618B (zh) * 2018-09-28 2020-07-28 真相网络科技（北京）有限公司 数据源数据的验证方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105491228A (zh) * 2015-11-24 2016-04-13 大连楼兰科技股份有限公司 分享车辆控制权的方法及系统
CN107967525A (zh) * 2016-10-19 2018-04-27 腾讯科技（深圳）有限公司 车辆业务数据处理的方法和装置
WO2020218810A1 (ko) * 2019-04-24 2020-10-29 현대자동차주식회사 Ev 사용자 인가 방법 및 시스템
CN111935200A (zh) * 2019-05-13 2020-11-13 华为技术有限公司 一种车辆控制方法及相关设备

Also Published As

Publication number Publication date
CN112913209A (zh) 2021-06-04

Similar Documents

Publication Publication Date Title
JP7280396B2 (ja) 機器の安全なプロビジョニングと管理
WO2022160124A1 (zh) 一种服务授权管理方法及装置
EP3474488A1 (en) System, certification authority, vehicle-mounted computer, vehicle, public key certificate issuance method, and program
US10084790B2 (en) Peer to peer enterprise file sharing
US10652742B2 (en) Hybrid authentication of vehicle devices and/or mobile user devices
WO2019041802A1 (zh) 基于服务化架构的发现方法及装置
US20070254630A1 (en) Methods, devices and modules for secure remote access to home networks
US10148651B2 (en) Authentication system
KR20150074414A (ko) 펌웨어 업그레이드 방법 및 그 시스템
CN111742531B (zh) 简档信息共享
KR20160127167A (ko) 다중 팩터 인증 기관
EP2166727B1 (en) Center apparatus, terminal apparatus, and authentication system
CN112913189B (zh) 一种ota升级方法及装置
EP2715634A1 (en) Dynamic platform reconfiguration by multi-tenant service providers
JP2021511743A (ja) Ｉｏｔサービスを実施するための方法、アプリケーションサーバ、ｉｏｔ装置および媒体
US20120331286A1 (en) Apparatus and method for providing service to heterogeneous service terminals
CN114547583A (zh) 身份认证系统、方法、装置、设备及计算机可读存储介质
WO2023115913A1 (zh) 认证方法、系统、电子设备和计算机可读存储介质
CN113676478A (zh) 一种数据处理方法及相关设备
CN114785532B (zh) 一种基于双向签名认证的安全芯片通信方法及装置
WO2022171177A1 (zh) 通信密钥配置方法及装置
KR20170090008A (ko) 자동차 개방형 PnP형 플랫폼에서의 플러그인 디바이스 인증 방법 및 장치
US11818280B2 (en) Systems and methods for centrally managing and routing multiple credentials
JP7480689B2 (ja) 通信制御方法及び通信装置
WO2024037048A1 (zh) 通信方法、装置和系统

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: 21921744

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21921744

Country of ref document: EP

Kind code of ref document: A1