Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pkcs11-tool: allow using SW tokens #2113

Merged
merged 1 commit into from Sep 28, 2020

Conversation

conradoplg
Copy link
Contributor

I wanted to test SoftHSM with pkcs11-tool --test and had to remove CKF_HW from the mechanism filter, which is what this PR does.

I can't think of a reason for only allowing HW mechanisms, but let me know if I'm missing something.

@dengert
Copy link
Member

dengert commented Sep 19, 2020

I can think of a reason. pkcs11 is for accessing hardware devices that provide the real security. The hardware provides additional physical security.

pkcs11 Base v2.40 Introduction:
The PKCS#11 standard specifies an application programming interface (API), called “Cryptoki,” for
devices that hold cryptographic information and perform cryptographic functions. Cryptoki follows a
simple object based approach, addressing the goals of technology independence (any kind of device) and
resource sharing (multiple applications accessing multiple devices), presenting to applications a common,
logical view of the device called a “cryptographic token”.

If you wanted to submit a PR with a parameter to ignored the CKF_HW flag that would be more acceptable.
But the default should be use CKF_HW.

@conradoplg
Copy link
Contributor Author

I agree that hardware provides additional security. But should pkcs11-tool care? (In particular, should --test care?) I don't see a reason to prevent the user from using pkcs11-tool it with a software token if they want to. Maybe as a sanity check to prevent them from accidentally using a software token by accident, but seems unlikely...

I see these options:

  • Force CKF_HW (current behavior)
  • Remove CKF_HW (current PR)
  • Remove CKF_HW from --test only
  • Remove CKF_HW when a flag is specified (--allow-sw)?

Let me know what's best and I'll change it accordingly!

@dengert
Copy link
Member

dengert commented Sep 20, 2020

I would vote for "Remove CKF_HW when a flag is specified"

I would like to hear from others and what is the name of the option.

@mouse07410
Copy link
Contributor

I am OK with either one of these:

  • Remove CKF_HW (current PR) preferred, or
  • Remove CKF_HW when a flag is specified (--allow-sw)

I do not see value in pkcs11-tool trying to do the enforcement.

@popovec
Copy link
Member

popovec commented Sep 21, 2020

I vote for:

  • Remove CKF_HW when a flag is specified (--allow-sw)

@frankmorgner
Copy link
Member

prefering a HW slot is what the tool should do. you may implement the commandline switch for SW tokens as suggested above.

@Jakuje
Copy link
Member

Jakuje commented Sep 21, 2020

I am fine with either. The pkcs11-tool is just a tool to do some operations on pkcs11 library, whatever it provides.

Indeed it would be good if it would prefer hw variants of the operations (not sure if it is possible/common to have the same mechanism in HW and not in HW in the same pkcs11 library).

In any case, I consider pkcs11-tool as a testing tool rather than something that should be used for any production critical operations. We already have quite a lot configuration switches (which is good for testing various libraries, cards), but sometimes pain for testing pkcs11-tool itself and using.

@conradoplg
Copy link
Contributor Author

I've updated the PR with --allow-sw

@conradoplg
Copy link
Contributor Author

Note that each mechanism can be reported with either CKF_HW or not, you can't have both, so it's not possible to pick up a software implementation instead of a hardware implementation.

Copy link
Member

@Jakuje Jakuje left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution and clarification. Looks good to me.

@frankmorgner frankmorgner merged commit 40da5ca into OpenSC:master Sep 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants