2019-03-18 12:39:49 +00:00
|
|
|
/**
|
|
|
|
|
* \file baremetal.h
|
|
|
|
|
*
|
|
|
|
|
* \brief Test configuration for minimal baremetal Mbed TLS builds
|
|
|
|
|
* based on the following primitives:
|
|
|
|
|
* - ECDHE-ECDSA only
|
|
|
|
|
* - Elliptic curve SECP256R1 only
|
|
|
|
|
* - SHA-256 only
|
|
|
|
|
* - AES-CCM-8 only
|
|
|
|
|
*
|
|
|
|
|
* The library compiles in this configuration, but the example
|
|
|
|
|
* programs `ssl_client2` and `ssl_server2` require the
|
|
|
|
|
* modifications from `baremetal_test.h`.
|
|
|
|
|
*/
|
|
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2006-2018, ARM Limited, All Rights Reserved
|
|
|
|
|
* SPDX-License-Identifier: Apache-2.0
|
|
|
|
|
*
|
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License"); you may
|
|
|
|
|
* not use this file except in compliance with the License.
|
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
|
*
|
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
*
|
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
|
|
|
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
|
* limitations under the License.
|
|
|
|
|
*
|
|
|
|
|
* This file is part of mbed TLS (https://tls.mbed.org)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef MBEDTLS_BAREMETAL_CONFIG_H
|
|
|
|
|
#define MBEDTLS_BAREMETAL_CONFIG_H
|
|
|
|
|
|
|
|
|
|
/* Symmetric crypto: AES-CCM only */
|
|
|
|
|
#define MBEDTLS_CIPHER_C
|
|
|
|
|
#define MBEDTLS_AES_C
|
|
|
|
|
#define MBEDTLS_AES_ROM_TABLES
|
|
|
|
|
#define MBEDTLS_AES_FEWER_TABLES
|
|
|
|
|
#define MBEDTLS_CCM_C
|
|
|
|
|
|
|
|
|
|
/* Asymmetric crypto: Single-curve ECC only. */
|
|
|
|
|
#define MBEDTLS_BIGNUM_C
|
|
|
|
|
#define MBEDTLS_PK_C
|
|
|
|
|
#define MBEDTLS_PK_PARSE_C
|
|
|
|
|
#define MBEDTLS_PK_WRITE_C
|
|
|
|
|
#define MBEDTLS_ECDH_C
|
|
|
|
|
#define MBEDTLS_ECDSA_C
|
|
|
|
|
#define MBEDTLS_ECP_C
|
|
|
|
|
#define MBEDTLS_ECP_DP_SECP256R1_ENABLED
|
|
|
|
|
#define MBEDTLS_ECP_NIST_OPTIM
|
|
|
|
|
#define MBEDTLS_ECDSA_DETERMINISTIC
|
2019-04-03 10:31:31 +00:00
|
|
|
#define MBEDTLS_ECP_WINDOW_SIZE 2
|
|
|
|
|
#define MBEDTLS_ECP_FIXED_POINT_OPTIM 0
|
|
|
|
|
#define MBEDTLS_ECP_MAX_BITS 256
|
|
|
|
|
#define MBEDTLS_MPI_MAX_SIZE 32 // 256 bits is 32 bytes
|
2019-03-18 12:39:49 +00:00
|
|
|
|
|
|
|
|
/* Key exchanges */
|
|
|
|
|
#define MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED
|
2019-04-10 11:24:10 +00:00
|
|
|
#define MBEDTLS_SSL_CIPHERSUITES MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
|
2019-03-18 12:39:49 +00:00
|
|
|
|
|
|
|
|
/* Digests - just SHA-256 */
|
|
|
|
|
#define MBEDTLS_MD_C
|
|
|
|
|
#define MBEDTLS_SHA256_C
|
|
|
|
|
#define MBEDTLS_SHA256_SMALLER
|
|
|
|
|
|
|
|
|
|
/* TLS options */
|
|
|
|
|
#define MBEDTLS_SSL_CLI_C
|
|
|
|
|
#define MBEDTLS_SSL_TLS_C
|
|
|
|
|
#define MBEDTLS_SSL_PROTO_TLS1_2
|
|
|
|
|
#define MBEDTLS_SSL_EXTENDED_MASTER_SECRET
|
|
|
|
|
#define MBEDTLS_SSL_COOKIE_C
|
2019-04-03 12:39:31 +00:00
|
|
|
#define MBEDTLS_SSL_PROTO_DTLS
|
2019-06-18 08:54:25 +00:00
|
|
|
#define MBEDTLS_SSL_PROTO_NO_TLS
|
2019-03-18 12:39:49 +00:00
|
|
|
#define MBEDTLS_SSL_DTLS_ANTI_REPLAY
|
|
|
|
|
#define MBEDTLS_SSL_DTLS_HELLO_VERIFY
|
|
|
|
|
#define MBEDTLS_SSL_DTLS_BADMAC_LIMIT
|
2019-05-15 13:03:01 +00:00
|
|
|
#define MBEDTLS_SSL_DTLS_CONNECTION_ID
|
2019-03-18 12:39:49 +00:00
|
|
|
|
Exemplify harcoding SSL config at compile-time in example of ExtMS
This commit is the first in a series demonstrating how code-size
can be reduced by hardcoding parts of the SSL configuration at
compile-time, focusing on the example of the configuration of
the ExtendedMasterSecret extension.
The flexibility of an SSL configuration defined a runtime vs.
compile-time is necessary for the use of Mbed TLS as a
dynamically linked library, but is undesirable in constrained
environments because it introduces the following overhead:
- Definition of SSL configuration API (code-size overhead)
(and on the application-side: The API needs to be called)
- Additional fields in the SSL configuration (RAM overhead,
and potentially code-size overhead if structures grow
beyond immediate-offset bounds).
- Dereferencing is needed to obtain configuration settings.
- Code contains branches and potentially additional structure
fields to distinguish between different configurations.
Considering the example of the ExtendedMasterSecret extension,
this instantiates as follows:
- mbedtls_ssl_conf_extended_master_secret() and
mbedtls_ssl_conf_extended_master_secret_enforced()
are introduced to configure the ExtendedMasterSecret extension.
- mbedtls_ssl_config contains bitflags `extended_ms` and
`enforce_extended_master_secret` reflecting the runtime
configuration of the ExtendedMasterSecret extension.
- Whenever we need to access these fields, we need a chain
of dereferences `ssl->conf->extended_ms`.
- Determining whether Client/Server should write the
ExtendedMasterSecret extension needs a branch
depending on `extended_ms`, and the state of the
ExtendedMasterSecret negotiation needs to be stored in a new
handshake-local variable mbedtls_ssl_handshake_params::extended_ms.
Finally (that's the point of ExtendedMasterSecret) key derivation
depends on this handshake-local state of ExtendedMasterSecret.
All this is unnecessary if it is known at compile-time that the
ExtendedMasterSecret extension is used and enforced:
- No API calls are necessary because the configuration is fixed
at compile-time.
- No SSL config fields are necessary because there are corresponding
compile-time constants instead.
- Accordingly, no dereferences for field accesses are necessary,
and these accesses can instead be replaced by the corresponding
compile-time constants.
- Branches can be eliminated at compile-time because the compiler
knows the configuration. Also, specifically for the ExtendedMasterSecret
extension, the field `extended_ms` in the handshake structure
is unnecessary, because we can fail immediately during the Hello-
stage of the handshake if the ExtendedMasterSecret extension
is not negotiated; accordingly, the non-ExtendedMS code-path
can be eliminated from the key derivation logic.
A way needs to be found to allow fixing parts of the SSL configuration
at compile-time which removes this overhead in case it is used,
while at the same time maintaining readability and backwards
compatibility.
This commit proposes the following approach:
From the user perspective, for aspect of the SSL configuration
mbedtls_ssl_config that should be configurable at compile-time,
introduce a compile-time option MBEDTLS_SSL_CONF_FIELD_NAME.
If this option is not defined, the field is kept and configurable
at runtime as usual. If the option is defined, the field is logically
forced to the value of the option at compile time.
Internally, read-access to fields in the SSL configuration which are
configurable at compile-time gets replaced by new `static inline` getter
functions which evaluate to the corresponding field access or to the
constant MBEDTLS_SSL_CONF_FIELD_NAME, depending on whether the latter
is defined or not.
Write-access to fields which are configurable at compile-time needs
to be removed: Specifically, the corresponding API itself either
needs to be removed or replaced by a stub function without effect.
This commit takes the latter approach, which has the benefit of
not requiring any change on the example applications, but introducing
the risk of mismatching API calls and compile-time configuration,
in case a user doesn't correctly keep track of which parts of the
configuration have been fixed at compile-time, and which haven't.
Write-access for the purpose of setting defaults is simply omitted.
2019-06-11 12:43:27 +00:00
|
|
|
/* Compile-time fixed parts of the SSL configuration */
|
2019-06-12 15:20:48 +00:00
|
|
|
#define MBEDTLS_SSL_CONF_ANTI_REPLAY MBEDTLS_SSL_ANTI_REPLAY_ENABLED
|
Exemplify harcoding SSL config at compile-time in example of ExtMS
This commit is the first in a series demonstrating how code-size
can be reduced by hardcoding parts of the SSL configuration at
compile-time, focusing on the example of the configuration of
the ExtendedMasterSecret extension.
The flexibility of an SSL configuration defined a runtime vs.
compile-time is necessary for the use of Mbed TLS as a
dynamically linked library, but is undesirable in constrained
environments because it introduces the following overhead:
- Definition of SSL configuration API (code-size overhead)
(and on the application-side: The API needs to be called)
- Additional fields in the SSL configuration (RAM overhead,
and potentially code-size overhead if structures grow
beyond immediate-offset bounds).
- Dereferencing is needed to obtain configuration settings.
- Code contains branches and potentially additional structure
fields to distinguish between different configurations.
Considering the example of the ExtendedMasterSecret extension,
this instantiates as follows:
- mbedtls_ssl_conf_extended_master_secret() and
mbedtls_ssl_conf_extended_master_secret_enforced()
are introduced to configure the ExtendedMasterSecret extension.
- mbedtls_ssl_config contains bitflags `extended_ms` and
`enforce_extended_master_secret` reflecting the runtime
configuration of the ExtendedMasterSecret extension.
- Whenever we need to access these fields, we need a chain
of dereferences `ssl->conf->extended_ms`.
- Determining whether Client/Server should write the
ExtendedMasterSecret extension needs a branch
depending on `extended_ms`, and the state of the
ExtendedMasterSecret negotiation needs to be stored in a new
handshake-local variable mbedtls_ssl_handshake_params::extended_ms.
Finally (that's the point of ExtendedMasterSecret) key derivation
depends on this handshake-local state of ExtendedMasterSecret.
All this is unnecessary if it is known at compile-time that the
ExtendedMasterSecret extension is used and enforced:
- No API calls are necessary because the configuration is fixed
at compile-time.
- No SSL config fields are necessary because there are corresponding
compile-time constants instead.
- Accordingly, no dereferences for field accesses are necessary,
and these accesses can instead be replaced by the corresponding
compile-time constants.
- Branches can be eliminated at compile-time because the compiler
knows the configuration. Also, specifically for the ExtendedMasterSecret
extension, the field `extended_ms` in the handshake structure
is unnecessary, because we can fail immediately during the Hello-
stage of the handshake if the ExtendedMasterSecret extension
is not negotiated; accordingly, the non-ExtendedMS code-path
can be eliminated from the key derivation logic.
A way needs to be found to allow fixing parts of the SSL configuration
at compile-time which removes this overhead in case it is used,
while at the same time maintaining readability and backwards
compatibility.
This commit proposes the following approach:
From the user perspective, for aspect of the SSL configuration
mbedtls_ssl_config that should be configurable at compile-time,
introduce a compile-time option MBEDTLS_SSL_CONF_FIELD_NAME.
If this option is not defined, the field is kept and configurable
at runtime as usual. If the option is defined, the field is logically
forced to the value of the option at compile time.
Internally, read-access to fields in the SSL configuration which are
configurable at compile-time gets replaced by new `static inline` getter
functions which evaluate to the corresponding field access or to the
constant MBEDTLS_SSL_CONF_FIELD_NAME, depending on whether the latter
is defined or not.
Write-access to fields which are configurable at compile-time needs
to be removed: Specifically, the corresponding API itself either
needs to be removed or replaced by a stub function without effect.
This commit takes the latter approach, which has the benefit of
not requiring any change on the example applications, but introducing
the risk of mismatching API calls and compile-time configuration,
in case a user doesn't correctly keep track of which parts of the
configuration have been fixed at compile-time, and which haven't.
Write-access for the purpose of setting defaults is simply omitted.
2019-06-11 12:43:27 +00:00
|
|
|
#define MBEDTLS_SSL_CONF_EXTENDED_MASTER_SECRET \
|
|
|
|
|
MBEDTLS_SSL_EXTENDED_MS_ENABLED
|
|
|
|
|
#define MBEDTLS_SSL_CONF_ENFORCE_EXTENDED_MASTER_SECRET \
|
|
|
|
|
MBEDTLS_SSL_EXTENDED_MS_ENFORCE_ENABLED
|
|
|
|
|
|
2019-03-18 12:39:49 +00:00
|
|
|
/* X.509 CRT parsing */
|
|
|
|
|
#define MBEDTLS_X509_USE_C
|
|
|
|
|
#define MBEDTLS_X509_CRT_PARSE_C
|
|
|
|
|
#define MBEDTLS_X509_CHECK_KEY_USAGE
|
|
|
|
|
#define MBEDTLS_X509_CHECK_EXTENDED_KEY_USAGE
|
2019-06-10 14:08:43 +00:00
|
|
|
#define MBEDTLS_X509_REMOVE_INFO
|
2019-03-18 12:39:49 +00:00
|
|
|
#define MBEDTLS_ASN1_PARSE_C
|
|
|
|
|
|
|
|
|
|
/* X.509 CSR writing */
|
|
|
|
|
#define MBEDTLS_X509_CSR_WRITE_C
|
|
|
|
|
#define MBEDTLS_X509_CREATE_C
|
|
|
|
|
#define MBEDTLS_ASN1_WRITE_C
|
|
|
|
|
|
|
|
|
|
/* RNG and PRNG */
|
|
|
|
|
#define MBEDTLS_NO_PLATFORM_ENTROPY
|
|
|
|
|
#define MBEDTLS_ENTROPY_C
|
|
|
|
|
#define MBEDTLS_HMAC_DRBG_C
|
|
|
|
|
|
|
|
|
|
#define MBEDTLS_OID_C
|
|
|
|
|
#define MBEDTLS_PLATFORM_C
|
|
|
|
|
|
|
|
|
|
/* I/O buffer configuration */
|
|
|
|
|
#define MBEDTLS_SSL_MAX_CONTENT_LEN 2048
|
|
|
|
|
|
|
|
|
|
/* Server-side only */
|
|
|
|
|
#define MBEDTLS_SSL_TICKET_C
|
|
|
|
|
#define MBEDTLS_SSL_SRV_C
|
|
|
|
|
|
|
|
|
|
#if defined(MBEDTLS_USER_CONFIG_FILE)
|
|
|
|
|
#include MBEDTLS_USER_CONFIG_FILE
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#include <mbedtls/check_config.h>
|
|
|
|
|
|
|
|
|
|
#endif /* MBEDTLS_BAREMETAL_CONFIG_H */
|
