'PACE' is extremely card specific protocol and has not to be ostensibly
present in the common part of OpenSC:
* currently in OpenSC there is no card driver that supports or uses this protocol;
* amazing content of the common 'sc_perform_pace' -- beside the verbose logs
the only substantial action is to call the card/reader specific handler.
According to the current sources and the pull request 83
this 'common' procedure is called by the card driver or
card specific tool/operation.
* currently the 'PACE' can be thouroghly tested only by one person (Frank Morgner),
and only using the OpenSSL patched with the PACE specific patch.
So, at least a dedicated configuration option could be introduced when comiting PACE to the common part.
* common 'sc_perfom_pace' has the same role as the 'initialize-SM' handler of the existing SM framework
and can be implemented as card specific SM, as the others cards do.
This confirmed by Frank Morgner, the author of PACE commits and nPA card driver, himself.
(https://github.com/OpenSC/OpenSC/pull/83)
Implements PC/SC interface to PACE-enabled readers defined in PC/SC
pt. 10 AMD 1 and BSI TR-03119.
PACE can be started using `sc_perform_pace`. This function currently
calls the new `perform_pace` from `struct sc_reader_operations`, if the
reader has the needed capabilities. `sc_perform_pace` could also be
extended with a stand-alone implementation of PACE (code could be
imported from here http://vsmartcard.sourceforge.net/npa/README.html).
Note that the reader's PACE capabilities are correctly determined by
calling GetReaderPACECapabilities.
OpenSC's new PACE capabilities can be tested using the `npa-tool` from
the Virtual Smart Card Architecture (see link above).
The code that treated a timeout as success was never reached, because the
surrounding if eliminated the possibility of entering the block when the return code
from SCardGetStatusChange was SCARD_E_TIMEOUT.
Issue found by Coverity Scan.
Some pinpads do not support PIN size less than 4 or greater than 8.
PC/SC v2 part 10 allows to ask the driver/reader for the supported
values. This avoids to have the SECURE PIN CCID command rejected by the
reader.
This should fix OpenSC ticket #361 "card-entersafe should ask the pinpad
reader for the maximum pin size"
The timeout parameter of SCardGetStatusChange() is a DWORD (unsigned
int). An int timeout parameter was used instead.
The problem happens on 64-bits architectures where DWORD is 64-bits long
and int is only 32-bits long. The sign extension C mechanism transforms
the PC/SC value INFINITE into -1 instead of 4294967295.
See http://www.opensc-project.org/pipermail/opensc-devel/2011-June/016831.html
"Kobil KAAN Advanced Reader, "waiting for card" timeout"
On Mac OS X the HP smart card keyboard claims secure PIN entry support but the PIN is transmitted to host.
Disregard the pinpad flag for this reader. Other readers claiming pinpad support but having problems to follow in this list.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5273 c6295689-39f2-0310-b995-f0e70906c6a9
reader-pcsc.c: In function 'refresh_attributes':
reader-pcsc.c:339: warning: declaration of 'rv' shadows a previous local
reader-pcsc.c:273: warning: shadowed declaration is here
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5258 c6295689-39f2-0310-b995-f0e70906c6a9
reader-pcsc.c: In function 'refresh_attributes':
reader-pcsc.c:337: warning: declaration of 'state' shadows a previous local
reader-pcsc.c:272: warning: shadowed declaration is here
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5257 c6295689-39f2-0310-b995-f0e70906c6a9
* shift libpkcs11 from src/pkcs11 to src/common as it is not used to implement the OpenSC PKCS#11 module
* invent a "libscdl" mini library that implements either libltdl based dynamic loading or uses native interfaces
* drop hard requirement for libltl to build OpenSC
* native Windows build does not need libltdl any more
* specify CNGSDK include dir to find cardmod.h. CNGSDK only registers with a handful of compilers
Deals with #323
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5201 c6295689-39f2-0310-b995-f0e70906c6a9
The registry in no longer used to pass the
handles provided by BaseCSP. sc_ctx_use_reader
is used instead. (uses r5190)
A decryption routine was added as it is needed by login.
Key container names are based on the card serial
number and cert ID. The must be unique as they
are searched for in the certificate store to
find the card to insert in some situations.
If the handles change, the association to the reader
and card is refreshed as it may be a different card
or reader. (uses r5127)
Extra low lowel debugging was added. To use
it the CARDMOD_LOW_LEVEL_DEBUG but be defined in
cardmod.c This can log entries before and sc_context
is established.
The use of "texte" was replaced, as it looked like there
could be buffer overflows. It was replaced with a
loghex routine.
SC_ALGORITHM_RSA_HASH_MD5_SHA1 can now be used
(IE uses this.)
Several other bugs were fixed.
The code can now bue used for AD login, and was tested
with swaping cards duirng login, and with several readers.
The code is still experimental, and for login to work,
the dlls were moved to system32.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5192 c6295689-39f2-0310-b995-f0e70906c6a9
It is used by cardmod to pass in pointers to the PC/SC handles
provided by the caller of cardmod. Other drivers will return
an error if this routine called.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5190 c6295689-39f2-0310-b995-f0e70906c6a9
One of the few cards that has two different ATR-s is the EstonianEid card. The changing ATR (especially if
it has different protocol information and historical bytes) can cause confusion in many places, like
Microsoft BaseCSP or certain versions of pcsc-lite.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4890 c6295689-39f2-0310-b995-f0e70906c6a9
* One sc_context has only a single reader driver.
* remove dynamic reader driver loading capabilities
* remove opensc-tool -R command
* change the internal API, we don't need to pass around a "driver data" pointer as it can be found directly from the context.
* check in ./configure for only a single enabled reader driver
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4709 c6295689-39f2-0310-b995-f0e70906c6a9
From http://en.wikipedia.org/wiki/Malloc#Casting_and_type_safety
" Casting and type safety
malloc returns a void pointer (void *), which indicates that it is a
pointer to a region of unknown data type. One may "cast" (see type
conversion) this pointer to a specific type, as in
int *ptr = (int*)malloc(10 * sizeof (int));
When using C, this is considered bad practice; it is redundant under the
C standard. Moreover, putting in a cast may mask failure to include the
header stdlib.h, in which the prototype for malloc is found. In the
absence of a prototype for malloc, the C compiler will assume that
malloc returns an int, and will issue a warning in a context such as the
above, provided the error is not masked by a cast. On certain
architectures and data models (such as LP64 on 64 bit systems, where
long and pointers are 64 bit and int is 32 bit), this error can actually
result in undefined behavior, as the implicitly declared malloc returns
a 32 bit value whereas the actually defined function returns a 64 bit
value. Depending on calling conventions and memory layout, this may
result in stack smashing.
The returned pointer need not be explicitly cast to a more specific
pointer type, since ANSI C defines an implicit conversion between the
void pointer type and other pointers to objects. An explicit cast of
malloc's return value is sometimes performed because malloc originally
returned a char *, but this cast is unnecessary in standard C
code.[4][5] Omitting the cast, however, creates an incompatibility with
C++, which does require it.
The lack of a specific pointer type returned from malloc is type-unsafe
behaviour: malloc allocates based on byte count but not on type. This
distinguishes it from the C++ new operator that returns a pointer whose
type relies on the operand. (see C Type Safety). "
See also
http://www.opensc-project.org/pipermail/opensc-devel/2010-August/014586.html
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4636 c6295689-39f2-0310-b995-f0e70906c6a9
Fix
reader-pcsc.c: In function ‘pcsc_detect_readers’:
reader-pcsc.c:856: warning: initialization discards qualifiers from pointer target type
reader-pcsc.c:884: warning: initialization discards qualifiers from pointer target type
reader-pcsc.c:894: warning: initialization discards qualifiers from pointer target type
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4211 c6295689-39f2-0310-b995-f0e70906c6a9
* reduce to a few, supported functions.
* change all functions to take the debug level as parameter.
* use symbolic names for the debug levels.
* fix tools to pass "verbose"/"opt_debug" as ctx->debug.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4118 c6295689-39f2-0310-b995-f0e70906c6a9
Frank Morgner
Viktor Tarasov
Martin Paljak
Alon Bar-Lev
Ludovic Rousseau
Ludovic Rousseau
martin
ludovic.rousseau
dengert
vtarasov
flc
viktor.tarasov
aj