2 Replies Latest reply on Oct 31, 2019 8:48 AM by JoOr_4004241

    CYW20719 BLE Does Not Generate Local_Identity_Keys Events

    JoOr_4004241

      I am using a CYBT-423028-EVAL board with CYBT-423028-02/CYW20719 dual mode Bluetooth BR/EDR + BLE module. I'm using WICED Studio 6.2 for software development and I'm connecting and pairing to the EVAL board using a CY5677 BLE 4.2 USB dongle with CySmart 1.3 software.

       

      My application is configured to require an authenticated, bonded connection and everything is working as expected. On initial pairing I get the passkey from the CYW20719, enter it in the dialog box of the CySmart software and an authenticated, bonded connection is created. Subsequent connections always result in an authenticated connection using the keys stored by CySmart and by my application.

       

      However, when I power cycle the EVAL board (CYW20719) a connection and pairing only results in an encrypted connection (no MITM protection). After some research, I believe the problem is that I don't see the BTM_LOCAL_IDENTITY_KEYS_UPDATE_EVT or BTM_LOCAL_IDENTITY_KEYS_REQUEST_EVT events in my bt_management_cback function so the local keys on the EVAL board are being regenerated each time the board is powered on (instead of restoring them from NV

      memory).

       

      What would prevent the BTM_LOCAL_IDENTITY_KEYS_UPDATE/REQUEST_EVT events from occurring?

        • 1. Re: CYW20719 BLE Does Not Generate Local_Identity_Keys Events
          AnjanaM_61

          Hi,

           

          After power cycling , when you connected with CySmart, did you click pair button on CySmart GUI?

          Please note, if you paired and bonded once, you don't have to go through entire pairing process again. Can you please confirm how you checked there is no protection after power cycling?

          Can you please share the project which you are testing to check the implementation?

           

          Thanks,
          Anjana

          1 of 1 people found this helpful
          • 2. Re: CYW20719 BLE Does Not Generate Local_Identity_Keys Events
            JoOr_4004241

            Anjana,

             

            Thank you for your quick response. However, I must apologize because after taking another look this morning, I find that I am receiving the subject events. I guess I just spent too many hours at the keyboard without a break.

             

            I am receiving and properly responding to BTM_LOCAL_IDENTITY_KEYS_REQUEST_EVT events. There are no ***KEYS_UPDATE_EVT events because I am restoring the local keys from NV memory. I missed the ***KEYS_REQUEST_EVT events because I was using the HCI UART for tracing to BTSpy which I did not connect to the CYW20719 until after reset and initialization processing were complete and the REQUEST_EVT event occurs very early in the startup process.

             

            In answer to your first two questions:

            1. Yes, I am clicking the Pair button in CySmart after connection is successful.

            2. I do know that I don't have to repeat the entire pairing process once the two devices are bonded. In fact, I expect that. I also expect that the pairing after a reconnect should be at the same level as the initial pairing (authenticated or unauthenticated).

             

            Your third question is the crux of the matter:  Can you please confirm how you checked there is no protection after power cycling?

             

            On getting a BTM_ENCRYPTION_STATUS_EVT event, I call wiced_bt_ble_get_security_state() with the p_event_data->encryption_status.bd_addr. I check the security flags returned by this function to see if the BTM_SEC_LE_LINK_PAIRED_WITH_MITM bit is set (passkey was entered at initial pairing). This bit is set after initial pairing and subsequent re-connects and re-pairs. But after a reset or power cycle of the CYW20719, this bit is cleared after doing a re-connect and re-pair using previously saved keys.

             

            Is there some other way for my application to test if a pairing was authenticated with a passkey?

             

            Joe