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.