SIGSEGV ao chamar card.SignXades em Java

[rpvilao]

Olá,

Tenho um use case muito específico, preciso de assinar um ficheiro XML, mas o resultado tem de ser envoloped e não um container (ASiCS). Estava a explorar fazer isto à mão, mas ao chamar o método SignXades (ainda não sei se isto me vai resolver, estou ainda na fase de explorar, por isso caso não seja assim, também seria bom saber como fazer isto) estou a ter um SEG FAULT na lib do OpenSSL.

O meu ambiente é o seguinte:
OpenSSL 3.4.1 (já testei com openssl 1.X e com 3.0.16)
Java 17 (ja testei com 8 também)
Autenticação Gov 3.13.0 (que funciona bem, consigo assinar usando o cartão)
Apple M1 (não sei até que ponto pode ser por isto)

Comando:

java -verbose:jni -Djava.library.path=/usr/local/lib/ -cp .:/usr/local/lib/pteid_jni/pteidlibj.jar XAdESEnvelopedSignatureExample 

Erro:

[0.527s][debug][jni,resolve] [Dynamic-linking native method pt.gov.cartaodecidadao.pteidlibJava_WrapperJNI.PTEID_Card_SignXades__SWIG_1 ... JNI]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007ffd1587aa63, pid=62017, tid=8963
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.14+7 (17.0.14+7) (build 17.0.14+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.14+7 (17.0.14+7, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
# Problematic frame:
# C  [libcrypto.46.dylib+0x1da63]  i2c_ASN1_INTEGER+0x16

Alguma luz ao fundo do túnel?

[agrr]

Bom dia,
confirmamos o segfault no método SignXades nesse cenário específico, programa Java 17 em MacOS ARM.

Parece ser porque existem símbolos duplicados nas bibliotecas carregadas, essa libcrypto.46.dylib pelo que percebo deverá ser uma parte do LibreSSL incluído pela Apple no MacOS. As nossas bibliotecas dependem do OpenSSL 3.0 que é incluído na instalação em /usr/local/lib/libcrypto.3.dylib. Teremos de diagnosticar melhor e tentar corrigir esta situação.

De qualquer forma para implementar uma assinatura XML ou XAdES enveloped terá de implementar uma lógica de assinatura diferente do que temos no método SignXades e utilizar a assinatura de bloco de dados com o CC.

O método PTEID_Card.Sign é o recomendado, no parâmetro data deve ser fornecida a hash pré-calculada que se pretende assinar com a chave privada do CC. Este é o programa de exemplo relevante:
https://github.com/amagovpt/docs.autenticacao.gov/blob/main/SDK_Examples/Java/SignData.java

No caso dos cartões emitidos desde junho de 2024 este método retorna a assinatura ECDSA em formato plain, em determinados contextos é necessário codificar em ASN.1 (SEQUENCE com 2 INTEGERs de 32 bytes), que é o formato utilizado por exemplo pelo algoritmo Java "SHA256withECDSA".

[rpvilao]

Olá,

Obrigado pela resposta. Entretanto usei a vossa biblioteca (libpteid) com a DSS esig europeia ( https://github.com/esig/dss ) e já tenho tudo a funcionar (caso alguém esteja com o mesmo problema). Irei depois criar um repositório para quem queira usar.

[agrr]

O conflito de símbolos que existia é devido a uma opção de linkagem utilizada por uma das bibliotecas externas incluídas no software: a libxml-security-c. Esta utilizava no seu script de build uma opção do linker que introduz este comportamento indesejável na resolução de símbolos em runtime: a flag -flat_namespace.
Com esta opção o linker não regista a dylib que implementa cada função externa no módulo que está a ser linkado, reproduzindo um comportamento mais semelhante a outros sistemas Unix e Linux.

Foi corrigida esta questão na versão 3.13.3 que está em pré-release, através de uma re-compilação da libxml-security-c:
https://github.com/amagovpt/autenticacao.gov/releases/tag/v3.13.3