Implement support for Yubikeys and potential other tokens via wireless NFC using smartcard readers (Rebase) (#6895)
* Support NFC readers for hardware tokens using PC/SC
This requires a new library dependency: PCSC.
The PCSC library provides methods to access smartcards. On Linux, the third-party pcsc-lite package is used. On Windows, the native Windows API (Winscard.dll) is used. On Mac OSX, the native OSX API (framework-PCSC) is used.
* Split hardware key access into multiple classes to handle different methods of communicating with the keys.
* Since the Yubikey can now be a wireless token as well, the verb "plug in" was replaced with a more
generic "interface with". This shall indicate that the user has to present their token to the reader, or plug it in via USB.
* Add PC/SC interface for YubiKey challenge-response
This new interface uses the PC/SC protocol and API
instead of the USB protocol via ykpers. Many YubiKeys expose their functionality as a CCID device, which can be interfaced with using PC/SC. This is especially useful for NFC-only or NFC-capable Yubikeys, when they are used together with a PC/SC compliant NFC reader device.
Although many (not all) Yubikeys expose their CCID functionality over their own USB connection as well, the HMAC-SHA1 functionality is often locked in this mode, as it requires eg. a touch on the gold button. When accessing the CCID functionality wirelessly via NFC (like this code can do using a reader), then the user interaction is to present the key to the reader.
This implementation has been tested on Linux using pcsc-lite, Windows using the native Winscard.dll library, and Mac OSX using the native PCSC-framework library.
* Remove PC/SC ATR whitelist, instead scan for AIDs
Before, a whitelist of ATR codes (answer to reset, hardware-specific)
was used to scan for compatible (Yubi)Keys.
Now, every connected smartcard is scanned for AIDs (applet identifier),
which are known to implement the HMAC-SHA1 protocol.
This enables the support of currently unknown or unreleased hardware.
Co-authored-by: Jonathan White <support@dmapps.us>
2021-10-01 16:39:07 +02:00
|
|
|
# Copyright (C) 2021 KeePassXC Team <team@keepassxc.org>
|
|
|
|
#
|
|
|
|
# This program is free software: you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation, either version 2 or (at your option)
|
|
|
|
# version 3 of the License.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
# Use pkgconfig on Linux
|
|
|
|
if(NOT WIN32)
|
|
|
|
find_package(PkgConfig QUIET)
|
|
|
|
pkg_check_modules(PCSC libpcsclite)
|
|
|
|
endif()
|
|
|
|
|
|
|
|
if(NOT PCSC_FOUND)
|
|
|
|
# Search for PC/SC headers on Mac and Windows
|
2024-10-01 00:22:21 +02:00
|
|
|
|
|
|
|
# Additional search paths for Windows if not running in Visual Studio environment
|
|
|
|
if (WIN32)
|
|
|
|
# Resolve the ambiguity of using two names for one architechture
|
|
|
|
if(CMAKE_SYSTEM_PROCESSOR STREQUAL "AMD64" OR CMAKE_SYSTEM_PROCESSOR STREQUAL "x64")
|
|
|
|
set(ARCH_DIR "x64")
|
|
|
|
else()
|
|
|
|
set(ARCH_DIR "${CMAKE_SYSTEM_PROCESSOR}")
|
|
|
|
endif()
|
|
|
|
|
|
|
|
# Locate Windows SDK Paths
|
|
|
|
if (CMAKE_WINDOWS_KITS_10_DIR)
|
|
|
|
set(WINSDKROOTC_INCLUDE "${CMAKE_WINDOWS_KITS_10_DIR}/Include/${CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION}/um")
|
|
|
|
set(WINSDKROOTC_LIB "${CMAKE_WINDOWS_KITS_10_DIR}/LIB/${CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION}/um/${ARCH_DIR}")
|
|
|
|
else()
|
|
|
|
set(WINSDKROOTC_INCLUDE "$ENV{ProgramFiles\(x86\)}/Windows Kits/10/Include/${CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION}/um")
|
|
|
|
set(WINSDKROOTC_LIB "$ENV{ProgramFiles\(x86\)}/Windows Kits/10/LIB/${CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION}/um/${ARCH_DIR}")
|
|
|
|
endif()
|
|
|
|
endif()
|
|
|
|
|
Implement support for Yubikeys and potential other tokens via wireless NFC using smartcard readers (Rebase) (#6895)
* Support NFC readers for hardware tokens using PC/SC
This requires a new library dependency: PCSC.
The PCSC library provides methods to access smartcards. On Linux, the third-party pcsc-lite package is used. On Windows, the native Windows API (Winscard.dll) is used. On Mac OSX, the native OSX API (framework-PCSC) is used.
* Split hardware key access into multiple classes to handle different methods of communicating with the keys.
* Since the Yubikey can now be a wireless token as well, the verb "plug in" was replaced with a more
generic "interface with". This shall indicate that the user has to present their token to the reader, or plug it in via USB.
* Add PC/SC interface for YubiKey challenge-response
This new interface uses the PC/SC protocol and API
instead of the USB protocol via ykpers. Many YubiKeys expose their functionality as a CCID device, which can be interfaced with using PC/SC. This is especially useful for NFC-only or NFC-capable Yubikeys, when they are used together with a PC/SC compliant NFC reader device.
Although many (not all) Yubikeys expose their CCID functionality over their own USB connection as well, the HMAC-SHA1 functionality is often locked in this mode, as it requires eg. a touch on the gold button. When accessing the CCID functionality wirelessly via NFC (like this code can do using a reader), then the user interaction is to present the key to the reader.
This implementation has been tested on Linux using pcsc-lite, Windows using the native Winscard.dll library, and Mac OSX using the native PCSC-framework library.
* Remove PC/SC ATR whitelist, instead scan for AIDs
Before, a whitelist of ATR codes (answer to reset, hardware-specific)
was used to scan for compatible (Yubi)Keys.
Now, every connected smartcard is scanned for AIDs (applet identifier),
which are known to implement the HMAC-SHA1 protocol.
This enables the support of currently unknown or unreleased hardware.
Co-authored-by: Jonathan White <support@dmapps.us>
2021-10-01 16:39:07 +02:00
|
|
|
find_path(PCSC_INCLUDE_DIRS winscard.h
|
|
|
|
HINTS
|
2024-10-01 00:22:21 +02:00
|
|
|
${CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES}
|
|
|
|
/usr/include/PCSC
|
|
|
|
${WINSDKROOTC_INCLUDE}
|
Implement support for Yubikeys and potential other tokens via wireless NFC using smartcard readers (Rebase) (#6895)
* Support NFC readers for hardware tokens using PC/SC
This requires a new library dependency: PCSC.
The PCSC library provides methods to access smartcards. On Linux, the third-party pcsc-lite package is used. On Windows, the native Windows API (Winscard.dll) is used. On Mac OSX, the native OSX API (framework-PCSC) is used.
* Split hardware key access into multiple classes to handle different methods of communicating with the keys.
* Since the Yubikey can now be a wireless token as well, the verb "plug in" was replaced with a more
generic "interface with". This shall indicate that the user has to present their token to the reader, or plug it in via USB.
* Add PC/SC interface for YubiKey challenge-response
This new interface uses the PC/SC protocol and API
instead of the USB protocol via ykpers. Many YubiKeys expose their functionality as a CCID device, which can be interfaced with using PC/SC. This is especially useful for NFC-only or NFC-capable Yubikeys, when they are used together with a PC/SC compliant NFC reader device.
Although many (not all) Yubikeys expose their CCID functionality over their own USB connection as well, the HMAC-SHA1 functionality is often locked in this mode, as it requires eg. a touch on the gold button. When accessing the CCID functionality wirelessly via NFC (like this code can do using a reader), then the user interaction is to present the key to the reader.
This implementation has been tested on Linux using pcsc-lite, Windows using the native Winscard.dll library, and Mac OSX using the native PCSC-framework library.
* Remove PC/SC ATR whitelist, instead scan for AIDs
Before, a whitelist of ATR codes (answer to reset, hardware-specific)
was used to scan for compatible (Yubi)Keys.
Now, every connected smartcard is scanned for AIDs (applet identifier),
which are known to implement the HMAC-SHA1 protocol.
This enables the support of currently unknown or unreleased hardware.
Co-authored-by: Jonathan White <support@dmapps.us>
2021-10-01 16:39:07 +02:00
|
|
|
PATH_SUFFIXES PCSC)
|
|
|
|
|
|
|
|
# MAC library is PCSC, Windows library is WinSCard
|
|
|
|
find_library(PCSC_LIBRARIES NAMES pcsclite libpcsclite WinSCard PCSC
|
|
|
|
HINTS
|
2024-10-01 00:22:21 +02:00
|
|
|
${CMAKE_C_IMPLICIT_LINK_DIRECTORIES}
|
|
|
|
${WINSDKROOTC_LIB})
|
Implement support for Yubikeys and potential other tokens via wireless NFC using smartcard readers (Rebase) (#6895)
* Support NFC readers for hardware tokens using PC/SC
This requires a new library dependency: PCSC.
The PCSC library provides methods to access smartcards. On Linux, the third-party pcsc-lite package is used. On Windows, the native Windows API (Winscard.dll) is used. On Mac OSX, the native OSX API (framework-PCSC) is used.
* Split hardware key access into multiple classes to handle different methods of communicating with the keys.
* Since the Yubikey can now be a wireless token as well, the verb "plug in" was replaced with a more
generic "interface with". This shall indicate that the user has to present their token to the reader, or plug it in via USB.
* Add PC/SC interface for YubiKey challenge-response
This new interface uses the PC/SC protocol and API
instead of the USB protocol via ykpers. Many YubiKeys expose their functionality as a CCID device, which can be interfaced with using PC/SC. This is especially useful for NFC-only or NFC-capable Yubikeys, when they are used together with a PC/SC compliant NFC reader device.
Although many (not all) Yubikeys expose their CCID functionality over their own USB connection as well, the HMAC-SHA1 functionality is often locked in this mode, as it requires eg. a touch on the gold button. When accessing the CCID functionality wirelessly via NFC (like this code can do using a reader), then the user interaction is to present the key to the reader.
This implementation has been tested on Linux using pcsc-lite, Windows using the native Winscard.dll library, and Mac OSX using the native PCSC-framework library.
* Remove PC/SC ATR whitelist, instead scan for AIDs
Before, a whitelist of ATR codes (answer to reset, hardware-specific)
was used to scan for compatible (Yubi)Keys.
Now, every connected smartcard is scanned for AIDs (applet identifier),
which are known to implement the HMAC-SHA1 protocol.
This enables the support of currently unknown or unreleased hardware.
Co-authored-by: Jonathan White <support@dmapps.us>
2021-10-01 16:39:07 +02:00
|
|
|
endif()
|
|
|
|
|
|
|
|
include(FindPackageHandleStandardArgs)
|
|
|
|
find_package_handle_standard_args(PCSC DEFAULT_MSG PCSC_LIBRARIES PCSC_INCLUDE_DIRS)
|
|
|
|
|
|
|
|
mark_as_advanced(PCSC_LIBRARIES PCSC_INCLUDE_DIRS)
|