Release Notes
Table of Contents
Introduction
This is a GA release of the Core SDK 4.30.01.02 for MSP432E4 devices.
Documentation
Open the documentation overview web page file in the SDK’s Doc folder for a full list of documentation.
What’s New
A summary of changes made in the current release of this product can be found in the product Change Log.
This release supports the production release of SysConfig. All examples have been updated to use sysconfig. The drivers/empty_legacy example is provided as an example of how applications were supported in earlier releases.
The Button and LED modules have been added. These modules were previously provided in the the SAIL plugin. They have been updated and moved to the Core SDK. The APIs are defined in ti/drivers/apps/Button.h and ti/drivers/apps/LED.h respectively.
Upgrade and Compatibility Information
This release breaks compatibility with previous releases of the Core SDK in the following ways:
Example/SysConfig Updates
All examples in this release have been updated to use SyscConfig. SysConfig generates .c and .h files with the various configuration data structures and constants. These files were previously written by hand. Check the User’s Guide for more information about SysConfig.
Here is a short summary of the changes to each example:
Previous Release | This release |
---|---|
Hand written files with #defines and C structures | example.syscfg (generates files with #defines and C structures) |
Board.h, CCXXXX_LAUNCHXL.h | ti_drivers_config.h |
CCXXXX_LAUNCHXL.c | ti_drivers_config.c |
#defines are named Board_GPIO_LED0, etc. | #defines are named CONFIG_GPIO_LED_0, etc. |
pin settings common to all examples are shown in Board.html | pin settings unique to each example are commented in ti_drivers_config.h |
IAR RTOS plugin .dll
The ROV tool for IAR requires an update to work properly. If you are an ROV user, follow the instructions on this forum page: https://e2e.ti.com/support/processors/f/791/t/832561. If you don’t use ROV, you can proceed with the standard debugging sessions. The ROV tool does not affect any other funcationality.
Crypto API changes
The Crypto APIs have changed in the following ways:
TIDRIVERS-3849
Public and private keys as well as signature components hash, r, and s are now represented in octet string (OS) format as defined by SEC 1: Elliptic Curve Cryptography when using the ECDSA driver. Conversion from OS format to elliptic curve parameters and coordinates is now handled internally within the ECDSA driver itself.
The move from little-endian integers to represent public and private keying material to OS format has the following implications:
Previous Release | This release |
---|---|
Private keying material considered as little-endian integer | Private keying material considered as big-endian integer |
Hash considered as little-endian integer | Hash considered as big-endian integer |
r considered as little-endian integer | r considered as big-endian integer |
s considered as little-endian integer | s considered as big-endian integer |
Public keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. | Public keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer. |
As a result, public keys are now one byte longer than before and formatting of public and private keys as well as signature components r, s, and hashes within the application must be reviewed.
In practice, this will mean reversing the buffers containing the private key, r, s, hash, and public key coordinates as well as adding the formatting byte to the public keying material.
Since most networking stacks specify public keys to be formatted in OS format for transport over the network, this should result in the application no longer needing to convert to and from OS format. The OS formatted public key and signature received over the network can be used and stored without reformatting within the application itself.
Previously, the hash output of the chosen hash function had to be reversed in order to pass it into the ECDSA driver. This is no longer required. The hash output may be passed into the driver without any byte reversal.
Here is a table that illustrates the changes at byte level:
Parameter | Previous Release | This release |
---|---|---|
Private keying material | { |
{ |
Hash | // This is the byte reversed SHA256 hash |
// This is the SHA256 hash of the ASCII string |
r | {0xa6,0x41,0x5f,0xc9,0xf0,0x29,0xdd,0xb5, |
{0x70,0x28,0x82,0xe8,0xe8,0xca,0x0d,0xd2, |
s | {0xb3,0xf5,0x2b,0x0a,0x6f,0x31,0x04,0x25, |
{0xc0,0x16,0x38,0xec,0x93,0xa7,0x6f,0xdf, |
Public keying material | { |
{ |
TIDRIVERS-3847
The per-message secret number (PMSN) parameter of the ECDSA_OperationSign struct was removed. Signing a message with a known PMSN would allow attackers to derive the private key from the signature. On devices with a keystore, this method could also be used to exfiltrate the private key from the keystore. Consequently, the driver will ensure that a suitable PMSN is generated and discarded internally. On CC26X2, the TRNG is used to generate the PMSN internally.
TIDRIVERS-3816
Public keys, private keys, public Vs, private Vs, hashes, r, generator points, pre-shared secrets, and shared secrets, are now represented in octet string (OS) format as defined by SEC 1: Elliptic Curve Cryptography when using the ECJPAKE driver. Conversion from OS format to elliptic curve parameters and coordinates is now handled internally within the ECJPAKE driver itself.
The move from little-endian integers to represent public and private keying material to OS format has the following implications:
Previous Release | This release |
---|---|
Private keying material considered as little-endian integer | Private keying material considered as big-endian integer |
Private v material considered as little-endian integer | Private v material considered as big-endian integer |
Hash considered as little-endian integer | Hash considered as big-endian integer |
r considered as little-endian integer | r considered as big-endian integer |
Pre-shared secret considered as little-endian integer | Pre-shared secret considered as big-endian integer |
Public keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. | Public keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer. |
Public V material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. | Public V material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer. |
ZKP generator point keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. | ZKP generator point keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer. |
Shared Secret keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. | Shared secret keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer. |
As a result, public keys, public Vs, shared secrets, and ZKP generator points are now one byte longer than before and formatting of all public V, private v, public keys, private keys, r, hashes, pre-shared secrets, and shared secrets within the application must be reviewed.
In practice, this will mean reversing the buffers containing the private key, private v, r, hash, pre-shared secret, public key coordinates, public V coordinates, generator point coordinates, and shared secret coordinates as well as adding the formatting byte to the public key, public V, generator point, and shared secret.
Since most networking stacks specify public keys to be formatted in OS format for transport over the network, this should result in the application no longer needing to convert to and from OS format. The OS formatted public key and signature received over the network can be used and stored without reformatting within the application itself.
Previously, the hash output of the chosen hash function had to be reversed in order to pass it into the ECJPAKE driver. This is no longer required. The hash output may be passed into the driver without any byte reversal.
Here is a table that illustrates the changes at byte level:
Parameter | Previous Release | This release |
---|---|---|
Private keying material | { |
{ |
Private v material | { |
{ |
Hash | // This is the byte reversed SHA256 hash |
// This is the SHA256 hash of the ASCII string |
r | { |
{ |
Pre-shared secret | // The pre-shared secret can be any |
// The pre-shared secret can be any |
Public keying material | { |
{ |
Public V material | { |
{ |
ZKP generator | // NIST-P256 generator point |
// NIST-P256 generator point |
Shared secret | { |
{ |
TIDRIVERS-3779
Public and private keys for the ECDH driver are now represented in octet string (OS) format as defined by SEC 1: Elliptic Curve Cryptography. Conversion from OS format to elliptic curve parameters and coordinates is now handled internally within the ECDH driver itself.
The move from little-endian integers to represent public and private keying material to OS format has the following implications:
Previous Release | This release |
---|---|
Private keying material considered as little-endian integer | Private keying material considered as big-endian integer |
Public keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. | Public keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer. |
Shared Secret keying material considered as concatenation of affine coordinates x and y. Each coordinate considered as a little-endian integer. | Shared secret keying material considered as concatenation of a formatting byte (0x04) and affine coordinates x and y. Each coordinate considered as a big-endian integer. |
As a result, public keys and shared secrets are now one byte longer than before and formatting of public and private keys within the application must be reviewed.
In practice, this will mean reversing the buffers containing the private key and the public key coordinates as well as adding the formatting byte. Since most networking stacks specify public keys to be formatted in OS format for transport over the network, this should result in the application no longer needing to convert to and from OS format. The OS formatted public key received over the network can be used and stored without reformatting within the application itself.
Here is a table that illustrates the changes at byte level:
Parameter | Previous Release | This release |
---|---|---|
Private keying material | { |
{ |
Public keying material | { |
{ |
Shared secret | { |
{ |
Host Support
See the SDK release notes for a description of which host operating systems are supported in this release.
Dependencies
See the SDK release notes for a description of which components and tools are required to work with this product.
Device Support
See the SDK release notes for a list of TI devices that are supported in this product.
Validation Information
The Core SDK was validated with the following components:
- Code Composer Studio 9.2.0
- ARM 18.12.3.LTS
- GNU Code Generation Tools
- ARM GCC 7-2017-q4-major
- IAR Code Generation Tools
- ARM 8.32.2
- FreeRTOS 10.1.1
- XDCTools 3.60.00
Known Issues
ID | Summary |
---|---|
TIRTOS-1959 | IAR project is not rebuilt after .syscfg file is modified |
TIDRIVERS-3636 | I2C_transfer() occasionally fails when called from an interrupt context |
TIDRIVERS-1642 | NVSSPI25x driver does not work when using internal SPI CS |
Versioning
This product’s version follows a version format, M.mm.pp.bb, where M is a single digit Major number, mm is 2 digit minor number, pp is a 2 digit patch number, and b is an unrestricted set of digits used as an incrementing build counter.
Prior Release Changes
A summary of changes made in previous releases of this product can be found in the product Change Log