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

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 networkmany 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.


Introduction
In March 2000, a thunderstorm in New Mexico caused a 400million-dollar loss for the telecommunications equipment firm Ericsson.The fire in a semiconductor plant, a singlesource 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][9][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.

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.

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][43][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][50][51][52] as their security has been addressed comprehensively, as well.

Network Centrality Measures.
To calculate the BC, we model the SCN as a graph (, ).Each firm V in the SCN is represented by a vertex V ∈ .An economic dependency (e.g., material or financial flow) between firms , V ∈  is represented by an edge (, V) ∈  between these firms.In this case, we name  and V 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 V is calculated as follows [18]: In (1),   (V) ∈ N 0 is the number of shortest paths between source vertex  and target vertex , which pass through vertex V, 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.

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 1, 2, . . ., ||.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 7 players.Each player is represented by its own unique number.The set of vertices (players) is  = {1, 2, 3, 4, 5, 6, 7}.
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][63][64][65].
Assumption 2 (the connections in the SCN are equally weighted).In general, our artifact is applicable for graphs with  V ∈ R.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 (, V) ∈  with arbitrary , V ∈  is then defined by The × matrix  = ( V ) contains all weights of edges in the graph ∀ , V ∈  [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  ∈ V is represented by ℎ = ⟨V 0 , V 1 , . . ., V  ⟩.In this we assume that V 0 = , V  = , and (V −1 , V  ) ∈  for  = 1  .The length of the path is the sum of the weights of its forming edges.Based on (2) the weight of an edge is 1 therefore, if  vertices are forming a path, there are  − 1 edges on this path and (ℎ) =  − 1.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   = 1.To find a shortest path from a source vertex  to the target vertex t, the existing distance and the distance of all alternative paths via intermediate vertices ∀V ∈ , V ̸ = ,  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.

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 .
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.
For privacy preserving concerns, in methods calcu-lateSecureShortestPath(), 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   (V) decentrally.Each player has a portion of these values from its own perspective.We denote the portion of information which player  has by    , and    (V).The final values of   and   (V) are the sum of the decentrally calculated values of all players as follows.
The method calculateSecureBetweenness() uses the decentral values (   , and    (V)) to calculate the betweenness centrality and applies SMC algorithms to preserve privacy.
Table 3 elaborates on the sequences of our artifact.Steps 1 to 5 (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.
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 (aPlay-erNumber).We present a summary on these variables in the Appendix In Figure 3 we provide the pseudocode of calculateSe-cureShortestPath() 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.
Table 4 provides a detailed description of the calculateSe-cureShortestPath() 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.
In the following, Figure 5 presents the pseudocode of calculateNumberOfShortestPaths() method.
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 calculateNumberOfShort-estPaths(5,7) and identifies  (5)  57 = 1.Since player 7 is not a Security and Communication Networks 7 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 Ω.This method calculates the BC(V) 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.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 P l a y e r Each player executes the calculateSecureShortestPath() method for itself as the source player and all given targets in the network.

P l a y e r
Each player executes the calculateNumberOfShortestPaths() method to decentrally set the values of   for each given target .

P l a y e r
Each player executes the determinePlayersOnShortestPaths() method to decentrally calculate the values of   (V) for itself as source player  and each given target .By termination of the method for all given targets, the player informs ISA.Synchronization

I S A
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.

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.

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  ∈ N (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 6 shares 1 as its distance to players 7 ( 67 = 1), player 5 (as a neighboring player of player 6) infers that players 6 and 7 are adjacent.But if the method uses a modified value of the distance (we define,  for player 7 be 70), player 6 shares 71 as its distance to players 7 ( 67 = 71).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  for player 7 to 70.The distance of player 3 to 7 via player 5 is  37 = 73 and the distance of player 3 to 7 via player 6 is  37 = 72.Based on this information, player 3 reveals that players 5 and 6 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 5 is executing calculateSecureShortestPath (1,7)and it is the first request to player 5 for calculating the path to player 7. Players 5 and 7 are not adjacent and the initial value of the distance is  7 =  57 = ∞.In the meantime, player 5 receives the request for calculation of the path from source player 2 to target player 7 (calculateSecureShortestPath(2, 7)).If the execution of this requestends faster than calculateSecureShortestPath(1, 7), player 5 updates the distance to player 7 ( 7 ) to 72.Consequently, the value of  7 for the player 5 varies during the execution of calculateSecureShortestPath (1,7).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 1 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 (  = 1 (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 false otherwise 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 Ω t .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 Ω t .Finding an additional shortest path implies that player  is connecting player  with the shortest path to target player .Therefore, Line 35 adds player  to Ω  .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 (  = 1) 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 |Ω  | − 1, 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 neighboring player of player 5, and player 6 is in Ω 7 player the method calls itself from player 6. Player 6 does not identify any additional path (since player 6's Ω 7 = 0); therefore, it sets  (6)  57 = 0.At this point the method terminates while player 7 (the target) is a neighboring player of player 6.
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 deter-minePlayersOnShortestPaths(5,7) identifies  (5)  57 (6) = 1, while

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 |Ω  | − 1.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.

METHOD 3. determinePlayersOnShortestPaths
Input: sourcePlayerNumber s, targetPlayerNumber t. player 6 is in player 5's Ω 7 .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(V) method calculates the BC for player V 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 V based on (1) is as follows: where  = || and  = || − 1. ( 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 abovementioned 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   (V) ∀ ̸ = V ̸ =  ∈  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   (V) 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.

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  st (V) 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 5 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.
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 {(s, t) | s < t}.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.
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).
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

Table 1 :
[27]ription of the attributes of the class player[27].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.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.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.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 V.
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.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.

Table 3 :
427]artifact's sequences[27]., with all players in the network and notifies the players to initialize.4PlayerEach player initializes a new object of class Player and informs ISA. 5