Fix various spelling errors, mostly in comments but also in texts displayed.
Errors found & interactively fixed using 'codespell', with additional manual
checks after the fixes.
* Add minimal CAC1 driver for legacy cards.
It is using the same pkcs15 backend as the CAC2 cards as well as some of
the CAC2 driver methods.
The separation is made mostly for easier card matching or disabling.
This removes code related to the old CAC 1 specification, while
preserving the CAC 2 functionality including CAC Alt token detection
for the tokens without CCC or ACA.
The detection based on SELECT APPLET APDU is improved to require also
the READ BUFFER APDU working, which should fail on misbehaving Java cards.
* Refactor cac_properties_t structure to make its creation more readable
* Avoid manual allocation in cac_get_acr() and clean up bogus pointers
* Avoid bogus comments
* Properly check lengths of retrieved values
Previously, the code handled all the data objects as SimpleTLV,
which caused invalid encoding when we tried to merge TL + V buffers
into single PKCS#15 buffers.
This change is using GET PROPERTIES APDU after applet selection
to explore objects, figure out encoding and check the status of
PKI objects initialization to avoid reading them.
The previous solution was just guessing AIDs of the PKI objects
and trying if they answer.
This solution is inspecting card based on the Service Applet Table
(listing all the applets on the card) and using GET PROPERTIES APDU
listing all the available OIDs of the applet.
This was successfully tested with standard CAC card
(with different ACA AID) and uninitialized HID Alt tokens with empty
certificates slots.
Let sc_get_challenge() do sc_lock() and loop through the card driver's
get_challenge() until enough bytes were collected. The card driver's
get_challenge() now returns the number of bytes collected (less or equal
than requested) or an error code.
- Allow more code re-use.
- PIV driver now uses ASN.1 parser for reading the random bytes
Some "unfriendly" cards return SW 90 00 to any instruction including
the ACA file selection and therefore they are identified as CAC card.
To avoid this, we will try to read the assumed ACA file and we will
mark the card as matched only if we will read something from that file.
We do not parse the content yet.
To avoid infinite loop on "unfriendly" cards, we assume that
read data instruction always returns some data. It it does not,
we can safely assume the file is not there or it is not the card
we are looking for.
Peter Marschall
Frank Morgner
Jakub Jelen
Jakub Jelen