Concurrency issue with hmac init-update-finish

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Concurrency issue with hmac init-update-finish

726 Views
bug_squasher_77
Contributor I

Hey, @Kan_Li 

Following up from CreateCryptoObject fails while doing sss_mac_init 

While doing some stress testing, I witnessed wrong HMAC would return.

Further investigation revealed that if one process is killed while calling sss_mac_update()
Very next process would return wrong HMAC.

For example, see the code in the screenshot,

bug_squasher_77_0-1668753612334.png

It will randomly kill the current process just after sss_mac_update, without cleanup. (Simulate systemd watchdog reset…)

The next hmac calculation gives wrong result without any error.

 

Digging into the source code, I see that CryptoObject is created inside sss_mac_init() and deleted inside sss_mac_context_free()

However, there is logic to reuse the context in sss_mac_init that is causing the issue.

There could be a way to disable this behavior. Instead of reusing, I want to be able to delete existing and create new CryptoObject everytime there is mac_init

Right now, I have implemented this workaround,

bug_squasher_77_1-1668753612335.png

I am not sure if I should be using internal APIs or stick to first level sss_mac* APIs.

 

Summary.

- Should I use SSSFTR_SE05X_CREATE_DELETE_CRYPTOOBJ ? The documentation says I need to initialize all CryptoObject at time of provisioning. I don't think it will achieve what I am looking for
- Should I use my workaround and use internal APIs?
- I want to control this behavior programmatically (or via compile time if not possible programmatically), so a feature request for se05x dev team.

Edit: I tested SSS_FTR_SE05x_CREATE_DELETE_CRYPTOOBJ=0, it simply refuses to calculate hmac with init-update-finish. Which is not what I am looking for.

Labels (1)
0 Kudos
Reply
3 Replies

707 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @bug_squasher_77 ,

 

Actually there is a macro of EX_SSS_BOOT_DO_ERASE which enables similar operation as your workaround in the MW.

Kan_Li_0-1669011117066.png

 

Maybe you can reuse this mechanism as well? or you prefer to do it in your user application?

 

Have a great day,
Kan


-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

 

 

0 Kudos
Reply

705 Views
bug_squasher_77
Contributor I

Hey @Kan_Li ,

This also deletes all stored keys and performs factory reset - Not usable in production.

0 Kudos
Reply

695 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @bug_squasher_77 ,

 

I know, but maybe you can adjust it according to your application.

 

Have a great day,
Kan


-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply