Store Mgmt and keys loading ( keyform ENG )

Tue Oct 12 08:50:40 UTC 2021

in general, I think that despite what I read in previous replies,
with the operation:
dgst --provider=myprovider -sign handle:1
is not possible to fully reproduce what was possible with engines :
dgst -keyform ENG sign -in 1 -engine=myengine.
In the case of provider the store manager's caller sets
ossl_store_handle_load_result as fixed callback method when calling the
load of store mgmt. If that callback is not called , it will complain as no
private key is possible to read.

On Tue, Oct 12, 2021 at 9:22 AM Antonio Santagiuliana <
santantonioswap at gmail.com> wrote:

> Thank you for the suggestion.
> I am using providers though, not engine, and I can't see the higher level
> checking this RSA flags before it has detected a valid key is passed back
> from the store manager to ossl_store_handle_load_result() ( the callback
> passed to the store mgmt load() method).
> If I don't call the callback ossl_store_handle_load_result the higher
> level after the store mgmt load() complains no private key can be read.
> If I pass back an RSA key generated on the fly in the store mgmt load()
> then the ossl_store_handle_load_result() is fine using the RSA key mgmt
> load finds error in checking RSA flags , I think these flags are not set
> but I don't know how to set them in the fictitious private key I generated
> on the fly in the store mgmt load() with
>     EVP_PKEY *pkey = NULL;
>     pkey = EVP_RSA_gen(2048);
> This produces a valid pkey without errors but I think the rsa fields are
> not filled in.How can I add them to pkey ?
> I think I should register a different keymgmt on my provider but I am not
> sure what it should do in my case.
> So , for now, the RSA keymgmt is called and in its load() function
> ( rsa_load() ) at some point it wants to check RSA_check_flags() and there
> it stops as the rsa struct fileds referenced are not filled in.
>
>
>
> On Fri, 8 Oct 2021, 22:04 Piotr Lobacz, <piotr.lobacz at softgent.com> wrote:
>
>> Hi Antonio,
>> I was discussing about this problem about half a year ago in here. The
>> problem was itself in .net library but it concerned RSA_FLAG_EXT_PKEY in
>> RSA_METHOD which is wrong. Yo can read it in here
>> https://github.com/dotnet/runtime/issues/53345. The clue of my problem
>> was that this flag was being set by the dotnet and engine was setting it in
>> RSA_set_flags - which is the proper way. You need to verify how the engine
>> sets this flag and read my issue maybe it will help you in solving yours.
>>
>> BR
>> Piotr
>> ------------------------------
>> *Od:* openssl-users <openssl-users-bounces at openssl.org> w imieniu
>> użytkownika Antonio Santagiuliana <santantonioswap at gmail.com>
>> *Wysłane:* piątek, 8 października 2021 10:34
>> *Do:* Tomas Mraz <tomas at openssl.org>
>> *DW:* openssl-users at openssl.org <openssl-users at openssl.org>
>> *Temat:* Re: Store Mgmt and keys loading ( keyform ENG )
>>
>> Could I ask you what is the best way to let the Openssl carry on in the
>> case I can't pass the private key from my store manager load() function as
>> key is offloaded in secure hw?
>> I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the
>> callback function from my Store Mgmt's load() where I get the uri ( the
>> callback func is ossl_store_handle_load_result() ) I get error "could not
>> read the private key".
>> If instead I call the callback func , I don't know how to fill in its
>> params , as I don't have the private key. What should I put in the params
>> to let the rest of call chain ( I am on the dgst command ) not caring about
>> private key but carry on with operation?or can I avoid calling the callback?
>> Thank you
>>
>> On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, <
>> santantonioswap at gmail.com> wrote:
>>
>> It is because of prototypes of methods..
>>
>> On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, <
>> santantonioswap at gmail.com> wrote:
>>
>> Hello,
>> just continuing on this..
>> I defined my store mgmt as :
>> static const OSSL_ALGORITHM test_store[] = {
>> { "handle", "provider=test", mystore_functions},
>> {NULL, NULL, NULL}
>> };
>>
>> echo "test" | LD_LIBRARY_PATH=.    apps/openssl  dgst
>> --provider-path=./providers --provider=test  --sign handle:1 -out
>> messa.encrypted.bin
>>
>> Could not open file or uri for loading private key from handle:1
>>
>> C0628C24787F0000:error:16000069:STORE
>> routines:ossl_store_get0_loader_int:unregistered
>> scheme:crypto/store/store_register.c:237:scheme=file
>>
>> C0628C24787F0000:error:1608010C:STORE
>> routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No
>> store loader found. For standard store loaders you need at least one
>> of the default or base providers available. Did you forget to load
>> them? Info: Global default library context, Scheme (file : 0),
>> Properties (<null>)
>>
>> C0628C24787F0000:error:16000069:STORE
>> routines:ossl_store_get0_loader_int:unregistered
>> scheme:crypto/store/store_register.c:237:scheme=handle
>>
>> 1) It firstly looks for a provider for scheme file: and it doesn't
>> find as I haven't set up any store mgmt for file: .
>>
>> 2) It looks like on second attempt it tries to look for handle: but it
>> finds it not registered. What does this error mean ? Does it look for
>> registered uri schemes online ? if that is the case how can this works
>> instead : https://github.com/tpm2-software/tpm2-openssl ? They use
>> handle: scheme as well.
>>
>> Does this mean it's a problem of the methods I registered for the
>> store or is something related to the uri scheme I am using ?
>> Sorry but I couldn't find more info on this in the sources/docs .
>>
>>
>> thank you
>>
>>
>>
>> On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana
>> <santantonioswap at gmail.com> wrote:
>> >
>> > OK, thank you very much for your comments, that's clear.
>> >
>> > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, <tomas at openssl.org> wrote:
>> >>
>> >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already
>> >> modified to use OSSL_STORE API to load keys. So you do not need to
>> >> specify keyform=ENGINE if your key is provided by a provider that
>> >> supports the STORE functionality for some special URL scheme. You just
>> >> specify the right URL with that scheme to reference the key in the
>> >> provider.
>> >>
>> >> Of course third party applications need to be modified to call
>> >> OSSL_STORE API in a similar way how the openssl application does it.
>> >>
>> >> Tomas
>> >>
>> >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote:
>> >> > Thank you for your comment.
>> >> > Am I wrong then in saying that dgst and possibly other apps are not
>> >> > ready to be used with providers  rather than engines in the case you
>> >> > need keyform=ENGINE ?
>> >> >
>> >> >
>> >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, <tomas at openssl.org> wrote:
>> >> > > You would have to implement a STORE provider that handles your
>> >> > > special
>> >> > > url scheme and then the keys would be referenced by the
>> >> > > yourscheme://any-identifier-you-have. Of course the application
>> >> > > (i.e.,
>> >> > > the openssl application which already does this) would have to use
>> >> > > the
>> >> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER
>> >> > > API
>> >> > > or the d2i/PEM_read APIs.
>> >> > >
>> >> > > Tomas
>> >> > >
>> >> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote:
>> >> > > > I checked the sources, I found that keyform cannot be set to
>> >> > > > ENGINE
>> >> > > > if engine is not specified in the command options, this is in the
>> >> > > > function make_engine_url() called from load_key() when
>> >> > > > format==FORMAT_ENGINE.
>> >> > > > I am not specifying engine in the dgst command options as I am
>> >> > > using
>> >> > > > a  provider.
>> >> > > > I would like to achieve the same as FORMAT_ENGINE does, but with
>> >> > > > provider.
>> >> > > >
>> >> > > >
>> >> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana,
>> >> > > > <santantonioswap at gmail.com> wrote:
>> >> > > > > Hello,
>> >> > > > > I am doing my own provider starting from the default provider's
>> >> > > > > code.
>> >> > > > > I have now a question, I am seeing the STOREMGMT operation is
>> >> > > > > required to interpret the URI of input private key,  I would
>> >> > > > > like
>> >> > > > > that the string passed by the user for input key is not
>> >> > > > > interpret
>> >> > > > > as file to open but just my provider should save the string
>> >> > > > > value
>> >> > > > > to be used later .This is  when invoking command options such
>> >> > > > > as
>> >> > > > > dgst sign -in "text" -keyform ENG.
>> >> > > > > With engines' architecture this is possible by passing option -
>> >> > > > > keyform ENG to dgst command. The string in that case is not
>> >> > > > > interpreted as a file path and just passed through.
>> >> > > > > There was engine_set_load_privkey_function that was getting
>> >> > > > > this
>> >> > > > > string.
>> >> > > > > How can I achieve this now with the provider architecture ? If
>> >> > > > > I
>> >> > > > > pass -keyform ENG to dgst command together with --provider , it
>> >> > > > > says "no engine specified to load private key" Should I use
>> >> > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? .
>> >> > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I
>> >> > > don't
>> >> > > > > have a real private key info to load and use from a Filesystem.
>> >> > > > > Is there anything to set in the KEYMGMT too ? I can see there
>> >> > > > > is
>> >> > > a
>> >> > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key
>> >> > > > > data in a key object should be considered. Not really sure if
>> >> > > this
>> >> > > > > is something I should set or not and how this keymgmt operation
>> >> > > > > relates with storemgmt operation.
>> >> > > > >
>> >> > > > > thank you if you can send some comment on this.
>> >> > > > >
>> >> > >
>> >>
>> >> --
>> >> Tomáš Mráz
>> >> No matter how far down the wrong road you've gone, turn back.
>> >>                                               Turkish proverb
>> >> [You'll know whether the road is wrong if you carefully listen to your
>> >> conscience.]
>> >>
>> >>
>>
>> <https://www.softgent.com>
>>
>> *Softgent Sp. z o.o.*, Budowlanych 31d, 80-298 Gdansk, POLAND
>>
>> KRS: 0000674406, NIP: 9581679801, REGON: 367090912
>> www.softgent.com
>>
>> Sąd Rejonowy Gdańsk-Północ w Gdańsku, VII Wydział Gospodarczy Krajowego
>> Rejestru Sądowego
>>
>> KRS 0000674406, Kapitał zakładowy: 25 000,00 zł wpłacony w całości.
>>
>> Jesteśmy uczestnikiem Programu
>> *RZETELNA* *Firma *
>> Sprawdź naszą rzetelność na
>> https://www.rzetelnafirma.pl/F5IA32UW
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20211012/c6b4201d/attachment-0001.html>