Advisory X41-2021-003: Telenot complex - Insecure AES Key Generation

Summary and Impact

The complex alarm system manufactured by Telenot supports the use of NFC
tags for the authorization of users using DESFire EV2[6] tags that support
AES encryption.
The supplied management software compasX can generate the secret AES keys
that are stored both on the system and the NFC tag and are used for the mutual
authentication between them.
It was found that keys generated using compasX are predictable,
which allows attackers to clone NFC tags and gain unauthorized access to
secured areas, unless further security controls, like the requirement to provide
a PIN, are in place.

Deployments which use both

  • NFC tags of type MIFARE DESFire EV1 or EV2
  • AES keys generated with vulnerable compasX versions for use
    with the above tags

are vulnerable. All such AES keys should be replaced (including those
used for remote access) by either a manually generated key or
by using a recent compasX software revision (32.0) that is using a cryptographically
secure random number generator.

Root Cause Analysis

compasX versions older than 32.0 use random numbers supplied by
the cryptographically insecure PRNG implementation of the rand() function
to create AES keys.
The PRNG instance is seeded with the current system time as UNIX timestamp
via calls to srand(time()). Because the supplied timestamp value is a
32-bit number, the amount of possible seeds is bounded by the maximum
unsigned 32 bit value of 4294967295, down from
2128 possible keys for the used AES128. It is feasible
to search the whole key space on a modern Desktop system in reasonable time.

The possible key space can be even further reduced when assuming that
MIFARE DESFire EV1 seems to have first been introduced in 2006. Between
2006-01-01 00:00:00 GMT (timestamp 1136073600) and 2021-11-30 00:00:00 GMT
(timestamp 1638230400) there are 502156800 timestamps that could have been
used as seeds.

The Borland C/C++ library used in compasX, states that “rand uses a multiplicative
congruential random number generator”1, which is not a cryptographically secure
pseudorandom number generator (CSPRNG).
It’s important to note that even if the seed hadn’t been time-based, rand()
“generates a well-known sequence and isn’t appropriate for use as a
cryptographic function”2. While the previous quote is from Microsoft’s
documentation about their own implementation, a comparable warning is missing
from the documentation of the used implementation of rand().

The current recommended CSPRNG on modern Windows systems is
BCryptGenRandom3, which is part of the “Cryptography API: Next
Generation”4.

Proof of Concept

Head over to the blog post for a detailed description and our proof of concept!

Workaround

It is strongly recommended to raise the security level during the time window
until the AES keys can be changed to securely generated ones.
The complex alarm systems supports alternative authentication factors that
can be combined with the Desfire NFC tag authentication.
An example for such an additional factor is a requirement for a valid
PIN entry on the complex alarm system in addition to a successful
Desfire authentication to disarm the alarm.

Timeline

About X41 D-SEC GmbH

X41 is an expert provider for application security services. Having extensive
industry experience and expertise in the area of information security, a strong
core security team of world class security experts enables X41 to perform
premium security services.

Fields of expertise in the area of application security are security centered
code reviews, binary reverse engineering and vulnerability discovery. Custom
research and IT security consulting and support services are core competencies
of X41.

  1. https://docwiki.embarcadero.com/RADStudio/Sydney/en/Rand 

  2. https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rand?view=msvc-170 

  3. https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom 

  4. https://docs.microsoft.com/en-us/windows/win32/seccng/cng-portal