Supporting PIV I Cards

How to determine if your physical access control system supports the solution

• By Bob Fontana
• Jun 01, 2012

When your physical access control system (PACS) manufacturer tells you its system supports PIV-I “end-to-end,” you might want to do some additional digging to make sure you both agree as to what that really means. Legacy PACS designed for proximity cards (or even PIV cards) are unlikely to support PIV-I cards without specific upgrades for handling 128-bit identifiers. Just because a PACS supports PIV cards doesn’t mean it supports PIV-I cards. In a plug-and-play world, it may be your job to ensure that each component is capable of PIV-I.

PIV Card Identifiers

The identifier on a PIV card is the 32-digit Federal Agency Smart Credential Number (or FASC-N). The FASC-N, found in the card’s CHUID container, is a “smart number” consisting of nine fields.

The first five FASC-N fields—16 binary coded digits—are sufficient to uniquely identify every federally issued credential. That means that physical access control systems may safely use the first 16 digits of the FASC-N as the card identifier without concern for duplicates. The largest possible 16-digit identifier would therefore be 9,999,999,999,999,999, which happens to require 54 bits. Most access control panels cannot store a value as large as this as a single number. Instead, they employ schemes that split the value into two or three logical parts. A common method is to concatenate the agency code, system code and credential number (14 digits), forming one number, and the credential series code and individual credential issue (2 digits), forming another number. Another method is to combine the agency code and system code into a number represented as the traditional “facility code” and store the credential number as the traditional “card number.”

This is often done to avoid updating panel firmware and head-end software to support larger identifiers.

PIV-I Card Identifiers

PIV-I cards are intended for non-federal issuers. The number of organizations that could potentially deploy it is so large that the agency code-system code-credential number method used by PIV cards would not work. Therefore, with PIV-I, the FASC-N can no longer be used as the card identifier. In fact, the first 14 digits of the FASC-N on a PIV-I card are all 9s.

Therefore, if a system can read only a partial FASC-N, all PIV-I cards would appear the same.

PIV-I credentials must use a different numbering system called the globally unique identifier (GUID), which also is found in the CHUID container. The construction of the GUID has some important properties that impact physical access control systems. A GUID is generated in a way that ensures uniqueness across the planet, even if the machine generating it is “off the grid.” The GUID is always 128 bits, which is more than double the size of the 16-digit truncated FASC-N.

The Reader

The reader must be able to recognize that the credential is a PIV-I card. The correct way for the reader to do this is to read the CHUID and check the first 14 digits of the FASC-N. If it is not all 9s, it then outputs the FASC-N. If it is all 9s, it outputs the GUID. The panel must be able to accept cards of both formats—FASC-N or GUID.

The Panel

PIV-I credentials require the control panel and the head end to store larger values for identifiers. These values can still be broken into smaller pieces for ease of storage, but because the GUID is a series of 128 bits rather than a string of binary coded digits, the panel must employ a different method for splitting a GUID received from a reader.

Splitting must be done by bits, not digits. When a PIV-I GUID arrives on the reader port, the panel must split the GUID and compare it with pieces of GUIDs previously received from the head end.

The Head End

Because head-end computers usually have larger memory capacities and more sophisticated database engines, the PIV-I GUID can often be stored as a single 128-bit value. In fact, Microsoft SQL Server supports the GUID as a data type. Regardless, head-end software must be able to accept a GUID as card identifier from the enroller and must be able to send the complete GUID to the panel. The panel must be capable of storing the GUID in a way that it can quickly be compared with the GUID arriving on a reader port.

Remember, there are many things to keep in mind when determining if your PACS supports PIV-I “end-to-end” and whether your access control system truly has the capability to support PIV-I cards.

This article originally appeared in the June 2012 issue of Security Today.