Privacy-aware Adaptive Scheduling for Coalition Operations
Abstract
Coalition operations are essential for responding to the increasing number of world-wide incidents that require large-scale humanitarian assistance.
Many nations and non- governmental organizations regularly coordinate to address such problems but their cooperation is often impeded by lim- its on what information they are able to share.
In this paper, we consider the use of an advanced cryptographic tech- nique called secure multi-party computation to enable coalition members to achieve joint objectives while still meet- ing privacy requirements.
Our particular focus is on a multination aid delivery scheduling task that involves coordinating when and where various aid provider nations will deliver relief materials after the occurrence of a natural disaster.
Even with the use of secure multi-party computation technology, information about private data can leak.
We describe how the emerging ﬁeld of quantitative information ﬂow can be used to help data owners understand the extent to which private data might become vulnerable as the result of possible or actual scheduling operations, and to enable automated adjustments of the scheduling process to ensure privacy requirements.
Introduction
Coalition operations are becoming an increasing focus for many nations.
The need for collaboration derives from increasing awareness of mutual interests among both allies and nations that traditionally have not worked closely together.
For example, coalition operations for Humanitarian Assistance and Disaster Relief (HADR) have increased substantially in recent years in both numbers and scope.
With the impact of global warming, it is anticipated that there will be even more large-scale humanitarian crises resulting from adverse weather-related events and sea-level rises.
These coalitions often involve not just government and military organizations but also non-governmental organizations (NGOs) and commercial entities.
A key challenge facing coalitions is how to collaborate without releasing information that could jeopardize national (or organizational) interests.
Information security mechanisms for the military to date have focused on safeguarding information by limiting its access and use.
This approach has lead to a signiﬁcant undersharing problem, which impedes
Distribution Statement A: Approved for Public Release; Distribution is Unlimited.
effective joint operations.
Recent work on deﬁning access control mechanisms is useful for enabling selective sharing of information that is safe to release (Phillips, Ting, and Demurjian 2002).
However, many coalition tasks require information that participants do not wish to make available to others.
For example, consider the problem of scheduling the delivery of aid (food, water, medicine, fuel) to impacted nations after a natural disaster.
Historically, international response has involved dozens of countries and NGOs, each with the desire to contribute in interconnected and potentially conﬂicting ways.
Ideally coordination would be achieved by directly sharing information about the amount of aid each contributor has available or can produce, where that aid is situated, the position and storage capacity of ships for delivering the aid, harbor facilities where aid ships could dock, etc.
But the owners of this data may be unwilling to directly share it with coalition partners, for fear of revealing information that impacts national security (e.g., ship locations) or competitive advantages (e.g., a company’s backlog of inventory).
To address this problem of coalition collaboration without revealing private information, we exploit a cryptographic technology called secure multi-party computation (MPC) (Yao 1982).
MPC protocols enable mutually distrusting parties to perform joint computations on private information while it remains encrypted.
In our work, we use MPC to enable privacy-preserving computations over several types of coordination tasks related to scheduling aid delivery.
While participants cannot directly learn others’ private inputs from the process/protocol of a secure multi-party computation, they may be able to infer something about private data based on the results of the computation.
For this reason, our privacy-aware scheduling solution makes use of a complementary technology called quantitative information ﬂow (QIF) to measure the degree to which private data used in the scheduling task might leak to other participants.
Insights gained from this analysis are folded back into the scheduling process via an adaptive workﬂow capability, to ensure that the vulnerability of private data stays within acceptable thresholds.
The paper is organized as follows.
We begin by summarizing our aid distribution task, including a description of the core scheduling problem and the data (private and non-private) belonging to the various coalition members.
We then provide a short overview of secure multi-party computation followed by a description of how we employ it within a broader adaptive workﬂow framework to address the aid delivery scheduling task.
Next, we describe our use of quantitative information ﬂow to assess the vulnerability of private information as the scheduling progresses and to adapt the scheduling workﬂow in light of those assessments to ensure adherence to predeﬁned privacy requirements.
We conclude by identifying directions for future work and summarizing our contributions.
HADR Aid Delivery Problem
The aid delivery problem that we consider involves two categories of participants:
• N Aid Provider nations, each of which has some number S n of ships with aid (e.g., food, medicine) to be delivered • a single Aid Recipient nation that has P ports to which aid can be delivered
Collectively, these participants need to formulate a schedule for delivering aid on board the Aid Provider ships to ports belonging to the Aid Recipient, ensuring delivery prior to a speciﬁed deadline.
As summarized in Figure 1a , a solution involves assigning to each Aid Provider ship: a port to which its aid should be delivered, a berth at the port, and a docking time.
These assignments are subject to various constraints on ship and port characteristics to ensure physical compatibility between the ship and the port/berth, schedule availability of the berth, and the ability for the ship to completing the docking before the assigned deadline.
We further seek an assignment that optimizes according to the following load-balancing criteria.
Optimization Criteria: Load-balancing across ports.
Let Assigned ( Port i ) designate the number of aid provider ships assigned to aid recipient port Port i .
An optimal solution is a set of assignments that minimizes
MAX j,k ( | Assigned ( Port j ) − Assigned ( Port k ) | )
Generating a solution to this scheduling problem requires information from the various parties about their assets (ships, ports), some of which they would prefer not to share with other coalition members.
Figure 1b summarizes this private data.
In both Figure 1b and Figure 1a the problem data is color-coded, with blue used for private data belonging to an Aid Provider nation and green for private data belonging to the Aid Recipient nation.
As the coloring clearly shows, determining a solution requires combining private information from multiple parties, which motivates our use of secure multi-party within our scheduling algorithm.
Secure Multi-Party Computation
To address privacy concerns in our aid delivery use case, we leverage MPC.
MPC protocols compute a function and reveal the output of the computation without revealing private inputs to any other participant.
Early MPC work was based on two-party problems (Yao 1982), and subsequent work produced general approaches for any number of participants to participate in shared computation without learning private information (Goldreich, Micali, and Wigderson 1987).
Most MPC approaches involve modeling the desired algorithm as a boolean circuit (ﬁxed-time algorithms expressed as a combination of AND , OR , and NOT logic gates).
However, circuit-based approaches may require unrolling loops, introducing potential performance implications.
Alternate approaches based on Oblivious RAM (Goldreich and Ostrovsky 1996) do not require this full unrolling though have other performance trade-offs.
We use a circuit-based MPC approach in our scenario, though our privacy analysis and adaptive scheduling do not depend on the speciﬁcs of the underlying MPC approach.
MPC has proven to be a powerful tool to enable a wide range of use cases.
For example, private keys can be split among several hosts in order to reduce the number of hosts that must be compromised in order to obtain the key.
A computation that requires the decryption operation can then be done under MPC between the hosts, ensuring that the whole key is never revealed in the clear (Archer et al. 2018).
MPC can also be used between companies in collaborative supplychain management, where the reluctance to share sensitive data (such as costing and capacities) can lead to sub-optimal production plans.
The use of MPC allows for collaborative supply-chain planning without compromising sensitive data (Kerschbaum et al. 2011).
In our setting, each data owner provides their private input to a MPC circuit designed such that their inputs are not revealed to other participants.
Then participants follow the protocol for the multi-party computation, which allows them to collectively compute the solution to the planning and scheduling optimization problem.
In the end, only the ﬁnal result (schedule) is revealed to the relevant parties.
Scheduling Workﬂow
Creating a single MPC circuit to solve the full optimized scheduling problem in a general way is not practical at this point in time. For this reason, our solution approach consists of a workﬂow that decomposes the scheduling task into the following sequence of steps.
Step A. Collect relevant inputs: • Aid Provider: determine ports that can be reached by each ship before the deadline D • Aid Recipient: select ports to which aid will be accepted Step B. Determine ports that satisfy joint ship/harbor physical compatibility constraints: • Aid Provider ship draft is compatible with the harbor depth in the port • Aid Recipient port has sufﬁcient ofﬂoad capacity Step C. Determine all berths within each feasible port from Step B that satisfy joint ship/berth compatibility and berth availability constraints: • Aid Provider ship ﬁts within the berth
For a Ship to be scheduled to dock at a given Docking Time at a Berth belonging to a Port , the following must hold:
Port
• ship-draft ≤ port-harbor-depth • ship-cargo-amount ≤ port-cargo-ofﬂoad-capacity • ship-earliest-arrival =
EarthDistance ( ship-location , port ) ship-maxspeed • ship-earliest-arrival ≤ deadline
Berth in Port
• ship-length ≤ berth-length
Docking Time at Berth
• ship-earliest-arrival ≤ docking-time ≤ deadline • berth-availability (pairs of berth-occupied-start and berth-occupied-end ) for berth at docking-time Constraints
the
Aid Provider
Aid Recipient
Ship Info
Port Info
Berth Info ship-location port-available berth-length ship-length port-cargo-ofﬂoad-capacity berth-occupied-start ship-draft port-harbor-depth berth-occupied-end ship-maxspeed
[Figure]
• Aid Recipient berth is available at planned ship arrival
Step D. Schedule the aid ships across possible ship-portberth-arrival-time options (from Step C) in accordance with the optimization goal of load-balancing across ports.
Step A is a simple information gathering/ﬁltering task performed locally by individual participants.
Step B requires computation over private inputs from both the Aid Provider and the Aid Recipient.
Steps C and D combine private inputs with intermediate results from earlier steps.
For these reasons, we use three secure multi-party circuits within our workﬂow:
• A two-party circuit for the physical compatibility test in Step B (Aid Provider and Aid Recipient) •
A two-party circuit for the viability test in Step C (Aid Provider and Aid Recipient) • An N-party circuit for optimizing berth allocation in Step D (all N Aid Providers)
The circuits for Steps B and C are straightforward but must be run for each possible ship/port (Step B) and
ship/berth (Step C) combination.
The circuit for Step D is more complex.
Because it is not possible to implement a truly optimized solution in the MPC circuit model, we instead opted for the following greedy approach to load balancing across ports.
Initialization: set the list of ship-port-berth solutions to be empty and the working set of options to be the set of shipport-berth-unload time entries from Step C 2.
Select a port P with the fewest number of assignments and for which there remain options 3.
Select earliest ship-port-berth-unload time entry for P and add to the solutions list 4.
Remove from the set of options all entries for the ship and berth selected in Step5.
Repeat steps 2-4 until no more ship-port-berth solutions remain 6.
Output the solution list
We use the Lumen agent technology (described in (Myers et al. 2011)) to provide an adaptive workﬂow capability for executing this scheduling process.
Although we depict only one workﬂow here, more generally our adaptive workﬂow capability draws from a library of alternative approaches to a range of aid distribution scheduling problems, enabling solution approaches to be matched to the speciﬁcs of a given situation.
For example, we have deﬁned alternative workﬂows that embed different scheduling and optimization strategies and that make use of secure multi-party computation in different ways as a means of investigating tradeoffs between efﬁciency and privacy.
Quantifying Information Vulnerability
In this section we describe what is involved in using QIF to reason about questions of how private data can be inferred from the results of a computation.
Limitations of Multi-Party Computation
The “Millionaires’ Problem” (Yao 1982) is an early usecase for multi-party computation in which two people, Alice and Bob, use MPC to securely determine which of them is richer without revealing their actual wealth to each other.
But while they don’t learn the other’s precise values, they do learn something about each other.
The nature of the relationship between the revealed output and the private inputs determines how much one may infer about the inputs from the result.
For example, if Alice and
Bob use MPC to instead compute the arithmetic mean of their net worths, Alice could use the input she provided and the resulting mean from the computation to solve for Bob’s exact net worth.
Alice may not be able to extract Bob’s input via examination of the MPC circuit itself, but MPC cannot change the relationship between inputs and output that exists outside the circuit.
In our Aid Delivery scenario, private “inputs” may involve sensitive capability and operational details.
As the scenarios increase in scope and complexity, it becomes difﬁcult to reason informally about what an adversary may be able to infer.
1 We use Quantitative Information Flow (QIF) to address these concerns by characterizing an adversary’s ability to make these inferences based on information-theoretic bounds on the relationship between results and private inputs.
Modeling Workﬂows
A QIF analysis begins by transforming a program (such as our aid distribution workﬂow) into a model that represents the relationship between the (private) inputs and outputs.
Speciﬁcally, these models are based on informationtheoretic channels , which we use to construct a mapping from prior 2 distributions on private data to distributions on posterior distributions (Smith 2011; 2009).
We use these models to support “predictive-mode” adaptive workﬂows in which we reason about what an adversary could learn from any possible set of private inputs, as well as “posterior-mode” in which we determine how much an adversary may learn from some speciﬁc concrete result.
Quantifying Inference Capabilities
We can construct games in which we quantify the adversary’s inference capability by measuring how their chances of “winning” (i.e., guessing a piece of private data) improve given additional information.
We call the probability that an adversary can with one chance correctly guess a piece of private data the vulnerability of that variable.
In the “prior game,” the defender picks a private input value by sampling from the prior distribution of possible input values.
The adversary makes their best guess of the defender’s input based only on their knowledge of the prior distribution of possible input values.
The prior vulnerability is the probability the adversary will correctly guess the defender’s private input (without any additional information).
In the “posterior game,” the defender again picks a private input, but then performs the computation using that input and shares (only) the result with the adversary.
We also assume the adversary has full knowledge of how the inputs relate to outputs in the computation (e.g., could construct an identical channel-based model of the computation).
Here the chance the adversary correctly guesses the defender’s private input is called the posterior vulnerability .
To summarize, the prior game is how likely an adversary is to guess the private input before seeing the result of the computation, the posterior game is how likely the adversary is to guess the private input after seeing the speciﬁc output of the computation.
The Use of Vulnerability as a Metric
Vulnerability as a metric of risk is appealing because of its relatively intuitive nature.
The caveat to vulnerability as a metric is that it is extremely sensitive to the chosen prior belief.
Therefore, care must be taken in deciding upon a prior in order to assure that the metric reﬂects reality as much as possible.
Supporting Workﬂow Adaptation
Our predictive-mode adaptation strategy is based on QIF predictive leakage , which attempts to predict how much will be leaked about the private data before the computation is run on the concrete private values.
We can also approximate predictive leakage using Monte Carlo simulation, permitting the use of these metrics even in scenarios where operational requirements make it infeasible to complete the precise predictive leakage within a desired time frame.
Incorporating predictive leakage metrics into our workﬂows enables identiﬁcation of potentially higher-risk situations where it may be preferable to adapt or halt the workﬂow (based on some policy) rather than participating in a computation that may reveal too much.
Our posterior-mode adaptation strategy is based on QIF dynamic leakage , which takes into account the actual results of a computation.
As opposed to the predictive leakage’s assessments, that average all possible private input values, dynamic leakage enables our workﬂows to incorporate more accurate assessments of what was actually revealed in the speciﬁc ongoing workﬂow.
Sample Vulnerability Analysis
As discussed previously, the HADR aid delivery problem provides a strong foundation for analyzing adaptive workﬂows in a privacy-aware setting.
In this section we describe how the notion of vulnerability can be used to inform the cooperating parties of risk to their private data.
A Simplifying Example
To begin our discussion we ﬁrst describe a simpliﬁed version of the HADR aid delivery problem involving a single ship,
S , and a single port, P .
In this simpliﬁed scenario, the only private data is S ’s location ( ship_loc ).
We assume that other relevant data (such as ship maximum speed) is known publicly.
def reachable(deadline): dist = distance(ship_loc, port_loc) return (dist <
= (max_speed * deadline))
The channel is “is S able to reach port P within d hours?”.
As pseudo-code we write this channel as a function of d , over some global set of private ( ship_loc ) and public ( port_loc , max_speed ) variables.
Prior Belief In our simpliﬁed scenario an adversary who wants to determine S ’s private data will have some prior belief about that data.
In this case, the prior belief will be some area of the ocean where S could be located.
This may or may not be informed by other information available to the adversary.
While QIF can be calculated over non-uniform priors, in this exposition we assume uniform priors for the sake of simplicity.
Figure 3a shows a graphical representation of a possible prior for the simpliﬁed scenario.
Because our prior is uniform, the adversary’s chance of guessing the ship’s position (the prior vulnerability , V prior ), is simply
V prior = number of possible locations in the prior
This makes intuitive sense: under a uniform prior, the adversary’s likelihood of winning the prior game is equivalent to choosing a point out of the prior at random.
Posterior Belief When ship S , cooperating in the simpliﬁed scenario, responds to the reachable query in Figure 2, the adversary is able to observe the output of the channel.
This observation allows the adversary to rule out entire sections of the space of possible locations.
If the result of the query is True , then the adversary can infer that the location of S is within a circle of radius r , where r is the distance that the ship can travel at max_speed with deadline amount of time.
Inversely, if the result of the query is False , then the adversary could infer that the ship must be outside of the same circle.
Observing False is the circumstance illustrated in Figure 3b.
The important point is to see that regardless of the result of the query, the adversary may be able to infer rule out subsets of possible values for the private data.
The probability the adversary has of guessing the ship’s position after seeing the channel output (the posterior vulnerability , V post ) is simply
V post = number of possible locations in the posterior
Further Queries Because cooperation is the goal, it is likely that the coordinator of our simple scenario will need to query S multiple times.
This is particularly true if the initial query’s result was False .
The coordinator may query
S with reachable(d2) , where d 2 is a new, longer, deadline.
If the result is then True then the adversary is able to infer that S resides within the ring formed by two overlapping circles: an inner circle with radius r , described above, and a wider circle with radius r 2 , where r 2 is the distance that S is able to travel at max speed in time d 2 .
This circumstance is illustrated in Figure 3c.
Worst-Case Simple Scenario
If we add another port, P 2 , to the simple scenario above, but keep all other details the same, it may be possible for S ’s location to be determined within a very small tolerance.
If the result of reachable is True for both P and P 2 , then (using the same process as above) the adversary would intersect the appropriate circles.
The smaller the intersection, the more the adversary knows about the ship’s position.
Analysis of the Aid Distribution Scenario
The simpliﬁed scenario above only has one piece of private data: the ship’s position.
As a reminder, Figure 1b shows the private data in the full HADR scenario.
In this section we present some results from an analysis over a model of the full scenario, using a single ship (Ship #9) as a running example.
Prior Vulnerability As discussed above, an adversary has some notion of the possible values that a secret can take on even before running any computations over that secret data.
This is referred to as the Prior .
When analyzing a system, the analyst must choose appropriate ranges for the private data in question.
For some variables this may be straightforward (e.g., the ocean sector in question when deciding on a prior for a ship’s location), for others it may depend on domain knowledge (e.g., the appropriate range for naval ship drafts).
We can visualize the prior vulnerability over location easily.
Figure 5 shows several aspects of the HADR scenario.
The boundaries of the map in the image are the boundaries of the prior belief over ship position.
It is important to remind ourselves that the choice of prior (part of which is determined by the geographic area under consideration) affects the vulnerability metric signiﬁcantly.
Increasing the area decreases the prior vulnerability, while decreasing the area increases the prior vulnerability.
Because the prior models the adversary’s view of the world, it should be constructed carefully.
Predictive Vulnerability for Steps A+B
In resourceconstrained systems, it is useful to be able to predict how much of a given resource would be used if a certain action were to be executed.
Private data can similarly be viewed as a form of resource for which predictive analysis can be applied to assess the impact of planned or possible actions.
The ability to predict the future vulnerability can be implemented in several ways, the practicality and efﬁciency of different methods depends heavily on the constraints of the system, imposed by the state-space and the adversarial model.
[Figure]
In our system we have chosen an approximate method that enables an analyst to calculate a histogram over the possible vulnerability outcomes without any access to the private data.
This method uses Monte Carlo simulation to run our analysis over randomly sampled points from the space of possible private data values.
Figure 4 shows the results of a Monte Carlo simulation of the predictive vulnerability of running Steps A+B (using 13788 samples 4 ).
The vertical dotted line shows the median value ( 6 . 847603e − 6% ) of all the samples.
This method of approximation provides analysts with various options.
In a scenario where the preservation of privacy is paramount, the analyst may focus on the right-hand side of the ﬁgure, where the potential vulnerability is higher, 0 .
03039514% , though still unlikely.
This method also adapts well to use cases where an analyst may have access to some of the private data.
For example, an analyst for one of the coalition partner nations might have access to that nation’s private data, but not the private data of the ports.
Using this same method of sampling from the space of (unknown) private data, such an analyst would be able to approximate the future vulnerability of their data if they were to respond to a query.
Posterior Vulnerability for Steps A+B
Once a step is taken, we can calculate the posterior vulnerability of the private data.
Unlike the predictive analysis in the previous section, this analysis is ‘exact’ in that the real vulnerability cannot be more than what the analysis reports.
Ship # [Table] Position 6 . 847603e
[Equation]
In this case, the posterior vulnerability coincides with the median of the predictive vulnerability.
This is not too surprising as the median was also the most likely value by a signiﬁcant margin.
Predictive Vulnerability for Step C Figure 6 shows the
Monte Carlo simulation for vulnerability of a ship after Step
C is completed.
The median predicted value in this instance, 6 .
644298e − 4% , is two orders of magnitude higher than the vulnerability after Steps A+B alone.
This makes intuitive sense as much more information is revealed after Step
C that can be used to infer a ship’s private data.
Unsurprisingly, the maximum sampled predictive vulnerability is also substantially higher: 0 .
Posterior Vulnerability for Steps C
As with the posterior vulnerability for Steps A+B, the posterior vulnerability for
Step C is based on a sound analysis using the real results of the workﬂow step, and are not simulated as in the predictive vulnerability.
Ship #9 Position
[Equation]
In the case of Step C, the posterior vulnerability for
Ship #9 is lower than the median of the predictive result ( 6 . 644298e − 4% ).
From an analyst’s perspective, this could mean that Ship #9 has revealed even less about its private data than the ‘average’ ship would in this scenario.
Why Step D doesn’t leak Step D has no meaningful consequences on the vulnerability of the private data for any stakeholder in the HADR scenario if the result of Step C has been observed by the adversary .
The reason for this is that
Step D’s algorithm can be computed completely from the results of previous steps in the workﬂow, i.e. it does not require the values of the private data directly.
Interestingly, this point reinforces an important aspect of QIF analysis: even though Step C’s result was computed with private data, the vulnerability metrics from the QIF analysis of Step C take into account any possible use of the result.
Therefore additional computation over the results of Step C (or any prior step) does not affect the vulnerability of private data.
Privacy-aware Workﬂow Adaptation
The vulnerability assessment computed by the QIF capability provides insights to data owners as to the security of private information that they wish to protect.
We exploit these insights within our workﬂow manager to adapt the scheduling process in order to ensure adherence to privacy objectives.
More speciﬁcally, we use the QIF capability in two ways: in a predictive mode to estimate the amount of leakage associated with potentially performing a particular query or task and in a posterior mode to track actual leakage based on the speciﬁc values that a query or task returns.
When executing a particular task our workﬂow manager invokes the predictive mode to estimate leakage.
If the estimate of aggregate leakage for designated private data does not exceed set thresholds, then the workﬂow proceeds and the posterior leakage analysis is invoked to determine actual leakage values.
If the estimate does exceed the threshold then the workﬂow is either terminated or (if possible) modiﬁed via a remediation strategy to keep leakage below the threshold.
The idea behind a remediation strategy is to modify the problem or state in ways that will likely reduce impacts on private data.
For example, our aid delivery problem requires computing the reachability of a port by a given deadline.
Knowing that a given ship can reach the port by that deadline reveals information about the combination of ship position and maximum speed.
One simple remediation strategy is to postpone the deadline, which will reveal less information about the position and speed values (e.g., the fact that a ship can reach a port by a given deadline reveals something about the lower bound for its max-speed; a later deadline introduces greater uncertainty as to what that speed might be by decreasing that lower bound).
Our Lumen-based adaptive workﬂow engine includes such remediation strategies to enable adaptivity based on QIF predictive analyses.
Privacy thresholds are implemented using an existing policy framework within Lumen that was developed previously to enable users to impose boundaries on the behaviors of autonomous agents (Myers and Morley 2003).
The privacy policies have the general form:
Keep below <percentage>
the probability of knowing
<private-data> within <tolerance>
Below we show two examples used in the system, one for the Aid Provider nation and one for the Aid Recipient nation.
Aid Provider Sample Policy: “Keep below 10 % the probability of knowing the location of my ships within 50 NMs”
Aid Recipient Sample Policy: “Keep below 20 % the probability of knowing the port harbor depth within 40 feet”
Figure 7 shows sample vulnerability assessments for two types of private data (max-speed, location) for a select set of ships belonging to an individual Aid Provider nation.
The top image shows the initial vulnerabilities of the data, prior to performing any computations; the bottom image shows the vunlerabilities after workﬂow completion.
The display shows the QIF-derived vulnerability level as a colored bar representing the adversary’s likelihood of guessing the private data within the speciﬁed tolerance.
The vertical line bisecting the display for each piece of private data marks the policy-prescribed threshold of acceptability for the vulnerability.
We note that the initial vulnerabilities for the ship locations are non-zero but so small as to not be perceptible in the image.
Future Work
Here, we consider two avenues for future work.
Analogs can be drawn between our use of the QIF analysis to predict and track vunlerabilities of private data within the scheduling workﬂow and prior work on estimating resource usage in workﬂows (Morley, Myers, and YorkeSmith 2006).
Although we currently consider individual actions incrementally as the workﬂow executes, we envision performing predictive vulnerability assessments of entire workﬂows prior to execution, to enable informed choices about alternative approaches before any information usage has occurred.
Generating useful assessments will require predictive QIF techniques that consider cases beyond worstcase leakage, whose inherent pessimism can make them of limited value for certain vulnerability assessment tasks.
Longer term, such analyses could also potentially open the door to using ﬁrst-principles planning techniques to synthesize privacy-aware workﬂows on an as needed basis that are tailored to the speciﬁcs of a given task and privacy requirements.
The scalability of QIF techniques can be an issue for systems where there are complex relationships between sets of variables.
Some work has been done on attaining scalability by enhancing static analysis techniques with approximations that speed up analysis with probabilistic bounds on certainty (Sweet et al. 2018).
However, there is still further work required before the QIF analysis of arbitrary channels could scale to use cases such as the end-to-end HADR scenario considered in this paper.
In particular, the methods described in this paper utilize bespoke analyses for the channels under consideration, providing a more scalable approach at the cost of generality.
One future direction may be to design Domain Speciﬁc Languages that enable description of a scenario and its analysis in tandem.
Conclusion
A key challenge facing coalitions is how to collaborate without releasing information that could jeopardize national (or organizational) interests.
In this paper, we consider this challenge for a realistic scheduling problem tied to aid delivery.
Our work makes several contributions.
First, we show how state-of-the-art secure multi-party computation can be used to safeguard private information with an overall distributed scheduling solution to the aid delivery problem.
A second contribution relates to the use of quantitative information ﬂow (QIF): even with secure multi-party computation, scheduling outputs can reveal information about coalition members’ private data.
We show how QIF can be applied to assess the vulnerability of providate data for both prospective (i.e., where results are not known) and actual (i.e., where results are known) computations.
As a third contribution, these assessments can be used to adapt the scheduling algorithm to ensure it remains within accepted vulnerability thresholds established by data owners.
Acknowledgments
This material is based upon work supported by the Defense
Advanced Research Projects Agency (DARPA), the United
States Air Force, and the Space and Naval Warfare Systems
Center, Paciﬁc (SSC Paciﬁc) under Contracts No. FA875016-C-0022 and N66001-15-C-4071.
Any opinions, ﬁndings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reﬂect the views of DARPA, the Department of Defense, the United
States Air Force, or SSC Paciﬁc.
The authors thank Stealth Software Technologies, Inc.
(in particular; Steve Lu, Rafail Ostrovsky, Paul Bunn and
Chongwon Cho) for providing the MPC software that was used on this effort.