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.