P7m codificato

[Sbraaa (Domenico Sgarbossa)]

Ciao,
ho un problema con un p7m che non riesco a leggere ma non trovo nessun post che descriva il problema pertanto chiedo aiuto sperando qualcuno mi sappia dare le informazioni necessarie.
Dispongo di diversi xml codificati con Cades che riesco a leggere eliminando l’incapsulamento della firma in formato PKCS#7 ma ne ho ricevuto uno che non riesco proprio a gestire: sembra sia salvato in binario anziché come banale testo.
I vari software (dike, assoinvoice) lo leggono regolarmente e segnalano la firma come valida, a qualcuno è capitato di aver a che fare con file del genere?

[vbato (Vladan Bato)]

Cosa intendi con “sembra sia salvato in binario anziché come banale testo”?
I file PKCS#7 sono tutti binari. Cosa fai esattamente per eliminare l’incapsulamento?

[Sbraaa (Domenico Sgarbossa)]

probabilmente non mi sto esprimendo nei termini corretti: da quello che leggo in rete un XML firmato CAdES è di fatto l’XML nativo al quale viene aggiunto in testa ed in coda un set di dati per incapsularne il contenuto.

es.

0ƒ+S *†H†÷

a ƒ+C0ƒ+>

1
0 `†H
e
0ƒ$U *†H†÷

a
ƒ$Eƒ$@<?xml version="1.0" encoding="UTF-8"?>…

ed in questo caso identificare il contenuto del file è abbastanza semplice.
Viceversa ho degli xml.p7m che contengono dati del tipo:

MIIdqwYJKoZIhvcNAQcCoIIdnDCCHZgCAQExDzANBglghkgBZQMEAgEFADCCDeIG
CSqGSIb3DQEHAaCCDdMEgg3PPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0i
VVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+PD94bWwtc3R5bGVzaGVldCB0eXBlPSd0
ZXh0L3hzbCcgaHJlZj0nZmF0dHVyYXByX3YxLjIueHNsJz8+PHA6RmF0dHVyYUVs
ZXR0cm9uaWNhIHhtbG5zOnA9Imh0dHA6Ly9pdmFzZXJ2aXppLmFnZW56aWFlbnRy
YXRlLmdvdi5pdC9kb2NzL3hzZC9mYXR0dXJlL3YxLjIiIHhtbG5zOnhzaT0iaHR0
cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHZlcnNpb25l
PSJGUFIxMiI+PEZhdHR1cmFFbGV0dHJvbmljYUhlYWRlcj48RGF0aVRyYXNtaXNz
aW9uZT48SWRUcmFzbWl0dGVudGU+PElkUGFlc2U+SVQ8L0lkUGFlc2U+PElkQ29k
aWNlPjA1MDA2OTAwOTYyPC9JZENvZGljZT48L0lkVHJhc21pdHRlbnRlPjxQcm9n
cmVzc2l2b0ludmlvPmp1Y2VtMDAwNTk8L1Byb2dyZXNzaXZvSW52aW8+PEZvcm1h
dG9UcmFzbWlzc2lvbmU+RlBSMTI8L0Zvcm1hdG9UcmFzbWlzc2lvbmU+PENvZGlj
ZURlc3RpbmF0YXJpbz4wMDAwMDAwPC9Db2RpY2VEZXN0aW5hdGFyaW8+PFBFQ0Rl…

vedo che anche in quest’ultimo caso il file è di testo quindi il contenuto è evidentemente criptato.
Come posso decrittarlo? Dike e Assoinvoice lo fanno senza problemi.
E’ forse crittato con una chiave pubblica che non è la mia?

[vbato (Vladan Bato)]

Così a naso direi che quello è un file .p7m codificato in base64.
Anzi, ho provato a decodificare il pezzo che hai postato ed è in effetti l’inizio di un file .p7m. Quindi devi fare la decodifica base64.
Pensavo che un file del genere non fosse valido, ma ho appena provato a fare la verifica sul sito dell’agenzia delle entrate con un file .p7m codificato in base64 e mi dice che è valido, quindi mi sbagliavo.

A parte questo problema della codifica in base64, ti avviso che il sistema che stai usando è comunque sbagliato. I file .p7m non hanno semplicemente dei dati davanti e dietro al file xml. Il formato è più complesso di così. In alcuni casi il file xml può essere spezzettato in più blocchi con altri dati binari nel mezzo (per esempio Infocert li fa così). Ti consiglio vivamente di usare una libreria in grado di gestire i file PKCS#7 correttamente.

[Sbraaa (Domenico Sgarbossa)]

ok grazie per la dritta!
mi confermi comunque che se estraggo i dati dal .p7m usando openssl dovrei ottenere un’estrazione valida?

es. openssl smime -verify -inform DER -in file_originale.p7m -noverify -out file_finale

[vbato (Vladan Bato)]

@Sbraaa

mi confermi comunque che se estraggo i dati dal .p7m usando openssl dovrei ottenere un’estrazione valida?

Sì, ho appena fatto una prova e funziona correttamente.

[sgardini (Stefano Gardini)]

Ovviamente dal canale arrivano fatture in codifica base64. Sto cercando di capire se dal file xml si riesce ad individuarle in qualche modo, capire se sono codificate o meno. A quanto vi risulta possono essere codificate in base 64 anche fatture non firmate? Immagino di sì.

[vbato (Vladan Bato)]

Anche a noi sono arrivate fatture codificate in base64.

La nostra procedura per prima cosa verifica se il file è codificato in base64, ovvero verifica se la lunghezza è un multiplo di 4 e se tutti i caratteri sono caratteri base64 validi ([A-Za-z0-9+/=] dove ‘=’ può comparire solo come ultimo o come ultimi due caratteri). Se sì, allora esegue la conversione da base64 e poi procede come di consueto.

Non possono esserci dubbi, perché sia i file .p7m che i file xml contengono sempre caratteri non validi nella codifica base64.

[sgardini (Stefano Gardini)]

Grazie della dritta non ci avevo pensato in effetti.

[sgardini (Stefano Gardini)]

Se può servire uso questa Regex
^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$
oltre al controllo multiplo di 4, anche se probabilmente è pure di troppo

[vbato (Vladan Bato)]

Vi segnalo anche che il hash che c’è nel file dei metadati è del file che vi arriva, quindi se il file arriva codificato in base64, il hash corrisponderà a quello. Se lo decodificate e buttate via l’originale, non avrete più la corrispondenza con il hash nel file dei metadati.

[Romolo_Manfredini]

io prima verifico l’hash se l’hash non corrisponde per me è un’anomalia e la registro comunque
per chi non lo sapesse visto che il tag HASH nel metadati non era (non ho fatto caso all’ultima documentazione) documentato, è l’sha256sum del file.

[Romolo_Manfredini]

@vbato

Anche a noi sono arrivate fatture codificate in base64.

La nostra procedura per prima cosa verifica se il file è codificato in base64, ovvero verifica se la lunghezza è un multiplo di 4 e se tutti i caratteri sono caratteri base64 validi ([A-Za-z0-9+/=] dove ‘=’ può comparire solo come ultimo o come ultimi due caratteri). Se sì, allora esegue la conversione da base64 e poi procede come di consueto.

Non possono esserci dubbi, perché sia i file .p7m che i file xml contengono sempre caratteri non validi nella codifica base64.

ti sono arrivati degli xml in base64 o degli xml.p7m ?
Perchè se arrivano degli xml.p7m per la documentazione fornita da sogei va ancora bene, ma nella documentazione non c’è scritto da nessuna parte che la codifica base64 per i file dei flussi è accettabile. (o perlomeno non l’ho trovato scritto)

[vbato (Vladan Bato)]

@Romolo_Manfredini

ti sono arrivati degli xml in base64 o degli xml.p7m ?

Finora ho visto un solo file .p7m. È una casistica piuttosto rara.

[ClaudioP (Claudio Pizzillo)]

Ho riscontrato in p7m codificati in tutte le fatture emesse dalla SIAE.

[vbato (Vladan Bato)]

Vi segnalo che i criteri sopra esposti per identificare i file codificati in base64 non vanno bene
Oggi abbiamo ricevuto un file (.p7m) codificato in base64 ma spezzato su più righe (come si usa negli allegati delle mail). Quindi nel verificare se sono dati base64 bisogna tirare via eventuali caratteri CR e LF (non so se altri tipi di spazi sono ammessi).

[Marcx (Marco Carettoni)]

Da quello che ho letto in giro i file codificati in CaDES possono essere in Base64…

Noi abbiamo risolto cosi, tentando la decodifica in b64 sempre se va bene teniamo il content nuovo, altrimenti quello vecchio:

public static byte[] removeP7MCodes(final String NOME_FILE, byte[] p7bytes) throws WSException {
	try {
		if (p7bytes == null || !NOME_FILE.toUpperCase().endsWith(".P7M")) {
			return p7bytes;
		}
		try {
			p7bytes = org.bouncycastle.util.encoders.Base64.decode(p7bytes);
		} catch (Exception e) {
			logger.debug("File P7m non in base64, tengo content standard" + e.getMessage());
		}

		CMSSignedData cms = new CMSSignedData(p7bytes);
		if (cms.getSignedContent() == null)
			throw new WSException("Impossibile trovare signed Content durante decodifica da P7M per file: " + NOME_FILE);    		

		ByteArrayOutputStream out = new ByteArrayOutputStream();
		cms.getSignedContent().write(out);
		out.flush();
		return out.toByteArray();
	} catch (CMSException | IOException e) {
		throw new WSException("Impossibile decodificare P7M per File: " + NOME_FILE, e);}
}

Con i vari flussi passivi ricevuti in produzione ci siamo accorti delle seguenti casistiche:

• File p7m in base64, gestisto con il check sulla decodifica.
• File p7m che decodificati contenevano il carattere BOM e che faceva fallire la fase di unmarshalling e abbiamo rimosso manualmente…

[Romolo_Manfredini]

Il mio criterio è il seguente:

1. file ricevuto inizia con <?XML (dopo aver ripulito eventuali spazi iniziali allora è un file xml posso leggere i dati del destinatario ed inoltrarla.
   Se anche contiene dssignature, e quindi è uno xades sarà comunque il destinatario a verificare la firma, eventualmente in caso di PA inoltrerò le notifiche di scarto qualora il destinatario dovesse rifiutare la fattura per firma non valida: caso che non dovrebbe mai succedere dato che la verifica dovrebbe farla anche SDI.

2. il file ricevuto non inizia con xml provo la decompattazione con openssl (potrebbe trattarsi di un file xml mal nominato che in realtà è un .xml.p7m, ma SDI avrebbe dovuto scartarla) se la decompattazione fallisce acquisisco il file fra le anomalie, non sapendo a chi inoltrarlo, altrimenti prendo il file decompattato, leggo l’xml per trovare il destinatario e inoltro il p7m originale al destinatario.

Ad oggi dopo qualche migliaio di fatture trattate, non ho anomalie.

[vbato (Vladan Bato)]

Non hai mai ricevuto file codificati in base64?
Non hai mai ricevuto file senza la dichiarazione xml (che iniziano direttamente con l’elemento <FatturaElettronica>)?

Noi abbiamo riscontrato entrambe le casistiche.

[Romolo_Manfredini]

non capisco come facciano a passare il controllo dell’xsd senza l’intestazione <?XML
p7m codificati base 64 si, ma xml codificati base64 no…
per quello chiedevo precedentemente…