Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support Cipher.OneShot operations #62

Open
dmercer-google opened this issue Jul 26, 2023 · 1 comment
Open

Feature Request: Support Cipher.OneShot operations #62

dmercer-google opened this issue Jul 26, 2023 · 1 comment

Comments

@dmercer-google
Copy link
Collaborator

JC 3.0.5 introduced Cipher.OneShot operations.

Our experience with OneShot signatures indicates a significant performance boost (40ms+ ???, I don't remember the exact number) when using ECDSA P-256 on one of the chips we target. While 40ms may not seem like much, it does make a difference when using CAK Auth to open doors. We have found that the 40ms reduction in time to open the door has changes the door UX from being a noticeable lag to it being unnoticeable. I guess that that is some human perception threshold thing?

In addition, OneShot operations may improve memory utilization because of the way state is maintained. We have no data on this but logic would suggest that this is the case.

This will require compiling different source depending on support for OneShot operations on the card and a build that supports pulling different source depending on various factors (e.g. JC version, chip being targeted, etc.). We have decided that the added build complexity is worth the performance gain.

To make things a bit more complex: I could be wrong but I seem to remember reading that full support for OneShot ciphers may be optional in JC 3.0.5. That would mean that the build would not only have to take into account the JC version being built but also the particular chip being targeted. One of the chips we target is JC 3.0.5 and compilation with OneShot works just fine. However, trying to execute operations on said throw because the chip manufacturer has not implemented OneShot ciphers.

@makinako
Copy link
Owner

makinako commented Aug 1, 2023

This has been implemented for the upcoming v2.0.0 FIPS version in the form of basic platform abstraction.
To summarise, there is a PIVPlatform class created for each supported platform and this lets you implement JCRE and platform-specific enhancements without adulterating the rest of the code base. This means there will be a CAP file built for each platform.

So far, the platforms are:

  • JCRE304
  • JCRE305
  • NXPP71D600
  • NXPP60SECID
    We should even be able to put JCRE222 in fairly easy after this, allowing support for older cards (albeit losing ECC crypto and reselectingApplet support).

Regarding the optional support for OneShot as you mentioned, it is possible to add additional platforms, but we could also enhance the JCRE305 class to try one-shot first, then if it causes an exception just instantiate a normal instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants