While there is a way to mark an attribute as needing authentication
and/or authorization, there does not seem to be a way to mark an
attribute as requiring encryption (or a particular key size), and I
couldn't find any code that would return the ATT_ECODE_INSUFF_ENC or
ATT_ECODE_INSUFF_ENCR_KEY_SIZE responses.
There is an explicit test case in the GATT TS for this:
TP/GAR/SR/BI-05-C [Read Characteristic Value - Insufficient
Encryption Key Size]
The TRCL maps this:
(GATT:3/8 AND ATT:5/2)
OR
(ATT:3/1 AND ATT:3/10 AND ATT:5/2)
GATT:3/8 [Read Characteristic Value] is Mandatory
ATT:5/2 - [LE Security Mode 1] is Optional, but without it none of the
authentication or authorization stuff makes sense either
Reference:
GATT 4.8.1
ATT 3.4.11, 3.4.4.3
Thoughts?
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
On Mon, Oct 21, 2013 at 6:31 PM, Anderson Lizardo
<[email protected]> wrote:
> On Mon, Oct 21, 2013 at 9:01 PM, Scott James Remnant <[email protected]> wrote:
>> While there is a way to mark an attribute as needing authentication
>> and/or authorization, there does not seem to be a way to mark an
>> attribute as requiring encryption (or a particular key size), and I
>> couldn't find any code that would return the ATT_ECODE_INSUFF_ENC or
>> ATT_ECODE_INSUFF_ENCR_KEY_SIZE responses.
>
> There is a FIXME for this on function att_check_reqs()
> (src/attrib-server.c). Feel free to fix it :)
>
Actually the FIXME seems unrelated, that seems to be about looking at
the reported security level of the connection and only considering the
"have authentication" check to be passed if the level is
BT_IO_SEC_HIGH -- right now it would accept BT_IO_SEC_MEDIUM as
evidence of authentication.
At least that's how I read it.
That said, having stared at the standard and the Test Purposes a
little longer, the test isn't even checking for "insufficient
encryption" but "insufficient encryption key size". In these tests the
PTS actually does negotiate encryption, it's expecting the attribute
server to record the key size and allow attributes to declare that
they need a bigger key.
> Note that, as part of the ongoing implementation of a D-Bus API for
> implementing external GATT services, we have patches (currently being
> cleaned up for upstream submission) that will refactor the internal C
> API for creating GATT services. If you are interested, take a look at
> (note that it is work-in-progress code):
>
> git://git.infradead.org/users/cktakahasi/bluez.git (branch gatt-api-devel)
>
> Also take a look at the API document sent by Claudio a few days ago:
> "[RFC BlueZ v0] doc: Add GATT API"
>
I have this on my TODO to read once we're clear through qualification.
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
Hi Scott,
On Mon, Oct 21, 2013 at 9:01 PM, Scott James Remnant <[email protected]> wrote:
> While there is a way to mark an attribute as needing authentication
> and/or authorization, there does not seem to be a way to mark an
> attribute as requiring encryption (or a particular key size), and I
> couldn't find any code that would return the ATT_ECODE_INSUFF_ENC or
> ATT_ECODE_INSUFF_ENCR_KEY_SIZE responses.
There is a FIXME for this on function att_check_reqs()
(src/attrib-server.c). Feel free to fix it :)
Note that, as part of the ongoing implementation of a D-Bus API for
implementing external GATT services, we have patches (currently being
cleaned up for upstream submission) that will refactor the internal C
API for creating GATT services. If you are interested, take a look at
(note that it is work-in-progress code):
git://git.infradead.org/users/cktakahasi/bluez.git (branch gatt-api-devel)
Also take a look at the API document sent by Claudio a few days ago:
"[RFC BlueZ v0] doc: Add GATT API"
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil