Security and Communication Networks
Volume 2018 (2018), Article ID 3858592, 18 pages
https://doi.org/10.1155/2018/3858592

Research Article

A Privacy Preserving Approach to Collaborative Systemic Risk Identification: The Use-Case of Supply Chain Networks

Tirazheh Zare-Garizy,¹ Gilbert Fridgen,² and Lars Wederhake³

¹FIM Research Center, University of Augsburg, Universitaetsstrasse 12, 86159 Augsburg, Germany
²FIM Research Center, University of Bayreuth, Wittelsbacherring 10, 95444 Bayreuth, Germany
³Project Group Business & Information Systems Engineering of the Fraunhofer FIT, University of Augsburg, 86135 Augsburg, Germany

Correspondence should be addressed to Lars Wederhake; lars.wederhake@fit.fraunhofer.de

Received 31 December 2017; Revised 26 April 2018; Accepted 15 May 2018; Published 22 July 2018

Academic Editor: Angel M. Del Rey

Copyright © 2018 Tirazheh Zare-Garizy et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract.

Globalization and outsourcing are two main factors which are leading to higher complexity of supply chain networks. Due to the strategic importance of having a sustainable network, it is necessary to have an enhanced supply chain network risk management. In a supply chain network many firms depend directly or indirectly on a specific supplier. In this regard, unknown risks of network’s structure can endanger the whole supply chain network’s robustness. In spite of the importance of risk identification of supply chain network, firms are not willing to exchange the structural information of their network. Firms are concerned about risking their strategic positioning or established connections in the network. The paper proposes to combine secure multiparty computation cryptography methods with risk identification algorithms from social network analysis to address this challenge. The combination enables structural risk identification of supply chain networks without endangering firms’ competitive advantage.

1. Introduction

In March 2000, a thunderstorm in New Mexico caused a 400-million-dollar loss for the telecommunications equipment firm Ericsson. The fire in a semiconductor plant, a single-source key components provider for Ericsson, led to this damage. This loss could have been lower with an appropriate risk management within the supply chain network (SCN) of Ericsson [1].

High complexity of SCNs and steady increase in vulnerability within the SCN are the results of globalization, digitalization, outsourcing, and customer or supplier dependencies [2]. The complex structures of SCNs are vulnerable to systemic risk at all scales. Systemic risk is not just the risk of statistically independent failure, but also the risk of failure cascading within the whole interconnected system [3]. This cascading effect impacts the whole system’s performance and can lead to irrecoverable value disruptions [4, 5]. 54% of firms are either extremely or very concerned about their sustainability performance [6]. Being one of the four emerging issues in global risk [7], it is inevitable to invest in risk management for supply chains. Managers and public policy makers need to identify risks to perform proper risk management and mitigation plans.

Simulation models [8–10], descriptive case studies [11, 12], and development of taxonomies of SCNs [13, 14] are common research results of the scholars on analysis of SCNs. The embedded positioning of firms within the SCN is important for each firm in the network as well as for the network as a whole. Innovation adoption, influence power, or brokering activities of the firms can be derived from their structural positioning in the SCN. Moreover, the structural positioning of the firms can affect the vulnerability or robustness of the SCN [15]. Over the last few decades, the importance of adopting a network perspective in supply chain analysis and management has increased. Recently, the idea of adopting network measures for the investigation of SCNs is opening new potentials to evaluate supply chains [16, 16, 17].

There are several measures to quantitatively characterize the network structure. Each measure can be adopted to capture a specific feature of the network [18]. Betweenness, closeness, and degree centrality are some of the widely used measures in social network analysis [19, 20]. Kim et al. [15] mapped these measures within the SCN and defined their implication for two types of supply networks: material flows and contractual relationships. They identified that firms with higher betweenness centrality (BC) have a higher impact on the product quality, coordination cost, and lead time or can cause unwanted intervene or control among the SCN. These risky firms have a higher contribution to systemic risk. The BC is an indicator for identifying firms with the possibility of influencing information processing, strategic alignments, and perverting risk management within the supply network [15]. Based on Hallikas et al. [21] the risks in a SCN can affect the long-term sustainable competitive advantage of the network. Considering our focus and above-mentioned findings, we assume the BC to be an appropriate measure to identify risky firms in the SCN.

One of the main challenges in studying supply chain risks is the scarcity of real life data on SCNs [15, 22]. The fear of risking competitors’ advantage by information sharing hinders firms’ collaboration within the SCN. To calculate the BC, either based on definition [18, 19], or by means of widely used algorithms such as Brandes’ [23], having information about the network’s structure is necessary. This structural information contains data on the network’s firms and their possible connectivity to other firms. However, the strategic importance of the firms’ position and connections within the network [24] dissuades firms from sharing this information. In this case, the application of secure multiparty computation (SMC) cryptographic algorithms [25, 26] would be one of the solutions to facilitate information sharing willingness within the network. SMC algorithms are based on simultaneous exchanges of encrypted data among parties. The result is calculated from the encrypted data and is shared among all firms (parties) in the network. The algorithm prevents leakage of key information between the firms.

Summarizing, we find considerable support for the importance of risk analysis in SCNs and the adequacy of the BC to identify the bottlenecks in SCNs. Literature, however, also backs that firms are reluctant to share information on their position in the network. Having this as a starting point, the main focus of this paper is to introduce an artifact, based on the design science paradigm, for privacy preserving calculation of the BC of a given SCN. This paper is an extended version of our prior research [27, 28] and includes detailed information on the developed artifact, the pseudocode of the artifact, and a detailed description and explanation of the pseudocode. Our artifact consists of four main methods that are calculating the desired result. The main contributions of our paper are as follows:

(i)Identification of risks: in the first step of risk management, it is necessary to develop models and methods for risk identification in SCNs. In a small SCN, firms are more likely to keep the overview of the SCN topology and the firms in the network. Consequently, in such cases risks are relatively transparent and privacy might not be the main subject of interest. Our concern is the risk identification in large SCNs consisting of hundreds of interconnected firms. In a large SCN, on the one hand, the identification of unknown risks is important and on the other hand the privacy of members should be maintained. For an increasing size of the SCN and the interrelationships among the firms, the network becomes more complex [29, 30]. Due to the higher complexity the probability of unseen risks and the necessity of proper risk analysis increase. In the artifact proposed, we study the economic dependency (e.g., material or financial flow) between firms by means of BC calculation for the identification of risky firms in SCNs. We thereby assume that our artifact could be a module of standard ERP systems that use existing communication links to suppliers and customers. An alternative implementation could use existing blockchain technology.(ii)Preservation of privacy: one of the main concerns of firms in a SCN is their strategic position in the network, so they avoid risking their competitive advantage in order to identify their own risks. Our artifact keeps the network’s structure mostly unknown to the firms within the network. The artifact prevents data leakage or reconstruction of information to ensure the firms’ willingness for information sharing. In order to meet this objective, we base our approach on SMC algorithms in a semihonest environment as outlined in the latter. Our modeling focus is on providing a privacy preserving artifact, whereas we omit the analysis and improvement of computational complexity.

Considering the guidelines by Hevner et al. [31] and Gregor and Hevner [32] for the conduction of design science research, the remainder of this papers is organized as follows: the first section covers a brief review on essential literature. It also includes specifying the problem’s context and the relevance of the problem for SCNs. Subsequently, we discuss the modeling procedure and requirements that must be met for solving the problem. The fourth section illustrates the developed artifact. The section is followed by the evaluation of the artifact by means of testing and descriptive methods. The paper ends with a summary and an outlook on further research.

2. Literature Review

2.1. Supply Chain Networks

“Supply chains are interlinked networks of suppliers, manufacturers, distributors, and customers that provide a product or service to customers” [33]. Current trends, like e-commerce, e-logistics, and e-business, increase the complexity of supply chains. Furthermore, the importance of staying competitive in the market gives supply chain management a higher importance [34]. The SCN in a global economy consists of a large number of interdependent networks. This interdependency is very susceptible to external effects and defaults [35]. The risk type in SCNs can be specific disruption, general disruption, cost shock (e.g., exchange rates), product safety, commoditization, and shift in tastes [30]. Weather, terrorism, firms manufacturing failures, or financial crises can cause a default in the supply chain [36]. Risks in SCNs can lead to various types of losses such as financial loss, performance loss, physical loss, psychological loss, social loss, and time loss [37]. Since the disruptions in SCN in extreme cases may lead to the bankruptcy of the SCN’s firms, it is important for the firms to manage these risks and minimize the possible losses. A study by Gyorey et al. [38] states that 67% of firms are not ready for geopolitical instability challenges. In the management of SCNs, one of the main tasks is risk management. The risk management process consists of risk identification and assessment, decision and implementation of risk management actions, and risk monitoring [21]. Bellamy and Basole [39] classified the themes in SCNs analysis as system architecture (network structure), system behavior, and system policy and control. Among these categories, system architecture analysis methods focus on structural investigation of SCNs, relationship of firms, and the importance of the relationship. Considering social networks, structural investigations based on network analysis methods are well established. In the field of SCNs they are relatively new but evolving [15, 17, 40]. These methods focus on network components’ connections and patterns and implication of these connections for the whole network [18, 20]. Among various measures on structural analysis of SCN, as it has been mentioned earlier, the BC can be a suitable indicator to identify the structural risks of a SCN [15] and it is our choice in this paper.

2.2. Privacy Concerns in Supply Chain Networks

On the one hand, knowing the structure of a network is a prerequisite of calculating the BC (as outlined earlier) and on the other hand in a SCN, the competitive advantage of network firms is relying on the privacy of their contacts and network relations they have [35]. Solutions to these data privacy concerns of firms can be as follows:

(i)A trusted third party: if the firms trust a third party, it is easy to solve the problem by sharing their information with this trusted third party and letting it calculate the results. For instance, Brandes’ algorithm for the BC [23] works based on the idea of having a third party who collects the information and calculates the indices and returns the result. In practice, such a party that all network’s firms trust might be difficult to find and firms might have concerns about this third party revealing the information.(ii)SMC algorithms: these cryptography algorithms enable different firms in the network to share their information privately and calculate the result jointly. The main advantage of these algorithms is that the individual’s input stays mostly private.

SMC first was addressed by Yao [41]. Yao’s algorithm is answering the question of SMC for two parties. This algorithm is a solution to the millionaires’ problem. The problem is that two millionaires want to know which of them is richer but they do not want to share the real amount of their wealth. Yao’s [41] algorithm provides a solution that lets them privately encrypt their input, share it, and jointly calculate the result. The main advantage is that their input stays private. SMC algorithms today enable us to do secure addition, multiplication, and comparison [25, 42–44].

SMC algorithms are used in various fields of science. For instance, they are used for secure auctions [45]. They are also used for sharing financial risk exposures [46] with the focus on necessity of process and methods secrecy in financial industry. SMC algorithms are also applied for sustainable benchmarking in clouds without disclosing the individual’s confidential information [47].

“SecureSCM”, secure collaborative supply chain management, the European research project [48], is an example of the application of SMC algorithms in the field of SCNs. The project enabled privacy preserving online collaboration among various firms in a SCN. The focus was on providing the possibility of better reaction on possible capacity concerns or short notices. The collaboration of the firms with the application of SMC algorithms results in better production planning in the SCN. However, they did not study SCN’s risks and focused on cost minimization.

In this paper, SMC algorithms are our choice for the privacy preserving calculation of the result. To apply these algorithms, we develop an artifact that enables calculation of the result based on private shares of the firms. SMC algorithms have a high acceptance and are widely used in the field of cryptography since the 1980s [45, 49–52] as their security has been addressed comprehensively, as well.

2.3. Network Centrality Measures

To calculate the BC, we model the SCN as a graph . Each firm in the SCN is represented by a vertex . An economic dependency (e.g., material or financial flow) between firms is represented by an edge between these firms. In this case, we name and adjacent or neighbors. Since an economic dependency is undirected, in this paper graphs are undirected. Moreover, the graphs are connected, as connected firms are forming a SCN. The BC is a centrality index based on the number of shortest paths and the frequency in which a vertex is appearing on shortest paths between two other vertices. A shortest path is a path between two vertices such that the sum of the weights of its constituent edges is minimized (as outlined in Section 3). The BC describes how other vertices potentially can influence the interaction between two nonneighboring vertices [18, 20]. The BC for vertex is calculated as follows [18]:

In (1), is the number of shortest paths between source vertex and target vertex , which pass through vertex , and is the number of shortest paths between source vertex and target vertex .

The main aspect of the BC algorithms [23, 53, 54] is finding the shortest paths. Based on categorization of Cormen et al. [55] on shortest paths algorithms, we classify existing BC algorithms as follows:

(i)Algorithms based on single-source shortest paths: Brandes’ algorithm [23] is a widely used one among them. Brandes [23] applies single-source shortest paths algorithms (breadth-first [56]) search for unweighted and Dijkstra’s algorithm for weighted graphs [55, 57] to calculate the BC.(ii)Algorithms based on all-pairs shortest paths: the method developed by [58] adopted modification of algorithms like the Floyd-Warshall [55, 59, 60] to enable parallelism and space-efficiency in calculation of the BC.

Both categories of algorithms need the network topology as input and a stack to store information. For privacy concerns we strive to avoid a central stack for information. Having a central stack implies that there is a central player who owns this stack. This player can infer information, from the communication of the players via this stack or from the large amounts of available data (although the information is encrypted) in the stack. This can be a risk for privacy concerns of the firms in the SCN.

In this paper, inspired by the Floyd-Warshall [55, 59, 60] algorithm as well as backtracking search [61] to identify shortest paths, we develop an artifact which does not need a central stack, stores information decentrally, and does not need the network’s topology as input.

3. Modeling Procedure, Assumptions, and Requirements

The first part of this section focuses on the modeling procedure and assumptions of our artifact. In this part, before we focus on privacy concerns and information that each firm has, we define the general terms and construct of our artifact. The second part includes the more specific information on the firm’s privacy preservation and requirements.

We label each firm and its representing vertex with a unique number . The numbers are randomly assigned to each firm and represent the row number for the player in the graph’s weight matrix. The relation between the identity of a firm and its number is only known to the firm itself and to the neighboring firms. From now on, we name a firm and its representing vertex as a “player” when we refer the firm’s row number and not the true identity of the firm.

In the following, we illustrate an exemplary SCN (Figure 1). The SCN is chosen simple to make the visualization easier and the example more comprehensible. The SCN consists of players. Each player is represented by its own unique number. The set of vertices (players) is .

Figure 1: Exemplary network [27].

For reasons of simplicity, the following assumptions are the basis for the development of our artifact.

Assumption 1 (the firms are semihonest (honest-but-curious)). Semihonest adversaries are following the protocol, but they might try to gather information and draw conclusions from the messages they receive. Our artifact’s construction preserves privacy assuming the firms are semihonest. Moreover, related works on SMC algorithms are also based on a semihonest model [62–65].

Assumption 2 (the connections in the SCN are equally weighted). In general, our artifact is applicable for graphs with . However, Kim et al. [15] did their analysis on the BC, assuming equal weight connections. Their focus is on links between firms and the number of firms that are engaged in transferring information or material. Therefore, without loss of generality, in this paper we do not focus on the determination of the intensity of connections and its analysis and we treat the connections as equally weighted and leave the topic of connections’ intensity subject to further research. The weight of the edge with arbitrary is then defined by

The matrix contains all weights of edges in the graph [55]. The (symmetric) matrix in Figure 1 represents the weight matrix of our exemplary SCN.

The sequence of vertices that are forming the path from a source vertex to a target vertex is represented by . In this we assume that , , and . The length of the path is the sum of the weights of its forming edges. Based on (2) the weight of an edge is therefore, if vertices are forming a path, there are edges on this path and We define the length of a shortest path, labeled as distance between and , as

The matrix contains the distances . By our definition, if and are adjacent then . To find a shortest path from a source vertex to the target vertex , the existing distance and the distance of all alternative paths via intermediate vertices are compared (see (4)) and we choose the path with the minimum length.

In this part we represent the above-mentioned figures with particular details which include privacy preserving concerns and information availability for the players.

In our artifact we restricted the information availability of the players mostly up to their neighbors. Therefore, although the set is known to every player in the network, the relation between the players’ unique numbers and their true identities is only known to neighboring players. Furthermore, the network’s structure as illustrated in Figure 1 is not known to the players. Consequently is unknown to the players. Each player has access to the row/column (since the matrix is symmetric) of the weight matrix . The accessible information for player 5 is the 5-th row of the matrix, as marked in Figure 1. Moreover, the distance matrix is unknown to the players, although each player has access to the -th row of the matrix .

For our artifact we state the following requirements:

Requirement 1. The artifact should keep the SCN topology as private as possible.

Requirement 1 is an extension to conditions of SMC on satisfying privacy [44]. In our case it is not allowed that more information than the final result (BC) is shared. More specifically, we prohibit the sharing of the following information that can be used for reconstructing the SCN topology or interfering the real identity of the firms.

(i)The length of the shortest paths, to prevent firms from knowing the positioning of the players in the network(ii)The number of the shortest paths between a given source and target player in the network, to prevent firms from knowing which alternatives for trading players have in the network(iii)The number which shows how often a player is appearing on the shortest paths between a given source and target player, to prevent firms from knowing accessibility and connections to other firms

Requirement 2. The artifact should keep the identities of nonneighboring players private.

In a large SCN, due to members’ variety and multiplicity in the SCN, a firm is not able to identify other firms in the network. Concluding the identity of a player via execution of the artifact can provide the possibility of reconstructing a part of the network’s topology. Therefore, the artifact should not enable a firm to infer the real identity of nonneighboring firm.

4. Artifact Development

We choose an object oriented approach to design the artifact. To model the structure and behavior of the players in our artifact we model the class player. We represent each player by an object of class player running on a distributed system. Each player executes the methods on its own system and delivers the result. In our artifact we assume there is an initializing and synchronizing agent (ISA) (one of the SCN’s firms or an organization) who initializes, coordinates, and synchronizes the executions. The ISA does not have the possibility of accessing the private information of the players or monitor the communication between the players.

Figure 2 presents class player. For reasons of simplicity, in the following we assume the players’ object references are equal to their respective during the calculations. is the unique number assigned to each player in the network. implies the player is pointing the -th row/column the weight matrix .

Figure 2: Visualization of the class player in UML-oriented notation [27].

We assume is the number of the current objects of the player class. Table 1 provides the description of the attributes of the player class. Table 2 provides an overview and description of the commonly used variables in the methods. Table 2 provides the description of the methods of the player class.

Table 1: Description of the attributes of the class player [27].

Attribute
Mathematical Variable
Description

distance:

Denotes a vector of the distances of player to each target player in the network. The distances are unknown at the beginning of the execution. Each member of this list is the output of the method calculateSecureShortestPath() for a given target player.

omega:

Denotes a vector which contains the set of neighboring players of player that are connecting the player with the shortest paths to the target player The method calculateSecureShortestPath() sets the values of this set.

delta:

Denotes a random generated number of the player. We use it to modify the distance value to preserve privacy. Each player generates before participating in the execution of methods. For each player, this number stays constant during the execution of the artifact. It assures an identical response of the player to all calculation requests.

betweennessCentrality:
)
Denotes a vector which is filled with the BC of all players in the network. Each member of this list is the output of the calculateSecureBetweenness() method for each given player .

busy:

Denotes an matrix of flags (true/false). This flag serves implementation purposes and especially access management of the players (as described in Table 4, Line 1-4).

Table 2: Description of the methods of class player [27].

Method
Description

Name     calculateSecureShortestPathInput
    : int
    : int
Output
    distance: int
The method recursively identifies the shortest paths from the given source player to the given target player. It returns the encrypted value of the distance and keeps other variables local. If the target player is not the current player, the method calls itself at all neighboring players to determine their distances to the target. The method compares the delivered results of the neighboring players and chooses the path via the neighboring player/s which has/have the minimum distance value. For privacy preserving purposes the comparisons in this method are based on Yao’s secure comparison protocol [41]. The method also identifies the neighboring players who are forming the shortest paths and fills the set .

Name     calculateNumberOfShortestPaths
Input
    : int
    : int
Output
    void
The method recursively calculates the number of shortest paths between given unique numbers of source player and given target player via players forming the shortest paths. If is not a neighboring player of , the method calls itself at all neighboring players forming the shortest paths between and . The method determines the number of shortest paths which passes through current player by means of the size of the set .
The method saves the results of the calculation in an intermediate storage and later uses it to participate in calculateSecureBetweenness method.

Name     determinePlayersOnShortestPaths
Input
    : int
    : int
Output
    void
The method recursively determines how often players are appearing on the shortest paths from source player to target player via current player . If is not a neighboring player of , the method calls itself for all neighboring players which are forming the shortest paths between and . At each recursion the members of the set determine the players which are on the shortest paths through player .
The method determines the players which are on the shortest paths through current player by means of the members of the set .
The method saves the results of the calculation in an intermediate storage and later uses it to participate in calculateSecureBetweenness method.

Name     calculateSecureBetweenness
Input
    : int
    : int
Output
    BC(v): int
This method calculates the for the given player in the network. It is based on SMC algorithms and requires information exchange among the players in the network. The method performs all arithmetic based on secure protocols of Cramer et al. [44]. These protocols for SMC are an extension of Shamir’s algorithm [42] and providing us the possibility to calculate the BC preserving the privacy concerns.
Furthermore, the method applies the distributive property of binary operations to calculate the result of Equation (1). This provides us the possibility that private shares of players stay private.

For privacy preserving concerns, in methods calculateSecureShortestPath(), calculateNumberOfShortestPaths(), and determinePlayersOnShortestPaths() players only communicate via their neighboring players. Each object routes its encrypted messages through neighboring players in the network. The methods calculateNumberOfShortestPaths() and determinePlayersOnShortestPaths() calculate values of and decentrally. Each player has a portion of these values from its own perspective. We denote the portion of information which player has by , and . The final values of and are the sum of the decentrally calculated values of all players as follows.

The method calculateSecureBetweenness() uses the decentral values (, and ) to calculate the betweenness centrality and applies SMC algorithms to preserve privacy.

Table 3 elaborates on the sequences of our artifact. Steps to (initialization) and 9 (synchronization) of Table 3 are not in the focus of this paper and also do not influence the artifact’s construction. Therefore, these steps are not documented in this paper. Furthermore, we provide a brief description of all methods which are listed in Table 2.

Table 3: The artifact’s sequences [27].

Step
Executor
Description

Initialization

1
ISA
Identifies the number of players, , in the network.

2
ISA
Assigns each participating company a (without knowing the real identities of the firms).

3
ISA
Shares the number of players, , with all players in the network and notifies the players to initialize.

4
Player
Each player initializes a new object of class Player and informs ISA.

5
ISA
Notifies all players that the players’ objects exist and they are available to execute the methods.

Decentral calculation of the shortest paths and path forming players

6
Player
Each player executes the calculateSecureShortestPath() method for itself as the source player and all given targets in the network.

7
Player
Each player executes the calculateNumberOfShortestPaths() method to decentrally set the values of for each given target .

8
Player
Each player executes the determinePlayersOnShortestPaths() method to decentrally calculate the values of for itself as source player and each given target . By termination of the method for all given targets, the player informs ISA.

Synchronization

9
ISA
ISA informs every player in the network that the determinePlayersOnShortestPaths() is terminated when it receives the notification of termination from all players. This implies that the variables to calculate the BC are available.

Calculation of the BC

10
ISA
ISA coordinates players for execution of the calculateSecureBetweenness() method. With termination of the method for all players in the network, all firms have their own BCs as well as the BC of all players in the network.

Table 4: Description of the calculateSecureShortestPath() method.

Line
Description

1-4
The calculateSecureShortestPath() is a recursive method, which sequentially routes the requests of the calculation of shortest paths via the neighboring players. Therefore, each player should not receive a duplicate request for the calculation of a specific path. However, a player may receive such a request, since the graph of the SCN is not necessarily acyclic. Once current player routes the message of the calculation of a specific shortest path via a neighboring player, due to the possible graph cycles, after few message routings player might receive its own message from a neighboring player causing endless loop. To avoid such conditions, the method uses a busy flag ().

As long as player is busy with the calculation of the shortest paths between players and , if it receives a message for the calculation of the same path, it implies that the message is its own message. Therefore, Line 1 identifies this message as a duplicate message. Furthermore, Line 3 prevents further calculations of the method and returns . Returning ensures that the duplicate request has no influence on the result of the calculations, and the method terminates.

5-8
To calculate the BC (c.f. Equation (1)), it is important to know the number of the shortest paths between two players, and to know which players are forming the shortest paths. The absolute numeric value of the length of the shortest paths does not change the result of BC. Thus, for privacy preserving concerns, we can modify the absolute numeric value ofthe distances between players by adding an offset to the target players given that the number of shortest paths and their forming players remain intact. Still, we obtain the same results as without modification of the distances.

In our method, each player uses its own private number (delta explained in Table 1) to modify the distance value (Line 7). Note that, this number must not be the players’ unique number, because if it is so, the positioning of the players might be disclosed. Please note, since the communication is only via neighboring players, this private number is only known to the player and its neighboring players. Players use the private number only if they are the target player . This assures a consistent modification of the distances to a specific target player and the comparability of the results for the source player .

The following scenario elaborates the importance of using to modify the value of distance. In our exemplary network (Figure 1), if the method does not modify the value of distances, and player shares 1 as its distance to players 7 , player (as a neighboring player of player ) infers that players and are adjacent. But if the method uses a modified value of the distance (we define, for player be ), player shares 71 as its distance to players 7 . This modification hinders unwanted information sharing in terms of inferring the positioning of players in the network.

To find the shortest paths, we must be able to compare the distances of the paths. Although the modified distance values (Line 7) eliminate many sorts of privacy concerns, yet there is a chance to reconstruct parts of the network structure by comparing the modified values. For instance in Figure 1 we set to 7. The distance of player to via player is and the distance of player to via player is . Based on this information, player reveals that players and are adjacent. Therefore, in addition to modifying the shortest path we apply a privacy preserving method to compare the shortest paths (See Line 17-40).

9-12
If the player already calculated the distance to target player , then it returns this calculated value of distance. This part increases the efficiency of the method by preventing recalculation of the shortest paths, which are already calculated.

13-43
If the current player receives a request for the calculation of a specific path for the first time and is not the target player, this part of the method (Line 17-40) recursively calculates the shortest paths between source player and target player .

To avoid data inconsistency during the execution of various instances of the method, Line 16 sets the temporary distance variable to which is the initial distance value of the current player to the target. The method does not use its distance attribute () for calculations, because the value of , may change during the calculation of a specific shortest path, leading to inconsistency of the result. The following example elaborates the necessity of the temporary distance variable.

We assume player is executing calculateSecureShortestPathand it is the first request to player for calculating the path to player . Players and are not adjacent and the initial value of the distance is . In the meantime, player receives the request for calculation of the path from source player to target player (calculateSecureShortestPath). If the execution of this requestends faster than calculateSecureShortestPath, player updates the distance to player () to . Consequently, the value of for the player varies during the execution of calculateSecureShortestPath.This leads to inconsistent values of the distance for the comparisons within the execution of the method. Using , the method prevents this sort of inconsistencies.

When player starts the calculation of the path between source player and target player via its neighboring players, Line 15 sets the to true. When player finishes calculating the shortest paths between players and , Line 41 sets to false. It allows the player to respond to the messages which are not originating from itself.
At Line 42 the method returns the value of distance ), which is the distance of player to the target player ().

17-40
Current player routes the message of the calculation of the path via all neighboring players to calculate the result recursively. For this purpose Line 17 goes through each player to , where is the number of players in the network. Furthermore, the method identifies the neighboring players and only routes the request for calculating the shortest path via them.

19-39
Player identifies its neighboring players at Line 19. For this purpose it considers a given player as a neighboring player when the distance of the current player to the player is equal to one ( (Equation (2))). The player routes the request of calculation only via its neighboring players, since for privacy preserving concerns we limit direct communication of players and only allow communication via neighboring players. Please note that in this paper we assume the connections in the SCN are equally weighted. In a weighted graph, another mechanism to identify the neighboring players will be necessary.

Furthermore, this part of the method determines a new shortest path (Line 21-28), or the additional shortest paths (Line 29-38).

21-28
This part of the method determines if the path via the neighboring player is a new shortest path.

We define, smin as a function which performs the comparison of given input parameters and based on Yao’s secure comparison algorithm as

which keeps the input parameters of the players and private.

In method calculateSecureShortestPath() we are interested in finding the result of . The values of and are known to player . The distance of the neighboring player to target player , () is known to player . To use , and keep the input variables of each player private, we do the comparison as which uses the input of the current player and the neighboring player separately. The value of is not known for the current player, therefore it routes the requests to its neighboring player to participate in the calculation of the by Please note, as mentioned at Line 16 current player uses a temporary distance value instead of during the calculation.

Player does not share the distance value, and takes part with its encrypted input in the secure comparison of the distances. If the result of smin() is true, it implies that the alternative path via is shorter than the existing path(s), so this path is a shortest path in this iteration. In this case current player, at Line 27, assigns the calculated value of distance to its temporary variable of distance .

For privacy preserving concerns, we share as little information as possible. Consequently, if the alternative path via player is not shorter than the existing one(s), current player will not find it out.

23-26
Since the method is recursive, it is important to prevent assignment of values during the execution and before the source player which initiated the request receives the final result. Line 23 examines if is source player , which implies the initiating player received its own request, and then allows the method to update .

By finding a new shortest path (at Line 21), the previously found path(s) and the players which are forming these paths are not relevant anymore. Player is the neighboring player, which connects player with the shortest path to the target. Therefore, the method updates , and sets player as its only member.

29-38
If the path via the neighboring player is not shorter than previously found shortest path(s), this part of the method determines if the path via this neighboring player is an additional shortest path.

31-37
This part of the method aims to determine if the path via the neighboring player is an additional shortest path. If the following equation is true, it implies that the alternative path via player , and the already calculated path are equal.

In our case we evaluate the following expression: . In the case of , we only need to examine = true. Line 31 of the methods performs this comparison.

For privacy preserving concerns (as already elaborated at Line 21-28) player does not share the distance value, but only takes part with its encrypted input for secure multiparty calculation of , a. calculateSecureShortestPath()

It should be noted that for the comparison of the shortest path distances (Line 31) the current player does not know , and therefore routes the request to the neighboring player by a. calculateSecureShortestPath(s,t). Please note, the neighboring player , already calculated this path (as Line 21) and therefore immediately returns this value.

33-36
Since the method is recursive, it is important to prevent the assignment of values before the source player, which initiated the request receives the final result. Line 33 examines if is source player and then allows the method to update .

Finding an additional shortest path implies that player is connecting player with the shortest path to target player . Therefore, Line 35 adds player to .

In the following, we provide the pseudocodes and a detailed description of the methods of our artifact. The artifact’s methods use integer variables to reference players similar to the mathematical variable, e.g., for inputs and outputs. The declared references are the source player s (sourcePlayerNumber), the target player t (targetPlayerNumber), the current player p (currentPlayerNumber), i.e., the player currently calling a method, a neighboring player a (neighboringPlayerNumber), and some given player v (aPlayerNumber). We present a summary on these variables in the Appendix

In Figure 3 we provide the pseudocode of calculateSecureShortestPath() method. This method requires an additional variable for calculation purposes. It denotes a temporary variable saving the distances during calculation of the shortest paths. This variable ensures data consistency.

Figure 3: Pseudocode of the method calculateSecureShortestPath

Table 4 provides a detailed description of the calculateSecureShortestPath() method.

For reasons of simplicity, we provide the sequence diagram of the method for a specific path. Figure 4 provides the calculateSecureShortestPath(5,7) from player 5’s perspective for our exemplary network (Figure 1). We assumed for player 7 is 70.

Figure 4: Sequence diagram for calculateSecureShortestPath(5,7) from player 5’s perspective [27].

In the following, Figure 5 presents the pseudocode of calculateNumberOfShortestPaths() method.

Figure 5: Pseudocode of the method calculateNumberOfShortestPaths.

Table 5 provides a detailed description of calculateNumberOfShortestPaths() method.

Table 5: Description of the calculateNumberOfShortestPaths () method.

Line
Description

1-11
This part of the method sets the number of the shortest paths () when the current player is the source player .

3-6
This part of the method sets the number of the shortest paths () when the target player is a neighboring player of source player .

If target player is a neighboring player of source player s (Line 3), Line 5 sets the number of the shortest paths to one () because there is only one shortest path between two neighboring players in an unweighted graph.

7-10
This part of the method sets the number of the shortest paths () when the target player is not a neighboring player of source player .

If target player is not a neighboring player of source player s, the size of set (that includes all neighboring players which connect current player as source to the target) is the number of shortest paths between player and the target (). As already mentioned, the player has a portion of this value from its own perspective. The final value of is the sum of the decentrally calculated values of all players as shown in Equation (5).

12-15
This part of the method sets the number of the shortest paths () when the current player is not the source player . This player received the request of calculateNumberOfShortestPaths(s,t) because it is one of the players which is forming the shortest path between source and target player.

Already one of the shortest paths on which the player lies, is considered by the source player . Consequently, we need to consider the additionally identified shortest paths via this player. If there is an additional path via this player to the source, Line 14 sets the value of to , otherwise set it to zero. We decrease the value of by one, to prevent double consideration of the already considered path.

16-19
To consider additional shortest paths which might be identified by the players which are forming the shortest paths between the source and target player, the method recursively routes the message for calculating the number of shortest paths via the neighboring players which are forming the shortest paths (Line 18). The method identifies this neighboring player by Line 16, when .

The calculateNumberOfShortestPaths() method identifies the number of the shortest paths from the source player and recursively identifies additional shortest paths via the players who are forming the shortest path(s). The following example elaborates an exemplary scenario of the method’s execution. For instance, player 5 executes the calculateNumberOfShortestPaths(5,7) and identifies . Since player 7 is not a neighboring player of player 5, and player 6 is in player the method calls itself from player 6. Player 6 does not identify any additional path (since player 6’s ; therefore, it sets . At this point the method terminates while player 7 (the target) is a neighboring player of player 6.

Figure 6 provides the pseudocode of determinePlayersOnShortestPaths() method.

Figure 6: Pseudocode of the method determinePlayersOnShortestPaths.

Table 6 provides a detailed description of determinePlayersOnShortestPaths() method.

Table 6: Description of determinePlayersOnShortestPaths() method.

Line
Description

1-4
This part of the method sets the values of the frequency of the appearance of a player on a shortest path for itself .

When current player is not source player and the number of shortest paths (size of set ) from the current player to the target is greater that one, Line 3 sets the value of to . The player is already considered on the shortest paths by the neighboring player which called it. Therefore, to prevent double consideration of the player we decrease the value of by one. As already mentioned, the player has a portion of this value from its own perspective. The final value of is the sum of the decentrally calculated values of all players as shown in Equation (5).

5-9
This part of the method sets the values of the frequency of the appearance of a the neighboring players that form the shortest path on the shortest path between players and () and routes the message via the neighboring players forming the shortest paths.

Line 7 sets the value of for the neighboring player to one because the player is on the shortest path from to .

Player can only update the values of for its neighboring players, but the frequency of appearance of a player on the shortest paths should be updated for all of the players on the shortest paths between source player and target player . The method calls itself to route the message via its neighboring player and update the values recursively.

The determinePlayersOnShortestPaths() method subsequently considers a player on the shortest paths between source player and target player when the player is in of the current player. The following example elaborates an exemplary scenario of the method’s execution. Moreover, it reconsiders the current player (except the case where ) on the shortest paths when current player has more than one shortest path to the target. For instance, the determinePlayersOnShortestPaths(5,7) identifies , while player 6 is in player 5’s . Since player 7 is not a neighboring player of player 5, the method calls itself from its neighboring player (player 6). Player 6 is the neighboring player of the target (player 7); therefore, no further calculation takes place and the method terminates.

The calculateSecureBetweenness() method calculates the BC for player based on SMC algorithms. In order to facilitate all-to-all communication, ISA coordinates the simultaneous exchange of information. To ensure that the real identities of the firms stay private in an all-to-all communication, existing tools for anonymization can be adapted.

The BC for player based on (1) is as follows:

For the calculation of the BC we use SMC algorithms. Secure addition and secure multiplication algorithms will, however, reveal a party’s input as inverse functions can easily be applied for only two input factors. To keep the input variables in arithmetic operations private, it is necessary that more than two players deliver input. In the above-mentioned equation, we address this problem. By division of two variables delivered by two players, even with the application of SMC algorithms, the end result reveals the input variables for the players. Therefore, by using a common denominator we solve the problem as follows:

Furthermore, the values of and    are the results of (5). For privacy preserving concerns, as addressed in Requirement 1, we do not calculate and share the final values of and in the network. Hence, we use the distributive property of arithmetic operations to distributedly consider the components of (5) in (7). Using the mentioned modification on the BC calculation’s equation we provide the possibility of keeping the private shares of the players private and calculating the BC. The implementation of the artifact with the application of SMC algorithms, anonymization methods, and necessary communication protocols is not covered in this paper.

5. Evaluation

This section provides the evaluation of our artifact. Concerning characteristics of our artifact, we chose the “testing” and “descriptive evaluation” methods based on [31, 66]. We implemented a simplified prototype of the artifact. The prototype covers the methods of class player. However, the prototype does not cover the implementation of SMC algorithms and assumes they are given. Moreover, the prototype models each player as a local thread, and it is not executed on a distributed system. Furthermore, a third person other than the authors manually evaluated the artifact with a structural walk through the code. In the following, we cover general evaluation of completeness, termination, complexity, utility, and privacy of the artifact. Furthermore, we illustrate the privacy evaluation based on an application example. It is important to note that we exemplarily analyze and present the privacy situation of player 5. This is so because it is the player which obtains most information by the application of the algorithm. Because of the acceptance and wide application of SMC algorithms, we did not analyze their properties again but assume SMC algorithms to be complete and secure.

Completeness. To evaluate the artifact in terms of completeness we executed the prototype with various scenarios and evaluated the results. It proved that our approach creates complete results for each given network. Moreover, the structural walk through the code is the same.

Termination. By means of testing the prototype in various scenarios as well as structural walk through the code we validated that the artifact terminates.

Complexity. Analysis of our artifact pointed that both the time complexity and the message complexity are polynomial in the maximum distance between the source and the target player, and number of network members. In our artifact we focused on achieving a privacy preserving method. To preserve privacy, it is necessary for the players to encrypt and exchange data more often compared to some widely used algorithms (e.g., [23]). Further improvements of computational complexity of the artifact are subject to further research.

Utility. Based on Gregor and Hevner [32] an artifact evaluation must address the utility of the artifact. Due to the complexity of implementation and evaluation of the artifact’s utility in reality, in this paper we evaluated the utility of the artifact based a simplified prototype and used an application example. Our artifact’s characteristics based on [66] are as follows: it is a novel method, which is open because it is possible to modify it and is interesting because it addresses risk management and sustainability as one of the main concerns of the firms in SCNs.

Privacy. The privacy requirements of our artifact (Requirement 1 and 2) are addressed as follows.

(i)The application of Yao’s [41] comparison algorithm and using the modified values for distances ensure that the distances of nonneighboring players remain unknown. Although in a small network, we illustrate in our application example that the distances might be inferable. However, in larger real-world SCN (which are in the focus of our research) players cannot infer the distance during the execution of the artifact.(ii)The number of the shortest paths and the frequency of appearance of a player on the shortest path are saved decentrally, as mentioned in (5). Therefore, the final values of and are not available to the players and stay private.(iii)By restricting communication via neighboring players and application of anonymization methods, we addressed Requirement 2.

However, we will appreciate if other researchers challenge our artifact in terms of privacy. In specific cases players might infer information when they are called from neighboring players to execute the methods. However, the inferred information of the players is limited to the information from their perspective. For instance, if the shortest path of a neighboring player to target is via the current player it implies for the current player that the neighboring player and target are not neighbors, whereas it does not contain the information about the players which are forming the shortest paths and the number of shortest paths.

Furthermore, to illustrate the potential of our artifact to preserve privacy, we describe the artifact’s outcome in a short example. Figure 7 provides the network structure (see Figure 1) from player 5’s perspective before and after execution of the method. Based on the result of the BC calculation, players are prioritized and colored as shown in the figure. Player 5 has the highest BC. Player 4 is second. Players 6 and 2 are having the same BC and thus rank third place. The BC of players 1, 3, and 7 is zero, because they are not on any shortest path. This is a valuable information for all network’s members. For instance, it implies that if player faces any failure, the whole network’s robustness might be at risk. The BC of the players is available for all players in the SCN.

Figure 7: Delta distance versus actual distance.

Privacy related issues stem from disclosed information such as return values from method calls. An essential method is calculateSecureShortestPath(s,t). It operates decentrally and discloses portions of information. We therefore present all return values (if called) that are available for individual players. The pseudocode does not store the return values but a curios player might do so. That is why we provide an additional analysis if and if so what information might be inferred. Because the path from s to t has the same length as the path from t to s (adjusted by the difference of their delta-values), we only present all pairs with Table 7 presents the shortest path information for all 7 players in our example as illustrated by Figure 1 after all calculateSecureShortestPath(s,t) calls terminated. For the illustration we assigned a random delta-value to each player. Before, we have already assigned 70 as the delta-value for player 7. In this example we continue to do so. Also, in Table 7 we present a delta distance value and an actual distance value. While the former represents the return value of s.calculateSecureShortestPath(s,t), the actual distance value denotes the real, nondistorted distance between s and t. The latter information shall not be revealed or inferable by any means as has been formulated by the requirements. By the results depicted in Table 7, it becomes clear that more central players as indicated by the BC score receive more method calls and thus more information.

Table 7: Shortest path information from the perspective of each player.

Player number (p)
1
2
3
4
5
6
7

Delta ()
73
17
99
93
46
8
70

Distance (s,t)
Return values or no information
Delta distance
Actual distance

(1,2)
18
17
∞
∞
∞
∞
∞
18
1

(1,3)
103
102
99
101
100
∞
∞
103
4

(1,4)
95
94
∞
93
∞
∞
∞
95
2

(1,5)
49
48
∞
47
46
∞
∞
49
3

(1,6)
12
11
9
10
9
8
∞
12
4

(1,7)
75
74
∞
73
72
71
70
75
5

(2,3)
∞
102
99
101
100
∞
∞
102
3

(2,4)
∞
94
∞
93
∞
∞
∞
94
1

(2,5)
∞
48
∞
47
46
∞
∞
48
2

(2,6)
∞
11
9
10
9
8
∞
11
3

(2,7)
∞
74
72
73
72
71
70
74
4

(3,4)
∞
∞
95
93
94
95
∞
95
2

(3,5)
∞
∞
47
∞
46
47
∞
47
1

(3,6)
∞
∞
9
∞
9
8
∞
9
1

(3,7)
∞
∞
72
∞
72
71
70
72
2

(4,5)
∞
∞
∞
47
46
∞
∞
47
1

(4,6)
∞
∞
9
10
9
8
∞
10
2

(4,7)
∞
∞
72
73
72
71
70
73
3

(5,6)
∞
∞
9
∞
9
8
∞
9
1

(5,7)
∞
∞
72
∞
72
71
70
72
2

(6,7)
∞
∞
∞
∞
∞
71
70
71
1

In fact the return values approximate the delta distance quite well. However, this data does not provide insight into actual distances. In order to demonstrate the distortion of information we plotted delta distances against actual distances in Figure 7. The plot presents itself as very scattered. The correlation coefficient between both actual and delta distances is 0.14. The low correlation coefficient indicates there is barely any relationship in the data (0 would indicate no relationship). While clearly with larger graphs more data is available and more sophisticated information retrieval methods might be applicable, we yet validated that the decentral computation does not reveal relevant information, given our exemplary network. As stated before, we leave a systematic validation of larger graphs (real-world SCNs) for future research.

Additionally, players store information about shortest paths by design. Doing so they might infer additional information: in our exemplary network, player 5 knows that players 3 and 6 are neighbors because players 6 and 3 are 5’s neighboring players and their shortest paths are not via player 5. Player 5 clearly knows the neighbor relationship right from initialization and stores shortest paths information (Figure 8).

Figure 8: The network’s structure from player 5’s perspective [27].

Player 5 knows also that players 1 and 6, 2 and 6, and 4 and 6 are not neighboring players. The latter information is inferred based on the information that their shortest path is via player 5. But the player does not know their exact positioning and if there exists any other alternative shortest path.

It is to conclude that the gained information about the network’s structure, even in a small network, is limited. By increasing the network’s size and complexity the possibility of inferring information decreases. Additionally, the inferred information on nonneighboring vertices is limited. This is similar to a common situation of a SCN. In reality, in a SCN, a firm knows more information about its neighbors. The firm can partially reveal information about the neighbors of its own neighbors. By going further in the SCN, the firm is less able to deduce the underlying topology or identity of the firms. Moreover, in most of the SCNs, there are some main players that are known by everyone. If other firms identify these firms and their importance, it is not a risk for these players. Their importance and positioning in the network are predictable for most of the firms in the SCN.

5.1. Discussion

While this paper’s evaluation represents a first step toward subsequent real-world evaluation steps, we discuss security challenges which might arise on the road ahead from a multiple layer perspective as a basis for future research. The layers comprise the orchestration platform, i.e., the ISA, the algorithms, and players’ behavior.

First, it is important to reemphasize that risk management as stated before will greatly benefit, if players in a SCN can determine the systemic risks they are exposed to. However, the necessary disclosure of relevant information is subject to the player’s trust in the network. Players will not share information, if they fear that the underlying platform, algorithms, and other players’ behavior are unfit to maintain high standards of security.

Regarding the ISA, the paper suggests either an ERP module or a blockchain-based instance. Both have advantages and disadvantages alike with regard to security. The latter might facilitate a decentral execution based on cryptographic protocols but might require additional information to be exchanged which ought to be analyzed when there is a first prototypical implementation, e.g., as part of a future research contribution. The former corresponds to a central execution platform and allows for an implementation and information exchange exactly as presented herein. However, technically it might be difficult to shield the orchestration from a curious ISA operator (which is considered to be a player for itself). Other players might be skeptical and decline requests to participate in the network and its corresponding information disclosure.

Regarding the security of the algorithms, we performed a critical evaluation and pointed out that we suggest performing further evaluation steps on large-scale networks. The SCM algorithms we apply have been proven to satisfy security standards. The protocols either rely on some mathematical problem such as factoring or are unconditional referring to a probability of error which can be sized arbitrarily small (e.g., [25, 26]).

Finally, security in the SCN is challenged by the behavior of the players itself. As this paper assumes semihonest players which do not deviate from the protocol, i.e., the set of methods and its orchestration, real-world players might prove to be malicious for, e.g., business strategic reasons. From a social science perspective, it might be relevant to better understand motifs of players to do so but from a computer networks perspective, it should be even more tempting to advance the methods of this contribution to prove security under malicious environments featuring players which are likely to cheat. While those preserve privacy in any case, it will be interesting to observe, if honest players would then abort the execution resulting in little information on systemic risk of individual players. Moreover, increasing security comes at the cost of efficiency as already pointed out in our evaluation. MPC algorithms for semihonest environments might be considered relatively efficient. Corresponding algorithms for malicious environments might be secure but too inefficient for use in practice. Developing resource-efficient algorithms to deal with malicious environments poses a great but demanding opportunity for the field of security in computer networks.

Summarizing, we state that security in general and privacy preserving computing in specific enable improvements of risk management in SCNs but the interaction of the various layers as described above leaves unsolved challenges for research; this contribution cannot solve at once.

6. Conclusion

In this paper, we proposed an artifact which preserves privacy and identifies the risky players in the SCNs applying the BC measure. Based on the guidelines of [31, 32] for conducting design science research, we can summarize our work as follows: our artifact consists of four main methods. It is an exaptation solution, because we adopted the existing methods in social networks and cryptography algorithms to identify risks in SCNs. Our artifact is formally noted and therefore is well defined. Based on the literature (e.g., [35]) we addressed two relevant problems: the risk identification in SCNs and privacy concerns of firms in SCNs. We focused on the study of [15] and decided to calculate the BC as a measure to identify risky firms. In the evaluation section, beside the testing and descriptive evaluation, we illustrated that, in our artifact, even in a small exemplary network, the inferred information is limited. To develop a rigorous artifact, we applied well established methods of other fields and extended them to our problem context. Regarding the contribution of our result, we choose the evolving technical solutions in computer science and network theory, to answer the question of risk management in SCNs.

In this paper, we focused on identifying risks and kept the information as private as possible. However, higher visibility in the network facilitates improved risk management [67]. Therefore, it might be necessary that firms agree on sharing more information than the BCs. For instance, they might decide to reveal the identities of firms with the BC among top 10%, because they are the most risky ones for the network. On the one hand, the more information is shared, the highest is the privacy at risk, and on the other hand it is inevitable to share extra information to reach the network’s robustness. Hence, the firms in the network should deal with the trade-off between sharing additional information to facilitate risk management in the network or preserve their privacy.

Although the BC measure identifies the risks in the SCN, integration of complementary network analysis approaches (e.g., [18]) in our artifact for enhanced risk identification is subject to further research. It is also important to study the intensity of connection and their impacts on the network. These subjects as well as improvement of computational complexity are subject to further research.

Appendix

See Tables 8 and 9.

Table 8: Description of the commonly used variables.

Variable
Mathematical Variable
Description

:

Denotes the unique number of the source player.

:

Denotes the unique number of the target player.

:

Denotes the unique number of the current instance of the class Player.

:

Denotes the unique number of a neighboring player.

:

Denotes the unique number of a given player.

Table 9: Description of the variable defined for calculateSecureShortestPath() method.

Variable
Mathematical Variable
Description

:

Denotes a temporary variable saving the distances during calculation of the shortest paths. This variable ensure data consistency.

Data Availability

All data arising from this study are contained within the manuscript.

Conflicts of Interest

The authors declare that there are no conflicts of interest regarding the publication of this article.

Acknowledgments

This research was (in part) carried out in the context of the Project Group Business and Information Systems Engineering of the Fraunhofer Institute for Applied Information Technology FIT. Grateful acknowledgement is due to the DFG (German Research Foundation) for their Grant [ITPM (FR 2987/2-1, BU 809/13-1)] making this paper possible.

References

H. Peck, Creating Resilient Supply Chains: A Practical Guide, Cranfield University, United Kingdom, 2003.

S. M. Wagner and N. Neshat, “A comparison of supply chain vulnerability indices for different categories of firms,” International Journal of Production Research, vol. 50, no. 11, pp. 2877–2891, 2012.

D. Helbing, “Globally networked risks and how to respond,” Nature, vol. 497, no. 7447, pp. 51–59, 2013.

D. Acemoglu, A. Ozdaglar, and A. Tahbaz-Salehi, “Networks, Shocks, and Systemic Risk,” National Bureau of Economic Research w20931, 2015.

C. Ellinas, N. Allan, and A. Johansson, “Project systemic risk: Application examples of a network model,” International Journal of Production Economics, vol. 182, pp. 50–62, 2016.

HBR Advisory Council, “Is Your Supply Chain Sustainable?,” Harvard Business Review;, vol. 88, no. 10, p. 74, 2010.

World Economic Forum, “Global Risks 2008: A Global Risk Network Report,” 2008.

G. Fridgen, C. Stepanek, and T. Wolf, “Investigation of exogenous shocks in complex supply networks - A modular petri net approach,” International Journal of Production Research, vol. 53, no. 5, pp. 1387–1408, 2015.

M. Giannakis and M. Louis, “A multi-agent based framework for supply chain risk management,” Journal of Purchasing and Supply Management, vol. 17, no. 1, pp. 23–31, 2011.

L. K. Chu, Y. Shi, S. Lin, D. Sculli, and J. Ni, “Fuzzy chance-constrained programming model for a multi-echelon reverse logistics network for household appliances,” Journal of the Operational Research Society, vol. 61, no. 4, pp. 551–560, 2010.

C. Blome and T. Schoenherr, “Supply chain risk management in financial crises - A multiple case-study approach,” International Journal of Production Economics, vol. 134, no. 1, pp. 43–57, 2011.

T. Y. Choi and Y. Hong, “Unveiling the structure of supply networks: Case studies in Honda, Acura, and DaimlerChrysler,” Journal of Operations Management, vol. 20, no. 5, pp. 469–493, 2002.

R. Wilding, B. Wagner, J. Miemczyk, T. E. Johnsen, and M. Macquet, “Sustainable purchasing and supply management: A structured literature review of definitions and measures at the dyad, chain and network levels,” Supply Chain Management: An International Journal, vol. 17, no. 5, pp. 478–496, 2012.

K. Zhao, A. Kumar, T. P. Harrison, and J. Yen, “Analyzing the resilience of complex supply network topologies against random and targeted Disruptions,” IEEE Systems Journal, vol. 5, no. 1, pp. 28–39, 2011.

Y. Kim, T. Y. Choi, T. Yan, and K. Dooley, “Structural investigation of supply networks: A social network analysis approach,” Journal of Operations Management, vol. 29, no. 3, pp. 194–211, 2011.

A. Vereecke, R. Van Dierdonck, and A. De Meyer, “A typology of plants in global manufacturing networks,” Management Science, vol. 52, no. 11, pp. 1737–1750, 2006.

K. J. Mizgier, M. P. Jüttner, and S. M. Wagner, “Bottleneck identification in supply chain networks,” International Journal of Production Research, vol. 51, no. 5, pp. 1477–1490, 2013.

M. E. J. Newman, Networks: An Introduction, Oxford University Press, Oxford, UK, 2010.

L. C. Freeman, “A set of measures of centrality based on betweenness,” Sociometry, vol. 40, no. 1, pp. 35–41, 1977.

S. Wasserman and K. Faust, Social Network Analysis: Methods and Applications, Cambridge University Press, Cambridge, UK, 1994.

J. Hallikas, I. Karvonen, U. Pulkkinen, V.-M. Virolainen, and M. Tuominen, “Risk management processes in supplier networks,” International Journal of Production Economics, vol. 90, no. 1, pp. 47–58, 2004.

W. Kersten, P. Hohrath, and M. Winter, “Risikomanagement in WertschöpfungsnetzwerkenStatus quo und aktuelle Herausforderungen,” Supply Chain Risk Management, p. 7, 2008.

U. Brandes, “A faster algorithm for betweenness centrality,” Journal of Mathematical Sociology, vol. 25, no. 2, pp. 163–177, 2001.

Y. V. Hochberg, A. Ljungqvist, and Y. Lu, “Whom you know matters: venture capital networks and investment performance,” The Journal of Finance, vol. 62, no. 1, pp. 251–301, 2007.

A. C.-C. Yao, “How to generate and exchange secrets,” in Proceedings of the 27th Annual Symposium on Foundations of Computer Science, pp. 162–167, Toronto, Canada, October 1986.

O. Goldreich, S. Micali, and A. Wigderson, “How to play any mental game,” in Proceedings of the Proceeding of the nineteenth annual ACM conference on Theory of Computing, pp. 218–229, IEEE Press, Piscataway, NJ, USA, 1987.

G. Fridgen and T. Zare Garizy, “Supply chain network risk analysis - A privacy preserving approach,” in Proceedings of the 23rd European Conference on Information Systems, ECIS 2015, deu, May 2015.

Tirazheh Zare Garizy, “Systemic Risk Assessment in Complex Network Structures: Information Technology as a Challenge and a Chance”.

T. Y. Choi and D. R. Krause, “The supply base and its complexity: implications for transaction costs, risks, responsiveness, and innovation,” Journal of Operations Management, vol. 24, no. 5, pp. 637–652, 2006.

D. R. Lessard, “Uncertainty and Risk in Global Supply Chains,” SSRN Electronic Journal.

A. R. Hevner, S. T. March, J. Park, and S. Ram, “Design science in information systems research,” MIS Quarterly: Management Information Systems, vol. 28, no. 1, pp. 75–105, 2004.

S. Gregor and A. R. Hevner, “Positioning and presenting design science research for maximum impact,” MIS Quarterly: Management Information Systems, vol. 37, no. 2, pp. 337–355, 2013.

J. Blackhurst, T. Wu, and P. O'Grady, “Network-based approach to modelling uncertainty in a supply chain,” International Journal of Production Research, vol. 42, no. 8, pp. 1639–1658, 2004.

M. Arns, M. Fischer, P. Kemper, and C. Tepper, “Supply chain modelling and its analytical evaluation,” Journal of the Operational Research Society, vol. 53, no. 8, pp. 885–894, 2002.

H. U. Buhl and H.-G. Penzel, “The Chance and Risk of Global Interdependent Networks,” Business & Information Systems Engineering, vol. 2, no. 6, pp. 333–336, 2010.

V. Babich, A. N. Burnetas, and P. H. Ritchken, “Competition and diversification effects in supply chains with supplier default risk,” Manufacturing & Service Operations Management, vol. 9, no. 2, pp. 123–146, 2007.

J. F. Yates and E. R. Stone, “The risk construct,” in The risk construct, behavior. Risk-taking and J. F. Yates, Eds., pp. 49–85, John Wiley & Sons, New York, 1992.

T. Gyorey, M. Jochim, and S. Norton, “The challenges ahead for supply chains,” McKinsey on Supply Chain: Select Publications, pp. 10–15, 2011.

M. A. Bellamy and R. C. Basole, “Network analysis of supply chain systems: A systematic review and future research,” Systems Engineering, vol. 16, no. 2, pp. 235–249, 2013.

M. Li and T. Y. Choi, “Triads in services outsourcing: Bridge, bridge decay and bridge transfer,” Journal of Supply Chain Management, vol. 45, no. 3, pp. 27–39, 2009.

A. C. Yao, “Protocols for secure computations,” in Proceedings of the 23rd Annual Symposium on Foundations of Computer Science, pp. 160–164, 1982.

A. Shamir, “How to share a secret,” Communications of the ACM, vol. 22, no. 11, pp. 612-613, 1979.

R. Sheikh, B. Kumar, and D. K. Mishra, “Privacy Preserving k Secure Sum Protocol,” International Journal of Computer Science and Information Security, vol. 6, no. 2, pp. 184–188, 2009.

R. Cramer, I. B. Damgard, and J. B. Nielsen, Secure Multiparty Computation and Secret Sharing, Cambridge University Press, Cambridge, 2015.

P. Bogetoft, I. Damgård, T. Jakobsen, K. Nielsen, J. Pagter, and T. Toft, “A practical implementation of secure auctions based on multiparty integer computation,” Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics): Preface, vol. 4107, pp. 142–147, 2006.

E. A. Abbe, A. E. Khandani, and A. W. Lo, “Privacy-preserving methods for sharing financial risk exposures,” American Economic Review, vol. 102, no. 3, pp. 65–70, 2012.

F. Kerschbaum, “Secure and sustainable benchmarking in clouds,” Business & Information Systems Engineering, vol. 3, no. 3, pp. 135–143, 2011.

F. Kerschbaum, A. Schroepfer, A. Zilli et al., “Secure collaborative supply-chain management,” The Computer Journal, vol. 44, no. 9, pp. 38–43, 2011.

D. Dolev and A. C. Yao, “On the security of public key protocols,” Institute of Electrical and Electronics Engineers Transactions on Information Theory, vol. 29, no. 2, pp. 198–208, 1983.

D. Beaver, S. Micali, and P. Rogaway, “The round complexity of secure protocols,” in Proceedings of the the twenty-second annual ACM symposium, pp. 503–513, Baltimore, Maryland, United States, May 1990.

Y. Lindell and B. Pinkas, “A proof of security of Yao's protocol for two-party computation,” Journal of Cryptology. The Journal of the International Association for Cryptologic Research, vol. 22, no. 2, pp. 161–188, 2009.

T. I. Reistad, “Multi-party secure position determination,” in in Norsk Informatikkonferanse NIK, pp. 137–142, Norwegian University of Science and Technology, Trondheim, 2006.

R. Jacob, D. Koschützki, K. A. Lehmann, L. Peeters, and D. Tenfelde-Podehl, “Algorithms for Centrality Indices,” in Network Analysis, vol. 3418 of Lecture Notes in Computer Science, pp. 62–82, Springer Berlin Heidelberg, Berlin, Heidelberg, 2005.

D. J. Klein, “Centrality measure in graphs,” Journal of Mathematical Chemistry, vol. 47, no. 4, pp. 1209–1223, 2010.

T. H. Cormen, C. E. Leiserson, and R. Rivest, An Introduction to Algorithms, MIT Press, Boston, Mass, USA, 2009.

E. F. Moore, “The shortest path through a maze,” in the International Symposium on the Theory of Switching, pp. 285–292, Harvard University Press.

E. W. Dijkstra, “A note on two problems in connexion with graphs,” Numerische Mathematik, vol. 1, pp. 269–271, 1959.

N. Edmonds, T. Hoefler, and A. Lumsdaine, “A space-efficient parallel algorithm for computing betweenness centrality in distributed memory,” in Proceedings of the 17th International Conference on High Performance Computing, HiPC 2010, ind, December 2010.

R. W. Floyd, “Algorithm 97: shortest path,” Communications of the ACM, vol. 5, no. 6, p. 345, 1962.

S. Warshall, “A theorem on boolean matrices,” Journal of the ACM, vol. 9, pp. 11-12, 1962.

S. Russell and P. Norvig, Artificial Intelligence: A Modern Approach, Prentice Hall, 2009.

J. Brickell and V. Shmatikov, “Privacy-preserving graph algorithms in the semi-honest model,” in Advances in Cryptology, vol. 3788 of Lecture Notes in Comput. Sci., pp. 236–252, Springer, Berlin, 2005.

R. Canetti, “Theory of cryptography,” in Fifth theory of cryptography conference, TCC, Springer Berlin Heidelberg, 2008.

Y. Huang, J. Katz, and D. Evans, “Quid-pro-quo-tocols: Strengthening semi-honest protocols with dual execution,” in Proceedings of the 33rd IEEE Symposium on Security and Privacy, S and P 2012, pp. 272–284, usa, May 2012.

T. Schneider, Engineering Secure Two-Party Computation Protocols: Design, Optimization, and Applications of Efficient Secure Function Evaluation, Springer Berlin, Berlin, Heidelberg, 2012.

T. G. Gill and A. R. Hevner, “A Fitness-Utility Model for Design Science Research,” ACM Transactions on Management Information Systems (TMIS), vol. 4, no. 2, pp. 1–24, 2013.

R. C. Basole and M. A. Bellamy, “Supply Network Structure, Visibility, and Risk Diffusion: A Computational Approach,” Decision Sciences, vol. 45, no. 4, pp. 753–789, 2014.