serving the solutions day and night

Pages

Wednesday, April 7, 2010

Smart Card Java Card Technology

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 Card
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.

RID - 0xf2, 0x34, 0x12, 0x34, 0x56.

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.
code
private 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 HeaderOptional Body
CLAINSP1P2 LcData fieldLe
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 BodyMandatory Trailer
Data FieldsSW1SW2Meaning of status word
No data 0x9000Successful processing
No data 0x6999 Applet selection failed: the applet could not be found or selected

VERIFY APDU command
Command APDU
Mandatory HeaderOptional Body
CLAINSP1P2 LcData fieldLe
0xB0 0x20 0x0 0x0 Length of the PIN data PIN data N/A
* CLA byte denotes the structure of the command
* 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 BodyMandatory Trailer
Data FieldsSW1SW2Meaning of status word
No data 0x9000Successful processing
No data 0x6300 Verification failed

CREDIT APDU command
Command APDU
Mandatory HeaderOptional Body
CLAINSP1P2 LcData fieldLe
0xB0 0x30 0x0 0x0 1Credit amount N/A
* The data field contains the credit amount

Response APDU
Optional BodyMandatory Trailer
Data FieldsSW1SW2Meaning of status word
No data 0x9000Successful 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 HeaderOptional Body
CLAINSP1P2 LcData fieldLe
0xB0 0x40 0x0 0x0 1Debit amountN/A
* The data field contains the debit amount

Response APDU
Optional BodyMandatory Trailer
Data FieldsSW1SW2Meaning of status word
No data 0x9000Successful 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                                                                 
CLAINSP1P2 LcData fieldLe
0xB0 0x50 0x0 0x0 N/AN/A2
* The data field contains the balance amount

Response APDU
Optional BodyMandatory Trailer                                                                
Data FieldsSW1SW2Meaning of status word
No data 0x9000Successful processing

4 comments:

Wouter Slegers said...

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 ;-) ).

Daynight said...

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.

Wynand Vermeulen said...

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.

Indli said...

Your blog is cool. To gain more visitors to your blog submit your posts at indli.com