How encryption and security work

A technical description for people who work with technology daily, but aren't IT security specialists.

1. Who's talking to whom

Component	What it holds	What it does
Card	secret AES key (DESFire)	never reveals the key, only "signs" challenge responses with it
Reader	nothing secret	just an RF antenna — reads/writes the card, decides and knows nothing itself
ChipLogin service (on the station PC)	its own certificate + private key (the station's mTLS identity)	the only thing on the station allowed to talk out over the network; owns the reader
Credential Provider	nothing — stateless	a thin switch between the Windows login screen and the service, over a local pipe
Auth server (on your network, not in our cloud)	the database of cards, their keys, and account passwords	makes the actual "who is this" and "what are they allowed" decision

Two things are easy to mix up: ChipLogin Cloud (our SaaS, handling only licensing/accounts/telemetry — "is the station alive") and the Auth server (runs on-prem on your network, handling cards/passwords/login). The encryption this document describes concerns only the latter — our cloud servers never touch your login data at all.

2. Data flow when a card is tapped

RFID — card ↔ reader network — station ↔ server (mTLS) internal processing

Step by step:

(0) Before anything happens with the card: the station and server verify each other's certificate and open an encrypted channel between them (mTLS). This runs continuously in the background, not just after a card is tapped.
(1) The employee taps their card against the reader.
(2) The reader activates the card with its RF field and reads its UID (just "which card", no proof of authenticity yet).
(3) The service sends the UID + a login request (and a one-time key, see layer C below) over the mTLS channel to the server.
(4) The server generates a random challenge and sends it back to the station.
(5) The station forwards that challenge through the reader to the card — unchanged, just delivered.
(6) The card computes the response itself using its secret key (the key never leaves the card, only the result of the computation does).
(7) That response travels back through the reader and station to the server.
(8) The server performs the same computation with its copy of the key and compares — if it matches, the card is genuine.
(9) The server sends back the Windows password, encrypted for this one specific attempt only (ECIES).
(10) The service decrypts the password and sends it to the Credential Provider over a local pipe.
(11) The Credential Provider hands it to Windows (LSA) — the employee is logged in.

3. Three encryption layers running at once

These layers protect different parts of the exchange: mTLS authenticates devices and encrypts the channel, DESFire challenge-response verifies possession of the configured card key, and ECIES seals the password payload to a one-time station key. They are separate controls, but the security of the complete system still depends on correct implementation, key management, endpoints, and server operation.

Layer A — the channel (mTLS): both sides verify each other before they start talking

Ordinary HTTPS (like when you open your bank in a browser) only verifies one side — you know you're talking to the real bank, but the bank doesn't yet know anything about you (you send your password only after the encrypted channel is already open).

ChipLogin uses mTLS (mutual TLS), so both sides authenticate with certificates. The station generates its own private key during installation and is designed to retain it locally; the server has its own identity. Before application data is exchanged, each side must present credentials trusted by the other. A device without the corresponding trusted certificate and private key cannot complete that authentication.

Layer B — the card (DESFire, "challenge-response"): proving you know the key, not showing the key itself

This is the most important and least intuitive part, so let's walk through it with an example.

An ordinary cheap card (like an old attendance badge) works like an 1980s car key — it has a number engraved on it (UID), and the system simply checks "does that number match?" The problem: the UID can be read and copied with an ordinary copier for a few dollars — it's as if the lock only checked the shape of the key, which anyone can mill for themselves.

A DESFire card works differently. Both the card and the server know the same secret key (set once during card manufacturing/personalization; the card never reveals it — not even to its owner or the reader). During login:

The server generates a random number (a challenge) — different every time.
That challenge is sent to the card. The card combines it with its secret key using AES encryption and computes a response.
The server performs the same computation with its copy of that key and compares the results.
If the response matches, it's certain: this device knows the secret key — without ever having sent it over the wire.

Why this is clever: even if someone recorded this entire exchange (eavesdropping), it's useless the second time around — next time the challenge is different (random), and the old response can't be recycled. A cloned card that only knows the UID can't answer the challenge at all — the server recognizes this immediately and never lets such a card into the rest of the process (the card type is checked as the very first step).

Layer C — the password itself (ECIES): sealed for this one specific attempt only

In layer B, the card proved "I am the right device," but nobody has said what the actual Windows password is yet. That comes only now, and it arrives specially packaged for this one station and this one login attempt only:

At the start (in the "begin" step), the station generates a one-time keypair, which it discards after use, and sends the public part to the server with the login request. Once the server has verified the card (layer B), it encrypts the password specifically for this particular one-time key (a technique called ECIES). Only the station that just asked can decrypt it, and only at this moment — even the server itself can't read that message again after sending it, because it doesn't hold the one-time private half.

The result: a plaintext (unencrypted) password never exists on the network, and it exists in the computer's memory for only a fraction of a second — exactly between the moment the service decrypts it and the moment it hands it to Windows and clears it from memory.

4. Why it's designed this way — principles that repeat throughout

Principle	What it means in practice
Keys never travel, only proof of them does	the station's private key stays on the station, the card's secret key stays on the card — only "I proved I know it" ever goes over the network, never the key itself
The UID isn't a secret, it's just an address	even if an attacker knows a card's UID (readable even with a cheap reader), that alone unlocks nothing — it's just "which card," not "proof it's genuine"
No long-lived secret is sent as plaintext	captured network traffic is protected by mTLS, while each password payload is additionally sealed to the one-time key generated for that login attempt
Each component has a defined exposure	the station does not persist Windows passwords; a UID-only copy cannot pass DESFire challenge-response; server-side secrets remain a separate asset that must be protected through deployment and key-management controls

5. What happens under attack — concrete scenarios

Scenario	What happens
Someone copies a card's UID with a cheap copier	The server recognizes the card can't answer the cryptographic challenge (it doesn't know the secret key) → `unknown_card`, rejected immediately, it never even reaches the real data exchange
Someone eavesdrops on the network between the station and server	They only see encrypted traffic (mTLS). Even if they decrypted it, inside they'd find only data sealed for one use, useless a second time
Someone steals or takes apart the computer next to a machine	There's no stored password to find — passwords live on the server, and on the station they exist in memory for only a fraction of a second during login itself
Someone steals an entire station along with its certificate (mTLS identity)	The admin blocks/revokes the station on the server just like a card — from that moment, the server rejects every request bearing its certificate, even if the attacker powers the computer on and keeps trying
Someone impersonates the auth server (a fake server on the network)	The station rejects it at the mTLS level already — it doesn't have a valid certificate signed/approved by what the station recognizes as "the real server"
An employee loses their card	The administrator blocks/revokes the card in the system (a pure database operation) — with no need to change anything on the stations

6. What's different for the machine reader (production, not a PC)

The same three layers apply there too, with one difference: because of network outages on the shop floor, the reader (the brain) keeps a current, signed copy of the rules and card keys locally (in a secure chip) and makes decisions even without a connection to the server. There, the network isn't used to verify every single card tap — it's used to periodically refresh that local copy and to send back records of what happened once the connection is restored. Details on this variant are on the ChipLogin for Machines .

← Back to Security Architecture