6. ATT level security and digital signing

Closely related to security are the concepts of authentication, authorization, and the access rights of resources. Attribute permissions are a combination of access permissions, encryption permissions, authentication permissions and authorization permissions.

Authentication is the process which guarantees that a message has originated from a trusted party. Authorization is a confirmation by the user to continue with the procedure. Authentication does not necessarily provide authorization.

In BLE, the following access permissions are possible:

  • Readable

  • Writeable

  • Readable and writable

The following encryption permissions are possible:

  • Encryption required

  • No encryption required

The following authentication permissions are possible:

  • Authentication Required

  • No Authentication Required

The following authorization permissions are possible:

  • Authorization Required

  • No Authorization Required

Encryption, authentication, and authorization permissions can have different possibilities; for example, a specific attribute could require a particular kind of authentication or a certain minimum encryption key length. An attribute can have several combinations of permissions that apply; for example, a specific attribute could allow any of the following:

  • Read if encrypted (authentication not required)

  • Write if authenticated and encrypted

  • Read or write if authenticated and authorized (irrespective of encryption)

6.1. Authentication and data signing

Digital communications are ubiquitous and in the case of wireless transmissions there must be a robust way of determining if the messages we receive have originated from the expected end or if they have been altered. Just like a paper document, a digital document or message can be signed with a digital signature.

A digital signature is a mathematical scheme which provides extremely high probability that the received message is original. The benefits that digital signatures provide are:

  • Authentication: When the message is received and the signature is verified, we can confirm the originator of the message.

  • Message integrity: A digital signature assures us that the received message has not been altered in any way.

  • Non-repudiation: This means that the party that has signed the message cannot deny at a later time that they have signed it.

In the Bluetooth Low Energy specification, authentication is provided either by enabling encryption or at the ATT layer with the Connection Data Signing procedure.

6.1.1. Connection Data Signing procedure

This procedure is invoked when encryption is not required and the Connection Signature Resolving Key is available (LE security mode 2). A device generates a new CSRK for each set of peer device(s) to which it sends signed data in connections. The inputs to the signing function are the Data PDU, the CSRK, and the SignCounter value, which is a counter incremented every time a message is signed. The resulting signature is composed of the counter value and the Message Authentication Code, as can be seen in the figure below.

Every Attribute operation indicates in its opcode if the message is signed or not by means of a bit called Authentication Signature Flag. If the Authentication Signature Flag of the Attribute opcode is set to one, the Authentication Signature value will be appended to the end. Only the Write command may include an Authentication Signature. Authentication signatures are not sent when the link is encrypted, since an encrypted link already includes authentication data on every packet.

The receiving device is protected against a replay attack by comparing the received SignCounter with previously received SignCounter from the same peer device. If the SignCounter was previously used then the receiving device will ignore the Data PDU.

_images/att_signing.png

Figure 28 Generic format of signed data

6.2. Authorization

The Attribute protocol can be used to access information that may require both authorization and an authenticated and encrypted physical link before an attribute can be read or written. Each device implementation will determine how authorization occurs. Authorization procedures are defined in GAP, and may be further refined in a higher layer specification. This means that developer of the software has the freedom to design their own way of user confirmation, for example by pressing a button or with a touch screen. If a request is issued when the client has not been authorized to access this information, the server will send an Error Response with the error code set to Insufficient Authorization.

In case that such a request is issued when the physical link is unauthenticated, the server shall send an Error Response with the error code set to Insufficient Authentication. A client wanting to read or write this attribute can then request that the physical link be authenticated, and once this has been completed, send the request again.