Found hard-coded secret-key for challenge-response on libfprint

[Seong-Joong Kim]

Dear all,

We need to fix hard-coded symmetric-key for challenge-response authentication on `uru4000 driver`.

The driver uses a symmetric-key technique to encrypt the challenge data using AES encryption algorithm for authentication.

"2nd generation MS devices added an AES-based challenge/response authentication scheme, where the device challenges the authenticity of the driver."
link: https://gitlab.freedesktop.org/libfprint/libfprint/blob/master/libfprint/drivers/uru4000.c#L348

Unfortunately, the driver creates risk by exposing a hard-coded secret key as follows:

/* For 2nd generation MS devices */
static const unsigned char crkey[] = {
 0x79, 0xac, 0x91, 0x79, 0x5c, 0xa1, 0x47, 0x8e,
 0x98, 0xe0, 0x0f, 0x3c, 0x59, 0x8f, 0x5f, 0x4b,
};
link: https://gitlab.freedesktop.org/libfprint/libfprint/blob/master/libfprint/drivers/uru4000.c#L150

If the library wants to use challenge-response authentication, we need to introduce a new key distribution scheme also.

Furthermore, I don't know why the library is really necessary to use it such a resource constrained environment.

Lastly, is it a kind of CWE-321: Use of Hard-coded Cryptographic Key? (see https://cwe.mitre.org/data/definitions/321.html)

Many thanks!!

[Sebastien Bacher (seb128)]

Thank you for your bug report, could you maybe report that upstream? We don't have any active maintainer for that stack in Ubuntu and upstream is better placed to respond to the issues you are raising

[Seong-Joong Kim (sungjungk)]

Okay! I just reported it to upstream.

[Sebastien Bacher (seb128)]

Can you share the url?

[Seong-Joong Kim (sungjungk)]

It is https://gitlab.freedesktop.org/libfprint/libfprint/issues/151

[Sebastien Bacher (seb128)]

Thanks

[Sebastien Bacher (seb128)]

Conclusion from the upstream bug is that it needs to be fixed in the hardware, closing