Simulate and test Open Source Java Card Applets

[frankmorgner]

Compiles jCardSim, IsoApplet, GidsApplet, ykneo-openpgp, PivApplet as described here. Thanks to https://github.com/arekinath/jcardsim/ this is now also possible on Linux in combination with https://github.com/frankmorgner/vsmartcard. @OpenSC/maintainers

Unfortunately, I'm not very fluent in personalizing most of the Java Card Applets, so I'm hoping that @vletoux, @arekinath, @philipWendland could maybe add some more details and corner cases that should be added for the applets. Testing special PIV's special cases should also be interesting for @mouse07410 and @dengert. I think @Jakuje also has a link to some CAC applet code that could be integrated.

Finally, Travis-CI now also runs some basic PKCS#11-tests, but adding p11tests to the automation would be better. If extend this testing, I hope we can achieve shorter release cycles...

This commit also adds caching of apt, brew and maven packages as well as the OpenSSL/OpenPACE build on macOS.

[Jakuje]

Good job! I certainly plan to have a look into this to continue the work with either coolkey applet (should be easy to adapt, but I will need to figure out the initialization) and/or libcacard (that is not actually the java applet, but c emulation).

For this PR, I have only few comments/proposals:

• would it be possible to provide the initialization of the applets as a shell scripts rather than the lengthy yaml so it is easy to run it locally? Ideally to be able to run it as simply as make check before pushing the changes (maybe with environment variable DO_SIMULATION).
• I noticed the following output:

YubiKey serial number 0 is affected by vulnerability CVE-2017-15361 (ROCA) and should be replaced. On-chip key generation was permitted by default, but is not recommended.  The default behavior will change in a future Yubico release.  See YSA-2017-01 <https://www.yubico.com/support/security-advisories/ysa-2017-01/> for additional information on device replacement and mitigation assistance.

would it make sense to modify the applet build to give it some different serial number so it does not complain here?

• I see you are installing the yubico-piv-tool. The piv-tool that is part of the OpenSC does not know the things how to initialize the applet and load the keys if I remember well. But would it make sense to extend the PIV tool here (or test at least something with piv-tool?) since we actually do not use yubico piv applet but different PivApplet (which is probably to some extent compatible with the yubico piv applet).

[frankmorgner]

• Yes, a script could just be copy/pasted from the YAML script. However, there are a lot of assumptions about the environment and many steps involved that need to be done initially, others regularly so I didn't figure that the given steps above would be usable on too many platforms. Maybe you could integrate the simulation in some of your pipelines and create a generalized script in the process.
• Maybe Alex can clearify how to set a serial number for his applet to avoid the ROCA warning
• Personalizing PIV applets with piv-tool/PKCS#11 and similar has been discussed earlier and I think the Doug wasn't interested in maintaining vendor specific personalization.

[vletoux]

Excellent idea !
From the GIDS applet point of view, the card should support everything:

• change PIN (and support error handling on unsupported pin change)
• generate RSA 1024 / 2048 keys
• import certificate
• import pfx file
• sign / decrypt
• remove key
  The only dedicated operation is the PIN unblock using the admin key performed by the gids tool

[frankmorgner]

I hoped that the GIDS applet would be that potent. The only problem is that I don't know the exact scriptable commands to do all this.

[dengert]

In regards to: "Doug wasn't interested in maintaining vendor specific personalization." That is true.

There is no standard PIV applet. Each card vendor writes their own applet. NIST will test and approve cards that past the NIST accreditation process. NIST left up to each vendor on how to do the installation and personalization to give them a competitive edge in the market. The NIST approved vendors do no publish their source code. They sell their cards with their PIV applet already installed. They provide information on how to personalize them but this is via NDAs.

Thus trying to "maintaining vendor specific personalization" would in most cases violate nondisclosure agreements.

Many of the non approved PIV applets were written so they could use the builtin Windows PIV driver without any other middle ware. Vendors such as Yubico, PIVCard and MyEID provide their own tools to do personalization and some of them only run on Windows.

The piv-tool can do some personalization using the '9B' admin key with PUT DATA and GENERATE KEY PAIR. This key is optional in the NIST standards but was just enough for testing cards.

There are many objects on a PIV card that are not normally needed. The CHUID is needed because the the Windows builtin driver expects it. (The OpenSC driver will use it if present to generate a serial number.)

As far as I can tell, all the open source PIV applets have not been tested or approved by NIST and have missing or buggy implementations. Especially in the handling of SELECT AID and the VERIFY Lc=0 cases.
Many of them do not fully implement ECDSA and ECDH.

As a side note: The piv-tool when reading or writing objects considers the "53" BER-TLV to be part of the object. (i.e. the object is what is read or written by the GET_DATA "CB" or PUT_DATA "DB" APDUs). The yubico-tool adds or removes the outer "53" BER-TLV. The piv-tool can write certificates. It puts them into a certificate object and if requested gzip them.

[arekinath]

• I noticed the following output:

YubiKey serial number 0 is affected by vulnerability CVE-2017-15361 (ROCA) and should be replaced. On-chip key generation was permitted by default, but is not recommended.  The default behavior will change in a future Yubico release.  See YSA-2017-01 <https://www.yubico.com/support/security-advisories/ysa-2017-01/> for additional information on device replacement and mitigation assistance.

would it make sense to modify the applet build to give it some different serial number so it does not complain here?

Yes, it would. Currently PivApplet implements the proprietary YubicoPIV command to get the applet version number, and returns 4.0.0 always. It seems like at https://github.com/Yubico/yubico-piv-tool/blob/master/lib/util.c#L736 they look for <4.3.5 in that field to print that message, so stopping that output should be an easy fix. I've filed this as arekinath/PivApplet#14 and also another issue for the 0 serial number as arekinath/PivApplet#15

Regarding personalization, as well as the yubico-piv-tool, the PivApplet should work with the OpenSC piv-tool well enough to generate keys -- I've used e.g. piv-tool -A M:9b:03 -G 9e:06 and piv-tool -A M:9b:03 -C 9e etc successfully. It might be preferable to use that for personalizing it here for the purpose of these tests since it'll be self-contained to the OpenSC tools? PivApplet generates a default basic CHUID file at installation, so you don't necessarily need to write a new one if it's just for testing -- you can just generate keys right away.

[frankmorgner]

feel free to extend the script file (.travis.yml) or to add a new test script (for your card) in tests.