Colloquio TOTEM-SIRGESA - OSCAT

Transcript

Gestione della Carta Sanitaria Elettronica - TS-CNS
Colloquio SIRGESA-TOTEM – Specifiche Tecniche
Colloquio TOTEM-SIRGESA
Specifiche Tecniche
Versione 1.0
07/03/2013
RTI
Funzione
Redazione
Capo progetto RTI (Aruba)
Esperto di dominio (Actalis)
Capo progetto CMS (Engineering)
Esperto architetture (Engineering)
Approvazione
Capo progetto RTI
Regione Toscana
Funzione
Nome
Umberto Ferrara,
Riccardo Casiraghi
Massimo Agostiniani
Fabio Bennati
Nome
Verifica
Approvazione
Nome file: CSE-ServiziAggiuntivi_SIRGESA_TOTEM_ST_1-0.odt
Pag. 1 di 40
Indice generale
AGGIORNAMENTI DELLE VERSIONI..................................................................3
1GENERALITÀ............................................................................................4
1.1Scopo........................................................................................................................................................................4
1.2Riferimenti................................................................................................................................................................4
1.3Definizioni e abbreviazioni.......................................................................................................................................4
1.4Allegati......................................................................................................................................................................4
2PREREQUISITI/VINCOLI..............................................................................5
3SCENARIO D'USO......................................................................................6
3.1Caso d'uso F001P1UC1: Installazione Servizio Aggiuntivo....................................................................................6
3.2Caso d'uso F001P1UC1-1: Esecuzione macro comando........................................................................................10
4SPECIFICHE INTERFACCIA SIRGESA-TOTEM....................................................13
4.1Autorizza Richiesta.................................................................................................................................................13
4.1.1Sirgesa Response AuthReq........................................................................................................................14
4.2Recupera Modello...................................................................................................................................................14
4.2.1Sirgesa Response Model............................................................................................................................15
4.2.2Schema di validazione del RuntimeServiceModel...............................................................................15
4.2.3Macro Comandi............................................................................................................................................17
4.2.3.1Crea Area Servizio Aggiuntivo.................................................................................................................18
4.2.3.2Elimina Area Servizio Aggiuntivo............................................................................................................20
4.2.3.3Crea Cartella.............................................................................................................................................21
4.2.3.4Elimina Cartella........................................................................................................................................23
4.2.3.5Crea File....................................................................................................................................................24
4.2.3.6Crea File BSO...........................................................................................................................................26
4.2.3.7Elimina File...............................................................................................................................................28
4.2.3.8Verifica File..............................................................................................................................................29
4.2.3.9Verifica Cartella........................................................................................................................................30
4.2.3.10Verifica Seriale Carta.............................................................................................................................31
4.2.4Esempio Risposta REST............................................................................................................................31
4.3Notify Esito.............................................................................................................................................................36
4.3.1Sirgesa Response Notify..........................................................................................................................36
4.4Validate...................................................................................................................................................................38
4.4.1Sirgesa Response Validate.......................................................................................................................39
Pag. 2 di 40
AGGIORNAMENTI DELLE VERSIONI
Versione
Data
Motivo
0.9 draft a
1.0
28/01/13
07/03/13
Emissione
Gestione nuovo parametro
“parameters” + Correzione
Modifiche
–
Aggiunta riga alle tabelle descrittive dei
comandi nei sottoparagrafi del § 4.2.3
Struttura securityElement del comando
“CreaFileBSO” - paragrafo 4.2.3.6
Pag. 3 di 40
1 GENERALITÀ
Nell'ambito della diffusione di servizi aggiuntivi sulla CNS Regione Toscana ha implementato per le CNS di
cui è ente emettitore un servizio infrastrutturale utile alla semplificazione dell'inizializzazione dei servizi.
Il servizio “SIstema Regionale di GEstione dei Servizi Aggiuntivi” (SIRGESA) ha il compito di inizializzare il
servizio aggiuntivo su richiesta del “Sistema di Gestione dello Specifico Servizio (SGSS)”.
Il servizio, una volta inizializzato potrà essere utilizzato da altri sistemi secondo le specifiche del servizio
stesso.
Il presente documento costituisce l’output del processo di definizione delle specifiche tecniche
dell’interfaccia di colloquio tra SIRGESA ed i sistemi TOTEM, di cui si è dotata Regione Toscana, volto
all’inizializzazione di un generico servizio aggiuntivo sulla carta CNS regionale.
Il documento descrive:
• Pre-requisiti
• Scenario d'uso
• Indicazione delle specifiche di interfaccia;
1.1
Scopo
L’obiettivo di questo documento è quello di descrivere l’interfaccia e le modalità di interazione tra SIRGESA
e TOTEM.
1.2
Riferimenti
http://www.digitpa.gov.it/sites/default/files/LineeguidaCNS%28v3.0%29.pdf
http://www.digitpa.gov.it/sites/default/files/FileSystemCNS_21112005.pdf
http://www.digitpa.gov.it/sites/default/files/allegati_tec/CNS Functional Specification 1.1.6_02042011.pdf
1.3
Definizioni e abbreviazioni
RT
Regione Toscana
SIRGESA
SIstema Regionale di GEstione dei Servizi Aggiuntivi
SGSS
Sistema di Gestione dello Specifico Servizio
CNS
Carta Nazionale dei Servizi
TOTEM
Chiosco o punto informativo, è principalmente un computer
disponibile all'uso pubblico
APDU
Application Protocol Data Unit
ISO7816-4
Identification cards - Integrated circuit cards - Organization,
security and commands for interchange
JSON
JavaScript Object Notation
REST
Representational state transfer
1.4
Allegati
N.A.
Pag. 4 di 40
2 PREREQUISITI/VINCOLI
Di seguito elenchiamo i pre-requisiti necessari all’attivazione del colloquio tra SIRGESA e TOTEM:
•
SIRGESA ha a disposizione un proprio certificato APP2APP (p12) composto di due chiavi una
pubblica ed una privata di seguito indicate con SIRGESA_PK e SIRGESA_SK.
•
SGSS ha a disposizione un proprio certificato APP2APP (p12) composto di due chiavi una pubblica
ed una privata di seguito indicate con SGSS_PK e SGSS_SK.
•
Il TOTEM ha ricevuto la chiave pubblica di SIRGESA (SIRGESA_PK) quale elementi necessario alla
gestione del colloquio tra i due sistemi
•
Affinché l'inizializzazione del servizio possa avvenire è necessario che la postazione TOTEM, di
seguito indicato genericamente come client, ove è presente la CNS abbia le seguenti
caratteristiche:
o connettività di rete
o driver di colloquio con la carta secondo le specifiche CNS (ISO7816)
o capacita di instaurare un colloquio secondo il protocollo http ovvero http over ssl in
architettura REST
•
Il TOTEM richiama la url di autorizzazione richiesta esposta da SIRGESA per l'inizializzazione del
servizio sulla carta solo se SGSS lo ha notificato dell'assenza del servizio sulla carta fornendogli i
parametri necessari alla costruzione della richiesta.
•
Il TOTEM deve essere in grado di recuperare il seriale dalla carta CNS regionale e di colloquiare
con esso secondo lo standard ISO 7816 (comandi APDU)
Pag. 5 di 40
3 SCENARIO D'USO
3.1
Caso d'uso F001P1UC1: Installazione Servizio Aggiuntivo
ID:
F001P1UC1
Titolo:
Installazione Servizio Aggiuntivo
Versione:
1.0
Stato:
Draft
Attori:
Totem, SGSS, SIRGESA
Breve descrizione:
Il TOTEM rilevata l'asenza del servizio aggiuntivo sulla carta richiede al sistema SGSS le informazioni
necessarie per procedere all'installazione del servizio sulla carta CNS regionale; Il TOTEM ricevute le
informazioni colloquia con il sistema SIRGESA per essere pilotato nell'installazione dello specifico servizio
aggiuntivo sulla carta. Completata l'installazione del servizio aggiuntivo il TOTEM torna a colloquiare con il
sistema SGSS per gestire il servizio aggiuntivo sulla carta.
Evento scatenante:
Accesso dell'utente alle funzionalità di gestione del servizio aggiuntivo presso una postazione TOTEM e
mancata presenza del servizio aggiuntivo sulla propria carta CNS regionale.
Postcondizioni:
Precondizioni:
• Il TOTEM trova installato sulla carta CNS
• Il client (TOTEM) ha connettività internet
regionale, in esso inserita, il servizio
• Il client ha ricevuto la chiave pubblica di
aggiuntivo gestito da SGSS
SIRGESA (SIRGESA_PK) quale elemento
necessario alla gestione del colloquio tra i
due sistemi
• SIRGESA è una applicazione web
• SIRGESA espone su internet alcune risorse
web su cui il client farà pervenire delle
richieste secondo protocollo http ovvero
http over ssl in architettura REST.
Attività:
1. Il TOTEM, rilevata l'assenza dello specifico servizio aggiuntivo sulla carta CNS regionale e ricevute
da SGSS le informazione necessarie ad attivare il processo di installazione del servizio sulla carta,
invia a SIRGESA (Autorizza Richiesta) una richiesta di autorizzazione all'installazione del servizio
sulla carta;
2. Il Sistema SIRGESA riceve la richiesta di autorizzazione all'esecuzione dell'installazione del servizio
corredata di tutte le informazioni necessarie a completare l’attività; La richiesta è corredata di un
parametro denominato verifycheck che rappresenta l'hash dei parametri di richiesta firmato con la
chiave privata di SGSS;
3. Il TOTEM riceve da SIRGESA la sessionkey associata alla propria richiesta e la modalità di
esecuzione dell'azione richiesta: automatica o con previo consenso del possessore della carta;
4. Il TOTEM richiede a SIRGESA (Recupera Modello) il modello di esecuzione dell'azione autorizzata
fornendo come propria chiave autorizzativa la sessionkey precedente ricevuta;
5. SIRGESA comunica al TOTEM il modello di esecuzione precedentemente generato ed associato alla
specifica sessionkey; la risposta è corredata di un valore denominato verifycheck che rappresenta
l'hash della risposta firmato con la chiave privata di SIRGESA;
6. Il TOTEM verificata l'autenticità della risposta, analizza il modello di esecuzione individuando in
esso le unità di processo da eseguire sulla carta;
7. Il TOTEM per ciascuna delle unità di processo presenti procede alla sua interpretazione e alla
esecuzione sulla carta dell'insieme di macro comandi in essa contenuti come descritto nel sottocaso d'uso (Esecuzione macro comando);
8. Il TOTEM completata positivamente l'esecuzione di tutte le unità di processo previste dal modello
Pag. 6 di 40
di esecuzione trasmette a SIRGESA (Notify Esito) l'esito dell'esecuzione così come definito nel
modello di esecuzione e la sessionkey autorizzativa;
9. SIRGESA comunica al TOTEM l'avvenuta registrazione dell'esito ed un insieme di valori utili a
riprendere il colloquio con SGSS per la gestione del servizio aggiuntivo sulla carta; la risposta è
corredata di un valore denominato verifycheck che rappresenta l'hash della risposta firmato con la
chiave privata di SIRGESA;
10. Il caso d’uso termina.
Flussi alternativi:
Se la richiesta di autorizzazione inviata dal TOTEM a SIRGESA non ha esito positivo.
sulla carta;
3. Il TOTEM riceve da SIRGESA un esito negativo all'autorizzazione della richiesta ed interrompe il
processo di gestione del servizio sulla carta dando opportuna notifica al possessore della carta;
Flussi alternativi:
Se la richiesta di Recupera Modello inviata dal TOTEM a SIRGESA non ha esito positivo.
sulla carta;
5. SIRGESA comunica al TOTEM un esito negativo in risposta alla richiesta effettuata; la risposta è
6. Il TOTEM verificata l'autenticità della risposta interrompe il processo di gestione del servizio sulla
carta dando opportuna notifica al possessore della carta;
Flussi alternativi:
Se la verifica di autenticità della risposta ricevuta da SIRGESA all'invocazione della risorsa
Recupera Modello non ha esito positivo.
sulla carta;
Pag. 7 di 40
3.
4.
5.
6.
7.
8.
9.
Il TOTEM riceve da SIRGESA la sessionkey associata alla propria richiesta e la modalità di
Il TOTEM richiede a SIRGESA (Recupera Modello) il modello di esecuzione dell'azione autorizzata
SIRGESA comunica al TOTEM il modello di esecuzione precedentemente generato ed associato alla
Il TOTEM non avendo verificata l'autenticità della risposta trasmette a SIRGESA (Notify Esito)
l'esito negativo (94) e la sessionkey autorizzativa;
SIRGESA comunica al TOTEM l'avvenuta registrazione dell'esito;
Il TOTEM interrompe il processo di gestione del servizio sulla carta dando opportuna notifica al
possessore della carta;
Il caso d’uso termina.
Flussi alternativi:
Se il modello di esecuzione del servizio non è conforme allo schema previsto.
sulla carta;
6. Il TOTEM verificata l'autenticità della risposta, analizza il modello di esecuzione e ne riscontra la
non conformita allo schema previsto;
7. Il TOTEM trasmette a SIRGESA (Notify Esito) l'esito negativo (99) e la sessionkey autorizzativa;
8. SIRGESA comunica al TOTEM l'avvenuta registrazione dell'esito;
9. Il TOTEM interrompe il processo di gestione del servizio sulla carta dando opportuna notifica al
Flussi alternativi:
Se una unità di processo definita nel modello non si completa con esito positivo ad esclusione
dell'unità di verifica assenza servizio (codici errore diverso da “01”).
sulla carta;
Pag. 8 di 40
8. Il TOTEM rileva un esito negativo nell'esecuzione della singola unità di processo ed individua nella
definizione della stessa all'interno del modello di esecuzione il codice di errore da trasmettere a
SIRGESA;
9. Il TOTEM trasmette a SIRGESA (Notify Esito) l'esito negativo e la sessionkey autorizzativa;
10. SIRGESA comunica al TOTEM l'avvenuta registrazione dell'esito;
Flussi alternativi:
Se l'unità di processo di verifica assenza servizio ritorna esito negativo (“01”).
sulla carta;
8. Il TOTEM rileva un esito negativo nell'esecuzione della singola unità di processo ed individua nella
definizione della stessa all'interno del modello di esecuzione il codice di errore da trasmettere a
SIRGESA (“01”: servizio già installato);
9. Il TOTEM trasmette a SIRGESA (Notify Esito) l'esito negativo (“01”) e la sessionkey autorizzativa;
10. SIRGESA comunica al TOTEM l'avvenuta registrazione dell'esito ed un insieme di valori utili a
riprendere il colloquio con SGSS per la gestione del servizio aggiuntivo sulla carta; la risposta è
11. Il caso d'uso termina.
Pag. 9 di 40
Flussi alternativi:
Se la comunicazione dell'esito dal TOTEM a SIRGESA (NotifyEsito) non si completa con esito
positivo.
sulla carta;
8. Il TOTEM completata positivamente l'esecuzione di tutte le unità di processo previste dal modello
di esecuzione trasmette a SIRGESA (Notify Esito) l'esito dell'esecuzione così come definito nel
modello di esecuzione e la sessionkey autorizzativa;
9. SIRGESA comunica al TOTEM la mancata registrazione dell'esito ritornando un esito negativo; la
risposta è corredata di un valore denominato verifycheck che rappresenta l'hash della risposta
firmato con la chiave privata di SIRGESA;
3.2
Caso d'uso F001P1UC1-1: Esecuzione macro comando
ID:
F001P1UC1-1
Titolo:
Esecuzione Macro Comando
Versione:
1.0
Stato:
Draft
Attori:
Totem, SIRGESA
Breve descrizione:
Il TOTEM, analizzata l'unità di processo del modello di esecuzione, ne estrapola i macro comandi corredati
da insiemi specifici di parametri di esecuzione. Per ciascun macro comando il Totem verifica che la smart
card inserita abbia il numero seriale associato al macro-comando e procede a trasformarlo nell'insieme di
comandi APDU che consentono l'attuazione del medesimo sulla carta. Il TOTEM per inoltrare i comandi
APDU potrebbe avere necessità di eseguire una external authentication sulla carta e per eseguirla dovrà
Pag. 10 di 40
richiedere a SIRGESA la criptazione del challenge ottenuto dalla carta. Completato l'invio dei comandi
APDU alla carta il TOTEM procederà alla chiusura della sessione in external authentication.
Evento scatenante:
Il TOTEM ha ricevuto da SIRGESA un modello di esecuzione valido, analizzando una unità di processo in
esso contenuta ha individuato un macro comando da eseguire sulla carta.
Precondizioni:
Postcondizioni:
• Il TOTEM ha realizzato correttamente sulla
carta il macro comando riportato nel modello
di esecuzione.
Attività:
1. Il TOTEM, analizza il comando ed estrapola i valori dei singoli parametri ad esso associati
verificando coerenza e completezza;
2. Il TOTEM verifica che il seriale della carta su cui opera corrisponda al parametro “serialeCarta”
presente all'interno del comando;
3. Il TOTEM richiede alla carta la generazione di un challenge per attivare l'external authentication;
4. Il TOTEM richiede a SIRGESA (Validate) la validazione del comando posto in esecuzione e la
criptazione del challenge fornendo come propria chiave autorizzativa la sessionkey ricevuta;
5. SIRGESA comunica al TOTEM il challenge criptato;
6. Il TOTEM tramite il challenge criptato esegue l'external authentication sulla carta;
7. Il TOTEM trasforma il macro comando ed i parametri ad esso associato nei relativi comandi APDU,
li invia alla carta e ne gestisce gli esiti;
8. Il TOTEM completata positivamente l'esecuzione di tutti i comandi APDU generati chiude la
sessione di external authentication sulla carta;
9. Il TOTEM segnala la corretta esecuzione del macro comando sulla carta al gestore di esecuzione
della unità di processo di cui il comando fa parte;
Flussi alternativi:
Se la verifica della coerenza del seriale della carta ha esito negativo.
2. Il TOTEM verifica che il seriale della carta su cui opera non corrisponde al parametro
“serialeCarta” presente all'interno del comando;
3. Il TOTEM segnala la non corretta esecuzione del macro comando sulla carta al gestore di
esecuzione della unità di processo di cui il comando fa parte;
Flussi alternativi:
Se la richiesta di Validate inviata dal TOTEM a SIRGESA non ha esito positivo.
5. SIRGESA comunica al TOTEM un esito negativo;
Pag. 11 di 40
Flussi alternativi:
Se l'esito dell'invio dal TOTEM alla carta di un comando APDU non ha l'esito previsto.
5. SIRGESA comunica al TOTEM il challenge criptato;
6. Il TOTEM tramite il challenge criptato esegue l'external authentication sulla carta;
7. Il TOTEM trasforma il macro comando ed i parametri ad esso associato nei relativi comandi APDU,
li invia alla carta e ne gestisce gli esiti;
8. Il TOTEM registra un esito imprevisto come risultato dell'esecuzione di un comando APDU e
quindi chiude la sessione di external authentication sulla carta;
Pag. 12 di 40
4 SPECIFICHE INTERFACCIA SIRGESA-TOTEM
4.1
Autorizza Richiesta
Il SIRGESA mette a disposizione una risorsa web, in architettura REST su protocollo https, a cui il client
(TOTEM) richiede l'autorizzazione all'esecuzione di una delle azioni previste sulla carta relativamente ad
uno specifico servizio aggiuntivo.
Le url da richiamare sono:
Ambiente di pre-produzione
https://<nome_server_pre-produzione>/sirgesa/rest/autorizzaRichiesta
Ambiente di produzione
https://<nome_server_produzione>/sirgesa/rest/autorizzaRichiesta
Il sistema SIRGESA sulle indicate url:
• non prevede l’identificazione del client
• attraverso il parametro verifycheck verifica che i parametri di chiamata risultano inalterati e forniti
da SGSS.
Di seguito le caratteristiche di invocazione in termini di parametri passati in POST sulla url:
PARAMETRI
Azione
serviceName
transId
urlRitorno
serialNumber
timestamp
verifycheck
DESCRIZIONE
Azione richiesta sulla carta. Possibili valori:
•
INIT
•
REMOVE (ancora non attiva)
•
VERIFY (ancora non attiva)
Nome del servizio aggiuntivo come censito su SIRGESA
Identificativo di transazione nel sistema SGSS
Risorsa web SGSS a cui il client ritorna l'esito dell'azione terminata
l'esecuzione della stessa sulla carta (eventualmente vuoto)
Numero seriale della carta
Tempo di generazione della richiesta espresso nel formato
dd/MM/yyyy-HH:mm:ss (*)
Digest secondo l’algoritmo SHA-256 della concatenazione dei valori
presenti nei parametri precedenti, criptato con la chiave privata di
SGSS (SGSS_SK) e codificato in Base64 (**)
(*) Verranno prese in considerazione ed elaborate solo le richieste pervenute al SIRGESA entro 100 secondi dal timestamp
dichiarato nella chiamata.
(**) Encode(Sign(Hash(Azione+serviceName+transId+urlRitorno+serialNumber+timestamp, SHA-256), SGSS_SK),BASE64)
Di seguito riportiamo le caratteristiche della risposta:
RESPONSE
SirgesaResponseAuthReq
DESCRIZIONE
Rappresentazione JSON dell’oggetto SirgesaResponseAuthReq
Pag. 13 di 40
4.1.1 Sirgesa Response AuthReq
La struttura dell’oggetto SirgesaResponseAuthReq viene di seguito rappresentata:
ATTRIBUTI
TIPO
DESCRIZIONE
Esito
String
Esito della operazione di autorizzazione azione sulla carta:
“00” : autorizzata
“92” : carta non valida / non riconosciuta
“94” : colloquio sirgesa non validato
“97” : servizio inesistente
“98” : richiesta non conforme
“99” : errore generico
sessionkey
String
Identificativo
della richiesta di autorizzazione inviata dal client
(TOTEM) a SIRGESA e da questo verificata. La sessionkey equivale ad
una chiave una-tantum a tempo (100 secondi) tramite la quale il
sistema SIRGESA re-interrogato possa gestire in ogni momento i
parametri della richiesta e fornire le informazioni necessarie al client.
automatic
String
Permette di rendere automatica o meno l’esecuzione dell’azione
richiesta sulla carta. Nel caso di valore false il client deve chiedere
consenso al possessore delle carta prima di procedere all'esecuzione
dell'azione richiesta sulla carta. Valori ammessi:”true” e “false”
verifycheck
String
SIRGESA (SIRGESA_SK) e codificato in Base64 (**)
(**) Encode(Sign(Hash(esito+sessionkey+automatic, SHA-256), SIRGESA_SK),BASE64)
4.2
Recupera Modello
SIRGESA mette a disposizione una risorsa web, in architettura REST su protocollo https, da cui il client
(TOTEM) può recuperare il runtimeServiceModel del servizio aggiuntivo; tale modello contiene l’insieme
delle operazioni che dovranno essere eseguite sulla carta per portare a termine l’azione richiesta (es.
Installazione del servizio).
https://<nome_server_pre-produzione>/sirgesa/rest/getModel
https://<nome_server_produzione>/sirgesa/rest/getModel
- non prevede l’identificazione del client
- attraverso il parametro sessionkey, che non è altro che una chiave a tempo* fornita in precedenza
al client dal sistema SIRGESA, viene recupera l’azione richiesta, il numero seriale della carta a cui
tale chiave è associata e per cui viene generato il runtimeServiceModel.
- La risposta SIRGESA alla richiesta contiene un attributo verifycheck che consente al client di
verificare che i restanti attributi forniti sono generati da SIRGESA e non sono stati alterati durante il
traporto.
Di seguito riportiamo le caratteristiche di invocazione in termini di parametri passati in POST sulla
chiamata:
Pag. 14 di 40
PARAMETRI
DESCRIZIONE
sessionKey
Identificativo della richiesta di inizializzazione inviata dal client a
SIRGESA e da questo verificata. La sessionkey equivale ad una
chiave una-tantum a tempo* tramite la quale il sistema SIRGESA reinterrogato possa gestire in ogni momento i parametri della richiesta
e fornire le informazioni necessarie al client.
(*) Verranno prese in considerazione ed elaborate solo le richieste pervenute al SIRGESA entro 100
secondi dal timestamp dichiarato nella chiamata “Autorizza Richiesta”.
RESPONSE
DESCRIZIONE
SirgesaResponseModel
Rappresentazione JSON dell’oggetto SirgesaResponseModel
4.2.1 Sirgesa Response Model
La struttura dell’oggetto SirgesaResponseModel viene di seguito rappresentata:
ATTRIBUTI
TIPO
DESCRIZIONE
sessionkey
String
Identificativo
della richiesta di autorizzazione inviata dal client
(TOTEM) a SIRGESA e da questo verificata.
runtimeServiceModel String
Rappresentazione xml del modello di comandi da eseguire a runtime
sulla carta per la realizzazione della azione richiesta per lo specifico
servizio aggiuntivo. Tale rappresentazione rispetta lo schema riportato
nel paragrafo seguente
esito
String
Esito della operazione di recupero del runtime Service Model:
“00” : successo
“90” : ip di provenienza della chiamata non conforme
“91” : sessione inesistente
“95” : sessione scaduta
verifycheck
String
SIRGESA (SIRGESA_SK) e codificato in Base64 (**)
(**) Encode(Sign(Hash(sessionkey+runtimeServiceModel+esito, SHA-256), SIRGESA_SK),BASE64)
4.2.2 Schema di validazione del RuntimeServiceModel
Di seguito riportiamo lo schema di validazione del Runtime Service Model ricevuto da SIRGESA.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="service" type="serviceType"/>
<xs:complexType name="serviceType">
<xs:sequence>
<xs:element maxOccurs="unbounded" name="action" type="actionType"/>
</xs:sequence>
Pag. 15 di 40
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="actionType">
<xs:sequence>
<xs:element maxOccurs="unbounded" name="unit" type="unitType"/>
</xs:sequence>
<xs:attribute name="successCode" type="xs:string" use="required"/>
<xs:attribute name="failCode" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="unitType">
<xs:sequence>
<xs:element maxOccurs="unbounded" name="command" type="commandType"/>
</xs:sequence>
<xs:attribute name="failCode" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="commandType">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="parameter"
type="parameterType"/>
</xs:sequence>
<xs:attribute name="name" type="nameCommandType" use="required"/>
<xs:attribute name="expectedCode" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="parameterType">
<xs:choice>
<xs:element name="runtimeValue" type="runtimeValueType"/>
<xs:element name="staticValue" type="staticValueType"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="staticValueType">
<xs:attribute name="value" type="xs:hexBinary" use="required"/>
</xs:complexType>
<xs:complexType name="runtimeValueType">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="key" type="xs:string"/>
</xs:sequence>
<xs:attribute name="function" type="xs:string" use="required" />
</xs:complexType>
<xs:simpleType name="nameCommandType">
<xs:restriction base="xs:string">
<xs:enumeration value="creaAreaServizioAggiuntivo"/>
<xs:enumeration value="eliminaAreaServizioAggiuntivo"/>
<xs:enumeration value="creaCartella"/>
<xs:enumeration value="eliminaCartella"/>
<xs:enumeration value="creaFile"/>
Pag. 16 di 40
<xs:enumeration value="creaFileBSO"/>
<xs:enumeration value="eliminaFile"/>
<xs:enumeration value="verificaFile"/>
<xs:enumeration value="verificaCartella"/>
<xs:enumeration value="verificaSerialeCarta"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
4.2.3 Macro Comandi
Di seguito l'elenco dei macro comandi gestiti nel modello del generico Servizio Aggiuntivo da SIRGESA.
COMMANDTYPE
MACRO COMANDO
01x
Crea Area Servizio Aggiuntivo
02x
Elimina Area Servizio Aggiuntivo
03x
Crea Cartella
04x
Elimina Cartella
05x
Crea File
06x
Crea File BSO
07x
Elimina File
08x
Verifica File
09x
Verifica Cartella
0Ax
Verifica Seriale Carta
Pag. 17 di 40
4.2.3.1 Crea Area Servizio Aggiuntivo
Il comando consente la creazione della cartella specifica del servizio aggiuntivo applicando a quest’ultima la
tipologia di sicurezza richiesta. Tutti i parametri sono di tipo byte o array di byte espressi con il tipo
hexBinary.
PARAMETRI
DESCRIZIONE
sessionkey
Identificativo della richiesta di autorizzazione inviata dal client (TOTEM) a SIRGESA e da questo
verificata.
nomeCartella
FID
AID
securityElement
Nome della cartella da creare sotto l’area DF2
Identificativo della cartella come comunicato al CNIPA e quindi associato allo specifico servizio
espresso tramite due byte.
Application identifier espresso al messimo tramite 16 byte.
Modalità di sicurezza ida attivare sull’area del servizio aggiuntivo.
Viene rappresentato tramite una sequenza di nove bytes, posizionalmente correlati a specifiche
Access Condition secondo la tabella seguente:
Byte N.
1
2
3
4
5
6
7
8
9
Access Condition
UPDATE
APPEND
DEACTIVATE
ACTIVATE
DELETE
ADMIN
CREATE
-
ciascuno indicante la specifica condition secondo il seguente formalismo:
Byte Value
00x
01x…1Fx
FFx
Condition
ALWAYS
BSO ID
NEVER
Pag. 18 di 40
PARAMETRI
DESCRIZIONE
Modalità di comunicazione sicura da attivare nell’esecuzione delle operazioni sull’oggetto; nel
secureMessaging caso non debba essere attivata l’array di byte avrà lunghezza 0.
Viene rappresentato tramite una sequenza di 24 byte, posizionalmente correlati a specifiche SM
Element
Condition secondo la tabella seguente:
Byte N.
1,2
3
4
5..12
13
14
15
16
17..24
SM Condition
ENC_UPDATE/APPEND
SIG_UPDATE/APPEND
ENC_ADMIN
SIG_ADMIN
ENC_CREATE
SIG_CREATE
-
Byte Value
00x
01x…1Fx
FFx
serialeCarta
commandType
Condition
ALWAYS
BSO ID
NEVER
Numero seriale della carta su cui eseguire il comando
Identificativo del comando richiesto. Valorizzato con la costante 01x
Digest secondo l’algoritmo SHA-256 della concatenazione dei valori presenti nei parametri
commandCheck precedenti in un unico array di byte, firmato con la chiave privata di SIRGESA (SIRGESA_SK).
Sign(
Hash(
sessionkey+nomeCartella+FID+AID+securityElement+secureMessagingElement+serialeCarta+
commandType,
SHA-256),
SIRGESA_SK)
parameters
Concatenazione dei seguenti parametri:
nomeCartella+FID+AID+securityElement+secureMessagingElement
Pag. 19 di 40
4.2.3.2 Elimina Area Servizio Aggiuntivo
Il comando consente l’eliminazione della cartella specifica del servizio aggiuntivo. Tutti i parametri sono di
tipo byte o array di byte espressi con il tipo hexBinary.
PARAMETRI
DESCRIZIONE
sessionkey
Identificativo della richiesta di autorizzazione inviata dal client (TOTEM) a
SIRGESA e da questo verificata.
nomeCartella
FID
serialeCarta
Nome della cartella da eliminare sotto l’area DF2
Identificativo della cartella come comunicato al CNIPA e quindi associato allo
specifico servizio espresso tramite due byte.
commandType
commandCheck
Digest secondo l’algoritmo SHA-256 della concatenazione dei valori presenti
nei parametri precedenti in un unico array di byte, firmato con la chiave
privata di SIRGESA (SIRGESA_SK).
Sign(
Hash(
sessionkey+nomeCartella+FID+serialeCarta+commandType,
SHA-256),
SIRGESA_SK)
parameters
nomeCartella+FID+serialeCarta
Pag. 20 di 40
4.2.3.3 Crea Cartella
Il comando consente la creazione di una cartella con specifico FID e nome all’interno dell’area dello
specifico servizio in uno specifico path e applicando a quest’ultima la tipologia di sicurezza richiesta.Tutti i
parametri sono di tipo byte o array di byte espressi con il tipo hexBinary.
PARAMETRI
DESCRIZIONE
sessionkey
verificata.
nomeCartella
Nome della cartella da creare
path
Path della cartella rispetto alla DF2 della carta
FID
Identificativo della cartella come indicato nelle specifiche tecniche della struttura del servizio
aggiuntivo, espresso tramite due byte.
AID
Application id della cartella espresso al messimo tramite 16 byte.
Modalità di sicurezza ida attivare sulla cartella.
securityElement Viene rappresentato tramite una sequenza di nove bytes, posizionalmente correlati a specifiche
Access Condition secondo la tabella seguente:
Byte N.
1
2
3
4
5
6
7
8
9
Access Condition
UPDATE
APPEND
DEACTIVATE
ACTIVATE
DELETE
ADMIN
CREATE
-
Byte Value
00x
01x…1Fx
FFx
Condition
ALWAYS
BSO ID
NEVER
Pag. 21 di 40
PARAMETRI
DESCRIZIONE
Element
Byte N.
1,2
3
4
5..12
13
14
15
16
17..24
SM Condition
ENC_UPDATE/APPEND
SIG_UPDATE/APPEND
ENC_ADMIN
SIG_ADMIN
ENC_CREATE
SIG_CREATE
-
Byte Value
00x
01x…1Fx
FFx
serialeCarta
commandType
Condition
ALWAYS
BSO ID
NEVER
Sign(
Hash(
sessionkey+nomeCartella+path+FID+AID+securityElement+secureMessagingElement+serialeCarta+
commandType,
SHA-256),
SIRGESA_SK)
parameters
nomeCartella+path+FID+AID+securityElement+secureMessagingElement
Pag. 22 di 40
4.2.3.4 Elimina Cartella
Il comando consente l’eliminazione di una cartella all’interno dell’area specifica del servizio aggiuntivo. Tutti
i parametri sono di tipo byte o array di byte espressi con il tipo hexBinary.
PARAMETRI
DESCRIZIONE
sessionkey
Identificativo della richiesta di autorizzazione inviata dal client
nomeCartella
Nome della cartella da eliminare
path
Path della cartella rispetto alla DF2 della carta
FID
Identificativo della cartella come comunicato al CNIPA e quindi
associato allo specifico servizio espresso tramite due byte.
serialeCarta
commandType
commandCheck
presenti nei parametri precedenti in un unico array di byte, firmato
con la chiave privata di SIRGESA (SIRGESA_SK).
Sign(
Hash(
sessionkey+nomeCartella+path+FID+serialeCarta+commandType,
SHA-256),
SIRGESA_SK)
parameters
nomeCartella+path+FID
Pag. 23 di 40
4.2.3.5 Crea File
Il comando consente la creazione di un elementary file con specifico FID e nome all’interno dell’area dello
specifico servizio in uno specifico path e applicando a quest’ultimo la tipologia di sicurezza richiesta. Tutti i
PARAMETRI
DESCRIZIONE
sessionkey
verificata.
nomeFile
Nome del file elementare da creare
path
Path della cartella all’interno della quale creare il file rispetto alla DF2 della carta
FID
Identificativo del file come indicato nelle specifiche tecniche della struttura del servizio
aggiuntivo, espresso tramite due byte.
size
Dimensione massima del file
tipo
Tipologia del file da creare espressa secondo la tabella seguente:
Valore
01x
02x
05x
06x
recordSize
Tipologia
TRASPARENT
FIXED
VARIABLE
CYCLIC
Dimensione del singolo record nel caso di tipo FIXED, 0 in tutti gli altri casi
Modalità di sicurezza ida attivare sul file. Viene rappresentato tramite una sequenza di nove
securityElement bytes, posizionalmente correlati a specifiche Access Condition secondo la tabella seguente:
Byte N.
1
2
3
4
5
6
7
8,9
Access Condition
READ
UPDATE
APPEND
DEACTIVATE
ACTIVATE
DELETE
ADMIN
-
Byte Value
00x
01x…1Fx
FFx
Condition
ALWAYS
BSO ID
NEVER
Pag. 24 di 40
PARAMETRI
DESCRIZIONE
Element
Byte N.
1
2
3
4
5
6
7..12
13
14
15..22
23
24
SM Condition
ENC_READ_OUT
SIG_READ_OUT
ENC_UPDATE
SIG_UPDATE
ENC_APPEND
SIG_APPEND
ENC_ADMIN
SIG_ADMIN
ENC_READ_IN
SIG_READ_IN
Byte Value
00x
01x…1Fx
FFx
serialeCarta
commandType
Condition
ALWAYS
BSO ID
NEVER
Sign(
Hash(
sessionkey+nomeFile+path+FID+size+tipo+recordSize+securityElement+secureMessagingElement+
serialeCarta+commandType,
SHA-256),
SIRGESA_SK)
parameters
nomeFile+path+FID+size+tipo+recordSize+securityElement+secureMessagingElement
Pag. 25 di 40
4.2.3.6 Crea File BSO
Il comando consente la creazione di un file di tipo BSO con specifico ID e nome all’interno dell’area dello
specifico servizio in uno specifico path e applicando a quest’ultimo la tipologia di sicurezza richiesta. Tutti i
PARAMETRI
DESCRIZIONE
sessionkey
verificata.
nomeFile
path
ID
maxErrors
tipo
Nome del file elementare da creare
Path della cartella all’interno della quale creare il file BSO rispetto alla DF2 della carta
Identificativo del file come indicato nelle specifiche tecniche della struttura del servizio aggiuntivo,
espresso tramite un byte.
Numero massimo di errori consentito
Tipologia del file BSO da creare espresso con tre byte secondo la tabella seguente (dove i tre byte
indicano rispettivamente in sequenza: class, option e algorithm del file BSO – si faccia riferimento
alle specifiche CNS per ulteriori dettagli):
Valore
20220Cx
21020Cx
202288x
210288x
002188x
010188x
008382x
108303x
108382x
208303x
000287x
00027Fx
validityCounter
minimumLength
securityContent
Tipologia
RSA_PRI_MOD_CRIPT
RSA_PRI_EXP_CRIPT
RSA_PRI_MOD_SIGN
RSA_PRI_EXP_SIGN
RSA_PUB_MOD
RSA_PUB_EXP
3DES_AUTH
3DES_SM_CRIPT
3DES_SM_AUTH
3DES_CRIPT
PIN
LOGICAL
Indicatore che serve a limitare l’uso di un diritto di accesso a specifici ambiti (00x, FFx significano
nessuna limitazione)
Indica la lunghezza minima espressa con un byte; in casi di oggetto di tipo PIN e la lunghezza
minima del challenge per gli oggetti che ne fanno uso. Nel caso di PIN indica la lunghezza del PIN.
Per gli altri oggetti impostata a 00x.
Rappresenta il contenuto del file BSO espresso sottoforma di array di byte
Pag. 26 di 40
PARAMETRI
DESCRIZIONE
Modalità di sicurezza ida attivare sul file. Viene rappresentato tramite una sequenza di sette byte,
securityElement posizionalmente correlati a specifiche Access Condition secondo la tabella seguente:
Byte N.
1
2
3
4,5,6
7
8,9
Access Condition
USE
CHANGE
UNBLOCK
GENKEYPAIR
-
Byte Value
00x
01x…1Fx
FFx
Condition
ALWAYS
BSO ID
NEVER
Modalità di comunicazione sicura da attivare nell’esecuzione delle operazioni sull’oggetto; nel caso
secureMessaging non debba essere attivata l’array di byte avrà lunghezza 0.
Element
Byte N.
1
2
3
4
5
6
7
8
SM Condition
ENC_USE_IN
SIG_USE_IN
ENC_CHANGE
SIG_CHANGE
ENC_UNBLOCK
SIG_UNBLOCK
ENC_USE_OUT
SIG_USE_OUT
Byte Value
00x
01x…1Fx
FFx
serialeCarta
commandType
Condition
ALWAYS
BSO ID
NEVER
Sign(
Hash(
sessionkey+nomeFile+path+ID+maxErrors+tipo+validityCounter+minimumLength+securityElement+
secureMessagingElement+serialeCarta+commandType,
SHA-256),
SIRGESA_SK)
Pag. 27 di 40
PARAMETRI
parameters
DESCRIZIONE
nomeFile+path+ID+maxErrors+tipo+validityCounter+minimumLength+securityElement+
secureMessagingElement
Pag. 28 di 40
4.2.3.7 Elimina File
Il comando consente l’eliminazione di un file all’interno dell’area specifica del servizio aggiuntivo. Tutti i
PARAMETRI
DESCRIZIONE
sessionkey
nomeFile
path
FID
serialeCarta
Nome del file elementare da eliminare
Path della cartella all’interno della quale eliminare il file rispetto alla
DF2 della carta
Identificativo del file come comunicato al CNIPA e quindi associato
allo specifico servizio espresso tramite due byte.
commandType
commandCheck
Sign(
Hash(
sessionkey+nomeFile+path+FID+serialeCarta+commandType,
SHA-256),
SIRGESA_SK)
parameters
nomeFile+path+FID
Pag. 29 di 40
4.2.3.8 Verifica File
Il comando consente di verificare la presenza di un file all’interno dell’area specifica del servizio aggiuntivo.
Tutti i parametri sono di tipo byte o array di byte espressi con il tipo hexBinary.
PARAMETRI
sessionkey
path
FID
serialeCarta
DESCRIZIONE
Path della cartella all’interno della quale verificare la presenza del
file rispetto alla DF2 della carta
commandType
commandCheck
Sign(
Hash(
sessionkey+path+FID+serialeCarta+commandType,
SHA-256),
SIRGESA_SK)
parameters
path+FID
Pag. 30 di 40
4.2.3.9 Verifica Cartella
Il comando consente di verificare la presenza di una cartella all’interno dell’area specifica del servizio
aggiuntivo.Tutti i parametri sono di tipo byte o array di byte espressi con il tipo hexBinary.
PARAMETRI
sessionkey
path
FID
serialeCarta
DESCRIZIONE
Path della cartella all’interno della quale verificare la presenza del
file rispetto alla DF2 della carta
commandType
commandCheck
Sign(
Hash(
sessionkey+path+FID+serialeCarta+commandType,
SHA-256),
SIRGESA_SK)
parameters
path+FID
Pag. 31 di 40
4.2.3.10
Verifica Seriale Carta
Il comando consente di verificare che il seriale della carta corrisponda al seriale passato come parametro.
Tutti i parametri sono di tipo byte o array di byte espressi con il tipo hexBinary.
PARAMETRI
DESCRIZIONE
sessionkey
serialeCarta
Seriale da verificare se corrispondente con quello della carta.
commandType
Identificativo del comando richiesto. Valorizzato con la costante 0Ax
commandCheck
Sign(
Hash(
sessionkey+serial+commandType,
SHA-256),
SIRGESA_SK)
parameters
Valorizzato con un array di byte vuoto
4.2.4 Esempio Risposta REST
Di seguito si riporta un esempio di risposta prodotta da SIRGESA.
{"runtimeServiceModel":"\u003cservice name\u003d\"ISEE\"\u003e\u003caction
failCode\u003d\"99\" name\u003d\"INIT\"
successCode\u003d\"00\"\u003e\u003cunit failCode\u003d\"96\"
name\u003d\"VerificaSerialeCarta\"\u003e\u003ccommand expectedCode\u003d\"1\"
name\u003d\"verificaSerialeCarta\"\u003e\u003cparameter
name\u003d\"sessionKey\"\u003e\u003cstaticValue
value\u003d\"62373234616561312d386137662d396662332d656632372d36316334383139613
4326139\"/\u003e\u003c/parameter\u003e\u003cparameter
name\u003d\"serialeCarta\"\u003e\u003cstaticValue
value\u003d\"36303930303034323932363439303031\"/\u003e\u003c/parameter\u003e\u
003cparameter name\u003d\"commandType\"\u003e\u003cstaticValue
value\u003d\"0A\"/\u003e\u003c/parameter\u003e\u003cparameter
name\u003d\"commandCheck\"\u003e\u003cstaticValue
value\u003d\"41eaaa53720ce57b13cf222a527cdb4f6150d577f2d4c6134cd2f8ddf165de945
58251c573fd798f3f703011f0855e7b721a11540355af9ab5459a20f314201f52aa1e626dd3232
8e3fcf898af8318af48216d05fbdcef7d3fd6af6fc87f5d7f5bd7716df0e88179ee021605c9485
93062bde04b90f485fd021714795b3e6534\"/\u003e\u003c/parameter\u003e\u003c/comma
nd\u003e\u003c/unit\u003e\u003cunit failCode\u003d\"01\"
name\u003d\"VerificaPresenzaServizio\"\u003e\u003ccommand
expectedCode\u003d\"0\" name\u003d\"verificaCartella\"\u003e\u003cparameter
value\u003d\"62373234616561312d386137662d396662332d656632372d36316334383139613
name\u003d\"path\"\u003e\u003cstaticValue
value\u003d\"\"/\u003e\u003c/parameter\u003e\u003cparameter
Pag. 32 di 40
name\u003d\"FID\"\u003e\u003cstaticValue
value\u003d\"1F21\"/\u003e\u003c/parameter\u003e\u003cparameter
value\u003d\"09\"/\u003e\u003c/parameter\u003e\u003cparameter
value\u003d\"58cc5cbbdf4c60388c9ef4db04d732519023ee05281cff5468b5ff7b9770ca7ff
52000c92f648ed9a7f188cfd9b6b64af2396ce0ed3b7a57f6adb26651f2dca431fe639f43e5654
5f9ed4b7d8e65ff0ca2f39b531443b156adcd44fd86d1fd29d4f4249efa8af1a10ccae255c4e65
621aac2293a3369b71dbb2ff352d87d54e6\"
/\u003e\u003c/parameter\u003e\u003c/command\u003e\u003c/unit\u003e\u003cunit
name\u003d\"InstallazioneServizio\" failCode\u003d\"99\"\u003e\u003ccommand
expectedCode\u003d\"1\"
name\u003d\"creaAreaServizioAggiuntivo\"\u003e\u003cparameter
value\u003d\"62373234616561312d386137662d396662332d656632372d36316334383139613
name\u003d\"nomeCartella\"\u003e\u003cstaticValue
value\u003d\"44465f49534545\"/\u003e\u003c/parameter\u003e\u003cparameter
name\u003d\"AID\"\u003e\u003cstaticValue
value\u003d\"44465f49534545\"/\u003e\u003c/parameter\u003e\u003cparameter
name\u003d\"securityElement\"\u003e\u003cstaticValue
value\u003d\"FFFFFFFF03FFFFFFFF\"/\u003e\u003c/parameter\u003e\u003cparameter
name\u003d\"secureMessagingElement\"\u003e\u003cstaticValue
value\u003d\"791664fb88c471339822bf20c229b1e9bc13427160b9db912b65718ad8b8370b7
9923dd9ca1d499130171056cb9e8255417761dd6bd5e4e862ce422e5963d38e310db86cafea440
5c3249bef650edb856f2c73f145f7b899c40b434e5ef6ad1e859e639c62e19fd2d805550f3ceea
31b99645fedc2fd99df556cf7d02207a0af\"
/\u003e\u003c/parameter\u003e\u003c/command\u003e\u003ccommand
expectedCode\u003d\"1\" name\u003d\"creaFileBSO\"\u003e\u003cparameter
value\u003d\"62373234616561312d386137662d396662332d656632372d36316334383139613
name\u003d\"nomeFile\"\u003e\u003cstaticValue
value\u003d\"42534f5f495345455f41646d696e5075624b65794d6f64\"/\u003e\u003c/par
ameter\u003e\u003cparameter name\u003d\"path\"\u003e\u003cstaticValue
name\u003d\"ID\"\u003e\u003cstaticValue
name\u003d\"maxErrors\"\u003e\u003cstaticValue
name\u003d\"tipo\"\u003e\u003cstaticValue
name\u003d\"validityCounter\"\u003e\u003cstaticValue
name\u003d\"minimumLength\"\u003e\u003cstaticValue
name\u003d\"securityContent\"\u003e\u003cstaticValue
value\u003d\"00BEECADE0222DD3F908DC108CBA4CA880E5A18358053C338CF7EDB3A3634CF35
132742997948CBAC418BF86CE260D57A2CBBAD890CB7856A8BF56D68A3F38121D71582CEFE7A85
F186651731DA0C281777AFC91002E3DC23496A246C05DEC65F9F63ACE002FD242C0015A0158CBE
Pag. 33 di 40
324594D318E3F1DC38F2EA9C141A5944B1A53\"/\u003e\u003c/parameter\u003e\u003cpara
meter name\u003d\"securityElement\"\u003e\u003cstaticValue
value\u003d\"00FFFFFFFFFFFF\"/\u003e\u003c/parameter\u003e\u003cparameter
value\u003d\"34616e75f7203cfc62bdf8ffccaf641c4784049dee1df1316db06e4fad91ce6f7
4e509de59865d1e7fb2d1a037b00388fa0169e7b08eb0a3201dc1b2ebf7721ded45250ef36f3b0
c6bf43c353cc543b9e057c5faa840219a1e5d7c17e0dbe2883877aef3c76e700bacfbe02ca79c5
e3491da0169b8ce52df4ab191ab3a35f52c\"
expectedCode\u003d\"1\" name\u003d\"creaFileBSO\"\u003e\u003cparameter
value\u003d\"62373234616561312d386137662d396662332d656632372d36316334383139613
value\u003d\"42534f5f495345455f41646d696e5075624b6579457870\"/\u003e\u003c/par
ameter\u003e\u003cparameter name\u003d\"path\"\u003e\u003cstaticValue
name\u003d\"ID\"\u003e\u003cstaticValue
name\u003d\"maxErrors\"\u003e\u003cstaticValue
name\u003d\"validityCounter\"\u003e\u003cstaticValue
name\u003d\"minimumLength\"\u003e\u003cstaticValue
name\u003d\"securityContent\"\u003e\u003cstaticValue
value\u003d\"00FFFFFFFFFFFF\"/\u003e\u003c/parameter\u003e\u003cparameter
value\u003d\"6b97ce3cad5f34c2ccd085310a16734dd552150a079aff4a56f2e18557a103b81
c44ac16b8fad953fb4a73bb37f5807aa3aae63455886be43d084edd9d3d6576d5435637d04ee90
4c7f2f3953817ffcc09b4995363c11401dbbfc92f93b092f9f8db5d17f44c92e832731552141e1
53e9ca4d908ff613fb59a5cf4bc6cd4b792\"
expectedCode\u003d\"1\" name\u003d\"creaFile\"\u003e\u003cparameter
value\u003d\"62373234616561312d386137662d396662332d656632372d36316334383139613
value\u003d\"45465f495345455f494e464f5f4150504c\"/\u003e\u003c/parameter\u003e
\u003cparameter name\u003d\"path\"\u003e\u003cstaticValue
name\u003d\"size\"\u003e\u003cstaticValue
Pag. 34 di 40
name\u003d\"recordSize\"\u003e\u003cstaticValue
value\u003d\"0007FFFFFFFFFFFFFF\"/\u003e\u003c/parameter\u003e\u003cparameter
value\u003d\"ae44d602de49c35beee3c186264563c297ccc5fc5cc11bcb928d69f2f73f726fc
5d170132685e8cad998adea07f213a8c10ae92ed3e76fc21b06cf22f014a8baa9c5c3b7eeebf81
4d8e9ec787030694d5b62ae5b27c9eb2b181daf8d9fa1c71aa687e2c38cccfd1ab7746c5f6f815
a0751e5bdb3ece8e48c3f10be3ffbc71355\"
value\u003d\"62373234616561312d386137662d396662332d656632372d36316334383139613
value\u003d\"45465f495345455f48415348\"/\u003e\u003c/parameter\u003e\u003cpara
meter name\u003d\"path\"\u003e\u003cstaticValue
value\u003d\"8f50fa70a9a30c46e2872d22512f438364cbf1cc1bf756e6b723867bb204be450
25331a6a71e6a3459d59fa94a8c5a400c1280504df4b9a6d1744b30587fb15061c5f23744bac7a
93fdd01850f053177b804ab2ae4372c799855b44fd798bc5d1f15848ccaf4fec60f652f7077453
06c2e9da6702d2784dacb816e39f8348ed2\"
value\u003d\"62373234616561312d386137662d396662332d656632372d36316334383139613
value\u003d\"45465f495345455f5349474e4154555245\"/\u003e\u003c/parameter\u003e
\u003cparameter name\u003d\"path\"\u003e\u003cstaticValue
Pag. 35 di 40
value\u003d\"509c242ed4ed11a64e713c579d8aa8543cdb0ebd222b84ba7186fed685fffa4f1
12d7f8cf4244f1ad140ecbcd0a6b7cfbe9e9750959baa7299267ea987ea1fb76b264ab3c4ca16c
52c03804ce3d92c233f1e2a27de21112b0375c81bfb7e7601eae455d146bdf8e6d19ec483cd89f
f9326c357462b0d1caaaa6a8ef7a1950de1\"
/\u003e\u003c/parameter\u003e\u003c/command\u003e\u003c/unit\u003e\u003c/actio
n\u003e\u003c/service\u003e","esito":"00","verifycheck":"GcuGJrqUYa4OK3WT713PW
TCcFmpsjN9B6Itt+0MDWrpzgaXpI9oUDMp9F+7mRZM2+ufW9KGyuzxia7w4emr9Ap5pXl9cXhNfFEY
L0n3QwPqqtLwX+oWqCIC0KXfksS7cYlYqq3irLSINRlawoD5tTRPvHDNDitbS8ABEl9tberA\u003d
","sessionKey":"b724aea1-8a7f-9fb3-ef27-61c4819a42a9"}
Pag. 36 di 40
4.3
Notify Esito
SIRGESA mette a disposizione una risorsa web, in architettura REST su protocollo https, a cui il client
(TOTEM) comunica l'esito dell'esecuzione del runtimeServiceModel sulla carta e da cui recupera le
informazioni necessarie a gestire il colloquio di gestione del servzio aggiuntivo con il sistema SGSS.
https://<nome_server_pre-produzione>/sirgesa/rest/notifySirgesa
https://<nome_server_produzione>/sirgesa/rest/notifySirgesa
- attraverso il parametro sessionkey, che non è altro che una chiave a tempo*, il sistema verifica la
possibilità di eseguire la registrazione dell'esito.
- La risposta SIRGESA alla richiesta contiene un attributo verifycheck che consente al client di
verificare che i restanti attributi forniti sono generati da SIRGESA e non sono stati alterati durante il
traporto.
chiamata:
PARAMETRI
DESCRIZIONE
sessionkey
Identificativo della richiesta di autorizzazione* inviata dal client
esito
Esito della operazione di esecuzione del runtime Service Model:
“00” : servizio installato correttamente
“01”: servizio già installato
“94”: colloquio sirgesa non validato
“96” : seriale della carta non conforme alla richiesta iniziale
“99” : errore nell’inizializzazione del servizio sulla carta
secondi dal timestamp dichiarato nella chiamata e associato al sessionkey.
RESPONSE
SirgesaResponseNotify
DESCRIZIONE
Rappresentazione JSON dell’oggetto SirgesaResponseNotify
4.3.1 Sirgesa Response Notify
La struttura dell’oggetto SirgesaResponseNotify viene di seguito rappresentata:
ATTRIBUTI
nomeServizioAggiuntivo
transId
TIPO
DESCRIZIONE
String
Nome del servizio aggiuntivo come censito su SIRGESA
String
Identificativo di transazione per SGSS
Pag. 37 di 40
serialNumber
Esito
verifycheck4SGSS
sessionkey
esitoNotifica
urlRitorno
verifycheck
String
Numero seriale della carta
String
Esito della operazione di inizializzazione del servizio sulla carta:
“00” : servizio sulla carta inizializzato correttamente
“01” : servizio sulla carta già presente
“93” : operazione interrotta dall'utente (Annulla sull'applet)
“94” : colloquio sirgesa non validato
“96” : seriale carta non conforme alla richiesta iniziale
“99” : errore nell’inizializzazione del servizio sulla carta
String
Digest secondo l’algoritmo SHA-256 della concatenazione dei
valori presenti nei parametri precedenti, criptato con la chiave
privata di SIRGESA (SIRGESA_SK) e codificato in Base64 (**)
String
Identificativo della richiesta di inizializzazione inviata da SGSS a
SIRGESA e da questo verificata. La sessionkey equivale ad una
chiave una-tantum a tempo (100 secondi) tramite la quale il
sistema SIRGESA re-interrogato possa gestire in ogni momento i
parametri della richiesta e fornire le informazioni necessarie alla
applet.
String
Esito della notifica:
“true” : notifica completata correttamente
“false” : errore in fase di notifica
String
Risorsa web SGSS a cui il client ritorna l'esito dell'azione
terminata l'esecuzione della stessa sulla carta (eventualmente
vuoto)
String
Digest secondo l’algoritmo SHA-256 della concatenazione dei
valori presenti nei parametri precedenti, criptato con la chiave
privata di SIRGESA (SIRGESA_SK) e codificato in Base64 (***)
(**) Encode(Sign(Hash(nomeServizioAggiuntivo+transId+serialNumber+esito, SHA-256), SIRGESA_SK),
BASE64)
(***)
Encode(Sign(Hash(nomeServizioAggiuntivo+transId+serialNumber+esito+verifycheck4SGSS+sessionkey
+esitoNotifica+urlRitorno, SHA-256), SIRGESA_SK), BASE64)
Pag. 38 di 40
4.4
Validate
SIRGESA mette a disposizione una risorsa web, in architettura REST su protocollo https, a cui il client
(TOTEM), per ciascun comando presente nel modello di esecuzione della azione richiesta, richiede la
validazione del comando da eseguire, della sessionkey ad esso collegata e la criptazione del challenge
ricevuto dalla carta per attivare una external authentication.
http://<nome_server_pre-produzione>/sirgesa/rest/validate
https://<nome_server_produzione>/sirgesa/rest/validate
- Attraverso il parametro commandCheck SIRGESA è in grado di autenticare come proprio il
comando ed i parametri che verranno eseguiti sulla carta dopo aver attivato la external
authentication.
chiamata:
PARAMETRI
DESCRIZIONE
sessionkey
Identificativo della richiesta di autorizzazione* inviata dal client
parameters
Parametri del comando da validare concatenati secondo l'ordine
espresso nel runtimeServiceModel ed espressi in forma esadecimale.
serialeCarta
Numero seriale della carta da validare
commandType
Identificativo del comando da validare espresso in forma esadecimale
commandCheck
Sign(
Hash(
sessionkey+parameters+serialeCarta+commandType,
SHA-256),
SIRGESA_SK)
opCommand
input
Rappresenta lo scopo per il quale si richiede l'attivazione del modulo
di criptazione regionale. Può assumere i valori:
authdf2: consente di cripatare un challenge generato dalla carta e
fornito sul parametro input per attivare un external authentication
sulla carta.
decrdf2: consente di criptare il dato fornito in input per la
generazione di un comando criptato da utilizzare durante uan
sessione in secure messaging.
Dato da criptare espresso in forma esadecimale
secondi dal timestamp dichiarato nella chiamata iniziale.
Pag. 39 di 40
RESPONSE
DESCRIZIONE
SirgesaResponseValidate
Rappresentazione JSON dell’oggetto SirgesaResponseValidate
4.4.1 Sirgesa Response Validate
La struttura dell’oggetto SirgesaResponseValidate viene di seguito rappresentata:
ATTRIBUTI
Esito
response
TIPO
DESCRIZIONE
String
Esito della operazione di validazione:
“00” : validazione eseguita correttamente
“89” : modulo di criptazione regionale non raggiungibile
“94” : comando sirgesa non validato
“96” : seriale carta non conforme
“98” : richiesta non conforme
String
Risposta ottenuta dal modulo di criptazione regionale.
Il formato dell'attributo response di tipo stringa rispetta il seguente formalismo:
response := <opCommand>out:<data>
<data> := *<messaggio di errore>|<crypted input>
Pag. 40 di 40

Colloquio TOTEM-SIRGESA - OSCAT

Transcript

Documenti analoghi

MISIAD – TOTem

DESCRIZIONE: Letto matrimoniale in multistrato di betulla. Il

Design - Alisei

si diffonde il totem della pace

Letto - soppalco in multistrato di betulla. La base del letto è

credito di imposta investimento al sud. agevolabile anche il totem

Totem - Vetroelite

CONTRATTO DI ASSISTENZA TECNICA

EVENTO NAZIONALE OTTOBRE: OSCILLOCOCCINUM

totem digital signage