WEBVTT
Kind: captions
Language: en

00:00:00.458 --> 00:00:06.458
>>	I am Richard Klafter and this
is Eric Swanson this is our
first time talking here at DEF

00:00:09.042 --> 00:00:13.750
CON. Looking forward to it.
(Applause.) In fact this is our
first time being at DEF CON.

00:00:13.750 --> 00:00:19.000
It's been tons of fun. Anyway,
today we're going to be talking
to you about checking your

00:00:19.000 --> 00:00:23.458
fingerprints. Specifically we're
going to talking about taking
your GPG fingerprints. So, we

00:00:23.458 --> 00:00:27.625
are going to do a little bit of
background Just to get everyone
up to speed, GPG is an open

00:00:27.625 --> 00:00:33.625
source alternative to BGB. It's
a general encryption and signing
tool. And it's very important

00:00:35.875 --> 00:00:40.708
answer surveillance tool. That
is it's used for both sending
secure messages between

00:00:40.708 --> 00:00:45.542
individuals, corporations,
etcetera, and signing packages
and messages so that you get the

00:00:45.542 --> 00:00:51.042
message -- it's from who you
think it is. There are lots of
good resources online. This is

00:00:51.042 --> 00:00:58.667
not going to teach you how to
use GBG . So, one of the --
there are a few important

00:00:58.667 --> 00:01:04.750
things. First of all, GBG is
used everywhere. It is the most
widely used e-mail encryption

00:01:04.750 --> 00:01:09.292
package. It's used extensively
for software package
verification which is kind of

00:01:09.292 --> 00:01:16.125
some of the stuff we're going to
be talking about. There's lots
of people that use GBG other

00:01:16.125 --> 00:01:21.833
than privacy conscious crypt
owners like me and a lot of you
probably. Including journalists,

00:01:21.833 --> 00:01:25.542
lawyers, lawyers, activists,
etcetera. I'd like to mention
that these people don't write

00:01:25.542 --> 00:01:28.625
the software. They don't
necessarily understand all how
to use this. But I think it's

00:01:28.625 --> 00:01:32.333
important that they know how to
use this competently and safely
because their jobs and often

00:01:32.333 --> 00:01:38.333
their lives depend on it. In
order to exchange a secret
message, you must get the

00:01:40.542 --> 00:01:47.250
receivers key. This is normally
done via the GBG key servers.
And when you specify your V key

00:01:47.250 --> 00:01:54.333
on the GBG servers, you specify
either a fingerprint, 32-bit ID
or a 64-bit ID. You receive the

00:01:54.333 --> 00:01:59.583
key. And once you receive the
key, you verify that it is the
key you think the key is.

00:01:59.583 --> 00:02:03.750
There's two ways of doing this.
The one is manually check the
fingerprint, character by

00:02:03.750 --> 00:02:09.292
character and the other way is
to use the web of trust. More on
that later. And the big problem

00:02:09.292 --> 00:02:13.708
with this essentially is
mistakes are fatal. If you trust
a key that you shouldn't be

00:02:13.708 --> 00:02:17.500
trusting and there's no
recourse, you lost, Which makes
this key exchange part very,

00:02:17.500 --> 00:02:24.750
very hard. >>	So, the web of
trust is the most commonly
specified way to do a key

00:02:24.750 --> 00:02:30.708
exchange with GPG and its one of
GPG's big innovations. Again,
the whole point of this

00:02:30.708 --> 00:02:34.208
authentication is to verify that
the key you got is from who you
think it's from. So it's from

00:02:34.208 --> 00:02:39.750
somebody with the correct id and
everything else. And the web of
trust is the most popular

00:02:39.750 --> 00:02:43.167
decentralized method for key
exchange. People have built a
lot of other things on top of it

00:02:43.167 --> 00:02:48.000
and it's very cool but it's also
very hard to use. In order to
get into the the web of trust,

00:02:48.000 --> 00:02:52.417
you have to find somebody that
you trust, verify their ID and
verify that they will check

00:02:52.417 --> 00:02:57.000
other people's IDs. And then you
can only trust them so far as
you verify they perform the same

00:02:57.000 --> 00:03:02.875
steps and so on. And this means
that a lot of those other users
don't, the Lawyers and activists

00:03:02.875 --> 00:03:07.417
and the like don't join the web
of trust and instead rely on
less sophisticated mechanisms.

00:03:07.417 --> 00:03:12.417
Also, GPG as a tool has a
somewhat complicated interface.
You have to use some arcane

00:03:12.417 --> 00:03:16.500
command line options or the
interactive mode are a couple
other ways to verify that you

00:03:16.500 --> 00:03:20.125
trust a key. And it has a lot of
complicated questions that again
can scare off a less

00:03:20.125 --> 00:03:26.417
sophisticated user. And even
Debian which is a well known
being a pretty secure operating

00:03:26.417 --> 00:03:32.250
system tells users to ignore the
message, no ultimately trusted
key is found because that's part

00:03:32.250 --> 00:03:35.500
of the web of trust and they
didn't want to get into it. And
we've all seen what happens when

00:03:35.500 --> 00:03:42.583
you tell users to ignore warning
messages . So, we promised a
demo in this talk, and here's

00:03:42.583 --> 00:03:47.167
our demo. We're going to install
puppet and its signature from
our mirror and since we don't

00:03:47.167 --> 00:03:51.333
trust our mirror we are going to
verify our signature with GPG
like the documentation tells you

00:03:51.333 --> 00:03:56.083
to. So, first we need to get the
two binaries and this is from
our secretly evil mirror at

00:03:56.083 --> 00:04:03.500
evilmirror@32.com. Now we'll
follow the documentation. They
tell us to request the key by

00:04:03.500 --> 00:04:09.500
the 32-bit ID. And you'll see
two keys imported. Now we'll
verify the fingerprint following

00:04:17.625 --> 00:04:23.625
the documentation. And you can
see in here, alright, let's see
47 B 3. Let's see if we can get

00:04:28.875 --> 00:04:34.875
this a little bigger. 47B3,
47B3, 20EB, 20EB, 4C7C, 375A,
375A, and so on. Now, of course

00:04:38.667 --> 00:04:43.667
you should verify the full
finger print but in the interest
of time I won't go through it.

00:04:43.667 --> 00:04:46.833
And then finally we'll verify
the source Tarball that we
downloaded using the signature

00:04:46.833 --> 00:04:52.375
we downloaded against that key
that we just fetch from the key
server. And you see it says good

00:04:52.375 --> 00:04:57.375
signature. Now, there's this
warning here saying it's not
certified but both Puppet and

00:04:57.375 --> 00:05:02.583
Debian have told us "Oh, don't
worry about that warning, it's
no big deal". So it looks good,

00:05:02.583 --> 00:05:08.083
we can go ahead and install it.
And we just got owned. Now, it
turns out that when we fetched

00:05:08.083 --> 00:05:14.458
the keys, we received two
different keys. You can see them
both here. Here's one key's

00:05:14.458 --> 00:05:19.292
fingerprint and here's the the
second key's fingerprint. This
was the evil key. Unless you're

00:05:19.292 --> 00:05:23.417
paying particular attention, you
might not have noticed there was
a second key or you thought oh

00:05:23.417 --> 00:05:31.000
well there's two. No big deal.
This one matches. The truth is,
humans are broken, not the

00:05:31.000 --> 00:05:36.083
encryption. Humans make
mistakes. We're bad at comparing
long strings and particularly

00:05:36.083 --> 00:05:41.292
bad at noticing differences in
output we see often. So, as you
can see below, if you request

00:05:41.292 --> 00:05:47.292
the key with a short ID of
10000001 from the PGP.MiT.edu
key server you will receive two

00:05:50.417 --> 00:05:54.833
keys back. One for John Doe and
one for Jane Doe. But if you
import keys frequently, you

00:05:54.833 --> 00:05:57.958
might not notice that you've got
two keys and you might not
notice they were for two

00:05:57.958 --> 00:06:02.417
different people. But they're
both in your key right now. GBG
doesn't say anything to warn

00:06:02.417 --> 00:06:07.292
about this. They return to the
same status code, everything
looks normal. And slightly more

00:06:07.292 --> 00:06:12.708
worryingly, GPG doesn't even
verify that the received key
matches for the one you asked.

00:06:12.708 --> 00:06:16.667
So if you asked for the
fingerprint, the full
fingerprint, but there's for an

00:06:16.667 --> 00:06:20.000
example a man in the middle
break. So in this case, we have
a server impersonating

00:06:20.000 --> 00:06:26.292
PGP.Mit.edu, which returns back
the zero bad beef key. Clearly
that doesn't match the

00:06:26.292 --> 00:06:31.292
fingerprint we asked for, but
again GBG gives no warning and
this key is in your key ring.

00:06:31.292 --> 00:06:34.958
Since GPG doesn't verify
anything, the key servers can
tell you to import anything they

00:06:34.958 --> 00:06:38.500
want. And since the key servers
don't use transport level
security or anything else like

00:06:38.500 --> 00:06:43.917
that, they're vulnerable to man
in the middle attacks. So for a
practical exploitation of that,

00:06:43.917 --> 00:06:48.917
this line comes from Dokers
install script. If you use act
key advanced and you give it the

00:06:48.917 --> 00:06:52.667
received keys with a full
fingerprint but again with a man
in the middle break, you'll see

00:06:52.667 --> 00:06:58.625
we fetched the zero bad beef key
and now that's in your ATP key
ring. And again, this comes from

00:06:58.625 --> 00:07:04.625
the script dot doctor dot IO. So
there's a few caveats with this.
None of these examples on their

00:07:07.208 --> 00:07:10.833
own will result in a practical
break. Both Puppet and Doker
will give you their binaries

00:07:10.833 --> 00:07:16.625
over SSL most of the time. In
this case, they're merely trying
to check that GPG sign box.

00:07:16.625 --> 00:07:22.167
They're using TLS to give them
the real security but TLS relies
on certificate authorities. And

00:07:22.167 --> 00:07:27.500
we all know in various sign
certificates authorities are not
to be trusted. We love GBG and

00:07:27.500 --> 00:07:31.042
we want to have a good
decentralized option that can
replace certificate authorities.

00:07:31.042 --> 00:07:35.458
But when it was used like it was
used in these examples, it adds
nothing to the security. If the

00:07:35.458 --> 00:07:42.750
HTTPS weren't there, it wouldn't
be secure. >>	Okay, So for
finding these fingerprint

00:07:42.750 --> 00:07:46.458
conclusions and some of this fun
stuff, we've wrote a tool. It's
called scallion. And the

00:07:46.458 --> 00:07:50.250
generally way, during high level
view is how scallion works is it
generates five hundred million

00:07:50.250 --> 00:07:56.833
GBGs per second. It does this on
the GPU. And for each key, it
checks for partial fingerprint

00:07:56.833 --> 00:08:04.292
collision. Now, Scallion runs on
any modern GPU cold bit coin
hardware is prime. On open CL.

00:08:04.292 --> 00:08:11.083
And you can grab sources and
such at evil32.com. A little bit
more detail, essentially first

00:08:11.083 --> 00:08:18.167
step and generating the GPG keys
is we generate an RSA key with
libOpenSSL. We send the key to

00:08:18.167 --> 00:08:24.167
the GPU. And increase the public
key's exponent. Hash the key and
steps two or steps three and

00:08:26.583 --> 00:08:32.083
four we do five hundred million
times a second. If there's a
partial collision, we send it

00:08:32.083 --> 00:08:38.083
back to the CPU and bam you have
a brand new GBG key with a
partial fingerprint collision.

00:08:41.208 --> 00:08:46.583
So what are the implications of
this? First off, 32-bit keys Ids
are ridiculously broken. They've

00:08:46.583 --> 00:08:51.917
been broken for one some time,
you can do this on a CPU. But an
RGP with our software it takes a

00:08:51.917 --> 00:08:57.750
few seconds to do this. To
demonstrate how easy this is to
do, we've cloned the entire WoT

00:08:57.750 --> 00:09:02.833
strong set, which is about fifty
thousand keys, in one day, on a
four year old bit coin miner.

00:09:02.833 --> 00:09:08.833
You can check out our cloned key
server at keyserver.evil32.com.
So another way you could specify

00:09:13.000 --> 00:09:19.083
how to receive a key from GPG
key servers with 64 bit key ID.
So this is like the obvious path

00:09:19.083 --> 00:09:24.750
to go forward and make the more
secure, use more bits, right.
This one's already there. You

00:09:24.750 --> 00:09:30.958
can already use it. So at the
moment, finding a specific key
with a 64-bit key ID is not

00:09:30.958 --> 00:09:35.583
practical. However, let's say we
wanted to find one of the higher
keys. We have a list of a

00:09:35.583 --> 00:09:39.333
hundred different software
packages and we just want to
find a collision -- given 20

00:09:39.333 --> 00:09:43.875
DPUs, looking for a hundred keys
it would take approximately a
hundred and seven days to pull

00:09:43.875 --> 00:09:49.292
this off. So like this is strong
fairly at the moment, like. Not
practically broken, but in the

00:09:49.292 --> 00:09:56.292
long run, this isn't going to
work. >>	So this leads to two
big classes of vulnerabilities.

00:09:56.292 --> 00:10:00.750
First of all, if the attacker
owns the network, they can
exploit the fact that GBG

00:10:00.750 --> 00:10:06.042
performs no verifications to
send arbitrary keys back to you
in response to receive keys. And

00:10:06.042 --> 00:10:10.833
this one might seem a little bit
obvious to you but they can
tamper with the fingerprints and

00:10:10.833 --> 00:10:12.833
documentation that are served
over and insecure channel. I've
seen a lot of cases where

00:10:12.833 --> 00:10:18.417
documentation for what
fingerprint to use is just over
http which doesn't add very much

00:10:18.417 --> 00:10:23.917
in level of security. And if the
network is secure, then things
are a little bit better. The

00:10:23.917 --> 00:10:28.333
attacker can still exploit 32
bit key collisions to return
multiple keys with the same ID.

00:10:28.333 --> 00:10:33.208
And as you saw the output looks
very similar when this happens.
And they could also upload

00:10:33.208 --> 00:10:38.250
arbitrary data to the server. So
keeping with the big coin theme
here, I looked at Satoshi

00:10:38.250 --> 00:10:45.250
Nakamoto's key, and his key was
created in 2008 and there was
two signatures on this key that

00:10:45.250 --> 00:10:53.042
start out. One in 1995 by Dade
Murphy from hackers, and one in
2001 by the Time Traveler from

00:10:53.042 --> 00:10:58.042
Usenet John Titor. So neither of
these seem particularly
legitimate, but the key server

00:10:58.042 --> 00:11:03.958
is happy to show them to you and
GPG is happy to import them to
you when you request the key.

00:11:03.958 --> 00:11:08.833
So, take away. If there's three
rules to follow these will keep
you pretty safe with GPG. First

00:11:08.833 --> 00:11:13.500
of all, always verify your
fingerprints by hand. Follow the
full fingerprint and make sure

00:11:13.500 --> 00:11:17.208
you get it from a trusted
source. Or use the web of trust
and understand what the

00:11:17.208 --> 00:11:21.917
implications of that are. Second
of all, don't trust the key
server. Even if you request a

00:11:21.917 --> 00:11:27.542
full fingerprint, that might not
be what you get back if the
network is not secure. And

00:11:27.542 --> 00:11:32.167
finally, don't use 32-bit key
id's anywhere. Don't put them on
your blog, don't input them in

00:11:32.167 --> 00:11:37.667
the GBG, certainly don't input
them in your software
documentation . For the people

00:11:37.667 --> 00:11:41.958
who need to fix the problem, GBG
UI is broken up in a couple
ways, first of all, it shouldn't

00:11:41.958 --> 00:11:46.250
accept 32 bit key id's anymore
and it shouldn't display them by
default . There is a format

00:11:46.250 --> 00:11:50.250
option that you can put in your
config that will make it show
64-bit id's by default but it

00:11:50.250 --> 00:11:55.167
will still accept 32-bit id's
and it will still show you keys
that colide. Second of all, if

00:11:55.167 --> 00:11:58.792
there are key collisions, that
seems pretty unlikely. GBG
should give you a warning if you

00:11:58.792 --> 00:12:06.458
ask for a key especially by
fingerprint or by ID and get a
collision. >>	Okay. So, we have

00:12:06.458 --> 00:12:12.333
a -- if you want to know more
about the project, more GBGEUI
hacks, get access to the key

00:12:12.333 --> 00:12:16.667
codes, source code et cetera.
You can check our site at
eagle32.com. There's additional

00:12:16.667 --> 00:12:21.917
material we didn't cover here
today on this. So it definitely
worth checking out. And I think

00:12:21.917 --> 00:12:27.917
we have a few minutes left don't
we? Does anybody have any
questions or anything? Umm, we

00:12:30.250 --> 00:12:36.250
have not looked into it yet, but
that's kind of on my to do list.
We are doing a presentation. But

00:12:39.917 --> 00:12:44.208
that seems blatantly obvious it
shouldn't break anything. It
should be pretty easy to do, you

00:12:44.208 --> 00:12:51.208
think. >>	So one challenge with
that is you can request key by
UID. By last name or e-mail. And

00:12:51.208 --> 00:12:54.958
it'll perform a search on e-mail
and it will return those keys.
So it is somewhat reasonable

00:12:54.958 --> 00:12:59.667
that you could want to import
every key with a certain e-mail
demand and use that but that

00:12:59.667 --> 00:13:03.333
would rely on you having a
trusted key server, maybe an
organizational setting or

00:13:03.333 --> 00:13:07.000
something like that. So that
would be a little bit of a
caveat. But I think that would

00:13:07.000 --> 00:13:13.000
be a good first step for GBG to
do. Anyone else? Yup? >>	So the
question was what kind of

00:13:22.375 --> 00:13:29.083
implications does this have for
e-mail security? Most notably,
it's problems in key exchange.

00:13:29.083 --> 00:13:33.250
If you can safely get the key
from the counterparty, then
there's no implications for

00:13:33.250 --> 00:13:37.125
this. GBG as a tool is very
solid. The problem is the user
interface and the social

00:13:37.125 --> 00:13:43.125
engineering exploits this opens.
Does that answer your question?
>>	Okay. If there's no one else,

00:13:47.250 --> 00:13:52.958
we can talk about the tool we
created. If anyone finds that
interesting? >>	All right.

00:13:52.958 --> 00:13:58.958
Scallion is actually, we wrote
it, started writing it a couple
months ago. Okay, more than a

00:14:01.500 --> 00:14:07.208
couple months ago. It was
originally intended to generate
addresses for tor hidden

00:14:07.208 --> 00:14:12.625
services. Which essentially
consists of generating an RSA
key and doing a sha1 hash. In

00:14:12.625 --> 00:14:18.917
order to generate enough RSA
keys on the GPU, what we do is
we increase the -- I screw that

00:14:18.917 --> 00:14:24.917
one up. And umm, we don't have
to actually regenerate the key
we just change the exponet. We

00:14:27.458 --> 00:14:33.792
can take the shot hash and check
it. >>	That was pretty much the
key insight was that we could

00:14:33.792 --> 00:14:38.875
take the public -- so an RSA key
consists of a public module and
a public exponent and then the

00:14:38.875 --> 00:14:43.250
private secret components as
well. Which are the two factors
of the modulus and also the

00:14:43.250 --> 00:14:48.542
private exponent. So the sort of
insight was that we could take
this public modulus, public

00:14:48.542 --> 00:14:54.125
exponent that were generated
fairly slowly on the CPU and
then again kind of came from bit

00:14:54.125 --> 00:15:01.000
coin as well we could increment
that exponent as if it were a
noss and look for other keys and

00:15:01.000 --> 00:15:08.458
just take the Sha on the GPU. We
wrote some pretty clever code to
give some limited regular

00:15:08.458 --> 00:15:13.083
expression support so you could
match against regular expression
patterns on the GPU efficiently.

00:15:13.083 --> 00:15:17.333
And this is what let us ask for
all of the keys in the strong
set in such a short amount of

00:15:17.333 --> 00:15:22.458
time. And then there's a couple
of other things that are
particular to GPG that for

00:15:22.458 --> 00:15:27.125
example the creation time is
also part of the hashed packet.
In general, this would let you

00:15:27.125 --> 00:15:33.583
make at least interestingly a
vanity GBG key. You saw the 0
bad beef key. And also any sort

00:15:33.583 --> 00:15:37.792
of collisions you'd like. So
let's say maybe you're looking
for a DSA key is looking a

00:15:37.792 --> 00:15:42.333
little bit long in the tooth.
Maybe you would want to make
another one in the same key ID.

00:15:42.333 --> 00:15:46.708
So you could make an RSA key
forty ninety-six bit using the
same thing. And the tor

00:15:46.708 --> 00:15:52.500
implications are pretty cool too
in that tor uses, they kind of
cheat on the key exchange

00:15:52.500 --> 00:15:58.167
problem, by making the users
type in the full first eighty
bits of the hash of the key in

00:15:58.167 --> 00:16:04.083
the address. So the onion
address is the first eighty bits
if the Sha1 hash of the public

00:16:04.083 --> 00:16:09.333
key of the hidden service. And
this tool lets you generate
various vanity sha1 hash's. So

00:16:09.333 --> 00:16:14.750
for example the silk roads old
hash which was silk road I think
eight or something like that

00:16:14.750 --> 00:16:19.125
they used another tool and did
it on the CPU but we generated
the same hash in like two

00:16:19.125 --> 00:16:26.958
minutes on the GPU. Alright, if
there is nothing else we are
going to be across the hall in

00:16:26.958 --> 00:16:31.083
the encrypto and privacy village
they have a key signing party
that starts at four so we will

00:16:31.083 --> 00:16:37.083
be over there if anyone has any
questions. Thanks for watching.
(Applause.)