Diferenças entre MIFARE e DESFire em controle de acesso: 13,56 MHz, UID, autenticação criptográfica, AES, gestão de chaves, migração e integração com leitores.
Confira!
MIFARE é uma família de tecnologias de cartões inteligentes sem contato utilizada em sistemas de transporte, identificação e controle de acesso. DESFire é uma das famílias mais avançadas dentro do ecossistema MIFARE e oferece recursos criptográficos, autenticação e mensagens seguras que permitem construir credenciais muito mais robustas do que arquiteturas baseadas apenas na leitura de um identificador estático.
O erro mais comum em projetos de controle de acesso é tratar “MIFARE” como se fosse uma única tecnologia e assumir que qualquer cartão de 13,56 MHz oferece o mesmo nível de segurança. Não oferece. Existem famílias, gerações, modos de autenticação, formas de armazenamento e políticas de chave diferentes. O nível real de proteção depende tanto do chip quanto da maneira como a aplicação foi configurada.
Outro erro recorrente é comprar um cartão tecnicamente capaz de autenticação criptográfica e usar somente o UID como número de credencial. Nesse caso, boa parte dos mecanismos avançados da tecnologia não participa da decisão de acesso. Para obter benefício real, leitor, credencial, aplicação, chaves e controladora precisam ser projetados como uma cadeia.
O que é MIFARE
MIFARE é uma marca e família de produtos de identificação sem contato baseada em tecnologias HF/NFC, geralmente associadas à frequência de 13,56 MHz e ao padrão ISO/IEC 14443. Dentro da família existem produtos com capacidades e modelos de segurança bastante distintos.
Em controle de acesso, o nome MIFARE aparece frequentemente como requisito genérico de cartão ou leitor. Essa descrição é insuficiente para projetos atuais, porque não informa qual família, qual mecanismo de autenticação, qual estrutura de aplicação ou qual política de chaves será utilizada.
MIFARE não é sinônimo de DESFire
DESFire pertence ao ecossistema MIFARE, mas não representa todos os cartões MIFARE. MIFARE Classic, MIFARE Plus e MIFARE DESFire possuem arquiteturas e gerações diferentes.
Ao escrever uma especificação, é melhor declarar requisitos de segurança e interoperabilidade do que simplesmente exigir “cartão MIFARE”.
O que é MIFARE DESFire
MIFARE DESFire é uma família de circuitos integrados contactless voltada a aplicações que exigem múltiplas aplicações, autenticação e proteção criptográfica. A geração DESFire EV3, por exemplo, suporta algoritmos criptográficos incluindo AES, autenticação, secure messaging, múltiplas aplicações e mecanismos adicionais de proteção.
Segundo a documentação atual da NXP, DESFire EV3 é compatível com ISO/IEC 14443 A e possui certificação Common Criteria EAL5+ em hardware e software. Esses dados caracterizam a plataforma, mas a segurança do sistema final ainda depende da implementação.
EV1, EV2 e EV3
As gerações evoluíram em recursos de segurança, gerenciamento de aplicações e proteção transacional. Projetos brownfield podem conter cartões EV1, EV2 e EV3 simultaneamente, além de tecnologias legadas.
A decisão de migração deve avaliar interoperabilidade dos leitores, chaves existentes, infraestrutura de emissão e possibilidade de coexistência durante o período de transição.
UID não é autenticação criptográfica
O UID identifica um chip ou cartão dentro do protocolo. Em muitas instalações antigas, o leitor captura esse identificador e o envia como número de credencial. Essa abordagem é simples, mas não utiliza os mecanismos mais fortes da credencial.
Uma arquitetura baseada apenas em UID deve ser avaliada de acordo com o risco, porque o sistema pode estar usando um smart card sofisticado como se fosse apenas um número de proximidade.
Por que isso acontece
Sistemas legados foram frequentemente implantados para maximizar compatibilidade entre leitores, controladoras e cartões. Ler UID reduz dependência de aplicações específicas e de gestão de chaves, mas também reduz a capacidade de autenticar o cartão de forma forte.
O que muda com autenticação
Quando leitor e cartão executam autenticação criptográfica, a decisão pode depender de uma aplicação protegida, chaves e dados cuja leitura ou alteração exige autorização. Isso aumenta a dificuldade de reproduzir uma credencial apenas copiando um identificador visível.
Estrutura de aplicações e arquivos
DESFire permite organizar dados em aplicações e arquivos com regras de acesso. Essa estrutura possibilita usar uma mesma mídia para diferentes funções, como controle de acesso, identificação interna e outros serviços, mantendo domínios lógicos separados.
A vantagem só existe se a governança definir quem administra cada aplicação e quais chaves protegem cada função. Usar uma única chave global compartilhada por toda a organização cria dependência e amplia impacto de comprometimento.
AES e secure messaging
DESFire EV3 suporta AES e mecanismos de secure messaging. Em termos de projeto, isso significa que comandos e dados podem ser protegidos por autenticação e criptografia conforme a configuração da aplicação.
Não basta exigir “AES” em uma ficha técnica. É preciso saber onde a criptografia é aplicada, como as chaves são provisionadas, se cada site ou aplicação possui domínio próprio e como ocorre rotação ou substituição.
Criptografia no cartão e criptografia no cabo são coisas diferentes
A comunicação cartão-leitor pode usar autenticação criptográfica enquanto o trecho leitor-controladora permanece vulnerável se utilizar interface legada sem proteção. Da mesma forma, OSDP Secure Channel pode proteger leitor-controladora, mas não corrige uma credencial baseada em UID fraco.
A segurança precisa ser analisada por trecho.
Gestão de chaves é parte da engenharia
A decisão entre UID, aplicação criptográfica, modelo de chaves e coexistência com o legado deve ser documentada no projeto, não deixada apenas à parametrização do integrador.
Chaves criptográficas são ativos. Precisam ser geradas, armazenadas, distribuídas, substituídas e eventualmente revogadas de forma controlada. A organização deve saber quem possui acesso e como recuperar o sistema em caso de troca de fornecedor ou perda de um componente.
Uma solução que depende de uma chave desconhecida pelo cliente cria risco de lock-in. Esse problema aparece frequentemente em migrações quando a organização possui cartões e leitores, mas não possui documentação de chaves e personalização.
Chaves padrão
Manter chaves padrão de fábrica ou chaves conhecidas reduz drasticamente o valor da autenticação. O projeto deve exigir personalização segura e comprovação de que o processo foi executado.
Diversificação de chaves
Em algumas arquiteturas, chaves podem ser derivadas por cartão, aplicação ou outro contexto, reduzindo o impacto de comprometimento de uma única credencial. A estratégia de diversificação depende da plataforma e precisa ser documentada.
Leitor compatível não significa aplicação compatível
Um leitor pode declarar suporte a MIFARE ou DESFire, mas isso não prova que ele consegue executar a aplicação específica utilizada pelo cliente. É necessário verificar suporte a geração do cartão, autenticação, chaves, formatos de saída e mecanismos de atualização.
Em licitações e projetos, expressões como “compatível com MIFARE” devem ser detalhadas por requisitos funcionais e de segurança.
MIFARE Classic, Plus e DESFire
As três famílias podem coexistir em instalações reais, mas não devem ser tratadas como equivalentes.
| Família | Uso típico | Segurança de projeto | Observação |
| MIFARE Classic | base legada e aplicações simples | depende de mecanismos legados | avaliar migração em novos projetos críticos |
| MIFARE Plus | migração e evolução sobre ecossistemas existentes | possui modos e mecanismos mais modernos | verificar configuração efetiva |
| MIFARE DESFire | aplicações com autenticação e múltiplos domínios | suporta arquitetura criptográfica avançada | exige gestão de chaves e aplicação correta |
A tabela não substitui análise da geração e configuração. O mesmo nome comercial pode abranger diferentes versões e modos.
Segurança por camadas
Uma credencial segura participa de uma arquitetura maior. As camadas principais são:
- emissão e cadastro da credencial;
- autenticação cartão-leitor;
- comunicação leitor-controladora;
- decisão na controladora;
- comunicação com servidor;
- proteção do banco de dados;
- identidade administrativa;
- revogação e ciclo de vida.
Fortalecer apenas uma camada não garante segurança sistêmica.
DESFire e OSDP
Quando credencial, leitor, controladora, rede e sistemas corporativos formam uma cadeia de autenticação, a arquitetura precisa ser especificada de ponta a ponta.
DESFire e OSDP resolvem trechos distintos. DESFire pode proteger a relação entre credencial e leitor. OSDP estrutura a comunicação entre leitor e controladora e pode utilizar Secure Channel quando suportado e configurado.
Em um projeto moderno, é coerente combinar credencial criptográfica com comunicação supervisionada e protegida até a controladora. O artigo OSDP x Wiegand aprofunda essa segunda camada.
Wiegand pode neutralizar parte do ganho
Se um leitor autentica um cartão de forma robusta e depois envia apenas um número por Wiegand sem supervisão ou criptografia, a arquitetura ainda possui um trecho de maior exposição.
Isso não significa que todo retrofit Wiegand seja inviável. Significa que o risco precisa ser conhecido e que a migração deve considerar leitor, controladora e cabeamento, não apenas o cartão.
Formato de credencial e identificação
Sistemas de acesso normalmente transformam o resultado da leitura em um número ou identificador que a controladora associa ao usuário. Facility code, card number e outros formatos podem variar.
Durante migrações, é necessário compreender como o número atual é formado. Trocar a tecnologia física sem planejar numeração pode causar duplicidades ou exigir recadastro massivo.
Emissão de cartões
A emissão pode envolver impressão visual, gravação de aplicações, carregamento de chaves, associação ao usuário e validação. Esse processo deve ser controlado porque é o ponto em que a identidade física é vinculada à identidade lógica.
Personalização centralizada
Centralizar emissão facilita padronização e governança, porém exige processo de contingência e distribuição.
Emissão distribuída
Em múltiplos sites, emissão local pode melhorar operação, mas amplia a quantidade de estações e pessoas com acesso a chaves ou credenciais de administração.
Ciclo de vida
Credencial deve ter emissão, ativação, suspensão, revogação, expiração e destruição. Perda de cartão precisa resultar em bloqueio rápido no sistema.
Se a mesma mídia possui várias aplicações, desligamento do usuário pode exigir tratamento coordenado de todas elas.
Migração de tecnologias legadas
Migração raramente ocorre em um único dia. Grandes organizações precisam manter cartões antigos e novos durante meses. O projeto deve desenhar coexistência e data de descontinuação.
Leitores multitecnologia
Leitores capazes de operar tecnologias legadas e novas podem permitir transição. O risco é manter indefinidamente o modo fraco. O plano deve possuir marco de desligamento da tecnologia antiga.
Migração por área
Outra estratégia é migrar prédio, pavimento ou zona por etapas. Isso facilita controle, mas exige atenção a usuários que transitam entre áreas.
Migração por população
Pode-se emitir novas credenciais por grupo de usuários. A base precisa evitar colisão de identificadores e manter regras consistentes.
Brownfield e levantamento técnico
Antes de definir DESFire para um sistema existente, a due diligence deve verificar leitores, controladoras, interfaces, formatos de cartão, banco de usuários, chaves, software e licenças.
A pergunta crítica é: o cliente controla a própria aplicação e as próprias chaves? Se a resposta for desconhecida, isso deve ser tratado como risco de migração.
Como especificar MIFARE/DESFire sem amarrar fabricante
Embora MIFARE seja tecnologia proprietária da NXP, um projeto pode formular requisitos de segurança de forma funcional. Por exemplo:
- smart card contactless compatível com a aplicação definida;
- autenticação criptográfica adequada ao risco;
- suporte a AES quando requerido;
- armazenamento de aplicação protegido;
- gestão de chaves documentada;
- capacidade de personalização e emissão;
- interoperabilidade comprovada com leitores;
- política de migração;
- proteção da comunicação leitor-controladora;
- evidências de teste.
Quando a compatibilidade com base instalada exige DESFire especificamente, a justificativa deve ser técnica e documentada.
Interoperabilidade e lock-in
Tecnologia aberta no nível de radiofrequência não garante independência no nível da aplicação. Chaves, codificação, emissão e software podem criar dependência de integrador.
A documentação de entrega deve incluir o que for necessário para operação futura, respeitando segurança: modelo de credencial, estrutura de aplicação, política de chave, responsabilidades, equipamentos de emissão e procedimento de recuperação.
Cartão corporativo multiaplicação
DESFire pode suportar múltiplas aplicações em uma única mídia. Isso permite separar controle de acesso de outros serviços, mas exige governança de memória e chaves.
Cada aplicação deve ter responsável e regra de ciclo de vida. Não é recomendável permitir que um serviço secundário altere ou exponha a aplicação de acesso.
Credencial física e credencial móvel
Organizações podem coexistir com cartões DESFire e credenciais móveis. O modelo de identidade precisa garantir que ambos representem o mesmo usuário e que revogação seja coordenada.
A migração para mobile não elimina a necessidade de avaliar segurança do leitor, controladora e backend.
Testes de aceitação
A migração só deve ser aceita quando cartões válidos, inválidos, coexistência, revogação e comunicação protegida forem comprovados em cenários reais.
O SAT de uma nova credencial deve provar mais do que “o cartão abre a porta”. É necessário confirmar comportamento de autenticação, formatos, perfis, revogação e integração.
Leitura e autorização
Testar cartões válidos, expirados, revogados e não cadastrados.
Chaves incorretas
Quando o escopo permitir, deve-se verificar que credenciais sem a aplicação ou chave correta não são aceitas.
Coexistência
Durante migração, testar cartões antigos e novos nos leitores designados, garantindo que zonas já migradas não aceitem tecnologia antiga quando isso for requisito.
Comunicação
Verificar o trecho leitor-controladora, principalmente quando OSDP Secure Channel foi especificado.
Auditoria
Confirmar que eventos registram identidade e resultado de forma consistente, independentemente do tipo de credencial.
Erros comuns
Os erros mais frequentes incluem:
- especificar apenas “MIFARE” sem família;
- usar UID de um cartão avançado como única autenticação;
- não possuir as chaves da aplicação;
- compartilhar a mesma chave indiscriminadamente;
- usar leitor “compatível” sem testar a aplicação real;
- migrar cartões sem mapear formato de credencial;
- manter tecnologia legada indefinidamente em leitores multitecnologia;
- proteger cartão-leitor e deixar leitor-controladora em interface fraca;
- não documentar emissão e recuperação;
- confundir criptografia disponível com criptografia efetivamente habilitada.
Quando DESFire é especialmente adequado
DESFire é uma alternativa forte para ambientes corporativos, data centers, plantas industriais, governo e outras instalações que precisam de autenticação contactless com governança de chaves e possibilidade de múltiplas aplicações.
A escolha deve ser proporcional ao risco e à capacidade operacional da organização. Uma tecnologia sofisticada sem processo de gestão pode ser administrativamente frágil.
Considerações finais
A pergunta correta não é “MIFARE é seguro?”, porque MIFARE é uma família ampla. O projeto precisa identificar qual tecnologia, qual geração e, principalmente, como ela será utilizada.
DESFire permite construir credenciais com autenticação e proteção criptográfica robustas, mas o ganho depende de gestão de chaves, emissão, leitores, interface com controladoras e ciclo de vida. A segurança está na arquitetura completa, não apenas no nome impresso no cartão.
Referências técnicas
[1] NXP SEMICONDUCTORS. MIFARE DESFire EV3: High-Security IC for Contactless Smart City Services. Disponível em: https://www.nxp.com/products/MF3DHx3
[2] NXP SEMICONDUCTORS. MIFARE DESFire EV3 contactless multi-application IC — Product short data sheet, Rev. 3.1, 11 jan. 2024. Disponível em: https://www.nxp.com/docs/en/data-sheet/MF3D_H_X3_SDS.pdf
[3] NXP SEMICONDUCTORS. MIFARE DESFire product family. Disponível em: https://www.nxp.com/products/rfid-nfc/mifare-hf/mifare-desfire%3AMC_53450
[4] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-1:2013 — Electronic access control systems — System and components requirements. Disponível em: https://webstore.iec.ch/en/publication/11873
[5] SECURITY INDUSTRY ASSOCIATION. Open Supervised Device Protocol — OSDP. Disponível em: https://www.securityindustry.org/industry-standards/open-supervised-device-protocol/
Perguntas frequentes
Não. MIFARE é uma família de tecnologias contactless. DESFire é uma família dentro do ecossistema MIFARE, com recursos avançados de autenticação, criptografia e aplicações.
Depende da família e da implementação. Usar apenas UID em um cartão tecnicamente sofisticado não aproveita autenticação criptográfica e deve ser avaliado conforme o risco.
As gerações atuais, como DESFire EV3, suportam AES e secure messaging, entre outros recursos. A segurança real depende de configuração e gestão adequada das chaves.
É um identificador do chip/cartão usado no protocolo. Ler somente UID não é equivalente a autenticar criptograficamente uma aplicação protegida.
Não. DESFire protege a camada credencial-leitor; OSDP trata comunicação leitor-controladora. São camadas diferentes e podem ser usadas em conjunto.
Sim. Leitores multitecnologia e migração por áreas ou populações podem permitir coexistência, mas o projeto deve definir prazo para retirar a tecnologia legada.
Porque as chaves controlam autenticação e acesso aos dados da aplicação. Chaves padrão, desconhecidas ou mal distribuídas podem comprometer segurança e criar dependência do integrador.
O SAT deve testar cartões válidos e inválidos, revogação, coexistência, formatos de identificação, autenticação, comunicação com controladora e registro de eventos.
Materiais técnicos complementares
Soluções relacionadas
Serviços relacionados
Conteúdos principais sobre o tema
- Sistema de Controle de Acesso: tipos, tecnologias, normas e projeto
- OSDP x Wiegand em controle de acesso: arquitetura, supervisão e segurança
- Como funciona uma porta controlada: leitora, ACU, REX, sensor, relé e fechadura
