Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repeat pairing #287

Merged
merged 6 commits into from
Jun 16, 2017
Merged

Repeat pairing #287

merged 6 commits into from
Jun 16, 2017

Conversation

ccollins476ad
Copy link
Contributor

This pull request addresses the issue identified in MYNEWT-750 (https://issues.apache.org/jira/browse/MYNEWT-750).

This PR incorporates changes from another PR: 277 (#277). Therefore, this PR should only be merged after 277.

@sjanc
Copy link
Contributor

sjanc commented May 18, 2017

Hi,
does this cover scenario for security level increase? from unauthenticated to authenticated

@ccollins476ad
Copy link
Contributor Author

Yes, this does apply to a security level increase. The application has to do a little more work, though. Specifically, the application needs to compare the properties of the current bond to those of the imminent secure link. E.g.,

if (event.repeat_pairing.cur_authenticated && !event.repeat_pairing.new_authenticated) {
    return BLE_GAP_REPEAT_PAIRING_IGNORE;
}

if (event.repeat_pairing.cur_sc && !event.repeat_pairing.new_sc) {
    return BLE_GAP_REPEAT_PAIRING_IGNORE;
}

/* Delete existing bond using ble_store_delete_peer(). */

return BLE_GAP_REPEAT_PAIRING_RETRY;

I do think the application needs this level of control, though. If there is a good default behavior, we can supply it as a library function.

We would persist the authenticated flag if either peer supported
authentication.  We should only persist it if both support it.
If a device is already bonded, ;he host should not allow the same device
to pair again. Currently, the host blindly proceeds with the pairing
operation. This should not be allowed because the second peer could be
an imposter masquerading as the original.

New behavior in such a scenario:

1. Host notifies application of the duplicate pairing attempt via the
gap event callback. The callback specifies a new event code
(BLE_GAP_EVENT_REPEAT_PAIRING) that specifically indicates a duplicate
pairing attempt.

2. The gap event callback returns an error code indicating which
of the following behaviors to perform:

    a. Retry: Return BLE_GAP_REPEAT_PAIRING_RETRY after deleting the
       conflicting bond. The stack will verify the bond has been deleted
       and continue the pairing procedure. If the bond is still present,
       this event will be reported again.

    b. Ignore: Return BLE_GAP_REPEAT_PAIRING_IGNORE. The stack will
       silently ignore the pairing request.
@limal
Copy link

limal commented Jun 14, 2017

I'm having the same issue with pairing. When is this PR expected to be merged?

@ccollins476ad ccollins476ad merged commit 1a077e8 into apache:master Jun 16, 2017
@ccollins476ad ccollins476ad deleted the repeat-pairing branch June 16, 2017 20:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants