This presentation is locked until .

Mitch Negus

PhD Candidate

UC Berkeley, Dept. of Nuclear Engineering

No Data, No Problem

Giving nuclear inspectors better tools
without revealing state secrets

The following content includes static images of terrorism that some may find distressing.

Viewer discretion is advised.

Nuclear inspectors prevent material from being diverted to weapons purposes.

The Treaty on the Non-Proliferation of Nuclear Weapons

All but 4 countries have signed the treaty, and on this map, they are shaded in red. Signatories possessing nuclear weapons are shaded in blue, and those without are shaded in green.

For better or worse, as sophisticated data analytics become ubiquitous, it is anticipated that States will be increasingly reluctant to share anything more than the minimum amount of information that is required under their safeguards agreement with the IAEA. This is not generally because they intend to act illegally or make a nuclear weapon, but rather because they wish to protect proprietary business advantages, or sensitive State information. Still, while these protective stances aren't necessarily a bad thing when it comes to individual national security (for the vast majority of states, at least), they may pose an impediment to the IAEA detecting a diversion somewhere... and that could lead to catastrophe.

Privacy

Security

Privacy

Security

Secure Multiparty Computation

MPC

A Brief History of MPC

The idea of MPC has its roots in the late 1970s and early 1980s, and I'll largely be focusing here on one class of MPC algorithms called garbled circuits—credited to cryptographer Andrew Yao in the 1980s.

Yao presented what he called the millionaire's problem. Two millionaires go out to dinner, agreeing that the richer one covers the meal. Neither wishes to disclose their true net worth, so they devise an algorithm to indicate who's paying and nothing else.

There was more formulation and mathematical theory that was developed through the 1990s, and by the early 2000s software was being written to actually implement these MPC algorithms. As computing power has grown, the abilities of software implementations have grown with them, with MPC really only entering the scene as a practical technology in the past decade. A couple examples are privacy-preserving cryptocurrencies like Zcash, or an anonymous study on gender wage gaps by Boston University in 2015. Covid-19 contact tracing has recently spiked interest in these algorithms too.

With all this development, we decided to try applying MPC to our safeguards problem.

What can we DO?

What types of DATA?

Why hasn't it been DEPLOYED?

At the most basic level, we were asking the following questions:

What can we actually do with it? (Which specific safeguards problems would lend themselves to MPC?)
What types of data could we analyze?
And why isn't this already being deployed?

Let's start with the first question. The key insight about Yao's garbled circuits (and subsequent evolutions of them) is that they can handle literally any calculation that might be performed by multiple parties. If you can program a computer to do it, you can build a garbled circuit to do it. I'll come back to this in a bit.

As far as what data we could use? Well, we decided that an interesting exercise would be using MPC to analyze the output of the detectors like those relied on by IAEA inspectors.

Radiation Spectra

keV: kiloelectronvolts

Since every radioactive isotope (think "flavor" of an element) produces a unique radiation signature, measuring these emitted radioactive particles can tell an inspector exactly how much nuclear material—and what types—are in a location.

This plot of the spectra produced by uranium ore serves as a good illustration. You can see the distinct spectral peaks, each one where the detector measured many radioactive particles with the same energy. While none of these peaks actually correspond to the radiation from uranium itself, they come from a cocktail of radioactive particles that is really only produced in this observed ratio by uranium ore.

Taking this idea further, perhaps if we could "watch" the output of a detector over time, we could flag measurements with radioactive signatures for nuclear materials that are proliferation risks. This is what the IAEA inspectors and data analysts already do, but with MPC we could do it obliviously–we'd learn nothing else about the material compositions that are picked up by the detector.

What can we DO?

What types of DATA?

Why hasn't it been DEPLOYED?

MPC isn't yet used in safeguards today, due in part to:

Technical requirements

Viable MPC is a relatively new development.
Risk-averse inspectorate

Technologies must be rigorously proven, limiting reliance on the cutting edge.
Limited pool of expertise

Primary focus is on nuclear technology, so overlap with advanced cryptography is thin.

Well, on one hand, the technical requirements of MPC mean that only very recently have off-the-shelf computer systems been able to handle privacy-preserving computations of what would I would truly consider data-analytics.

Additionally, the IAEA is necessarily incredibly risk averse. You can't ride the cutting edge without taking risks, and when it comes to nuclear security, losing bets are not acceptable. The IAEA has to ensure that every technology put into practice is guaranteed to work. Oftentimes, this also means deployed technologies are customized to be extra secure and extra resilient. The IAEA's technology tends to be tried-and-true, not latest-and-greatest.

And finally, nuclear safeguards is a small field on a constrained budget. The pool of expertise is pretty limited, and unlike a lot of tech fields, nuclear safeguards isn't a moneymaker. That means that the technical overlap between nuclear fields and latest in cryptography is just pretty small.

Now, before I show you what we accomplished, I want to take a few minutes to explain how MPC actually works. It's super cool, but I told you it wasn't magic, and so I'm going to have to back that up.

$ A \stackrel{?}{=} B $

Digital logic circuits can evaluate any computable function.

2 Parties

Facility:
$F$
IAEA:
$I$

$F \stackrel{?}{=} I$

2 Parties

$\times$

2 Inputs

$F$
$=F_1 F_0$
$I$
$\,=I_1 I_0$

$F \stackrel{?}{=} I$

$\{$

$0 = 00_2$

$1 = 01_2$

$2 = 10_2$

$3 = 11_2$

Facility's Viewpoint

$ F = F_1 F_0 $

$ \;I = I_1 I_0 $

6fd0

🔑

32f1

🔑

ed56

••••

fddd

6fd0

🔑

c4d4

🔑

bd67

••••

ad11

131b

🔑

32f1

🔑

bd67

••••

c2bf

131b

🔑

c4d4

🔑

ed56

••••

4b0e

5e4d

🔑

253e

🔑

19b6

••••

0d14

5e4d

🔑

767a

🔑

7d2f

••••

cd16

41cb

🔑

253e

🔑

7d2f

••••

12cf

41cb

🔑

767a

🔑

19b6

••••

6dc9

bd67

🔑

7d2f

🔑

bbe9

••••

6f4e

bd67

🔑

19b6

🔑

bbe9

••••

b49c

ed56

🔑

7d2f

🔑

bbe9

••••

712a

ed56

🔑

19b6

🔑

0084

••••

f4de

Each party has two input wires to the circuit, and the party's integers are only the same if each bit in each input is the same. The gate that gives a one only when the bits are identical is the XNOR gate (you can see that on this truth table here). We have two of these XNOR gates, one for each pair of bits. Then, since both pairs of bits have to be the same, an AND gate gives us an output value of 1 only when both of the XNOR gates confirm a match.

Now, this is all relatively straightforward, and we can see all the bits clear as day. However, we need the circuit to be garbled.

Let's imagine that the facility goes through this circuit and replaces the two values on each wire with two random strings that only they know. Starting with the first XNOR gate, we replace the 0 and 1 on the first input wire, then 0 and 1 on the second input wire, and finally 0 and 1 on the output wire. We repeat this process for the second XNOR gate. And finally one last time for the AND gate. After the labels are added, we can still see the pattern from before, but that's the only thing that tells us whether a label corresponds to a 0 or a 1.

Next, the facility uses the input wire labels for each gate to symmetrically encrypt the gate's output wire label. We start in the first table, encrypting the first row, then the second, third, and fourth. The process is the same in the the other two. This produces a 4 encrypted tokens for each gate, one for each row in every truth table. If the facility were to hand you one token for each of the input wires to a gate, you could only successfully decrypt one of the four outputs. And, the only thing indicating now which encrypted token belongs to which row is the fact that they haven't moved from where they started. Let's change that. ((show shuffle))

Facility's Viewpoint

$ F = F_1 F_0 $

$ F = 1 \, 1_2 $

$ \;I = I_1 I_0 $

$ \;I = \, ? \, ? $

🔑

••••

ad11

🔑

••••

4b0e

🔑

••••

fddd

🔑

••••

c2bf

🔑

••••

6dc9

🔑

••••

12cf

🔑

••••

cd16

🔑

••••

0d14

🔑

••••

712a

🔑

••••

b49c

🔑

••••

f4de

🔑

••••

6f4e

Now remember, up until this point every step we've seen was performed by one party—the facility. The facility knows all the labels and what values they represent, and so they can give the labels matching their own input values to the IAEA. Since the other party hasn't seen any of this yet, they don't know which random label matches which wire value; that label is just a random string to them.

Now the IAEA needs to get the labels for its own input wires, but this presents a dilemma. It can't directly ask the facility for the label corresponding to it's bit choice, because then the facility knows that the IAEA's input is whichever one it asked for. Likewise, the IAEA can't be shown both labels and the matching values, because then it will be able to decrypt more than just one of the encrypted rows.

Oblivious Transfer

Facility

🔑 (0) = 32f1

🔑 (1) = c4d4

$\longrightarrow$

Inspector

$\longleftarrow$

🔑 (1)?

$\longrightarrow$

🔑 = c4d4

Inspector's Viewpoint

$ F = F_1 F_0 $

$ F = \, ? \, ? $

$ \;I = I_1 I_0 $

$ \;I = 1 \, 0_2 $

••••

ad11

131b

32f1

••••

bd67

4b0e

••••

fddd

••••

c2bf

41cb

767a

••••

19b6

6dc9

••••

12cf

••••

cd16

••••

0d14

••••

712a

bd67

19b6

••••

bbe9

b49c

••••

f4de

••••

6f4e

After executing oblivious transfer, the IAEA has all the labels it needs: labels matching its own known values, and labels matching the facility's unknown values. The IAEA can start walking through the circuit, successfully decrypting only one token for each gate. This decrypted token reveals the label on that gate's output wire, which can then be used as a decryption key for the next gate. Again, this process repeats for each gate in the circuit. Finally, once the IAEA has the computed label on the circuit's output wire, it can share that label back to the facility so that the computation result becomes public.

So now that we've covered the fundamental cryptography, let's get back to real implementations.

Existing Frameworks

(and more...)

I told you before that we wanted to be able to identify anomalies in radiation spectra, effectively demonstrating that MPC worked on safeguards data. At the same time, knowing our audience of safeguards inspectors and data analysts, we recognized that if this was to ever be more than just a fun idea, we needed to be able to do it a way that was clear and convincing—especially to folks at the IAEA who might not be at the forefront of cryptographic research. We surveyed available MPC software frameworks, and found a pretty wide range of options available, which is great!

These were codes that satisfied our obvious criteria of being able to perform calculations correctly while keeping data private, but all of them presented other challenges...

Some were too limited in their ability to handle a challenge of this scope. Some are no longer maintained. Others are commercial, and so while potentially great for a contract down the line, they're not so great for a highly tailored demo with full transparency. But most often, the codes were state-of-the-art research codes designed to showcase the latest development in the field, and were too sophisticated for building a demo aimed at a budget constrained inspectorate with a relatively limited base of expertise.

750 hours

31 ¼ days

CypherCircuit

Circuits can be built and evaluated in just a few lines of code.

Facility


												# Build a circuit
												circuit = CircuitBoard()
												A, B = Wire(circuit), Wire(circuit)
												OneBitComparator(A, B)

												# Run the protocol as the circuit generator
												with Generator(circuit, evaluator_address) as facility:
													vector = '1-'
													facility.evaluate_protocol(vector)

Inspector


												# Run the protocol as the circuit evaluator
												with Evaluator(circuit, generator_address) as inspector:
													vector = '-0'
													inspector.evaluate_protocol(vector)

Circuits can be explored and analyzed on the fly.


												>>> wire0.value
												>>> wire1.value
												False

												>>> wire2.value
												True

												>>> and_gate = And(wire1, wire2)
												>>> and_gate.output_wire.value
												False

												>>> and_gate.truthtable
												W0001  W0002  |  W0003
												——————————————————————
												  0      0    |    0
												  0      1    |    0
												  1      0    |    0
												  1      1    |    1


												>>> and_gate.label()
												>>> and_gate.labeltable()
												 W0001    W0002   |   W0003
												————————————————————————————
												70850a…  b54f72…  |  e785bd…
												70850a…  d430d6…  |  e785bd…
												11faae…  b54f72…  |  e785bd…
												11faae…  d430d6…  |  86fa19…

												>>> and_gate.garble()
												>>> and_gate.tokentable
												encrypted
												—————————
												 44e869…
												 98ddc3…
												 bf0f97…
												 590a8a…

Now I confess, I'm not a cryptographer, just a nuclear engineer with a passion for reproducible computing.

Our prototype evaluates circuits successfully and securely, and while it is admittedly slow, it is highly accessible.

Here is a quick snapshot showing how the whole process we just walked through can be encapsulated in just a few lines of Python.

The package is designed to be used by anyone who understands the fundamentals of garbled circuits, installed without any headaches, and inspected thoroughly at every step of the circuit evaluation process.

But finally, after development, the time came to begin testing garbled circuits on real-world time series anomaly detection datasets.

Now, the radiation spectra that we were looking at before tend to be large sets of data. At each point in time one may monitor hundreds or thousands of "channels", each giving a count of how many radioactive particles are measured in some energy range.

ECG

Heartbeat Anomaly Detected

Cardiogram data sourced from the Beth Israel Deaconness Congestive Heart Failure database

We started smaller, looking to find a univariate time series that we could analyze first as a test. We settled on something outside the safeguards realm, but which I hope is easily relatable to you all in the audience. An electrocardiogram signal; a heartbeat.

Here I've shown a sample of heartbeat data sourced from the Beth Israel Deaconness Congestive Heart Failure database. It's pretty obvious just by looking at it to see where the anomaly is. But for privacy preserving computation, we can't look at it. Instead, we coded up a garbled circuit to analyze the cardiogram. One party inputs their cardiogram data, the other party inputs parameters of the anomaly detection algorithm.

The result? The garbled circuit identified the exact location of the anomaly, but never revealed the actual cardiogram heartbeat.

Modeling Urban Scenarios and Experiments

MUSE

Modeling Urban Scenarios and Experiments

February 2019

Oak Ridge National Laboratory

Lab
Facility

²³³Pa

Research
Reactor

February 2019

Oak Ridge National Laboratory

Lab
Facility

²³³Pa

Research
Reactor

MUSE – Oblivious Safeguards Anomaly Detection

keV: kiloelectronvolts

I'll show you.

Here's an animation of just a few minutes of data collection on one morning in late February. The animation is sped up, so you won't have to stay still quite that long.

On the left is the view that a facility might have. The plot gives the radiation spectra that was actually measured—in this case the MUSE data. You can hopefully see the jitter at the bottom of the plot—that's background radiation. It's everywhere, all the time, including around you right now. It's low enough that it has almost no impact on your life, but the detectors see it, and so our algorithms must filter it out.

Then, on the right, is the view an inspector might have, using a garbled circuit. At the top is a rough example of the "radiation signature" of the protactinium. You can see the large peak at around 300 kiloelectronvolts (keV) and a smaller peak at around 400 keV. That's what we've built the garbled circuit to look for. (The lower energy peak is less likely to show up reliably in the detector, so we're ignoring that one.) At the bottom is an indicator of whether the data input by the facility shows hints of protactinium. Green is good-to-go, And red is a anomaly. Here, detected at 9:19 am.

It's a success!

Still to come...

Enhanced efficiency
Malicious adversaries
Spoofed inputs

Now, as I mentioned before, our package is fairly slow, and so our goal is to speed this up to something approaching real-time. After that, ideally we move to implement the package as a "language" in-and-of-itself, akin to most of the existing frameworks available today where circuits can be built as computer code, not wire-by-wire, gate-by-gate, like I showed before.

There are also still some other obvious challenges that lay in front of us:

How will we deal with malicious adversaries? These are participants who might try to subvert the calculation by not following the rules of garbled circuits. Fortunately, this is a problem that has generally been solved in the literature, and so we'd just need to build it into our own methods.
Perhaps more importantly, can we prevent parties from spoofing their input data? Garbage in, garbage out as the saying goes, but adding techniques like commitment schemes to the procedure could ensure that when a party enters data, it becomes immutable, enabling the inspector to return and verify it's authenticity at some point in the future if its deemed necessary.

Despite these challenges, I believe that this technology is needed now more than ever. As international relationships are becoming increasingly strained, the ability to use trustless, privacy preserving systems may allow us to maintain relationships and international cooperation around nuclear safeguards. Hopefully they even present the opportunity to rebuild trust between nations that may not currently see eye-to-eye.

And so, for all you nuclear inspectors in the audience, let's consider where MPC might fit into the IAEA's future operations. For anyone who's left, I believe that MPC could have applications in almost every aspect of modern life, and so I challenge you to think about where and when you might desire privacy-preserving computation in your own daily routine. Then, I hope you'll push for MPC to go mainstream.

This research was advised by Dr. Rachel Slaybaugh (UC Berkeley) and Dr. David Farley (Sandia National Laboratories).

Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

We acknowledge the support of the NA-22 Office of Proliferation Detection (NA-221) and especially that of the NA-221/Safeguards Program manager, Dr. Chris Ramos, in funding this work.

Special thanks goes to Jared Johnson, Andrew Nicholson, Daniel Archer, Michael Willis, Irakli Garishvili, Andrew Rowe, Ian Stewart, and James Ghawaly developing, curating, and providing access to the MUSE dataset.

Approved for unlimited unclassified release (SAND2021-0391 C).

Get in touch with Mitch by reaching out to negus@berkeley.edu

Image Attributions

"WTC smoking on 9-11", Michael Foran, CC BY 2.0, via Wikimedia Commons
"Boston Marathon explosions", Aaron "tango" Tang from Cambridge, MA, USA, CC BY 2.0, via Wikimedia Commons
"IAEA Inspectors", Dean Calma, Attribution, via Wikimedia Commons
"IAEA Mass Spectrometry", Dean Calma/IAEA, Attribution-NonCommercial-NoDerivs 2.0 Generic (CC BY-NC-ND 2.0), via Flickr
"IAEA Headquarters", Rodolfo Quevenco/IAEA, Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0), via Flickr
"NPT Signatories", File:NPT Participation.svg: Allstar86, L.tak, Danlaycockderivative work: Danlaycock, CC BY-SA 3.0, via Wikimedia Commons
"Gamma spectrum of the shown Uranium...", Wusel007, CC BY-SA 3.0, via Wikimedia Commons
"Uranium Ore", Andrew Silver, USGS, Public domain, via Wikimedia Commons

No Data, No Problem

Giving nuclear inspectors better toolswithout revealing state secrets

Nuclear inspectors prevent material from being diverted to weapons purposes.

The Treaty on the Non-Proliferation of Nuclear Weapons

MPC

A Brief History of MPC

Radiation Spectra

2 Parties

2 Parties

2 Inputs

Oblivious Transfer

Facility

Inspector

Existing Frameworks

CypherCircuit

CypherCircuit

Facility

Inspector

ECG

Modeling Urban Scenarios and Experiments

MUSE

Modeling Urban Scenarios and Experiments

February 2019

Oak Ridge National Laboratory

February 2019

Oak Ridge National Laboratory

MUSE – Oblivious Safeguards Anomaly Detection

Still to come...

Image Attributions

Giving nuclear inspectors better tools
without revealing state secrets