On Mon, Oct 21, 2013 at 6:31 PM, Anderson Lizardo <anderson.lizardo@xxxxxxxxxxxxx> wrote: > On Mon, Oct 21, 2013 at 9:01 PM, Scott James Remnant <keybuk@xxxxxxxxxx> 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 | keybuk@xxxxxxxxxx | Google -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
