Cards: from reading a number to verifying a key

1. LF 125 kHz: the card reports an identifier

Common identification cards in this group, such as EM4100 and compatible types, send a fixed stored number to the reader. The system looks it up in its directory and decides based on the assigned permission. In this use, the card does not prove knowledge of a secret cryptographic key.

The number is an identifier used to find a record. Receiving the right number alone does not prove that the issued card is genuine. A sign-in process that distinguishes the actual card from a device imitating its identifier needs an additional authentication step.

2. HF 13.56 MHz, UID only: the reading method matters

The UID is an identifier used when communicating with a card. Some access systems read only this value and grant entry based on it. They may not use the card's cryptographic capabilities at all.

UID-only therefore describes a method of use, not a separate chip family. Even a card capable of stronger authentication can be used this way. When assessing existing cards, it is important to identify not only the chip model but also whether the system actually verifies the key.

3. MIFARE Classic: an older generation of protection

MIFARE Classic can protect access to its memory using keys and the Crypto1 cipher. It is therefore not automatically just a card with a number. Its cryptographic protection belongs to an older generation, however; manufacturer NXP points to MIFARE DESFire and MIFARE Plus for security-relevant applications.

If a system reads only the UID from a Classic card, it does not use even this memory protection. When designing a new sign-in solution, we therefore separate two questions: what protection the card offers, and what authentication the particular system actually performs.

4. MIFARE DESFire EV2 / EV3: ChipLogin's current principle

DESFire supports mutual cryptographic authentication and AES with a 128-bit key. The card and verifier prove that they know the right secret key without sending it to each other during authentication. DESFire also supports several separate applications on one card, each with its own keys.

When issuing a card, ChipLogin prepares it with its sign-in key and verifies knowledge of that key when the card is used. In Auth mode, the company server performs this task; in Local mode, a service on the standalone computer does. A matching card number alone is not enough to release credentials.

How challenge and response work

In simple terms, the verifier prepares a new random challenge and the card responds using its key. The verifier checks the response. A previously captured response will not solve the new challenge because it contains different random values.

Actual DESFire authentication has several steps, with both parties proving knowledge of the key. The exchange also derives keys for protected communication. The slide diagram illustrates this principle, not the exact sequence of protocol messages.

5. PKI: a possible future direction for ChipLogin

PKI uses a private and public key pair. The card can sign a challenge with its private key, and the other party verifies the signature with the public key. A certificate links the public key to an identity and a trusted issuer. The verifier therefore does not need to know the same secret key as the card.

This sign-in method also requires certificate management: issuance, trust in a certification authority, renewal and revocation. Its specific use depends on the card and the target system's support. PKI is a different arrangement for authentication and key management; the label alone does not guarantee the security of the entire deployment.

For ChipLogin, this is a possible future extension. This presentation does not announce current support for user PKI card sign-in or a release date. The sign-in description in the preceding sections refers to DESFire. Certificates already used between the workstation and Auth server authenticate devices and belong to a different part of the system.

Can we use the cards we already have?

Before deployment, we check the specific card type, reader and ability to prepare a ChipLogin application on the card with the appropriate keys. The same appearance, frequency or MIFARE label alone does not confirm compatibility.

With suitable cards, you can keep using your existing equipment. If a card also serves other systems, setup must respect their applications and card administration rights. The aim is one card for everyday work, with cryptographic authentication wherever ChipLogin needs it.