Java Card Technology - allows applets written in Java language to be executed on smart cards JCT provides JSRE (JC Runtime Environment)
CAD accepts Java Card
Selects an applet and sends it a series of commands to execute.Each Applet is identified and selected by its AID(Application Identifier). Commands are formatted and transmitted in the form of APDU. Status Word: Applets reply to each APDU commands as SW. Applets can optionally reply to an APDU command with other data.
For more information about the Java Card Development Kit, refer to the Web site at http://java.sun.com/products/javacard.
The lifetime of a Java CardFor more information about the Java Card Development Kit, refer to the Web site at http://java.sun.com/products/javacard.
Java Card needs to go through initialization and personalization.
Initialization refers to loading general data into a card's non-volatile memory.
This data is identical across a large number of cards and is not specific to an individual; an example might be the issuer or manufacture's name.
Personalization, involves assigning a card to a person.
It can occur through physical personalization or through electronic personalization.
Physical personalization refers to embossing or laser engraving your name and card number on the plastic surface of a card.
Electronic personalization refers to loading personal data into a card's non-volatile memory, for example, your personal key, name, and pin number.
In both, EEPROM (a type of non-volatile memory) is often used for storing data.
At this point, the Java Card is ready for use. You can get a Java Card from an issuer or buy it from a retailer. Cards sold by a retailer are general-purpose, in which case personalization is often omitted.
AID - sequence of bytes between 5 and 16 bytes in length.
National Registered application provider (RID) - 5 bytes - (ISO standard).
Proprietary AI extension(PIX) - 0 to 11 bytes.
When the package, masked in ROM of smart cards, is linked with other packages already loaded in ROM with their own AID.
Methods
deselect() -
install(byte[] barray, short boffset) - to create an instance of the Applet subclass
process(APDU apdu) - to process an incoming APDU command
register() - assign the default AID
register (byte[] bArray, short bOffset, byte bLength)
select()
Actual work of an applet starts after it is instantiated and registered with the JCRE's registry table.
Instantiation and Registration
The applet is instantiated by implementing: install( ) method. The registration of the instance with the JCRE is done by invoking one of the two register( ) methods.
codeprivate Wallet (byte [ ] bArray, short boffset, byte bLength)
{
pin = new OwnerPIN( PIN_TRY_LIMIT, MAX_PIN_SIZE );
// the installation parameters contain the PIN initialization
value pin.update(bArray, boffset, bLength );
register( );
}
public static void install(byte [ ] bArray, short boffset, byte bLength)
{
// create a Wallet applet instance
new Wallet (bArray, boffset, bLength);
} // end of the install method
Applet Selection Procedure: select( ) Method
Until now, an applet on the Java Card is in an inactive stage, until it is explicitly selected. When a JCRE receives a SELECT APDU command, it searches its internal table for the applet whose AID matches the one specified in the command.
If the match is found, the JCRE prepares a new applet to be selected.
This preparation process consist of two steps:
First, if a currently-selected applet is present, the JCRE deselects it by invoking the deselect( ) method.
The new applet performs any initialization necessary before it actually becomes selected
.
.
The applet returns true to the select( ) method if it is now ready to become active and to process subsequent APDU commands.
Otherwise, the applet returns false to decline its participation, and if so, no applet will be selected.
Function of process( ) Method
After this Selection of an applet, the JCRE forwards all the command APDU to the process( ) method (including the SELECT Command).
The process( ) method interprets each APDU command and performs the task specified by the command.
The applet for each APDU command sends the results back to the CAD by sending response APDU.
This command and response dialogue continues until a new applet is SELECTED or the card is removed from CAD.
Code
public boolean select ( ) {
// the applet declines to be selected if the pin is blocked.
If ( pin.getTriesRemaining ( ) == 0 )
return false;
return true;
} // end of select method
public void deselect ( ) {
// reset the pin value
pin.reset ( ) ;
}
public void process(APDU apdu) {
// At this point, only the first header bytes
// [CLA, INS, P1, P2, P3] are available in the APDU buffer.
byte[] buffer = apdu.getBuffer();
// check SELECT APDU command
if ((buffer[ISO7816.OFFSET_CLA] == 0) && (buffer[ISO7816.OFFSET_INS] == (byte)(0xA4)) )
return;
// verify the reset of commands have the correct CLA byte, which specifies the command structure
if (buffer[ISO7816.OFFSET_CLA] != Wallet_CLA)
ISOException.throwIt
(ISO7816.SW_CLA_NOT_SUPPORTED);
switch (buffer[ISO7816.OFFSET_INS]) {
case GET_BALANCE: getBalance(apdu);
return;
case DEBIT: debit(apdu);
default: ISOException.throwIt
(ISO7816.SW_INS_NOT_SUPPORTED);
}
Some Basics About APDU
APDU commands are always a set of pairs.
Each pair contains a Command APDU, a command sent by the application through a CAD, and response APDU, which specifies the result executed by the applet.
SELECT APDU command
Command APDU
Mandatory Header | Optional Body | |||||
CLA | INS | P1 | P2 | Lc | Data field | Le |
0x0 | 0xA4 | 0x04 | 0x0 | 0x08 | 0xF2, 0x34, 0x12, 0x34, 0x56, 0x10, 0x0, 0x1 | N/A |
The command header (CLA, INS, P1, and P2) must be coded as in the above table, so that the JCRE can identify it as a SELECT APDU command. The data field contains the AID of the wallet applet.
The JCRE searches its internal registry table against the AID bytes. If a match is found, the wallet applet is selected.
Response APDU
Optional data Status word Meaning of status word
Optional Body | Mandatory Trailer | ||
Data Fields | SW1 | SW2 | Meaning of status word |
No data | 0x9000 | Successful processing | |
No data | 0x6999 | Applet selection failed: the applet could not be found or selected |
VERIFY APDU command
Command APDU
Mandatory Header | Optional Body | |||||
CLA | INS | P1 | P2 | Lc | Data field | Le |
0xB0 | 0x20 | 0x0 | 0x0 | Length of the PIN data | PIN data | N/A |
* INS byte (0x20) indicates a verify instruction
* P1 and P2 are not used, and are both set to 0
* The data field contains the PIN value
Optional Body | Mandatory Trailer | ||
Data Fields | SW1 | SW2 | Meaning of status word |
No data | 0x9000 | Successful processing | |
No data | 0x6300 | Verification failed |
CREDIT APDU command
Command APDU
Mandatory Header | Optional Body | |||||
CLA | INS | P1 | P2 | Lc | Data field | Le |
0xB0 | 0x30 | 0x0 | 0x0 | 1 | Credit amount | N/A |
Response APDU
Optional Body | Mandatory Trailer | ||
Data Fields | SW1 | SW2 | Meaning of status word |
No data | 0x9000 | Successful processing | |
No data | 0x6301 | PIN verification required | |
No data | 0x6A83 | Invalid credit amount | |
No data | 0x6A84 | Exceed the maximum amount |
DEBIT APDU command
Command APDU
Mandatory Header | Optional Body | |||||
CLA | INS | P1 | P2 | Lc | Data field | Le |
0xB0 | 0x40 | 0x0 | 0x0 | 1 | Debit amount | N/A |
Response APDU
Optional Body | Mandatory Trailer | ||
Data Fields | SW1 | SW2 | Meaning of status word |
No data | 0x9000 | Successful processing | |
No data | 0x6301 | PIN verification required | |
No data | 0x6A83 | Invalid debit amount | |
No data | 0x6A85 | Negative balance |
GET BALANCE APDU command
Command APDU
Mandatory Header | Optional Body | |||||
CLA | INS | P1 | P2 | Lc | Data field | Le |
0xB0 | 0x50 | 0x0 | 0x0 | N/A | N/A | 2 |
Response APDU
Optional Body | Mandatory Trailer | ||
Data Fields | SW1 | SW2 | Meaning of status word |
No data | 0x9000 | Successful processing |
3 comments:
Not to harp on you specifically Mohideen, but that blogspot gives a good example why secure smartcard programming is seriously different then normal coding. For example in the code:
public boolean select ( ) {
// the applet declines to be selected if the pin is blocked.
If ( pin.getTriesRemaining ( ) == 0 )
return false;
return true;
} // end of select method
public void deselect ( ) {
// reset the pin value
pin.reset ( ) ;
}
The first if-statement, on the application select, has a 255/256 chance of being overruled by a perturbation attack on the data of the remaining PIN tries (and similar chances on the code execution). All the attacker then needs to do, is deselect the applet and presto, the PIN tries are reset!
It is these kind of items that make smartcard software development unlike most of the other code development (and serious fun if you have the appropriate wicked mind ;-) ).
in my code i used to set no of tries, suppose if i set no of tries 4, if you type the pin wrongly for 4 times, then it will lock, means program code deleted from the card. So, you have to publish your code inside once again through super admin.
Bell ID's I-PIN solution uses web services and Java applet technology to provide cross browser and cross platform communications to a smart card reader. Currently the product offering is aimed at EMV PIN Change, EMV Scripting, and Post Issuance personalisation, but this technology can be licenced for any general communications with a Smart Card.
See http://www.bellid.com for more information on I-PIN.
Post a Comment