CRYPTOGRAPHIC MIGRATION
Moving a live fare system from MIFARE Classic to MIFARE Plus while the installed base continues to operate.
Cryptographic migration is often described by its endpoints. The old credential uses one mechanism; the new credential uses another. Replace the cards, update the readers and the system becomes stronger.
A live transport system cannot usually move in one step. Cards may remain in circulation for years. Validators are updated by depot, vehicle or operator. Personalisation equipment and back-office services follow different release cycles. Lost and replacement media introduce further paths through the transition.
Migration from MIFARE Classic to MIFARE Plus makes that reality explicit. MIFARE Plus was designed with compatibility and staged security levels that can support transition toward AES-based authentication and secure messaging. Those facilities are valuable, but they do not define the operator’s migration.
The migration is the set of states in which cards, readers, SAMs, keys and back-office rules may coexist—and the controls that permit movement from one state to the next.
Compatibility is a starting condition
MIFARE Plus can participate in infrastructures originally built around MIFARE Classic. In compatibility-oriented modes, a new card can be introduced before every reader is ready for the stronger security mode. Later, the card can be moved toward AES-based operation when the surrounding infrastructure has been upgraded.
This solves an important deployment problem: distribution and security activation do not need to occur on the same day.
It also creates a period in which the system supports more than one security condition. If that period is not governed, compatibility can become permanent downgrade. The ability to operate like the old card should therefore be treated as a transitional state with entrance criteria, monitoring and an exit plan.
The architecture needs to identify which operations are permitted in each state. Reading a non-sensitive identifier, updating a purse or modifying security configuration do not carry the same consequence. NXP’s later MIFARE Plus EV2 features include sector-level migration and separation of access rights between legacy-compatible and stronger modes, illustrating how detailed that policy can become.
Model every population
The word “fleet” hides several distinct populations:
- legacy MIFARE Classic cards;
- MIFARE Plus cards operating in a compatibility state;
- cards already activated for AES-based operation;
- readers capable only of the legacy flow;
- readers with updated firmware but old key material;
- readers and SAMs fully provisioned for both transition and target states;
- personalisation stations that create new cards or replace damaged ones.
Each combination implies a transaction path. Some combinations must work temporarily; others must fail deliberately. A migration plan that lists components but not allowed combinations leaves critical behaviour to accident.
A state matrix is more useful than a rollout slogan. For each card state and terminal generation, it records whether the operation is accepted, which authentication is used, which data may be changed and what evidence is logged.
Keys migrate differently from cards
A new algorithm requires new key material, but the key transition has its own lifecycle.
Master keys need generation under an appropriate ceremony, separation by environment and purpose, controlled distribution to SAMs or personalisation systems, and versioning that lets the terminal choose the intended key without trial-and-error downgrade. Diversified card keys require stable, documented inputs and an agreed derivation method.
During coexistence, a secure module may hold both legacy and target keys. That makes access control inside the module especially important. Firmware that can freely invoke every key has not gained much separation merely because the bytes are stored in secure hardware.
The transition also needs answers for:
- readers that miss a key update;
- cards personalised with an unexpected key version;
- rollback after a failed application release;
- retirement of legacy keys after the last legitimate use;
- test keys accidentally carried into production paths;
- audit evidence showing which security mode protected a transaction.
Card issuance is visible. Key population is quieter and often more consequential.
Activation should be monotonic
A move to a stronger card state should normally be one-way. If a credential can be returned to a weaker mode through an ordinary field command, an attacker may be able to create the downgrade that the migration was intended to eliminate.
Irreversible transitions deserve conservative preconditions. Before activation, the system should know that the target application data is valid, the required keys exist, the relevant readers have passed interoperability tests and a failed or interrupted operation has a defined outcome.
An anti-tear mechanism helps preserve card data across interrupted writes, but it does not decide the business state. The surrounding software still needs to recognise whether an activation completed, whether a retry is safe and whether the card should be quarantined for controlled recovery.
Monotonic does not mean rushed. It means that progress toward the target state is recorded and that rollback occurs through operational recovery—not by silently restoring the weaker cryptographic condition.
Data compatibility is not semantic compatibility
MIFARE Plus provides memory and command compatibility intended to ease migration from MIFARE Classic. Existing sector layouts and value operations may therefore remain technically accessible.
That does not guarantee that the old data model should remain unchanged. A historical layout may have duplicated values, implicit version rules, terminal-maintained counters or assumptions tied to the old authentication flow. Reproducing those assumptions under AES preserves operational debt inside a stronger channel.
The migration is an opportunity to distinguish three layers:
- the physical card and command set;
- cryptographic authentication and messaging;
- the application’s record structure and transaction semantics.
They can be migrated together or in planned stages, but they should not be confused. Changing the card’s security level does not by itself correct weak application logic, excessive key sharing or an ambiguous fare record.
Reader firmware carries the transition
The reader is where many migration decisions become executable. It identifies the card family and state, selects a supported transaction path, coordinates with a SAM where present and produces an outcome within the time available at a gate or vehicle.
Firmware therefore needs deterministic discovery. Repeatedly attempting protocols until one succeeds can create latency, obscure faults and accidentally enable downgrade. Card identification, supported capabilities and expected state should lead to one allowed path.
Telemetry is essential during rollout. The back office should be able to distinguish an old card from a new card in legacy mode, an authentication failure from a missing key and a reader software defect from damaged media. Aggregate counts show whether the population is moving toward the target or accumulating in an intermediate state.
Logs must avoid exposing keys or complete sensitive transaction data. Useful migration evidence consists of versions, states, failure classes and identifiers scoped for diagnosis.
Rollout is a security control
A safe sequence usually upgrades the ability to accept the future state before issuing credentials that require it. Readers and secure modules receive code and keys, are tested across the actual card population, and only then does activation expand.
Pilot groups should be chosen to expose operational diversity rather than merely minimise size. Depot connectivity, validator models, transaction load and recovery access can matter more than the number of cards.
Exit criteria are equally important. The migration is not complete when most transactions use the new path. It is complete when legacy acceptance can be removed without excluding legitimate users, legacy keys can be retired, and monitoring confirms that no supported process still creates weaker-state credentials.
Leaving the legacy path enabled “just in case” preserves the attack surface indefinitely.
What the migration proves
A successful MIFARE Plus transition does more than introduce AES. It demonstrates control of a distributed cryptographic lifecycle.
The system can identify credential state, provision the correct keys, prevent unintended downgrade, survive interrupted transitions and explain failures across a heterogeneous installed base. Those capabilities are transferable to future algorithm and credential migrations.
The essential artifact is not the new card specification. It is the state model shared by issuance, readers, secure modules and the back office.
Cryptographic endpoints matter. Operational security is determined by every state allowed between them.
Context and scope
This note draws on transport-card migration work involving MIFARE Classic and MIFARE Plus. It presents the engineering structure of a staged migration without disclosing the transport operator, production keys, card data layout, rollout sequence or reader implementation.
