On Sun, 13 Oct 2013 08:25:08 -0700
Leo Vegoda <l...@vegoda.org> wrote:
> I am not a security expert either but presumably people will need to
> export keys for backup and deployment on other systems. For
> instance, many people have something like a laptop computer, a
> smartphone and a tablet. Presumably, users would want to use the
> same keys on all those devices so that they can read all their
> e-mail no matter which device they use.
>
> I also expect people would want to be able to revoke a key if a
> device is stolen and then generate a new key to replace it, back
> that up and distribute it to all the devices in use.
...
> So my questions are:
Excellent questions.
> - how do people use the same keys on all their devices?
OK. Keys are just small files. So this boils down to 'how do I securely
transfer small files between my devices?'.
This involves private keys, so we really need to be a little careful with this
one.
Here is how I think this might work:
Besides the normal keys that are generated when your MUA is first started, a
'device key' (device keypair, public and private key for the device) is
generated. These are unique to each device, and you are prompted for 'device
name' at some point ('Joe's tablet', 'Joe's Phone' etc.). So now we have a way
to encode something that only one device can read.
But we need to exchange public keys. Since these are public keys, just about
any way will work that will transfer a file. Best would be something completely
local of course, but this could also be something like an attachment to an
email.
So: select menu item 'Friend a Device'
See:
"Friending a device means interchanging device public keys. This is required in
order to be able to securely share your friending environment between all your
devices that use email (home computer, tablet, phone, etc.). Each device must
have the device public keys for all your other devices. This step only must be
done once.
There are two ways you can make this key exchange:
1. You can export your device public key for the device you are currently using
to a file, which will be called YOURDEVICENAME.devicepublickey. This is then
copied to all your other devices using a disk, usbstick, local lan, or other
means of locally copying files from one device to another. Then, on the other
device, you select 'Import Other Device Public Key From file'. You must export
the device public key from each device you use, and import it to the other
devices.
This is the most secure means of making this key exchange since the device
public key never leaves your local environment.
2. You can use email to send the device public key as well. This is slightly
less secure, since your device public key will go over the network, where it
could be seen by someone else. Your private key will still be completely safe
though. This may be required for certain kinds of devices where other means are
not possible. If you select this option, a new email message will be created,
to yourself, that contains the device public key in the body of the email. You
should send this, then on each device you wish to 'friend' as a device, call up
the email and select from the menu 'Import Device Public Key From Current
Email'.
You must do the to and from each device.
Select 'Method 1' 'Method 2' 'Abort'"
Now we have a way to encode transfers between devices.
To actually sync:
Select from menu: "Sync my complete email friending environment from this
device to another"
See:
"Select device to sync to from list"
Select one.
"Select method:
1. Export to file, which will be called USERNAME.friendkeysenv. This will
create a standard format file, encrypted with the other devices device public
key, that can be copied over and imported and decoded.
2. Use email. This will create a standard format file, encrypted with the other
devices public key, in the body of an email to send to yourself. Select 'Import
Friend Environment From Current Email' from menu on the other device.
This will update all private public keys and private private keys on the remote
device to be the same as on the source device ('master'). Any existing files
will be overwritten."
That will sync a device to a master device, but we need another option, because
life is messy. Ideally, we would have all our friending be on one device, and
then replcate that environment to other devices. But people do not always
follow such rules, and sometimes this is inconvenient or impossible.
So we also need a similar function that can copy just ONE new friend over to
other devices. So if I friend someone on my phone in a meeting, I can later
just import that one into my master.
This would work just like the above function, but would create a file with just
one name in it, in some standard format, so the importing device will know to
just append it.
Well, that's a bit awkward, isn't it? What I really want as a user is something
like
Hit sync button
See 'Select device from list'
Everything else handled automatically.
Can that be done?
The very first step, that only has to be done once - the initial device public
key exchange, pretty much has to be done the way shown. We can't have a device
just automatically grabbing anothers public key through some protocol, it would
be less secure. The user really needs to be in control of that from the device
sending the key, to be sure only his own devices are in his inner circle.
But after that...can't be done by the file method since we do not know ahead of
time how files might be transferred between two random devices.
Perhaps through email, by keeping track of state similarly to how the friending
stuff works. IF this became standardized, we would at least know that the email
program on the other end (and we don't really have control of what email
program is running on many devices, like phones) would be able to handle that
somehow.
-This is important-
A sort of 'Default Deny' standard way of creating these files and formats could
be created, but what I really feel is that having a way of exchanging a crypto
environment _that is tied to some particular 'Default Deny' standard or program
is the wrong way to go. What I WANT to use for this is standard formats for
keys, key exchanges, whole key environment exchanges, using standard methods.
That could be used by ANY program.
The difficulties here point up a real, serious flaw in the current crypto
ecosystem, I believe, which is this: there are not enough GENERIC standards for
crypto. Mostly because all this is still really new, everything seems to have
developed in isolation, each protocol or program more or less in its own world,
tied to a particular program. Often even when doing identical things, names are
different, locations are unpredictable. There are subtle differences in the way
things are done that should be the same, and standardized.
For example, consider where my email public/private keys are kept for gnupg.
They are kept in /~user/.gnupg/. They are actually in a little database,
formatted in a certain way, probably unique to gnupg.
I suppose if I used pgp, they would be in ~user/.pgp/. Probably with different
format. My ssh keys are in /~user/.ssh, not in a database, stored in a
different way. Here, even within a single application, all the private and
public keys even have different names, and are stored in a different way. And
not in a database.
id_dsa.pub
id_rsa.pub
identity.pub
Here we have some metadata in the actual name, but it is pointless, because:
# more id_dsa.pub
ssh-dss AAAAB3NzaC...
that metadata is already in the file itself.
Ssh has a list of authorized keys in 'authorized_keys'. Whatever gpupgs
equivalent is, is stored in a completely different form. Look up 'using gpg
keys for my ssh keys' in Google to see people struggling to do something that
SHOULD be simple. (Even if not, in my opinion, wise.)
Gnupg has other uses than just email, why tie all the email keys to this one
program?
Why not have a generic place for those email keys, something like
/~user/.crypto/email/publickeys/ with some kind of standard naming scheme? That
way, if a user used two different email programs, things would just work the
same. If you WANTED, for some reason, one to be different, just use
'/~user/.crypto/email/publickeys/eudora/' as an override of the default. But
that would be exceptional.
Having standards that put things in standard places with standard names and
formats makes intoperability and writing helper programs possible.
Crypto is complicated and affects security. You know what else is complicated
and affects security? Networking. Consider the difference in how the two work:
Networking:
Some expert discovers a security problem with some protocol, say 'talk'. I want
to know if I have this at all, and if is is running. What is 'talk' anyway?
Look at the standard list of services in /etc:
# grep talk /etc/services
talk 517/tcp # like tenex link
talk 517/udp
Not REAL helpful, but something.
# cryptstat
-bash: cryptstat: command not found
# man talk
NAME
talk - talk to another user
OK, fine, some sort of chat thing, port 517 service. Is it available? Is anyone
running this?
# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:submission *:* LISTEN
tcp 0 0 *:http *:* LISTEN
...
nope, so will not worry about this for now.
Crypto:
Some expert discovers a security problem with some crypto method, say '3des'. I
want to know if I have this at all, and if anyone is using it. What is '3des'
anyway? Look at the standard list of crypto methods in in /etc:
Oops, doesn't exist.
OK, well, try:
# cryptstat
-bash: cryptstat: command not found
# man 3des
No manual entry for 3des
# man des
des(3) OpenSSL
des(3)
NAME
DES_random_key, DES_set_key, DES_key_sched, DES_set_key_checked,
DES_set_key_unchecked, DES_set_odd_parity, DES_is_weak_key,
DES_ecb_encrypt,
DES_ecb2_encrypt, DES_ecb3_encrypt, DES_ncbc_encrypt, DES_cfb_encrypt,
DES_ofb_encrypt, DES_pcbc_encrypt, DES_cfb64_encrypt, DES_ofb64_encrypt,
DES_xcbc_encrypt, DES_ede2_cbc_encrypt, DES_ede2_cfb64_encrypt,
DES_ede2_ofb64_encrypt, DES_ede3_cbc_encrypt, DES_ede3_cbcm_encrypt,
DES_ede3_cfb64_encrypt, DES_ede3_ofb64_encrypt, DES_cbc_cksum,
DES_quad_cksum, DES_string_to_key, DES_string_to_2keys, DES_fcrypt,
DES_crypt, DES_enc_read, DES_enc_write - DES encryption
DESCRIPTION
This library contains a fast implementation of the DES encryption
algorithm.
Well, thank you openSSL, at least. I infer it must exist on my system somewhere
since I have a man page for it.
# cryptstat
-bash: cryptstat: command not found
Is anyone using it? Try a little wishful thinking...
# cryptstat
-bash: cryptstat: command not found
Oops, no such program. No way to easily tell if someone might be running a
serious security hazard on my system.
Not only does 'cryptstat' not exist, but it would be nearly impossible to write
one. It would have to know every single crypto program that MIGHT exist on the
system, what their formats are, how to discover what is currently seleted for
use.
IETF is all about standards and interoperability. It's time for some in this
area.
> - how do people securely backup their keys?
They get backed up when they back up their system.
They can also use the functions mentioned above to make a 'standard' crypto
environment file to share between friendly devices, which has all their own and
friends public keys, and their own private keys. Put it on a disk somewhere
safe.
In a multi-device environment, if a single device loses a disk or somethng,
they can just use the 'export to friendly device' from any of the remaining
good devices to restore everything.
> - how do people revoke keys when a device is stolen or otherwise
> compromised?
I covered this previously - if your device is stolen or hacked, it is basically
'game over'. You need to use the functions that drop all your current private
and public keys (to 'inactive' status), and create new ones, and refriend your
email contacts that use encryption. Public key cryptography depends upon
keeping your private key safe. I know of no way to change that.
As to 'revocation' - none needed (other than telling your friends to refriend
you - the 'I was Hacked' menu item could possibly do that part automatically),
because we are not using any public keyservers or Certificate Authorities
external to our own envronment. There is nothing in public to 'revoke'.
I need to be very clear about what I am doing here by NOT using that stuff: I
am deliberately sacrificing some security for usability.
The reasons for -all- that complicated keyservers and Certificate Authority
stuff are 1. The need to have public keys available for anyone who asks (we do
not need that since this is 'default deny' for all except our 'friends') and 2.
The need to establish authentication - 'are we actually talking to who we think
we are?'.
The need for an external authentication authority is to make sure there is not
a 'man in the middle' of our transaction. Specifically, in the key exchange as
I suggest it, someone COULD insert themselves in between us, get both public
keys from us, and impersonate each of us to the other. So I would think I was
emailing you my public key, but 'spook' in the middle actually gets it, and
sends you a different key, which he also has the private key for. You think you
got my key, you actually got his. He now gets an email from me, decodes it
since I encoded it with HIS public key, recodes it with your public key which
he has but you think only I have.
Protecting against this possibility causes an immense amount of extra
complexity, which is one of the things that puts people off using cryptography.
The question is, 'While theoretically possible, how likely is this in real
life'. My answer to that is: not very likely, unless you are specifically
targeted by someone powerful enough to insert themselves into someone elses
network. Most people are using large isps now, like ATT, Verizon, and they have
direct connections to each other, so in actual reality this man in the middle
has to have access to these large networks in a very deep way.
Who could do this?
A hacker? Maybe briefly, for a very small number of people. To do this to
EVERYONE would take immense amounts of money, and for what gain? They would be
pretty quickly found out.
Verizon itself, perhaps for commercial reasons? To sell ads? The cost equation
just does not work, it takes far too many resources for too little gain.
A foreign government? Maybe in specifically targeted cases. No practical return
and pretty much impossible to do for everyone, there are simply far too many
resoures needed, too much exposure, it would surely be found out quickly.
Your own government? Most of what they do is more in the line of 'taps' to get
information than man in the middle (with possible exception of https, in some
situations). It does take a lot of resources, even for a govenment. But this
has another problem in the case of email: it is very likely to be found out.
In the MITM setup I described above, remember that the man in the middle is
fooling both sides by giving them the wrong keys. So what happens if you take
your cell phone with you on vacation (to Russia, Brazil, Hong Kong, a place
with a very small isp in the country...) and use another network to connect?
Well, that network had better be MITM'd too , because if it is not, you and
your friend will not be able to read each others email, because you both do not
have each others keys, you have the man in the middle's keys. You will know by
this that you are compromised.
This is also defeated by exchanging keys manually, or even by something so easy
as checking through another channel, for example, call up your friend and tell
him to start reading what he thinks is your public key out loud. It had better
match what you see...
It makes little sense for a government to try to MITM every single possible
path for every single person, in every possible circumstance, something that is
not practically possible, to do something so easily found out, and of limited
value.
Even if I went the other way, and forced everyone to use a complex system, buy
personal certificates from a CA, what would be gained? Apparently they have the
private keys of the CAs already, and can still game this.
Key-signing by multiple people as used for pgp still useful, and still can be
used as desired.
One thing I left out of the key exchange is that of course, while the initial
emails are not encrypted, they should still be signed, and by the 'private'
private key which can be later checked after the friend has obtained it. That
may help some.
What the user gains from this is ease of use, less spam, privacy protection
from most bad actors reading your mail, and protection from generic, automated,
mass 'fishing expeditions' of the type that create a lot of false positives -
so you don't get put on a 'watch list' for talking about pressure cookers. Or a
couple actors for talking about 'making a bomb' after watching 'The Producers'.
This is all about 'reasonable privacy' not 'perfect security'. It is like
deciding to have a private conversation with someone by walking outside your
house. Yes, someone COULD be using a parbolic microphone from a half mile away
to pick it up and record it. Still, I see no need to build a solid concrete
soundproof blockhouse just to keep old Aunt Biddie from being shocked by what
the young folk are talking about.
-Mike
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
