Fixes
error: misleading indentation; statement is not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if(cipher)
^
../../../git/src/libopensc/card-entersafe.c:369:2: note: previous statement is here
if(sbuf)
^
Before the output looked like this, if a public key was not found:
```
testing key 1 (IDKey2)
RSA-X-509: OK
RSA-PKCS: OK
testing key 2 (IDKey3)
couldn't find the corresponding pubkey for validation
couldn't find the corresponding pubkey for validation
RSA-X-509: RSA-PKCS: testing key 3 (IDKey4)
couldn't find the corresponding pubkey for validation
couldn't find the corresponding pubkey for validation
```
Now:
```
testing key 1 (IDKey2)
RSA-X-509: OK
RSA-PKCS: OK
testing key 2 (IDKey3) -- can't find corresponding public key, skipping
testing key 3 (IDKey4) -- can't find corresponding public key, skipping
```
Before it was a bit confusing, e.g.:
```
testing key 1 (2048 bits, label=IDKey2) with 1 signature mechanism
RSA-X-509: OK
couldn't find the corresponding pubkey
testing key 2 (0 bits, label=IDKey3) with 1 signature mechanism -- can't be used to sign/verify, skipping: can't obtain modulus
```
The error message in line 3 is for IDKey3 and not for IDKey2.
With this patch the output is aligned with `test_verify`:
```
testing key 1 (IDKey2) with 1 mechanism
RSA-X-509: OK
testing key 2 (IDKey3) with 1 mechanism -- can't find corresponding public key, skipping
```
GIDS decipher APDU fails with status '65 00' or '67 00' if
"Padding Indication" byte is present. Debug logs of Microsoft
certutil -v -scinfo using Microsoft drivers show that for a
decipher, the "Padding Indication" is not present. It maybe
needed if Secure Messaging is added later.
Extended APDU is turned off as this may not be supported on
some cards. Chaining is used used instead, it works on all cards.
RAW RSA is turned off, it is supported.
Tested with pkcs11-tool on Windows 10 with a TPM 2.0 module.
On branch gids-decipher
Changes to be committed:
modified: src/libopensc/card-gids.c
Date: Tue Dec 3 18:08:32 2019 -0600
interactive rebase in progress; onto 01678e87
Last commands done (3 commands done):
squash c968d0dd GIDS No Padding Indication Byte
squash 0fa940fc Take 3
No commands remaining.
You are currently rebasing branch 'gids-decipher' on '01678e87'.
* Explicitly copies the mechanism parameters during a PKCS#11 `C_VerifyInit`
and `C_DecryptInit` operation.
* Resolves issues where the calling application deallocates the `pParameter`
pointer in the `CK_MECHANISM` struct between calls to `C_VerifyInit` and
`C_Verify`, or between `C_DecryptInit` and `C_Decrypt`.
* These mech parameters are used in RSASSA-PSS and RSAES-OAEP, for example.
* This commit copies the same fix that was applied to `sc_pkcs11_sign_init` in
commit e5707b545e for supporting RSASSA-PSS.
When the application (NSS) does not use WaitForSlotEvent and just
opportunistically tries to detect card and reader removals with
C_GetSlotInfo() and C_GetSessionInfo(), we might get errors in
various plcaes, in the sc_lock() function, when we try to transfer
other messages or when we ask for the reader status.
This is generally too late to call any disconnect functions because no
PC/SC handles are valid anymore. The reader state from PCSC
is searched by name so we can be pretty sure it is very similar
reader (with same name as the old one) and I hope we can reuse the
reader structure and just call the pcsc_connect() on that as we do
with invalid handles.
Otherwise we detect this issue in the refresh_attributes() (called
from C_GetSlotInfo()), where we can report the slot change in the
expected manner.
Fixes#1822
The error was
fuzz_pkcs15_reader.c: In function ‘fuzz_get_chunk’:
fuzz_pkcs15_reader.c:66:19: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
66 | *chunk_size = (uint16_t) data->Data;
| ^
cc1: all warnings being treated as errors
The negative integers were parsed uterly wrong, resulting in undefined
shift overflows as reported by oss-fuzz.
The current implementation takes negated values (properly masked) and
calculates two's complement in the end, which results in correct values
and correct data handling.
https://oss-fuzz.com/testcase-detail/5125815506829312
Reported by clang analyzer:
src/libopensc/asn1.c:2115:14: warning: The right operand of '<' is a garbage value [clang-analyzer-core.UndefinedBinaryOperatorResult]
if (halflen < r_len || halflen < s_len) {
* pkcs11-register: Fixed detection of already registered OpenSC
Anny configuration of onepin-opensc-pkcs11.so and opensc-pkcs11.so
should be enough to skip registering the default module again.
* Use onepin module for generic NSS DB
fixes https://github.com/OpenSC/OpenSC/issues/1818
May have the disadvantage that some other programs that use NSS don't
see the signature keys. However, we currently only know for sure that
Chromium is using the generic NSS DB.
The corresponding GET DATA command only returns the serial,
nothing else.
Tested with CardOS 5.0 and 5.3 cards. The serial number
is the same as shown with other tools
Changed four places where "<" should be "<=" so Le will be set correctly
Previous for 65K (extended) or 256 (short) Le is left set to 0.
This then caused Le to be to be not added to APDU as Le==0
Code later converts actual Le in APDU to be set to 0 to mean 256 or 65K.
SC_APDU_CASE_*_EXT are changed to SC_APDU_CASE_* so sc_detect_apdu_cse
to set the cse based on card capabilities as well as data chaining.
This commit is not well tested and neds review.
On branch fix-1731
Changes to be committed:
modified: src/libopensc/card.c
buf_len is a CK_ULONG (unsigned long). But if the attribute is sensitive
or is not extractable or is invalid for the object then the library set
the buffer length value to (CK_LONG)-1.
It is more friendly to see "-1" instead of "18446744073709551615" (on
64-bits CPU)
opensc-tool: for options --version, --list-readers, -D, etc. we do not
need to connect card/reader. This removes unnecessary error messages
if card is not present in card reader or if reader is not available.
util.c: use symbolic error codes, pass error codes to caller without change.
CID 344928 (#1 of 1): Sizeof not portable (SIZEOF_MISMATCH)
suspicious_sizeof: Passing argument object_handles of type CK_OBJECT_HANDLE_PTR and argument objects_length * 8UL /* sizeof (CK_OBJECT_HANDLE_PTR) */ to function realloc is suspicious. In this case, sizeof (CK_OBJECT_HANDLE_PTR) is equal to sizeof (CK_OBJECT_HANDLE), but this is not a portable assumption.
CID undefined (#1 of 1): Unchecked return value (CHECKED_RETURN)
10. check_return: Calling RSA_set0_key without checking return value (as is done elsewhere 7 out of 8 times).
* The fail_msg() in cmocka has a way not to fail, which confuses coverity. Adding explicit retunr/exit should address this issue
* Reformat some code in p11test
Option -r is used in other opensc tools to specify card reader. pkcs15-tool
uses -r to specify cerfificate. This fix intorduces warning message if -r
is used, and for future versions of pkcs15-tool -r is used to specify
reader.
sc-ossl-compat.h will check if OpenSSL has been built with or without some
deprecated defines. OpenSSL will provide defines for some of these if
built to still support depreacted routines but not if built with
"no-depracted". .
This commit will define some of the needed defines if ther are not
defined by OpenSSL. Thus if a distro builds OpenSSL with "no-depracted"
it can still be used.
On branch fix-1755
Changes to be committed:
modified: src/libopensc/sc-ossl-compat.h
When card supports SC_ALGORITHM_RSA_PAD_PKCS1 but not SC_ALGORITHM_RSA_HASH_NONE, then the DigestInfo need to be removed.
Current check make requires the card to not support both SC_ALGORITHM_RSA_PAD_PKCS1 and SC_ALGORITHM_RSA_HASH_NONE to have the removal done.
when importing a private key onto a pkcs15 card, if the card does not support
extended APDUs, we need to use chaining to store keys longer than 255 bytes.
While for RSA keys, this check was included, it was missing for EC keys.
This patch adds the SC_APDU_FLAGS_CHAINING flag to apdu.flags if data length is
greater than 255 and the card caps does not include SC_CARD_CAP_APDU_EXT.
Fixes#1747
The check condition is obviously wrong. It should check for EQUAL. The original bitwise check caused any other language to turn into DE because as long as a bit is filtered, it will hit.
Fixes regression from commit 3688dfe which did not consider that
the zero prefixing tests were too generic and matched EC keys too.
This simplifies the code even further and avoids data copying
when possible. Proper test is now included to do data value prefixing
only for the RSA keys it is needed.
Closes#1701.
At the point when gemsafe_match_card is called, the card type is already known,
either because of a previous match at card.c, or because it is forced at opensc.conf.
With this redundant match it's not possible to force selection on opensc.conf.
Signed-off-by: Nuno Goncalves <nunojpg@gmail.com>
This adds support for a minimalistic, small and fast card profile based on IAS-ECC.
Based on information from https://installer.id.ee/media/id2019/TD-ID1-Chip-App.pdf
and proprietary driver snoops.
Thanks to @metsma and @frankmorgner.
Change-Id: I2e4b4914d8a3b991d9a639728695abf4a2362ca0
Encode the component ID to be key type and component ID. This allows
each combination to be unique and direct mapping to card component
ID type in the code by just taking the low byte. This simplifies
the code, and reduces confusion as there is now only one #define
for each component.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
MyEID starting version 4.5 supports 4K RSA keys. The card also
now supports proper APDU chainging (for sending large APDUs) and
receiving large responses via GET_RESPONSE splitting.
This updates the following:
* detection code properly announces 3K and 4K RSA support
when available
* APDU chaining is used when possible
* use ISO GET_RESPONSE handling for large responses
* max_recv_size is set to 256 which it always was supposed to be
as the old cards respond with that large responses too
* use the 2K signing kludge only on cards that need it
* unwrap and decipher code paths unified to the extent possible
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Instead of a double check_sw call in case there is no data, assume
that a SW is properly sent by the card and do not expose
SC_ERROR_FILE_END_REACHED outside of the function
(like sc_pkcs15_read_file)
This is to facilitate Estonian eID 2018+ that instead of properly returning
6282 with trunkated data, 9000 is returned and next READ BINARY returns
6b00 (invalid p1/p2). The change should be generally harmless for well-behaving
cards.
Change-Id: I7511ab4841d3bcdf8d6f4a37a9315ea4ac569b10
If card driver fails to connect to card, 'opensc-tool -a' may fail to print
ATR even if ATR is available from card reader. Before use of card driver,
do only card reader connect, then print ATR. Only if it is neccesary, use
card driver for the rest of opensc-tool functions.
The code already removes all active cards when the service goes
away, but it doesn't remove the reader. This can be a bit confusing
since they will still be polled and listed.
CVE-2019-6502 was assigned to what appears to be a very minor
memory leak that only occurs on an error-case in a CLI tool.
If util_connect_card fails, we still need to release the sc
context previously allocated by sc_context_create else memory
will leak.
* Remove postecert and infocamere support because no longer issued
* Remove wrong changes
* reset NEWS
* EC_POINT_set_affine_coordinates_GFp and EC_POINT_get_affine_coordinates_GFp are
deprecated, use EC_POINT_set_affine_coordinates and EC_POINT_get_affine_coordinates
* If OPENSSL API version is < 3 use old functions EC_POINT_[sg]et_affine_coordinates_GFp
* Move the OpenSSL compatibility stuff to src/libopensc/sc-ossl-compat.h
* pgp: initialize ecc keys for OPC3
* Add supported ECC algorithms by card version
* Add tasks identified so far
* pgp: Recognize ECC set on card
* pgp: get_pubkey_pem read ECC pubkey from card
* pgp: minor code changes for ECC compatibility
* pgp: expand sc_cardctl_openpgp_keygen_info to hold ec info
* Fix segfault problem in pkcs15-pubkey.c
* pgp: enable key generation with pkcs15-init and ECC
* pgp: adapt calculate_and_store_fingerprint to accept ECC
* pgp: adapt rest of pgp_gen_key and subfunctions to accept ECC
* pgp: add kdf parameters for ECDH fingerprint calculation
* pgp: enable key import with pkcs15-init and ECC
* pkcs15-pubkey: fix_ec_parameters onlz accpets explicit data or named_curve
* Fix some mistakes during merge
* More clean up for PR
* Fix some ugly alignments
* Improve code readability
* Prevent unitialized variable by using FUNC_RETURN
* OpenPGP: add length check
* pgp: save exponent length in bits for sc_cardctl_openpgp_keystore_info_t
* pgp: length checks and reallocations
* pgp: oid init added
* OpenPGP: slightly re-factor pgp_update_new_algo_attr()
* replace loop copy with memcpy()
* use ushort2bebytes() to set RSA modulus & exponent
* use symbolic name SC_OPENPGP_KEYFORMAT_RSA_STD for the key import format
* OpenPGP: slighly re-factor pgp_parse_and_set_pubkey_output()
* check for RSA modulus & exponent lengths not being a multiple of 8
* make sure RSA modulus & exponent lengths are always set
* remove a left-over RSA setting from the EC code
* pgp: adding BYTES4BITS
* pgp: initialization of values in pgp_build_extended_header_list based on key type
* pgp: add BYTES4BITS and remove unnecessary tests
* Fix broken pgp_update_new_algo_attr
* pgp: fix the ecpoint_len variable
* Add object type "secrkey" to help of --type switch in pkcs11-tool
Reading an object with pkcs11-tool requires the `--type` switch. The help for that switch is currently incomplete as it is missing the (not very friendly named" *secrkey* option used to read out a secret key object.
I have added this information to the help description.
* Update man page
Describe secrkey option of pkcs11-tool's --type switch in man page
Framework-pkcs15.c silently ignores adding objects if MAX_OBJECTS
is exceeded while creating the fw_data objects. This simple fix
is to change the MAX_OBJECTS from 64 to 128. A better fix would
be to realloc the objects arrays as needed.
__pkcs15_create_data_object and __pkcs15_create_secret_key_object
now return rv like the other __pkcs15_create_*_object routines.
pkcs15_dobj_get_value now calls sc_pkcs15_read_data_object just like
the other pkcs15_*_get_value routines. The problem was introduced
in 0c3412bb 2018-04-09 which added:
`return sc_to_cryptoki_error(SC_SUCCESS, "C_GetAttributeValue");`
before trying to read the data object.
The MAX_OBJECT problem was discovered while trying to use a new PIV
card with 24 standard cert objects and 10 other objects for a total
of 106 objects. Each cert object corresponds to a cert, pubkey,
private key, and the cert object itself for a possible 112 data objects.
The pkcs15_dobj_get_value was found while running:
running pkcs11-tool -r -y data --application-id 2.16.840.1.101.3.7.2.1.1
using git bisect to locate the bad commit. The pkcs11 data objects are
created last from the pkcs15 objects which are a linked list with no limits.
On branch fix-object-restrictions
modified: src/pkcs11/framework-pkcs15.c
* 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.
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.