La crittografia XML è effettivamente danneggiata?

Con un po 'di ricerche, ho trovato alcune prove di recenti attività su questo argomento: Spiegazione funzionale delle modifiche in XML Encryption 1.1 (W3C Working Group Note 11 aprile 2013) . Ci sono molti cambiamenti in XML Encryption 1.1, tra gli altri:

• Aggiunta della derivazione chiave
• Aggiunta dell'accordo chiave Elliptic Curve Diffie-Hellman
• Algoritmi aggiunti
• Algoritmi modificati

e tra i più rilevanti per la tua domanda, modifiche alle considerazioni sulla sicurezza:

Added security consideration information on Chosen Ciphertext Attacks, including attacks against encrypted data and encrypted key. Provide specific notes on CBC Block Encryption vulnerability, and the Bleichenbacher attack.

L'articolo che stavi leggendo riguarda lo sfruttamento di un punto debole nella modalità CBC per il concatenamento di diversi blocchi di testo cifrato. Sebbene sembri la cosa reale , si applica agli schemi di crittografia prima di XML Encryption 1.1 :

“We were able to decrypt data by sending modified ciphertexts to the server, by gathering information from the received error messages.” The attack was tested against a popular open source implementation of XML Encryption, and against the implementations of companies that responded to the responsible disclosure – in all cases the result was the same: the attack works, XML Encryption is not secure.

Anche se non lo vedo come un'esagerazione, e nemmeno mi sembra sorprendente (vedi ad esempio questo rispondi alla domanda Quanto è meno sicura una crittografia se sappiamo qualcosa sui dati originali? e Wiki sull'attacco Adaptive Selected-ciphertext ), è necessario menzionare nuovamente che si applica alla modalità di crittografia CBC disponibile in XML Encryption 1.0 che è stato gestito da un diverso gruppo di lavoro W3C ( XML Encryption WG attivo per l'ultima volta nel 2008).

Questo lavoro è stato spostato in XML Security Working Group il cui figlio è XML Encryption 1.1 come risposta diretta a tali attacchi come descritto nell'articolo. Infatti, XML Security Working Group menziona direttamente questi attacchi su XML Encryption 1.0 nella documentazione di XML Encryption 1.1. / p>

Addendum : leggendo alcuni articoli di crittografia non correlati, mi sono imbattuto in Matthew Green Il post del blog su Attack of the week: XML Encryption che risale indietro fino all'ottobre 2011. Matthew Green è un crittografo e ricercatore presso la Johns Hopkins University e scrive i più favolosi testi sulla crittografia e argomenti correlati. La sua spiegazione di cosa sia questo attacco su XML Encryption è la migliore che abbia mai letto e, naturalmente, una lettura consigliata per chiunque sia interessato a saperne di più su di loro. Ecco un breve estratto:

Stop using unauthenticated CBC mode. Stop using any encryption standard designed before 2003 that hasn't been carefully analyzed and recently updated. Stop using any unauthenticated encryption at all. Wrap your SOAP connections with TLS (a recent version!) if you can.

^{Fonte: Attacco della settimana: XML Encryption, Matthew Green}

Penso che sarà utile aggiungere un commento a questa risposta, incluso lo stato corrente.

Attacchi cifratici adattati eletti:
Gli attacchi applicati su XML Encryption sono attacchi a testo cifrato adattivi scelti. In uno scenario di attacco con testo cifrato adattativo scelto, l'utente malintenzionato prende il testo cifrato originale, lo modifica e lo invia al server. Quindi valuta la risposta del server, che gli consente di decidere se il testo in chiaro sottostante è valido o meno. Ripete più volte ciò che gli consente di decifrare l'intero messaggio.

Questi attacchi sono ad es. applicabile agli schemi CBC (modalità operativa Cipher Block Chaining), che è ancora standardizzata da XML Encryption o da molti altri standard. CBC (AES-CBC o 3DES-CBC) consente di modificare i plaintext nel testo cifrato, senza conoscere la chiave di crittografia. Più specificamente, l'attaccante è in grado di capovolgere i bit specifici nel testo in chiaro (non sto entrando nei dettagli, per favore leggi la carta o il post sul blog di Matt Green menzionato nella prima risposta). Se alcuni bit nel testo in chiaro vengono capovolti, l'utente malintenzionato genera un messaggio che non può essere elaborato dal parser XML. Altri bit generano testi in chiaro validi.

Prerequisiti di attacco: Ci sono due prerequisiti per l'esecuzione dell'attacco. Innanzitutto, l'utente malintenzionato deve essere in grado di modificare i testi cifrati e imporre al server di elaborarli. Secondo, l'attaccante deve avere un'informazione se il testo cifrato decrittografato è valido o meno. Ciò è in genere possibile poiché il server risponde con un diverso messaggio di errore se il testo cifrato modificato era valido e con un messaggio diverso se non era valido (esistono anche altri modi per distinguere i messaggi validi o non validi, ad esempio misurando i tempi di risposta).

Ok, ma le firme XML dovrebbero garantire l'integrità ... Sì, abbiamo lo standard XML Signature che consente di proteggere l'integrità dei messaggi XML. Ciò mitiga teoricamente gli attacchi dal momento che i testi cifrati possono essere firmati. Ciò impedisce la modifica del testo cifrato (il primo prerequisito di attacco).

Tuttavia, in tutti i framework testati, è stato possibile applicare questo attacco anche se sono state applicate le firme XML. In breve, una tipica firma XML protegge solo una parte di un messaggio XML. Siamo stati in grado di posizionare i testi cifrati modificati in parti, che non erano firmate. Anche se non sono stati firmati, i framework sono stati elaborati e decodificati.

Questo non è stato considerato dallo standard XML Encryption e ora viene indirizzato nella versione più recente, incluso uno schema di crittografia sicuro AES-GCM: link

Framework che abbiamo analizzato: Abbiamo analizzato alcuni framework e scoperto che erano vulnerabili agli attacchi. Ad esempio Apache Axis2, JBossWS, Apache CXF o alcuni framework SAML. Gli attacchi hanno funzionato, anche se sono state utilizzate le firme XML.

Contromisure: Come menzionato nella prima risposta, ci sono diverse contromisure elencate nel nuovo standard. Se si progetta o si utilizza XML Security, il server deve controllare attentamente se i testi cifrati sono stati firmati. Se il messaggio contiene un testo cifrato senza segno, il messaggio dovrebbe essere rifiutato. Ecco come è stato implementato ora in Apache CXF. Un'altra possibilità è usare AES-GCM ...

Per ulteriori informazioni, puoi dare un'occhiata alla mia tesi, che riassume tutti gli attacchi (compresi gli attacchi su RSA PKCS # 1 v1.5) e fornisce diversi contromisure: link

Stato attuale: Con le contromisure presentate, è possibile implementare un sistema sicuro contro gli attacchi adattati al testo cifrato. Abbiamo fatto diversi pentests e abbiamo visto molti sistemi, dove non siamo stati in grado di applicare questi attacchi.

Penso che XML Encryption (insieme a XML Signature) sia un ottimo standard che supporta così tanti scenari di riservatezza. Ma devi prestare attenzione a come configuri il tuo sistema (non sono sicuro che i framework siano sicuri per impostazione predefinita).

Aggiorna

Abbiamo rilasciato un plug-in per il nostro framework WS-Attacker per testare le vulnerabilità nei servizi Web utilizzando XML Encryption: link

Abbiamo presentato il nostro nuovo articolo: Come rompere la crittografia XML - Automaticamente: link Lì, abbiamo analizzato anche il framework WCF.