JCOP offcard
I am having problems trying to use JCOP offcard for a terminal application using the SCR331-DI reader on an XP platform. The problem is better described by this snippet:
JCTerminal jcTerminal = JCTerminal.getInstance("pcsc:4", null);
jcTerminal.open();
jcTerminal.waitForCard(5000); // ** THIS NEVER WAITS FOR A CARD **
I go on further and use:
JCard jCard = new JCard(jcTerminal, null, 5000); // **THIS NEVER WAITS EITHER **
What am I missing here? I don't see where any kind of a listener is documented in JCOP offcard. Obviously the blocking version is not working either. The Javadoc for JCTerminal does not give me much clue as to the param values for getInstance(String, String) which is where I suspect the problem might be.
I have dug through and reached the end of the internet looking for the solution. Please help.
Best Regards,
Sami
PS. OpenCard equiv code works fine:
SmartCard.start();
CardRequest cr = new CardRequest(CardRequest.NEWCARD, null, null);
SmartCard sc = SmartCard.waitForCard(cr); // WORKS FINE
[1108 byte] By [
samisamia] at [2007-10-2 4:09:04]
For accessing PC/SC termminals, JCOP uses JPCSC. The source of JPCSC is avialable here:
http://www.linuxnet.com/middle.html
AFAIK PCSCJCTerminal uses one of the two Context.wainforCard(..) function. You could try if they wait for a card if you use them directly without the JCOP offcard framework.
Jan
Thank you JP. I will dig through JPCSC source to see what is going on with JCOP offcard in this case.
In the meantime I got OCF working pretty good. My reasons for trying to get JCOP offcard working have to do with the status of OCF, being that it has been in a state of neglect for the last 5 years.
I have been looking at OCF1.2, JCOP offcard, JACCAL and JSR-268. If you were developing CAD applications TODAY what would you consider using?
Thank you in advance.
Sami
> In the meantime I got OCF working pretty good. My
> reasons for trying to get JCOP offcard working have
> to do with the status of OCF, being that it has been
> in a state of neglect for the last 5 years.
>
> I have been looking at OCF1.2, JCOP offcard, JACCAL
> and JSR-268. If you were developing CAD applications
> TODAY what would you consider using?
I have only only worked with OCF and JCOP. JACCAL came too late for my diploma thesis, so I only checked the API documentation when it came out. At the moment JACCAL looks to me like a OCF-light without the highlevel functions. I dind't check JSR-268 or JSR-177 (the J2ME version).
For my diploma thesis i use JC-RMI, so JCOP was the easiest way to access my card. Before I found out how to list the PC/SC readers via JPCSC, i used the OCFJCTerminal and configured OCF to connect to my PC/SC reader and with the WrapperFactory to connecto to the JCOP emulator.
Now I use the plain JCOP tools with RemoteJCTerminal and PCSCJCTerminal.
IMHO, the only "future-safe" safe framework for accessing cards is your self written one that can use any of these frameworks for accessing a java card.
Jan
Thank you JP. I feel a little more comfortable with OCF since it is open source. I have not verified it but thats what I understand.Best regards,Sami
> I feel a little more comfortable with
> OCF since it is open source. I have not verified it
> but thats what I understand.
The OpenCard Framework has the word open in it's name but I don't think that has anything to to with open source (or where did you get that information?).
It would be nice, indeed to have an Opensource OpenCard Framework, but I think it is only a rumor...
Jan
OCF was intended as an inter-industry standard. However, OCF is dead. There hasn't been any work done on OCF in over 5 years, and the consortium does no longer exist. Why the website is still up is a mistery.
Jaccal is an attempt to create an open-source alternative to OCF. JSR 268 is the official Java way to communicate with smart cards in Java 6.
What we could really do with is an open JPCSC-like Java wrapper for PC/SC -- something that doesn't want to be a can-do-it-all framework. After all, we don't need to do anything more than send simple byte arrays back and forth...
There lies the rub ! With that simplicity, I think using JPCSC-Lite or the PC/SC in Java 6 would suffice. Instead of building Yet Another Framework, why not Extend the JPCSC-Lite or the PC/SC library in Java 6. I would like to see more extensions in the PC/SC library in Java 6. It would be easier to deploy and any low-level issues will be resolved by the implementor(Sun,IBM, BEA, etc). All engineers would need to do is download the extension for the JRE. If another framework is built from scratch, it might require another learning curve that engineers might not be interested in
-.
For Open Sourced projects, I'd rather see real solutions, not just a tool. For example, an Open Source project that integrates your Java Card with your email client for digital signatures/encryption/decryption, or a Open Source Card Management System, or an Open Source plug-in for Firefox that can authenticate your credentials stored on a Java Card to a web service, or how about Open Source Applets that conform to the FIPS 201( http://csrc.nist.gov/publications/nistpubs/800-73/SP800-73-Final.pdf ), or an Open Source project for Java Card login with Linux, etc.
Contact me when these open source projects get underway and I'll be glad to jump in !!!
Just my two cents.
What about an open source Java Card operating system?
That would require us to have access to a card manufacturer OS. Plus that would also have to clear hurdles with Global Platform. Due to security issues, constraints, and profit$, card manufactures aren't going to open up their proprietary card OS !
The closest thing to an open sourced JC would be JCOP IDE. A plug in for Netbeans would be nice and encourages(smile). But you understand it would just be a reference implementation. I'm not saying it not possible, but I doubt any vendor will open their card OS for us to load our implementation on it. Also, it becomes an ownership issue of support. If there's an issue with the card, who supports it ? The Open source community or the card vendor ?
-
I'm open for suggestions and like I stated, I'll be glad to jump into a project that is more framework oriented then another tool. OR (to contradict myself)a tool for .NET cards. Right now only Gemalto is it. Shoot me an email and let's discuss !
> That would require us to have access to a card manufacturer OS.
You could design a Java Card OS in C or some Assembler of a popular micro controller (e.g. ARM).
> Plus that would also have to clear hurdles with Global Platform.
What hurdles?
> Due to security issues, constraints, and profit$, card manufactures aren't
> going to open up their proprietary card OS !
Companies would safe heaps of money spent on development and security. A community project can produce terrific results. So if they adopt this open source OS, in return they would open the card OS. I don't agree that by keeping a card OS secret it is more secure.
> The closest thing to an open sourced JC would be JCOP IDE. A plug in for Netbeans would be nice and
> encourages(smile).
This is one example how a Java Card OS became quite popular. IBM gave the tools, including the simulator, for free. Plus it was embedded in an open source IDE. Anyone could try it out. This gave JCOP the momentum.
>But you understand it would just
> be a reference implementation. I'm not saying it not
> possible, but I doubt any vendor will open their card
> OS for us to load our implementation on it. Also, it
> becomes an ownership issue of support. If there's an
> issue with the card, who supports it ? The Open
> source community or the card vendor ?
I do not see a problem there. Anyone can use Linux, but they do not sue the Linux community for missing support. The card vendor which decides to use the open source Java Card OS has the full responsibility towards the customer. The customer benefits additionally from the community (e.g. forum). The customer can examine the open source for security, and with this transparency the smart card becomes more secure and acceptable. The card manufacturer profits from the increased popularity so more controllers are sold. I get quite upset when companies keep things secret, with all their proprietary features. You can seldom be sure that the security is to my expectations and my applications will really be supported. The open source concept is a plus for everyone.
> -
> I'm open for suggestions and like I stated, I'll be
> glad to jump into a project that is more framework
> oriented then another tool. OR (to contradict
> myself)a tool for .NET cards. Right now only Gemalto
> is it. Shoot me an email and let's discuss !
First, a JC isn't an OS. You need a native OS to run JC. (But I think you already know that)The hurdles are the fact that the card OS is proprietary. No two card manufacturers card OS is the same. Not JC API, but the card vendor OS. It's theirs and it comes from their manufacturing facilities. And no two JC implementations on the card are the same(native-to-VM). They built those OS way before there was a thought of JC. Remember, they don't just do JC, they have a ton of proprietary cards that comply with 7816 and have nothing to do with JC. Also those facilites are very tight. You'll need to undergo a security background investigation to even work with that level of engineering. Why? Because they are doing money on those cards and are trusted with engineering a secure unbreakable platform. That's why you saw Visa Open Platform(later GP) come about. It offered more security to the JC platoform, so they can get greater security and adoption. As far as hurdles, you'll have to work at a vendor to see the restraints Visa places. Trust me, there isn't a vendor on the planet that does Visa cards, going to risk that relationship. Hell, just try to drive up to a plant and you'll see !!! Remember, those cards are about money, money, and more money. They aren't going to open their bread and butter card OS to the open source community so we can engineer a JC for them. There's a reason it's a proprietary card OS ! Because it's their OS to use for other cards. Now why would they want to open that for their competitors and the world to see ? It would be like asking Coke to share their secret formula, or biometric companies to share their algorithms. It's not about the technology, it's about the business.
I hear what you are saying about saving heaps of money, but that's not entirely true in the open sourced community and in some cases, an open source myth. Just making something open&free doesn't automatically reduce cost. Without strong in-house engineers, it could cost more. I've witnessed myself.
Also, JCOP IDE is downright awesome for engineering and testing. When you do a deployment, tell me what card OS are your card manufacturers using. Call GemAlto, Oberthur, G&D and ask.(And by deployment I mean, where a key ceremony is performed, test cards are produced, and production begins on no less than 50,000 cards.)
Your not correct that the JCOP is why JC became so popular. There were and still are plenty of tools out there. JC had momentum before there was a JCOP. I have seen millions of JC issued in phones and national government before JCOP. And when JCOP was out, no one switched. Like I stated, there are a lot of tools out there way before JCOP. I know one company that give away their non-PKI IDE way before JCOP. Don't give IBM credit for pushing JC technology, give it to Sun and Schlumberger(later Axalto, now GemAlto). Yes, JCOP made our engineering easier, but it didn't push the adoption of JC. I still recall doing my JC 2.0 that didn't have CAP formats. I was working a JC deployment for a large bank way before there was a JCOP !
Who, other than a card manufacturer would review your open sourced project ? Also, name one customer that cares if the JC implemented on the card is from the Open Source community or not ? I understand your anger, but the reality of card manufacturing is just as I pointed out. Again, I'm not saying you won't get any interests, but why haven't there been an Open Sourced JC by now ? Unfortunately Open Source doesn't fit into all technologies. It's the nature of the business, and not technology.
I know I sound like a broken record, but take your focus away from engineering and move it towards deployment. Engineering is locked up. Look at the .NET card. It came from a card vendor, Axalto(later GemAlto). There's room for standards, and GP even became standardized in ISO-7816. There's room for post-production applets see the FIPS-201 specifications. There is plenty of room for deployment tools, like for the .NET and a NetBeans environment. But for deployments, there could be a market for an open sourced Card Management System(CMS) or a framework that can fit into a CMS. (Now even MSFT has gotten in the CMS game with their Identity Lifecycle Manager(ILM) )
-
The funny thing about all that I said, is that the next generation JC will contain a little Open Source in it !!!
Maybe the card vendors have different implementations, but of one I know where JC VM and RE is written in assembler, so there is no underlying smart card OS. The only secret thing is the assembler instruction set. So compared to Java on e.g. a x86 or Sparc, there is the OS layer missing. This is why I say that Java Card is an OS.
Your next argument about the proprietary cards is true, but .. The Java Card technology increases its market share year after year. People understand that in long term proprietary solutions are the wrong way. Just to change some of the functionality you need to change the OS and create a new mask. With JC you just re-load the applet.
My vision is to write an open source Java Card OS in C and assembler, leaving out the HAL. If a card manufacturer is interested, they need to open their micro controller architecture or provide an API. For reference, one could implement it first on e.g. ARM.
Customers want a system solution. This means to provide everything for application development. I have some experience with different tools, and JCOP tools beat them all. You do not need to use JCOP for it, as long as the OS is JC and GP compliant it works. If you check out what market share JCOP has in banking and eGovernment you see that customers switched to JCOP or chose it from the beginning.
With a good open source project you need governance. This is the standard process of review. Eclipse claims to be the most successful project. They have superb governance setup. I know a couple customers I worked with who would have liked to understand the internals and security features of the JC implementation. This would have included a look into the code.
You are correct with your argument that the lack of an open source JC OS has its reasons. I am questioning this reasons and even think that it will become a problem for this technology in near future. JC won't use the full potential it has. As long as the smart card is dominated by proprietary and closed JC solutions, you will always encounter problems in deployment. The unifying factor is missing.
Now I think I understand your angle. Something like what the Sun RI is right ? Then how about a Open Source Card OS RI that can support JC and .NET ? Shoot me an email and lets discuss !!!! I"m all for that !
I have customers that want to understand the security aspects of a JC, and I just refer to the firewall protection, key generation, Java Crypto subset, and algorithms. When they want to understand security that involves deployment, I refer to Global Platform and the key ceremonies, CMS, cert authorities, etc. I never had one client ask about the internals and what the card OS is.
I think once you see the next generation JC you'll see JC adoption increase due to the ease of engineering, testing/debugging, and deployment. But as with most new/cutting edge technology, there needs to be a market driven use case for it.
Yeah something like the Sun RI, but including the security, performance abd content management aspect. A user shall be able to load it onto a micro controller, pack it into a smart card form factor and have security device. Of course it would not pass any certification, but if card manufacturers will get interested they could provide a secure HW platform.
I do not know if I am keen on .NET card. What added value would it have?
I got a pretty good impression from JavaOne that the next generation Java Card hits the nail on the head. Finally we will get rid off all the smart card specific issues. With the Servlet model combined with TCP/IP the killer App is about to come.
do not know if I am keen on .NET card. What added value would it have? That was the same thing I heard when JC came out !!!!
It's offers solid integration into .NET framework, uses CLI, already a part of Visual Studio, remoting, on-card timer, int-64, filesystem, role-based access, XML parser
I have to get the kit to see how "worthy" it is of my time. But the timer, file system, RBAC, and XML parser has caught my attention.I'd like to see how friendly Studio is with smart cards, not just .NET cards. Also, see if the Mono project has .NET card in it.
Why you ask ? Because MSFT die-hards who never jumped on JC or smart cards for that matter, will swear by .NET cards and will need help !!! Like I stated earlier, MSFT bought a CMS from Alacris and turned it into Identity Lifecycle Manager(ILM). Plug in the Certificate Lifecycle Manager(CLM), and I see smart card talents like yourself and I getting calls ....
I read through the Gemalto brochures on the .NET card and the corresponding kit. Sorry Joseph, but this sounds to me like the same story as with Java and C#. The points listed are an exact copy of the Java Card concept. Name me one thing that is an innovation compared to JC. Furthermore this solution only targets the Identity Management. Can I write my own smart card applications? Is there an open .NET smart card application specification? If there is a way to get a trial version of this .NET smart card kit I will look into it. And as you mentioned, it has not to be only Windows dependant (Mono support ...).
I pointed out the differences between JC and .NET in my previous post. Of course C# is similar to Java. That's old news. Yes, the architecture is the same as JC and it should be considering it's a virtual machine like JC. One major plus is with that .NET filesystem, I can now support PKCS#15, I can't do that with JC unless I want to engineer a filesystem applet. Another is a clock. I can require certain checks to be done based on that timer.
Your right, about identity manager. One of the major uses of smart cards,(outside of mobile devices) whether JC or proprietary is Identity Management. That's all I've been doing for the last 5 years !( Take a look at FIPS 201 !) It's a token used for access, physical and logical. It's a token that has credentials stored for data security, like email signing and encryption. It secures your biometric to unlock instead of a PIN. Like I've stated before, that's what I would like to see as an Open Source CMS.That CMS will be plugged into an IDM solution.
This is MSFT driven, nothing is "trial" version with them ! Now, why do you think you can't engineer your own applets on it ? Isn't that what the purpose of the kit is ?(okay, that was a smart *** comment, sorry) WIth the kit, you'll engineer applets, and load them on the card. With .NET Studio and hopefully Mono, you may also, test and debug.
I don't understand your anger towards .NET. Or maybe I'm just reading it wrong. You need to realize this isn't a replacement of JC or a JC vs. .NET cards. I heard all these same arguments when JC was coming out. Everyone agreed, "Cool", but "Who cares", "It won't succeed", etc....NET card is just another card platform that is angled towards MSFT loyalist. There's no harm in adding a .NET card to the multiple card platforms already in the market. JC isn't the perfect solution to every need and neither is .NET. However, I believe these two are going to be the leaders and help drive down the cost of cards.
OK, I seem to understand your point now. Sorry for my ignorance, but I started out with a couple proprietary smart card OSs and switched to JC. I was never keen on C# because I had to pay money before I even had a solution. Sun's approach with Java and Solaris was more appealing. Contrary to you I worked in the other major areas of smart card implementations: eBanking and eTicketing. Identity Management is new to me.
From your post I collect the following enhancements
- Windows support
- Microsoft Visual Studio Development
- Timer, file system, int-64, RBAC and XML parser
The beta kit is average priced (299$) including the SDK, a PC/SC reader and 4 .NET smart cards. I will give it a try and come back with my trial experience.
Hi Lexdabear and Josef!Can anyone of you explain in a few words concept of Multos cards? Do you have some experience with them?
Multos is a multiapplication card OS. It is an interpreted language like Java Card. Check out the Multos website. There are some nice tutorials. The main difference between Multos and Java Card is the market acceptance.
