Proper Ed25519/X25519 certs have pubkey algo with OID 1.3.101.112/110, according to
RFC8410. This commit add these OIDs, and also fixes pubkey parsing/creation - according
to the same RFC, it's just a bytestring, without ASN.1 wrapping.
Also, according to the same RFC, EDDSA/X25519 MUST not have params, even empty.
Let's define an environment MINIDRIVER_PIN=1234 in order to be able
to reuse the tests with any cards.
usage:
(cmd) set MINIDRIVER_PIN=1234
When the PIN code is not defined, let's skip the tests since it may runs
the number of trials out of the max attempts.
Moreover, some cards may have many roles, but the tests are designed for
the ROLE_USER, so let's enforce only the ROLE_USER.
Fix: issue #2326
if 5000 bytes are read, then at the end of the array we will write zero beyond its boundaries, damaging the stack.
Here's a simple solution. if you see the need to increase the array itself, let me know.
Rutoken ECP cards have no default SE file. Previous cards ignored
MSE with restoring default SE, but new cards don't. This requires
SC_SEC_ENV_FILE_REF_PRESENT to be removed from env flags.
Do not truncate ECDSA input to size of key if card or driver will do HASH.
On branch Fix_for_2283_ECDSA
Changes to be committed:
modified: src/libopensc/pkcs15-sec.c
Extend the current support from 9abf8ee04c
in order to add a fixup for the CPx cards.
Since the data is not properly encoded when the card is initialized
let's re-build it for each run time from the DF.
Suggested-by: Doug Engert <deengert@gmail.com>
Fix: issue #2270
Some cards, such as the CPX are missing features that should
have been initialized using:
iasecc_pkcs15_encode_supported_algos()
Let's export this function in order to build a fixup when the DF
should be parsed.
When OPENSSL is missing, an error should be rised since this
workaround for the CPX cards cannot work. It means that
any environments that use the CPX cards must be compiled with
ENABLE_OPENSSL.
Suggested-by: Doug Engert <deengert@gmail.com>
Fix: issue #2270
The CPX has the standard capabilities of the IASECC standard.
Let's be carefull with memory leakage, see the
previous commit 83162c5c8
Fix: issue #2270
From the logs, we can detect many 6A 86 (Incorrect P1 or P2 paremeters).
A deeper analysis will be required, but the best option to check them
is to start emitting any Warning for such events.
The code segment checks the response to determine if the
SC_CARD_CAP_PROTECTED_AUTHENTICATION_PATH is available.
From the APDU manual of the sc-hsm, there's one status word:
SC_ERROR_REF_DATA_NOT_USABLE(0x6984) that should also be taken into account.
fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32324
sc_enum_apps() causes card->cache.current_ef to be allocated for
IAS/ECC, but not freed if any other error occurs during initialization.
since sc_enum_apps() is called anyway during PKCS#15 initialization.
Having this at the card driver level (instead of the PKCS#15 level) is
not needed.
Since commit dba0f56 the tokenPresent parameter is ignored in case the
slot has been already seen.
This breaks the API expectations as we may return a slot that has no
token inserted.
So, only consider the SC_PKCS11_SLOT_FLAG_SEEN if tokenPresent is false
Some Smartcards have some capabilities (for instance the IASECC)
that can influence the can_do cases. In order to track them, it
is useful to log any checks.
* IASECC: offset is a size_t
Let's use a size_t for the offset in order to have a proper logic
along with the related arithmetics.
Fix: part if issue #2262
Suggested-by: Frank Morgner <frankmorgner@gmail.com>
* iasecc: Fix ACLs support when length is 6
ACLs with length < 6 are allowed, depending on the mask of the offset 0.
For instance, when the offset 0 is 0x7B, then length can be up to 7
when the offset 0 is 0x7A, the loop was never performing any access to
the acls[7] thanks to:
if (!(mask & acls[0]))
continue;
However, the oss-fuzz tools cannot guess such behavior. So let's have a
robust boundary check.
Fix: issue #2262
Fix: ae1cf0be90 'Prevent stack buffer overflow when empty ACL is returned'
Co-authored-by: Vincent JARDIN <vjardin@free.fr>
Co-authored-by: Frank Morgner <frankmorgner@gmail.com>
