You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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 withOneShot
works just fine. However, trying to execute operations on said throw because the chip manufacturer has not implementedOneShot
ciphers.The text was updated successfully, but these errors were encountered: