跳到主要内容

Introduction

All ESP ZeroCode firmware is designed and built with the best security practices in mind. On this page, we will look at some of the common security settings and configurations that we have chosen for all ESP ZeroCode based products. We will also look at how ESP ZeroCode products can get standards based security certifications.

Security Practices​

ESP ZeroCode products are built with the following security practices in mind.

Hardware Security​

For most connected products, security begins with the hardware. At the hardware level, ESP ZeroCode products have the following features enabled out of the box:

  • Secure Boot: Secure Boot (or Trusted Boot) ensures that a chip can only execute firmware that is cryptographically signed by an authorised entity. All ESP ZeroCode products are configured to have Secure Boot enabled. This guarantees that only trusted firmware can be executed on these devices. The trusted firmware is signed securely by cryptographic keys that are maintained in read-protected vaults in AWS infrastructure. This gives them the highest level of protection of leaks and tampering.
  • Flash Encryption: ESP ZeroCode Products have, by default, flash encryption enabled. This protects in two ways. First, the firmware that is executing on the chip is encrypted on flash. This prevents attackers from reading the firmware, or easily tampering with the same. Secondly, this also encrypts the configuration data that is stored on the flash. The configuration data could include the end-user's Wi-Fi credentials, the device's credentials for authenticating with the cloud, or ecosystem based credentials (NoC, DAC in case of Matter) as may be applicable for the device.
  • Disabled Debug Interfaces: ESP ZeroCode modules are shipped out with default debug interfaces, like JTAG and UART-download mode disabled.

Note that customers may opt to disable any of these default-on configurations at the time of placing orders.

Software Security​

The ESP ZeroCode firmware incorporates the most common security guidelines in software. Some of these include:

  • No default passwords are used in the ESP ZeroCode firmware.
  • Only the minimum necessary services (and network ports) are running in the ESP ZeroCode firmware.
  • Resetting the device to factory, or erasing any configuration information, requires a physical action by the user of the device.
  • Per-device unique identification: For both the solutions that ESP ZeroCode supports, per-device unique identification is used. In the case of the Matter framework this is enabled by means of the unique Device Attestation Certificates stored on the device. In the case of ESP RainMaker, this includes the unique certificates that are registered with the cloud. In both the cases, care is taken to store the device keys in the most secure manner possible as may be supported by the SoCs. For example, few SoCs allow the ECDSA keys to be locked in the hardware peripheral. ESP ZeroCode firmware running on these SoCs will use this mechanism for protecting the keys. For other SoCs, the next most secure mechanism will be used.
  • All production capable ESP ZeroCode firmware supports Over the Air (OTA) upgrades. Supporting OTA upgrades is important to ensure that fixes can be deployed for any new issues or bugs that are found.
  • The ESP ZeroCode firmware only allows upgrades of cryptographically signed images. These images must be signed with a trusted signing key that is owned by Espressif (or the product vendor).

Security Practices​

Some of the security practices that we follow are listed below:

  • Commitment to upgrades: All ESP ZeroCode products have a commitment of supporting firmware upgrades for any critical security issues for a minimum of 3 years. Product manufacturers also have an option to choose a longer support period for these upgrades.
  • Monitoring for Vulnerabilities: Espressif monitors the various software components within ESP ZeroCode for any published known vulnerabilities. As new vulnerabilities are found, the individual components would be updated, and the fixed firmware be available as a part of firmware upgrade, depending on the severity of issues reported.
  • Bug Reporting Mechanism: Espressif has a published bug reporting mechanism where security researchers and others could report security vulnerabilities. We have a track record of working closely with security researchers helping them perform responsible disclosures alongside fixes.
  • Penetration Testing: Espressif periodically performs network penetration testing on the ESP ZeroCode firmware. Any vulnerabilities discovered through these mechanisms are fixed and incorporated in the next firmware upgrade.

Security Certifications​

We are currently working on validating that ESP ZeroCode based products can pass the following security certifications:

  • PSWG Level 1 Security Certification (Matter based Products)
  • ETSI 303 645 Security Certification (ESP RainMaker based Products)

We will share more information on this once the certifications are available. These certifications at our end ensure that if you wish to get your ESP ZeroCode products certified, they can sail through the certifications quickly.

Certification Collateral​

For product vendors who wish to apply for security certification of ESP ZeroCode products, we can help you get through this process faster. We make documentation collateral available to speed up the process of filling the forms and questionnaires needed for these certifications. Please reach out to your ESP ZeroCode support for requesting support for the specific security certifications that you are looking out for.

On this page