The hardware module name otherName SAN contains 2 OIDs:
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
The first, type-id, is the one that identifies the otherName as a
HardwareModuleName. The second, hwType, identifies the type of hardware.
This change fixes 2 issues:
1. We were erroneously trying to identify HardwareModuleNames by looking
at hwType, not type-id.
2. We accidentally inverted the check so that we were checking that
hwType did NOT match HardwareModuleName.
This fix ensures that type-id is correctly checked to make sure that it
matches the OID for HardwareModuleName.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
When parsing a subject alternative name of type otherName, retain the
type-id field of the otherName. Previously this was not copied to the
mbedtls_x509_san_other_name struct when it should have been.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Remove the workaround for psa_key_agreement_internal to
have a shared_secret array always non-zero. The spec is
recently updated so that PSA_RAW_KEY_AGREEMENT_OUTPUT_MAX_SIZE
is always non-zero
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
New bignum modules are only needed when the new ecp_curves module is
present. Remove them when they are not needed to save code size.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The original IAR fix submitted to TF-M directly changed asm to __asm.
But mbed TLS now has a workaround for such cases hence just remove the
original change modification.
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
Some of the error strings that should be printed with the
error preprocessor directive are missing quotes
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
Applied the same change as in mbed-crypto for using this as a sub
project with the IAR toolchain. Use __asm generic ,and avoid empty
enum. Avoid declaration of array with null size. This is a porting
of the original patch contributed to trusted-firmware-m.
Signed-off-by: TTornblom <thomas.tornblom@iar.com>
Signed-off-by: Michel Jaouen <michel.jaouen@st.com>
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
If passed a zero length, AES CBC could potentially corrupt the passed
in IV by memcpying it over itself. Although this might be ok with
more recent compilers, its not for every compiler we support. Found
by coverity.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
