CN114978741A - Intersystem authentication method and system - Google Patents

Intersystem authentication method and system Download PDF

Info

Publication number
CN114978741A
CN114978741A CN202210634802.2A CN202210634802A CN114978741A CN 114978741 A CN114978741 A CN 114978741A CN 202210634802 A CN202210634802 A CN 202210634802A CN 114978741 A CN114978741 A CN 114978741A
Authority
CN
China
Prior art keywords
entity
federated
service
digital signature
network address
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
CN202210634802.2A
Other languages
Chinese (zh)
Other versions
CN114978741B (en
Inventor
张蔚茵
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Telecom Corp Ltd
Original Assignee
China Telecom Corp Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Telecom Corp Ltd filed Critical China Telecom Corp Ltd
Priority to CN202210634802.2A priority Critical patent/CN114978741B/en
Publication of CN114978741A publication Critical patent/CN114978741A/en
Application granted granted Critical
Publication of CN114978741B publication Critical patent/CN114978741B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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/3236—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 using cryptographic hash functions
    • 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

Landscapes

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

Abstract

The disclosed embodiment provides a method and a system for authentication between systems, which relate to the technical field of communication security, and comprise the following steps: the first federated entity obtains entity information of a second federated entity from the blockchain network and sends a first calling request to the second federated entity, wherein the first calling request comprises identity information of the first federated entity and a first digital signature obtained by encrypting the identity information by using a private key of the first federated entity. The second federated entity obtains entity information of the first federated entity from the block chain network, utilizes a public key of the first federated entity to verify the first digital signature, and if the verification is passed, a first call response is sent to the first federated entity; wherein the first invocation response includes the network address of the second processing entity. The first federated entity sends the network address of the second processing entity to the first processing entity, which accesses the second processing entity. Thereby improving the security of the edge computing service of the MEC system.

Description

Inter-system authentication method and system
Technical Field
The present disclosure relates to the field of communication security technologies, and in particular, to an inter-system authentication method and system.
Background
Multi-access Edge Computing (MEC) technology, also called Edge cloud technology, can set capabilities of Computing and network to the network Edge, thereby creating a carrier-class service environment with high performance, low delay and high bandwidth, and being capable of providing services for users nearby.
With the rapid development of the MEC technology, the objects of the MEC system service are also more extensive, for example, the MEC system can provide edge computing service for other MEC systems besides providing edge computing service for terminals such as mobile phones or computers. However, if the MEC systems can be freely called in an open manner, a malicious device may spoof the identity of the MEC system and thus cheat the edge computing capability of other MEC systems, so that the edge computing service of the MEC system has a security risk.
Disclosure of Invention
An object of the embodiments of the present disclosure is to provide an inter-system authentication method and system, so as to improve the security of an edge computing service of an MEC system. The specific technical scheme is as follows:
in a first aspect, an embodiment of the present disclosure provides an inter-system authentication method, which is applied to an inter-system authentication system, where the inter-system authentication system includes a requester system, a provider system, and a blockchain network, and the requester system includes: a first federated entity and a first processing entity; the provider system includes: the block chain network is used for storing entity information of the federated entities in each system with a federation relation, and the entity information comprises a network address and a public key; the method comprises the following steps:
the first federated entity acquires entity information of the second federated entity from the blockchain network, and sends a first calling request to the second federated entity according to the entity information of the second federated entity, wherein the first calling request comprises identity information of the first federated entity and a first digital signature obtained by encrypting the identity information of the first federated entity by using a private key of the first federated entity;
the second federated entity responds to the first calling request, acquires entity information of the first federated entity from the blockchain network, verifies the first digital signature by using a public key of the first federated entity, and sends a first calling response to the first federated entity if the first digital signature is verified; the first invocation response includes a network address of the second processing entity;
the first federated entity sends the network address of the second processing entity to the first processing entity;
the first processing entity accesses the second processing entity based on the network address of the second processing entity.
In some embodiments, the first call response further comprises: the method includes that information to be transmitted and a second digital signature obtained by encrypting the network address of the second processing entity and the information to be transmitted by using a private key of the second federated entity are transmitted, the information to be transmitted includes a first access token distributed by the second federated entity, and before the first federated entity sends the network address of the second processing entity to the first processing entity, the method further includes:
and the first federated entity verifies the second digital signature by using the public key of the second federated entity, and if the second digital signature is verified, the step of sending the network address of the second processing entity to the first processing entity is executed.
In some embodiments, the first processing entity comprises a first management entity and a first service entity; the second processing entity comprises a second management entity and a second service entity; the information to be transmitted also comprises a third digital signature obtained by encrypting the first access token and the network address of the second management entity by using a private key of the second association entity;
before the first processing entity accesses the second processing entity based on the network address of the second processing entity, the method further comprises:
the first management entity receives the first access token and the third digital signature sent by the first federated entity;
the first processing entity accessing the second processing entity based on the network address of the second processing entity, including:
the first management entity sending a second invocation request to the second management entity, the second invocation request including the first access token and the third digital signature;
the second management entity responds to the second calling request, acquires a public key of the second federated entity, and verifies the third digital signature by using the public key of the second federated entity; if the third digital signature is verified, sending the second call response to the first management entity, the second call response comprising the network address of the second service entity;
the first management entity sends the network address of the second service entity to the first service entity;
the first serving entity accesses the second serving entity based on the network address of the second serving entity.
In some embodiments, the second call response further comprises: the second access token distributed by the second management entity and a fourth digital signature obtained by encrypting the second access token and the network address of the second service entity by using a private key of the second management entity; before the first processing entity accesses the second processing entity based on the network address of the second processing entity, the method further comprises:
the first service entity receives the second access token and the fourth digital signature sent by the first management entity;
the first service entity accesses the second service entity based on the network address of the second service entity, including:
the first service entity sends a third calling request to the second service entity based on the network address of the second service entity, wherein the third calling request comprises the second access token and the fourth digital signature;
and the second service entity responds to a third calling request, acquires the public key of the second management entity, verifies the fourth digital signature by using the public key of the second management entity, and provides service for the first service entity if the fourth digital signature passes verification.
In some embodiments, the first processing entity further comprises a first platform management entity; the sending, by the first management entity, the network address of the second service entity to the first service entity includes:
the first management entity sends the network address of the second service entity to the first platform management entity;
the first platform management entity forwards the network address of the second service entity to the first service entity.
In some embodiments, the blockchain network stores entity information of a second federated entity in the provider system and service information of a service provided by the provider system; the first federated entity obtains entity information of the second federated entity from the blockchain network, and the method comprises the following steps:
and the first joint entity searches entity information of the joint entity corresponding to the specified service information from the block chain network.
In some embodiments, the requestor system is a multi-access edge computing MEC system or a cloud system and the provider system is an MEC system.
In a second aspect, an embodiment of the present disclosure provides an inter-system authentication system, including a requester system, a provider system, and a blockchain network, where the requester system includes: a first federated entity and a first processing entity; the provider system includes: the block chain network is used for storing entity information of the federated entities in each system with a federation relation, and the entity information comprises a network address and a public key;
the first federated entity is configured to obtain entity information of the second federated entity from the blockchain network, and send a first invocation request to the second federated entity according to the entity information of the second federated entity, where the first invocation request includes the identity information of the first federated entity and a first digital signature obtained by encrypting the identity information of the first federated entity using a private key of the first federated entity;
the second federated entity is configured to, in response to the first invocation request, obtain entity information of the first federated entity from the blockchain network, verify the first digital signature by using a public key of the first federated entity, and send a first invocation response to the first federated entity if the first digital signature is verified; the first invocation response includes a network address of the second processing entity;
the first federated entity is configured to send a network address of the second processing entity to the first processing entity;
the first processing entity is configured to access the second processing entity based on a network address of the second processing entity.
In some embodiments, the first call response further comprises: the information to be transmitted and a second digital signature obtained by encrypting the network address of the second processing entity and the information to be transmitted by using a private key of the second joint entity are obtained, wherein the information to be transmitted comprises a first access token distributed by the second joint entity;
the first federated entity is further configured to verify the second digital signature using a public key of the second federated entity before sending the network address of the second processing entity to the first processing entity, and if the second digital signature is verified, perform the step of sending the network address of the second processing entity to the first processing entity.
In some embodiments, the first processing entity comprises a first management entity and a first service entity; the second processing entity comprises a second management entity and a second service entity; the information to be transmitted also comprises a third digital signature obtained by encrypting the first access token and the network address of the second management entity by using a private key of the second association entity;
the first management entity is used for receiving the first access token and the third digital signature sent by the first joint entity;
the first management entity is further configured to send a second invocation request to the second management entity, where the second invocation request includes the first access token and the third digital signature;
the second management entity is configured to respond to the second invocation request, obtain a public key of the second federated entity, and verify the third digital signature by using the public key of the second federated entity; if the third digital signature is verified, sending the second call response to the first management entity, wherein the second call response comprises the network address of the second service entity;
the first management entity is further configured to send a network address of the second service entity to the first service entity;
the first service entity is used for accessing the second service entity based on the network address of the second service entity.
In some embodiments, the second call response further comprises: the second access token distributed by the second management entity and a fourth digital signature obtained by encrypting the second access token and the network address of the second service entity by using a private key of the second management entity;
the first service entity is further configured to receive the second access token and the fourth digital signature sent by the first management entity;
the first service entity is specifically configured to send a third invocation request to the second service entity based on a network address of the second service entity, where the third invocation request includes the second access token and the fourth digital signature;
the second service entity is specifically configured to, in response to the third invocation request, obtain a public key of the second management entity, verify the fourth digital signature by using the public key of the second management entity, and provide a service to the first service entity if the fourth digital signature passes verification.
In some embodiments, the first processing entity further comprises a first platform management entity;
the first management entity is specifically configured to send the network address of the second service entity to the first platform management entity;
the first platform management entity is configured to forward the network address of the second service entity to the first service entity.
In some embodiments, the blockchain network stores entity information of a second federated entity in the provider system and service information of a service provided by the provider system;
the first federated entity is specifically configured to search entity information of a federated entity corresponding to the specified service information from the blockchain network.
In some embodiments, the requestor system is a multi-access edge computing MEC system or a cloud system and the provider system is an MEC system.
The embodiment of the disclosure has the following beneficial effects:
in the inter-system authentication method and system provided by the embodiment of the present disclosure, the first federated entity of the requester system may obtain entity information of the second federated entity of the provider system from the blockchain network, and send a call request to the second federated entity. The second federated entity can acquire the entity information of the first federated entity from the blockchain network, so that the public key of the first federated entity is used for verifying the identity of the first federated entity, and the network address of the second processing entity in the provider system is returned to the first federated entity after the verification is passed, so that the requester system can access the second processing entity. That is, in the embodiment of the present disclosure, before providing a service, the provider system verifies the identity of the requestor to confirm that the other party is a system that is in mutual federation with itself, and if the verification passes on the requestor system, the requestor system is allowed to access to provide the service for the requestor, so that a situation that a malicious device spoofs the identity to trick the service of the provider system can be avoided, and thus the security of the edge computing service of the MEC system is improved.
Of course, not all advantages described above need to be achieved at the same time to practice any one product or method of the present disclosure.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other embodiments can be obtained by referring to these drawings.
Fig. 1 is a schematic structural diagram of an inter-system authentication system according to an embodiment of the present disclosure;
fig. 2 is a flowchart of an inter-system authentication method according to an embodiment of the present disclosure;
fig. 3 is a flowchart of another inter-system authentication method according to an embodiment of the present disclosure;
fig. 4 is a flowchart of another inter-system authentication method provided by the embodiment of the present disclosure;
fig. 5 is a flowchart of another inter-system authentication method provided by the embodiment of the present disclosure;
fig. 6 is a schematic structural diagram of another inter-system authentication system according to an embodiment of the present disclosure.
Detailed Description
The technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the described embodiments are only a part of the embodiments of the present disclosure, and not all of the embodiments. All other embodiments that can be derived from the disclosure by one of ordinary skill in the art based on the embodiments in the disclosure are intended to be within the scope of the disclosure.
An Edge Computing capability cross-domain open flow including MEC system discovery, MEC platform discovery, and information exchange processes is defined in the European telecommunications standardization Institute Group Report Mobile Edge Computing 035 (ETSI GR MEC 035) Standard, and the ETSI GS MEC 003 Standard defines an architecture for Edge Computing capability cross-domain opening. The MEC system may provide edge computing capability to other MEC systems or systems such as cloud systems that conform to the 3GPP Northbound interface generic API Framework (CAPIF), where 3GPP is 3rd Generation Partnership Project; the API is an Application Programming Interface, i.e., an Application program Interface. However, the identity authentication process of entities at each level between MEC systems is not defined by the current standard, and if identity authentication is not performed between entities at each level, the result of spoofing identity to obtain edge computing service may be caused.
In order to improve the security of the inter-system communication, the embodiments of the present disclosure provide an inter-system authentication method, which is applied in an inter-system authentication system. As shown in fig. 1, the inter-system authentication system includes: a requestor system 1, a provider system 2, and a blockchain network 3, the requestor system 1 comprising: a first federated entity 11 and a first processing entity 12; the provider system 2 includes: a second federated entity 21 and a second processing entity 22. The number of systems included in the inter-system authentication system is not limited to the number shown in fig. 1. The requestor system may be an MEC system or a cloud system and the provider system may be an MEC system. That is, the MEC system may function as both a requester system and a provider system. The MEC system functions as a requester system in the embodiment of the present disclosure when requesting to provide a service to another system, or functions as a provider system in the embodiment of the present disclosure when providing a service to another system. For example, when the MEC system a provides edge computing services to the terminal, a specified service in the MEC system B needs to be called, and then the MEC system a serves as a requester system and the MEC system B serves as a provider system.
The blockchain network 3 is used for storing entity information of the federated entities in each system with a federation relationship. Wherein the entity information comprises a network address and a public key. The network address may be an Internet Protocol (IP) address or a domain name, etc. As shown in fig. 1, the blockchain network 3 includes a plurality of blockchains. Two blockchains are exemplarily shown in fig. 1, and the number of blockchains included in the blockchain network is not limited thereto.
A first federated entity 11 for handling interaction issues with the provider system 2.
A second federated entity 21 for handling interaction matters with the requesting system 1.
A first processing entity 12 for requesting the provider system 2 to provide a service.
A second processing entity 22 for managing and implementing services that the provider system 2 may provide.
In the case where the requesting system 1 is an MEC system, the first federated entity 11 is an MEC Federator (MEF) entity, and the first processing entity 12 may include: an MEC orchestration Management (MEO) entity, an MEC platform management (MEPM) entity, and an MEC platform (MEP) entity. The MEO entity is used for managing each device and each MEC application in the MEC system. The MEPM entity is used for managing the life cycle of each MEC application and managing each MEP entity. The MEP entity is used for bearing the MEC application, so that the edge operation service is provided by running the MEC application. In the case where the requesting system 1 is a cloud system, the first federated entity 11 is a cloud management (CManager) entity, and the first processing entity 12 comprises: cloud entity1 (center 1) and cloud entity2 (center 2).
In case the provider system 2 is an MEC system, the second federated entity 21 is an MEF entity and the second processing entity 22 comprises an MEO entity and an MEP entity.
Hereinafter, MEF entity is abbreviated as MEF, MEO entity is abbreviated as MEO, MEPM entity is abbreviated as MEPM, MEP entity is abbreviated as MEP, CManager entity is abbreviated as CManager.
With reference to fig. 1, an embodiment of the present disclosure provides an inter-system authentication method, as shown in fig. 2, including the following steps:
s201, the first joint entity acquires entity information of the second joint entity from the block chain network. Wherein the entity information comprises a network address and a public key.
System information for systems federating with each other may be stored in a blockchain network. For example, the blockchain network may store entity information for a first federated entity in the requestor system. And the blockchain network may correspond to storing entity information for a second federated entity in the provider system and service information for services provided by the provider system. The service information may include an Identity Document (ID) of the service, a service profile, and the like. At this time, the first federated entity may search entity information of the federated entity corresponding to the specified service information from the blockchain network, where the specified service information may be an ID of the specified service requested by the requestor system, so as to search the entity information of the federated entity in the provider system providing the specified service.
Or, the blockchain network may store entity information of the second federated entity and an entity identifier of the second federated entity in the provider system, and at this time, the first federated entity may search for entity information corresponding to the entity identifier of the second federated entity from the blockchain network. Or, the blockchain network may store entity information of the second federated entity in the provider system and a system identifier of the provider system, and at this time, the first federated entity may search for entity information corresponding to the system identifier of the provider system from the blockchain network. Or the first federated entity may also search the entity information of the second federated entity from the blockchain network in other manners, the embodiment of the present disclosure does not limit the specific form of storing the entity information in the blockchain network and the specific manner in which the first federated entity searches the entity information of the second federated entity from the blockchain network.
In the embodiment of the present disclosure, in a requester system, when a first processing entity needs to invoke a specified service of a provider system, a notification message may be sent to a first federated entity, where the notification message may include a system identifier of the provider system, an entity identifier of a second federated entity, or a specified service identifier. After the first federated entity receives the notification message, S201 is executed to acquire the entity information of the second federated entity from the blockchain network.
S202, the first federated entity sends a first calling request to the second federated entity according to the entity information of the second federated entity.
The first call request includes: the identity information of the first federated entity and a first digital signature obtained by encrypting the identity information of the first federated entity by using a private key of the first federated entity are obtained. The first federated entity can perform a preset hash (hash) operation on the identity information of the first federated entity to obtain a hash value, and encrypt the hash value by using a private key of the first federated entity to obtain a first digital signature. For example, the identity information includes a network address.
S203, the second federated entity responds to the first call request and acquires the entity information of the first federated entity from the blockchain network.
In the embodiment of the present disclosure, since the entity information of the federated entity stored in the blockchain network includes the network address and the public key, the second federated entity may search the entity information including the network address of the first federated entity from the blockchain network, thereby obtaining the public key of the first federated entity.
S204, the second federated entity verifies the first digital signature by using the public key of the first federated entity.
And the second federated entity decrypts the first digital signature by using the public key of the first federated entity to obtain a decrypted result. And performing preset hash operation on the identity information included in the first calling request to obtain a hash value. And comparing whether the decryption result is the same as the hash value. If the first digital signature is the same, the first digital signature is verified. If not, the first digital signature is not verified.
Since for a pair of the public key and the private key, the data encrypted by the private key can be decrypted by using the public key. If the decryption result obtained by the second federated entity after decrypting the first digital signature by using the public key of the first federated entity is the same as the hash value obtained by the first federated entity before encrypting by using the first digital signature, it indicates that the key used by the first federated entity is a pair with the key used by the second federated entity, and the second federated entity uses the public key of the first federated entity, so the first federated entity uses the private key of the first federated entity. Since the private key is not public and can only be used by itself, the entity sending the first invocation request is indicated as the first federated entity.
Therefore, the second federated entity can verify whether the entity sending the first invocation request uses the private key of the first federated entity by comparing whether the hash value and the decryption result are the same, thereby verifying whether the entity sending the first invocation request spoofs the identity. If the identity information is the same as the identity information, the identity information is not counterfeited, and the identity information is not tampered, so that the verification is determined to be passed; if not, the description may counterfeit the identity and the identity information may have been tampered with, thus determining that the authentication failed.
And S205, if the second federated entity passes the verification of the first digital signature, sending a first call response to the first federated entity. Wherein the first invocation response includes the network address of the second processing entity.
Optionally, in order to further improve the communication security, the first federated entity and the second federated entity may also encrypt information to be transmitted using a public key of the other party, so that the other party decrypts the encrypted information using its own private key after receiving the encrypted information. For example, the first federated entity may encrypt the identity information of the first federated entity and the first digital signature using a public key of the second federated entity to obtain an encrypted data packet, and then send the encrypted data packet to the second federated entity by carrying the encrypted data packet in the first invocation request. And after receiving the first calling request, the second federated entity decrypts the encrypted data packet by using the private key of the second federated entity to obtain the identity information and the first digital signature of the first federated entity.
In embodiments of the disclosure, the second federated entity may deny access to the requestor system if the first digital signature is not verified. For example, the denial may be such that the second federated entity sends a message to the first federated entity indicating denial of access, or does not send a message to the first federated entity.
S206, the first united entity sends the network address of the second processing entity to the first processing entity.
The network address may be an IP address or a domain name, etc.
S207, the first processing entity accesses the second processing entity based on the network address of the second processing entity.
In the inter-system authentication method provided by the embodiment of the present disclosure, the first federated entity of the requester system may obtain entity information of the second federated entity of the provider system from the blockchain network, and send a call request to the second federated entity. The second federated entity can acquire the entity information of the first federated entity from the blockchain network, so that the public key of the first federated entity is used for verifying the identity of the first federated entity, and the network address of the second processing entity in the provider system is returned to the first federated entity after the verification is passed, so that the requester system can access the second processing entity. That is, in the embodiment of the present disclosure, before providing a service, the provider system verifies the identity of the requester system first, so as to confirm that the other party is a system that is in mutual federation with the provider system, and if the requester system passes verification, the requester system is allowed to access, so as to provide a service for the requester, so that a situation that a malicious device spoofs the identity to cheat the service of the provider system can be avoided, and thus the security of the edge computing service of the MEC system is improved.
In some embodiments, during an interaction between a first federated entity and a second federated entity, the first federated entity may verify the identity of the second federated entity in addition to the second federated entity may verify the identity of the first federated entity.
For the first federated entity to verify the identity of the second federated entity, the first invocation response sent by the second federated entity to the first federated entity further includes: and the information to be transmitted and a second digital signature obtained by encrypting the network address of the second processing entity and the information to be transmitted by using a private key of the second joint entity. Wherein the information to be transmitted comprises a first access token (access token) assigned by the second federated entity. The second association entity may perform a preset hash operation on the network address of the second processing entity and the information to be transmitted to obtain a digest, and perform an encryption operation on the digest by using a private key of the second association entity to obtain a second digital signature.
Optionally, the information to be transmitted may further include an access token type (token type), an effective duration (expires _ in) refresh token (refresh token), and the like.
In this case, before the first federated entity sends the network address of the second processing entity to the first processing entity in S206, the first federated entity verifies the second federated entity in the following manner: the first federated entity verifies the second digital signature using the public key of the second federated entity, and if the second digital signature is verified, the step of S206 sending the network address of the second processing entity to the first processing entity is executed.
The principle of the first federated entity using the second federated entity's public key to authenticate the second federated entity is similar to the above-described principle of the second federated entity using the first federated entity's public key to authenticate the first federated entity. That is, the first federated entity may decrypt the second digital signature using the public key of the second federated entity to obtain a decrypted result. And performing hash operation on the network address of the second processing entity and the information to be transmitted to obtain a hash value. And comparing whether the decryption result is the same as the hash value. If the identity of the second processing entity is the same as the identity of the first processing entity, the second processing entity does not copy the identity, and the network address of the second processing entity and the information to be transmitted are not tampered, so that the verification is determined to be passed; if not, it is indicated that the second federated entity may counterfeit its identity, and the network address of the second processing entity and the information to be transmitted may have been tampered with, thus determining that the authentication is not passed.
By adopting the method, in the embodiment of the present disclosure, the first federated entity may also verify the identity of the second federated entity, and only after the verification is passed, the first federated entity sends the network address of the second processing entity in the provider system to the first processing entity. Therefore, the situation that the first united entity responds to the tampered first call response sent by the malicious device is avoided, and the inter-system communication safety is improved.
The authentication process between the first federated entity and the second federated entity may be referred to as a top-level trust construction process, and since the entities in the requester system and the provider system are both hierarchically arranged, after the top-level trust construction is completed, in order to further ensure the security of communication, the embodiments of the present disclosure further provide a bottom-level trust transfer mechanism between other hierarchies. The underlying trust transfer process is described below.
In some embodiments, the first processing entity includes a first management entity and a first service entity. The second processing entity includes a second management entity and a second service entity. The entities have a hierarchical relationship, specifically, the lower level entity of the first joint entity is a first management entity, and the lower level entity of the first management entity is a first service entity. The next-level entity of the second federated entity is a second management entity, and the next-level entity of the second management entity is a second service entity.
When the requesting system is the MEC system, the first management entity is the MEO, and the first service entity is the MEP. In the case that the requesting system is a cloud system, the first management entity is a center 1, the first service entity is a center 2, and the cloud entity1 and the cloud entity2 are different cloud entities respectively. And under the condition that the provider system is an MEC system, the second management entity is an MEO, and the second service entity is an MEP.
In this case, the network address of the second processing entity is specifically a network address of the second management entity, that is, a network address of a next-level entity of the second federated entity.
In order to improve the security of the intersystem communication, the information to be transmitted further comprises a third digital signature obtained by encrypting the first access token and the network address of the second management entity by using the private key of the second federated entity. The second federated entity may encrypt the first access token and the network address of the second management entity using its own private key, to obtain a third digital signature.
In this case, the first federated entity needs to send the first access token and the third digital signature to the first administrative entity in addition to the network address of the second administrative entity. That is, the first access token and the third digital signature sent by the first federated entity are also received before the first administrative entity accesses the second processing entity.
Referring to fig. 3, the manner in which the first processing entity accesses the second processing entity in S207 may be implemented as the following steps:
s2071, the first management entity sends a second call request to the second management entity. Wherein the second invocation request includes the first access token and the third digital signature.
And S2072, the second management entity obtains the public key of the second federated entity in response to the second call request, and verifies the third digital signature by using the public key of the second federated entity.
The second management entity may obtain the public key of the second federated entity from a Certificate Authority (CA) entity of the provider system, for example, the second management entity may obtain the public key of the second federated entity from the CA entity at intervals, or obtain the public key of the second federated entity from the CA entity in real time after receiving the second invocation request. And then the second management entity decrypts the third digital signature by using the public key of the second combination entity to obtain a decryption result. And performing hash operation on the first access token and the network address of the second management entity to obtain a hash value, and comparing whether the hash value is the same as the decryption result. If the first access token is the token distributed by the second federated entity, the first access token is not tampered, the second federated entity verifies the first federated entity, and therefore the second management entity can communicate with the first management entity, and therefore the third digital signature is determined to be verified; if not, the verification is determined not to be passed.
And S2073, if the second management entity passes the verification of the third digital signature, sending a second call response to the first management entity. Wherein the second invocation response includes the network address of the second service entity.
S2074, the first management entity sends the network address of the second service entity to the first service entity.
In this embodiment of the disclosure, in a case that the requesting system is an MEC system, the first processing entity further includes a first platform management entity, and the first platform management entity is an MEPM. The next-level entity of the first management entity is a first platform management entity, and the next-level entity of the first platform management entity is a first service entity. In this case, the first management entity may send the network address of the second service entity to the first platform management entity, and then the first platform management entity forwards the network address of the second service entity to the first service entity.
In the case where the requesting system is a cloud system, the first management entity is center 1 and the first service entity is center 2. The center 1 may send the network address of the second service entity directly to the center 2.
S2075, the first service entity accesses the second service entity based on the network address of the second service entity.
And after receiving the network address of the second service entity, the first service entity accesses the second service entity based on the network address of the second service entity.
By adopting the method, the second management entity can verify the authenticity of the first access token by verifying the third digital signature, so that the identity of the first management entity is verified, and the second management entity responds to the second calling request sent by the first management entity only under the condition that the upper-level entity of the second management entity passes the verification of the upper-level entity of the first management entity, namely under the condition that the second joint entity passes the verification of the first joint entity, so that the condition that the second management entity responds to the tampered second calling request sent by a malicious entity is avoided, and the inter-system communication safety is improved.
In order to further improve the security of the inter-system communication, the second call response returned by the second management entity to the first management entity further includes: the second access token distributed by the second management entity and a fourth digital signature obtained by encrypting the second access token and the network address of the second service entity by using a private key of the second management entity. After the second management entity verifies the third digital signature in S2072, that is, after the identity of the first management entity is verified, the second management entity may allocate a second access token (access token), and encrypt the second access token and the network address of the second service entity using its own private key, so as to obtain a fourth digital signature.
In this case, the first management entity needs to send the second access token and the fourth digital signature to the first service entity in addition to sending the network address of the second service entity to the first service entity. I.e. before the first service entity accesses the second service entity, the second access token and the fourth digital signature sent by the first management entity are also received.
The above manner of accessing the second service entity by the first service entity in S2075 may be implemented as the following two steps:
step one, the first service entity sends a third calling request to the second service entity. Wherein the third invocation request includes the second access token and the fourth digital signature.
And step two, the second service entity responds to the third calling request, acquires the public key of the second management entity, verifies the fourth digital signature by using the public key of the second management entity, and provides service for the first service entity if the fourth digital signature passes verification. The second service entity can provide services such as edge calculation and the like for the first service entity, and can also return data generated in the service process and a service result to the first service entity.
The second serving entity may obtain the public key of the second management entity from the CA entity of the provider system. And then, the public key of the second management entity is utilized to decrypt the fourth digital signature to obtain a decryption result. And performing hash operation on the second access token and the network address of the second service entity to obtain a hash value, and comparing whether the hash value and the decryption result are the same. If the first access token is the same as the second access token, the second access token is the token distributed by the second management entity and is not tampered, the second management entity verifies the first management entity, and therefore the second service entity can communicate with the first service entity, and therefore the verification is determined to be passed; if not, the verification is determined not to pass.
Optionally, the third invocation request may further include a service identifier of the specified service requested to be invoked, so that the second service entity may provide the corresponding service for the first service entity according to the service identifier. Or, in the case that the second service entity can only provide one service, the third invocation request may not carry the service identifier.
By adopting the method, the second service entity can verify the authenticity of the second access token in a mode of verifying the fourth digital signature, so that the identity of the first service entity is verified, and the second service entity provides service for the first service entity only under the condition that the upper-level entity of the second service entity passes the verification of the upper-level entity of the first service entity, namely under the condition that the second management entity passes the verification of the first management entity, so that the condition that the second service entity responds to a tampered third call request sent by a malicious entity is avoided, and the inter-system communication security is improved.
The following describes an overall flow of the inter-system authentication method provided in the embodiment of the present disclosure with reference to a specific application scenario.
Referring to fig. 4, taking the requesting system as the MEC1 system and the providing system as the MEC2 system as an example, the MEC1 system includes: MEF1, MEO1, MEPM1, and MEP 1; the MEC2 system includes: MEF2, MEO2, MEP2, and CA 2. The inter-system authentication process is as follows:
s401, MEF1 obtains the network address and public key of MEF2 from the blockchain network.
S402, MEF1 sends a first invocation request to MEF2 based on the network address of MEF 2.
S403, MEF2 obtains the public key of MEF1 from the blockchain.
S404, the MEF2 verifies the first digital signature included in the first calling request by using the public key of the MEF1, if the first digital signature passes the verification, the access token is distributed, and the network addresses of the access token and the MEO2 are encrypted by using the private key of the MEF2 to obtain a third digital signature; and encrypting the network address of the access token and the MEO2, the third digital signature, the token type, the expires _ in and the refresh token by using the private key of the access token and the MEO2 to obtain a second digital signature.
S405, MEF2 sends a first call response to MEF 1. Wherein the first call response comprises the access token, the network address of the MEO2, the third digital signature, the token type, the expires _ in, the refresh token, and the second digital signature.
S406, MEF1 verifies the second digital signature using the public key of MEF 2.
S407, MEF1, if the verification passes, sends an access token, the network address of MEO2, and the third digital signature to MEO 1.
S408, MEO1 sends a second invocation request to MEO2 based on the network address of MEO 2. The second call request includes the access token, the network address of MEO2, and a third digital signature.
In addition, MEF1 may also send token type, expires _ in, and refresh token to MEO1 if the validation passes. Wherein the MEO1 may determine whether the access token is expired based on expires _ in, and if so, the MEO1 may obtain a new access token using the refresh token.
The MEO1 may obtain the type of the access token through the token type sent by the MEF1, and carry the type of the access token in the second call request. For example, the token type may be a holder (bearer) or a Message Authentication Code (MAC).
S409, MEO2 obtains the public key of MEF2 from CA 2.
S410, the MEO2 authenticates the third digital signature by using the public key of the MEF2, if the authentication is passed, the access token is distributed, and the access token and the network address of the MEP2 are encrypted by using the private key of the MEO2, so that a fourth digital signature is obtained.
S411, MEO2 returns a second call response to MEO 1. Wherein the second call response comprises: access token, network address of MEP2, and fourth digital signature. Optionally, the second call response may further include: token type, expires _ in and refresh token.
S412, MEO1 sends access token, the network address of MEP2, and the fourth digital signature to MEPM 1. Optionally, MEO1 may also send token type, expires _ in, and refresh token to MEPM 1.
S413, MEPM1 sends access token, the network address of MEP2, and the fourth digital signature to MEP 1. Optionally, the MEPM1 may also send token type, expires _ in, and refresh token to the MEP 1.
S414, MEP1 sends a third invocation request to MEP2 based on the network address of MEP 2. Wherein the third call request includes an access token and a fourth digital signature.
The MEP1 may determine whether the access token is expired based on expires _ in, and if so, the MEP1 may acquire a new access token using refresh token. The MEP1 may obtain the type of the access token based on the token type sent by the MEPM1, and carry the type of the access token in the third call request.
S415, MEP2 obtains the public key of MEO2 from CA 2.
S416, MEP2 verifies the fourth digital signature using the public key of MEO 2.
S417, MEP2 provides service to MEP1 if the verification is passed.
Referring to fig. 5, taking the requesting system as a cloud system and the providing system as an MEC2 system as an example, the cloud system includes: CManager, center 1, and center 2; the MEC2 system includes: MEF2, MEO2, MEP2, and CA 2. The inter-system authentication process is as follows:
s501, CManager obtains the network address and the public key of the MEF2 from the blockchain network.
S502, the CManager sends a first calling request to the MEF 2.
S503, MEF2 obtains the public key of CManager from the blockchain.
S504, the MEF2 verifies the first digital signature included in the first calling request by using the public key of the CManager, if the first digital signature passes the verification, the access token is distributed, and the network addresses of the access token and the MEO2 are encrypted by using the private key of the MEF2 to obtain a third digital signature. And encrypting the network address of the access token and the MEO2, the third digital signature, the token type, the expires _ in and the refresh token by using the private key of the access token and the MEO2 to obtain a second digital signature.
S505, the MEF2 sends a first call response to the CManager. Wherein the first call response comprises the access token, the network address of the MEO2, the third digital signature, the token type, the expires _ in, the refresh token, and the second digital signature.
S506, the CManager verifies the second digital signature by using the public key of the MEF 2.
S507, if the CManager passes the verification, the access token, the network address of the MEO2 and the third digital signature are sent to the center 1.
S508, center 1 sends a second call request to MEO2 based on the network address of MEO 2. The second call request includes the access token, the network address of MEO2, and a third digital signature.
In addition, the CManager may also send token type, expires _ in, and refresh token to the center 1 if the verification passes. The throughput 1 may determine whether the access token is expired based on the expires _ in, and if so, the throughput 1 may obtain a new access token using the refresh token.
The center 1 may obtain the type of the access token through the token type sent by the CManager, and carry the type of the access token in the second call request. For example, token type may be bearer or MAC.
S509, MEO2 obtains the public key of MEF2 from CA 2.
And S510, the MEO2 authenticates the third digital signature by using the public key of the MEF2, if the third digital signature passes the authentication, the access token is distributed, and the access token and the network address of the MEP2 are encrypted by using the private key of the MEO2 to obtain a fourth digital signature.
S511, MEO2 returns a second call response to center 1. Wherein the second call response comprises: access token, network address of MEP2, and fourth digital signature. Optionally, the second call response may further include: token type, expires _ in, and refresh token.
S512, center 1 sends access token, the network address of MEP2, and the fourth digital signature to center 2. Optionally, the center 1 may also send token type, expires _ in, and refresh token to the center 2.
S513, center 2 sends a third call request to MEP2 based on the network address of MEP 2. Wherein the third call request includes an access token and a fourth digital signature.
The center 2 may determine whether the access token is expired based on expires _ in, and if so, the center 2 may obtain a new access token by using refresh token. The center 2 can obtain the type of the access token through the token type sent by the center 1, and carry the type of the access token in the third call request.
S514, MEP2 obtains the public key of MEO2 from CA 2.
S515, MEP2 verifies the fourth digital signature using the public key of MEO 2.
S516, if the verification is passed, the MEP2 provides service to the center 2.
In the embodiment shown in FIG. 4, S401-S406 are top-level trust construction processes for two inter-system federated entities, and S407-S417 are bottom-level trust transfer processes between processing entities.
In the embodiment shown in FIG. 5, S501-S506 are top-level trust construction processes for two inter-system federated entities, and S507-S516 are bottom-level trust transfer processes between processing entities.
If the information of all entities in the system is recorded in the blockchain network, it is equivalent to exposing all entities in the system externally, which cannot meet the requirement of the MEC system with strict requirement of hierarchical arrangement. In the top trust construction process, the embodiment of the disclosure only stores the entity information of the joint entities in the system in the block chain network, and transmits the information of the next-level entity after the verification between the joint entities passes, thereby adapting to the requirements of the MEC system.
Moreover, in a conventional Public Key Infrastructure (PKI) mechanism, both a requester system and a provider system have CA entities, and when communication is performed between the systems, the CA entities of the two systems need to be docked by a third-party device, which results in higher cost of communication between the systems. In the process of the bottom trust transfer, each level of entity only trusts the information sent by the upper level of entity, namely, the public key of the upper level of entity verifies whether the received information is from the upper level of entity without the butt joint of CA entities among systems, so that the communication safety can be guaranteed on the basis of saving the cost.
Based on the same inventive concept, corresponding to the above method embodiment, the disclosed embodiment provides an inter-system authentication system, as shown in fig. 1, including a requester system 1, a provider system 2, and a blockchain network 3, where the requester system 1 includes: a first federated entity 11 and a first processing entity 12; the provider system 2 includes: a second federated entity 21 and a second processing entity 22, the blockchain network 3 is used for storing entity information of federated entities in each system with a federation relationship, the entity information includes a network address and a public key;
the first federated entity 11 is configured to obtain entity information of the second federated entity 21 from the blockchain network 3, and send a first invocation request to the second federated entity 21 according to the entity information of the second federated entity 21, where the first invocation request includes identity information of the first federated entity 11 and a first digital signature obtained by encrypting the identity information of the first federated entity 11 using a private key of the first federated entity 11;
the second federated entity 21 is configured to, in response to the first invocation request, obtain entity information of the first federated entity 11 from the blockchain network 3, verify the first digital signature by using the public key of the first federated entity 11, and send a first invocation response to the first federated entity 11 if the first digital signature is verified; the first invocation response includes the network address of the second processing entity 22;
a first federated entity 11 configured to send a network address of the second processing entity 22 to the first processing entity 12;
a first processing entity 12 for accessing a second processing entity 22 based on a network address of the second processing entity 22.
In some embodiments, the first call response further comprises: the information to be transmitted and a second digital signature obtained by encrypting the network address of the second processing entity 22 and the information to be transmitted by using a private key of the second federated entity 21, wherein the information to be transmitted comprises a first access token distributed by the second federated entity 21;
the first federated entity 11 is further configured to verify the second digital signature using the public key of the second federated entity 21 before sending the network address of the second processing entity 22 to the first processing entity 12, and if the second digital signature is verified, perform the step of sending the network address of the second processing entity 22 to the first processing entity 12.
As shown in fig. 6, in some embodiments, the first processing entity 12 comprises a first management entity 121 and a first service entity 122; the second processing entity 22 comprises a second management entity 221 and a second service entity 222; the information to be transmitted further includes a third digital signature obtained by encrypting the first access token and the network address of the second management entity 221 by using the private key of the second federated entity 21;
a first management entity 121, configured to receive the first access token and the third digital signature sent by the first federated entity 11;
the first management entity 121 is further configured to send a second invocation request to the second management entity 221, where the second invocation request includes the first access token and the third digital signature;
the second management entity 221, configured to, in response to the second invocation request, obtain the public key of the second federated entity 21, and verify the third digital signature by using the public key of the second federated entity 21; if the third digital signature is verified, sending a second invocation response to the first management entity 121, the second invocation response including the network address of the second service entity 222;
the first management entity 121, further configured to send the network address of the second service entity 222 to the first service entity 122;
the first serving entity 122 is configured to access the second serving entity 222 based on the network address of the second serving entity 222.
In some embodiments, the second call response further comprises: the second access token distributed by the second management entity 221 and a fourth digital signature obtained by encrypting the second access token and the network address of the second service entity 222 by using the private key of the second management entity 221;
the first service entity 122, further configured to receive the second access token and the fourth digital signature sent by the first management entity 121;
the first service entity 122 is specifically configured to send a third invocation request to the second service entity 222 based on the network address of the second service entity 222, where the third invocation request includes the second access token and the fourth digital signature;
the second service entity 222 is specifically configured to, in response to the third invocation request, obtain the public key of the second management entity 221, verify the fourth digital signature by using the public key of the second management entity 221, and provide a service to the first service entity 122 if the fourth digital signature passes the verification.
In some embodiments, as shown in fig. 6, the first processing entity 12 may further include a first platform management entity 123;
the first management entity 121 is specifically configured to send the network address of the second service entity 222 to the first platform management entity 123;
a first platform management entity 123 for forwarding the network address of the second service entity 222 to the first service entity 122.
In some embodiments, the blockchain network 3 stores entity information of the second federated entity in the provider system and service information of the service provided by the provider system;
the first federated entity 11 is specifically configured to search entity information of the federated entity corresponding to the specified service information from the blockchain network 3.
In some embodiments, the requestor system 1 is an MEC system or a cloud system and the provider system 2 is an MEC system.
It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure are included in the scope of protection of the present invention.

Claims (14)

1. An inter-system authentication method is applied to an inter-system authentication system, the inter-system authentication system comprises a requester system, a provider system and a blockchain network, and the requester system comprises: a first federated entity and a first processing entity; the provider system includes: the block chain network is used for storing entity information of the federated entities in each system with a federation relation, and the entity information comprises a network address and a public key; the method comprises the following steps:
the first federated entity obtains entity information of the second federated entity from the blockchain network, and sends a first call request to the second federated entity according to the entity information of the second federated entity, wherein the first call request comprises the identity information of the first federated entity and a first digital signature obtained by encrypting the identity information of the first federated entity by using a private key of the first federated entity;
the second federated entity responds to the first calling request, acquires entity information of the first federated entity from the blockchain network, verifies the first digital signature by using a public key of the first federated entity, and sends a first calling response to the first federated entity if the first digital signature is verified; the first invocation response includes a network address of the second processing entity;
the first federated entity sends the network address of the second processing entity to the first processing entity;
the first processing entity accesses the second processing entity based on the network address of the second processing entity.
2. The method of claim 1, wherein the first call response further comprises: the method includes that information to be transmitted and a second digital signature obtained by encrypting the network address of the second processing entity and the information to be transmitted by using a private key of the second federated entity are transmitted, the information to be transmitted includes a first access token distributed by the second federated entity, and before the first federated entity sends the network address of the second processing entity to the first processing entity, the method further includes:
and the first federated entity verifies the second digital signature by using the public key of the second federated entity, and if the second digital signature is verified, the step of sending the network address of the second processing entity to the first processing entity is executed.
3. The method of claim 2, wherein the first processing entity comprises a first management entity and a first service entity; the second processing entity comprises a second management entity and a second service entity; the information to be transmitted also comprises a third digital signature obtained by encrypting the first access token and the network address of the second management entity by using a private key of the second association entity;
before the first processing entity accesses the second processing entity based on the network address of the second processing entity, the method further comprises:
the first management entity receives the first access token and the third digital signature sent by the first federated entity;
the first processing entity accessing the second processing entity based on the network address of the second processing entity, including:
the first management entity sending a second invocation request to the second management entity, the second invocation request including the first access token and the third digital signature;
the second management entity responds to the second calling request, acquires a public key of the second federated entity, and verifies the third digital signature by using the public key of the second federated entity; if the third digital signature is verified, sending the second call response to the first management entity, wherein the second call response comprises the network address of the second service entity;
the first management entity sends the network address of the second service entity to the first service entity;
the first serving entity accesses the second serving entity based on the network address of the second serving entity.
4. The method of claim 3, wherein the second call response further comprises: the second access token distributed by the second management entity and a fourth digital signature obtained by encrypting the second access token and the network address of the second service entity by using a private key of the second management entity; before the first processing entity accesses the second processing entity based on the network address of the second processing entity, the method further comprises:
the first service entity receives the second access token and the fourth digital signature sent by the first management entity;
the first service entity accesses the second service entity based on the network address of the second service entity, including:
the first service entity sends a third calling request to the second service entity based on the network address of the second service entity, wherein the third calling request comprises the second access token and the fourth digital signature;
and the second service entity responds to a third calling request, acquires the public key of the second management entity, verifies the fourth digital signature by using the public key of the second management entity, and provides service for the first service entity if the fourth digital signature passes verification.
5. The method of claim 3, wherein the first processing entity further comprises a first platform management entity; the sending, by the first management entity, the network address of the second service entity to the first service entity includes:
the first management entity sends the network address of the second service entity to the first platform management entity;
the first platform management entity forwards the network address of the second service entity to the first service entity.
6. The method of claim 1, wherein the blockchain network stores entity information of a second federated entity in the provider system and service information of services provided by the provider system; the first federated entity obtains entity information of the second federated entity from the blockchain network, and the method comprises the following steps:
and the first joint entity searches entity information of the joint entity corresponding to the specified service information from the block chain network.
7. The method of claim 1, wherein the requestor system is a multi-access edge computing (MEC) system or a cloud system, and wherein the provider system is an MEC system.
8. An inter-system authentication system comprising a supplicant system, a provider system, and a blockchain network, the supplicant system comprising: a first federated entity and a first processing entity; the provider system includes: the block chain network is used for storing entity information of the federated entities in each system with a federation relation, and the entity information comprises a network address and a public key;
the first federated entity is configured to obtain entity information of the second federated entity from the blockchain network, and send a first invocation request to the second federated entity according to the entity information of the second federated entity, where the first invocation request includes the identity information of the first federated entity and a first digital signature obtained by encrypting the identity information of the first federated entity using a private key of the first federated entity;
the second federated entity is configured to, in response to the first invocation request, obtain entity information of the first federated entity from the blockchain network, verify the first digital signature by using a public key of the first federated entity, and send a first invocation response to the first federated entity if the first digital signature is verified; the first invocation response including a network address of the second processing entity;
the first federated entity is configured to send a network address of the second processing entity to the first processing entity;
the first processing entity is configured to access the second processing entity based on a network address of the second processing entity.
9. The inter-system authentication system of claim 8, wherein the first invocation response further comprises: the information to be transmitted and a second digital signature obtained by encrypting the network address of the second processing entity and the information to be transmitted by using a private key of the second federated entity are transmitted, wherein the information to be transmitted comprises a first access token distributed by the second federated entity;
the first federated entity is further configured to verify the second digital signature using a public key of the second federated entity before sending the network address of the second processing entity to the first processing entity, and if the second digital signature is verified, perform the step of sending the network address of the second processing entity to the first processing entity.
10. The inter-system authentication system of claim 9, wherein the first processing entity comprises a first management entity and a first service entity; the second processing entity comprises a second management entity and a second service entity; the information to be transmitted also comprises a third digital signature obtained by encrypting the first access token and the network address of the second management entity by using a private key of the second association entity;
the first management entity is used for receiving the first access token and the third digital signature sent by the first joint entity;
the first management entity is further configured to send a second invocation request to the second management entity, where the second invocation request includes the first access token and the third digital signature;
the second management entity is configured to, in response to the second invocation request, obtain a public key of the second federated entity, and verify the third digital signature by using the public key of the second federated entity; if the third digital signature is verified, sending the second call response to the first management entity, wherein the second call response comprises the network address of the second service entity;
the first management entity is further configured to send a network address of the second service entity to the first service entity;
the first serving entity is configured to access the second serving entity based on a network address of the second serving entity.
11. The inter-system authentication system of claim 10, wherein the second invocation response further comprises: the second access token distributed by the second management entity and a fourth digital signature obtained by encrypting the second access token and the network address of the second service entity by using a private key of the second management entity;
the first service entity is further configured to receive the second access token and the fourth digital signature sent by the first management entity;
the first service entity is specifically configured to send a third invocation request to the second service entity based on a network address of the second service entity, where the third invocation request includes the second access token and the fourth digital signature;
the second service entity is specifically configured to, in response to the third invocation request, obtain a public key of the second management entity, verify the fourth digital signature by using the public key of the second management entity, and provide a service to the first service entity if the fourth digital signature passes verification.
12. The inter-system authentication system of claim 10, wherein the first processing entity further comprises a first platform management entity;
the first management entity is specifically configured to send the network address of the second service entity to the first platform management entity;
the first platform management entity is configured to forward the network address of the second service entity to the first service entity.
13. The system-to-system authentication system of claim 8, wherein the blockchain network stores entity information of a second federated entity in the provider system and service information of a service provided by the provider system;
the first federated entity is specifically configured to search entity information of a federated entity corresponding to the specified service information from the blockchain network.
14. The inter-system authentication system of claim 8, wherein the requestor system is a multi-access edge computing or cloud system and the provider system is an MEC system.
CN202210634802.2A 2022-06-07 2022-06-07 Inter-system authentication method and system Active CN114978741B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210634802.2A CN114978741B (en) 2022-06-07 2022-06-07 Inter-system authentication method and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210634802.2A CN114978741B (en) 2022-06-07 2022-06-07 Inter-system authentication method and system

Publications (2)

Publication Number Publication Date
CN114978741A true CN114978741A (en) 2022-08-30
CN114978741B CN114978741B (en) 2024-03-19

Family

ID=82959447

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210634802.2A Active CN114978741B (en) 2022-06-07 2022-06-07 Inter-system authentication method and system

Country Status (1)

Country Link
CN (1) CN114978741B (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190026450A1 (en) * 2017-07-24 2019-01-24 Dell Products, Lp Method and apparatus for optimized access of security credentials via mobile edge-computing systems
CN111586017A (en) * 2020-04-29 2020-08-25 北京邮电大学 Method and device for authenticating communication user
CN112491829A (en) * 2020-11-13 2021-03-12 中移雄安信息通信科技有限公司 MEC platform identity authentication method and device based on 5G core network and block chain
CN112822675A (en) * 2021-01-11 2021-05-18 北京交通大学 MEC environment-oriented OAuth 2.0-based single sign-on mechanism

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190026450A1 (en) * 2017-07-24 2019-01-24 Dell Products, Lp Method and apparatus for optimized access of security credentials via mobile edge-computing systems
CN111586017A (en) * 2020-04-29 2020-08-25 北京邮电大学 Method and device for authenticating communication user
CN112491829A (en) * 2020-11-13 2021-03-12 中移雄安信息通信科技有限公司 MEC platform identity authentication method and device based on 5G core network and block chain
CN112822675A (en) * 2021-01-11 2021-05-18 北京交通大学 MEC environment-oriented OAuth 2.0-based single sign-on mechanism

Also Published As

Publication number Publication date
CN114978741B (en) 2024-03-19

Similar Documents

Publication Publication Date Title
US10706427B2 (en) Authenticating and enforcing compliance of devices using external services
CN109511115B (en) Authorization method and network element
TWI466553B (en) Home node-b/home evolved node b and method fo authenticating the same with a network
US20200186358A1 (en) Persistent network device authentication
US11303431B2 (en) Method and system for performing SSL handshake
US11689367B2 (en) Authentication method and system
US20070036110A1 (en) Access control of mobile equipment to an IP communication network with dynamic modification of the access policies
US12058258B2 (en) Crypto tunnelling between two-way trusted network devices in a secure peer-to-peer data network
US20100306820A1 (en) Control of message to be transmitted from an emitter domain to a recipient domain
US20220400102A1 (en) Crypto-signed switching between two-way trusted network devices in a secure peer-to-peer data network
US11924229B2 (en) Distributed security in a secure peer-to-peer data network based on real-time sentinel protection of network devices
US10893414B1 (en) Selective attestation of wireless communications
US20230209345A1 (en) Device-specific selection between peer-to-peer connections and core-based hybrid peer-to-peer connections in a secure data network
US11582201B1 (en) Establishing and maintaining trusted relationship between secure network devices in secure peer-to-peer data network based on obtaining secure device identity containers
US12081558B2 (en) Distributed security in a secure peer-to-peer data network based on real-time guardian protection of network devices
JPWO2014207929A1 (en) Information processing apparatus, terminal, information processing system, and information processing method
US11870899B2 (en) Secure device access recovery based on validating encrypted target password from secure recovery container in trusted recovery device
US11949717B2 (en) Distributed security in a secure peer-to-peer data network based on real-time navigator protection of network devices
US20230111701A1 (en) Secure keyboard resource limiting access of user input to destination resource requesting the user input
CN114978741B (en) Inter-system authentication method and system
CN112865975B (en) Message security interaction method and system and signaling security gateway device
Edris et al. Security in network services delivery for 5g enabled d2d communications: Challenges and solutions
KR100463751B1 (en) Method for generating packet-data in wireless-communication and method and apparatus for wireless-communication using that packet-data
US12010245B2 (en) Secure assistance for asynchronous task completion by unavailable endpoint device upon restored availability in a secure peer-to-peer data network
JP7573104B2 (en) Authentication method and system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant