Hello,
I'm preparing a bluetooth "access point" using BlueZ 5.47, so that for exam=
ple mobile phones can connect to it, and further use PAN profile (which is =
not part of this question). So far it works well, just using the JustWorks =
pairing method.
I'd like to secure this a little bit, not allowing anyone to pair, rather t=
o request passkey (let's say hardcoded string) before accepting pairing req=
uested by a client mobile phone.
After searching through documentation and much googling, I don't see any hi=
nts how to achieve this.
I found some information about pairing agents in BlueZ5, both in bluetoothc=
tl and custom (programming them seems complicated but viable and I cannot u=
se simple-agent since I don't have python on my machine), but all the useca=
ses seem to target on BlueZ being the client, who initiates pairing, and th=
e agent takes care of inputting passkey required by the other side - which =
is the opposite of what I need.
How to configure BlueZ5 to require passkey from any incomming pairing reque=
sts?
Thanks very much for your answers!
Libor
VGhhbmsgeW91IGZvciB0aGUgYW5zd2VyIGFnYWluLg0KDQpJJ20gcmVnaXN0ZXJpbmcgdGhlIGFn
ZW50IHdpdGg6DQogICAgZGJ1c19jb25uZWN0aW9uX3RyeV9yZWdpc3Rlcl9vYmplY3RfcGF0aChh
Z2VudF9jb25uLCAiL2J0cGFuZF9hZ2VudCIsICZhZ2VudF90YWJsZSwgTlVMTCwgJmVycik7DQoN
CiAgICAib3JnLmJsdWV6IiAiL29yZy9ibHVleiIgIm9yZy5ibHVlei5BZ2VudE1hbmFnZXIxIiAi
UmVnaXN0ZXJBZ2VudCIgIm8iICIvYnRwYW5kX2FnZW50IiAicyIgIk5vSW5wdXROb091dHB1dCIN
Cg0KICAgICJvcmcuYmx1ZXoiICIvb3JnL2JsdWV6IiAib3JnLmJsdWV6LkFnZW50TWFuYWdlcjEi
ICJSZXF1ZXN0RGVmYXVsdEFnZW50IiAibyIgIi9idHBhbmRfYWdlbnQiDQoNClRoaXMgZ29lcyB3
aXRob3V0IGFueSBlcnJvciBhbmQgSSBndWVzcyBpdCBpcyBjb3JyZWN0IHNpbmNlIHRoZSBBdXRo
b3JpemVTZXJ2aWNlIG1ldGhvZCBpcyBjYWxsZWQgcHJvcGVybHkuDQoNClRvIGJlIGV4YWN0LCBJ
IGNvcnJlY3QgdGhhdCB0aGUgQXV0aG9yaXplU2VydmljZSBtZXRob2QgaXMgbm90IGNhbGxlZCBh
dCB0aGUgdGltZSBvZiBwYWlyaW5nLCBidXQgb25seSB3aGVuIEkgcmVxdWVzdCBQQU4gcHJvZmls
IGFjdGl2YXRpb24gb24gdGhlIG1vYmlsZSBwaG9uZS4gQnV0IHRoZSBSZXF1ZXN0UGFzc2tleSBt
ZXRob2QgaXMgc3RpbGwgbmV2ZXIgY2FsbGVkLg0KDQpTdXJlLCBJIGFsd2F5cyB1bnBhaXIgYm90
aCBzaWRlcyBiZWZvcmUgSSB0ZXN0IGFueXRoaW5nLg0KDQpBbnkgb3RoZXIgaWRlYXMsIHBsZWFz
ZT8NCg0KTGlib3INCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJhc3RpZW4g
Tm9jZXJhIFttYWlsdG86aGFkZXNzQGhhZGVzcy5uZXRdIA0KU2VudDogRGllbnN0YWcsIDE0LiBB
dWd1c3QgMjAxOCAxNDoyNg0KVG86IExpYm9yIFBlbHRhbiA8bHBlbHRhbkBpbnN5cy10ZWMuZGU+
OyBsaW51eC1ibHVldG9vdGhAdmdlci5rZXJuZWwub3JnDQpTdWJqZWN0OiBSZTogYnQgInNlcnZl
ciIgaG93IHRvIGNvbmZpZ3VyZSByZXF1aXJpbmcgcGFzc2tleSBmcm9tIGNvbm5lY3RpbmcgY2xp
ZW50cw0KDQpPbiBUdWUsIDIwMTgtMDgtMTQgYXQgMTI6MTQgKzAwMDAsIExpYm9yIFBlbHRhbiB3
cm90ZToNCj4gVGhhbmtzIEJhc3RpZW4gZm9yIHlvdXIgYnJpZWYsIGJ1dCBsZWFkaW5nIGFuc3dl
ci4NCj4gDQo+IFN0aWxsLCBJIGZlZWwgbGlrZSBJJ20gbWlzc2luZyBzb21ldGhpbmcgOigNCj4g
DQo+IEkndmUgcmVhZCB0aGUgbGlua3MgY2FyZWZ1bGx5LiBUaGUgIkNISVAtYmx1ZXRvb3RoLXNw
ZWFrZXIiIHVzZXMgDQo+IGJsdWV6LXRvb2xzJyBidC1hZ2VudCB3aXRoIHBhcmFtZXRlcnMgc2V0
IHNvIHRoYXQgaXQncyB1c2luZyANCj4gTm9JbnB1dE5vT3V0cHV0IGNhcGFiaWxpdGl5LCBidXQg
cmVxdWlyaW5nIFBhc3NrZXkgYXQgdGhlIHNhbWUgdGltZS4NCj4gVGhpcyBpcyBleGFjdGx5IHdo
YXQgSSB3YW50IQ0KPiANCj4gTm8gaGF2aW5nIGJsdWV6LXRvb2xzIGluIG15IHNldHVwLCBJIHRy
aWVkIHRvIG1ha2UgbXkgb3duIHByb2dyYW1tZWQgDQo+IGFnZW50IGJlaGF2ZSBzaW1pbGFybHks
IGkuZS4gYWNjb3JkaW5nIHRvIHlvdXIgaGludCwgaW1wbGVtZW50IHRoZSANCj4gUmVxdWVzdFBh
c3NrZXkgbWV0aG9kIGluIG15IGFnZW50LiBIb3dldmVyLCB0aGlzIG1ldGhvZCBpcyBuZXZlciAN
Cj4gY2FsbGVkISBXaGVuIHBhaXJpbmcgYSBwaG9uZSwgQmx1ZVogb25seSBjYWxscyB0aGUgQXV0
aG9yaXplU2VydmljZSANCj4gbWV0aG9kIG9mIG15IGFnZW50Lg0KPiANCj4gSG93IGNhbiBJIGZv
cmNlIEJsdWVaICB0byBjYWxsIHRoZSBSZXF1ZXN0UGFzc2tleSBtZXRob2Qgb2YgbXkgYWdlbnQ/
DQo+IA0KPiBJIHRyaWVkIHRvIGFuYWx5emUgaG93IGJsdWV6LXRvb2xzIGRvIGl0LCBidXQgSSBo
YXZlbid0IGZpbmQgYW55dGhpbmcgDQo+IGluIHRoZWlyIGNvZGUuIFRoZXkgc2VlbSB0byBzaW1w
bHkgd29yay4uLg0KDQpZb3Ugd2lsbCBhbHNvIG5lZWQgdG8gcmVnaXN0ZXIgdGhlIGFnZW50LCBh
bmQgbWFrZSBzdXJlIGl0J3MgdGhlIGRlZmF1bHQgb25lICh5b3UnbGwgcHJvYmFibHkgd2FudCB0
byBkaXNhYmxlIHdoYXRldmVyIG90aGVyIG9uZSB5b3UgaGF2ZSBydW5uaW5nKS4NCg0KWW91IHdv
dWxkIHByb2JhYmx5IG9ubHkgZXZlciBnZXQgQXV0aG9yaXplU2VydmljZSBpZiB0aGUgZGV2aWNl
IGlzIGFscmVhZHkgcGFpcmVkLiBZb3Ugd291bGQgbmVlZCB0byB1bnBhaXIgaXQsIGFuZCBvbmNl
IHBhaXJlZCwgbWFyayBpdCBhcyB0cnVzdGVkIHNvIHRoYXQgQXV0aG9yaXplU2VydmljZSBpcyBu
b3QgY2FsbGVkIGFuZCB0aGUgc2VydmljZSBpcyBhdXRob3Jpc2VkIHdpdGhvdXQgYW55IGZ1cnRo
ZXIgcHJvbXB0cyAob3IgY2hlY2sgdGhhdCB0aGUgZGV2aWNlIGlzIHBhaXJlZCBpbiB5b3VyIEF1
dGhvcml6ZVNlcnZpY2UgaW1wbGVtZW50YXRpb24pLg0KDQpIVEgNCg0K
On Tue, 2018-08-14 at 12:14 +0000, Libor Peltan wrote:
> Thanks Bastien for your brief, but leading answer.
>
> Still, I feel like I'm missing something :(
>
> I've read the links carefully. The "CHIP-bluetooth-speaker" uses
> bluez-tools' bt-agent with parameters set so that it's using
> NoInputNoOutput capabilitiy, but requiring Passkey at the same time.
> This is exactly what I want!
>
> No having bluez-tools in my setup, I tried to make my own programmed
> agent behave similarly, i.e. according to your hint, implement the
> RequestPasskey method in my agent. However, this method is never
> called! When pairing a phone, BlueZ only calls the AuthorizeService
> method of my agent.
>
> How can I force BlueZ to call the RequestPasskey method of my agent?
>
> I tried to analyze how bluez-tools do it, but I haven't find anything
> in their code. They seem to simply work...
You will also need to register the agent, and make sure it's the
default one (you'll probably want to disable whatever other one you
have running).
You would probably only ever get AuthorizeService if the device is
already paired. You would need to unpair it, and once paired, mark it
as trusted so that AuthorizeService is not called and the service is
authorised without any further prompts (or check that the device is
paired in your AuthorizeService implementation).
HTH
VGhhbmtzIEJhc3RpZW4gZm9yIHlvdXIgYnJpZWYsIGJ1dCBsZWFkaW5nIGFuc3dlci4NCg0KU3Rp
bGwsIEkgZmVlbCBsaWtlIEknbSBtaXNzaW5nIHNvbWV0aGluZyA6KA0KDQpJJ3ZlIHJlYWQgdGhl
IGxpbmtzIGNhcmVmdWxseS4gVGhlICJDSElQLWJsdWV0b290aC1zcGVha2VyIiB1c2VzIGJsdWV6
LXRvb2xzJyBidC1hZ2VudCB3aXRoIHBhcmFtZXRlcnMgc2V0IHNvIHRoYXQgaXQncyB1c2luZyBO
b0lucHV0Tm9PdXRwdXQgY2FwYWJpbGl0aXksIGJ1dCByZXF1aXJpbmcgUGFzc2tleSBhdCB0aGUg
c2FtZSB0aW1lLiBUaGlzIGlzIGV4YWN0bHkgd2hhdCBJIHdhbnQhDQoNCk5vIGhhdmluZyBibHVl
ei10b29scyBpbiBteSBzZXR1cCwgSSB0cmllZCB0byBtYWtlIG15IG93biBwcm9ncmFtbWVkIGFn
ZW50IGJlaGF2ZSBzaW1pbGFybHksIGkuZS4gYWNjb3JkaW5nIHRvIHlvdXIgaGludCwgaW1wbGVt
ZW50IHRoZSBSZXF1ZXN0UGFzc2tleSBtZXRob2QgaW4gbXkgYWdlbnQuIEhvd2V2ZXIsIHRoaXMg
bWV0aG9kIGlzIG5ldmVyIGNhbGxlZCEgV2hlbiBwYWlyaW5nIGEgcGhvbmUsIEJsdWVaIG9ubHkg
Y2FsbHMgdGhlIEF1dGhvcml6ZVNlcnZpY2UgbWV0aG9kIG9mIG15IGFnZW50Lg0KDQpIb3cgY2Fu
IEkgZm9yY2UgQmx1ZVogIHRvIGNhbGwgdGhlIFJlcXVlc3RQYXNza2V5IG1ldGhvZCBvZiBteSBh
Z2VudD8NCg0KSSB0cmllZCB0byBhbmFseXplIGhvdyBibHVlei10b29scyBkbyBpdCwgYnV0IEkg
aGF2ZW4ndCBmaW5kIGFueXRoaW5nIGluIHRoZWlyIGNvZGUuIFRoZXkgc2VlbSB0byBzaW1wbHkg
d29yay4uLg0KDQpUaGFua3MgbXVjaCENCg0KTGlib3INCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IEJhc3RpZW4gTm9jZXJhIFttYWlsdG86aGFkZXNzQGhhZGVzcy5uZXRdIA0K
U2VudDogTWl0dHdvY2gsIDguIEF1Z3VzdCAyMDE4IDE3OjE1DQpUbzogTGlib3IgUGVsdGFuIDxs
cGVsdGFuQGluc3lzLXRlYy5kZT47IGxpbnV4LWJsdWV0b290aEB2Z2VyLmtlcm5lbC5vcmcNClN1
YmplY3Q6IFJlOiBidCAic2VydmVyIiBob3cgdG8gY29uZmlndXJlIHJlcXVpcmluZyBwYXNza2V5
IGZyb20gY29ubmVjdGluZyBjbGllbnRzDQoNCk9uIFdlZCwgMjAxOC0wOC0wOCBhdCAxNDozMSAr
MDAwMCwgTGlib3IgUGVsdGFuIHdyb3RlOg0KPiBIaSBCYXN0aWVuLA0KPiBUaGFua3MgbXVjaCBm
b3IgeW91ciBhbnN3ZXIuDQo+IA0KPiBFdmVuIGlmIHByb2dyYW1tZWQgbXkgb3duIHBhaXJpbmcg
YWdlbnQsIEkgY2FuJ3Qgc2VlIGhvdyBJIGNvdWxkIA0KPiBhY2hpZXZlIGhhdmluZyBmaXhlZCBQ
SU4gZm9yIGluY29tbWluZyByZXF1ZXN0cy4NCj4gDQo+IFdoZW4gSSByZWdpc3RlciBteSBhZ2Vu
dCwgSSBjYW4gY2hvb3NlIG9uZSBvZiBmb2xsb3dpbmcgY2FwYWJpbGl0eSANCj4gb3B0aW9ucyBb
YWNjb3JnaW5nIHRvIEJsdWVaIEFnZW50IEFQSV06DQo+ICAtIE5vSW5wdXROb091dHB1dCwgRGlz
cGxheVllc05vLCBLZXlib2FyZE9ubHk6IEkgY2FuIGp1c3QgDQo+IHByb2dyYW1hdGljYWxseSBk
ZWNpZGUgYmFzZWQgb24gdGhlIGNsaWVudCdzIEJEIGFkZHJlc3MgaWYgSSBhY2NlcHQgDQo+IHRo
ZSBwYWlyaW5nIG9yIG5vdA0KPiAgLSBEaXNwbGF5T25seSwgS2V5Ym9hcmREaXNwbGF5OiBhdCB0
aGUgdGltZSBvZiBwYWlyaW5nLCB0aGUgYWdlbnQgDQo+IHJlY2VpdmVzIGFscmVhZHkgdGhlIFBJ
TiwgYW5kIGNhbiBqdXN0IGRlY2lkZSBpZiBpdCdzIGFjY2VwdGVkLiBCdXQgDQo+IHRoaXMgUElO
IGlzIG5vdCBlbnRlcmVkIGJ5IHRoZSBtb2JpbGUgcGhvbmUgKGNsaWVudCkgdXNlciwgaXQncyBq
dXN0IA0KPiBmYWJyaXF1ZWQgKHJhbmRvbWx5Pykgc29tZXdoZXJlIGluc2lkZSB0aGUgcGFpcmlu
ZyBwcm9jZXNzLiBBY3R1YWxseSwgDQo+IHRoZSBtb2JpbGUgcGhvbmUgdXNlciBpcyBxdWVyaWVk
IHdpdGggdGhlIHNhbWUgUElOIGFuZCBjYW4gb25seSBhY2NlcHQgDQo+IGl0IHRvby4NCj4gDQo+
IEFsbCBpbiBhbGwsIG15IGFnZW50IGlzIG5ldmVyIGFza2VkIHRvIHJldHVybiB0aGUgUElOLg0K
PiANCj4gVGhlIGFnZW50cyBidWlsdC1pbiBpbiBibHVldG9vdGhjdGwgb3IgdGhlIGJsdWV6LXRv
b2xzIHlvdSBwb2ludGVkIHRvLCANCj4gYmVoYXZlIHJvdWhseSB0aGUgc2FtZS4NCj4gDQo+IEFt
IEkgbWlzc2luZyBzb21ldGhpbmcsIHNvbWUgb3RoZXIgdXNlY2FzZSBvZiBwYWlyaW5nIGFnZW50
Pw0KPiANCj4gSXQgc2VlbXMgd2VpcmQgdG8gbWUgdGhhdCBmb3Igb2xkIHZlcnNpb24gb2YgQmx1
ZVogKDQ/KSwgSSBoYXZlIGZvdW5kIA0KPiBzb21ldGhpbmcgbGlrZSAnYmx1ZXRvb3RoLWFnZW50
IDEyMzQnIGNvbW1hbmQgaW5zdGFudGx5IGRvaW5nIHdoYXQgSSANCj4gbmVlZC4uLiBCdXQgSSBk
b24ndCBrbm93IGV4YWN0bHkuDQoNClRoaXMsIHVwIHRvIGxpbmUgMTAwOg0KaHR0cHM6Ly9naXRo
dWIuY29tL2hhZGVzcy9DSElQLWJsdWV0b290aC1zcGVha2VyL2Jsb2IvbWFzdGVyL3NldHVwLnNo
I0w3Mw0KaXMgdGhlIGV4YW1wbGUgb2YgYSBzY3JpcHQgdGhhdCBjcmVhdGVzIGEgZml4ZWQgUElO
LCBmb3IgYWxsIGNsaWVudHMsIHdpdGggYmx1ZXotdG9vbHMnIGJ0LWFnZW50IHJ1bm5pbmcgYXMg
YSBzZXJ2aWNlLiBJZGVhbGx5LCB5b3Ugd291bGQgc3RhcnQgdGhpcyBhZnRlciBzb21lIHNvcnQg
b2YgcGh5c2ljYWwgaW50ZXJhY3Rpb24gd2l0aCB5b3VyIGRldmljZSwgb3IgaGF2ZSBhbiAidW5j
b21tb24iIHBpbmNvZGUgKGEgcGFzc3dvcmQgb2Ygc29ydHMsIGVnLiBub3QgMDAwMCBvciAxMTEx
KSwgb3RoZXJ3aXNlIHlvdXIgbmVpZ2hib3VycyB3aWxsIGJlIGFibGUgdG8gcGFpciB3aXRoIHlv
dXIgZGV2aWNlLg0KDQpJZiB5b3Ugd2FudCB0byB1c2UgYSBmaXhlZCBwaW4gY29kZSBpbiB5b3Vy
IGFnZW50LCB5b3UnZCBuZWVkIHRvIHVzZSB0aGUgTm9JbnB1dE5vT3V0cHV0IGNhcGFiaWxpdHks
IGFuZCBpbXBsZW1lbnQgdGhlIFJlcXVlc3RQYXNza2V5IGZ1bmN0aW9uIHNvIHRoYXQgeW91IGNh
biBwcm92aWRlIHRoZSBwYXNza2V5IHRvIGJlIHVzZWQuDQoNCkNoZWVycw0K
On Wed, 2018-08-08 at 14:31 +0000, Libor Peltan wrote:
> Hi Bastien,
> Thanks much for your answer.
>
> Even if programmed my own pairing agent, I can't see how I could
> achieve having fixed PIN for incomming requests.
>
> When I register my agent, I can choose one of following capability
> options [accorging to BlueZ Agent API]:
> - NoInputNoOutput, DisplayYesNo, KeyboardOnly: I can just
> programatically decide based on the client's BD address if I accept
> the pairing or not
> - DisplayOnly, KeyboardDisplay: at the time of pairing, the agent
> receives already the PIN, and can just decide if it's accepted. But
> this PIN is not entered by the mobile phone (client) user, it's just
> fabriqued (randomly?) somewhere inside the pairing process. Actually,
> the mobile phone user is queried with the same PIN and can only
> accept it too.
>
> All in all, my agent is never asked to return the PIN.
>
> The agents built-in in bluetoothctl or the bluez-tools you pointed
> to, behave rouhly the same.
>
> Am I missing something, some other usecase of pairing agent?
>
> It seems weird to me that for old version of BlueZ (4?), I have found
> something like 'bluetooth-agent 1234' command instantly doing what I
> need... But I don't know exactly.
This, up to line 100:
https://github.com/hadess/CHIP-bluetooth-speaker/blob/master/setup.sh#L73
is the example of a script that creates a fixed PIN, for all clients,
with bluez-tools' bt-agent running as a service. Ideally, you would
start this after some sort of physical interaction with your device, or
have an "uncommon" pincode (a password of sorts, eg. not 0000 or 1111),
otherwise your neighbours will be able to pair with your device.
If you want to use a fixed pin code in your agent, you'd need to use
the NoInputNoOutput capability, and implement the RequestPasskey
function so that you can provide the passkey to be used.
Cheers
SGkgQmFzdGllbiwNClRoYW5rcyBtdWNoIGZvciB5b3VyIGFuc3dlci4NCg0KRXZlbiBpZiBwcm9n
cmFtbWVkIG15IG93biBwYWlyaW5nIGFnZW50LCBJIGNhbid0IHNlZSBob3cgSSBjb3VsZCBhY2hp
ZXZlIGhhdmluZyBmaXhlZCBQSU4gZm9yIGluY29tbWluZyByZXF1ZXN0cy4NCg0KV2hlbiBJIHJl
Z2lzdGVyIG15IGFnZW50LCBJIGNhbiBjaG9vc2Ugb25lIG9mIGZvbGxvd2luZyBjYXBhYmlsaXR5
IG9wdGlvbnMgW2FjY29yZ2luZyB0byBCbHVlWiBBZ2VudCBBUEldOg0KIC0gTm9JbnB1dE5vT3V0
cHV0LCBEaXNwbGF5WWVzTm8sIEtleWJvYXJkT25seTogSSBjYW4ganVzdCBwcm9ncmFtYXRpY2Fs
bHkgZGVjaWRlIGJhc2VkIG9uIHRoZSBjbGllbnQncyBCRCBhZGRyZXNzIGlmIEkgYWNjZXB0IHRo
ZSBwYWlyaW5nIG9yIG5vdA0KIC0gRGlzcGxheU9ubHksIEtleWJvYXJkRGlzcGxheTogYXQgdGhl
IHRpbWUgb2YgcGFpcmluZywgdGhlIGFnZW50IHJlY2VpdmVzIGFscmVhZHkgdGhlIFBJTiwgYW5k
IGNhbiBqdXN0IGRlY2lkZSBpZiBpdCdzIGFjY2VwdGVkLiBCdXQgdGhpcyBQSU4gaXMgbm90IGVu
dGVyZWQgYnkgdGhlIG1vYmlsZSBwaG9uZSAoY2xpZW50KSB1c2VyLCBpdCdzIGp1c3QgZmFicmlx
dWVkIChyYW5kb21seT8pIHNvbWV3aGVyZSBpbnNpZGUgdGhlIHBhaXJpbmcgcHJvY2Vzcy4gQWN0
dWFsbHksIHRoZSBtb2JpbGUgcGhvbmUgdXNlciBpcyBxdWVyaWVkIHdpdGggdGhlIHNhbWUgUElO
IGFuZCBjYW4gb25seSBhY2NlcHQgaXQgdG9vLg0KDQpBbGwgaW4gYWxsLCBteSBhZ2VudCBpcyBu
ZXZlciBhc2tlZCB0byByZXR1cm4gdGhlIFBJTi4NCg0KVGhlIGFnZW50cyBidWlsdC1pbiBpbiBi
bHVldG9vdGhjdGwgb3IgdGhlIGJsdWV6LXRvb2xzIHlvdSBwb2ludGVkIHRvLCBiZWhhdmUgcm91
aGx5IHRoZSBzYW1lLg0KDQpBbSBJIG1pc3Npbmcgc29tZXRoaW5nLCBzb21lIG90aGVyIHVzZWNh
c2Ugb2YgcGFpcmluZyBhZ2VudD8NCg0KSXQgc2VlbXMgd2VpcmQgdG8gbWUgdGhhdCBmb3Igb2xk
IHZlcnNpb24gb2YgQmx1ZVogKDQ/KSwgSSBoYXZlIGZvdW5kIHNvbWV0aGluZyBsaWtlICdibHVl
dG9vdGgtYWdlbnQgMTIzNCcgY29tbWFuZCBpbnN0YW50bHkgZG9pbmcgd2hhdCBJIG5lZWQuLi4g
QnV0IEkgZG9uJ3Qga25vdyBleGFjdGx5Lg0KDQpUaGFuayB5b3UhDQoNCkxpYm9yIFBlbHRhbg0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQmFzdGllbiBOb2NlcmEgW21haWx0
bzpoYWRlc3NAaGFkZXNzLm5ldF0gDQpTZW50OiBNaXR0d29jaCwgOC4gQXVndXN0IDIwMTggMTQ6
MTkNClRvOiBMaWJvciBQZWx0YW4gPGxwZWx0YW5AaW5zeXMtdGVjLmRlPjsgbGludXgtYmx1ZXRv
b3RoQHZnZXIua2VybmVsLm9yZw0KU3ViamVjdDogUmU6IGJ0ICJzZXJ2ZXIiIGhvdyB0byBjb25m
aWd1cmUgcmVxdWlyaW5nIHBhc3NrZXkgZnJvbSBjb25uZWN0aW5nIGNsaWVudHMNCg0KT24gVHVl
LCAyMDE4LTA4LTA3IGF0IDA5OjQzICswMDAwLCBMaWJvciBQZWx0YW4gd3JvdGU6DQo+IEhlbGxv
LA0KPiBJJ20gcHJlcGFyaW5nIGEgYmx1ZXRvb3RoICJhY2Nlc3MgcG9pbnQiIHVzaW5nIEJsdWVa
IDUuNDcsIHNvIHRoYXQgZm9yIA0KPiBleGFtcGxlIG1vYmlsZSBwaG9uZXMgY2FuIGNvbm5lY3Qg
dG8gaXQsIGFuZCBmdXJ0aGVyIHVzZSBQQU4gcHJvZmlsZSANCj4gKHdoaWNoIGlzIG5vdCBwYXJ0
IG9mIHRoaXMgcXVlc3Rpb24pLiBTbyBmYXIgaXQgd29ya3Mgd2VsbCwganVzdCB1c2luZyANCj4g
dGhlIEp1c3RXb3JrcyBwYWlyaW5nIG1ldGhvZC4NCj4gDQo+IEknZCBsaWtlIHRvIHNlY3VyZSB0
aGlzIGEgbGl0dGxlIGJpdCwgbm90IGFsbG93aW5nIGFueW9uZSB0byBwYWlyLCANCj4gcmF0aGVy
IHRvIHJlcXVlc3QgcGFzc2tleSAobGV0J3Mgc2F5IGhhcmRjb2RlZCBzdHJpbmcpIGJlZm9yZSAN
Cj4gYWNjZXB0aW5nIHBhaXJpbmcgcmVxdWVzdGVkIGJ5IGEgY2xpZW50IG1vYmlsZSBwaG9uZS4N
Cj4gDQo+IEFmdGVyIHNlYXJjaGluZyB0aHJvdWdoIGRvY3VtZW50YXRpb24gYW5kIG11Y2ggZ29v
Z2xpbmcsIEkgZG9uJ3Qgc2VlIA0KPiBhbnkgaGludHMgaG93IHRvIGFjaGlldmUgdGhpcy4NCj4g
DQo+IEkgZm91bmQgc29tZSBpbmZvcm1hdGlvbiBhYm91dCBwYWlyaW5nIGFnZW50cyBpbiBCbHVl
WjUsIGJvdGggaW4gDQo+IGJsdWV0b290aGN0bCBhbmQgY3VzdG9tIChwcm9ncmFtbWluZyB0aGVt
IHNlZW1zIGNvbXBsaWNhdGVkIGJ1dCB2aWFibGUgDQo+IGFuZCBJIGNhbm5vdCB1c2Ugc2ltcGxl
LWFnZW50IHNpbmNlIEkgZG9uJ3QgaGF2ZSBweXRob24gb24gbXkgDQo+IG1hY2hpbmUpLCBidXQg
YWxsIHRoZSB1c2VjYXNlcyBzZWVtIHRvIHRhcmdldCBvbiBCbHVlWiBiZWluZyB0aGUgDQo+IGNs
aWVudCwgd2hvIGluaXRpYXRlcyBwYWlyaW5nLCBhbmQgdGhlIGFnZW50IHRha2VzIGNhcmUgb2Yg
aW5wdXR0aW5nIA0KPiBwYXNza2V5IHJlcXVpcmVkIGJ5IHRoZSBvdGhlciBzaWRlIC0gd2hpY2gg
aXMgdGhlIG9wcG9zaXRlIG9mIHdoYXQgSSANCj4gbmVlZC4NCj4gDQo+IEhvdyB0byBjb25maWd1
cmUgQmx1ZVo1IHRvIHJlcXVpcmUgcGFzc2tleSBmcm9tIGFueSBpbmNvbW1pbmcgcGFpcmluZyAN
Cj4gcmVxdWVzdHM/DQo+IA0KPiBUaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIGFuc3dlcnMhDQoN
CllvdSBuZWVkIGEgcGFpcmluZyBhZ2VudCB0byBkbyB0aGlzIHNvcnQgb2YgdGhpbmcsIGFuZCBi
bHVleiBpdHNlbGYgZG9lc24ndCBzaGlwIGFueSBzdWNoIHRvb2xzIGZvciBoZWFkbGVzcyB1c2Uu
IFlvdXIgYmVzdCBiZXQgaXMgdXNpbmcgdGhlICJibHVlei10b29scyIgcmVwbzoNCmh0dHBzOi8v
Z2l0aHViLmNvbS9raHZ6YWsvYmx1ZXotdG9vbHMNCg0KSSd2ZSB1c2VkIHRoZW0gc3VjY2Vzc2Z1
bGx5IG9uIGhlYWRsZXNzIGRldmljZXMuIEluIHlvdXIgY2FzZSwgeW91IGNvdWxkIGhhdmUgdGhl
IHBhaXJpbmcgYWdlbnQgKGJ0LWFnZW50KSBiZSBzdGFydGVkIGZvciBYIHNlY29uZHMgYWZ0ZXIg
YSBidXR0b24gcHJlc3MgZm9yIGV4YW1wbGUuDQoNCklmIHlvdSB3YW50IHNvbWV0aGluZyBtb3Jl
IGNvbXBsaWNhdGVkLCB5b3UnbGwgbmVlZCB0byBpbXBsZW1lbnQgeW91ciBvd24gYWdlbnQsIHRo
ZSB0ZXN0L3NpbXBsZS1hZ2VudCBQeXRob24gc2NyaXB0IGluIHRoZSBibHVleiBzb3VyY2VzIGlz
IHByb2JhYmx5IGEgZ29vZCBzdGFydC4NCg0KQ2hlZXJzDQo=
Hi,
On Wed, Aug 8, 2018 at 3:19 PM, Bastien Nocera <[email protected]> wrote:
> On Tue, 2018-08-07 at 09:43 +0000, Libor Peltan wrote:
>> Hello,
>> I'm preparing a bluetooth "access point" using BlueZ 5.47, so that
>> for example mobile phones can connect to it, and further use PAN
>> profile (which is not part of this question). So far it works well,
>> just using the JustWorks pairing method.
>>
>> I'd like to secure this a little bit, not allowing anyone to pair,
>> rather to request passkey (let's say hardcoded string) before
>> accepting pairing requested by a client mobile phone.
>>
>> After searching through documentation and much googling, I don't see
>> any hints how to achieve this.
>>
>> I found some information about pairing agents in BlueZ5, both in
>> bluetoothctl and custom (programming them seems complicated but
>> viable and I cannot use simple-agent since I don't have python on my
>> machine), but all the usecases seem to target on BlueZ being the
>> client, who initiates pairing, and the agent takes care of inputting
>> passkey required by the other side - which is the opposite of what I
>> need.
>>
>> How to configure BlueZ5 to require passkey from any incomming pairing
>> requests?
>>
>> Thanks very much for your answers!
>
> You need a pairing agent to do this sort of thing, and bluez itself
> doesn't ship any such tools for headless use. Your best bet is using
> the "bluez-tools" repo:
> https://github.com/khvzak/bluez-tools
>
> I've used them successfully on headless devices. In your case, you
> could have the pairing agent (bt-agent) be started for X seconds after
> a button press for example.
>
> If you want something more complicated, you'll need to implement your
> own agent, the test/simple-agent Python script in the bluez sources is
> probably a good start.
I was wondering about this while hacking the AlwaysPairable option, we
could perhaps add a third option there for hardcoding a pincode that
way it would not be limited to just works since that does not offer
main in the middle protection. Obviously if the system does have an
agent then it should stick to AlwaysPairable = false.
--
Luiz Augusto von Dentz
On Tue, 2018-08-07 at 09:43 +0000, Libor Peltan wrote:
> Hello,
> I'm preparing a bluetooth "access point" using BlueZ 5.47, so that
> for example mobile phones can connect to it, and further use PAN
> profile (which is not part of this question). So far it works well,
> just using the JustWorks pairing method.
>
> I'd like to secure this a little bit, not allowing anyone to pair,
> rather to request passkey (let's say hardcoded string) before
> accepting pairing requested by a client mobile phone.
>
> After searching through documentation and much googling, I don't see
> any hints how to achieve this.
>
> I found some information about pairing agents in BlueZ5, both in
> bluetoothctl and custom (programming them seems complicated but
> viable and I cannot use simple-agent since I don't have python on my
> machine), but all the usecases seem to target on BlueZ being the
> client, who initiates pairing, and the agent takes care of inputting
> passkey required by the other side - which is the opposite of what I
> need.
>
> How to configure BlueZ5 to require passkey from any incomming pairing
> requests?
>
> Thanks very much for your answers!
You need a pairing agent to do this sort of thing, and bluez itself
doesn't ship any such tools for headless use. Your best bet is using
the "bluez-tools" repo:
https://github.com/khvzak/bluez-tools
I've used them successfully on headless devices. In your case, you
could have the pairing agent (bt-agent) be started for X seconds after
a button press for example.
If you want something more complicated, you'll need to implement your
own agent, the test/simple-agent Python script in the bluez sources is
probably a good start.
Cheers