Discussion:
Suggestion: Determistic key generation option for completely read-only systems
(too old to reply)
Sebastian Nielsen
2018-07-14 13:58:01 UTC
Permalink
I have a suggestion for tails, that will make it more useful for the masses,
and still having it completely read-only.



And that is having, when the Tails OS starts up, there will be a password
prompt.



This password prompt will accept any password. This passsword is then used
with PBKDF2 key strengtening to create a ”master key”. Then this ”master
key” is SHA512’d concatenated with a counter, creating a CSPRNG stream.
(with a 32 bit counter there will be exactly 2 TB of randomness before it
start to repeat)

(ergo: the first 512 bits is: Sha512( PBKDF2(password) + 0 ) , second 512
bits = Sha512( PBKDF2(password) + 1 ), and so on).



Then this CSPRNG stream is then used to create a PGP key, then a bitcoin
keypair (with adress and such), then a Tor keypair, and then a few other
keys, certificates and such needed for the system. Of course this should not
be fed into /dev/random, instead other ways is needed to correctly inject
this randomness in the key generation functions for OpenPGP and such.



Of course, 2 different users starting up Tails and entering the identical
password will of course get the same PGP key, same bitcoin keypair and such.



But the main advantage is that you don’t need to store anything. Even if
your Tails installation media is seized, nothing can happen. You have your
password, thats all that is needed to recreate ”your” installation of Tails.

Of course, the user needs to select a secure password.



This also means any single tails installation media can be used by unlimited
users. And that would also make it more interesting for internet cafés and
such to install Tails on their public computers, since tails then become
completely read-only but still users can get their PGP keys, bitcoin keys,
and TOR keys and other keys by simply logging in with the password they
chose when first starting to use tails at home.



Best regards, Sebastian Nielsen
Andrew Gallagher
2018-07-14 19:59:23 UTC
Permalink
This also means any single tails installation media can be used by unlimited users. And that would also make it more interesting for internet cafés and such to install Tails on their public computers, since tails then become completely read-only but still users can get their PGP keys, bitcoin keys, and TOR keys and other keys by simply logging in with the password they chose when first starting to use tails at home.
The entire point of Tails is to have a secure, trustable OS. This is completely incompatible in principle with internet cafes. While it may be possible for an internet cafe to provide tails based machines, nobody concerned about their data security should ever use such an instance.

A
Sebastian Nielsen
2018-07-14 20:22:36 UTC
Permalink
Yes, I agree about it. It was just a usage example on how it could become more ”universal”. You could also for example borrow a trusted friend’s Tails installation and just use with your password for example.



Från: Tails-dev <tails-dev-***@boum.org> För Andrew Gallagher
Skickat: den 14 juli 2018 22:09
Till: The Tails public development discussion list <tails-***@boum.org>
Ämne: Re: [Tails-dev] Suggestion: Determistic key generation option for completely read-only systems





On 14 Jul 2018, at 14:58, Sebastian Nielsen <***@sebbe.eu <mailto:***@sebbe.eu> > wrote:

This also means any single tails installation media can be used by unlimited users. And that would also make it more interesting for internet cafés and such to install Tails on their public computers, since tails then become completely read-only but still users can get their PGP keys, bitcoin keys, and TOR keys and other keys by simply logging in with the password they chose when first starting to use tails at home.



The entire point of Tails is to have a secure, trustable OS. This is completely incompatible in principle with internet cafes. While it may be possible for an internet cafe to provide tails based machines, nobody concerned about their data security should ever use such an instance.



A
s7r
2018-07-15 12:40:29 UTC
Permalink
Hello,
Post by Sebastian Nielsen
I have a suggestion for tails, that will make it more useful for the
masses, and still having it completely read-only.
 
And that is having, when the Tails OS starts up, there will be a
password prompt.
 
This password prompt will accept any password. This passsword is then
used with PBKDF2 key strengtening to create a ”master key”. Then this
”master key” is SHA512’d concatenated with a counter, creating a CSPRNG
stream. (with a 32 bit counter there will be exactly 2 TB of randomness
before it start to repeat)
(ergo: the first 512 bits is: Sha512( PBKDF2(password) + 0 ) , second
512 bits = Sha512( PBKDF2(password) + 1 ), and so on).
 
Then this CSPRNG stream is then used to create a PGP key, then a bitcoin
keypair (with adress and such), then a Tor keypair, and then a few other
keys, certificates and such needed for the system. Of course this should
not be fed into /dev/random, instead other ways is needed to correctly
inject this randomness in the key generation functions for OpenPGP and such.
 
Of course, 2 different users starting up Tails and entering the
identical password will of course get the same PGP key, same bitcoin
keypair and such.
This is not entirely true. You cannot generate PGP RSA keys this way,
only ECC keys maybe (because the password might represent the point on
the curve to regenerate the same key). Also the anatomy of a PGP key is
not that simple. Basically in order to have the same PGP key it needs to
have the same fingerprint, and the fingerprint doesn't just hash the
key, it also includes the timestamp of creation, UID, expiration date,
etc. And by design it should also have an ENCRYPTION subkey that has the
same variables which might or might not be the same with the primary key
ones.

It's not simple for average users to enter these details at every boot,
and it's very easy to mess it up and break stuff -- we should not
recommend this practice. There is a reason why there's no "restore from
seed / passphrase" option in GnuPG itself.

For SSH keys used to authenticate to servers or sign commits, if they
are RSA (which are the most common used) this will not work as well. It
might work for EdDSA / Ed25519 but AFAIK deterministic generation of
Ed25519 from passphrase / seed doesn't exist in any implementation
currently, yet I don't see a reason why it couldn't be done.

For Bitcoin this is unnecessary, as this is already supported. You can
use Electrum wallet which is included in Tails and restore your wallet
from seed every time you boot, ensuring everything remains the same by
following a protocol standard widely tested and used. You are also not
forced to use a 'seed' (string of 12 words or so) - you can have your
own passphrase and when restoring the wallet instead of entering the
string of words just paste the sha256(passphrase) and you'll have the
same wallet. This is not bad and does not have any security flow,
except users choosing a weak passphrase which is why the GUI doesn't
explicitly tell you how to do this, but it allows you if you really want
to and know what you are doing. We should always assume that regular
users are inclined to use weak passwords and try to defend them from
that by at least not making it explicit: "hey you can enter 1234 here as
password easy to remember and you'll have a wallet".
Post by Sebastian Nielsen
But the main advantage is that you don’t need to store anything. Even if
your Tails installation media is seized, nothing can happen. You have
your password, thats all that is needed to recreate ”your” installation
of Tails.
Of course, the user needs to select a secure password.
 
This also means any single tails installation media can be used by
unlimited users. And that would also make it more interesting for
internet cafés and such to install Tails on their public computers,
since tails then become completely read-only but still users can get
their PGP keys, bitcoin keys, and TOR keys and other keys by simply
logging in with the password they chose when first starting to use tails
at home.
Earlier I addressed Bitcoin keys, PGP keys and SSH keys. I am not sure
what you mean by Tor keys?

Tails uses Tor in client mode (not relay mode) so there is no Tor keys
to back up at all. You don't need anything. What would Tails need is a
way to have the same Guard at every reboot for a limited guard lifetime,
but this is a whole other topic and there are some ideas on the
blueprint -- not an easy task. There are 0 reasons to run a relay on
Tails (it would also be a huge PITA) so I won't discuss relay keys.

Other than that, there is nothing in a Tor install that would be needed
on every reboot. There are no keys, unless you are talking about onion
service keys. If you are talking about onion service keys, Tails is not
intended to be a server operating system (people that want to run onion
services hosted should be using whonix / qubes-os or other server
oriented stuff).

Even if one would want to do onion service hosting on Tails and use it
as a server operating system, the feature we are discussing here still
won't work:

a) v2 onion services use RSA 1024 keys. As I said above for PGP and SSH
keys, RSA can't be regenerated from a passphrase.

b) v3 onion services use Ed25519 keys. They were explicitly coded to
support offline master key, so Tails should aim to let this feature be
properly implemented upstream (in Tor). I am sure after this is
implemented Tor will allow neat stuff like restoring your onion service
from a string of words, or passphrase, because with ECC it's possible
with relatively low risks given enough entropy.


I am sorry about the "won't work" arguments, but as I see it this will
complicate things for users, leave more attack surface and place for
mistakes from average users this degrading their security level
considerably, with no actual real benefit.

I can see you have some knowledge in this field, so instead let me point
you in a direction that would be really useful.

Please help us with this:
https://tails.boum.org/blueprint/persistent_Tor_state/

See what is the current plan, drawbacks and discarded ideas and help in
taking the best decision here.

-s7r
Sebastian Nielsen
2018-07-15 13:31:11 UTC
Permalink
Of course I know that you cannot directly use a random number R to generate
a OpenPGP or RSA key.
But there is a function such as x,y = f(R) where R is a random number (then
usually taken from /dev/random) and x is a public key and y is a private
key.

And the function f() does "generate" the key. If R is identical from 2 runs,
then the same RSA keypair will came out.

About timestamp, uid and expiration date. Uid could be a username input
(Username/password login) while timestamp could be fixed, and no expiration
date.


About bitcoin, I know these clients and keys exist. My idea was just to
implement it as a user-friendly package into tails so you can "boot from a
seed" and get everything restored from seed.

-----Ursprungligt meddelande-----
Från: Tails-dev <tails-dev-***@boum.org> För s7r
Skickat: den 15 juli 2018 14:41
Till: tails-***@boum.org
Ämne: Re: [Tails-dev] Suggestion: Determistic key generation option for
completely read-only systems

Hello,
Post by Sebastian Nielsen
I have a suggestion for tails, that will make it more useful for the
masses, and still having it completely read-only.
 
And that is having, when the Tails OS starts up, there will be a
password prompt.
 
This password prompt will accept any password. This passsword is then
used with PBKDF2 key strengtening to create a ”master key”. Then this
”master key” is SHA512’d concatenated with a counter, creating a CSPRNG
stream. (with a 32 bit counter there will be exactly 2 TB of randomness
before it start to repeat)
(ergo: the first 512 bits is: Sha512( PBKDF2(password) + 0 ) , second
512 bits = Sha512( PBKDF2(password) + 1 ), and so on).
 
Then this CSPRNG stream is then used to create a PGP key, then a bitcoin
keypair (with adress and such), then a Tor keypair, and then a few other
keys, certificates and such needed for the system. Of course this should
not be fed into /dev/random, instead other ways is needed to correctly
inject this randomness in the key generation functions for OpenPGP and such.
 
Of course, 2 different users starting up Tails and entering the
identical password will of course get the same PGP key, same bitcoin
keypair and such.
This is not entirely true. You cannot generate PGP RSA keys this way,
only ECC keys maybe (because the password might represent the point on
the curve to regenerate the same key). Also the anatomy of a PGP key is
not that simple. Basically in order to have the same PGP key it needs to
have the same fingerprint, and the fingerprint doesn't just hash the
key, it also includes the timestamp of creation, UID, expiration date,
etc. And by design it should also have an ENCRYPTION subkey that has the
same variables which might or might not be the same with the primary key
ones.

It's not simple for average users to enter these details at every boot,
and it's very easy to mess it up and break stuff -- we should not
recommend this practice. There is a reason why there's no "restore from
seed / passphrase" option in GnuPG itself.

For SSH keys used to authenticate to servers or sign commits, if they
are RSA (which are the most common used) this will not work as well. It
might work for EdDSA / Ed25519 but AFAIK deterministic generation of
Ed25519 from passphrase / seed doesn't exist in any implementation
currently, yet I don't see a reason why it couldn't be done.

For Bitcoin this is unnecessary, as this is already supported. You can
use Electrum wallet which is included in Tails and restore your wallet
from seed every time you boot, ensuring everything remains the same by
following a protocol standard widely tested and used. You are also not
forced to use a 'seed' (string of 12 words or so) - you can have your
own passphrase and when restoring the wallet instead of entering the
string of words just paste the sha256(passphrase) and you'll have the
same wallet. This is not bad and does not have any security flow,
except users choosing a weak passphrase which is why the GUI doesn't
explicitly tell you how to do this, but it allows you if you really want
to and know what you are doing. We should always assume that regular
users are inclined to use weak passwords and try to defend them from
that by at least not making it explicit: "hey you can enter 1234 here as
password easy to remember and you'll have a wallet".
Post by Sebastian Nielsen
But the main advantage is that you don’t need to store anything. Even if
your Tails installation media is seized, nothing can happen. You have
your password, thats all that is needed to recreate ”your” installation
of Tails.
Of course, the user needs to select a secure password.
 
This also means any single tails installation media can be used by
unlimited users. And that would also make it more interesting for
internet cafés and such to install Tails on their public computers,
since tails then become completely read-only but still users can get
their PGP keys, bitcoin keys, and TOR keys and other keys by simply
logging in with the password they chose when first starting to use tails
at home.
Earlier I addressed Bitcoin keys, PGP keys and SSH keys. I am not sure
what you mean by Tor keys?

Tails uses Tor in client mode (not relay mode) so there is no Tor keys
to back up at all. You don't need anything. What would Tails need is a
way to have the same Guard at every reboot for a limited guard lifetime,
but this is a whole other topic and there are some ideas on the
blueprint -- not an easy task. There are 0 reasons to run a relay on
Tails (it would also be a huge PITA) so I won't discuss relay keys.

Other than that, there is nothing in a Tor install that would be needed
on every reboot. There are no keys, unless you are talking about onion
service keys. If you are talking about onion service keys, Tails is not
intended to be a server operating system (people that want to run onion
services hosted should be using whonix / qubes-os or other server
oriented stuff).

Even if one would want to do onion service hosting on Tails and use it
as a server operating system, the feature we are discussing here still
won't work:

a) v2 onion services use RSA 1024 keys. As I said above for PGP and SSH
keys, RSA can't be regenerated from a passphrase.

b) v3 onion services use Ed25519 keys. They were explicitly coded to
support offline master key, so Tails should aim to let this feature be
properly implemented upstream (in Tor). I am sure after this is
implemented Tor will allow neat stuff like restoring your onion service
from a string of words, or passphrase, because with ECC it's possible
with relatively low risks given enough entropy.


I am sorry about the "won't work" arguments, but as I see it this will
complicate things for users, leave more attack surface and place for
mistakes from average users this degrading their security level
considerably, with no actual real benefit.

I can see you have some knowledge in this field, so instead let me point
you in a direction that would be really useful.

Please help us with this:
https://tails.boum.org/blueprint/persistent_Tor_state/

See what is the current plan, drawbacks and discarded ideas and help in
taking the best decision here.

-s7r
sajolida
2018-07-19 18:38:00 UTC
Permalink
Post by Sebastian Nielsen
I have a suggestion for tails, that will make it more useful for the masses,
and still having it completely read-only.
Hi Sebastian!

Thanks for taking the time to make suggestions on how to improve Tails
for the masses. That's what we want :)
Post by Sebastian Nielsen
But the main advantage is that you don’t need to store anything. Even if
your Tails installation media is seized, nothing can happen. You have your
password, thats all that is needed to recreate ”your” installation of Tails.
Other consequences:

- Two people using the same password would have the same cryptographic
key. Unfortunately, different people use the same password all the
time.

To have secure (unique) seeds you would have to imposed something very
long that people wouldn't be able to memorize. See the seeds in
Electrum for example.

- You wouldn't be able to destroy your cryptographic key or revoke it.

Plus, ask s7r pointed out, this might not really work for OpenPGP.

This seed scheme might be useful in some cryptographic applications
(like Electrum) but unfortunately, I don't think it's would work for all
the crypto used in Tails.
--
sajolida
u
2018-07-25 03:49:00 UTC
Permalink
Hi Sebastian,
Post by Sebastian Nielsen
And that is having, when the Tails OS starts up, there will be a password
prompt.
What problem would your solution solve?

I often see in nerd communities a strong capacity for problem solving,
but often people find solutions before actually having a problem
defintion. In order to understand how useful such a solution might be,
maybe you could give a bit more background information on your thoughts?

Cheers!
u.
Sebastian Nielsen
2018-07-25 03:52:40 UTC
Permalink
The problem it would solve, is that you can avoid having a persistent
partition alltogether, but still allow users to be able to use PGP
encryption and SSH keys and similiar. By simply determisticly generating
them out of a password that user enters on startup.

-----Ursprungligt meddelande-----
Från: u <***@451f.org>
Skickat: den 25 juli 2018 05:50
Till: The Tails public development discussion list <tails-***@boum.org>;
Sebastian Nielsen <***@sebbe.eu>
Ämne: Re: [Tails-dev] Suggestion: Determistic key generation option for
completely read-only systems

Hi Sebastian,
Post by Sebastian Nielsen
And that is having, when the Tails OS starts up, there will be a password
prompt.
What problem would your solution solve?

I often see in nerd communities a strong capacity for problem solving,
but often people find solutions before actually having a problem
defintion. In order to understand how useful such a solution might be,
maybe you could give a bit more background information on your thoughts?

Cheers!
u.
Daniel Kahn Gillmor
2018-07-26 14:32:58 UTC
Permalink
Post by Sebastian Nielsen
The problem it would solve, is that you can avoid having a persistent
partition alltogether, but still allow users to be able to use PGP
encryption and SSH keys and similiar. By simply determisticly generating
them out of a password that user enters on startup.
This has a range of potential downsides that other people have already
pointed out (passphrase reuse means duplicate keys, impossibility of
changing keys, etc). Additionally, just generating keys from this
passphrase doesn' obviate the need for an encrypted persistent volume
for some users; some users are actually storing data that they care
about (photos, documents, etc) in the persistent volume, and that data
cannot be generated from the passphrase.

It's not clear to me that the benefit is worth the risks here, but if
you wanted to do something like this for Tails, the right approach would
be to make it work generally, as a straightforward, well-engineered
piece of software (for a project like this, user experience and system
integration seem like critical features). Get that software into
debian, and then ask for its inclusion in Tails.

This isn't a short process -- to do something like this right takes a
lot of work and persistence! And in the course of developing it and
interacting with real users, you might find yourself with new ideas
about what would be useful, either cryptographically or from a UI/UX
perspective. But by all means, please do work on it -- we need more
experimentation and exploration in this area.

--dkg

Loading...