CC2640: Secure connection with BLE APP

Mark Felberg

Guru 19990 points

Part Number: CC2640
Other Parts Discussed in Thread: CC1310,

Hi everyone, I working with Project-Zero and CC1310 board custom 4x4. The project it works and I can to on and off the LED of my device through the APP. Now, I would like to implement more security for this project. I and my company we thought to had different passkey for each customer. The objectives we have decided to implement are one of these:

When I go to program the device, it assigns me a different passkey through a file. So, first programming first password, second programming second password.
Change the passkey through the APP.
Implement a partnership button. So when I see that the smartphone wants to connect to the cc2640 I hold down the device button and binds.
When I click on the device button, it assigns me a random passkey, to be displayed on the app, and I connect to the device.

What could be the easiest route to take?

over 6 years ago

0 Evan W over 6 years ago

TI__Mastermind 39620 points

Hi Mark,

Mark Felsberg said:
When I go to program the device, it assigns me a different passkey through a file. So, first programming first password, second programming second password.

First, if you use TRNG, no matter how many times you flash it, the passcode will always be different. You can reference the security examples here to show you how to do this. https://github.com/ti-simplelink/ble_examples/blob/ble_examples-2.2/src/examples/security_examples_central/cc26xx/app/security_examples_central.c

All this would start after a pairing session has started.

Mark Felsberg said:
Change the passkey through the APP.

From the app on the phone? In the above, this won't really matter, because all new bonds will be a randomly generated new passcode.

Mark Felsberg said:

Implement a partnership button. So when I see that the smartphone wants to connect to the cc2640 I hold down the device button and binds.

When I click on the device button, it assigns me a random passkey, to be displayed on the app, and I connect to the device.

This just sounds like triggering a pairing session, which is entirely possible by having the central initiate a pair with a slave device that you're connected to.

0 Mark Felberg over 6 years ago in reply to Evan W

Guru 19990 points

Hi Evan W, I can not load the github example on my CCS version 8.1. How can I use the TRNG? Changing the passkey remotely would seem like the nicest thing to implement.

0 Evan W over 6 years ago in reply to Mark Felberg

TI__Mastermind 39620 points

Hi Mark,

I'm not sure that you need to change the passkey remotely. The passkey if implemented properly using a RNG will change every time you create a new bond with a device. You only bond with a device once, and in the future you then use the shared keys that was transmitted over an encrypted session.

Please study this page as well as the BLE Specification as it pertains to secure connections and pairing. dev.ti.com/.../gapbondmngr.html

In the process of a pair with a device, a GAP_PASSKEY_NEEDED_EVENT is sent to the application which calls the Passcode_callback. In the passcode callback, you can randomly generate a passcode similar to how it's done in security_examples_central_processPasscode() function in the security_examples_central.c file of the example i linked. From there, the passcode is loaded via GAPBondMgr_PasscodeRsp.

I know in the past that you've asked to change the passcode every time you want to connect to a device. I struggle to see how this adds security. In my understanding, it would actually removes security from your application and makes it more vulnerable to attack. A passcode is not a password, passkey entry is a type of authenticated pairing that can prevent man in the middle (MITM) attacks. It can be used with either LE Legacy pairing or Secure Connections pairing. In this pairing method, one device displays a 6-digit passcode, and the other device enters the passcode. The most vulnerable point in a BLE secure connection is the first time the devices pair and bond.

After the devices pair and bond, the devices will always used the shared secrets that were shared after an encrypted link has been established, things like LTK, IRK etc. That way, the devices can quickly start an encrypted link without having to worry about exchanging vital info.

If you decide to pair every time, as in create a new passkey everytime you want to connect to a device, you are essentially always exposing yourself to a chance of eavesdropping.

Can you explain how your implementation makes it more secure?

Can you also please inform me what your IO Cap is set to for your initiator and responder?

0 Mark Felberg over 6 years ago in reply to Evan W

Guru 19990 points

Hi Ewan, this is what my piece of code is the part of the IoCap.

 uint32_t passkey = 0; // passkey "0000"
  uint8_t pairMode = GAPBOND_PAIRING_MODE_INITIATE;
  uint8_t mitm = TRUE;
  uint8_t ioCap = GAPBOND_IO_CAP_DISPLAY_YES_NO;
  uint8_t bonding = FALSE;

  GAPBondMgr_SetParameter(GAPBOND_DEFAULT_PASSCODE, sizeof(uint32_t),
                         &passkey);
  GAPBondMgr_SetParameter(GAPBOND_PAIRING_MODE, sizeof(uint8_t), &pairMode);
  GAPBondMgr_SetParameter(GAPBOND_MITM_PROTECTION, sizeof(uint8_t), &mitm);
  GAPBondMgr_SetParameter(GAPBOND_IO_CAPABILITIES, sizeof(uint8_t), &ioCap);
  GAPBondMgr_SetParameter(GAPBOND_BONDING_ENABLED, sizeof(uint8_t), &bonding);

My goal is to have more security for my customers. Obviously, if I set a default passkey in my code, everyone will know it and anyone can connect. So I asked for the possibility to change the passkey when programming the chip, or to implement something with the button.

0 Evan W over 6 years ago in reply to Mark Felberg

TI__Mastermind 39620 points

Hi Mark,

Can you also give me the info of your responder? What settings are being used?

What is your responder? Is it an iPhone/Android or is it another TI chip?

0 Mark Felberg over 6 years ago in reply to Evan W

Guru 19990 points

Android phone

0 Evan W over 6 years ago in reply to Mark Felberg

TI__Mastermind 39620 points

Is it in the slave or master role?

Do you know the io cap value it's using?

Can you comment as to why you are leaving bonding off? It is more secure to pair/bond once and use the shared secrets in subsequent connections.

0 Mark Felberg over 6 years ago in reply to Evan W

Guru 19990 points

I don't know the configuration of my smartphone. The my goal is only the association through the button with my CC2640

0 Evan W over 6 years ago in reply to Mark Felberg

TI__Mastermind 39620 points

Hi Mark,

I'm going to assume that youre the peripheral/slave in this case since you're using Project Zero in your earlier post. Then your phone would be the master. It's important to know what role your devices play in the system.

While you can change your passkey every time you connect and pair, doing this every time is NOT more secure than doing it once. I highly recommend you turn bonding on.

passkey entry should not be treated as a password to a connection, but rather as a way to verify that the device you're connecting to is the device you wish to be paired with and share encrypted information.

I highly recommend you read through this page, and in particular, study Figure 57 flow diagram for pairing sessions.

http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_2_30_00_28/docs/blestack/ble_user_guide/html/ble-stack-3.x/gapbondmngr.html#gap-bond-manager-and-le-secure-connections

In ProjectZero, under user_processApplicationMessage(), there is an application message titled APP_MSG_SEND_PASSCODE. Here, we will add the following code that will randomize the passkey. This message is triggered when a GAP_PASSKEY_NEEDED_EVENT is generated by the stack during the pairing process. This event is then sent to the GAPBondMgr which calls the applications passcode callback which then enqueues the APP_MSG_SEND_PASSCODE application message.

In APP_MSG_SEND_PASSCODE you can randomly generate a new passcode using the following code:

    case APP_MSG_SEND_PASSCODE: /* Message about pairing PIN request */
      {
        uint32_t passcode = 0;
        passcode = Util_GetTRNG();
        passcode %= 1000000;
        passcode_req_t *pReq = (passcode_req_t *)pMsg->pdu;
        Log_info2("BondMgr Requested passcode. We are %s passcode %06d",
                  (IArg)(pReq->uiInputs?"Sending":"Displaying"),
                  passcode);
        // Send passcode response.
        GAPBondMgr_PasscodeRsp(pReq->connHandle, SUCCESS, passcode);
      }
      break;

This will generate a random passkey every time you try to pair with a device. Again, I recommend that you turn bonding on, but if you dont want to do that, then this code will still create a random passkey everytime you pair with a device. If you want to have a button on your android app that triggers a new generation of a passkey, then you can do that as well I guess. You'd probably have it tied with a characteristic and then when that value is written call a callback to basically randomly generate the passkey again. However, I find it more useful to be in this app msg than over an unsecure characteristic.

I also believe it would be beneficial to study the BLE Security Fundamentals Lab in SimpleLink Academy. dev.ti.com/.../ble_02_sec_basics.html

Bluetooth®︎

Bluetooth forum

CC2640: Secure connection with BLE APP