pcsc-lite is a Free Software implementation of the PC/SC (or WinSCard) API for Unix systems.
1.8.20: Ludovic Rousseau
30 December 2016
- Fix a crash and potential security issue in
TB2, if present, is global. The usage of TB2 is deprecated since the 2006 edition of the standard, which prescribes that cards should not include TB2 in the ATR, and readers shall ignore TB2 if present.
In the 1997 edition of the standard, TB2 (8th to 1st bit) encode PI2, which when in range 50..250 (other values being RFU) encode VPP in increments of 0.1 V, and subsumes the coarser indication given by PI1 of TB1. Refer to that section for why modern Smart Cards have no use of VPP, and thus of TB2.
Historical note: Provision for TB2 did not exist in ISO/IEC 7816-3:1989, and was introduced because VPP = 12.5 V became a popular value in EEPROM technology, replacing 25 V and 21 V.
Interface byte TA2, if present, is global, and is named the specific mode byte.
Presence of TA2 commands that the reader use specific mode as defined by TA2 and earlier global bytes, rather than negotiable mode when TA2 is absent.
TA2 encodes in its 4 low-order bits an integer T defining the protocol required by the card, in the convention used for TD1 (EMV prescribes that a card which T encoded in TA2 does not match that in TD1 shall be rejected).
The 5th bit is 0 to encodes that the required ETU duration is Fi/Di clock cycles as defined by TA1 (or its default value if absent); or 1 to indicate that the ETU duration is implicitly known (by some convention, or setting of the reader; EMV prescribes that such card shall be rejected).
The 6th and 7th bit are reserved for future use; 0 indicates not used.
The 8th bit is 1 to indicate that the card is unable to change the negotiable/specific mode (that is, does not propose other settings); or 0 to indicate that card has that ability (perhaps after a warm ATR).
Historical note: Provision for specific mode did not exist in ISO/IEC 7816-3:1989. Back then, the interface character TA2 had no particular name or function, and was specific (to the protocol introduced by TD1). ISO/IEC 7816-3:1997 introduced the specific mode and the specific mode byte, with interim note helping cards with specific mode byte TA2 in their ATR dealing with a reader that did not implement specific mode.
SCardGetStatusChange(): Fix a (rare) race condition
SCardReconnect()will never return
pam_smartcard(8) BSD System Manager's Manual pam_smartcard(8) NAME pam_smartcard -- Smartcard PAM module SYNOPSIS [service-name] function-class control-flag pam_smartcard [options] DESCRIPTION The Smartcard PAM module supports authentication function class. In terms of the function-class parameter, this is ``auth.'' The Smartcard Authentication Module This module permits or denies users based on smartcard authentication support in the Open Directory database, and the presence of an appropri- ate smartcard in the reader attached to the local machine. When a card is locked, the user is asked to unlock it with his PIN. The following options may be passed to this account management module: no_check_shell Continues evaluation even if user's shell is not valid. Normally, users with a shell like /usr/bin/false are considered as dis- abled. EXAMPLE Adding the following line on the top of the /etc/pam.d/sudo enables smartcard support for sudo: auth sufficient pam_smartcard.so SEE ALSO pam.conf(5), pam(8) SmartCardServices(7) BSD August 27, 2015 BSD
$ grep pam_smartcard /etc/pam.d/* /etc/pam.d/authorization_ctk:auth required pam_smartcard.so use_first_pass /etc/pam.d/screensaver_ctk:auth required pam_smartcard.so use_first_pass
$ cat /etc/pam.d/authorization_ctk # ctk: auth auth required pam_smartcard.so use_first_pass account required pam_opendirectory.so
$ cat /etc/pam.d/screensaver_ctk # ctk: auth auth required pam_smartcard.so use_first_pass account required pam_opendirectory.so account sufficient pam_self.so account required pam_group.so no_warn group=admin,wheel fail_safe account required pam_group.so no_warn deny group=admin,wheel ruser fail_safe
SmartCardServices(7) BSD Miscellaneous Information Manual SmartCardServices(7) NAME SmartCardServices -- overview of smart card support DESCRIPTION SmartCardServices is a set of components for OS X smart card support. Any smart card which supports the PIV standard is supported natively by OS X. Access to smart card items is possible using the keychain inter- face. Applications can install additional drivers for smart cards that are not natively supported. Smart card certificates are automatically added to user's keychain when a smart card is inserted. Smart card certificates can be listed with security using the list-smartcards or export-smartcard commands. Keychain Access GUI cannot be used to manipulate or list these certificates. SETUP To associate users with smart cards, the system can be set up for either fixed key mapping or attribute based mapping. For fixed key use sc_auth(8) or use the dialog which appears automatically when an unasso- ciated smartcard is inserted into a reader. This dialog can be globally suppressed by: sudo defaults write /Library/Preferences/com.apple.security.smartcard UserPairing -bool NO Attribute matching can be set up using the appropriate AttributeMapping section in the configuration file as described below. There is no default configuration. If no AttributeMapping exists or the configuration file is missing, attribute matching is not used. If both fixed key mapping and attribute mapping are able to associate the inserted smart card with a user, attribute mapping takes precedence. By default certificates do not need to be trusted to allow association. Certificate trust can be globally enforced by setting: sudo defaults write /Library/Preferences/com.apple.security.smartcard checkCertificateTrust -bool YES [...]
SecurityTokend-55111/SecurityTokend.xcodeproj/project.pbxproj | 6 ++++++ SecurityTokend-55111/lib/transition.cpp | 1 + SecurityTokend-55111/security_tokend_client/transition.cpp | 1 + 3 files changed, 8 insertions(+)
|OS X Version||SmartcardCCID||CCID|