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.
- update code signing credentials, thanks to Tim Wilbrink
- split up large files into 50 MB chunks for Nightly to avoid Github's file size limit
- codesign tools/libs with hardened runtime and entitlements
- avoid relocation of app bundles on installation
- sign installer for distribution
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
When failed to access reader, cxt needs to be released before
exiting the program. Like in the patch of CVE-2019-6502, a
sc_release_context(ctx) is needed before line 71, or a
memory leak may occur.
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.)