You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm setting up a distributed system that runs multiple KSMs using the python KSM included in this package (yubikey_ksm.py). I will be connecting each KSM to a dedicated yubiHSM. I'm using a centralized MySQL database to store the AEAD keys for all of the servers. I would like each of my KSMs to use a unique key handle for decryption. In my example I have 5 servers, so server 1 decrypts using key handle 1, server 2 decrypts using key handle 2, etc. The AEAD keys are encrypted with all 5 of the key handles and stored together in a single table on the database.
Problem
When I start a server with the --key-handle 3 argument, I expect that it will load the AEAD encrypted with key handle 3 from the database. This behavior is correct when the AEAD keys are stored using the file system backend. However, with the database backend, it doesn't respect the --key-handle argument and instead returns an AEAD with a random key handle.
You can see that it's iterating over all of the AEADs that match the yubikey and returning the last one outside of the loop. The row that ends up being returned is random. If it doesn't match a key handle that is shared with the HSM, the decryption will fail.
Solution
I was able to fix this by updating the SQL query to filter on only the key handles that were specified via --key-handles.
I think that makes sense and should be fixed.
Does the query as constructed by sql alchemy hit the index for public_id + keyhandle?
Please submit it as a pull request and I'll get it merged.
Scenario
I'm setting up a distributed system that runs multiple KSMs using the python KSM included in this package (yubikey_ksm.py). I will be connecting each KSM to a dedicated yubiHSM. I'm using a centralized MySQL database to store the AEAD keys for all of the servers. I would like each of my KSMs to use a unique key handle for decryption. In my example I have 5 servers, so server 1 decrypts using key handle 1, server 2 decrypts using key handle 2, etc. The AEAD keys are encrypted with all 5 of the key handles and stored together in a single table on the database.
Problem
When I start a server with the
--key-handle 3
argument, I expect that it will load the AEAD encrypted with key handle 3 from the database. This behavior is correct when the AEAD keys are stored using the file system backend. However, with the database backend, it doesn't respect the--key-handle
argument and instead returns an AEAD with a random key handle.Here's the offending logic:
https://github.com/Yubico/python-pyhsm/blob/master/pyhsm/ksm/yubikey_ksm.py#L220
You can see that it's iterating over all of the AEADs that match the yubikey and returning the last one outside of the loop. The row that ends up being returned is random. If it doesn't match a key handle that is shared with the HSM, the decryption will fail.
Solution
I was able to fix this by updating the SQL query to filter on only the key handles that were specified via
--key-handles
.I have a fork with my changes here https://github.com/michael-lazar/python-pyhsm/blob/ksm_db_backend/pyhsm/ksm/yubikey_ksm.py#L208. I would be happy to submit a pull request if you're interested in getting this upstream
The text was updated successfully, but these errors were encountered: