Scrivere un'applet per JavaCard

Non è una cosa particolarmente difficile, ma bisogna riuscire a capire tante piccole cose. A partire dalla terminologia per finire col software da utilizzare...
Non voglio affrontare in questa pagina la scrittura dell'applet in sé (ci sono tanti tutorial in giro fatti meglio di quanto potrei fare io...), ma solo le "questioni di contorno" che vengono date per scontate ma che, per chi inizia, non lo sono.

Scelta degli ID

Per ogni applet servono due ID: un packageID ed un AID.
Normalmente l'AID è basato sul packageID, con un'aggiunta. Non è necessario, ma può essere comodo.
Ogni ID inizia con 5 byte di RID che dovrebbero essere assegnati dall'ISO. Il primo nibble può essere (preso da un draft IETF, dato che non voglio pagare per ottenere il documento ufficiale dall'ISO...):

  0-9  An ISO 7812 IIN.
   A    Internatinal registration.
  B-C  Reserved for ISO.
   D    National registration.
   E    Reserved for ISO.
   F    Proprietary non-registered

Con 500$ si può ottenere un codice A (valido a livello internazionale) per la propria organizzazione (forse un codice D costa meno, ma non ci scommetterei). È una spesa necessaria se si vuole vendere il proprio prodotto con la garanzia che nessun altro possa usare (legalmente...) lo stesso ID.
Ma visto che non mi interessa vendere, mi accontento (per ora, in futuro chissà...) di un codice F da scegliere a caso (meglio verificare che non lo stia già utilizzando qualcuno con una ricerchina in rete...).
Sistemata la questione dei 5 byte "assegnati dall'ISO" (e che ci siamo auto-assegnati), rimangono fino a 11 altri byte di PIX. Molto spesso si utilizza il nome dell'applet.
Ottenendo in questo modo il packageID, basta poi aggiungere un byte per avere l'AID. Il byte aggiunto può, per es, identificare la minima major version del protocollo che l'app supporta (così che qualsiasi programma che tenti di usare l'applet possa avere un "minimo comune denominatore"). Ovviamente, se siete abbastanza furbi da utilizzare un protocollo che rimane compatibile con le sue versioni precedenti, questo byte extra rimarrà sempre a 1...

Scelta dei byte CLA/INS da usare

Sarebbe furbo seguire la codifica stabilita dall'ISO. Vedi sezione 5.4.1 (e dintorni). Se ci si vuole inventare completamente il protocollo (completamente proprietario), allora meglio usare CLA tra D0 ed FE che sono, appunto, i codici per indicare i protocolli proprietari.
Analogo discorso per gli INS, facendo riferimento alla sezione 5.4.2.
Ma sarebbe meglio seguire il più possibile lo standard (quando ha senso per l'applicazione che si implementa). Per esempio, se l'applet implementa un filesystem è meglio che accetti i normali comandi invece di crearne di proprietari: sarà così compatibile da subito con tanti tool di "esplorazione" (tipo opensc-explorer). Oltretutto, così potreste trovare librerie già fatte (vedi, p.e. javacardx.framework.File di CDK 2.2.2)...
Da tenerne conto mentre si progetta il protocollo. CardWerk rende disponibile una "vecchia" copia di ISO7816 liberamente consultabile. Manca qualche immagine, ma se proprio serve si può sempre acquistare l'ultima versione dall'ISO!

Compilazione dell'applet

Questo è tutt'altro che banale.
Intanto, è necessario lasciare le info di debug (flag -g), o la conversione fallirà. Molti raccomandano di non attivare l'ottimizzazione del codice, al fine di minimizzarne la dimensione.
Va specificato che il sorgente è Java 1.3 e che il codice generato deve essere compatibile con JVM 1.1 (dovrebbe essere il default per i sorgenti 1.3, ma meglio specificarlo).
Bisogna anche includere nel classpath il file api.jar (o api21.jar) del JCDK (occhio che deve essere una versione supportata dalla vostra card!).

Conversione da .class a .cap

Per questo va utilizzato il converter del JCDK (dovrebbe essere in $JC_HOME/bin/convert).
Il parametro -classdir deve puntare alla directory dove avete compilato i sorgenti dell'app, -d alla buildroot, -exportpath alla dir api_export_files/ del JCDK, per -applet vanno indicati l'AID (in esadecimale, come sequenza di 0xXX separati da ':' ) ed il nome dell'applet. Andranno poi indicati in ordine il nome del package, il package AID e la versione (1.0, e se si prova ad indicarne una diversa serve anche l'export file della versione precedente... prima o poi scoprirò il perché...).

Conclusioni

Con queste informazioni dovrebbe risultare abbastanza chiaro quello "pseudo makefile" già postato.
Lo strumento più indicato per lavorare in Java sarebbe, in realtà, ant. Ma visto che un progetto JavaCard non dovrebbe richiedere tante classi, sia make che ant mi sembrano un tantino overkill... Ma sono pronto a ricredermi