Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: tcp: use PSA functions for ISN generation instead of legacy MbedTLS ones #71827

Merged
merged 7 commits into from
May 9, 2024

Conversation

valeriosetti
Copy link
Collaborator

@valeriosetti valeriosetti commented Apr 23, 2024

This PR:

  • replaces MD5 with SHA256 for the computation of ISN (see this comment for details)
  • replaces mbedtls_xxx() with psa_hash_compute()
  • replaces sys_rand_get() with sys_csrand_get()

This PR is an alternative to #71747 in the sense that there is no mbedtls_sha256() alternative option. We go directly to PSA functions instead. This is not a problem because we assume that a PSA provider is always present in the build should it either be built-in into MbedTLS (when MBEDTLS_PSA_CRYPTO_C is enabled) or provided externally through TFM (when BUILD_WITH_TFM is enabled).

jukkar
jukkar previously approved these changes Apr 25, 2024
Copy link
Member

@jukkar jukkar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to networking changes.

rlubos
rlubos previously approved these changes Apr 25, 2024
Copy link
Member

@ceolin ceolin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It needs clarification about the mix usage of cryptographically safe random generator.
Please check comments.

return PSA_ERROR_GENERIC_ERROR;
}
#else
sys_rand_get(output, output_size);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't it need to be cryptographicallly secure ? AFAIU it needs, this fallback shouldn't be an option IMHO.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sorry, I pushed an updated version that fixes this.

sys_rand_get(unique_key, sizeof(unique_key));
#endif
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this condition really scares me. Does it need to be cryptographically secure or not ?
If yes, we should only use sys_crand_get and make it a requirement, if not, why we don't always use the cheaper sys_rand_get ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this is slightly different that the previous case. As far as I understand from RFC6528 at section 3 we just need the ISN to be "not easy to guess". For this we pick some random number and some extra data (input port, output port, etc) and hash all of this. In case the provided random number is not "random enough" then we can apply some hashing function to improve that.
This would mean that sys_rand_get() would be enough, but if CSPRNG is available, why not benefit from it anyway? Wdyt?

Copy link
Collaborator

@frkv frkv May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not easy to guess sys_csrand_get doesn't allow test-modes (If I'm not mistaken). If you have predictive RNG numbers then they are definitely guessable. Please use only sys_csrand_get so we can remove any possible weak holes (e.g. due to RNG behaving "random looking" but still be predictive)

Copy link
Member

@ceolin ceolin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It needs clarification about the mix usage of cryptographically safe random generator.
Please check comments.

@valeriosetti valeriosetti force-pushed the fix-tcp-psa-only branch 3 times, most recently from 4ed09d8 to 8849ed3 Compare May 7, 2024 09:52
@zephyrbot zephyrbot added area: TF-M ARM Trusted Firmware-M (TF-M) area: Samples Samples labels May 7, 2024
@@ -230,8 +230,8 @@ config NET_TCP_ISN_RFC6528
default y
depends on NET_TCP
select MBEDTLS
select MBEDTLS_MD
select MBEDTLS_MAC_MD5_ENABLED
select MBEDTLS_PSA_CRYPTO_C
Copy link
Collaborator

@frkv frkv May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
select MBEDTLS_PSA_CRYPTO_C
select MBEDTLS_PSA_CRYPTO_C if !BUILD_WITH_TFM

Selecting MBEDTLS_PSA_CRYPTO_C is incompatible with BUILD_WITH_TFM. Not sure if this dependency will help, but you could try it out

Use only cryptographically secure random number generators for ISN.

Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Add a choice to select between legacy modules
(i.e. ENTROPY + CTR_DRBG/HMAC_DRBG) and CSPRNG as random generators
for PSA_CRYPTO_C.

Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Create a new Kconfig named CONFIG_PSA_WANT_ALG_SHA_256 which allows to
enable PSA_WANT_ALG_SHA_256. This allows to use PSA functions to
compute SHA256 hashes. When PSA is provided by TFM this allows also
to remove legacy mbedtls_sha256() support and therefore reduce
footprint for the NS side.

Signed-off-by: Valerio Setti <vsetti@baylibre.com>
@valeriosetti
Copy link
Collaborator Author

Comments received so far should be addressed and CI is green. This PR is ready for review.

tomi-font
tomi-font previously approved these changes May 8, 2024
Copy link
Collaborator

@tomi-font tomi-font left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noting that

size_t hash_len;

psa_hash_compute(PSA_ALG_SHA_256, (const unsigned char *)&buf, sizeof(buf),
hash, sizeof(hash), &hash_len);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alignment

size_t hash_len;

psa_hash_compute(PSA_ALG_SHA_256, (const unsigned char *)&buf, sizeof(buf),
hash, sizeof(hash), &hash_len);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both indentations should be OK now

Copy link
Collaborator

@frkv frkv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (assuming alignment is fixed)

When BUILD_WITH_TFM is enabled we can dispatch hash computation
to TFM. This allows to remove the built-in support of SHA256 from
the non-secure side (if it's not used for any other purpose, of course).

Signed-off-by: Valerio Setti <vsetti@baylibre.com>
CONFIG_MINIMAL_LIBC was required for:
- CONFIG_MINIMAL_LIBC_NON_REENTRANT_FUNCTIONS
- CONFIG_MINIMAL_LIBC_RAND

while CONFIG_ENTROPY_GENERATOR and CONFIG_MBEDTLS_ZEPHYR_ENTROPY
are required for CRYPTO_C.

Signed-off-by: Valerio Setti <vsetti@baylibre.com>
PICOLIBC misses the dirent.h header which is required
to emulate ITS (internal trusted storage) in PSA APIs.

Signed-off-by: Valerio Setti <vsetti@baylibre.com>
MBEDTLS_PSA_CRYPTO_C and MBEDTLS_USE_PSA_CRYPTO are 2 different
things and the former should not automatically enable the
latter. The reson is that the user might want the MbedTLS
PSA crypto toolbox to be built, but at the same time he/she
does not want TLS/DTLS (and other intermediate modules such
as PK, MD and Cipher) to use PSA APIs.

For this reason this commit introduces a new Kconfig option
named CONFIG_MBEDTLS_USE_PSA_CRYPTO to enable the corresponding
build symbol. By default USE_PSA_CRYPTO is disabled. It is
only explicilty enabled in tests/samples that were previously
setting CRYPTO_C (since in those cases USE_PSA was set).

Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants