Using "standard" javax.smartcardio

[Martin Paljak]

Hello,

I wanted to give JavaEMVReader (JER) a try, but as I'm running on OSX (10.9.1) with the latest OpenJDK1.7, smart card access via javax.smartcardio bundled with the JDK is broken.

So I tried to fix it by replacing the SunPCSC provider in java.security with the jnasmartcardio (can be found on Github) but still the coredump.

After looking into the code that deals with smartcardio I was just left wondering, why all that trickery with reflection etc?

Thanks,

Martin

[sasc]

Hi,

i have not been able to test JER on osx, but if jnasmartcardio should work on osx, then you should be able to use that (in theory).

The reason for using reflection was that javax.smartcardio is not part of the standard JavaSE api (eventhough its in the sun/oracle distribution, and now, in OpenJDK). The JavaSE implementations were more fragmented a few years back, with gnu classpath, apache harmony (ibm) etc, and there was no guarantee that these distributions would implement smartcardio.

Also, by using reflection, you could use the binary on Android, without having to remove the classes that use smartcardio.

If you manage to get a solution working on osx, please let me know, and i can put the documentation on the wiki page if you like.

Thomas

[Martin Paljak]

Hola,

On Friday, 17 January 2014 15:42:00 UTC, sasc wrote:

Hi,

i have not been able to test JER on osx, but if jnasmartcardio should work on osx, then you should be able to use that (in theory).

Yes, the *theory* is that by replacing the provider (or adding it) code that is using "TerminalFactory.getDefault()" (or getInstance "PC/SC") would give me a working JER. 

That's the point and spirit of javax.smartcardio, at least. But it does not work.

 

The reason for using reflection was that javax.smartcardio is not part of the standard JavaSE api (eventhough its in the sun/oracle distribution, and now, in OpenJDK). The JavaSE implementations were more fragmented a few years back, with gnu classpath, apache harmony (ibm) etc, and there was no guarantee that these distributions would implement smartcardio.

Sure, but that's probably a very small percentage of possible users. There will always be people using "esoteric solutions".

Also, by using reflection, you could use the binary on Android, without having to remove the classes that use smartcardio.

As javax.smartcardio is the only abstraction that would allow to write portable code. See http://stackoverflow.com/a/15110077/44289

 

If you manage to get a solution working on osx, please let me know, and i can put the documentation on the wiki page if you like.

My only solution would be getting rid of all the reflection thing and excess code, but I solved my curiosity by running it on Linux. I don't know the codebase nor do I want to perform chainsaw-surgery on it.

Cheers,

Martin

[sasc]

Hi again,

>Yes, the *theory* is that by replacing the provider (or adding it) code
>
>that is using "TerminalFactory.getDefault()" (or getInstance "PC/SC")
>would
>give me a working JER.
>That's the point and spirit of javax.smartcardio, at least. But it does
>not
>work.

Can you easily see if it coredumps due to the openjdk impl still being loaded, or if its jnasmartcardio that crashes?

>As javax.smartcardio is the only abstraction that would allow to write
>portable code. See http://stackoverflow.com/a/15110077/44289

I would like to see scio on android, but i dont think we'll get that in standard android anytime soon. I have an experimental scio impl with ccid driver working on android, but it currently only works in a local process. I would like to expose it as an IPC service, but i have to figure out how to handle releasing remote resources ("distributed gc") first. I can see that seek4android is doing it, so I'll investigate that if i get the time.

>My only solution would be getting rid of all the reflection thing and
>excess code,

The reflection part can probably be removed now. It was implemented back in 2008.. And the classes using scio can be removed with a maven plugin. (Until we get scio on android).

Cheers
Thomas

[Martin Paljak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/01/14 18:41 , sasc wrote:
> Hi again,
>
>> Yes, the *theory* is that by replacing the provider (or adding
>> it) code
>>
>> that is using "TerminalFactory.getDefault()" (or getInstance
>> "PC/SC") would give me a working JER. That's the point and spirit
>> of javax.smartcardio, at least. But it does not work.
>
> Can you easily see if it coredumps due to the openjdk impl still
> being loaded, or if its jnasmartcardio that crashes?

It is still OpenJDK that coredumps but what I meant by "this does not
work" is that I can't replace the sunpcsc provider by replacing the
provider in java.security (your code is bypassing the provider inetrface)

>
>> As javax.smartcardio is the only abstraction that would allow to
>> write portable code. See
>> http://stackoverflow.com/a/15110077/44289
>
> I would like to see scio on android, but i dont think we'll get
> that in standard android anytime soon. I have an experimental scio
> impl with ccid driver working on android, but it currently only
> works in a local process. I would like to expose it as an IPC
> service, but i have to figure out how to handle releasing remote
> resources ("distributed gc") first. I can see that seek4android is
> doing it, so I'll investigate that if i get the time.

Well, I would like to use other code I have that makes use of
javax.smartcardio to talk to cards over NFC.

Having CCID on Android is also interesting, but I don't have any
hardware that would "look sensible" with something with USB attached
for such purposes.

>
>> My only solution would be getting rid of all the reflection thing
>> and excess code,
>
> The reflection part can probably be removed now. It was implemented
> back in 2008.. And the classes using scio can be removed with a
> maven plugin. (Until we get scio on android).

I don't speak maven :)

But I can test it on OSX once that "normal" javax.smartcardio
reference can be used.


- --
Martin
+372 515 6495
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJS2X+fAAoJEKzwIt3aPjKjyxAIAJSd5lTqQl80TYJEJnFY5OC3
psRTEuxCkmYaHixpq8iwE6qZP8YRR/3Vxh5YjsEqt+SXy1mBF5Wyo4Saz627klkZ
tMSlFYOQibgZQ0Y4FZPDqSnAGePSgLd5oq3bdPCut2z64UqR/BH5bIyw9NxeG12t
CKu2LycRJeQOkZTV7AblDTZXogN3qMincCUJzgpv5aYqMIKmGqq8gH71fWo8ipqo
QKV3yG0W2yD9SAZHqEFDSQhOlm4mxbXu/ES7wkSGl839OHwJk6XlxuT/Ti38Rro4
p88/2xnq+ydseHiPjjn/0I/hZyyb7KZMFr+3Pvezgpq3LRYmP4tnqgCiLGvndfw=
=0cqr
-----END PGP SIGNATURE-----

[Martin Paljak]

On 17/01/14 18:41 , sasc wrote:

> Hi again,
>
>> Yes, the *theory* is that by replacing the provider (or adding
>> it) code
>>
>> that is using "TerminalFactory.getDefault()" (or getInstance
>> "PC/SC") would give me a working JER. That's the point and spirit
>> of javax.smartcardio, at least. But it does not work.
>
> Can you easily see if it coredumps due to the openjdk impl still
> being loaded, or if its jnasmartcardio that crashes?

Well, trying again in the morning, everything works on OSX as well,
for whatever reason it failed yesterday. JNA PC/SC version is loaded,
works without problems, doesn't crash.

The crash I got yesterday was jn pcsc_multi2jstring, which should be
OpenJDK-s implementation.

"Have you tried turning it off and on again" is a golden rule...