Fix various spelling errors, mostly in comments but also in texts displayed.
Errors found & interactively fixed using 'codespell', with additional manual
checks after the fixes.
Treat CardOS V5_0 and V5_3 cards differently then older versions:
Use card->dvr_data as a pointer to cardos_data_t to store private driver
data to pass internally, especially between set security environment
and the crypto operations. Sc_get_encoding_flags sets sec_flags from
algo_info->flags in pkcs15-sec.c and it passed to decipher.
Some cards when doing a decipher may drop leading 00 byte when
returning data from RSA_RAW decipher. Add leading byte(s) as needed.
Get Cryptographic Mechanism Reference from Key Reference:
Key reference byte appears to be a 4 bit Cryptographic Mechanism Reference
and a 4 bit key reference.
This is only done if key reference & 0xF0 != 0 i.e. default Cryptographic
mechanism reference is 0. which appears to be the case for RSA RAW.
PKCS1 appears to be 0x10 and ECDSA 0x30
See iso 7816-4 table 55 for DST:
84 Reference of a private key
95 Usage qualifier byte - Table 57 - 40 looks OK
80 Cryptographic mechanism reference and referes to section 9.2
The 4 bit key reference limits card to 16 keys. In future this may not work,
but we can derive a Cryptographic Mechanism Reference from what OpenSC
thinks the card needs to do. Only know RSA RAW, PKCS1 and ECDSA.
ECDSA code has not been tested, but expected to work.
Allow setting CardOS type and flags from opensc.conf using card_atr stanza
This is a fallback if newer cards are added or older cards have problems
giving us time to make need changes in next release.
It will help in identifying what flags are needed for each card.
As user can report what combination of flags work for them. They do this by
adding to opensc.conf with something like this. (Change the ATR to your card's ATR):
card_atr 3b:d2:18:00:81:31:fe:58:c9:03:16 {
driver = "cardos";
# type is decimal from cards.h:
# SC_CARD_TYPE_CARDOS_V5_0 is 1009
# SC_CARD_TYPE_CARDOS_V5_3 is 1010
type = 1010;
# flags is hex from opensc.h:
#define SC_ALGORITHM_ONBOARD_KEY_GEN 0x80000000
#define SC_ALGORITHM_NEED_USAGE 0x40000000
#define SC_ALGORITHM_RSA_RAW 0x00000001 /* RSA_RAW is PAD_NONE */
#define SC_ALGORITHM_RSA_PAD_NONE 0x00000001
#define SC_ALGORITHM_RSA_PAD_PKCS1 0x00000002 /* PKCS#1 v1.5 padding */
#define SC_ALGORITHM_RSA_PAD_ANSI 0x00000004
#define SC_ALGORITHM_RSA_PAD_ISO9796 0x00000008
#define SC_ALGORITHM_RSA_PAD_PSS 0x00000010 /* PKCS#1 v2.0 PSS */
#define SC_ALGORITHM_RSA_PAD_OAEP 0x00000020 /* PKCS#1 v2.0 OAEP */
#define SC_ALGORITHM_RSA_HASH_NONE 0x00000100 /* only applies to PKCS1 padding */
# example: SC_ALGORITHM_ONBOARD_KEY_GEN | SC_ALGORITHM_RSA_HASH_NONE | SC_ALGORITHM_RSA_RAW
flags = 80000101;
#example: SC_ALGORITHM_ONBOARD_KEY_GEN | SC_ALGORITHM_RSA_PAD_PKCS1
flags = 80000002;
}
For V5_0 and v5_3 cards, use sc_get_max_send_size and sc_get_max_recv_size
which takes care or reader sizes even on Windows where SCardControl can not get PART_10 sizes.
(commit eddea6f3c2 on Windows forces reader sizes to 255, 256
in reader-pcsc.c if not already set. It should not do this, but leave that up to card drivers.)
pkcs15-cardos.c added:
New file, pkcs15-cardos.c, added as emulation only for CardOS
V5_0 and V5_3 cards.
sc_pkcs15_bind_internal is called to get tokenInfo as CardOS
cards are substantially PKCS15 cards. But some V5_* cards have
errors in the tokenInfo, Which are corrected.
For older CardOS cards, card-cardos.c will create all the
card->algorithms.
Pkcs15-cardos.c will check for card->algorithms and if there
are none, it will do the following:
SC_CARDCTL_CARDOS_PASS_ALGO_FLAGS is called twice. First to get
the flags as set by user via opensc.conf card_atr or default
flags set by the card driver. Then after determining from the
tokenInfo what algorithms the card can support, the new flags
are passed to card_cardos.c to create card->algorithms.
https://atos.net/wp-content/uploads/2018/11/CT_181026_LPM_CardOS_V5-3_Multifunctionality_FS_en3_web.pdf
says card supports: "“Command chaining” in accordance with ISO/IEC 7816-4"
To take advantage of this with older readers, max_send_size and max_recv_size
is now based on minimum of reader limits and "data_field_length" from card.
This should allow card to work in older readers not capable of extended APDU.
So far current cards we have seen do no appear to support “Command chaining”.
Changes to be committed:
modified: src/libopensc/Makefile.am
modified: src/libopensc/Makefile.mak
modified: src/libopensc/card-cardos.c
modified: src/libopensc/cardctl.h
modified: src/libopensc/cards.h
new file: src/libopensc/pkcs15-cardos.c
modified: src/libopensc/pkcs15-syn.c
modified: src/libopensc/pkcs15-syn.h
The corresponding GET DATA command only returns the serial,
nothing else.
Tested with CardOS 5.0 and 5.3 cards. The serial number
is the same as shown with other tools
* Remove postecert and infocamere support because no longer issued
* Remove wrong changes
* reset NEWS
* EC_POINT_set_affine_coordinates_GFp and EC_POINT_get_affine_coordinates_GFp are
deprecated, use EC_POINT_set_affine_coordinates and EC_POINT_get_affine_coordinates
* If OPENSSL API version is < 3 use old functions EC_POINT_[sg]et_affine_coordinates_GFp
* Move the OpenSSL compatibility stuff to src/libopensc/sc-ossl-compat.h
As most of the drivers do not modify these, we can mark them as const.
Two drivers that we cannot convert are dnie and masktech.
section size
.data 35232 -> 25472
.data.rel.ro 36928 -> 46688
* Simplify CardOS 5.0 support (removing explicit 5.3 marker since the behavior should be the same)
* Restore RSA_PKCS signatures functionality
Closes https://github.com/OpenSC/OpenSC/pull/1079
* Set security context for CardOS 5.3 with p1=0x41 (as Coolkey does)
* Do not emulate signatures in CardOS 5.3
Remove the bogus SC_ALGORITHM_NEED_USAGE which prevents using the
actual implementation in cardos_compute_signature().
It might be bogus also in previous version, but I don't have a way
to verify against these cards.
* Do not advertise RSA-X-509 mechanism for CardOS 5.3 (card strips padding)
Since "Add GCC format checking attributes to log functions" commit GCC
warns us about problems with format strings and their arguments provided
to OpenSC message logging functions.
This commit fixes all cases where GCC warned about incorrect format on
64-bit Linux, 32-bit and 64-bit mingw builds (with SM and OpenSSL enabled).
Well, almost all since on mingw GCC does not recognize "ll" size specifier
(present at least since Visual Studio 2005, also in mingw own CRT) so these
(few) warnings about it remain.
In most cases format size specifier for size_t type was missing (usually
size was left at default int level, with is different on 64-bit x86).
Some formats had too few / too many arguments.
In some cases pointers were printed as integers.
Some long variables were missing "l" prefix (especially with regard to %x
format).
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
In set_security_env, the algorithmInfo structure (from the TokenInfo file of
PKCS#15) is parsed to see, what algorithm IDs are supported for signature
operations.
Using the information from AlgorithmInfo set in set_security_env when
computing signatures.
Fixed incorrect order of code blocks. If neither a reference to rsa_sig nor to
rsa_pure_sig is found in AlogirthmInfo, boths methods are enabled before (and
not after) trying pure_sig
Jakub Jelen
Peter Marschall
Frank Morgner
Doug Engert
Andreas Kemnade
opensignature
Priit Laes
Jakub Jelen
Maciej S. Szmigiero
Frank Morgner
Shaun Schutte
Viktor Tarasov
Jean-Pierre Szikora
mtausig
andre
ludovic.rousseau
vtarasov
martin