Depending on the "lifecycle" of the file, we may omit the authentication
operation. Typically if the card is in initialization or creation state,
the access control mechanism is inactive. If authentification can be
skiped, the card driver is responsible for setting the "acl_inactive"
variable in sc_file structure.
card-opennpgp.c and pkcs15-openpgp.c have a strang way of
using sc_object_id_t to store what they call a binary_oid
or oid_binary. It is used to convert the EC curve asn1
returned in the cxdata.
This code uses asn1_decode_object_id to use sc_object_id_t
as used in the rest of the code.
The code and ec_curve tabes in card-openpgp.c where not changed.
pkcs15-openpgp.c was channge si to can use:
algorithm_info = sc_card_find_ec_alg(card, 0, &oid);
to retried the key_length to add to the pubkey and prkey entries.
The EC and EDDSA needs (i.e. field_length) to run.
On branch eddsa
Your branch is up to date with 'Jakuje/eddsa'.
Changes to be committed:
modified: card.c
modified: pkcs15-openpgp.c
Since 09a594d bringing ECC support to openPGP card, it did not count
with GNUK. This adds exception for GNUK to unbreak ECC signatures
as GNUK presents BCD version < 3.
This fixes a problem reported in Nitrokey forum at
https://support.nitrokey.com/t/veracrypt-encryption-with-nitrokey-error/2872
as inability to save the VeraCrypt's keyfile onto the token
after deleting an existing one, unless the PKCS11 is reinitialized.
Reason: commit cbc53b9 "OpenPGP: Support write certificate for Gnuk"
introduced a condition on getting the blob handle, which is surplus
(the pgp_find_blob() function actually does that) and prevents
the blob refresh upon deletion, breaking the logic introduced
earlier in commit 9e04ae4 and causing the higher-level effect reported.
While at it, corrected comments to actually reflect the flow logic.
Tested on Fedora 33 using the repro steps from the forum and Nitrokey Pro.
Signed-off-by: alt3r 3go <alt3r.3go@protonmail.com>
config option for MyEID: "disable_hw_pkcs1_padding"
If user set this option to non zero, OpenSC is forced to calculate padding
in software. This will allow users to use RSA 1024 with SHA512.
This PR is based on discussion with @popovec in
https://github.com/OpenSC/OpenSC/issues/2181
and https://github.com/OpenSC/OpenSC/pull/2187
which was cherry-picked as 5e5300816c8
This has been tested with PIV, MyEID and Smartcard-HSM.
with ECDSA keys.
The main fixes include :
- Setting "flags" in card drivers
- added code to sc_pkcs15-compute-signature for handle ECDSA with hashes
- code in framework-pkcs15.c
Signatures made by pkcs11-tool -sigm verify with openssl
but pkcs11-tool --verify does not work with ECDSA but does with RSA
I suspect it has to do with:
and some then creating the wrong PKCS11 mechanisms
It should work with the epass2003 which does hashes in the driver.
CKM_ECDSA and CKM_ECDSA_SHA1 cannot be registered in the same way.
We need to use sc_pkcs11_register_sign_and_hash_mechanism ()
for CKM_ECDSA_SHA1.
This fix also enables more ECDSA-SHAxxx mechanisms in framework-pkcs15.c
Tested: MyEID 4.0.1 (secp256r1 with SHA1, SHA224, SHA256, SHA384, SHA512)
CI tests (Travis + OsEID) for ECDSA-SHAxxx mechanisms are also enabled.
Information about "Life cycle status byte" is now available in listing.
Also src/libopensc/types.h update - added more LCSB definitions.
iso7816_process_fci () update: improved tag 0x8A parsing.
Fixes in card-flex.c and card-miocos.c - SC_FILE_STATUS_xxx is not
bitfield.
Thanks clang:
/src/libopensc/card-authentic.c:1564:47: warning: The left operand of '==' is a garbage value [clang-analyzer-core.UndefinedBinaryOperatorResult]
if (acls[AUTHENTIC_ACL_NUM_PIN_RESET].method == SC_AC_CHV) {
^
Thanks clang
/src/libopensc/card-belpic.c:230:7: warning: Although the value stored to 'r' is used in the enclosing expression, the value is never actually read from 'r' [clang-analyzer-deadcode.DeadStores]
if((r = get_carddata(card, carddata, sizeof(carddata))) < 0) {
^
/src/libopensc/card-belpic.c:230:7: note: Although the value stored to 'r' is used in the enclosing expression, the value is never actually read from 'r'
Cleanup trailing whitespaces and protect hand formated structures
in card-piv.c and pkcs15-piv.c
On branch PIV-whitespace
Changes to be committed:
modified: card-piv.c
modified: pkcs15-piv.c
This patch enables using of: SHA224-RSA-PKCS, SHA256-RSA-PKCS,
SHA384-RSA-PKCS, SHA512-RSA-PKCS and PSS variants of these mechanism for
MyEID users. (This patch is related to issue #2173.)
CI tests for these mechanisms are also enabled (using OsEID emulation).
ASN1 tags are represented in two many ways within OpenSC.
This is a trivial change to simplify one aspect of this.
It also makes the code more readable.
SC_ASN1_CLASS_MASK, SC_ASN1_APP, SC_ASN1_CTX, SC_ASN1_PRV,
SC_ASN1_CONS are changed, and SC_ASN1_CLASS_MASK is added.
These then align with the bits defined by SC_ASN1_TAG_CLASS,
SC_ASN1_TAG_APPLICATION, SC_ASN1_TAG_CONTEXT, SC_ASN1_TAG_PRIVATE,
and SC_ASN1_TAG_CONSTRUCTED.
(SC_ASN1_UNI and SC_ASN1_TAG_UNIVERSAL are both 0x00 thus no change
is needed).
(No sign of a right shift of SC_ASN1_CTX or SC_ASN1_PRV causeing
problems has been seen in the code.) If found, can be solved.)
Close examination of the OpenSC code base shows all uses of tags
used by routines and sc_asn1_entry use the defines.
This could allows 26 lines of code in sc_asn1_skip_tag used to test
the 3 CLASS and CONSTRUCTED bits to be replaced by:
if (((cla << 24) | tag) != tag_in)
return NULL;
The 26 lines still work as will any other code in OpenSC
that tests the bits using the defines. It also allows new code
to be simplified.
Problem identified while looking at better way to check response
on GET_DATA (0xCB) that returns TLV as used in card-piv.c
Changes tested using pkcs11-tool --test --login with PIV, SC_HSM
and OpenPGP cards.
Fixes#2141
NIST 800-73-3 based cards only had 2 bits set in first pin policy byte.
NIST 800-73-4 defines additions bits in first pin policy byte.
When one of these bit is set, and the policy prefers the Global pin,
it is not recognized and the local pin is used.
On branch PIV-global-pin-bug
Changes to be committed:
modified: src/libopensc/card-piv.c
Update the ATR table for PIV/CAC matrix to 2019 -10-18 version:
https://www.cac.mil/Portals/53/Documents/DoD%20Token%20utilziation%20and%20variation%20matrix%20v2_06_17October2019.docx?ver=2019-10-18-102519-120
Also update table for several PivKey cards, and added ATR for IDEMIA PIV 2.4.1.
But did not update for use of SM or VCI.
Yubico changed the ATR historical data for Yubikey 5 NFC. Code was added to recognize
it, when used with USB or NFC.
Note: Yubikey 5 NFC when used with NFC cant use touch policy. NFC reader may not provide
enough power to power the LED on button.
On branch PIV-update-DOD-Yubikey
Changes to be committed:
modified: card-piv.c
The previous erase sequence did not always work. For example:
% pkcs15-init -C
Using reader with a card: Feitian ePass2003 00 00
New User PIN.
Please enter User PIN: 1234
Please type again to verify: 1234
Unblock Code for New User PIN (Optional - press return for no PIN).
Please enter User unblocking PIN (PUK):
Failed to create PKCS #15 meta structure: Security status not satisfied
% pkcs15-init -E
Using reader with a card: Feitian ePass2003 00 00
Failed to erase card: Security status not satisfied
This apparently bricked many people's ePass2003 devices:
https://github.com/OpenSC/OpenSC/issues/767https://sourceforge.net/p/opensc/mailman/message/33621883/https://github.com/OpenSC/OpenSC/wiki/Feitian-ePass2003
Feitian provided a proprietary binary blob called `FIX_TOOL' to recover
devices from this state, but declined to offer source code when asked:
https://download.ftsafe.com/files/ePass/Fix_Tool.tar.gzhttps://download.ftsafe.com/files/reader/SDK/Fix_Tool_20200604.zip
With reverse-engineering help by Saleem Rashid (@saleemrashid on
Github), I was able to find the sequence of three APDUs that the tool
submits to the device to erase it. The mechanism seems to be:
1. Install a magic PIN. This is like install_secret_key, as used by
internal_install_pin, but with a few different magic constants.
2. Verify the magic PIN.
3. Delete the MF file, without selecting anything first.
With this patch, `pkcs15-init -E' successfully erases my ePass2003, and
I am able to initialize it with `pkcs15-init -C -p pkcs15+onepin' if I
set both a user pin and a PUK. (This patch does not prevent the
ePass2003 from getting into the state which could not be erased by the
old erase sequence.)
Vincent JARDIN
Jakub Jelen
Peter Popovec
Doug Engert
Frank Morgner
alt3r 3go
ihsinme
rickyepoderi
w00475903
Anton Logachev
Taylor R Campbell