RedCloud Enterprise offers all the software features found in RedCloud Virtual, including PIVCheck Plus integration and is packaged in a network appliance. Both RedCloud Systems are 100% Web-based and leverage an open architecture, plus they offer integrated identity management and video surveillance.

Codebench accomplished the integration by utilizing RedCloud’s REST API, one of many IT collaboration tools available from RedCloud.

Codebench’s PIVCheck software suite is a card validation, authentication and registration solution for HSPD-12 compliance. Pairing the PIVCheck solution with RedCloud Security Management Software will enable federal government users and other organizations that need to comply with HSPD-12 requirements to easily validate FIPS-201 compliant credentials in real-time and to continue that validation on an ongoing, user-defined schedule. In addition, it will allow entities to easily register PIV, TWIC, CAC or FRAC cards without having to do additional data entry on each cardholder.

The U.S. government data uses Apriva’s technology to secure mobile communications for classified and unclassified email. The company’s BT200 smart card reader and PKI authentication software are used on handheld terminals deployed by government agencies to inventory sensitive assets from commissary items to advanced weapons.

Psion’s handheld computers have been used by the U.S. government for applications such as homeland security at the nation’s borders, ports and airports, as well as military applications.

Government Smart Card Interagency Advisory Board (IAB) Meeting

• Opening Remarks
  Tim Baldridge, IAB Chair

  MP3: click here

• A TWIC Program Status and Update
  John Schwartz, TSA

  PDF: click here

  MP3: click here

• CAC/PKI Logon to Warriorgateway.org
  Devin Holmes, Warrior Gateway
  http://www.warriorgateway.org

  PDF: click here

  MP3: click here

• A Federal Security Professional PACS Perspective since the Signing of HSPD 12
  Ron Martin, HHS

  PDF: click here

  MP3: click here

• Closing Remarks
  Tim Baldridge, IAB Chair

  MP3: click here

Quintron has produced an AccessNsite HSPD-12 PACS hardware and software solution that incorporates OCSP certificate validation via the Federal Bridge at the time of card enrollment. The validation status is stored and is periodically updated so that a revoked certificate will cause a credential’s privileges to be immediately suspended.

The result is a properly implemented high assurance solution that validates the card using up-to-date certificate status each and every time the card is presented at a door to gain access.

Government Smart Card Interagency Advisory Board (IAB) Meeting

• Opening Remarks
  Tim Baldridge, IAB Chair

  MP3: click here

• Using PKI to Mitigate Leaky Documents
  John Landwehr, Adobe

  PDF: click here

  MP3: click here

• The Digital Identity Ecosystem of the States: Leveraging Federal Initiatives
  Doug Robinson, NASCIO

  PDF: click here

  MP3: click here

• Achieving Federal Identity Compliance in PACS Without a Rip-and-Replace Investment
  Dave Adams, HID

  PDF: click here

  MP3: click here

• Aviation Credentialing and the New RTCA Standard 230C
  Tom Lockwood for Christer Wilkerson, AECOM

  PDF: click here

  MP3: click here

• Closing Remarks
  Tim Baldridge, IAB Chair

  MP3: click here

“We tried to achieve new functionality with costs considered and without agencies having to buy more than they wanted to buy,” MacGregor says. “Some people say the draft is conservative but I think it’s appropriate for the current requirements and implementations. Disruptive change would not be good.”

For the most part the draft has been well received. Some, however, have expressed disappointment that other form factors for the credential, such as mobile devices, and additional applications were not addressed. The Interagency Advisory Board plans to encourage NIST to enable other form factors in the revised specification.

“HSPD-12 doesn’t specifically call for a card but rather leaves it open for other devices,” says Tim Baldridge, chair of the IAB and project manager for NASA’s Common Badging and Access Control System. Baldridge made the comments during the April IAB meeting stating that the group is going to submit comments recommending other form factors.

When collecting comments NIST divided them into three categories. First were the comments that were in scope of the specification and NIST members knew how to address the question. The second category contained questions that were possibly in scope but the team didn’t know how to address the question. The last category contained concerns that didn’t make sense to the team and were out of scope.

“The majority of comments were in the first category and were regarding efficiency and effectiveness,” MacGregor says. “Making the card lifecycle more efficient and coherent, (there were) several changes in this category.”

FIPS 201-2 proposes synchronizing the card, digital certificate and biometric lifetimes on the card, MacGregor says. The proposal would extend the card to six years from five and extended the certificates to three years and the biometric data to 12 years. The aim of these changes it to reduce the number of visits an employee would have to make to an issuer.

Another change is to the biometric chain of trust, MacGregor says. If an employee’s credential is lost, stolen or damaged, in the past they would have to repeat the entire enrollment process, MacGregor says. The draft spec would enable the employee to be identified using the biometric stored on the system and issued a new ID.

The same would be true if an employee transferred between federal agencies, MacGregor says. Instead of repeating the background check and issuance process the employee would be identified with the stored biometric and issued a credential.

The biometric of choice is still fingerprint, but FIPS 201-2 does enable iris as an alternative biometric, MacGregor says. While the failure to enroll rate for fingerprint is low, 1% or less, it still exists and the number can add up when issuing credentials to more than 6 million employees.

“We wanted to introduce another biometric modality that would give people a second chance if their fingerprints failed,” says MacGregor. NIST has been testing iris recognition for the past year and results are promising, he adds, explaining that “iris authentication can be used for a range of purposes and error rates are comparable to that of fingerprint recognition.”

For now iris is only being considered for use in enrollment and to verify a chain of trust. But MacGregor expects a discussion to take place when comments are collected on the draft around how the biometric could potentially be used more broadly. “We wanted to take all possible care to prevent disruption of current deployments (and) minimize the impact on existing issuance stations,” he says.

Match on card is also proposed in the draft, MacGregor says. Instead of activating the card with a PIN the user could present a fingerprint or iris. The matching of the biometric would also take place on the card, leading to greater security because the biometric information would never leave the card.

The draft also enables match-on-card functionality to be used for other applications, such as physical and logical access control, MacGregor says.

The changes in how biometrics would be used in the draft spec are encouraging, says Walter Hamilton, chairman of the board at the International Biometrics and Identification Association. Including biometrics in the chain of trust and enabling it for physical access control are good moves, he says. “It creates a framework for the use of biometrics for contactless access control without requiring entry of a six to eight digit PIN,” he says.

There’s some work that will have to be done to refine the biometric portions, Hamilton says. Revisions to NIST’s Special Publications 800-73 and 800-76 will have to be done to specifically define how the biometric will be used. “While FIPS 201-2 provides encouraging directions it’s not complete until those publications are updated.”

Key changes

FIPS 201-2 also aims to clear up some ambiguity with the public key infrastructure plans from the original standard, MacGregor says. The draft calls for a mandatory asymmetric card authentication key. This wasn’t in the first FIPS 201 standard, which called for an asymmetric, symmetric or both types of keys. It was, however, specified in NIST’s Special Publication 800-73.

Since the first FIPS 201 spec has some ambiguity it prevented one type of key from being used throughout the government, MacGregor says. “You didn’t know what kind of card authentication key would be in the card,” he adds. This hampered true interoperability.

The asymmetric key would be mandatory with the new draft. “Many people like the asymmetric key because the key management is simpler and less expensive,” MacGregor says.

Application, device authentication

FIPS 201-2 also wants to enable applications and devices to authenticate to the credential, MacGregor says. “Both ends present their identities,” he says. “The identity of the reader or the application is given to the cards and vice versa and a secure session is created.”

This means a card won’t give up any data unless the reader or application is authenticated, which will present possible data skimming, MacGregor says.

Device authentication lends itself to another request that has surfaced in recent years: support for other form factors, such as mobile devices. “This was in the second tier of questions, important but no simple answers,” MacGregor says.

Supporting device authentication and encrypting secure sessions between the smart card and a mobile device puts us one step closer to enabling other form factors, MacGregor says. But there are questions to be answered before credentials could be completely moved to a mobile device. Issues surrounding the viability of a complete PKI solution on the device persist, and the security of mobile devices remains up for debate.

Steve Howard, vice president of operations at CertiPath, suggests that not tackling alternative form factors was a glaring omission in the draft. While there may be many questions on how to port a PIV to a mobile device now, these questions won’t exist in another five years. The specification could be outdated by the time it comes out if alternatives form factors aren’t addressed in some way.

The IAB has come up with some ways that other form factors could be enabled, Baldridge says. The secure elements on the devices and software would need to meet specific FIPS 140 encryption standards.

Adding applications

Also missing from FIPS 201-2 was the possibility of adding agency-specific applications to the PIV. The Defense Department has been considering transit and payment applications for the Common Access Card and many officials expected something to be added to the new spec related to other applications.

MacGregor says that adding other applications can be difficult, and any new application would have to pass additional cryptographic standards testing and validation.

While the work on FIPS 201-2 has been going on for some time it’s not going be over soon. Macgregor hopes to resolve the comments from others by the end of 2011, but that could be pushed back depending on the number and complexity of the comments received on the draft.

Top 10 proposed changes to FIPS 201

As presented by Hildegard Ferraiolo, a computer scientist at NIST, at the FIPS 201-2 Workshop in April at in Gaithersburg, Md.

1. The asymmetric Card Authentication Key is now mandatory

• Used for single-factor authentication for physical access control to access federal buildings and facilities
• Used over the card’s contactless interface
• By making this Card Authentication Key mandatory, it can be interoperable throughout government
• Better alternative than the Cardholder Unique Identifier, which can be sniffed and or copied and replayed

2. An enrollment record, or chain of trust, is introduced

• Maintained by issuer and contains the documentary evidence of identity proofing, background investigation and biometric data
• Enables cardholder to reconnect to the record by matching against registered fingerprints when card is lost, stolen, or compromised
  • Eliminates complete re-enrollment
  • Eliminates recapturing biometrics
  • Eliminates repeating background check

3. Iris recognition is supported

• Includes iris as an optional authentication method
• Includes iris biometric to re-connect to the enrollment record when fingerprints cannot be enrolled with issuer

4. Standards based technological advancements are added
In 2005, some open standards were promising, but immature. Now, these standards are mature and thus incorporated in Draft FIPS 201-2 draft

• Added optional On Card Biometric Comparison authentication
  • The cardholder’s fingerprint biometric representation is captured by the reader and transferred to the card, where it is matched against the cardholder’s stored biometrics
• On Card Biometric Comparison also enabled as an optional card activation mechanism in addition to PIN–based card activation

5. Option to support ISO/IEC 24727 standard is included

• Added ISO/IEC 24727 based standards technology to improve reader resilience and flexibility. The standard offers a suite of authentication mechanisms for identification, authentication and signature applications with a smart card
• Interest in ISO/IEC 24727 for the secure channel feature, for example to secure communication between the card-to-PC or PINpad-to-PC paths

6. Optional card orientation feature is added

• To comply with Section 508 of the Rehabilitation Act that strives to make electronic and information technology accessible to people with disabilities
• Improves usability of the card for visually challenged cardholder
• The card now has orientation features to help align for insertion into a card reader

7. Maximum length of the printed name is increased

• Eliminate name truncation, if possible, and the resulting irritation and inaccuracies that result

8. Online background investigation verification is added and on-card National Agency Check and Inquiries Investigation (NACI) Indicator is removed

• Once there is a government-wide, online background check status service, the NACI Indicator can become optional, as advised by OMB

9. Remote post issuance update of the card, in cases where none of the printed information on its surface has changed, is allowed

10. I-9 Identity Source Document specifications are introduced

• Define the permitted combinations of I-9 Identity Source documents in FIPS 201-2 to reduce confusion and mistakes

Much of what is written about PIV and PIV-I gets caught up in PKI. But just as much, if not more, attention needs to be paid to why organizations need to create an enterprise identity service and the architecture to support this. Fundamentally there needs to be a single authoritative source for identity data also known as a registration authority. This needs to be the case even if organizations have opted for identity as a service and outsourced their PKI.

One of the best results from the Federal Identity, Credential and Access Management (ICAM) initiative is the separation of the lifecycle management of each of the ICAM components. In order to progress in the ICAM maturity model organizations must start with an enterprise service to support the identity creation function and as a result support the creation of a registration authority.

A registration authority can serve as a powerful focal point to implement policy for the creation of a range of credentials. This can range anywhere from high assurance multi-step, multi-role, multi-person registration to doing self assertion via a simple Web registration portal.

One of the important things that come from starting with the creation of a registration authority is the ability to create an identity vault that properly safeguards data. The other significant benefit is that it invokes an architecture that properly restricts the frequency of access to data that by its very nature is long lived and does not need to be updated.

In fact the ICAM process has an underlying logic that comes from the inverse relationship to the frequency with which data needs to be accessed and its life cycle. Identity data is long lived and seldom needs to be accessed – but still needs to have a chain of trust maintained – while certification related attributes have shorter life cycles and are more frequently accessed. The following inverted triangle can be used to represent these relationships.

The enterprise registration authority and the associated identity vault sit at the bottom of the triangle. It is the building block on top of which enterprises will implement ICAM. It provides the foundation for enterprise governance, risk management and compliance by providing a common identity footing across these regimes and activity.

ICAM needs to be done in order; identity then credentials, then access, then management of other attributes and certifications. In order to take the first step in getting the “I” in place a registration authority needs to be put in place and organizations need to look to PIV and PIV-I and the process they define.

When doing these organizations need to make sure they put in place a process that meets the highest level of assurance they will need to meet. Supporting lower levels of identities is easy to do from a high assurance identity infrastructure. Supporting higher levels of identity is extremely difficult if not impossible with a low level of assurance identity infrastructure.

The need to get things right at the start and to support the full range of use cases is all the more reason to adopt PIV and PIV-I as enterprise policy for identity creation and to establish this as policy and a requirement for the enterprise registration authority.

There is a long standing lesson from manufacturing that building quality in to a process is much more cost effective than trying to add it on after the fact. In building 21st century identities quality – high assurance – needs to be built in at the beginning. Getting identity – as opposed to simple identifiers – right necessarily needs to have a registration authority and the associated roles and policy that can meet the requirements as laid out in FIPS 201 and supported by the PIV and PIV-I frameworks.

In doing so organizations not only maximize the use cases they can support but also maximize the return on their identity infrastructure investment.

“Prior to the release of this SDK, Android devices were not able to meet the fundamental requirements of HSPD-12 and DOD directives,” says Jeff Ford, Apriva’s Information Security Systems (ISS) division president.

Android device manufacturers and application developers can leverage Apriva’s SDK at no cost with a signed license agreement and employ it to integrate with the Apriva portable Bluetooth smart card reader. According to Apriva, the SDK includes all of the software, drivers, libraries, and interfaces needed to extend smart card operations into new or existing platforms and applications.

Additionally, Android device manufacturers can provide “STIG capable” platforms with the SDK, enabling add-on middleware and applications to be in compliance with government security policies. Apriva’s SDK is designed to handle the complexity of using and managing PKI smart cards, while providing a simple way to add the PKI-based encryption and identity management to new Android applications and platforms.

Government Smart Card Interagency Advisory Board (IAB) Meeting

• Opening Remarks
  Tim Baldridge, IAB Chair

  MP3: click here

• FICAM Plan for FIPS 201-2
  Tim Baldridge, IAB Chair and Deb Gallagher, GSA

  PDF: click here

  MP3: click here

• NSTIC Cross-Sector Digital Identity Initiative
  Keith Ward, Northrup Grumman

  PDF: click here

  MP3: click here

• FiXs, Helping Meet the OMB 11-11 Directive
  Warren Blosjo, 3Factor

  PDF: click here

  MP3: click here

• Legal Implementation Challenges for NSTIC: Emerging Virginia Solutions for Credential Issuer Liability, Trademarks, and Remote Notarization
  Tim Reiniger, FutureLaw

  PDF: click here

  MP3: click here

• Closing Remarks
  Tim Baldridge, IAB Chair

  MP3: click here

To ensure and support strong identity standards, PIV-I outlines specific control objectives and security requirements for government employees and contractors. The standard addresses the vast population of private-sector workers who need to work with federal systems in the course of their daily business, as well as, state and local government agencies, critical infrastructure businesses and emergency workers.

Verizon’s Identity Managed Service Offering provides identity management, credential management, biometric enrollment, privilege management and validation services in one complete offering. As this offering is available via the cloud, customers benefit from a solution that is faster and less complex than traditional credentialing implementations.