- when listing the slots, we don't have a hotplug slot anymore with
slot->reader == NULL. Instead, we're now using this state for any left
over slots when a reader is removed. So we don't need to include this in
the slot list
- when listing the slots, we need to remember which slots the
application has seen already, to not shrink the list of slots (which is
allowed in PKCS#11 v2.2, but NSS can't handle this)
Macro DEBUG_VSS and routine _debug_virtual_slots were added.
DEBUG_VSS(slot, "printf like format string" [,args...]) will print the virtual_slots
to the opensc-debug.log showing were it was called from.
If slot is not NULL and found in the table it will be highlighted
with an "*".
In gdb: call _debug_virtual_slots(slot) can be used along with
another window to tail opensc-debug.log
On branch PKCS11-SLOTS-2
Date: Fri Feb 21 08:19:37 2020 -0600
Changes to be committed:
modified: src/pkcs11/sc-pkcs11.h
modified: src/pkcs11/slot.c
- allows re-attatching a reader to an existing reader object by
resetting the SC_READER_REMOVED flag
- readers that are flagged with SC_READER_REMOVED are not used for
SCardGetStatusChange to avoid SCARD_E_UNKNOWN_READER
fixes https://github.com/OpenSC/OpenSC/issues/1903
OpenSC PKCS11 now retains slots even when the reader is removed.
It can do this because existing OpenSC reader handling in ctx.c,
reader-pcsc.c and PC/SC allow OpenSC to do this.
This simplifies the code, and allow a reader to be reinserted
and use the existing slot. This matching is actually done
in reader-pcsc.c because PC/SC returns the unique ids based on
the OS reader names. This is then used as the manufacturerID
By not deleting slots the slot list can only increase which is a
restriction of Firefox. It does not fix all the Firefox issues, but
it does not go into a loop, when all the readers are removed.
The defaults in opensc.conf for max-virtual-readers and slots-per-card
allow for 4 different readers used during one session.
On branch PKCS11-SLOTS-3
Changes to be committed:
modified: sc-pkcs11.h
modified: slot.c
* distinguish between Internal and Working EFs
* add information optionally available in sc_file_t
- record_count
- record_length
- type_attr
* align all labelled values
Replace magic numbers, used as size of PIN-type buffers,
with the symbolic constant SC_MAX_PIN_SIZE, fixing
- readability / understandability
- too small sizes (e.g. for GnuPG cards)
* define file type SC_FILE_TYPE_UNKNOWN
* explicitly set file->type to SC_FILE_TYPE_UNKNOWN for unkown files
* store full-length file type attributes via sc_file_set_type_attr()
* parse # of records for record-oriented EFs
* parse record length for for EFs with fixed-size records
Note: I am not sure, parsing the record length only for EFs with fixed-
size records is the correct approach.
My interpretation of the norm is slightly different, but it seems
to be in-line what's currently in opensc:
- there's a comment hinting at that interpretation
- otherwise variable size records fail to be read in opensc-explorer
So I leave it this way for now.
Use __FUNCTION__ as defind in log.h so will compile with any compiler.
logprint additional handles as size_t
Add check in reader-pcsc.c pcsc_user_reader for minidriver only.
On branch minidriver-5
Changes to be committed:
modified: src/libopensc/reader-pcsc.c
modified: src/minidriver/minidriver.c
Add MD_FUNC_CALLED(pCardData, level) and MD_FUNC_RETURN(pCardData, level, ...)
macros.
Handles are type __int3264 in VS2015 are casted as size_t when printing so
all bytes are printed. size_t on Windows are also treated as 32 or 64 bits.
SC_FORMAT_LEN_SIZE is used in the format.
(Works with VS2105 needs to be tested on other platforms.)
On branch minidriver-4
Changes to be committed:
modified: minidriver.c
Minidriver.c and reader-pcsc.c - reuse OpenSC reader structure
Windows CNG is managing the insertion and removal of the reader and the card
and will call CardAcquireContext and CardDeleteContext as needed if
the card or reader change. But different processes or threads may establish
different PCSC connects to the same reader and card but with different handles.
Reuse the OpenSC reader when windows uses the same reader but with different
handles. Tests show the certutil -v -scinfo works the same.
Associate_card is only need when called from
CardAcquireContext and disassociate_card is only need when called from
CardDeleteContext.
No need to call reinit_card_for(pCardData, name) just because the handles changed.
This may be the fix for #1763 because calls like CardCreateContainerEx remain
in card state rather then being lost when the handles changed.
Changes to be committed:
modified: src/libopensc/reader-pcsc.c
modified: src/minidriver/minidriver.c
The EC Parameters are the way the EC curve is presented to the outside world,
and in most cases is present in a matching certificate in the SPKI.
card-openpgp.c is modified to add the EC named_curve to the PKCS15 public key.
OpenPGP specs only provide this via the "Algorithm Attributes" for the 3 keys
via tags C1, C2 and C3 These contain the OID (not DER encoded) for the EC curve.
PKCS15 has two ways to encode a "pubkey" as it was originally written for RSA.
But other algorithms have parameters. X509 certificates encode the public key
in the SPKI and PKIX requires the parameters to be in the SPKI. PKCS15
allows for using a SPKI as source for a public key.
pgp_get_pubkey_pem will return the DER encoded RSA pubkey as before by
calling sc_pkcs15_encode_pubkey
pgp_get_pubkey_pem will return the DER encoded EC pubkey with parameters by
calling sc_pkcs15_encode_pubkey_as_spki which calls sc_pkcs15_fix_ec_parameters
internally to map DER encoded OID to named_curve.
For readability, "sc_pkcs15_pubkey_t pubkey;" definitions are changed to
"sc_pkcs15_pubkey_t p15pubkey;"
sc_pkcs15_erase_pubkey is used to avoid memory leaks.
On branch openpgp-ec-pub-curve
Date: Tue Jan 21 09:43:56 2020 -0600
Changes to be committed:
modified: src/libopensc/card-openpgp.c
- turns out, you can shrink a buffer with realloc on some implementations
- realloc is never called with 0 (which would free the data)
- length checking is done in zlib, we just do the allocation
closes https://github.com/OpenSC/OpenSC/issues/1905
In pre-v3 cards, it is hard-coded to 254 bytes.
In v3+ cards, it is stored in the "extended capabilities" DO 00C0.
Make the determined size available as a variable in the driver data.
* OpenPGP v3 increased the size for private DOs. Adapt to it.
* Use the symbolic constant from the refactored OpenPGP driver
instead of relying on magic numbers.
- turns out, you can shrink a buffer with realloc on some implementations
- realloc is never called with 0 (which would free the data)
- length checking is done in zlib, we just do the allocation
closes https://github.com/OpenSC/OpenSC/issues/1905
- remove command line option '--card-driver';
- instead force driver 'dnie' and fail if card is not a DNIe card
- overhaul option parsing
- remove unused variable 'long_optind'
- bail out with usage message on all unknown/unhandled args
- correctly terminate option parsing (no infinite loop)
- slight refactoring
- avoid magic constant '0x0f'
- make variable 'tries_left' more local
- move dependent code into if block
- remove command line option '--card-driver';
- instead force driver 'cardos' and fail if card is not a CardOS card
- overhaul option parsing
- remove unused variable 'long_optind'
- bail out with usage message on all unknown/unhandled args
- correctly terminate option parsing (no infinite loop)
- remove command line option '--card-driver';
- instead force driver 'PIV-II' and fail if card is not a PIV card
- overhaul option parsing
- remove unused variable 'long_optind'
- make work option '--reader' ( "r:" was missing in the optstring!!!)
- bail out with usage message on all unknown/unhandled args
- correctly terminate option parsing (no infinite loop)
Rename option '--driver' to '--card-driver' for increased consistency.
In addition, extend it the same way opensc-explorer was extended. I.e.
treat the question mark given as argument to option '--card-driver'
special: list all available drivers instead of stupidly bailing out.
In contrast to opensc-tool and opensc-explorer, which are card-agnostic,
I am not sure whether the option '--card-driver' makes sense on this
card-specific tool.
Extend cardos-tool the same way opensc-explorer was extended. I.e.
treat the question mark given as argument to option '--card-driver'
special: list all available drivers instead of stupidly bailing out.
In contrast to opensc-tool and opensc-explorer, which are card-agnostic,
I am not sure whether the option '--card-driver' makes sense on this
card-specific tool.
Extend piv-tool the same way opensc-explorer was extended. I.e.
treat the question mark given as argument to option '--card-driver'
special: list all available drivers instead of stupidly bailing out.
In contrast to opensc-tool and opensc-explorer, which are card-agnostic,
I am not sure whether the option '--card-driver' makes sense on this
card-specific tool.
Extend opensc-tool the same way opensc-explorer was extended. I.e.
treat the question mark given as argument to option '--card-driver'
special: list all available drivers instead of stupidly bailing out.
Make opensc-explorer a bit more user friendly by treating the question mark
given as argument to option '--card-driver' special: list all available
drivers instead of stupidly bailing out.
The corpus is generated using a local build with
#define APDU_LOG_FILE "apdulog"
and by running:
./src/tools/pkcs11-tool -L --module ./src/pkcs11/.libs/opensc-pkcs11.s
cb50689bf49ccb45a2af690848517305dcf1e429 -- my Yubikey
830e1bf4c7f0c539e9686bc1517d6f87907d4bf8 -- PIV Test Card 14
9ad3fc3cb11967be927bad9263d326783c450e37 -- CAC card
b2b75c07a2c427c15ecd40ce47a9814279745b7d -- old CAC card
7cf8e9b31dcee040ee438441aca2aecb523ed5e9 -- CardOS 5.x
741a0aae7b5b08c0ad2822ede5b3364302b28b31 -- CAC Alt token
de913ba454f894cfc38a16dd122ad673d32ac480 -- coolkey
./configure --enable-code-coverage --disable-optimization
make check
make code-coverage-capture
lcov --summary OpenSC-*-coverage.info
This does not work well with Windows so on windows it should be disabled (WIP)
The card is largely ISO 7816 compliant, but does not provide any
simple way of listing the content which is supported by current
PKCS#15 implementation therefore the PKCS#15 emulator had to be
used.
The certificates are compressed in a similar way as in DNIE
cards which complicates reading from the card and which I think
could be moved to the shared ISO (or some other file since I saw
that code already many times).
The card supports wide range of algorithms including
RSA-PSS and RSA-OAEP padding schemes in-card. On the other hand,
it does not allow raw RSA and SHA1 hashes on card anymore.
The card is manufactured by Gemalto so it has strict ATR which
can be used for detection.
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.