How is the architecture of chip on JCOP 30?
Hi everyone,
I have some questions about JCOP 30 dual interface smart card(Contact and Contactless,Mifare 1K...4k),I would like to know How is the architecture of JCOP card ,IS there two chips on the card or not?How is the memory map in this card (EEPROM,..).
How can Applets work with contact or contactless mode? I need some documents about programming with contactless card .
Please inform me if any one knows.
yours sincerely,
Orchid
[474 byte] By [
NewOrchida] at [2007-11-27 1:17:35]
# 1
A dual interface card has one CPU, with two different communication interfaces (transport layer and below). You can use only one interface at a time. The application layer is independent of the lower layers. You can figure out in your applet what protocol is used atm (see Java Card API --> APDU.getProtocol()).
You should not care what protocol is used. The OS handles the communication for you.
The JCOP architecture is not open.
# 2
There is an interesting security issue: sometimes it is not desirable to allow execution of some APDU commands when communication protocol is contactless. It may be, for instance, authentication command that could possibly allow somebody to block the PIN or to lock the card.
# 3
Why is this a security issue? You think about a eavesdrop attack? You can listen on a wire as well. Furthermore the authentication command relies on session keys --> the strength of security lies in the secrecy of the key and the strength of the algorithm.
I do not see any security issue when the communication is done via the contactless protocol. Take care of the security on application level.
# 4
Lexdabear, you have more experience than I do...
Please, can you tell me if the following situation is possible? If there is an applet featuring VERIFY APDU command and it is installed on a contactless smartcard, can somebody, using "strong" smart card readers block pins of card holders in a 20 meter round area? It would be a kind of "denial of service" attack. I am sorry if my question is senseless...
If true, it would have sense to reject processing this APDU command if protocol is contactless.
Thank you in advance!
Aleksandar
# 5
If you know how an applet is functioning (an open specification, e.g. EMV) you could theoretically try an attack by issuing APDUs, which after a limited tries, lock or terminate the applet/card. To prevent this one will add a secure channel protocol before any processing starts.
Example:
CAD --> SELECT app --> ICC
ICC --> ok --> CAD
CAD --> INIT UPDATE > app --> GP: processSecurity(INIT UPDATE) --> ISD/SSD (puts the response into the global buffer)
ISD/SSD --> number of bytes --> app --> setOutgoingAndSend() --> CAD
CAD --> EXTERNAL AUTH, MAC + ENC--> app --> processSecurity(EXT AUTH) --> ISD/SSD
ISD/SSD --> number of bytes --> app --> getSecurityLevel() --> ISD/SSD --> security level --> app (OK?) .. --> CAD
if setting up a secure channel is successful
CAD --> VERIFY APDU --> app --> unwrap(VERIFY APDU) --> ISD/SSD --> app --> ...
VERIFY APDU is secured with MAC and encryption. So if the protection is not valid, there is a security incident and the application will abort, without calling the method to verify the PIN. This way the 'denial of service attack' should not be possible.
