New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 835393 link

Starred by 3 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Feature

Blocking:
issue 842952



Sign in to add a comment

LE legacy pairing as the master role of connection establishment

Project Member Reported by mcchou@chromium.org, Apr 20 2018

Issue description

This bug tracks the Implementation of LE Legacy pairing based on Just Work pairing as the master role when establishing a LE connection.

The master of pairing is responsible for the following tasks.
Phase 1: Send pairing request to initiate the pairing.
Phase 2: Send pairing confirm value to start information exchanging fo generating STK. Start encryption using exchanged STK.
Phase 3: Wait for the slave to send keys, identity and address over and sent own keys identity and address to the slave. Re-encrypt the link using exchanged LTK.

 
Project Member

Comment 1 by bugdroid1@chromium.org, May 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/newblue/+/9cd841a345128ae832a0e89bc889be2e8469a722

commit 9cd841a345128ae832a0e89bc889be2e8469a722
Author: Miao-chen Chou <mcchou@chromium.org>
Date: Fri May 11 23:01:44 2018

sm, l2cap, hci, persist: implement APIs for pairing/unpairing

This patch includes the following changes.

- Define and implement smPair/smUnpair API and observer mechanism for
the upper layer to initiate pairing and get notified on pairing state
changes and pairing error code if any.
- Add new number types to persist.h for bookkeeping the security
requirements (bonding and MITM protection) provided by the previous pairing.
Whenever an application initiate the pairing with a previously-paired
peer device, the security requirements should be checked to avoid
unnecessary pairing.
- Add a new option, "pair", to new_blue_test for verifying the just-work
pairing as the master role of a pairing session.
- Modify new_blue_test so that three options, none "pair" and "scan", are in
their own blocks. In the case of not provided option, none,
new_blue_test performs 3 advertisements. As for option scan, new_blue_test
simply scans for the nearby devices for 20 seconds.For option "pair",
new_blue_test scans for 5 seconds each round to look for a pre-defined target
address and performs pairing and unpairing. The pre-defined address is
advertised using option "scan".
- Fix the return value of hciLeEncryptConn

BUG= chromium:835393 
TEST=run new_blue_test w/o option to performs 3 advertisements on one DUT
, run new_blue_test w/ option "pair" on the other DUT and verify that
the just-work pairing and unpairing finishes correctly
Change-Id: I94effcb1b9c9bb60ffb1c88e854f34453186f670

[modify] https://crrev.com/9cd841a345128ae832a0e89bc889be2e8469a722/config.h
[modify] https://crrev.com/9cd841a345128ae832a0e89bc889be2e8469a722/l2cap.c
[modify] https://crrev.com/9cd841a345128ae832a0e89bc889be2e8469a722/test.c
[modify] https://crrev.com/9cd841a345128ae832a0e89bc889be2e8469a722/sm.c
[modify] https://crrev.com/9cd841a345128ae832a0e89bc889be2e8469a722/hci.c
[modify] https://crrev.com/9cd841a345128ae832a0e89bc889be2e8469a722/sm.h
[modify] https://crrev.com/9cd841a345128ae832a0e89bc889be2e8469a722/persist.h

Project Member

Comment 2 by bugdroid1@chromium.org, May 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/newblue/+/85b1d7e2da66325af66bb1f11f75a8689cbc3efa

commit 85b1d7e2da66325af66bb1f11f75a8689cbc3efa
Author: Miao-chen Chou <mcchou@chromium.org>
Date: Fri May 11 23:01:44 2018

sm, config: introduce work queue for notification works to the upper layer

This introduces a work queue to perform the notification work to the
upper layer without potentially blocking the lower layer threads, such as
HCI work thread and L2CAP work thread. This also fixes the double-freeing
in smDeinit().

BUG= chromium:835393 
TEST=Run new_blue_test w/o option to performs 3 advertisements on one
DUT, run new_blue_test w/ option "pair" on the other DUT and verify that
the just-work pairing and unpairing finishes correctly. The notification
works fine when the new_blue_test sleeps for 5 seconds before unpairing.

Change-Id: Ia912d09593cbb24ce342b5ae1e9352f98ea848ec

[modify] https://crrev.com/85b1d7e2da66325af66bb1f11f75a8689cbc3efa/config.h
[modify] https://crrev.com/85b1d7e2da66325af66bb1f11f75a8689cbc3efa/sm.c
[modify] https://crrev.com/85b1d7e2da66325af66bb1f11f75a8689cbc3efa/test.c

Project Member

Comment 3 by bugdroid1@chromium.org, May 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/newblue/+/165907254c3a7adbc6d3af5adb89e1a5cfad2c01

commit 165907254c3a7adbc6d3af5adb89e1a5cfad2c01
Author: Miao-chen Chou <mcchou@chromium.org>
Date: Fri May 11 23:01:44 2018

persist: support enumeration of numbers

This adds the support of enumeration of numbers in
persistEnumKnownDevs() where it takes wantedNumType as an nullable
parameter, and this also adds haveNums and wantedNum as parameters of
persistKnownDevEnumeratorF to expose the result of searching. Three
tests are added to PersistTestSuite.

The use case of searching numbers can be handy for the default security
manager to find the target peer address with a set of random number and
EDIV.

BUG= chromium:835393 
TEST=build, run new_blue_test and verify that all tests pass

Change-Id: Ice2154e1382e33d95667eb043ee0bc710e3a0507

[modify] https://crrev.com/165907254c3a7adbc6d3af5adb89e1a5cfad2c01/persist.c
[modify] https://crrev.com/165907254c3a7adbc6d3af5adb89e1a5cfad2c01/tests/persist_unittest.cc
[modify] https://crrev.com/165907254c3a7adbc6d3af5adb89e1a5cfad2c01/persist.h

Comment 4 by mcchou@chromium.org, May 15 2018

Status: Fixed (was: Started)

Comment 5 by mcchou@chromium.org, May 15 2018

Blocking: 842952
Status: Verified (was: Fixed)

Sign in to add a comment