Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/147 Thanks!
Please welcome
Pavel Rusnak, which
is currently developing.
So if a colleague of his, he himself
is a co-founder
of Sperm Labs and the Fab
Lab in Prague,
his colleague,
I think, is the one who who
invented share
the bitcoin mining pools, bitcoin
mining.
And today they will
show us a secure
device for storing or actually
authenticating bitcoin
transactions called Trezor.
So thank you for the introduction,
and I will try to reintroduce
our team again, so
you might recognize the guy on the left
who was mentioned.
It's marked by Latinos, also known
as slash inventor of
pool of mining pool
concept and also operator
of the first mining pool,
which is still one of the biggest
with around 10 percent of
hash rate on the Bitcoin network.
He also invented the stratum
protocol, which is currently used in the
miners pools and in
bitcoin client, and
the guy on the left is me popular snack.
And I'm responsible for some smaller
bitcoin projects like, for example,
quantum dot org and
put together the
form of if Alana, who is
sadly not in the photo
company called Satoshi Labs.
And we tried to
have something like an umbrella
organization for this bitcoin
related project.
One of the most important problems
in the Bitcoin mass adoption
is security and safety
of bitcoin private keys
by security.
I mean, the security of the end users
computer because we have
compromised computers with viruses
and malware and keyloggers.
We also have, for example,
in an internet cafe, our computers we
don't trust.
And what's not very common nowadays but
may be common in future are clients
which look like the regular clients,
but they do something they are not
supposed to do.
And by safety of bitcoin
private keys, we
mean the data
are more particularly wallet loss
during various disasters,
hardware failures and they, for
instance, of operating system and
also failing to do proper
backups, which is
very easy, for example, in bitcoin.
There are not a lot of users are aware
that you have to back up your
wallet regularly,
otherwise you will lose your bitcoins.
And solution to this,
we think, is hardware wallets,
hardware, wallet ideas.
This idea is not
new.
First, I encountered this idea
during a bitcoin conference in Prague in
2011, when
the Clemmens cap introduced
us to this project of hardware
wallet.
Sadly, he didn't
pursue with his students
this this idea of Arduino based
how to develop further.
And after a Bitcoin
Conference 2012 in London,
we decided we flush to
create a project that is now
now known as Trezor
to actually bring this hardware
wallet idea to life.
We decided to follow the
Keep It Simple principle.
So we are building a USB-C gadget,
more particularly a human interface
device.
It has an OLED display
and OK cancel buttons,
which require a physical interaction
with user to confirm or discard
transaction.
And we don't have batteries
because we use just power from
the user's be and
we don't have radio like Bluetooth or
wireless because we aim to
focus on the security of bitcoin
transaction, not not the mobility,
which is quite good nowadays.
What's inside of treasure?
We have our views arm cortex
and Free Micron controller,
more particularly ASTM 42
f 205
clocked at 120 megahertz.
It has half a megabyte of flesh
for our code, one hundred
twenty eight
kilobytes of RAM and
how the random generator, which I will
talk a little bit
later. And it has OLED
display,
which is more or less one one one
inch wide.
During the development, we also created
a Raspberry Pi shield, which
uses the same display.
Sadly, Raspberry Pi that can't
act as a USB client
device.
Just she was B host, so we
had to put an extra USB
B to serial converter
chip on board, and
this shield was used
as a prototyping platform during
a development phase because that allowed
us to use Python instead of C and
to quickly,
quickly try some stuff before
implementing the implant it
in much loved ever see.
And the good thing is
that this Raspberry Pi, the shield
follows the same logic as the real
Trezor device, so client has
no way to determine if there is a real
device or a Raspberry Pi shield on
the other side.
So let me give you an overview of how
Trezor works.
First, we have to generate the
initial entropy and we
want to allow its easy backup.
Then we use this entropy to derive
master private key and master public
key.
I call them generators because
with these master keys, you are able
to generate basically an infinite
number of private keys and
corresponding public keys and addresses.
And if you send this master public key
to computer, it
immediately knows which addresses are
there available to be spent.
And because of
that, a computer can then prepare
transactions and send them to
Trezor.
But these transactions are
are not having signatures because
computer doesn't know the private keys.
It just feels fill in,
fills in the gaps with key indices,
and then Trezor can use master
private key to generate
these private needed private
keys from these indices.
If the user confirms the transaction,
then it's signed
using these keys sent back to computer
and it can broadcast it to the network or
like it would normally do.
The main idea behind this
is that private keys never leave the
device because they are generated inside
of the device.
And even during the signature, there
is no reason to buy.
They should go out.
So how do we generate entropy?
We use hardware random generator
two to create the internal
entropy a, we can
request the external entropy from
from a computer, and then we
use both entropy to generate final
entropy. And
if we commit to
entropy a before
receiving entropy b, we can prove
that the external entropy was used,
for example, with this very simple
scheme.
More complex schemes were suggested
by Timo Hanka and Ilya Gerhart
variable, for example, by
publishing half of the final entropy.
You could say for 90 percent
that external entropy was used, and
you can increase this percentage by
revealing more and more bits from
from this final entropy.
So we have this
entropy, which is basically 100
to twenty eight or 256
bits, and we want to somehow
make them available for pickup.
So we use something that's
called the mnemonic code,
which is heavily inspired
by what Thomas did in
his Electrum client.
The idea is simple we split these
bits into a chunk of
of the bits.
We have a short list of 248
words. We interpret each.
This chunk as an integer between zero
and 247 and use
the the
vault from vault waste to
to create a sentence.
We could use entropy directly
to generate the master private key,
but we decided to do something more.
Likes and standardize it
as a mnemonic code for
thirty nine.
So what we do is we use
B-BBEE ADF to to generate master
private key.
It's a constructed use.
So the random function H
MC Sha 512.
We use password as a password of using
mnemonic sentence and we solved
it with string mnemonic
concatenated user secret
and that allows us to create
something like password protected
monarchs.
So the idea is you write down
this twelve or twenty five
words on the paper put
it in a safe
and if even if
someone steals this paper,
he doesn't have your massive
private key because he has to provide
this user secret.
If it was used and also
a nice side effect, is that it provides
plausible deniability because if you
if you give some different user secrets
to an attacker, he would obtain
a different master private key and
a completely different set of addresses.
And if you are clever enough to
send some small amounts of bitcoins to
these fake addresses, he can never know
that you gave him a right or
wrong user secret.
We use 496 iteration
and desire to kill these
five hundred twelve bits.
That's because there is
another standard called hierarchical
deterministic wallets,
which use exactly 512
bits for its master node.
And the idea is that
using that construct, uh,
you could create basically
a tree of, uh,
of addresses, and each level
can can be some
logical way how to add
how to do this addresses into logical
groups. So, for example,
uh, the first level would
be what your wallet's second
level would be or different wallet chains
like, for example, main addresses
and change addresses.
And the third level would be actual
addresses of that kind,
and the function that
generates
a level one from level zero
is called
child key derivation function.
And it takes data
from parent node
and index.
Index zero one.
To create different, different
child of that particular node.
And then you can descend deeper and
deeper in the tree and you
have some logical structure in your
addresses. So it's not like it's flat.
The derivation function
that uses also HMX are
512, and
it was designed by Peter
Sipamla.
And it's standardized as B-52,
and because it's very abstract concept,
it provides lots of possibilities.
The first one I described on the previous
slide, but you can, for example,
have first level as a representation
of different coin types like, for
example, the
first node would be bitcoin
addresses, second node light code
addresses and so on.
And then it would follow these logical
structure deeper.
Or you have some
even more complex setup.
Imagine there is a company that
has headquarters and
local branches around the world,
and this key
that happens to be a headquarter
key can derive
all oral keys
in all branches or around the world.
But if you are a director of a local
branch, you have access access.
Just to address this
only happened that that
happened in your in your branch.
What's even cooler?
We can push this concept
even further and
use first the
first node in level one for a
cryptocurrency second
second node in level one for generating
SSL keys,
another node for generating full disk
encryption keys, and
Lex Node for generating challenge
response keys, which can
happen in if you have some
intelligent door to your house,
or maybe even to start your car.
And that's very cool, because suddenly
your wallet's token happens to be
identity token.
You can do pretty much everything you
do. You can.
Another problem we found
or tackled
is that SDK
signatures require
random nonce.
During signing for bitcoin.
It's 256 bits,
and if you use the same nonce twice
for sending different messages,
you using the same particular key,
you would basically be risky.
This was demonstrated on 02:33
failure for all the talk about console
hacking, how they got the place free
private key.
And sadly, it was also
exploded in August 2013,
where there was Android, the Java
random number generator vulnerability in
secure random class, which
didn't use enough entropy to generate
this nonsense.
And more than 59 bitcoins
were stolen.
What's what was
even worse was that all
of all Android clients were
affected because the bug was
in a shared library.
Be below the application
code and also
it.
Even if you imported your own private key
into Android.
Already, you were not safe because the
problem was during generating
launches for signatures, not during
generating the private keys.
So coincidentally,
in August same year,
out of six six nine seven nine was
released with implementation
in Java, and Go later
reported this idea to buy
the Python SDK.
This slush and it was merged in
0.9 release.
And the idea is you don't use
random nonce for signature,
but you generate
these bits with
each mark
deterministic random generator,
which is seeded with private key and the
message so it can cannot
happen that you sign
off two different messages with the same
particular key using the
same nonce.
And it was great news for us because
that avoided the problem.
It enabled us to do unique tests
which weren't possible before, and now
suddenly we could.
We could see the Treasury doing
the correct thing for
during signing.
And also what was important
that allowed us to prove the Trezor
doesn't leak massive private key in nonce
because you could create such a scheme
that would do that.
And let me tell you something about
integration in order to be
Treasury possible, we need to
integrate it into existing
disciplines.
So the work is being done in
the multi bit by multiple guys
and this will be the uses
for Bitcoin, Jay and Treasury
Library and
Electrum and Armory clients,
which are written in Python, which
we are really fond of with
America.
And sadly, bitcoin
security is pretty
complex codebase, and we
currently have no
immediate goal to to
implement Trezor support into it.
And also upstream is probably
not very hesitant to
uh.
It's a little bit hesitant to to
do such big changes in their code base.
The good thing about mobile clients,
particularly in Android, is that
most of new Android phones have
USB OTG, which
allows them to communicate with
USB devices.
And because multi it is written in Java,
they can pretty reuse most
of the code base that
that is that was written for multi
bit.
And also, what we are working right now
is a native
browser plugin which will create
a bridge between Lovullo
value be communication if Trezor
to JavaScript.
So web wallets can actually use
Trezor via JavaScript bindings.
And that would allow you to finally
create a safe
level as because there would be no
private keys stored on the server.
So I think that's it.
If you want to contact us, there
is this email.
Please put for a DC free in a subject.
So I know it's came from this conference.
Most of the source code is
published on GitHub.
We will release.
We will release a few of our source code
in January.
Then we will ship.
We will ship most of the preorders.
And if there are any questions,
I'm willing to
answer them right now.
I can show them if
they want, if they want.
I think one minute is OK, but.
OK, then.
So I can show you, uh,
before you line up in a microphone,
I can show you some early prototype from
from September.
So it looks like it is, uh,
it's a metallic version, which
is more or less final.
We will be doing some, uh,
polishing touches to the version that
will be shipped in January and.
OK. I don't know if you see it.
And it just just the demo
screen, because that's if you femur back
from September.
So there is there is some
demo demo transaction and I can
either confirm it or cancel it.
And if I confirm it, then it's just
some animation doing the signing.
And so that's how it looks.
I anyone
is.
Thank you very much.
If you have any questions you already
know the drill, please line up
behind the microphones
so you have
a question number three.
Please go right ahead.
Yes, I was wondering if your your
hardware wallet supports
other types of complex transactions,
like in out of him transactions
and such.
In the first funeral we be releasing
in January, there won't be such
a feature. But because we have a future
update possibility, we
definitely want to include
multi-signature in the next version of
firmware and probably some more complex,
complex transaction types.
If.
Are there any questions from IOC?
Yes, one, please.
Um, it's look look like
the person perfect solution
for Ethereum usage.
Um, do you think maybe
bitcoin ATM machines
are, uh,
popular?
Integrate it
with some popular ATM machines
in the future?
I think it should.
It should be possible to integrate it
with ATM in the future there.
Well, ATM is more or less
common computer nowadays, so I
see no reason why we we shouldn't
go that way.
But if
because we don't have any Bluetooth or
radio, uh, the first
version would have to support USB,
but maybe in the future there will be
some, some other ways.
Number one, please tell me
what happens with a bitcoin
stored on the device when
it breaks,
then you able to recover your
paper wallet with this 12 or
twenty four words.
And using this backup,
you can recover it into other Trezor
device or just use software
that's compatible with Bip 49
and send your bitcoins to
other other address.
So that's the main purpose of
this paper. One of the backups?
Next question from number four, please.
Hi, thank you for your talk.
It's very interesting.
Thanks. I saw on the website
the preorders are closed.
Do you have an idea when you will be
taking orders again?
We will be shipping
Trezor to preorder people in
January. And after all these preorders
are shipped, we will reopen Trezor
for regular sale
in February.
Well, after we are done.
So most probably in February, right?
Thank you.
Number one, please.
Are you thinking
about another version where you have
maybe a power supply within the device
and then you could transfer the
transactions via Bluetooth or something,
which would be more convenient, maybe for
later users?
The problem is, if we want to have radio
in Trezor, we would need to have a
battery and other stuff.
And it's it looks simple,
but it's adding more and more complexity.
I'm not saying we are not going to go
this way, but the first version,
of course, I suppose version is, yeah, we
will see how her market will
responds.
It's still a new, it's still a new
area for us and for everybody.
So maybe it will be needed.
Maybe it won't.
We'll see. It would be nice, but the
first version is already very well.
Thank you. Lots of luck for that.
Thank you.
Another question from number four,
please.
Yes. So you talked about update
functionality.
How do you prevent any kind
of update functionality from compromising
the device? Obviously, when you plug it
in an untrusted system like
web shop, like an
internet cafe or the aforementioned
ATM machine?
All right. What?
We have a bootloader that contains
our public keys
and all of our freeware
is signed by us.
And if the signature
is incorrect, then Trezor will print that
you are running an official FINRA so
you can build your own forever, but you
will have to confirm
this warning in order to run it.
Thank you.
Many of you are trying to find seats for
the next talk, but please, I
know it's hard. Try not to queue up to
walkways
any more questions from
IOC. Maybe.
OK.
Then thank you for the talk.
Thank you for this lovely.