Yubikey enhancement: adds feature set to support multiple slots

[bsingh-kpt]

Following features are implemented:

1. Multiple slots of yubikey can be used
2. Algorithm support include: RSA2048 and RSA3072 for yubikey type only
3. --keytype options enhancement. For yubikey and for each key type SB hierarchy algorithm and slot can be specified. For example, to create a RSA3072 key in slot 9a, --keytype yubikey:RSA3072:9a can be used. Different algorithm and slot can be chosen for each SB key type
4. Subject DN in openssl style can also be specified for certificate generation for each key type
5. KeyConfig is enahanced to support Algorithm and slot for yubikey type only
6. Added key file existence check so that only missing keys are created with create-keys command and avoids unintentional key overwrite
7. Check key certificate first in yubikey and then fallback to its attestation cert if key cert is missing
8. Also supports yubikey retired key slots
9. Adds --prompt option to enable pin prompt for yubikey
10. Adds custom management key support when default is replaced

[Foxboron]

Generally, this is one large PR to support multiple features. Splitting things would be much easier to review.

[bsingh-kpt]

@Foxboron Did you had the time to test the changes?

[Foxboron]

I haven't had time. Sorry.

The PR is not super high on my list as the code is a big hard to review and the commit is doing several things. The description is also point list which is not great.

It would be nicer if there where multiple commits describing each atomic change.

[compujuckel]

This PR addresses a lot of the stuff I was missing, but a small issue remains:
I have a key in slot 0x82 without an accompanying certificate, so GetPIVKeyCert will fail to notice this key and sbctl will try to overwrite it. The key is imported, so GetPIVAttestationCert will not "find" it either.
Instead, KeyInfo could be used to also find private keys without a certificate.

[Foxboron]

I have a key in slot 0x82 without an accompanying certificate, so GetPIVKeyCert will fail to notice this key and sbctl will try to overwrite it. The key is imported, so GetPIVAttestationCert will not "find" it either. Instead, KeyInfo could be used to also find private keys without a certificate.

Is this related to this change? Is this an existing bug in sbctl?

[compujuckel]

Probably yeah, the same should happen if you import a key into the default slot used by sbctl. Attestation will only work when the key was generated on-device.

Basically:

• Imported key, no certificate -> neither detected by this PR or vanilla sbctl
• Imported key, imported certificate -> detected by this PR, not detected by vanilla sbctl
• On-device generated key -> always detected, certificate doesn't matter

[Foxboron]

Attestation will only work when the key was generated on-device.

Yes, you can't have attestation for something that was not created on the yubikey/hardware enclave.

Imported key, no certificate -> neither detected by this PR or vanilla sbctl
Imported key, imported certificate -> detected by this PR, not detected by vanilla sbctl
On-device generated key -> always detected, certificate doesn't matter

The first case should not work, so that is expected. The second case is fine, but it's unclear to me if it's intentionally fixed by this PR or just an artifact that we are looking at more slots.

The latter case is what the support on sbctl has been about.

[compujuckel]

The second case is fine, but it's unclear to me if it's intentionally fixed by this PR or just an artifact that we are looking at more slots

Intentionally fixed since now the stored cert is checked first before getting the attestation cert:
https://github.com/Foxboron/sbctl/pull/474/changes#diff-139951845068372dc118aaf15b7c853040ad4bdd89b375acd696bdb4a022375fR85

[TroyKomodo]

Please run go mod tidy on your branch, it seems to be out of date.

troy@troy-framework ~/g/t/sbctl (yubikey_enhancements)> git diff
diff --git a/go.mod b/go.mod
index fd6d570..30ec785 100644
--- a/go.mod
+++ b/go.mod
@@ -18,7 +18,6 @@ require (
        github.com/spf13/cobra v1.8.1
        golang.org/x/exp v0.0.0-20231219180239-dc181d75b848
        golang.org/x/sys v0.36.0
-       golang.org/x/term v0.35.0
 )
 
 require (
diff --git a/go.sum b/go.sum
index e2ba4b5..3590423 100644
--- a/go.sum
+++ b/go.sum
@@ -217,8 +217,8 @@ github.com/fortytw2/leaktest v1.2.0/go.mod h1:jDsjWgpAGjm2CA7WthBh/CdZYEPF31XHqu
 github.com/fortytw2/leaktest v1.3.0/go.mod h1:jDsjWgpAGjm2CA7WthBh/CdZYEPF31XHquHwclZch5g=
 github.com/foxboron/go-tpm-keyfiles v0.0.0-20240725205618-b7c5a84edf9d h1:odwhCo3olsbN0fkXxCSH3aYz2OhrkcH93oU2QKEcI9s=
 github.com/foxboron/go-tpm-keyfiles v0.0.0-20240725205618-b7c5a84edf9d/go.mod h1:uAyTlAUxchYuiFjTHmuIEJ4nGSm7iOPaGcAyA81fJ80=
-github.com/foxboron/go-uefi v0.0.0-20251010190908-d29549a44f29 h1:2XQY2y+CZCLpFjK5p2EEMwDdP99c7AWP29WhCTkiQm8=
-github.com/foxboron/go-uefi v0.0.0-20251010190908-d29549a44f29/go.mod h1:sqQZKX1X86EAN4C07n6DcbGC/DCN36BNaX/uNvjzmfk=
+github.com/foxboron/go-uefi v0.0.0-20250207204325-69fb7dba244f h1:SGo7y1xmmGWiQzp7QU3ueehmdMVkjj9Yyo1IDEuHbYw=
+github.com/foxboron/go-uefi v0.0.0-20250207204325-69fb7dba244f/go.mod h1:q85c4IRlhhwdRJgGIUWrisDjU8dgcMj8dnXZCXo3hus=
 github.com/foxboron/swtpm_test v0.0.0-20230726224112-46aaafdf7006 h1:50sW4r0PcvlpG4PV8tYh2RVCapszJgaOLRCS2subvV4=
 github.com/foxboron/swtpm_test v0.0.0-20230726224112-46aaafdf7006/go.mod h1:eIXCMsMYCaqq9m1KSSxXwQG11krpuNPGP3k0uaWrbas=
 github.com/franela/goblin v0.0.0-20200105215937-c9ffbefa60db/go.mod h1:7dvUGVsVBjqR7JHJk0brhHOZYGmfBYOrK0ZhYMEtBr4=
@@ -812,6 +812,8 @@ go.etcd.io/etcd/tests/v3 v3.5.0-alpha.0/go.mod h1:HnrHxjyCuZ8YDt8PYVyQQ5d1ZQfzJV
 go.etcd.io/etcd/tests/v3 v3.5.0/go.mod h1:f+mtZ1bE1YPvgKdOJV2BKy4JQW0nAFnQehgOE7+WyJE=
 go.etcd.io/etcd/v3 v3.5.0-alpha.0/go.mod h1:JZ79d3LV6NUfPjUxXrpiFAYcjhT+06qqw+i28snx8To=
 go.etcd.io/etcd/v3 v3.5.0/go.mod h1:FldM0/VzcxYWLvWx1sdA7ghKw7C3L2DvUTzGrcEtsC4=
+go.mozilla.org/pkcs7 v0.0.0-20200128120323-432b2356ecb1 h1:A/5uWzF44DlIgdm/PQFwfMkW0JX+cIcQi/SwLAmZP5M=
+go.mozilla.org/pkcs7 v0.0.0-20200128120323-432b2356ecb1/go.mod h1:SNgMg+EgDFwmvSmLRTNKC5fegJjB7v23qTQ0XLGUNHk=
 go.opencensus.io v0.15.0/go.mod h1:UffZAU+4sDEINUGP/B7UfBBkq4fqLu9zXAX7ke6CHW0=
 go.opencensus.io v0.20.1/go.mod h1:6WKK9ahsWS3RSO+PY9ZHZUfv2irvY6gN279GOPZjmmk=
 go.opencensus.io v0.20.2/go.mod h1:6WKK9ahsWS3RSO+PY9ZHZUfv2irvY6gN279GOPZjmmk=
@@ -1077,8 +1079,6 @@ golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.36.0 h1:KVRy2GtZBrk1cBYA7MKu5bEZFxQk4NIDV6RLVcC8o0k=
 golang.org/x/sys v0.36.0/go.mod h1:OgkHotnGiDImocRcuBABYBEXf8A9a87e/uXjp9XT3ks=
 golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
-golang.org/x/term v0.35.0 h1:bZBVKBudEyhRcajGcNc3jIfWPqV4y/Kt2XcoigOWtDQ=
-golang.org/x/term v0.35.0/go.mod h1:TPGtkTLesOwf2DE8CgVYiZinHAOuy5AYUYT1lENIZnA=
 golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
 golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
 golang.org/x/text v0.3.1-0.20180807135948-17ff2d5776d2/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
troy@troy-framework ~/g/t/sbctl (yubikey_enhancements)>    

[bsingh-kpt]

@compujuckel
Just came back from vacation. Yes, the change assiciated with checking key cert first before attestation is intentional. There is a FIXME question for the reviewer about it. Since Attestatiion cert is being checked , I think it should still be the same to maintiain compatiobility. I needed to use the key cert instead.

@Foxboron
Atomic change would indeed be nice but I do not have cycles to dissect the change into atomic small changes as the same files/lines will need to be changed over and over again. The changes are too coupled.