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.
Commit e5707b545e broke signing using minidriver on Windows.
More specifically changing #define SC_ALGORITHM_RSA_PAD_NONE from 0x00000000 to 0x00000001 caused a call to sc_pkcs1_encode() to fail as the padding algorithm was not specified anywhere in the CardSignData() implementation. It kind of worked as long as SC_ALGORITHM_RSA_PAD_NONE was 0x00000000, but the above mentioned commit broke this.
Now padding algorithm has to be explicitly specified, otherwise a call to sc_pkcs1_encode() will fail.
- rename 'keytype' in some OpenPGP-specific types to 'key_id'
because they key ID was what the field was used for
- introduce field 'algorithm' in the structures above
to indicate the key's algorithm: RSA, ...
- define constant SC_OPENPGP_KEYALGO_RSA and use it
- rename constants SC_OPENPGP_KEYFORMAT_* to SC_OPENPGP_KEYFORMAT_RSA_*
because they are RSA specific
List additional algorithms & attributes as supported only when the card
supports changing the algorithms attributes DOs and exposes this by having
the EXT_CAP_ALG_ATTR_CHANGEABLE capability set.
Using different algorithms and attributes requires changing the algorithm
attributes DOs. If that is not supported - as indicated by a missing
EXT_CAP_ALG_ATTR_CHANGEABLE capability - then only those algorithms
described by the current algorithms attributes DOs' contents can be used.
In addition simplify setting the flags.
* use variables if they are already there
* be a bit more explicit in logging
* more consistent tag format: %04X
* cleanup flag setting for _sc_card_add_rsa_alg()
card-piv.c
make sure the string is null terminated before passing it
to hex_to_bin routine, which expects it
pkcs15-cac.c
free cn_name on failure
pkcs11-tool.c
make sure the string is null terminated before passing it to
parse_certificate(), which expects it
A card driver may declare support for computing the padding on the card,
or else the padding will be applied locally in padding.c. All five
PKCS11 PSS mechanisms are supported, for signature and verification.
There are a few limits on what we choose to support, in particular I
don't see a need for arbitrary combinations of MGF hash, data hash, and
salt length, so I've restricted it (for the user's benefit) to the only
cases that really matter, where salt_len = hash_len and the same hash is
used for the MGF and data hashing.
------------------------------------------------------------------------
Reworked and extended in 2018 by Jakub Jelen <jjelen@redhat.com> against
current OpenSC master, to actually work with existing PIV cards:
* extended of missing mechanisms (SHA224, possibility to select MGF1)
* compatibility with OpenSSL 1.1+
* Removed the ANSI padding
* Formatting cleanup, error checking
Based on the original work from
https://github.com/NWilson/OpenSC/commit/42f3199e66
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
modified: src/libopensc/pkcs15-infocamere.c
modified: src/libopensc/pkcs15-starcert.c
modified: src/pkcs15init/pkcs15-lib.c
Changed isf_acl to also need SO PIN for CREATE.
modified: src/pkcs15init/starcos.profile
* localize variables
* print errors to stderr
* release allocated resources
* return error code on error - improve non-interactive use
* do not show help on unknown commands when used non-interactively
* make 'interactive' a global variable
* set it when opensc was called with the SCRIPT argument
* document the behaviour in the manual page
Make interactive a global variable and set it in main.
When arguments are given, compare them like ambguous_match() does,
and show the matching ones only.
Add documentation of the 'help' command to the manual page.
In main loop on multiple matches, show help on matching commands only.
* most importantly: immediately return success on exact match
- this allows one command to be a prefix of another one
- it fixes the long-standing breakage between 'find' and 'find_tags'
* fail on second prefix-only match instead of waiting until the end
* check all parameters
* add comments
* inform caller on whether the match was ambiguous or there was no match
* move printing error messages to processing loopt in main()
Accept a file name as a second argument to the 'random' command
to allow storing the generated random bytes to the file given.
Forbid writing binary data to stdout in interactive mode.
* limit buffer to SC_MAX_EXT_APDU_BUFFER_SIZE
* fix buffer length calculation to correctly calculate the available space
* add length checks when parsing passed data into buffer
* consistently show ellipsis for repeatable arguments as 3 dots
* embrace alternative mandatory arguments with curly braces
* use hyphens instead of spaces within non-literal arguments
for improved alignment with the manual page