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-boun...@openssl.org> w imieniu użytkownika Antonio Santagiuliana <santantonios...@gmail.com> Wysłane: piątek, 8 października 2021 10:34 Do: Tomas Mraz <to...@openssl.org> DW: openssl-users@openssl.org <openssl-users@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, <santantonios...@gmail.com<mailto:santantonios...@gmail.com>> wrote: It is because of prototypes of methods.. On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, <santantonios...@gmail.com<mailto:santantonios...@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 <santantonios...@gmail.com<mailto:santantonios...@gmail.com>> wrote: > > OK, thank you very much for your comments, that's clear. > > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, > <to...@openssl.org<mailto:to...@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, >> > <to...@openssl.org<mailto:to...@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, >> > > > <santantonios...@gmail.com<mailto:santantonios...@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://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com> Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND KRS: 0000674406, NIP: 9581679801, REGON: 367090912 www.softgent.com<https://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
