10.2 Secure Biometric Match-On-Card
All changes in this version
Title changed
Before · SP 800-116
Secure Biometric Match-On-Card
After · SP 800-116 Rev. 1
Secure Biometric Match-On-Card
Control changed
Before · SP 800-116
FIPS 201 defines the biometric authentication mechanisms BIO and BIO-A. According to these definitions, the PIV reference template object is stored on the PIV Card during issuance. When a PIV Card is inserted into a contact biometric reader and the PIN has been entered, the biometric reader can read the reference template object from the PIV Card. The subject presents a finger to a fingerprint scanner on the biometric reader, and the reader acquires a sample template from the scan. The reader then performs the matching algorithm comparing the reference and sample templates, and produces a Yes or No response. This is known as Match-Off-Card biometric authentication. Biometric Match-On-Card is similar, but performs the match on the PIV Card instead of on the reader. To do this, the sample template must be sent to the reader, but the reference template need not leave the PIV Card. Secure Biometric Match-On-Card combines Biometric Match-On- Card with a secure communication protocol that encrypts the sample template as transmitted into the PIV Card, and signs a Yes or No result returned to the reader. Secure Biometric Match-On-Card (SBMOC) has important benefits over Match-Off-Card. Communication of sensitive biometric data is always encrypted and can be decrypted only by the PIV Card. The subject’s reference template is never released from the PIV Card. The biometric match is performed in the trusted execution environment of the PIV Card. ISO/IEC 7816 secure messaging commands and asymmetric cryptography mean that only the PIV Card can decrypt the biometric data and sign the result. [ISO/IEC7816] Moreover, the cardholder PIN is not required to perform the transaction. Because of the secure communication protocol and no PIN requirement, SBMOC can be performed safely and quickly over a contactless interface. Finally, because the match is performed on the PIV Card, the card knows and can use the result of the match. NIST recently completed the Secure Biometric Match-On-Card Feasibility Study, as reported in NISTIR 7452 [SBMOC] and the companion MINEX II report [MINEXII]. The results of the SBMOC study show 17 cards successfully implemented the functionality and security requirements of the study, and met the 2.5 second transaction time goal. The MINEX II results indicate that one of the tested cards approached the accuracy of ANSI 378 matching algorithms, thereby exceeding the accuracy requirements of FIPS 201 as defined in [SP800-76]. Three additional smart cards and Match-On-Card algorithms met some, but not all, of the criteria. Recommendation: SBMOC should be pursued as a standard FIPS 201 authentication mechanism, especially for PACS. Assuming it is judged to be at least as trustworthy as PIN entry, SBMOC should be allowed to substitute for PIN to activate a PIV Card. Appendix A—R ecommendations
Section 2.2 Recommendation: The OMB Memorandum [M-08-01] requires that the credential issuance be accomplished by October 27, 2008 (or by the date specified in the implementation plan mutually agreed-upon by the agency and OMB). Agency implementation plans should be written to accomplish the goals of HSPD- 12. Section 2.3 Recommendation: This document recommends a risk-based approach for selecting appropriate PIV authentication mechanisms to manage physical access to Federal government facilities and assets. Agencies should seek recommendations on PACS architectures, authorization, and facility protection from other sources. Section 4.9 Recommendation: This section emphasizes the technical risks that remain with the CHUID authentication mechanism. If the CHUID authentication mechanism were implemented without restriction, operational risk would increase as the value of targets and the availability of cloning and counterfeiting tools increase. NIST therefore recommends that the CHUID authentication mechanism be implemented in only two situations: 1) access control points separating two areas at the same impact level, either Controlled or Limited; and 2) combined with the VIS authentication mechanism at access points between Unrestricted and Controlled areas. See Section 7 for further detail. NIST further recommends that the asymmetric CAK authentication mechanism be used instead of the CHUID authentication mechanism to the greatest extent practical. Section 6.1 Recommendation: To obtain the full benefit of PIV interoperability, HSPD-12 project managers should ensure that relying systems have the capability to use all cryptographic algorithms that apply to the authentication mechanism(s) performed. Departments and agencies should procure and deploy HSPD-12 products on the GSA HSPD-12 Evaluation Program Approved Products List where applicable, and can use the PIMM presented in Section 9 to measure progress toward the goal of interoperability. [FIPS 201 Evaluation Program] Section 6.2 Recommendation: Once all appropriate authentication mechanisms are satisfied, all access control decisions are made by comparing the 14 decimal digit FASC-N Identifier, and optionally the values of additional FASC-N fields, against the ACL entries. Recommendation: As agencies develop risk-based implementation plans, they will create and evolve plans for PIV Card issuance and application integration. They might consider which of the eight qualities are most relevant to agency goals and priorities, and derive further project objectives, metrics, and milestones from those qualities. They should also consider the relation of HSPD-12 to FISMA requirements, and examine the potential for cost tradeoffs where PIV can replace more expensive authentication methods. Section 6.3 Recommendation: Operational metrics should be designed to measure actual benefits over the operational lifetime of the PIV System. They may be derived by formulating each of the expected benefits above as a service quality metric, e.g., for “integrated system”, service quality could be defined as the fraction of PACS registrations that are performed automatically by provisioning from the PIV issuance system. Section 6.4 Recommendation : Maximum benefit will be obtained from the PIV System when it is adequately supported by infrastructure. Infrastructure upgrades may be justified, especially to improve communication among PACS system elements (e.g., support two way communication). Section 7.1 Recommendation: NIST strongly recommends that every PIV Card contain an asymmetric CAK and corresponding certificate, and that PACS use an asymmetric challenge/response CAK protocol. Recommendation: PACS should always verify the digital signature on the biometric template data object, and do path validation, before performing a match. Otherwise, the result of the match should not be trusted. Recommendation: Biometric readers, especially those used at access points to Limited and Exclusion areas, should have a proven capability to accept live fingers and reject artificial fingers. Biometric readers, especially unattended readers in an Unrestricted area, should be physically hardened to protect against direct electrical compromise. Section 7.3 Recommendation: Authentication assurance will be increased if a PACS uses relevant information from previous access control decisions (“context”) when making a new access control decision. For example, if a cardholder attempts to pass from a Controlled to a Limited area, the PACS could require that the cardholder was recently allowed access to the Controlled area. Historically, rigorous implementation of this concept required person-traps and exit tracking, but partial implementations have significant value, and could be strengthened by new technology and systems integration. Section 7.4 Recommendation: When a PIV Card is terminated, the PCI must revoke all valid authentication certificates for the PIV Card. The authentication certificates include the PIV Authentication Key certificate and the Card Authentication Key certificate (if present). Recommendation: The CHUID may be collected at registration, but it should be treated as if it were a password for purposes of retention, i.e., hashed, the hash stored, and the CHUID deleted. A stored CHUID presents risks similar to a stored password; it can be copied and used to gain access. Data elements may be extracted from the CHUID and retained (e.g., the FASC-N, DUNS Number, and GUID), and a retained hash is sufficient to enable verification. NIST strongly recommends against the storage of complete CHUIDs in relying systems. Recommendation: PKI and asymmetric CAK authentication mechanisms should be implemented by a PACS reader capable of full certificate path validation, either on-line or using a caching status proxy. Agencies should consider using on-line status checks as a means to reduce the latency of PIV Card status when a PIV Card is used for access to Exclusion areas. If a caching status proxy is used, the certificates should be captured when the PIV Card is registered to the PACS.
Section 7.5 Recommendation: On-line credential validation should be implemented for all of the FIPS 201 authentication mechanisms whenever possible. It is especially important when the one-factor, non-biometric mechanisms (CHUID, CAK) are used, because they could be exploited by simple possession of a misappropriated PIV Card. Caching techniques can be used to implement credential validation when on-line, on-demand credential validation is not possible. It is also recommended that the cached data be protected against tampering. Recommendation: Path validation should be performed on all signed data objects required by the authentication mechanism in use. Path validation should employ on-line credential validation where possible, or cached certificate status where on-line certificate validation is not possible. Section 8.6 Recommendation: Because having on-card role and permission information would raise difficult challenges concerning update and revocation, PACS permissions should generally be stored in a PACS facilities-based component, such as a panel or controller database. Section 10.1 Recommendation: Agencies should collaborate to standardize an enhancement or replacement of the FASC-N that accomplishes both credential identification and object binding, and supports an extensible framework for subject identification. Section 10.2 Recommendation: SBMOC should be pursued as a standard FIPS 201 authentication mechanism, especially for PACS. Assuming it is judged to be at least as trustworthy as PIN entry, SBMOC should be allowed to substitute for PIN to activate a PIV Card. Appendix B—P IV Uniqueness
All access control decisions are made by comparing a FASC-N Identifier, which includes Agency Code, System Code, and Credential Number, against the ACL entries. Optionally, the values of additional FASC-N fields may also be compared. An ACL pattern may match the entire FASC- N, just the Agency Code, or the Agency Code and System Code (e.g., all PIV Cards issued to one agency, or to one site in one agency) without introducing dangerous collisions or ambiguities across agencies. In other words, an individual’s FASC-N Identifier is unique among all cardholders when the complete three element subset of the FASC-N is used for comparison. There will be no collisions since all the cardholders have been assigned unique numbers. This restricts the access control comparison to one of three cases: 1. the Agency Code alone (i.e., all PIV Cards with the same Agency Code are accepted); 2. the Agency Code and System Code only (i.e., all PIV Card with the same Agency Code and System Code are accepted); or 3. the Agency Code, System Code, and Credential Number (i.e., a uniquely identified PIV Card). Any of these cases may also include comparison of additional FASC-N values such as the Credential Series, Individual Credential Issue, Organizational Identifier, or Person Identifier. The FASC-N data fields are defined as fixed length values of Binary Coded Decimal digits. The complete subset of three data fields is 14 decimal digits in length, as stored on the PIV Card. Other representations of the FASC-N Identifier, for example a binary representation, may be used off-card, provided that they are isomorphic with respect to pattern matching. The following examples demonstrate the possible uses of FASC-N in a PIV-enabled PACS application.
B.1 Full FASC-N Comparison
The following table shows a successful match against an ACL pattern consisting of a full FASC- N comparison. These examples show an organization-specific access control policy that includes the comparison of all FASC-N fields. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 3728 System Code 8377 8377 Credential Number 123456 123456 Credential Series 1 1 Individual Credential Issue 1 1 Person Identifier 1234567890 1234567890 Organizational Category 1 1 Organizational Identifier 0010 0010 Person/Organization Association Category 1 1 The following table shows an unsuccessful match against an ACL pattern consisting of full FASC-N comparison. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 3728 System Code 8377 8377 Credential Number 123456 234567 Credential Series 1 1 Individual Credential Issue 1 1 Person Identifier 1234567890 1234567890 Organizational Category 1 1 Organizational Identifier 0010 0010 Person/Organization Association Category 1 1
B.2 FASC-N Identifier Comparison
The following table shows a successful match against an ACL pattern consisting of one specific FASC-N Identifier. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 3728 System Code 8377 8377 Credential Number 123456 123456
The following table shows an unsuccessful match against an ACL pattern consisting of one specific FASC-N Identifier. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 3728 System Code 8367 8377 Credential Number 123456 123456 B.3 Partial FASC-N Comparison
The following table shows a successful match against an ACL pattern consisting of an Agency Code and the System Code. The “x” symbols represent “don’t care” decimal digits. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 3728 System Code 8391 8391 Credential Number 654321 xxxxxx
The following table shows an unsuccessful match against an ACL pattern consisting of an Agency Code and the System Code. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3628 3728 System Code 8377 8377 Credential Number 123456 xxxxxx
The following table shows a disallowed pattern that is not an initial string of the FASC-N Identifier. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 37xx System Code 8377 83xx Credential Number 123456 xxxxxx
B.4 Isomorphic FASC-N Comparison
The following table shows a successful match against an ACL pattern, with the FASC-N Identifier and the upper and lower bounds of the ACL pattern represented in hexadecimal. The match succeeds because the presented FASC-N Identifier is in the closed interval [LB, UB]. This example is the same as the MATCH example of B.2, with a shift in representation from decimal to hexadecimal. FIELD VALUE PIV Card FASC-N ACL Pattern LB ACL Pattern UB Hexadecimal Value 21E9E156BBB1 21E9DBE03300 21E9E1D613FF The following table shows an unsuccessful match against an ACL pattern, with the FASC-N Identifier and the upper and lower bounds of the ACL pattern represented in hexadecimal. The match fails because the presented FASC-N Identifier is not in the closed interval [LB, UB]. This example is the same as the NO MATCH example of B.2, with a shift in representation from decimal to hexadecimal. FIELD VALUE PIV Card FASC-N ACL Pattern LB ACL Pattern UB Hexadecimal Value 21010BD3F280 21E9DBE03300 21E9E1D613FF Appendix C—P ossible PIV Authentication Mechanisms in PACS
The following list provides a complete list of possible PIV authentication mechanism combinations that are available for application to Federal facilities. The table entry contains PIV authentication mechanisms used to cross from Unrestricted to Controlled to Limited to Exclusion. The following acronyms are used in the table: CV – CHUID + VIS CAK – Card Authentication Key BIO – Biometric BIO-A – Biometric in Attendance PKI – PIV Authentication Key CPB – CAK + BIO combined or CAK + BIO-A combined The table below provides all possible applications of PIV authentication mechanisms, progressing from Unrestricted to Exclusion areas. Note that the table includes individual PIV authentication mechanisms except for the combination of CV and CPB. Other PIV authentication mechanisms combinations can also be derived. The arrows in the above table represent the possibility of crossing multiple levels at an Access Point. For example, the arrow on Line 6 shows that CPB may be used to access Limited or Exclusion areas.
Access Point A (Controlled) Access Point B (Limited) Access Point C (Exclusion)
After · SP 800-116 Rev. 1
FIPS 201 defines the biometric authentication mechanisms BIO and BIO-A. According to these definitions, the PIV reference template object is stored on the PIV Card during issuance. When a PIV Card is inserted into a contact biometric reader and the PIN has been entered, the biometric reader can read the reference template object from the PIV Card. The subject presents a finger to a fingerprint scanner on the biometric reader, and the reader acquires a sample template from the scan. The reader then performs the matching algorithm comparing the reference and sample templates, and produces a Yes or No response. This is known as Match-Off-Card biometric authentication. Biometric Match-On-Card is similar, but performs the match on the PIV Card instead of on the reader. To do this, the sample template must be sent to the reader, but the reference template need not leave the PIV Card. Secure Biometric Match-On-Card combines Biometric Match-On- Card with a secure communication protocol that encrypts the sample template as transmitted into the PIV Card, and signs a Yes or No result returned to the reader. Secure Biometric Match-On-Card (SBMOC) has important benefits over Match-Off-Card. Communication of sensitive biometric data is always encrypted and can be decrypted only by the PIV Card. The subject’s reference template is never released from the PIV Card. The biometric match is performed in the trusted execution environment of the PIV Card. ISO/IEC 7816 secure messaging commands and asymmetric cryptography mean that only the PIV Card can decrypt the biometric data and sign the result. [ISO/IEC7816] Moreover, the cardholder PIN is not required to perform the transaction. Because of the secure communication protocol and no PIN requirement, SBMOC can be performed safely and quickly over a contactless interface. Finally, because the match is performed on the PIV Card, the card knows and can use the result of the match. NIST recently completed the Secure Biometric Match-On-Card Feasibility Study, as reported in NISTIR 7452 [SBMOC] and the companion MINEX II report [MINEXII]. The results of the SBMOC study show 17 cards successfully implemented the functionality and security requirements of the study, and met the 2.5 second transaction time goal. The MINEX II results indicate that one of the tested cards approached the accuracy of ANSI 378 matching algorithms, thereby exceeding the accuracy requirements of FIPS 201 as defined in [SP800-76]. Three additional smart cards and Match-On-Card algorithms met some, but not all, of the criteria. Recommendation: SBMOC should be pursued as a standard FIPS 201 authentication mechanism, especially for PACS. Assuming it is judged to be at least as trustworthy as PIN entry, SBMOC should be allowed to substitute for PIN to activate a PIV Card. Appendix A—R ecommendations
Section 2.2 Recommendation: The OMB Memorandum [M-08-01] requires that the credential issuance be accomplished by October 27, 2008 (or by the date specified in the implementation plan mutually agreed-upon by the agency and OMB). Agency implementation plans should be written to accomplish the goals of HSPD- 12. Section 2.3 Recommendation: This document recommends a risk-based approach for selecting appropriate PIV authentication mechanisms to manage physical access to Federal government facilities and assets. Agencies should seek recommendations on PACS architectures, authorization, and facility protection from other sources. Section 4.9 Recommendation: This section emphasizes the technical risks that remain with the CHUID authentication mechanism. If the CHUID authentication mechanism were implemented without restriction, operational risk would increase as the value of targets and the availability of cloning and counterfeiting tools increase. NIST therefore recommends that the CHUID authentication mechanism be implemented in only two situations: 1) access control points separating two areas at the same impact level, either Controlled or Limited; and 2) combined with the VIS authentication mechanism at access points between Unrestricted and Controlled areas. See Section 7 for further detail. NIST further recommends that the asymmetric CAK authentication mechanism be used instead of the CHUID authentication mechanism to the greatest extent practical. Section 6.1 Recommendation: To obtain the full benefit of PIV interoperability, HSPD-12 project managers should ensure that relying systems have the capability to use all cryptographic algorithms that apply to the authentication mechanism(s) performed. Departments and agencies should procure and deploy HSPD-12 products on the GSA HSPD-12 Evaluation Program Approved Products List where applicable, and can use the PIMM presented in Section 9 to measure progress toward the goal of interoperability. [FIPS 201 Evaluation Program] Section 6.2 Recommendation: Once all appropriate authentication mechanisms are satisfied, all access control decisions are made by comparing the 14 decimal digit FASC-N Identifier, and optionally the values of additional FASC-N fields, against the ACL entries. Recommendation: As agencies develop risk-based implementation plans, they will create and evolve plans for PIV Card issuance and application integration. They might consider which of the eight qualities are most relevant to agency goals and priorities, and derive further project objectives, metrics, and milestones from those qualities. They should also consider the relation of HSPD-12 to FISMA requirements, and examine the potential for cost tradeoffs where PIV can replace more expensive authentication methods. Section 6.3 Recommendation: Operational metrics should be designed to measure actual benefits over the operational lifetime of the PIV System. They may be derived by formulating each of the expected benefits above as a service quality metric, e.g., for “integrated system”, service quality could be defined as the fraction of PACS registrations that are performed automatically by provisioning from the PIV issuance system. Section 6.4 Recommendation : Maximum benefit will be obtained from the PIV System when it is adequately supported by infrastructure. Infrastructure upgrades may be justified, especially to improve communication among PACS system elements (e.g., support two way communication). Section 7.1 Recommendation: NIST strongly recommends that every PIV Card contain an asymmetric CAK and corresponding certificate, and that PACS use an asymmetric challenge/response CAK protocol. Recommendation: PACS should always verify the digital signature on the biometric template data object, and do path validation, before performing a match. Otherwise, the result of the match should not be trusted. Recommendation: Biometric readers, especially those used at access points to Limited and Exclusion areas, should have a proven capability to accept live fingers and reject artificial fingers. Biometric readers, especially unattended readers in an Unrestricted area, should be physically hardened to protect against direct electrical compromise. Section 7.3 Recommendation: Authentication assurance will be increased if a PACS uses relevant information from previous access control decisions (“context”) when making a new access control decision. For example, if a cardholder attempts to pass from a Controlled to a Limited area, the PACS could require that the cardholder was recently allowed access to the Controlled area. Historically, rigorous implementation of this concept required person-traps and exit tracking, but partial implementations have significant value, and could be strengthened by new technology and systems integration. Section 7.4 Recommendation: When a PIV Card is terminated, the PCI must revoke all valid authentication certificates for the PIV Card. The authentication certificates include the PIV Authentication Key certificate and the Card Authentication Key certificate (if present). Recommendation: The CHUID may be collected at registration, but it should be treated as if it were a password for purposes of retention, i.e., hashed, the hash stored, and the CHUID deleted. A stored CHUID presents risks similar to a stored password; it can be copied and used to gain access. Data elements may be extracted from the CHUID and retained (e.g., the FASC-N, DUNS Number, and GUID), and a retained hash is sufficient to enable verification. NIST strongly recommends against the storage of complete CHUIDs in relying systems. Recommendation: PKI and asymmetric CAK authentication mechanisms should be implemented by a PACS reader capable of full certificate path validation, either on-line or using a caching status proxy. Agencies should consider using on-line status checks as a means to reduce the latency of PIV Card status when a PIV Card is used for access to Exclusion areas. If a caching status proxy is used, the certificates should be captured when the PIV Card is registered to the PACS.
Section 7.5 Recommendation: On-line credential validation should be implemented for all of the FIPS 201 authentication mechanisms whenever possible. It is especially important when the one-factor, non-biometric mechanisms (CHUID, CAK) are used, because they could be exploited by simple possession of a misappropriated PIV Card. Caching techniques can be used to implement credential validation when on-line, on-demand credential validation is not possible. It is also recommended that the cached data be protected against tampering. Recommendation: Path validation should be performed on all signed data objects required by the authentication mechanism in use. Path validation should employ on-line credential validation where possible, or cached certificate status where on-line certificate validation is not possible. Section 8.6 Recommendation: Because having on-card role and permission information would raise difficult challenges concerning update and revocation, PACS permissions should generally be stored in a PACS facilities-based component, such as a panel or controller database. Section 10.1 Recommendation: Agencies should collaborate to standardize an enhancement or replacement of the FASC-N that accomplishes both credential identification and object binding, and supports an extensible framework for subject identification. Section 10.2 Recommendation: SBMOC should be pursued as a standard FIPS 201 authentication mechanism, especially for PACS. Assuming it is judged to be at least as trustworthy as PIN entry, SBMOC should be allowed to substitute for PIN to activate a PIV Card. Appendix B—P IV Uniqueness
All access control decisions are made by comparing a FASC-N Identifier, which includes Agency Code, System Code, and Credential Number, against the ACL entries. Optionally, the values of additional FASC-N fields may also be compared. An ACL pattern may match the entire FASC- N, just the Agency Code, or the Agency Code and System Code (e.g., all PIV Cards issued to one agency, or to one site in one agency) without introducing dangerous collisions or ambiguities across agencies. In other words, an individual’s FASC-N Identifier is unique among all cardholders when the complete three element subset of the FASC-N is used for comparison. There will be no collisions since all the cardholders have been assigned unique numbers. This restricts the access control comparison to one of three cases: 1. the Agency Code alone (i.e., all PIV Cards with the same Agency Code are accepted); 2. the Agency Code and System Code only (i.e., all PIV Card with the same Agency Code and System Code are accepted); or 3. the Agency Code, System Code, and Credential Number (i.e., a uniquely identified PIV Card). Any of these cases may also include comparison of additional FASC-N values such as the Credential Series, Individual Credential Issue, Organizational Identifier, or Person Identifier. The FASC-N data fields are defined as fixed length values of Binary Coded Decimal digits. The complete subset of three data fields is 14 decimal digits in length, as stored on the PIV Card. Other representations of the FASC-N Identifier, for example a binary representation, may be used off-card, provided that they are isomorphic with respect to pattern matching. The following examples demonstrate the possible uses of FASC-N in a PIV-enabled PACS application.
B.1 Full FASC-N Comparison
The following table shows a successful match against an ACL pattern consisting of a full FASC- N comparison. These examples show an organization-specific access control policy that includes the comparison of all FASC-N fields. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 3728 System Code 8377 8377 Credential Number 123456 123456 Credential Series 1 1 Individual Credential Issue 1 1 Person Identifier 1234567890 1234567890 Organizational Category 1 1 Organizational Identifier 0010 0010 Person/Organization Association Category 1 1 The following table shows an unsuccessful match against an ACL pattern consisting of full FASC-N comparison. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 3728 System Code 8377 8377 Credential Number 123456 234567 Credential Series 1 1 Individual Credential Issue 1 1 Person Identifier 1234567890 1234567890 Organizational Category 1 1 Organizational Identifier 0010 0010 Person/Organization Association Category 1 1
B.2 FASC-N Identifier Comparison
The following table shows a successful match against an ACL pattern consisting of one specific FASC-N Identifier. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 3728 System Code 8377 8377 Credential Number 123456 123456
The following table shows an unsuccessful match against an ACL pattern consisting of one specific FASC-N Identifier. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 3728 System Code 8367 8377 Credential Number 123456 123456 B.3 Partial FASC-N Comparison
The following table shows a successful match against an ACL pattern consisting of an Agency Code and the System Code. The “x” symbols represent “don’t care” decimal digits. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 3728 System Code 8391 8391 Credential Number 654321 xxxxxx
The following table shows an unsuccessful match against an ACL pattern consisting of an Agency Code and the System Code. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3628 3728 System Code 8377 8377 Credential Number 123456 xxxxxx
The following table shows a disallowed pattern that is not an initial string of the FASC-N Identifier. FIELD NAME PIV Card FASC-N ACL FASC-N Pattern Agency Code 3728 37xx System Code 8377 83xx Credential Number 123456 xxxxxx
B.4 Isomorphic FASC-N Comparison
The following table shows a successful match against an ACL pattern, with the FASC-N Identifier and the upper and lower bounds of the ACL pattern represented in hexadecimal. The match succeeds because the presented FASC-N Identifier is in the closed interval [LB, UB]. This example is the same as the MATCH example of B.2, with a shift in representation from decimal to hexadecimal. FIELD VALUE PIV Card FASC-N ACL Pattern LB ACL Pattern UB Hexadecimal Value 21E9E156BBB1 21E9DBE03300 21E9E1D613FF The following table shows an unsuccessful match against an ACL pattern, with the FASC-N Identifier and the upper and lower bounds of the ACL pattern represented in hexadecimal. The match fails because the presented FASC-N Identifier is not in the closed interval [LB, UB]. This example is the same as the NO MATCH example of B.2, with a shift in representation from decimal to hexadecimal. FIELD VALUE PIV Card FASC-N ACL Pattern LB ACL Pattern UB Hexadecimal Value 21010BD3F280 21E9DBE03300 21E9E1D613FF Appendix C—P ossible PIV Authentication Mechanisms in PACS
The following list provides a complete list of possible PIV authentication mechanism combinations that are available for application to Federal facilities. The table entry contains PIV authentication mechanisms used to cross from Unrestricted to Controlled to Limited to Exclusion. The following acronyms are used in the table: CV – CHUID + VIS CAK – Card Authentication Key BIO – Biometric BIO-A – Biometric in Attendance PKI – PIV Authentication Key CPB – CAK + BIO combined or CAK + BIO-A combined The table below provides all possible applications of PIV authentication mechanisms, progressing from Unrestricted to Exclusion areas. Note that the table includes individual PIV authentication mechanisms except for the combination of CV and CPB. Other PIV authentication mechanisms combinations can also be derived. The arrows in the above table represent the possibility of crossing multiple levels at an Access Point. For example, the arrow on Line 6 shows that CPB may be used to access Limited or Exclusion areas.
Access Point A (Controlled) Access Point B (Limited) Access Point C (Exclusion)