Skip to content

Commit

Permalink
Merge pull request Mbed-TLS#6498 from yuhaoth/pr/fix-session-resumpti…
Browse files Browse the repository at this point in the history
…on-fail-when-hostname-is-not-localhost
  • Loading branch information
yuhaoth committed Nov 29, 2022
2 parents 71d7ad0 + bf249ac commit 0ba62db
Show file tree
Hide file tree
Showing 60 changed files with 2,072 additions and 323 deletions.
37 changes: 8 additions & 29 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -1,40 +1,19 @@
Notes:
* Pull requests cannot be accepted until the PR follows the [contributing guidelines](../CONTRIBUTING.md). In particular, each commit must have at least one `Signed-off-by:` line from the committer to certify that the contribution is made under the terms of the [Developer Certificate of Origin](../dco.txt).
* This is just a template, so feel free to use/remove the unnecessary things
## Description
A few sentences describing the overall goals of the pull request's commits.

Please write a few sentences describing the overall goals of the pull request's commits.

## Status
**READY/IN DEVELOPMENT/HOLD**

## Requires Backporting
When there is a bug fix, it should be backported to all maintained and supported branches.
Changes do not have to be backported if:
- This PR is a new feature\enhancement
- This PR contains changes in the API. If this is true, and there is a need for the fix to be backported, the fix should be handled differently in the legacy branch

Yes | NO
Which branch?
## Gatekeeper checklist

## Requires ChangeLog entry
- [ ] **changelog** provided, or not required
- [ ] **backport** done, or not required
- [ ] **tests** provided, or not required

YES | NO - if no, why not?

## Migrations
If there is any API change, what's the incentive and logic for it.

YES | NO
## Notes for the submitter

## Additional comments
Any additional information that could be of interest
Please refer to the [contributing guidelines](../CONTRIBUTING.md), especially the
checklist for PR contributors.

## Todos
- [ ] Tests
- [ ] Documentation
- [ ] Changelog updated
- [ ] Backported


## Steps to test or reproduce
Outline the steps to test or reproduce the PR here.
15 changes: 11 additions & 4 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,16 @@
Contributing
============
We gratefully accept bug reports and contributions from the community. There are some requirements we need to fulfill in order to be able to integrate contributions:
We gratefully accept bug reports and contributions from the community. All PRs are reviewed by the project team / community, and may need some modifications to
be accepted.

- As with any open source project, contributions will be reviewed by the project team and community and may need some modifications to be accepted.
- The contribution should not break API or ABI, unless there is a real justification for that. If there is an API change, the contribution, if accepted, will be merged only when there will be a major release.
Quick Checklist for PR contributors
-----------------------------------
More details on all of these points may be found in the sections below.

- [Sign-off](#license-and-copyright): all commits must be signed off.
- [Tests](#tests): please ensure the PR includes adequate tests.
- [Changelog](#documentation): if needed, please provide a changelog entry.
- [Backports](#long-term-support-branches): provide a backport if needed (it's fine to wait until the main PR is accepted).

Coding Standards
----------------
Expand All @@ -25,7 +32,7 @@ Backwards Compatibility

The project aims to minimise the impact on users upgrading to newer versions of the library and it should not be necessary for a user to make any changes to their own code to work with a newer version of the library. Unless the user has made an active decision to use newer features, a newer generation of the library or a change has been necessary due to a security issue or other significant software defect, no modifications to their own code should be necessary. To achieve this, API compatibility is maintained between different versions of Mbed TLS on the main development branch and in LTS (Long Term Support) branches, as described in [BRANCHES.md](BRANCHES.md).

To minimise such disruption to users, where a change to the interface is required, all changes to the ABI or API, even on the main development branch where new features are added, need to be justifiable by either being a significant enhancement, new feature or bug fix which is best resolved by an interface change.
To minimise such disruption to users, where a change to the interface is required, all changes to the ABI or API, even on the main development branch where new features are added, need to be justifiable by either being a significant enhancement, new feature or bug fix which is best resolved by an interface change. If there is an API change, the contribution, if accepted, will be merged only when there will be a major release.

Where changes to an existing interface are necessary, functions in the public interface which need to be changed, are marked as 'deprecated'. This is done with the preprocessor symbols `MBEDTLS_DEPRECATED_WARNING` and `MBEDTLS_DEPRECATED_REMOVED`. Then, a new function with a new name but similar if not identical behaviour to the original function containing the necessary changes should be created alongside the existing deprecated function.

Expand Down
6 changes: 6 additions & 0 deletions ChangeLog.d/cert_write-set-extended-key-usages.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
Features
* cert_write: support for setting extended key usage attributes. A
corresponding new public API call has been added in the library,
mbedtls_x509write_crt_set_ext_key_usage().
* cert_write: support for writing certificate files in either PEM
or DER format.
5 changes: 5 additions & 0 deletions ChangeLog.d/ecdsa-verify-fixes.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
Bugfix
* Fix ECDSA verification, where it was not always validating the
public key. This bug meant that it was possible to verify a
signature with an invalid public key, in some cases. Reported by
Guido Vranken using Cryptofuzz in #4420.
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
Bugfix
* Fix TLS 1.3 session resumption fail. Fixes #6488.
* Add configuration check to exclude TLS 1.3 optional authentication of
client.
3 changes: 3 additions & 0 deletions ChangeLog.d/fix_zeroization.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
Bugfix
* Fix possible crash in TLS PRF code, if a failure to allocate memory occurs.
Reported by Michael Madsen in #6516.
6 changes: 6 additions & 0 deletions ChangeLog.d/psa_crypto_code_gen_1_1.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
Features
* Brought in PSA code geneneration JSON driver list.
Added auto generated templating support for key management.
Added Support for transparent and opaque keys (import/export/copy).
Included some general JSON validation for the given entry points.
Addresses version 1.1 of #5137.
10 changes: 3 additions & 7 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ and [@hannestschofenig](https://github.com/hannestschofenig).
In the following, we describe the features that are currently under development.
The main Mbed TLS documentation is available via [ReadTheDocs](https://mbed-tls.readthedocs.io/).

Documentation for the PSA Cryptography API is available [on GitHub](https://armmbed.github.io/mbed-crypto/psa/#application-programming-interface).
Documentation for the PSA Cryptography API is available [on GitHub](https://arm-software.github.io/psa-api/crypto/).

## TLS 1.3

Expand Down Expand Up @@ -276,11 +276,11 @@ Mbed TLS is mostly written in portable C99; however, it has a few platform requi
PSA cryptography API
--------------------

### PSA API design
### PSA API

Arm's [Platform Security Architecture (PSA)](https://developer.arm.com/architectures/security-architectures/platform-security-architecture) is a holistic set of threat models, security analyses, hardware and firmware architecture specifications, and an open source firmware reference implementation. PSA provides a recipe, based on industry best practice, that allows security to be consistently designed in, at both a hardware and firmware level.

The [PSA cryptography API](https://armmbed.github.io/mbed-crypto/psa/#application-programming-interface) provides access to a set of cryptographic primitives. It has a dual purpose. First, it can be used in a PSA-compliant platform to build services, such as secure boot, secure storage and secure communication. Second, it can also be used independently of other PSA components on any platform.
The [PSA cryptography API](https://arm-software.github.io/psa-api/crypto/) provides access to a set of cryptographic primitives. It has a dual purpose. First, it can be used in a PSA-compliant platform to build services, such as secure boot, secure storage and secure communication. Second, it can also be used independently of other PSA components on any platform.

The design goals of the PSA cryptography API include:

Expand All @@ -292,10 +292,6 @@ The design goals of the PSA cryptography API include:

Arm welcomes feedback on the design of the API. If you think something could be improved, please open an issue on our Github repository. Alternatively, if you prefer to provide your feedback privately, please email us at [`[email protected]`](mailto:[email protected]). All feedback received by email is treated confidentially.

### PSA API documentation

A browsable copy of the PSA Cryptography API documents is available on the [PSA cryptography interfaces documentation portal](https://armmbed.github.io/mbed-crypto/psa/#application-programming-interface) in [PDF](https://armmbed.github.io/mbed-crypto/PSA_Cryptography_API_Specification.pdf) and [HTML](https://armmbed.github.io/mbed-crypto/html/index.html) formats.

### PSA implementation in Mbed TLS

Mbed TLS includes a reference implementation of the PSA Cryptography API.
Expand Down
6 changes: 6 additions & 0 deletions docs/proposed/psa-driver-developer-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,12 @@ A driver therefore consists of:

Mbed TLS calls driver entry points [as specified in the PSA Cryptography Driver Interface specification](psa-driver-interface.html#driver-entry-points) except as otherwise indicated in this section.

## Mbed TLS extensions

The driver description can include Mbed TLS extensions (marked by the namespace "mbedtls"). Mbed TLS extensions are meant to extend/help integrating the driver into the library's infrastructure.
* `"mbedtls/h_condition"` (optional, string) can include complex preprocessor definitions to conditionally include header files for a given driver.
* `"mbedtls/c_condition"` (optional, string) can include complex preprocessor definitions to conditionally enable dispatch capabilities for a driver.

## Building and testing your driver

<!-- TODO -->
Expand Down
18 changes: 13 additions & 5 deletions docs/proposed/psa-driver-wrappers-codegen-migration-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,20 +13,28 @@ During the process of implementation there might be minor variations wrt version

## Prerequisites

Python3 and Jinja2 rev 2.10.1
Python3, Jinja2 rev 2.10.1 and jsonschema rev 3.2.0

## Feature Version

1.0
1.1

### What's critical for a migrating user

The Driver Wrapper auto generation project is designed to use a python templating library ( Jinja2 ) to render templates based on drivers that are defined using a Driver description JSON file(s).

While that is the larger goal, for version 1.0 here's what's changed
While that is the larger goal, for version 1.1 here's what's changed

#### What's changed

(1) psa_crypto_driver_wrappers.c will from this point on be auto generated.
(2) The auto generation is based on the template file at scripts/data_files/driver_templates/psa_crypto_driver_wrappers.c.jinja.
(3) So while all driver wrapper templating support is yet to come in, the library user will need to patch into the template file as needed, this could be read as replacing the template file with the current psa_crypto_driver_wrappers.c file maintained by the library user.
(2) The auto generation is based on the template file at **scripts/data_files/driver_templates/psa_crypto_driver_wrappers.c.jinja**.
(3) The driver JSONS to be used for generating the psa_crypto_driver_wrappers.c file can be found at **scripts/data_files/driver_jsons/** as their default location, this path includes the schemas against which the driver schemas will be validated (driver_opaque_schema.json, driver_transparent_schema.json) and a driverlist.json which specifies the drivers to be considered and the order in which they want to be called into. The default location for driverlist.json and driver JSONS can be overloaded by passing an argument --json-dir while running the script generate_driver_wrappers.py.
(4) While the complete driver wrapper templating support is yet to come in, if the library user sees a need to patch psa_crypto_driver_wrappers.c file, the user will need to patch into the template file as needed (psa_crypto_driver_wrappers.c.jinja).

#### How to set your driver up

Please refer to psa-driver-interface.md for information on how a driver schema can be written.
One can also refer to the example test drivers/ JSON schemas under **scripts/data_files/driver_jsons/**.

The JSON file 'driverlist.json' is meant to be edited by the user to reflect the drivers one wants to use on a device. The order in which the drivers are passed is also essential if/when there are multiple transparent drivers on a given system to retain the same order in the templating.
4 changes: 1 addition & 3 deletions include/mbedtls/ecdsa.h
Original file line number Diff line number Diff line change
Expand Up @@ -245,10 +245,8 @@ int mbedtls_ecdsa_sign_det_ext( mbedtls_ecp_group *grp, mbedtls_mpi *r,
* This must be initialized.
*
* \return \c 0 on success.
* \return #MBEDTLS_ERR_ECP_BAD_INPUT_DATA if the signature
* is invalid.
* \return An \c MBEDTLS_ERR_ECP_XXX or \c MBEDTLS_MPI_XXX
* error code on failure for any other reason.
* error code on failure.
*/
int mbedtls_ecdsa_verify( mbedtls_ecp_group *grp,
const unsigned char *buf, size_t blen,
Expand Down
13 changes: 13 additions & 0 deletions include/mbedtls/x509_crt.h
Original file line number Diff line number Diff line change
Expand Up @@ -1145,6 +1145,19 @@ int mbedtls_x509write_crt_set_authority_key_identifier( mbedtls_x509write_cert *
int mbedtls_x509write_crt_set_key_usage( mbedtls_x509write_cert *ctx,
unsigned int key_usage );

/**
* \brief Set the Extended Key Usage Extension
* (e.g. MBEDTLS_OID_SERVER_AUTH)
*
* \param ctx CRT context to use
* \param exts extended key usage extensions to set, a sequence of
* MBEDTLS_ASN1_OID objects
*
* \return 0 if successful, or MBEDTLS_ERR_X509_ALLOC_FAILED
*/
int mbedtls_x509write_crt_set_ext_key_usage( mbedtls_x509write_cert *ctx,
const mbedtls_asn1_sequence *exts );

/**
* \brief Set the Netscape Cert Type flags
* (e.g. MBEDTLS_X509_NS_CERT_TYPE_SSL_CLIENT | MBEDTLS_X509_NS_CERT_TYPE_EMAIL)
Expand Down
40 changes: 7 additions & 33 deletions library/bignum.c
Original file line number Diff line number Diff line change
Expand Up @@ -1931,39 +1931,11 @@ int mbedtls_mpi_gcd( mbedtls_mpi *G, const mbedtls_mpi *A, const mbedtls_mpi *B
return( ret );
}

/* Fill X with n_bytes random bytes.
* X must already have room for those bytes.
* The ordering of the bytes returned from the RNG is suitable for
* deterministic ECDSA (see RFC 6979 §3.3 and mbedtls_mpi_random()).
* The size and sign of X are unchanged.
* n_bytes must not be 0.
*/
static int mpi_fill_random_internal(
mbedtls_mpi *X, size_t n_bytes,
int (*f_rng)(void *, unsigned char *, size_t), void *p_rng )
{
int ret = MBEDTLS_ERR_ERROR_CORRUPTION_DETECTED;
const size_t limbs = CHARS_TO_LIMBS( n_bytes );
const size_t overhead = ( limbs * ciL ) - n_bytes;

if( X->n < limbs )
return( MBEDTLS_ERR_MPI_BAD_INPUT_DATA );

memset( X->p, 0, overhead );
memset( (unsigned char *) X->p + limbs * ciL, 0, ( X->n - limbs ) * ciL );
MBEDTLS_MPI_CHK( f_rng( p_rng, (unsigned char *) X->p + overhead, n_bytes ) );
mbedtls_mpi_core_bigendian_to_host( X->p, limbs );

cleanup:
return( ret );
}

/*
* Fill X with size bytes of random.
*
* Use a temporary bytes representation to make sure the result is the same
* regardless of the platform endianness (useful when f_rng is actually
* deterministic, eg for tests).
* The bytes returned from the RNG are used in a specific order which
* is suitable for deterministic ECDSA (see the specification of
* mbedtls_mpi_random() and the implementation in mbedtls_mpi_fill_random()).
*/
int mbedtls_mpi_fill_random( mbedtls_mpi *X, size_t size,
int (*f_rng)(void *, unsigned char *, size_t),
Expand All @@ -1980,7 +1952,7 @@ int mbedtls_mpi_fill_random( mbedtls_mpi *X, size_t size,
if( size == 0 )
return( 0 );

ret = mpi_fill_random_internal( X, size, f_rng, p_rng );
ret = mbedtls_mpi_core_fill_random( X->p, X->n, size, f_rng, p_rng );

cleanup:
return( ret );
Expand Down Expand Up @@ -2042,7 +2014,9 @@ int mbedtls_mpi_random( mbedtls_mpi *X,
*/
do
{
MBEDTLS_MPI_CHK( mpi_fill_random_internal( X, n_bytes, f_rng, p_rng ) );
MBEDTLS_MPI_CHK( mbedtls_mpi_core_fill_random( X->p, X->n,
n_bytes,
f_rng, p_rng ) );
MBEDTLS_MPI_CHK( mbedtls_mpi_shift_r( X, 8 * n_bytes - n_bits ) );

if( --count == 0 )
Expand Down
80 changes: 80 additions & 0 deletions library/bignum_core.c
Original file line number Diff line number Diff line change
Expand Up @@ -540,4 +540,84 @@ int mbedtls_mpi_core_get_mont_r2_unsafe( mbedtls_mpi *X,
return( ret );
}

void mbedtls_mpi_core_ct_uint_table_lookup( mbedtls_mpi_uint *dest,
const mbedtls_mpi_uint *table,
size_t limbs,
size_t count,
size_t index )
{
for( size_t i = 0; i < count; i++, table += limbs )
{
unsigned char assign = mbedtls_ct_size_bool_eq( i, index );
mbedtls_mpi_core_cond_assign( dest, table, limbs, assign );
}
}

/* Fill X with n_bytes random bytes.
* X must already have room for those bytes.
* The ordering of the bytes returned from the RNG is suitable for
* deterministic ECDSA (see RFC 6979 §3.3 and the specification of
* mbedtls_mpi_core_random()).
*/
int mbedtls_mpi_core_fill_random(
mbedtls_mpi_uint *X, size_t X_limbs,
size_t n_bytes,
int (*f_rng)(void *, unsigned char *, size_t), void *p_rng )
{
int ret = MBEDTLS_ERR_ERROR_CORRUPTION_DETECTED;
const size_t limbs = CHARS_TO_LIMBS( n_bytes );
const size_t overhead = ( limbs * ciL ) - n_bytes;

if( X_limbs < limbs )
return( MBEDTLS_ERR_MPI_BAD_INPUT_DATA );

memset( X, 0, overhead );
memset( (unsigned char *) X + limbs * ciL, 0, ( X_limbs - limbs ) * ciL );
MBEDTLS_MPI_CHK( f_rng( p_rng, (unsigned char *) X + overhead, n_bytes ) );
mbedtls_mpi_core_bigendian_to_host( X, limbs );

cleanup:
return( ret );
}

/* BEGIN MERGE SLOT 1 */

/* END MERGE SLOT 1 */

/* BEGIN MERGE SLOT 2 */

/* END MERGE SLOT 2 */

/* BEGIN MERGE SLOT 3 */

/* END MERGE SLOT 3 */

/* BEGIN MERGE SLOT 4 */

/* END MERGE SLOT 4 */

/* BEGIN MERGE SLOT 5 */

/* END MERGE SLOT 5 */

/* BEGIN MERGE SLOT 6 */

/* END MERGE SLOT 6 */

/* BEGIN MERGE SLOT 7 */

/* END MERGE SLOT 7 */

/* BEGIN MERGE SLOT 8 */

/* END MERGE SLOT 8 */

/* BEGIN MERGE SLOT 9 */

/* END MERGE SLOT 9 */

/* BEGIN MERGE SLOT 10 */

/* END MERGE SLOT 10 */

#endif /* MBEDTLS_BIGNUM_C */
Loading

0 comments on commit 0ba62db

Please sign in to comment.