System provided scards support #252
Conversation
|
@TheBestTvarynka Do you want to rebase or squash this PR? If rebasing, can you reword the commits? Thank you! |
|
On Windows, with mstscex, I'm always getting E_INVALIDARG (0x80070057):
I'm trying to use a Windows virtual smartcard device with this in my .RDP file, similar to what it would be without sspi-rs: username:s:@@BooZeoydRgfEwgrQROH1cL4sWZlA My environment variables: MSRDPEX_LOG_LEVEL=DEBUG |
|
From my testing in Windows, it is still checking all the WINSCARD_ environment variables required for virtual smartcards. I would have expected WINSCARD_USE_SYSTEM_SCARD=1 to be the only one required? I also expects the certificate file and key which makes no sense for the system-provided smartcard. |
|
Currently, only the winscard part pf the |
I would like to rebase this PR. Yes, I'll reword commits |
To support system-provided smart cards, we need to somehow access them from `sspi-rs`. On Windows, we will use native WinSCard API. We plan to use the `pcsc-lite` library on Linux and macOS; to do so, we need these bindings. _Why can't we just use the pcsc-sys crate?_ The main reason is that it links with the PCSC framework on macOS which was deprecated for years. _How the bindings work?_ The `sspi-rs` loads the pcsc-lite in the runtime, builds the functions table, and returns it to the user. It allows us to: * simplify build process; * replace the library in the runtime.
Added new methods for the `WinScard` and `WinScardContext` traits and implement them for the emulated smart card: `WinScard` trait: * `control_with_output`; * `reconnect`; * `get_attribute`; * `set_attribute`; * `disconnect`. `WinScardContext` trait: * `list_cards`; * `list_reader_groups`; * `calcel`; * `get_status_change`; * `get_card_type_provider_name`;
Now we can call system API to access system-provided smart cards. Also, the dynamic `winscard.dll` loading is implemented. We can't always use the `winscard-sys` crate, because if the `winscard.dll` is hooked (in the case of https://github.com/devolutions/msrdpex/), then the `winscard-sys` will just redirect calls to our library and we'll get a stack overflow. The system scards implementation is hidden under the `WinScard` and `WinScardContext` traits. The system scard is just another implementation of these traits.
_Implementation notes_ * Move the `clippy::undocumented_unsafe_blocks` lint to the `ffi/winscard` module lever instead of `ffi/winscard/system_scard`. Now all winscard-related code is checked. * Refactor the code and remove all panics. * Improve the memory management. _Memory management improvements_ Many winscard functions can treat the resulting data differently based on the input parameters. * When the input data pointer is `NULL`, we should write out data len in the input data len pointer. * When the input data length pointer value is `SCARD_AUTOALLOCATE`, we should allocate memory by ourselves, cast the output data pointer to pointer to pointer to memory, and write the memory address. * Otherwise, we copy the data and data length into corresponding pointers. And there are a lot of functions with such behavior. To simplify this process and reduce many `if`s/`match`s, We've introduced the `RequestBufferType` and `OutBuff` types. They are well documented, so you can read its description in the code. Moreover, we put the effort into keeping all memory management inside the `WinScardContexthandle` structure implementation. Now it's easier to manage the memory and search for problems if there are any.
…f_wide` functions (#251) Previously, these function always check that the data pointer is not `null`. But actually we need to check it only in the `OutBuffer::Allocated` case. Move this check into the corresponding `match` branch and updated the safety comment. Improve logging for the `WinScardContextHandle` and `WinScardHandle`.
TheBestTvarynka
force-pushed
the
feat/system-provided-scards-support
branch
from
d2257b4 to
041664c
Compare
@CBenoit, done! |
Hi,
In this PR I've implemented the system provided smart cards support. Now the user can use real smart cards using our library as well as emulated ones.
More information you can read in those pull requests descriptions:
save_out_bufandsave_out_buf_widefunctions #251Implementation notes
sspiloads all additional libraries (likelibpcscliteorwinscard.dll) in the runtime. Related discussion: PCSC-lite bindings #246 (comment).WinScardandWinScardContext. The system scard is just another implementation of these traits. Our custom FFI layer works only with high-lever Rust API. It gives us a few advantages:if/matchexpressions in the FFI layer.RequestBufferTypeandOutBufftypes to improve the memory management.Configuration
The user should set the
WINSCARD_USE_SYSTEM_SCARDenv variable with the value set totrueto use system-provided smart cards.The
sspilibrary uses the PCSC Lite library on Linux and macOS to access the system-provided smart card. This library is loaded in the runtime. The user can use thePCSC_LITE_LIB_PATHenv variable to specify thelibpcsclitelocation.The standard
WinSCardwill be used on Windows. But the user has an ability to confiture thewinscard.dlllocation using theWINSCARD_LIB_PATHenv variable. It can be helpful in situations when the originalwinscard.dllis hooked and we need to call the original one anyway.Demo
Using
mstscex:Windows.11.x64.smart.card.Running.-.Oracle.VM.VirtualBox.2024-06-10.18-18-28.mp4
Using
FreeRDP:Windows.11.x64.smart.card.Running.-.Oracle.VM.VirtualBox.2024-06-10.18-15-43.mp4
Note
Currently, only the winscard part pf the
sspi-rsis modified. Currently, our CredSSP implementation can use only the emulated smart card. We plan to improve the CredSSP module in next iterations.Docs & references:
winscard.hPCSC Litecc @awakecoding