We prototyped our software with Secure Link disabled in the wfx-fullMAC-driver since it has zero benefit to us and just wastes code space, cpu time, and battery energy. Since this worked fine on the WGM160P module that came with the starter kit (SLWSTK6121A) I paid no further attention to Secure Link, but now on a production device it turns out it won't run at all because Secure Link is enabled on its WF200 (yet evidently not on the one in the starter kit) and obnoxiously this causes it to refuse to talk to the host in plaintext anymore!
This is really annoying! There doesn't seem to be separate part numbers for this (like there are with the WF200 and WFM200), nor is secure link even mentioned in the WGM160P datasheet at all.
And why does the WF200 even care whether the host chooses to enable SecureLink or not? The entire security model seems wonky here. The benefit of SecureLink is entirely to the host: if it is worried about physical attacks on the SDIO link to the WF200, then the host may demand to authenticate the WF200 and establish an encrypted link with it before entrusting the WF200 with secrets such as wifi passwords and (plaintext) packet data. In contrast, the WF200 itself has (on power-up) no secrets to protect other than the SecureLink MAC key (which cannot be retrieved by the host anyway as far as I can tell), hence it doesn't have any reason to authenticate the host or complain if the host chooses to skip SecureLink setup. The only command that could be viewed as being "privileged" for which the WF200 might want to require authentication is PREVENT_ROLLBACK (which is fine since that command is only relevant for hosts that use Secure Link anyway).
Is there any hope Silicon Labs will consider removing this pointless restriction in a future WF200 firmware update?
Also, BTW, is there a preferred email address or contact form for reporting security vulnerabilities? since I'm fairly sure I spotted a major (but easy to fix) one in the wfx-fullMAC-driver that completely defeats Secure Link.
The WGM160P comes indeed with the Secure Link Enforced. The biggest Secure Link burden is the pairing between the WF200 and the host processor. In the WGM160P case, the security pairing is done by Silicon Labs in production.
The other Secure Link impacts can be mitigated. For example, a host can use the lesser demanding cryptographic Secure Link algorithm (more information in the Secure Link documentation) to quicken the initial security handshake. Once the Secure Link handshake has been performed, the AES encryption can be disabled on the WF200 APIs using the sl_wfx_secure_link_configure() API.
You can contact your Silicon Labs Sales representative for those kind of requests if it is still an issue for your application.