O mistério da exclusão dos certificados A3

[Delcio]

Olá amigos, depois de mais um cliente ter perdido o certificado resolvi que ia tentar descobrir oque estava causando isso, e depois de muita peleja(são 4:00 da manhã ), acho que consegui chegar ao causador do problema, pelo menos tive sucesso em excluir um certificado por diversas vezes assinando um XML.

E como muito se falava, não é diretamente o ACBR que está excluindo o certificado, pelo que constatei é a MSXML que está "reiniciando" o certificado e somando isso a mais algum problema está causando a exclusão. Se você assinar um XML e deixar o administrador do token aberto, verá que no momento da assinatura, no trecho "xmldsig.sign(dsigKey, CERTIFICATES);"  o token muda de: Operacional >> Ausente >> Presente >> Operacional, como se o cartão fosse removido e inserido novamente. Pensei aí tem coisa!

Tentei remover o cartão durante a assinatura mas não consegui simular a exclusão do certificado, imaginei que não estava sendo rápido o suficiente. Então coloquei um loop no trecho do ACBR que pega a chave privada do certificado, antes de executar a assinatura, percebi que até aí o PIN do certificado não era solicitado, somente mais a frente quando ocorre a assinatura com "xmldsig.sign(dsigKey, CERTIFICATES);". 

Porém quando removi o certificado da leitora e inseri novamente dentro do loop(o mesmo que a MSXML faz durante a assinatura) foi me solicitado o PIN e logo depois veio a mensagem: "O conjunto de chaves não está definido", olhando no administrador do token que estava aberto pude ver o certificado sendo excluído: O PIN que ele me solicitou foi para excluir o certificado!

O que imagino que esteja acontecendo é que se você chamar o método Assinar repetidamente, antes de dar tempo do cartão ficar operacional novamente, o certificado pode ser excluído.

Isso explicaria o porque da exclusão ser esporádica e também não acontecer com todos os sistemas, pois dependeria da lógica usada por cada um para assinar, como assinaturas em sequência ou mesmo mais de uma thread acessando o certificado.

Fiz um vídeo mostrando o momento da exclusão, note que não consegui excluir na primeira tentativa, porque demorei muito pra inserir o cartão, estava com uma mão ocupada filmando, ia editar isso mas tô com muito sono.

MODERAÇÃO: vídeo removido a pedido do usuário

Vou dormir um pouco e amanha ver se me aprofundo no problema. 

   

Editado 7 Novembro, 2017 por EMBarbosa
Pedido do usuário.

[Agnaldo Prates]

@Delcio, parabéns pelo post. É importante que de agora em diante, quando houver a exclusão do certificado A3, que os envolvidos solicitem das certificadoras uma declaração por escrito e assinado pelo responsável da certificadora e não do cliente, atestando que o ACBr excluiu o certificado. Isso vai ser importante para reunir uma base de informações que poderá ser extremamente útil para toda a comunidade de desenvolvedores.

 

 

[RenatoRicci]

Parabéns pela investigação a fundo @Delcio!! Já tive 2 ou 3 clientes que perderam certificado e quando eles ligaram no suporte da certificadora foi dito a eles que o software de emissão de NFe era quem estava apagando o certificado.. Revoltante né? Seu vídeo ajudou muito a esclarecer o real problema!! Parabéns!

Renato

[Sérgio Assunção]

Parabéns pela iniciativa ! O seu esclarecimento vai ser de grande importância.
Vou fixar o tópico para que essa sua conclusão repercuta e que novas conclusões sejam descritas aqui.
 

[Delcio]

Veja que de qualquer maneira tem uma falha muito grande ai:

Permitir a exclusão do certificado pelo PIN, se você for lá no administrador do token e remover manualmente o certificado, também será solicitado somente o PIN.

Para excluir deveria ser o PUK ou mesmo outra senha diferente, aí não teria como o usuário ser "enganado" e excluir. Nem se quer um diálogo de confirmação é apresentado, o que leva a acreditar que estamos autorizando a assinatura quando na verdade estamos autorizando a exclusão.

Editado 31 Outubro, 2017 por Delcio

[RenatoRicci]

Tem razão Delcio.. deveria solicitar o PUK... porém o mais grave ainda é o certificado sair de fábrica com o PUK e PIN 1234 como no caso da Certisign, veja:

A pessoa pode achar que está digitando o PIN, e está na verdade digitando o PUK.. ai já era!!

Renato

[armando.boza]

11 minutos atrás, rrricci disse:

Tem razão Delcio.. deveria solicitar o PUK... porém o mais grave ainda é o certificado sair de fábrica com o PUK e PIN 1234 como no caso da Certisign, veja:

A pessoa pode achar que está digitando o PIN, e está na verdade digitando o PUK.. ai já era!!

Renato

Poderia ser invertido por padrão né, 4321.

Mas no momento que ele pede a senha para deletar o certificado, ele está solicitando a PIN ou a PUK?

Editado 31 Outubro, 2017 por armando.boza

[Delcio]

4 minutos atrás, armando.boza disse:

Poderia ser invertido por padrão né, 4321.

Mas no momento que ele pede a senha para deletar o certificado, ele está solicitando a PIN ou a PUK?

Está solicitando PIN, e não tem nenhuma informação que é para a exclusão do certificado.

[armando.boza]

3 minutos atrás, Delcio disse:

Está solicitando PIN, e não tem nenhuma informação que é para a exclusão do certificado.

Que falha hein.

[Felipe E. Resende Mesquita]

Parabéns Delcio,

 

Trabalhei na PRODEMGE com certificação e nunca me atentei para esse problema, clientes sempre reclamando do desaparecimento do certificado, achávamos  que era queda de energia ou utilização incorreta do mesmo!

Sugiro encaminhar uma sugestão de melhoria, referente ao seu teste para o e-mail: [email protected]

Acredito que com esses fundamentos e testes, pelo menos na PRODEMGE o problema poderá ser resolvido... 

[Delcio]

Mais alguns testes:

Ambos os métodos "IXMLDigitalSignature.createKeyFromCertContext()" e  "IXMLDigitalSignature.createKeyFromCSP()" usados nas classes TDFeSSLXmlSignMsXml e  TDFeSSLXmlSignMsXmlCapicom,  causaram a exclusão do certificado quando forçada a sua chamada antes do cartão estar "Operacional".

Isso aumenta minhas desconfianças sobre a MSXML.

Ainda não deu tempo de testar com TDFeSSLXmlSignXmlSec, libxmlSec e OpenSSL.

[João Paulo Alcântara]

15 minutos atrás, Delcio disse:

Mais alguns testes:

Ambos os métodos "IXMLDigitalSignature.createKeyFromCertContext()" e  "IXMLDigitalSignature.createKeyFromCSP()" usados nas classes TDFeSSLXmlSignMsXml e  TDFeSSLXmlSignMsXmlCapicom,  causaram a exclusão do certificado quando forçada a sua chamada antes do cartão estar "Operacional".

Isso aumenta minhas desconfianças sobre a MSXML.

Ainda não deu tempo de testar com TDFeSSLXmlSignXmlSec, libxmlSec e OpenSSL.

Delcio,

Obrigado por compartilhar sua investigação.

Como não sou da área de programação, não consegui ver no código o modo de utilização, então tenho que perguntar:

como é o acesso ao certificado digital nesse exemplo? Capicom, OpenSLL, WinCrypt ??

 

[Daniel Simoes]

É sempre bom lembrar, que os fontes do ACBr, apenas abrem o Certificado como "ReadOnly".. Veja o código abaixo, de ACBrDFeWinCrypt.pas

  FpStore := CertOpenStore(
      StoreProvider, 0, 0,
      StoreFlag or CERT_STORE_READONLY_FLAG,
      LPCTSTR( FpDFeSSL.StoreName ) );

 

[Delcio]

13 minutos atrás, Daniel Simoes disse:

É sempre bom lembrar, que os fontes do ACBr, apenas abrem o Certificado como "ReadOnly".. Veja o código abaixo, de ACBrDFeWinCrypt.pas

  FpStore := CertOpenStore(
      StoreProvider, 0, 0,
      StoreFlag or CERT_STORE_READONLY_FLAG,
      LPCTSTR( FpDFeSSL.StoreName ) );

 

Até aí tudo bem, em nenhum momento culpo o ACBR, mas entre ele o o Certificado temos vários suspeitos: MSXML, Software Gerenciador do Certificado, Hardware da Leitora e o próprio Hardware do SmartCard.

O fato é que o problema, mesmo que externo ao ACBR,  está ocorrendo e causando muitos transtornos as empresas. 

Se encontrarmos o ponto exato onde o problema ocorre, talvez possamos contornar esse problema externo pelo próprio ACBR ou mesmo forçar as Certificadoras e fabricantes de dispositivos a resolver o problema.

[Daniel Simoes]

Vendo o seu vídeo e de acordo com as suas investigações... a única medida prática e efetiva, seria deixar na Tela, uma mensagem clara e visível ao usuário...

"ACESSANDO CERTIFICADO DIGITAL.
NÃO REMOVER O CARTÃO..."

As empresas que emitem o Certificado, não tem qualquer relação com a MSXML.dll.. ela e feita pela Microsoft e está depreciada...

Eu particularmente, recomendo a meus clientes, que evitem a todo custo, certificados A3... a diferença de preço entre um A3 e A1, me parece ser "economia a base da porcaria"... A3 gera muito suporte e trabalho... Ele seria mais seguro, é claro.... isso se todos não usassem "1234" na senha, ou colassem uma etiqueta com a Senha no cartão... então.. só vejo desvantagens em usar A3

 

O que provavelmente está excluindo o Certificado, é justamente isso... a falha na autenticação do mesmo... Isso é uma medida de segurança, que é de conhecimento de todos... se você digitar a senha errada várias vezes, a própria biblioteca de acesso ao certificado excluirá o mesmo...

[Delcio]

40 minutos atrás, Daniel Simoes disse:

...deixar na Tela, uma mensagem clara e visível ao usuário...

"ACESSANDO CERTIFICADO DIGITAL.
NÃO REMOVER O CARTÃO..."

Acho que não resolveria, porque o usuário não está removendo o cartão, mas no momento da assinatura, quando é solicitado o PIN, o certificado dá uma "reiniciada", como se tivesse sido removido e inserido novamente. Só notei isso em métodos de assinatura que usam MSXML.

Quanto ao certificado ser excluído pela biblioteca não encontrei nenhuma especificação que mencione isso, sempre diz que o certificado deve ser bloqueado em caso de tentativas de PIN incorretas, e não excluído. Então acho que os fabricantes tem alguma culpa aí sim.

Também recomendo o A1 a todo custo, mas convencer o cliente a usar é outra história. Sempre tem alguém que vai dizer pra ele: Uso a anos e nunca vi isso acontecer. As próprias certificadoras recomendam o A3 e dizem que não vai ter problema, depois que a bomba explode tiram o corpo fora e colocam a culpa em nossos sistemas.

Vou fazer uns testes com libXMLSec pra ver se consigo algo com ela.  

Editado 31 Outubro, 2017 por Delcio

[Daniel Simoes]

4 minutos atrás, Delcio disse:

Acho que não resolveria, porque o usuário não está removendo o cartão, mas no momento da assinatura, quando é solicitado o PIN, o certificado dá uma "reiniciada"

Acho que não compreendi... nos seus testes, não foi esse método que você usou ? Ou seja, remover o cartão no meio do processo de assinatura ?

5 minutos atrás, Delcio disse:

Vou fazer uns testes com libXMLSec pra ver se consigo algo com ela.  

Até o momento, XMLSec no ACBr não funciona com MSCrypto... então... não suportará A3

[Agnaldo Prates]

32 minutos atrás, Delcio disse:

Então acho que os fabricantes tem alguma culpa aí sim.

Então a gente vai estudar todo esse procedimento com carinho e depois vamos pleitear uma reparação destas certificadoras, afinal, teve muita gente que pagou certificado sem contar o erro ao atribuir ao ACBr algo que não existe. Se for problema com a MSXML eles que encontrem uma forma de responsabilizar a Microsoft. Estou juntando tudo que posso neste sentido aí a gente vai conversar com @Daniel Simoes, @André Ferreira de Moraes e outros neste sentido.

[RenatoRicci]

@Delcio, voce já tentou realizar este mesmo procedimento com senhas diferente entre PIN e PUK para ver se mesmo assim a chave privada é perdida? Caso não, seria interessante testar...

Renato

[marcio-carneiro]

Bom post, e bom trabalho.

Pergunto, o que podemos  orientar nossos clientes para evitar esse trauma?

Todo cliente quer comprar A3, o valor do A1 em relação ao A3 é muito grande, nesta economia porca fica difícil convencer nossos clientes.

Eles tem dificuldade de fazer uma boa instalação elétrica quanto mais gastar mais num certificado A1.

 

 

Editado 5 Novembro, 2017 por marcio-carneiro

[Delcio]

 

Em 01/11/2017 at 01:15, rrricci disse:

@Delcio, voce já tentou realizar este mesmo procedimento com senhas diferente entre PIN e PUK para ver se mesmo assim a chave privada é perdida? ...

Renato

Sim estava testando com senhas diferentes e sempre é solicitado o PIN.

Fiz mais alguns testes:

Testando com outro cartão, esse da Oberthur, que permite ativar um log dos acessos ao certificado descobri mais umas coisas:

Após cada transação, o hardware do cartão é reiniciado como pode ser visto abaixo; 

2017-11-03 16:03:10.240 (TID=9840) DEBUG   [PCSCReader.cpp:83]	 SCardEstablishContext (0000)
2017-11-03 16:03:10.260 (TID=9840) DEBUG   [PCSCReader.cpp:430]	 begin Transaction
2017-11-03 16:03:10.266 (TID=9840) DEBUG   [PCSCReader.cpp:94]	 POWER_ON
2017-11-03 16:03:10.585 (TID=9840) DEBUG   [PCSCReader.cpp:107]	 SCardConnect on reader ACS CCID USB Reader 0 (0000)
2017-11-03 16:03:10.595 (TID=9840) DEBUG   [PCSCReader.cpp:629]	 APDU 00 A4 04 0C 10 A0 00 00 00 77 01 08 00 07 00 00 FE 00 00 01 00
2017-11-03 16:03:10.665 (TID=9840) DEBUG   [PCSCReader.cpp:677]	 Return :90 00
	
2017-11-03 16:03:10.665 (TID=9840) DEBUG   [PCSCReader.cpp:629]	 APDU 00 A4 04 0C 0D E8 28 BD 08 0F F2 50 4F 54 20 41 57 50
2017-11-03 16:03:10.695 (TID=9840) DEBUG   [PCSCReader.cpp:677]	 Return :90 00
	
2017-11-03 16:03:10.695 (TID=9840) DEBUG   [PCSCReader.cpp:520]	 end Transaction
2017-11-03 16:03:10.698 (TID=9840) DEBUG   [PCSCReader.cpp:239]	 POWER_OFF

2017-11-03 16:03:10.702 (TID=9840) DEBUG   [PCSCReader.cpp:260]	 SCardDisconnect (0000)

Demora um tempo para essa "reinicialização" acontecer, e caso seja chamado o método createKeyFromCSP ou createKeyFromCertContext da MSXML5.dll durante esse intervalo, algum bug nessa DLL faz com que uma chamada para exclusão do conjunto de chaves seja feita ao hardware do cartão, como pode ser visto mais abaixo:

2017-11-03 16:03:10.702 (TID=9840) DEBUG   [PCSCReader.cpp:260]	 SCardDisconnect (0000)
2017-11-03 16:03:10.704 (TID=9840)  [OcsCsp.cpp:245]	 CPAcquireContext returned ERROR 0x80090016

2017-11-03 16:03:10.708 (TID=9840)  [OcsCsp.cpp:166]	 AcquireContext (container "{2E6C5A0A-2AE2-7ff6-D224-EA19FB355731}", flags CRYPT_DELETEKEYSET 0x00000010)

Nesse momento o gerenciador do cartão solicita o PIN e caso o usuário digite o certificado é excluído.

Essa DLL é a que usamos para a assinatura dos XMLs, ela é da Microsoft, faz parte do office e na sua versão mais atual, a MSXML6 não tem mais suporte a assinatura de XMLs, portanto é muito provável que não haverá qualquer correção ou suporte nessa DLL por parte da Microsoft. 

Notei que a Oberthur já contornou o problema: Na nova versão 5.1.8 SR1 do AWP Manager é exibida uma mensagem de "Acesso Negado" no momento da tentativa de exclusão e o certificado não é excluído. Testei o gerenciador da Safesign e mesmo na versão mais atual o certificado foi excluído, inclusive certificados armazenados em tokens USB.

Estou trabalhando em uma Unit de assinatura que usa somente a MSCRYPTO, assim que terminar vou disponibilizar aqui, precisarei de ajuda para testá-la e quem sabe assim se livramos da MSXML5 e conseguimos conviver em paz com os A3.

 

Editado 5 Novembro, 2017 por Delcio
correção

[Daniel Simoes]

15 horas atrás, Delcio disse:

Estou trabalhando em uma Unit de assinatura que usa somente a MSCRYPTO, assim que terminar vou disponibilizar aqui, precisarei de ajuda para testá-la e quem sabe assim se livramos da MSXML5 e conseguimos conviver em paz com os A3.

Qual é a sua abordagem de trabalho ? Usar a XMLSec com suporte a MSCrypto ?

[Daniel Simoes]

tópico relacionado...

 

[Delcio]

@Daniel Simoes é fogo, agora resolveram enviar e-mail. 

E ainda por cima a explicação deles não tem nada a ver com oque realmente acontece.

 

5 horas atrás, Daniel Simoes disse:

Qual é a sua abordagem de trabalho ? Usar a XMLSec com suporte a MSCrypto ?

Não consegui fazer essa dupla funcionar, então parti pra assinatura direta, usando somente a MSCrypto, gerando o hash, assinando e aplicando as transformações diretamente no XMl, não é um processo tão complicado, mas estou apanhado pra aplicar a Canonification c14n, não estou conseguindo selecionar corretamente os nodes para aplicar o cn14, o resto estaria pronto já.

[Daniel Simoes]

Uau... coragem... eu cheguei a cogitar esse caminho mas tb vi dificuldade nesse ponto...

Repare que na WinCrypt, já temos métodos para gerar o Hash... então, depois de "sanitizar" o XML com as transformações necessárias, poderíamos usar os métodos existentes...