Usando Mifare Ultralight C com RC522 no Arduino: 3 etapas

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:35

Usar a tecnologia RFID para identificar os titulares do cartão ou autorizar algo (abrir uma porta, etc.) é uma abordagem bastante comum. No caso de aplicação DIY, o módulo RC522 é amplamente utilizado, pois é muito barato e existe uma grande quantidade de código para este módulo.

Na maioria dos casos, o UID do cartão é usado para “identificar” o titular do cartão, e os cartões Mifare Classic são usados por serem baratos e frequentemente incluídos na compra de um módulo RC522.

Mas como você deve saber, o sistema Mifare Classic foi hackeado por alguns anos e não é mais considerado seguro. O sistema de criptografia Crypto1 usado pelos cartões Classic pode ser superado e são cartões regraváveis onde os dados e UID podem ser reprogramados (cartões mágicos).

Portanto, para qualquer aplicação de segurança relevante, o uso de cartões Mifare Classic não é recomendado! O mesmo se aplica à (maioria) dos sistemas NTAG e Mifare Ultralight

Portanto, a escolha é usar um sistema profissional ou tentar usar um sistema RFID mais seguro. Os sistemas disponíveis são Mifare Ultralight C, Mifare DESFire e Mifare Plus. Como existem muitos sistemas profissionais usando esses sistemas mais seguros, para a comunidade DIY praticamente não há soluções (existe uma solução DESFire baseada em Teensy, que é baseada na placa de apoio PN523, mais cara). Além disso, as placas DESFire são muito caras. Portanto, o desafio era encontrar uma solução melhor e mais barata.

A solução apresentada fornece acesso total aos cartões Mifare Ultralight “C” baratos usando o módulo barato chinês RC522 DIY. Com base neste código, o seguro Mifare Ultralight C pode ser usado em aplicações DIY.

Etapa 1: condições prévias

Embora o RC522 seja bem projetado, na maioria dos casos é mal construído, pois alguns componentes são mal dimensionados. Isso leva à má reputação do módulo que tem baixa sensibilidade e nem todos os tipos de cartões serão identificados. Principalmente o Mifare Ultralight C não será identificado nem será possível ler os cartões.

O principal problema é a especificação dos indutores L1 e L2. Conforme descrito em https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Simplesmente substituindo esses indutores por outros apropriados, por ex. FERROCORE CW1008-2200 de repente o RC522 mostra qual é o seu verdadeiro potencial.

Portanto, antes de tentar o código fornecido, você DEVE SUBSTITUIR os indutores. Ele simplesmente não funcionará com os indutores pré-instalados!

O pano de fundo de tudo isso é que as placas Ultralight C são bastante famintas de energia. Esta energia é fornecida pelo campo RF RC522. Devido à baixa amperagem dos indutores, o campo de energia não é poderoso o suficiente para alimentar o Ultralight C. Outras placas como a Mifare Classic precisam de menos energia e, portanto, funcionam de forma bastante estável.

Etapa 2: Como funciona?

Então, depois de modificar o módulo RC522, como você pode usar o Mifare Ulralight C para sua aplicação?

O truque é que o Mifare Ultralight C suporta uma autenticação de senha baseada na cifra 3DES. Ao usar essa senha, o conteúdo do cartão pode ser “somente leitura” ou completamente invisível para um usuário não autorizado.

Para usar essa proteção por senha, a senha deve ser gravada no cartão e as páginas protegidas. Uma vez feito isso, você pode verificar o cartão em seu aplicativo apenas pedindo uma autenticação baseada em senha ou dados adicionais prontos de uma área protegida. Somente se isso for bem-sucedido, você saberá que pode confiar no UID fornecido no cartão.

Cuidado: sem a autenticação baseada em senha você ainda não pode confiar em um cartão Mifare Ultralight C, pois também existem “cartões mágicos” que simulam o Ultralight C.

Cada cartão independente da tecnologia (se na frequência correta) responderá com seu UID quando alimentado pelo campo RF e solicitará sua identificação. Além disso, eles fornecem um valor SAK fornecendo informações mínimas sobre o tipo de cartão presente. Infelizmente, todos os Mifare Ultralight e NTAG se identificam como o tipo de sistema (SAK = 0x00), incluindo o Mifare Ultralight C. Portanto, ao pesquisar os cartões, pelo menos o valor SAK de 0x00 dará uma dica de que pode haver um Ultralight C no leitor.

Para certificar-se de que é um Ultralight C, uma solicitação de autenticação criptografada pode ser enviada ao cartão. Se esta NÃO for uma placa Ultralight C, esta solicitação não será compreendida e a resposta será um NAK (não reconhecido).

Se este for um cartão Ulralight C, você receberá uma resposta de 8 bytes. Esses 8 bytes são um número aleatório “B” (RndB) criptografado pela chave armazenada no cartão usando a cifra 3DES.

Este RndB criptografado deve ser descriptografado usando a mesma chave no programa. Este número aleatório é então ligeiramente modificado (girado por um byte → byte 1 será movido para o byte 8 e todos os outros bytes são empurrados um byte abaixo, então chamados de RndB '). O programa então gera um número aleatório "A" de 8 bytes (RndA) e anexa este RndA ao RndB 'modificado. Isso é novamente criptografado usando a chave e enviado para o cartão.

O cartão descriptografa a mensagem e verifica se o RndB 'se ajusta ao RndB gerado anteriormente no cartão. Se forem iguais, o cartão agora sabe que o programa conhece a chave.

Neste ponto, o programa ainda não sabe se o cartão conhece a chave e, portanto, pode ser confiável ou não. Para conseguir isso, o cartão agora gira o RndA descriptografado em um byte e, em seguida, criptografa esses bytes usando a chave e os envia de volta.

O programa irá então descriptografar a resposta do cartão e verificar se o RndA original e o RndA respondido correspondem. SÓ ENTÃO ambas as entidades (programa e cartão) sabem que compartilham o conhecimento da mesma chave.

Este processo só pode ser usado para autenticação. Todas as comunicações posteriores são sempre em “texto simples”.

Embora existam cartões “magic Ultralight C” onde o UID pode ser modificado, a chave em si não pode ser obtida do cartão e a cifra 3DES é bastante segura. A chave é uma chave de 16 bytes, portanto, uma abordagem de força bruta para obter a chave levará algum tempo.

Conforme declarado, a comunicação antes da autenticação e após a autenticação é sempre em texto não criptografado (também conhecido como não criptografado). Ao escrever uma nova chave no cartão, o conteúdo da chave pode ser detectado usando o equipamento certo. Portanto, escreva a chave apenas em um ambiente seguro e mantenha-a em segredo.

Ao usar o cartão Ultralight C

O cartão Ultralight C tem vários recursos de segurança integrados:

1. Memória de programação única (OTP). Nesta área, os bits podem ser gravados, mas o barramento não pode ser excluído.
2. Um contador unidirecional de 16 bits. Este contador só pode ser incrementado, quando acessado.
3. Uma proteção de “gravação” ou “leitura / gravação” de páginas na memória. Somente se autenticadas com a chave, essas páginas podem ser lidas ou modificadas.
4. Um congelamento / bloqueio de páginas individuais para proteção contra qualquer modificação.

Nem o uso de OTP, o contador de 16 bits nem o uso do bit de bloqueio estão implementados no código fornecido, mas podem ser facilmente implementados com base nas informações fornecidas em https://www.nxp.com/docs/en/data- folha / MF0ICU2.pd…

Como a proteção por chave é essencial para o uso do Mifare Ultralight C, todas as funções relevantes estão presentes.

Todos os comandos são usados no monitor serial com "somente nova linha" e com 115200 Baud

• “Auth 49454D4B41455242214E4143554F5946” solicitará uma autenticação com a chave fornecida (neste caso, a chave Mifare Ultralight C padrão)
• “Despejar” irá despejar o conteúdo do cartão até onde eles estiverem visíveis. Caso as páginas sejam protegidas pela chave, essas páginas podem não ser visíveis até uma autenticação prévia com a chave. Nas primeiras duas colunas é indicado se as páginas estão bloqueadas ou o acesso é restrito.
• “NewKey 49454D4B41455242214E4143554F5946” gravará uma nova chave no cartão. A chave está gravada nas páginas 44 a 47. Isso só funcionará se essas páginas não estiverem bloqueadas nem protegidas sem uma autenticação prévia.
• "wchar 10 hello world" escreverá "hello world" a partir da página 10. Novamente, isso só funciona se as páginas não forem bloqueadas nem protegidas sem uma autenticação anterior. Ao tentar escrever acima da página 39 ou abaixo da página 4, isso exibirá um o erro ou os dados são ignorados, pois essas páginas não são da memória do usuário.
• “Whex 045ACBF44688” gravará os valores hexadecimais diretamente na memória, condições anteriores se aplicam.
• “Proteger 30” protege todas as páginas da página 30 para cima. Dependendo da permissão, essas páginas só podem ser modificadas ou lidas após uma autenticação prévia com chave. Usar “proteger” com valores maiores que 47 definirá todas as páginas como “desprotegidas” INCLUINDO A CHAVE nas páginas 44-47 (que só pode ser modificada, mas não lida). Para evitar a alteração da chave, a proteção deve começar pelo menos na página 44.
• “Setpbit 0” define o bit de proteção e decide se as páginas protegidas são somente leitura (“setpbit 1”) ou não podem ser lidas nem gravadas (“setpbit 0”) sem uma autenticação prévia com chave.

Nem todos os comandos podem ser usados imediatamente após a placa ser detectada. Um "despejo" antes de um outro comando sempre ajuda.

Etapa 3: importante

1. O programa diferencia entre os tipos Ultralight lendo a página 43 e 44. Se a página 43 for legível e a página 44 não, é mais provável que seja um Ultralight C. MAS, se você proteger contra leitura / gravação a página 43, o cartão não será mais reconhecido como Ultralight C (não tem efeito em nada) A correta identificação do Ultralight deve ser feita através da autenticação com chave (não implementei por questões de estabilidade).
2. Antes de usar os comandos “setpbit” e “proteger”, o comando “dump” deve ser usado, caso contrário, o status de proteção das páginas não será conhecido.
3. Se você protege as primeiras páginas do seu cartão com “leitura / gravação”, ele não funcionará mais com este programa, pois a primeira página é lida constantemente para ver se ainda há um cartão presente. Como as duas primeiras páginas são somente lidas de qualquer maneira (o UID é armazenado lá), não há sentido em protegê-las.

Problemas de estabilidade

Este código usa a biblioteca RC522 “padrão” para Arduino e uma biblioteca 3DES de https://github.com/Octoate/ArduinoDES. Enquanto a biblioteca RC522 é comumente usada, a biblioteca 3DES não parece tão difundida e deve ser instalada manualmente.

O código foi testado em um Arduino Uno. Mas enquanto o escrevia, encontrei muitos problemas estranhos em relação à estabilidade. De alguma forma, ou minhas habilidades de programação não são tão boas, uma das bibliotecas usadas é instável ou misturar as bibliotecas não é uma boa ideia.

Tenha isso em mente ao usar o código !!!

Alterá-lo ou usar apenas partes dele pode levar a um comportamento estranho, como travar, imprimir coisas estranhas ou obter tempo limite ou NAK ao ler o cartão. Isso pode acontecer em qualquer lugar do código (me custou muitas horas de depuração). Se você encontrar o (s) motivo (s) para isso, dê-me uma dica.