We were recently asked whether our XPressEntry handheld system was FIPS 140-2 certified. This article explains why FIPS 140-2 is not directly relevant to XPressEntry handhelds, when tied to physical access control systems (PACS). If you are interested in the actual specification, here is a link to the FIPS 140-2 standard.
The title of the FIPS 140-2 document, Security Requirements For Cryptographic Modules, gives the core reason why it does not apply. This is a certification for crypto modules, used for cryptographic computation and secure authentication. This has a very specific meaning when you are interfacing to a chip over a contact (ISO 7816) or contactless (ISO14443 A/B) interface. It is only applicable when you use secure keys stored in a SAM (Security Access Module) to access secure data on a chip or communication to that chip. This is not how PACS work in practice.
This DOD document, DoD Implementation Guide for Transitional PIV II SP 800-73 v1, describes one of the baseline functionalities of the CAC card was to “enable physical access to buildings.” To enable this, the identification data or CHUID was made available for open (unencrypted) read. This is shown in the image below.
The vast majority of DOD physical access control installations open their doors and gates using this open data. The hope was PKI Card Authentication Keys (CAK) could be cryptographically checked at the reader, but this proved impractical. What was implemented broadly is described on pg. 41 of the previously cited FIPS 140.2 standard:
Preregistration of PIV Cards can help to speed up many of the steps in the PKI-CAK authentication mechanism. If the card’s Card Authentication certificate was obtained during the preregistration process then it doesn’t need to be read from the card at the time of authentication … status information for the Card Authentication certificate may be obtained from a caching status proxy rather than performing certificate validation at the time of authentication.
Using this cached proxy, PIV/CAC badges are validated on enrollment using its authentication keys. The proxy is updated on a regular basis and revoked certificates are reflected to the PACS. Products like HID’s pivCLASS Authentication Module (PAM) are used for this purpose. Products like this are required to be FIPS 140-2 as they contain crypto modules.
In Appendix C of the 2018 NIST document, Guidelines For The Use Of PIV Credentials In Facility Access, NIST speaks about some alternatives for the “deprecation of the CHUID authentication mechanism.” However, these recommendations are not mandatory, nor have they reached the market.
Now back to XPressEntry.
Some credentials that we support, such as Mifare, DESFire, SEOS, require cryptographic keys to access secure data. Other HF (13.56 MHz) cards have varying amounts of security, from none (CSN access) to highly encrypted data. However, all of these are proprietary standards and not subject to FIPS 140-2. Proximity (LF/125KHz) cards transmit their data without any security at all. Government PIV/CAC cards similarly provide unencrypted access control data, only requiring reading the specific application container in the badge memory.
XPressEntry uses this open badge data (PIV/CAC/Prox/Other) only as a pointer to look up users for authentication purposes. On our handhelds, we store badge data in our encrypted database. XPressEntry transmits data over SSL encrypted channels. We take the security of our system seriously – enough so that we had our system penetration tested. FIPS 140-2 is specifically not applicable as our handhelds are not a “cryptographic module” nor do we have any cryptographic authentication of the PIV/CAC PKI data.
