Secured Interfaces#
All product interfaces shall be appropriately secured by the manufacturer.
The interfaces to be secured will vary by product configuration. For example, in an NCP topology the NCP interface must be secured. Debug interfaces should always be locked. Wireless interfaces should be secured by using strong pairing and commissioning methods and by enabling encrypted and authenticated transmissions.
While securing the interfaces is in the end your responsibility, Silicon Labs provides the tools to enable that security.
Both Series 1 and Series 2 devices are designed to support securing debug access. For Series 1 devices, that functionality is provided through writing a Debug Lock word to the device. Unlocking the device erases the main application and the key material stored in the Lockbits page. For Series 2 devices, securing debug access is done through the device’s Secure Engine. Both allow the developer to lock the debug port itself. See Silicon Labs Gecko Bootloader User’s Guide for Series 3 and Higher, Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher (series 1 and 2 devices), or UG266: Silicon Labs Gecko Bootloader User’s Guide for GSDK 3.2 and Lower for an overview of securing debug access, and Series 2 Secure Debug for details on the Series 2 implementation. UG104: Testing and Debugging Applications for the Silicon Labs EFR32MG Platforms provides an overview of the various application testing stages and the debug access (hardware and software) required in each.
For more information on Wireless interface security in the different protocols, see the following:
Bluetooth LE Fundamentals and relevant KBAs
AN1037: Apple HomeKit Over Bluetooth®
UG235.03: Architecture of the Silicon Labs Connect Stack v2.x
UG435.03: Architecture of the Silicon Labs Connect Stack v3.x