can I talk today I'm Nikolas co-founder
and CTO Fletcher manufacturer of fine
other wallet I talked to there would be
about hardening smart contract with
hardware security an alternative title
could be who to build how to design a
platform to design hardware wallets on
different kind of secure hardware so
let's move forward so first why do you
why do we need to secure smart contracts
because smart contracts themselves are
extremely secure they are running into
the ETM VM blockchain I mean they are
secured by the consensus is securing
smart contracts but there are some nasty
things that could happen around the
edges if we look at the right thing
first mat contract can receive data from
external sources so here this external
source which is a picture from Delfy
who as you know is telling the future so
some people are calling that Oracle's I
decided to stop doing that after getting
some nasty gram from a database or
designing company but you get the idea
so if they are not twisted the smart
contract can act and perform some
mistakes on the other hand smart
contract are interacting with users who
are holding keys so generic user PC is
not extremely secure also as you can see
here so we need to secure key protection
here we have two items to secure and
we'll see how secure Hardware can help
with that so what kind of rights
can we get against the edges first we
can consider malware so we are very done
malware which will just steal private
keys or smart or malware that can
manipulate contracts I'll just feed bad
data to the user first then we have
physical attacks so we can have messy
physical attacks with which are
extremely powerful
if the algorithms are not properly
define an attacker can manage by looking
at the chip power consumption or
significative
things I mean changing with a chip can
retrieve private keys and can basically
steal that from the executing process
then physical attacks requiring access
to the chip itself which can be
leveraged on to change the behavior of
the chip by performing some glitching
attacks so here people might think that
glitching is going to open something
glitching is a bit more complex it will
change the way the process is running
basically so it's still extremely
powerful it's not easy to get right but
if you manage to glitch an item if you
managed to glitch a physical device the
right way you can also extract keys so
we have to consider all those frights
when dealing with secure hardware so
secure other way here we'll be bringing
an isolated environment to run the
different applications so we want secure
hardware that let us execute code
otherwise we can't do much we want
ideally secure hardware that is
physically resistant so secure Hardware
on which it's hard to extract data sick
we also want secure adware to give us
proof of execution on the platform so
when we run code and secure hardware we
must be able to be able to prove to an
external party that the platform is
healthy so that the platform has not
been broken into and that the code
running into the hardware has been
running into the right platform and
ideally if depending on the hardware
were running on we might want to we
might and we might want to strengthen
the cryptographic primitives to prevent
the passes to prevent the passive
attacks we have been talking about
before so when considering secure
Hardware people do not feel comfortable
about them because of because of binary
blobs and NGA's around secure hardware
but the general idea here is that today
we don't have any kind of open hardware
really available if you look closely
into the different architecture of the
hardware that you are using you never
fully own your hardware I mean at least
for all generic for all general-purpose
computers available today on your CPU
people can modify the microcode of your
CPU so the way it behaves if you are
using an stm32 which is a very common
when microcontroller use for hardware
wallets you don't really know how the
chip is behaving itself as well because
it has critical parts regarding to the
related to the security of the chip
itself so I am taking a pragmatic
approach about that I'm basically
considering that secure hardware is
considered to be best of class right to
protect data and if it's available and
if we think about the different threats
and if we try to limit them it seems
safe to use it and it's still open it's
still open enough and on a small point I
mean if you are using as if you are
using an Intel CPU today and you don't
want to use SGX I would just remind you
that you are already using the
management engine which can do a lot of
stuff behind your back so if you are
using the management in giant for the
bad parts we can also use it was a good
parts small very quick history of secure
hardware so the general idea here is
that secure hardware is getting more
open over time
so initially everything started with
smart cards in CIT smart cards were not
very powerful and when I'm not easy to
use you had to buy a specific video to
use them they were absolutely not
internet friendly in 2005 yubico
innovated with something more
sophisticated on which you could bring
user presence and you didn't need a
reader but still the chip was not very
powerful and not extremely open and we
have seen really a new set of secure
hardware coming with cryptocurrencies
because how do I wallets have been
designed to be able to work in an
extremely hostile environment in which
malware could change things on the user
computer and the hardware wallet had to
always operate properly otherwise people
would be losing money so I'm considering
Hardware wallets today as the next
evolution in smart cards because they
are really smart cards design foreigners
v environment and for the internet if we
look now at the history of generic
hardware so wide secure hard way is
getting mopin generic how do I is
getting more secure so they will meet at
some point that's the idea so
here initially if we if we want to
consider the generate CPUs I'm
introduced redzone which I'll set up
very low level primitives that you can
use to basically create operating system
that will easily tip applications and
create a normal world and a secure world
in which secure application can execute
without being interrupted by the
operating system Intel did the same
thing a bit later the platform is more
rich so while Trustin only provides
primitives in hgx is providing a set of
API that you can use to run any kind of
application without writing the
operating system yourself and then a bit
later
we have seen some evolutions of tours on
and mostly trails on coming with
hardware components optimizing
cryptographic primitives that we have
been talking about before and one
interesting chip if you want to look at
that it is all the latest chip are
including ble from Nordic which has
chosen which has frozen and a
cryptographic accelerator so those chips
are extremely close to secure element
today they don't have exactly the same
physical properties I mean regarding
resistance to hardware attacks and
proving the origin of the chip but
otherwise they are they are extremely
close so now what do we what is a
hardware wallet and what do we want to
build if we are splitting the different
parts of hardware wallet into an
architecture that I will call the
transaction interface so the transaction
interface will interact with secret data
which is basically as the seed of the
user if we are considering if we are
considering keys and if you are
considering deriving keys several
applications will be interacting with
those keys we don't want those
applications who interact directly with
the secrets otherwise they can steal the
secrets and we want to iterate the
applications from each other so
applications have to call the
transaction interface over a secured
pass which won't reveal the secret and
will only let them run a specific set of
of algorithms and further we can lock
the applications on several properties
for example we can lock them on an HDD
revision pass which means that here if
an application gets compromised the only
derivation
pass that can leak is a specific is past
specific to this application so here I'm
referring to your article deterministic
wallets which are getting used on now
significantly I mean for for atrium and
have been used in Bitcoin for a long
time but we can generalize a concept for
all set of keys how do we so what kind
of components do we need to build the
transaction in their place and secure
Hardware we need to build the iteration
first so because if we want to run
several applications together we need to
isolate them and we need to easily the
part into writing with secret data from
the applications then we need to
guarantee secure storage we need to
guarantee a secure implementation of the
cryptographic primitives so referring to
the passive attacks that we talked about
before and then we need to make we need
to provide a way for the external party
to verify that the platform is
legitimate and that an application
running on the platform is legitimate
and on top of that because we are
running in a world with smart contracts
we want to provide a way to authenticate
this on chain so typically we want to be
able to prove and change that we are
running the right application on the
right platform and now we will see how
to implement this different components
on different hardware and the
consequences so first why are we
designing a traditional interface rather
than running with a set of different
applications point is we are saving time
by in doing that rather than just
letting each provider design his own set
of applications as we've seen before
formal validation is quite complicated
so that's just an example if we want a
formal validation of a secure Hardware
it's better to do it on a common
interface than to duplicate the work on
a set of applications so here the right
parts has a critical path the
transaction interface is critical and
all the stubs are that the others that
the other application would call which
are still executing in the secure world
are protected by the transaction
interface so you don't need to spend too
much time in that case validating them
because the platform will already
guarantee that they can't leak thanks to
the iteration
properties if we want to implement that
on arm so that's regular the most
regular use case which will be
completely native we can use the native
properties of an see of arm CPUs to do
that so we can iterate the secrets using
memory management you need our memory
protection unit and when the course that
will be done over from the applications
to the transaction in their face can be
directly mapped to arm service calls
so here the architecture is extremely
close to the first one we are just
replacing all the calls and all the
iteration by native arm properties and
the applications themselves are native
we don't need to run a VM when you are
using arm because the hardware is
allowing is allowing us to perform the
iteration by itself now let's consider
hgx so hgx is kind of different
we don't have ax we don't work close to
the metal we can't really easy right
enclaves so enclaves being application
running an edge reacts from each other
we don't have either and attestation
schemes that can run on chain so the
attestation scheme and HTX is Intel
proprietary and we have to call a server
on Intel side to guarantee that the
platform is legitimate so in this case
our one simple use case that I suggest
is to use a virtual CPU so it might look
complex to use a virtual CPU but
thankfully there are things like Moxie
which happens was already very easy to
test and already almost problem I would
say so it has been used by different
projects in the Bitcoin space and why
would we use that rather than the AVM
the most I mean the easiest reason is
that if we want to guarantee Portability
and easy possibility between different
secure environment targeting C is a good
call because when we are when we will be
working on arm we will have native
iteration and here we simulate the
native iteration by running with virtual
CPUs so of course just a situation I
would say this architecture is
completely open for for comments and
don't hesitate to
for some other ideas now secure storage
so how are we going to unload secure
storage depending on the platforms if we
are running on our own platform natively
and we don't have any problem because we
can just stop things natively on the
platform if we are running on a host on
which we can store anything which is an
example for enclaves and HDX
we have to be a little bit more creative
in this case so one way to do that is
every time move on to use secret data we
can encrypt it by a key which is owned
by the application running into HDX
running into the secure environment we
can store this on the host because then
it's not dangerous because this I mean
this blob is encrypted and cannot be
cannot be used by the host and when we
want to use it we will just pass it back
to the Enclave we can also choose to
bind the data to different items so we
can bind it to the interface itself we
can bind it to the device or we can bind
it to a specific application so we have
all kind of granularity in the way we
relate secrets from other applications
even when running on an enclave we still
have some some problems if we want to
consider secure storage on Enclave so on
which we can store things natively
typically on TV play is a critical
feature if we want to implement a pin
counter and we don't have on TV play
it's not going to work because then
people can just push you the same
counter over and over again and you just
can't do that so one way to overcome
this this limitation is to use monotonic
contours monitoring contours would be
counter that and can only go forward and
this is guaranteed by hardware so in
this case we would use a monetary
contour put it in the object reference
store the value increase it when we want
to change it and it's fine because this
can't be replayed this can be replayed
depending on the condition we have for
the implementation of monotonic contours
on the platform so here again keeping in
mind that you have to consider all
threats when implementing something you
want to verify typically if there is a
reset condition for monetary control and
how that would work
now something else to consider
specifically for SGX let's say you want
to migrate data from one Enclave to
another you have to consider if you want
to lock your secrets to your
applications or lock your secrets to
your issuer if you lock to your
application then secure I mean security
wise is quite safe because if the
application is modified you are losing
secrets but it's not that nice for the
end-user because then you have to repose
analyze everything
if you lock to the issuer everybody can
update the application but if you lose
the issuer key then you are going to be
you are going to be able to compromise
all user data by just deploying your own
Enclave so here again you have a
trade-off to perform between security
and usability and think carefully about
it now regarding the implementation of
cryptographic primitives you have
basically two choices you can use
cryptographic primitives given to you by
the platform with guarantees that they
are going to behave very well and they
are going to resist all kind of all kind
of side-channel attacks or you can use
open source crypto history has proven so
far that it's better to use open source
crypto so if you have been following
security news in an infinite library as
some issues recently so here well we
have good typical choices to implement
several cryptographic primitives are
coming from Bitcoin we have lipstick P
256 K 1 and CT AES IES and we have also
open source libraries for different kind
of crypto switch have been tested again
side channel attacks and which are
reliable I would consider too I would
consider to exert extreme caution when
picking a cryptographic library because
there are a lot of open source
cryptographic libraries when where these
attacks have not been considered but
thanks to different cryptocurrency
projects I've already picked some good
libraries for us so we can use that in
all trades as well now the proof of
execution if we want to prove that
something has been running on the
trusted platform and on the blockchain
the easiest way to do that is to just
include the hash of the application into
a primitive that we will call to let
an application sign a message we can do
that because the iteration and join is
knowing which application is running and
so can intercept the call insert the
hash of the application in the middle
and walk further with that so by
implementing this we have something that
extremely easy to verify unchain because
it's just a signature and typically is
as always this has already been
implemented by our class and there is an
example you can you can you can check on
hgx the way we will do that is we will
go through one step we will call IAS so
we'll call the Intel attestation service
at some point because that's necessary
to initiate the chain of trust and then
we will continue the chain of trust from
from ourselves so in the end we end up
with applications that we can verify on
chain even if they are running on an hgx
Enclave with an attestation which is not
supposed to run on chain but we might
still want from time to time to check
the health of the platform because the
state of an enclave can change over time
typically if there are bugs of or
exploit that's the case today there is a
bug that's going to be patched by Intel
shortly so we we have a system that we
can verify or unchain we still have to
pay some attention on who we are going
to patch it several use case we can have
with all those systems so we can first
this decide to replace hardware wallets
and visualize hardware wallets but to do
that we first need to have a twisted
display and twisted input because one of
the key part of hardware wallets is not
lying to the user when displaying
something and waiting for the user input
before actually performing an action if
you want to do that we need specific
primitives that might be not implemented
by all platforms
typically on hgx we will need the
twisted display school PGD whole body
heat protection display projection
display sorry we need to have this
implemented if we want to have a user
wallet which is similar to a consumer
product we can still perform some we
have some mitigations if we don't have
PTV typically we can use to unclip to
have one acting as a secure screen and
one binding to the other but yeah that's
kind of a hack and not extremely
comfortable if you tell two users that
you are going to make their life easier
but still require need to have two
devices to work properly another use
case which is probably more useful and
easier to deploy in that case is to use
to create a usage specific hardware
wallet so how do I wallet that would
look for specific contracts for specific
addresses for specific limits or code
size that you want to implement on the
under system so that's easy to deploy
even if you don't have a twisted input
question is you might wonder why this is
better than a smart contract
implementation that could do all this by
itself so first if you want to deploy
this on a device it's a great way to
make sure that your device keys won't be
stolen to do something else which is
still compact is enforcing things and
then you can create more flexible update
rules if you want to update a smart
contract today either you have to think
about it before creating it or you would
have to empty it and transfer its funds
as well so doing that with hardware
might be more convenient in in many use
cases you can also use the service to
create external services that you can
verify so the on demas random Oracle is
an example also for moralize creating a
random source and verifying that the
random has been generated by a trusted
platform and finally so speaking about
those architecture we have an
implementation running the prototype
that you can already play with so I'm
taking all kind of suggestions about it
today's a reason implementation walking
on hgx there will be one walking on arm
shortly next year so it's heavy walking
polar ice just to let you know we don't
have yet an ATM one at available but you
will find all cryptographic primitives
and if you want to start playing with it
and then asking some questions well I'm
around let's get the conversation
started
[Music]