* consistently use term "Invalid key ID; must be 1, 2, or 3" in error messages
about invalid key IDs instead of various alternatives.
* use error type SC_ERROR_INVALID_ARGUMENTS instead of SC_ERROR_INVALID_DATA
when the key_id was passed to the respective function
* harmonize the checks to consistently use 'key_id < ... || key_id > ...'
In addition, initialize a variable to keep clang & compilers on OSX happy.
Combine sequences
sc_log(..., "...");
LOG_FUNC_RETURN(...);
where c_log() prints a constant string
by
LOG_TEST_RET(..., "...");
This change results in shorter, more concise code as well as
better harmonized error messages.
Don't terminate the messages with a period, because they are going to end up
as the first argument to a format string of the form "%s: ...".
I.e. they will be part of a longer string and terminated by a colon anyway.
When card->sm_ctx.ops.free_sm_apdu gets called in sc_sm_single_transmit
with a prior transmission error, then `sm_encrypt` still tries to
decrypt the response and hence, accesses the previously uninitialized
`resp`.
Use defined symbolic names for well-known DOs to copy data to a correctly
defined buffer 'apdu_data' using ulong2bebytes() instead of relying on
"magic" constants and C's string semantic.
Also use 'sizeof(apdu_data)' instead of additional magic constants.
Use defined symbolic names for well-known DOs to copy data to a correctly
defined buffer 'data' using ulong2bebytes() instead of relying on
"magic" constants and C's string semantic.
Also use 'sizeof(data)' instead of strange strlen() calculations.
Use defined symbolic names for well-known DOs to copy data to a correctly
defined buffer 'data' using ulong2bebytes() instead of relying on
"magic" constants.
Random data from PIV card is obtained using GENERAL AUTHENTICATE command
for a request of a Challenge from the card. "00 87 00 9B 04 7C 02 81 00"
Usually 8 bytes are returned.
NIST 800-73-3_PART2, "A.1 Authentication of the PIV Card Application Administrator"
"Table 11. Authentication of PIV Card Application Administrator" shows an example of
how to do this.
Some cards (one I have: 3b:7d:96:00:00:80:31:80:65:b0:83:11:17:d6:83:00:90:00)
will not allow 2 of these commands in a row. (Maybe assuming command is only
used as in Table 11 and is expecting the second command.)
Code was added to card-piv.c so if "6A 80" is returned, try the command one more time.
For any other GENERAL AUTHENTICATE failure, SC_ERROR_NOT_SUPPORTED is returned.
piv_get_challenge may be called within a loop from sc_get_challenge if more random
data is needed thus causing the the 2 commands to sent in a row.
On branch piv-improved-matching
Changes to be committed:
modified: card-piv.c
Not all PIV applets are the same. Different versions of NIST 800-73 and improperly implemented
or not implemented required features of NIST 800-73 cases problems. Have a look at the card_issues
listed in card-piv.c. The PIV driver has tried to detect the differences based on clues found in
the ATR historical bytes and vendor version numbers for some cards.
At the same time it has tried to support the possibility there are multiple applets
on a card that the user may want to use at the same time from different applications.
This has lead to some detection problems with Dual CAC/PIV cards. The same cards
sold by the vendor may have only a PIV applet that may not be the same PIV applet that
is on the Dual PIV/CAC cards.
http://www.cac.mil/Portals/53/Documents/CAC-utilziation-and-variation-matrix-v2.03-20May2016.doc
defines a number of official CAC cards in active service. A table of the ATRs for these is now used
to detect these cards. The PIV version of the CCC is also read to see if any CAC PKI objects
are defined in the CCC, indicating it is a Dual CAC/PIV, even if the ATR is not listed.
A more conservative approach to try and handle multiple applets on a card is used. Based
on issues with the implementation of the PIV applet this may not be possible to do.
So for many cards no additional detection will be done at the start of every transaction,
and the login state can not be detected correctly.
ATRs for PIVKEY are also in the match table, as these cards have a log of issues.
Other PIV cards in the future or not yet tested may not be covered properly by this patch.
Extra debugging was added with "PIV_MATCH" to help with these other cards.
With "debug = 7;", `grep PIV_MATCH opensc-debug.log` can be used to see how a card
type and card_issues are derived.
On branch piv-improved-matching
Changes to be committed:
modified: card-piv.c
modified: cards.h
Same information is printed a few line below in same function, the only
difference is that there it takes care of case when label is NULL pointer
unlike this line
secondly, every function call to cosm_write_tokeninfo() in this file
passes label=NULL, and then it tries to print a null pointer
Fixes errors like
src/libopensc/log.h:48:47: error: '%s' directive argument is null
[-Werror=format-overflow=]
Signed-off-by: Khem Raj <raj.khem@gmail.com>
1. pkcs15-init is using XKU but it should use cert KU to check private key usage instead.
2. Don't mark imported keys as ALWAYSSENSITIVE and NEVEREXTRACTABLE as they are not.
3. When importing keys from PKCS#12 files (with several certs inside), use consecutive IDs for additional certificates (instead of starting from 45).
PKCS#15 token label may be padded with spaces, trim it when making a PKCS#11 token label in order not to loose closing parenthesis.
I would actually prefer for the token label to be "myCard (User PIN)" instead of current "User PIN (myCard)"
before:
$ pkcs11-tool --list-slots
Available slots:
Slot 0 (0x0): OMNIKEY AG CardMan 3121 00 00
token label : User PIN (myCard
...
after:
$ pkcs11-tool --list-slots
Available slots:
Slot 0 (0x0): OMNIKEY AG CardMan 3121 00 00
token label : User PIN (myCard)
...
1. Show pinpad reader capabilities even for uninitialised tokens. This way pinpad can be used during initialisation.
2. Make possible to create so-pin object during initialisation even if no so-pin was provided (on the command line) but pinpad reader is used and card profile contains so-pin data.
This fixes problem as stated in:
https://github.com/OpenSC/OpenSC/issues/1292#issuecomment-431879472
pkcs15-crypt.c will treat keys with user_consent like PKCS#11 would.
SC_AC_CONTEXT_SPECIFIC is set when doing a verify so a card driver can
take action if needed.
card-piv.c is currently the only driver doing so.
It uses this to hold the card lock so both the VERIFY and following crypto
operations are in the same transaction. The card enforces this restriction.
Without this additional APDUs may be sent before every transaction to test
that the expected applet is selected.
Unlike the circumvention of using ignore_user_consent=true and pin caching
this modification allows a pin pad reader to be used for keys requiring user_consent.
On branch pkcs15-context-specific
Changes to be committed:
modified: pkcs15-crypt.c
pkcs15: added function to get a specific supported algorithm, checking also OID.
This is needed because for AES there are different OIDs for each key length.
For a problem description, see <https://github.com/OpenSC/OpenSC/issues/1524>.
In a nutshell, for a card with the CoolKey applet and 2048-bit keys,
the command
pkcs11-tool --test --login
fails to complete all of its tests.
This commit consists of a patch from @dengert.
To avoid triggering an error when the data exceeds 255 bytes, this commit
limits the amount of the payload sent to the CoolKey applet on the card based
on the maximum amount of data that the card can receive, and overhead bytes
(namely, a header and nonce) that accompany the payload.
With this change, the command
pkcs11-tool --test --login
succeeds.
Instead of only expecting a key length, and implicitly assuming RSA
as the key algorithm, introduce option --key-type to pass the key type
as a string.
When generating the key determine key algorithm and attributes based on
the key type passed.
If no key was given, default to "rsa2048".
* when listing public keys, do not cut object labels in compact mode
* when listing private keys in compact mode, left align labels
* make hex codes at least 2 chars wide by changing "0x%X" to "0x%02X"
- Added session_object flag to sc_pkcs15init_skeyargs to enable on-card session objects.
- Corrections to handling native and extractable flags
- Allow creating an empty secret key EF for receiving an unwrapped key later.
Not yet complete, but can be run with CKA_TOKEN=FALSE set in the target object. Currently unwrapping emulated
with a decrypt operation in card-myeid.c. To be improved.
* 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.
Frank Morgner
Peter Marschall
Jakub Jelen
Doug Engert
Khem Raj
Luka Logar
Hannu Honkanen
Shahin Hajikhorasani
Mounir IDRASSI
Steve Ross
Andreas Kemnade
Lars Silvén
Lars Silvén
Jakub Jelen
Vadim Penzin