VAI ALLA BIBLIOGRAFIA E PUNTATORI A RISORSE DI RETE
CAPITOLO 6 : MASSC (Architettura per Smart Card)
6.1 Struttura di MASSC (Multi Application Secure Smart Card)
6.4 Sicurezza dell’architettura MASSC
Protezione del codice
Protezione dei dati nella RAM
Protezione dei dati della EEPROM
CAPITOLO 6 : MASSC (Architettura per Smart Card)
Il progetto MASSC (Multi Application Secure Smart Card)
è finalizzato alla realizzazione di una piattaforma sicura per Smart
Card (componenti e software) per transazioni su reti globali. I promotori
di tale progetto sono aziende specializzate nel settore quali: Bull, DeLaRue,
Oscard, STMicroelectronics, Philiphs, Telecom Italia Mobile. I principali
obiettivi di sviluppo comprendono ottimizzazione delle prestazioni, modularità,
sicurezza.
La generica Struttura di MASSC (mostrata in figura 21) comprende interfaccie definite tra applicazioni e Sistema Operativo (definite come System call interface), tra Sistema Operativo e strato Hardware (HIS, Hardware-Software Interface) e tra Virtuale Machine e applicazioni (java API).
Il progetto prevede una definizione di tipo generale che non si lega ad una specifico Hardware o Sistema Operativo, e permette l’implementazione di diverse tipologie di configurazione dei componenti (modifiche del Sistema Operativo, della VM e del processore).
Questa architettura è simile a quella vista per
le generiche JavaCard e prevede lo sviluppo separato dei componenti lasciando
fisse le interfaccie tra gli strati. La JVM (Java Virtual Machine) è
una particolare applicazione che poggia sul Sistema Operativo e la Java
API risulta ben separata dalla System call interface. Tale JVM interpreta
i metodi definiti dalla API e crea il Byte Code corrispondente alle System
Call supportate, garantendo una separazione logica tra linguaggi di alto
livello e codici specifici della carta in uso. Il software del Sistema
Operativo (e della macchina virtuale) è scritto in linguaggio compilato
(solitamente C), con parti dipendenti dall’Hardware di basso livello in
Assembler (dello specifico processore). Il Sistema Operativo prende il
controllo della carta all’accensione, manda l’ATR ed offre un insieme di
servizi alle applicazioni native; tra cui, il ripristino di transazioni
interrotte, cicli di attesa ed interpretazione delle istruzioni, passaggio
dei comandi all’applicazione corrente. Le applicazioni di alto livello
(java applet) vedono questi servizi come implementati dalla Virtuale Machine
presente sulla carta.
TORNA ALL'INDICE
DEL CAPITOLO ATTUALE (CAP 6 : MASSC Generica Architettura per Smart
Card )
Il progetto MASSC ha portato alla realizzazione (presentata
nel Novembre 1999) di una particolare piattaforma basata sul microprocessore
Tiny?J della STMicroelectronics, e presenta una struttura mostrata in figura
22. Tale processore è un RISC (Reduced Instruction Set Computer)
sviluppato per supportare il linguaggio nativo ed il Java Bytecode. Questo
permette una notevole velocità di computazione rispetto a processori
tradizionali che devono simulare la macchina virtuale sulla carta. Il linguaggio
nativo è utilizzato per eseguire il Sistema Operativo e le funzioni
supportate in modo efficiente, mentre il Bytecode è utilizzato dalle
applicazioni java. La frequenza del clock è con cui sono state realizzate
le prove è di 40 Mhz ha permesso prestazioni dell’ordine dei 35
MIPS, ed anche con frequenze standard (3-5 Mhz) le prestazioni sono 10
volte superiori rispetto a carte tradizionali. Il set di istruzioni comprende
operazioni aritmetiche, logiche, gestione dati e di sistema e crittografiche.
Tiny?J è compatibile con le specifiche del Java Bytecode (JavaCard
2.1) di tipo Short (Bytecode visto in precedenza) e decodifica tale codice
in una o più istruzioni del linguaggio RISC nativo (a livello Hardware).
Alcune caratteristiche sono date di seguito.
Registri: sono presenti 16 registri a 32-bit indirizzabili su bus a 32-bit, altri di dimensioni variabili ed indirizzamenti di memoria a 24-Bit.
Istruzioni: le istruzioni native sono da 1 a 4 Byte e sono presenti istruzioni speciali per la gestione dello Stack (frequente) e per salti condizionali. Tali istruzioni sono elaborate con pipeline in quatto fasi (Fetch, decode, execute e Writeback) in un unico ciclo.
Java decoder: Un decoder per istruzioni Java è accoppiato al pipeline delle istruzioni native e comprende due fasi (Bytecode Fetch e decodifica). Le istruzioni Java sono prima trasformate in codice nativo e poi elaborate come tali.
Modalità di esecuzione: sono Java e modo
nativo, la prima usato per il Java Bytecode, la seconda per Long Java Bytecode
(istruzioni di più Byte), routine si sistema e codice nativo.
Memoria: sono presenti due Bus di memoria, uno per le RAM ed uno per le ROM ed EEPROM. Questo permette l’accesso contemporaneo a dati ed istruzioni migliorando le prestazioni; infatti, i dati frequentemente utilizzati sono posti sullo Stack in RAM, mentre le istruzioni native ed i metodi Java sono contenuti in ROM ed EEPROM. Sono presenti 4 Kbyte di RAM, 96 Kbyte di ROM e 64 Kbyte di EEPROM.
Sicurezza e domini: un circuito di protezione della memoria protegge l’accesso ai domini di sicurezza limitandolo a determinate parti della memoria. Ogni processo agisce all’interno di un determinato dominio confinato in una particolare regione di memoria, in modo da evitare utilizzi non permessi dei dati. Il circuito proibisce l’accesso a dati e metodi non appartenenti al dominio del processo corrente. Il passaggio a un nuovo processo (cambio di contesto) è permesso in occasione di eventi particolari quali interruzioni esterne, abort interni ed esterni o chiamate di dominio. Tale passaggio è fortemente controllato per garantire la sicurezza sulla carta. Circuiti di protezione sull’alimentazione e frequenza del clock controllano la corretta interazione con l’esterno.
Stack: sono presenti 4 Stack. Uno da 16-bit, per
contenere valori durante l’esecuzione del Java Bytecode. Due a 32-bit per
la modalità nativa, utilizzati dalle istruzioni C del codice di
Sistema Operativo per eseguire annidamenti di chiamate a subroutine. L’ultimo
è utilizzato per i cambi di contesto tra diversi domini (Program
counter, dominio, stack pointer, e registri di stato).
TORNA ALL'INDICE
DEL CAPITOLO ATTUALE (CAP 6 : MASSC Generica Architettura per Smart
Card )
Lo schema dell’architettura Software di MASSC (indicato
in figura 23) mostra la suddivisione dei componenti in vari livelli ed
il loro interfacciamento. Il Software dello strato più basso include
il supporto per l’Hardware (microcontrollore MCU) e fornisce l’HSI (Hardware-Software
Interface).Lo strato Kernel contiene il Software della parte di Sistema
Operativo dipendente dal particolare microcontrollore utilizzato. Gli strati
Middle e Service la parte indipendente che fornisce la SCI (System Call
Interface). Gli ultimi strati implementano la Macchina Virtuale e il caricatore
delle applet. Le applicazioni di sistema (System Application) sono identificate
per mezzo dell’AID unico e gestite similmente alle altre Applet, ad eccezione
del fatto che possono effettuare chiamate di sistema (system call) particolari
(non permesse alle applicazioni utente). I principali componenti sono brevemente
descritti di seguito.
RAM Manager: Il gestore della RAM controlla l’allocazione dei Buffer della memoria RAM nello Heap del Sistema Operativo, la validità dei puntatori nelle chiamate al Sistema Operativo e cancella il contenuto degli Stack in caso di deselezione dell’applicazione.
Entity Manager: questa parte fornisce servizi per l’allocazione di parti di memoria non volatile (EEPROM) e l’accesso a tali aree, si occupa anche di minimizzare la frammentazione della memoria ed effettua controlli sulla integrità delle celle.
Start-up Handler: Questo modulo è responsabile di tutte le operazioni necessarie alla gestione dell’accensione della carta (ripristino di contesto dopo l’inserimento della carta nel lettore). Deve generare l’ATR, gestire la selezione del corretto protocollo di trasmissione ed effettuare il roolback di eventuali transazioni.
Card executive: questo modulo (contenuto nel Card
Manager) può essere pensato come la parte del Sistema Operativo
che seleziona un’applicazione (attraverso APDU di SELECT) e si occupa di
indirizzarle i comandi provenienti da livelli superiori. In generale dopo
un reset viene lanciato il modulo Start-up Handler ed in seguito il controllo
passa al Card Executive che può essere visto come procedura Main
() del Sistema Operativo.
Virtual Machine: la Macchina virtuale opera sopra il Sistema Operativo e ne utilizza le funzioni offerte. Si occupa di interpretare, controllare ed eseguire le istruzioni Bytecode provenienti dalle applet ed offrire una interfaccia di programmazione (API) verso l’esterno. MASSC prevede la possibilità di far girare diversi tipi di macchine virtuali, provenienti da diversi sviluppatori e supportanti linguaggi differenti. Attualmente è implementata solo la JavaCard Virtual Machine, ma l’idea è quella di rendere compatibile una carta con differenti sistemi multi applicazione esistenti.
APDU Manager: questo componente fornisce le chiamate di sistema per accedere ai comandi degli APDU e costruire appropriati APDU di risposta. Si occupa di gestire il formato di trasmissione degli APDU per renderlo indipendente dal protocollo di comunicazione utilizzato (T=0, T=1 o T=14, ossia definito dallo sviluppatore dell’applicazione); in questo modo applicazioni che utilizzano protocolli diversi sono correttamente servite. Le applicazioni possono comunicare in modo sincrono o asincrono con l’esterno. Nel primo caso l’applicazione controlla la comunicazione restando bloccata fino all’invio completo del messaggio. Nel secondo caso è il Sistema Operativo che si occupa del trasferimento in background del messaggio. La seconda modalità è quindi non bloccante ma richiede un buffer per gestire la trasmissione differita.
Cryptographic Server: questo componente fornisce
tre principali servizi crittografici: crittografia simmetrica, asimmetrica
e Hashing (descritti brevemente nel capitolo 4).
Loader: questo componente si occupa di caricare
di caricare le nuove applet provenienti da un compilatore esterno (file
.CAP visti in precedenza) all’interno della memoria EEPROM della carta.
Questo viene fatto in due principali fasi, una esterna ed una interna alla
carta:
TORNA ALL'INDICE
DEL CAPITOLO ATTUALE (CAP 6 : MASSC Generica Architettura per Smart
Card )
6.4 Sicurezza
dell’architettura MASSC
La sicurezza del sistema è uno dei parametri di
progetto più rilevanti per l’architettura MASSC. Il punto di partenza
è la separazione tra applicazioni e Sistema Operativo (sia del codice
che dei dati). Basandosi su questo principio è possibile implementare
diverse soluzioni per mezzo dello strato Hardware sottostante (MMU, Memori
Management Unit) e scegliere in funzione di costi, sicurezza e prestazioni.
Il metodo scelto è utilizzato sia per le applicazioni proprie del
sistema (scritte in codice nativo) che per le applet (scritte in Java Bytecode).
Il sistema offre una Sandbox di esecuzione sicura in entrambe i casi. Le
principali caratteristiche di sicurezza di MASSC sono rappresentate dalla
protezione del codice, della memoria RAM e della memoria non volatile (EEPROM).
Protezione del codice
Una applicazione lanciata dal Sistema Operativo deve restare all’interno dello spazio di memoria competente al proprio codice per impedire che possa saltare al codice relativo ad un’altra applicazione. Senza tale limitazione, si potrebbero verificare salti al codice di altre applicazioni senza che il Sistema Operativo possa intervenire sui valori relativi allo stato del sistema. L’Hardware implementa questi meccanismi di protezione del codice creando una finestra di modalità utente, in cui le istruzioni sono controllate prima di essere eseguite. Il Sistema Operativo setta i corretti valori di tale finestra utente, in tal modo, durante il ciclo di fetch (operato dalla MMU) è eseguito il controllo sulla possibile esecuzione del codice. Il codice presente sulla RAM è protetto per mezzo di domini di appartenenza.
Protezione dei dati nella RAM
Quanto visto sopra vale anche per i dati presenti nella
memoria RAM. Una applicazione non deve potere accedere ai dati del Sistema
Operativo (o di eventuali applicazioni concorrenti) presenti nella RAM.
Poiché anche le applicazioni hanno accesso diretto alla RAM, con
istruzioni di lettura e scrittura, la sicurezza è garantita con
finestre implementate in Hardware che delimitano lo spazio di memoria accessibile.
In figura 24 è mostrata la finestra accessibile ad un’applicazione
in ROM e RAM.
Protezione dei dati della EEPROM
L’architettura MASSC prevede l’accesso ai dati presenti
nella memoria EEPROM attraverso chiamate di Sistema Operativo. Le applicazioni
non possono quindi accedere in modo diretto a tali dati ma devono ricorrere
a riferimenti logici. Il Sistema Operativo si occupa della corretta correlazione
tra i riferimenti logici utilizzati dalle applicazioni ed indirizzi fisici
dei dati richiesti. Questo principio permette una incapsulazione dei dati
ed una gestione dei dati indipendente dalla posizione fisicamente occupata.
Le applicazioni, ad esempio, possono utilizzare una chiave crittografica
senza potere accedere direttamente alla memoria (o alterarne il contenuto).
L’accesso logico anziché fisico permette una gestione della frammentazione
dei dati immagazzinati, e rende semplice il rilascio di spazzi aggiuntivi
eventualmente richiesti dalle applicazioni. In figura 25 è mostrato
un esempio di frammentazione dei dati relativi ad una singola applicazione
sulla EEPROM.
TORNA ALL'INDICE DEL CAPITOLO ATTUALE (CAP 6 : MASSC Generica Architettura per Smart Card )