Specifiche di base: XML Encryption in pillole...

  • Article

La specifica XML Encryption [XMLENC xmlns:xenc='https://www.w3.org/2001/04/xmlenc#' ] ha il compito di definire la sintassi e il processo per cifrare dei dati binari o testuali e rappresentarli in formato XML. La struttura XML della specifica si basa sull’elemento EncryptedData :

 <EncryptedData Id? Type? MimeType? Encoding?>
    <EncryptionMethod/>?
    <ds:KeyInfo>
      <EncryptedKey>?
      <AgreementMethod>?
      <ds:KeyName>?
      <ds:RetrievalMethod>?
      <ds:*>?
    </ds:KeyInfo>?
    <CipherData>
      <CipherValue>?
      <CipherReference URI?>?
    </CipherData>
    <EncryptionProperties>?
  </EncryptedData>

il quale può contenere o referenziare il documento cifrato (o ciphertext) permettendo due modalità diverse di rappresentazione : Enveloping e Detached.

Figura7

Nel primo caso è presente l’elemento CipherValue che contiene il ciphertext espresso in Base64 mentre nel secondo caso l’elemento CipherReference punta ad una locazione dove è presente il ciphertext. In questo caso è stato utilizzato il termine Detached encryption e non Enveloped encryption perchè in crittografia Enveloped encryption ha un significato diverso. Infatti Enveloped Encryption viene utilizzato per definire una operazione di cifratura un pò più complessa. Il testo in chiaro (o plaintext) viene cifrato con una chiave simmetrica (detta di sessione) generando un ciphertext. La chiave di sessione appena utilizzata (e generata) per l’encryption viene cifrata a sua volta da un’altra chiave (asimmetrica). La cifratura della chiave di sessione avviene tramite la chiave pubblica del destinatario (inteso come l’entità che deve decifrare il messaggio). Il ciphertext e la chiave di sessione cifrata devono essere presenti entrambi durante la fase di decryption possibile solo dal possessore della chiave privata associata.

EncryptionMethod è un elemento opzionale che indica quale algoritmo crittografico è stato utilizzato per le operazioni di cifratura. Nel caso questo elemento non fosse presente, il compito di ottenere tali informazioni è demandato al livello applicativo. In tabella 1 è presente uno schema riassuntivo degli algoritmi supportati dalla specifica.

image

 

 

 

 

 

 

 

 

 

 

 

Tabella 1.

L’elemento KeyInfo serve per rappresentare le informazioni inerenti le chiavi di cifratura. Si noti che tale elemento è preceduto dal namespace ds (xmlns:ds='https://www.w3.org/2000/09/xmldsig# ) della specifica [XMLDSIG]. Questo indica che le regole riguardanti questo elemento appartengono alla specifica di firma digitale. Per un maggiore dettaglio sull’argomento consultare la specifica [XMLDSIG] mentre per le possibili estensioni consultare la specifica [XMLENC].

Un ’estensione importante è data dall’elemento EncryptedKey.

 <element name='EncryptedKey' type='xenc:EncryptedKeyType'/>
  <complexType name='EncryptedKeyType'>
    <complexContent>
      <extension base='xenc:EncryptedType'>
        <sequence>
          <element ref='xenc:ReferenceList' minOccurs='0'/>
          <element name='CarriedKeyName' type='string' minOccurs='0'/>
        </sequence>
        <attribute name='Recipient' type='string' use='optional'/>
      </extension>
    </complexContent>   
  </complexType>

Tale elemento viene impiegato per la distribuzione delle chiavi simmetriche tramite il pattern definito in Enveloped Encryption, dove la chiave simmetrica viene cifrata per ogni destinatario con un’altra chiave (chiave pubblica). EncryptedKey può essere inserito come figlio di ds:KeyInfo, come documento XML disgiunto, oppure come elemento all’interno dello stesso documento XML contenente un ds:KeyInfo.

Il sottoelemento opzionale ReferenceList indica quali chiavi simmetriche sono state cifrate mentre CarriedKeyName e Recipient danno ulteriori informazioni al contesto applicativo per individuare la chiave di cifratura.

L’elemento CipherData è un dato obbligatorio e referenzia o contiene il ciphertext che sostituisce l’informazione in chiaro. Lo schema di CipherData indica che sono possibili due valori : CipherValue e CipherReference

 <element name='CipherData' type='xenc:CipherDataType'/>
  <complexType name='CipherDataType'>
     <choice>
       <element name='CipherValue' type='base64Binary'/>
       <element ref='xenc:CipherReference'/>
     </choice>
   </complexType>

L’elemento CipherValue rappresenta il ciphertext in formato Base64 mentre CipherReference è un riferimento al ciphertext puntato tramite l’attributo URI.

 <element name='CipherReference' type='xenc:CipherReferenceType'/>
   <complexType name='CipherReferenceType'>
       <sequence>
         <element name='Transforms' type='xenc:TransformsType' minOccurs='0'/>
       </sequence>
       <attribute name='URI' type='anyURI' use='required'/>
   </complexType>

   <complexType name='TransformsType'>
      <sequence>
        <element ref='ds:Transform' maxOccurs='unbounded'/> 
      </sequence>
   </complexType>

Anche in questo caso, come in [XMLDSIG] è possibile effettuare delle trasformazioni per processare i dati. Le operazioni di trasformazione però sono state concepite in modo diverso rispetto alla specifica di firma digitale. Infatti in [XMLDSIG] il processo di generazione e di validazione utilizza sempre gli stessi dati di input (sempre il plaintext) ed applica le trasformazioni nello stesso ordine.Vicecersa, in [XMLENC], le operazioni di cifratura e decifratura partono da input diversi (rispettivamente il plaintext e il ciphertext) e la specifica indica che l’ordine in cui sono impostate le trasformazioni sono da intendersi solo per l’operazione di decifratura. Questo significa che durante la fase di cifratura le operazioni vengono svolte nell’ordine inverso. A causa di queste diversità il sottoelemento Transforms è definito all’interno del namespace di [XMLENC].

Infine l’ultimo elemento opzionale di EncryptedData è EncryptionProperties che rappresenta un insieme di informazioni aggiuntive per l’applicazione di decrypt come ad esempio il timestamp o informazioni rigurdanti device crittografici o settaggi software per la decifratura.

In seguito sono riportati alcuni esempi di applicazione , tratti dalla specifica, di questa RFC a porzioni di documenti XML:

<!-- Informazione in chiaro-->

<PaymentInfo xmlns='https://example.org/paymentv2'>
<Name>John Smith</Name>
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>

<!-- Cifratura dell'elemento CreditCard-->

<PaymentInfo xmlns='https://example.org/paymentv2'>
<Name>John Smith</Name>
<EncryptedData Type='https://www.w3.org/2001/04/xmlenc#Element'
    xmlns='https://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</PaymentInfo>

<!-- Cifratura di parte del contenuto dell' elemento CreditCard-->

<PaymentInfo xmlns='https://example.org/paymentv2'>
<Name>John Smith</Name>
<CreditCard Limit='5,000' Currency='USD'>
<EncryptedData xmlns='https://www.w3.org/2001/04/xmlenc#'
      Type='https://www.w3.org/2001/04/xmlenc#Content'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</CreditCard>
</PaymentInfo>

Esempio di cifratura secondo il pattern Enveloped Encryption.

 <S:Envelope
   xmlns:S="https://www.w3.org/2001/12/soap-envelope"
   xmlns:ds="https://www.w3.org/2000/09/xmldsig#"
   xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/04/secext"
   xmlns:xenc="https://www.w3.org/2001/04/xmlenc#">
  <S:Header>
    <wsse:Security>
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod Algorithm="..."/>
        <ds:KeyInfo>
          <ds:KeyName>CN=Mario Fontana, C=IT</ds:KeyName>
        </ds:KeyInfo>
        <xenc:CipherData>
          <xenc:CipherValue>...</xenc:CipherValue>
        </xenc:CipherData>
        <xenc:ReferenceList>
          <xenc:DataReference URI="#bodyID"/>
        </xenc:ReferenceList>
      </xenc:EncryptedKey>
    </wsse:Security>
  </S:Header>
  <S:Body>
    <xenc:EncryptedData Id="bodyID">
      <xenc:CipherData>
        <xenc:CipherValue>...</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </S:Body>
</S:Envelope>

Il documento XML è formato dall’elemento xenc:EncryptedKey il quale contiene le informazioni sulle chiavi simmetriche e asimmetriche e un secondo elemento xenc:EncrytpedData contenente il ciphertext dei dati applicativi. Vediamo durante le due fasi (encryption e decryption) quali sono i passi che un’applicazione deve seguire: nella fase di creazione del documento XML l’applicazione genera una chiave di sessione SK1 che utilizza per cifrare le informazioni sensibili creando l’elemento xenc:EncryptedData che sostituisce al plaintext. A questo punto determina il destinatario del messaggio secondo la propria logica applicativa e utilizza la relativa chiave pubblica per cifrare SK1 che, in formato cifrato, viene inserita in xenc:CipherValue e imposta l’URI in xenc:DataReference per associare i dati cifrati con la chiave di sessione. Successivamente l’applicazione crea l’elemento ds:KeyInfo che tramite il sottoelemento ds:KeyName inserisce una stringa (“CN = Mario Fontana, C=IT”) che l’applicazione utilizzerà per iniziare il processo di decifratura tramite l’uso della corrispettiva chiave privata. In fase di decifratura l’applicazione, partendo dalla stringa in ds:KeyName, accede alla chiave privata e decifra il contenuto in xenc:CipherValue. Tale contenuto è la chiave di sessione SK1 che verrà utilizzata per decifrare la porzione XML referenziata da xenc:DataReference (in questo caso “#bodyID”) che punta ovviamente ad un blocco xenc:EncryptedData. Con questo meccanismo è possibile risolvere il problema della cifratura di informazioni applicative oltre al problema della distribuzione delle chiavi.

--Mario