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.