Skip to content

Latest commit

 

History

History
54 lines (33 loc) · 3.59 KB

ext000c-shared-secret-auth.md

File metadata and controls

54 lines (33 loc) · 3.59 KB

EXT000C: Shared Secret Authentication

  • Extension dependencies: 0008
  • Document status: Approved on 2020-02-01

This extension describes a two-way process for authenticating an application and a device with a hard-wired secret key (256 bits) known to the application. Also, the device must have a unique number (UID), by which the application can find its secret key in the list of all devices known to it.

Disadvantage of the method: the application must store in clear text all known secret keys of all devices. An attack on an application can compromise this entire list and make it unreliable, while on devices that are on sale, the extension does not provide for key changes. A more secure authentication algorithm is described in the EXT000F extension.

Commands (CMD)

0016 Device-Server Shared Secret Authentication

Request for device authentication with UID and SKEY (device secret key) known to the application. The client generates two random sequences of bytes and sends them in clear text, along with the hash of the first concatenation of the first sequence and the secret key. By re-hashing these values, the device receives confirmation (if the hashes match) that the application knows the secret key of the device. After that, the device sends in response the hash of the second concatenation of the second sequence and the secret key. The application likewise receives confirmation that the device knows its secret key.

For each connection of the device with the client, the client is considered unauthenticated and receives the minimum access rights (minimum - general requests and requests for the extensions EXT0008 and EXT000C, i.e. commands 0000, 0001, 0012 and 0016 , any additional requests to start encryption, and others - at the discretion of the device).

This request can be initiated at any time at the discretion of the client, the order of work is always the same.

If the client receives an erroneous hash value, device authentication is considered unsuccessful and further actions are left to the client's discretion (for example, immediately disconnect the connection or continue polling the device, marking it as an unknown manufacturer).

If the device receives an incorrect hash in the request, it must return an error to the client, report the error to the user when working with the application, and leave the minimum access rights to the unauthenticated client; there is no need to terminate the connection.

At the discretion of the hardware developers - on the device side, a limitation on the number of authentication requests in a certain period of time can be added (to protect against brute-force attacks).

Request

<TID> 3900 0062 0016 <DTOKEN> <STOKEN> <CHALLENGE>

Response

<TID> 3900 0022 0016 <ANSWER>

Fields

Field Length (bytes) Description
DTOKEN 32 Random sequence of 256 bits.
STOKEN 32 Random sequence of 256 bits.
CHALLENGE 32 the first 256 bits of the SHA-512 hash of the following set of bytes: <DTOKEN> <SKEY>, where SKEY is a secret key (256 bits) hardwired into the device known to the application.
ANSWER 32 the first 256 bits of the SHA-512 hash of the following set of bytes: <STOKEN> <SKEY>, where SKEY is a secret key (256 bits) hardwired into the device, known to the application.

Errors

Code Description
0010 Mismatch of hash CHALLENGE with the expected value (client authentication error).
0011 Too many authentication requests, try again later.