- 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.