Appunti per Scuola e Università
humanisticheUmanistiche
Appunti e tesine di tutte le materie per gli studenti delle scuole medie riguardanti le materie umanistiche: dall'italiano alla storia riguardanti le materie umanistiche: dall'italiano alla storia 
sceintificheScientifiche
Appunti, analisi, compresione per le scuole medie suddivisi per materie scientifiche, per ognuna troverai appunti, dispense, esercitazioni, tesi e riassunti in download.
tecnicheTecniche
Gli appunti, le tesine e riassunti di tecnica amministrativa, ingegneria tecnico, costruzione. Tutti gli appunti di AppuntiMania.com gratis!
Appunti
informatica
CComputerDatabaseInternetJava
Linux unixReti


AppuntiMania.com » Informatica » Appunti di Java » Dalle Smart Card alle Java Card

Dalle Smart Card alle Java Card




Visite: 1552Gradito:apreciate stela [ Picolo appunti ]
Leggi anche appunti:

La firma digitale


La firma digitale Un utilizzo molto diffuso della crittografia è per processi

Dalle Smart Card alle Java Card


Dalle Smart Card alle Java Card Il principale limite delle Smart Card era

La sicurezza delle Java card


La sicurezza delle Java card Le procedure di sicurezza delle Java Card sono
immagine di categoria



Scarica gratis Dalle Smart Card alle Java Card

Dalle Smart Card alle Java Card


Il principale limite delle Smart Card era essenzialmente rappresentato dai lunghi tempi di produzione delle carte, limite che spesso finiva col rele-gare le Smart Card sempre un passo indietro rispetto alle richieste del mercato.

I programmi per le Smart Card venivano scritti direttamente in linguaggio assembler e venivano salvati nella ROM; ciò imponeva che il codice di tali applicazioni non potesse subire alcuna evoluzione nè aggiornamento e di fatto rappresentava una forte limitazione all'evoluzione dell'uso di tali carte.



Per poter emettere una carta con una applicazione era infatti richiesta una scrittura precisa e dettagliata delle specifiche, la scrittura e riscrittura del software di base (una sorta di sistema operativo) per le diverse piat-taforme, lo sviluppo di specifiche funzionalità per l'applicazione ed infine la verifica del software prima del suo caricamento su un numero assai ele-vato di carte. É facile comprendere come questo processo fosse pesante in termini di tempo e soprattutto di costi.

Per avvicinarsi sempre di più alle esigenze dei consumatori ed al tempo stesso per ridurre il time-to-market e rendere sempre più flessibili le applicazioni per le carte, negli ultimi anni si è fatta strada una nuova generazione di Smart Card chiamata Java Card.

A differenza delle Smart Card, che una volta prodotte e distribuite all'u-tente risultano immodificabili, le Java Card consentono all'utente di scari-care piccole applicazioni sulla propria carta in modo da poter modificare i servizi offerti dalla carta stessa.

Le Java Card vengono costruite basandosi sugli stessi standard delle Smart Card rappresentando dunque una loro evoluzione. Questo aspetto rende possibile inserire le Java Card all'interno di ambienti che utilizzano Smart Card senza dover modificare il software.



Caratteristiche di una Java Card


Il principale obiettivo della tecnologia Java Card è stato quello di inserire nella carta un sistema Java tale da lasciare ampio spazio di memoria per le applicazioni. Questa soluzione ha fatto sì che le Java Card siano in grado di supportare solo un sottoinsieme di istruzioni del linguaggio Java [7] ed ha portato ad un nuovo modello "splittato" della Java Virtual Machine (JVM).

La Java Card Virtual Machine (JCVM) [1], la versione della JVM per Java Card, risulta infatti divisa, "splittata" in due parti: una parte che lavora off-card e l'altra che lavora invece on-card. La parte di JCVM che lavora on-card si preoccupa di eseguire il bytecode delle applicazioni, di verificare l'allocazione della memoria, di gestire gli oggetti creati dall'applicazione, e di garantire la sicurezza dinamica, come sarà ampiamente illustrato nel prossimo capitolo.



Il linguaggio supportato dalla Java Card


Data la scarsa disponibilità di memoria, le Java Card supportano solo un sottoinsieme di istruzioni del linguaggio Java. Nelle Tabelle 2.3 e 2.4 vengono illustrate rispettivamente le limitazioni imposte al linguaggio Java ed alla struttura dei programmi per Java Card.


Keyword

native, synchronized, transient, volatile, strictfp non sono supportati.

Tipi

char, double, float, long, e gli array multidimensionali non sono supportati. Il tipo int è opzionale.

Classi e interfacce

Le classi e le interfacce API (java.io, java.lang, java.util) sono previste solo per Object e Throwable. La maggior parte dei metodi di Object e Throwable non sono disponibili.

Eccezioni

Molte classi di eccezioni ed errori sono non previste.


Tabella 2.3 : Principali limitazioni al linguaggio Java per Java Card


Package

Un package può al massimo riferire altri 128 package

Un package può contenere al massimo 255 classi.

Un package può avere al massimo 256 metodi static se contiene applet (è un applet package), oppure al massimo 255 metodi static se non contiene applet (è un library package).

Classi

Una classe può direttamente o indirettamente implementare fino ad un massimo di 15 interfacce.

Una classe può implementare fino ad un massimo di 128 istanze di metodi public o protected, ed al massimo 128 istanze di metodi private.


Tabella 2.4 : Principali limitazioni alla struttura di applet Java per Java Card





Java Card Runtime Environment


Il  Java Card Runtime Environment (JCRE) riunisce tutti i componenti del Java Card system che lavorano sulla Java Card.

Il JCRE è responsabile delle politiche di gestione delle risorse, dell'esecu-zione delle applet e del sistema di sicurezza on-card.

L'architettura del JCRE è illustrata in Figura 2.7.


Le framework classes definiscono le interfacce disponibili per le applica-zioni e sono costruite ed adattate specificamente per le applet delle Java Card così da rendere davvero semplice costruire un'applet per una Java Card.

Le industry-specific extensions definiscono servizi aggiuntivi di sicurezza per le applet.

L'installer si preoccupa invece di garantire la possibilità di scaricare sulla carta, dopo che questa è stata prodotta e distribuita all'utente, nuove ap-plicazioni in sicurezza. L'installer collabora con il programma di instal-lazione off-card .

Le system classes costituiscono il nucleo del sistema operativo delle Java Card.

Infine i native methods mettono a disposizione dei supporti per la JCVM e per le system classes.



Figura 2.7 : Struttura del JCRE



Il JCRE viene inizializzato una sola volta durante il tempo di vita della Java Card al tempo di inizializzazione globale della carta.

Quando l'alimentazione della carta viene meno il JCRE è solamente sospeso e lo stato del JCRE e degli oggetti creati sulla carta viene preser-vato.

Quando la carta viene nuovamente alimentata, il JCRE riattiva l'ese-cuzione della JCVM prelevando i dati necessari dalla memoria non volatile (EEPROM).


Il periodo che va dal momento che la Java Card viene inserita in un CAD al momento in cui la carta viene rimossa dal CAD e chiamato CAD ses-sion.

Durante una CAD session il JCRE opera come una normale Smart Card ovvero supporta la comunicazione con l'host mediante APDU.

Subito dopo che la carta viene inserita in un CAD per iniziare una CAD session, il JCRE, dopo aver inviato una ATR APDU all'host, entra in un loop in attesa di una select APDU ovvero di una APDU di selezione di un applet della carta.

Quando questa select APDU arriva, il JCRE seleziona l'applet richiesta e instrada verso di lei tutte le successive APDU lasciando quindi all'applet il compito di analizzare il contenuto delle APDU e di selezionare gli oppor-tuni metodi dell'applet.

Terminate le operazioni, l'applet restituisce il controllo al JCRE che si mette in attesa di una nuova select APDU, ed il loop riparte.



Creazione di una Java Card Applet


Analizziamo adesso come si realizza una Java Card Applet [8,15].

In Figura 2.8 è illustrato il processo di realizzazione di una Java Applet.



Figura 2.8 : Processo di creazione di una applet


Questo processo inizia con la scrittura dell'applicazione attraverso la sua scomposizione in classi Java che verranno salvate in altrettanti file Java.

Questi file verranno dapprima compilati per produrre class file e suc-cessivamente inviati al simulatore che esegue e testa l'applet simulando su PC il JCRE della carta.

Durante la simulazione l'applet viene eseguita mediante JVM e dunque alcuni aspetti tipici delle Java Card quali ad esempio il meccanismo del Firewall o la definizione di oggetti transienti o persistenti, che vedremo meglio più avanti, non vengono  presi in considerazione in questa fase.

Successivamente i class file che costituiscono un package vengono inviati al converter, il quale riceve in ingresso anche eventuali export file relativi a package esterni cui l'applicazione fa eventualmente riferimento e produce un CAP (Converted APplet) file ed un export file per il package.

Infine il CAP file prodotto dal converter viene eseguito e testato da un emulatore che simula su PC la JCVM della Java Card e dunque l'ambien-te di esecuzione del package risulta essere esattamente lo stesso che si trova su una Java Card.

Se l'emulazione ha successo e l'applet risulta funzionare correttamente può adesso essere caricata ed installata su una Java Card.



Denominazione di applet e package


Concludiamo questa introduzione parlando della denominazione che as-sumono nella piattaforma Java Card le applet oppure i package che rappresentano un insieme di applet associate ad una singola applicazione.

Nella piattaforma Java Card ciascuna istanza di applet o ciascun package è univocamente identificato da un Application IDentifier (o AID). Quando un package viene dunque caricato sulla carta, questo può comunicare con altri package presenti sulla carta mediante i relativi AID.

L'AID è un array di byte che è costituito da due parti: la prima parte ha una lunghezza fissa di 5 byte e prende il nome di Resource IDentifier (o RID), la seconda parte ha invece una lunghezza variabile da 0 a 11 byte e prende il nome di Proprietary Identifier eXtension (o PIX).

Lo standard ISO gestisce l'assegnamento dei RID alle compagnie produt-trici di applet in modo che ciascuna compagnia si veda assegnato un uni-co RID. Ciascuna compagnia gestisce in autonomia l'assegnazione dei PIX ai package prodotti. La concatenazione tra il RID (che identifica la compagnia produttrice) ed il PIX (che identifica i package e le applet prodotti dalla compagnia) costituisce l'AID. L'AID dei package e l'AID di default per ciascuna applet definita in un package viene specificato al converter per generare correttamente il CAP file.


Scarica gratis Dalle Smart Card alle Java Card
Appunti su:











Scarica 100% gratis e , tesine, riassunti



Registrati ora

Password dimenticata?
  • Appunti superiori
  • In questa sezione troverai sunti esame, dispense, appunti universitari, esercitazioni e tesi, suddivisi per le principali facoltà.
  • Università
  • Appunti, dispense, esercitazioni, riassunti direttamente dalla tua aula Universitaria
  • all'Informatica
  • Introduzione all'Informatica, Information and Comunication Tecnology, componenti del computer, software, hardware ...

Appunti c c
Tesine internet internet
Lezioni database database