Thank you again for attending our session on Embedded Security. Here are the questions that followed the presentation and their answers. If you have additional questions, be sure to reach out.
Do all i.MX processors support secure boot to establish the root of trust?
NXP: Yes, all i.MX processor families support secure boot utilizing either HAB or AHAB depending on the processor family. Newer processors also support ECDSA key support for High Assurance Boot.
In your presentation you mentioned secure boot and encrypted boot. Can they both be used together?
NXP: Yes, you need secure boot before you can do the encrypted boot step. You do not want to encrypt an image that has not been authenticated first to prevent executing untrusted code containing malware. The encrypted boot feature adds an extra security operation on top of secure boot.
Can the secure boot process be used with mainline u-Boot and Linux kernel versions?
Can trusted execution environments like OPTEE be authenticated to extend the root of trust?
NXP: Yes, OPTEE or any other TEE can be authenticated to extend the root of rust.
What i.MX processor or Digi SOM would you recommend we start with to explore the security features described today?
Digi: Well, it really depends on your end application. As all i.MX processors and Digi ConnectCore® SOMs support the secure boot features we discussed today, you would need to see what additional functionality is required. The new i.MX 8 processors are certainly very popular and provide a range of security and processing to fit your application.
You can find a list of ConnectCore SOM options as well as a product comparison tool on the Digi SOMs page. Or get in touch with a Digi representative from the Contact Us link.
Where can I get more information on the secure boot process for i.MX processors?
NXP: We have detailed documentation such as application notes on our website and step-by-step guides on Code Aurora for a secure and encrypted boot to get your system securely booted and establishing the root of trust:
Digi: We have fully integrated secure boot as part of the Digi TrustFence® security building blocks for Linux and Android. You can find the information you need for enabling and using it as well as explanations on the concepts and infrastructure is in the Digi documentation.
If the module becomes infected, the data will be altered before encryption. How do you defeat this type of malware?
NXP: Users need to perform secure boot before you can do the encrypted boot step. You do not want to encrypt an image that has not been authenticated first to prevent executing untrusted code containing malware. The encrypted boot feature adds an extra security operation on top of secure boot.
What is the user interface that allows users to securely update firmware and manage certificates? Do customers perform these functions or are their managed service providers that do this?
NXP: All things related to firmware management and OS management is currently performed by our partners (clouds and 3rd party). NXP does not currently have in house service for that but can provide partner information.
Digi: For Digi devices, you can perform secure firmware updates with Digi TrustFence®. See the TrustFence documentation.
We have noticed NXP endorsed the Vigiles™ in multiple places. Are the patches and mitigations validated by NXP?
NXP: NXP Linux software GA releases use the Vigiles™ tool to ensure patches are correctly applied and validated. For customer specific software, Vigiles™ relies on upstream validations. In addition, Vigiles™ provides reference links to exploits/mitigation when available so customers can set up to validate the fix or apply the respective mitigations. See the Vigiles™ content for more information.
How does root of trust help if the supply chain fails? Infected programs are loaded into the device?
NXP: Secure manufacturing is key. Our manufacturing webinar provides some useful information to address this.
NXP also offers Manufacturing Protection features on select i.MX processors. See our manufacturing information on securing the edge.
Are you allowing boot updates/upgrades?
NXP: The initial Secure Boot starting from the Internal immutable On chip ROM can not be updated/upgraded. The secondary bootloader used by the customer however can be updated using various mechanism. An example of performing Secure Over the Air updates is provided in the Secure Over-the-Air Prototype for Linux Using CAAM and Mender or SWUpdate application note.
Digi: We provide instructions for performing secure firmware updates (which can include a signed / encrypted bootloader image) in the Digi TrustFence® documentation.
Does NXP charge for EdgeLock™ 2GO services?
NXP: Yes, the service uses a pay as you go model (fee per keys / certificate issuance, revocation). NXP can provide budgetary quote for your specific application. See the EdgeLock 2GO page for details.
Hi Asim, would you mind commenting on situations when EdgeLock™ 2GO makes sense to use and when using the crypto features of I.MX 8 makes sense to use?
NXP: EdgeLock™ 2GO is a SaaS service whereas the i.MX is a secure processor, so they do not compare. EdgeLock™ 2GO is available on i.MX and other SoC’s attached to a SE050 SE. EL 2GO can manage certificates on i.MX + SE050 devices on behalf of the customers; SE050 + EL 2GO enhances the security capabilities of the i.MX (keys management, root of trust, zero touch cloud onboard). See the EdgeLock 2GO white paper.
However customers can still manage the keys / certificates on the i.MX processors leveraging the cryptographic / key storage capabilities of the i.MX. See the i.MX Encrypted Storage Using CAAM Secure Keys
application note.
Can we update the application code using Digi Remote Manager? I have heard only the operating system can be updated via Digi Remote Manager?
Digi: Yes, Digi Remote Manager provides full flexibility on updates. It can be just applications, selected partitions or a full system update.
What guarantees do you provide to customers using your security solutions?
NXP: While NXP has implemented advanced security features, all products may be subject to unidentified vulnerabilities. Customers are responsible for the design and operation of their applications and products to reduce the effect of these vulnerabilities on customers’ applications and products, and NXP accepts no liability for any vulnerability that is discovered. Customers should implement appropriate design and operating safeguards to minimize the risks associated with their applications and products.
Digi: Agreed. We have excellent support and documentation to help customers build in security into their products, as well as a Wireless Design Services team that can provide expert engineering support along the way. Contact us to learn more.