Oggi è il 05 Settembre 2008, ore 13.01

SIPA

Ti trovi in: Home Versione Italiana > Sistema informatizzato dei pagamenti della PA > La firma digitale in SIPA

Regole tecniche

Uso della firma digitale in ambito SIPA
 
Al fine di dematerializzare impegni ed ordini, occorre soddisfare i seguenti requisiti di base:

a) sostituzione delle attuali firme autografe dei dirigenti/funzionari abilitati con le rispettive firme digitali;
b) sostituzione della conservazione degli attuali documenti cartacei con l’archiviazione dei documenti elettronici firmati digitalmente, secondo le regole per l’archiviazione dei documenti generati elettronicamente: questo aspetto viene trattato nel presente documento solamente in termini generali e per quanto concerne il successivo punto d).
Per il buon funzionamento del sistema complessivo (SIPA) sono altresì da garantire alcuni aspetti tecnico-organizzativi relativi alla sicurezza:
c) presenza di regole certe in merito alla responsabilità dei soggetti (Amministrazione mittente, RGS, Banca d’Italia), nel seguito organizzazioni;
d) possibilità di individuazione certa dell'organizzazione nel cui ambito sia stato alterato un dato (accidentalmente o meno), ovvero la possibilità di verificare (nell’accezione di opporre a terzi), in qualsiasi momento, che cosa è stato trasmesso e cosa è stato ricevuto ;
e) garanzia della riservatezza dei dati "riservati" (segnatamente che riguardano i beneficiari), ovvero impossibilità anche solo di lettura degli stessi da parte di persone non autorizzate.


Firma digitale

Occorre ricordare due requisiti normativi relativi alla firma digitale:
  • le procedure utilizzate per la generazione, l'apposizione e la verifica delle firme digitali debbono presentare al sottoscrittore, chiaramente e senza ambiguità, i dati a cui la firma si riferisce e richiedere conferma della volontà di generare la firma (DPR 445/2000 art.29 sexies);
  • l’operazione di firma deve generare un unico file (o stringa di dati) detto busta o file firmato aderente allo standard PKCS#7 (RFC 2315) relativo al contenuto "dati firmati" e contenente:
    - i dati originari, in chiaro;
    - la firma;
    - il certificato di sottoscrizione del firmatario, che contiene la sua chiave pubblica ed opzionalmente il ruolo in base al quale ha potere di firma (DPR 445/2000 art.27).

Per quanto concerne il ruolo, poichè il citato DPR lo pone come facoltativo, per il SIPA si ritiene che allo stato attuale sia opportuno non farne uso e gestire invece il problema a livello applicativo.


Responsabilità

Già nell’impostazione generale del SIPA si era deciso che ogni organizzazione è responsabile:
  • della qualità dei dati che trasmette;
  • del corretto aggiornamento della propria contabilità (informatizzata o meno),
  • della gestione della sicurezza all’interno del proprio dominio.
Nel prosieguo dei lavori era poi stato precisato che spetta all'organizzazione mittente garantire che vengano trasmessi unicamente dati per i quali siano state verificate:
  1. l’integrità dei dati firmati (i dati non sono stati alterati dopo l’apposizione della firma);
  2. la validità della firma apposta (chi ha firmato era – alla data – abilitato ad apporre la propria firma sui dati, ad es. relativamente all’importo).

È altresì evidente che l'organizzazione che riceve i dati per poi inoltrarli ad altre organizzazioni (la RGS alla Banca d’Italia, quest’ultima al circuito bancario e postale) deve garantire che non avvengano alterazioni improprie di quanto ricevuto rispetto a quanto trasmesso. In altre parole, poiché l'organizzazione che riceve i dati ha necessità di controllarli, memorizzarli, elaborarli, selezionare quelli da inoltrare ed eventualmente modificarne il formato, detta organizzazione deve garantire che non venga alterato il contenuto informativo dei dati stessi.

Chi riceve i dati non è tenuto, quindi, ad effettuare verifiche di integrità dei dati o di attendibilità della firma, in quanto entrambe già garantite dal mittente (v. seguito): ha però l’esigenza di estrarre i dati dalle buste PKCS#7 ai fini del controllo e dell’elaborazione, eseguendo una semplice operazione di sbustamento (tramite apposito software di mercato, disponibile anche in ambiente mainframe).


Confrontabilità tra quanto spedito e quanto ricevuto

Per poter verificare (nell’accezione di opporre a terzi), in qualsiasi momento, che cosa è stato trasmesso (Amministrazione, RGS) e cosa è stato ricevuto (Amministrazione, RGS, Banca d’Italia), è necessario che chi trasmette i dati li memorizzi opportunamente così come spediti e, analogamente, chi li riceve li memorizzi così come ricevuti: in questo modo sarà sempre possibile confrontare quanto spedito con quanto ricevuto ed individuare le eventuali responsabilità di una manomissione. Occorre perciò individuare i “morsetti” ove poter effettuare gli eventuali confronti tra i dati trasmessi dal mittente e quelli ricevuti dal destinatario, nonché le “tratte” tra i morsetti (sia di rete che interne all'organizzazione di appartenenza) lungo le quali va garantita la sicurezza dei dati.

Nell'architettura prevista per il SIPA (cfr. "Specifica del servizio" ed il suo Allegato B "Specifiche EAS) la "catena" di sistemi ed apparati utilizzati tra il sistema informativo dell'organizzazione e la rete è costituita dall’EAS che unitamente al Front End Multi-Servizio (FEMS), fornisce il servizio di trasporto responsabile della comunicazione tra le Applicazioni. In particolare:
  • EAS: Entità di Accesso al Sistema, è il punto di accesso alla rete di trasporto e si può considerare come un confine applicativo del sistema informativo dell'organizzazione, in quanto vi risiedono le code di input e di output;
  • FEMS: (Front End Multiservizio): ) è il punto di accesso alla rete e costituisce il confine fisico tra il mondo della RUPA e il sistema informativo degli utenti connessi. Dialoga con EAS, gestendo i servizi specializzati di Message Switching, File Transfer e Transazionale. FEMS sono le macchine che interfacciano fisicamente i sistemi informativi delle Amministrazioni alla rete e che provvedono al trasporto dei dati attraverso la rete.


Da quanto detto segue che i morsetti sono:
  • le code EAS dal punto di vista applicativo (trasporto logico), più precisamente le code di output per chi trasmette e quelle di input per chi riceve,
  • FEMS dal punto di vista della rete (trasporto fisico);
mentre le tratte sono di due tipi:
  • interne, di esclusiva responsabilità dell'organizzazione (Amministrazione, RGS, Banca d’Italia), cioè quelle tra il sistema informativo dell'organizzazione stessa ed EAS, tra EAS e FEMS ( FEMS comunica mediante collegamenti Token-ring o Ethernet in protocollo SNA logical unit 6.2 con il prodotto software EAS installato sul sistema informativo dell'Utente o su Server UNIX fornito da SIA)
  • di rete (RUPA/RNI) cioè FEMS-to.FEMS (di organizzazioni diverse).

Le code EAS sono però "temporanee", quindi la memorizzazione dei dati trasmessi e ricevuti consiste rispettivamente nella memorizzazione dei dati:
  • prima di accodarli alle code di output,
  • come presenti sulle code di input, prima di elaborarli;
come delineato negli schemi riportati alla fine del presente documento.


Riservatezza dei dati

Occorre ricordare che:
  • l'identificazione dell'organizzazione mittente è garantita dall'utilizzo di EAS (autenticazione) La funzione di autenticazione prevede un riconoscimento reciproco fra EAS e FEMS, attraverso la condivisione una chiave comune. Questa è calcolata da SIA mediante un processo che in modo random, attraverso l'utilizzo di un algoritmo, genera un valore personalizzato per ogni utente. La "quantità di sicurezza" è considerata come password per tutte le applicazioni che vogliono utilizzare i servizi di rete mediante quel punto di accesso.
  • La funzione di crittografia di rete che garantisce la sicurezza tra FEMS-to-FEMS è realizzata attraverso l’utilizzo del protocollo IPSEC direttamente implementato da Windows 2000. Tale funzionalità viene realizzata mediante la soluzione Micorsoft Kerberos e consente di realizzare la funzione di autenticazione e crittografia delle diverse frame IP inoltrate verso le controparti di rete.
  • sulle code EAS, sia di input che di output, i dati sarebbero crittografati solamente in seguito all'adozione della crittografia applicativa, che garantisce la riservatezza EAS-toEAS, ma vanno considerati due diversi scenari:


Conclusioni

  1. non utilizzo del ruolo nei certificati di sottoscrizione;
  2. invio dei dati come firmati, ovvero si trasmettono le buste PKCS#7;
  3. memorizzazione dei dati come trasmessi, ovvero si memorizzano le buste spedite;
  4. memorizzazione dei dati come ricevuti, ovvero si memorizzano le buste ricevute;
  5. crittografia applicativa:
a) non utilizzo nel periodo transitorio,
b) da studiare l'opportunità dell'utilizzo a regime.
Gli schemi seguenti delineano i processi a regime:
  • del mittente, senza distinguere tra Amministrazione ed RGS: è la fase finale del processo, dall'apposizione della firma digitale all'accodamento su EAS;
  • del ricevente, distintamente per RGS (con rinvio allo schema di cui sopra) e Banca d’Italia.


Schema di preparazione invio firma digitale per l'Amministrazione e l'RGS


Schema di preparazione invio firma digitale per la Ragioneria


Schema di preparazione invio firma digitale per la Banca d'Italia