Colloquio TOTEM-SIRGESA

Transcript

1 Colloquio TOTEM-SIRGESA Specifiche Tecniche Versione /03/2013 RTI Funzione Nome Redazione Capo progetto RTI (Aruba) Esperto di dominio (Actalis) Capo progetto CMS (Engineering) Esperto architetture (Engineering) Umberto Ferrara, Riccardo Casiraghi Massimo Agostiniani Fabio Bennati Approvazione Capo progetto RTI Regione Toscana Funzione Nome Verifica Approvazione Nome file: CSE-ServiziAggiuntivi_SIRGESA_TOTEM_ST_1-0.odt Pag. 1 di 40

2 Indice generale AGGIORNAMENTI DELLE VERSIONI...3 1GENERALITÀ Scopo Riferimenti Definizioni e abbreviazioni Allegati...4 2PREREQUISITI/VINCOLI...5 3SCENARIO D'USO Caso d'uso F001P1UC1: Installazione Servizio Aggiuntivo Caso d'uso F001P1UC1-1: Esecuzione macro comando SPECIFICHE INTERFACCIA SIRGESA-TOTEM Autorizza Richiesta Sirgesa Response AuthReq Recupera Modello Sirgesa Response Model Schema di validazione del RuntimeServiceModel Macro Comandi Crea Area Servizio Aggiuntivo Elimina Area Servizio Aggiuntivo Crea Cartella Elimina Cartella Crea File Crea File BSO Elimina File Verifica File Verifica Cartella Verifica Seriale Carta Esempio Risposta REST Notify Esito Sirgesa Response Notify Validate Sirgesa Response Validate...39 Pag. 2 di 40

3 AGGIORNAMENTI DELLE VERSIONI Versione Data Motivo Modifiche 0.9 draft a 28/01/13 Emissione /03/13 Gestione nuovo parametro parameters + Correzione Aggiunta riga alle tabelle descrittive dei comandi nei sottoparagrafi del Struttura securityelement del comando CreaFileBSO - paragrafo Pag. 3 di 40

4 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 Functional Specification 1.1.6_ pdf 1.3 Definizioni e abbreviazioni RT SIRGESA SGSS CNS TOTEM APDU ISO JSON REST Regione Toscana SIstema Regionale di GEstione dei Servizi Aggiuntivi Sistema di Gestione dello Specifico Servizio Carta Nazionale dei Servizi Chiosco o punto informativo, è principalmente un computer disponibile all'uso pubblico Application Protocol Data Unit Identification cards - Integrated circuit cards - Organization, security and commands for interchange JavaScript Object Notation Representational state transfer 1.4 Allegati N.A. Pag. 4 di 40

5 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

6 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. Precondizioni: Il client (TOTEM) ha connettività internet Il client ha ricevuto la chiave pubblica di 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. Postcondizioni: Il TOTEM trova installato sulla carta CNS regionale, in esso inserita, il servizio aggiuntivo gestito da SGSS 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

7 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. 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 un esito negativo all'autorizzazione della richiesta ed interrompe il processo di gestione del servizio sulla carta dando opportuna notifica al possessore della carta; 4. Il caso d uso termina. Flussi alternativi: Se la richiesta di Recupera Modello inviata dal TOTEM a SIRGESA non ha esito positivo. 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 un esito negativo in risposta alla richiesta effettuata; 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 interrompe il processo di gestione del servizio sulla carta dando opportuna notifica al possessore della carta; 7. Il caso d uso termina. Flussi alternativi: Se la verifica di autenticità della risposta ricevuta da SIRGESA all'invocazione della risorsa Recupera Modello non ha esito positivo. 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 Pag. 7 di 40

8 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 non avendo verificata l'autenticità della risposta trasmette a SIRGESA (Notify Esito) l'esito negativo (94) e la sessionkey autorizzativa; 7. SIRGESA comunica al TOTEM l'avvenuta registrazione dell'esito; 8. Il TOTEM interrompe il processo di gestione del servizio sulla carta dando opportuna notifica al possessore della carta; 9. Il caso d uso termina. Flussi alternativi: Se il modello di esecuzione del servizio non è conforme allo schema previsto. 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 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 possessore della carta; 10. Il caso d uso termina. 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 ). 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 Pag. 8 di 40

9 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 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; 11. Il TOTEM interrompe il processo di gestione del servizio sulla carta dando opportuna notifica al possessore della carta; 12. Il caso d uso termina. Flussi alternativi: Se l'unità di processo di verifica assenza servizio ritorna esito negativo ( 01 ). 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 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 è corredata di un valore denominato verifycheck che rappresenta l'hash della risposta firmato con la chiave privata di SIRGESA; 11. Il caso d'uso termina. Pag. 9 di 40

10 Flussi alternativi: Se la comunicazione dell'esito dal TOTEM a SIRGESA (NotifyEsito) non si completa con esito positivo. 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 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; 10. Il TOTEM interrompe il processo di gestione del servizio sulla carta dando opportuna notifica al possessore della carta; 11. Il caso d uso termina. 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

11 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; 10. Il caso d uso termina. Flussi alternativi: Se la verifica della coerenza del seriale della carta ha esito negativo. 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 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; 4. Il caso d uso termina. Flussi alternativi: Se la richiesta di Validate inviata dal TOTEM a SIRGESA non ha esito positivo. 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 un esito negativo; 6. 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; 7. Il caso d uso termina. Pag. 11 di 40

12 Flussi alternativi: Se l'esito dell'invio dal TOTEM alla carta di un comando APDU non ha l'esito previsto. 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 registra un esito imprevisto come risultato dell'esecuzione di un comando APDU e quindi chiude la sessione di external authentication sulla carta; 9. 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; 10. Il caso d uso termina. Pag. 12 di 40

13 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 Ambiente di produzione 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 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 Rappresentazione JSON dell oggetto SirgesaResponseAuthReq Pag. 13 di 40

14 4.1.1 Sirgesa Response AuthReq La struttura dell oggetto SirgesaResponseAuthReq viene di seguito rappresentata: ATTRIBUTI TIPO 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 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(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). Le url da richiamare sono: Ambiente di pre-produzione Ambiente di produzione Il sistema SIRGESA sulle indicate url: - 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

15 PARAMETRI 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. Di seguito riportiamo le caratteristiche della risposta: RESPONSE SirgesaResponseModel Rappresentazione JSON dell oggetto SirgesaResponseModel Sirgesa Response Model La struttura dell oggetto SirgesaResponseModel viene di seguito rappresentata: ATTRIBUTI TIPO 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 99 : errore generico verifycheck 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(sessionkey+runtimeServiceModel+esito, SHA-256), SIRGESA_SK),BASE64) 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=" <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

16 <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="name" type="xs:string" use="required"/> <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="name" type="xs:string" use="required"/> <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:attribute name="name" type="xs:string" use="required"/> </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

17 <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> Macro Comandi Di seguito l'elenco dei macro comandi gestiti nel modello del generico Servizio Aggiuntivo da SIRGESA. COMMANDTYPE 01x 02x 03x 04x 05x 06x 07x 08x 09x 0Ax MACRO COMANDO Crea Area Servizio Aggiuntivo Elimina Area Servizio Aggiuntivo Crea Cartella Elimina Cartella Crea File Crea File BSO Elimina File Verifica File Verifica Cartella Verifica Seriale Carta Pag. 17 di 40

18 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 sessionkey nomecartella FID AID securityelement Identificativo della richiesta di autorizzazione inviata dal client (TOTEM) a SIRGESA e da questo verificata. 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. Access Condition 1-2 UPDATE 3 APPEND 4 DEACTIVATE 5 ACTIVATE 6 DELETE 7 ADMIN 8 CREATE 9 - ciascuno indicante la specifica condition secondo il seguente formalismo: Byte Value 00x 01x 1Fx FFx ALWAYS BSO ID NEVER Condition Pag. 18 di 40

19 PARAMETRI securemessaging Element Modalità di comunicazione sicura da attivare nell esecuzione delle operazioni sull oggetto; nel 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 Condition secondo la tabella seguente: Byte N. SM Condition 1,2-3 ENC_UPDATE/APPEND 4 SIG_UPDATE/APPEND ENC_ADMIN 14 SIG_ADMIN 15 ENC_CREATE 16 SIG_CREATE ciascuno indicante la specifica condition secondo il seguente formalismo: Byte Value 00x 01x 1Fx FFx ALWAYS BSO ID NEVER Condition serialecarta commandtype commandcheck parameters 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 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) Concatenazione dei seguenti parametri: nomecartella+fid+aid+securityelement+securemessagingelement Pag. 19 di 40

20 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 sessionkey nomecartella FID serialecarta commandtype commandcheck parameters Identificativo della richiesta di autorizzazione inviata dal client (TOTEM) a SIRGESA e da questo verificata. 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. Numero seriale della carta su cui eseguire il comando Identificativo del comando richiesto. Valorizzato con la costante 02x 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) Concatenazione dei seguenti parametri: nomecartella+fid+serialecarta Pag. 20 di 40

21 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 sessionkey nomecartella path FID AID securityelement Identificativo della richiesta di autorizzazione inviata dal client (TOTEM) a SIRGESA e da questo verificata. Nome della cartella da creare Path della cartella rispetto alla DF2 della carta Identificativo della cartella come indicato nelle specifiche tecniche della struttura del servizio aggiuntivo, espresso tramite due byte. Application id della cartella espresso al messimo tramite 16 byte. Modalità di sicurezza ida attivare sulla cartella. Viene rappresentato tramite una sequenza di nove bytes, posizionalmente correlati a specifiche Access Condition secondo la tabella seguente: Byte N. Access Condition 1-2 UPDATE 3 APPEND 4 DEACTIVATE 5 ACTIVATE 6 DELETE 7 ADMIN 8 CREATE 9 - ciascuno indicante la specifica condition secondo il seguente formalismo: Byte Value 00x 01x 1Fx FFx ALWAYS BSO ID NEVER Condition Pag. 21 di 40

22 PARAMETRI securemessaging Element Modalità di comunicazione sicura da attivare nell esecuzione delle operazioni sull oggetto; nel 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 Condition secondo la tabella seguente: Byte N. SM Condition 1,2-3 ENC_UPDATE/APPEND 4 SIG_UPDATE/APPEND ENC_ADMIN 14 SIG_ADMIN 15 ENC_CREATE 16 SIG_CREATE ciascuno indicante la specifica condition secondo il seguente formalismo: Byte Value 00x 01x 1Fx FFx ALWAYS BSO ID NEVER Condition serialecarta commandtype commandcheck parameters Numero seriale della carta su cui eseguire il comando Identificativo del comando richiesto. Valorizzato con la costante 03x 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+path+fid+aid+securityelement+securemessagingelement+serialecarta+ commandtype, SHA-256), SIRGESA_SK) Concatenazione dei seguenti parametri: nomecartella+path+fid+aid+securityelement+securemessagingelement Pag. 22 di 40

23 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 sessionkey nomecartella path FID serialecarta commandtype commandcheck parameters Identificativo della richiesta di autorizzazione inviata dal client (TOTEM) a SIRGESA e da questo verificata. Nome della cartella da eliminare Path della cartella rispetto alla DF2 della carta Identificativo della cartella come comunicato al CNIPA e quindi associato allo specifico servizio espresso tramite due byte. Numero seriale della carta su cui eseguire il comando Identificativo del comando richiesto. Valorizzato con la costante 04x 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+path+fid+serialecarta+commandtype, SHA-256), SIRGESA_SK) Concatenazione dei seguenti parametri: nomecartella+path+fid Pag. 23 di 40

24 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 sono di tipo byte o array di byte espressi con il tipo hexbinary. PARAMETRI sessionkey nomefile path FID size tipo Identificativo della richiesta di autorizzazione inviata dal client (TOTEM) a SIRGESA e da questo verificata. Nome del file elementare da creare Path della cartella all interno della quale creare il file rispetto alla DF2 della carta Identificativo del file come indicato nelle specifiche tecniche della struttura del servizio aggiuntivo, espresso tramite due byte. Dimensione massima del file Tipologia del file da creare espressa secondo la tabella seguente: Valore 01x 02x 05x 06x TRASPARENT FIXED VARIABLE CYCLIC Tipologia recordsize securityelement 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 bytes, posizionalmente correlati a specifiche Access Condition secondo la tabella seguente: Byte N. Access Condition 1 READ 2 UPDATE 3 APPEND 4 DEACTIVATE 5 ACTIVATE 6 DELETE 7 ADMIN 8,9 - ciascuno indicante la specifica condition secondo il seguente formalismo: Byte Value 00x 01x 1Fx FFx ALWAYS BSO ID NEVER Condition Pag. 24 di 40

25 PARAMETRI securemessaging Element Modalità di comunicazione sicura da attivare nell esecuzione delle operazioni sull oggetto; nel 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 Condition secondo la tabella seguente: Byte N. SM Condition 1 ENC_READ_OUT 2 SIG_READ_OUT 3 ENC_UPDATE 4 SIG_UPDATE 5 ENC_APPEND 6 SIG_APPEND ENC_ADMIN 14 SIG_ADMIN ENC_READ_IN 24 SIG_READ_IN ciascuno indicante la specifica condition secondo il seguente formalismo: Byte Value 00x 01x 1Fx FFx ALWAYS BSO ID NEVER Condition serialecarta commandtype commandcheck parameters Numero seriale della carta su cui eseguire il comando Identificativo del comando richiesto. Valorizzato con la costante 05x 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+nomefile+path+fid+size+tipo+recordsize+securityelement+securemessagingelement+ serialecarta+commandtype, SHA-256), SIRGESA_SK) Concatenazione dei seguenti parametri: nomefile+path+fid+size+tipo+recordsize+securityelement+securemessagingelement Pag. 25 di 40

26 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 sono di tipo byte o array di byte espressi con il tipo hexbinary. PARAMETRI sessionkey nomefile path ID maxerrors tipo Identificativo della richiesta di autorizzazione inviata dal client (TOTEM) a SIRGESA e da questo verificata. 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 x x x x x x x x x 00027Fx 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 validitycounter minimumlength securitycontent 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

27 PARAMETRI securityelement Modalità di sicurezza ida attivare sul file. Viene rappresentato tramite una sequenza di sette byte, posizionalmente correlati a specifiche Access Condition secondo la tabella seguente: Byte N. Access Condition 1 USE 2 CHANGE 3 UNBLOCK 4,5,6-7 GENKEYPAIR 8,9 - ciascuno indicante la specifica condition secondo il seguente formalismo: Byte Value 00x 01x 1Fx FFx ALWAYS BSO ID NEVER Condition securemessaging Element Modalità di comunicazione sicura da attivare nell esecuzione delle operazioni sull oggetto; nel caso non debba essere attivata l array di byte avrà lunghezza 0. Viene rappresentato tramite una sequenza di 8 byte, posizionalmente correlati a specifiche SM Condition secondo la tabella seguente: Byte N. SM Condition 1 ENC_USE_IN 2 SIG_USE_IN 3 ENC_CHANGE 4 SIG_CHANGE 5 ENC_UNBLOCK 6 SIG_UNBLOCK 7 ENC_USE_OUT 8 SIG_USE_OUT ciascuno indicante la specifica condition secondo il seguente formalismo: Byte Value 00x 01x 1Fx FFx ALWAYS BSO ID NEVER Condition serialecarta commandtype commandcheck Numero seriale della carta su cui eseguire il comando Identificativo del comando richiesto. Valorizzato con la costante 06x 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+nomefile+path+id+maxerrors+tipo+validitycounter+minimumlength+securityelement+ securemessagingelement+serialecarta+commandtype, SHA-256), SIRGESA_SK) Pag. 27 di 40

28 PARAMETRI parameters Concatenazione dei seguenti parametri: nomefile+path+id+maxerrors+tipo+validitycounter+minimumlength+securityelement+ securemessagingelement Pag. 28 di 40

29 Elimina File Il comando consente l eliminazione 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 nomefile path FID serialecarta commandtype commandcheck parameters Identificativo della richiesta di autorizzazione inviata dal client (TOTEM) a SIRGESA e da questo verificata. 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. Numero seriale della carta su cui eseguire il comando Identificativo del comando richiesto. Valorizzato con la costante 07x 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+nomefile+path+fid+serialecarta+commandtype, SHA-256), SIRGESA_SK) Concatenazione dei seguenti parametri: nomefile+path+fid Pag. 29 di 40