Hi Marcel, >> Hmm, according to the spec the "Optional authentication signature for >> the Attribute Opcode and Attribute Parameters" is 12 octets in length. >> See "Core v4.1, Vol 3, Part F, Section 3.3.1, Table 3: Format of >> Attribute PDU", and tell me what I'm missing. Or are you suggesting >> that we calculate the authentication signature in bt_att? My idea was >> that the calculation of the signature and resolving (for incoming >> signed requests) would be handled by an upper layer. > > We have to calculate the signature brand new anyway since it is generated over the actual PDU. So yes, lets store the master + slave signature keys in bt_att and handle the signature generation and verification internally. > In that case, we need to access the remote and local sign counters as well, which change dynamically. Should bt_att store and internally manage that count then? Basically, the first time the CSRK is generated, the upper layer stores it by calling bt_att_set_signing_key() and that function internally initializes the local sign counter to 0? Similarly, bt_att would also keep track of the remote sign count? -Arman -- 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
