Introduzione Sistemi ad agenti 1

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Introduzione Sistemi ad agenti 1"

Transcript

1 Introduzione Sistemi ad agenti 1 1 Introduzione Sistemi ad agenti Problemi di sicurezza 7 2 FIPA Modello di riferimento Agent Directory Facilitator (DF) Agent Management System (AMS) Message Transport Service (MTS) Agent Platform (AP) Scambio di messaggi Sicurezza 16 3 JADE Piattaforma Agenti Ciclo di vita Comportamenti Messaggi Remote Monitoring Agent Sicurezza 27 4 Requisiti di sicurezza Integrità Riservatezza Responsabilità Disponibilità Anonimato 32 5 Minacce alla sicurezza Agente contro piattaforma Unauthorized access Masquerading Denial of service Agente contro agente Unauthorized access Masquerading Denial of service Repudiation Piattaforma contro agente Masquerading 37

2 Introduzione Sistemi ad agenti Denial of service Eavesdropping Alteration Altri contro sistema Unauthorized access Masquerading Denial of service Copy and replay 39 6 Contromisure convenzionali Crittografia Cifrari a sostituzione e trasposizione Crittografia a chiave segreta DES Crittografia a chiave pubblica RSA Sintesi di messaggi Firme digitali Certificati a chiave pubblica Secure Sockets Layer Negoziazione Autenticazione Invio di dati cifrati 47 7 Contromisure nei sistemi ad agenti Proteggere la piattaforma Software-based fault isolation Safe code interpretation Signed code Attribute certificates State appraisal Path history Proof carrying code Proteggere gli agenti Partial result encapsulation Mutual itinerary recording Replication and voting Execution tracing Environmental key generation Encrypted functions Obfuscated code 58 8 Implementazioni esistenti Telescript Protezione degli oggetti durante l esecuzione Sicurezza e protezione dei processi 60

3 Introduzione Sistemi ad agenti Autorità Riferimenti protetti Permessi Spostamenti e incontri Classi mix-in Protezione del sistema Sicurezza di rete Politiche di regione Canali sicuri Aglet Modello di sicurezza Identità e principal Agenti Contesti Domini Politiche di sicurezza Mobilità degli agenti Accesso a risorse locali Linguaggio di autorizzazione Gruppi Privilegi Politiche dei contesti Preferenze degli agenti Ara Risorse e principal Autenticazione Passaporto Host trace Creazione e migrazione Regioni Autorizzazione Concessioni Funzioni di ammissione 80 9 Un modello di sicurezza per JADE Il modello code-centric Il modello user-centric Principal Risorse Permessi Amministrazione Ereditarietà Autorità di certificazione Autenticazione Autenticazione degli utenti Autenticazione degli agenti 87

4 Introduzione Sistemi ad agenti Autorizzazione Dominio di protezione Certificati di autorizzazione Delega Modalità di delega Certificati di delega Politiche di sicurezza Canali sicuri Implementazione di riferimento JADEPrincipal JADEPermission JADEPermissionCollection AgentPermission ContainerPermission BePermission PermissionCertificate PermissionDescr Subject CheckAction SubjectDomainCombiner Authority PlatformAuthority ContainerAuthority PolicyFile FileCipher SSL RMISSLServerSocketFactory RMISSLClientSocketFactory JADESecurityException AuthenticationException AuthorizationException Modifiche alla piattaforma Boot AgentManager AgentContainerImpl MainContainerImpl AgentDescriptor e ContainerTable Modifiche alle ontologie JADEAgentManagementOntology AMSRegister, AMSDeregister, AMSModify Modifiche agli agenti Agent 118

5 Introduzione Sistemi ad agenti AMS RMA Conclusioni Sviluppi futuri Ringraziamenti Riferimenti 123

6 Introduzione Sistemi ad agenti 6 1 Introduzione Questa tesi verte sui problemi di sicurezza nei sistemi ad agenti. In particolare viene preso in considerazione JADE, un ambiente per lo sviluppo di applicazioni ad agenti sviluppato dallo CSELT in collaborazione con l Università degli Studi di Parma. Dopo una descrizione sommaria di JADE e delle specifiche FIPA in base alle quali è stato progettato, saranno analizzati nel dettaglio tutti i problemi di sicurezza che si presentano in un sistema ad agenti come JADE e le possibili contromisure da adottare, prendendo in considerazione anche esempi di implementazioni già esistenti. Infine sarà presentato un modello di sicurezza progettato per JADE ed una implementazione di riferimento, anch essa conforme alle specifiche FIPA. 1.1 Sistemi ad agenti Prima di procedere nell analisi del problema bisogna rispondere ad una domanda di fondo: che cos è un agente software? Cosa sia in realtà un agente e come esso differisca da un normale programma è stato per lunghi anni argomento di dibattito. Nonostante il dibattito sia tutt altro che esaurito, sempre più spesso vengono proposte applicazioni dove gli agenti sono labilmente definiti come programmi che assistono le persone e agiscono per conto di queste. Dal punto di vista di un utente finale è quindi possibile definire un agente come un programma che lo aiuta nelle sue attività e agisce in sua vece. Gli agenti funzionano permettendo alle persone di delegare parte del proprio lavoro. Anche se questa definizione potrebbe essere sostanzialmente corretta, tuttavia non tocca la questione di fondo. Gli agenti si presentano sotto svariate forme ed in molte configurazioni. Si possono trovare in sistemi operativi per computer, software di rete, basi di dati. Quali sono le proprietà condivise da questi sistemi, che costituiscono l essenza di un agente? Anche se questa non è la sede per esaminare le caratteristiche dei numerosi sistemi ad agenti resi disponibili al pubblico da numerosi laboratori di ricerca, tuttavia si può notare che una proprietà condivisa da tutti gli agenti è il fatto che essi vivono in qualche ambiente. Essi hanno l abilità di interagire con il proprio ambiente di esecuzione e di funzionare in maniera asincrona ed autonoma su di esso. In generale a nessuno viene

7 Introduzione Problemi di sicurezza 7 richiesto di consegnare informazioni all agente o di consumare qualche sua uscita. L agente semplicemente agisce in maniera continua per raggiungere i propri obbiettivi. In sostanza possiamo definire un agente come un oggetto software che: è situato all interno di qualche ambiente di esecuzione; possiede le seguenti proprietà obbligatorie: o reattivo percepisce i cambiamenti nell ambiente e agisce in accordo a questi cambiamenti; o autonomo ha il controllo delle proprie azioni; o orientato ad un obbiettivo è proattivo; o continuo nel tempo agisce in maniera continua; e può possedere una o più delle seguenti proprietà ortogonali: o comunicativo può comunicare con altri agenti; o mobile può spostarsi da un sito ad un altro; o apprendimento si adatta in base alle esperienze precedenti; o credibile gode della fiducia dell utente finale. La mobilità è una proprietà ortogonale degli agenti, quindi non tutti gli agenti devono necessariamente essere mobili; un agente può semplicemente risiedere in un posto e comunicare con i suoi vicini attraverso gli strumenti convenzionali, come varie forme di chiamata a procedure remote o di scambio di messaggi. Gli agenti che non si muovono o che non possono muoversi sono definiti stazionari. In contrasto, un agente mobile non è legato al sistema dove comincia la propria esecuzione ma è libero di spostarsi tra i nodi che compongono la rete. Dopo essere stato creato in un ambiente di esecuzione, può trasportare il suo stato e il suo codice in un altro ambiente di esecuzione nella rete, dove riprende a funzionare. 1.2 Problemi di sicurezza Durante i primi decenni della loro esistena, le reti di computer sono state usate principalmente dai ricercatori universitari per inviare messaggi elettronici e dai dipendenti di aziende per condividere stampanti. In questi ambiti la sicurezza non aveva ragione di esistere. Invece adesso, con milioni di comuni cittadini che utilizzano le reti per operazioni bancarie, commerciali e fiscali questo problema è apparso all orizzonte come potenzialmente collettivo.

8 Introduzione Problemi di sicurezza 8 La sicurezza tradizionalmente, nella forma più semplice, si occupa di assicurare che nessuno possa leggere o modificare i messaggi destinati ad altri. Inoltre si occupa di persone che cercano di accedere a servizi remoti che non sono autorizzate ad usare, di verificare che i messaggi siano spediti realmente dai mittenti indicati o di problemi come l intercettazione di messaggi autografi e la loro riproduzione, e di persone che cercano di negare di aver spedito tali messaggi. I sistemi ad agenti in genere devono offrire almeno le stesse garanzie di sicurezza offerte dai sistemi tradizionali, basati sul modello client-server; i requisiti di solito comprendono qualche forma di integrità, riservatezza, responsabilità, disponibilità, anonimato. Inoltre nei sistemi ad agenti, ed in modo particolare nei sistemi ad agenti mobili, si presentano ulteriori problemi legati alla natura maggiormente distribuita del modello computazionale adottato.

9 FIPA Modello di riferimento 9 2 FIPA La Foundation for Intelligent Physical Agents (FIPA) è una organizzazione internazionale che si dedica alla promozione dei sistemi ad agenti intelligenti attraverso lo sviluppo di specifiche aperte, per il supporto della interoperabilità tra agenti e tra applicazioni basate sugli agenti. Questo avviene attraverso una collaborazione aperta tra le organizzazioni che ne fanno parte, che sono aziende o università attive nell area degli agenti. Dal 1997 FIPA ha rilasciato una serie di specifiche per sistemi ad agenti che hanno come loro obbiettivo i sistemi ad agenti interoperabili. Questi lavori comprendono specifiche per la realizzazione di infrastrutture ed applicazioni orientate agli agenti. Le specifiche per le infrastrutture includono un linguaggio di comunicazione tra agenti, servizi per agenti, e prevedono la gestione delle ontologie. Viene anche specificato un insieme di domini applicativi, come assistenza personale ai viaggi, gestione di reti, commercio elettronico, distribuzione di audiovisivi. Al cuore del modello FIPA c è la comunicazione tra agenti; in particolare viene descritto come questi possono scambiare tra loro messaggi semanticamente significativi allo scopo di completare le attività previste dall applicazione. 2.1 Modello di riferimento Il modello di riferimento per i sistemi ad agenti consiste di un certo numero di componenti logiche, ognuna delle quali rappresenta un insieme di funzionalità (che nelle implementazioni reali possono essere raggruppate in modi diversi). Le entità contenute nel modello di riferimento sono insiemi logici di capacità (cioè servizi) e non implicano alcuna configurazione fisica. Inoltre, i dettagli implementativi delle singole piattaforme e degli agenti sono lasciati alla libera scelta di progetto degli sviluppatori di sistemi ad agenti.

10 FIPA Modello di riferimento 10 Software Agent Platform Agent Agent Management System Directory Facilitator Message Transport System Message Transport System Agent Platform Figura 1 Modello FIPA Agent È il protagonista principale di ogni piattaforma ad agenti e combina le funzionalità di uno o più servizi in un modello di esecuzione unico e integrato che può comprendere interazioni con programmi esterni, utenti umani e strumenti di comunicazione. Un agente può svolgere anche il compito di mediatore per gli accessi software a risorse condivise. Ad ogni agente deve essere associato almeno un responsabile, per esempio in base all appartenenza ad organizzazioni o all utente che lo esegue. Inoltre ogni agente riceve un identificatore di agente (AID), che lo contrassegna in modo tale da poter essere riconosciuto senza ambiguità all interno del suo dominio, e può registrare un insieme di indirizzi di trasporto, presso i quali può essere contattato. Gli agenti, intesi come processi software reali, hanno un ciclo di vita preciso, che deve essere gestito dalla piattaforma. Nelle specifiche FIPA sono descritti precisamente gli stati in cui si può trovare un agente durante la sua esistenza e quali transizioni tra gli stati sono possibili.

11 FIPA Modello di riferimento 11 Waiting Suspended Wait Resume Wake Up Suspend Active Destroy Quit Unknown Move Invoke Execute Create Transit Initiated Figura 2 Ciclo di vita degli agenti In particolare le transizioni possibili tra gli stati sono: Create creazione o installazione di un nuovo agente; Invoke invocazione di un nuovo agente; Destroy (1) terminazione forzata di un agente; non può essere ignorata dall agente; Quit terminazione normale di un agente; può essere ignorata dall agente; Suspend (1) l agente viene messo in uno stato di sospensione; Resume (1) riattivazione dell agente dopo una sospensione; Wait (2) l agente si pone in attesa di un evento; Wake Up (2) l agente riprende l esecuzione dopo una attesa; Move (2) l agente viene messo in uno stato transitorio durante uno spostamento; Execute (1) riattivazione dell agente dopo uno spostamento. Le transizioni indicate con (1) possono essere invocate solo dall AMS mentre quelle indicate con (2) possono essere invocate solo dall agente.

12 FIPA Modello di riferimento Directory Facilitator (DF) Il Directory Facilitator (DF) è il componente della piattaforma, obbligatorio, che fornisce servizi di pagine gialle agli agenti. Presso il DF gli agenti possono registrare i propri servizi o determinare quali servizi sono offerti dagli altri agenti. All interno di una stessa piattaforma possono coesistere e federarsi numerosi DF Agent Management System (AMS) È un componente obbligatorio: su ogni piattaforma deve essere presente un solo AMS, che esercita un controllo di supervisione su tutti gli accessi alla piattaforma. L AMS offre servizi di pagine bianche agli agenti; per offrire questo servizio l AMS mantiene una directory di AID che contiene, tra le altre cose, gli indirizzi di trasporto degli agenti registrati sulla piattaforma. Ogni agente deve registrarsi presso l AMS per ottenere un AID valido. In particolare, per realizzare il servizio di pagine bianche, l AMS deve implementare le seguenti funzioni: register; deregister; modify; search; get-description. Può essere interessante mostrare, a titolo di esempio, l ontologia relativa al servizio di modifica della registrazione, che si riferisce ai servizi forniti dall AMS e dal DF: Function modify Ontology FIPA-Agent-Management Supported by DF and AMS Description An agent may make a modification in order to change its object registration with another agent. The argument of a modify function will replace the existing object description stored within the executing agent. The DF or AMS description supplied must include a valid AID. Domain df-agent-description / ams-agent-description Range The execution of this function results in a change of the state, but it has no explicit result. Therefore there is no range set. Arity 1 Figura 3 Ontologia della funzione modify In particolare i parametri di questa funzione fanno riferimento ad un oggetto di tipo amsagent-description, di cui pure viene riportata l ontologia, in quanto spesso utile nella

13 FIPA Modello di riferimento 13 gestione degli agenti e del loro ciclo di vita. I suoi campi comprendono il nome dell agente la cui registrazione deve essere modificata (name), le informazioni sulle entità responsabili dell agente (ownership), e lo stato dell agente (state), che può essere uno tra quelli definiti per il ciclo di vita dell agente. Frame Ontology ams-agent-description FIPA-Agent-Management Parameter Description Presence Type Reserved Values name The identifier of the agent. Optional agent-identifier ownership The owner of the agent. Optional String state The life cycle state of the agent. Optional String initiated active suspended waiting transit Figura 4 Ontologia dell oggetto ams-agent-description Oltre alle funzioni di gestione scambiate tra l AMS e gli agenti residenti sulla piattaforma, l AMS può indicare alla piattaforma sottostante di eseguire le seguenti operazioni sugli agenti: creazione, distruzione, sospensione e riattivazione della loro esecuzione; inoltre può richiedere alla piattaforma particolari operazioni di gestione delle risorse Message Transport Service (MTS) L MTS è lo strumento standard per le comunicazioni tra gli agenti residenti in piattaforme diverse. Agent Agent platform Message Transport Service Messaggi ACL inviati tramite MTS Message Transport Protocol Message Transport Service Agent Agent platform Figura 5 Message Transport Service

14 FIPA Scambio di messaggi 14 Il modello di riferimento per il trasporto dei messaggi comprende tre livelli: il Message Transport Protocol (MTP) viene usato per eseguire il trasferimento reale dei messaggi tra due ACC; il Message Transport Service (MTS) è un servizio fornito dalla piattaforma agli agenti residenti ; supporta il trasporto di messaggi ACL tra agenti su una data piattaforma e tra agenti su piattaforme diverse; l ACL rappresenta il contenuto dei messaggi trasportati da MTS e MTP Agent Platform (AP) Fornisce l infrastruttura fisica necessaria all esecuzione degli agenti. La piattaforma consiste di un computer o di un sistema hardware distribuito, del sistema operativo, del software di supporto agli agenti, dei componenti FIPA per la gestione degli agenti (DF, AMS e MTS) e degli agenti stessi. Il progetto interno di una piattaforma è un problema degli sviluppatori dei sistemi ad agenti e non è oggetto di standardizzazione da parte di FIPA. Le piattaforme e gli agenti che risiedono in queste piattaforme, sia quelli creati direttamente al loro interno o quelli giunti attraverso una migrazione, possono usare tra loro metodi di comunicazione proprietari. FIPA riguarda solo le modalità di comunicazione tra gli agenti interni ad una piattaforma e quelli residenti all esterno, o come gli agenti possono registrarsi dinamicamente su una piattaforma. Altrimenti gli agenti sono liberi di scambiare messaggi direttamente con ogni strumento a loro disposizione. Bisogna notare che il concetto di piattaforma non implica che tutti gli agenti residenti su una piattaforma debbano essere eseguiti su uno stesso computer. FIPA prevede una serie di diverse piattaforme: dai singoli processi contenenti agenti come lightweight thread, fino a piattaforme completamente distribuite costruite attorno a middleware proprietario o su standard aperti. 2.2 Scambio di messaggi Nei sistemi ad agenti FIPA gli agenti comunicano tra loro attraverso l invio di messaggi. L elemento di base è un messaggio FIPA scritto in un linguaggio di comunicazione tra agenti, come FIPA ACL. Il contenuto del messaggio FIPA è espresso in un linguaggio di contenuto, come KIF o SL, il quale può fare riferimento ad una ontologia, che definisce i

15 FIPA Scambio di messaggi 15 concetti discussi nel contenuto. I messaggi FIPA contengono anche i nomi del mittente e dei riceventi, espressi come nomi di entità FIPA, i quali sono assegnati univocamente ad ogni agente. Quando un messaggio FIPA viene inviato, è trasformato in un payload e incluso in un messaggio di trasporto. Il payload è una rappresentazione del messaggio secondo una codifica appropriata per il sistema di trasporto. Ad esempio, se il messaggio deve essere inviato su un sistema di trasporto a banda stretta, come una connessione via etere, può essere usata una rappresentazione a bit, più efficiente rispetto ad una rappresentazione tramite stringa, per permettere un utilizzo migliore della banda disponibile. Transport message FIPA Message Message encoding Payload FIPA Message Address & attributes Envelope Sender: transport-descr Receiver: transport-descr Additional attributes: Sender: entity-name Receiver: entity-name Content: Sender: entity-name Receiver: entity-name Content: Payload FIPA Message Sender: entity-name Receiver: entity-name Content: Figura 6 Trasporto dei messaggi Il messaggio di trasporto è il payload più un envelope. L envelope include le descrizioni di trasporto di mittente e destinatario. Le descrizioni di trasporto contengono informazioni su come inviare il messaggio (attraverso quale sistema di trasporto, a quale indirizzo, con i dettagli su come utilizzare il trasporto). L envelope può anche contenere informazioni aggiuntive, come la codifica da usare per rappresentare il messaggio, la sicurezza relativa ai dati, ed altre informazioni relative a implementazioni specifiche, necessarie solo durante il trasporto o per il destinatario.

16 FIPA Sicurezza 16 Ogni agente ha un nome di entità FIPA. Questo nome di entità FIPA è unico e non modificabile. Ogni agente ha anche una o più descrizioni di trasporto, che sono usate dagli altri agenti per inviare i messaggi di trasporto. Ogni descrizione di trasporto indica un particolare protocollo per il trasporto dei messaggi, come IIOP, SMTP o HTTP. In sostanza un trasporto è un meccanismo per il trasferimento di messaggi; un messaggio di trasporto è un messaggio inviato da un agente all altro in un formato (o codifica) che risulta appropriato per il trasporto utilizzato. 2.3 Sicurezza Anche se nell architettura definita da FIPA si fa qualche riferimento ai problemi relativi alla sicurezza, tuttavia solo una piccola parte dei temi viene realmente affrontata, in quanto la maggior parte delle questioni di sicurezza sono ritenute strettamente correlate alla loro implementazione. Spesso, infatti, il livello di sicurezza richiesto dipende fortemente dall ambiente applicativo previsto. Tra le opzioni previste figura il campo ownership definito nell oggetto ams-agentdescription, che dovrebbe contenere dei riferimenti alle entità responsabili per l esecuzione dell agente, oppure l uso di particolari formati di codifica dei messaggi. In sostanza nel modello di riferimento FIPA c è una semplice forma di sicurezza: autenticazione e cifratura dei messaggi. Con l autenticazione è possibile accertarsi che i messaggi non siano stati modificati durante il percorso. Con la cifratura, si può fare in modo che il contenuto dei messaggi non possa essere letto da entità non autorizzate.

17 FIPA Sicurezza 17 Transport message: HTTP Envelope Sender: transport-type: FIPA-HTTP transport-addr: transport-prop: none Receiver: transport-type: FIPA-HTTP transport-addr: transport-prop: Encrypt: 3DES Additional attributes: none Attributes for encryption Payload Transport message: HTTP Envelope Sender: transport-type: FIPA-HTTP transport-addr: transport-prop: none Receiver: transport-type: FIPA-HTTP transport-addr: transport-prop: Encrypt: 3DES Additional attributes: public-key: <data> payload-stat: 3DES encrypt FIPA Message Sender: abc Receiver: xyz Content: Encrypted payload Payload ### Figura 7 Sicurezza nel trasporto dei messaggi L architettura FIPA indirizza questi obbiettivi attraverso la rappresentazione dei messaggi tramite codifiche particolari, e l uso di attributi aggiuntivi nell envelope. Per esempio, durante il trasporto di un messaggio, il suo payload potrebbe essere convertito in una sequenza cifrata di dati, usando una chiave pubblica ed un particolare algoritmo crittografico ed aggiungendo all envelope dei parametri ulteriori, non cifrati altrimenti il destinatario non sarebbe capace di usarli, per indicare queste caratteristiche. In sostanza l autenticazione e la cifratura sono trattate come normali trasformazioni di messaggi in un linguaggio di codifica, a parte il fatto che le rappresentazioni risultanti in realtà sono sequenze cifrate di dati.

18 JADE Sicurezza 18 3 JADE JADE (Java Agent Development Framework) è un ambiente per lo sviluppo di software basato sul modello multi-agente e di applicazioni conformi agli standard FIPA per gli agenti intelligenti. Consiste di due elementi principali: una piattaforma ad agenti conforme alle specifiche FIPA e una gerarchia di classi orientata allo sviluppo di agenti. Per sfruttare le caratteristiche di JADE, essendo questo un sistema sviluppato completamente in Java, gli agenti dovrebbe essere realizzati usando tale linguaggio. Per farsi una idea di ciò che è realmente JADE, può essere utile elencarne brevemente le caratteristiche principali. Piattaforma per agenti distribuita. La piattaforma può essere ripartita tra numerosi host, purché essi siano raggiungibili tramite RMI. Su ciascun host viene eseguita una sola applicazione Java, e quindi è sufficiente una sola macchina virtuale. Gli agenti sono implementati come thread Java e risiedono in container di agenti, i quali forniscono l infrastruttura di servizi necessaria all esecuzione degli agenti. Interfaccia grafica per gestire molteplici agenti e container anche attraverso un collegamento da un host remoto. Strumenti di debugging per aiutare nello sviluppo di applicazioni multi-agente basate su JADE. Mobilità intra-piattaforma degli agenti. Gli agenti possono spostarsi da un container ad un altro all interno della stessa piattaforma. È supportata la mobilità del codice e dello stato interno degli agenti. Supporto per la gestione di numerose attività concorrenti degli agenti, eseguite in parallelo secondo il modello a comportamenti o behaviour. Lo scheduling tra i comportamenti viene effettuato trasparentemente da JADE in maniera nonpreemptive. Piattaforma ad agenti conforme agli standard FIPA. Sono inclusi un agente AMS (Agent Management System), uno o più agenti DF (Directory Facilitator), ed una implementazione di ACC (Agent Communication Channel). Queste tre componenti sono tutte attivate automaticamente durante la fase di avvio della piattaforma.

19 JADE Piattaforma 19 Sistema di trasferimento dei messaggi conforme agli standard FIPA. Per connettere differenti piattaforme ad agenti viene utilizzato il protocollo IIOP. Per implementare applicazioni multi-dominio possono essere istanziati numerosi DF. Un dominio è inteso come un insieme logico di agenti, i cui servizi sono pubblicizzati attraverso un servizio condiviso. Ogni DF eredita una interfaccia grafica e tutte le normali caratteristiche definite da FIPA, quindi la possibilità di registrare, cancellare, modificare e cercare descrizioni di agenti; inoltre è offerta la possibilità di creare una rete di DF tra loro federati. Trasporto efficiente di messaggi ACL all interno della stessa piattaforma. Infatti i messaggi durante il trasferimento sono codificati come oggetti Java, piuttosto che come stringhe, per evitare le procedure di marshalling e unmarshalling. Solo quando risulta realmente necessario, ad esempio quando un messaggio viene inviato al di fuori della piattaforma, allora il messaggio viene automaticamente convertito in sintassi, codifica e protocollo di trasporto conformi agli standard FIPA. Lo stesso accede quando viene ricevuto un messaggio dall esterno. Entrambe queste conversioni sono trasparenti agli sviluppatori di agenti, che devono occuparsi solo di oggetti Java. Implementazione completa di una libreria di protocolli di interazione FIPA. Registrazione e cancellazione automatica degli agenti presso l AMS. Servizio di naming conforme alle specifiche FIPA: all avvio gli agenti ottengono dalla piattaforma il proprio identificatore GUID (Global Inique Identifier). Supporto alle applicazioni per la definizione e l uso di nuovi linguaggi e ontologie per le comunicazioni. 3.1 Piattaforma Il modello adottato è conforme allo standard definito da FIPA per le piattaforme ad agenti. Gli elementi principali, come visto, sono l AMS (Agent Management System), per la supervisione e gestione degli agenti e per il servizio di pagine bianche, uno o più DF (Directory Facilitator) per il servizio di pagine gialle, l ACC (Agent Communication Channel), che controlla lo scambio di messaggi.

20 Application Agent Application Agent Application Agent Application Agent Application Agent Application Agent Application Agent Application Agent Application Agent JADE Agenti 20 JADE è completamente conforme a questa architettura di riferimento: all avvio di una nuova piattaforma, l AMS e il DF sono creati automaticamente e il modulo ACC viene subito impostato per permettere la trasmissione di messaggi. Host 1 Host 2 Host 3 RMI Registry Jade Distributed Agent Platform Jade Main Container Jade Agent Container JRE 1.2 JRE 1.2 JRE 1.2 Network protocol stack Jade Agent Container Figura 8 Architettura di JADE La piattaforma ad agenti può essere suddivisa tra diversi computer. Solo una applicazione Java, e quindi solo una macchina virtuale Java viene eseguita su ciascun computer. Ogni JVM costituisce in sostanza un contenitore di agenti e fornisce a questi un completo ambiente di esecuzione, permettendo a numerosi agenti di funzionare in maniera concorrente sulla stessa macchina. Il container principale, o front-end, è quello dove risiedono l AMS e il DF e dove viene creato il registro RMI usato internamente da JADE. Gli altri container per agenti si connettono al container principale, in modo da realizzare un ambiente completo per l esecuzione di qualsiasi insieme di agenti JADE. 3.2 Agenti La classe Agent costituisce una classe base comune per gli agenti di sistema e quelli definiti a livello applicativo. Perciò, dal punto di vista di un programmatore, un agente JADE è semplicemente una istanza di una classe Java che estende la classe base

21 JADE Agenti 21 Agent. Questo permette di ereditare caratteristiche per realizzare semplici interazioni con la piattaforma ad agenti (come registrazione, configurazione, gestione remota) e un insieme di base di metodi che possono essere richiamati per implementare il comportamento richiesto al particolare agente, per esempio inviare o ricevere messaggi, usare protocolli standard di interazione, registrarsi presso numerosi domini. Il modello computazionale previsto per gli agenti è di tipo multitask, dove i task o comportamenti sono eseguiti in maniera concorrente. Ogni funzionalità o servizio fornito dall agente dovrebbe essere implementato come uno o più comportamenti. Uno scheduler, interno alla classe base Agent e nascosto al programmatore, gestisce automaticamente lo scheduling dei comportamenti Ciclo di vita Un agente JADE può essere in uno di numerosi stati, in accordo alle specifiche FIPA per il ciclo di vita di un agente; questi stati, rappresentati come costanti di tipo stringa definite all interno della classe Agent, sono: AP_INITIATED l agente è stato creato, ma non si è ancora registrato presso l AMS, non ha un nome e nemmeno un indirizzo e non può comunicare con gli altri agenti; AP_ACTIVE l agente si è registrato presso l AMS, ha un nome regolare ed un indirizzo e quindi può accedere a tutti i vari servizi di JADE; AP_SUSPENDED l agente è attualmente bloccato; il suo thread interno di esecuzione è sospeso e non viene eseguita alcuna attività; AP_WAITING l agente è attualmente bloccato in attesa di qualche evento particolare; il suo thread interno di esecuzione è in attesa su un monitor Java e sarà riattivato solo al verificarsi di qualche condizione (tipicamente all arrivo di un messaggio); AP_DELETED l agente è definitivamente morto; il thread associato all agente ha terminato la propria esecuzione e l agente non è più registrato presso l AMS; AP_TRANSIT un agente mobile entra in questo stato mentre migra in una nuova posizione; il sistema continua a conservare i messaggi, che saranno consegnati all agente nella nuova locazione; AP_COPY questo stato viene usato internamente da JADE per gli agenti che devono essere clonati;

22 JADE Agenti 22 AP_GONE usato internamente da JADE quando un agente mobile è migrato in una nuova locazione ed ha già uno stato consistente. La classe Agent fornisce metodi pubblici per eseguire le transizioni tra i vari stati; questi metodi prendono il loro nome dalle transizioni possibili nella macchina a stati finiti definita nelle specifiche FIPA relative alla gestione degli agenti. Per esempio il metodo dowait() pone l agente nello stato AP_WAITING dallo stato AP_ACTIVE, il metodo dosuspend() pone l agente nello stato AP_SUSPENDED dagli stati AP_ACTIVE o AP_WAITING. Si noti che ad un agente è permesso eseguire i suoi comportamenti sono quando è nello stato AP_ACTIVE. Bisogna anche fare attenzione che la chiamata al metodo dowait() blocca non solo il comportamento che ha eseguito la chiamata, ma tutto l agente e le attività in esecuzione al momento della chiamata. Invece nella classe Behaviour è presente il metodo block() per consentire la sospensione di un singolo comportamento dell agente Comportamenti Un agente deve spesso essere in grado di completare numerose attività concorrenti in risposta a diversi eventi esterni. Per rendere la gestione degli agenti efficiente, ogni agente JADE è composto da un singolo thread di esecuzione e tutte le sue attività devono essere implementate come oggetti di tipo Behaviour. Il programmatore che vuole implementare una attività specifica per un agente deve definire una o più sottoclassi di Behaviour, istanziarle e aggiungerle agli oggetti Behaviour già presenti nella lista delle attività dell agente. La classe Agent, che deve essere estesa dal programmatore, espone due metodi: addbehaviour(behaviour) e removebehaviour(behaviour), che permettono di gestire la coda delle attività in esecuzione su uno specifico agente. Si noti che i comportamenti ed i sottocomportamenti possono essere aggiunti al momento del bisogno, e non solo all interno del metodo Agent.setup(). Aggiungere un comportamento dovrebbe essere inteso come un modo di lanciare un nuovo thread di esecuzione cooperativo all interno dell agente. Uno scheduler, implementato dalla classe base Agent e nascosto al programmatore, gestisce una politica di scheduling round-robin non-preemptive tra tutti i comportamenti disponibili in una apposita coda, eseguendo il metodo action() di una istanza Behaviour finchè questa non rilascia il controllo, ossia fino a quando il metodo action() non

23 JADE Agenti 23 termina. A questo punto viene invocato il metodo done() per stabilire se il comportamento ha completato i suoi compiti, nel qual caso viene rimosso dalla coda. Per evitare attesa attiva sui messaggi, e come conseguenza evitare di sprecare cicli di CPU, ad ogni singolo comportamento è permesso di bloccare la sua computazione. Il metodo block() pone il comportamento in una coda di comportamenti bloccati ed ha effetto non appena il metodo action() termina. Tutti i comportamenti bloccati sono riattivati non appena arriva un nuovo messaggio. Inoltre un oggetto di tipo Behaviour si può bloccare per una quantità di tempo limitata passando un valore di timeout alla chiamata block(). A causa del modello di multitasking non-preemptive scelto per i comportamenti dell agente, all interno del metodo action() dovrebbe essere evitato l uso di cicli infiniti ed anche l esecuzione di lunghe operazioni. Infatti durante l esecuzione del metodo action() di un comportamento, nessun altro comportamento può continuare fino alla fine del metodo. Ovviamente questo è valido solo per quanto riguarda i comportamenti dello stesso agente, in quanto gli altri agenti vengono eseguiti in thread Java diversi e possono ancora procedere indipendentemente. Inoltre, poiché non viene salvata alcuna informazione riguardo al contesto di esecuzione, il metodo action() viene eseguito sempre dall inizio; non c è modo di interrompere un comportamento nel mezzo del metodo action(), concedere la CPU ad altri comportamenti e poi riattivare il comportamento originale automaticamente nel punto in cui era stato interrotto. Nella gestione di comportamenti complessi, come alcuni protocolli di interazione, usare in maniera esplicita variabili di stato può essere frustrante; per questo motivo JADE supporta anche un tecnica di composizione per costruire comportamenti più complessi a partire da quelli più semplici. In particolare il framework fornisce sottoclassi di Behaviour che permettono di gestire liste di sotto-comportamenti e di eseguirli in accordo a determinate politiche. Per esempio è presente una classe SequentialBehaviour, che esegue i suoi sottocomportamenti uno dopo l altro ad ogni invocazione successiva del metodo action().

24 JADE Messaggi Messaggi La classe ACLMesage rappresenta i messaggi ACL che possono essere scambiati tra gli agenti. Contiene una serie di attributi conformi alle specifiche definite da FIPA. Un agente che vuole inviare un messaggio deve creare un nuovo oggetto ACLMessage, riempire i suoi attributi con i valori appropriati ed infine invocare il metodo send(), implementato nella classe Agent. Il valore del campo ACLMessage.receiver indica la lista dei nomi degli agenti destinatari del messaggio. La chiamata del metodo è completamente trasparente rispetto alla locazione in cui risiedono i destinatari, i quali possono essere sia locali rispetto al mittente che remoti, in quanto è la piattaforma che si preoccupa di selezionare gli indirizzi ed i meccanismi di trasporto più appropriati. Allo stesso modo, un agente che vuole ricevere un messaggio deve invocare i metodi receive() o blockingreceive(), entrambi implementati nella classe Agent. L invio o la ricezione di messaggi possono anche essere impostati come attività indipendenti dell agente, aggiungendo i comportamenti ReceiverBehaviour o SendBehaviour alla coda delle attività correnti dell agente. In accordo alle specifiche FIPA un messaggio di risposta deve essere composto seguendo una precisa serie di regole, come impostare l appropriato valore per il campo in-reply-to, usare lo stesso conversation-id, e così via. JADE aiuta il programmatore in questo compito attraverso il metodo createreply() della classe ACLMessage. Questo metodo restituisce un oggetto ACLMessage che è una valida replica al messaggio iniziale. In seguito il programmatore deve solo impostare gli atti comunicativi ed il contenuto del messaggio, che sono specifici dell applicazione. 3.4 Remote Monitoring Agent Il Remote Monitorino Agent (RMA) permette di controllare la piattaforma ad agenti e il ciclo di vita di tutti gli agenti registrati. L architettura distribuita di JADE permette anche il controllo remoto, dove l interfaccia grafica è usata per controllare l esecuzione degli agenti ed il loro ciclo di vita da un computer remoto. Naturalmente, per portare a termine i suoi compiti, l RMA interagisce continuamente con l AMS della piattaforma, al quale invia le operazioni richieste dall amministratore, e dal quale riceve notifica dei cambiamenti avvenuti nell ambiente, come la creazione di un agente o la connessione di un nuovo container.

25 JADE Remote Monitoring Agent 25 Un agente RMA è un oggetto Java, istanza della classe jade.tools.rma.rma e può essere lanciato dalla linea di comando come un normale agente, con il comando java jade.boot myconsole:jade.tools.rma.rma oppure fornendo l opzione gui tra i parametri della linea di comando, ossia digitando java jade.boot -gui Diversi RMA possono essere eseguiti su una stessa piattaforma, purché ogni istanza abbia un nome locale differente; tuttavia un solo RMA può essere eseguito nello stesso container. Figura 9 Remote Monitoring Agent Attraverso l RMA è possibile eseguire una completa amministrazione della piattaforma, usando i controlli presenti sulla toolbar o tra i menù della sua interfaccia. In particolare, il menù File contiene i comandi generali dell RMA. Close RMA agent: termina l agente RMA invocando il metodo dodelete(); la chiusura della finestra ha lo stesso effetto; Exit this container: chiude il container dove l agente RMA risiede, uccidendo in questo modo l RMA e tutti gli altri agenti che risiedono nel container; se il

26 JADE Remote Monitoring Agent 26 container è quello principale della piattaforma, allora l intera piattaforma viene spenta; Shut down agent platform: spegne l intera piattaforma ad agenti, chiudendo tutti i container collegati e uccidendo tutti gli agenti. Il menù Actions contiene elementi per invocare tutte le necessarie azioni amministrative sulla piattaforma nel suo complesso o su un insieme di agenti o di container; l azione richiesta è eseguita usando come obbiettivo la selezione attuale dell albero di agenti; la maggior parte di queste azioni sono associate anche a bottoni presenti sulla toolbar, e quindi possono essere eseguite anche da lì. Start new agent: crea un nuovo agente; all utente viene richiesto il nome del nuovo agente e la classe Java di cui il nuovo agente deve essere istanza; inoltre, se un container è attualmente selezionato, l agente viene creato ed eseguito su quel container, altrimenti l utente può specificare il container su cui vuole che l agente venga eseguito; se non viene specificato alcun container l agente viene lanciato sul container principale della piattaforma; Kill selected items: uccide tutti gli agenti ed i container attualmente selezionati; uccidere un agente è equivalente ad invocare il metodo dodelete(), mentre chiudere un container equivale ad uccidere tutti gli agenti che risiedono sul container e poi scollegare quel container dalla piattaforma; naturalmente, se attualmente è selezionato il container principale della piattaforma, allora l intera piattaforma viene spenta; Suspend selected agents: sospende gli agenti selezionati ed è equivalente ad invocare il metodo dosuspend(); bisogna prestare attenzione al fatto che sospendere gli agenti di sistema, in particolare l AMS, può bloccare in deadlock l intera piattaforma; Resume selected agents: pone di nuovo gli agenti selezionati nello stato AP_ACTIVE, supposto che essi fossero sospesi, e funziona esattamente come invocare il loro metodo doactivate(); Send custom message: permette di inviare un messaggio ACL ad un agente; quando l utente seleziona questo elemento di menu viene mostrata una speciale finestra di dialogo nella quale il messaggio può essere composto ed inviato.

27 JADE Sicurezza 27 Il menu Tools contiene i comandi per invocare tutti gli strumenti forniti da JADE agli sviluppatori di applicazioni. Questi strumenti aiutano durante le varie fasi dello sviluppo e della verifica di sistemi ad agenti basati su JADE. Dummy agent: questo strumento permette agli utenti di interagire con gli agenti JADE in maniera versatile; l interfaccia grafica permette di comporre ed inviare messaggi; inoltre gestisce una lista di tutti i messaggi inviati e ricevuti, permettendo di modificare i singoli messaggi oppure salvare su disco o ripristinare l intera lista; DF GUI: invia un messaggio ACL al DF chiedendo di mostrare la propria interfaccia grafica; perciò questa interfaccia può essere mostrata solo sul container principale, dove il DF viene eseguito; usando questo strumento è possibile interagire con il DF registrando agenti, cancellandoli o modificando le loro descrizioni; è anche possibile effettuare ricerche oppure federare il DF con altri DF per creare complesse reti di domini e sotto-domini di pagine gialle; Sniffer agent: come già dice il nome, questo strumento è un agente conforme alle specifiche FIPA con caratteristiche di spionaggio; quando l utente decide di spiare un agente o un gruppo di agenti, ogni messaggio diretto ad essi o da essi inviato viene intercettato e mostrato nell interfaccia grafica; è possibile salvare e ripristinare i singoli messaggi o anche tutta la registrazione. 3.5 Sicurezza L implementazione attuale di JADE offre numerosi strumenti anche evoluti per lo sviluppo di complesse applicazioni distribuite. Tuttavia sistemi critici dal punto di vista della sicurezza, come piattaforme per commercio elettronico o per la gestione di dati riservati, necessitano di requisiti più stringenti. In particolare spesso viene richiesto di tenere in domini di protezione separati gli agenti lanciati da utenti diversi, in modo da impedire alle entità che non possiedono le necessarie autorizzazioni l accesso a risorse che dovrebbero restare private. Inoltre spesso è necessario proteggere lo stesso ambiente hardware e software che ospita la piattaforma da possibili danni, anche accidentali, provocati dagli agenti in esecuzione.

28 JADE Sicurezza 28 Invece JADE dal punto di vista della sicurezza non offre molto, essendo basato su un modello aperto che privilegia la collaborazione tra gli agenti spesso anche a danno della loro protezione. In parte questa scarsa protezione deriva da una lacuna nelle specifiche rilasciate da FIPA, su cui JADE si basa, le quali non prevedono ancora un modello di sicurezza definitivo per i sistemi ad agenti. Allo stato attuale delle cose in un sistema JADE qualsiasi agente può sospendere o chiudere qualsiasi altro agente; può comunicare con chiunque e persino modificare arbitrariamente le descrizioni di altri agenti memorizzate sui servizi di pagine gialle o di pagine bianche del sistema; inoltre è possibile per qualsiasi agente chiudere i container e anche spegnere improvvisamente l intera piattaforma. Nel seguito saranno analizzati più nel dettaglio i requisiti di sicurezza che un generico sistema ad agenti dovrebbe garantire, i possibili attacchi che possono mettere a rischio tali requisiti, e gli strumenti disponibili per prevenire e rilevare questi attacchi. Saranno poi descritti altri sistemi ad agenti attualmente utilizzati ed i rispettivi modelli di sicurezza adottati, in modo da poter avere una visione più completa del problema nella definizione di un modello di sicurezza per JADE. Infine sarà descritta una implementazione reale di tale modello.

29 Requisiti di sicurezza Sicurezza 29 4 Requisiti di sicurezza Per descrivere le caratteristiche di sicurezza che gli utenti tipicamente si aspettano da un sistema ad agenti, e quindi le minacce che un tale sistema dovrebbe riuscire a contrastare, è conveniente fare riferimento ad un modello abbastanza astratto di tale sistema, in cui individuiamo due componenti principali: agente e piattaforma. Come agente intendiamo l insieme del codice e dell informazione di stato necessaria per eseguire l elaborazione richiesta. La piattaforma fornisce l ambiente e le risorse computazionali nei quali gli agenti operano. Uno o più host possono far parte di una sola piattaforma, ed una sola piattaforma può supportare numerosi ambienti, o luoghi d incontro, dove gli agenti possono interagire e cooperare. Agente Agente Piattaforma Piattaforma Figura 10 Modello astratto agente-piattaforma Gli utenti dei sistemi ad agenti, ed in modo particolare quelli di sistemi ad agenti mobili, richiedono che il sistema offra certe caratteristiche di sicurezza. Parlando in modo abbastanza astratto possiamo dire che questi requisiti sono grosso modo gli stessi che sono richiesti ad una rete di calcolatori o ad un sistema informatico distribuito tradizionale, ossia basato sul modello client-server. Questi requisiti sono riconducibili a cinque aree principali: integrità, riservatezza, responsabilità, disponibilità, anonimato.

30 Requisiti di sicurezza Integrità Integrità La piattaforma dovrebbe proteggere gli agenti che ospita da modificazioni non autorizzate del loro codice, del loro stato e dei loro dati. Dovrebbe anche assicurare che solo gli agenti o i processi autorizzati possano modificare i dati condivisi. La completa funzionalità di un sistema ad agenti dipende inoltre dall integrità delle piattaforme stesse. Un nodo malizioso potrebbe facilmente compromettere l integrità dell intera rete. Un agente infatti non può impedire ad una piattaforma maliziosa di manomettere il suo codice o il suo stato o i suoi dati, anche se in alcuni casi può adottare delle misure atte a rilevare una tale manomissione. Bisogna anche considerare che gli utenti o i processi che interagiscono con una determinata piattaforma non sono a conoscenza di eventuali modifiche apportate al suo codice sorgente, e quest ultima potrebbe quindi subdolamente alterare il flusso dell esecuzione degli agenti ospitati o produrre risultati errati difficilmente rilevabili. Il risultato dell attacco potrebbe essere anche peggiore se non fosse portato in modo casuale ma orientato ad un obbiettivo preciso. Attacchi di questo tipo potrebbero alterare le comunicazioni tra gli agenti modificando il contenuto, la sorgente o la destinazione di alcuni messaggi, cancellando o sostituendo interamente altri, riusando vecchi messaggi. 4.2 Riservatezza In linea di principio qualsiasi dato memorizzato su una piattaforma o trasportato da un agente dovrebbe restare riservato. Il sistema dovrebbe anche garantire che qualsiasi comunicazione, sia intra-piattaforma che inter-piattaforma resti riservata. Attraverso l eavesdropping, ossia l intercettazione non autorizzata di comunicazioni, è possibile ricavare informazioni sull attività di un agente non solo dal contenuto dei messaggi scambiati ma anche dal flusso dei messaggi da un agente verso un altro agente o verso un gruppo di agenti. Un agente mobile potrebbe anche voler tenere segreta la sua locazione. Gli agenti mobili potrebbero ad esempio comunicare usando un proxy la cui posizione sia nota a tutti, per celare la loro presenza su una particolare piattaforma. Spesso è desiderabile che una piattaforma tenga traccia degli eventi rilevanti dal punto di vista della sicurezza. Tuttavia, poiché i file di log contengono una traccia dettagliata

31 Requisiti di sicurezza Responsabilità 31 delle attività che ogni agente svolge sulla piattaforma, il loro contenuto dovrebbe essere tenuto attentamente protetto e restare riservato. 4.3 Responsabilità In certi contesti applicativi, si pensi ad esempio a sistemi per commercio elettronico o per transazioni finanziarie, ogni processo, utente o agente su una data piattaforma dovrebbe poter essere ritenuto responsabile delle sue azioni. Questo richiede che ogni processo, utente o agente venga identificato in maniera univoca, autenticato e tenuto sotto controllo. Esempi di azioni per le quali bisognerebbe poter stabilire le responsabilità includono gli accessi a risorse particolari, come file locali, o le modifiche alle politiche di sicurezza della piattaforma. A seconda del livello di sicurezza desiderato, potrebbe essere necessario attribuire anche le responsabilità degli atti comunicativi tra agenti. Gli agenti dovrebbero essere in grado di autenticare la loro identità nei confronti della piattaforma ma anche nei confronti degli altri agenti, mentre le piattaforme dovrebbero autenticare la loro identità con gli agenti e con le altre piattaforme. Nelle società di agenti nelle quali la reputazione è tenuta in conto e usata come mezzo per stabilire relazioni di fiducia, la piattaforma dovrebbe esercitare la dovuta diligenza nel proteggere la reputazione degli agenti dai danni che potrebbero derivare dal masquerading. Affinché le responsabilità possano essere attribuite precisamente è necessario tenere una traccia degli eventi rilevanti dal punto di vista della sicurezza ed elencare le persone o i processi responsabili di quell evento. Gli eventi rilevanti dovrebbero essere definiti nella politica di sicurezza ed includere almeno il nome dell utente o dell agente, l istante dell evento, il tipo ed il successo o fallimento dell evento. Naturalmente i file di log dovrebbero essere protetti da accessi o modificazioni non autorizzate. I file di log sono molto importanti e preziosi anche quando la piattaforma deve essere ristabilita dopo una violazione della sicurezza o dopo un guasto software o hardware. 4.4 Disponibilità La piattaforma dovrebbe assicurare la disponibilità di dati e servizi agli agenti che ospita ed eventualmente anche ad agenti remoti; dovrebbe fornire un forma controllata di concorrenza, supportare accessi simultanei alle risorse condivise, gestire situazioni di deadlock e accessi esclusivi quando necessario.

32 Requisiti di sicurezza Anonimato 32 Per evitare il rischio di creare non intenzionalmente situazioni di denial of service, ossia per non trovarsi nelle condizioni di non riuscire a fornire i servizi previsti, la piattaforma dovrebbe essere in grado di gestire richieste da centinaia o migliaia di agenti residenti o remoti. Nel caso che la piattaforma non riuscisse a gestire il suo carico di computazione e comunicazione, dovrebbe evitare un degrado brusco dei servizi forniti e comunque notificare agli agenti di non riuscire più a garantire loro il livello e la qualità dei servizi che si aspettano. La minaccia di un attacco di tipo denial of service sottolinea l importanza di un attento controllo e monitoraggio delle risorse della piattaforma. Un attacco di tipo denial of service contro una piattaforma è un attacco indiretto a tutti gli agenti che dipendono dalle risorse e dai servizi offerti da quella piattaforma. Poiché una piattaforma può ospitare agenti di organizzazioni diverse, un attacco ad una singola piattaforma può ripercuotersi su numerose altre piattaforme e sistemi. Assicurare la riservatezza pone limiti dal punto di vista della disponibilità ed ha anche un costo in termini di prestazioni. Cifrare agenti e messaggi in transito potrebbe imporre ritardi inaccettabili in sistemi dove sia richiesta una elaborazione real-time o near realtime. Anche accertare le responsabilità potrebbe imporre limiti sulla disponibilità di servizi. Per esempio quando la capacità di memorizzazione è esaurita spesso la politica di sicurezza rifiuta di eseguire tutti quei servizi che creano nuovi record nei file di log. In questo modo si espone il fianco agli attacchi di tipo denial of service, che possono bloccare la piattaforma semplicemente producendo un grosso numero di eventi monitorati. 4.5 Anonimato Una piattaforma ad agenti dovrebbe in genere trovare un equilibrio tra i bisogni di riservatezza degli agenti e la sua necessità di poter ritenere gli agenti responsabili del loro comportamento. La piattaforma dovrebbe essere in grado di tenere segreta l identità di un agente per gli altri agenti, usando però una forma di anonimato reversibile, dalla quale sia cioè possibile determinare l identità dell agente qualora risulti necessario, ad esempio per motivi legali.

33 Requisiti di sicurezza Anonimato 33 L anonimato nelle comunità umane può aiutare lo sviluppo di particolari commerci o promuovere la libertà di espressione eliminando la paura di esprimere punti di vista impopolari. Questo accade anche nelle comunità di agenti e quindi le politiche di sicurezza delle piattaforme e le loro necessità di monitoraggio dovrebbero essere attentamente bilanciate con le richieste di riservatezza mosse dagli agenti.

34 Minacce alla sicurezza Agente contro piattaforma 34 5 Minacce alla sicurezza Si possono in genere distinguere tre classi principali di minacce alla sicurezza: accesso ad informazioni riservate, negazione del servizio, e alterazione di informazioni. Ci sono svariati modi per esaminare più nel dettaglio queste minacce e come si applicano ai sistemi ad agenti. Facendo riferimento alle componenti principali di ogni sistema ad agenti, possiamo classificare le minacce in base alle possibili fonti e agli obbiettivi dell attacco. Identifichiamo quattro categorie di minacce: un agente che attacca la sua piattaforma, una piattaforma che attacca i suoi agenti, un agente che attacca un altro agente, ed altre entità che attaccano il sistema nel suo complesso. L ultima categoria copre gli attacchi di un agente contro agenti di una piattaforma diversa e di una piattaforma contro un altra piattaforma. Sono qui compresi anche i più tradizionali attacchi contro il sistema operativo che ospita la piattaforma ad agenti. 5.1 Agente contro piattaforma Questa categoria di attacchi rappresenta l insieme delle minacce nelle quali gli agenti sfruttano le debolezze nel sistema di sicurezza della piattaforma, o comunque tentano attacchi alla piattaforma. Comprende unauthorized access, masquerading e denial of service Unauthorized access Utenti o processi possono tentare di accedere a servizi e risorse per cui non hanno ricevuto i permessi e privilegi previsti dalla politica di sicurezza. Ogni piattaforma dovrebbe implementare meccanismi di controllo per impedire gli accessi non autorizzati ed ogni agente ospitato dovrebbe essere soggetto alla politica di sicurezza. Applicare i meccanismi di controllo di accesso richiede però che l identità di un agente venga autenticata prima di essere istanziato sulla piattaforma Masquerading Quando un agente non autorizzato simula l identità di un altro agente si parla di masquerading. L agente che tenta il mascheramento può impersonare un agente autorizzato con lo scopo di ottenere accesso a risorse e servizi che altrimenti non gli

35 Minacce alla sicurezza Agente contro agente 35 sarebbero riconosciuti. Più semplicemente può tentare di addossare ad un altro agente le colpe di azioni per le quali non vuole essere ritenuto responsabile. In questo modo l agente che opera il mascheramento può danneggiare la fiducia e la reputazione di cui gode nella comunità l agente legittimo Denial of service Gli agenti possono lanciare attacchi del tipo denial of service consumando una quota eccessiva delle risorse di calcolo a disposizione della piattaforma ad agenti. Questi attacchi possono essere lanciati intenzionalmente eseguendo script che sfruttano le debolezze del sistema, o non volutamente a causa di errori di programmazione. La situazione è aggravata dal fatto che il modello di computazione mobile può in taluni casi imporre alla piattaforma di accettare e mandare in esecuzione un agente il cui codice sia stato scritto all esterno della società e non sia stato soggetto ad una analisi preventiva. Un agente potrebbe trasportare codice progettato per interrompere i servizi offerti dalla piattaforma, degradarne le prestazioni, o ricavare informazioni per le quali non avrebbe l autorizzazione necessaria. A seconda del livello di accesso l agente potrebbe essere in grado di spegnere o bloccare la piattaforma. 5.2 Agente contro agente Sono comprese in questa categoria le minacce originate da agenti che sfruttano le debolezze nella sicurezza di altri agenti o più in generale lanciano attacchi contro di questi. Le possibili minacce includono unauthorized access, masquerading, denial of service e repudiation. Spesso anche componenti della piattaforma sono realizzati come agenti. Questi agenti possono fornire servizi di sistema come servizi di directory e di comunicazione interpiattaforma. Alcuni sistemi permettono comunicazioni dirette tra agente ed agente mentre altri prevedono il passaggio delle comunicazioni attraverso uno speciale agente. Tutte queste scelte architetturali influiscono sul livello di sicurezza tra agenti diversi e tra gli agenti e la piattaforma Unauthorized access Se la piattaforma ha attivi pochi o deboli meccanismi di protezione degli accessi, un agente potrebbe interferire con un altro agente invocandone direttamente i metodi pubblici oppure modificandone i dati e il codice. La modificazione del codice di un

36 Minacce alla sicurezza Agente contro agente 36 agente è una minaccia particolarmente insidiosa dal momento che può cambiare radicalmente il comportamento di un agente, ad esempio trasformando un agente fidato in uno malizioso. Un agente può anche ottenere informazioni sull attività degli altri agenti usando i servizi della piattaforma per spiare le loro conversazioni Masquerading La comunicazione tra agenti si può svolgere direttamente o può richiedere l intervento della piattaforma sottostante e dei servizi da essa offerti. In entrambi i casi un agente può tentare di dissimulare la sua identità con lo scopo di confondere l agente con il quale sta comunicando. Ad esempio un agente potrebbe impersonare un noto fornitore di beni o servizi per tentare di convincere altri agenti non sospettosi a fornire il numero della loro carta di credito o altre informazioni private. Il mascheramento danneggia sia l agente ingannato che quello di cui è stata assunta l identità, specialmente nelle società di agenti dove la reputazione è importante ed usata come mezzo per stabilire rapporti di fiducia Denial of service Oltre a lanciare attacchi di tipo denial of service contro la propria piattaforma, gli agenti possono anche lanciare questo tipo di attacco contro altri agenti. Per esempio l invio in rapida sequenza di numerosi messaggi ad un altro agente o la diffusione verso più agenti di messaggi non desiderati può portare lavoro e ritardi non dovuti nelle routine di gestione dei messaggi presso i destinatari. Gli agenti sotto spam possono scegliere di bloccare i messaggi provenienti da fonti non autorizzate, ma anche ciò richiede una certa elaborazione da parte dell agente o del suo proxy per le comunicazioni. Se ad un agente vengono addebitati i cicli di CPU che consuma sulla piattaforma allora lo spam comporta per l agente che lo subisce un costo in termini monetari oltre che in termini di prestazioni. I linguaggi e le politiche di conversazione dovrebbero assicurare che un agente malizioso non possa trattenere un agente in una conversazione infinita o estremamente lunga col solo scopo di sprecare risorse. Agenti maliziosi possono anche distribuire informazioni false o inutili per impedire ad altri di completare i loro compiti correttamente ed in tempo utile.

37 Minacce alla sicurezza Piattaforma contro agente Repudiation Si parla di repudiation quando un agente coinvolto in una transazione o una comunicazione in seguito sostiene che tale comunicazione non sia mai avvenuta. Il ripudio, sia che avvenga in maniera deliberata o accidentale, può portare a prolungate e serie dispute. La piattaforma non può impedire ad un agente di ripudiare una transazione, ma può assicurare la disponibilità di evidenze sufficientemente forti a risolvere i disaccordi. È importante che gli agenti e le piattaforme interessate ad una transazione tengano una traccia dei relativi messaggi che aiuti a risolvere ogni controversia. 5.3 Piattaforma contro agente Questa categoria rappresenta l insieme di minacce nelle quali la piattaforma compromette la sicurezza degli agenti. Include masquerading, denial of service, eavesdropping e alteration Masquerading Una piattaforma può assumere l identità di un altra piattaforma nel tentativo di ingannare un agente mobile sulla sua reale destinazione e sul relativo domino di sicurezza. Una piattaforma che impersona una piattaforma fidata può riuscire ad attirare su di sé agenti non sospettosi e ricavare poi informazioni importanti da questi agenti. La piattaforma che assume l identità di un altra piattaforma può danneggiare gli agenti che la visitano ma anche la piattaforma di cui assume l identità. Normalmente un agente che assume una identità diversa può danneggiare altri agenti solo attraverso i messaggi che scambia con questi, mentre una piattaforma maliziosa può danneggiare gli agenti in maniera assai più grave Denial of service Quando un agente arriva su una piattaforma si aspetta che questa esegua precisamente le sue richieste, provveda ad una equa allocazione delle risorse e rispetti la qualità di servizio prevista. Una piattaforma maliziosa può tuttavia ignorare le richieste dell agente, introdurre ritardi inaccettabili in situazioni critiche, semplicemente non eseguire il codice dell agente o anche terminare la sua esecuzione senza nessuna notifica.

38 Minacce alla sicurezza Piattaforma contro agente 38 Bisogna fare in modo che agenti su altre piattaforme in attesa di risposta da un agente bloccato su una piattaforma maliziosa non restino a loro volta bloccati in deadlock. Un agente su una piattaforma maliziosa può anche essere messo in livelock. Gli agenti in livelock non sono bloccati in uno stato di attesa infinita come gli agenti in deadlock, ma ricevono continuamente nuovi incarichi da eseguire e non riescono mai a raggiungere i loro obbiettivi Eavesdropping La minaccia classica di eavesdropping implica la intercettazione e il monitoraggio di comunicazioni segrete. La minaccia posta nel caso di sistemi ad agenti mobili tuttavia è ulteriormente aggravata poiché la piattaforma oltre che le comunicazioni può osservare anche ogni istruzione eseguita dall agente, tutti i dati non criptati che porta sulla piattaforma e tutti i dati generati sulla piattaforma. Poiché la piattaforma ha accesso a codice, stato e dati di ogni agente bisognerebbe essere consci del rischio di esporre algoritmi proprietari, segreti commerciali, strategie di negoziazione e altre informazioni riservate. Anche se l agente non espone direttamente informazioni segrete, la piattaforma può fare deduzioni in base al tipo di servizi richiesti e all identità degli agenti con cui comunica Alteration Quando un agente giunge su una piattaforma espone il suo codice e i suoi dati. Poiché un agente nel corso della sua vita potrebbe visitare diverse piattaforme in domini di sicurezza diversi, bisognerebbe prevedere dei meccanismi che assicurino l integrità del codice e dello stato. È possibile riconoscere alterazioni nel codice di un agente se questo porta la firma digitale del suo autore. Non è stata ancora trovata invece una soluzione generale al problema del riconoscimento di alterazioni, maliziose o involontarie, dello stato di un agente e dei dati da esso prodotti durante l esecuzione su una piattaforma compromessa. I rischi risultanti da un agente che si sposta dalla sua piattaforma iniziale ad un altra piattaforma sono indicati come single-hop problem, mentre i rischi risultanti da un agente che visita numerose piattaforme sono indicati come multi-hop problem.

39 Minacce alla sicurezza Altri contro sistema 39 La piattaforma può anche alterare le comunicazioni tra agenti, per esempio corrompendo i dati contenuti in una transazione finanziaria o anche modificando il contenuto dei messaggi perseguendo un scopo preciso. 5.4 Altri contro sistema Questa categoria rappresenta l insieme di minacce in cui entità esterne, anche altri agenti e piattaforme, attaccano la sicurezza di una piattaforma ad agenti. Include unauthorized access, masquerading, denial of service e copy and replay Unauthorized access Utenti, processi ed agenti remoti possono richiedere risorse per le quali non sono autorizzati. Lo stesso sistema che ospita la piattaforma deve essere adeguatamente protetto affinché non sia possibile ottenere il controllo del sistema operativo e di conseguenza di tutte le risorse della macchina. L amministrazione remota di una piattaforma, comprese le sue politiche di sicurezza, è una caratteristica spesso desiderata ma che può divenire oggetto di attacco Masquerading Sia un agente che una piattaforma su sistemi remoti possono assumere identità fasulle e richiedere servizi e risorse per i quali non sono autorizzati. Gli attacchi di questo tipo possono anche prevedere la collaborazione di agenti remoti e piattaforme in modo da ingannare il sistema oggetto dell attacco Denial of service I servizi offerti dalla piattaforma e dai suoi agenti spesso sono accessibili anche da remoto, rendendo in questo modo possibile un comune attacco di tipo denial of service. Inoltre la piattaforma risente anche di attacchi di questo tipo portati al sistema operativo sottostante e ai protocolli di comunicazione Copy and replay Una entità che intercetti un agente o un messaggio in transito tra piattaforme diverse può tentare di farne una copia e ritrasmetterla in seguito. Ad esempio un ordine di acquisto potrebbe essere copiato e replicato numerose volte, facendo acquistare quantità maggiori di quelle previste.

40 Contromisure convenzionali Crittografia 40 6 Contromisure convenzionali Molte delle tecniche di sicurezza convenzionali usate nelle attuali applicazioni distribuite, spesso basate sul modello client-server, risultano utili come contromisure nel contesto del paradigma ad agenti o ad agenti mobili. Inoltre ci sono numerose estensioni alle tecniche convenzionali e tecniche sviluppate specificamente per controllare codice mobile e contenuti eseguibili, come per le applet Java, che sono applicabili alla sicurezza dei sistemi ad agenti. Particolarmente importante è l utilizzo della crittografia a chiave pubblica, principalmente nella forma delle firme digitali e attraverso una adeguata infrastruttura che permetta l emissione e la revoca di certificati. 6.1 Crittografia Fino all avvento dei computer uno dei principali limiti alla crittografia era, oltre al grado di abilità del codificatore nell eseguire le trasformazioni necessarie, la difficoltà di passare velocemente da un metodo crittografico all altro. Nonostante ciò, soprattutto in ambiti militari, è sempre stato essenziale poter cambiare il metodo crittografico all istante, qualora fosse sorta la necessità. Questi requisiti tra loro in conflitto hanno portato al modello in figura. Gli intrusi passivi ascoltano semplicemente Gli intrusi attivi possono modificare i messaggi Testo in chiaro Cifratura Chiave di cifratura Testo cifrato C = E k (P) Decifratura Chiave di decifratura Testo in chiaro Figura 11 Modello crittografico

41 Contromisure convenzionali Crittografia 41 I messaggi da codificare, detti testi in chiaro, vengono trasformati da una funzione che è parametrizzata da una chiave. L uscita del processo di codifica, detto testo cifrato, viene quindi trasmessa verso la destinazione. Viene indicata con C = E k (P) la codifica del testo in chiaro P utilizzando la chiave k per produrre il testo cifrato C. In modo simile, P = D k (C) rappresenta la decodifica di C per produrre nuovamente il testo in chiaro. In ogni caso si assume che il nemico o l intruso, anche se riuscisse ad ascoltare e trascrivere il testo cifrato completo, non potrebbe facilmente decodificarlo in quanto egli, a differenza del corretto destinatario, non sa qual è la chiave per decodificare Cifrari a sostituzione e trasposizione I metodi di cifratura più semplici, e in passato molto utilizzati, sono quelli basati sui cifrari a sostituzione e sui cifrari a trasposizione. In un cifrario a sostituzione ogni lettera o gruppo di lettere viene rimpiazzato da un altra lettera o gruppo di lettere in modo da mascherarli. In assoluto uno dei più vecchi e noti cifrari è quello noto come cifrario di Cesare, in cui ogni lettera viene sostituita dalla lettera seguente a distanza di tre posti nell alfabeto, ad esempio a diventa d, b diventa e. Dei possibili miglioramenti sono quelli di trasporre l alfabeto del testo cifrato di k lettere anziché delle solite 3, oppure di avere ogni simbolo del testo in chiaro, diciamo per semplicità le 26 lettere, mappato in qualche altro simbolo. Un sistema di questo tipo viene detto di sostituzione monoalfabetica. Anche se le combinazioni possibili da provare in un attacco basato sulla forza bruta sono elevate, è possibile violare il cifrario data una piccola quantità di testo cifrato, sfruttando le proprietà statistiche dei linguaggi naturali, in cui le singole lettere e le loro combinazioni hanno frequenze diverse. I cifrari a sostituzione conservano l ordine dei simboli del testo in chiaro ma li trasformano. I cifrari a trasposizione, al contrario, riordinano le lettere ma non le trasformano. Un tipico esempio è il cifrario a trasposizione per colonne, che si basa su una tabella dove il testo in chiaro è scritto orizzontalmente, per righe, mentre il testo cifrato viene letto per colonne, nell ordine indicato da una chiave segreta. Anche questo metodo è tuttavia violabile con relativa facilità ipotizzando una possibile porzione di testo in chiaro e verificando le varie possibilità.

42 Contromisure convenzionali Crittografia a chiave segreta Crittografia a chiave segreta I metodi di crittografia più tradizionali prevedono che la chiave usata durante la fase di codifica sia uguale a quella da usare in fase di decodifica. In tale contesto risulta di primaria importanza tenere riservata tale chiave e gli algoritmi sono perciò definiti a chiave segreta. Storicamente il problema della distribuzione delle chiavi è stato sempre il punto debole della maggior parte dei crittosistemi. Non importa quanto sia sicuro un sistema, se un intruso riesce ad entrare in possesso della chiave, il sistema perde valore. Il problema risulta tanto più grave in quanto la chiave deve essere distribuita a tutti gli utenti, sia quelli interessati alla codifica e trasmissione che quelli interessati alla ricezione e decodifica DES Il DES (Data Encryption Standard) venne realizzato dall IBM e adottato come standard ufficiale dal governo statunitense nel In seguito fu adottato estesamente dalle aziende che si occupavano di sicurezza. In questo schema, il testo in chiaro viene codificato in blocchi di 64 bit che generano 64 bit di testo cifrato; l algoritmo, parametrizzato da una chiave di 56 bit, ha 19 passi distinti. Tuttavia, a dispetto della apparente complessità, il DES è essenzialmente un cifrario a sostituzione monoalfabetico che utilizza un carattere di 64 bit. Ogni volta che viene dato in ingresso lo stesso testo in chiaro di 64 bit, in uscita si ha lo stesso testo cifrato di 64 bit. Per aumentare la complessità, il DES può venire concatenato in vari modi. Un esempio è la concatenazione a blocchi del cifrario, dove ogni blocco di testo in chiaro viene messo in or esclusivo con il precedente blocco di testo cifrato prima di essere codificato. Nella sua forma originale comunque il DES non è più sicuro; nel 1994 ad esempio è stato presentato un progetto dettagliato di una macchina che può forzare il DES mediante una ricerca esaustiva in circa quattro ore. Un altra cosa è invece la tripla codifica, in cui vengono usate due chiavi e tre passi. Nel primo passo il testo in chiaro viene codificato con la prima chiave; nel secondo passo viene eseguita una decifrazione usando la seconda chiave; infine viene eseguita un altra codifica usando di nuovo la prima chiave. Viene usata la modalità EDE invece dell EEE perché in questo

43 Contromisure convenzionali Crittografia a chiave pubblica 43 modo un computer che utilizza la codifica tripla può parlare con quei computer che utilizzano la codifica singola semplicemente impostando la seconda chiave uguale alla prima. 6.3 Crittografia a chiave pubblica Nel 1976 due ricercatori della Stanford University, Diffie e Hellman proposero un tipo di crittosistema radicalmente nuovo, nel quale le chiavi di cifratura e decifratura fossero differenti, e la chiave di decifratura non potesse essere derivata da quella di cifratura. Il metodo viene definito a chiave pubblica in quanto esso prevede che ogni utente possegga due chiavi: una chiave pubblica, nota a tutti e usata per cifrare i messaggi da inviare a quell utente, e una chiave privata, nota solo all utente e usata per decifrare i messaggi RSA Un algoritmo di crittografia a chiave pubblica molto utilizzato è l RSA, che deve il suo nome ai tre ricercatori del MIT che lo hanno pubblicato: Rivest, Shamir e Adleman. La sicurezza del metodo si basa sulla difficoltà di fattorizzare i numeri grandi: i matematici hanno provato a fattorizzare i grandi numeri per almeno 300 anni e l esperienza accumulata suggerisce che è un problema molto difficile. A grandi linee possiamo descrivere il metodo come una sequenza di quattro passi. 1. Scegliere due grandi numeri primi, tipicamente più grandi di , p e q. 2. Calcolare n = p x q e z = (p-1) x (q-1). 3. Scegliere un numero d che sia primo rispetto a z. 4. Trovare e tale che (e x d) mod z = 1. Usando questi parametri calcolati in anticipo è possibile iniziare la cifratura. Il testo in chiaro viene diviso in blocchi di k bit, dove k è il più grande intero tale che 2 k < n, in modo che ogni porzione di testo in chiaro P ricada nell intervallo 0 P < n. A questo punto per cifrare un messaggio P basta calcolare C = P e mod n, mentre per decifrare C si può calcolare P = C d mod n. È possibile provare che per tutti i P nel dominio specificato le funzioni di cifratura e decifratura sono inverse.

44 Contromisure convenzionali Crittografia a chiave pubblica Sintesi di messaggi Una funzione di sintesi crittografica è simile ad una checksum. La differenza principale è che mentre una checksum è progettata per rilevare alterazioni accidentali nei dati, le funzioni di sintesi vengono progettate per rilevare alterazioni deliberate. Quando un messaggio viene elaborato da una funzione di sintesi crittografica, come risultato si ottiene una breve sequenza di bit, nota come hash o message digest. Anche le più piccole modifiche apportate al messaggio tipicamente risultano in grosse differenze nella sintesi ottenuta. Le funzioni di sintesi non richiedono l uso di chiavi crittografiche. Due funzioni di hash molto utilizzate sono MD5, la quinta di una serie di funzioni di sintesi progettate da Ron Rivest, e SHA (Secure Hash Algorithm), sviluppata dalla NSA e standardizzata dal NIST Firme digitali L autenticità di molti documenti legali, finanziari e altri ancora è determinata dalla presenza o dall assenza di una firma autografa. Tuttavia i sistemi telematici eliminano lo scambio fisico di documenti cartacei ed è quindi necessario trovare soluzioni alternative. Essenzialmente, ciò che serve è un sistema col quale ogni corrispondente possa inviare un messaggio firmato ad un altro corrispondente in modo che: il destinatario possa verificare l identità rivendicata dal mittente; il mittente non possa in seguito disconoscere il contenuto del messaggio firmato; il destinatario non abbia la possibilità di inventarsi da solo il messaggio firmato. Fortunatamente, la crittografia a chiave pubblica può dare un contributo importante. Le firme digitali in questo caso si ottengono applicando un algoritmo di cifratura a chiave pubblica ad una sintesi crittografica del testo in chiaro. La sintesi del messaggio viene cifrata usando la chiave privata del mittente ed il risultato, che costituisce la firma digitale, viene trasmesso assieme al testo in chiaro, in modo da fornire una prova della sua autenticità Certificati a chiave pubblica Un certificato a chiave pubblica può essere immaginato come l equivalente digitale di un passaporto. Viene rilasciato da una organizzazione di fiducia e permette l identificazione del portatore. Una organizzazione fidata che rilascia certificati a chiave pubblica è nota

45 Contromisure convenzionali Secure Sockets Layer 45 come una autorità di certificazione (CA). L autorità può essere immaginata come un pubblico notaio: per ottenere un certificato da una autorità di certificazione, bisogna fornire prova della propria identità; l autorità firma il certificato solo una volta che sia sicura che il richiedente rappresenti effettivamente l organizzazione che dice di rappresentare, attestando in questo modo la validità delle informazioni contenute all interno del certificato. Un certificato a chiave pubblica contiene diversi campi, tra i quali: issuer rappresenta l autorità che ha rilasciato il certificato; se un utente si fida dell autorità e se il certificato è valido, allora può fidarsi del certificato; validity ogni certificato ha una data di scadenza e questa informazione dovrebbe essere controllata per verificare la validità del certificato; subject racchiude informazioni sulla entità identificata dal certificato; public key il contributo informativo principale trasportato da un certificato è di solito costituito dalla chiave pubblica del subject; signature rappresenta la firma digitale apposta al certificato dalla autorità che lo ha rilasciato; la firma è ottenuta usando la chiave privata dell autorità ed assicura la validità del certificato. 6.4 Secure Sockets Layer Secure Sockets Layer (SSL) è il protocollo più estesamente usato per implementare la crittografia sul Web. È stato sviluppato da Netscape nel 1994 e con la spinta della comunità Internet si è evoluto fino a diventare uno standard. Attualmente è sotto il controllo della Internet Engineering Task Force (IETF) che ne ha rilasciato una nuova versione sotto il nome di Transport Layer Security (TLS). Le differenze tra SSL 3.0 e TLS 1.0 sono tuttavia minime. SSL costituisce una evoluzione sicura delle socket standard TCP/IP, usate per le comunicazioni Internet. Lo strato di sicurezza è aggiunto tra il livello del trasporto ed il livello delle applicazioni nello stack del protocollo standard TCP/IP. L applicazione più comunemente usata con SSL è Hypertext Transfer Protocol (HTTP), il protocollo per le pagine Web su Internet, anche se possono essere usate con SSL molte altre applicazioni, come Net News Transfer Protocol (NNTP), Telnet, Lightweight Directory Access Protocol (LDAP) e File Transfer Protocol (FTP). Anche il protocollo Java RMI,

46 Contromisure convenzionali Secure Sockets Layer 46 che pure è costruito sulle socket standard TCP/IP, può essere adattato per funzionare al di sopra del protocollo SSL. Application Layer HTTP, NNTP, Telnet, FTP, RMI Secure Socket Layer SSL Transport Layer TCP Internet Layer IP Figura 12 Stack di protocolli TCP/IP con SSL Una delle ragioni della efficacia del protocollo SSL è che usa una combinazione di processi crittografici per garantire sicurezza alle comunicazioni su reti pubbliche: crittografia a chiave pubblica per fornire autenticazione; crittografia a chiave segreta per fornire riservatezza; firme digitali per garantire l integrità dei dati. Le comunicazioni basate su SSL cominciano con uno scambio di informazioni tra client e server, chiamato SSL handshake, che ha tre principali obbiettivi: negoziare i meccanismi e le impostazioni di cifratura; autenticare reciprocamente le identità; garantire la riservatezza dei messaggi Negoziazione La sessione SSL comincia con una negoziazione tra le due parti su quali meccanismi di cifratura verranno usati. Questa scelta riguarda i protocolli per lo scambio di chiavi pubbliche, gli algoritmi a chiave segreta e la dimensione delle chiavi che è possibile usare per cifrare i dati, le funzioni di sintesi crittografica. In pratica il client descrive al server quali meccanismi di sicurezza ha a disposizione, e il server sceglie la migliore impostazione accettabile per entrambi Autenticazione Anche se nel protocollo SSL l autenticazione è opzionale, spesso essa viene richiesta dal client ed in alcune applicazioni anche dal server. Ad esempio in una transazione di commercio elettronico sul Web, il client ha interesse ad autenticare il server. Quest ultimo, per provare che appartiene all organizzazione che dichiara di rappresentare, invia il suo certificato a chiave pubblica al client. Se il certificato è valido, il client può essere sicuro dell identità del server.

47 Contromisure convenzionali Secure Sockets Layer 47 Il client ed il server si scambiano poi informazioni che permettono loro di accordarsi su una stessa chiave segreta. Per esempio, nel caso dell RSA, il client usa la chiave pubblica del server, ricavata dal certificato ricevuto, per cifrare l informazione sulla chiave segreta ed inviarla al server. Solo il server può decifrare questo messaggio dal momento che è richiesta la sua chiave privata Invio di dati cifrati Sia il client che il server hanno ora accesso alla stessa chiave segreta. Con ogni messaggio, essi usano la funzione di sintesi crittografica scelta in precedenza e l informazione segreta che condividono per calcolare l HMAC, un codice di autenticazione simile alle sintesi crittografiche ma basato su una chiave segreta, da aggiungere al messaggio. Poi usano la chiave segreta e gli algoritmi già negoziati per cifrare il testo originale insieme all HMAC. Il client ed il server possono quindi comunicare in maniera sicura scambiando tra loro dati cifrati e autenticati. Client hello Client Certificate (optional) Client key exchange (optional) Certificate verify (optional) Change cipher spec Finished Encrypted data Server Server hello Certificate (optional) Certificate request (optional) Server key exchange (optional) Server hello done Change cipher spec Finished Encrypted data Figura 13 Messaggi SSL

48 Contromisure nei sistemi ad agenti Proteggere la piattaforma 48 7 Contromisure nei sistemi ad agenti Come già detto, le tecniche di sicurezza tradizionali sono spesso impiegate con successo anche nell ambito dei sistemi ad agenti. Tuttavia in questi sistemi possono sorgere problemi e requisiti non affrontati nelle applicazioni tradizionali, che necessitano di soluzioni ad hoc. Nell analisi delle contromisure studiate apposta per i sistemi ad agenti è conveniente analizzare separatamente le tecniche che possono essere applicate alla protezione delle piattaforme da quelle per la protezione degli agenti che sono in esecuzione su di esse. Inoltre è importante notare che mentre alcune tecniche permettono di prevenire gli attacchi alla sicurezza altre sono in grado soltanto di fornire a posteriori prove dell attacco, in modo da poter attribuire le giuste responsabilità e fungere così da deterrente. Contromisura Categoria Oggetto Signed code Rilevamento Piattaforma State appraisal Rilevamento Piattaforma Path histories Rilevamento Piattaforma Partial result encapsulation Rilevamento Agente Mutual itinerary recording Rilevamento Agente Replication and voting Rilevamento Agente Execution tracing Rilevamento Agente Software-based fault isolation Prevenzione Piattaforma Safe code interpretation Prevenzione Piattaforma Attribute certificate Prevenzione Piattaforma Proof carrying code Prevenzione Piattaforma Environmental key generation Prevenzione Agente Encrypted functions Prevenzione Agente Obfuscated code Prevenzione Agente Figura 14 Strumenti di contromisura 7.1 Proteggere la piattaforma Uno dei principali problemi nella progettazione e nell implementazione di un sistema ad agenti è assicurarsi che gli agenti non siano in grado di interferire tra loro o con la piattaforma sottostante. Un approccio comune per raggiungere questo obbiettivo prevede di stabilire domini isolati per ciascun agente e la piattaforma e controllare tutti

49 Contromisure nei sistemi ad agenti Proteggere la piattaforma 49 gli accessi inter-dominio. In termini tradizionali questo approccio è noto come reference monitor. Una qualsiasi implementazione di reference monitor dovrebbe avere le seguenti caratteristiche: essere invocato sempre e non essere scavalcabile, in modo da mediare tutti gli accessi; essere protetto da manomissioni e alterazioni; essere abbastanza compatto da poter essere ben analizzato e testato. Varie implementazioni di reference monitor sono in uso fin dai primi anni 80 e sfruttano una serie di tecniche di sicurezza convenzionali, spesso utilizzabili anche nei sistemi ad agenti: meccanismi di isolamento tra i diversi processi e dal processo di controllo; meccanismi di controllo di accesso alle risorse computazionali; tecniche crittografiche di cifratura delle informazioni scambiate; tecniche crittografiche di identificazione e autenticazione di utenti e processi; registrazione di tutti gli eventi rilevanti dal punto di vista della sicurezza. Tecniche sviluppate più recentemente e destinate a codice mobile e sicurezza per la mobilità di agenti sono per lo più una evoluzione di queste linee tradizionali. Tra le tecniche sfruttate per la protezione di piattaforme ad agenti ricordiamo le seguenti: software-based fault isolation; safe code interpretation; signed code; attribute certificates; state appraisal; path histories; proof carrying code Software-based fault isolation Questa tecnica, come suggerisce il nome, è un metodo per isolare le applicazioni in domini di sicurezza distinti garantiti da uno strato software. La tecnica, nota comunemente come sandboxing, permette l esecuzione sicura di codice non fidato. Infatti il codice insicuro viene trasformato in modo che tutti gli accessi siano confinati ai segmenti di codice e dati contenuti nel dominio di sicurezza.

50 Contromisure nei sistemi ad agenti Proteggere la piattaforma 50 In particolare le implementazioni esistenti di sandbox escludono dal dominio di sicurezza le risorse del file system locale, gli accessi alla rete, le variabili di ambiente, gli accessi a basi di dati; sono previsti vari modi per garantire a particolari programmi la possibilità di accedere a risorse esterne al dominio di sicurezza, ma ciò viene concesso solo se esplicitamente indicato nelle politiche di sicurezza definite dall utente. Le implementazioni possono essere anche abbastanza efficienti se la maggior parte del codice cade in un dominio considerato sicuro, dal momento che i moduli contenuti all interno del dominio di sicurezza non richiedono overhead di esecuzione Safe code interpretation I sistemi ad agenti sono spesso sviluppati usando linguaggi di programmazione o di scripting interpretati. La motivazione principale è quella di supportare piattaforme ad agenti su sistemi eterogenei dal punto di vista sia hardware che software. Inoltre il più alto livello di astrazione fornito da un linguaggio interpretato può agevolare lo sviluppo del codice di un agente. L idea alla base dell interpretazione sicura del codice è che i comandi considerati insicuri siano o resi sicuri o negati agli agenti. Uno dei più diffusi linguaggi interpretati è oggi Java. Il linguaggio e l ambiente di esecuzione assicurano la sicurezza attraverso una serie di diversi meccanismi: è un linguaggio fortemente tipizzato, prevede una verifica statica sul byte-code scaricato, oltre che una separazione nei name space e la possibilità di richiamare solo i metodi pubblici delle classi appartenenti a package diversi, impedisce di accedere liberamente alla memoria manipolando dei puntatori. Il modello di sicurezza seguito è quello del sandboxing, usato per isolare gli accessi alla memoria e ai metodi, e mantenere domini di esecuzione mutualmente esclusivi. Un security manager media tutti gli accessi alle risorse di sistema, fungendo in effetti da reference monitor. Inoltre Java supporta la mobilità del codice, il codice firmato, il richiamo di metodi su oggetti remoti, la serializzazione ed è implementato su piattaforme eterogenee. Tutte queste caratteristiche lo rendono l ambiente d elezione per lo sviluppo di sistemi ad agenti, come dimostrano le Aglets di IBM, Mole, Ajanta, Vojager, oltre a JADE naturalmente. Tuttavia sono stati sottolineati da più parti i grossi limiti di Java nella gestione delle quote di memoria, CPU e risorse di rete consumate dai diversi thread e nel supportare la mobilità dei thread.

51 Contromisure nei sistemi ad agenti Proteggere la piattaforma 51 Probabilmente il più conosciuto interprete sicuro per linguaggi di scripting è Safe Tcl, usato ad esempio nello sviluppo del sistema Agent Tcl. Safe Tcl si basa sul concetto di padded cell, dove un secondo interprete controlla ogni comando potenzialmente pericoloso prima che questo venga eseguito dall interprete Tcl principale. Il termine padded cell si riferisce a questa tecnica di isolamento e controllo di accesso, che costituisce la base per realizzare il concetto di reference monitor. In genere comunque i linguaggi di scripting soffrono di una progettazione spesso priva di un modello di sicurezza e che lascia principalmente al momento della implementazione tutte le decisioni sulla sicurezza e la protezione degli accessi Signed code Una tecnica fondamentale per proteggere un sistema ad agenti è contrassegnare il codice o altri oggetti con una firma digitale. Una firma digitale serve come strumento per garantire l autenticità di un oggetto, la sua origine e la sua integrità. Tipicamente chi firma il codice è il creatore dell agente, l utente dell agente, o qualche entità che comunque ha analizzato l agente. Poiché un agente opera per conto di un utente o di una organizzazione, i sistemi ad agenti comunemente usano la firma di un utente come indicazione dell autorità sotto cui l agente opera. La firma del codice richiede l uso di crittografia a chiave pubblica, che si basa su una coppia di chiavi associate ad una entità, delle quali una è tenuta privata e l altra è resa pubblicamente disponibile. La firma digitale beneficia grandemente della presenza di una infrastruttura a chiavi pubbliche, dal momento che i certificati contenenti l identità di una entità e la sua chiave pubblica possono essere prontamente rintracciati e verificati. Passare il codice di un agente attraverso una funzione di hash non reversibile, che fornisce una impronta o una sintesi univoca del codice, e poi cifrare il risultato usando la chiave privata dell entità che lo contrassegna costituisce una firma digitale. Poiché la sintesi è unica, e quindi legata al codice, la firma relativa funge anche da garanzia di integrità. Il codice dell agente, la firma e il certificato a chiave pubblica possono essere inviati ad un destinatario, il quale può facilmente verificare l autenticità del codice e la sua provenienza.

52 Issuer Signature Contromisure nei sistemi ad agenti Proteggere la piattaforma Attribute certificates Poiché spesso gli agenti operano per conto di una autorità responsabile dei loro comportamenti, essi devono seguire le politica di sicurezza stabilite. Piuttosto che accorpare i privilegi prescritti dalla politica all interno dell agente, è possibile porre queste informazioni in un oggetto esterno, l attribute certificate. L autorità che rilascia l attribute certificate ne imposta il contenuto in modo da governare l uso delle risorse computazionali e dei meccanismi di sicurezza da parte dell agente. L attribute certificate deve poi essere firmato dal suo emittente per proteggere da alterazioni le informazioni attinenti alla sicurezza dell agente. Gli elementi di un attribute certificate, mostrati in Figura 15, includono l identità del proprietario (formata da una sintesi sicura del codice e dei dati dell agente), l identità dell emittente, un identificatore degli algoritmi usati per proteggere il certificato, la durata del certificato, e gli attributi stessi, i quali possono essere espressi come semplici coppie chiave-valore o attraverso espressioni sintattiche più complesse. Questi elementi possono essere usati per stabilire la validità del certificato e il legame tra certificato e agente. Version Owner Signature Algorithm Certificate Serial Number Validity Period Attributes Estensions Figura 15 Attribute Certificate Quando l agente si sposta tra le piattaforme, porta con sé l attribute certificate che gli è stato rilasciato e l identity certificate dell entità (utente o altra autorità) che ha assegnato i privilegi. Una piattaforma che riceve l agente determina la validità dei certificati, verifica l identità dell emittente, probabilmente appoggiandosi ad una infrastruttura di chiavi pubbliche, e controlla che ci sia concordanza tra l assegnazione di privilegi suggerita dai certificati e la politica della piattaforma. Diversi principal (ad esempio l utente e l autore di un agente) possono assegnare privilegi sia firmando e rilasciando congiuntamente un singolo attribute certificate ad un agente, oppure rilasciando individualmente i propri

53 Contromisure nei sistemi ad agenti Proteggere la piattaforma 53 certificati e lasciando che vengano interpretati e validati in base alla politica della piattaforma. Mentre c è variabilità nel numero e tipo di principal interessati ad impostare le politiche, sembra che in pratica ne bastino solo alcuni. Sfortunatamente, questi principal possono differire a seconda dell applicazione e della infrastruttura di sicurezza in cui operano, rendendo difficile inserire in un sistema ad agenti un meccanismo di privilegi generale, che soddisfi i bisogni di tutte le applicazioni. L uso degli attribute certificate per esprimere politiche in termini di privilegi concessi a principal identificati, comunque, permette di realizzare una infrastruttura estensibile che può potenzialmente soddisfare i bisogni della maggior parte delle applicazioni. Inoltre, poiché un attribute certificate è un oggetto firmato le cui manomissioni possono essere rilevate, può fungere da contromisura ulteriore per quei sistemi ad agenti che altrimenti sarebbero vulnerabili agli attacchi portati da piattaforme maliziose attraverso modifiche dei privilegi concessi agli agenti State appraisal L obbiettivo di questa tecnica è assicurare che un agente non sia stato in qualche modo danneggiato attraverso alterazioni delle sue informazioni di stato. Il successo di tale tecnica si basa sull assunto che alterazioni dannose dello stato di un agente possano essere riconosciute in modo da poter prendere le necessarie precauzioni. Sia l autore che l utente di un agente producono funzioni di stima dello stato che diventano parte del codice dell agente. Un utente tipicamente introduce limiti allo stato per ridurre i rischi o i costi. Quando sia l autore che l utente firmano l agente, le rispettive funzioni di stima sono protette da modificazioni non rilevabili. Una piattaforma usa poi le funzioni per verificare la consistenza dello stato di ogni agente che sopraggiunge, in modo da applicare le giuste politiche di sicurezza. Non è tuttavia chiaro quanto la teoria si possa applicare alle situazioni reali, dal momento che lo spazio degli stati di un agente può essere anche molto vasto, e mentre è facile generare funzioni di stima per prevenire attacchi ovvi, attacchi più sofisticati possono essere considerevolmente più difficili da prevedere e riconoscere. Gli stessi sviluppatori della tecnica riconoscono infatti che non sempre è possibile distinguere i risultati normali dalle alternative fasulle.

54 Contromisure nei sistemi ad agenti Proteggere la piattaforma Path history L idea alla base di questa tecnica è di mantenere una registrazione autenticabile delle piattaforme visitate da un agente, in modo che una nuova piattaforma possa determinare se eseguire l agente e quali limitazioni di accesso alle risorse applicare. Per costruire una registrazione del percorso è necessario che ogni piattaforma aggiunga una voce firmata al percorso, indicando la sua identità e l identità della prossima piattaforma da visitare, e fornire la registrazione del percorso completo alla piattaforma successiva. Per prevenire modificazioni la firma della nuova voce nel percorso deve includere la voce precedente nel calcolo della sintesi di messaggio. La nuova piattaforma può sia verificare se si fida dell ultima piattaforma visitata dall agente, o controllare l intera registrazione del percorso per verificare le singole voci e decidere di conseguenza. Mentre la tecnica non impedisce ad una piattaforma di assumere comportamenti maliziosi, funge da forte deterrente poiché ogni voce del percorso è firmata e non ripudiabile. Un ovvio svantaggio è che la verifica del percorso diventa computazionalmente più pesante man mano che il percorso diventa più lungo Proof carrying code L approccio preso da questa tecnica obbliga l autore di ogni agente a provare formalmente che l agente possegga delle caratteristiche di sicurezza negoziate in precedenza con l ambiente di esecuzione e la sua politica di sicurezza. Una rappresentazione della semantica del programma viene generata direttamente dal codice per accertarsi della corrispondenza con la prova che accompagna il codice. Ogni tentativo di manomissione nel codice o nella prova risulta o in un errore in fase di verifica o in una modificazione comunque sicura del codice. In questo senso l approccio in questione è di tipo preventivo, mentre l uso di codice firmato è uno strumento di identificazione usato come deterrente, ma che non previene l esecuzione di codice non sicuro. Ricerche iniziali hanno mostrato l applicabilità di questa tecnica per la gestione sicura della memoria e per l accesso controllato alle risorse, rendendone possibile in alcuni ambiti l uso in alternativa al sandboxing. Ci sono comunque alcuni potenziali problemi da risolvere prima che l approccio risulti applicabile praticamente, come la creazione di standard per esprimere le politiche di

55 Contromisure nei sistemi ad agenti Proteggere gli agenti 55 sicurezza e la realizzazione di strumenti di generazione delle prove. Inoltre la tecnica è legata all ambiente hardware e software di esecuzione del codice. 7.2 Proteggere gli agenti Mentre le contromisure tese alla protezione della piattaforma sono una diretta evoluzione dei meccanismi tradizionali usati nei sistemi distribuiti ed enfatizzano la prevenzione, le contromisure tese alla protezione degli agenti spingono verso tecniche di rilevamento a posteriori, da usare come deterrente. Ciò è dovuto al fatto che l agente, essendo completamente in balia della piattaforma su cui risiede, non può prevenire il verificarsi di comportamenti maliziosi, ma può essere al massimo in grado di rilevarli. Tra le tecniche di protezione degli agenti utilizzabili in contesti generici sono da citare le seguenti: partial result encapsulation; mutual itinerary recording; replication and voting; execution tracing; environmental key generation; encrypted functions; obfuscated code Partial result encapsulation Un approccio usato per rilevare manomissioni da parte di piattaforme maliziose è di incapsulare i risultati delle azioni di un agente, ad ogni nodo visitato, per una verifica successiva, quando l agente torna al suo punto di origine o sui nodi intermedi che godono di particolare fiducia. In generale ci sono tre modi alternativi di incapsulare i risultati parziali: fornire all agente gli strumenti per incapsulare le informazioni; affidarsi alle capacità di incapsulazione della piattaforma; affidarsi ad una terza parte fidata per contrassegnare una impronta digitale dei risultati. Anche se nessuna delle alternative proposte impedisce comportamenti maliziosi delle piattaforme, permettono di rilevare alcuni tipi di alterazioni.

56 Contromisure nei sistemi ad agenti Proteggere gli agenti 56 Questo metodo è usato soprattutto nella forma di partial results authentication codes, che sono checksum crittografiche basate su algoritmi a chiave segreta, anche se esistono varianti basate su chiavi pubbliche. Questa tecnica richiede che l agente e la piattaforma di origine mantengano o generino in maniera incrementale una lista di chiavi usate nelle computazioni delle checksum. Una volta che la chiave viene usata per incapsulare le informazioni raccolte, l agente la distrugge prima di spostarsi sulla piattaforma successiva, garantendo l integrità durante le varie tappe Mutual itinerary recording Una variazione interessante della path history è uno schema generale che permette la registrazione dell itinerario di un particolare agente da parte di un agente cooperante e viceversa, in maniera che ci sia un sostegno reciproco. Quando si sposta da una piattaforma ad un altra, un agente invia le informazione sulla piattaforma precedente, quella corrente e quella successiva all agente collaboratore attraverso un canale autenticato. L idea alla base di questo schema è che solo poche piattaforme siano maliziose e che quindi, anche se l agente incappasse in una piattaforma maliziosa, sia improbabile che questa collabori con un altra piattaforma maliziosa visitata dal suo compagno. Perciò, dividendo le operazioni dell applicazione tra due agenti, certi comportamenti potenzialmente dannosi di una piattaforma possono essere rilevati Replication and voting L idea è che piuttosto che affidare una data funzione ad una singola copia di un agente, siano usate numerose copie dello stesso agente. Anche se una piattaforma non fidata può modificare alcune copie dell agente, la presenza di un elevato numero di replicati garantisce che la computazione sia portata a termine con successo. L ipotesi è che la maggior parte delle piattaforme abbia un comportamento corretto e che la maggior parte degli agenti arrivi senza alterazioni a risultati equivalenti ad ogni passo. La tecnica sembra appropriata per applicazioni specializzate dove gli agenti possono essere duplicati senza problemi, il problema può essere formulato come una computazione a più stadi, e la sopravvivenza è un requisito fondamentale. Uno

57 Contromisure nei sistemi ad agenti Proteggere gli agenti 57 svantaggio ovvio è il consumo addizionale di risorse richiesto dalle diverse copie dell agente Execution tracing Questa è una tecnica per individuare modificazioni non autorizzate di un agente attraverso la registrazione del comportamento dell agente durante la sua esecuzione su ciascuna piattaforma. La tecnica richiede che ciascuna piattaforma coinvolta crei e mantenga una registrazione o traccia non ripudiabile delle operazioni eseguite dall agente durante la sua permanenza, e di fornire alla fine una impronta crittografica della registrazione. L approccio ha un certo numero di svantaggi, tra cui il più evidente è la dimensione e il numero delle registrazioni da mantenere Environmental key generation Questo schema permette ad un agente di prendere azioni predefinite quando certe condizioni ambientali risultino verificate. L approccio è incentrato sulla costruzione di agenti in modo tale che sotto particolari condizioni ambientali venga generata una chiave, usata per sbloccare una porzione cifrata di codice. Una debolezza dell approccio risiede nel fatto che la piattaforma controlla completamente l agente e così al verificarsi dell evento potrebbe avere libero accesso al codice decodificato invece che eseguirlo semplicemente. Inoltre le politiche di sicurezza adottate dalle piattaforme di solito non permettono l esecuzione di codice generato dinamicamente Encrypted functions L obbiettivo è quello di determinare un metodo attraverso cui del codice mobile possa essere eseguito in un ambiente computazionale non fidato e operare autonomamente senza interazioni con la piattaforma di partenza. L'approccio è di fare eseguire alla piattaforma un programma che realizza una funzione cifrata in modo non reversibile, ossia da cui non è possibile ricostruire la funzione originale. Per esempio si supponga che l agente A voglia che la piattaforma P calcoli una certa funzione f(x), dove x è un dato input, senza che tuttavia P venga a conoscenza di f. Se f può essere cifrata in modo da ottenere un altra funzione E f, allora è possibile far calcolare alla piattaforma E f (x) e decifrare in seguito il risultato per ottenere f(x).

58 Contromisure nei sistemi ad agenti Proteggere gli agenti 58 Sebbene l idea sembri promettente, è necessario trovare appropriati schemi di cifratura che possano trasformare funzioni arbitrarie nella maniera voluta. Inoltre la tecnica non previene altri tipi di attacco all agente, ad esempio il denial of service Obfuscated code La strategia dietro questa tecnica, nota anche come blackbox security, è semplice: mescolare il codice in modo tale che nessuno sia in grado di capire completamente il suo funzionamento, o di modificarlo senza che ciò venga rilevato. Tuttavia non sono note attualmente tecniche per stabilire il livello minimo di complessità necessaria per ottenere il codice originale dell agente attraverso un attacco di tipo reverse engineering.

59 Implementazioni esistenti Telescript 59 8 Implementazioni esistenti Dopo aver analizzato gli strumenti disponibili per prevenire o rilevare gli attacchi che possono essere portati ad un generico sistema ad agenti, può essere utile analizzare come queste varie soluzioni sono adottate dagli ambienti ad agenti esistenti. Citeremo tra i tanti possibili esempi i più significativi, sia perché sono ampiamente diffusi ed utilizzati anche per applicazioni reali, o perché implementano sistemi di sicurezza che si adattano bene alle necessità evidenziate nell uso di JADE. 8.1 Telescript Telescript è stato uno dei primi sistemi ad agenti ad essere messo in commercio. Tuttavia, essendo basato su un linguaggio proprietario e trovandosi a fronteggiare la crescente popolarità di Internet e del linguaggio Java, perse molta della sua appetibilità ed ebbe vita breve. Attualmente la General Magic, proprietaria delle tecnologia Telescript, commercializza un sistema ad agenti sviluppato in linguaggio Java, Odissey, che ne ha raccolto l eredità. Telescript è sostanzialmente un linguaggio interpretato ed orientato agli oggetti per scrivere agenti mobili. Come in altri linguaggi orientati agli oggetti, un programma Telescript è sostanzialmente una collezione di classi organizzate gerarchicamente, con sottoclassi ed ereditarietà multipla. Tuttavia Telescript include anche classi che supportano il multitasking di tipo pre-emptive con diverse priorità. Un singolo ambiente può ospitare processi di numerosi utenti diversi e quindi mostrare gli stessi problemi di sicurezza relativi alle informazioni condivise che si presentano nei sistemi operativi multi-utente. Uno degli aspetti interessanti è il supporto per la migrazione dei processi. In particolare i processi della classe Agent, una sottoclasse della classe Process, possiedono un metodo go. Quando un agente invoca con successo il suo metodo go, l esecuzione viene trasferita in una locazione diversa, anche su un computer remoto. La semplicità di questo modello costituisce tuttora un punto di riferimento con cui qualsiasi sistema ad agenti mobili si deve confrontare. Non tutti i processi tuttavia sono mobili. In particolare i processi della classe Place sono stazionari e costituiscono le locazioni in cui gli agenti possono spostarsi. Quando un

60 Implementazioni esistenti Telescript 60 agente occupa una locazione, riceve un riferimento a quella locazione così che possa sfruttarne i servizi offerti. Ovviamente la sicurezza è un problema di primaria importanza in un ambiente come Telescript, che permette l esecuzione di codice caricato dinamicamente e potenzialmente non sicuro. Il modello di sicurezza di Telescript può essere considerato a quattro livelli: protezione degli oggetti durante l esecuzione; sicurezza e protezione dei processi; protezione del sistema; sicurezza di rete Protezione degli oggetti durante l esecuzione Telescript, come Java, non ha puntatori o operazioni aritmetiche su puntatori. Invece l accesso agli oggetti è possibile solo attraverso le loro interfacce e solo usando riferimenti validi. L interprete di Telescript esegue il controllo dei tipi, gestisce la memoria con garbage collection, supporta le eccezioni, fornisce classi già pronte come le liste che generano eccezioni per gli accessi con indici inappropriati. Dal punto di vista della sicurezza, la cosa più importante è che l interprete funge da reference monitor mediando gli accessi agli oggetti. In questo modo viene imposta una rigorosa incapsulazione dei dati, rendendo i dati ed i metodi privati disponibili solo all interno della classe e delle sottoclassi. Le classi possono essere installate una sola volta e poi sono immutabili. Un agente non può in alcun modo modificare o reinstallare una classe già presente nell ambiente, o installare una classe con un nome uguale per ingannare il meccanismo di binding Sicurezza e protezione dei processi Telescript si basa sull incapsulamento per fornire protezione inter-processo. Inoltre fornisce una serie di meccanismi che assicurano la sicurezza dei processi, quali: identità autenticate associate ad ogni processo; riferimenti protetti in sola lettura agli oggetti; gestione delle quote e delle restrizioni dei privilegi attraverso i permessi; protocolli mediati dal sistema per le comunicazioni inter-processo;

61 Implementazioni esistenti Telescript 61 classi mix-in che permettono agli oggetti di ereditare specifiche funzionalità di sicurezza, come il controllo degli accessi Autorità In Telescript una autorità è un identificatore univoco che denota un particolare individuo o organizzazione, ciò che viene riferito come principal in molti altri sistemi. Ogni processo è associato ad una autorità. Telescript gestisce diversi tipi di autorità, comprese quelle registrate presso una naming authority. Le autorità usate con i dispositivi Telescript portatili sono generate con tecniche crittografiche. Durante la personalizzazione del dispositivo l utente genera una coppia casuale di chiavi RSA. Viene quindi generato un identificativo di autorità applicando una funzione di sintesi non reversibile ad un buffer firmato. In questo modo i dispositivi possono registrare la loro autorità presso i servizi Telescript ed in seguito autenticarsi dimostrando di conoscere la chiave privata usata per generare l autorità. Ogni interprete Telescript viene eseguito sotto una autorità di regione, una autorità privilegiata simile all account di root nei sistemi Unix. In una regione ci possono essere locazioni con differenti autorità, occupati a loro volta da agenti con differenti autorità Riferimenti protetti Tutti gli oggetti devono essere associati ad un processo, proprietario dell oggetto, per evitare di essere distrutti durante la garbage collection. Nel caso di un agente, la proprietà implica il diritto di trasportare con sé l istanza dell oggetto qualora l agente si spostasse. In genere il riferimento ad un oggetto implica la possibilità di invocare i suoi metodi pubblici. Tuttavia un riferimento protetto ad un oggetto non può essere usato per modificare quell oggetto. Un riferimento protetto può essere ottenuto da un altro riferimento usando il metodo protect, che è un metodo pubblico della classe Object ed è ereditato da tutte le istanza di oggetti Permessi I permessi costituiscono uno strumento per limitare il consumo di risorse e restringere le capacità del codice in esecuzione. Un permesso è un oggetto che può specificare l età massima, la dimensione o la priorità di un processo, concedere la possibilità di creare

62 Implementazioni esistenti Telescript 62 un nuovo processo o ancora indicare dove un agente può andare. L interprete Telescript prevede quattro tipi di permessi: native, assegnato dal creatore di un processo; regional, assegnato dall interprete quando arriva o viene creato un nuovo processo; local, assegnato da una locazione quando un agente viene ospitato o un nuovo processo viene creato; temporary, che può essere imposto su blocchi arbitrari di codice. I permessi effettivamente validi in ogni situazione sono calcolati dall interprete come intersezione di tutti i vari permessi posseduti. Quando un processo o un frammento di codice viola i suoi permessi, l interprete solleva una eccezione che di solito provoca la terminazione del processo Spostamenti e incontri Nell esecuzione del comando go di un agente, Telescript permette alla destinazione di scegliere se lasciare entrare o meno l agente. L interprete richiama il metodo entering della destinazione passando come parametri l autorità per cui opera l agente, la sua classe e i suoi permessi. La destinazione può decidere di accettare l agente, anche imponendo dei permessi locali, oppure può negare l ingresso sollevando una eccezione OccupancyDenied o DestinationUnknown. Se la destinazione accetta l agente, l interprete passa un riferimento non protetto dell agente, e l agente riprende l esecuzione nella nuova locazione. Anche l agente può ottenere un riferimento non protetto alla locazione, permettendo così ad ognuno di iniziare una interazione invocando i metodi dell altro. In maniera simile l interprete media i protocolli per gli incontri tra agenti. In una certa misura, le locazioni possono essere usate per fornire un ambiente protetto dove ospitare in maniera sicura agenti potenzialmente dannosi. Un esempio di locazione protetta è il purgatorio, una locazione presente sulle piattaforme Telescript e usata come destinazione per gli agenti che non possono essere per qualche motivo consegnati alle destinazioni indicate. Un agente che viene trasferito nel purgatorio dopo una chiamata a go riceve una eccezione e dei permessi temporanei con una durata molto breve. L intenzione è di fornire una locazione protetta dove l agente possa

63 Implementazioni esistenti Telescript 63 catturare l eccezione e decidere di andare da qualche altra parte. Il purgatorio non ha metodi che l agente possa invocare né si cura delle interfacce implementate dall agente Classi mix-in Le classi mix-in sono classi astratte, che possono essere ereditate da altre classi ma che non possono essere istanziate direttamente. Le classi mix-in, come le interfacce Java, forniscono una forma limitata di ereditarietà multipla. Telescript fornisce classi mix-in relative alla sicurezza che vengono trattate in modo speciale dall interprete: Unmoved, viene sollevata una eccezione se l agente tenta di spostare l oggetto; Uncopied, un tentativo di copiare l oggetto restituisce un riferimento all oggetto originale; Copyrighted, viene applicata una politica configurabile per controllare la generazione di nuove istanze; Protected, l oggetto non può essere modificato in alcun modo dopo la creazione, a parte la possibilità di un cambiamento di proprietario. Le librerie di classi distribuite con Telescript includono altre classi mix-in che permettono di includere nelle definizioni di classe le funzionalità delle liste di controllo di accesso basate sull identità. Queste classi non sono però trattate in nessun modo particolare dall interprete Protezione del sistema Telescript provvede a rendere visibili le risorse del sistema sottostante, come file o accessi alla rete, attraverso oggetti di sistema presenti nell ambiente di esecuzione. Per accedere ad un file, per esempio, uno script dovrebbe istanziare un oggetto ExternalFile, fornendo il percorso e le informazioni rilevanti. Oggetti di questo tipo sono anche sottoclassi di Copyrighted, Unmoved e Uncopied. La politica di accesso è gestita da un oggetto CopyrightEnforcer, gestito dall autorità regionale. Sono protette in questo modo le seguenti classi: ExternalFile, usata per accedere al file system; ControlManager, usata per eseguire funzioni prilegiate di manutenzione, come forzare l uscita dal sistema; ExternalHandle, usata per gestire gli accessi alla rete.

64 Implementazioni esistenti Telescript 64 In circostanze normali, solo funzioni di manutenzione del sistema accedono al file system locale, di solito per scopi quali configurazione, auditing e logging. Inoltre Telescript non permette in alcun modo di eseguire comandi arbitrari sul sistema sottostante Sicurezza di rete Una rete Telescript è un insieme di interpreti interoperanti. È possibile creare reti che includono anche molte diverse regioni, ed ogni regione può impostare le proprie politiche di sicurezza. Inoltre gli agenti si spostano tra le regioni su canali sicuri Politiche di regione La locazione più esterna in ogni interprete è il suo EnginePlace, un processo privilegiato eseguito sotto l autorità regionale. La classe EnginePlace prevede metodi per decidere se ammettere un agente nella regione o meno, per imporre allo stesso agente il rispetto delle politiche regionali e per controllare quali locazioni l agente può visitare. Le politiche di sicurezza regionali possono essere configurate a seconda delle necessità di ambienti particolari Canali sicuri Un canale sicuro è una connessione autenticata e riservata tra regioni diverse. In Telescript gli agenti non sono autenticati singolarmente; invece l autenticazione è relativa alle connessioni tra le singole regioni. Quando arriva un agente, l EnginePlace della destinazione riceve l autorità dell agente, l autorità della regione remota, e il regime di sicurezza applicato alla connessione; in base a queste informazioni ed alla politica regionale attiva decide se fidarsi dell autenticazione dell agente. Per esempio, poiché i dispositivi mono-utente sono considerati come una singola regione, una politica ragionevole nelle comunicazioni con tali dispositivi potrebbe essere di accettare solo agenti la cui autorità sia la stessa della regione remota (già autenticata). Un regime di sicurezza è un insieme predefinito di servizi di sicurezza che devono essere negoziati tra le parti durante l apertura di un canale di comunicazione. Telescript supporta i seguenti regimi:

65 Implementazioni esistenti Aglet 65 identification, quando viene scambiata solo informazione sulle rispettive autorità, senza eseguire alcuna operazione di crittografia; di solito questo viene usato per accessi pubblici, per esempio per ricevere un modulo di iscrizione; registration, che usa autenticazione tramite chiavi pubbliche RSA, scambio di chiavi Diffie-Hellman, e cifratura RC4 per creare un canale sicuro; i dispositivi usano il regime di registrazione quando contattano per la prima volta un servizio Telescript; quando viene applicato questo regime, la politica regionale permette l ingresso esclusivamente a certe classi di agenti di registrazione, e limita le locazioni che gli agenti possono visitare; dopo una registrazione riuscita, l interprete memorizza le informazioni sullo stato dell autenticazione del dispositivi remoto; fast authentication, che usa l algoritmo di cifratura DES sia per autenticare la regione remota che per trasferire in maniera sicura dati segreti dai quali viene generata una chiave di sessione RC4; questo è considerato più veloce che eseguire operazioni con chiavi pubbliche ogni volta che un dispositivo contatta il servizio; re-key, essenzialmente uguale alla registrazione, con autenticazione a chiave pubblica, ma usato solo quando la chiave DES termina o in circostanze nelle quali il dispositivo o il servizio perdono la chiave condivisa; authentication, simile all autenticazione veloce, eccetto il fatto che usa l algoritmo Diffie-Hellman per negoziare una chiave condivisa di sessione RC4. Per i regimi registration, re-key e authentication viene usato uno scambio di autenticazioni asimmetrico, essendo il dispositivo che si autentica presso i servizi Telescript. Come detto i dispositivi si autenticano presso i servizi provando il possesso della chiave privata usata per generare l autorità. Se richiesto, i servizi Telescript si autenticano presso i dispositivi usando un certificato a chiave pubblica. 8.2 Aglet Questo sistema, sviluppato presso i laboratori dell IBM e recentemente reso open source, si basa sul modello delle applet Java, con l obbiettivo di aggiungere alle applet le pontenzialità della mobilità. Il termine aglet è infatti una fusione dei termini agent e

66 Implementazioni esistenti Aglet 66 applet. Il risultato è un modello particolarmente pulito e apprezzabile per la maniera in cui riflette il modello delle applet Modello di sicurezza Il modello di sicurezza sviluppato per le Aglet fornisce all ambiente di esecuzione i meccanismi necessari per applicare misure di sicurezza ad ogni livello. Il modello supporta la definizione flessibile di varie politiche di sicurezza e descrive come e dove applicare tali politiche in un sistema sicuro. Le politiche di sicurezza sono definite da una autorità amministrativa in termini di un insieme di regole che specificano: le condizioni sotto le quali gli agenti possono accedere ai vari oggetti; l autenticazione richiesta per gli utenti e gli altri principal, quali azioni può compiere una entità autenticata, e se tali entità possono delegare i propri diritti; la sicurezza richiesta nelle comunicazioni tra agenti e tra contesti; il grado di responsabilità richiesto per ogni evento rilevante dal punto di vista delle sicurezza. Un agente potrebbe anche non curarsi delle politiche di sicurezza del contesto in cui viene ospitato e di come queste vengano esercitate. In questo caso l utente viene autenticato prima di creare l agente e in seguito la politica viene applicata in maniera automatica. Altri agenti, pur non applicando in prima persona alcun controllo di accesso, potrebbero invece aver bisogno di controllare o influenzare quali politiche siano applicate dal sistema nei loro confronti. Altri ancora potrebbero voler applicare le loro politiche particolari per controllare gli accessi ai loro dati riservati o monitorare le attività rilevanti per la loro sicurezza Identità e principal Un principal è una entità la cui identità può essere autenticata durante il tentativo di accesso ad un sistema. Un principal può essere un individuo, una organizzazione, un processo condiviso o una smart card. Una identità invece consiste principalmente di un nome e altri attributi opzionali. Il modello di sicurezza identifica numerosi principal, ognuno con certi interessi e responsabilità, che possiamo riassumere tra i seguenti tipi: Aglet, una istanza del programma relativo ad un aglet;

67 Implementazioni esistenti Aglet 67 AgletManufacturer, l autore dell aglet (una persona, una compagnia, una terza parte che fornisce servizi di valutazione, ecc.); AgletOwner, l individuo che ha lanciato l esecuzione dell agente, o comunque il principal che si assume la responsabilità, eventualmente anche legale, del comportamento dell agente; Context, l ambiente che esegue l agente; ContextManufacturer, l autore del contesto (uomo, compagnia, ecc.); ContextMaster, l operatore o l amministratore sotto la cui autorità opera il contesto; Domain, un gruppo di contesti posseduti dalla stessa autorità; DomainAuthority, l operatore o l amministratore del dominio. Gli agenti e i contesti sono processi, o meglio thread, che vengono eseguiti per conto di un utente; programmatori, utenti e autorità diverse impongono regole agli agenti e ai contesti, in relazione alla propria posizione sociale, funzionale o organizzativa Agenti Ogni agente ha un suo identificatore che durante tutta la sua vita resta unico e indipendente dal contesto di esecuzione. Il suo valore comunque non è noto prima che l agente venga creato e perciò non è utilizzabile per concedere autorizzazioni. Per questo l identità di ogni agente comprende il nome della propria classe, una sorta di nome del prodotto, utile per l autenticazione. Il nome della classe può essere usato in riferimento ad un particolare tipo di agente, per esempio per garantire a tutti gli agenti di una classe l accesso ad uno specifico file. L identificatore può anche essere usato in politiche che si riferiscono a specifiche istanze di un agente; per esempio una politica potrebbe indicare che un particolare agente può disporre di ogni ulteriore agente da lui generato. L autore di un agente è colui che ne scrive il codice e che ne garantisce comportamenti corretti. È infatti interesse dell autore che nessun danno possa essere addebitato ad un agente malfunzionante. A sua protezione, l autore potrebbe definire precisi termini di affidabilità. Il proprietario dell agente, tipicamente un utente, è interessato alla sicurezza del singolo agente in esecuzione, all affidabilità dei risultati ottenuti ed alla correttezza dell esecuzione; a tal fine l utente potrebbe definire delle preferenze di sicurezza, un

68 Implementazioni esistenti Aglet 68 insieme di regole che specificano l insieme di soggetti che possono interagire con l agente e le modalità di tali interazioni. Dal momento che l agente deve affidarsi al contesto per completare i suoi compiti, le preferenze non sono altro che una dichiarazione di intenti; tuttavia permettono al proprietario di limitare le capacità dell agente, per esempio specificando qualche proprietà globale relativa al numero massimo di salti o al consumo di cicli di CPU, in modo da ridurre le responsabilità attribuibili per eventuali danni provocati dall agente Contesti Un contesto rappresenta la piattaforma di esecuzione degli agenti. La sua identità è rappresentata dall indirizzo della macchina su cui opera, unito ad un qualificatore se eventualmente la macchina ospitasse più d un contesto. Diversamente dagli agenti, i contesti sono oggetti longevi e perciò possono mantenere la loro identità, cioè il loro indirizzo, anche dopo modifiche o sostituzioni complete del software e dell hardware che li implementano. Per applicazioni critiche che associano particolare fiducia ad una versione particolare del contesto, l identità del contesto dovrebbe includere un attributo che si riferisca ad una specifica versione del suo software e hardware, come il numero di serie di una CPU. L autore del contesto dovrebbe produrre un contesto affidabile in accordo alle specifiche previste. È infatti interesse dell autore che nessun danno sia imputabile ad un contesto malfunzionante. Le specifiche delle funzionalità di un contesto fornite dall autore sono quelle su cui fa affidamento il proprietario del contesto come garanzia della robustezza e della sicurezza del contesto e della macchina sottostante. Ogni proprietario di contesto definisce le politiche di sicurezza per il contesto sotto il suo controllo, in particolare per proteggere le risorse locali dagli agenti; deve anche farsi garante del fatto che altri agenti non possano interferire con un particolare agente in esecuzione nello stesso contesto, se non esplicitamente permesso dal suo proprietario Domini Molti fattori spingono ad organizzare i singoli contesti in gruppi. Per esempio un contesto fornisce una certa infrastruttura: servizi generali per l amministrazione degli agenti, per la comunicazione, supporto per audio e immagini, servizi di sicurezza specifici come autenticazione, autorizzazione e gestione delle responsabilità; un singolo

69 Implementazioni esistenti Aglet 69 contesto che fornisca tutti questi servizi potrebbe essere molto oneroso, mentre gruppi di contesti potrebbero risultare più efficienti ed economici. Potrebbe anche essere facile fornire comunicazioni sicure tra i contesti di un gruppo, se queste avvenissero localmente, e quindi sotto la protezione del sistema operativo. Tutti i membri di un dominio seguono le politiche di sicurezza impostate dall autorità di dominio. In alcuni casi l autorità di dominio e il proprietario del contesto possono coincidere, ma in generale identificano principal diversi. Un dominio può essere definito in vari modi: attraverso l uso di caratteri jolly per identificare un sottodominio Internet, oppure come l insieme di tutti i contesti posseduti da uno stesso proprietario, oppure attraverso un servizio di directory Politiche di sicurezza Tutti i principal menzionati possono definire politiche di sicurezza, in particolare i proprietari degli agenti e dei contesti. Un sistema sicuro dovrebbe assicurare che tutte le politiche di sicurezza previste siano rispettate. Per esempio sebbene il proprietario di un agente potrebbe aver specificato un consumo di 10 secondi di CPU per ogni piattaforma visitata, il proprietario del contesto potrebbe aver fissato un limite di 5 secondi, che sostituirebbe il limite previsto dal proprietario dell agente. La gerarchia nelle politiche di sicurezza definite dai vari principal è: AgletManufacturer < AgletOwner < ContextMaster < DomainAuthority. Questo significa che l autorità di dominio definisce le politiche di base per l esecuzione degli agenti nei contesti specificati, la quale può essere raffinata ma non sostituita da proprietari di contesto, proprietari e autori di agente Mobilità degli agenti Se l autore di un agente, il suo proprietario, l autore e il proprietario del contesto possono essere opportunamente identificati, per esempio tramite la loro chiave pubblica ed una adeguata infrastruttura di certificazione, allora è possibile creare un agente che possa viaggiare con sicurezza. Prima che possa essere lanciato un agente, il contesto deve autenticare il proprietario come un utente registrato. Durante la richiesta di creazione, il proprietario dell agente definisce le preferenze di sicurezza da applicare all agente. Quando il contesto istanzia l agente dalla classe Java corrispondente può includere informazioni riguardanti

70 Implementazioni esistenti Aglet 70 l autore, il proprietario e il contesto di origine dell agente, cioè se stesso. Queste informazioni, con il codice dell agente e le preferenze di sicurezza definite dall utente, formano la parte statica dell agente che viene firmata dal contesto. In questo modo ogni contesto che riceverà l agente potrà facilmente verificare l integrità della sua parte statica. Gli agenti si spostano quando vengono inviati o richiamati da qualche posizione remota. In questo caso il contesto attuale e quello di destinazione negoziano tra loro le condizioni per stabilire un canale sicuro: il contesto attuale può proteggere l integrità dei dati dell agente calcolando una sintesi sicura che permetta al contesto di destinazione di verificare a posteriori il danneggiamento dell agente durante lo spostamento; inoltre entità non autorizzate possono essere escluse dalla lettura di informazioni riservate tenute dall agente durante il transito tra i due contesti se le due parti concordano sull uso di adeguati algoritmi crittografici. La politica di sicurezza di ogni contesto definisce gli appropriati meccanismi di comunicazione con ogni altro contesto. Per esempio, sebbene un agente potrebbe non aver richiesto alcun meccanismo di protezione per il suo trasferimento presso il contesto di destinazione, la politica del contesto di destinazione potrebbe imporre l uso del protocollo Secure Socket Layer (SSL) con autenticazione del cliente Accesso a risorse locali Quando un agente si sposta, il nuovo contesto riceve un riferimento all agente, e quest ultimo riprende l esecuzione nel nuovo contesto. A sua volta l agente riceve un riferimento al contesto, che può essere usato per ottenere informazioni sul suo nuovo ambiente, in particolare sugli altri agenti attualmente in esecuzione, in modo tale da poter interagire con alcuni di loro. I contesti devono proteggersi dalle azioni degli agenti ed inoltre devono impedire agli agenti stessi di poter interferire reciprocamente. Il contesto deve in altre parole realizzare un reference monitor e fornire agli agenti solo gli accessi alle risorse esplicitamente accordati dalla politica di controllo di accesso definita dal suo proprietario. Perciò un contesto stabilisce un dominio di servizi logicamente raggruppati sotto una comune politica di sicurezza che governa tutti gli agenti presenti nel contesto. Il proprietario del contesto configura le politiche di sicurezza da applicare agli agenti che arrivano definendo vari livelli di autorizzazione:

71 Implementazioni esistenti Aglet 71 livello generale, per un autore non autenticato; livello di organizzazione, per un utente non autenticato; livello specifico dell agente, negli altri casi. Inoltre l autorizzazione può essere concessa con riferimento alla potenza di calcolo, livello di occupazione, rapporti tra organizzazioni, prezzi, certificazioni del codice o tipo di agente (ad esempio distinguendo tra un agente di gioco o di ricerca). In accordo alle politiche di sicurezza da applicare ai vari livelli di autorizzazione, il reference monitor di un contesto può concedere permessi di ottenere informazioni sul file system, di leggere, scrivere o cancellare file locali, di connettersi su una porta di rete con il contesto di origine o ad un contesto qualsiasi, di caricare una libreria o di aprire una finestra. Oltre a queste risorse, presenti anche nel modello di sicurezza di Java, un sistema ad agenti necessita di ulteriori risorse per rappresentare operazioni come creare un nuovo agente, clonarne uno già esistente, terminarlo o inviarlo su un contesto diverso. Un agente trasporta poi le preferenze di sicurezza definite dal suo proprietario, che di solito includono regole per governare il tipo di cooperazione che l agente può stabilire con l ambiente; tali preferenze costituiscono comunque solo una dichiarazione d intenti, in quanto l agente si deve affidare al contesto per ottenere i risultati desiderati. Le preferenze di sicurezza descrivono chi ed in quali circostanze può terminare, disattivare, clonare, trasferire o richiamare l agente, sia per quanto riguarda gli altri agenti che per quanto riguarda i contesti; le preferenze inoltre possono proteggere l accesso a qualsiasi metodo considerato critico dall agente Linguaggio di autorizzazione L architettura di sicurezza implementa il modello di sicurezza fornendo una serie di componenti e le loro interfacce. Due elementi di tale sistema sono particolarmente importanti: il database delle politiche dei contesti e le preferenze degli agenti. Poiché sia i proprietari di contesto che i proprietari di agente hanno i loro specifici interessi a riguardo di ciò che un agente dovrebbe essere in grado di fare, entrambi potrebbero voler restringere le sue capacità. Le politiche di sicurezza consistono in ultima analisi di un insieme di regole, identificate da un nome, le quali associano una serie di privilegi ai principal a cui essi devono essere concessi.

72 Implementazioni esistenti Aglet 72 Il linguaggio per la descrizione di politiche e preferenze tuttavia permette anche di definire politiche di autorizzazione di più alto livello attraverso l uso di gruppi, principal compositi e gerarchie di risorse a cui è possibile associare permessi. Inoltre il linguaggio prevede la definizione di liste nere che disabilitano gli agenti e i contesti di cui si sospetta un comportamento non corretto Gruppi Nella definizione delle autorizzazioni è possibile fare riferimento ai diversi principal elencati in precedenza, come l utente o l autore di un agente, oppure il proprietario di un contesto. Nel caso dei basic principal, questi vengono identificati singolarmente, per esempio indicando aglet=anaglet oppure owner=anowner. I composite principal offrono invece un modo conveniente per raccogliere in un gruppo i vari principal che devono avere gli stessi diritti d accesso. Una tale caratteristica di raggruppamento semplifica considerevolmente l amministrazione della sicurezza, permettendo di concedere certi privilegi a numerosi principal tramite un unica regola. Esistono diversi costrutti per la gestione dei gruppi: GROUP, per definire un gruppo assegnando ad esso un nome ed alcuni principal; IS_MEMBER_OF, per aggiungere un principal ad un gruppo; EXCEPT, OR, AND, per indicare una differenza tra insiemi, la loro unione o la loro intersezione; utili ad esempio per concedere privilegi ad un intero gruppo ad eccezione di un certo utente. È anche possibile usare caratteri jolly per specificare gruppi di contesti, ad esempio indicando oppure *.edu Privilegi I privilegi definiscono le capacità del codice in esecuzione imponendo restrizioni d accesso e limiti al consumo di risorse. Un privilegio consiste di una risorsa, come un file locale, associato ad una azione appropriata come lettura, scrittura o esecuzione nel caso del file locale. Sono previsti i seguenti tipi di risorsa: File, risorse del file system locale; Net, accessi di rete;

73 Implementazioni esistenti Aglet 73 Awt, il sistema a finestre locale; System, ogni genere di risorsa di sistema, come memoria e CPU; QoP, qualità della protezione; Context, risorse del contesto; Aglet, risorse dell agente. Le risorse sono strutturate gerarchicamente. Perciò i permessi possono essere dati per un insieme di risorse o anche per un tipo completo di risorse, come accesso universale ai file Politiche dei contesti Il proprietario del contesto definisce le politiche di sicurezza, limitando le azioni che gli agenti sotto il suo controllo possono fare. In sostanza nel database delle politiche il proprietario del contesto elenca una serie di regole nelle quali i principal, che denotano gruppi di agenti, vengono associati ai privilegi corrispondenti. La forma sintattica di una regola è la seguente: <label>:<principal> -> <privileges> Quando un agente risponde a diversi principal, ad esempio il suo autore ed il suo utente, viene applicato una sorta di diritto di veto per combinare le politiche di questi principal. In altre parole anche una sola regola negativa implica una negazione d accesso Preferenze degli agenti Il proprietario di un agente ha la possibilità di stabilire un insieme di preferenze di sicurezza che dovrebbero essere rispettate dai contesti visitati dall agente. Le preferenze, come le politiche dei contesti, combinano i gruppi e i privilegi in regole. La forma sintattica di una regola è <label>:<context_group_definition> -> <privileges> La seguente lista definisce l insieme dei metodi che un proprietario può proteggere sui propri agenti: clone, deactivate, dispatch, retract, dispose; getagletclassname, getagletcontext, getcodebase, getidentifier, getitinerary, getmessagemanager, getproperty, getpropertykeys, gettext;

74 Implementazioni esistenti Ara 74 sendmessage; setitinerary, setproperty, settext; subscribe, unsubscribe. Queste azioni possono essere richieste dall agente stesso o da altri agenti attraverso l AgletProxy. Nella definizione delle preferenze è anche possibile definire delle concessioni a riguardo del consumo di risorse come tempo di CPU e memoria. Tali concessioni possono essere locali, riguardando solo il contesto attuale, o globali, e perciò riguardare tutto l insieme di host visitati. Una concessione globale definita alla creazione pone limiti precisi sulle azioni dell agente durante tutta la sua vita, limitando nei fatti le responsabilità attribuibili al suo proprietario. Gli agenti possono anche formare gruppi che condividono una concessione comune. La concessione definisce una età o una dimensione massima, ed indica se possono essere creati nuovi agenti. Nel caso della creazione o clonazione di agenti, la concessione deve essere condivisa. Si noti che, nonostante l architettura preveda i costrutti necessari a definire le concessioni, il contesto dovrebbe poi essere in grado di controllare fattivamente il consumo di risorse e prevenire gli attacchi denial of service, cosa attualmente non possibile senza modificare la macchina virtuale di Java. 8.3 Ara Ara è una piattaforma per agenti mobili scritta in vari linguaggi interpretati (Java, Tcl e C++, per quest ultimo precompilando in byte code intermedio), la quale permette una migrazione del tutto trasparente per quanto riguarda lo stato di esecuzione interno dell agente. Il modello di programmazione di Ara consiste di agenti che si spostano e stazionano in locazioni diverse, dove usano certi servizi forniti dal sistema ospite o da altri agenti. Una locazione è situata fisicamente su qualche macchina e può imporre le sue specifiche restrizioni di sicurezza agli agenti che vi stazionano. Un servizio è accessibile solo agli agenti presenti sulla stessa locazione del servizio Risorse e principal I principal rappresentati nel modello di sicurezza di Ara sono gli utenti degli agenti, i loro autori, e le varie macchine che ospitano il sistema.

75 Implementazioni esistenti Ara 75 L utente di un agente è la persona che inizialmente richiama l agente ed è alla fine responsabile dei suoi comportamenti; le autorizzazioni e le responsabilità per le azioni dell agente in una certa locazione sono di solito basate sulla identità di questo utente. Nella pratica l autore di un agente commerciale è spesso più noto agli altri principal che hanno a che fare con l agente rispetto al suo utente, e perciò sembra utile introdurre l autore come principal separato. In certi contesti gli utenti potrebbero anche ritenere l autore responsabile per le azioni dell agente se queste fossero in qualche modo inattese. Naturalmente, nel caso di agenti progettati in proprio, l utente assume implicitamente anche il ruolo di autore. Il terzo tipo di principal è la macchina ospite, sulla cui identità si basano gli agenti per decidere se visitare o meno una determinata locazione. Con soli tre tipi di principal, il modello di Ara è notevolmente più semplice del modello delle Aglet, che ne usa otto. Tuttavia questo sembra sufficiente per gli scopi pratici e ovviamente meno scomodo da usare. In maniera forse sorprendente, l agente stesso non compare tra i principal; una ragione di questo risiede nella natura transitoria della maggior parte degli agenti, che rende difficile basare una politica sulle identità degli agenti; un altra è che il comportamento di un agente è completamente determinato da quello degli altri principal, cioè il suo utente, il suo autore e probabilmente gli host dove staziona. Ragionamenti simili si applicano alla macchina ospite. Né l operatore della macchina, né il suo software (ad esempio il sistema ad agenti), né il suo autore sono rappresentati come principal; ciò perché da un punto di vista esterno, quindi quello di un agente che sopraggiunge, una macchina appare monolitica in termini di responsabilità; sarebbe impossibile discriminare dall esterno se un certo comportamento debba essere attribuito all operatore della macchina o al produttore del software o dell hardware. Duali rispetto ai principal, le entità che compiono le azioni, sono le risorse, gli oggetti su cui le stesse azioni sono compiute. Le risorse da proteggere in Ara sono piuttosto convenzionali, comprendendo da un lato le risorse del sistema operativo, come file, connessioni di rete, spazio su disco, memoria principale e tempo di CPU, e dall altro le risorse del sistema ad agenti, come gli agenti e le locazioni.

76 Implementazioni esistenti Ara Autenticazione Molto importante in questo modello è il ruolo delle firme e dei certificati. In Ara ci sono diversi tipi di certificati: da un lato i certificati di utente e di autore, che legano la chiave al nome comune dell utente o dell autore, dall altro i certificati di host, che legano la chiave al nome DNS assoluto dell host designato. Per gli agenti mobili, sarebbe ideale se l intero agente fosse firmato dall utente e dall autore: in tal modo la firma potrebbe essere controllata ad ogni nodo per scoprire potenziali alterazioni avvenute sugli host visitati in precedenza. Sfortunatamente questo è difficilmente realizzabile per la parte mutabile dell agente, dal momento che l agente dovrebbe essere firmato nuovamente dopo ogni variazione al suo stato, e la firma su un nodo non fidato è un problema ancora irrisolto. Per evitare questo problema in Ara le parti mutabili ed immutabili di un agente sono chiaramente distinte. Quelle immutabili, che includono principalmente il codice e il passaporto, possono essere firmate alla creazione dell agente: l autore, a meno che non coincida con l utente, firma il codice al momento del rilascio, mentre l utente firma il passaporto e, se presenti, anche gli argomenti dell agente Passaporto La componente più importante di un agente dal punto di vista della sicurezza è il suo passaporto. Il passaporto contiene tutte le informazioni rilevanti sull identità di un agente, il suo utente ed il suo autore. I campi principali di questo oggetto sono mostrati qui: AgentPassport { GlobalUniqueId id; String name; // optional symbolic Time dateofbirth; Allowance maxglobalallow; // timetolive, maxsize, Certificate usercert; Certificate manufcert; Signature codesig; // by manuf. Signature argssig; // by user Signature passportsig; // by user covering passport } Il passaporto è immutabile durante la vita di un agente, il che rende facile per l utente firmare l agente al momento della creazione. Il passaporto stabilisce anche le concessioni massime per l agente, ossia il limite globale sull accesso alle risorse. È sufficiente notare che questo campo realizza una sorta di protezione dell agente contro

77 Implementazioni esistenti Ara 77 errori di programmazione o manipolazioni di host maliziosi che potrebbero risultare in un consumo indesiderato, e probabilmente anche costoso, di risorse Host trace Oltre alla parte immutabile, sono associati all agente anche molti attributi di sicurezza mutabili, il più importante dei quali è l host trace, una lista degli host visitati dall agente finora. L host trace risulta utile soprattutto al momento di attribuire un certo grado di fiducia ad un agente in arrivo presso una locazione: questa infatti potrebbe voler preservare certi requisiti di sicurezza ed in questo senso potrebbe voler conoscere i nodi visitati dall agente in precedenza per controllare che questo non abbia attraversato un nodo non fidato. Infatti un nodo malizioso potrebbe aver alterato una parte mutabile dell agente, non autenticata dalla firma. L host trace è firmata in maniera incrementale dai nodi a ciascun salto ed in questo modo ogni host certifica l arrivo dell agente dal corrispondente host di provenienza. Supposto che i nodi di fiducia non imbroglino nell aggiornamento dell host trace, questo schema assicura che un agente non possa avere attraversato un nodo non fidato, poiché alla fine tale nodo comparirebbe nell host trace. La parte mutabile di un agente, prima di tutto i dati di lavoro, non sono in genere firmati; solo casi speciali possono essere trattati attraverso schemi appositi come descritto per l host trace. Per alleviare il pericolo di alterazioni maliziose, gli host potrebbero tenere copia degli agenti ricevuti; questo, in combinazione con l autenticazione degli host, creerebbe effettivamente una traccia di eventi sufficiente ad identificare un nodo malizioso. Tuttavia, avvenendo la rilevazione a posteriori, potrebbe essere troppo tardi ed inoltre la procedura risulta complicata; in sostanza il problema dell autenticazione dei dati mutabili degli agenti mobili aspetta ancora una soluzione soddisfacente Creazione e migrazione In effetti tutto questo avviene in maniera abbastanza trasparente, rendendo le API per la creazione di agenti molto semplici, come mostrato qui usando la sintassi della shell Unix per semplicità: ara_agent [-auth] code arg* Omettere auth creerebbe un agente senza capacità crittografiche.

78 Implementazioni esistenti Ara 78 Se l agente in seguito migra, ha la possibilità di farlo senza supporto crittografico, cosa che potrebbe essere sufficiente per esempio tra nodi fidati, o di usare una protezione completa, con autenticazione della sorgente e della destinazione e con trasferimento cifrato per evitare l eavesdropping, o di adottare varie soluzioni intermedie tra i due estremi. Anche le API per la migrazione sono piuttosto semplici: ara_go destination [-auth [-nohosttrace] [-noencrypt]] Qui auth abilita la protezione completa, mentre nohosttrace omette l autenticazione del nodo sorgente (con l effetto che non è possibile registrare e autenticare la lista dei nodi visitati), e noencrypt usa autenticazione simmetrica ma senza cifratura Regioni Nella pratica gruppi di host sono spesso amministrati da una autorità comune, come una compagnia, e può essere pratico trattare tali gruppi come entità atomiche dal punto di vista della sicurezza, per esempio omettendo pesanti calcoli crittografici mentre ci si sposta all interno di tali gruppi. Per questo Telescript introduce il concetto di regione, trattato a tutti gli effetti come un ulteriore principal, che nel processo di autorizzazione gode di una priorità più elevata rispetto all host. Anche Ara ha un concetto di regione, ma ad un livello più basso, cercando di raccogliere i benefici dell omissione della crittografia non necessaria, senza introdurre la complessità di un nuovo tipo di principal: le regioni non sono visibili agli agenti, i quali semplicemente migrano tra gli host come prima, ma solo al sistema attraverso un file di configurazione che elenca gli host della regione. Il sistema in modo trasparente omette autenticazione e cifratura quando un agente migra in una destinazione all interno della stessa regione. Questo evita di introdurre l ulteriore complessità derivante dall avere un insieme di principal organizzato gerarchicamente Autorizzazione Ancora più che il processo di autenticazione, concedere ad un agente l autorizzazione per l accesso alle risorse è un problema aperto a politiche che possono essere complesse o specifiche per le singole applicazioni. In accordo a ciò, l autorizzazione in Ara è in gran parte definita a livello di applicazione, preoccupandosi il sistema solo di fornire i meccanismi necessari.

79 Implementazioni esistenti Ara 79 Le diverse locazioni esistenti su un sistema Ara giocano un ruolo centrale nella gestione delle autorizzazioni. Oltre ad aggiungere struttura all host fisico e allo spazio dei nomi, una locazione Ara stabilisce infatti un dominio di servizi organizzati sotto una comune politica di sicurezza che governa tutti gli agenti presenti in quella locazione. Molti sistemi ad agenti hanno concetti simili alle locazioni, comunque di solito usati solo per strutturare; in particolare hanno un ruolo molto simile alle locazioni di Ara i contesti del modello delle Aglet Concessioni La funzione centrale di una locazione è di decidere sulle condizioni di ammissione di un agente che cerca di entrare. Queste condizioni sono espresse nella forma di concessioni accordate all agente per il tempo in cui staziona nella locazione. Una concessione è un vettore di diritti di accesso alle varie risorse di sistema, cioè file, tempo di CPU, memoria eccetera. Gli elementi di tale vettore stabiliscono i limiti di accesso ad un particolare tipo di risorsa, che possono essere quantitativi (ad esempio per il tempo di CPU) o qualitativi (ad esempio per i domini di rete verso i quali è possibile aprire connessioni). Un agente che migra in una locazione specifica le concessioni che desidera ricevere per completare il proprio compito, e la locazione a sua volta decide quali concessioni accordare in realtà al richiedente. Il sistema si preoccuperà in seguito di garantire che un agente non possa mai superare le sue concessioni. Oltre a queste concessioni locali accordate ad un agente dalla sua locazione corrente, ogni agente viene anche dotato all atto della creazione di una concessione globale. La concessione globale pone limiti definitivi alle azioni di un agente per tutto il corso della sua vita, limitando in effetti le responsabilità imputabili al suo principal. Il sistema si assicura che una locazione non accordi mai ad un agente una concessione locale che superi quella globale. Gli agenti possono in ogni istante conoscere la loro concessione attuale e quella globale, e possono trasferire tra loro una certa quantità di tale concessione sotto certe condizioni. Gli agenti che stazionano in una certa locazione possono anche formare gruppi che condividono una certa concessione. Piuttosto che esprimere le preferenze di autorizzazione dei principal coinvolti attraverso strumenti diversi, il concetto di concessione globale e locale li unifica, il che appare sia

80 Implementazioni esistenti Ara 80 concettualmente che tecnicamente più facile da gestire, dal momento che c è una considerevole sovrapposizione tra le varie preferenze. Per esempio sia l utente di un agente che la locazione che lo ospita possono voler limitare il tempo trascorso in quella locazione; anche se queste preferenze appaiono diverse, in realtà sono strettamente correlate. Se ignoriamo per un momento le distinzioni tra concessioni locali e globali sia quantitative che qualitative, le concessioni sono concettualmente simili alle tradizionali capability. La maggior parte dei sistemi operativi preferisce le liste di controllo di accesso piuttosto che le capability, poiché sono più facili da amministrare quando l insieme dei principal è più stabile di quello degli oggetti, come di solito accade nei sistemi operativi. Con gli agenti mobili, la situazione appare rovesciata così che uno schema di autorizzazione più simile alle capability che alle liste di controllo di accesso risulta infatti più adeguato. Le restrizioni generali di accesso alle risorse impostate dalle concessioni sono un meccanismo adeguato per proteggere accessi tipici come allocare memoria, scrivere un file o inviare ad una certa locazione di rete. Tuttavia certi requisiti di sicurezza di più alto livello, come imporre che siano spediti solo dati in uno specifico formato, o che siano preservate condizioni di consistenza tra diversi file, richiedono corrispondentemente restrizioni di accesso di più alto livello. Ciò può essere ottenuto in Ara usando servizi come aperture del dominio di sicurezza, forniti da un agente fidato che si occupa di questi requisiti di alto livello. Con particolare riferimento a queste aperture, il concetto di dominio di sicurezza delle locazioni Ara è in qualche misura simile al modello di sicurezza basato sulle padded cell del Safe Tcl, ma realizzato in maniera indipendente da uno specifico linguaggio e anche più completo, riguardando anche le concessioni per il tempo di CPU e il consumo di memoria Funzioni di ammissione Ogni agente può creare una locazione dinamicamente, specificando un nome ed una funzione di ammissione. La funzione di ammissione ha una interfaccia predefinita, ricevendo il passaporto dell agente, gli attributi di sicurezza e le concessioni locali desiderate come parametri di input. La funzione di ammissione restituisce o le concessioni locali da imporre all agente o un rifiuto di ammissione. Poiché la funzione di ammissione è un programma arbitrario fornito dall agente che crea la locazione, ogni

81 Implementazioni esistenti Ara 81 locazione può così implementare le sue specifiche politiche di sicurezza, discriminando tra agenti individuali, principal o domini di provenienza, e controllando l accesso alle risorse con la granularità appropriata. Quando un agente riprende l esecuzione dopo una migrazione riuscita, può controllare le sue concessioni locali, per scoprire in che grado la locazione ha rispettato i suoi desideri. Ciò permette all agente di decidere da sé cosa fare se trova le concessioni locali insufficienti. Un agente a cui viene negato l accesso ad una locazione viene rimandato alla locazione di provenienza, dove il fallimento viene segnalato attraverso un errore restituito dalla sua chiamata di migrazione. Molti sistemi ad agenti forniscono meccanismi per definire le autorizzazioni concesse ad un agente in arrivo. Di solito queste sono espresse sotto forma di una tabella che collega un principal, come l agente stesso o il suo utente, ad un insieme di diritti di accesso alle risorse locale. Tuttavia l utilizzo di un tale tipo di tabella non si adatta bene alle politiche di autorizzazione più complesse: una particolare politica potrebbe scegliere di usare la tabella non indicando un solo principal, ma attraverso l utente o l autore o l host di partenza o una combinazione di questi, mentre un altra politica potrebbe fare uso della data di nascita o dell host trace, e un altra ancora potrebbe sfruttare diverse tabelle per diverse situazioni, a seconda per esempio delle risorse attualmente disponibili, del numero di agenti già presenti per la stessa sorgente, o basarsi sulla esperienza precedente con agenti dello stesso autore o utente. Piuttosto che espandere e raffinare continuamente il formato usato per definire le autorizzazioni, come accade per il linguaggio proposto dalle Aglet o per le varie versioni di Java, Ara invece fornisce un modo per esprimere politiche arbitrarie nella forma di funzioni di ammissione, facendo uso di qualsiasi informazione sembri utile per l applicazione concreta. Per i casi più comuni la funzione di ammissione può implementare niente più che una semplice tabella, mantenendo al contempo tutta la flessibilità necessaria per i casi più complessi.

82 Un modello di sicurezza per JADE Il modello code-centric 82 9 Un modello di sicurezza per JADE Essendo JADE un sistema ad agenti implementato in linguaggio Java, è abbastanza ovvio costruire un modello di sicurezza per quanto possibile simile a quello già disponibile, cercando di creare dove necessario le opportune estensioni. Il modello della sicurezza di Java è pero di tipo code-centric, essendo la protezione degli accessi basata sul codice e non sull entità responsabile dell esecuzione, come risulta più giusto nei sistemi ad agenti. Il modello della sicurezza di JADE dovrà necessariamente fornire concetti adeguati a rappresentare principal, risorse e permessi di accesso, a gestire l autenticazione di utenti e agenti, a concedere le necessarie autorizzazioni dove previsto. Inoltre dovrà fornire costrutti utili a semplificare l amministrazione del sistema come gerarchie di principal e risorse, gruppi e ruoli. Anche la possibilità di delegare diritti di accesso ad altre entità potrebbe essere utile per completare determinate operazioni in una complessa comunità di agenti, dove si possono instaurare particolari relazioni di fiducia tra alcuni agenti. Infine le comunicazioni dovrebbero restare riservate quando ciò venga richiesto da applicazioni critiche dal punto di vista della sicurezza, come quelle che gestiscono transazioni finanziarie o che implementano protocolli di commercio elettronico. 9.1 Il modello code-centric La sicurezza è stata considerata nello sviluppo di Java una componente fondamentale e, fin dalla prima versione disponibile, sono stati implementati nell ambiente numerosi meccanismi di sicurezza. Il modello della sicurezza di Java è in particolare basato sul concetto di reference monitor, ossia prevede che tutti gli accessi alle risorse critiche siano mediati dal sistema, il quale si accerta che l accesso sia corretto dal punto di vista della sicurezza. Mentre nelle prime versioni le politiche di sicurezza previste erano fisse e distinguevano soltanto tra applicazioni, lanciate dalla consolle, ed applet, eseguite all interno della finestra del browser, con le versioni successive sono stati introdotti i concetti di firma digitale e file di politiche.

83 Un modello di sicurezza per JADE Il modello user-centric 83 L ultima versione di Java al momento disponibile, Java 2, usa infatti delle politiche di sicurezza configurabili dall utente per decidere sulla concessione dei singoli permessi di accesso al codice in esecuzione. Queste decisioni vengono prese sulla base delle caratteristiche del codice stesso, in particolare in base al dominio dal quale esso proviene, al fatto che sia accompagnato da una firma digitale del suo autore o meno e, nel caso di codice firmato, in base all identità di chi appone la firma. I successivi tentativi di accedere a risorse protette invocheranno controlli di sicurezza e i permessi concessi saranno confrontati con i permessi necessari per l accesso tentato. Se i primi includono i secondi, l accesso sarà permesso, altrimenti l accesso sarà negato. Il motivo principale per implementare un controllo di accesso di tipo code-centric è che, quando un utente usa un browser web per navigare in rete e se necessario accedere a contenuti eseguibili, cioè codice mobile scritto in Java, la variabile utente resta essenzialmente costante. D'altro canto, un utente potrebbe fidarsi di una porzione di codice mobile più che di altre e potrebbe volere che questo codice fosse eseguito con privilegi più ampi. Questo è infatti naturale quando le valutazioni sulla sicurezza delle applicazioni sono basate sulle caratteristiche del codice in esecuzione. 9.2 Il modello user-centric Il controllo di accesso di tipo code-centric proprio di Java è abbastanza inusuale; le misure di sicurezza tradizionali, tipicamente presenti nei sistemi operativi più sofisticati, sono di solito centrate sull utente, applicando il controllo sulla base di chi esegue una applicazione e non sulla base di quale applicazione viene eseguita. È abbastanza evidente che un sistema ad agenti, come ogni altro ambiente multiutente, mal si adatta ad essere gestito con uno stile di sicurezza code-centric, ma richiede piuttosto una infrastruttura e delle interfacce di programmazione atte ad autenticare gli utenti e ad assegnare i privilegi Principal Nel modello di sicurezza previsto per JADE un principal rappresenta una qualsiasi entità la cui identità può essere autenticata. L attenzione è ulteriormente ristretta agli scoped principal, dove lo scope rappresenta un dominio organizzativo, che potrebbe a sua volta essere ulteriormente strutturato e limitato nella maniera voluta.

84 Un modello di sicurezza per JADE Il modello user-centric 84 I principal sono la maggior parte delle volte associati a singole persone, anche se possono anche rappresentare entità come dipartimenti, intere compagnie o ogni altra unità autenticabile. Inoltre in JADE anche i singoli agenti vengono associati ad un principal, il cui nome è quello assegnato dal sistema all agente stesso; rispetto ai propri agenti, l utente costituisce un gruppo di appartenenza, rendendo possibile concedere particolari permessi a tutti gli agenti lanciati da uno stesso utente. D altra parte anche gli utenti possono essere strutturati in gruppi, realizzando gerarchie anche complesse e rendendo più flessibile la gestione delle politiche di sicurezza. La nozione di principal è in ogni caso fondamentale per associare le identità al codice in esecuzione e formare un dominio di sicurezza basato su questa informazione Risorse Le risorse di cui si occupa il modello della sicurezza di JADE includono quelle già previste nel modello di Java, come il file system locale, gli accessi di rete, le variabili d ambiente, gli accessi alle basi di dati. Inoltre esistono delle risorse proprie dei sistemi ad agenti che devono essere protette da accessi non autorizzati. Tra queste compaiono gli agenti stessi ed i container. È possibile associare a queste risorse particolari permessi che rappresentano operazioni come creare un nuovo agente, clonarne uno già esistente, terminarlo o inviarlo in una locazione diverso. Sia le risorse mutuate dalla sicurezza di Java che quelle introdotte da JADE sono organizzate gerarchicamente in modo da poter facilmente essere raggruppate nella concessione dei permessi. Tra le risorse disponibili non compaiono il tempo di CPU, lo spazio occupato in memoria e lo spazio occupato su disco. La protezione di queste risorse infatti non risulta possibile nell ambiente di esecuzione di una applicazione Java se non modificando le specifiche e l implementazione della macchina virtuale, il che ovviamente esula dagli obbiettivi prefissati Permessi Un permesso è un oggetto che attribuisce la capacità di eseguire azioni in un sistema. In particolare i permessi di JADE, ereditati dal modello della sicurezza di Java, rappresentano le risorse del sistema. Tutti i permessi hanno un nome e molti includono anche un elenco delle azioni che sono possibili sull oggetto.

85 Un modello di sicurezza per JADE Il modello user-centric 85 Una caratteristica importante è che è possibile confrontare i permessi. In parole povere, il permesso p1 implica il permesso p2 significa che, se ad uno viene concesso il permesso p1, allora gli viene automaticamente concesso anche il permesso p2. Come si capisce questo non è tanto un test di uguaglianza quanto di inclusione. Per prendere una decisione durante il tentativo di accesso ad una risorsa, le funzioni di controllo di accesso confrontano i permessi concessi al principal con i permessi richiesti per eseguire l operazione; l accesso viene consentito se si è in possesso di tutti i permessi richiesti Amministrazione Uno strumento utile per facilitare l amministrazione della sicurezza di una organizzazione è la delega di diritti di amministrazione applicabili solo a precisi sottoinsiemi dell intero dominio dell organizzazione. Il requisito importante è poter concedere il diritto di gestire un piccolo insieme di utenti o gruppi all interno della propria area di responsabilità e, allo stesso tempo, non dare il permesso di gestire oggetti in altre aree dell organizzazione. Questo è possibile in quanto la presenza di risorse organizzate in una gerarchia rende facile assegnare ad un amministratore la responsabilità della gestione di particolari gruppi o insiemi di risorse. Inoltre il fatto che non sia possibile in alcun modo creare oggetti o utenti con un insieme di diritti d accesso più grande di quello posseduto, garantisce che le eventuali ulteriori deleghe di amministrazione restino confinate al dominio di competenza assegnato Ereditarietà L ereditarietà dei diritti di accesso specifica come l informazione di controllo di accesso definita ai livelli più alti della gerarchia si propaghi verso il basso fino ai singoli agenti. Questo riguarda in particolare il concetto di ruolo, visto come insieme di permessi che possono essere assegnati unitariamente ad un gruppo di utenti o agenti. Ci sono generalmente due modelli per implementare l ereditarietà dei diritti d accesso: ereditarietà statica e dinamica. L ereditarietà dinamica determina gli effettivi diritti d accesso di un oggetto valutando i permessi definiti esplicitamente sull oggetto e quelli definiti per tutti gli oggetti superiori nella gerarchia. Questo garantisce la flessibilità di modificare i diritti d accesso su

86 Un modello di sicurezza per JADE Autorità di certificazione 86 porzioni dell albero di gerarchia facendo cambi su uno specifico nodo che automaticamente influenzano tutti i nodi e gli oggetti sottostanti. Il compromesso per questa flessibilità è il costo in termini di prestazioni richiesto per calcolare i diritti di accesso effettivi ogni volta che un agente richieda un servizio su uno specifico oggetto della gerarchia. Il modello della sicurezza di JADE prevede una forma statica di ereditarietà dei diritti di accesso definita al momento della creazione degli oggetti. Ogni cambio ai diritti di accesso fatto successivamente nei livelli più alti della gerarchia deve essere esplicitamente applicato a tutti gli oggetti che devono essere influenzati. 9.3 Autorità di certificazione La sicurezza di JADE si fonda in gran parte sulla disponibilità di un certo numero di certificati, i quali possono attestare l identità di una entità oppure i permessi ad essa concessi. Affinché sia possibile verificare l autenticità di tali certificati è necessario che questi vengano firmati da una autorità pubblicamente riconosciuta. Una autorità in JADE consiste essenzialmente di una coppia di chiavi, delle quali una viene tenuta privata e l altra è resa nota a tutti. Le due chiavi sono calcolate in modo tale che, se un messaggio viene cifrato usando la chiave privata, allora può essere letto solo attraverso la chiave pubblica e viceversa. La firma digitale dei documenti si basa infatti su algoritmi a chiave pubblica, e richiede che una sintesi non reversibile del documento venga cifrata usando la chiave privata dell autorità. Tale firma verrà in seguito trasmessa assieme al documento in modo da attestarne l autenticità e la integrità. Per verificare la integrità di un documento ricevuto, è sufficiente calcolare nuovamente la sua sintesi e controllare che questa coincida con quella ricevuta assieme al documento, dopo averla ovviamente decifrata usando la chiave pubblica dell autorità certificante. Modificazioni non autorizzate del documento infatti risulterebbero in una sintesi diversa e verrebbero sicuramente rilevate. La autenticità è dimostrata dal fatto che la cifratura della sintesi viene fatta usando una chiave privata, ossia tenuta debitamente protetta da sguardi indiscreti, in modo tale che nessuno possa firmare documenti a nome di altri senza che questo venga rilevato.

87 Un modello di sicurezza per JADE Autenticazione Autenticazione Il primo passo per poter assegnare in maniera precisa dei permessi di accesso ai vari agenti in esecuzione nel sistema è quello di autenticare l identità degli utenti che si connettono ed in seguito quella degli agenti durante i tentativi di accesso alle risorse. In base a queste identità sarà in seguito possibile prendere le corrette decisioni sugli accessi protetti. Inoltre questo costituisce la base per poter attribuire ai diversi individui o enti le responsabilità di eventuali danni o problemi causati dagli oggetti a loro riconducibili Autenticazione degli utenti In un sistema ad agenti JADE un utente si autentica come proprietario di un agente fornendo un nome ed una password, e ricevendo in cambio una certificazione della sua identità e dei permessi di cui gode. Tali permessi possono in seguito essere delegati agli agenti lanciati dall utente sul sistema, in modo da avere un controllo preciso di quali azioni sono permesse ai singoli agenti. Ogni agente verrà in seguito identificato come una risorsa posta al di sotto del proprio utente nella relativa gerarchia, in modo che il controllo di accesso possa usare l informazione sulle entità responsabili dell agente per prendere le decisioni corrette. Anche la creazione di un container prevede l autenticazione dell utente per esso responsabile. Tale informazione resterà poi associata al container in modo da poter proteggere anche questo oggetto da azioni non autorizzate, come ad esempio un tentativo di chiudere il container da parte di un utente o di un agente privo dei necessari permessi Autenticazione degli agenti Gli agenti si autenticano presso il sistema quando richiedono accesso a risorse protette. L autenticazione coinvolge la presentazione di un opportuno strumento di riconoscimento, un certificato d identità. Gli elementi di un certificato d identità, mostrati in Figura 16, includono l identità del soggetto, l identità dell autorità emittente, un identificatore degli algoritmi usati per proteggere il certificato, la durata del certificato. Questi elementi possono essere usati per stabilire la validità del certificato e il legame tra certificato e agente.

88 Issuer Signature Un modello di sicurezza per JADE Autorizzazione 88 Version Issuer Subject Signature Algorithm Certificate Serial Number Validity Period Extensions Figura 16 Certificato d identità Poiché i principal sono strutturati gerarchicamente, l identità dell agente include anche quella del suo utente e di tutte le entità responsabili nei livelli più alti della gerarchia. 9.5 Autorizzazione Per assicurare la necessaria protezione degli accessi bisogna fare in modo che il codice in esecuzione possa essere associato ad un principal autenticato, in modo che i permessi attualmente in possesso di tale principal vengano controllati da un reference monitor. Tale implementazione di reference monitor deve essere in grado di mediare gli accessi alla piattaforma sottostante, in modo da proteggere le risorse del sistema operativo come file system e connessioni di rete, ma deve anche mediare le interazioni tra gli agenti, in modo da proteggerli da attacchi di tipo masquerading o denial of service lanciati da altri agenti Dominio di protezione Nel modello di sicurezza di Java 2 un dominio di protezione è semplicemente un insieme di classi le cui istanze godono degli stessi privilegi. I domini diversi vengono identificati in base alla loro fonte, ossia alle chiavi con le quali il byte code è firmato e all indirizzo dal quale viene scaricato. Dunque, classi firmate con le stesse chiavi e prelevate dagli stessi indirizzi sono poste nello stesso dominio, classi che hanno gli stessi permessi ma vengono da fonti diverse appartengono a domini differenti. Il codice in esecuzione su una macchina virtuale Java è sempre associato ad un preciso dominio di protezione tramite un contesto di controllo d accesso, che permette di discriminare gli accessi consentiti da quelli bloccati.

89 Un modello di sicurezza per JADE Delega 89 Tuttavia questa forma di autorizzazione non è sufficiente in un ambiente come JADE, dove possono operare contemporaneamente agenti di diversi utenti e probabilmente anche di diverse compagnie. Occorre invece poter decidere sugli accessi alle risorse in base all autorità responsabile di una certa esecuzione, oltre che in base alla fonte del codice; in altre parole occorre associare un soggetto all attuale contesto di controllo di accesso. Il soggetto in particolare deve essere in possesso di un certificato attestante l identità del principal responsabile del codice in esecuzione e di un certo numero di certificati di autorizzazione riportanti i permessi attualmente posseduti dal principal, tipicamente un agente Certificati di autorizzazione Oltre ad un certificato di identità, ogni agente può disporre anche di diversi certificati di autorizzazione, i quali elencano particolari permessi concessi all agente. Questi certificati possono essere ottenuti dall agente alla sua creazione in base alle decisioni dell utente oppure tramite delega da altri agenti presenti nel sistema. Il sistema si accerta in ogni caso che il passaggio di permessi dall utente o dagli altri agenti sia legittimo, ossia che questi permessi siano effettivamente posseduti dal delegante e che questo abbia il diritto di delegarli ulteriormente. Il certificato di autorizzazione è in sostanza nient altro che una attestazione del possesso di particolari permessi, ricevuti da una entità autenticata che di tali permessi era già in possesso. Perciò la struttura di tali certificati viene riferita ad un generico processo di delega. 9.6 Delega Una delega sicura si ha quando un oggetto, definito delegante o iniziatore, autorizza un altro oggetto, definito delegato, ad eseguire qualche compito usando alcuni dei diritti del delegante. L essenza di una delega sicura è essere capaci di verificare che un oggetto che dichiara di agire per conto di un altro, abbia in effetti la necessaria autorizzazione. Il problema diventa più complicato nella pratica se consideriamo oggetti, agenti e codice mobile che vengono trasferiti attraverso una rete pubblica, quando l iniziatore non necessariamente ha una idea di dove tutti i suoi rappresentanti possano trovarsi. Inoltre devono essere risolte una serie di questioni pratiche: l infrastruttura dovrebbe essere

90 Un modello di sicurezza per JADE Delega 90 scalabile, rimanere efficiente anche sotto un uso diffuso e restare sicura quando si ha a che fare con le complesse relazioni di fiducia che emergono nella pratica. Per garantire queste caratteristiche il modello della sicurezza previsto per JADE adotta un approccio sfaccettato, supportando diversi stili e protocolli: prevede ad esempio la delega semplice (rappresentanza o deputazione) e la delega a cascata o concatenata, e fornisce strumenti per disabilitare o revocare le deleghe concesse Modalità di delega Una serie di oggetti può essere coinvolta in una certa richiesta di servizio. Per esempio si supponga che l oggetto A (client) richieda un servizio ad un altro oggetto B (server). L oggetto B potrebbe completare il compito da sé oppure potrebbe a sua volta aver bisogno dei servizi offerti da un altro oggetto, C. In questo contesto, l oggetto B che era prima il server (rispetto alla richiesta di A) diventa un client rispetto alla richiesta fatta a C. Questo in effetti forma una catena di deleghe dove l oggetto A è l iniziatore, l oggetto C è l obbiettivo finale e l oggetto B è un intermediario, come mostrato nella Figura 17. Figura 17 Modalità di delega

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica.

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica. Sistemi e tecnologie per la multimedialità e telematica Fabio Burroni Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena burronif@unisi unisi.itit La Sicurezza delle Reti La presentazione

Dettagli

CdL MAGISTRALE in INFORMATICA

CdL MAGISTRALE in INFORMATICA 05/11/14 CdL MAGISTRALE in INFORMATICA A.A. 2014-2015 corso di SISTEMI DISTRIBUITI 7. I processi : il naming Prof. S.Pizzutilo Il naming dei processi Nome = stringa di bit o di caratteri utilizzata per

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

PROGETTAZIONE E SVILUPPO DI UN SISTEMA MULTI-AGENTE PER LA GESTIONE DEL CENTRO UNICO PRENOTAZIONE (CUP) E DEI FASCICOLI SANITARI

PROGETTAZIONE E SVILUPPO DI UN SISTEMA MULTI-AGENTE PER LA GESTIONE DEL CENTRO UNICO PRENOTAZIONE (CUP) E DEI FASCICOLI SANITARI UNIVERSITA POLITECNICA DELLE MARCHE FACOLTA DI INGEGNERIA Corso di Laurea in Ingegneria Informatica e dell Automazione PROGETTAZIONE E SVILUPPO DI UN SISTEMA MULTI-AGENTE PER LA GESTIONE DEL CENTRO UNICO

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Introduzione ai certificati S/MIME e alla posta elettronica certificata...2 Procedura di installazione del certificato personale S/MIME rilasciato

Introduzione ai certificati S/MIME e alla posta elettronica certificata...2 Procedura di installazione del certificato personale S/MIME rilasciato Guida all installazione e all utilizzo di un certificato personale S/MIME (GPSE) Introduzione ai certificati S/MIME e alla posta elettronica certificata...2 Procedura di installazione del certificato personale

Dettagli

Introduzione a JADE. Francesco Di Giunta

Introduzione a JADE. Francesco Di Giunta Introduzione a JADE Francesco Di Giunta SOMMARIO Introduzione Architettura generale di un sistema multiagente (MAS) in JADE Architettura e implementazione di un agente JADE Comunicazione e interazione

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

La sicurezza nelle reti di calcolatori

La sicurezza nelle reti di calcolatori La sicurezza nelle reti di calcolatori Contenuti del corso La progettazione delle reti Il routing nelle reti IP Il collegamento agli Internet Service Provider e problematiche di sicurezza Analisi di traffico

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

TRASMISSIONE DI DATI VIA INTERNET

TRASMISSIONE DI DATI VIA INTERNET TRASMISSIONE DI DATI VIA INTERNET 2.0 1 11 Sommario SOMMARIO...2 1. STORIA DELLE MODIFICHE...3 2. TRASMISSIONE DATI VIA INTERNET...4 2.1 SCOPO DEL DOCUMENTO...4 2.2 INTRODUZIONE...4 3. FORMATO DEI DOCUMENTI...5

Dettagli

Sommario. G. Piscitelli

Sommario. G. Piscitelli Sommario Interprocess Communication Processi (e thread) cooperanti Il paradigma produttore-consumatore Shared Memory e Inter Process Communication (IPC) facility Proprietà caratteristiche della comunicazione

Dettagli

Perchè utilizzare un'autorità di certificazione

Perchè utilizzare un'autorità di certificazione Una generica autorità di certificazione (Certification Authority o più brevemente CA) è costituita principalmente attorno ad un pacchetto software che memorizza i certificati, contenenti le chiavi pubbliche

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Reti di Calcolatori Claudio Marrocco Componenti delle reti Una qualunque forma di comunicazione avviene: a livello hardware tramite un mezzo fisico che

Dettagli

Accordi. Tecnologie di cooperazione. Cooperazione fra Amministrazioni

Accordi. Tecnologie di cooperazione. Cooperazione fra Amministrazioni Alcune considerazioni nell ambito di un sistema di cooperazione informatico che preveda lo scambio di dati tra due o più organizzazioni. Quando parliamo di un sistema di cooperazione informatico ci riferiamo

Dettagli

Programmazione di sistemi distribuiti

Programmazione di sistemi distribuiti Programmazione di sistemi distribuiti I Sistemi Distribuiti, per loro natura, prevedono che computazioni differenti possano essere eseguite su VM differenti, possibilmente su host differenti, comunicanti

Dettagli

SICUREZZA. Sistemi Operativi. Sicurezza

SICUREZZA. Sistemi Operativi. Sicurezza SICUREZZA 14.1 Sicurezza Il Problema della Sicurezza Convalida Pericoli per i Programmi Pericoli per il Sistema Difendere i Sistemi Scoperta di Intrusioni Cifratura Esempio: Windows NT 14.2 Il Problema

Dettagli

Sistemi Operativi SICUREZZA. Sistemi Operativi. D. Talia - UNICAL 14.1

Sistemi Operativi SICUREZZA. Sistemi Operativi. D. Talia - UNICAL 14.1 SICUREZZA 14.1 Sicurezza Il Problema della Sicurezza Convalida Pericoli per i Programmi Pericoli per il Sistema Difendere i Sistemi Scoperta di Intrusioni Cifratura Esempio: Windows NT 14.2 Il Problema

Dettagli

INTRODUZIONE A RETI E PROTOCOLLI

INTRODUZIONE A RETI E PROTOCOLLI PARTE 1 INTRODUZIONE A RETI E PROTOCOLLI Parte 1 Modulo 1: Introduzione alle reti Perché le reti tra computer? Collegamenti remoti a mainframe (< anni 70) Informatica distribuita vs informatica monolitica

Dettagli

Sicurezza a livello IP: IPsec e le reti private virtuali

Sicurezza a livello IP: IPsec e le reti private virtuali Sicurezza a livello IP: IPsec e le reti private virtuali Davide Cerri Sommario L esigenza di proteggere l informazione che viene trasmessa in rete porta all utilizzo di diversi protocolli crittografici.

Dettagli

Processi. Laboratorio Software 2008-2009 C. Brandolese

Processi. Laboratorio Software 2008-2009 C. Brandolese Processi Laboratorio Software 2008-2009 Introduzione I calcolatori svolgono operazioni simultaneamente Esempio Compilazione di un programma Invio di un file ad una stampante Visualizzazione di una pagina

Dettagli

La rete è una componente fondamentale della

La rete è una componente fondamentale della automazioneoggi Attenti alle reti La telematica si basa prevalentemente sulle reti come mezzo di comunicazione per cui è indispensabile adottare strategie di sicurezza per difendere i sistemi di supervisione

Dettagli

Protezione delle informazioni in SMart esolutions

Protezione delle informazioni in SMart esolutions Protezione delle informazioni in SMart esolutions Argomenti Cos'è SMart esolutions? Cosa si intende per protezione delle informazioni? Definizioni Funzioni di protezione di SMart esolutions Domande frequenti

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi a.a. 2010/2011 Francesco Fontanella Il Sistema Operativo Sistema Operativo 2 Il Sistema Operativo Il Sistema Operativo è uno strato

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori Roma, 30 gennaio 2003 La realtà della carta di identità elettronica (nel seguito CIE) e della carta nazionale dei servizi (nel seguito CNS) rende ineluttabile l individuazione di servizi da erogare in

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB.

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. SISTEMI E RETI Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. CRITTOGRAFIA La crittografia è una tecnica che si occupa della scrittura segreta in codice o cifrata

Dettagli

SETEFI. Marco Cantarini, Daniele Maccauro, Domenico Marzolla. 19 Aprile 2012

SETEFI. Marco Cantarini, Daniele Maccauro, Domenico Marzolla. 19 Aprile 2012 e VIRTUALCARD 19 Aprile 2012 e VIRTUALCARD Introduzione Il nostro obiettivo é quello di illustrare la struttura e le caratteristiche di fondo che stanno alla base delle transazioni online operate tramite

Dettagli

Comunicazioni sicure su Internet: https e SSL. Fisica dell Informazione

Comunicazioni sicure su Internet: https e SSL. Fisica dell Informazione Comunicazioni sicure su Internet: https e SSL Fisica dell Informazione Il servizio World Wide Web (WWW) Come funziona nel dettaglio il Web? tre insiemi di regole: Uniform Resource Locator (URL) Hyper Text

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica.

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica. Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Corso di Sistemi Distribuiti Prof. Stefano Russo Modellidi SistemiDistribuiti

Dettagli

Gestione del database Gidas

Gestione del database Gidas Gestione del database Gidas Manuale utente Aggiornamento 20/06/2013 Cod. SWUM_00535_it Sommario 1. Introduzione... 3 2. Requisiti e creazione del Database Gidas... 3 2.1.1. SQL Server... 3 2.1.2. Requisiti

Dettagli

PKI PUBLIC KEY INFRASTRUCTURES

PKI PUBLIC KEY INFRASTRUCTURES Premesse PKI PUBLIC KEY INFRASTRUCTURES Problemi Come distribuire in modo sicuro le chiavi pubbliche? Come conservare e proteggere le chiavi private? Come garantire l utilizzo corretto dei meccanismi crittografici?

Dettagli

Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi

Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi Sistemi Operativi Lez. 13: primitive per la concorrenza monitor e messaggi Osservazioni I semafori sono strumenti particolarmente potenti poiché consentono di risolvere ogni problema di sincronizzazione

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Sistemi Distribuiti. Informatica B. Informatica B

Sistemi Distribuiti. Informatica B. Informatica B Sistemi Distribuiti Introduzione Che cos è un sistema distribuito? Un sistema distribuito è una collezione di computer indipendenti che appare all utente come un solo sistema coerente Da notare: le macchine

Dettagli

INDICE. DATEX il manuale edizione aprile 2011

INDICE. DATEX il manuale edizione aprile 2011 DATEX MANUALE INDICE INDICE... 1 INTRODUZIONE... 2 PRINCIPALI CARATTERISTICHE... 3 IL PRIMO COLLEGAMENTO... 4 INTERFACCIA... 5 DEFINIZIONE DELLE OPERAZIONI E DEI PROFILI... 6 INGRESSO CON PASSWORD NEL

Dettagli

Posta elettronica DEFINIZIONE

Posta elettronica DEFINIZIONE DEFINIZIONE E-mail o posta elettronica è un servizio Internet di comunicazione bidirezionale che permette lo scambio uno a uno oppure uno a molti di messaggi attraverso la rete Un messaggio di posta elettronica

Dettagli

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30 Protocolli di rete Vittorio Maniezzo Università di Bologna Vittorio Maniezzo Università di Bologna 02 Protocolli - 1/30 Strati di protocolli (Protocol Layers) Le reti sono complesse Molti elementi: host

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

Dettagli

LABORATORIO DI TELEMATICA

LABORATORIO DI TELEMATICA LABORATORIO DI TELEMATICA COGNOME: Ronchi NOME: Valerio NUMERO MATRICOLA: 41210 CORSO DI LAUREA: Ingegneria Informatica TEMA: Analisi del protocollo FTP File Transfer Protocol File Transfer Protocol (FTP)

Dettagli

Livello cinque (Livello application)

Livello cinque (Livello application) Cap. VII Livello Application pag. 1 Livello cinque (Livello application) 7. Generalità: In questo livello viene effettivamente svolto il lavoro utile per l'utente, contiene al suo interno diverse tipologie

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

Università degli Studi di Messina MAP Mobile Agent Platform

Università degli Studi di Messina MAP Mobile Agent Platform Università degli Studi di Messina MAP Mobile Agent Platform a cura di MAP Mobile Agent Platform La MAP è la piattaforma per agenti mobili realizzata presso l Istituto di Informatica e Telecomunicazioni

Dettagli

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

Networking Wireless con Windows XP

Networking Wireless con Windows XP Networking Wireless con Windows XP Creare una rete wireless AD HOC Clic destro su Risorse del computer e quindi su Proprietà Clic sulla scheda Nome computer e quindi sul pulsante Cambia Digitare il nome

Dettagli

Realizzazione su piattaforma ad agenti mobili Jade di un sistema di autenticazione biometrica

Realizzazione su piattaforma ad agenti mobili Jade di un sistema di autenticazione biometrica UNIVERSITÀ DEGLI STUDI DI PADOVA Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Realizzazione su piattaforma ad agenti mobili Jade di un sistema di autenticazione biometrica Relatore:

Dettagli

Capitolo 2 -- Silberschatz

Capitolo 2 -- Silberschatz Struttura dei Sistemi Operativi Capitolo 2 -- Silberschatz Struttura di un sistema operativo Servizi di un sistema operativo Interfaccia Utente Chiamate di sistema Tipi di chiamate Programma di sistema

Dettagli

Protezione. Sistemi Operativi mod. B 16.1

Protezione. Sistemi Operativi mod. B 16.1 Protezione Scopi della Protezione Dominio di Protezione Matrice d Accesso Implementazione della Matrice d Accesso Revoca dei Diritti d Accesso Sistemi Basati su Abilitazioni Protezione basata sul linguaggio

Dettagli

SSL: applicazioni telematiche SSL SSL SSL. E-commerce Trading on-line Internet banking... Secure Socket Layer

SSL: applicazioni telematiche SSL SSL SSL. E-commerce Trading on-line Internet banking... Secure Socket Layer : applicazioni telematiche Secure Socket Layer E-commerce Trading on-line Internet banking... Protocollo proposto dalla Netscape Communications Corporation Garantisce confidenzialità e affidabilità delle

Dettagli

Componenti di Sistemi Operativi. System Call Programmi di sistema Componenti di un SO Servizi di SO

Componenti di Sistemi Operativi. System Call Programmi di sistema Componenti di un SO Servizi di SO Componenti di so 1 Componenti di Sistemi Operativi System Call Programmi di sistema Componenti di un SO Servizi di SO 2 System Call Le system call forniscono l'interfaccia tra running program e SO Generalmente

Dettagli

Crittografia. Crittografia Definizione. Sicurezza e qualità dei servizi su internet. 2009 Università degli Studi di Pavia, C.

Crittografia. Crittografia Definizione. Sicurezza e qualità dei servizi su internet. 2009 Università degli Studi di Pavia, C. Definizione La crittografia è la scienza che utilizza algoritmi matematici per cifrare e decifrare i dati. La criptoanalisi è la scienza che analizza e decifra i dati crittografati senza conoscerne a priori

Dettagli

Struttura di un sistema operativo. Struttura dei Sistemi Operativi. Servizi per l utente generico. Servizi per l utente generico

Struttura di un sistema operativo. Struttura dei Sistemi Operativi. Servizi per l utente generico. Servizi per l utente generico Impossibile visualizzare l'immagine. Struttura di un sistema operativo Struttura dei Sistemi Operativi Servizi di un sistema operativo Interfaccia Utente Capitolo 2 -- Silberschatz Chiamate di sistema

Dettagli

Reti di Telecomunicazione Lezione 6

Reti di Telecomunicazione Lezione 6 Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server

Dettagli

Sicurezza: credenziali, protocolli sicuri, virus, backup

Sicurezza: credenziali, protocolli sicuri, virus, backup Sicurezza: credenziali, protocolli sicuri, virus, backup La sicurezza informatica Il tema della sicurezza informatica riguarda tutte le componenti del sistema informatico: l hardware, il software, i dati,

Dettagli

Protezione dei Dati Digitali: Scenari ed Applicazioni

Protezione dei Dati Digitali: Scenari ed Applicazioni Protezione dei Dati Digitali: Scenari ed Applicazioni 1 Sommario Parte I : Scenari Parte II : La Teoria Parte III: La Pratica 2 Parte I: Scenari 3 Applicazioni quotidiane (1/2) Transazioni finanziarie

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

Università degli Studi di Modena e Reggio Emilia

Università degli Studi di Modena e Reggio Emilia Università degli Studi di Modena e Reggio Emilia Facoltà di Ingegneria Sede di Modena Corso di Laurea in Ingegneria Informatica Nuovo Ordinamento Studio della Sicurezza in una Piattaforma ad Agenti un

Dettagli

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

Dettagli

ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/01/2013 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX

ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/01/2013 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/01/2013 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX NB: il candidato troverà nell archivio ZIP scaricato da Esamix anche il software Start Kit

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Lezione 3 Martedì 15-10-2013 1 Struttura ed organizzazione software dei sistemi

Dettagli

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Il File System È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Le operazioni supportate da un file system sono: eliminazione di dati modifica

Dettagli

Sicurezza delle reti e dei calcolatori

Sicurezza delle reti e dei calcolatori Sicurezza e dei calcolatori Introduzione a IPSec Lezione 11 1 Obiettivi Aggiungere funzionalità di sicurezza al protocollo IPv4 e IPv6 Riservatezza e integrità del traffico Autenticità del mittente La

Dettagli

Appunti di Sistemi Distribuiti

Appunti di Sistemi Distribuiti Appunti di Sistemi Distribuiti Matteo Gianello 27 settembre 2013 1 Indice 1 Introduzione 3 1.1 Definizione di sistema distribuito........................... 3 1.2 Obiettivi.........................................

Dettagli

Sommario. Introduzione alla Sicurezza Web

Sommario. Introduzione alla Sicurezza Web Sommario Introduzione alla Sicurezza Web Considerazioni generali IPSec Secure Socket Layer (SSL) e Transport Layer Security (TLS) Secure Electronic Transaction (SET) Introduzione alla crittografia Introduzione

Dettagli

Sistemi di gestione delle basi di dati. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma

Sistemi di gestione delle basi di dati. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma Sistemi di gestione delle basi di dati 1 Cos è un DBMS? Una collezione integrata molto grande di dati Modella organizzazioni del mondo reale Entità (ad esempio studenti, corsi) Relazioni (ad esempio, Madonna

Dettagli

Cod. SWUM_00399_it RCCL

Cod. SWUM_00399_it RCCL Cod. SWUM_00399_it RCCL Libreria di comunicazione CISS Manuale utente Aggiornamento 2/9/2008 Sommario 1. Presentazione... 3 2. Installazione del prodotto... 3 3. Applicazione di esempio... 4 4. Per iniziare

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Il Sistema Operativo Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela Fogli Cos

Dettagli

Obiettivo: realizzazione di reti sicure TIPI DI ATTACCO. Politica di sicurezza: a) scelte tecnologiche b) strategie organizzative

Obiettivo: realizzazione di reti sicure TIPI DI ATTACCO. Politica di sicurezza: a) scelte tecnologiche b) strategie organizzative Obiettivo: realizzazione di reti sicure Politica di sicurezza: a) scelte tecnologiche b) strategie organizzative Per quanto riguarda le scelte tecnologiche vi sono due categorie di tecniche: a) modifica

Dettagli

Xerox SMart esolutions. White Paper sulla protezione

Xerox SMart esolutions. White Paper sulla protezione Xerox SMart esolutions White Paper sulla protezione White Paper su Xerox SMart esolutions La protezione della rete e dei dati è una delle tante sfide che le aziende devono affrontare ogni giorno. Tenendo

Dettagli

Informatica di Base - 6 c.f.u.

Informatica di Base - 6 c.f.u. Università degli Studi di Palermo Dipartimento di Ingegneria Informatica Informatica di Base - 6 c.f.u. Anno Accademico 2007/2008 Docente: ing. Salvatore Sorce Il Sistema Operativo Gerarchia del software

Dettagli

Sicurezza nei Sistemi Distribuiti

Sicurezza nei Sistemi Distribuiti Sicurezza nei Sistemi Distribuiti Aspetti di Sicurezza La sicurezza nei sistemi distribuiti deve riguardare tutti i componenti del sistema e coinvolge due aspetti principali: Le comunicazioni tra utenti

Dettagli

Sicurezza nei Sistemi Distribuiti

Sicurezza nei Sistemi Distribuiti Sicurezza nei Sistemi Distribuiti Aspetti di Sicurezza La sicurezza nei sistemi distribuiti deve riguardare tutti i componenti del sistema e coinvolge due aspetti principali: Le comunicazioni tra utenti

Dettagli

Sicurezza dei sistemi e delle reti Introduzione

Sicurezza dei sistemi e delle reti Introduzione Sicurezza dei sistemi e delle reti Introduzione Damiano Carra Università degli Studi di Verona Dipartimento di Informatica Riferimenti! Cap. 8 di Reti di calcolatori e Internet. Un approccio topdown, J.

Dettagli

Music Everywhere with BT

Music Everywhere with BT Music Everywhere with BT Acquaviva Luca 231767 luca.acquaviva@studio.unibo.it Colombini Gabriele 231491 gabriele.colombini@studio.unibo.it Manservisi Alberto 258370 alberto.manservisi@studio.unibo.it Abstract

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

Protezione dei dati INTRODUZIONE

Protezione dei dati INTRODUZIONE Protezione dei dati INTRODUZIONE Le reti LAN senza filo sono in una fase di rapida crescita. Un ambiente aziendale in continua trasformazione richiede una maggiore flessibilità sia alle persone che alle

Dettagli

Sistemi Distribuiti. Libri di Testo

Sistemi Distribuiti. Libri di Testo Sistemi Distribuiti Rocco Aversa Tel. 0815010268 rocco.aversa@unina2.it it Ricevimento: Martedì 14:16 Giovedì 14:16 1 Libri di Testo Testo Principale A.S. Tanenbaum, M. van Steen, Distributed Systems (2

Dettagli

Strutture dei Sistemi Operativi

Strutture dei Sistemi Operativi Strutture dei Sistemi Operativi Componenti di sistema Servizi del sistema operativo Chiamate di sistema Programmi di sistema Struttura del sistema Macchine virtuali Progetto e implementazione di sistemi

Dettagli

Certificati di Attributi

Certificati di Attributi Certificati di Attributi Sicurezza dei dati in rete La rete è un mezzo non sicuro I messaggi in rete possono essere intercettati e/o modificati a cura di: R.Gaeta, F.Zottola Sicurezza dei dati in rete

Dettagli

Fondamenti di Informatica: Sistemi Operativi 1. Introduzione

Fondamenti di Informatica: Sistemi Operativi 1. Introduzione Introduzione Fondamenti di Informatica: Sistemi Operativi 1 Elaboratori necessitano di SOFTWARE SOFTWARE DI SISTEMA (SISTEMI OPERATIVI): fanno funzionare le varie componenti del computer e permettono all

Dettagli

Sistema Operativo e Applicativi

Sistema Operativo e Applicativi Sistema Operativo e Applicativi Modulo di Informatica Dott.sa Sara Zuppiroli A.A. 2012-2013 Modulo di Informatica () Software A.A. 2012-2013 1 / 36 Software Conosciamo due classi di software: Programmi

Dettagli

Universal Resource Identifier (URI) Autore slide: Fabio Vitali

Universal Resource Identifier (URI) Autore slide: Fabio Vitali Universal Resource Identifier (URI) Autore slide: Fabio Vitali 1 Introduzione Esaminiamo: Gli Universal Resource Identifier (URI) 2 URI Gli URI (Universal Resource Identifier) sono una sintassi usata in

Dettagli

Sistemi Operativi. Processi GESTIONE DEI PROCESSI. Concetto di Processo. Scheduling di Processi. Operazioni su Processi. Processi Cooperanti

Sistemi Operativi. Processi GESTIONE DEI PROCESSI. Concetto di Processo. Scheduling di Processi. Operazioni su Processi. Processi Cooperanti GESTIONE DEI PROCESSI 4.1 Processi Concetto di Processo Scheduling di Processi Operazioni su Processi Processi Cooperanti Concetto di Thread Modelli Multithread I thread in diversi S.O. 4.2 Concetto di

Dettagli

Windows Vista, il nuovo sistema operativo Microsoft che cerca le giuste risposte ai quesiti di sicurezza

Windows Vista, il nuovo sistema operativo Microsoft che cerca le giuste risposte ai quesiti di sicurezza Windows Vista, il nuovo sistema operativo Microsoft che cerca le giuste risposte ai quesiti di sicurezza Microsoft Windows è il sistema operativo più diffuso, ma paradossalmente è anche quello meno sicuro.

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1 Introduzione Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio Livello applicativo Principi delle applicazioni di rete 2-1 Pila di protocolli Internet Software applicazione: di

Dettagli

IBM Access Connections 2.7 - Guida alla distribuzione

IBM Access Connections 2.7 - Guida alla distribuzione IBM Access Connections 2.7 - Guida alla distribuzione ii IBM Access Connections 2.7 - Guida alla distribuzione Indice Capitolo 1. A chi è rivolto questo manuale............... 1 Capitolo 2. Informazioni

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Sistemi Operativi. ugoerr+so@dia.unisa.it 3 LEZIONE PROCESSI CORSO DI LAUREA TRIENNALE IN INFORMATICA. Sistemi Operativi 2007/08

Sistemi Operativi. ugoerr+so@dia.unisa.it 3 LEZIONE PROCESSI CORSO DI LAUREA TRIENNALE IN INFORMATICA. Sistemi Operativi 2007/08 Sistemi Operativi Docente: Ugo Erra ugoerr+so@dia.unisa.it 3 LEZIONE PROCESSI CORSO DI LAUREA TRIENNALE IN INFORMATICA UNIVERSITA DEGLI STUDI DELLA BASILICATA Sommario della lezione Concetto di processo

Dettagli

Esercitazioni di Basi di Dati

Esercitazioni di Basi di Dati Esercitazioni di Basi di Dati A.A. 2008-09 Dispense del corso Utilizzo base di pgadmin III Lorenzo Sarti sarti@dii.unisi.it PgAdmin III PgAdmin III è un sistema di progettazione e gestione grafica di database

Dettagli

Il Sistema Operativo. Funzionalità. Sistema operativo. Sistema Operativo (Software di base)

Il Sistema Operativo. Funzionalità. Sistema operativo. Sistema Operativo (Software di base) Sistema Operativo (Software di base) Il Sistema Operativo Il sistema operativo è un insieme di programmi che opera sul livello macchina e offre funzionalità di alto livello Es.organizzazione dei dati attraverso

Dettagli

INTRODUZIONE AI SISTEMI OPERATIVI

INTRODUZIONE AI SISTEMI OPERATIVI INTRODUZIONE AI SISTEMI OPERATIVI Il sistema operativo è il software che permette l esecuzione di programmi applicativi e lo sviluppo di nuovi programmi. CARATTERISTICHE Gestisce le risorse hardware e

Dettagli

Cenni sulla Sicurezza in Ambienti Distribuiti

Cenni sulla Sicurezza in Ambienti Distribuiti Cenni sulla Sicurezza in Ambienti Distribuiti Cataldo Basile < cataldo.basile @ polito.it > Politecnico di Torino Dip. Automatica e Informatica Motivazioni l architettura TCP/IPv4 è insicura il problema

Dettagli

Problemi legati alla sicurezza e soluzioni

Problemi legati alla sicurezza e soluzioni Corso DOMOTICA ED EDIFICI INTELLIGENTI UNIVERSITA DI URBINO Docente: Ing. Luca Romanelli Mail: romanelli@baxsrl.com Accesso remoto ad impianti domotici Problemi legati alla sicurezza e soluzioni Domotica

Dettagli