CoreStreet's Real Time Credentials Validation Authority

A proof--in CoreStreet parlance, an OCSP response or Vtoken--is a digitally signed statement regarding the status of a digital certificate or user account. These proofs contain unique information about the user, including certificate serial number or user name; status of the user account (active, revoked or suspended); a time stamp that gives the period for which the proof is valid; any attached attributes; and a digital signature showing the VA's private key. Because the proof is signed using public key cryptography--RSA or DSA--any changes, such as a status or validity-period change, to the contents of the proof will cause the signature validation to fail. As long as the signing VA, in this case RTCVA, is protected from attack, only it can create statements of validity using its private key.

I set up RTCVA in our Syracuse University Real-World Labs using a Microsoft Certificate Server as our CA (Certificate Authority), although RTCVA works with all directories via LDAP. RTCVA runs on an Apache Tomcat application server and uses a relational database to store data. I used the included Mckoi Java database server. Installation using command line went smoothly. Once RTCVA was installed, I defined the signing CAs by importing the signed CA digital certificate.

Physical Validation

Corestreet, working with hardware lock vendors, can provide a robust validation system for both connected and unconnected card-based door locks and solves the problem of having to manually update non-networked card door readers. The card reader still authenticates the user, but by using CoreSteet's SDK Real Time Credentials Foundation, the reader can also validate the credentials. Lock vendor's sell CoreStreet-enabled products as a package, complete with RTCVA.

On the reader, two items are needed: a policy that defines access controls for users or user groups and the signing RTCVA public certificate. On the user's card, a proof is written that is valid for a specific time period. After the user authenticates, the reader validates that the user is an authorized user and that the user has access rights. If both checks are OK, the user is granted access. If the proof is out of date, doesn't validate or doesn't match the policy in the reader, the user is denied access. The proofs can be read from an OCSP responder if the reader is network-attached or from the user's card if the reader is standalone.

The reader can also write proofs to users' cards. So when users first enter the building, they should have to pass through a network-attached reader, which will automatically update users' cards with a current proof. Then they can pass through any non-networked reader. More importantly, the revocation proofs, or reader policies, of other users can be written to any user's card for automatic redistribution to any non-network-attached reader because the revocation proof can be read off the card and stored for later use. Likewise, reader log files can be collected from non-network-attached readers. The obvious weakness in this system is that users need to swipe their cards through a connected reader to get their updated proofs. You should take extra care when deciding where to place network-attached card readers--often used, easily accessed readers are critical for a successful system.

RTCVA is a useful product for certificate validation, and the performance gains of pre-generating OCSP responses and the decreased exposure of the signing RTCVA being off-line are compelling to any organization using digital certificates. The physical security validation is a practical and unique use of validation that augments existing physical security measures.

Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®; he covers all security-related topics. Prior to joining this magazine, Mike worked as an independent consultant in central New York. Write to him at [email protected].

Post a comment or question on this story.