00:00:00.042-->00:00:06.375
>>Okay thank you for come today.
Um, our talk is on, uh, hardware
tol-tolerant uh hardware. Um,

00:00:06.375-->00:00:11.375
that’s tolerant of Trojans and
uh we’re gonna talk a little bit
more on that and supply chain

00:00:13.667-->00:00:18.667
security in practice. Um, so the
highlights of this talk is uh we
start first discussing the

00:00:20.833-->00:00:25.417
private life of keys um there
are some weak- also some weak
links on the supply chain so

00:00:25.417-->00:00:31.333
we’re gonna bring this up. And
then we have the, some lessons
learned from airplanes. And then

00:00:31.333-->00:00:36.250
we’ll see how can transfer this
crypto hardware, uh then Dan is
going to do a demo and describe

00:00:36.250-->00:00:40.208
the architecture we came up
with. And then I’ll describe the
protocols some mods and and some

00:00:40.208-->00:00:45.750
magic stuff we do. And finally
uh we’ll close the presentation
with, uh, some talk about

00:00:45.750-->00:00:51.542
politics and how we can explode
this to crypto hardware. To
begin with, um, there’s this

00:00:51.542-->00:00:58.000
thing that we have priv-private
uh key and public keeper. Um,
how do we generate that? So

00:00:58.000-->00:01:04.250
first someone somewhere in the
developer design house, uh,
designs an integrated circuit

00:01:04.250-->00:01:10.000
which is then fabricated to a
foundry somewhere else probably.
Um And then this integrated

00:01:10.000-->00:01:15.625
circuit is delivered to the
hardware vendor to that actually
ordered it. Uh, the vendor then,

00:01:15.625-->00:01:21.667
um, loads it’s firm--firmware on
it and assembles the actual
device that’s gonna use it. The

00:01:21.667-->00:01:26.792
integrated circuit. And um then
the device is sent with the
customer that bought it. The

00:01:26.792-->00:01:32.000
customer use it-uses the device
to generate and store, uh, to
generate and store the key.

00:01:32.000-->00:01:37.000
Only, um, the problem with this,
uh, the life cy-cycle of keys is
that, um, in practice if any of

00:01:41.042-->00:01:46.292
these, uh, steps, gets
compromised or an attack happens
in them, the final key’s weak or

00:01:46.292-->00:01:51.292
compromised completely. Um, and
this is, um, for this reason we
have hardware security modules

00:01:54.333-->00:02:00.250
so, um, hardware security
modules were built with a
purpose of, um, um, protecting

00:02:00.250-->00:02:05.500
keys and tech performing audio
prints for the device. So it
provides very neat features.

00:02:05.500-->00:02:09.375
Some of them are, uh,
cryptographic key generation,
storage and management. A lot of

00:02:09.375-->00:02:13.917
these things happen on the
device. And then they have a-a
whole set of features that have

00:02:13.917-->00:02:19.708
to do with, uh, tamper-proof,
tamper-resistance, and, uh,
tamper-response. So what they do

00:02:19.708-->00:02:26.583
is basically if you physically
manipulate, uh, a HSM, um, then
this is gonna be, uh, visible to

00:02:26.583-->00:02:31.708
the owner of it. Uh, also the,
uh, manipulating physically any
system to retrieve the secrets

00:02:31.708-->00:02:36.333
of uh, that sort of thing.
Inside that’s not trivial so
they provide tamper resistance.

00:02:36.333-->00:02:42.333
And then tamper response means
that the actual HSM, actually
the HSM can take action if, uh,

00:02:42.333-->00:02:48.542
detects its being manipulating
so it may raise the keys or lock
down completely. Um, so this

00:02:48.542-->00:02:53.250
makes it very hard for the
adversary to retrieve what’s in
there. Um, plus for companies

00:02:53.250-->00:02:57.708
that want to check all the
boxes. They HSMs are usually
certified with a very high

00:02:57.708-->00:03:02.208
level- really high level of
security. And then,
valida-validated for it. Um, the

00:03:02.208-->00:03:08.625
bottom line for HSMs is that the
all the impressions are being
carried out on the device so the

00:03:08.625-->00:03:14.375
secret keys and all the secrets
stored inside never have to
leave the device. And the- for

00:03:14.375-->00:03:18.250
this reason because they provide
really high security they’re
using a very um, in lots of

00:03:18.250-->00:03:23.750
publications where high service
is needed. So like public key
infrastructures, um SSL

00:03:23.750-->00:03:30.042
connections, accelerators, um
payment systems is very popular
and actually vendors are willing

00:03:30.042-->00:03:35.042
to pay the very high cost that
comes with them, um ten k that
we have here on the slides is

00:03:35.042-->00:03:39.875
the very very low um end of it,
usually it's much higher. And
then there are lots of other

00:03:39.875-->00:03:45.958
costs that usually um are hard
to quantify but they are- they
are quite uh high uh that have

00:03:45.958-->00:03:50.417
to do with integrating the
actual HSM once you buy it and
then uh operating it and

00:03:50.417-->00:03:55.417
supporting throughout the years.
Despite the the high cost HSMs
protect only the last few steps

00:03:57.917-->00:04:02.917
of the um private key life cycle
so the-the top four um are also
are still exposed. And um,

00:04:07.167-->00:04:13.250
there’ve been cases where we’ve
seen, um, things going wrong in
the first four steps meaning

00:04:13.250-->00:04:18.292
that the actual security of the
device is being completely um
broken and nonexistent. For this

00:04:18.292-->00:04:24.125
reason and because people know
that they try to come up with
solutions and there lot-there’s

00:04:24.125-->00:04:30.042
lots of academic literature on
it actually. Um the most popular
of those are trust foundries so

00:04:30.042-->00:04:35.458
this means that you sent your uh
circuit design to a foundry or
factory uh that you completely

00:04:35.458-->00:04:42.042
trust not to insert any Trojans
in it. Um this, the problem with
it is that it’s very expensive

00:04:42.042-->00:04:48.417
and of course mistakes can still
happen during publication. The
other approach is more academic

00:04:48.417-->00:04:54.917
it’s split manufacturing. There
should be few um foundries that
support that. It’s still

00:04:54.917-->00:05:00.250
expensive and again errors may
happen. And the final one is the
post fabrication inspection so

00:05:00.250-->00:05:04.750
what happens is that you order
your credit, check it um they
manufacture it, you get it back

00:05:04.750-->00:05:09.583
and then you run some tests on
it. The problem with this is
that it’s expensive. You need

00:05:09.583-->00:05:13.625
expensive tools to do that. You
need to constantly retool
because the connects uh uh

00:05:13.625-->00:05:18.625
advanced uh and then it's a huge
pain because if you’re there are
like a thousand a few thousand

00:05:18.625-->00:05:24.250
chips you cannot test all of
them. So it doesn’t scale very
well. Um, in general overall um

00:05:24.250-->00:05:29.250
it's an arms, an arms race
because because uh hardware
Trojans connects are constantly

00:05:31.708-->00:05:37.583
advancing and uh adversaries are
always and will be always a step
forward. So you can never be a

00:05:37.583-->00:05:41.167
hundred percent certain that
nothing went wrong throughout
the process. Even your trust

00:05:41.167-->00:05:46.167
foundry may sometime uh betray
you and cooperate with uh
someone. So another note there

00:05:48.625-->00:05:53.750
is another community. A fault
tolerant community so not
security but had a similar

00:05:53.750-->00:05:59.833
problem and they solved it uh
using um tandem systems.So what
they do is basically uh instead

00:05:59.833-->00:06:04.708
of using one integrated circuit
they use three coming from
completely different supply

00:06:04.708-->00:06:10.958
chains and uh the they build
therefore they build either dual
redundancy systems which allows

00:06:10.958-->00:06:17.417
them to detect if one of those
two circuits is misbehaving uh
and detect errors in the final

00:06:17.417-->00:06:23.500
results or a triple redundancy
systems um where all the
computations are being

00:06:23.500-->00:06:28.667
replicated between the three
different um processors and they
in the end they perform a

00:06:28.667-->00:06:34.625
majority vote about what the uh
correct output is. And this is
actually used in the autopilots

00:06:34.625-->00:06:41.375
uh on uh commercial aircrafts
and uh I think also they use it
in space. The problem with uh

00:06:41.375-->00:06:45.917
fault tolerant systems is that
uh they are they are built for
safety and they do their job

00:06:45.917-->00:06:50.917
very well for that. But um for
complicated they replicated
computations but for security

00:06:50.917-->00:06:56.667
tuh they don't transfer well at
all. Actually they’re bought for
security because what you end up

00:06:56.667-->00:07:03.000
having is a system that has
three processors starting your
secret key. Um Meaning that uh

00:07:03.000-->00:07:09.583
if one of your uh processors is
uh compromised and then um uh
you're prone to attacks so

00:07:09.583-->00:07:15.875
instead of actually improving
your security you increase your
attack surface. For this reason

00:07:15.875-->00:07:20.500
we came up with uh the solution
where we represent today. Which
provides protection and the

00:07:20.500-->00:07:25.500
option for uh first steps of
these uh life cycle of keys. I
am Vasilios uh I did this work

00:07:28.792-->00:07:35.417
with George Danezis, Dan Cvrcek
and Petr Svenda. And here are
the ingredients of our solution.

00:07:35.417-->00:07:39.500
So we have two ingredients. One
of them is a hardware components
and the second is a

00:07:39.500-->00:07:43.583
cryptographic protocols. And we
need specific things from uh
these kind of uh from these

00:07:43.583-->00:07:49.500
components. So for ICs we need
the independent fabrications so
they must be fabricated in

00:07:49.500-->00:07:53.375
different facilities and the
supply chain leading to them
should, their supply chains

00:07:53.375-->00:07:59.417
should be non overlapping. Uh
they must be programmable um
hopefully affordable and if they

00:07:59.417-->00:08:04.417
are commercial off the shelf but
that’s actually even better. Um
for cryptographic protocols we

00:08:06.833-->00:08:12.542
want protocols that uh all the
parties that participate in them
are not trusted. That the

00:08:12.542-->00:08:17.792
secrets are completely
distributed and allow them to
perform operations um in a

00:08:17.792-->00:08:22.625
distributed matter instead of a
centralized one. And they’re
provably secure meaning there

00:08:22.625-->00:08:27.625
are maths that support their uh
security. So, our um hardware
components are smart cards.

00:08:30.250-->00:08:34.583
Because you have many dependent
manufacturers with who have
their own facilities to produce

00:08:34.583-->00:08:40.875
smart cards. And the supply
chains are indeed disjoint. Both
in terms of locations, design,

00:08:40.875-->00:08:46.458
and the foundries. They’re
programmable and they certify at
a very high level, high

00:08:46.458-->00:08:51.875
standard. And they’re commercial
off the shelf and pretty cheap
actually. And then for the

00:08:51.875-->00:08:57.417
protocols we have um multiparty
computation protocols which
allows you to do um distributed

00:08:57.417-->00:09:02.292
operations meaning that the key
is not on a single point at
anytime and you can generate

00:09:02.292-->00:09:08.542
random numbers in a restricted
matter. Um key pair do key pair
generation which is what we are

00:09:08.542-->00:09:13.500
interested in. Decryption is
high which is what we are also
interested in. Um the two nice

00:09:13.500-->00:09:19.667
products of those protocols is
that they allow you to be
securing cases where all but one

00:09:19.667-->00:09:24.333
of your components are malicious
and they cooperate with each
other. Or they allow you to be

00:09:24.333-->00:09:29.333
secure in cases where all your
components are malicious but
they don’t cooperate. So now Dan

00:09:31.917-->00:09:36.250
is gonna take over and he’s
going to introduce our prototype
and then move on with our actual

00:09:36.250-->00:09:41.250
demos. >>Alright thank you.
[applause] So with help of Jack
I’ll try to show you some live

00:09:46.792-->00:09:51.792
demo. Uh and what was so far
pretty much slide here I’ll try
to turn it into a product. And

00:09:54.750-->00:09:59.750
reproduct look about this. And
we got one prototype or one one
one piece here on the table and

00:10:02.167-->00:10:07.167
I will try to use it for to show
how the multi party computation
security of the design actually

00:10:09.917-->00:10:14.917
works. Uh so what’s inside the
box, uh we got many smart cards.
This this particular one has got

00:10:16.917-->00:10:23.792
one hundred twenty of them. Uh
and the we were able to use them
in groups of three to basically

00:10:23.792-->00:10:29.417
shows how scalable it is in
properties of protocol that we
designed. Uh Probably you say

00:10:29.417-->00:10:35.500
well smart cards is pretty slow
cheap device. Well we can talk
to them directly at about one

00:10:35.500-->00:10:41.542
megabit per second so in the box
basically we are talking for
than one hundred twenty megabits

00:10:41.542-->00:10:47.917
per second to smart cards. So I
don’t see how one hundred twenty
megabits is really that slow

00:10:47.917-->00:10:53.958
even today. Um there is FPGA to
connect all the pins together
and those ports are connected

00:10:53.958-->00:10:59.208
with standard ethernet to
through some internal hardware
in mine internal port. And just

00:10:59.208-->00:11:06.042
put it to a rack and use it in
scale. So here’s just the main
the main parts. So hundred

00:11:06.042-->00:11:11.375
twenty smart cards. Use
JavaCards because they are easy
to program. And we need some

00:11:11.375-->00:11:16.625
department for JavaCards so we
can use really very easily
JavaCards from different

00:11:16.625-->00:11:21.917
manufacturers. Something
presented earlier at Def- at
Black Hat. Uh, so each smart

00:11:21.917-->00:11:27.792
card gives you physical
security. Very good. Several
layers of physical security that

00:11:27.792-->00:11:32.792
makes it very very difficult to
get inside and extract any keys.
Command of those things uh all

00:11:33.875-->00:11:43.375
the memory and addressing in the
smart card is encrypted so just,
uh, deleting one AS key

00:11:43.375-->00:11:48.167
basically destroys all the
information uh and makes it
basically random data. Uh we’ve

00:11:48.167-->00:11:54.375
FPGA. That basically connects
JavaCards. All we use here are
protocol to [indiscernible]

00:11:54.375-->00:12:00.792
JavaCards into basically TCP
packets. And then you got
internal network hop and main

00:12:00.792-->00:12:06.750
Linux server that runs for us
basically on untrusted restful
server that allows connectivity

00:12:06.750-->00:12:15.292
uh to outside. So we got three
demonstrations. Uh, so I will
try the first one which is about

00:12:15.292-->00:12:21.250
showing geographically disputed
uh control of integrated
circuits. Uh what I will use is

00:12:21.250-->00:12:26.542
my laptop. I will use a black
box that is next to me. It’s got
one hundred twenty smart cards

00:12:26.542-->00:12:31.125
inside and runs the RESTful
server. I will talk to but I
will also try to connect to

00:12:31.125-->00:12:35.500
instead of one hundred twenty
smart cards that are just now
sitting in our Cambridge office

00:12:35.500-->00:12:57.542
in UK. So if everything goes
well. So we’ll load final
reports. So as almost all grey

00:12:57.542-->00:13:13.125
or red because we don’t have any
data here yet. Let’s start uh
the root connector connect

00:13:13.125-->00:13:21.792
RESTful server to the
ritualization report and now
let’s reach the pond. Now you

00:13:21.792-->00:13:27.125
can see that what I actually did
is I started the server with
integration that shows two IP

00:13:27.125-->00:13:33.458
address feeds that hide two sets
of smart cards. One is local
that goes in the server and

00:13:33.458-->00:13:38.708
there’s one that goes all the
way to uh to the UK. Uh, through
some commercial ISP uh this is

00:13:38.708-->00:13:45.667
an enumeration of the smart
cards. What it’s opening now is
basically the uh the RESTful

00:13:45.667-->00:14:05.458
server uh should be starting any
second. So what is happening
when we look at the server try

00:14:05.458-->00:14:33.667
to connect to all those smart
cards. It takes longer than
elsewhere. Still not-not

00:14:33.667-->00:14:52.375
started. [inaudible off mic]
Yeah here we go. So it took a
while uh but again we go there

00:14:52.375-->00:14:59.292
so now you could basically
available two hundred forty
processors that are each able to

00:14:59.292-->00:15:07.792
basically run uh multiparty
computation for us. So the nice
thing about the system as we

00:15:07.792-->00:15:13.333
designed it is that not only you
can use uh micro control
different geographic locations,

00:15:13.333-->00:15:18.208
but each multi party
computation, each group can
contain processors that are in

00:15:18.208-->00:15:24.042
different physical locations so
you can run that com processor
here in the room, another

00:15:24.042-->00:15:30.875
processing Cambridge that one
actually can be JavaCard
simulator. And as such on any

00:15:30.875-->00:15:36.458
platform with its own Intel and
SPARC so it gives you really
wide range of options to provide

00:15:36.458-->00:15:42.083
different supply chains and
complete independent
manufacturing processes so

00:15:42.083-->00:15:46.875
basically the only come on
point. When you start using
crypto-generated keys is a lot

00:15:46.875-->00:16:01.375
of key stop generator key. So, I
will quickly switch pond off so
it should be much much bigger

00:16:01.375-->00:16:13.042
now I go basically just local.
Local. I press for abort in
here. I change different report.

00:16:13.042-->00:16:26.958
Also put. So something there
already and what I’m going to do
now is um use my laptop as a

00:16:26.958-->00:16:33.125
low-low generator. I’m start
running the request against the
smartcards. So what I’m going to

00:16:33.125-->00:16:39.333
do is basically create circuit
independent groups of smartcards
with search different keys that

00:16:39.333-->00:16:46.833
can basically uh surf different
customers at the same time. So
instances been allocated and now

00:16:46.833-->00:16:51.625
basically this is uh
transactions per second. We run
for about a minute. If I just

00:16:51.625-->00:16:57.750
sort of bit of context imagine
that use bit chain or bock chain
uh technologic and you’ve got

00:16:57.750-->00:17:04.083
five ten parties in a private
scheme and basically each
transaction needs ten signatures

00:17:04.083-->00:17:09.167
by ten parties. What you can do
with this, this computation is
basically involve all those ten

00:17:09.167-->00:17:14.583
parties but it will result in
just one signature. But you know
the signature needed cooperation

00:17:14.583-->00:17:18.042
of all of them. So it’s much
easy to verify signatures cause
instead of going to ten

00:17:18.042-->00:17:23.625
different uh lectures, you’ve
got uh just one, uh one master
copy that you could replicate

00:17:23.625-->00:17:30.167
and verify independently. Right,
so this basically just
demonstration of the throughput

00:17:30.167-->00:17:34.375
of the whole system. And the
scalability and the
possibilities will show a bit

00:17:34.375-->00:17:43.708
more uh uh veros about our
previous tests. Uh that will it.
So the last demo is actual

00:17:43.708-->00:17:51.042
showing how someone can try to
attack the whole system. But he
needs to put a lot of effort

00:17:51.042-->00:17:57.208
into it to actually succeed. So
again just one server that is
running here. Uh A laptop

00:17:57.208-->00:18:02.375
connecting it to it and I will
have a small group or chart of
smartcards that have got

00:18:02.375-->00:18:08.292
backdoor inside. And yet I will
try to use a RESTful server, the
thing that is facing the

00:18:08.292-->00:18:14.167
internet. I will try to set the
key that I will use to some kind
of default value so it can

00:18:14.167-->00:18:27.250
easily decrypt data.So I gotta
change the dashboard to
something new. So I’m using

00:18:27.250-->00:18:35.750
dashboard uh and also uh no
threats to basically connect uh
all the flows and show you

00:18:35.750-->00:18:43.625
something meaningful. Oh it’s
bigger than I thought. Um anyway
there are two main flows. One is

00:18:43.625-->00:18:49.250
to generate key. I don’t know
how well it is-it is visible. So
this is to generate the key and

00:18:49.250-->00:18:55.042
then I got three triggers that
will allow me to compromise card
one, two, or three. Uh how it

00:18:55.042-->00:19:04.750
happens is uh each time I’ll
need to create uh a RESTful
request that will allow open the

00:19:04.750-->00:19:10.500
backdoor that will part in the
chip and then basically I will
try to generate key and see if

00:19:10.500-->00:19:17.500
the key uh is all that I can use
and I assume that I expect so I
cannot take the whole system. Of

00:19:17.500-->00:19:27.250
the first one will be, so let’s
go in slide on the dashboard. So
we’ve got sort of an initial

00:19:27.250-->00:19:31.958
state. So now there are three
cards used because we needed
some extra than before. All is

00:19:31.958-->00:19:36.833
green but you see that there is
no key and there is no-no group
that we can use. So let’s run

00:19:36.833-->00:19:44.417
create. As a result I got now
three addresses so I can
certificate address for

00:19:44.417-->00:19:51.083
integrated-integrate,
uh-integrated uh-uh circuits
that I will use. That requires a

00:19:51.083-->00:19:59.875
little bit of clicking. What I’m
going to do is basically do all
that CR tech would do figure out

00:19:59.875-->00:20:11.833
which of the uh processors uh
that he wants to compromise. So
this is the first one done. So

00:20:11.833-->00:20:41.750
it’s second one. And the last
one. And I’m almost there. Bear
with me. So last bit I need is

00:20:41.750-->00:20:51.833
to say to tell the key generate
algorithm which uh which group
of cards it should be using. So

00:20:51.833-->00:21:01.792
confirm deploy. Make sure that
we’ve got all cards that there
are. Uh that they are secure.

00:21:01.792-->00:21:06.792
Now we try to generate new key.
We got some delays here so you
cannot show the switch quickly.

00:21:06.792-->00:21:12.083
So you see that there is now
public key and it’s different
than the fixed key that we know

00:21:12.083-->00:21:19.292
the attacker set uh and wants to
wants to wants to run the chips
to share. So the first one that

00:21:19.292-->00:21:28.458
is to compromise card one. So in
the inspector. So the card is
compromised. Takes a few

00:21:28.458-->00:21:34.875
seconds. And now basically the
new uh new cards new
configuration will generate new

00:21:34.875-->00:21:37.792
key that is changed. But you can
see that it’s still green. It’s
still secure. Uh imagine that

00:21:37.792-->00:21:46.500
basically to get this it is
either easier to change the
firmware that can be uh verified

00:21:46.500-->00:21:51.375
by us or controlled by different
parties or have to compromise
manufacturing of the chips

00:21:51.375-->00:21:58.292
anywhere. Uh doing their
manufacturing process so if I do
part cards two. So compromised.

00:21:58.292-->00:22:07.417
Now imagine that all those keys
are elected curve to two five
six bit keys. And if at least

00:22:07.417-->00:22:11.958
one part is secure we’ve still
got two hundred and fifty six
bits of random data, random key.

00:22:11.958-->00:22:20.375
So second attempt still didn’t
succeed. I’ll try finally the
third card. Now basically expect

00:22:20.375-->00:22:24.958
assume the CR tech are
compromised three different
places, three different chips

00:22:24.958-->00:22:29.292
that can be under control. Three
different parties. Manufactured
or running on different hardware

00:22:29.292-->00:22:34.042
from-from chip manufacturers.
Now only that many does all
three of them you can see that

00:22:34.042-->00:22:38.292
the keys as expected and now you
can basically decrypt all the
data that we’ve tried to encrypt

00:22:38.292-->00:22:45.292
with the key. All for the
signature. On the other hand, if
I expect that this can happen

00:22:45.292-->00:22:51.500
and regularly try to refresh the
uh the chips that I use. If I
refresh just one of them and

00:22:51.500-->00:23:03.042
turn it into secure state then I
gain- get key that is absolutely
secure from uh cryptographing

00:23:03.042-->00:23:10.000
point of view. Alright, so that
was bit of long demo and uh
Vasilios will tell you what it-

00:23:10.000-->00:23:22.542
what is actually doing inside.
>> [applause] Kay thank you
again. So yes we build that

00:23:22.542-->00:23:30.542
system um however in um so in
for our demos we used um a group
of cards that uh had three cards

00:23:30.542-->00:23:35.958
inside to do all the
computations. However someone
for whatever reason he may wants

00:23:35.958-->00:23:43.042
to use less or more cards so we
tried to obtain other protocols
rescalable. So for assigning a

00:23:43.042-->00:23:48.750
decryption we do super well.
This means that uh you can use
as many cards as you want and

00:23:48.750-->00:23:54.000
the processing time doesn’t
increase. In the processing time
cooperation. Uh for keys in

00:23:54.000-->00:23:59.792
relation because we need very
high assurance. Uh this is not
the case but as you can see the

00:23:59.792-->00:24:04.375
increase is linearly so it’s
it’s nicely it’s not like you
get a devastating delay. Uh for

00:24:04.375-->00:24:11.000
scalability uh on our hardware
here we used a hundred and
twenty or two hundred and forty

00:24:11.000-->00:24:16.208
if you use hardware remotely.
You can have as many um
processors as you want. As you

00:24:16.208-->00:24:20.792
can see both operations
decryptions in signing signing
uh the throughput increases um

00:24:20.792-->00:24:27.000
linearly so the more you add the
faster you become so depending
on your need you can uh you can

00:24:27.000-->00:24:33.208
needs you can uh decide how many
processors you can you want to
use. So a little bit more about

00:24:33.208-->00:24:39.250
the magic that’s going on behind
the scenes. Uh I keep I kept it
uh extremely light in terms of

00:24:39.250-->00:24:47.125
mathematics. So there is nothing
there. Um so there are three
plus one key points that uh we

00:24:47.125-->00:24:52.375
wanted for for it so far in the
algorithm you use. So the first
one is that there must be no

00:24:52.375-->00:24:59.458
single processor handling
sensitive stuff such as secret
keys or anything else at any

00:24:59.458-->00:25:05.000
time. Uh the second one is that
uh if one of the processors is
misbehaving and is trying to

00:25:05.000-->00:25:09.750
actively attack other processors
or trick them into doing stuff
uh honest ones, honest

00:25:09.750-->00:25:14.792
processors can detect that. The
third one is that if one of the
honest processors is being

00:25:14.792-->00:25:19.125
excluded from the protocol
execution uh the user can
actually tell that this happen.

00:25:19.125-->00:25:25.667
And finally if we could uh-uh
come up with a protocol or an
algorithm that’s uh is doing

00:25:25.667-->00:25:34.458
well in terms of performance
which we did. So a little bit of
a side note, um secret setting

00:25:34.458-->00:25:41.708
is a very neat concept. So
imagine you have three people
and they want to share uh a

00:25:41.708-->00:25:45.292
treasure map. Uh the simple
solution would be uh so that
they can retrieve the treasure

00:25:45.292-->00:25:50.500
only if all of them uh get
together again otherwise no one
can actually retrieve the

00:25:50.500-->00:25:54.167
treasure map. So the nice
solution would actually be to
actually uh cut the uh the

00:25:54.167-->00:25:59.625
treasure map in three pieces and
then uh each one of them gets
one of the pieces. However there

00:25:59.625-->00:26:04.750
is a problem with this because
each people is leaking uh part
of the information of where the

00:26:04.750-->00:26:09.167
treasure is and someone may be
able to successfully use this
information to retrieve the sec-

00:26:09.167-->00:26:13.625
the treasure by himself. So we
use there are some schemes
called secret setting schemes

00:26:13.625-->00:26:20.417
that they allow you to split the
secret into shares. And then you
they allow you to recombine the

00:26:20.417-->00:26:25.333
shares to retrieve the original
secret to reconstruct it. Um but
they have this very neat

00:26:25.333-->00:26:33.000
property that allows- that is-
that each share doesn’t leak any
information about the-the actual

00:26:33.000-->00:26:38.583
secret. So as long as not all
shares um are present you learn
nothing about the actual secret

00:26:38.583-->00:26:42.417
that they are hiding. And then
there are two parameters that
they usually can actually chose

00:26:42.417-->00:26:47.500
to tweek. One is how many shares
you split the secret into. And
the second one is how many of

00:26:47.500-->00:26:51.958
those shares you need to
reconstruct the original secret.
So you may actually cut the

00:26:51.958-->00:26:57.167
treasure map into hundred shares
and then you need only three of
them to reconstruct the original

00:26:57.167-->00:27:05.000
uh map. But in this case for our
hardware we use um three out of
three um scheme. So this means

00:27:05.000-->00:27:10.875
that we split our secrets into
three and then you need three uh
processors to uh come together

00:27:10.875-->00:27:16.625
to reconstruct them. Okay so
here are the operations. Classic
key generation. You go to the

00:27:16.625-->00:27:26.000
HSM. You-you inquire a new
private key for yourself. If the
HSM um responds he generates a

00:27:26.000-->00:27:30.083
key internally, stores a private
key inside, pretends to use a
public key. The problem is that

00:27:30.083-->00:27:35.833
if the HSM has a malicious
processor this means that uh the
processor gains full access to

00:27:35.833-->00:27:40.667
the private key and then the
public key that you are getting
back you have no idea if this is

00:27:40.667-->00:27:45.917
uh some sort of a weak public
key or there’s any other problem
with that. Instead what we’ll do

00:27:45.917-->00:27:51.167
is something different. So we
have three processors as you can
see the bottom of this slide. So

00:27:51.167-->00:27:58.292
on the step one uh you inquire
them to generate the public k-uh
public private keeper. So they

00:27:58.292-->00:28:02.875
generate the public keys and
then through a process they
combine them to form uh the

00:28:02.875-->00:28:06.667
common public key that you can
see on step four. So what’s
interesting about the common

00:28:06.667-->00:28:12.917
public key is that despite the
fact that all the keys except
one may be compromised as long

00:28:12.917-->00:28:18.042
as the-as long as there’s one
key that’s strong uh the final
key is uh maintained and

00:28:18.042-->00:28:25.042
secured. So going back to the
key points that we evaluate
algorithms with. Um we have all

00:28:25.042-->00:28:31.417
of them except the one that uh
accounts for performance and
this is because on the step, on

00:28:31.417-->00:28:35.000
step three there is no
interaction between the
processors so this means that

00:28:35.000-->00:28:39.375
there is some slowness there.
We’ve seen it previously on
the-on the graph where we saw

00:28:39.375-->00:28:45.375
how it scales. So then we have
decryption. Pretty similar
process. You go to the HSM. You

00:28:45.375-->00:28:51.125
say I want to decrypt this
email. HSM knows you’re a key so
it decrypts the email for you it

00:28:51.125-->00:28:55.917
tends to do in plaintext. Again
this is problem. The HSM needs
to have in a single place your

00:28:55.917-->00:29:01.792
full key. Uh instead we do
something else. We do
distributed decryption so in

00:29:01.792-->00:29:08.833
step one inquire uh from the HSM
to decrypt your ciphertext. Uh
what happens in the second step

00:29:08.833-->00:29:13.292
the different processors
generate what we call decryption
shares. So the decryption shares

00:29:13.292-->00:29:18.875
hold no information about the
plaintext. They are just shares
that then they send to-to Bob

00:29:18.875-->00:29:23.583
and Bob can then combine them by
himself to retrieve the
plaintext. So the reason I

00:29:23.583-->00:29:28.833
didn’t benefit from that because
the HSM never sees the actual
plaintext. All the decryption

00:29:28.833-->00:29:35.583
process happens actually by the
user himself. Again we have all
the key points checked except

00:29:35.583-->00:29:40.500
there must be having a processor
one. Because there is no
interaction between the um um

00:29:40.500-->00:29:46.542
processors in this protocol it
makes no sense. I mean if you
misbehave then the cipher the

00:29:46.542-->00:29:51.292
plaintext in the end will make
no sense. And it seems silly the
Trojan, the hardware of the

00:29:51.292-->00:29:55.917
Trojan hardware will reveal its
existence and then the user will
know that something is going on

00:29:55.917-->00:30:02.250
with his hardware. Um then we
have classic signing. Same
process. You supply plaintext

00:30:02.250-->00:30:08.167
and you say I want to sign the
plaintext um the IC again needs
full access to your private and

00:30:08.167-->00:30:13.042
then it returns you the
signature for uh for the
document you provided. Instead

00:30:13.042-->00:30:19.542
uh what we do is a bit
different. So there is a first
step. Um or step zero. Which is

00:30:19.542-->00:30:24.833
casing. So when you set up the
device you do some casing uh you
do this once for thousands of

00:30:24.833-->00:30:31.333
signatures. So you takes uh
about um few minutes and you do
this only once in the lifetime

00:30:31.333-->00:30:36.167
of the user. And then you move
on with the actual protocol. So
this is what you execute when

00:30:36.167-->00:30:40.542
you want to sign the document.
What you do is you send the
document to the HSM. They

00:30:40.542-->00:30:45.125
generate the signature uh
signature cells which are then
step three returned to the user

00:30:45.125-->00:30:51.250
and the user combines them to
retrieve the signature for the
document. Again we’re very

00:30:51.250-->00:30:58.375
efficient and at no point no one
learns uh the full um private
key of the user. However, so far

00:30:58.375-->00:31:04.375
we’ve discussed cases where you
have only uh three processors
interacting but our hardware

00:31:04.375-->00:31:09.875
uses many more so we have the
problem of how to make that
thing scale. And by scaling is

00:31:09.875-->00:31:16.000
basically adding more groups of
cards. So we ended up adding
forty groups of cards and then

00:31:16.000-->00:31:21.375
we had this key- this problem
with a key that yes, it’s card,
it’s group of cards can generate

00:31:21.375-->00:31:27.917
its own public private keeper.
The problem is that how we can
make that key be consistent with

00:31:27.917-->00:31:32.750
what’s the public key of Bob. So
can all those groups serve
request for- coming from Bob.

00:31:32.750-->00:31:38.625
And we had to come up with
another protocol if that’s that.
And this is key what we call key

00:31:38.625-->00:31:43.333
replication. So the naive way to
do that is you have let’s say
group A and group B. Group A has

00:31:43.333-->00:31:50.208
the key for Bob. Um and then uh
the the processors inside the
inside the group serve um the

00:31:50.208-->00:31:57.625
key serves with the processors
inside the Group B. On a one to
one basis. So this looks fine

00:31:57.625-->00:32:05.542
however what happens is that if
processors um A1, uh B2, and A3
which we can see here is

00:32:05.542-->00:32:10.833
malicious uh collude, they all
cooperate then they can retrieve
the actual secret. So this is

00:32:10.833-->00:32:15.708
really bad and we don’t want
this to happen. Uh so this is
not clearly- Clearly this is not

00:32:15.708-->00:32:20.542
the right way to do key
replication. What you do instead
is you split um each of the

00:32:20.542-->00:32:24.750
processors is splitting its
secret with three secrets and it
distributes them to um um a

00:32:24.750-->00:32:30.417
processors of Group B and then
this is how you do that uh in a
secure way. I’m not going into

00:32:30.417-->00:32:35.042
details. It’s pretty easy from a
mathematical perspective but we
don’t need to know that. Um

00:32:35.042-->00:32:40.417
what’s important is that both by
the end of the protocol both
groups A and B or whichever

00:32:40.417-->00:32:44.792
other groups you may have. We
have forty here. You can have
more. Uh can serve requests for

00:32:44.792-->00:32:50.708
the same public key that belongs
to Bob or whoever else. So now
the politics part of the of the

00:32:50.708-->00:32:59.667
uh talk. So initially. So so far
we’ve been saying that our
system provides security as long

00:32:59.667-->00:33:05.417
as there is at least one
processor in the system so you
can have many malicious ones but

00:33:05.417-->00:33:10.875
if there is one that is not
honest them you’re okay. However
this is not always the case or

00:33:10.875-->00:33:19.000
you cannot always be sure that
not all your components are a
backdoor. And to be to be um

00:33:19.000-->00:33:24.583
accurate. The adversaries that
are capable of introducing
hardware backdoors or Trojan

00:33:24.583-->00:33:30.292
horses are mainly governments
and because they have access to
deep access fabrication

00:33:30.292-->00:33:34.833
facilities. They use very
sophisticated techniques and
they-their Trojans and their

00:33:34.833-->00:33:40.000
techniques are very hard to
detect. And if you detect
usually you’re not sure if it's

00:33:40.000-->00:33:44.833
an error or a bug or a
manufacturing mistake or an
actually malicious act. However

00:33:44.833-->00:33:48.917
they are very secretive and all
those things are highly
classified and there is no

00:33:48.917-->00:33:53.500
chance that they will share the
details of their backdoors with
anyone. And we were thinking if

00:33:53.500-->00:33:59.417
we could exploit this and how.
So what what this entails is
that we are unlikely to collude

00:33:59.417-->00:34:08.625
or cooperate with any adversary.
Uh any other adversary. So if
you remember the um uh MPC

00:34:08.625-->00:34:11.792
protocols, multiparty
computation protocols provide
the security guarantees against

00:34:11.792-->00:34:15.542
another class of adversaries.
Adversaries that are all
malicious but they don’t

00:34:15.542-->00:34:22.542
cooperate. So in this case what
you can do is basically you can
buy processor from the US,

00:34:22.542-->00:34:27.792
another one from China and
another one from Russia but they
are fabricated there. And even

00:34:27.792-->00:34:32.125
if all of them are backdoored
you can be certain that they
will never cooperate and they

00:34:32.125-->00:34:36.333
will never reveal their
backdoors um one to the other.
So you’re safe and secure

00:34:36.333-->00:34:42.500
despite your hardware being
super compromised. So concluding
this talk um we yes we

00:34:42.500-->00:34:47.667
introduced the hardware that can
tolerate faulty and malicious
hardware. Uh we have decent

00:34:47.667-->00:34:52.583
performance that we have scaled
nicely so you can move this uh
you can serve as many requests

00:34:52.583-->00:34:57.958
as you need. Um we use uh off
the shelf components and this is
neat so we will show you later

00:34:57.958-->00:35:03.083
how this is very nice. And then
all the techniques that we’ve
discussed about trusted

00:35:03.083-->00:35:07.958
foundries, split manufacturing
and these kind of things um you
can of course uh source

00:35:07.958-->00:35:12.250
components that manufacture
securely to increase the
security of the system. We’re

00:35:12.250-->00:35:16.542
not competing with them. We can
actually use them. So what’s in
this thing is that yes we took

00:35:16.542-->00:35:21.500
it to an extreme. We built a
hardware but what you can do is
you can build your own um

00:35:21.500-->00:35:30.333
hardware tolerant device. Uh
it's pretty easy. Uh you can buy
USB hub and a few card readers

00:35:30.333-->00:35:36.292
depending on how many processors
you want to have. Uh you can
download our MPC applet. Buy

00:35:36.292-->00:35:39.292
some cards from different
countries. Do your research
there. Where they’re-where

00:35:39.292-->00:35:44.292
they’re coming from. Which
manufacturer has its own
fabrication facility and where

00:35:44.292-->00:35:51.708
this is located. Uh some of them
are actually um providing um
details or you have to pay a

00:35:51.708-->00:35:55.792
little bit more and then they
are produced in specific
fabrication facilities. So

00:35:55.792-->00:36:02.292
download your applet afterwards.
Review the code. Please do that.
And then uh yes we upload your

00:36:02.292-->00:36:08.333
applet in the cards and you have
your homemade HSM that can serve
not many requests but I don’t

00:36:08.333-->00:36:14.083
expect that the single user will
generate thousands of keys per
hour or something. And yeah.

00:36:14.083-->00:00:00.000
That was it. Thank you.
[applause]