Mailing List Archive

Storing key on multiple smartcards
(This went wrong! For some reason, gnupg-devel had dropped from the
recipients while I was writing the message. I must have accidentally
pressed some key or mouse button. I noticed this and added
gnupg-users to the recipients instead of the intended gnupg-devel. Here
is the message again on the right list)

I agree that GnuPG would benefit from preferring keys that are
available, both in the sense of different subkeys and different
smartcards with copies of the same subkey, in the sense you describe.
But let me pick out one detail you mentioned that is a different issue.

On 10/04/2019 09:38, Frederick Zhang via Gnupg-devel wrote:
> Currently "keytocard" replaces the keygrip with a shadow key (which I
> don't think works pretty intuitively in case of multiple smart cards,
> as it requires users to manually back up the subkey beforehand to
> transfer the same key to multiple cards)

It's less difficult than that. After a "keytocard", simply exit the
--edit-key interaction without saving, and the key will still be
on disk as well. So use "quit" or Ctrl-D rather than "save", and
confirm that you wish to exit without saving changes.

Not really intuitive, but less bothersome than backups and restores. I
think maybe "keytocard" should have an option to just leave it on disk
as well. And then you can just insert all your smartcards you want the
key on and "keytocard" them one after the other without exiting the
--edit-key menu.

HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
Re: Storing key on multiple smartcards [ In reply to ]
Well, while it's good to know that keytocard does not update the file
immediately, I genuinely didn't expect that keytocard would replace the
keygrip in the first place (although it's clearly stated in man page,
yeah, lazy me :P). No idea whether I'm the one who's got a weird
mindset, I believed it meant "copying the key to a smart card and store
some metadata about the card somewhere else" without the slightest
doubt. I actually kinda want to blame the setup instruction from Yubico
<https://support.yubico.com/support/solutions/articles/15000006420>.
They suggest having a backup card but mentioned absolutely nothing about
the behaviour of keytocard, and it clearly says "enter y (yes)" to save
the changes after "quit"... Only when I was to copy the same keys to the
backup card after done configuring the primary one, I realised I may
have screwed up. Thank goodness I backed up the keys when I started
using GPG, but the authentication keys I generated during the setup are
never gonna settle themselves in a different nest :'(

So I strongly agree keytocard should, even by default, leave the
originals untouched, and perhaps instruct users to move the keygrip to a
safe place afterwards.

On 10/4/19 7:55 pm, Peter Lebbing wrote:
> (This went wrong! For some reason, gnupg-devel had dropped from the
> recipients while I was writing the message. I must have accidentally
> pressed some key or mouse button. I noticed this and added
> gnupg-users to the recipients instead of the intended gnupg-devel. Here
> is the message again on the right list)
>
> I agree that GnuPG would benefit from preferring keys that are
> available, both in the sense of different subkeys and different
> smartcards with copies of the same subkey, in the sense you describe.
> But let me pick out one detail you mentioned that is a different issue.
>
> On 10/04/2019 09:38, Frederick Zhang via Gnupg-devel wrote:
>> Currently "keytocard" replaces the keygrip with a shadow key (which I
>> don't think works pretty intuitively in case of multiple smart cards,
>> as it requires users to manually back up the subkey beforehand to
>> transfer the same key to multiple cards)
>
> It's less difficult than that. After a "keytocard", simply exit the
> --edit-key interaction without saving, and the key will still be
> on disk as well. So use "quit" or Ctrl-D rather than "save", and
> confirm that you wish to exit without saving changes.
>
> Not really intuitive, but less bothersome than backups and restores. I
> think maybe "keytocard" should have an option to just leave it on disk
> as well. And then you can just insert all your smartcards you want the
> key on and "keytocard" them one after the other without exiting the
> --edit-key menu.
>
> HTH,
>
> Peter.
>

--
Best Regards,
Frederick Zhang

Email: frederick888@tsundere.moe
Re: Storing key on multiple smartcards [ In reply to ]
On 10/04/2019 16:22, Frederick Zhang wrote:
> So I strongly agree keytocard should, even by default, leave the
> originals untouched, and perhaps instruct users to move the keygrip to a
> safe place afterwards.

People move their keys to a card because they do not want the key to be
on disk for whatever reason. Leaving them on the disk by default might
be surprising to them and potentially harmful.

I'd rather propose that the default is that "keytocard" shows a warning
message:

| Warning: moving the key to card will remove it from disk. It is not
| possible to get the private key out of the card again. If this is not
| what is intended, supply the '--keep' option to 'keytocard' to keep the
| key stored on disk as well. Continue? (y/N)

And obviously that option needs to be implemented as well. This is just
a first setup for the precise message to convey my intention.

Everybody should have a backup of their encryption key, but still,
throwing it away when the user might not expect it on 'keytocard' might
be a bad idea (this is what we do now!). Primary keys are not quite as
bad as that, but still.

HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
Re: Storing key on multiple smartcards [ In reply to ]
Hi NIIBE,

May I know what your thoughts are on this issue? I understand my changes
to finish_lookup seem to have some unnecessary impacts on other logic,
e.g. public key query, so maybe we should tweak the current
build_sk_list to detect smart cards regardless of locusr?

And what did you think of my "different keygrips for different cards"
solution for the "same subkey on multiple cards" problem? Did it sound
good to you?

By the way, I reckon Peter has made some solid points about the warning
message and the additional option for keytocard command. Do you think we
should get this implemented first?

On 11/4/19 12:42 am, Peter Lebbing wrote:
> On 10/04/2019 16:22, Frederick Zhang wrote:
>> So I strongly agree keytocard should, even by default, leave the
>> originals untouched, and perhaps instruct users to move the keygrip to a
>> safe place afterwards.
>
> People move their keys to a card because they do not want the key to be
> on disk for whatever reason. Leaving them on the disk by default might
> be surprising to them and potentially harmful.
>
> I'd rather propose that the default is that "keytocard" shows a warning
> message:
>
> | Warning: moving the key to card will remove it from disk. It is not
> | possible to get the private key out of the card again. If this is not
> | what is intended, supply the '--keep' option to 'keytocard' to keep the
> | key stored on disk as well. Continue? (y/N)
>
> And obviously that option needs to be implemented as well. This is just
> a first setup for the precise message to convey my intention.
>
> Everybody should have a backup of their encryption key, but still,
> throwing it away when the user might not expect it on 'keytocard' might
> be a bad idea (this is what we do now!). Primary keys are not quite as
> bad as that, but still.
>
> HTH,
>
> Peter.
>

--
Best Regards,
Frederick Zhang

Email: frederick888@tsundere.moe
Re: Storing key on multiple smartcards [ In reply to ]
Hello,

I was not able to catch up, because I didn't receive Peter's two
messages on April 10th, for some reason. I am reading those messages in
the archive.

Frederick Zhang <frederick888@tsundere.moe> wrote:
> May I know what your thoughts are on this issue? I understand my changes
> to finish_lookup seem to have some unnecessary impacts on other logic,
> e.g. public key query, so maybe we should tweak the current
> build_sk_list to detect smart cards regardless of locusr?
>
> And what did you think of my "different keygrips for different cards"
> solution for the "same subkey on multiple cards" problem? Did it sound
> good to you?
>
> By the way, I reckon Peter has made some solid points about the warning
> message and the additional option for keytocard command. Do you think we
> should get this implemented first?

Sorry, I can't understand how your patch solves your particular problem.
Let me focus on "same subkey on multiple cards" problem.

IIUC, it is related to how we can consider an identity of a card and how
we manage its raw key materials inside. (I think that it is more than
"UI improvement" issue.)

There is an assumption in the current implementation of gpg-agent, a key
material can be on disk or in a single card.

Our discussion is how we can relax this assumption.

Once, I had a practice to have multiple cards with same serial number,
so that I worked around the situation like you. Obviously, this
violates an assumption (perhaps, very important one), of smartcard
administration. At least, it can't be recommended.

Perhaps, better approach would be using a serial number only as a hint,
extending keygrip-centric approach of gpg-agent. It would be good to
administrate the hint information editable by user. Showing the serial
number to ask insertion of a card... is not helpful so much to a user.
It is more helpful when a user can name the card by some nickname.

For warning message at keytocard command, I think that Peter's
suggestion makes sense, but please don't mix separate things. It is
related somehow, but I think it is better to be handled seperately.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Storing key on multiple smartcards [ In reply to ]
> Sorry, I can't understand how your patch solves your particular
> problem.

There are 2 issues in my case:

1. When `-u` is given, GPG selects the latest secret subkey from those
which have the desired capability, but keys that can be found on disk or
in a currently accessible smart card should actually be preferred.
2. The current shadow key mechanism does not allow the same subkey to be
stored on disk and/or one or more smart cards at the same time.

My patch fixes only the first one (partially). It prioritises the secret
subkey which is stored in the smart card that's being used right now
among all those that can reach
<https://dev.gnupg.org/source/gnupg/browse/master/g10/getkey.c;dc93e57226db32d5b90884dcf768d271baa6628a$3517>.

> Perhaps, better approach would be using a serial number only as a
> hint, extending keygrip-centric approach of gpg-agent.

That sounds great! I was thinking that working around the current shadow
key logic might require fewer changes but removing serial numbers from
shadow keys is indeed better. If the serial numbers can be saved in
plain text files, not only the duplicate data across shadow keys in my
proposal can be avoided, it will also allow users to easily manage the
info and store additional metadata like nicknames as you mentioned.

> For warning message at keytocard command, I think that Peter's
> suggestion makes sense, but please don't mix separate things. It is
> related somehow, but I think it is better to be handled seperately.

Sure. This is something that we can get out of the door quickly and it's
not influenced by the other 2 problems. Do you want me to start another
thread to nail down the wording?

Peter also mentioned a new option for the keytocard command which allows
users to keep the keygrip untouched after transferring the secret key to
a smart card. Shall we move the discussion about this to the new thread
as well?

--
Best Regards,
Frederick Zhang

Email: frederick888@tsundere.moe
Re: Storing key on multiple smartcards [ In reply to ]
Frederick Zhang <frederick888@tsundere.moe> wrote:
> That sounds great! I was thinking that working around the current shadow
> key logic might require fewer changes but removing serial numbers from
> shadow keys is indeed better.

Let me share some technical detail of GnuPG internal.

My plan (in master, towards 2.3) is:

(1) gpg-agent shadow key protocol fix/modification

Now, gpg-agent assumes one private key material resides in a single
smartcard. This restriction should be relaxed.

While current flow from gpg-agent to scdaemon is:

gpg-agent
|
keygrip -> private key file -> shadow-info -> serial number + id_string
|
V
scdaemon

It should be possible, directly using keygrip to scdaemon:

gpg-agent
|
keygrip
|
V
scdaemon

Then, we don't need the serial number as shadow-info in private key file.

I think that this direct use of keygrip will simplify things in GnuPG.

Besides, current protocol in use is named "t1-v1", which is typo.


(2) scdaemon modification

Now, the way to specify a key is:

serial number + id_string

or

serial number + "/" + fingerprint

where id_string is "OpenPGP.1", "OpenPGP.2", and "OpenPGP.3".

I'd like to extend it using a keygrip to specify a key.



Once, those modifications will be done, it's more straightforward to
support different use cases with smartcard. (Or, those modifications
themselves will solve some existing issues automatically.)

Some use cases will still remain. Some day, I'd like to support a use
case where signing+encryption is done naturally. That is, signing with
a signing key on inserted smartcard and encryption for a encryption key
on that card.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Storing key on multiple smartcards [ In reply to ]
NIIBE Yutaka <gniibe@fsij.org> wrote:
> (2) scdaemon modification

I have started this part in master.

> Now, the way to specify a key is:
>
> serial number + id_string
>
> or
>
> serial number + "/" + fingerprint
>
> where id_string is "OpenPGP.1", "OpenPGP.2", and "OpenPGP.3".

Sorry, the description above is not correct. It is either:

id_string
serial number
serial number + "/" + fingerprint

I pushed the change supporting keygrip here.

Matching card with the serial number should be selected beforehand, when
the PKSIGN, PKDECRYPT or PKAUTH commands are used. Note that scdaemon
has support of having multiple cards (by internal CCID driver), a card
is selected by the SERIALNO command.

gpg-agent uses the sequence of SERIALNO and then
PKSIGN/PKDECRYPT/PKAUTH with the context of serial number.

We need a way to ask crypto operations with no-context-of-serial-number
(the specific card) but with the keygrip.

For crypto operations with the keygrip, I'm going to add new commands to
scdaemon:

KEYINFO [--list]
PKSIGN_DIRECT
PKDECRYPT_DIRECT
PKAUTH_DIRECT

(Perhaps, there are better names for PKSIGN_DIRECT, PKDECRYPT_DIRECT,
and PKAUTH_DIRECT. Please let me know your comments.)

The KEYINFO command is just like the one of gpg-agent. It gives us
key information with keygrips.

gpg-agent/gpg will use scdaemon's KEYINFO command to get the information
of available keys by scdaemon. Then, do *_DIRECT.

The *_DIRECT commands are not with a specific card context, scdaemon
internally selects a card context automatically. It is scdaemon which
determines card context by keygrip,

This is the thing I call keygrip-centric.

I'm going add KEYINFO to master this week.

Since I'm not that confident yet, for *_DIRECT, I will have a topic
branch, in next month. Then, merge into master.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Storing key on multiple smartcards [ In reply to ]
On Mon, 22 Apr 2019 13:43, gniibe@fsij.org said:

> Then, we don't need the serial number as shadow-info in private key file.

The information is also used to prompt the user to insert a specific
card. The serial number is a good way to identify a card because it is
printed onto the card. However some configurable way to name a card is
also useful.

I am currently working on recording all serial numbers used with a token
based key in the shadow key info file. The new format allows easy
manual editing of that info and also allows to put a "Label:" line into
the the file to be prompted with e.g. "The green token on my keyring".


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Storing key on multiple smartcards [ In reply to ]
On Fri, May 03, 2019 at 04:26:23PM +0200, Werner Koch wrote:
> On Mon, 22 Apr 2019 13:43, gniibe@fsij.org said:
>
> > Then, we don't need the serial number as shadow-info in private key file.
>
> The information is also used to prompt the user to insert a specific
> card. The serial number is a good way to identify a card because it is
> printed onto the card. However some configurable way to name a card is
> also useful.
It's NOT always printed on cards. I have multiple NitroKey Pro units,
and aside from my own labelling, there are no unit-specific identifiers
on the units themselves, or even on the internal cards.

Consider me entirely in favour of being able to specify an arbitrary
label.

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Re: Storing key on multiple smartcards [ In reply to ]
Hello,

I merged the scdaemon change of mine to master. Now,
PKSIGN/PKAUTH/PKDECRYPT command can be used with KEYGRIP directly, and
it is scdaemon which selects card (among possibly multiple cards).

Werner Koch <wk@gnupg.org> wrote:
> The information is also used to prompt the user to insert a specific
> card. The serial number is a good way to identify a card because it is
> printed onto the card. However some configurable way to name a card is
> also useful.
>
> I am currently working on recording all serial numbers used with a token
> based key in the shadow key info file. The new format allows easy
> manual editing of that info and also allows to put a "Label:" line into
> the the file to be prompted with e.g. "The green token on my keyring".

Yes. Support of label (and serial number) is orthogonal to ongoing
change of mine.

* * *

My plan to change gpg-agent is: By gpg-agent's offering private key
information in a better way, gpg frontend can be modified to select
a key easier (so that user can have better UI).

Now, gpg-agent KEYINFO command is like this:

# KEYINFO [--[ssh-]list] [--data] [--ssh-fpr[=algo]] [--with-ssh] <keygrip>
#
# Return information about the key specified by the KEYGRIP. If the
# key is not available GPG_ERR_NOT_FOUND is returned. If the option
# --list is given the keygrip is ignored and information about all
# available keys are returned. If --ssh-list is given information
# about all keys listed in the sshcontrol are returned. With --with-ssh
# information from sshcontrol is always added to the info. Unless --data
# is given, the information is returned as a status line using the format:
#
# KEYINFO <keygrip> <type> <serialno> <idstr> <cached> <protection> <fpr>
#
# KEYGRIP is the keygrip.
#
# TYPE is describes the type of the key:
# 'D' - Regular key stored on disk,
# 'T' - Key is stored on a smartcard (token),
# 'X' - Unknown type,
# '-' - Key is missing.
#
# SERIALNO is an ASCII string with the serial number of the
# smartcard. If the serial number is not known a single
# dash '-' is used instead.
#
# IDSTR is the IDSTR used to distinguish keys on a smartcard. If it
# is not known a dash is used instead.
#
# CACHED is 1 if the passphrase for the key was found in the key cache.
# If not, a '-' is used instead.
#
# PROTECTION describes the key protection type:
# 'P' - The key is protected with a passphrase,
# 'C' - The key is not protected,
# '-' - Unknown protection.
#
# FPR returns the formatted ssh-style fingerprint of the key. It is only
# printed if the option --ssh-fpr has been used. If ALGO is not given
# to that option the default ssh fingerprint algo is used. Without the
# option a '-' is printed.
#
# TTL is the TTL in seconds for that key or '-' if n/a.
#
# FLAGS is a word consisting of one-letter flags:
# 'D' - The key has been disabled,
# 'S' - The key is listed in sshcontrol (requires --with-ssh),
# 'c' - Use of the key needs to be confirmed,
# '-' - No flags given.
#
# More information may be added in the future.

I'm going to modify this, to distinguish a key on card which is
inserted, and a key on card which is not inserted. This can be either:

(1) For key on inserted card, add another flag into FLAGS (say, 'A' for
active),

or

(2) Introduce new TYPE (say, 'O' for offline) and change the semantics
of 'T' meaning inserted card.


Currently, both of gpg frontend and gpg-agent need to have code of loop
for enumerating active cards. Using KEYINFO command of scdaemon,
gpg-agent can merge card key information and disk key information.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Storing key on multiple smartcards [ In reply to ]
On Tue, 7 May 2019 10:21, gniibe@fsij.org said:

> # TYPE is describes the type of the key:
> # 'D' - Regular key stored on disk,
> # 'T' - Key is stored on a smartcard (token),
> # 'X' - Unknown type,
> # '-' - Key is missing.
> #
> # SERIALNO is an ASCII string with the serial number of the
> # smartcard. If the serial number is not known a single
> # dash '-' is used instead.
> #
> # IDSTR is the IDSTR used to distinguish keys on a smartcard. If it
> # is not known a dash is used instead.
> #
> # CACHED is 1 if the passphrase for the key was found in the key cache.
> # If not, a '-' is used instead.
> #
> # PROTECTION describes the key protection type:
> # 'P' - The key is protected with a passphrase,
> # 'C' - The key is not protected,
> # '-' - Unknown protection.
> #
> # FPR returns the formatted ssh-style fingerprint of the key. It is only
> # printed if the option --ssh-fpr has been used. If ALGO is not given
> # to that option the default ssh fingerprint algo is used. Without the
> # option a '-' is printed.
> #
> # TTL is the TTL in seconds for that key or '-' if n/a.
> #
> # FLAGS is a word consisting of one-letter flags:
> # 'D' - The key has been disabled,
> # 'S' - The key is listed in sshcontrol (requires --with-ssh),
> # 'c' - Use of the key needs to be confirmed,
> # '-' - No flags given.
> #
> # More information may be added in the future.
>
> I'm going to modify this, to distinguish a key on card which is
> inserted, and a key on card which is not inserted. This can be either:
>
> (1) For key on inserted card, add another flag into FLAGS (say, 'A' for
> active),

I think that is the proper solution.

> (2) Introduce new TYPE (say, 'O' for offline) and change the semantics
> of 'T' meaning inserted card.

Alsthough I don't think we will run into problems with that it is not as
clear as using an extra flag.



Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Storing key on multiple smartcards [ In reply to ]
Hello,

Before changing the output of KEYINFO command of gpg-agent (for T4244),
I modified gpg-agent to relax the assumption/requirment of the map
between serialno and keys. In GnuPG, so far, there used to be an
assumption that serialno determines.

Now, by the master commit of 1091f22511e1a8259eb5c998f5c207ee95723a4a ,
we can use a token for backup which has different serialno.

I think that T4301 (using backup key in a different token) is now
handled.

I think that a bit more changes will be needed for better UI. For now,
it is only possible to use back up token, when the token is active
(after gpg --card-status [all]). Perhaps, it is better if KEYINFO
command of scdaemon initiates card/token scanning at first. Let us
consider more.

T3416 would include other use cases. For using signing backup key in a
different token, it should work well. For something like selecting key
in an active token, gpg-frontend changes are needed as well. I keep
considering about that. If any suggestion for a good solution, please
let me know.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel