Physical Access Control Systems and FIPS 201

Transcription

1 Physical Access Control Systems and FIPS 201 Physical Access Council Smart Card Alliance December This presentation was developed by the Smart Card Alliance Physical Access Council. The goals of the presentation are to: Provide an overview of the FIPS 201 PIV II requirements included in FIPS 201, SP , SP , and PACS 2.2 (or updated v. 2.3) that pertain to PACS. Provide a clear understanding on what the term FIPS 201 compliant means for PACS. Highlight open issues and make recommendations to overcome ambiguities and resolve issues to ensure interoperability and achievement of long-term FIPS 201 (government) goals. Clarify current government (NIST and GSA) FIPS 201 conformance testing requirements/plans for PACS. The Physical Access Council plans to review this presentation with the appropriate government agencies to discuss and resolve issues so that agencies are able to implement FIPS 201-compliant PACS more easily.

2 Topics Introduction: PACS Overview PIV Card PACS-Related Components PACS Readers PACS Panels & Hosts (Servers) PACS Infrastructure (Cabling, Communications and Interfaces) PACS & Biometrics Privilege Granting & Revocation PACS Certification & Accreditation Conclusions 2

3 Introduction: Traditional PACS System operator verifies an employee s identity according to organizational policy User credential is created and enrolled at PACS enrollment station Credential data and access privileges are downloaded to controllers database Readers at control points read data from credential and send data to controller for access decision 3 Traditional PACS Systems Control point functions Each access control point is configured as per ID requirement for the activity within the secured area. This could require a combination of PIN, card, biometric, two-person control, and or other action. Each access point is configured as to other events that may be required following a decision to grant or deny access. Enrollment process Employee identity is verified as per organizational policy. Employee is hired and ID badge/access credential is created. The PACS enrollment officer enrolls the ID badge/access credential to the PACS database and access privileges are registered to the credential. Enrollment may be permanent or valid until an expiration date/time occurs. At that time the server automatically removes from the controllers all access privileges for the individual s credential. Access to certain areas may require multiple identification methods. An employee who has access to areas with different identification requirements is enrolled and issued PIN for the ID card. When biometric identification is required, employee biometric is captured and written to the access card, or distributed to the biometric readers located at the access control points. Credential data is downloaded to relevant access control panels. Usage As the employee presents the card/pin to the access control point reader, the reader sends the card data to the controller. Controller verifies the credential with the entered PIN, makes the access grant/deny decision, and reports the event to the server. When the decision is to grant access, the door lock is released and the door may be opened. Deletion, Suspension The PACS enrollment officer may delete a credential from the system. In this case, all access privileges are instantly revoked and PIN and biometric records are removed. Some systems retain access log files of deleted credentials and some systems remove earlier transactions. Credentials may be suspended, meaning all access privileges are still registered in the system but are invalid until the enrollment officer reactivates the card.

4 1 Employee Enrolls Introduction: PIV Identity Verification and Issuance 2 Employer/ Sponsorship Employee Application 5 3 Approval Authority Identity Management System (IDMS) 6 Identity Verification 1:n 1:n biometric biometric search search Confirm Confirm employment employment ID ID validation validation through through standard standard government-wide government-wide services services (HSPD-11) (HSPD-11) Government Government databases databases Threat Threat risk risk 4 Enrollment 8 7 Card Production & Personalization PKI Infrastructure Issuer - Card Activation PIV Activated for Operational Use 4 Under HSPD 12, PIV I changes how employee identity is verified. ID badges/access credentials are created centrally.

5 Introduction: FIPS 201 PACS Relationship ID Records Personnel Data Card Management System Certificate Authority Bridge-Certified CA Identity Management System (IDMS) Employee A PIV cardholder arrives OCSP (or other means) confirms with IDMS that credential is still valid Enrollment officer confirms ID with PIV and biometrics Enrollment officer confirms access requirements PACS enrollment officer adds PIV card CHUID to PACS PACS enrollment officer registers physical access privileges to PACS Uses low or medium assurance profile PACS performs periodic validity checks with IDMS 5 FIPS 201 PIV I PACS must be connected to an IDMS and card management system (CMS) such that access privileges may be revoked centrally. In this scenario the process is as follows. Employee name and expiration date are downloaded to local PACS server. Employee arrives at the local facilities. Employee confirms the credential is still valid. Enrollment officer verifies access requirements for the employee. Enrollment officer locates employee s name in the PACS server database. Employee presents the PIV card to PACS enrollment station Enrollment officer registers the card to the physical access points as required for the individual. Access to areas requiring low, medium and high assurance levels may require additional enrollment steps. PACS server downloads the card data to relevant controllers. Usage Employee presents the PIV card to a PIV reader at the access control point. The PIV reader reads the PIV card data and sends the information to the controller for access grant/denied decision. The controller sends the information and decision the PACS server for archiving. Procedures for access to areas requiring high and very high assurance levels are undefined at the time of this writing. Deletion, Suspension PACS server database is updated periodically from the central IDMS and/or CMS. When a credential is revoked, the expiration date is changed and downloaded to the PACS server. The PACS server receives the expiration date, distributes this to the user record in the relevant controllers that will the make an access/deny decision for that employee's credential. This process may take up to 18 hours as per FIPS 201 guidelines. The PACS enrollment officer may manually revoke or change access privileges for an employee. This is a real-time process with instant change to the access privileges for the card.

6 Physical Access Control Systems and FIPS 201: PIV Card Components Physical Access Council Smart Card Alliance 6

7 PIV Card Issues/Recommendations FASC-N Usage Requirements How many of the FASC-N BCD digits (14 up to 32) need to be read/processed to be considered FIPS 201 compliant? Since PACS v2.2/2.3 states that a minimum of the first 14 BCD digits (Agency Code, System Code, and Credential Number) need to be used to ensure a unique number across the Federal Government, this should be the minimum required for FIPS 201 compliance. GUID Usage Requirements Cannot currently be relied on to be a unique number across the Federal Government. Guidance should be provided to PIV Issuers on using unique IPv6 addresses for the GUID. Since there is no currently established standard for assigning a GUID and its uniqueness cannot be ensured, it should only be used locally. 7 The data included on the PIV card intended for use in PACS is encoded in a container named the Cardholder Unique ID (CHUID). In a dual technology (two chip) card, the identical CHUID is encoded on both the contact and contactless smart chips. In a dual-interface (single chip) card, the CHUID is only encoded once, but it is accessible through either the contact or contactless interface. FASC-N Usage Requirements The CHUID consists of several mandatory data elements, which are the FASC-N, GUID, Expiration Date, and Asymmetric Signature. Provided that all PIV card issuers follow the guidance for encoding the FASC-N included in PACS v2.2/3, the FASC-N will be a unique number across the Federal Government. In fact the first 14 digits (Agency Code, System Code, and Credential Number) are enough to ensure this uniqueness. Therefore, the minimum requirement to meet FIPS 201 compliance should be to read and process these first 14 digits of the FASC-N. GUID Usage Requirements SP states, The Global Unique Identifier (GUID) field must be present, and may include either an issuer assigned IPv6 address or be coded as all zeros. The GUID is included to enable future migration away from the FASC-N into a robust numbering scheme for all issued credentials. However, since there is currently no specific guidance on how these IPv6 addresses will be distributed and assigned to create the GUID and it is not mandatory that unique numbers be encoded in the GUID field, the GUID cannot be relied upon as a unique number across the Federal Government. Therefore, if a PIV card issuer decides to encode a number in the GUID field and use it for PACS, they should understand that this should only be used with PACS within their issuing agency. Other PIV card issuers may encode only zeros in the GUID, so these PIV cards would not function in a PACS that is setup to use the GUID.

8 PIV Card Issues/Recommendations GUID Usage Requirements What is the timeframe for implementing this? Since OMB policy has set June 2008 as the date by which all agencies infrastructure (network backbones) must be using IPv6 and agency networks must interface with this infrastructure, this should be the target implementation date. Work should begin as early as possible to meet this target implementation date. Expiration Date Usage Requirements When and/or how often does this need to be checked? The PIV card contains multiple expiration dates (e.g., printed on the PIV card, inside CHUID, printed info buffer (optional), within PKI certificates). Expiration dates need to be synchronized. This should initially only need to be checked/validated at the time of initial registration and not at each access control event. 8 GUID Usage Requirements Because SP states, The GUID is included to enable future migration away from the FASC-N into a robust numbering scheme for all issued credentials, guidance needs to be provided on when this is intended to begin. Without a specific timeframe, manufacturers, integrators, and issuers cannot properly plan and prepare for this future migration. Since OMB policy has set June 2008 as the date by which all agencies infrastructure (network backbones) must be using IPv6 and agency networks must interface with this infrastructure, this should be the target implementation date. Expiration Date Usage Requirements FIPS 201 and SP specify multiple expiration dates to be printed and/or encoded on a PIV card. Some are mandatory (e.g., printed on the PIV card, inside the CHUID, and within the PIV Authentication Certificate) and others are optional (i.e., printed information buffer and within other PKI certificates). To avoid confusion with these various expiration dates, they should either be synchronized and/or clear guidance should be provided on when and/or how often they need to be checked. For example, with today s PACS technology, it is not practical to read all of these expiration dates prior to granting or denying access at a control point.

9 PIV Card Issues/Recommendations CHUID Asymmetric Signature Usage Requirements - When and/or how often does this need to be checked? The CHUID asymmetric signature should initially only need to be checked/validated at the time of initial registration and not at each access control event. At some later time this could be expanded as infrastructure matures. Card Authentication Key Usage Requirements - When and/or how should asymmetric keys be used in PACS? PACS 2.2/2.3 includes the use of symmetric keys for PACS in the high assurance profile, but does not include the use of asymmetric keys mentioned in FIPS 201 and SP To ensure interoperability, this needs to be made mandatory and the PACS document must be updated to include this as a PKI high assurance profile. 9 CHUID Asymmetric Signature Usage Requirements The CHUID Asymmetric Signature is intended to guarantee the integrity of the CHUID (i.e., that it has not been altered). However, FIPS 201 states that checking this signature is only optional. Current PACS technology does not support this option, but to avoid confusion, guidance should be provided on when and/or how often does this needs to be checked. We recommend that this should initially only need to be checked/validated at the time of initial registration and not at each access control event. At some later time this could be expanded as infrastructure matures. Card Authentication Key Usage FIPS 201 includes the option to include a Card Authentication Key on a PIV card and also allows for it to be either an asymmetric or symmetric key. Since this key is optional and can be either symmetric or asymmetric, implementations that use them cannot be interoperable. Guidance should be provided on when and/or how asymmetric keys should be used in PACS. PACS 2.2/2.3 includes the use of symmetric keys for PACS in the high assurance profile, but does not include the use of asymmetric keys mentioned in FIPS 201 and SP To ensure interoperability, we recommend that this needs to be made mandatory and the PACS document must be updated to include this as a PKI high assurance profile.

10 PKI High Assurance Profile: Strong, Standards-based Token Authentication Physical Access Council Smart Card Alliance 10 This section provides the basis for the recommendation of the Card Authentication Certificate for authentication in physical access systems.

11 Recommendation and Benefits to Use Certificates for Authentication Uses industry standard and FIPS 201 compliant authentication methods with x.509 certificates (Card Authentication Certificate) Uses asymmetric authentication that is already required to read CHUID signature (no additional requirements for reader functionality) Provides acceptable physical access performance with dual-interface credentials Card Authentication Certificate does not require use of PIN for high throughput physical access applications Provides common solution across Federal agencies Eliminates key management issues with Shared Secret Keys 11 At present the Card Authentication Certificate is optional under FIPS 201. The recommendation is to introduce the Card Authentication Certificate as a means of authentication for physical access. This slide goes through the rationale for the recommendation. The PIV Authentication Certificate, which requires a PIN, does not present a good option for logical access since the PIN requirement does not work with Windows log on and other aspects of the Windows operating system.

12 Current PACS 2.2/2.3 Authentication Profiles CHUID Low Assurance Free read data, sent to panel Small volume of data Low anti-counterfeiting, low anti-tampering CHUID Medium Assurance Free read data, subset sent to panel Medium volume of signed data Low to medium (with security guard observation) anti-counterfeiting, higher antitampering CHUID High Assurance Authentication key stored on card Key verified by readers/panels holding Site Secret Key (SSK) Can t use on a reader without a copy of an SSK Compromise of an SSK could permit batch counterfeiting SSK distribution/management challenges 12 This slide reviews the current assurance profiles for physical access and highlights issues/concerns with the various approaches. Low and medium are susceptible to counterfeiting. High assurance presents key management issues and difficulty in implementation of solution across the entire Federal government. Alternative proposed meets requirements for high security and high throughput without the drawbacks associated with the current authentication techniques.

13 PKI High Assurance Profile On-card generation of private key (RSA, ECC) Public key bound to card/fasc-n in X.509 certificate Standard card authentication certificate from SP , certificate profile from FICC Card verification without shared secrets (no SSK) Highest anti-counterfeiting Interoperation with logical security uses 13 The proposed alternative takes advantage of a number of features already in the FIPS documents while continuing to provide the benefits for security, throughput and anti-counterfeiting. In addition, the on-card generation of the private key provides maximum key security, maximum privacy and only exposes single key to compromise. Certificate suggestion takes advantage of a number of existing standards and specifications. Proposed physical access solution could be used by logical access applications to address constraint of required PIN with PIV Authentication Certificate.

14 PKI High Assurance Notes PKI-capable cards required (e.g., current dualinterface cards) Readers (or bi-directional panels) with real time clock and RSA/ECC signature verification required to use certificates (i.e., same level required for CHUID verification in medium profile) No on-card second factors (PIN, biometric) required for contactless use. Second/third factors would require use of contact interface (on-card) or panel-side match (i.e., same as the other profiles) 14 Recommendation is that the certificate be accessible through the contactless interface and that space be allocated to support this application. The certificate can exist either on the contactless component of a dual chip card or accessed through the contactless portion of a dual interface card. Provides an industry standard approach for the high security profile without the drawbacks associated with the current high assurance profile.

15 Physical Access Control Systems and FIPS 201: PACS Readers Physical Access Council Smart Card Alliance 15

16 PACS Readers: FIPS 201 Requirements FIPS 201 defaults to PACS 2.2 for access control low, medium and high assurance profiles. There is not a requirement to read and output the entire CHUID to open a door. Reading the entire CHUID would add more time to the actual transaction and could not all be processed by modern day access control systems. Enough information should be read to output either the FASC-N or the GUID and to be able to calculate the HMAC for a higher level of assurance. If the highest assurance security level is required, the reader will also need to be capable of symmetric or asymmetric keying. Another option would be passing the card certificate from the contact chip. Whether ISO is used for contactless or ISO 7816 is used for contact chips, output to the access control panels should remain the same since the same CHUID data is used through either interface. Read speed is not believed to be an issue if the system is only reading and outputting the FASC-N/GUID alone or with the HMAC. Read speed may be an issue with reading/verifying very large biometric images or meeting higher security assurance profiles. 16 NIST should consider updating FIPS 201 to reference PACS 2.3 or latest update. The NIST website has a demo video showing how the access control scenario would work. It shows the access reader passing the entire CHUID with digital signature and expiration date to the access control panel. This is not correct; the entire CHUID does not need to be passed to the panel. Most likely a PACS will use all or part of the FASC-N number for low assurance and all or part of the FASC-N with HMAC for medium. The medium profile adds some additional security so that someone cannot copy information from one card onto another card and use it. Both the low and medium profiles do not prevent someone from attempting to sniff the card and retransmit back the information. To easily mitigate this risk, a suggestion would be to add a simple PIN or biometric, making sniffing impossible. For higher security, the reader will need to be capable of symmetric or asymmetric keying; another option would be passing the card certificate. The trade-off for the higher security profile today is that it could make it more difficult for an interoperable solution. It should be noted that none of the three assurance profiles are 100% tamperproof. They all have vulnerabilities, but there are different ways to help reduce some of these vulnerabilities. Reader vendors should keep all of these options in mind while designing readers and should make them as flexible as possible as each installation could require something different. Whether ISO is used for contactless or ISO 7816 is used for contact chips, output to the access control panels should remain the same since the same CHUID data is used through either interface.

17 PACS Readers: Issues/Recommendations FIPS 201 defaults to PACS2.2 for access control, low, medium and high assurance profiles. NIST should consider updating FIPS 201 to reference PACS 2.3 or latest update. Readers can be configured to output many different configurations to the panel. The data that is output will be dependent on whether the agency is working with a legacy installation or new installation. For legacy installations, each access control vendor s system is different and may initially require different data imported from the reader. For new installations, a minimum set of data to be passed from the FASC-N or GUID should be specified (e.g., 16 GUID digits). 17

18 PACS Readers: Issues/Recommendations There has been no clear guidance from NIST or any government agency or committee on whether an access control card reader needs to go through conformance testing. There is an absolute need for NIST or some governing agency to publish a test data model set for an entire CHUID. Without an official data model set to test with, no reader vendor can truly build and test products to meet the SP "End Point" solution. This is an absolute must for the industry to deliver product in a timely manner. 18 The access control industry needs to know what, if any, products need to go through conformance testing and what that process will be. The access control industry needs sample cards with sample CHUID data models on them in order to fully test their solutions.

19 Physical Access Control Systems and FIPS 201: PACS Panels and Hosts (Servers) Physical Access Council Smart Card Alliance 19

20 PACS Panels & Hosts: Overview FIPS 201 does not specify requirements related to the physical access control system. Implementation is manufacturer specific. Interoperability between PACS is not part of FIPS and therefore still open to interpretation by individual agencies. There is a lack of formal protocol or standardization for the interface between PACS and IDMS. Industry should define the interoperability standard to support FIPS 201 functionality. 20 The FIPS-201 standard is specific to cards and the card/reader interface. Very little is said about PACS (or logical access control). Interoperability is between card and reader, not the reader and the PACS. Thus, all cards must be read by all readers, but not all readers will work with all PACS. Thus, it is up to manufacturers and customers to ensure that the PACS solution being implemented at any given location selects PACS and readers that are compatible.

21 PACS Panels: Overview Panels are configured by head-end (host), but can work standalone in offline mode to control door access. High throughput is required (e.g., turnstiles at start of shift). Cardholders are identified by matching card data from readers to cardholder data in panel database. Additional checks can be made on expiration date (either from card or from head end) and PIN. Connection to readers: Readers are connected to panel via Wiegand, RS-232/422/485, or other wired interface. Connection to head-end Card holder record including FASC-N fields or GUID, PACS expiration date, PIN, clearances 21 All decision-making regarding the status of the door is made by the panel, which can work offline, using configuration data (cardholder data, clearances, access rules) downloaded from host. Access transactions are sent to the host for display and journaling if the panel is online, or buffered locally if the panel is offline. Once the panel goes back online, buffered transactions are sent to the host. The reader can be connected directly to the panel, or to a door control module which is, in turn, connected to the panel. The door control module acts as a driver/repeater to increase distance between reader and panel, and also has additional input/output capability for controlling and monitoring doors; it does not, however, have any independent decision-making capability. All decisions to open or close doors is made by the panel. Connection between panel and host can be over the IT network, via high hard-wired serial interface (e.g. RS-485), or by phone line. Multiple methods may be used to provide redundancy should the primary connection fail.

22 PACS Panels & Reader Data There is a need to specify what data to use: FASC-N data or the full GUID. There are multiple data formats supported by the various reader vendors (e.g., 200-bit, 128-bit, 64-bit, 40-bit) For full interoperability across agencies, the reader FASC-N data should minimally include the following (14 digits) Agency (4 digits) System (4 digits) Credential (6 digits) For legacy applications, a fewer number of digits can be output, but the number will not be unique across Federal agencies and must be assessed for risk by local security manager. Optionally, for medium security applications, the reader can also output a Hashed Message Authentication Code (HMAC) which is used to verify that the card has not been modified since cardholder enrollment into the PACS Optionally, the reader can also output the card s expiration date 22 As there is no mandated interoperability between readers and panels, it is up to manufacturers, integrators, and customers to ensure compatibility between selected readers and PACS. Although the input parameters are defined, the algorithm used to calculate the HMAC is not and can vary across manufacturers. Thus, the same card presented to readers from various manufacturers, even if those readers are loaded with the same site key, may result in different HMAC values. It is thus recommended that readers utilizing the same algorithm (from the same manufacturer) be used for any given site key.

23 PACS Hosts (Servers): Overview The PACS host is the primary application for configuring, controlling, and disseminating information about the access infrastructure (particularly controlled doors) and the cardholders who have access privileges to those doors. The host has a configuration database, a cardholder database, administrative functions for configuring doors, readers, panels, clearances, schedules, cardholders, and other various features. All configuration activity is journaled for audit purposes. The host communicates to administrative clients, guard/monitoring station clients, and panels The host interfaces to the IDMS and other enrollment systems. 23 Host to IDMS interface is not defined by FIPS-201. It is up to manufacturers to define an interface for their application. Some customers will, and some customers will not, want direct interface to the IDMS. Given that, within the government space, there will be multiple and disparate IDMS/CMS s and multiple and disparate PACS. It is impractical to expect a web of connectivity connecting each possible IDMS/CMS to each PACS. Some customers will request a local enrollment solution whereby a cardholder visiting a facility for the first time will present their PIV-II card, and the information on that card will be authenticated and used to enroll the individual into the PACS. A means should also be provided to periodically check all cardholders against a certificate revocation list (CRL) or certificate authority (CA) and maintain/revoke access privileges as appropriate

24 PACS Hosts: Cardholder Database Name Privileges Clearances Card number data FASC-N data fields and/or GUID HMAC for medium security Other user-defined fields Expiration date Picture (This does not have to be in the database, but can be the path of a picture file.) 24 Privileges are defined by the local security manager, but can be revoked automatically based on an automated CRL/CA check. Expiration date does not have to be the same expiration date as on the PIV-II card, but should be no later than the PIV-II expiration date.

25 PACS Hosts: Cardholder Enrollment Enrollment GUI in the admin client allows data to be entered manually. Methods to interface to other applications IDMS used to issue the badge Local enrollment application where cardholders present their badges the first time they access the facility. A reader would read the card and populate the cardholder database with the data encoded on the card. A revocation list monitoring application can un-enroll a cardholder who appears on the revocation list. 25 There is currently no interoperability standard for PACS to IDMS/CMS/CA systems. Each manufacturer must provide an individual solution to meet the customer need.

26 Physical Access Control Systems and FIPS 201: PACS Infrastructure (Cabling, Communications & Interfaces) Physical Access Council Smart Card Alliance 26

27 C CR CRI CARD PACS Infrastructure: Issues / Recommendations CARD READER CARD READER INTERFACE Interface Points 1,2,3: Could be combined ACP Local Database ACCESS CONTROL PANEL LAN/WAN ADMIN or CLIENT WORKSTATION Relevant Issue: FIPS compliance does not imply PACS compliance and therefore confusion will result ; what is compliance? Recommendation: Minimum specifications for reader output should be more clearly defined based on open standards Relevant Issue: One way or two way reader communications with ACP Recommendation: Two way communications with readers are possible (and now also with Weigand data) and more secure but not addressed. Tools to crack Weigand available. Relevant Issue: Intelligent readers do not prevent physical attacks Recommendation: Employ tamper mechanisms to avoid physical attacks and provide guidance on door and hardware specs for high assurance applications 5 LAN/WAN IDMS PACS Server/ Database 27 I. Within the FIPS model and PACS 2.2/2.3 documentation, the primary focus is on the interface between the PIV card and the FIPS compliant card reader. The statement that FIPS compliance does not imply PACS compliance is meant to imply the following: that since the physical access control system (PACS) is not addressed, by design, then an approved or FIPS compliant reader, with current available guidance, will not, by default, provide guidelines for access control system vendors to clearly define the design criteria to be able to offer the community an interface that best communicates with the card reader. To offer guidance, it is recommended that reader outputs (bit length and protocol) be addressed in the near future. II. III. IV. As the necessity grows to communicate pertinent information or data to the reader once it is installed (such as updates from the outside world), the requirements for the readers to be able to communicate in both directions with the ACP (duplex) will become more important. This scenario will become more likely as the readers become more complex and require sophisticated software/firmware to comply with higher assurance profiles and the infrastructure to communicate with the smart card. As we continue to focus on the hardware and software that make the FIPS model and PACS 2.2/2.3 model a reality, we should never forget that this advanced hardware will ultimately be installed on a variety of door hardware and frame construction. That is, what good is it to provide a heavy duty lock on a door with a frame that cannot withstand the slightest pressure against a forced entry or prevent a reader from being removed and the data stream duplicated that is read by the ACP? Sniffing of data behind the reader (or on the secure side of the portal) is very possible and explained in detail at hacker conventions. The dotted line shown around the Card Reader Interface (CRI) and the Access Control Panel (ACP) implies that some vendors incorporate the functions of the CRI within the electronics of the ACP and as such may not depict a CRI in their product architecture.

28 C CR CRI CARD CARD READER PACS Infrastructure: Issues / Recommendations Interface Point 2 Could be combined CARD READER INTERFACE ACP Local Database ACCESS CONTROL PANEL LAN/WAN ADMIN or CLIENT WORKSTATION Relevant Issue: No established definition of a FIPS reader Recommendation: Provide fundamental interface requirements to permit minimum (open standards based) criteria for establishing basic output specs for compliant readers Relevant Issue: Degree or level of compatibility of FIPS compliant readers is not defined. How compatible is it? Recommendation: Establish levels of compatibility and compliance which are commensurate with the communications requirements to achieve low, medium and high assurance profiles; include guidance on one-way or two-way communications if necessary to comply with high assurance and PKI applications 5 LAN/WAN IDMS PACS Server/ Database 28 I. Definitions are key to proper and accurate interpretation. If all involved parties have the same definition of the key components of PACS system (using FIPS compliant readers), then interpretations become more uniform and standardization becomes readily possible. By establishing a definition of a FIPS reader and what constitutes a defined level of conformance to the established guidelines (especially when applied to assurance levels) then interoperability of FIPS readers and product selections can be made with less ambiguity. II. There is currently a flood of product announcements and statements by vendors of their currently available FIPS compliant readers. The prospective buyer is led to believe that compliance can be assured if purchased. If the buyer were to separate marketing hype from fact, is it truly compliant to the level anticipated? For example, one seeks to buy a ladder and the vendor offers to deliver one. Not having specified a specific height for the application, a ladder delivered that reaches six feet meets the specification but I find out later I need a twelve foot ladder to do the job. Is a ladder then a ladder? Technically yes, but unless guidance is provided for FIPS compatibility, there will be many FIPS products that may not be truly FIPS compliant for the application or assurance level required.

29 C CR CRI CARD CARD READER PACS Infrastructure: Issues / Recommendations Could be combined CARD READER INTERFACE Interface Point 2 cont d ACP Local Database ACCESS CONTROL PANEL LAN/WAN ADMIN or CLIENT WORKSTATION Relevant Issue: No established minimum outputs for compatibility with legacy systems Recommendation: Establish minimum default settings for legacy systems (based on standards) as well as minimum outputs to meet minimum future GUID requirements 5 LAN/WAN PACS Server/ Database IDMS 29 I. There are currently no available guidelines and governance documents that address the interface between the card reader and the access control panel relative to minimum outputs (for legacy systems) and for future migration to interpreting the GUID. II. If guidance is provided relative to legacy systems with future requirements for migration to the capabilities expected, then access control vendors can readily plan for migration support to comply with HSPD 12 and commercial off-the-shelf systems will be readily available without waiting for vendor redesign.

30 C CR CRI CARD CARD READER PACS Infrastructure: Issues / Recommendations Interface Point 3 Could be combined CARD READER INTERFACE ACP Local Database ACCESS CONTROL PANEL LAN/WAN ADMIN or CLIENT WORKSTATION Relevant Issue: Lack of security between reader and panel provides a weak link for PACS. RS232, RS485 & current loop are established asynchronous bi-directional forms of communications standards and can be made secure but are not addressed in any current guideline documents Recommendation: Consider encryption for medium and/or high assurance applications Relevant Issue: Card reader interface to ACP is typically proprietary Recommendation: Emphasis should be on CRI to card reader for open standards and minimum data requirements set for legacy systems and with migration guidelines for future proofing such as requirements for the GUID 5 LAN/WAN IDMS PACS Server/ Database 30 I. The current guidelines and governance documents do not address the security infrastructure that supports a FIPS card reader behind the mounting barrier of the reader. Physical tampering is possible and needs to be addressed to thwart such attacks. II. In addition to potential physical attacks, the current legacy defacto standards do not prevent data sniffing or tampering for compromising the data stream from the reader to the access control panel. III. Considerations for securing the communications between the reader and the control panel could include encryption technology as well as considering two-way communications to enhance challenge and response options. IV. As the CRI to ACP communication (whether the two component model or the CRI/ACP combined model) is the key link point between the FIPS card readers and the ACP, future guidance should focus on Interface Point 2 between the card reader (CR) and the card reader interface; or, for the combined model, between the card reader and the access control panel (ACP).

31 C CR CRI CARD 1 2 CARD READER PACS Infrastructure: Issues / Recommendations CARD READER INTERFACE Interface Point 4/5 Could be combined 3 ACP Local Database ACCESS CONTROL PANEL 4 4 LAN/WAN ADMIN or CLIENT WORKSTATION Relevant Issue: Data fields within the schema of the PACS database server are not identified and may not correlate to those in the CHUID fields for easy migration to the host from the IDMS. Every system will therefore have to be customized at a cost Recommendation: Establish a minimum set of data to be imported and the method of transfer for standardization Relevant Issue: (for example, XML). All systems would have same set There is much confusion on what is open and what is proprietary when PACS systems are evaluated and purchases are made on beliefs and assumptions 5 LAN/WAN IDMS PACS Server/ Database Recommendation: Clearly define what portions of the PACS are to be based on open standards and what does not have to be 31 I. For those applications where the IDMS will populate select fields of the PACS electronically, guidance should be provided such that a common and standard interface is defined. Along with this, a standard transmission methodology would provide for greater interoperability (such as XML). Once this transport solution is defined and specified, flexibility for PACS options will increase and migration and conversions could readily be accomplished without affecting the applications specific programming at the IDMS end. II. As PACS systems are evaluated and selected for implementation, it would be important to understand upfront which portions of the solution are truly based on open standards and which are proprietary to the vendor. This will provide guidance to the agency as to whether they are independent of the vendor for program development or bound to vendor specific services.

32 Physical Access Control Systems and FIPS 201: Biometrics Smart Card Alliance Physical Access Council 32

33 Biometrics An access control reader with biometric capability is required for assurance levels of high confidence or very high confidence NIST Special Publication provides interoperable biometric data specification for storage on the PIV card Requires storage of minutiae templates from two index fingerprints Templates must comply with ANSI-INCITS 378 standard Alternative fingers are allowed if index fingers cannot be imaged SP is in draft mode and is still subject to change 33 Biometrics are the automated measurement of a person s unique behavioral or biological characteristics for identification. Biometrics link an authentication event to a specific person rather than to a token, card or number. FIPS 201 envisions a multi-factored approach to authentication with layers added based on required levels of assurance. For the high confidence and very high confidence levels of assurance, FIPS 201 requires the use of biometrics in addition to other authentication mechanisms. Biometric data that is stored on the PIV card and required for interoperability between agencies is described under FIPS 201 through NIST Special Publication SP requires the storage of minutiae templates of two index fingers on the PIV card. These templates must comply with the International Committee for Information Technology Standards (INCITS) 378 Finger Minutiae Format for Data Interchange standard with specific guidance contained in SP Alternative fingers can be used if the primary fingers cannot be imaged due to missing fingers or damaged fingerprint pattern. SP is still in draft form and is subject to change.

34 Biometrics: Issues/Recommendations Use of contact readers and PIN entry for release of the mandatory fingerprint templates may not be appropriate for PACS due to throughput performance requirements or environmental requirements Use of alternative biometric paradigms for contactless operation is not precluded in FIPS 201 However, such implementations may not be interoperable with other agencies Examples of alternative biometric paradigms include: Different modalities (e.g., fingerprint, iris, face, hand geometry, etc.) Store on card match on reader (agency specific PIV container) Store on server match on server (CHUID acts as pointer to biometric record in external database) Store on card match on card (PIN replacement option) 34 FIPS 201 currently requires that the biometric data stored on the PIV card can only be read from the contact interface and with the additional entry of a PIN. The additional user actions of card insertion and PIN entry add time to the access process that may conflict with agency standards of performance. In addition, exterior environments that are weather exposed may not be appropriate for placement of contact readers that are susceptible to moisture intrusion. FIPS 201 does not preclude the use of alternative biometrics paradigms in conjunction with contactless readers. However, such implementations may not be considered interoperable with other agencies unless agencies share the same alternative biometric implementation. For PACS performance reasons, agencies should consider alternative biometric paradigms. In addition to fingerprint, these could include iris, face, hand geometry or other biometric modalities. Biometric templates used for PACS could be stored on the PIV card in an agency specific container with matching taking place at the reader. These templates could also be stored in a server with the PIV CHUID read from the contactless interface simply acting as a pointer to the enrolled biometric record on the server. In this scenario, matching would take place on the server. A third alternative that is gaining serious consideration among some agencies is having the matching function take place directly on the card using a technique called match-on-card where the actual matching algorithm resides inside the PIV card logic and the enrolled template never leaves the card.

35 Biometrics: Issues/Recommendations If fingerprint templates are used for alternative authentication paradigms, they should comply with the INCITS 378 standard (as defined in SP ) to allow interoperability with various manufacturer s hardware sensors and algorithms that may be used within an agency If biometric templates are stored off the PIV card, consider the requirement for an external communications link from PACS reader PIN entry or contact reader is not required if an alternative biometric paradigm is chosen 35 If an agency chooses to use alternative biometric paradigms within their PACS and wishes to use fingerprint technology, it is recommended that the fingerprint templates comply with the International Committee for Information Technology Standards (INCITS) 378 standard. This will allow the ability to use reader hardware and matching algorithms from a growing number of vendors that now support this data interchange standard. If biometric templates are stored in an external database rather than on the PIV card, then the PACS needs to provide a communication link of sufficient speed from the PACS reader to the database so that timely matching can take place at the server. We do not believe that there will be a requirement for PIN entry or contact reader if alternative biometric paradigms are chosen. This is based on our interpretation of FIPS 201 where the PIN and contact interface are required only for the mandatory biometric data specified under FIPS 201.

36 Physical Access Control Systems and FIPS 201: Privilege Granting and Revocation Physical Access Council Smart Card Alliance 36

37 Privilege Granting and Revocation PACS privileges (authorizations) for PIV cardholders are granted and revoked based on local security policies. The biggest issue related to granting privileges is trust in the PIV cardholder s identity. This trust can be established at varying levels of assurance through the FIPS 201 PIV authentication mechanisms. Asymmetric key related authentication mechanisms require network connectivity to CRLs and/or OCSP responders. Continued trust in the PIV card requires that the issuing agency support the card s validity by distributing or providing access to pertinent status change information. 37 The biggest issue related to granting privileges to someone is trust in their identity and ensuring that the person has been properly adjudicated and is still in good standing. This trust can be established using the PIV card at varying levels of assurance through the FIPS 201 PIV authentication mechanisms. Issue: Possession of a FIPS 201-compliant PIV card does not automatically permit the cardholder to access any Federal government facility that is FIPS 201 compliant. Recommendations: A cardholder should be enrolled in the PACS for every facility to which the cardholder needs access. Each agency should create policies that govern how to accept and authenticate cardholders who require access to an agency s facilities but who are not enrolled in that agency s home system. For example: The cardholder should have to see the security officer at the receiving agency s facility, at which time the card can be checked for authenticity. The cardholder should be asked to provide biometric verification (a live image to be compared to the image stored on the card), and the validity of the credentials can be checked. Only if all is in order and the visitor has legitimate reasons for being on site (a local sponsor, for example), then the PIV card CHUID data should be added to the local PACS. Issue: Physical access rights and privileges at a Federal government facility for an individual PIV cardholder are defined by the local PACS manager. Recommendations: The local PACS manager should grant access privileges to a PIV cardholder by registering/enrolling the PIV card s CHUID data (e.g., FASC-N, GUID, expiration date) in the local PACS. The cardholder should only be allowed to access areas controlled by that PACS as authorized by that cardholder s registered access level. Access to highly sensitive areas should require use of multiple identification elements as determined by the organization s policies and assurance level requirements. Combinations of a card and PIN, biometric checks, and/or digitally signed challenges may be required. All of these parameters are registered, processed, and verified by the local PACS.

38 Privilege Granting and Revocation PACS revocation pertains to the revocation of privileges and not the revocation of a PIV card. PACS privileges can be revoked even though the PIV card has not been revoked, but PACS privileges should be revoked if the PIV card (PIV authentication certificate) is revoked. Automated PACS privilege revocation for revoked PIV cards is not mandatory, but is recommended. Automated PACS privilege revocation based on a revoked PIV authentication certificate requires network connectivity to the PKI infrastructure (e.g., CRLs and/or OCSP responders). There is no requirement that each access point triggers a credential status request, as long as the PACS is updated according to agency-specific FIPS 201-compliant procedures. 38 There are three types of revocation involving PIV cards: card revocation, certificate revocation, and privilege revocation. It is important to understand the definition of revocation as it pertains to PACS. Revocation pertaining to PACS is the revocation of privileges and not necessarily the revocation of a PIV card. Issue: The PIV card is intended to establish trusted identity authentication across Federal agencies. Privilege denial simply halts an otherwise permitted activity. Privilege management lies outside of the scope of HSPD-12 and agencies have wide latitude in establishing the policies and methods for granting or denying access. Recommendation: Revocation of a PIV card means that there is no longer a basis for trusting the authenticity of the cardholder. As a consequence, agencies must not rely upon a revoked PIV card for authentication of a person attempting physical access or entry into a facility. Issue: Revocation or temporary suspension of physical access privileges can be triggered by the local PACS, by a central identity management system (IDMS) database, by the card management system (CMS), by a system operator, or by an automatic event (e.g., when a card expires). Recommendation: Whatever the trigger, processes that update and synchronize credential status in affected databases and systems must be in place to ensure that PIV card status is accurate and valid. Issue: The right to access a facility through a specific control point or group of control points can be controlled locally or remotely. Remote control requires multiple facilities to be linked using an enterprise-level access control system that shares information in a common database or IDMS. Recommendations Access privileges can be denied using different methods ranging from suspension to, in extreme circumstances, PIV card and associated certificate(s) revocation. Denial of physical access privileges can be managed from a local PACS, from the agency s central database and/or IDMS, or through checks against a certificate revocation list (CRL) or on-line certificate status protocol (OCSP) responder. Issue: Revocation requirements need to be specified. Recommendations: Getting the card revocation alerts out to all PACS systems in real time or near real time should be the goal. Develop the policies and procedures for revocation (e.g., staleness). Determine how local physical and logical access control systems will be integrated with revocation mechanisms.