De poucos em poucos meses alguém nos faz a mesma pergunta: podemos autenticar utilizadores com o Cartão de Cidadão dentro da nossa própria aplicação? A resposta é sim, e o caminho é mais aberto do que a maioria das equipas espera. O middleware oficial é publicado como código aberto pela AMA, e cobre o Cartão de Cidadão, a Chave Móvel Digital e o sistema de certificação de atributos profissionais.
O que apanha as equipas de surpresa não é a criptografia. É a camada do leitor, a escolha entre autenticação e assinatura qualificada, a cadeia de certificação, e o que acontece quando o cartão que está à sua frente é uma versão que o seu código nunca viu.
A data relevante é junho de 2024. Foi quando Portugal começou a emitir o Cartão de Cidadão v2, redesenhado para as normas de segurança e formato do Regulamento (UE) 2019/1157, que estava em aplicação desde 2 de agosto de 2021 e foi substituído pelo Regulamento (UE) 2025/1208 a 9 de julho de 2025. O cartão v2 usa chaves ECDSA onde o v1 usava RSA, e suporta leitura sem contacto. A versão 3.12.0 do middleware foi a primeira a suportá-lo. Se a sua integração é anterior a meados de 2024 e ninguém lhe mexeu desde então, está a correr contra pressupostos que o cartão já não satisfaz.
O middleware está aberto a aplicações privadas, ou só ao Estado?
Aberto a qualquer pessoa. O código-fonte, o SDK e a documentação técnica são todos públicos. Não há negociação de licenciamento nem porta de aprovação para ler atributos de identidade ou realizar uma autenticação.
O que está condicionado é outra coisa. Emitir credenciais é uma função do Estado. Autenticação.gov é o serviço do Estado que está por trás. Usar atributos profissionais envolve as autoridades que os emitem. Ler o cartão e verificar uma assinatura não.
Qual é a diferença entre autenticação e assinatura qualificada?
O cartão tem dois certificados separados, com dois PIN separados e dois efeitos jurídicos muito diferentes. Escolher o errado é o erro mais caro disponível no início de um projecto, porque altera a arquitectura, as obrigações de retenção e o âmbito.
Para ser completo: o cartão tem três PIN, autenticação, assinatura e morada, mais um código de cancelamento mais longo usado para desactivar as funções digitais em caso de perda ou roubo. Todos chegam na carta de PIN enviada ao cidadão.
Porque é que o leitor de cartões trava mais projectos do que a criptografia?
Porque a criptografia é normalizada e a camada do leitor não é. Um browser não fala com um cartão inteligente por si. O middleware tem de estar instalado na máquina do utilizador, e tudo nisso está fora do seu controlo.
O contactless muda isto, em parte. O cartão v2 suporta leitura sem contacto, o que retira o leitor da equação em cenários móveis. Introduz o CAN, um número de seis dígitos impresso no cartão, exigido para operações contactless e distinto dos três PIN. Ao invocar C_Login através de PKCS#11 em modo contactless com um cartão v2, o CAN é passado como parâmetro de PIN.
O que muda entre o Cartão de Cidadão v1 e v2 para o seu código?
Suficiente para que código escrito só contra o v1 não se comporte correctamente contra o v2. E o middleware não oferece forma directa de perguntar qual a versão que está no leitor.
O que é que cada âmbito acrescenta ao trabalho?
A variável que determina o esforço não é a criptografia, que é fixa. É quantos dos seguintes precisa, e cada um traz as suas dependências e os seus modos de falha.
Não publicamos intervalos de preço aqui, porque a resposta honesta depende de quais destes se aplicam, de quantas plataformas suporta e dos seus requisitos de auditoria. Descreva o âmbito e devolvemos um número, não um intervalo.
O que tem de guardar, e por quanto tempo?
Para autenticação, está a provar que uma verificação ocorreu: o facto, quando, qual o certificado, e o resultado das verificações de cadeia e de revogação. Não uma cópia de tudo o que está no cartão. Ao abrigo da minimização de dados, guardar o conjunto completo de identidade porque estava disponível é um passivo, não um registo.
Para assinatura qualificada, está a provar algo mais difícil: que a assinatura era válida no momento em que foi feita, verificável anos depois, após o certificado ter expirado. Isso exige o documento assinado, um selo temporal de confiança, e o material de validação capturado no momento da assinatura.
Duas decisões a tomar explicitamente. Guarda o número de identificação civil ou um identificador derivado, sabendo que um identificador interno pseudonimizado cobre a maioria dos casos e reduz consideravelmente a exposição. E reverifica em cada sessão ou confia num token de sessão após a primeira verificação, uma resposta que depende do risco da operação e que deve ficar escrita em vez de herdada do que o developer escolheu.
Como é que isto se relaciona com a EUDI Wallet que chega em dezembro de 2026?
Todos os Estados-Membros da UE têm de disponibilizar uma Carteira Europeia de Identidade Digital até 24 de dezembro de 2026, e as organizações privadas obrigadas têm de a aceitar cerca de um ano depois. Isso não torna o Cartão de Cidadão obsoleto, e os dois não são alternativas no curto prazo. A posição prática para os próximos dois a três anos é que ambos serão apresentados.
O que aponta para uma decisão arquitectural agora. Mantenha a lógica de verificação atrás de uma interface que não sabe qual o mecanismo que produziu o resultado. Se o código da aplicação pergunta se esta pessoa foi verificada e a que nível, em vez de perguntar o que o cartão devolveu, acrescentar a aceitação de carteira mais tarde é uma implementação e não uma reescrita. Os nossos guias sobre implementação do eIDAS 2.0 e integração de relying party cobrem esse lado.


