Delete a slot using softhsm2-util about softhsmv2 HOT 10 CLOSED

In PKCS#11 there is no concept of deleting a token. So we need a tool specific for SoftHSM.

All tokens are located in the directory given in the configuration file. The slot numbers are assigned according to the order of which the token directories are loaded from disc. The name of the token directory is a 16 byte random UUID.

When initializing a new token, its slot number will always be N+1. N is the number of existing tokens. But once the new token has been initialized and you reload the library, it is a high probability that it will be assigned a new slot number (because of the random directory name).

To avoid any confusion, e.g. people scripting softhsm2-util --init-token --slot X and softhsm2-util --delete-token --slot X, we should use the token label or token serial as the identifier.

We should also ask the user to verify the action (--force to ignore the question) and that the user login as the SO.

Or we could just document the manual procedure of removing the correct token. --show-slots will display the token serial which is the second half of the tokens directory name.

from softhsmv2.

I agree that slot numbers would be a bad reference for the actual tokens. Being able to delete with the token label or serial would be sufficient. It may also be good to remove the requirement to specify a slot number to initialization (i.e., softhsm2-util --init-token --slot 0), and simply initialize the next free token.

from softhsmv2.

Question: Is this somewhere stated in the documentation?

• Are slot-sumbers stable?
• Should they be stable?
• Labels are not forced to be unique and I see problems incoming, if it would be forced
• So how do I guarantee a stable identification to my Keys over the lifetime of my store?
• Will the serial-number be guaranteed to be stable?

Currently we're in the process of evaluating SoftHSM2 for DNSSEC with PowerDNS and what makes it quite difficult is the fact, that the slotnumber (which is also used to identify the slot) possibly can change when we add new slots.

from softhsmv2.

Keys, and other objects on a token, identified by a identifier (CKA_ID) and an optional label (CKA_LABEL). Tokens are identified by their label as well as their serial number. There is no real guarantee for uniqueness among any of these identifiers. However, tokens created by SoftHSM has certain properties.

As long as we warn the user about potential conflicts, I don't see a problem deleting by any currently unique property. If there is only one token with label X and the administrator wants to delete X, we're good. If there are two tokens with label X, the administrator should be notified that more qualifiers are needed to uniquely identify the target.

from softhsmv2.

To add to what Jakob has already said: none of the identifiers in PKCS
#11 are guaranteed to be or supposed to be unique. This is also the
reason why all calls in PKCS #11 have the following semantic:

Call #1: supply NULL array and CK_ULONG_PTR pointing to a CK_ULONG, PKCS
#11 library returns the number of items

Call #2: supply suitable size array on call

This is also the case for e.g. C_GetSlotList

Also: slots are not what you actually connect to, you connect to a token
in a slot. This semantic stems from the fact that PKCS #11 can also be
used for e.g. smart cards. If a machine has multiple smart card readers
than these are the slots, whereas an actual smart card inserted into
them is the token you actually (want to) talk to.

Summarising: Rickard, Nikos and Jakob are right, we should refer to the
token by token label or serial number. Also: AFAIK the way SoftHSM v2
generates token serials means that these are virtually guaranteed to be
unique.

Jakob Schlyter wrote:

Keys, and other objects on a token, identified by a identifier (CKA_ID)
and an optional label (CKA_LABEL). Tokens are identified by their label
as well as their serial number. There is no real guarantee for
uniqueness among any of these identifiers. However, tokens created by
SoftHSM has certain properties.

As long as we warn the user about potential conflicts, I don't see a
problem deleting by any currently unique property. If there is only one
token with label X and the administrator wants to delete X, we're good.
If there are two tokens with label X, the administrator should be
notified that more qualifiers are needed to uniquely identify the target.

—
Reply to this email directly or view it on GitHub
#143 (comment).

-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surf.nl/en/about-surf/subsidiaries/surfnet
-- e: [email protected]

from softhsmv2.

Fixed in #214

from softhsmv2.

The fact that there is no API exposed to delete a token and the fact that token labels need not be unique makes deleting and re-initaliazing a slot/token very hard unless one uses softhsm-util. Are there any works arounds to delete the token short of invoking a shell command to invoke softhsmutil from within our application to delete the token

from softhsmv2.

from softhsmv2.

In our application we are trying to use softhsm as our primary keystore to save PKI certs and Pvt and Public keys. Multiple applications will be using this softhsm keystore hosted on our infrastructure and each app initializes its own application specific token. So i need a way to create multiple tokens using the API . The other usecase we need to support is re-init token. This is when running unit test, we want to destroy the previous token and reinit for a fresh run of test. we are currently using https://github.com/miekg/pkcs11 pkc11 Go library to interface with softhsm. The problem I'm facing is for initToken there is no option in API to choose --free like we use in softhsm-util. The softhsm2-util --init-token --slot 0 --label xyz will only work if its the first slot in hsm. Once there is a slot present, slot 0 is no longer accepted as a staging slot. I want to be able to create tokens via API. We did implement logic to find a Token which returns 0 or CKR_INVALID_SLOT_ID if token is not present, which is good, but at that point I don't have a way to create a token in a new slot. using the --slot 0 will not work if there is already one token present and for initToken i haven't found an option to use --free as a part of API call.

from softhsmv2.

from softhsmv2.