Security

Threat question:
How can you achieve your latency or throughput performance while maintaining your keys/data/code security?

Simple explanation:
You can leverage the efficiency of dedicated hardware to implement your cryptographic objectives. It can be provided as hardware or as ROM, such as advanced encryption standard (AES) tables. In some cases, the device does not provide cryptographic acceleration, but we provides generic software C libraries.

Threat question:
Can somebody use a debugger probe to read out your assets?

Simple explanation:
You can lock out debugging ports. Some devices will provide various options such as permanent locks, or you can create a password/credential per device to allow reopening of the debugging port.

Threat question:
How can you identify and authenticate the identity of your device to the network?

Simple explanation:
You can evaluate and elect to use an identity that TI stores in the devices. It may have the form of a unique ID (UID) and optionally a signature (certificate) key whose public key is easily shareable with a cloud service, for example.

Threat question:
How do you expand your application with off-chip flash or double-data-rate (DDR) memory? 

Simple explanation:
Quad SPI (QSPI)/external memory interface (EMIF) with execute-in-place provides an easy way to expand your application. The capability to decrypt/authenticate on the fly can assist you in protecting confidentiality/authenticity while allowing only your application to run on the CPU.

Threat question:
You want to program your chip in an untrusted environment (such as a foreign manufacturing facility). How can you ensure that your application/keys are not altered, stolen or replaced?

Simple explanation:
We provide a methodology that you can evaluate and elect to use to strengthen the confidentiality, integrity and authenticity of initial firmware or keys programmed in an untrusted facility or during the first boot of the application.

Threat question:
How can you get optimal performance while connecting to the network with known protocols?

Simple explanation:
You can use networking protocol accelerators for Internet Protocol security (IPsec), Transport Layer Security (TLS), or dedicated hardware and firmware to these protocols (A firmware denotes a piece of software in ROM or a piece of software that we program at manufacturing).

Threat question:
If somebody has physical access to your application, can they open the package or use the power supply to get access to your assets?

Simple explanation:
Removing the package and measuring the answer time or power consumed by a protocol request are powerful attacks that anyone with access to the device can use. We provide various hardware and software features to help you thwart these types of attacks

Threat question:
Your application runs off an external flash. How can you make sure that only your software runs on your devices?

Simple explanation:
Methodologies can help secure the boot process by preventing the loading of software (bootloaders, drivers, operating systems, applications) not signed with an acceptable digital signature.

Threat question:
How can you update your application remotely and securely? Nobody should be able to spy, impersonate or replay your updates.

Simple explanation:
You can encrypt and sign the updated image for part or all of the application to help mitigate against efforts to spy, impersonate or replay your firmware updates. We provide various product-dependent features such as over-the-air updates (OTA) while the application is running, hot swap and load for external flash.

Threat question:
If somebody tampers with your device or finds a software weakness to exploit, are your critical keys and data secure?

Simple explanation:
Keys and data are stored in a part of the memory that is isolated from the rest of the code and data. We provide various security features ranging from encrypted blob of keys, anti-tamper modules with master keys, and a private key bus between the nonvolatile memory and the cryptographic accelerators.

Threat question:
Your software IP (code) represents a significant investment that you’d like to protect. Can you protect its confidentiality during different parts of your product’s life cycle?

Simple explanation:
Firewalls, IP protection zones/regions, encryption and debugging lockout of part or all of the application are some of the security features that we provide to help you address these types of concerns.

Threat question:
Now that you have developed, audited and/or certified your application, how can you make sure that vulnerability in another application running on the same central processing unit (CPU) cannot be exploited to attack your assets: keys, data and code?

Simple explanation:
A TEE enables you to isolate your application (keys/data/code) at run time from other applications, helping you reduce the risk of security vulnerabilities in other parts of the software. A TEE can either be a physically separated MCU or a virtually isolated processing unit