Binary PIN Support

Binary PIN Support

[David Herrmann]

Hi

Since only half of my binary-PIN patches got applied upstream, I want to start
a new discussion about binary PIN support.

The thing is, the wiimote device (and as reported also some other
devices) requires
a BT-address (which may contain \0) as bluetooth pin. Current dbus
design forbids
strings containing \0 (used as string terminator) and so an agent cannot send
binary PINs to bluetoothd as return value of RequestPinCode().

The BT specs 3.0+ HS (Volume 3, Part C, 3.2.3 Bluetooth Passkey) say
the UI-input shall
be UTF-8 encoded and preferably use only the UFT-8 range 0x00-0x7F to
avoid multibyte
characters. There is also a recommendation for multi-byte characters.
Dbus uses utf-8 encoded strings so bluetoothd does not need to modify the
PIN, but current implementation restricts/violates the specs because
it disallows 0x00 as
valid PIN character.

Since the idea with hex-encoding binary PINs and prefixing them with
'$' did not get
accepted, I have some other ideas for this:

1: Use hard coded PINs for those devices. That is, use VID/PID
detection during pairing
and send hardcoded PIN (or based on src/dst address). Problem: VID/PID
information is
not available during pairing or may not be available, yet. Some
devices may even reject
SDP requests when not paired (as mentioned on IRC). Maybe someone has
an idea how to
get this working.

2: Extend DBus Agent API with a function RequestBinaryPinCode() which
works exactly
like RequestPinCode() but returns a bytearray (with length) instead of a string.
A dbus agent then needs to signal to bluetoothd that it provides this
method and bluetoothd
shall call RequestBinaryPinCode() instead of RequestPinCode().
However, I couldn't figure out a proper way to signal this capability
to bluetoothd.
The agent could send some kind of EnabledBinaryPinSupport-Signal to
bluetoothd...

3: Use some kind of encoding in the UTF-8 string as proposed with the
'$' character.
However, this might break old software.


Any comments or other ideas?

Regards
David

Re: Binary PIN Support

[Anderson Lizardo]

Hi David,

On Wed, Jun 1, 2011 at 10:47 AM, David Herrmann
<dh.herrmann@googlemail.com> wrote:
> Any comments or other ideas?

What about a "BinaryPIN" adapter property (default: False) that when
set to True treats the PIN data as binary stream and not as string? It
shall be False by default so to not break backwards compatibility.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Re: Binary PIN Support

[Gustavo F. Padovan]

* Anderson Lizardo <anderson.lizardo@openbossa.org> [2011-06-01 11:32:33 -0400]:

> Hi David,
> 
> On Wed, Jun 1, 2011 at 10:47 AM, David Herrmann
> <dh.herrmann@googlemail.com> wrote:
> > Any comments or other ideas?
> 
> What about a "BinaryPIN" adapter property (default: False) that when
> set to True treats the PIN data as binary stream and not as string? It
> shall be False by default so to not break backwards compatibility.

It's not on the adapter, it may have others devices paired with non-binary
pincode.
Maybe we should signal this BinaryPIN property on the DeviceFound signal,
seems like a good place for this.

-- 
Gustavo F. Padovan
http://profusion.mobi

Re: Binary PIN Support

[Marcel Holtmann]

Hi David,

> Since only half of my binary-PIN patches got applied upstream, I want to start
> a new discussion about binary PIN support.
> 
> The thing is, the wiimote device (and as reported also some other
> devices) requires
> a BT-address (which may contain \0) as bluetooth pin. Current dbus
> design forbids
> strings containing \0 (used as string terminator) and so an agent cannot send
> binary PINs to bluetoothd as return value of RequestPinCode().
> 
> The BT specs 3.0+ HS (Volume 3, Part C, 3.2.3 Bluetooth Passkey) say
> the UI-input shall
> be UTF-8 encoded and preferably use only the UFT-8 range 0x00-0x7F to
> avoid multibyte
> characters. There is also a recommendation for multi-byte characters.
> Dbus uses utf-8 encoded strings so bluetoothd does not need to modify the
> PIN, but current implementation restricts/violates the specs because
> it disallows 0x00 as
> valid PIN character.
> 
> Since the idea with hex-encoding binary PINs and prefixing them with
> '$' did not get
> accepted, I have some other ideas for this:
> 
> 1: Use hard coded PINs for those devices. That is, use VID/PID
> detection during pairing
> and send hardcoded PIN (or based on src/dst address). Problem: VID/PID
> information is
> not available during pairing or may not be available, yet. Some
> devices may even reject
> SDP requests when not paired (as mentioned on IRC). Maybe someone has
> an idea how to
> get this working.

if I remember this correctly, then Wiimote does support DeviceID profile
and thus reports proper VID/PID combinations.

So just create some auto-pair support in bluetoothd (if needed via
plugins) and just auto-pair them like we would do with Secure Simple
Pairing anyway.

There is really no need at all to involve the UI code and mess up the
D-Bus API as it is. It was never designed for hardcoded PIN codes other
then numbers and strings anyway.

> 2: Extend DBus Agent API with a function RequestBinaryPinCode() which
> works exactly
> like RequestPinCode() but returns a bytearray (with length) instead of a string.
> A dbus agent then needs to signal to bluetoothd that it provides this
> method and bluetoothd
> shall call RequestBinaryPinCode() instead of RequestPinCode().
> However, I couldn't figure out a proper way to signal this capability
> to bluetoothd.
> The agent could send some kind of EnabledBinaryPinSupport-Signal to
> bluetoothd...

No way ever. We had that problem when we initially had to support a
fallback for the agent in 3.x series. Never ever again.

> 3: Use some kind of encoding in the UTF-8 string as proposed with the
> '$' character.
> However, this might break old software.

And how is that going to work out in reality. Same as $ is a valid
character. So also a clear no.

Go with 1) and try to just auto-pair the Wiimotes. That is the right
approach and makes a lot sense. It might be the one with the most work
on getting the DeviceID support integrated properly, but it is the right
way forward here.

Regards

Marcel

Re: Binary PIN Support

[Johan Hedberg]

Hi Marcel,

On Thu, Jun 02, 2011, Marcel Holtmann wrote:
> > Since the idea with hex-encoding binary PINs and prefixing them with
> > '$' did not get accepted, I have some other ideas for this:
> > 
> > 1: Use hard coded PINs for those devices. That is, use VID/PID
> > detection during pairing and send hardcoded PIN (or based on src/dst
> > address). Problem: VID/PID information is not available during
> > pairing or may not be available, yet. Some devices may even reject
> > SDP requests when not paired (as mentioned on IRC). Maybe someone
> > has an idea how to get this working.
> 
> if I remember this correctly, then Wiimote does support DeviceID profile
> and thus reports proper VID/PID combinations.
> 
> So just create some auto-pair support in bluetoothd (if needed via
> plugins) and just auto-pair them like we would do with Secure Simple
> Pairing anyway.
> 
> There is really no need at all to involve the UI code and mess up the
> D-Bus API as it is. It was never designed for hardcoded PIN codes other
> then numbers and strings anyway.
> 
> > 2: Extend DBus Agent API with a function RequestBinaryPinCode()
> > which works exactly like RequestPinCode() but returns a bytearray
> > (with length) instead of a string. A dbus agent then needs to
> > signal to bluetoothd that it provides this method and bluetoothd
> > shall call RequestBinaryPinCode() instead of RequestPinCode().
> > However, I couldn't figure out a proper way to signal this capability
> > to bluetoothd.
> > The agent could send some kind of EnabledBinaryPinSupport-Signal to
> > bluetoothd...
> 
> No way ever. We had that problem when we initially had to support a
> fallback for the agent in 3.x series. Never ever again.
> 
> > 3: Use some kind of encoding in the UTF-8 string as proposed with the
> > '$' character.
> > However, this might break old software.
> 
> And how is that going to work out in reality. Same as $ is a valid
> character. So also a clear no.
> 
> Go with 1) and try to just auto-pair the Wiimotes. That is the right
> approach and makes a lot sense. It might be the one with the most work
> on getting the DeviceID support integrated properly, but it is the right
> way forward here.

Does the Wiimote support DeviceID info through EIR? If not we'd need to
change the way CreatePairedDevice works since right now SDP is done only
*after* pairing.

Johan

Re: Binary PIN Support

[Marcel Holtmann]

Hi Johan,

> > > Since the idea with hex-encoding binary PINs and prefixing them with
> > > '$' did not get accepted, I have some other ideas for this:
> > > 
> > > 1: Use hard coded PINs for those devices. That is, use VID/PID
> > > detection during pairing and send hardcoded PIN (or based on src/dst
> > > address). Problem: VID/PID information is not available during
> > > pairing or may not be available, yet. Some devices may even reject
> > > SDP requests when not paired (as mentioned on IRC). Maybe someone
> > > has an idea how to get this working.
> > 
> > if I remember this correctly, then Wiimote does support DeviceID profile
> > and thus reports proper VID/PID combinations.
> > 
> > So just create some auto-pair support in bluetoothd (if needed via
> > plugins) and just auto-pair them like we would do with Secure Simple
> > Pairing anyway.
> > 
> > There is really no need at all to involve the UI code and mess up the
> > D-Bus API as it is. It was never designed for hardcoded PIN codes other
> > then numbers and strings anyway.
> > 
> > > 2: Extend DBus Agent API with a function RequestBinaryPinCode()
> > > which works exactly like RequestPinCode() but returns a bytearray
> > > (with length) instead of a string. A dbus agent then needs to
> > > signal to bluetoothd that it provides this method and bluetoothd
> > > shall call RequestBinaryPinCode() instead of RequestPinCode().
> > > However, I couldn't figure out a proper way to signal this capability
> > > to bluetoothd.
> > > The agent could send some kind of EnabledBinaryPinSupport-Signal to
> > > bluetoothd...
> > 
> > No way ever. We had that problem when we initially had to support a
> > fallback for the agent in 3.x series. Never ever again.
> > 
> > > 3: Use some kind of encoding in the UTF-8 string as proposed with the
> > > '$' character.
> > > However, this might break old software.
> > 
> > And how is that going to work out in reality. Same as $ is a valid
> > character. So also a clear no.
> > 
> > Go with 1) and try to just auto-pair the Wiimotes. That is the right
> > approach and makes a lot sense. It might be the one with the most work
> > on getting the DeviceID support integrated properly, but it is the right
> > way forward here.
> 
> Does the Wiimote support DeviceID info through EIR? If not we'd need to
> change the way CreatePairedDevice works since right now SDP is done only
> *after* pairing.

the Wiimote is still a Bluetooth 2.0 (or even 1.2) device. So no EIR
available. And yes, you are right, we need to figure out on how we can
do DeviceID before pairing. Especially with Security Mode 3 this will
get funny.

Regards

Marcel

Re: Binary PIN Support

[David Herrmann]

On Wed, Jun 8, 2011 at 3:36 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Marcel,
>
> On Thu, Jun 02, 2011, Marcel Holtmann wrote:
>> > Since the idea with hex-encoding binary PINs and prefixing them with
>> > '$' did not get accepted, I have some other ideas for this:
>> >
>> > 1: Use hard coded PINs for those devices. That is, use VID/PID
>> > detection during pairing and send hardcoded PIN (or based on src/dst
>> > address). Problem: VID/PID information is not available during
>> > pairing or may not be available, yet. Some devices may even reject
>> > SDP requests when not paired (as mentioned on IRC). Maybe someone
>> > has an idea how to get this working.
>>
>> if I remember this correctly, then Wiimote does support DeviceID profile
>> and thus reports proper VID/PID combinations.
>>
>> So just create some auto-pair support in bluetoothd (if needed via
>> plugins) and just auto-pair them like we would do with Secure Simple
>> Pairing anyway.
>>
>> There is really no need at all to involve the UI code and mess up the
>> D-Bus API as it is. It was never designed for hardcoded PIN codes other
>> then numbers and strings anyway.
>>
>> > 2: Extend DBus Agent API with a function RequestBinaryPinCode()
>> > which works exactly like RequestPinCode() but returns a bytearray
>> > (with length) instead of a string. A dbus agent then needs to
>> > signal to bluetoothd that it provides this method and bluetoothd
>> > shall call RequestBinaryPinCode() instead of RequestPinCode().
>> > However, I couldn't figure out a proper way to signal this capability
>> > to bluetoothd.
>> > The agent could send some kind of EnabledBinaryPinSupport-Signal to
>> > bluetoothd...
>>
>> No way ever. We had that problem when we initially had to support a
>> fallback for the agent in 3.x series. Never ever again.
>>
>> > 3: Use some kind of encoding in the UTF-8 string as proposed with the
>> > '$' character.
>> > However, this might break old software.
>>
>> And how is that going to work out in reality. Same as $ is a valid
>> character. So also a clear no.
>>
>> Go with 1) and try to just auto-pair the Wiimotes. That is the right
>> approach and makes a lot sense. It might be the one with the most work
>> on getting the DeviceID support integrated properly, but it is the right
>> way forward here.
>
> Does the Wiimote support DeviceID info through EIR? If not we'd need to
> change the way CreatePairedDevice works since right now SDP is done only
> *after* pairing.

Would it be ok if I write a plugin that compares the remote-name of
the bluetooth device with its database and performs SDP queries before
authentication?
That is, the UI programs would have to use CreateDevice() to connect
to wiimotes, the plugin would then see that the device-name looks
familiar, perform SDP query and if the DeviceID matches, then the
plugin will call CraetePairedDevice() (or its internal functions) to
start authentication.

This would mean that despite UI programs call CreateDevice() they will
get always a paired device (if the remote device is a wiimote).
Otherwise I would need to change CreatePairedDevice() to always
perform SDP queries before pairing which would delay the
authentication on many devices that don't need this. Also many devices
may not even allow SDP when not paired so this would even fail on many
devices.

Regards
David

Re: Binary PIN Support

[Marcel Holtmann]

Hi David,

> >> > Since the idea with hex-encoding binary PINs and prefixing them with
> >> > '$' did not get accepted, I have some other ideas for this:
> >> >
> >> > 1: Use hard coded PINs for those devices. That is, use VID/PID
> >> > detection during pairing and send hardcoded PIN (or based on src/dst
> >> > address). Problem: VID/PID information is not available during
> >> > pairing or may not be available, yet. Some devices may even reject
> >> > SDP requests when not paired (as mentioned on IRC). Maybe someone
> >> > has an idea how to get this working.
> >>
> >> if I remember this correctly, then Wiimote does support DeviceID profile
> >> and thus reports proper VID/PID combinations.
> >>
> >> So just create some auto-pair support in bluetoothd (if needed via
> >> plugins) and just auto-pair them like we would do with Secure Simple
> >> Pairing anyway.
> >>
> >> There is really no need at all to involve the UI code and mess up the
> >> D-Bus API as it is. It was never designed for hardcoded PIN codes other
> >> then numbers and strings anyway.
> >>
> >> > 2: Extend DBus Agent API with a function RequestBinaryPinCode()
> >> > which works exactly like RequestPinCode() but returns a bytearray
> >> > (with length) instead of a string. A dbus agent then needs to
> >> > signal to bluetoothd that it provides this method and bluetoothd
> >> > shall call RequestBinaryPinCode() instead of RequestPinCode().
> >> > However, I couldn't figure out a proper way to signal this capability
> >> > to bluetoothd.
> >> > The agent could send some kind of EnabledBinaryPinSupport-Signal to
> >> > bluetoothd...
> >>
> >> No way ever. We had that problem when we initially had to support a
> >> fallback for the agent in 3.x series. Never ever again.
> >>
> >> > 3: Use some kind of encoding in the UTF-8 string as proposed with the
> >> > '$' character.
> >> > However, this might break old software.
> >>
> >> And how is that going to work out in reality. Same as $ is a valid
> >> character. So also a clear no.
> >>
> >> Go with 1) and try to just auto-pair the Wiimotes. That is the right
> >> approach and makes a lot sense. It might be the one with the most work
> >> on getting the DeviceID support integrated properly, but it is the right
> >> way forward here.
> >
> > Does the Wiimote support DeviceID info through EIR? If not we'd need to
> > change the way CreatePairedDevice works since right now SDP is done only
> > *after* pairing.
> 
> Would it be ok if I write a plugin that compares the remote-name of
> the bluetooth device with its database and performs SDP queries before
> authentication?
> That is, the UI programs would have to use CreateDevice() to connect
> to wiimotes, the plugin would then see that the device-name looks
> familiar, perform SDP query and if the DeviceID matches, then the
> plugin will call CraetePairedDevice() (or its internal functions) to
> start authentication.
> 
> This would mean that despite UI programs call CreateDevice() they will
> get always a paired device (if the remote device is a wiimote).
> Otherwise I would need to change CreatePairedDevice() to always
> perform SDP queries before pairing which would delay the
> authentication on many devices that don't need this. Also many devices
> may not even allow SDP when not paired so this would even fail on many
> devices.

I think that actually modifying CreatePairedDevice() to compare the
device name and in case it matches some magic string (provided by a
plugin), do SDP and check VID/PID (provided by the plugin) to do
internal PIN handling.

If the plugin is not present it falls back to doing PIN input from the
UI and that is fine with me.

Regards

Marcel