Pode autenticar utilizadores com o Cartão de Cidadão na sua própria aplicação?

Avatar
Autor

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.

A barreira para usar o Cartão de Cidadão num produto comercial é esforço de engenharia, não autorização.

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.

Três caminhos de integração, e quando é que cada um serve
PKCS#11
API multiplataforma para tokens. O módulo pteid-pkcs11 vem com o middleware. Melhor para Java e para tudo o que já fala PKCS#11.
Criptografia nativa do sistema
Suporte criptográfico do Windows, CryptoTokenKit via PteidToken no macOS. Melhor para aplicações desktop.
SDK
C, C++, Java e C#, mais um módulo .NET 8/9 a partir do 3.13.0. Obrigatório para contactless no v2.
A maioria dos projectos comerciais usa dois dos três: o SDK para ler dados e o PKCS#11 para assinar. A leitura contactless no v2 exige especificamente os métodos mais recentes do SDK, por isso um desenho só com PKCS#11 não chega a essa funcionalidade.

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.

Autenticação
Esta pessoa está presente, agora
Usa o PIN de autenticação. Uma afirmação de identidade, forte mas não uma assinatura. Guarda um registo de que a verificação aconteceu. Uso típico: login, onboarding, verificação de idade ou residência.
Assinatura qualificada
Esta pessoa concordou com este documento
Usa o PIN de assinatura. Efeito jurídico equivalente a uma assinatura manuscrita, ao abrigo do artigo 25.º, n.º 2, do Regulamento (UE) 910/2014. Guarda o documento assinado mais os dados necessários para o verificar anos depois.
A armadilha é o alargamento de âmbito na direcção errada. Um projecto definido como login descobre três meses depois que o negócio quer mandatos assinados. A assinatura qualificada traz validação de longo prazo, selo temporal, uma decisão sobre formato de arquivo e uma política de retenção. Decida isto na primeira semana.

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 middleware não está instalado. A sua aplicação não tem forma fiável de detectar isto a partir de uma página web, por isso a falha aparece como um erro inexplicado. Precisa de uma estratégia de detecção e de um caminho de instalação que uma pessoa não técnica consiga seguir.
Os drivers de leitor diferem por plataforma e por modelo. O manual do utilizador publica testes de compatibilidade de leitores para as duas versões do cartão. O que funciona num portátil de developer com um leitor falha numa máquina de cliente com outro.
Conflitos de versão do pcsc-lite em Linux. Em distribuições com pcsc-lite 2.3.0, como o Ubuntu 24.10 e o Fedora 41, é necessário um pacote flatpak específico.
O cartão é retirado a meio da operação. É comum, e o tratamento de erros tem de distinguir isso de uma falha genuína.
O PIN é desconhecido ou já está bloqueado. Três tentativas erradas bloqueiam aquele código específico. Os outros continuam a funcionar, por isso um PIN de autenticação bloqueado não impede assinar, mas o desbloqueio exige uma ida presencial a um balcão do IRN com o cartão e a carta de PIN. O seu processo de suporte precisa de uma resposta para isto antes do lançamento.

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.

Está a integrar o Cartão de Cidadão e não sabe qual dos três caminhos serve a sua stack?
Fale com a nossa equipa

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.

v1
Chaves RSA, só contacto
A versão original. Interface de contacto, chaves e certificados RSA, CA intermédias devolvidas como esperado através de PKCS#11.
v2, desde junho de 2024
ECDSA, contactless, CAN
Chaves ECDSA. Contactless sobre ISO/IEC 14443. O modo de contacto funciona depois de actualizar o software, sem alteração significativa de integração. O contactless exige os métodos mais recentes do SDK. As CA intermédias podem não ser devolvidas através de PKCS#11.
Duas consequências. Se alguma parte da sua stack assume RSA, vai falhar no v2 de uma forma que parece um cartão avariado. E a documentação oficial é explícita que não existe API de PKCS#11 dedicada para verificar o tipo de cartão ou o modo contactless, pelo que os developers têm de implementar a sua própria estratégia. Uma abordagem documentada: tentar a inicialização sem PIN nem CAN, e repetir com o CAN se falhar. Cobrimos a migração em detalhe em Cartão de Cidadão v1 e v2.

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.

Autenticação. Detecção de leitor, verificação de presença do middleware, tratamento de PIN, validação da cadeia de certificação e de revogação, um registo da verificação. Esforço determinado pelo número de sistemas operativos e por saber se um sistema de login existente tem de continuar a funcionar em paralelo.
Leitura de atributos de identidade. Integração do SDK, mapeamento de campos, uma decisão de minimização sobre o que guarda. Esforço determinado por saber se o PIN de morada é necessário, que é um PIN separado e um pedido separado ao utilizador.
Assinatura qualificada. Tratamento de documentos, selo temporal de confiança, material de validação de longo prazo, decisão de formato de arquivo, política de retenção. Determinado por saber se as assinaturas têm de permanecer verificáveis depois de o certificado expirar, o que a maioria dos casos regulados exige.
Contactless no v2. Os métodos mais recentes do SDK, captura do CAN na interface, e uma estratégia de detecção de versão e de modo que você implementa.
Manutenção contínua. Acompanhar as versões do middleware, testar contra novas gerações de cartão, alterações de dependências ao nível da distribuição. A cadência de lançamentos não é sua para controlar, e junho de 2024 quebrou pressupostos em integrações construídas antes.

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.

Leitura relacionada

Cartão de Cidadão v1 e v2: o que mudou para os developers A lista de migração se a sua integração é anterior a junho de 2024. ECDSA, PACE, o CAN, e a construção da cadeia de certificação.
Guia de implementação do eIDAS 2.0 O que as organizações têm de decidir, construir e registar antes de dezembro de 2026, por uma equipa que mantém middleware de identidade electrónica nacional desde 2011.
Guia de integração de relying party da EUDI Wallet O lado de engenharia da aceitação de carteira, e como difere da verificação baseada em cartão.
eID Box O nosso produto de middleware para organizações que acrescentam identidade electrónica nacional às suas próprias aplicações.
Código aberto ou proprietário: qual é mais seguro? Porque é que a cadência de manutenção importa mais do que o licenciamento quando o código está debaixo de um fluxo de identidade.

Perguntas frequentes

Acesso e licenciamento

O middleware do Cartão de Cidadão é gratuito para uso comercial?
Sim. O middleware é publicado como código aberto pela AMA no repositório amagovpt/autenticacao.gov, com SDK para C, C++, Java e C#. Não é necessária negociação de licença nem aprovação do Estado para ler o cartão ou verificar uma autenticação numa aplicação privada. Emitir credenciais e actuar como prestador qualificado de serviços de confiança continuam a ser actividades reguladas.
Uma aplicação web pode ler o Cartão de Cidadão directamente?
Não por si. Um browser não comunica com um cartão inteligente, por isso o middleware tem de estar instalado no dispositivo do utilizador e a sua aplicação interage com ele localmente. É por isso que uma integração do Cartão de Cidadão inclui sempre um componente do lado do cliente e um plano para detectar se o middleware está presente.

O cartão novo

O que é o CAN e quando é necessário?
O CAN é um Card Access Number de seis dígitos impresso no Cartão de Cidadão v2. É exigido apenas para leitura sem contacto e é distinto dos PIN de autenticação, assinatura e morada. Ao usar C_Login através de PKCS#11 em modo contactless com um cartão v2, o CAN é fornecido como parâmetro de PIN.
Código escrito para o Cartão de Cidadão antigo funciona com o novo?
Para operações em modo de contacto, actualizar o middleware é em geral suficiente, sem alterações significativas de integração. O contactless exige métodos novos do SDK. Tudo o que na sua stack assuma RSA vai precisar de atenção, porque o v2 usa ECDSA, e as CA intermédias podem não ser devolvidas através de PKCS#11 no v2.

Implementação e o que vem a seguir

O que tem de estar instalado no dispositivo do utilizador?
O middleware Autenticação.gov, que fornece o módulo PKCS#11 e o suporte criptográfico do sistema operativo. Um browser não alcança um cartão inteligente sem ele. A sua aplicação precisa portanto de uma forma de detectar se está presente e de um caminho de instalação que uma pessoa não técnica consiga seguir, mais o pacote flatpak do pcsc-lite em distribuições Linux com pcsc-lite 2.3.0.
A EUDI Wallet substitui o Cartão de Cidadão?
Não a curto prazo. Os Estados-Membros têm de disponibilizar uma carteira até 24 de dezembro de 2026 e os sectores obrigados têm de a aceitar cerca de um ano depois, mas a adesão dos cidadãos é voluntária e o cartão mantém a maior base instalada em Portugal. Conte suportar ambos, o que é um argumento para manter a lógica de verificação atrás de uma interface comum. O nosso trabalho em identidade digital para um arquipélago mostra o que essa abstracção compra quando o contexto de implementação é invulgar.
Caixa Mágica Software
Equipa Caixa Mágica
A Caixa Mágica Software é uma empresa portuguesa de software com mais de 20 anos de experiência a entregar software à medida, soluções de IA e equipas de desenvolvimento nearshore para organizações europeias. Trabalhamos em middleware de identidade electrónica nacional há mais de uma década.
eID Box · Caixa Mágica Software
Fale com a equipa que mantém este middleware
Trabalhamos em middleware de identidade electrónica nacional há mais de uma década. Envie-nos as plataformas que precisa de suportar e as operações que precisa de realizar, e dizemos-lhe qual o caminho de integração que serve e onde o seu prazo tem probabilidade de derrapar.