| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
location (current dir) of core file.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
in vanilla or FAIL SMPPairingState
In pre-pairing, it may occur that the slave adapter sends the SECURITY_REQUEST out,
but pre-pairing is still setup and working.
Hence ignore this request if SMPPairingState has progressed,
BT Spec agrees here (only once before pairing).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To have full SMP key persitency in peripheral slave mode,
BTAdapter requires fine grained control over
- Passing stored keys to BTDevice's PairingData (w/o uploading them)
- Uploading BTDevice's PairingData to the adapter
This required interaction in certain places,
only enabled if adapter is BTRole::Slave (peripheral):
- BTAdapter::mgmtEvDeviceConnectedHCI()
Only issue unpairDevice() if not pre-paired.
Unpairing is required for new pairing to avoid DHKey Check failures!
- BTAdapter::mgmtEvDeviceDisconnectedHCI()
- First unpairDevice() will be issued via notifyDisconnect()
- Set and upload stored keys for disconnected device (if existing),
preparing for next connect.
- BTAdapter::sendDevicePairingState()
- SMPPairingState::COMPLETED && not SMPPairingState::PRE_PAIRED: Store keys
- SMPPairingState::COMPLETED && SMPPairingState::PRE_PAIRED: Refresh keys to BTDevice (set), no upload!
- SMPPairingState::FAILED: Remove and delete keys
+++
BTAdapter::setSMPKeyPath(path) allows user to enable the persistent key storage
by setting its local filesystem path.
It will also read all key files (SMPKeyBin) and if valid and matching with the adapter,
uploads them for pre-pairing.
See dbt_peripheral00.cpp:
adapter->setSMPKeyPath(ADAPTER_KEY_PATH);
+++
|
|
|
|
| |
peripheral key management
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uploading keys (required for peripheral BTAdapter key management)
SMPKeyBin has the key apply action revoked.
SMPKeyBin is reduced to store keys, address and security settings,
as well adding persistence (read/write to filesystem).
BTDevice::setSMPKeyBin(SMPKeyBin&) shall be used copy the key data over
and BTDevice::uploadKeys() to upload them to the adapter for pre-pairing.
See dbt_scanner10.cpp's use of convenient API (same efficiency as before)
device->uploadKeys(KEY_PATH, req_sec_level, true /* verbose_ */);
BTDevice::setSMPKeyBin(SMPKeyBin&) fully restored BTDevice's PairingData
- keys
- key caps
- user security level and IOCaps
+++
The reduced 'set<Name>Key(..)' methods only
- copy the key to BTDevice's PairingData
- set the KeyType bit for keys_<role>_[init|resp], fully restoring key caps
|
| |
|
|
|
|
| |
filename; Add member getFilename(path) and remove(path)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and connected as peripheral
This enforces a consistent and stable security workflow.
- when a BTRole::Slave BTDevice is discovered, see AdapterStatusListener::deviceFound().
- when a BTRole::Slave BTDevice is disconnected, see AdapterStatusListener::deviceDisconnected().
- when a BTRole::Master BTDevice gets connected, see AdapterStatusListener::deviceConnected().
+++
Especially when connected as peripheral without unpair in SC mode,
the peripheral fails the DHKey Check.
TODO: Provide a persistent pre-pairing mechanism via SMPKeyBin for peripheral mode.
+++
Note: Our existing example code to connect to a remote slave/peripheral,
already performed the unpair on deviceFound(..) and deviceDisconnected().
These calls have now being removed, as they are performed directly by Direct-BT.
The example code uploads pre-existing keys for pre-pairing when device is found,
if existing.
|
|
|
|
| |
BTDevice::unpair(): Add DBG_PRINT on failure; BTDevice::clearSMPStates() reduce to one DBG_PRINT
|
| |
|
| |
|
|
|
|
| |
replies DBT_PRINT
|
| |
|
|
|
|
| |
BTSecurityRegistry by start-of name as well
|
|
|
|
| |
ClientCharConfig
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
(name + SC)
|
|
|
|
| |
cleanup incl. CCCD regs
|
|
|
|
|
|
| |
from BTRole::Slave (peripheral)
BlueZ/Kernel not reliably sending out HCI_LE_REMOTE_FEATURES
|
|
|
|
| |
for one adapter and apply them all (peripheral pre-pairing)
|
|
|
|
|
|
| |
pre-connection
FIXME: Pass keys to BTDevice instance after connection!
|
|
|
|
| |
> usedMTU
|
|
|
|
| |
address, just ignore (LTK is enough)
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Give remote slave (peripheral, Gatt-Server) 'some time' (100ms)
to complete connection and listening to our Gatt-Client requests.
We give the Gatt-Server a slightly longer period
after newly paired encryption keys (150ms).
|
| |
|
|
|
|
|
|
|
|
|
| |
clearSMPStates() call from BTDevice::disconnect() is
- redundant
- may cause a deadlock due to mtx_pairing lock
Issued at ctor(), manual unpair() and notifyDisconnect()
notifyDisconnect() will be called at all times, even if disconnect() fails!
|
| |
|
| |
|
|
|
|
| |
Expose SMPIdentityResolvingKey (IRK) adding get/set methods; Add setSignatureResolvingKey();
|
| |
|
|
|
|
|
|
|
|
|
| |
- BTDevice::notifyConnected(..): Don't issue clearSMPStates() to have valid content from manual settings.
Previous disconnect commands should have cleaned these.
- BTDevice::remove(): Don't issue clearSMPStates(), disconnect(..) will.
- BTDevice::disconnect(): Issue clearSMPStates()!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Semantics
Revise BTDevice::PairingData Handling
- BTDevice::PairingData
- Add SMPIdentityResolvingKey, replacing uint128_t
- Use 'BDAddressAndType id_address_init, id_address_resp'
- Add 'toString(const BDAddressAndType& addressAndType, const BTRole& role)'
for unified string representation
- Add 'encryption_enabled'
- checkPairingKeyDistributionComplete()
- bring back strict KEY checking (w/ IRK + SIGN)
- requires encryption_enabled
- drop printKeyDistributionStatus()
- BTDevice::updatePairingState()
- #if CONSIDER_HCI_CMD_FOR_SMP_STATE
- Never override SMP key induced data
- Only take HCI Encryption keys in SC mode
- In SC mode, LTK is for both, Server + Slave
- Add early (pre-pair) MgmtEvent::Opcode::HCI_LE_ENABLE_ENC
- Move checkPairingKeyDistributionComplete() and DBG_PRINT to end of switch/if branches,
cleaning up workflow.
- Reset claimed_state also if any key is invalid (fix)
- DBG_PRINT BTDevice::PairingData::toString()
- BTDevice::hciSMPMsgCallback()
- Move DBG_PRINT to end of switch/if branches, cleaning up workflow.
- DBG_PRINT BTDevice::PairingData::toString()
++++
Fix HCITypes/MgmtTypes Encryption Key Semantics,
i.e. HCILEEnableEncryptionCmd, HCILELTKReplyAckCmd and HCILELTKReqEvent (+ Mgmt mappings)
HCILEEnableEncryptionCmd:
- This command shall only be used when the local device’s role is BTRole::Master (initiator).
- Encryption key belongs to the remote device having role BTRole::Slave (responder).
- The encryption key matches the LTK from SMP messaging in SC mode only!
HCILELTKReplyAckCmd:
- This command shall only be used when the local device’s role is BTRole::Slave (responder).
- LTK belongs to the local device having role BTRole::Slave (responder).
- The LTK matches the LTK from SMP messaging in SC mode only!
HCILELTKReqEvent
- This event shall only be generated when the local device’s role is BTRole::Slave (responder, adapter in peripheral mode).
- Rand and Ediv belong to the local device having role BTRole::Slave (responder).
- Rand and Ediv matches the LTK from SMP messaging in SC mode only!
|
|
|
|
| |
code in BTDevice::updatePairingState)
|
|
|
|
|
|
| |
Peripheral testing w/ 'normal' SMP messaging, ..
drop the HCI security related commands for now.
|