are you referring to threading or the contactless having the same capabilites as a contact ?
There are cards called Hybrid. Those cards contain contact&contactless chips. The contactless chips are "wired" to the contact chip to utilize the same features, memory, firewalls, etc found on the contact.
Actually it is one micro controller with two different interfaces. Upon the interface detection (signal on contact? signal on ct'less? ...) the OS decides which interface to choose. As for JCOP/NXP I did some tests. First it checks for ct'less, then, if not present, it checks the contact interface. Once the activation sequence is successful (resulting in an ATR/ATS at the end), JCOP sticks with the interface until the next reset.
Message was edited by:
lexdabear
JCOP/NXP: Once the activation sequence passes, the interface is fixed until next reset. So you cannot connect at the same time with the contactless interface. The contactless part is specified in the new PC/SC specification. The ATS is parsed into an ATR.
According to the Java Card specification, there is no way to reset a card from within an applet.
What are you trying to achieve? If you want to avoid contactless communication, there are methods to check the interface used. Check out javacard.framework.APDU.getProtocol()
A smart card solution relies heavily on standards. I do not see any possibility to change the interface "on the fly" without violating ISO7816-3 or ISO14443-3/4 standard. What you could do is build a system where the off-card side (terminal, back end system) issues a reset in case a certain APDU is received from the card. A reset comes always from the off-card side.
I still don't understand. What we are trying to tell you is that with hybrid cards, you have two interfaces using the same memory space. In other words, two doors to the same house. Regardless of how you entered, you are able to utilize the same JC features. Based on what you stated as your use-case, you are using different readers at different times. When you resend your data to a CL reader, you are removing the card from the USB/contact reader. ( I don't know of a hybrid reader that reads BOTH at the same time ).
> Same here, would like hear about. push further any
> case for tri-interface ( contact, contactless, usb)?
> any case for virgin card (pre-perso), switch T0/T1,
> Type A/Type B , speed on field instead of factory
> (with NXP Permission, of cause)?
I guess there is no big business case for this kind of request. Otherwise companies would drive this option in the standardization organizations.
If you're a NXP customer you should know that to a certain point there is a way to change the settings. Again, if you have a good business case, contact a smart card OS provider with your requirement. There is always the possibility to implement something proprietary. The question is if you're OK to be not compliant anymore.
> A card which acts like a proxy.... having main
> connection on contact interface and resending all
> data forth and back via contactless to some other
> device
The only possibility I see is to store the history of the communication history with the contact reader in your applet and when the card is activated contactless, resend the history once the applet is selected.
As Joseph.Smith pointed out the the smart card architecture does not allow your use case. The biggest problem would be the security aspect.