I searched extensively and could not find any documentation about what AWS API calls (or GCE, or Azure, any other external provider really) are required for step-ca to work. Would be much easier to create an user/role with minimal permissions if a list of API calls was provided.

Also, there is no documentation about the naming, tagging, or anything related to the resources created, which also makes it hard to create properly scoped policies.

Thanks!

It works with PKCS11 but not with YubiKey:

$ step kms certificate --import root_ca.crt --kms 'yubikey:pin-value=123456' 'yubikey:slot-id=9a'
Error: error opening yubikey: connecting to smart card: the smart card cannot be accessed because of other connections outstanding
exit status 1

• I'm able to do other operations on the YubiKey, eg. step kms create
• I'm able to import a certificate using ykman as well

go install github.com/smallstep/step-kms-plugin@latest

will not proceed with the following error.

# go.step.sm/crypto/tpm/attestation
.go/pkg/mod/go.step.sm/[email protected]/tpm/attestation/client.go:216:26: ac.baseURL.JoinPath undefined (type *url.URL has no field or method JoinPath)
.go/pkg/mod/go.step.sm/[email protected]/tpm/attestation/client.go:260:26: ac.baseURL.JoinPath undefined (type *url.URL has no field or method JoinPath)

My env.

2023-10-27T12:11:25 [✖ USAGE  2] ⬢ [Systemd] ❯ uname -a
Linux SSD0086 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

~
2023-10-27T12:12:40 ⬢ [Systemd] ❯ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ncaq/.cache/go-build"
GOENV="/home/ncaq/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/ncaq/.go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ncaq/.go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.18"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.18/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2420606553=/tmp/go-build -gno-record-gcc-switches"

It seems that the currently provided prebuilt binaries for step-kms-plugin are not compatible with the official step-ca Docker image. The container also lacks go that would allow manual compilation/install.

If possible, it would be nice if this plugin were included in the step-ca image or one of the prebuilt binaries of step-kms-plugin were compatible with it.

$ step kms create 'yubikey:slot-id=9a' --kms 'yubikey:?pin-value=987654'

Error: failed to create key: error generating key: authenticating with management key: auth challenge: smart card error 6982: security status not satisfied
exit status 1

Update:

With Non Default Management Key (010203040506070801020304050607080102030405060708)

Error: verify pin: smart card error 63c2: verification failed

With Non Default PIN/PUK

step ca certificate --attestation-uri 'yubikey:slot-id=9a' --kms 'yubikey:?pin-value=987654' --provisioner acme-da 17634747 17634747.crt

Error: verify pin: smart card error 63c2: verification failed (2 retries remaining)

With Default PIN/PUK/Management Key all went well.

hi, we try to use step-ca with Thales Proect Server 3+ External with Protect Tool Kit (PTK) 7.2.0.

with PTK emurator mode (did not use actual hardware), step kms sign can create token inside/outside of kubernetes pod without any problem, by using kubectl exec -ti $pod_name. like following

$ kubectl exec -ti $pod_name bash -- step kms sign --in data.jwt --format jws --kms 'pkcs11:module-path=/opt/safenet/protecttoolkit7/ptk/lib/libcryptoki.so;token=$token?pin-value=$pin' 'pkcs11:id=$id'
Defaulted container "main" out of: main, pkcs-tool

n858qRj(redacted)w3-3nyo_nxg

but with actual hardware (Thales Proect Server 3+ External), we got following error. we believe we did setup hsm correctly, because we could create step-ca's root-ca/intermediate-ca key object into the HSM by using step certificate create.

$ kubectl exec -ti $pod_name bash -- step kms sign --in data.jwt --format jws --kms 'pkcs11:module-path=/opt/safenet/protecttoolkit7/ptk/lib/libcryptoki.so;token=$token?pin-value=$pin' 'pkcs11:id=$id'
Defaulted container "main" out of: main, pkcs-tool

Error: failed to load key manager: error initializing PKCS#11: could not open PKCS#11
exit status 1
command terminated with exit code 1

strange thing, if I run the command after logged into pods, error does not happen.

$ kubectl exec -ti smallstep-66dcc85c64-fdjpm -- bash
Defaulted container "main" out of: main, pkcs-tool

# step kms sign --in data.jwt --format jws --kms 'pkcs11:module-path=/opt/safenet/protecttoolkit7/ptk/lib/libcryptoki.so;token=$token?pin-value=$pin' 'pkcs11:id=$id'
aq8DNrx(redacted)zWdv7-f_Is6j-Wg

not only step kms sign but also other command that access to actual hardware (Thales Proect Server 3+ External) like step kms encrypt got same error.

any idea why these commands fails only when run from outside of container (by using kubectl exec -ti $pod -- $command)?

regards,

I am really struggling to make the instructions work on OS X.

I have put the concatenation of ID + password into a file, e.g. echo '0001pppp' > foo

I have tried calling step as follows:

step kms create --json --kty RSA --size 4096 --kms "pkcs11:module-path=/usr/local/lib/libyubihsm_usb.dylib;token=YubiHSM?pin-source=/path/to/foo" "pkcs11:id=7534;object=my-root-ca;export-under-wrap"

But that returns error:

Error: failed to load key manager: error initializing PKCS#11: could not open PKCS#11

The same with /usr/local/lib/pkcs11/yubihsm_pkcs11.dylib.

So I thought, OK, let's try the http connector

So I fired up yubihsm-connector -d

and then tweaked the step call:

step kms create --json --kty RSA --size 4096 --kms "pkcs11:module-path=/usr/local/lib/libyubihsm_http.dylib;token=YubiHSM?pin-source=/path/to/foo" "pkcs11:id=7534;object=my-root-ca;export-under-wrap"

But the same error:

Error: failed to load key manager: error initializing PKCS#11: could not open PKCS#11

And yubihsm-connector shows nothing in its debug output. So step doesn't even try to connect.

STEPDEBUG=1 has zero effect, it produces no extra information.

Setting YUBIHSM_PKCS11_CONF per the yubico docs also has zero effect.

Meanwhile I have no problems using the YubiHSM wih the Yubico tools, e.g.

yubihsm-connector
yubihsm-shell:
  - connect
  - session open 1 <PASSWORD>

That all works fine.

Hi,
Oracle cloud has a vault KMS solution with hardware encryption.

https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Concepts/keyoverview.htm

It would be nice to have a integration and be able to use oracle kms to protect the private key of root ca in smallstep.

Description

We need to add docs on how to define URIs for all the KMSs. We can also add URI support on some of the KMSs that do not support it everywhere, e.g. cloudkms.

At some point we might want to support also go-cloud style URIs compatible with cosign

When I run an ACME DA challenge on an attestation certificate with a touch policy that isn't "never", I need to touch the yubikey to complete the challenge. It would nice to prompt the user to touch the key in this scneario.

When creating an intermediate CA using AWS KMS keys, I would like to be able to have the root and intermediate keys stored in different regions.

We would like to deploy a CAs to multiple regions, using the same root certificate, but with one intermediate per region. I am aware that AWS supports multi-region keys, which is almost certainly how I will accomplish our goals for now, but it would be very useful to be able to specify a different region for --ca-key and --key.

For example, we might store a root key in the us-west-1 region and want to create an intermediate in us-east-2:

step certificate create --profile intermediate-ca \
   --kms 'awskms:region=us-east-2' \
   --ca root_ca.crt \
   --ca-key 'awskms:key-id=78980acd-a42d-4d84-97ba-1e50d3082214' \
   --key 'awskms:key-id=9432458d-1e67-4a74-9a23-8f94708b45fe;region=us-west-1' \
   "Smallstep Intermediate CA" intermediate_ca.crt

To further improve interoperability with other TPM2 tooling, such as tpm2_tools, we should add support for exporting TPM keys in the PEM TSS2 PRIVATE KEY format. Importing that same format would be nice too. A document describing the format is available here.

Exporting can probably be done by printing the key in the right PEM format to stdout, so that the contents can be written to a file by redirecting the output. Importing would require reading from file or stdin, parsing the PEM, then converting it to our (external) key format, so that it can be serialized into our own format.

We probably want to support the core of these operations in go.step.sm/crypto, so that it can be reused. Parts of it should go in pemutil. Others in the kms/tpmkms and tpm packages.

In step-kms-plugin we would need to add the format as an option for export, and ensure that the PEM file can be read for import.

An extension of this would be to support TSS2 PRIVATE KEY PEM as a "native" storage format in the tpm/storage package. We'll likely need to store some additional (meta)data for a private key outside of the base64 in the PEM file. Headers and/or before/after the ----BEGIN and -----END anchors could work for that. Separate file(s) could also work.

Some more context is available in the discussion for #71.

Please add libpcsclite1 as a dependency since it requires libpcsclite.so.1 to run.

Steps to Reproduce

1. Configure AWS profile with credential_process (using a tool like Granted

$ cat ~/.aws/config
[profile My-Account/SuperUser]
granted_sso_start_url      = https://example.awsapps.com/start/
granted_sso_region         = us-east-1
granted_sso_account_id     = 112233445566
granted_sso_role_name      = SuperUser
common_fate_generated_from = aws-sso
credential_process         = granted credential-process --profile My-Account/SuperUser

2. Attempt an operation with a step* binary using AWSKMS:

step-kms-plugin:

$ step kms create --json --kms 'awskms:region=us-east-1' step-ca-test
Error: failed to create key: awskms CreateKeyWithContext failed: NoCredentialProviders: no valid providers in chain. Deprecated.
	For verbose messaging see aws.Config.CredentialsChainVerboseErrors
exit status 1

step certificate create (pre-created KMS key):

$ step certificate create --profile root-ca \
   --kms 'awskms:region=us-east-1' \
   --key 'awskms:key-id=1234567-abcd-1234-dcba-1234567890' \
   "Smallstep Root CA" root_ca.crt

failed to get public key: command "/Users/gralaw/bin/step-kms-plugin key --kms awskms:region=us-east-1 awskms:key-id=f60e6f04-ea3f-4984-b4e6-c2f3f7279d12" failed with:
Error: open awskms:key-id=f60e6f04-ea3f-4984-b4e6-c2f3f7279d12: awskms GetPublicKeyWithContext failed: NoCredentialProviders: no valid providers in chain. Deprecated.
	For verbose messaging see aws.Config.CredentialsChainVerboseErrors

3. WORKAROUND: manually export STS session credentials from credential_process:

$ granted credential-process --profile My-Account/SuperUser
{"Version":1,"AccessKeyId":"AKIAIOSFODNN7EXAMPLE","SecretAccessKey":"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY","SessionToken":"AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE","Expiration":"2024-01-12T04:57:27-05:00"}

$ export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
$ export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
$ export AWS_SESSION_TOKEN="AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE"

$ step kms create --json --kms 'awskms:region=us-east-1' step-ca-test
{
  "name": "awskms:key-id=1234567-abcd-1234-dcba-1234567890",
  "publicKey": "-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE3b1V3/ikBR/pmFI7xFJ4pEKGwS+rpOw7//pveoHgx/FVwuAaOaVcw/PlThZb7/jircsnrugsr7wpjolyVAUHsw==\n-----END PUBLIC KEY-----\n"
}

NOTE: Examples are derived from actual command runs, but all values/IDs replaced with example values for security.

Your Environment

• OS - macOS Sonoma 14.1.2 (23B92)
• Version:

$ step --version
Smallstep CLI/0.25.1 (darwin/arm64)
Release Date: 2023-11-29 09:17 UTC

$ step-kms-plugin version
🔐 step-kms-plugin/0.9.2 (darwin/arm64)
   Release Date: 2023-11-10T22:20:48Z

Expected Behavior

Step should support AWS SSO credentials configured by credential_process in addition to the normal AWS SSO workflow (aws sso login).

Actual Behavior

See reproduction for full details. AWS Go SDK returns NoCredentialProviders error.

Additional Context

AWS Go SDK v2 supports this via: https://docs.aws.amazon.com/sdk-for-go/api/aws/credentials/processcreds/

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Firstly, many thanks to the Smallstep team for creating step and step-kms-plugin.

It seems step-kms-plugin currently requires passing the PIN directly in via the --kms command-line argument, i.e.:

$ step certificate create --profile root-ca \
   --kms "yubikey:pin-value=123456" \
   --key "yubikey:slot-id=82" \
   "Smallstep Root CA" root_ca.crt

Passing sensitive values in via command-line is insecure as nicely outlined in Smallstep's own blog post, "How to Handle Secrets on the Command Line" by Carl Tashian.

It would be great to be able to provide the PIN via more secure methods, such as pipes, file, or environment variable, e.g.:

Pipe example leveraging HashiCorp Vault

$ vault kv get -field=pin yubikey
123456
$ vault kv get -field=pin yubikey \
   | step certificate create --profile root-ca \
     --kms "yubikey" \
     --key "yubikey:slot-id=82" \
     "Smallstep Root CA" root_ca.crt

File example

$ cat yubikey_pin
123456
$ step certificate create --profile root-ca \
     --kms "yubikey:pin-file=yubikey_pin" \
     --key "yubikey:slot-id=82" \
     "Smallstep Root CA" root_ca.crt

Environment example leveraging 1Password

$ op read op://pki/yubikey/pin
123456
$ export STEP_KMS_PIN_VALUE="op://pki/yubikey/pin"
$ op run  -- \
   step certificate create --profile root-ca \
     --kms "yubikey" \
     --key "yubikey:slot-id=82" \
     "Smallstep Root CA" root_ca.crt

Azure also offers Managed HSM that are FIPS 140-2 lvl 3 compliant.
These instances follow the AKV API (no secret & cert support)

It would be nice to have the option to also use managed.
Managed HSM should support the action: getKey & signKey

The only difference is, that they use a different default endpoint: <your-HSM-name>.managedhsm.azure.net

Maybe that could be supported by setting a new optional flag within the uri parameter. E.g. managedhsm=true, or hsm=premium|managed|dedicated

premium = Current behavior using Premium AKV
managed = using Azure Managed HSM
dedicated = future implementation to support dedicated Azure HSM instances

See for a comparison of different AKV SKU

See spf13/cobra#2018. This was added to v1.8.0. Might be useful for our plugin structure too.

E.g. usage text becomes step kms plugin if ran as step-kms-plugin, if I understand correctly. Also applies to autocompletion and other related functionalities.