This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3220S: Possible to set the 32-byte PSK directly through API call in CC3220?

Part Number: CC3220S

Hi team,

Asking on behalf of a customer evaluating CC3220:

I'm looking for a way to set the PSK and not the passphrase. I.e. the 32 byte key that is the result of the pbkdf2 with passphrase and ssid as arguments.

From the wpa_supplicant.conf file:

# psk: WPA preshared key; 256-bit pre-shared key # The key used in WPA-PSK mode can be entered either as 64 hex-digits, i.e., # 32 bytes or as an ASCII passphrase (in which case, the real PSK will be # generated using the passphrase and SSID). ASCII passphrase must be between # 8 and 63 characters (inclusive).

Thanks,

/ Wolfgang

  • Hi Wolfgang,

    This isn't supported on our device. Why do they want to do this?

    Best,
    Ben M
  • Hi Ben,

    My customer uses a proprietary sub-1GHz network to control the nodes of the system. The wifi nodes are powered down until a command is sent over the sub-1 protocol to wake up wifi, and the command includes the wifi login credentials which are set (and may be different) on every wake up. All nodes are battery powered.

    See further comments from customer:

    The provisioning protocol over our low bandwidth 868MHz radio was designed to enable nodes with limited processing power to be able to connect quickly. The PBKDF2 operation with the SSID and the passphrase is a slow operation by design. I've worked with WLAN modules where this operation can take seconds. Therefor we send the PSK already "calculated".

    Our radio protocol also doesn't allow very long packet. We have a limit of 44 bytes payload. This means that we can not use the full length/entropy of the passphrase which is 63 ascii characters. The PSK however is 32 bytes and we can use the full range as well as utilizing hardware random number generators for this.

    Thanks,

    / Wolfgang

  • Hi Wolfgang,

    Thank you for the additional detail.

    This does somewhat play to our strengths because the operation does not take seconds on our device. Our built-in hardware accelerators help keep that time much shorter than a second. Unfortunately, there isn't much we can do about the second constraint. Though it seems like they shouldn't have much trouble using fragments of the passphrase by splitting it up across two different packets.

    Best Regards,
    Ben M