Wifi provisioning with Security level 2 - confused

[cskilbeck]

When using Security level 2, a QR code is used for provisioning via a mobile app. I'm confused about this comment in the wifi_prov_mgr sample.

Code: Select all

#if CONFIG_EXAMPLE_PROV_SEC2_DEV_MODE
    /* This pop field represents the password that will be used to generate salt and verifier.
     * The field is present here in order to generate the QR code containing password.
     * In production this password field shall not be stored on the device */
    const char *username = EXAMPLE_PROV_SEC2_USERNAME;
    const char *pop = EXAMPLE_PROV_SEC2_PWD;

In particular, the bit which says 'In production this password field shall not be stored on the device'. My question is:

Given that the QR code encodes the username and password in, effectively, plaintext (so it's not a secret), what's the problem with storing it on the device? If there's a sticker on the device with the QR code on it then the username and password are basically 'stored on the device' in a roundabout way already, right?

Or am I just misunderstanding something here?

[liaifat85]

A more secure approach would involve securely transmitting the credentials during the provisioning process without storing them persistently on the device.

[cskilbeck]

But the QR code is generated using those values...?

[rdinge]

Hi, I've been confused also by this problem, that I have seen raised on other forums as well, so in hope it will help someone one day (or maybe my future self), please challenge if incorrect:

1. Security level 2 doesn't provide more security if the attacker can have physical access to the device with the QR-code stuck on it

It is to make sure that only derived keys are used for communication. Never the original password (even encrypted) is transfered over the air. That makes it more robust to all sorts of attack vectors (for example dictionaries attacks) when eavedropping on the communication.

2. Storing the salt/verifier on the device is just to save firmware space

I believe that storing the original password or salt/verifier is not more secure anyway, but instead of having the original password and the code to derive the salt/verifier on the device with the required algorithms, you directly store the latter. Your firmware doesn't then need the algorithms, which saves some firmware space. In the manufacturing process, the machine flashing the manufacturing partition has the algorithms.

So all in all, even if the QR-code is stuck on the device, the scheme is more secure than Security level 1 in the presence of an eavesdropper.