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.