CLA= 0x7E in APDU command

[trgorce]

Our clients want to use CLA= 0x7E in APDU command. However, when I use javax.smartcardio to send an APDU command with CLA = 0x7E, the CLA my Java Card receives is 0x3C. Does this CLA 0x7E have something wrong? I always thought that the problem is caused by this CLA byte. But I can not point out the reason. Hope anyone can help. Thanks a lot.

[popmun09]

I'm curious. How do you know the CLA bytes that card receive is 0x3C?

[trgorce]

I'm curious. How do you know the CLA bytes that card receive is 0x3C?

I grabbed the data by Bus Hound. Bus Hound is a tool that can fetch the data from USB driver on PC.

[popmun09]

Why must your customer use 0x7E as CLA byte? You may try to communicate with them and use CLA=0x80 or 0x00.

[trgorce]

Why must your customer use 0x7E as CLA byte? You may try to communicate with them and use CLA=0x80 or 0x00.

Changing CLA to 0x80 or 0x00 can work. But our customer has required the CLA byte, if I want to change it, I need to find the problem and explain to them. Do you know the where is the problem?

[popmun09]

0x7E isn't a valid CLA.

The CLA value 0x7E is reserved for inter-industry use. CLA=7E contains relevant bits 0111xxxxb, where x can be 0 or 1. It indicate that both secure messaging and command chaining will be used. Maybe javax.smartcardio detects this CLA value and automatically starts a secure messaging session and so CLA is changed to others, I guess.

[trgorce]

I am greatly appreciated for your useful info. I have contacted our customer and wait for the news. Thanks.