Closed DIEGGOMEZ closed 1 year ago
Hi @DIEGGOMEZ,
Can you please share the errors log? Also if possible please share the entire code that you are working on.
"i have commented the break to continue the process" -> Can you please tell us which break you have commented?
Hi @ShaikKarishma0 ! There are no LOG ERRORS, but no read are being produced, i cannot share the entire code because NDA, but i share the snippet in what i am working, the drivers i added, and the break i commented:
Another doubt: os_event timer should use a different timer than the rest of the application?
Regards.
It is most likely the callbacks/timers inside the PAL implementation are incorrect, which leads to a constant blocking behavior (optiga_lib_status = busy). Could you please check if the callback functions in pal_os_event.c are triggered? Please ensure that this function is executed precisely in the code.
You can also refer to the following cases of porting OPTIGA Trust M on STM32: https://github.com/Infineon/optiga-trust-m/issues/52 https://github.com/Infineon/optiga-trust-m/issues/10
Another doubt: os_event timer should use a different timer than the rest of the application?
Regards.
It depends, you can use the same timer across the entire application or different timers. If you are using the same timer, then you have to make sure that only one can access/reset the timer. So for developing & sanity, it would be better to use a different timer if available.
Hi @ShaikKarishma0 ,
I have made some advances, i have implemented PAL as #52, and my code enters in funtion pal_os_event_trigger_registered_callback() and pal_os_event_register_callback_oneshot() frequently, my problem now is:
in cmd_handler, when i open an application i can reach this funtion, but it just execute first case, never reachinc COMMS_OPEN_START, do you know why or how the code execute this "state machine"?
Thank you
New update @ShaikKarishma0 : Sometimes code can reenter two times in open_comm function, but it is random, and i cant conclude why is happening this, any idea?
Regards!
Hello @DIEGGOMEZ ,
There are several most frequent problems during the porting. First, pal_os_event.c
isn't implemented in the way optiga library expects and second, pal_i2c.c
isn't in the way optiga library expects.
pal_os_event.c
isn't implemented in the way optiga library expectsTwo function are expected to be implemented: pal_os_event_register_callback_oneshot()
and pal_os_event_trigger_registered_callback()
.
pal_os_event_register_callback_oneshot()
There are several ways how to implement it, most common is using a software or hardware timers.
As optiga library executes it's code sequentially (this is important) the function shall request a timer in a given microseconds time, where the callback shall invoke the next function - pal_os_event_trigger_registered_callback()
, please make sure the code leaves the pal_os_event_register_callback_oneshot()
and the timer is raised. If, for instance, the pal_os_event_trigger_registered_callback()
will be called directly, then it will cause enourmous stack grow, as the optiga library state machine relies on the fact, that individual state machine states will be called from different stacks. If no correct timer will be implemented, then the call stack would be like following: optiga_state_machine -> pal_os_event_register_callback_oneshot() -> pal_os_event_trigger_registered_callback() -> optiga_state_machine -> pal_os_event_register_callback_oneshot() -> pal_os_event_trigger_registered_callback() -> optiga_state_machine -> pal_os_event_register_callback_oneshot() -> pal_os_event_trigger_registered_callback() ... etc till the end of the stack, if you have enough stack allocated that might work, but fir sure not always. Ideally it should be done like this:
pal_os_event_trigger_registered_callback()
This function shall check if the context has a registered callback so that any erroneously triggered timers will not cause the optiga state machine processing. Also it is important to make sure, that the timer has been stopped once invoked, as only the pal_os_event_register_callback_oneshot()
shall be a source of the function call
You can check entrance into the functions by putting breakpoints in both functions, they should be called one by one and not in any other combination, ideally to check whether the time given to the pal_os_event_register_callback_oneshot()
corresponds to a real-world value.
pal_i2c.c
isn't in the way optiga library expectsThe 'pal_i2c_write()' and the 'pal_i2c_read()' functions usually are the source of the most of the problems. Depending on the underlying i2c driver, the functions can be implemented either in a blocking mode, when you call a function and ask to send/receive an i2c frame and till the frame is transmitted or received the function will not return, ot in an interrupt mode, when the result of the send or receive will be reported in an interrupt. Both variant are possible and you can see some details of that in the template
General comment#1: please make sure you remove all of the changes performed other than PAL layer, this is important, as every line written makes sense and might affect the overall result. Users are expected to implement the PAL layer.
General comment#2: it might take less time, if we can have a look on the PAL code (only it) you have written. It shouldn't contain any company specific information, neither disclose any information about the platform. Alternative to a private repo on github and we accessing it (or a public repo) could be that you can send the PAL code to your Infineon contact via an email.
General Comment#3: you should try to stick to the following function call pattern:
/* Reset the variable which stores the result of the the follow-up API call */
optiga_lib_status = OPTIGA_LIB_BUSY;
return_status = optiga_crypt_or_util_api_call(me, other_parameters);
/* Check the returning status of the funciton; e.g if it was called with wrong parameters */
if (OPTIGA_LIB_SUCCESS != return_status)
{
return USER_DEFINED_ERROR;
}
/* Wait till OPTIGA finishes an internal processing and either an OPTIGA's timeout happens
* or a result from OPTIGA is returned. OPTIGA has an internal timpeout mechanism, but an aditional protection can be used inside the loop
*/
while (OPTIGA_LIB_BUSY == optiga_lib_status) { }
/* Check the status of the return */
if (OPTIGA_LIB_SUCCESS != optiga_lib_status)
{
return_status = optiga_lib_status;
return return_status;
}
Hi @ayushev !
First of all, thank you both @ShaikKarishma0 and you for the support, this is for me an extreme critical and urgent topic, and your help is greatly appreciated, i am gonna test what you have recommended to me, but to streamline the process i attach you my PAL files (i dont have at this moment an Infinieon contact), and an screenshot about the TIMER callback function.
If you can give me feedback aboud the PAL integration, i appreciate it a lot.
Thank you.
pal_ifx_i2c_config.txt pal_os_event.txt pal_os_lock.txt pal_os_timer.txt pal_gpio.txt pal_i2c.txt
Additionally, to the stament: "the time given to the pal_os_event_register_callback_oneshot() corresponds to a real-world value." it is true, the return in this case is always 1000.
Hi @ayushev !
First of all, thank you for the call, i write you because trying to decrypt a message, Optiga answer me 0x8005, according to your solution reference manual, it is "Invalid parameter in command data field" but i followed your example example_optiga_crypt_rsa_decrypt.c,
i attach you my code, where i read a certificate, and y try to use that array read, to decrypt using the default key in 0xE0FC slot.
Regards!
Update: I have changed read_data_buffer array size to 256 bytes, according to E0FD size private key, and now error is 0x802E.
Hello @DIEGGOMEZ
After the discussion I've added the last point we discussed in the recommendation, please have a look
The decrypt function is called afaik with a shielded connection established (see the example) as this implies by default reading out sensitive information
Referring to the Solution Reference Manual, the above mentioned scheme is able to encrypt decrypt at once not more that a key size used. The default RSA Key size provisiong in the OPTIGA Trust M Express is 2048, that is why the buffer size shall be maximum 256.
The cypher text shall also be structured according to the RSA PKCS#1 v1.5 specification. As the Certificate stored in the the provided Data Slot doesn't contain real encrypted data, it can't be decrypted.
If the RSA PKCS#1 v1.5 isn't a hard requirement and you need to encrypt more that a block size data, I'd propose you to have a look on the symmetric encryption/decryption schemes
Hi @ayushev , thank you for the information, according to encrypt, we have the next issue:
We have already got the certificate from E0E2 and it doesn’t seem to be a valid certificate for us. Maybe it has to do with the format or something like that, because if we try with the contents of E0E0 from the json in gitlab, we receive the same error.
We get the bin contents of that record and try to verify the certificate’s content with this command:
openssl x509 -inform der -in contents.bin
We get this error: asn1 encoding routines:asn1_check_tlen:wrong tag
Should we use a different format/command to verify the contents?
Regards
Hi,
I am developing an Optiga Trust M in STM32, i have added the libraries in Keil uVision and i am adapted PAL drivers, but trying to read data is not working, first issue is that if i aopen an aplication, when i try to read data, OPTIGA_LIB_INSTANCE_BUSY is set, i have commented the break to continue the process but multiple errors occuring, any help? am i doing something wrong?
Regards.