Tradotto dal Afrikaans al Italiano - www.onlinedoctranslator.

com

Guida per sviluppatori di applet Java Card

Sun Microsystems, Inc.

901 San Antonio Road Palo
Alto, CA 94303 USA 650
960-1300

Revisione 1.10, 17 luglio 1998

Copyright 1998 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94043 USA. Tutti i
diritti riservati.

Questo prodotto o documento è protetto da copyright e distribuito con licenze che ne limitano l'uso, la copia, la distribuzione e la decompilazione. Nessuna
parte di questo prodotto o documento può essere riprodotta in qualsiasi forma con qualsiasi mezzo senza previa autorizzazione scritta di Sun e dei suoi
eventuali licenziatari. Il software di terze parti in questo prodotto, se presente, è protetto da copyright e concesso in licenza dai fornitori Sun.

DIRITTI LIMITATI: L'uso, la duplicazione o la divulgazione da parte del governo degli Stati Uniti è soggetto alle restrizioni di FAR
52.227-14 (g) (2) (6/87) e FAR 52.227-19 (6/87) o DFAR 252.227-7015 ( b) (6/95) e DFAR 227.7202-3 (a).

Sun, Sun Microsystems, il logo Sun, Solaris, Java, Java Powered, il logo Java Powered, il logo Coffee Cup, Java Card, JavaPurse e
tutti gli altri marchi Sun basati su Java sono marchi, marchi registrati o marchi di servizio di Sun Microsistemi, Inc. negli Stati
Uniti e in altri paesi.

QUESTA PUBBLICAZIONE VIENE FORNITA "COSÌ COM'È" SENZA ALCUN TIPO DI GARANZIA, ESPRESSA O IMPLICITA,
INCLUSE, A TITOLO ESEMPLIFICATIVO, LE GARANZIE IMPLICITE DI COMMERCIABILITÀ, IDONEITÀ PER UNO SCOPO
PARTICOLARE O NON.

QUESTA PUBBLICAZIONE POTREBBE CONTENERE IMPRECISIONI TECNICHE O ERRORI TIPOGRAFICI. LE MODIFICHE SONO
AGGIUNTE PERIODICAMENTE ALLE INFORMAZIONI QUI PRESENTE; QUESTE CAMBIAMENTI SARANNO INCORPORATI NELLE
NUOVE EDIZIONI DELLA PUBBLICAZIONE. SUN MICROSYSTEMS, INC. PUÒ APPORTARE MIGLIORAMENTI E/O CAMBIAMENTI
AL PRODOTTO E/O AI PROGRAMMI DESCRITTI IN QUESTA PUBBLICAZIONE IN QUALSIASI MOMENTO.
 Guida per sviluppatori di applet Java Card

Contenuti

Prefazione viii

1. Panoramica 1-1

Architettura della smart card 1-1

Interfaccia di comunicazione 1-2

Smart Card CPU 1-2

Memoria su scheda 1-2

Unità dati protocollo applicativo 1-3

Smart Card con tecnologia Java 1-3

Carta bloccata 1-5

2. Tecnologia Java Card 2-1

La macchina virtuale 2-1

Specifiche della lingua 2-2

Discussioni 2-3

Raccolta dei rifiuti 2-3

Tipi primitivi 2-3

Matrici 2-6

Eredità 2-6

Sicurezza 2-7

Portabilità 2-7

Eccezioni 2-7

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. iii

Guida per sviluppatori di applet Java Card

Classi principali 2-9

La classe lanciabile 2-9

La classe dell'oggetto 2-10

Creazione di un'applet per schede Java 3-1

Un esempio di base 3-2

Installazione dell'applet della scheda Java 3-5

L'applet Classe 3-5

Registrazione dell'applet 3-6

Selezione dell'applet 3-7

Lavorare con APDU 3-8

Sequenza di comunicazione APDU 3-10

Ricezione dei dati APDU 3-10

Risposte dell'APDU 3-12

Valori di ritorno 3-13

Atomicità 3-14

Conferma buffer 3-14

4. Ottimizzazione delle applet per schede Java 4-1

Riutilizzo di oggetti 4-1

Allocazione della memoria 4-2

Accesso agli elementi dell'array 4-2

5. File 5-1

File elementari e dedicati 5-1

Registra i file 5-1

La classe FileSystem 5-3

Operazioni sui file 5-4

Sicurezza dei file 5-5

Trovare i file 5-6

Registra le operazioni 5-7

IV Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Trovare record 5-7

Gestione dei file con la classe FileSystem 5-8

Crittografia 6-1

Concetti di crittografia 6-1

Tasti simmetrici 6-2

Verifica dei messaggi codificati in modo simmetrico 6-3

Tasti asimmetrici 6-4

Autenticazione e verifica 6-5

Glossario 1

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. v

Guida per sviluppatori di applet Java Card

Figure

FIGURA 1-1 Fronte e retro delle Smart Card 1-1

FIGURA 1-2 Otto punti di contatto del chip della Smart Card 1-2 Dispositivo
FIGURA 1-3 di accettazione della carta 1-2
FIGURA 1-4 Architettura della tecnologia Java Card 1-4
FIGURA 1-5 Creazione di un'applet Java Card 1-5 Creazione
FIGURA 3-1 di un'applet Java Card 3-1 Selezione dell'applet
FIGURA 3-2 3-7
FIGURA 3-3 Lunghezza del buffer 3-11
FIGURA 3-4 Dividi il buffer APDU 3-12
FIGURA 5-1 File lineari 5-2
FIGURA 5-2 Ordine record file ciclico 5-2 File ciclico
FIGURA 5-3 dopo il record aggiunto 5-2 Gerarchia
FIGURA 5-4 classi FileSystem 5-3 Gerarchia dati
FIGURA 5-5 applet 5-4
FIGURA 6-1 Grafico 6-3 della BCE
FIGURA 6-2 Diagramma CBC 6-3

vi Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Tabelle

TABELLA 1-1 Componenti software Smart Card 1-3

TABELLA 2-1 Tipi primitivi supportati 2-3 Tipi
TABELLA 2-2 primitivi non supportati 2-4 Eccezioni
TABELLA 2-3 supportate 2-8
TABELLA 2-4 Classi principali della piattaforma Java
TABELLA 5-1 Card 2-9 Classi e tipi di file 5-3
TABELLA 5-2 Flag di autorizzazione di accesso ai file 5-5
TABELLA 5-3 Flag di file 5-6
TABELLA 5-4 Indicatori di direzione della modalità di ricerca
TABELLA 5-5 5-8 Metodi del file system 5-8
TABELLA 5-6 Metodi FileSystem 5-9

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. vii

Guida per sviluppatori di applet Java Card

Prefazione

Giava-Carta-La tecnologia combina un sottoinsieme del linguaggio di programmazione Java con un ambiente di runtime
ottimizzato per smart card e relativi dispositivi embedded con memoria ridotta. L'obiettivo della tecnologia Java Card è di
portare molti dei vantaggi della programmazione del software Java nel mondo delle smart card con risorse limitate.

Questo documento illustra i concetti e le API di cui gli sviluppatori hanno bisogno per scrivere applicazioni (applet) per la
piattaforma Java Card. Questo documento è specifico della versione 2.0 della specifica API Java Card per l'utilizzo con la
versione 1.0.2 del Java Development Kit (JDK). Dopo aver letto questa guida, uno sviluppatore avrà una conoscenza sufficiente
dei concetti di programmazione della tecnologia Java Card e dell'API Java Card per sviluppare applet software Java per smart
card.

Chi dovrebbe usare questa guida?

Gli sviluppatori del linguaggio Java, che desiderano estendere i loro sforzi di sviluppo su piattaforme di smart card, sono il pubblico
previsto di questa guida. È anche destinato all'uso da parte degli sviluppatori di smart card esistenti che sono abituati alla
programmazione in assembler o C.

Prima di leggere questa guida

Prima di leggere questa guida, dovresti familiarizzare con il linguaggio di programmazione Java, la Java Virtual Machine
e la tecnologia delle smart card. Una buona risorsa per acquisire familiarità con la tecnologia Java e la tecnologia Java
Card è il Sun Microsystems, Inc. sito web, che si trova all'indirizzo: http://java.sun.com. Per scaricare il JDK, vedere
http://java.sun.com/products/jdk/.

viii Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Come è organizzata questa guida

Capitolo 1, "Panoramica",fornisce una panoramica delle smart card e dell'architettura della tecnologia Java Card.

Capitolo 2, "Tecnologia Java Card",fornisce uno sguardo alla tecnologia Java Card a titolo di confronto con la
tecnologia Java.

Capitolo 3, "Creazione di un'applet Java Card",fornisce un'applet Java Card di esempio e descrive come creare la
prima applet Java Card.

Capitolo 4, "Ottimizzazione delle applet Java Card",descrive le considerazioni sulla programmazione per
l'ambiente con risorse limitate della smart card.

Capitolo 5, "File",spiega come utilizzare le classi di file della tecnologia Java Card.

Capitolo 6, "Crittografia",spiega come utilizzare le classi di crittografia della tecnologia Java Card.

Glossarioè un elenco di parole e le loro definizioni per aiutarti nell'utilizzo di questa guida.

Documenti correlati
In questo manuale si fa riferimento a vari documenti o prodotti. Dovresti avere a disposizione i
seguenti documenti:

- Interfaccia di programmazione dell'applicazione Java Card 2.0, Sun Microsystems, Inc.

- Sottoinsieme del linguaggio Java Card 2.0 e specifica della macchina virtuale, Sun Microsystems, Inc.

- La specifica del linguaggio Javadi James Gosling, Bill Joy e Guy L. Steele. Addison-Wesley, 1996, ISBN
0-201-63451-1.
- La specifica della macchina virtuale Java(Java Series) di Tim Lindholm e Frank Yellin. Addison-
Wesley, 1996, ISBN 0-201-63452-X.
- Specifiche ISO 7816 Parti 1-6.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. ix

 Guida per sviluppatori di applet Java Card

1. Panoramica

Le specifiche Java Card consentono alla tecnologia Java di funzionare su smart card e altri dispositivi con memoria limitata. Per
semplificare il materiale, il focus in questo documento è sulla smart card. Una smart card ha le stesse dimensioni di una tipica
carta di credito e memorizza ed elabora le informazioni attraverso i circuiti elettronici incorporati nel silicio nel substrato di
plastica della carta. Esistono due tipi base di smart card: memoria e intelligente. Una scheda di memoria memorizza i dati
localmente, ma non contiene una CPU per eseguire calcoli su quei dati. Una scheda intelligente (intelligente) include un
microprocessore e può eseguire calcoli su dati archiviati localmente.

Ci sono diversi vantaggi esclusivi della tecnologia Java Card in queste smart card, come ad esempio:

- Piattaforma indipendente—Le applet Java Card conformi alla specifica API Java Card verranno eseguite su schede
sviluppate utilizzando Java Card Application Environment (JCAE), consentendo agli sviluppatori di utilizzare la stessa applet
Java Card per l'esecuzione su schede di fornitori diversi.

- Capace di applicazioni multiple--Più applicazioni possono essere eseguite su una singola scheda. Nel linguaggio di
programmazione Java, il design intrinseco attorno a piccoli elementi di codice scaricabili semplifica l'esecuzione sicura di più
applicazioni su una singola scheda.

- Post-emissione delle domande—L'installazione delle applicazioni, dopo l'emissione della carta, offre agli
emittenti di carte la capacità di rispondere in modo dinamico alle mutevoli esigenze dei propri clienti.

- Flessibile—La metodologia orientata agli oggetti della tecnologia Java Card offre flessibilità nella
programmazione delle smart card.

- Compatibile con gli standard delle smart card esistenti—L'API Java Card è compatibile con
standard formali, come ISO7816, e standard specifici del settore.

Architettura delle smart card

L'architettura della smart card è costituita da un'interfaccia di comunicazione, memoria e una CPU per
eseguire calcoli ed elaborare informazioni. Il fronte e il retro della carta sono illustrati nella FIGURA 1-1.

Elettrico
contatti Banda magnetica
Microprocessore

XYZ B800010
Davanti Indietro

FIGURA 1-1 Fronte e retro delle Smart Card

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 1-1

Guida per sviluppatori di applet Java Card

Interfaccia di comunicazione

Una smart card non contiene il proprio alimentatore, display o tastiera. Interagisce con un dispositivo CAD (Card
Acceptance Device) utilizzando un'interfaccia di comunicazione, fornita da una raccolta di otto punti di contatto elettrici
o ottici, come illustrato nella FIGURA 1-2.

Potenza— (Vcc) (GND) —Terra

Ripristina— (RST) (Vpp) —Facoltativo

Orologio— (CLK) (I/O) —Ingresso/Uscita

Riservato per uso futuro— (RFU) (RFU) — Riservato per noi futuri e

FIGURA 1-2 Otto Punti di Contatto del Chip Smart Card

Dispositivo di accettazione della carta

Il dispositivo di accettazione della carta (CAD) (chiamato anche lettore di carte, lettore di dispositivi o terminale di carte) funge da
canale per le informazioni in entrata e in uscita dalla carta. La scheda deve essere inserita nel CAD, come illustrato in FIGURA 1-3,
per fornire alimentazione alla scheda (attraverso i suoi contatti, come descritto sopra).

FIGURA 1-3 Dispositivo di accettazione della carta

CPU Smart Card

La CPU su una smart card è semplice. Come risultato della sensibilità ai costi e del basso profilo delle CPU per smart card,
rappresentano la fascia bassa del mercato delle piattaforme software Java. Molti sviluppatori di linguaggi Java sono abituati a
un mondo di potenti CPU multitasking con grandi quantità di RAM, supporto di memoria virtuale, paging e dispositivi I/O
integrati. L'attuale tecnologia delle smart card rappresenta un ritorno ai giorni in cui le CPU erano dispositivi single-tasking a 8
bit con 1 KB di RAM o meno.

Memoria su scheda
Esistono tre tipi principali di memoria su una smart card, sono:

- ROM (Read-Only Memory) - contiene codice e dati che sono di sola lettura e non possono essere modificati. Le
informazioni memorizzate nella ROM persistono anche dopo aver scollegato l'alimentazione alla scheda.

1-2 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

- RAM (Random Access Memory) - è una memoria veloce e volatile. Qualsiasi informazione nella RAM viene persa quando viene
scollegata l'alimentazione alla scheda. Una tipica implementazione della piattaforma Java Card utilizza la RAM per gli stack di frame
e operandi e per la memorizzazione di dati temporanei.

- EEPROM (Electrical Erasable Programmable Read Only Memory) - è come la ROM in quanto le informazioni in questo tipo di
memoria persistono durante le sessioni di alimentazione. Tuttavia, la EEPROM ha l'ulteriore vantaggio di essere sia leggibile che
scrivibile, sebbene la scrittura su EEPROM sia più lenta della scrittura su RAM e la EEPROM sia soggetta ad usura. Dopo un
numero elevato di scritture su un particolare byte, in genere più di 100.000, l'integrità dei dati di quel byte nella EEPROM
potrebbe non riuscire. Per i dettagli, vedere le specifiche del produttore del chip.

Lo sviluppatore dell'applet deve assicurarsi che i campi temporanei che vengono aggiornati frequentemente siano componenti di
matrici transitorie. Ciò riduce la potenziale usura della memoria persistente e garantisce migliori prestazioni di scrittura. Come
regola generale, se un campo temporaneo viene aggiornato più volte per ciascuna APDU (Application Protocol Data Unit), lo
sviluppatore dell'applet dovrebbe spostarlo in una matrice transitoria.

Unità di dati del protocollo applicativo

Le smart card comunicano utilizzando un meccanismo a pacchetto chiamato Application Protocol Data APUDnU
suo) (. Intelligente

le carte sono comunicatori reattivi, ovvero non avviano mai comunicazioni, si limitano a resAppoDnU dsto
dal CAD. Il modello di comunicazione è basato sulla risposta al comando, ovvero theececiavredsra cm richiesta
APDU, esegue l'elaborazione richiesta da thmemcaond e restituisce un responAsPeDU. Vedi ilCreazione di un'applet
per schede Javacapitolo per ulteriori informazioni sul lavoro con wiA thPDU.

L'International Standards Organization (ISO) ha stabilito specifiche hardware e software per la

creazione di smart card interoperabili. Queste specifiche sono contenuteÈun
io7oth8e16 Parti 1-6documenti.
Ai fini dello sviluppo di applet Java Card, il docu più rilevanteiom COSÌe7T8io1S6-4.

Smart Card con tecnologia Java

Una smart card con tecnologia Java è una smart card in grado di eseguire applet Java Card. Queste applet vengono eseguite
nell'ambiente Jav Card, che può essere piccolo come:

- 24K di ROM
- 16K o EEPROM
- 512 byte di RAM

Oltre a CPU e memoria, una smart card con tecnologia Java contiene vari componenti software, come
descritto nella tabella seguente.

TABELLA 1-1 Componenti software per smart card

Componente software Descrizione

Sistema operativo della carta Il sistema operativo della carta (OS).

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 1-3

Guida per sviluppatori di applet Java Card

Servizi nativi Esegue i servizi di I/O, crittografia e allocazione della memoria della scheda.

VM La Java Card Virtual Machine (VM) fornisce l'esecuzione di bytecode e il supporto

del linguaggio Java, inclusa la gestione delle eccezioni.

Struttura L'insieme di classi che implementano l'API. Ciò include pacchetti di base
ed estensione. Le responsabilità includono l'invio di APDU, la selezione di
applet, la gestione dell'atomicità e l'installazione di applet.

API L'Application Programming Interface (API) definisce le convenzioni di

chiamata in base alle quali un'applet accede a JCRE e ai servizi nativi.

JCRE L'ambiente di runtime Java Card (JCRE) include la Java Card

Virtual Machine (VM), il framework, i metodi nativi associati e
l'API.

Estensioni del settore Classi aggiuntive che estendono le applet installate sulla scheda.

Applet Programmi scritti nel linguaggio di programmazione Java per l'uso su una smart
card.

Questi componenti sono illustrati nella FIGURA 1-4.

Applet Applet Applet

Industria-Sp Efficaci estensioni

JCRE
Struttura
UN
Pio

VM con scheda Java

Servizi nativi

Sistema operativo della carta

FIGURA 1-4 Architettura della tecnologia Java Card

Una differenza principale tra la Java Card Virtual Machine (JCVM) e la Java Virtual Machine (JVM) è che la JCVM è
implementata come due parti separate. In effetti, è distribuito sia nello spazio che nel tempo. Il primo pezzo
della VM viene eseguito off-card su un PC o workstation. Questa parte fuori scheda di JCVM, Java Card Converter,
esegue tutto il lavoro necessario per caricare le classi e risolvere i riferimenti ove possibile. La parte su scheda
della VM include l'interprete di bytecode.

1-4 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

L'interfaccia tra le due parti è un'applet compilata (file .cap), come illustrato nella FIGURA 1-5, prodotta dalla VM
esterna alla scheda durante il processo di sviluppo e utilizzata dalla VM sulla scheda durante il processo di
esecuzione.

Fuori carta Sulla carta

Convertitore JCRE
. classe

File

. cap
file

FIGURA 1-5 Creazione di un'applet per schede Java

Per ulteriori informazioni, vedere ilTecnologia Java Cardcapitolo e Java Card 2.0 Reference Implementation (JC2RI),
disponibile su Sun Microsystems, Inc. sito web, che si trova all'indirizzo http://java.sun.com.

Carta bloccata
Ci sono alcune condizioni che causano il blocco della carta, impedendo un ulteriore utilizzo della carta. Ad esempio, una carta
potrebbe bloccarsi quando viene rilevato un tentativo di violare la sicurezza della carta (forse il codice PIN viene inserito in modo
errato più di cinque volte consecutive). In questo caso, è necessario contattare l'emittente (e potrebbe essere necessario restituire
la carta) per ripristinare la VM da tale stato bloccato.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 1-5

 Guida per sviluppatori di applet Java Card

2. Tecnologia Java Card

La tecnologia Java Card preserva molti dei vantaggi del linguaggio di programmazione Java (produttività, sicurezza,
robustezza, strumenti e portabilità), consentendo al contempo l'utilizzo della tecnologia Java sulle smart card. La
macchina virtuale (VM), la definizione del linguaggio ei pacchetti principali sono stati resi più compatti e concisi per
portare la tecnologia Java nell'ambiente delle smart card con risorse limitate.

La macchina virtuale
La Java Card Virtual Machine (VM) fornitaBeySesecuzione di tecode e supporto del linguaggio Java, inclusa la gestione delle
eccezioni. Java Card Runtime Environment (JCRE) include una macchina virtuale (VM) e classi principali per supportare il routing
APDU, le comunicazioni ISO un
tio
protocolli icn ed elaborazione basata sulle transazioni.

La Java Card VM è in realtà divisa in due parti, una per l'esecuzione su scheda e l'altra per l'esecuzione su scheda, come
spiegato in tho eVisualizzacapitolo. La Java Card VM su scheda esegue bytecode, gestisce classi e
oggetti, impone la separazione tra le applicazioni (firewall) e consente la condivisione sicura dei dati.

La Java Card VM off-card contiene uno strumento Java Card Converter per fornire molte delle verifiche, preparazioni,
ottimizzazioni e risoluzioni che Java VM esegue al momento del caricamento della classe. Il caricamento dinamico della classe in
fase di esecuzione non è supportato dalla Java Card VM perché:

- Il caricamento dinamico della classe richiede l'accesso alla posizione di archiviazione del file di classe (riferito al
disco o a Internet) che non è disponibile in un ambiente con smart card

- Gli aspetti di sicurezza dell'ambiente delle smart card vietano il comportamento più dinamico (è consentita l'associazione dinamica degli
oggetti)

- Ci sono risorse limitate all'interno dell'ambiente delle smart card

Lo strumento Java Card Converter è un'implementazione di "associazione anticipata" di Java VM. Ogni classe referenziata direttamente o
indirettamente da un'applet deve essere collegata all'immagine binaria dell'applet quando l'applet viene installata sulla scheda. Il
convertitore di schede Java funge da post-processore di associazione anticipata sui file di classe della piattaforma Java. Il convertitore di
schede Java esegue i seguenti passaggi:

1.Verifica—Verifica che le immagini di caricamento delle classi siano ben formate, con tabelle di simboli appropriate e
controlli per violazioni di linguaggio, specifiche per le specifiche Java Card

2.Preparazione— Alloca lo spazio di archiviazione per e crea le strutture dati della macchina virtuale per rappresentare le classi, crea
campi e metodi statici e inizializza le variabili statiche sui valori predefiniti

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 2-1

Guida per sviluppatori di applet Java Card

3.Risoluzione—Sostituisce i riferimenti simbolici a metodi o variabili con riferimenti diretti, ove possibile

L'esecuzione di questi tre passaggi in Java Card Converter, prima dell'installazione di un'applet sulla scheda, consente alla Java
Card VM su scheda di essere più compatta ed efficiente. Il seguente frammento di codice mostra un esempio di dove Java Card
Converter può risolvere una chiamata al metodo prima che una classe venga installata sulla smart card:

// FooBar() è dichiarato in BaseType, sovrascritto in ExtendedType. Tipo base b;

ExtendedType e = nuovo ExtendedType (); b = e;

// e FooBar si chiama
(ExtendedType) b.FooBar ();

Nota -Se la classe effettiva dell'oggetto a cui fa riferimentoBnon è ExtendedType in fase di esecuzione (ovvero, inseriamo un
riferimento a qualche altro tipo esteso inBin fase di esecuzione), il cast di cui sopra causerebbe a
ClassCastException,proprio come farebbe sulla piattaforma Java.

Una volta che un'applet è stata installata su una smart card basata su Java Card, è considerata carica e pronta per l'esecuzione (sebbene
potrebbero essere necessarie alcune inizializzazioni e personalizzazioni dell'applet). Il JCRE esegue quindi un'inizializzazione aggiuntiva
del tempo di caricamento, che implica l'impostazione di inizializzatori di costanti statiche e l'inizializzazione dei parametri dichiarati con
valori predefiniti nelle interfacce.

Sebbene Java Card Converter esegua il più possibile il binding e la risoluzione anticipati, JCRE supporta anche alcuni
binding tardivi. Il seguente segmento di codice viene eseguito nella piattaforma Java Card come farebbe sulla
piattaforma Java:

// FooBar() è dichiarato in BaseType, sovrascritto in ExtendedType. Tipo base b;

ExtendedType e = nuovo ExtendedType (); b = e;

// e FooBar si chiama
b.FooBar();

Associando in ritardo la chiamata ab.FooBar (),il JCRE garantisce che il metodo della classe estesaeviene
chiamato al posto del metodo della classe base per cui la variabileBè dichiarato.

Late binding consente inoltre alla tecnologia Java Card di supportare funzioni virtuali, ad esempio:

// FooBar() è dichiarato come metodo astratto in BaseType e implementato // sia da ExtendedType1

che da ExtendedType2
Tipo base b;
ExtendedType1 e1 = nuovo ExtendedType1 ();
ExtendedType2 e2 = nuovo ExtendedType2 (); b = e1;

// e1 FooBar si chiama
b.FooBar ();
b = e2;
// e2 FooBar si chiama
b.FooBar ();

Specifiche della lingua

Esistono differenze nelle specifiche del linguaggio tra la piattaforma Java e la piattaforma Java Card,
risultanti dall'ambiente con risorse limitate della smart card. Una delle principali differenze tra Java

2-2 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

piattaforma e la piattaforma Java Card è che la piattaforma Java Card supporta solo applet Java Card, non applet
o applicazioni JDKstyle.

L'API Java Card utilizza un sottoinsieme del linguaggio di programmazione Java come definito nella versione 1.0.2 di
JDK. L'implementazione di riferimento verrà eseguita su qualsiasi versione di JDK dopo e inclusa la versione 1.1. Java
Card 2.0 Reference Implementation (JC2RI), disponibile su Sun Microsystems, Inc. sito web (http://java.sun.com), si
basa sulSottoinsieme del linguaggio Java Card 2.0 e specifica della macchina virtuale.

Le differenze linguistiche tra la piattaforma Java e la piattaforma Java Card sono riassunte in questa
sezione.

Fili
La piattaforma Java Card non supporta i thread perché le attuali unità di elaborazione centrale (CPU) delle smart card non possono
supportare il multitasking efficiente. Di conseguenza, nessuna delle parole chiave del thread è supportata.

Inoltre, nella piattaforma Java Card non esiste supporto per sincronizzato o volatile (utilizzato per controllare l'accesso a
variabili e metodi condivisi tra i thread).

Raccolta dei rifiuti

Le implementazioni della tecnologia Java Card non sono necessarie per supportare la raccolta dei rifiuti, quindi ilfinalizzare ()
il metodo non è supportato.

Tipi primitivi
Come nella tecnologia Java, la tecnologia Java Card supporta i seguenti tipi primitivi:byte,breve, ebooleano.
Un byte è un numero in complemento a due con segno a 8 bit con un possibile intervallo di valori compreso tra -128 e 127. Un
breve è un numero in complemento a due con segno a 16 bit con un possibile intervallo di valori compreso tra -32768 e 32767.
Internamente, la tecnologia Java Card rappresenta il tipo tohoelean come byte. Ciò è in contrasto con la tecnologia Java, che
rappresenta inte booleana arliny come int. Questi sono gli unici tipi primitivi universalmente supportati in Java
Tecnologia Card, che riflette i microprocessori a 8 bit e 16 bit su cui è attualmente eseguita la tecnologia Java
Card.

Ilinttype è disponibile per l'uso su alcune smart card avanzate a 32 bit (il tipo int potrebbe essere effettivamente implementato su
schede a 16 o anche a 8 bit, ma con un costo di esecuzione e un sovraccarico). Il tipo int rappresenta un numero in complemento a
due con segno a 32 bit con un possibile intervallo di valori compreso tra -2147483648 e 2147483647. La tabella seguente descrive i
tipi primitivi supportati.

TABELLA 2-1 Tipi primitivi supportati

Tipo Larghezza Gamma

byte 8 bit - 128, 127

breve 16 bit - 32768, 32767
booleano 8 bit Vero o falso
int (supportato su 32 bit - 2147483648 a
alcune piattaforme) 2147483647

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 2-3

Guida per sviluppatori di applet Java Card

La piattaforma Java Card non supporta ilcar,Doppio,galleggiante, opolmonetipi primitivi. Iltransitorioe volatilei
modificatori di dichiarazione non sono supportati. La tabella seguente descrive i tipi primitivi non supportati.

TABELLA 2-2 Tipi primitivi non supportati

Tipo Larghezza Gamma

Polmone 64 bit - 264, 264-1

Char 16 bit Set di caratteri Unicode v1.1.5 Fare

Galleggiante 32 bit riferimento a IEEE 754

Doppio 64 bit Fare riferimento a IEEE 754

Le variabili di tipo "byte" possono essere ampliate a "brevi" utilizzando il cast (breve). L'allargamento avviene senza perdita di
precisione. Le variabili di tipo "short" possono essere ridotte a "byte" utilizzando il cast (byte). Gli 8 bit superiori del valore breve
vengono scartati. È anche possibile formare uno short da due valori di byte usando il
Util.makeShort ()metodo trovato nel javacard.frameworkpacchetto.

Per garantire che i risultati dei calcoli aritmetici siano coerenti con la tecnologia Java convenzionale, la tecnologia Java Card
utilizza regole di casting. La regola generale è che i risultati di calcoli aritmetici intermedi o non assegnati devono essere espressi
in modo esplicito su un valore "byte" o "breve" quando utilizzati in combinazione con alcune altre operazioni (altrimenti, per
impostazione predefinita, digiterebbero" int "). Un risultato non assegnato è uno che non è assegnato a una variabile (ad
esempio, un indice di matrice calcolato utilizzando un calcolo aritmetico). Nell'esempio seguente, la calculatio (na + 1)restituisce
un risultato intermedio che deve essere convertito in modo esplicito su un valore "byte" o "breve":

byte B;
breve un;
matrice di byte [] = nuovo byte [10]; b =
(byte) ((a + 1) / 2); // Ciò fa sì che Java Card Converter // emetta un errore

b = (byte) ((byte) (a + 1) / 2); b = (byte) // Ok

((breve) (a + 1) / 2); B // Ok
= matrice [a + 1]; // Errore
B = matrice [(byte) (a + 1)]; // Ok
B = matrice [(breve) (a + 1)]; // Ok

Sostituzione del calcolo intermedio (o unf +1)con il simboloioriduce l'equazione a:

b = (byte) (I / 2);

Un secondo calcolo aritmetico (nio / 2)ora si verifica, ma questo secondo calcolo aritmetico non è né intermedio né non
assegnato. Il risultato del secondo calcolo aritmetico viene assegnato direttamente alla variabile Be le regole del linguaggio
di programmazione Java richiedono un cast esplicito al tipo di variabile, in questo caso un byte. La tecnologia Java Card è
coerente con la tecnologia Java poiché richiede il cast esplicito quando i risultati del calcolo aritmetico vengono assegnati a
una variabile tipizzata.

I requisiti di casting della tecnologia Java Card sui risultati intermedi dei calcoli aritmetici sono necessari a causa del modo in
cui la tecnologia Java gestisce il calcolo dei risultati intermedi. La tecnologia Jav converte i risultati intermedi delle operazioni
che coinvolgono byte e short in valori int (32 bit), a meno che non venga utilizzato un cast esplicito in short o byte. Poiché la
tecnologia Java Card è progettata per funzionare su CPU a 8 e 16 bit, non è possibile memorizzare risultati intermedi a 32 bit
(Consultare la documentazione di Java Card Converter per la segnalazione degli errori quando non viene eseguito un cast
esplicito.)

2-4 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Si può dimostrare che il risultato complessivo di un'espressione aritmetica complessa (che coinvolge risultati intermedi) può
variare, a seconda del numero di bit utilizzati per memorizzare i risultati intermedi. Questa discrepanza è dovuta al fatto che i
bit di overflow, che risultano dal calcolo intermedio, lo sonoconservatoquando vengono utilizzati più bit per memorizzare i
valori intermedi e sonotroncatoquando vengono utilizzati meno bit. Casting esplicito dei risultati di calcoli intermedi o non
assegnati, definisce in modo esplicito il numero di bit utilizzati per memorizzare i risultati intermedi e garantisce risultati
coerenti con la tecnologia Java.

Le operazioni aritmetiche intermedie o non assegnate soggette alle regole di casting esplicite sono:

Elenco n. 1

- Aggiunta (+, ++)

- Sottrazione (-, -)
- Negazione unaria (-)
- Spostamento a sinistra (<<)

- Moltiplicazione (*)
- Divisione (/)

I risultati aritmetici intermedi delle operazioni sopra elencate devono essere espressi quando utilizzati come operandi di una qualsiasi delle
operazioni elencate di seguito:

Elenco n. 2

- Resto (%) (entrambi gli operandi)

- Negazione unaria (-)
- Maiusc a destra (>>) (operando spostato)
- Maiusc a destra senza segno (>>>) (operando spostato)
- Divisione (/) (entrambi gli operandi)

Inoltre, i risultati aritmetici non assegnati (anziché intermedi) devono essere espressi in modo esplicito se utilizzati nelle
seguenti circostanze:

Elenco n. 3

- Poiché l'elemento conta durante la creazione di un nuovo array

- Come indice di matrice
- Come condizione diSeespressioni
- Come parametro di un metodo (richiesto anche con tecnologia Java)
- Poiché il valore della decisione ininterruttoredichiarazioni

I risultati intermedi delle operazioni nell'elenco n. 1, utilizzati come input per l'operazione AND bit per bit (&), l'operazione OR
bit per bit (|) e l'operazione XOR bit per bit (^), sono soggetti alle regole di casting se il risultato di l'operazione &, | o ^ è essa
stessa un input per una delle operazioni nell'elenco n. 2 o nell'elenco n. 3.

Ecco alcuni esempi di applicazione delle regole di casting esplicito:

breve s = 2, c = 4, d = 5; byte
a = 1, b = 3;
matrice di byte [] = nuovo byte [(byte) (a * b)]; s =
(breve) ((byte) (a / b) >> 2);
s = (breve) (b >> (a * b)); // nessun cast richiesto - intermedio //
non è stato spostato l'operando
s = (breve) ((byte) (a * b) / c);
s = (corto) ((corto) (a * b) / (corto) (c * d)); s
= (breve) array [(breve) (a / b)];
s = (corto) ((corto) ((c * c) & d) / a); // cast richiesto sul risultato di &
// operazione
se ((breve) (a * b * c) <10) {…}

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 2-5

Guida per sviluppatori di applet Java Card

interruttore ((byte) (c >> b)) {…}

Matrici
La tecnologia Java Card supporta gli array unidimensionali, ma non supporta gli array multidimensionali a causa dei
vincoli di risorse dell'ambiente delle smart card. Le matrici devono avere elementi che sono uno dei tipi o oggetti
primitivi supportati. Gli elementi dell'array possono essere riferimenti ad altri array. Di seguito sono riportati esempi di
dichiarazioni di array valide sia per la piattaforma Java che per la piattaforma Java Card:

byte a [] = nuovo byte [10];

byte a [] = {1,1,2};
corto finale statico MAX_ARRAY = 15; breve s [] =
nuovo cortocircuito [MAX_ARRAY]; AIUTO AIUTO
[] = nuovo AIUTO [5]; // array di 5 riferimenti a oggetti AID

Di seguito sono riportati esempi di dichiarazioni di array non valide:

byte b [] [] = nuovo byte [5] [2]; // array multidimensionali in tutti questi

// gli esempi non sono supportati
breve s [] [] = nuovo cortocircuito [10] [];
byte b [] [];

Gli array sono oggetti (proprio come nella tecnologia Java), in modo che il fileOggettometodi sono disponibili quando si utilizzano gli array. È
possibile confrontare due riferimenti di matrice per l'uguaglianza utilizzando ilequivale () metodo:

se (c.uguale a (d)) {...}

Il valore restituito è sempre TRUE o FALSE — o i riferimenti dell'array sono uguali o non lo sono. Confronti più
elaborati tra gli elementi di due array di byte possono essere eseguiti utilizzando il
Util.array Confronta ()metodo. Questo metodo consente di confrontare qualsiasi intervallo degli elementi di due matrici, con
un valore restituito che indica se l'intervallo è minore, uguale o maggiore dell'altro. Qualsiasi intervallo di un array di byte
può essere copiato nell'intervallo di un altro (incluso lo stesso array) utilizzando
Util.arrayCopy ().

IlarrayCopy ()Il metodo garantisce l'atomicità dell'operazione di copia: la rimozione (strappo) della scheda nel mezzo
dell'operazione non determina un array parzialmente copiato. La versione non atomica dello stesso metodo
èUtil.arrayCopyNon Atomic ().Un metodo simile,Util.arrayFillNon Atomic (),non atomicamente
riempie gli elementi di una matrice di byte con un valore specificato.

Le implicazioni sulla memoria delle copie di array da sorgente a sorgente e delle operazioni di array atomici sono discusse in modo più
dettagliato nella sezione oounottimizzare le applet di Java Card.

Due elementi di matrice di byte consecutivi possono essere restituiti come valore breveVOIeTvoiioSlio.ngetShort.Allo stesso modo, due
elementi di matrice di byte consecutivi possono essere impostati utilizzando il primo e il secondo byte in un valore breve utilizzando
Util.setShort.

Eredità
La piattaforma Java Card supporta pienamente tutte le funzionalità di ereditarietà disponibili nella piattaforma Java. Sono
supportati gli override dei metodi, i metodi astratti e le interfacceS D.voi
PTehRequestole parole chiave sono supportate,
con regole di utilizzo identiche: entrambi possono essere utilizzati solo in un metodo di istanza, in un costruttore o nell'inizializzatore di una variabile
di istanza di una classe.

2-6 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Sicurezza

Tutte le funzionalità di sicurezza della compilazione e del linguaggio Java sono supportate dalla tecnologia Java Card, come la
verifica del bytecode, che conferma che tutti i target nell'applet sono raggiungibili e modificatori di accesso pubblico, privato e
protetto.

Proprio come nella piattaforma Java, i membri hanno dichiarato come:

- Pubblicosono accessibili ad altre classi installate

- Privatosono accessibili solo dall'interno della classe in cui è dichiarato

- Protettosono accessibili ed ereditati dalle sottoclassi e accessibili dal codice nello stesso pacchetto

Nota -Per impostazione predefinita, i membri sono accessibili da qualsiasi codice all'interno dello stesso pacchetto.

Portabilità
L'API Java Card consente alle applicazioni scritte per una piattaforma di smart card basata su Java Card, di essere eseguite su qualsiasi
altra piattaforma di smart card basata su Java Card, che consente agli sviluppatori di utilizzare la stessa applet Java Card per l'esecuzione su
schede di fornitori diversi.

Un'applet Java Card non verrà eseguita come un'applet Java doeJsDiK dopo
l'ambiente di runtime e un'applet Java lo faranno
non viene eseguito come fa un'applet Java Card in JCRE. Tuttavia, se JCRE è simulatJeD dKinruthnteime
ambiente, l'applet della scheda verrà eseguita.

In generale, la tecnologia Java Card offre al tuo software l'indipendenza da:

- Caratteristiche specifiche della CPU della scheda (ad esempio set di istruzioni, convenzioni di ordinamento dei byte o larghezza del bus di
dati e istruzioni)

- Protocollo ISO utilizzato per comunicare tra la carta e il dispositivo di accettazione della carta

La tecnologia Java Card non garantisce l'indipendenza da tutte le funzionalità dei diversi modelli di smart card. Ad
esempio, alcune smart card possono supportare il tipo di dati int primitive o la raccolta dei rifiuti: se l'applet Java Card
presume che tale supporto sia presente, funzionerà solo su smart card che implementano tali funzionalità.

Eccezioni
Le applet Java Card devono essere testate a fondo per evitare errori irreversibili durante l'esecuzione sulla smart card. Per
assistere gli sviluppatori nel debug delle applet Java Card, la piattaforma Java Card supporta tutti i costrutti del linguaggio
di programmazione Java per le eccezioni. Puoi entrareTCR lyd (e),prendere (),ofinalmente ()
costrutti nelle tue applet Java Card e funzionano come nella piattaforma JavaTRhmroT wcome si dice
supportato anche, tuttavia, come discusso di seguito, il modo preferito per generare eccezioni non implica direttamente
l'uso digettare.

La piattaforma Java Card non supporta tutti i tipi di eccezioni presenti nei pacchetti di base della tecnologia Java perché molti
di essi non sono applicabili in un contesto di smart card. Ad esempio, i thread non sono supportati all'interno della
piattaforma Java Card (come discusso inlTunhuneSpecifiche del calibrosezione di questo capitolo) e, di conseguenza,
nessuna delle eccezioni relative ai thread è supportata. La tabella seguente elenca tutte le eccezioni supportate.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 2-7

Guida per sviluppatori di applet Java Card

TABELLA 2-3 Eccezioni supportate

Eccezione Pacchetto Superclasse Tipo

Eccezione java.lang Lanciabile Controllato

RuntimeException java.lang Eccezione Deselezionato

Eccezione aritmetica java.lang RuntimeException Deselezionato

ArrayStore java.lang RuntimeException Deselezionato

ArrayIndexOutOfBoundsException java.lang RuntimeException Deselezionato

ClassCastException java.lang RuntimeException Deselezionato

IndexOutOfBoundsException java.lang RuntimeException Deselezionato

NegativeArraySizeException java.lang RuntimeException Deselezionato

NullPointerException java.lang RuntimeException Deselezionato

SecurityException java.lang RuntimeException Deselezionato

Eccezione APDU javacard.framework RuntimeException Deselezionato

ISOException javacard.framework RuntimeException Deselezionato

PINException javacard.framework RuntimeException Deselezionato

SystemException javacard.framework RuntimeException Deselezionato

TransactionException javacard.framework RuntimeException Deselezionato

UserException javacard.framework Eccezione Controllato

Per ottimizzare l'utilizzo della memoria, tutti gli oggetti eccezione possono essere creati in anticipo al momento dell'inizializzazione e i relativi
riferimenti salvati in modo permanente. Quando si verifica l'evento eccezione, anziché creare un nuovo oggetto eccezione, il codice può:

1. Recuperare e riutilizzare il riferimento per l'oggetto eccezione desiderato.

Inserisci il codice motivo nell'oggetto.

3. Lancia l'oggetto.

JCRE precrea un'istanza di ogni tipo di eccezione specifica definita nell'API Java Card. La maggior parte di queste sono
eccezioni non controllate. Quando sono necessari questi oggetti eccezione, utilizzare il metodo staticogettarlo (). MareLa classe
lanciabilesezione per ulteriori informazioni.

Puoi definire le tue eccezioni creando sottoclassi di classeEccezione.Queste sono sempre eccezioni controllate.
Queste eccezioni possono essere generate e catturate come desiderato dall'applet. Tuttavia, durante
l'inizializzazione l'applet deve:

Crea una singola istanza di ciascuna di queste eccezioni.

2. Salvare il riferimento in un campo oggetto persistente.

3. Riutilizza quell'istanza ogni volta che è necessario generare quell'eccezione.

2-8 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Classi principali
Le classi principali dell'API Java Card sono più compatte e concise di quelle della piattaforma Java e forniscono servizi
essenziali alle applet Java Card. Gli sviluppatori che hanno familiarità con la piattaforma Java potrebbero non
riconoscere alcune delle classi principali della piattaforma Java Card, ad eccezione diOggettoeLanciabileinjava.lang.

IlCordaclassi,Io/Oclassi,AWTclassi, esolole classi non sono supportate nelle classi principali della piattaforma Java Card
a causa dei vincoli di memoria all'interno dell'ambiente della smart card.

La tabella seguente elenca tutti i pacchetti della piattaforma Java Card e le classi che contengono:

TABELLA 2-4 Classi principali della piattaforma Java Card

Pacchetto Classe

Classi principali

java.lang Oggetto

. Lanciabile
. Varie eccezioni linguistiche
javacard.framework AID
. APDU
. Applet
. ISO
. SPILLO

. Sistema

. Util
. Varie eccezioni correlate
Classi di estensione

javacardx.framework Classi di file system

javacardx.crypto Classi a chiave pubblica

. Classi di chiavi private

. Generatore di numeri casuali Digest

. del messaggio

javacardx.cryptoenc Classi di crittografia DES

La classe lanciabile
Per supportare le eccezioni, ilLanciabileclass è implementata all'interno della piattaforma Java Card. L'implementazione è progettata in
modo tale che gli oggetti di eccezione vengano allocati una volta a livello di sistema, quindi personalizzati e riutilizzati da tutte le classi
installate. Sebbene questa sia un'opzione per la gestione di oggetti di eccezione, è altamente raccomandata come salvaspazio perché la
piattaforma Java Card non fornisce il supporto universale per la raccolta dei rifiuti o per la deallocazione esplicita della memoria allocata
(fornire il supporto per la deallocazione esplicita della memoria allocata violerebbe il modello di programmazione della tecnologia Java).

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 2-9

Guida per sviluppatori di applet Java Card

Una volta che un oggetto è stato istanziato, lo spazio di archiviazione riservato a quell'oggetto è riservato per la durata della
smart card, consentendo una garanzia di disponibilità di spazio durante l'esecuzione futura di quell'oggetto.

Creando oggetti eccezione condivisi a livello di sistema, la piattaforma Java Card consente di generare eccezioni
utilizzando un oggetto eccezione riutilizzato. Un'applet recupera semplicemente un riferimento a un oggetto-eccezione
condiviso del tipo desiderato, personalizza l'eccezione con un codice di errore e genera l'eccezione invocando
l'eccezionegettarlo ()metodo-nonutilizzando ilgettareparola chiave.

Come la piattaforma Java, tutte le eccezioni derivano daTThhRedovutoclasse, ad esempio:

di classe pubblica Lanciabile

// Metodi:
pubblico breve getReason (); // ottieni il codice di errore da lanciare con il
// eccezione
public void setReason (); // imposta il codice di errore da generare con
l'eccezione //

A differenza della piattaforma Java, i seguenti metodi non sono paTRhTR

oFowaablea causa di vincoli di memoria
nell'ambiente della smart card:

getMessage
getLocalizedMessage
fillInStackTrace
printStackTrace (questo metodo non è supportato perché non c'è stampante su una smart card)

La dichiarazione oeFeccezionenella piattaforma Java Card è:

public class L'eccezione estende Throwable // Variabili

membro:
private static ExceptionExceptionInstance; Metodi:

public static void throwIt (breve motivo) genera Exception {

if (exceptionInstance == null)
eccezioneInstance = nuova eccezione ();
exceptionInstance.setReason (motivo); lanciare
un'eccezioneInstance;
}

Tutte le eccezioni della piattaforma Java Card nei pacchetti principali derivanoeFXroCm opzionee sovrascrivere ilgettarlo ()
metodo. Un esempio di come lanciare un'eccezione noiTin hGowIt ()è previsto nelOttimizzazione della Java Card
Appletcapitolo.

La classe dell'oggetto

La definizione delOggettoclasse nella piattaforma Java Card è più concisa rispetto alla tecnologia Java per
soddisfare i vincoli di risorse dell'ambiente smart card. La definizione all'interno della piattaforma Java Card
è la seguente:

classe pubblica Oggetto {

public boolean equals (Oggetto obj) {return false; }}

2-10 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

L'unico metodo supportato èequivale (),che, se implementato dalle sottoclassi diOggetto,fornisce un

confronto dell'uguaglianza di due riferimenti a oggetti. Si noti che non c'ègetClass ()metodo implementato—
Classegli oggetti non sono raggiungibili da un'applet nella piattaforma Java Card.

AltroOggettoi metodi nella piattaforma Java che non sono nella piattaforma Java Card includono:

codice hash
clone
aspettare

notificare
notificaTutti
finalizzare

A causa dei vincoli di risorse nei dispositivi con memoria limitata, i seguenti metodi non sono supportati
all'interno della piattaforma Java Card:

- Ilcodice hash ()metodo — le tabelle hash non sono supportate

- Ilclonare ()metodo — gli oggetti non possono essere clonati

- Ilattendere (), notificare (),enotificaTutto ()metodi: i thread non sono supportati

- IlSystem.exit ()metodo: la VM ha una vita continua su una scheda attiva, quindi non è necessario un
metodo che indichi a JCRE di spegnere la VM
- Ilfinalizzare ()metodo: la raccolta dei rifiuti non è universalmente supportata e il concetto di rinunciare alle
risorse di sistema di proprietà dell'oggetto da raccogliere (ad esempio, la grafica) non è significativo
nell'ambiente delle smart card

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 2-11

 Guida per sviluppatori di applet Java Card

3. Creazione di un'applet per schede Java

Gli strumenti di sviluppo della tecnologia Java standard possono essere utilizzati per creare e compilare il codice sorgente per le applet
Java Card. Una volta che il codice sorgente del software Java è stato compilato in un file di classe, viene creata una versione post-
elaborata dell'applet, adatta per il caricamento su smart card con tecnologia Java, utilizzando lo strumento Java Card Converter, come
discusso nelPanoramicacapitolo e illustrato nella FIGURA 3-1.

Fuori carta Sulla carta

Convertitore JCRE
. classe

File

. cap
file

FIGURA 3-1 Creazione di un'applet per schede Java

La tecnologia Java Card differisce dalla tecnologia Java a causa dei vincoli di risorse dell'ambiente smart card,
come discusso inTecnologia Java Cardcapitolo. Le smart card comunicano utilizzando un meccanismo a
pacchetto chiamato APDU, come discusso inPanoramicacapitolo e nelLavorare con APDUsezione di questo
capitolo.

Ora hai abbastanza background per iniziare il processo di creazione del codice sorgente per un'applet Java Card. Il
codice sorgente per l'applet inizia con le stesse designazioni di pacchetto trovate nel linguaggio Java (il
java.langil pacchetto non deve essere espressamente importato nell'applet).

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 3-1

Guida per sviluppatori di applet Java Card

Un esempio di base
Il seguente elenco di codici mostra un esempio di base di un'applet Java Card che può essere post-elaborata da Java
Card Converter e installata su una smart card con tecnologia Java:

Java Card supporta la convenzione del

pacchetto banca.borsa; nome del pacchetto e dell'identificatore
come nella tecnologia Java standard.

importare javacard.framework.*;
importare javacardx.framework.*;
Un'applet è un'istanza di una classe che si
public class Wallet estende l'applet {/ *
estende da:
dichiarazione di costanti * /
javacard.framework.Applet.
// codice del byte CLA nel comando APDU header byte statico
CLA identifica l'applicazione
finale Wallet_CLA = (byte) 0xB0;
// codici del byte INS nel comando APDU header byte statico
finale Deposit = (byte) 0x10; byte statico finale Debito = (byte) INS specifica le istruzioni per
0x20;
l'applicazione.
byte statico finale Balance = (byte) 0x30; byte statico
finale Convalida = (byte) 0x40;
// numero massimo di tentativi errati prima che il // PIN venga
bloccato
byte statico finale PinTryLimit = (byte) 0x03; // PIN Parametri oggetto PIN.
dimensione massima
byte statico finale MaxPinSize = (byte) 0x04;
// parola di stato (SW1-SW2) per segnalare che il // saldo
diventa negativo;
Parola statica specifica dell'applet.
breve statico finale SW_NEGATIVE_BALANCE = (breve) 0x6910;

/ * dichiarazione delle variabili di istanza * / pin

OwnerPIN;
bilanciamento dei byte;
buffer di byte []; // Buffer APDU
Portafoglio privato () { costruttore privato — un'istanza di cl Wallet culo
// È buona pratica di programmazione allocare // tutta la viene istanziata dal suo metodo di installazione.
memoria di cui ha bisogno un'applet durante // la sua vita
all'interno del costruttore pin = new OwnerPIN (PinTryLimit,
MaxPinSize); saldo = 0;

Registrati();
L'applet si registra con il JC RIF
chiamandoRegistratimetodo, che è
} // fine del costruttore definito in classeApplet.
installazione pubblica statica vuota (APDU apdu) {//
crea un'istanza dell'applet Wallet new Wallet (); Metodoinstallareviene richiamato da JCRE
come ultimo passaggio del processo di
installazione dell'applet.
} // metodo di fine installazione
booleano pubblico seleziona () {

// reimposta il flag di convalida nell'oggetto PIN su // false

Questo metodo viene richiamato da
pin.reset (); JCRE per indicare che questa applet è
stata selezionata. Esegue
// restituisce true a JCRE per indicare che // l'applet è pronta l'inizializzazione necessaria per
per accettare APDU in entrata. restituisce vero;
elaborare il messaggio APDU successivoges.

} // fine del metodo di selezione

3-2 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Dopo che l'applet è stata selezionata

correttamente, JCRE invia le APDU in entrata a
processo di vuoto pubblico (APDU apdu) { questo metodo.

// L'oggetto APDU trasporta un array di byte (buffer) per // L'oggetto APDU è di proprietà e gestito
trasferire l'intestazione APDU in entrata e in uscita // e i byte di da JCRE. Incapsula i dettagli del
dati tra la scheda e il buffer CAD = apdu.getBuffer ();
protocollo di trasmissione sottostante
(T0 o T1 come specificato in ISO 7816-3)
fornendo un'interfaccia comune.
Quando si verifica un errore, l'applet può
decidere di terminare il processo e lanciare
// verifica che se l'applet può accettare questo // messaggio
un'eccezione contenente la parola di stato
APDU
if (buffer [ISO.OFFSET_CLA]! == Wallet_CLA) (SW1 SW2) per indicare lo stato di elaborazione
ISOException.throwIt della carta.
(ISO.SW_CLA_NON_SUPPORTATO);
Un'eccezione che non viene rilevata da
un'applet viene rilevata da JCRE.
interruttore (buffer [ISO.OFFSET_INS]) {
Astuccio Bilanciamento: getBalance (apdu); Restituzione;
La funzione principale delprocessi
Astuccio Addebito: addebito (apdu); Restituzione;
Astuccio Depositare: caparra (apdu), restituzione; Il metodo consiste nell'eseguire
Astuccio Convalidare: convalidare (apdu); restituire un'azione come specificato nell'APDU e
predefinito: ISOException.throwIt restituire una risposta appropriata al
(ISO.SW_INS_NOT_SUPPORTATO); } terminale. Il byte INS specifica il tipo di
azione da eseguire.
} // metodo di fine processo
Il parametro oggetto APDU contiene
un campo dati, che specifica l'importo
deposito privato nullo (APDU apdu) { da aggiungere al saldo.
Dopo aver ricevuto l'oggetto APDU dal
// autenticazione di accesso se (! JCRE, i primi 5 byte (CLA, INS, P1, P2, Lc /
pin.isValidated ())
ISOException.throwIt (ISO.SW_PIN_REQUIRED); Le) sono disponibili nel buffer APDU. I
loro offset nel buffer APDU sono
// Lc byte indica il numero di byte nel // campo dati del specificati nella classe ISO. Poiché il
comando APDU campo dati è facoltativo, l'applet deve
byte numBytes = (byte) (buffer [ISO.OFFSET_LC]);
informare esplicitamente JCRE per
// indica che questa APDU ha dati in entrata e // riceve dati a recuperare ulteriori byte di dati.
partire dall'offset
La comunicazione tra scheda e CAD viene
// ISO.OFFSET_CDATA
byte byteLeggi = scambiata tra la coppia di APDU di comando e
(byte) (apdu.setIncomingAndReceive()); la coppia di APDU di risposta. Nel caso di
deposito, la risposta APDU non contiene alcun
// è un errore se il numero di byte di dati // letti non
campo dati. Il JCRE prenderebbe la parola di
corrisponde al numero in Lc byte if (byteRead! = 1)
stato 0x9000 (elaborazione normale) per
ISOException.throwIt (ISO.SW_WRONG_LENGTh); formare la risposta corretta APDU. Gli
sviluppatori di applet non devono
// aumenta il saldo dell'importo specificato // nel campo dati del
preoccuparsi dei dettagli della costruzione
comando APDU. equilibrio =
(byte) dell'APDU di risposta corretta.
(bilancia + buffer [ISO.OFFSET_CDATA]);

// ritorna con successo Quando JCRE rileva un'eccezione, che

Restituzione; segnala un errore durante
elaborando il comando, il JCRE utilizzerà
} // metodo di fine deposito la parola di stato contenuta
nell'eccezione per costruire la risposta
APDU.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 3-3

Guida per sviluppatori di applet Java Card

addebito nullo privato (APDU apdu) {

// autenticazione di accesso se (!
pin.isValidated ())
ISOException.throwIt (ISO.SW_PIN_REQUIRED);

byte numBytes = (byte) (buffer [ISO.OFFSET_LC]); byte byteLeggi

=
(byte) (apdu.setIncomingAndReceive());
Nel metodo di addebito, l'oggetto APDU
se (byteRead! = 1) contiene un campo dati, che specifica
ISOException.throwIt (ISO.SW_WRONG_LENGTH); l'importo da addebitare dal saldo.

// il saldo non può essere negativo

if ((bilanciamento - buffer [ISO.OFFSET_CDATA]) <0)
ISOException.throwIt (SW_NEGATIVE_BALANCE);

equilibrio = (byte)
(bilancia buffer [ISO.OFFSET_CDATA]);

} // metodo di fine addebito

getBalance vuoto privato (APDU apdu) {

// autenticazione di accesso se (!
pin.isValidated ())
ISOException.throwIt (ISO.SW_PIN_REQUIRED);

// informa il sistema che l'applet ha terminato // l'elaborazione

getBalance restituisce il saldo del ce
del comando e il sistema dovrebbe // ora prepararsi a costruire dire
PDU.
Portafoglio nel campo dati del responA
una APDU di risposta // che contiene il campo dati

apdu.setIn uscita (); Poiché il campo dati nella risposta APDUe

è facoltativo, l'applet deve informare
// indica il numero di byte nel campo dati apdu.setOutgoingLength esplicitamente JCRE dei dati aggiuntivi. Il
((byte) 1);
JCRE utilizza l'array d nel buffer degli o
// sposta i dati nel buffer APDU a partire // dall'offset 0 oggetti APDU e la parola di stato e
corretta per costruire una risposta APDU
tampone [0] = saldo; completa.
// invia 1 byte di dati all'offset 0 nel buffer APDU //

apdu.sendBytes ((breve) 0, (breve) 1);

} // fine del metodo getBalance

convalida del vuoto privato (APDU apdu) { Il PIN è un metodo comunemente utilizzato
// recuperare i dati del PIN che devono essere // validati. I dati nelle smart card per proteggere i dati da
dell'interfaccia utente sono // memorizzati nel campo dati
dell'APDU byte byteRead = accessi non autorizzati.

Un PIN registra il numero di tentativi

(byte) (apdu.setIncomingAndReceive());
non riusciti dall'ultima verifica del PIN ct
// convalida l'interfaccia utente e imposta il // flag di corrispondente. La carta verrebbe
convalida nell'interfaccia utente // oggetto su true se la bloccata se il numero di tentativi falliti
convalida. // riesce. Se la convalida dell'interfaccia utente // supera il numero massimo di tentativi F
fallisce, PinException verrebbe generato // dal metodo
consentiti definito nel PIN.
pin.check().
Dopo aver selezionato correttamente D,
pin.check (buffer, ISO.OFFSET_CDATA, byteRead); l'applet, è necessario prima convalidare il
PIN, prima che qualsiasi altra istruzione
} // fine del metodo di convalida} //
fine della classe Wallet possa essere eseguita sull'applet.

3-4 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Installazione dell'applet della scheda Java

L'installazione dell'applet avviene presso la fabbrica o presso la sede dell'emittente e può avvenire anche dopo l'emissione,
tramite ainstallazione sicuraprocesso (se definito dal produttore della carta). Questo processo prevede il download di un'applet
con firma digitale, che JCRE verifica come legittima, prima di installare l'applet. Le applet installate tramite download protetti
non possono contenere chiamate al metodo nativo poiché non sono attendibili.

Nota -Le applet con chiamate al metodo nativo devono essere installate in fabbrica o in un altro ambiente attendibile. Questo viene fatto per
motivi di sicurezza, poiché le chiamate native ignorano il framework di sicurezza della tecnologia Java e quindi devono essere altamente affidabili
prima di essere consentite sulla scheda.

Una volta installate, le classi della piattaforma Java Card non interagiscono direttamente con le applicazioni CAD o off-
card. Le classi installate possono interagire direttamente solo con JCRE o con altre classi installate. Il JCRE seleziona
un'applet e quindi passa le APDU alle applet selezionate. In sostanza, JCRE protegge lo sviluppatore dalla CPU della
smart card, dal CAD e dal particolare protocollo di comunicazione ISO impiegato. JCRE traduce anche le eccezioni non
rilevate generate dalle classi o le normali istruzioni di ritorno nei metodi dell'applet in valori di ritorno ISO standard.

Non è possibile recuperare lo spazio di archiviazione per un'applet installata; se è installata una versione più recente dell'applet, occupa
una nuova posizione di archiviazione e la versione precedente dell'applet diventa irraggiungibile. L'applet Java Card può anche essere
resa irraggiungibile rimuovendo il relativo riferimento dalla tabella del registro dell'applet JCRE. Una volta rimosso il riferimento, l'applet
non è più raggiungibile.

L'installazione dell'applet Java Card provoca l'inizializzazione dei suoi membri statici. Supporta la tecnologia Java Card
inizializzatori statici costanti: l'inizializzatore non può eseguire codice software Java, né può impostare il membro statico su un
valore (variabile) non costante. L'installazione comporta anche una chiamata all'aio PPun 'SllTT()unmetodo (a differenza
Smenzogna

applet Java).

La classe dell'applet
L'applet Java Card si estendeUNthPemacchiareclasse. Questa classe astratta ha alcuni metodi che devono essere
sovrascritti dall'implementazione specifica dell'applet. Questa sezione discute questi metodi.

Quando l'applet è installata sulla smart cardio , un

thSealto ()viene chiamato una volta da JCRE e mai
ancora. Ilinstalla ()il metodo deve essere dichiarato SD
taticoperché viene chiamato prima dell'applet
istanziato — il JCRE wiunllotchiama direttamente il costruttore dell'applet.

La prima cosainstalla ()dovrebbe fare è costruire l'applet chiamando il suo costruttore. Ciò ha l'effetto di allocare e
inizializzare qualsiasi variabile di istanza di classe non statica dichiarata dall'applet e di creare un'istanza dei suoi metodi non
statici. Le variabili di classe statiche vengono allocate e inizializzate prima che venga chiamato il costruttore, quando l'applet
viene caricata sulla scheda.

Poiché spetta all'applet stessa costruire i propri dati e metodi di istanza, il costruttore può essere dichiarato
pubblico, privato o protetto. Possibilmente, un'applet con un puco mlicstructor
ld potrebbe essere costruito da un altro
applet installata sulla smart card, ma nessun metodo o dato dell'applet è visibile alle classi non installate,
indipendentemente dai loro permessi.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 3-5

Guida per sviluppatori di applet Java Card

L'oggetto APDU, che viene passato ainstalla ()metodo da JCRE, può contenere dati di inizializzazione o
personalizzazione una tantum per l'applet.

L'esempio di borsa sopra eredita i metodi daAppletclasse, basandosi sulla loro implementazione predefinita. IlApplet
classe comprende parte del JCRE — un elenco è fornito di seguito per mostrare i metodi e la loro implementazione
predefinita.

applet di classe astratta pubblica {

Applet protetta () {}
installazione vuota statica pubblica (APDU apdu) genera ISOException {
ISOException.throwIt (ISO.SW_FUNC_NOT_SUPPORTED); }

processo vuoto pubblico (APDU apdu) genera ISOException {

buffer di byte [] = apdu.getBuffer (); ISOException.throwIt (Util.makeShort ((byte)
0x9F, buffer [1]));
}
protetto booleano seleziona () {
restituisce vero;
}
public void deselezionare () {} registro degli
annullamenti finali protetti () {
AppTable.register (questo); }

La classe Applet include un metodo calPmenzognaRDocesso ()che è l'unico meccanismo di ricezione dal
CAD, una volta installata l'applet. Informazioni fornite tramite un parametro APDUPTRoocesso ().
L'implementazione predefinitaPFoprocesso ()mostrato sopra è semplicemente esemplare. Java Claartdfoprm lo fa
non richiede questo comportamento dell'implementazione predefinitaP unRocess ().La nostra implementazione predefinita di
processi (),nell'esempio precedente, restituisce un errore c0oxd9eF insieme al byte dell'istruzione dall'intestazione
APDU, indicando che l'istruzione non è supportata.

Ilinstalla ()Il metodo genera un'eccezione ISOException (usando un'implementazione di eccezione che massimizza il riutilizzo degli oggetti) per
impostazione predefinita per indicare che non è stato possibile installare l'applet. A meno che tu oiovuneSrrTID ll e
un (),tuo
l'applet non sarà disponibile sulla scheda.

Ricorda che è durante la lavorazione inoSFalto ()che tutte le inizializzazioni una tantum devono essere eseguite,
inclusa la creazione di un'istanza dell'applet, la registrazione dell'applet con JCRE e la creazioneun elwls. a
circa

Registrazione dell'applet
Nell'esempio della borsa sopra, tAhP eDU viene passato all'applet construcatlothr, anche se non c'è
requisito per questo. Il costruttore dell'applet fa una cosa: essaRCeunGllioSstella()per aggiungere un riferimento alla
tabella dell'applet installata all'interno di JCRE.

Ogni applet deve caRllregistro ()durante l'elaborazione della chiamataioTun ostalla ()per garantire il futuro
comunicazione con il JCRE (il JCRE cerca sempre nell'elenco delle applet registrate quando decide dove instradare i
messaggi). Le applet dipendono da JCRE per tutte le comunicazioni e per trasferire il controllo a uno dei metodi dell'applet
quando l'applet viene selezionata, deselezionata o come destinazione di un APDU.

Nota -Il JCRE è a thread singolo, il che significa cheun ciclo infinito in qualsiasi applet blocca tutte le appletfino a quando l'alimentazione alla
scheda non viene scollegata. Quando viene ripristinata l'alimentazione, viene selezionata l'applet predefinita.

3-6 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Selezione dell'applet
IlAppletla classe include ancheSelezionare ()edeseleziona ()metodi. a differenza diprocessi ()einstalla (),
questi metodi non ricevono APDU dal JCRE. JCRE filtra il flusso APDU tra le applet installate e il CAD, come
illustrato nella FIGURA 3-2, e quindi chiama questi metodi solo quando viene ricevuta una APDU che
seleziona un'applet installata.

Applet

CAD
JCRE

FIGURA 3-2 Selezione dell'applet

Come accennato nelPanoramicacapitolo, a ciascuna applet Java Card viene assegnato un ID applicazione (AID) univoco.
L'AID viene utilizzato per identificare una particolare applet per la selezione. Se JCRE rileva una SELECT APDU, deseleziona
l'applet attualmente selezionata e quindi seleziona l'applet indicata dai byte di dati SELECT APDU. Il JCRE chiama l'applet
eleggere ()appena prima di inviare la SELECT APDU all'applet appena selezionata
processi ()metodo. SELECT APDU causa due volte l'applet JCREaltlothce; una chiamata tSoeleggere (),
un'altra chiamata aprocessi ()per passare l'applet il SELECT APDU.aItllsc ildeseleziona ()metodo dell'applet
attualmente selezionata per far sapere all'applet che non è più attualmente selezionata.

Esistono due tipi di SELECT APDU:

1. Per selezionare un'applet

2. Per selezionare un file controllato dall'applet selezionata

I due SELECT APDU sono molto simili, ma si distinguono dal JCRE. Upe ottenendo un SELECT
APDU, il JCRE tratta l'APDU atda come AID e cerca nella sua tabella dell'applet. Se viene trovata una corrispondenza, a
nuova applet è selezionata. In caso contrario, JCRE considera SELECT APDU come una APDU di selezione file e lo passa al metodo di
elaborazione dell'applet attualmente selezionato.

L'implementazione predefinita o SFeleggere ()restituisce TRUE, indicando che l'applet ha avuto successo
selezionato per ricevere le APDU successive. Qualsiasi altro valore restituito determina la selezione dell'applet acilt, ioandtothf e JCRE
non inoltra le APDU successive all'applet.

L'implementazione predefinita o DFeseleziona ()non fa nulla. Nota che boStheleggere ()edeseleziona ()sono
metodi di istanza. Un'istanza diUN thPemacchiarela classe deve essere creata affinché JCRE possa chiamarli
metodi. Poiché JCRE non chiama il costruttore dell'applet, l'applet deve farlo esplicitamente durante
l'elaborazione oioFninstalla ().

L'attuazione oRFregistro ()è definitivo e non può essere ignorato. TRheeieri()inserisce un riferimento a un oggetto
per l'applet nella tabella di registrazione dell'applet all'interno di JCRE. È attraverso questo riferimento che il JCRE è
in grado di chiamare il non-sta STecircuito integratoleggi ()edeseleziona ()metodi dell'applet

Il seguente pseudocodice riassume la procedura seguita dal JCRE per la gestione del SAEPLDEUC: T

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 3-7

Guida per sviluppatori di applet Java Card

se (SELEZIONA APDU dell'applet)

deseleziona chiamata () o applet attualmente selezionato
selezione chiamata () o applet identificata da APDU processo
di chiamata () o applet identificata da APDU

Un comando APDU viene analizzato alla prima chiamataAPDU.getBuffer ()per recuperare il pacchetto di dati
allegato all'APDU. Il pacchetto dati include l'intestazione APDU ei dati di comando. JCRE fornisce costanti per
analizzare rapidamente il pacchetto APDU. Il seguente frammento di codice mostra l'uso delle costanti
ISO.OFFSET_XXX (l'interpretazione dei byte di intestazione è spiegata nelLavorare con APDU sezione seguente):

byte buf [] = apdu.getBuffer (); byte cla =

buf [ISO.OFFSET_CLA]; byte ins = buf
[ISO.OFFSET_INS]; byte lc = buf
[ISO.OFFSET_LC]; byte p1 = buf
[ISO.OFFSET_P1]; byte p2 = buf
[ISO.OFFSET_P2]; // ottieni i dati dell'APDU

Util.arrayCopy (buf, ISO.OFFSET_CDATA, databuf, 0, lc);

Nota -Per una corretta verifica del pacchetto APDU, è una buona idea controllare tutti i valori di intestazione, incluso Lc per valori
validi.

Quando viene ricevuta la SELECT APDU, l'applet può recuperare il proprio AID chiamandoSystem.getAID().
L'AID nel buffer di dati APDU può essere confrontato con l'AID restituito dagetAID ()usando il
Util.array Confronta ()metodo. Il metodogetAID ()restituisce un oggetto AID e una matrice di byte, che
rappresentano il valore dell'AID e possono essere estratti chiamandoAID.copyTo ().

Lavorare con APDU

Le comunicazioni APDU si basano su un modello comando-risposta, come descritto inISO 7816-4. In genere, un'applet rimane
inattiva finché un comando APDU non viene passato all'applet, richiedendo una qualche forma di elaborazione. L'applet elabora
il comando e quindi restituisce una risposta.

Il buffer APDU è formattato in modo diverso per APDU di comando e APDU di risposta. Il formato generale di a
comando APDUè:

CLA INS P1 P2 Lc Dati Menzogna

L'intestazione descrive il comando che l'applet deve eseguire. I primi quattro byte del comando APDU
rappresentano l'intestazione, come segue:

CLA INS P1 P2

Dove:
- CLA — indica la classe, che identifica se il comando è un messaggio conforme a ISO
- INS — indica l'istruzione
- P1, P2 — indica parametri aggiuntivi

3-8 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

I valori precisi di CLA e INS per i diversi comandi sono riportati inISO 7816-4.

Gli altri campi del comando APDU sono opzionali (cioè non sono presenti in alcuni comandi). Questi campi
aggiuntivi definiscono tutti i dati passati con il comando, nonché la lunghezza prevista della risposta APDU. Gli
altri campi APDU sono:

Lc Dati Menzogna

Dove:
- Lc — indica la lunghezza dei dati del comando
- Dati: indica i dati del comando
- Le — indica la lunghezza della risposta prevista

Sono possibili quattro diversi formati di commanAdPDU, a seconda di whethaeta r non è incluso con il
comando e se sono richiesti dati di risposta. Quando i dati del comando non sono presenti e non è richiesta alcuna
risposta, il formato di thAePDU è:

CLA INS P1 P2

Quando i dati del comando sono presenti ma non è richiesta alcuna risposta, formaAtPoD f tU
sollevare:

CLA INS P1 P2 Lc Dati

Quando i dati di comandounèotpresente, ma sono richiesti dati di risposta, il formato o DeU

AfPth è:

CLA INS P1 P2 Menzogna

Quando sono presenti dati di comando e sono richiesti dati di risposta, il formato AtPoDfU
questi:

CLA INS P1 P2 Lc Dati Menzogna

Nota -Un valore Le di 0 non è lo stesso di un APDU senza Le. Un valore Le di 0 indica che l'applet deve fornire
tutti i dati di risposta disponibili nella risposta. Ciò si verifica in genere quando la lunghezza della risposta varia
(come il recupero di un record di lunghezza variabile da un file).

Il quinto byte dell'APDU (il primo byte dopo l'intestazione) può:

- Essere mancante (indicando che non sono presenti dati di comando o risposta)

- Contengono un valore Lc (che indica che sono presenti dati di comando)

- Contengono un valore Le

L'unica interpretazione del quinto byte è implicita, leggendo CLA e INS e conoscendo il formato del comando
che descrivono.

Le applet non dovrebbero mai leggere il valore Le direttamente dall'intestazione APDU. Chiama invece il metodo APDU
setIn uscita ()per recuperare il valore di Le. Le applet non dovrebbero leggere dal buffer APDU prima di chiamare
setIncomingAndReceive ()oricevereByte ()per trasferire i dati in entrata nel buffer APDU.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 3-9

Guida per sviluppatori di applet Java Card

Le risposte sono sempre obbligatorie, anche se non contengono dati. Il formato di arisposta APDUè:

Dati SW1 SW2

- Dati: dati di risposta

- SW1 — primo byte di stato
- SW2 — secondo byte di stato

Nella risposta sono sempre presenti il primo e il secondo byte di stato SW1 SW2. Tuttavia, l'applet della scheda non
imposta questi valori direttamente nel buffer APDU di risposta. Invece, questi valori sono impostati da JCRE su un
ritorno normale (SW1 = 90, SW2 = 00) o su un'eccezione generata dall'applet o da JCRE.

Poiché i byte di stato sono impostati da JCRE (al ritorno dell'applet) e inviati con i dati di risposta, l'applet può non inviare i
dati di risposta (o almeno, l'ultimo blocco di esso) finché l'applet non restituisce fPRRmetodo mt. oocCiò
hSha
eS importanti
()
implicazioni per la gestione del buffer, come discussoRifinceTiohve nei dati APDU
sezione sottostante.

Sequenza di comunicazione APDU

Una sequenza generale di comunicazione APDU per le smart card è la seguente:

1. Ricevi un oggetto APDU come parametro perPTRhoecess ()metodo.

2. Premere l'intestazione del comando APDU.

3. Leggi qualsiasi APDUadta.

Nota -I dati del comando non saranno nel buffer APDU finché non verranno letti dall'applet che utilizza
setIncomingAndReceive ()oricevereBytes().

Elabora il comando APDU e genera tutti i dati di risposta.

5. Inviare eventuali dati di risposta dall'applet.

Eseguire qualsiasi elaborazione aggiuntiva, assicurandosi di non modificare la risposta del buffer APDU.

7. Ritorno dalprocessi ()metodo normalmente, o lanciare un oggetto ISOException (il JCRE aggiunge i byte
di stato appropriati alla risposta APDU).

Ricezione di dati APDU

Per ricevere i dati dell'APDU di comando, l'applet deve prima mettere il JCRE in modalità di ricezione dei dati. La modalità di
ricezione indica a JCRE di cercare i dati dal CAD e di memorizzarli nel buffer di dati dell'APDU. I dati possono essere ricevuti
utilizzando un protocollo orientato ai caratteri o un protocollo orientato ai blocchi.

Come accennato in precedenza, JCRE protegge l'applet (e lo sviluppatore dell'applet) dai dettagli dell'implementazione del
protocollo specifico. Un unico metodo nelAPDUclasse, chiamatosetIncomingAndReceive (),viene utilizzato sia per impostare il
JCRE in modalità di ricezione sia per ricevere tutti i dati disponibili nel buffer APDU.

Il buffer APDU ha una dimensione minima di 37 byte: un aumento della dimensione del buffer è determinato dallo
sviluppatore JCRE e dipende dalla capacità di memoria della scheda.

3-10 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

I dati vengono inseriti nel buffer a partire dall'offset ISO.OFFSET_CDDATA. Il numero di byte letti, come illustrato
nella FIGURA 3-3, è determinato dalla seguente regola:

Se i byte che restano da leggere sono:

1. Minore o uguale alla lunghezza del buffer, quindi leggere tutti i byte rimanenti

2. Maggiore della lunghezza del buffer, quindi leggere fino alla lunghezza del buffer

Paraurti

Lunghezza del buffer

Dati
Compensare Byte rimanenti

FIGURA 3-3 Lunghezza del buffer

Per accedere ai dati nel buffer APDU, l'applet deve recuperare un riferimento al buffer dati APDU chiamando il metodo
APDUgetBuffer().Il buffer di dati è un array di byte la cui lunghezza può essere determinata utilizzando
buffer.length.L'oggetto APDU ricevuto dall'appletprocessi ()è di proprietà di JCRE (un singolo oggetto
APDU è condiviso tra tutte le applet sulla scheda).

Quando sono disponibili più dati di quelli che possono rientrare nel buffer APDU, la chiamata asetIncomingAndReceive ()
deve essere seguito da una o più chiamate al metodo APDUricevereBytes().Questo metodo legge sempre i dati
disponibili nel buffer APDU (non è possibile specificare un altro buffer fornito dall'applet). Piace
setIncomingAndReceive(), receiveBytes()è garantito che ritorni in modo sincrono, con tutti i byte che può contenere il
buffer APDU, solo se i byte rimanenti rientrano nel buffer APDU. In caso contrario, il metodo legge tutti i byte
rimanenti che rientreranno nel buffer e possibilmente meno. L'applet dovrebbe chiamarericevereByte ()
ripetutamente, elaborando o spostando i byte nel buffer di dati dell'APDU ad ogni chiamata, finché non vengono letti tutti i dati
disponibili. La quantità di dati disponibili può essere determinata controllando il byte Lc in
buffer [ISO.OFFSET_LC].

Per esempio,

byte [] buffer = apdu.getBuffer ();

byte_sinistra brevi = buffer (breve) [ISO.OFFSET_LC]; short
readCount = apdu.setIncomingAndReceive (); while (byte_sinistra>
0) {
// {elabora i dati ricevuti nel buffer}. . .

byte_sinistra - = readCount;
// prendi di più dati
readCount = apdu.receiveBytes (ISO.OFFSET_CDDATA);
}

Notare chericevereByte ()specifica l'offset del buffer in cui posizionare i dati. Ciò consente la "suddivisione del
buffer" per risparmiare risorse di memoria. L'applet può iniziare a preoceisvsedr dati e creare una risposta APDU,
senza utilizzare buffer separati.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 3-11

Guida per sviluppatori di applet Java Card

Nella FIGURA 3-4 è mostrato un buffer APDU diviso utilizzato sia per la lettura dei dati che per l'invio di una risposta.

I dati di risposta vanno qui Leggi i dati qui — receiverBytes (buffer.length / 2)

FIGURA 3-4 Dividi il buffer APDU

Nota -Quando il protocollo sottostante utilizzato da JCRE per comunicare con il CAD è orientato al blocco,
l'offset utilizzato per la lettura nel buffer APDU (buffer.length / 2) deve lasciare spazio sufficiente per almeno un
blocco all'interno del buffer. Se lo sviluppatore non lo fa,ricevereByte ()lancia un
APDUException.BUFFER_BOUNDS.

La dimensione del blocco del protocollo sottostante può essere determinata utilizzando il metodo APDUgetInBlockSize(). I protocolli
orientati ai caratteri restituiscono una dimensione del blocco di 1.

Le regole per il comportamento diricevereByte ()la lettura può essere così riassunta:

if (buffer.length-offset> bytes_left)
leggi byte_sinistra;
if (buffer.length-offset <byte_left) {
if (buffer.length — offset <BLOCK_SIZE) throw
APDUException.BUFFER_BOUNDS;
altrimenti leggi fino a buffer_size;
}

IlsetIncomingAndReceive() deve essere chiamato prima di chiamarericevereByte () . Non puoi chiamare

setIncomingAndReceive() se il JCRE è già in modalità di ricezione da una precedente chiamata a
setIncomingAndReceive() - in caso contrario, si verifica un'eccezione APDUException per APDUException.ILLEGAL_USE.

Risposte dell'APDU
Le APDU di risposta possono o meno inserire dati. Se la risposta non contiene dati, l'applet non deve fare altro
che restituire (o generare un'eccezione). Il JCRE genera i byte di stato appropriati e li invia al CAD. Se la risposta
richiede che l'applet restituisca dati, l'applet deve prima mettere JCRE in modalità di invio dati e quindi inviare i
dati. La necessità o meno dei dati di risposta dipende dalla particolare classe APDU e dai byte di istruzione.

Quando si inviano dati dall'applet, è necessario specificare il numero totale di byte da inviare. Questo numero totale
dovrebbe essere sempre minore o uguale alla lunghezza prevista della risposta specificata dal byte Le. Una volta inviati
tutti i byte di dati di risposta, l'applet non deve modificare il buffer di invio per il restoRdel metodo Pt.èIoces
bytehpotrebbero
Se ()
non essere effettivamente inviatiPunRToilcess ()ritorna al JCRE. Ciò consente a JCRE di combinare in modo efficiente i dati di
risposta con i byte di stato trattenendo l'ultimo invio fino al momento di inviare i byte di stato.

Nota -I dati vengono sempre inviati con byte di stato, ma in una APDU di risposta i dati sono facoltativi.

Per impostare la modalità JCRE da inviare, chiamare il metodo APDUimposta In uscita ().A differenza del corrispondente
setIncomingAndReceive ()metodo di lettura,setIn uscita ()non invia alcun byte; imposta solo la modalità. A differenza della
lettura, non è necessario inviare i dati subito dopo aver impostato la modalità di trasferimento. L'applet non può
continuare a ricevere byteSCeetIn uscita ()viene chiamato, perché la modalità di trasferimento non è più "ricezione".

IlsetIn uscita ()restituisce il numero di byte di risposta previsti dall'applicazione per il commandAPDU a
cui sta rispondendo l'applet. L'applet non dovrebbe rispondere con più di questo

3-12 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

numero di byte. L'applet deve informare il JCRE del numero di byte di risposta che invierà, utilizzando
il metodo APDUsetOutgoingLength ().

IlAPDUclasse contiene ilsetOutgoingAndSend ()metodo per:

- Impostazione della modalità di trasferimento da inviare

- Impostazione della lunghezza dei dati di risposta

- Invio dei byte di risposta

Questo metodo ricorda da vicino il funzionamento disetIncomingAndReceive (),tranne cheinviabyte, non li riceve. Il
setOutgoingAndSend ()utilizza il buffer APDU per l'invio di byte. È anche possibile utilizzare un buffer di proprietà e
fornito dall'applet per inviare byte, che possono essere più grandi del buffer APDU relativamente piccolo.

I dati di risposta inviati utilizzando questo metodo devono essere sufficientemente brevi da rientrare nel buffer APDU. I byte non
possono essere effettivamente inviati fino a quando l'applet non ritorna daprocessi ()metodo, in quel momento vengono combinati con
i byte di stato, quindi una volta chiamato questo metodo, l'applet non può aA ltP hebuffer fino aprocessi ()
erDtU
ritorna.

Se non si desidera inviare i dati subito dopo la chiamataSineGtIn uscita (),chiamatasendBytes ()o
sendBytesLong().Il primo metodo utilizza il buffer APDU, mentre il secondo metodo utilizza un buffer fornito
da apple. Per entrambi i metodi, non devi alterare il contenuto del buffePruoun CTeilss ()ritorna. Se
apeevoithsendBytesLong ()metodo
i dati di risposta vengono preparati in un buffer fornito dall'applet, usD.
e fornire il buffer fornito dall'applet come parametro, per evitare di dover copiare il buffer fornito dall'applet nel
buffer APDU.

Devi chiamaresetIn uscita ()prima di chiamaresetOutgoingLength (), sendBytes (),o

sendBytesLong().Non puoi chiamareSletOutgoingLength (), sendBytes (),osendBytesLong ()dopo
chiamandosetOutgoingAndSend ().Ad esempio, se hai tre byte che devono essere inviati, usa:

byte [] apduBuffer = apdu.getBuffer ();

apduBuffer [0] = byte1;

apduBuffer [1] = byte2;
apduBuffer [2] = byte3;

apdu.setOutgoingAndSend (0, 3); // 0-offset, 3-numero di byte da inviare

O:
le breve = apdu.setOutgoing ();

apdu.setOutgoingLength (breve) 3);

(apduBuffer [0] = byte1;
apduBuffer [1] = byte2;
apduBuffer [2] = byte3;

apdu.sendBytes ((breve) 0, (breve) 3);

Valori di ritorno
Un'applet ha diverse opzioni per restituire informazioni dall'apRPomenzognaCTes ()metodo. Il metodo più semplice è
lasciare semplicemente che il metodo ritorni. Quando si verificano errori durante l'elaborazione APDU, noiioe
SOException.throwIt (sw breve)per restituire errori SW. Le costanti di errore ISO SW possono essere trovate inISO
classe.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 3-13

Guida per sviluppatori di applet Java Card

Atomicita
Con le smart card, c'è il rischio di perdere energia in qualsiasi momento durante l'esecuzione dell'applet. Un utente della smart card può
rimuovere ("strappare") la scheda dal CAD, interrompendo l'alimentazione alla CPU della scheda e terminando l'esecuzione di eventuali
applet. Il rischio di tearing rappresenta una sfida per preservare l'integrità delle operazioni sui dati sensibili delle carte.

La tecnologia Java Card supporta la nozione di "transazioni" con funzionalità di commit e rollback per garantire che
operazioni complesse possano essere eseguiteunohmicamente
DTe —O completano con successo o parziale
i risultati non vengono messi in atto. Utilizzando le transazioni, puoi garantire che più campi di un oggetto vengano
aggiornati come un'unità.

Per creare una transazione, racchiudere una o più operazioni traSCyunSllTSoeTm.beginTransazione ()e
System.commitTransaction().I valori pre-transazione della destinazione vengono scritti in una posizione temporanea e
gli aggiornamenti vengono resi permanentiS wyhSeTunem.commitTransaction ()è chiamato. Se il potere è
persi durante la transazione, viene invocata una funzione di rollback, al ripristino dell'alimentazione, per riportare i valori di
destinazione al loro stato pre-transazione.

Le transazioni possono essere espressamente interrotte utilizzando l'acSunyllSTToem.abortTransaction().Una transazione deve

abortTransaction ()è
essere in corso quando chiamato; altrimenti,TunransactionExceptionviene lanciato.
Le transazioni non possono essere nidificate — a caBlleTG oinTransazionedall'interno di un blocco di transazione risulta anche
unTransactionException.Vengono restituiti i valori 0 o 1SByystem.getTransactionDepth().

Impegna buffer
Per supportare il rollback delle transazioni atomiche non vincolate, il JCRE conCtaoiom un muntamponedove la
Sio
i contenuti originali delle posizioni aggiornate vengono archiviati fino al commit della transazione. Questo buffer conserva anche le
informazioni di rollback, in caso di interruzione dell'alimentazione durante la fase di commit della transazione. Maggiore è il numero di
operazioni all'interno di un blocco di transazione, maggiore deve essere il buffer di commit per accoglierlo.

Prima di tentare una transazione, un'applet può verificare la dimensione del buffer di commit disponibile rispetto alla dimensione dei dati che
richiedono un aggiornamento atomico. Se non è disponibile una capacità di commit sufficiente, le operazioni possono essere eseguite
(rischiando la perdita di potenza durante le operazioni) o posticipate finché non è disponibile una capacità sufficiente.

Le opzioni di controllo della capacità sono le seguenti:

- System.getMaxCommitCapacity—restituisce la dimensione totale del buffer di commit

- System.getUnusedCommitCapacity—restituisce la capacità di commit disponibile

IlUtilclasse injavacard.frameworkcontiene metodi utili per copiare e riempire gli array

(arrayFill, arrayFillNonAtomic, copyArray, copyArrayNonAtomic).Le versioni non atomiche di
questi metodi non partecipano alle transazioni, il che significa che non beneficiano delle funzionalità di rollback e commit, anche quando
si trovano in un blocco di transazione. Per ottenere l'atomicità per la copia e il riempimento dell'array, utilizzare
arrayCopyearrayFillall'interno o all'esterno di un blocco di transazione.

Il numero di istruzioni di programma che si trovano all'interno di un blocco di transazione dovrebbe essere ridotto al minimo per evitare
di superare lo spazio di buffer cmomit fisso fornito dall'implementazione.

3-14 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

4. Ottimizzazione delle applet per schede Java

Un fattore importante che influenza il design e le funzionalità delle applet Java Card è la disponibilità limitata di programmi e
memoria dati nell'ambiente delle smart card. Questo capitolo si concentra sui problemi relativi alla creazione di applet Java
Card per dispositivi con vincoli di risorse.

La piattaforma Java Card accoglie ambienti in cui sono disponibili solo 512 byte di RAM. Il JCRE (inclusa la
Java Card VM e l'heap di sistema) deve essere contenuto nella ROM disponibile e le applet Java Card e le
librerie di classi devono essere archiviate nello spazio EEPROM disponibile sul dispositivo.

Per ottimizzare l'utilizzo della memoria, durante la creazione di applet Java Card si applicano le seguenti restrizioni:

- Un massimo di 127 metodi di istanza in qualsiasi classe (inclusi i metodi ereditati)

- Un massimo di 255 byte di dati di istanza

- Lo spazio oggetti è allocato dalla EEPROM

Nota -La versione JC2RI (Java Card 2.0 Reference Implementation) contiene un ambiente di simulazione che
consente di eseguire applet Java Card in un ambiente di workstation desktop. Questo ambiente ha limitazioni
di memoria diverse dall'esecuzione in un ambiente di memoria di smart card reale.

Riutilizzo di oggetti
Le applet non devono creare un'istanza di oggetti utilizzandonuovocon l'aspettativa che il loro spazio di archiviazione venga
recuperato, poiché JCRE potrebbe non includere un Garbage Collector. La regola generale è che nella tecnologia Java Card, a
la singola istanza di un oggetto dovrebbe essere "riciclata" ripetutamente, con ogni nuovo utilizzo che "personalizza" le variabili membro
dell'istanza dell'oggetto. Questo è un modello diverso da quello a cui potrebbero essere abituati gli sviluppatori di tecnologia Java.

Nella tecnologia Java, un'istanza di un oggetto viene creata secondo necessità, le sue variabili di istanza vengono impostate e quindi
l'oggetto viene scartato (in genere uscendo dall'ambito). Nella tecnologia Java Card, non dovresti mai consentire oggetti allocati connuovo
uscire dal campo di applicazione; diventeranno irraggiungibili, ma lo spazio di archiviazione che occupano non verrà mai recuperato.

Nella tecnologia Java Card, gli oggetti dovrebbero rimanere nell'ambito della vita dell'applet e dovrebbero essere riutilizzati
scrivendo nuovi valori nelle loro variabili membro. Si noti che ciò non richiede che tutti gli oggetti siano dichiarati come statici.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 4-1

Guida per sviluppatori di applet Java Card

L'esempio di codice seguente mostra come JCRE implementa le eccezioni in un modo che massimizza il riciclo
degli oggetti utilizzando ilsystemInstanceogni volta l'ISOExceptiongettarlo ()si usa il metodo:

la classe pubblica ISOException estende runtimeException {

istanza di sistema ISOException statica privata; public ISOException
(sw breve) {this.reason = sw;} public static void throwIt (sw breve) {

if (systemInstance == null) systemInstance = new ISOException (sw);}

systemInstance.setReason (sw);
sistema di lancio Istanza;
}

L'eccezione viene generata chiamando ilgettarlo ()metodo con una ragione (sw)per l'eccezione. Il
gettarlo ()viene dichiarato statico in modo che non sia necessario creare un'istanza di anISOExceptionoggetto per generare
l'eccezione. Invece, chiama semplicementegettarlo ()e personalizzare ogni chiamata con un codice motivo. Il
gettarlo ()il metodo a sua volta invocagettaresull'oggetto eccezione. Per esempio:

if (buffer [ISO.OFFSET_P1]! = 0) ISOException.throwIt

(ISO.SW_INCORRECT_P1P2);

Allocare memoria
La memoria per i tipi e gli array primitivi deve essere allocata al momento della dichiarazione dell'oggetto. La memoria per le variabili
dei membri della classe viene allocata dall'heap di sistema e non può essere recuperata (a meno che la smart card non implementi un
Garbage Collector). Qualsiasi memoria allocata danuovoè preso dal mucchio. La memoria per le variabili del metodo, i locali e i
parametri viene allocata dallo stack e viene recuperata quando il metodo ritorna.

Tipicamente,nuovonon dovrebbe essere chiamato da nessun metodo applet diverso dainstalla ()metodo, a meno chenuovo
verrà chiamato solo con moderazione dopo l'installazione dell'applet. Ilinstalla ()viene chiamato solo una volta, quando l'applet è
installata sulla scheda, in modo che anuovoininstalla ()risulta in una sola istanza dell'oggetto per la durata dell'applet. Si
raccomanda inoltre che ogni chiamata anuovoessere racchiuso in un blocco di transazione (vedi ilAtomicitasezione delCreazione
di un'applet per schede Javacapitolo). Ciò garantisce che tutta la memoria disponibile richiesta dall'oggetto venga allocata,
anche se l'alimentazione è stata interrotta in precedenzanuovoritorna. Più chiamate anuovopossono essere racchiusi in un unico
blocco di transazione, ma sono soggetti ai limiti della capacità di commit disponibile (maggiori informazioni di seguito).

Accesso agli elementi dell'array

Quando si accede a un elemento dell'array, vengono generati bytecode per soddisfare l'istruzione di accesso all'array. Per
ottimizzare l'utilizzo della memoria, se si accede più volte allo stesso elemento di una matrice da posizioni diverse nello stesso
metodo, salvare il valore della matrice in una variabile al primo accesso e quindi accedere alla variabile negli accessi successivi.
L'utilizzo del valore dell'array come variabile in questo modo crea bytecode più compatti rispetto al riaccesso all'array.

4-2 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

5. File

Il supporto per i file ISO 7816-4 è fornito dajavacardx.frameworkpacchetto. Questo è un pacchetto di estensione al
corejavacard.*classi che potrebbero non essere implementate su tutte le piattaforme Java Card. I file sono
raccolte identificate di dati correlati. I file sono utili per organizzare i dati in gruppi logici per l'archiviazione sulla
scheda. I due tipi di file supportati nelle classi javacardx, seguendo le definizioni della specifica ISO 7816-4, sono:

- File elementari

- File dedicati

File elementari e dedicati

I file elementari (EF) memorizzano i riferimenti agli array di byte che contengono i dati e i file dedicati (DF) fungono da
contenitori per i file elementari. La memorizzazione dei riferimenti viene eseguita per risparmiare memoria nelle situazioni in
cui l'applet alloca un array di byte e quindi passa l'array di byte al file system per aggiungerlo a un file. Il file memorizza un
riferimento alla matrice di byte e non alloca nuova memoria per il record. Di conseguenza, se l'applet modifica
successivamente il contenuto della matrice di byte, sta effettivamente modificando il record.

I file elementari possono essere organizzati in due modi, come:

- File trasparenti: una sequenza non strutturata di byte

- File di registrazione: uno o più array di byte

Non esiste supporto nella tecnologia Java Card per i record strutturati all'interno dei file. Cioè, i record vengono letti e scritti come
array di byte senza riguardo alla struttura interna dei campi di ciascun record. Spetta all'applet o all'applicazione esterna
interpretare la struttura dei campi degli array di byte memorizzati nei file di record.

Registra file
I file di registrazione possono blenell'orecchioociclico.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 5-1

Guida per sviluppatori di applet Java Card

File lineari
I file lineari contengono record organizzati in una sequenza ordinata. I record nel file vengono mantenuti nell'ordine in
cui sono stati inseriti, ovvero il primo record inserito è il record numero uno. La capacità del file lineare può essere
ampliata per includere più record (fino ai limiti imposti dal JCRE).

I record in un file lineare possono essere fissi o di lunghezza variabile, come illustrato nella FIGURA 5-1.

File fisso lineare File di variabili lineari

Record a lunghezza fissa Record a lunghezza variabile

FIGURA 5-1 File lineari

Non è necessario che tutti i byte in un record di lunghezza fissa contengano dati significativi, ma ogni record deve comunque
contenere un numero fisso di byte.

File ciclici
Nei file ciclici, i record sono organizzati come un anello (struttura ciclica), con dimensioni record fisse e uguali. Il numero di record in un
file ciclico viene assegnato al momento della creazione del file e non può essere modificato. I record sono al contrario
ordine in cui sono stati inseriti nel file: l'ultimo record inserito è identificato come record numero uno. Una volta che il file è
pieno, l'istruzione di aggiunta successiva sovrascrive il record più vecchio nel file e diventa il record numero uno.

L'ordine di registrazione di un file ciclico è mostrato nella FIGURA 5-2, prima di un comando append, con RecNum4 che è il
record più vecchio:

RecNum4 RecNum3 RecNum2 RecNum1

FIGURA 5-2 Ordine di registrazione dei file ciclici

Dopo il comando append record, il nuovo record sovrascrive il record più vecchio, RecNum4 e il record appena
inserito diventa RecNum1, come illustrato nella FIGURA 5-3.

RecNum1 RecNum4 RecNum3 RecNum2

FIGURA 5-3 File ciclico dopo l'aggiunta del record

Il numero massimo di record per qualsiasi file è 127 e la lunghezza massima di un record è 255 byte.

5-2 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

La classe FileSystem
L'API Java Card include aFile Systemclasse per l'elaborazione di APDU relativi ai file. IlFile System
class funge da contenitore principale per una gerarchia di file. IlFile Systemclass indirizza le APDU relative ai file
in entrata al file membro appropriato, quindi analizza e risponde alle APDU. Applet che non utilizzano a
File Systemla classe deve gestire autonomamente le APDU relative ai file.

La tabella seguente descrive i tipi di file associati a ciascuna classe:

TABELLA 5-1 Classi e tipi di file

Classe Tipo di file Descrizione

File dedicato Dedicato Agiscono come contenitori per i file elementari.

File Elementare Elementare Memorizzare i riferimenti alle matrici di byte che contengono i dati.

File variabile lineare Lineare Memorizza record lineari a lunghezza variabile.

File fisso lineare Lineare Memorizza record lineari a lunghezza fissa.

File ciclico Ciclico Memorizza record ciclici di lunghezza fissa.

Ilgerarchia di classidel file system è espresso nella FIGURA 5-4:

Classe: File

Classe: De DFile icato Classe: Elem File in entrata

( DF) (E F )

Classe: File System

Classe: TransparentFile cl un
ss:
(EF) LinearVaria bleFile (EF)

Classe: Linea arFixedFile

(E F)

Classe: File ciclico (EF)

FIGURA 5-4 Gerarchia delle classi FileSystem

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 5-3

Guida per sviluppatori di applet Java Card

Un tipicogerarchia dei file dell'appletè mostrato nella FIGURA 5-5, in contrasto con la gerarchia di classi mostrata sopra.

FIGURA 5-5 Gerarchia dei dati dell'applet

Si noti che il file dedicato non contiene dati propri: funge solo da contenitore per tipi di file elementari che
contengono dati.

Operazioni sui file

Le operazioni che possono essere eseguite sui file sono:

- Creazione di un nuovo file

- Aggiunta di un nuovo file a un file dedicato
- Impostazione degli attributi di sicurezza per un file
- Selezione di un file in un file system come destinazione delle operazioni implicite

Viene creato un nuovo file utilizzando thuneehmoperatore sul costruttore del file, come segue:

ciclico = nuovo CyclicFile (fileID, maxRecords, recordLength); dedicato = nuovo

DedicatedFile (fileID, nome, maxChildren);

I file di variabili lineari utilizzano un costruttore con almeno i due parametri seguenti:

- Un ID file univoco
- Il numero massimo di record che il file può contenere

L'ID file identifica in modo univoco il file da altri file. Se il file fa parte di un gruppo di file contenuti in un file
dedicato, i cinque bit inferiori dell'ID file (denominati Short File Identifier o SFI) vengono utilizzati per
individuare il file e distinguerlo dagli altri nel gruppo.

Il conteggio massimo dei record dichiara il numero massimo di record che il file può contenere. JCRE utilizza questo valore
per convalidare le operazioni sul file. JCRE non utilizza queste informazioni per calcolare o mettere da parte la memoria per
il file. I file nella tecnologia Java Card memorizzano i riferimenti agli array di byte, non gli array di byte stessi, ma la
memoria per i file viene allocata durante l'installazione dell'applet Java Card. Ad esempio, se un'applet Java Card dichiara
un file contenente 100 record, ogni record contiene 100 byte (per un totale combinato di 10.000 byte), la VM impedirà
l'installazione di questa applet se sono disponibili meno di 10.000 byte di memoria sul carta.

5-4 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Una volta che l'applet è stata installata, nuovi record possono essere allocati dall'applet (o dal file system) utilizzando il fileprocessi ()
metodo durante il normale utilizzo della carta (invece che durante ilinstalla ()metodo). Il conteggio massimo dei record per i file
lineari può essere aumentato in un secondo momento utilizzando una chiamata aaumentoMaxNumRecords ()
metodo. Per ottenere il massimo attuale, chiamaregetMaxNumRecords ().Per ottenere il numero corrente di record effettivi
nel file, chiamagetNumRecords ().I file a lunghezza fissa (LinearFixedFile e CyclicFile) hanno un parametro aggiuntivo per il
costruttore; la lunghezza del record. Il JCRE utilizza queste informazioni per convalidare che gli array di byte aggiunti ai file
come record abbiano la lunghezza corretta.

Il costruttore per i file dedicati (DF) contiene un parametro aggiuntivo che specifica il nome del file dedicato. A
differenza dei file elementari (EF), i file dedicati sono identificati da un nome logico oltre che da un ID file breve. Il
nome logico di un file dedicato è una matrice di byte, che non è necessariamente con terminazione null.

I file dedicati (DF) non contengono record, ma contengono riferimenti ad altri DF ed EF. Questi riferimenti
sono chiamati figli del file dedicato. Il costruttore di un file dedicato dichiara il numero massimo di figli,
che può essere aumentato in un secondo momento, ma non può superare i 30.

L'aggiunta di un nuovo file figlio a un file dedicato viene eseguita chiamando il fileaggiungiFileChild()metodo di
File dedicato.Per esempio:

dedicato.addChildFile (ciclico);

Il file dedicato su cui viene invocato il metodo diventa il contenitore (parent) per il file figlio, espresso come
parametro.

Sicurezza dei file

Gli attributi di sicurezza di un file sono progettati per proteggere il file dall'accesso esterno in lettura e scrittura. I file contengono due flag: uno
per controllare i permessi di lettura e uno per controllare i permessi di scrittura. Le autorizzazioni sono impostate indipendentemente l'una
dall'altra. Le autorizzazioni disponibili sono mostrate nella tabella seguente.

TABELLA 5-2 Flag di autorizzazione di accesso ai file

Autorizzazione Significato per la lettura Significato per la scrittura

ALLOW_ANY Lettura dei dati del file consentita Scrittura dei dati del file consentita

ALLOW_NONE Lettura dei dati del file non consentita Scrittura dei dati del file non consentita

ALLOW_AUTH1 Lettura consentita solo se il flag AUTH1 è impostato Scrittura consentita solo se nel file system a cui
nel file system a cui appartiene questo file appartiene questo file è impostato il flag AUTH1

ALLOW_AUTH2 Lettura consentita solo se il flag AUTH2 è impostato Scrittura consentita solo se nel file system a cui
nel file system a cui appartiene questo file appartiene questo file è impostato il flag AUTH2

Gli ultimi due flag, ALLOW_AUTH1 e ALLOW_AUTH2, vengono utilizzati quando il file appartiene a unFile System
classe. Ad esempio, supponiamo che un file supporti la lettura e la scrittura solo dopo la verifica del numero
PIN dell'utente. L'applet verifica il PIN e imposta il flag AUTH1 FiTavere
l Sistemaclasse su VERO. L'applet
quindi imposterebbe le autorizzazioni di lettura e scrittura del file su ALLOW_AUTH1.

Durante la lettura e la scrittura delle richieste sul file vengono effettuateFhiltheeSistemaclasse, viene
theeSistema
eseguita un'operazione AND sui due flag. Quando si accede al file tramite Fhil metodi, l'applet è
responsabile di garantire che siano soddisfatte le condizioni adeguate per la concessione di read andccwersitseto un file.

È possibile selezionare solo un file appartenente alla gerarchia del file system come file corrente. Il file corrente è la
destinazione delle operazioni sui file che non dichiarano esplicitamente su quale file operano. Ogni file system può

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 5-5

Guida per sviluppatori di applet Java Card

contengono un file elementare corrente e un file dedicato corrente. IlsetCurrentElementaryFile ()

esetCurrentDedicatedFile ()vengono utilizzati per impostare rispettivamente i file elementari e dedicati
correnti.

Nota -Una volta creati, i file rimangono sulla scheda per tutta la vita della scheda.

Trovare file
I metodi di ricerca dei file fanno tutti parte delFile dedicatoclass perché i file dedicati fungono da contenitori per tutti i DF e gli
EF. I file si trovano in diversi modi, ma il metodo più comune per individuare un file consiste nell'usare l'ID file breve del file,
che viene impostato quando viene costruito l'oggetto file. La ricerca per ID file si applica sia ai file dedicati che a quelli
elementari poiché entrambi i tipi hanno ID file.

IltrovaFile ()accetta l'ID del file come argomento e consente all'applet di specificare l'ambito della ricerca utilizzando un flag
come definito nella tabella seguente.

TABELLA 5-3 Flag di file

Bandiera Scopo
TROVA_CHILD_EF Cerca tra i figli del file dedicato corrente un file elementare corrispondente.
TROVA_CHILD_DF Cerca tra i figli del file dedicato corrente un file dedicato corrispondente.
TROVA_BAMBINO Cerca tra i figli del file dedicato corrente un file elementare o dedicato
corrispondente.

Si possono identificare univocamente fino a 30 file elementari tra i figli diretti di un file dedicato (i valori 0 e 31 sono
riservati). Gli ultimi cinque bit dell'ID del file, denominato Short File Identifier (SFI) vengono utilizzati per cercare un
file elementare, utilizzando il cafn llioaFile Elementare ().

I file dedicati, a differenza dei file elementari, sono identificati sia da un ID file che da un nome logico. Per
cercare un file dedicato figlio del file dedicato corrente,FCioununlFile
lD dedicato ()e specificare la logica
nome del file. Un altro modo per individuare un file è utilizzare l'ID figlio del file. L'id figlio è solo un
valore che identifica l'ordine sequenziale in cui il file è stato aggiunto al file dedicato corrente. Il
getChildFile ()il metodo individua un file usando il suo ID figlio.

IlFile Systemclass consente a un'applet di selezionare un file utilizzando il riferimento all'oggetto del file. Il metodo
seleziona il file ()prende un riferimento a un oggetto come parametro e rende il file di riferimento il file corrente. Uno
sviluppatore di applet può bypassare thio
F eleSystemclasse e accedere direttamente al file dedicato utilizzando l'ID del file
(FID). Ad esempio, se la struttura del file è:

Master DedicatedFile con FID (0x1234);

dove master contiene due file, vale a dire un DF e un EF, l'applet invocherà:

df.findFile (TROVA_XXX, 0x1234)

5-6 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

Se il flag FIND è FIND_CHILD, allora iltrovaFile ()il metodo restituisce null. Se il flag FIND è FIND_ANY,
allora iltrovaFile ()il metodo cercherà tutti i fratelli, i figli e il genitore del DF associato e restituirebbe il file
principale con FID = 0x1234.

Registra le operazioni
I file (tranne i file dedicati) sono contenitori di dati. I file trasparenti archiviano i dati come un unico flusso di byte non
strutturato. Altri file organizzano i dati in record. L'API Java Card consente le seguenti operazioni sui file utilizzando i
record:

- Aggiungi un record a un file.

- Scrivere i dati in un record in un file.
- Leggi i dati da un record.
- Cancella i dati in un record.

Come per i file, una volta creato un record, rimane all'interno del file per tutta la vita della scheda. Cancellare un record
non equivale a cancellarlo. La cancellazione riporta semplicemente a zero i byte nel record.

I record possono essere aggiunti a file di tipo LinearVariableFile e LinearFixedFile utilizzando l'estensioneaggiungiRecord ()
metodo. Due varietà diaggiungiRecord ()sono forniti: uno in cui l'applet alloca l'array di byte per il record da
aggiungere, un altro che si basa su JCRE per allocare l'array di byte per il record. Con entrambi i metodi, l'array
di byte non diventa parte del file: al file viene aggiunto solo un riferimento all'array.

Secondo ISO 7816-4, i file di tipCeyclicFilenon supportano l'aggiunta di record. I file trasparenti e i file
dedicati non contengono record.

Per scrivere dati in un record, attenersi alla seguente procedura:

1. Chiama ilgetRecord ()metodo per recuperare l'array di byte del record.

2. Modificare la matrice di byte, che in effetti scrive i dati nel record.

Trovare record
Dopo aver individuato un file, è necessario individuare il record da leggere o scrivere. I record vengono individuati utilizzando il
numero di record sequenziale o effettuando una ricerca sulla chiave del record. Per i file lineari, il numero di record è un numero
sequenziale con un valore compreso tra 1 e N, dove N è il numero di record nel file. Il numero di record viene assegnato quando il
record viene aggiunto al file e non viene mai modificato.

Per i file ciclici, il numero di record varia da 1 a N, dove N è il numero di record nel file. A differenza dei file lineari, i
numeri di record in un file ciclico vengono assegnati nell'ordine inverso rispetto a come sono stati scritti i record:
all'ultimo record scritto in un file ciclico viene assegnato il numero di record 1 e theclen atslty - rscritto
al record viene assegnato il numero di record N. UsaGTehTeDisco ()metodo e specificare il numero di record per recuperare la
matrice di byte per un record particolare. Mareeth menzognaeFile mentali e dedicatisezione sopra per i dati sul
archivio ciclico.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 5-7

Guida per sviluppatori di applet Java Card

La chiave del record è una combinazione del primo e del secondo byte del record. I record si trovano per
chiave, utilizzando iltrovarecord ()metodo. Iltrovarecord ()il metodo opera sia in modalità relativa che
assoluta. In modalità relativa, la ricerca inizia dal record corrente e da lì si sposta avanti o indietro. In
modalità assoluta, la ricerca inizia all'inizio del file e va avanti o indietro dalla fine del file. Un flag di
direzione specifica la modalità di ricerca, come indicato nella tabella seguente.

TABELLA 5-4 Bandiere di direzione della modalità di ricerca

Bandiera La moda

DIREZIONE_PRIMA Cerca in avanti dall'inizio del file. Cerca

DIREZIONE_ULTIMO indietro dalla fine del file. Cerca in
DIRECTION_NEXT avanti dal record corrente. Cerca
DIREZIONE_PREV indietro dal record corrente.

Gestione dei file con la classe FileSystem

L'API Java Card contiene una classe speciale chiamataFile Systemper la gestione delle APDU relative ai file. Il
File Systemla classe si estendeFile dedicato,fungendo da punto di controllo per i comandi che fanno riferimento ai file
elementari (dati) e dedicati (contenitore) in esso contenuti. MareLa classe FileSystemsezione precedente per ulteriori
informazioni sulFile Systemclasse.

IlFile Systemclass fornisce un'implementazione predefinita per:

- Leggere, scrivere, aggiornare e cancellare dati in file trasparenti

- Lettura, scrittura, aggiornamento e aggiunta di record nei file di record
- Lettura e scrittura su file con record in formato Tag-Length-Value

IlFile Systemclass fornisce anche un meccanismo di sicurezza per fornire una misura di controllo
dell'accesso ai singoli file. Il meccanismo di sicurezza si basa su due flag, AUTH1 e AUTH2. IlsetAuthFlag ()
viene utilizzato per impostare il valore di AUTH1 e AUTH2 su TRUE o FALSE. IlgetAuthFlag ()
viene utilizzato per ottenere il valore di questi flag.

Centrale per l'uso delFile Systemclass è il concetto del file corrente e del record corrente. Un APDU può omettere la specifica di un
file di destinazione per il suo funzionamento: in questa situazione, il file corrente diventa la destinazione. Allo stesso modo, un
APDU potrebbe non specificare un record di destinazione per itsao ehm — in questa situazione, la corrente
Consiglio
in poi

record diventa l'obiettivo. L'operazione del file di dati corrente foArPaDnU è sempre relativa al file dedicato
attualmente selezionato all'interno del file system.

Dal momento che ilFile Systemclass è di per sé un file dedicato, può contenere altri file dedicati, che, a loro volta,
possono contenere file elementari. Il record corrente è sempre relativo al file elementare corrente. Il
File Systemclass contiene metodi per impostare e ottenere il file dedicato corrente, il file elementare corrente e il
record corrente, come indicato nella tabella seguente.

TABELLA 5-5 Metodi del file system

Metodo Descrizione
getCurrentDedicatedFile () Ottiene il file dedicato corrente.

getCurrentElementaryFile () Ottiene il file elementare corrente.

5-8 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

getCurrentRecNum () Ottiene il numero del record corrente.

setCurrentDedicatedFile () Imposta il file dedicato corrente.

setCurrentElementaryFile () Imposta il file elementare corrente.

setCurrentRecNum () Imposta il numero del record corrente.

Questi metodi di impostazione non sono l'unico meccanismo per impostare il file elementare corrente o il numero di
record. Alcuni comandi ISO cambiano il file o il record elementare corrente. La tabella seguente mostra il
File Systemmetodi utilizzati nell'elaborazione di vari comandi ISO e il risultato risultante (si presume un CLA di
0 per tutti i comandi ISO):

TABELLA 5-6 Metodi del file system

Comando ISO INS Descrizione Metodo FileSystem Risultato risultante

LEGGI BINARIO B0 Leggi i dati da un readBinario () Rende l'EF corrente di destinazione
file trasparente e reimposta il numero del record
corrente su 0.

SCRIVERE BINARIO D0 Scrivi i dati su a writeBinary() Rende l'EF corrente di destinazione

cartella trasparente e reimposta il numero del record
corrente su 0.

AGGIORNA BINARIO D6 Aggiorna i dati in un updateBinary() Rende l'EF corrente di destinazione

file trasparente e reimposta il numero del record
corrente su 0.

CANCELLA BINARIO 0E Contrassegna i dati come cancellati cancellaBinary () Rende l'EF corrente di destinazione.
in un file trasparente

APPENDERE RECORD E2 Aggiungi un record a un appendRecord () Rende l'EF corrente di destinazione.

file orientato al record Crea un record allegato
record corrente.

LEGGI LA REGISTRAZIONE B2 Legge i dati da un file readRecord () Rende l'EF corrente di destinazione.
orientato ai record Crea record di lettura
record corrente.

SCRIVERE REGISTRAZIONE D2 Scrivi i dati in un file scriviRegistra () Rende l'EF corrente di destinazione.

orientato ai record Fare una registrazione scritta

record corrente.

AGGIORNAMENTO REGISTRO DC Aggiorna i dati in un file aggiornaRecord () Rende l'EF corrente di destinazione.
orientato ai record Crea record aggiornato
record corrente.

OTTIENI DATI circa Recupera tag-lunghezza- getData() Nessuno

Valore (TLV)
dati formattati da
file corrente.

METTERE DATI DA Imposta valore lunghezza tag putData() Nessuno

(TLV) dati formattati

nel file corrente.
SELEZIONARE A4 Seleziona un file come Selezionare () Se il target è un EF,
EF o DF corrente seleziona il DF del target
come DF corrente.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 5-9

Guida per sviluppatori di applet Java Card

Questi metodi sono metodi protetti e non sono pensati per essere invocati dalle applet. Questi metodi non solo
elaborano il comando APDU, ma creano anche una risposta APDU con byte di stato e la inviano.

Nota-Un'applet non dovrebbe modificare la virgolaAnP buffer dDU in alcun modo una volta che questi metodi ritornano perché
JCRE utilizza il buffer dei comandi per la risposta. L'ultima risposta (inclusi i byte di stato) potrebbe non essere inviata fino a quando
l'applet non ritorna da iP tsprocesso ()metodo.

Poiché i valori dei byte CLA e INS sono standard per il processo APDUFDioBlyeS thyevoceclasse,
non vi è alcun motivo per richiedere all'applet di analizzare prima l'APmDU
macc
per intestazione per i byte CLA e INS,
unteio
leSystemmetodo. Invece, thFeileSystem
eseguire uninterruttore ()dichiarazione e chiamare l'appropriatoF
la classe fornisce thPeprocesso ()metodo per eseguire questa elaborazione (da non confondere con l'applet
processi ()metodo). A meno che l'applet non debba eseguire un'elaborazione non standard per uno degli APDU di comando elencati
nella tabella, non vi è alcun motivo per analizzare il buffer di comando diAthPeDU o chiamare uno qualsiasi dei
File Systemmodalità indicate in tabella. VOIFSioeleSystem.process ()per instradare le APDU ai
metodi appropriati per l'elaborazione standard. Per esempio:

// Il seguente frammento di codice mostra come un'applet in genere delega // vari APDU per
l'elaborazione, in particolare come un'applet passa // APDU orientati ai file ISO a FileSystem per
la gestione.

buffer = apdu.getBuffer (); FileSystem fs =

nuovo FileSystem (4);

if (buffer [ISO.OFFSET_CLA] == 0) { // APDU orientata ai file ISO

interruttore (buffer [ISO.OFFSET_INS] {XX:
Astuccio
// quello che va qui è il codice per l'applet per gestire qualsiasi file ISO - // istruzioni
APDU orientate o e APDU
// istruzioni che il metodo FileSystem non supporta return;

predefinito:
// istruzione APDU del file system standard fs.process
(apdu);
Restituzione;
}
}

// APPLET_CLA - byte CLA dell'applet, un numero di byte assegnato in modo specifico a // questa
applet
se (buffer [ISO.OFFSET_CLA] == APPLET_CLA)
// Le istruzioni APDU specifiche dell'applet vengono gestite qui
Restituzione;
}

// Impossibile gestire altre istruzioni APDU in cui il byte CLA è // né APPLET_CLA

né 0.
ISOException.throwIt (ISO.SW_CLA_NOT_SUPPORTED);

Gli sviluppatori interessati a gestire personalmente le APDU del file system (ad esempio, quando il file
javacardx.frameworkpacchetto non è implementato sulla piattaforma) dovrebbe rifioeSRoa7816-4per un
riferimento completo sulla struttura di comando di tAhP ed
seUs e le risposte attese.

5-10 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

6. Crittografia

La crittografia nella tecnologia Java Card è fornita da due pacchetti di estensione:javacardx.cryptoe

javacardx.cryptoEnc.IlcryptoEncil pacchetto mantiene la capacità di crittografia DES separata. Ciò consente agli implementatori
di escludere DES dalcriptopacchetto per rispettare le restrizioni all'esportazione degli Stati Uniti. Nessuno dei due pacchetti
fa parte dei pacchetti API Java Card richiesti di base e quindi la crittografia potrebbe non essere supportata su alcune smart
card basate su Java Card.

La comprensione della crittografia dell'API Java Card richiede la comprensione dei concetti di crittografia di base
discussi in questo capitolo.

Concetti di crittografia
La crittografia supporta due funzioni di base:privacyeautenticazione. Per privacy si intende lo scambio sicuro di informazioni tra
due o più sedi senza il rischio di intercettazioni da parte di soggetti che non sono i destinatari previsti del messaggio.
Autenticazione significa dimostrare che un messaggio proviene effettivamente dalla parte prevista e non da un impostore.
Autenticazione significa anche dimostrare che un messaggio non è stato alterato durante la trasmissione.

Un concetto fondamentale della crittografia è ilchiave. Una chiave è una stringa di bit che viene inserita in un algoritmo per
la codifica o la decodifica delle informazioni. La crittografia si basa sul concetto che alcuni algoritmi per la decodifica delle
informazioni funzioneranno solo se dotati di una chiave identica o correlata alla chiave utilizzata nell'algoritmo per la
codifica delle informazioni.

Quando una chiave identica viene utilizzata per codificare e decodificare, si dice che lo siano gli algoritmisimmetrico.
L'esempio seguente illustra come comunicano due parti (A e B) utilizzando algoritmi simmetrici. La parte A crea un
messaggiome vi applica l'algoritmo di codifica. L'output dell'algoritmo di codifica è il messaggio codificatoC:

c = f (ks, m)

Il simbolo ks rappresenta la chiave utilizzata dagli algoritmi di codifica e decodifica. Il messaggio codificatoC viene
trasmesso alla Parte B. La Parte B decodifica il messaggio applicando l'algoritmo di decodifica aCper riprodurre il
messaggio originalem:

m = g (ks, c)

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 6-1

Guida per sviluppatori di applet Java Card

Gli algoritmi simmetrici sono veloci ed efficienti. Tuttavia, sia il mittente che il destinatario delle informazioni devono
possedere la chiave per scambiare informazioni codificate. Per questo motivo, la chiave in un algoritmo simmetrico è
talvolta chiamata achiave condivisa. Questo crea un problema: come possono le due parti scambiare la chiave condivisa
senza correre il rischio che una terza parte intercetti la chiave e ottenga l'accesso alle loro conversazioni successive?

Risolvere questo problemaun,simmetricosono stati sviluppati algoritmi. Utilizzando algoritmi asimmetrici,

nell'algoritmo di codifica viene utilizzata una chiave e nell'algoritmo di decodifica viene utilizzata una chiave
diversa. Le due chiavi non sono identiche, ma sono correlate. Soprattutto, la relazione tra le chiavi è tale che la
chiave per la decodifica non può essere derivata dalla chiave per la codifica. Questa importante proprietà consente
di pubblicare la chiave per la codifica nel mondo, mantenendo la chiave per la decodifica privata. L'esempio
seguente illustra come comunicano due parti (A e B) utilizzando algoritmi asimmetrici. La parte A crea un
messaggio e vi applica l'algoritmo di codifica. L'output dell'algoritmo di codifica è codificatoCm : saggio

c = f (k1, m)

Il simbolo k1 rappresenta tPhvoiechiave blicutilizzato dall'algoritmo di codifica per un particolare individuo (Parte B in questo
caso). La chiave k1 può essere utilizzata solo per codificare i messaggi in B, non per decodificarli. La codificaCedismessaggio
trasmesso alla Parte B. La Parte B decodifica il messaggio applicando l'algoritmo di decodificaCritohm riprodurre il
messaggio originaleme. L'algoritmo di decodifica utilizza la seconda chiave, k2:

m = g (k2, c)

Solo la Parte B può decodificare i messaggi codificati con la chiave k1, perché solo la Parte B possiede la chiave k2, motivo per cui il
terminechiave privataè usato per descrivere k2.

Gli algoritmi asimmetrici sono più lenti degli algoritmi simmetrici, ma sono più sicuri perché non è necessario che le parti comunicanti si
scambino chiavi private. Un approccio ibrido che utilizza le migliori caratteristiche degli algoritmi sia simmetrici che asimmetrici utilizza
innanzitutto la chiave pubblica del destinatario per codificare una chiave privata condivisa. La chiave privata condivisa viene utilizzata per
codificare la maggior parte del messaggio, quindi la chiave privata condivisa codificata viene allegata al messaggio codificato e inviata. Il
destinatario decodifica prima la chiave privata condivisa, utilizzando la chiave privata del destinatario. Successivamente, il destinatario
utilizza la chiave condivisa decodificata per decodificare la maggior parte del messaggio.

L'API Java Card supporta algoritmi sia simmetrici che asimmetrici.

Chiavi simmetriche
Iljavacardx.cryptoil pacchetto contiene il supporto per la creazione di chiavi da utilizzare negli algoritmi simmetrici. La classe base per le
chiavi simmetricheSioySmKey,che estende il bassoKcircuito integratoehiclasse utilizzata per tutte le chiavi. Prima di poter utilizzare una
chiave simmetrica, è necessario impostarne il valoreSGethKeehi ()metodo. Questo metodo imposta la stringa di bit per la chiave da una
matrice di byte, fornita come parametro. A differenza degli algoritmi asimmetrici, non è necessario creare due chiavi distinte e
correlate.

Gli algoritmi simmetrici supportati dall'API Java Card sono orientati ai blocchi. Ciò significa che gli algoritmi codificano le
informazioni un blocco alla volta. Una dimensione tipica del blocco è di 8 byte. L'API Java Card supporta due modalità di
codifica a blocchi: Electronic Code Book (ECB) e Cipher Block Chaining (CBC). La modalità ECB prende un blocco di
informazioni alla volta, lo codifica e produce un blocco codificato, come illustrato nella FIGURA 6-1.

6-2 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

m1 m2 m3 m4

c1 c2 c3 c4

FIGURA 6-1 Grafico della BCE

La modalità CBC prende un blocco di informazioni alla volta, lo combina con il blocco precedentemente codificato e
produce un blocco codificato dalla combinazione, come illustrato nella FIGURA 6-2.

m1 + ICVm2 + c1 m3 + c2 m4 + c3

c1 c2 c3 c4

FIGURA 6-2 Diagramma CBC

La modalità CBC ha il vantaggio di nascondere le ripetizioni in formato blocco nel messaggio originalem. Si noti che per il primo blocco,
l'algoritmo CBC non dispone di un blocco di informazioni codificate da aggiungere al primo blocco del messaggio. Un valore chiamato
vettore di concatenamento iniziale (ICV) viene aggiunto al primo blocco di messaggi per superare questo problema.

L'API Java Card include quattro classi per l'implementazione della codifica e decodifica simmetrica DES. La prima classe è
DES_Chiave.Questa classe viene utilizzata solo per la decodifica DES singola. DES singolo si riferisce all'algoritmo DES a passaggio
singolo, in cui il messaggio viene codificato una volta utilizzando un'unica chiave. Una seconda classe, chiamataDES3_Chiave,
implementa solo la decodifica tripla DES. Triple DES si riferisce a un'applicazione in tre fasi dell'algoritmo DES in cui il
messaggio viene codificato tre volte utilizzando due chiavi a lunghezza singola. Il triplo DES è considerato più sicuro in alcune
situazioni rispetto al singolo DES.

La funzionalità di codifica per i due algoritmi DES è aggiunta daDES_EncKeyeDES3_EncKeyclassi, che estendono il
DES_ChiaveeDES3_Chiaveclassi di decodifica, rispettivamente. Queste due classi fanno parte del
javacardx.cryptoEncpacchetto, non iljavacardx.cryptoclasse. Il motivo per tenerli separati, come accennato in precedenza, è
che non tutte le smart card con tecnologia Java avranno capacità di crittografia DES a causa delle restrizioni
all'esportazione su questa tecnologia.

Verifica dei messaggi con codifica simmetrica

I messaggi codificati utilizzando algoritmi simmetrici vengono verificati allegando acodice di autorizzazione del
messaggio(MAC) al messaggio. Il MAC serve a verificare che il messaggio non sia stato alterato dalla sua forma
originale. Il MAC viene creato in funzione dei dati del messaggio e della chiave, utilizzando ilgeneraMAC ()metodo. Per
autenticare un messaggio con un MAC allegato, chiamareverificaMAC().La verifica dell'integrità di un messaggio con un
MAC collegato è una funzione del valore MAC, dei dati del messaggio e della chiave. L'API Java Card supporta la
creazione e la verifica di MAC utilizzando il metodo di codifica CBC.

L'algoritmo CBC agisce in modo ondulatorio utilizzando l'output del blocco dell'iterazione precedente dell'algoritmo all'input
del blocco successivo. L'output del blocco dell'iterazione finale dell'algoritmo è una rappresentazione univoca dell'intero
messaggio, che incorpora le informazioni di tutti i blocchi precedenti nel messaggio. Questo

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 6-3

Guida per sviluppatori di applet Java Card

l'output finale è ideale per l'uso come MAC. Se il messaggio viene alterato in qualsiasi modo durante la trasmissione,
il valore MAC allegato non sarà uguale al valore MAC generato sul testo alterato.

Chiavi asimmetriche
A differenza delle chiavi simmetriche, gli algoritmi asimmetrici utilizzano due chiavi: una pubblica, una privata. Questa coppia di
chiavi ha una relazione matematica tra loro. La classe base per tutte le chiavi asimmetriche èAsym Key,e come
SymKey, AsymKeyè un'estensione del genericoChiaveclasse. Creare una chiave simmetrica è facile: imposta semplicemente la stringa
di bit per la chiave usando thSeetKey ()metodo. La creazione di coppie di chiavi asimmetriche è più complicata, perché la coppia di
chiavi deve essere calcolata matematicamente da determinati parametri chiave.

Per capire come creare chiavi asimmetriche, bisogna prima capire come vengono calcolate. Poiché la tecnologia Java Card
implementa l'algoritmo asimmetrico RSA, discuteremo la creazione di chiavi in termini di questo algoritmo. La generazione di una
coppia di chiavi RSA prima richiede due numeri primi grandiPbaenrsd,Q. Questi due numeri vengono moltiplicati per produrre un
modulounS :,

n = pq

Successivamente, un valoreeviene scelto che soddisfa le seguenti relazioni matematiche:

e <n eenon ha fattori in comune con i valori (p-1)o (q-1)

è scelto in modo tale che il valevoiDe-1è rotondo

Il valoreeè chiamato esponente pubblico. Successivamente, un vaDlu
divisibile per il valore(p-1) (q-1).Dè chiamato esponente privato. La coppia (n, e) forma la chiave pubblica e i valori (n, d)
formano la chiave privata. I valoriD, oPf, eQdeve essere tenuto rigorosamente segreto, mentre il valoreuns di eesono
resi pubblici. Per codificare un messaggio con la chiave pubblica, utilizzare la seguente formula:

c = memod n

Per decodificare un messaggio utilizzando la chiave privata, utilizzare la seguente formula:

m = cDmod n

Le formule appena descritte sono la base di una forma comune dell'algoritmo RSA, si sam unounDSulTvoihSe-
esponentemodulo. Un'altra forma comune è chiamata th CeTeorema del Resto di Hinese(CRT). Il modulo CRT
ha anche le sue radici nel prime facto PrasQ, ma viene calcolato in modo diverso, utilizzando una formula non pertinente a
la discussione qui. Dal punto di vista della programmazione basta solo rendersi conto che invece di impostare i valori (n,
e) per la chiave pubblica e (n, d) per quella privata, bisogna impostare i seguenti valori per quella privata solo chiave:

P
Q
P-1 mod Q
D mod (p-1)
D mod (q-1)

6-4 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.

 Guida per sviluppatori di applet Java Card

La tecnologia Java Card implementa l'algoritmo RSA sia nella sua forma esponente del modulo che nella forma CRT.
L'API Java Card contiene classi per chiavi pubbliche e private utilizzate negli algoritmi asimmetrici. Tutte le chiavi
pubbliche discendono daChiave pubblicaclasse. Tutte le chiavi private discendono dalChiave privataclasse. Nello specifico,
RSA_PublicKeydefinisce una chiave pubblica da utilizzare con l'algoritmo RSA nella sua forma esponente del modulo e
RSA_PrivateKeydefinisce una chiave privata corrispondente.

Per creare una chiave pubblica in questo modulo, è necessario specificare il moduloune l'esponentee. Per creare una chiave
privata, è necessario specificare il moduloune l'esponenteD.La classeRSA_CRT_Chiave privataimplementa una chiave privata
RSA nel modulo CRT. Per creare una chiave privata in questo modulo, devi specificare tutti i cinque parametri sopra elencati
per l'algoritmo CRT. Una chiave privata CRT può essere accoppiata con una chiave pubblica del modulo modulus-exponent.

Autenticazione e verifica
Gli algoritmi asimmetrici vanno oltre gli algoritmi simmetrici in quanto consentono al destinatario di un messaggio di verificare non solo
l'integrità di un messaggio, ma anche la sua origine. Viene chiamata la verifica dell'origine di un messaggio autenticazione. Per creare un
messaggio autentico, il mittente di un messaggio crea prima un messaggiovalore hashper il messaggio. Il valore hash (noto anche come
message digest) è una stringa di bit che identifica in modo univoco il messaggio. Il mittente codifica quindi il valore hash con la propria
chiave privata.

Successivamente, la maggior parte del messaggio viene codificata utilizzando la chiave pubblica del destinatario. Il valore hash codificato
viene allegato al messaggio codificato e agisceDunigSessounal firmaper quel messaggio. Il destinatario del messaggio prima decodifica la
maggior parte del messaggio utilizzando la chiave privata del destinatario. Successivamente, il destinatario confronta la firma digitale con il
messaggio, utilizzando una semplice relazione matematica che prevede:

- La chiave pubblica del mittente

- La firma
- Il messaggio

IlSha1MessageDigestclass crea un valore hash sicuro per un messaggio adatto all'uso nelle firme digitali.
Questa classe estende il bmuneSSesageDigestclasse che incorpora la funzionalità generale della tabella hash.
Nota dalla discussione precedente che le firme vengono create solo utilizzando la chiave privata del mittente
— i metodi per firmare i messaggi nell'API Java Card sono inclusi solo nelle classi che estendono
Chiave privata.Ilcartello ()metodo fa parte di questa classe e prende come parametri la chiave privata del mittente e i dati
del messaggio da firmare.

La verifica/autenticazione richiede solo la chiave pubblica del mittente — solo le classi si estendonoPinvoiGblthioecTasto
classe includono un metodo per la verifica. Tvheerifare ()fa parte di questa classe e include parametri per il
valore hash del messaggio da verificare, insieme ai dati firmati stessi.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 6-5

 Guida per sviluppatori di applet Java Card

Glossario

AIUTOè l'acronimo di Application IDentifier come definito nella ISO 7816-5.

APDUè l'acronimo di Application Protocol Data Unit come definito nella ISO 7816-4.

APIè l'acronimo di Application Programming Interface. L'API definisce le convenzioni di chiamata in base alle quali un
programma applicativo accede al sistema operativo e ad altri servizi.

Appletl'unità di base di selezione, contesto, funzionalità e sicurezza nella tecnologia Java Card.

Sviluppatore di appletsi riferisce a una persona che crea un'applet utilizzando l'API Java Card 2.0.

Contesto di esecuzione dell'applet. Il JCRE tiene traccia dell'applet attualmente selezionata e dell'applet attualmente attiva. Il valore
dell'applet attualmente attivo viene definito contesto di esecuzione dell'applet. Quando un metodo virtuale viene invocato su un
oggetto, il contesto di esecuzione dell'applet viene modificato in modo che corrisponda all'applet che possiede quell'oggetto. Quando
quel metodo ritorna, viene ripristinato il contesto precedente. Le invocazioni di metodi statici non hanno effetto sul contesto di
esecuzione dell'applet. Il contesto di esecuzione dell'applet e lo stato di condivisione di un oggetto determinano insieme se l'accesso a
un oggetto è consentito.

Operazione atomicaè un'operazione che viene completata nella sua interezza (se l'operazione ha esito positivo) o nessuna parte dell'operazione
viene completata (se l'operazione ha esito negativo).

Atomicitasi riferisce al fatto se una particolare operazione è atomica o meno ed è necessaria per un corretto ripristino dei dati nei casi in
cui viene interrotta l'alimentazione o la scheda viene rimossa inaspettatamente dal CAD.

CADè l'acronimo di Card Acceptance Device. Il CAD è il dispositivo in cui è inserita la carta.

Lancioè la conversione esplicita da un tipo di dati a un altro.

Classeè il prototipo di un oggetto in un linguaggio orientato agli oggetti. Una classe può anche essere considerata un insieme di
oggetti che condividono una struttura e un comportamento comuni. La struttura di una classe è determinata dalle variabili di
classe che rappresentano lo stato di un oggetto di quella classe e il comportamento è dato da un insieme di metodi associati alla
classe.

Le classi sono correlate in una gerarchia di classi. Una classe può essere una specializzazione (una "sottoclasse") di un'altra (una
delle sue "superclassi"), può essere composta da altre classi, oppure può utilizzare altre classi in una relazione client-server

EEPROMè l'acronimo di memoria di sola lettura programmabile e cancellabile elettricamente.

Strutturaè l'insieme di classi che implementano l'API. Ciò include pacchetti di base ed estensione. Le
responsabilità includono il dispatchingAoP
f DU, selezione di applet, gestione dell'atomicità e applet di durata.

Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc. 1

Guida per sviluppatori di applet Java Card

Raccolta dei rifiutiè il processo mediante il quale la memoria allocata dinamicamente viene recuperata durante l'esecuzione di un
programma.

Ambiente di runtime della scheda Java (JCRE)è costituito dalla Java Card Virtual Machine, dal framework e
dai metodi nativi associati.

JC2RIè l'acronimo di Java Card 2.0 Reference Implementation.

Sviluppatore JCREsi riferisce a una persona o azienda che crea un framework specifico del fornitore utilizzando l'API Java Card 2.0.

JDKè l'acronimo di Java Development Kit. Il JDK è un Sun Microsystems, Inc. prodotto che fornisce l'ambiente
necessario per la programmazione nel linguaggio software Java. Il JDK è disponibile per una varietà di
piattaforme, ad esempio Sun Solaris e Microsoft Windows.

Variabile di istanza, nella programmazione orientata agli oggetti, è quando può esistere un valore diverso per ogni oggetto di una classe.

Istanziazione, nella programmazione orientata agli oggetti, significa produrre un particolare oggetto dal suo
modello di classe. Ciò comporta l'allocazione di una struttura dati con i tipi specificati dal modello e l'inizializzazione
di variabili di istanza con valori predefiniti o quelli forniti dalla funzione di costruzione della classe.

MACè l'acronimo di Message Authentication Code. MAC è una crittografia dei dati a fini di sicurezza.

Metodoè il nome dato a una procedura o routine, associata a una o più classi, nei linguaggi orientati agli
oggetti.

Spazio dei nomiè un insieme di nomi in cui tutti i nomi sono univoci.

Orientato agli oggettiè una categoria di linguaggi e tecniche di programmazione basata sul concetto di “oggetto”
che è una struttura dati incapsulata con un insieme di routine, dette “metodi”, che operano sui dati.

Oggetti, nella programmazione orientata agli oggetti, sono istanze univoche di una struttura dati definita secondo il
modello fornito dalla sua classe. Ogni oggetto ha i suoi valori per le variabili appartenenti alla sua classe e può rispondere
ai messaggi (metodi) definiti dalla sua classe.

Pacchettoè uno spazio dei nomi di software Java e può avere classi e interfacce. Un pacchetto è l'unità più piccola del
software Java che può essere elaborata dall'utilità JCC e installata su una smart card con tecnologia Java.

Ambiente di runtime, vedere JCRE.

Transazioneè un'operazione atomica in cui lo sviluppatore definisce l'entità dell'operazione indicando nel codice
del programma l'inizio e la fine della transazione.

2 Rev.1.10 Copyright © 17 luglio 1998 Sun Microsystems, Inc.