WO2022227069A1 - Method and apparatus for cloud federation authorization - Google Patents

Method and apparatus for cloud federation authorization Download PDF

Info

Publication number
WO2022227069A1
WO2022227069A1 PCT/CN2021/091686 CN2021091686W WO2022227069A1 WO 2022227069 A1 WO2022227069 A1 WO 2022227069A1 CN 2021091686 W CN2021091686 W CN 2021091686W WO 2022227069 A1 WO2022227069 A1 WO 2022227069A1
Authority
WO
WIPO (PCT)
Prior art keywords
chain
data
indicator
retrieve request
log
Prior art date
Application number
PCT/CN2021/091686
Other languages
French (fr)
Inventor
Jingyu FENG
Original Assignee
Nokia Technologies Oy
Nokia Solutions And Networks Investment (China) Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy, Nokia Solutions And Networks Investment (China) Co., Ltd. filed Critical Nokia Technologies Oy
Priority to PCT/CN2021/091686 priority Critical patent/WO2022227069A1/en
Publication of WO2022227069A1 publication Critical patent/WO2022227069A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures

Definitions

  • Various example embodiments relate to cloud federation authorization.
  • Cloud federation further improves cost advantage of cloud computing by enabling use of plural clouds or sub-clouds.
  • access control and actual use of the information may then be exposed to single points of failure.
  • some mechanisms need to be provided to synchronize or distribute information.
  • a method for cloud federation authorization comprising:
  • the method may further comprise registering members of a data alliance in the indicator-chain so that members of the indicator-chain can query other members from the indicator-chain.
  • the method may further comprise registering the LSC in the respective log-chain.
  • the method may further comprise registering the ISC in the indicator-chain.
  • the indicator-chain may be a consortium blockchain.
  • the method may further comprise storing in the indicator-chain identity certificates of a plurality of log-chains, wherein each log-chain is a private blockchain of one data sub-cloud.
  • the verifying whether the data retrieve request is permissible may comprise determining using both the LSC and the ISC whether the data retrieve request is permissible for the requesting member.
  • the verifying whether the data retrieve request is permissible may comprise verifying that the requesting member indicated by the identity is one of the members of the data alliance.
  • the verifying whether the data retrieve request is permissible may comprise verifying that the LSC defines the requesting member as permitted receiver of the requested data.
  • a method in log-chain equipment for cloud federation authorization comprising:
  • the method may further comprise registering the LSC in the log-chain.
  • the indicator-chain may be a consortium blockchain to which only members of a data alliance authorized to have a read and write access.
  • the method may further comprise registering an identity certificate of the log-chain in an indicator-chain of the data alliance via the cross-chain.
  • an indicator-chain maintaining for members of a data alliance an indicator-chain, the indicator-chain being a consortium blockchain; wherein different ones of the members have different sub-clouds and respective log-chains;
  • the method may further comprise registering the members of the data alliance in the indicator-chain so that the members of the indicator-chain can query other members from the indicator-chain.
  • the method may further comprise registering in the indicator-chain identity certificates of a plurality of log-chains, wherein each log-chain is a private blockchain of one data sub-cloud.
  • the method may further comprise receiving the identity certificates from the blockchains via respective cross-chains.
  • the method may further comprise exchanging information between the indicator-chain and the plurality of log-chains via respective cross-chains.
  • the indicator-chains may authenticate the log-chains using their identity certificates.
  • the verifying whether the data retrieve request is permissible may comprise determining using both the LSC and the ISC whether the data retrieve request is permissible for the requesting member.
  • the verifying whether the data retrieve request is permissible may comprise verifying that the requesting member indicated by the identity is one of the members of the data alliance.
  • the verifying whether the data retrieve request is permissible may comprise verifying that the LSC defines the requesting member as permitted receiver of the requested data.
  • a computer program comprising computer executable program code configured to execute any method of any of the example aspects.
  • the computer program may be stored in a computer readable memory medium.
  • Any foregoing memory medium may comprise a digital data storage such as a data disc or diskette, optical storage, magnetic storage, holographic storage, opto-magnetic storage, phase-change memory, resistive random-access memory, magnetic random-access memory, solid-electrolyte memory, ferroelectric random access memory, organic memory or polymer memory.
  • the memory medium may be formed into a device without other substantial functions than storing memory or it may be formed as part of a device with other functions, including but not limited to a memory of a computer, a chip set, and a sub assembly of an electronic device.
  • an apparatus comprising a memory and a processor that are configured to cause the apparatus to perform the method of any of the first to third example aspects.
  • an apparatus comprising means for performing the method of any of the first to third example aspects.
  • Fig. 1 shows an architectural drawing of a system of an example embodiment
  • Fig. 2 shows a block diagram of an apparatus of an example embodiment
  • Fig. 3 shows a flow chart of a process of an example embodiment
  • Fig. 4 shows a flow chart of a process of an example embodiment
  • Fig. 5 shows a flow chart of a process of an example embodiment in a system
  • Fig. 6 shows a flow chart of a process of an example embodiment in a log-chain for cloud federation authorization
  • Fig. 7 shows a flow chart of a process of an example embodiment in an indicator-chain for cloud federation authorization.
  • Fig. 1 shows an architectural drawing of a system 100 of an example embodiment.
  • the system 100 comprises four entities: a first entity 110, a second entity 120, a third entity 130, and a fourth entity 140.
  • Fig. 1 further shows, for respective entities, first to fourth sub-clouds 112, 122, 132, 142; first to fourth log-chains 114, 124, 134, 144; first to fourth blocks 116, 126, 136, 146 in respective first to fourth log-chains 114, 124, 134, 144; first to fourth cross-chains 118, 128, 138, 148; and first to fourth users 119, 129, 139, 149.
  • term user refers to equipment used by a human or machine user for uploading or accessing data. Letters A to D are also used to aid understanding referencing to different entities.
  • the cross-chains are here drawn to be comprised by the entities, they could also be considered as part of a joint system or alliance.
  • the log-chains are in an example embodiment private blockchains.
  • the cross-chains may be protocols or data exchanges between blockchains in which exchanges given preselected set of nodes may participate.
  • the cross-chains are implemented by equipment that operates the indicator-chain 150.
  • the indicator-chain 150 is operated by the equipment that also provides at least a portion of one or more of the sub-clouds. Notice: two or more, even all, of the sub-clouds may be run by same equipment.
  • the log-chains 114, 124, 134, 144 may be hosted by equipment such as servers of respective entities 110, 120, 130, 140.
  • the cross-chains 118, 128, 138, 148 may be hosted by servers of respective entities 110, 120, 130, 140.
  • the indicator-chain may be hosted by equipment such as one of the servers of the entities 110, 120, 130, 140 or by a dedicated or other server or server function.
  • data is shared in a data sharing alliance that comprises several entities, such as entities 110, 120, 130, and 140.
  • Each entity has a cloud or sub-cloud, here referred to as a sub-cloud (e.g., first sub-cloud 112 or sub-cloud A) so as to indicate that the different clouds need not be the same, and a log-chain (e.g., first log-chain 114 or log-chain A) .
  • Each entity stores its own data in its sub-cloud.
  • the sub-clouds may be implemented by one or more different cloud computing vendors.
  • the log-chains 114, 124, 134, 144, and the indicator-chain 150 comprise blocks linked to one another, including smart contracts as blocks.
  • the smart contracts themselves are not stored as blocks. Instead, a derivative such as a hash, and optionally also a pointer, is stored in a block to represent the smart contract.
  • the smart contract can be stored by either the same equipment that stores the blockchain, or by some other element.
  • Each entity may have a server to store the blockchains.
  • the smart contracts may comprise codes and protocol rules that facilitate automatic operation of a blockchain. It is also possible to communicate by a blockchain across chains, e.g., using the cross-chains of the entities.
  • the cross-chains of Fig. 1 may be used to exchange information between the log-chains and the indicator-chain.
  • the smart contracts control operation of the underlying equipment such that it can be said that the smart contracts perform various steps.
  • any references to acts or events performed by the smart contracts shall be understood as being caused, just like computer programs themselves are just instructions which, when executed, cause an apparatus to perform actions.
  • the indicator-chain allows all entities in the alliance to know how the data is being stored among them, without having to store it all in a central cloud.
  • the cloud federation in terms of multiple sub-clouds can be considered in the data sharing alliance, rather than only a central cloud in the alliance.
  • the data sharing can be divided into two stages including data upload and data access. Notably, the same entity can concurrently perform both.
  • Fig. 2 shows a block diagram of an apparatus 200 according to an embodiment of the invention.
  • the apparatus 200 may operate as a server or client.
  • the apparatus 200 generally comprises a memory 240 including a persistent computer program code 250.
  • the apparatus 200 further comprises a processor 220 for controlling the operation of the apparatus 200 using the computer program code 240, a communication unit 210 for communicating with other nodes.
  • the communication unit 210 comprises, for example, a local area network (LAN) port; a wireless local area network (WLAN) unit; Bluetooth unit; cellular data communication unit; or satellite data communication unit.
  • LAN local area network
  • WLAN wireless local area network
  • Bluetooth unit Bluetooth unit
  • cellular data communication unit or satellite data communication unit.
  • the processor 220 comprises, for example, any one or more of: a master control unit (MCU) ; a microprocessor; a digital signal processor (DSP) ; an application specific integrated circuit (ASIC) ; a field programmable gate array; and a microcontroller.
  • MCU master control unit
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • Various parts of the apparatus 200 may also be distributed, virtualized, or implemented using cloud computing. Also, various parts may be implemented using more than one corresponding or different elements, such as memories and storages may be multiplied for capacity and/or redundancy purposes. Similarly, processing and/or communications may be implemented with multiple parallel or elements for capacity and/or redundancy purposes.
  • Fig. 3 illustrates a first process of an embodiment, comprising any one or more of:
  • the first entity 110 registers itself as a member of a data alliance in the indicator-chain 150 with which members of the indicator-chain 150 can query the first entity 110 from the indicator-chain 150;
  • the first entity 110 decides to upload information, such as newly generated data.
  • the first entity 110 automatically triggers a smart contract of its log-chain 114, referred to log-chain smart contract or LSC.
  • the LSC is performed by equipment of the log-chain, such as a server (dedicated; virtualized; cloud computing server; or any combination thereof) , that may be implemented as the apparatus 200 or otherwise.
  • the LSC saves the filename and time stamp and optionally a checksum or hash-code of the generated data on the first log-chain 114.
  • the LSC submits data to the sub-cloud of the entity in question (here, first entity 110) for storage.
  • the LSC abstracts metadata of the generated data as the block 116 of the first log-chain 114 and reports the block 116 to a smart contract of the indicator-chain 150, i.e., indicator-chain smart contract, ISC, which ISC saves it as the block 152 on the indicator-chain.
  • ISC indicator-chain smart contract
  • the ISC broadcasts the blocks of the indicator-chain 150 to all entities of the alliance (i.e., to all members) . Hence, the members are informed of the data stored by the first entity 110.
  • the indicator-chain is a consortium blockchain.
  • the indicator-chain may be run by each member which all thus store the blocks that comprise metadata of data stored by the members. This enables subsequent retrieval of information by the other members.
  • FIG. 4 illustrates a second process of an example embodiment, comprising any one or more of:
  • a second entity e.g., Entity B
  • ISC indicator-chain smart contract
  • the ISC verifies the identity of the second entity to authenticate whether the entity belongs to the data sharing alliance or not (e.g., using a certificate; and/or public key encryption) .
  • the ISC determines the location of the data to which access was requested from the indicator-chain.
  • the ISC confirms that the location of the data is a given sub-cloud (such as a third sub-cloud, here Sub-cloud C) that is one of the sub-clouds of the members;
  • the ISC sends the access request to the log-chain of the sub-cloud (e.g., Sub-cloud C) via a respective cross-chain.
  • the sub-cloud e.g., Sub-cloud C
  • the LSC of the sub-cloud storing requested data (e.g., Sub-cloud C) is automatically triggered in response to receiving the access request from the ISC.
  • the LSC verifies the identity of the requesting member.
  • the access request is transferred to the sub-cloud (such as Sub-cloud C) by LSC;
  • the members may set further conditions for the access such that the LSC also defines which members may access the uploaded data. Such conditions may be used by the LSC to further verify whether or not the access request should be allowed or denied, and the next steps are only taken in case of allowing the access request, although step 420 is still performed in some embodiments.
  • Data access is performed in the sub-cloud storing the requested data (e.g., Sub-cloud C) .
  • the sub-cloud storing the data submits the access records to the log-chain.
  • the sub-cloud storing the data (e.g., Sub-cloud C) provides the data that needs to be accessed to the ISC (in an example embodiment, the equipment running the ISC physically provides the data under control of the smart contract) .
  • the ISC transfers the data to the requesting entity (such as the second entity, Entity B)
  • the requesting entity e.g., the second entity or Entity B obtains the data from the alliance.
  • Fig. 5 illustrates a flow chart of a process of an example embodiment for cloud federation authorization, comprising any one or more of:
  • an indicator-chain that is a consortium blockchain; wherein different ones of the members have different sub-clouds and respective log-chains; and wherein each log-chain is a private blockchain of one data sub-cloud.
  • each log-chain is a private blockchain of one data sub-cloud.
  • verifying whether the data retrieve request is permissible verifying that the requesting member indicated by the identity is one of the members of the data alliance.
  • verifying whether the data retrieve request is permissible verifying that the LSC defines the requesting member as permitted receiver of the requested data.
  • Fig. 6 shows a flow chart of a process of an example embodiment in log-chain equipment for cloud federation authorization, comprising:
  • Fig. 7 shows a flow chart of a process of an example embodiment in indicator-chain equipment for cloud federation authorization, comprising:
  • circuitry may refer to one or more or all of the following:
  • combinations of hardware circuits and software such as (as applicable) : (i) a combination of analog and/or digital hardware circuit (s) with software/firmware; and (ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) ; software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) ; and
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
  • a technical effect of one or more of the example embodiments disclosed herein is that data may be shared in large volumes while avoiding exposing to a single point of failure.
  • Another technical effect of one or more of the example embodiments disclosed herein is that data access traceability can be provided.
  • Yet another technical effect of one or more of the example embodiments disclosed herein is that data access records can be tamper-protected against falsification attempts by entity insiders.
  • Embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware, and application logic.
  • the application logic, software, or an instruction set is maintained on any one of various conventional computer-readable media.
  • a “computer-readable medium” may be any non-transitory media or means that can contain, store, communicate, propagate, or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted in Fig. 2.
  • a computer-readable medium may comprise a computer-readable storage medium that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.
  • the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the before-described functions may be optional or may be combined.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

On uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC, in a log-chain and registering corresponding metadata abstracting the uploaded data to an indicator-chain via a cross-chain. The indicator-chain is a consortium blockchain to which members of a data alliance are authorized. The LSC receives a data retrieve request from an indicator-chain smart contract, ISC, via the cross-chain and responsively verifies whether the data retrieve request is permissible. The data retrieve request is allowed, if the data retrieve request is permissible, otherwise rejected. The LSC records in the log-chain the result of the determining of whether the data retrieve request is permissible.

Description

METHOD AND APPARATUS FOR CLOUD FEDERATION AUTHORIZATION TECHNICAL FIELD
Various example embodiments relate to cloud federation authorization.
BACKGROUND
This section illustrates useful background information without admission of any technique described herein representative of the state of the art.
Various organizations share large volumes with each other. For large volumes, data clouds offer cost-efficient alternative. Cloud federation further improves cost advantage of cloud computing by enabling use of plural clouds or sub-clouds. However, access control and actual use of the information may then be exposed to single points of failure. Moreover, if different entities use different clouds, some mechanisms need to be provided to synchronize or distribute information.
SUMMARY
The scope of protection sought for various embodiments of the invention is set out by the independent claims. The embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.
According to a first example aspect of the present invention, there is provided a method for cloud federation authorization, comprising:
maintaining for members of a data alliance an indicator-chain ; wherein different ones of the members have different sub-clouds and respective log-chains
exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains;
registering data access records of each data sub-cloud in the respective log-chain;
on uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC, and registering corresponding metadata abstracting the uploaded data to the indicator-chain;
registering a data retrieve request of a requesting member in the indicator-chain;
responsively to the registering of the data retrieve request, registering an indicator-chain smart contract and querying a location of requested data from the plurality of log-chains;
authenticating the requesting member using the indicator-chain smart contract, ISC, and the indicator-chain;
determining by the ISC which data sub-cloud is storing the requested data;
sending by the ISC the data retrieve request via the corresponding cross-chain to LSC of the data sub-cloud that is determined to be storing the requested information;
receiving by the LSC the data retrieve request and responsively verifying whether the data retrieve request is permissible;
allowing the data retrieve request if the data retrieve request is permissible, otherwise rejecting the data retrieve request; and
recording in the log-chain the result of the determining of whether the data retrieve request is permissible.
The method may further comprise registering members of a data alliance in the indicator-chain so that members of the indicator-chain can query other members from the indicator-chain.
The method may further comprise registering the LSC in the respective log-chain.
The method may further comprise registering the ISC in the indicator-chain.
The indicator-chain may be a consortium blockchain.
The method may further comprise storing in the indicator-chain identity certificates of a plurality of log-chains, wherein each log-chain is a private blockchain of one data sub-cloud.
The verifying whether the data retrieve request is permissible may comprise determining using both the LSC and the ISC whether the data retrieve request is permissible for the requesting member.
The verifying whether the data retrieve request is permissible may comprise verifying that the requesting member indicated by the identity is one of the members of the data alliance. The verifying whether the data retrieve request is permissible may comprise verifying that the LSC defines the requesting member as permitted receiver of the requested data.
According to a second example aspect of the present invention, there is provided a method in log-chain equipment for cloud federation authorization, comprising:
on uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC, and causing registering of corresponding metadata abstracting the uploaded data to an indicator-chain via a cross-chain for access by members of a data alliance authorized to have a read and write access;
receiving by the LSC a data retrieve request from an indicator-chain smart  contract, ISC, via the cross-chain data;
responsively verifying whether the data retrieve request is permissible;
allowing the data retrieve request, if the data retrieve request is permissible, otherwise rejecting the data retrieve request; and
recording by the LSC in the log-chain the result of the determining of whether the data retrieve request is permissible.
The method may further comprise registering the LSC in the log-chain.
The indicator-chain may be a consortium blockchain to which only members of a data alliance authorized to have a read and write access.
The method may further comprise registering an identity certificate of the log-chain in an indicator-chain of the data alliance via the cross-chain.
According to a third example aspect of the present invention, there is provided a method in indicator-chain equipment for cloud federation authorization;
maintaining for members of a data alliance an indicator-chain, the indicator-chain being a consortium blockchain; wherein different ones of the members have different sub-clouds and respective log-chains;
exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains;
registering a data retrieve request of a requesting member in the indicator-chain;
responsively to the registering of the data retrieve request, registering an indicator-chain smart contract and querying a location of requested data from the plurality of log-chains;
authenticating the requesting member using the indicator-chain smart contract, ISC, and the indicator-chain;
determining by the ISC which data sub-cloud is storing the requested data; and
sending by the ISC the data retrieve request via the corresponding cross-chain to LSC of the data sub-cloud that is determined to be storing the requested information.
The method may further comprise registering the members of the data alliance in the indicator-chain so that the members of the indicator-chain can query other members from the indicator-chain.
The method may further comprise registering in the indicator-chain identity certificates of a plurality of log-chains, wherein each log-chain is a private blockchain of one data sub-cloud. The method may further comprise receiving the identity certificates from the blockchains via respective cross-chains.
The method may further comprise exchanging information between the indicator-chain and the plurality of log-chains via respective cross-chains. The indicator-chains may authenticate the log-chains using their identity certificates.
The verifying whether the data retrieve request is permissible may comprise determining using both the LSC and the ISC whether the data retrieve request is permissible for the requesting member.
The verifying whether the data retrieve request is permissible may comprise verifying that the requesting member indicated by the identity is one of the members of the data alliance. The verifying whether the data retrieve request is permissible may comprise verifying that the LSC defines the requesting member as permitted receiver of the requested data.
According to a fourth example aspect of the present invention, there is provided a computer program comprising computer executable program code configured to execute any method of any of the example aspects.
The computer program may be stored in a computer readable memory medium.
Any foregoing memory medium may comprise a digital data storage such as a data disc or diskette, optical storage, magnetic storage, holographic storage, opto-magnetic storage, phase-change memory, resistive random-access memory, magnetic random-access memory, solid-electrolyte memory, ferroelectric random access memory, organic memory or polymer memory. The memory medium may be formed into a device without other substantial functions than storing memory or it may be formed as part of a device with other functions, including but not limited to a memory of a computer, a chip set, and a sub assembly of an electronic device.
According to a fifth example aspect of the present invention, there is provided an apparatus comprising a memory and a processor that are configured to cause the apparatus to perform the method of any of the first to third example aspects.
According to a sixth example aspect of the present invention, there is provided an apparatus comprising means for performing the method of any of the first to third example aspects.
Different non-binding example aspects and embodiments of the present invention have been illustrated in the foregoing. The embodiments in the foregoing are used merely to explain selected aspects or steps that may be utilized in implementations of the present invention. Some embodiments may be presented only with reference to certain example aspects of the invention. It should be appreciated that corresponding embodiments may apply to other example aspects as well.
BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of example embodiments of the present invention, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
Fig. 1 shows an architectural drawing of a system of an example embodiment;
Fig. 2 shows a block diagram of an apparatus of an example embodiment;
Fig. 3 shows a flow chart of a process of an example embodiment;
Fig. 4 shows a flow chart of a process of an example embodiment;
Fig. 5 shows a flow chart of a process of an example embodiment in a system;
Fig. 6 shows a flow chart of a process of an example embodiment in a log-chain for cloud federation authorization; and
Fig. 7 shows a flow chart of a process of an example embodiment in an indicator-chain for cloud federation authorization.
DETAILED DESCRIPTON OF THE DRAWINGS
An example embodiment of the present invention and its potential advantages are understood by referring to Figs. 1 through 7 of the drawings. In this document, like reference signs denote like parts or steps.
Fig. 1 shows an architectural drawing of a system 100 of an example embodiment. The system 100 comprises four entities: a first entity 110, a second entity 120, a third entity 130, and a fourth entity 140. Fig. 1 further shows, for respective entities, first to  fourth sub-clouds  112, 122, 132, 142; first to fourth log- chains  114, 124, 134, 144; first to  fourth blocks  116, 126, 136, 146 in respective first to fourth log- chains  114, 124, 134, 144; first to  fourth cross-chains  118, 128, 138, 148; and first to  fourth users  119, 129, 139, 149. Here, term user refers to equipment used by a human or machine user for uploading or accessing data. Letters A to D are also used to aid understanding referencing to different entities.
While the cross-chains are here drawn to be comprised by the entities, they could also be considered as part of a joint system or alliance. The log-chains are in an example embodiment private blockchains. The cross-chains may be protocols or data exchanges between blockchains in which exchanges given preselected set of nodes may participate. In an embodiment, the cross-chains are implemented by equipment that operates the indicator-chain 150. In an embodiment, the indicator-chain 150 is operated by  the equipment that also provides at least a portion of one or more of the sub-clouds. Notice: two or more, even all, of the sub-clouds may be run by same equipment.
The log- chains  114, 124, 134, 144 may be hosted by equipment such as servers of  respective entities  110, 120, 130, 140. The  cross-chains  118, 128, 138, 148 may be hosted by servers of  respective entities  110, 120, 130, 140. The indicator-chain may be hosted by equipment such as one of the servers of the  entities  110, 120, 130, 140 or by a dedicated or other server or server function.
In an example embodiment, data is shared in a data sharing alliance that comprises several entities, such as  entities  110, 120, 130, and 140. Each entity has a cloud or sub-cloud, here referred to as a sub-cloud (e.g., first sub-cloud 112 or sub-cloud A) so as to indicate that the different clouds need not be the same, and a log-chain (e.g., first log-chain 114 or log-chain A) . Each entity stores its own data in its sub-cloud. Notably, the sub-clouds may be implemented by one or more different cloud computing vendors.
The log- chains  114, 124, 134, 144, and the indicator-chain 150 comprise blocks linked to one another, including smart contracts as blocks. In an example embodiment, the smart contracts themselves are not stored as blocks. Instead, a derivative such as a hash, and optionally also a pointer, is stored in a block to represent the smart contract. The smart contract can be stored by either the same equipment that stores the blockchain, or by some other element. Each entity may have a server to store the blockchains. In practice, the smart contracts may comprise codes and protocol rules that facilitate automatic operation of a blockchain. It is also possible to communicate by a blockchain across chains, e.g., using the cross-chains of the entities. In this embodiment, we use an indicator-chain, multiple sub-clouds, and log-chains to form a data sharing alliance. Moreover, the cross-chains of Fig. 1 may be used to exchange information between the log-chains and the indicator-chain.
In operation, the smart contracts control operation of the underlying equipment such that it can be said that the smart contracts perform various steps. In this document, any references to acts or events performed by the smart contracts shall be understood as being caused, just like computer programs themselves are just instructions which, when executed, cause an apparatus to perform actions.
The indicator-chain allows all entities in the alliance to know how the data is being stored among them, without having to store it all in a central cloud. To avoid the single point of failure, the cloud federation in terms of multiple sub-clouds can be considered in the data sharing alliance, rather than only a central cloud in the alliance.
The data sharing can be divided into two stages including data upload and data access. Notably, the same entity can concurrently perform both.
In the data upload stage, newly created or other data of different entities can be uploaded to their sub-clouds and made known to other entities (referred to as members) of the alliance via the indicator-chain. Various operations are described with reference to Figs. 3 and 4 after first describing some apparatus features with reference to Fig. 2.
Fig. 2 shows a block diagram of an apparatus 200 according to an embodiment of the invention. The apparatus 200 may operate as a server or client. The apparatus 200 generally comprises a memory 240 including a persistent computer program code 250. The apparatus 200 further comprises a processor 220 for controlling the operation of the apparatus 200 using the computer program code 240, a communication unit 210 for communicating with other nodes. The communication unit 210 comprises, for example, a local area network (LAN) port; a wireless local area network (WLAN) unit; Bluetooth unit; cellular data communication unit; or satellite data communication unit. The processor 220 comprises, for example, any one or more of: a master control unit (MCU) ; a microprocessor; a digital signal processor (DSP) ; an application specific integrated circuit (ASIC) ; a field programmable gate array; and a microcontroller. Various parts of the apparatus 200 may also be distributed, virtualized, or implemented using cloud computing. Also, various parts may be implemented using more than one corresponding or different elements, such as memories and storages may be multiplied for capacity and/or redundancy purposes. Similarly, processing and/or communications may be implemented with multiple parallel or elements for capacity and/or redundancy purposes.
Fig. 3 illustrates a first process of an embodiment, comprising any one or more of:
300. The first entity 110 registers itself as a member of a data alliance in the indicator-chain 150 with which members of the indicator-chain 150 can query the first entity 110 from the indicator-chain 150;
302. storing in the indicator-chain 150 an identity certificate of the first log-chain 114 of the first entity 110;
304. exchanging information between the indicator-chain 150 and the first log-chain 114 with the respective first cross-chain 118;
306. The first entity 110 decides to upload information, such as newly generated data.
308. The first entity 110 automatically triggers a smart contract of its log-chain 114, referred to log-chain smart contract or LSC. The LSC is performed by equipment of the log-chain, such as a server (dedicated; virtualized; cloud computing server; or any combination thereof) , that may be implemented as the apparatus 200 or otherwise.
310. The LSC saves the filename and time stamp and optionally a checksum or hash-code of the generated data on the first log-chain 114.
312. The LSC submits data to the sub-cloud of the entity in question (here, first entity 110) for storage.
314. The LSC abstracts metadata of the generated data as the block 116 of the first log-chain 114 and reports the block 116 to a smart contract of the indicator-chain 150, i.e., indicator-chain smart contract, ISC, which ISC saves it as the block 152 on the indicator-chain.
316. The ISC broadcasts the blocks of the indicator-chain 150 to all entities of the alliance (i.e., to all members) . Hence, the members are informed of the data stored by the first entity 110.
In an example embodiment, the indicator-chain is a consortium blockchain. The indicator-chain may be run by each member which all thus store the blocks that comprise metadata of data stored by the members. This enables subsequent retrieval of information by the other members.
In the data access stage, an entity can access the required data from the data sharing alliance. Fig. 4 illustrates a second process of an example embodiment, comprising any one or more of:
400. a second entity (e.g., Entity B) sends an access request to the indicator-chain smart contract, ISC, for gaining access to given data.
402. The ISC verifies the identity of the second entity to authenticate whether the entity belongs to the data sharing alliance or not (e.g., using a certificate; and/or public key encryption) .
404. If yes, the ISC determines the location of the data to which access was requested from the indicator-chain.
406. The ISC confirms that the location of the data is a given sub-cloud (such as a third sub-cloud, here Sub-cloud C) that is one of the sub-clouds of the members;
408. The ISC sends the access request to the log-chain of the sub-cloud (e.g., Sub-cloud C) via a respective cross-chain.
410. The LSC of the sub-cloud storing requested data (e.g., Sub-cloud C) is automatically triggered in response to receiving the access request from the ISC.
412. The LSC verifies the identity of the requesting member.
414. If the verification is positive and the identity of the requesting member is confirmed as purported, the access request is transferred to the sub-cloud (such as Sub-cloud C) by LSC;
416. In an embodiment, the members may set further conditions for the  access such that the LSC also defines which members may access the uploaded data. Such conditions may be used by the LSC to further verify whether or not the access request should be allowed or denied, and the next steps are only taken in case of allowing the access request, although step 420 is still performed in some embodiments.
418. Data access is performed in the sub-cloud storing the requested data (e.g., Sub-cloud C) .
420. The sub-cloud storing the data (e.g., Sub-cloud C) submits the access records to the log-chain.
422. The sub-cloud storing the data (e.g., Sub-cloud C) provides the data that needs to be accessed to the ISC (in an example embodiment, the equipment running the ISC physically provides the data under control of the smart contract) .
424. The ISC transfers the data to the requesting entity (such as the second entity, Entity B)
426. The requesting entity (e.g., the second entity or Entity B) obtains the data from the alliance.
Fig. 5 illustrates a flow chart of a process of an example embodiment for cloud federation authorization, comprising any one or more of:
500. Maintaining for members of a data alliance an indicator-chain that is a consortium blockchain; wherein different ones of the members have different sub-clouds and respective log-chains; and wherein each log-chain is a private blockchain of one data sub-cloud.
501. Registering the members in the indicator-chain so that the members can query other members from the indicator-chain.
502. Exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains.
504. Registering data access records of each data sub-cloud in the respective log-chain.
506. On uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC, optionally in the respective log-chain, and registering corresponding metadata abstracting the uploaded data to the indicator-chain.
508. Registering a data retrieve request of a requesting member in the indicator-chain.
510. Responsively to the registering of the data retrieve request, registering an indicator-chain smart contract, optionally in the indicator-chain, and querying a location of requested data from the plurality of log-chains.
512. Authenticating the requesting member using the indicator-chain smart  contract, ISC, and the indicator-chain.
514. Determining by the ISC which data sub-cloud is storing the requested data.
516. Sending by the ISC the data retrieve request via the corresponding cross-chain to the LSC of the data sub-cloud that is determined to be storing the requested information.
518. Storing in the indicator-chain identity certificates of a plurality of log-chains, wherein each log-chain is a private blockchain of one data sub-cloud.
520. In the verifying whether the data retrieve request is permissible, determining using both the LSC and the ISC whether the data retrieve request is permissible for the requesting member.
522. In the verifying whether the data retrieve request is permissible, verifying that the requesting member indicated by the identity is one of the members of the data alliance.
524. In the verifying whether the data retrieve request is permissible, verifying that the LSC defines the requesting member as permitted receiver of the requested data.
Fig. 6 shows a flow chart of a process of an example embodiment in log-chain equipment for cloud federation authorization, comprising:
602. On uploading data into a data sub-cloud, registering the corresponding log-chain smart contract, LSC, optionally in the log-chain, and causing registering of corresponding metadata abstracting the uploaded data to an indicator-chain via the cross-chain for access by members of a data alliance;
604. Receiving by the LSC a data retrieve request from an indicator-chain smart contract, ISC, via a cross-chain data;
606. Responsively verifying whether the data retrieve request is permissible;
608. If the data retrieve request is permissible, then allowing the data retrieve request, otherwise rejecting the data retrieve request; and
610. Recording by the LSC in the log-chain the result of the determining of whether the data retrieve request is permissible.
612. Causing registering an identity certificate of the log-chain in the indicator-chain of the data alliance via the cross-chain.
Fig. 7 shows a flow chart of a process of an example embodiment in indicator-chain equipment for cloud federation authorization, comprising:
700. Registering for members of a data alliance an indicator-chain that is a consortium blockchain; wherein different ones of the members have different sub-clouds and  respective log-chains.
702. Registering the members in the indicator-chain so that members can query other members from the indicator-chain.
704. Exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains.
706. Registering the members of the data alliance in the indicator-chain so that the members of the indicator-chain can query other members from the indicator-chain.
708. Registering a data retrieve request of a requesting member in the indicator-chain.
710. Responsively to the registering of the data retrieve request, registering an indicator-chain smart contract and querying a location of requested data from the plurality of log-chains.
712. Authenticating the requesting member using the indicator-chain smart contract, ISC, and the indicator-chain.
714. Determining by the ISC which data sub-cloud is storing the requested data.
716. Sending by the ISC the data retrieve request via the corresponding cross-chain to the LSC of the data sub-cloud that is determined to be storing the requested information.
718.
718. Registering in the indicator-chain identity certificates of a plurality of log-chains, wherein each log-chain is a private blockchain of one data sub-cloud.
720. Receiving the identity certificates from the blockchains via respective cross-chains.
As used in this application, the term “circuitry” may refer to one or more or all of the following:
(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and;
(b) combinations of hardware circuits and software, such as (as applicable) : (i) a combination of analog and/or digital hardware circuit (s) with software/firmware; and (ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) ; software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) ; and
(c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is that data may be shared in large volumes while avoiding exposing to a single point of failure. Another technical effect of one or more of the example embodiments disclosed herein is that data access traceability can be provided. Yet another technical effect of one or more of the example embodiments disclosed herein is that data access records can be tamper-protected against falsification attempts by entity insiders.
Embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware, and application logic. In an example embodiment, the application logic, software, or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a “computer-readable medium” may be any non-transitory media or means that can contain, store, communicate, propagate, or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted in Fig. 2. A computer-readable medium may comprise a computer-readable storage medium that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.
If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the before-described functions may be optional or may be combined.
Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.
It is also noted herein that while the foregoing describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing  from the scope of the present invention as defined in the appended claims.

Claims (48)

  1. A method for cloud federation authorization, comprising:
    maintaining for members of a data alliance an indicator-chain that is a consortium blockchain; wherein different ones of the members have different sub-clouds and respective log-chains;
    exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains;
    registering data access records of each data sub-cloud in the respective log-chain;
    on uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC, and registering corresponding metadata abstracting the uploaded data to the indicator-chain;
    registering a data retrieve request of a requesting member in the indicator-chain;
    responsively to the registering of the data retrieve request, registering an indicator-chain smart contract and querying a location of requested data from the plurality of log-chains;
    authenticating the requesting member using the indicator-chain smart contract, ISC, and the indicator-chain;
    determining by the ISC which data sub-cloud is storing the requested data;
    sending by the ISC the data retrieve request via the corresponding cross-chain to the LSC of the data sub-cloud that is determined to be storing the requested information;
    receiving by the LSC the data retrieve request and responsively verifying whether the data retrieve request is permissible;
    if the data retrieve request is permissible, then allowing the data retrieve request, otherwise rejecting the data retrieve request; and
    recording in the log-chain the result of the determining of whether the data retrieve request is permissible.
  2. The method of claim 1, further comprising storing in the indicator-chain identity certificates of a plurality of log-chains.
  3. The method of claim 1 or 2, wherein each log-chain is a private blockchain of one data sub-cloud.
  4. The method of any one of preceding claims, wherein the verifying whether the data retrieve request is permissible comprises determining using both the LSC and the ISC whether the data retrieve request is permissible for the requesting member.
  5. The method of any one of preceding claims, wherein the verifying whether the data retrieve request is permissible comprises verifying that the requesting member indicated by  the identity is one of the members of the data alliance.
  6. The method of any one of preceding claims, wherein the verifying whether the data retrieve request is permissible comprises verifying that the LSC defines the requesting member as permitted receiver of the requested data.
  7. A method in log-chain equipment for cloud federation authorization, comprising:
    on uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC, and causing registering of corresponding metadata abstracting the uploaded data to the indicator-chain via a cross-chain;
    receiving by the LSC a data retrieve request from an indicator-chain smart contract, ISC, via the cross-chain;
    responsively verifying whether the data retrieve request is permissible;
    allowing the data retrieve request, if the data retrieve request is permissible, otherwise rejecting the data retrieve request; and
    recording by the LSC in the log-chain the result of the determining of whether the data retrieve request is permissible.
  8. The method of claim 7, further comprising registering the LSC in the log-chain.
  9. The method of claim 7 or 8, further comprising registering an identity certificate of the log-chain in the indicator-chain of the data alliance via a cross-chain.
  10. A method in indicator-chain equipment for cloud federation authorization, comprising:
    maintaining for members of a data alliance an indicator-chain; wherein different ones of the members have different sub-clouds and respective log-chains;
    exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains;
    registering a data retrieve request of a requesting member in the indicator-chain;
    responsively to the registering of the data retrieve request, registering an indicator-chain smart contract and querying a location of requested data from the plurality of log-chains;
    authenticating the requesting member using the indicator-chain smart contract, ISC, and the indicator-chain;
    determining by the ISC which data sub-cloud is storing the requested data; and
    sending by the ISC the data retrieve request via the corresponding cross-chain to LSC of the data sub-cloud that is determined to be storing the requested information.
  11. The method of claim 10, further comprising registering in the indicator-chain identity certificates of a plurality of log-chains, wherein each log-chain is a private blockchain of one data sub-cloud.
  12. The method of claim 10 or 11, further comprising receiving the identity certificates  from the blockchains via respective cross-chains.
  13. The method of any one of claims 10 to 12, further comprising exchanging information between the indicator-chain and the plurality of log-chains via respective cross-chains.
  14. The method of any one of claims 10 to 13, wherein the verifying whether the data retrieve request is permissible comprises determining using both the LSC and the ISC whether the data retrieve request is permissible for the requesting member.
  15. The method of any one of claims 10 to 14, wherein the verifying whether the data retrieve request is permissible comprises verifying that the requesting member indicated by the identity is one of the members of the data alliance.
  16. The method of any one of claims 10 to 15, wherein the verifying whether the data retrieve request is permissible comprises verifying that the LSC defines the requesting member as permitted receiver of the requested data.
  17. The method of any one of claims 1 to 6 or 10 to 16, further comprising registering the members of the data alliance in the indicator-chain so that the members of the indicator-chain can query other members from the indicator-chain.
  18. A computer program comprising computer executable program code configured to execute any method of any one of preceding claims.
  19. An apparatus for cloud federation authorization, comprising means for performing:
    maintaining for members of a data alliance an indicator-chain; wherein different ones of the members have different sub-clouds and respective log-chains;
    exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains;
    registering data access records of each data sub-cloud in the respective log-chain;
    on uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC, and causing registering of corresponding metadata abstracting the uploaded data to the indicator-chain;
    registering a data retrieve request of a requesting member in the indicator-chain;
    responsively to the registering of the data retrieve request, registering an indicator-chain smart contract and querying a location of requested data from the plurality of log-chains;
    authenticating the requesting member using the indicator-chain smart contract, ISC, and the indicator-chain;
    determining in the ISC which data sub-cloud is storing the requested data;
    sending in the ISC the data retrieve request via the corresponding cross-chain to the LSC of the data sub-cloud that is determined to be storing the requested information;
    receiving in the LSC the data retrieve request and responsively verifying whether the  data retrieve request is permissible;
    allowing the data retrieve request if the data retrieve request is permissible, otherwise rejecting the data retrieve request; and
    recording in the LSC in the log-chain the result of the determining of whether the data retrieve request is permissible.
  20. The apparatus of claim 19, wherein the means are further configured to perform registering members of a data alliance in the indicator-chain so that members of the indicator-chain can query other members from the indicator-chain.
  21. The apparatus of claim 19 or 20, wherein the means are further configured to perform registering the LSC in the respective log-chain.
  22. The apparatus of any one of claims 19 to 21, the indicator-chain being a consortium blockchain.
  23. The apparatus of any one of claims 19 to 22, wherein the means are further configured to perform storing in the indicator-chain identity certificates of a plurality of log-chains.
  24. The apparatus of any one of claims 19 to 23, wherein each log-chain is a private blockchain of one data sub-cloud.
  25. The apparatus of any one of claims 19 to 24, wherein the verifying whether the data retrieve request is permissible comprises determining using both the LSC and the ISC whether the data retrieve request is permissible for the requesting member.
  26. The apparatus of any one of claims 19 to 25, wherein the verifying whether the data retrieve request is permissible comprises verifying that the requesting member indicated by the identity is one of the members of the data alliance.
  27. The apparatus of any one of claims 19 to 26, wherein the verifying whether the data retrieve request is permissible comprises verifying that the LSC defines the requesting member as permitted receiver of the requested data.
  28. An apparatus for operating a log-chain for cloud federation authorization, comprising means for performing:
    on uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC and for causing registering of corresponding metadata abstracting the uploaded data to an indicator-chain via a cross-chain for access by members of a data alliance;
    receiving in the LSC a data retrieve request from an indicator-chain smart contract, ISC, via a cross-chain;
    responsively verifying whether the data retrieve request is permissible;
    allowing the data retrieve request, if the data retrieve request is permissible,  otherwise rejecting the data retrieve request; and
    recording in the LSC in the log-chain the result of the determining of whether the data retrieve request is permissible.
  29. The apparatus of claim 28, wherein the means are further configured to perform registering the LSC in the log-chain.
  30. The apparatus of claim 28 or 29, wherein the indicator-chain is a consortium blockchain to which only members of a data alliance authorized to have a read and write access.
  31. The apparatus of any one of claims 28 to 30, wherein the means are further configured to perform registering an identity certificate of the log-chain in the indicator-chain of the data alliance via a cross-chain.
  32. An apparatus for operating an indicator-chain for cloud federation authorization, comprising means for performing:
    maintaining for members of a data alliance the indicator-chain; wherein different ones of the members have different sub-clouds and respective log-chains;
    exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains;
    registering a data retrieve request of a requesting member in the indicator-chain;
    responsively to the registering of the data retrieve request, registering an indicator-chain smart contract and querying a location of requested data from the plurality of log-chains;
    authenticating the requesting member using the indicator-chain smart contract, ISC, and the indicator-chain;
    determining in the ISC which data sub-cloud is storing the requested data;
    sending in the ISC the data retrieve request via the corresponding cross-chain to LSC of the data sub-cloud that is determined to be storing the requested information.
  33. The apparatus of claim 32, wherein the means are further configured to perform registering the members of the data alliance in the indicator-chain so that the members of the indicator-chain can query other members from the indicator-chain.
  34. The apparatus of claim 32 or 33, wherein the means are further configured to perform registering in the indicator-chain identity certificates of a plurality of log-chains, wherein each log-chain is a private blockchain of one data sub-cloud.
  35. The apparatus of any one of claims 32 to 34, wherein the means are further configured to perform receiving the identity certificates from the blockchains via respective cross-chains.
  36. The apparatus of any one of claims 32 to 35, wherein the means are further  configured to perform exchanging information between the indicator-chain and the plurality of log-chains via respective cross-chains.
  37. The apparatus of any one of claims 32 to 36, wherein the verifying whether the data retrieve request is permissible comprises determining using both the LSC and the ISC whether the data retrieve request is permissible for the requesting member.
  38. The apparatus of any one of claims 32 to 37, wherein the verifying whether the data retrieve request is permissible comprises verifying that the requesting member indicated by the identity is one of the members of the data alliance.
  39. The apparatus of any one of claims 32 to 38, wherein the verifying whether the data retrieve request is permissible comprises verifying that the LSC defines the requesting member as permitted receiver of the requested data.
  40. A system comprising an apparatus for operating a log-chain for cloud federation authorization and an apparatus for operating an indicator-chain for cloud federation authorization, the system comprising means for performing:
    operating the log-chain to perform:
    on uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC, and causing registering of corresponding metadata abstracting the uploaded data to the indicator-chain via a cross-chain for access by members of a data alliance;
    receiving in the LSC a data retrieve request from an indicator-chain smart contract, ISC, via the cross-chain;
    responsively verifying whether the data retrieve request is permissible;
    allowing the data retrieve request, if the data retrieve request is permissible, otherwise rejecting the data retrieve request; and
    recording in the LSC in the log-chain the result of the determining of whether the data retrieve request is permissible;
    operating the indicator-chain to perform:
    maintaining for the members of a data alliance the indicator-chain, wherein different ones of the members have different sub-clouds and respective log-chains;
    exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains;
    registering a data retrieve request of a requesting member in the indicator-chain;
    responsively to the registering of the data retrieve request, registering an indicator-chain smart contract and querying a location of requested data from the plurality of log-chains;
    authenticating the requesting member using the indicator-chain smart contract, ISC, and the indicator-chain; and
    determining in the ISC which data sub-cloud is storing the requested data;
    sending in the ISC the data retrieve request via the corresponding cross-chain to LSC of the data sub-cloud that is determined to be storing the requested information.
  41. The system of claim 40, wherein the means are further configured to perform registering the members of the data alliance in the indicator-chain so that the members of the indicator-chain can query other members from the indicator-chain.
  42. The system of claim 40, wherein the means are further configured to perform the method of claim 8 or 9.
  43. The system of any one of claims 40 to 42, wherein the means are further configured to perform the method of any one of claims 11 to 17.
  44. An apparatus for operating a log-chain for cloud federation authorization, comprising:
    at least one processor; and
    at least one memory including computer program code;
    the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform:
    on uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC, and causing registering of corresponding metadata abstracting the uploaded data to an indicator-chain via a cross-chain for access by members of a data alliance;
    receiving by the LSC a data retrieve request from an indicator-chain smart contract, ISC, via a cross-chain;
    responsively verifying whether the data retrieve request is permissible;
    allowing the data retrieve request, if the data retrieve request is permissible, otherwise rejecting the data retrieve request; and
    recording by the LSC in the log-chain the result of the determining of whether the data retrieve request is permissible.
  45. An apparatus for operating an indicator-chain for cloud federation authorization, comprising:
    at least one processor; and
    at least one memory including computer program code;
    the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform:
    maintaining for members of a data alliance the indicator-chain; wherein  different ones of the members have different sub-clouds and respective log-chains;
    exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains;
    registering a data retrieve request of a requesting member in the indicator-chain;
    responsively to the registering of the data retrieve request, registering an indicator-chain smart contract and querying a location of requested data from the plurality of log-chains;
    authenticating the requesting member using the indicator-chain smart contract, ISC, and the indicator-chain;
    determining by the ISC which data sub-cloud is storing the requested data; and
    sending by the ISC the data retrieve request via the corresponding cross-chain to LSC of the data sub-cloud that is determined to be storing the requested information.
  46. A computer program comprising computer executable program code configured to cause, on executing the program code, an apparatus for operating a log-chain for cloud federation authorization to perform:
    on uploading data into a data sub-cloud, registering a corresponding log-chain smart contract, LSC and for causing registering of corresponding metadata abstracting the uploaded data to an indicator-chain via a cross-chain for access by members of a data alliance;
    receiving in the LSC a data retrieve request from an indicator-chain smart contract, ISC, via a cross-chain;
    responsively verifying whether the data retrieve request is permissible;
    allowing the data retrieve request, if the data retrieve request is permissible, otherwise rejecting the data retrieve request; and
    recording in the LSC in the log-chain the result of the determining of whether the data retrieve request is permissible.
  47. A computer program comprising computer executable program code configured to cause, on executing the program code, an apparatus for operating an indicator-chain for cloud federation authorization to perform:
    maintaining for members of a data alliance the indicator-chain; wherein different ones of the members have different sub-clouds and respective log-chains;
    exchanging information between the indicator-chain and each one of the log-chains with respective cross-chains;
    registering a data retrieve request of a requesting member in the indicator-chain;
    responsively to the registering of the data retrieve request, registering an indicator-chain smart contract and querying a location of requested data from the plurality of log-chains;
    authenticating the requesting member using the indicator-chain smart contract, ISC, and the indicator-chain;
    determining in the ISC which data sub-cloud is storing the requested data;
    sending in the ISC the data retrieve request via the corresponding cross-chain to LSC of the data sub-cloud that is determined to be storing the requested information.
  48. A computer readable medium comprising the computer program of claim 46 or 47.
PCT/CN2021/091686 2021-04-30 2021-04-30 Method and apparatus for cloud federation authorization WO2022227069A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/091686 WO2022227069A1 (en) 2021-04-30 2021-04-30 Method and apparatus for cloud federation authorization

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/091686 WO2022227069A1 (en) 2021-04-30 2021-04-30 Method and apparatus for cloud federation authorization

Publications (1)

Publication Number Publication Date
WO2022227069A1 true WO2022227069A1 (en) 2022-11-03

Family

ID=83847565

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/091686 WO2022227069A1 (en) 2021-04-30 2021-04-30 Method and apparatus for cloud federation authorization

Country Status (1)

Country Link
WO (1) WO2022227069A1 (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107085810A (en) * 2017-04-19 2017-08-22 朱皞罡 Across the chain operating method and block chain management system of a kind of block chain
CN109299338A (en) * 2018-10-31 2019-02-01 山东云息网络科技有限公司 Transregional piece of chain data management system of one kind and method
US20190340266A1 (en) * 2018-05-01 2019-11-07 International Business Machines Corporation Blockchain implementing cross-chain transactions
CN111245840A (en) * 2020-01-14 2020-06-05 北京工业大学 Inter-block chain cross-chain information transmission control system
CN111489256A (en) * 2019-01-25 2020-08-04 京东数字科技控股有限公司 Cross-chain processing method, equipment and system for multi-chain block chain system
US20200252202A1 (en) * 2019-02-06 2020-08-06 International Business Machines Corporation Cross-chain validation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107085810A (en) * 2017-04-19 2017-08-22 朱皞罡 Across the chain operating method and block chain management system of a kind of block chain
US20190340266A1 (en) * 2018-05-01 2019-11-07 International Business Machines Corporation Blockchain implementing cross-chain transactions
CN109299338A (en) * 2018-10-31 2019-02-01 山东云息网络科技有限公司 Transregional piece of chain data management system of one kind and method
CN111489256A (en) * 2019-01-25 2020-08-04 京东数字科技控股有限公司 Cross-chain processing method, equipment and system for multi-chain block chain system
US20200252202A1 (en) * 2019-02-06 2020-08-06 International Business Machines Corporation Cross-chain validation
CN111245840A (en) * 2020-01-14 2020-06-05 北京工业大学 Inter-block chain cross-chain information transmission control system

Similar Documents

Publication Publication Date Title
US11038891B2 (en) Decentralized identity management system
CN111698228B (en) System access authority granting method, device, server and storage medium
JP6872015B2 (en) Secure access to sensitive data using blockchain ledger
EP3603031B1 (en) Device credentials management
US9021264B2 (en) Method and system for cloud based storage
CN112005264A (en) Blockchain implementing cross-chain transactions
KR102618665B1 (en) Version history management using blockchain
KR102152360B1 (en) System and method for providing data reliability based on blockchain for iot services
US20220094560A1 (en) Integrating Device Identity Into A Permissioning Framework Of A Blockchain
US10637666B1 (en) Migrating data for decentralized applications between disparate backend storage providers
US10389693B2 (en) Keys for encrypted disk partitions
US10880076B1 (en) Backup of encrypted information stored off-chain in a blockchain-based decentralized storage system
US11157897B2 (en) Methods and devices for managing access to account in blockchain system
US20200252465A1 (en) Methods and devices for establishing communication between nodes in blockchain system
US20190319794A1 (en) Distributed access control
US20200136809A1 (en) Systems and methods for decentralized distributed storage using blockchain
US10104163B1 (en) Secure transfer of virtualized resources between entities
WO2021134835A1 (en) System and methods for data exchange using a distributed ledger
CN110445765B (en) Data sharing method based on block chain, terminal device and medium
WO2022121673A1 (en) Decentralized broadcast encryption and key generation facility
WO2022227069A1 (en) Method and apparatus for cloud federation authorization
Ramesh et al. Public auditing for shared data with efficient user revocation in the cloud
US20240214228A1 (en) Blockchain based public key infrastructure
US20230360158A1 (en) Intelligent transfer of assets using blockchain technology
US20230073894A1 (en) Blockchain network-based virtual common id service method and service provision server using same

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

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

Country of ref document: EP

Kind code of ref document: A1