I am using a somewhat modified version of IsoApplet. Up till now it worked fine. However recently I stumbled upon a web site that
forces a client cert auth with RSA-PSS. And (at least on windows, using minidriver) it didn't work. It looks to me, that it's a bug
in the PSS support code in minidriver, as I cannot find any place where a MGF1 padding scheme is specified. And since none is specified
signing fails. This patch fixes this. It assumes, that the same hash is used for hashing and padding.
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.
Use __FUNCTION__ as defind in log.h so will compile with any compiler.
logprint additional handles as size_t
Add check in reader-pcsc.c pcsc_user_reader for minidriver only.
On branch minidriver-5
Changes to be committed:
modified: src/libopensc/reader-pcsc.c
modified: src/minidriver/minidriver.c
Add MD_FUNC_CALLED(pCardData, level) and MD_FUNC_RETURN(pCardData, level, ...)
macros.
Handles are type __int3264 in VS2015 are casted as size_t when printing so
all bytes are printed. size_t on Windows are also treated as 32 or 64 bits.
SC_FORMAT_LEN_SIZE is used in the format.
(Works with VS2105 needs to be tested on other platforms.)
On branch minidriver-4
Changes to be committed:
modified: minidriver.c
Minidriver.c and reader-pcsc.c - reuse OpenSC reader structure
Windows CNG is managing the insertion and removal of the reader and the card
and will call CardAcquireContext and CardDeleteContext as needed if
the card or reader change. But different processes or threads may establish
different PCSC connects to the same reader and card but with different handles.
Reuse the OpenSC reader when windows uses the same reader but with different
handles. Tests show the certutil -v -scinfo works the same.
Associate_card is only need when called from
CardAcquireContext and disassociate_card is only need when called from
CardDeleteContext.
No need to call reinit_card_for(pCardData, name) just because the handles changed.
This may be the fix for #1763 because calls like CardCreateContainerEx remain
in card state rather then being lost when the handles changed.
Changes to be committed:
modified: src/libopensc/reader-pcsc.c
modified: src/minidriver/minidriver.c
Commit e5707b545e broke signing using minidriver on Windows.
More specifically changing #define SC_ALGORITHM_RSA_PAD_NONE from 0x00000000 to 0x00000001 caused a call to sc_pkcs1_encode() to fail as the padding algorithm was not specified anywhere in the CardSignData() implementation. It kind of worked as long as SC_ALGORITHM_RSA_PAD_NONE was 0x00000000, but the above mentioned commit broke this.
Now padding algorithm has to be explicitly specified, otherwise a call to sc_pkcs1_encode() will fail.
md_pinpad_dlg_allow_cancel now defines whether or not the user is asked
before verifying the PIN on the PIN pad. This can be denied without
interaction with the PIN pad. A checkbox in the dialog allows the user
to change this setting, which is saved in the registry by the path of
the process.
This change fixes the progress bar to match the actual configured
timout. The progressbar now fills instead of running empty, which seemed
less frightening for most users.
This change also fixes some copy/paste errors in the documentation of
opensc.conf(5).
Let sc_get_challenge() do sc_lock() and loop through the card driver's
get_challenge() until enough bytes were collected. The card driver's
get_challenge() now returns the number of bytes collected (less or equal
than requested) or an error code.
- Allow more code re-use.
- PIV driver now uses ASN.1 parser for reading the random bytes
CardDeleteContext may be called at any time, interrupting any ongoing
operation with the same PCARD_DATA. This leads to a race condition when
CardDeleteContext deletes, for example, the sc_context_t which the
interrupted call still wants to access. We have seen and fixed this
problem in https://github.com/OpenSC/OpenSC/issues/973 specifically for
the PIN entry process, however, it also applies to all other calls to
the md.
The new implementation removes the need for global data in the md.
In minidriver before performing a card operation we currently check whether
the supplied card handles have changed.
If they did the card in reader might have been changed so we reinitialize
it.
However, in few places in reinitialization call path an error returned by
some operation would leave the context in an inconsistent state.
So let's walk through this path to make sure that functions there will exit
cleanly if an error happens.
Also, make sure that all card operations that actually do something have
the necessary check call in the first place and also that they all
consistently check whether VENDOR_SPECIFIC pointer is not NULL before
dereferencing it.
This is a cleanup part of "Keep track of card resets by other contexts in
minidriver" (that is, it does not include the actual reset handling code
introduced by that commit), simplified.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Many cards need multiple PINs to work correctly since different on-card
keys are secured by different PINs (this is true for for example OpenPGP
card).
Smart Card Minidriver API has supported such cards since version 6.02
(Vista+).
Use the same method as PKCS#11 driver does to discover user and sign PINs,
for consistency.
However, if there is a default container on card we'll make sure that its
PIN is an user PIN and if there is no default container we'll mark the one
with the user PIN as default.
All other PINs securing containers on card are added as next PINs, up to
MD_MAX_PINS.
Use this opportunity to also fix two cases where a pointer-to-DWORD
variable was passed as pointer-to-size_t parameter to
md_dialog_perform_pin_operation() - they are of different size on Win64.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
- use UI framework
- timeout progressbar is running backwards
- cancelling is disabled by default
- removes card specific UI strings, use opensc.conf for that instead
- icon can be loaded by file
Pressing the cancel button in the PIN pad dialog should not close the
dialog. The application will still wait for the request to complete
even if the dialog is gone. Instead, we tell the user to press the
cancel butten on the PIN pad if the reader does not support SCardCancel.
When the dialog is shown in a separate thread and the user removes the
card, both, the thread for the pin pad operation and the main thread
are trying to access the card and context handles. Even worse, the main
thread deletes the context handle, which may result in a segmentation
fault for the thread with the pin pad operation.
- themable in the sense of using OS native design
- user messages on PIN pad dialog are identical to Base CSP, which still displays the dialog for PIN entry if no PIN pad is available
- adds progress bar to dialog
- Uses Smartcard icon extracted from DDORes.dll
- requires windows vista/windows server 2008 or above
- eac: allow CA without EF.CardSecurity
- sc-hsm: implemented CA based on document PKI
- sc-hsm: adds receive limit for SoC card
- introduces dedicated card type for SoC card
- md: integrate card's PIN pad capabilities
- installer: added SC-HSM SoC card to registry
- pkcs15-tool: Added support for PIN entry on card
- change/unblock PIN: add support for PIN entry on card
- added OpenPACE to macOS build
- travis-ci: install gengetopt/help2man via brew
- sc-hsm: Cache EF.C_DevAut
- sc-hsm: Prevent unnecessary applet selection and state resets
- sc-hsm: added support for session pin
- sc-hsm: avoid multiple AID selection
- sc-hsm: Use the information from match_card for all subsequent selections of the applet
- sc-hsm: cache optional files as empty files (Decoding the files will reveal that they were not existing prior caching. This avoids selecting the file though we have already tried to cache the file before.)
- use dedicated directory for CVC trust anchors
- appveyor: added OpenPACE to windows build
- pcsc driver takes over all the functionality
- no dedicated reader driver config values for cardmod, use application
specific blocks to define a different behavior for the pcsc reader if
needed
- removes legacy code; requiring at least libpcsclite 1.6.5
Fixes https://github.com/OpenSC/OpenSC/issues/892
According to minidriver specs CardReadFile() method output parameters are
optional so don't return SCARD_E_INVALID_PARAMETER when they are NULL.
Also, use this opportunity to walk through this function helpers to make
sure they correctly return error status.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
According to minidriver specs CardGetChallenge() method parameters
are purely for output and do not have a meaning of requested challenge
length, so remove a misleading log line.
There is also no need to have a special case for pcbChallengeData being
NULL since in this case the function would have exited early anyway with
SCARD_E_INVALID_PARAMETER (also, it was just dereferenced in the previous
code line).
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Since last commit GCC warns us about problems with format strings and their
arguments in minidriver, so let's fix these warnings just as we did in rest
of the OpenSC code.
Most of these warnings were about DWORDs being printed as ints, there were
also some format directives and size_t size specifiers missing and various
misc format / parameter disagreements.
Attempt was made to keep log strings as-is, only the most obvious typos
were fixed.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Commit "Add GCC format checking attributes to log functions" added format
and parameter checking to OpenSC log functions.
Minidriver, however, logs most of its output via a dedicated log function,
so this function needs such attributes, too.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Mingw currently links to msvcrt.dll as C runtime.
This library is documented by Microsoft as off-limits to applications and
its feature set vary between Windows versions.
Due to this, presence of particular printf() format string directives
depends on which Windows version the code is run.
This is, naturally, bad, so mingw developers introduced ability to replace
formatted output functions with built-in equivalents with defined feature
set by setting "__USE_MINGW_ANSI_STDIO" macro to 1.
There are, however, no built-in equivalents for "_s" suffixed functions.
Fortunately, they are used only a few times in minidriver so let's simply
replace them with equivalent code using standard functions.
This also allows skipping "MINGW_HAS_SECURE_API" macro definition so any
future uses will be caught by compiler.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Minidriver currently has basic support for unblocking card PIN by providing
PUK as an administrator password to CardUnblockPin() function.
However, this doesn't work for example when trying to unblock PIN via
system smartcard PIN unblock screen accessible after pressing Ctrl+Alt+Del
as it wants to use challenge / response authentication.
MS Smart Card Minidriver specification (version 7.07) explicitly says that
challenge / response is the only authentication mode that Windows uses to
authenticate an administrator.
Unfortunately, this way of unblocking PIN seems to not be widely supported
by cards.
However, we can simply treat the provided response to challenge as PUK.
Because (at least) Ctrl+Alt+Del PIN unblock screen accepts only hex string,
every PUK digit X has to be input as '3X' (without quotes) there.
Also the response string is not hidden behind asterisks on this screen as
it should been.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Luka Logar
Arya Senna
Peter Marschall
Doug Engert
Priit Laes
Frank Morgner
Jakub Jelen
Luka Logar
Maciej S. Szmigiero