Geoconfig and API settings models: AES CBC encryption read and write

[Jtang-1]

Product Description

N/A

Technical Summary

Continuation of the work initiated by this PR
Jira Ticket

Introduces a solution for these code scan alerts:
https://github.com/dimagi/commcare-hq/security/code-scanning/295
https://github.com/dimagi/commcare-hq/security/code-scanning/296

This PR updates GeoConfig's api_token, and ConnectionSettings's password, client_secret, and last_token_aes. The model continues supporting reads for both AES ECB and AES CBC encryption while writes only with CBC encryption.

Feature Flag

no FF

Safety Assurance

Safety story

locally tested. This change will not affect any existing data and existing data will be read the same way.

Automated test coverage

There exists tests that the encryption and decryption with CBC results in the expected plaintext.

QA Plan

no QA

Migrations

There is no migration in this PR. But there is a follow up PR that does a migration related to the changes in this PR.
Related migration

Rollback instructions

This PR will start writing data with AES CBC encryption while also adding support to read AES CBC encrypted data. If this PR is reverted, the data encrypted with CBC will fail to be decrypted. To rollback this PR, data written with AES CBC encryption will need to be reencrypted with EBC.

Labels & Review

• Risk label is set correctly
• The set of people pinged as reviewers is appropriate for the level of risk of the change

[jingcheng16]

Looks good! Thank you!

[jingcheng16]

If there is no existing_prefix, then it means the text is not encrypted, so we should not decrypt it right? Can this try except block moved to the first if block, when text starts with existing_prefix?

[Jtang-1]

If there is no existing_prefix, then it means the text is not encrypted, so we should not decrypt it right?

No that's not the case. The expectation is that the encrypted_text passed to reencrypt_ecb_to_cbc_mode is encrypted. The existing_prefix is only to handle situations where the encrypted text is prefixed such that the prefix can be stripped.

[jingcheng16]

Or maybe we don't need existing_prefix at all? Shouldn't this function be able to take in any text, determine if and how is encrypted then do whatever needs to return a cbc encrypted string?

[jingcheng16]

Is there a case that the text is encrypted without any prefix?

[Jtang-1]

Is there a case that the text is encrypted without any prefix?

Yes, it depends on the model.

If we remove the existing_prefix, then we would need to handle stripping prefix on the higher level function that calls reencrypt_ecb_to_cbc_mode and pass only the encrypted text. Is that what you're suggesting?

[jingcheng16]

I see. If there is such case, then existing_prefix is still required. I was suggesting refactoring, because I see logic like, check whether encrypted_text is empty string, is repeated in both reencrypt_ecb_to_cbc_mode and _reencrypt_or_encrypt_value_with_cbc (the latter function is from the migration PR #35641 ). Besides, if the prefix is CBC, then we do nothing and return the text, this logic can also be included in reencrypt_ecb_to_cbc_mode. So the function in the migration PR can be simplified. But this is not a hard block. It's just my personal preference to make the code looks cleaner. I'll approve the PR.

[Jtang-1]

I see what you mean by some repeated logic. I think when we initially wrote reencrypt_ecb_to_cbc_mode, I wasn't expecting to have to handle fields where some value were encrypted and some values weren't. I thought the only scenario would be fields where all the values were encrypted but some values were prefixed while some weren't. I don't think this distinction can be handled within reencrypt_ecb_to_cbc_mode and has to be handled by the caller.

[millerdev]

I'll be ready to sign off on this, after Jing's questions are resolved.

[jingcheng16]

Thanks for continue working on the CBC encryption!