Password Managment

[Anonymous]

My BLE device design requires a password.  The password will be entered via a phone app.  There will be a hard coded default.  What is the best way to handle this?

   

Perhaps:

   

Create a custom characteristic, write only, called password.

   

Save new passwords to NV memory.

       

Thanks

   

Rich

[Anonymous · Accepted solution]

Depending on how much security you want, there are multiple ways to do this:

   

If you want to prevent hardware compromise, you will want to store the password as a hashed value on the local side, rather than the "plaintext".

   

If you are only worried about the software/app interaction for security of the password, then as you listed above in the "Perhaps:" section will work well. Since you are working with sensitive data, where data corruption over-the-air might be a problem; you could try using the confirmed or "signed" writes to make sure the password doesn't get corrupted on transmission.

[Anonymous]

Thanks for your help on this.  What do I need to know about "signed write" other than checking that box in the GUI?

       

Rich

[Anonymous]

Alright, looking at the documentation for specifics: If you read through the API documentation for CyBle_GattcReliableWrites(connHandle, *writePrepReqParam, numOfRequests), that is the write characteristic function you will want to use. It validates the data to both sides before it writes it to the server.

   

This will generate: CYBLE_EVT_GATTS_EXEC_WRITE_REQ at the GATT server end, this is where you would check the value on the server side to be valid as a password argument

   

then CYBLE_EVT_GATTC_EXEC_WRITE_RSP at the GATT client end, this is where you validate that the data you sent to the server and the data it sent back are exactly the same.

   

Errors will be generated if a step fails. Documentation for the write function is on page 154 of the v3_30 BLE component PDF file.

   

The only difference between the reliable write and the regular characteristic write is that the client will receive the second event to "verify" the data being written is correct before the data is written. All of the hooks and switches should behave similar to the other BLE functions in the software for the Cypress chips.