zpcprovider for sign/verify (ecdsa/eddsa)

[holger-dengler]

This PR requires PR #40.

This PR adds OpenSSL provider support for libzpc. This first version covers the main functionality for store, keymgmt, sign/verify and decoder support.

As the series add a lot of new code, it is split into many commits to make the review (hopefully) a bit easier.

ToDo:

• public key support for store/decoder
• alloc/free needs some debugging

Restriction:

• the tests uses hard-coded public keys, so running tests on other machines require code changes in tprovider.c.
• the provider only supports uv origins, so testing is limited to SEL environments.

[ifranzki]

Are you looking at the Travis build failures? You might need to build OpenSSL from source to have a 3.5.0 version to build against.

[holger-dengler]

Yes, a fix for the travis is in progress. It looks like travis only provides 3.0 out of the box. So I'll build my own. At least 3.5, better 4.0.

[holger-dengler]

The update contains:

• re-order of the commits (move test to the end of the series)
• rework of signature/eddsa
• pick review comments
• minor fixes

[holger-dengler]

Another update (force push) to remove the merge conflicts and add a fix for travis.

[ifranzki]

I would suggest to also add tests that utilize the openssl application to use protected key origins. For example, creating/signing a certificate with a protected key origin specified via URI or PEM using openssl x509 -in cert.csr -out cert.pem -req -signkey <protected key origin> -days 1001.

[holger-dengler]

I would suggest to also add tests that utilize the openssl application to use protected key origins. For example, creating/signing a certificate with a protected key origin specified via URI or PEM using openssl x509 -in cert.csr -out cert.pem -req -signkey <protected key origin> -days 1001.

I plan to rework the test. tprovider will be renamed (t_provider) and changed to do only the lookup for the provider components. All key-related functional test will be moved to a new t_openssl test script, which uses openssl to create keys and call the functions. such a split is required to run the tests in a CI.

[ifranzki]

I would move the provider sources into a subdirectory, e.g. src/provider/. Maybe even move the library sources into a subdirectory e.g. src/lib/.

[holger-dengler]

I would postpone the source code restructuring until the provider transition is done (symmetric cipher, secure-key origins etc). There will be eventually also some removal of no longer used code.

[holger-dengler]

The current PR version contains a lot of fixes. The tests with the hard-coded keys (t_provider) has been removed completely. For testing purposes, I would suggest to checkout PR #43, as it provides test scripts which uses openssl cli to trigger the zpcprovider.

Further improvements:

• man-page generation from markdown sources
• reduced OpenSSL dependency (>v3.0.7)
• new zpcprovider configuration drop-in

[ifranzki]

Would it be possible to also run some tests here? Probably not .....

[holger-dengler]

All current tests require at least some existing key files. Provider tests in addition require a sel-setup. I would like to postpone futher testing to upcoming releases.

[ifranzki]

Are you anywhere describing the URI format?

I always wondered why the URI has hbkzpc: but we otherwise always talk about the zpc provider (no hbk here).

In the example OpenSSL conf file you have identity = hbkzpc. One could wonder why?

Also you register the provider operations with a hard coded provider=hbpzpc property string. What happens if one uses a different identity in the config ? Shouldn't the operations registration follow the identity string?

Or maybe just define that it must be identity = hbkzpc.

[holger-dengler]

I'll add the description of the URI format to the zpcprovier.7 man page. I think, that would be the right place as this man page covers all conceptual topics.

[ifranzki]

Right.

And please consider dropping the identity = hbkzpc thing completely.

With an identity set to blah, one would expect that your provider could be fetched with a property query like provider=blah- However, this does not work with your provider, since you register the operations hard coded with provider=hbpzpc regardless of the specified identity....

I don't see why you would want to allow anyone to specify a different identity at all. It would make sense if one could define multiple instances of the same provider with different settings. Then each would need its own identity to be able to fetch them separately. Your provider does not have any settings, so having multiple instances of it just does not make any sense.

The IBMCA provider allows multiple instances with different settings and different identities, and it registers the operations with the specified identity (See https://github.com/opencryptoki/openssl-ibmca/blob/7292da59025c5ca487da148c47be44d895708a1e/src/provider/p_ibmca.c#L1316 and https://github.com/opencryptoki/openssl-ibmca/blob/7292da59025c5ca487da148c47be44d895708a1e/src/provider/p_ibmca.c#L1196). I don't think that this complexity is needed for the zpc provider. Neither the default nor the base provider allow a different identity either.

[holger-dengler]

Regarding your other questions:

• zpc vs. hbkzpc: hbk is the abbreviation for the generic concept (hardware-backed key), while zpc is the abbreviation for platform specific implementation of this concept. I picked hbkzpc for the URI protocol, to express that the URI is targeting the generic concept, as well as the concret implementations.
• I picked zpcprovider for the provider name and zpcprovider.so for the module, because it is the concrete implementation.
• AFAIK there is no way, that the provider registration can follow the identity string. I've not seen such handling in other provider.

[ifranzki]

AFAIK there is no way, that the provider registration can follow the identity string. I've not seen such handling in other provider.

Right, so just drop the identity = hbkzpc from the config example, snippets, and man pages.

[holger-dengler]

Should I mention in the man pages, that setting the identity is not supported?

[ifranzki]

Probably yes. Something like if the identity is set to something other than hbkzpc then is has no effect....
You can't really hinder anyone from setting the identity (well you could check in the code if its the expected identity and fail otherwise.... but do we really want to do this?)

[holger-dengler]

As the zpcprovider has no further configuration possibility, it does not make any sense at the moment, to have multiple instances of it configured at the same time. And if there is only a single instance, it does not make any sense to specify the identity.
So, for the moment, setting the instance is not supported. It might change in the future, but not yet. I'll mention this in the configuration man page.