• I'm having some problems with this in practice using 2v02. What I'm seeing with a Pixl as a peripheral is that the it (the Pixl) ignores the security values in the services when negotiating with the central. It manages to bond with the central but without the security association required by the characteristic. As a result, subsequent reads or writes fail due to insufficient authentication.

    Here are the test configs and traces. The JS is below is the only config on the Pixl and I hard reset between test. I also delete bonding information and turn Bluetooth off/on to reset the phones before each test.

    Config 1: No security on read, security on write.

    NRF.setServices({
      0xBCDE : {
        0xABCD : {
          value : "Hello", // optional
          maxLen : 5, // optional (otherwise is length of initial value)
          readable : true,   // optional, default is false
          writable : true,   // optional, default is false
          security: { // optional
            read: { // optional
              encrypted: false, // optional, default is false
              mitm: false, // optional, default is false
              lesc: false, // optional, default is false
              signed: false // optional, default is false
            },
            write: { // optional
              encrypted: true, // optional, default is false
              mitm: true, // optional, default is false
              lesc: true, // optional, default is false
              signed: false // optional, default is false
            }
          },
          onWrite : function(evt) { // optional
            print("Got ", evt.data); // an ArrayBuffer
          }
        }
        // more characteristics allowed
      }
      // more services allowed
    });
    

    I tested with both Android (Oreo 8.1) and iOS (12.2) and had the same results. When trying to write, they get a failure due to insufficient authorisation (as you would expect) and so requests to bond (SecureConnection, MITM & Bonding parameters). The Pixl replies omitting MITM and SecureConnection and the bonding completes without these.

    Another write request is then attempted but again fails due to insufficient auth. The WireShark trace for the Android test is included below. Read works fine before and after bonding.

    Config 2: No security on write, security on read.

    NRF.setServices({
      0xBCDE : {
        0xABCD : {
          value : "Hello", // optional
          maxLen : 5, // optional (otherwise is length of initial value)
          readable : true,   // optional, default is false
          writable : true,   // optional, default is false
    //      notify : true,   // optional, default is false
          security: { // optional
            read: { // optional
              encrypted: true, // optional, default is false
              mitm: true, // optional, default is false
              lesc: true, // optional, default is false
              signed: false // optional, default is false
            },
            write: { // optional
              encrypted: false, // optional, default is false
              mitm: false, // optional, default is false
              lesc: false, // optional, default is false
              signed: false // optional, default is false
            }
          },
          onWrite : function(evt) { // optional
            print("Got ", evt.data); // an ArrayBuffer
          }
        }
        // more characteristics allowed
      }
      // more services allowed
    });
    

    With this config, the write works without security and the read fails (as expected). This failure leads to bonding but then fails again due to the insufficient authentication. The trace for this is also below. I include a screenshot of the negotiation trace for ease of access to show the Pixl failing to match the Pairing Request parameters.

    I've also tried adding

     NRF.setSecurity({passkey:"123456", mitm:1, display:1}); 
    

    but it doesn't make any difference. In fact it doesn't seem to register in the config at all after being pushed to the Pixl (see screen shot of IDE).

    I believe that the Pixl is expected to propose it's security parameters in the Pairing Response frame. Having different potential security associations for each characteristic seems like a problematic approach to me. The bonding is for the device and must converge on a single common set of security associations so you couldn't have one characteristic that requires MITM and another that doesn't want it - they either all get it or none do.

    It might work in cases where the device only pairs (effectively forgetting the security association after each connection), but that would still pose a problem until the connection is torn down. I think the security association needs to be at a system level. Each characteristic can then either implement security or not, which works fine as the traces show.

    Edit 1: Just to confirm, if I leave the MITM and LESC set to false, everything works fine.


    4 Attachments

About

Avatar for cefitzger @cefitzger started