Product security
Providing the foundation for secure embedded and analog development
Facilitating innovation with a security mindset
As product security requirements and regulations rapidly evolve, we leverage our global team of experts to monitor changes, adapt our development workflows and empower customers to achieve their security requirements. We are committed to continually developing our expertise and are actively participating in the working groups creating the harmonized standards for the Cyber Resilience Act (CRA). Our products help you build secure end equipments to comply with relevant regulations, such as UN R155 and the related ISO/SAE 21434 standard, US CISA, Europe CRA, China GB and other emerging standards.
Our security enablers
Assessing security should start with three fundamental questions:
1. What is being protected? (Asset)
2. Who or what are we protecting against? (Threat and threat probability)
3. What is the attack surface? (Exposure points)
Understanding the targeted application, a risk assessment will identify the assets that need protection and the consequences if the protection fails. Security measure(s) that can be implemented in the system and are adequate to mitigating the threats may then be identified and chosen based on their ability to materially reduce risk. Once the security measures are identified, determine the security enabler(s) needed to support the measures.
Cryptographic acceleration
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.
Debugging security
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.
Device identity/keys
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.
External memory protection
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.
Initial secure programming (overbuild protection plus counterfeiting)
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.
Networking security
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).
Physical security
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.
Secure boot
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.
Secure firmware and software update
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.
Secure storage
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.
Software intellectual Property (IP) protection
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.
Trusted Execution Environment (TEE)
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.
Report a potential vulnerability
Our Product Security Incident Response Team (PSIRT) oversees the process of accepting and responding to reports of potential security vulnerabilities involving our semiconductor products, including hardware, software and documentation.