BridgePoint used the existing infrastructure at the Neal Smith Federal Building for installing the TrustAlert PACS with a cloud-based protocol. The system meets federal standards and guidelines including HSPD-12 and FIPS 201-2.

It’s interoperable among the 40-plus agencies located in the building and works with the 500-plus employees who already have PIV credentials. An additional 300 employees who currently do not have PIV credentials will transition to the new system.

The PACS required the installation of 23 readers on parking gates, elevator controls and automated doors. The GSA and EmbarkIT enabled employee and contractor building access with the TrustAlert Enrollment system, which enabled them to set up different levels of security clearance and access permission.

The project came in ahead of schedule and on budget.

Until recently, upgrading to FIPS 201 standards was a difficult and expensive process that involved a number of suppliers and consultants. It also generally required a wholesale replacement of the current physical access control system (PACS) infrastructure, including head-end servers, panels and door control hardware.

This has all changed. With the advent of modular hardware solutions and turnkey implementation strategies, agencies can establish a clear migration path from existing credentials and preserve investments in their existing PACS infrastructure. This also allows them to support changing security requirements and enable cost-effective enhancements down the road.

Understanding FIPS 201 requirements

HSPD-12 set a clear goal to improve physical access control security and reliability through the use of government-wide standards. The FIPS 201 standard went further to define the specific characteristics of an interoperable identity credential to be used throughout government. Another important document, SP 800-116, introduced the concept of “Controlled, Limited, and Exclusion” areas, and required agencies to employ risk-based PIV authentication mechanisms for different areas within a facility (see Fig. 1).

Fig. 1: Innermost use of PIV authentication mechanisms

Simplifying the compliance process

Ideally, it should be possible to upgrade an existing PACS infrastructure so that it can authenticate credentials across the full range of assurance levels as defined in SP 800-116, without requiring a wholesale rip-and-replacement.

This is now possible using a modular hardware approach that delivers a high level of flexibility for future modifications. Agencies can install a combination of enhanced readers and FIPS 201 authentication modules that operate with existing components in the current PACS infrastructure. It is easy to deploy and eliminates the need to acquire a complicated mix of expertise, technologies and suppliers.

At the core of this solution is a reader that must feature EAL5+ Secure Element hardware. This ensures tamper-proof protection of keys and cryptographic operations. Additionally, the reader should use the industry-standard Open Supervised Device Protocol (OSDP) communications specification to establish a secure bidirectional link with FIPS 201 authentication modules.

To achieve compliance, agencies simply deploy the new readers and install authentication modules between the readers and the existing PACS panel. This upgraded access control system can now perform PIV authentication tasks across all PIV permission levels, with a validation server providing centralized control of assurance level settings and the distribution of validation data. This modular compliance system performs all necessary PIV authentication steps, beginning at the time of enrollment.

When a credential with the appropriate assurance level is presented to a corresponding reader, the authentication module validates the card according to the assurance level setting. The authentication module then extracts the FASC-N or UUID from the card and passes it on to the PACS panel for an access decision and logging. To prohibit access by revoked cards, the system retrieves and checks the card revocation status from the issuing certification authority or hotlist.

To validate visitor PIV cards, authentication modules use the Server-based Certificate Validation Protocol (SCVP) to establish a chain of trust through the Federal Bridge. Vendors must have first successfully completed cross-certification to the PIV-I standard via the CertiPath Bridge, which ensures interoperability across government agencies and with non-government members of the Federal Bridge. For invalid cards, the authentication module is configurable to send a preset badge ID to the PACS panel (for logging and investigation) and/or close an output relay (to trigger a video camera, for instance).

In the case of communications interruption in the validation process, authentication modules maintain an updated validation data cache that enables them to function “offline.” Meanwhile, strong authentication continues at the door.

Other features further improve simplicity and flexibility. By capturing cardholder data the first time a card is presented for validation to a reader connected to an authentication module, this data can be shared with other authentication modules. This feature delivers several benefits. It makes it possible to use existing access control enrollment functionality and it enables integration with an identity management or card management system. It also enables the use of third-party enrollment packages.

Meeting current and future compliance needs

Until recently, agencies faced with the mandate to upgrade their physical access control system to FIPS 201 compliance were required to work with multiple vendors and often had no choice but to replace their entire PACS infrastructure. The latest, modular solutions give agencies a single point of responsibility and accountability for achieving compliance without a wholesale rip-and-replace upgrade.

The solutions also provide the means to support many compliance needs, including PKI-at-the-door mandates as well as PIV-I and PIV-C requirements for cards issued by non-federal entities. For these and other challenging compliance requirements, today’s modular solutions give agencies a migration path that protects their current PACS investments while enabling them to employ risk-based security levels in selected areas, as required, and to leverage ongoing improvements in access control technology.

TREND #1: Government Mandates- FIPS 201 & PIV

Today’s security landscape has had a major impact on the world, specifically for the U.S. government, post-9/11. With the introduction of FIPS 201 requirements and PIV requirements for Federal employees and contractors in 2005, all government facilities are required to implement a specific plan for implementation by the end of 2011. Agencies wishing to leverage funds from the OMB must have a plan to upgrade all existing physical and logical access control systems to support PIV.

A major aspect of FIPS 201 focuses on the credential itself, since the PIV card must be smart and meet a variety of ISO/IEC specifications, read/write capabilities and encryption standards. We also believe that the upcoming FIPS 201-2 revision will drive additional access control requirements in the near future.

TREND #2: Security Migration for College Campuses

We’re seeing a general need for a migration path from low security credentials to higher security technologies for both college campuses and other types of facilities. Since this results in a mixed credential population, we’ve addressed this migration by introducing lock solutions that support both magnetic stripe and prox or iCLASS credentials, as well as lock solutions that can read multiple credentials with a single reader.

There is also a continued need to cut costs market wide, so we feel lock solutions that include fewer components, reducing material and installation costs and decreasing maintenance over the life of the product are the best option.

TREND #3: The Adoption of NFC/Mobile Keys

The advent of NFC or Mobile Keys technology in environments like college campuses, hotels and homes is another big trend we’re seeing across the industry.

This ID technology enables credentials and key information to be sent directly to smart devices over the air, enabling individuals to unlock a door by authenticating the smart device to the lock. This is an exciting area that we believe will begin to grow tremendously in the future. It offers not only higher security but also the simple convenience that users have come to expect as an increasing number of services become available through mobile phones.

Secure Identity Object (SIO) is another new technology from HID Global for digital credentials that supports advanced applications, mobility and heightened security. SIO ensures data authenticity and privacy through multi-layered security with tamper-proof protection of keys. An SIO can be an ID number or a fingerprint, and is not limited to traditional credentials so it can reside on a smart phone as a mobile key or on a key fob or token.

Overall, we’re seeing that organizations are matching the level of protection commensurate with the actual level of threat, with a custom security solution tailored to the specific requirements of each opening.

We will continue to see credential and ID technology rapidly evolve as decision makers begin customizing security solutions to meet the level of threat posed at higher education facilities, ensure compliance with requirements for government agencies, and address the growing demands for commercial spaces.

About the AVISIAN Publishing Expert Panel

At the close of each year, AVISIAN Publishing’s editorial team selects a group of key leaders from various sectors of the ID technology market to serve as Expert Panelists. Each individual is asked to share their unique insight into what lies ahead. During the month of January, these panelist’s predictions are published daily at the appropriate title within the AVISIAN suite of ID technology publications: SecureIDNews, ContactlessNews, CR80News, NFCNews, DigitalIDNews, ThirdFactor, RFIDNews, EnterpriseIDNews, FinancialIDNews, GovernmentIDNews, HealthIDNews, FIPS201.com, IDNoticias ^es.

In support of this, trust frameworks are helping to drive a clearer separation of the functions of identity proofing, identifier authentication and authorization. This provides a structure that enables various identity providers to supply certified components of identity proofing or identifier authentication, as referenced in the recently-updated version of NIST Electronic Authentication Guideline .

In addition, trust frameworks also enable service providers to “consume” a range of certified digital identities to support their required degree of identity assurance - in accordance with the assessed risk level. In this light, a PIV card is underpinned by the identity proofing provided by the NACI process, along with the authentication techniques specified in FIPS 201-1, up to and including biometric authentication. This combination of strong identifier authentication, and well-defined identity proofing process, supports the production of the very high assurance credential for this program. The smart card provides the secure credential to bind together a user’s identifier with their “proofed” identity.

Thus, it is clear that the three salient attributes of the PIV card are: the underlying identity proofing process; the use of strong authentication; and the secure binding inside the smart card of the user and their identifier by which they are known. The projection of these three factors, along with implicit cryptographic data protection and transport mechanisms, onto many diverse form factors such as smart phones, will enable users to access services using a broad variety of authentication mechanisms, in some cases using derived credentials1.

Indeed, as the global use of smart phones in personal, corporate, citizen and defense environments expands, it is critical to focus on these attributes to ensure that they are certified to fulfill a specified degree of identity assurance, rather than on the particular form factor used. This will enable users and service providers alike to use or accept, respectively, a wide range of user credentials, and will narrow the gap in terms of the levels of authentication that the various form factors can support.

We envisage that 2012 will see this continued certification of identity components and, therefore, users will be able to interact with service providers in a variety of ways. This will improve user convenience, by providing the ability to use already-available devices such as smart phones, in some cases with built-in biometric authentication capability. By the end of the year, this combination of strong authentication, along with the appropriate identity proofing, will allow such devices to be used in high assurance environments, and thereby serve as trusted credentials.

About the AVISIAN Publishing Expert Panel

At the close of each year, AVISIAN Publishing’s editorial team selects a group of key leaders from various sectors of the ID technology market to serve as Expert Panelists. Each individual is asked to share their unique insight into what lies ahead. During the month of January, these panelist’s predictions are published daily at the appropriate title within the AVISIAN suite of ID technology publications: SecureIDNews, ContactlessNews, CR80News, NFCNews, DigitalIDNews, ThirdFactor, RFIDNews, EnterpriseIDNews, FinancialIDNews, GovernmentIDNews, HealthIDNews, FIPS201.com, IDNoticias ^es.

The PrivateServer HSM is a solution designed to be network-attached and to serve multiple users and applications.

PrivateServer HSM has a number of API plug-n-play interfaces that support ID card systems, including full support for Microsoft’s CAPI/CNG, PKCS#11, and JCA standards.

Government Smart Card Interagency Advisory Board (IAB) Meeting

• Opening Remarks
  Tim Baldridge, IAB Chair

• FIPS 201-2 Goes Mobile
  Bill MacGregor, NIST

  PDF: click here

• Logon to Google Apps Using NASA Issued PIV
  Tim Baldridge, NASA, IAB Chair

  PDF: click here

  MP3: click here

• Implementing PKE for JPAS
  Maxwell Funk and Autumn Crawford-Grijalva, DoD

  PDF: click here

  MP3: click here

• Provisioning PACS using the GAMS
  Brad Hiddemen, GSA

  PDF: click here

  MP3: click here

• Closing Remarks
  Tim Baldridge, IAB Chair

  MP3: click here

MOBILE PIV software provides three-factor identity verification for federally issued smart cards including TWIC, CAC and other FIPS 201 smart cards. Salamander Technologies’ MOBILE and MOBILE PIV were granted the Motorola Solutions Validated™ Software logo through its program.

This designation will help assure customers and partners of system interoperability between Motorola devices and Salamander Technologies’ applications/solutions.

Salamander Technologies’ MOBILE software enables the scanning of high-capacity ID cards to identify and track first responders, volunteers and victims during incidents. Previously geared to read high-capacity bar codes, the new MOBILE software can now also read smart cards using Motorola’s MC75A-HF RFID mobile computer. Smart card IDs can be used to track individuals or groups of personnel such as fire companies, police squads, or industrial security and safety teams.

Salamander Technologies’ MOBILE PIV software provides three-factor identity verification of federal smart cards. Besides verifying identities, MOBILE PIV software can track federal employees and workers as part of an event or incident – providing transactional data for on-scene incident command or off-scene Web reports.

MOBILE PIV uses the Motorola MC75A mobile computer equipped with a biometric smart card reader

With the emergence of mobile devices and cloud computing making sure these devices are properly secured is paramount, MacGregor says. Tablets and smart phones will be used more frequently to access cloud-based computing. This problem only portends to increase as smart phones and cloud computing become more common.

“A mobile device without authentication isn’t worth much,” MacGregor says. “If you have a mobile device without authentication how can you give someone access?”

There are three options for enabling the PIV on a smart phone or tablet, MacGregor says. One is additional hardware that would connect the smart card to the mobile device, another is an enhanced PIV that would fully enable all functionality of the contactless interface of the credential and last is use of a mobile device manager and a derived credential.

Contact smart card readers that use Bluetooth, WiFi or a cord to securely connect the PIV credentials to mobile devices already exist, MacGregor says. This option isn’t the most attractive because of the cost of the hardware and the form factor. “From a usability point of view it’s awkward and not realistic,” he adds.

Enhanced PIV

The other two options seem to be more realistic but would require policy and technology changes. The phone could be used as a credential if the contactless interface of the PIV was fully enabled, MacGregor says. The first FIPS 201 version limited the amount of information that was available from the contactless portion of the card.

Near field communication devices could then read the PIV and authenticate to networks, sign and read email, and complete other tasks. To do this the process for creating a secure channel between the mobile and the credential would have to be created. “It’s easy to do technically but hard for the key management,” he says.

Since any NFC device would be able to read any PIV there would have to be a secure key placed on the mobile to make sure the credential is only being read by the properly authorized device. It would be a way to authorize the device to the credential.

Secure keys would have to be issued to the mobile devices, MacGregor says. This could be as simple as a pairing PIN that could be entered into the mobile to authorize pairing. “This doesn’t require too much more functionality,” he adds.

Derived credential

The other option is a derived credential and mobile device manager, MacGregor says. This option has the PIV presented to a mobile device manager which then assigns the credential to a device. The credentials would be placed on a secure element within the mobile.

Only a portion of the PIV functionality would be available with the derived credential and it’s possible that different derived credentials could be issued depending on the level of assurance necessary, MacGregor says.

“The chief negative of this approach is it’s more complex,” MacGregor says. “It needs interaction with a mobile device manager.”

Enhanced PIV and derived credentials are the focus of NIST’s efforts on enabling the PIV with smart phones, MacGregor says. Derived credentials are also mentioned in NIST’s soon to be released Special Publication 800-63-1 which focuses on electronic authentication.

The mention of derived credentials is in a generic form and not specific to PIV, says Hildegard Ferraiolo, a computer scientist at NIST. If derived credentials were to be included with PIV it would be included in the next draft of FIPS 201-2.

The next draft is expected in the first quarter of 2012 or early the second quarter.

When PIV-C became known as PIV compatible it was bad. Compatibility was too close to interoperability in some minds so a new acronym was requested. That this lead to the Commercial Identity Verification Credential and CIV, which has nothing to do with identity verification and is another topic for discussion, but onward with PIV-C.

Yes, PIV-C when it was used to mean PIV compatible was bad. It should have been PIV Counterfeit. In this way PIV-C could be used to help to explain why it is different than PIV-I. A credential can be a counterfeit either from the policy and procedures followed in issuing it and/or using un-trusted keys, certificates or other Web tokens. The government should have realized it’s the use case it doesn’t like not the acronym. CIV should have never come to pass and it’s really not that good an idea to be out there.

Standards for identity proofing and agreement on the authoritative sources of attributes and privileges are one of the current gaps in the identity ecosystem. PIV-C basically enables ad hoc enrollment and self assertion.

Technically you have a number keys, certificates, interfaces, and at present one or a small number of applets. Easy to implement as physical access enterprise credential where there is no federation, but a Web credential needs to be interoperable.

The goal for credentialing is to issue trusted identities. Trust is the killer app not being, as Frank Zappa said, “strictly commercial.” We are engaging in developing the National Strategy for Trusted Identities in Cyberspace not un-trusted identities. PIV-I meets these goals PIV-C does not.

Ironically, all during the conference it was easy to make this point. I used a counterfeit credential. Yes it was wrong and I didn’t do it with the intent of documenting it. But it was an immediate way to demonstrate to the members of the steering committees for the United States Federal government physical security and ICAM initiatives going in with me.

It helps to document security theatre. I used my demo FRAC credential to get into the Reagan building – my Federal colleague took a photo. Test credentials are useful and very real looking. Mine had a nice shiny chip, security lamination and 4 certificates of course all issued by a rouge certificate authority. These hardly mattered since it was as a flash pass that I put it to work. It doesn’t matter what acronym you give it, it’s a counterfeit flash pass.

This gets to the real point. Rather than focus on acronyms focus on strong authentication. This does not mean vague requirements but rather electronic verification including trust of the issuer.

Counterfeits exist, ask any teenager. The way to beat them is not to rename them, it’s to make sure you do a real job of checking them. The security theatre of the flash pass at government buildings and for that matter at airports – ultraviolet pens? – has to cease.

And it’s about more than authentication.

1. Make sure you have established identities to the assurance level needed for individuals’ roles.
2. Make sure there is a separation of roles among the people enforcing the process
3. Make sure the identity is bound properly to the credential
4. Perform cryptographic challenge of the credential and validation of issuer along with checks against other access control lists.
5. Don’t truncate the identifier, which is different than hashing them and yes, you will need to upgrade infrastructure to accomplish this
6. Match the level of authentication to the assets being protected.
7. Protect secrets, personally identifiable information and the cryptographic processing
8. Use standards-based technology and policy
9. Only procure systems that can do this
10. Only procure systems from vendors and integrators that have demonstrated they can do this at a system level. (The weakest link is the strength of the chain)
11. Implement and automate the controls that audit and alert to the above.

Guidance can and will need to provide more details including curriculum, security controls, specific approvals - products and certifications - that support the above. This takes times. Offer a glass of water not a fire hose. While this may not be simple it can be simply said. And it can start in a way where no acronym need be found.

In 2007, as part of a six-member team, Entrust Inc. was subcontracted a portion of the GSA’s $66.3 million contract, which was then awarded to Texas-based Electronic Data Systems–now HP Enterprise Solutions–to lead the HSPD-12 managed-service offering. Entrust’s new contract is directly from the GSA, adding more flexibility to the services provided to the U.S. government.

Entrust now provides PIV services to federal employees and contractors and PIV-I certificates to organizations who want their certificates trusted by the federal government. In addition to user certificates, the new contract enables Entrust to provide machine and device certificates to the federal government, contractors and business partners.

Entrust Managed Services PKI provides digital certificates to the federal government under the Shared Service Provider program. Entrust Managed Services PKI is designed to meet U.S. Federal Common Policy and standards requirements.

The PKI framework automates the management of digital certificates that are used by individuals, applications and devices. This helps enable security services such as strong authentication, integrity of digitally signed data, physical access to buildings and facilities, and the protection of encrypted data to an organization using public-key cryptography.

The Shared Service Provider program was established under the Federal Identity Credentialing Committee (FICC) and Federal PKI Policy Authority to give U.S. federal departments and agencies a method to access PKI services while leveraging previous government investments.