- Individual Use
CSPid is a virtual smartcard that maintains a central repository for X.509 certificates and private keys. It provides a secure environment for cryptographic operations that nearly all security-enabled applications can access via Java, PKCS#11, or Microsoft CAPI. It is available for, and compatible between, all 32- and 64-bit desktop versions of Windows, Linux, and Solaris/SPARC.
- provides a portable, operating system independent credential store that may be shared by all security-enabled applications
- simplifies enterprise-wide credential management; users need not replicate keys among applications, and may effortlessly migrate credentials between workstations
- provides administrative controls over user credentials; allows PKI enrollment, key rollover, credential backup, and other key management tasks to be automated in a user-transparent manner
- provides superior protection for private keys and overcomes password change/reset issues with Internet Explorer and Mozilla
- reduces help desk costs and PKI training requirements
NEW! CSPid release 4.0 includes the following enhancements:
- added support for centralized administration (with Bagala)
- added ability to cache DAS responses and support for the new DAS Proxy API
- improved FireFox integration
- Windows port now uses CSP/KSP and no longer relies on any Microsoft smart card components (i.e., the smart card minidriver shim in the diagram below has been eliminated)
- integrated certificate manager now sorts installed certificates into categories
Add-on DAS support allows CSPid to provide to all applications (including Outlook and Thunderbird S/MIME) high-assurance "role-based" signing and decryption operations that rely on remote private keys, possibly stored on an HSM (requires DAS 1.8 or above).
CSPid 2.x / 3.x Architecture Diagram
CSPid stores a user’s credentials in a single encrypted file on any designated storage device (e.g., a local hard drive, a network share, a flash drive, or any other removable memory device). That credential store may be opened by CSPid on any platform once its owner has entered their password.
In this way CSPid allows users to effortlessly migrate their public and private keys to any workstation in an OS-independent manner, without the need to physically replicate those keys. (The fewer persistent copies of a user’s private key that are created, the less likely it is to be compromised.)
CSPid’s programmable interface simplifies certificate lifecycle management. By giving security officers control over employee credentials throughout their enterprise, it reduces help desk costs and PKI training requirements.
Security officers can configure CSPid to force password change at designated intervals, prohibit password reuse, and enforce password quality requirements on cryptographic keys. These security policy settings are then enforced for all connected applications, including Microsoft IE and Mozilla (which do not provide such controls by themselves).
- affords your users the functionality of a physical smartcard for a fraction of the cost
- exposes a common store of certificates and private keys to applications via PKCS#11, Microsoft CAPI, and Java
- obviates the need to replicate keys among applications, and simplifies the migration of keys between workstations
- protects private keys independently of the operating system and browsers for greater flexibility and security; administrators can control password cache settings, mandate password quality and change requirements, and monitor credential use with better auditing capabilities
- links users to a specified CA to facilitate enrollment, certificate renewal, key rollover, etc., directly from the CSPid system tray menu
CSPid release 2.0 and above can be deployed in conjunction with DAS and your company's existing security-enabled applications (e.g., Microsoft Outlook S/MIME) to support enhanced security protocols, such as role-based signing and decryption, that were previously impossible to implement with conventional PKI-based tools. In fact, the combination of CSPid and DAS allows you to leverage applications based on today's standards to provide functionality that some vendors would have you believe can only be obtained using more recent schemes such as identity-based encryption (IBE) for which standards have not yet been established.
The following scenarios illustrate five of the possible applications of CSPid/DAS in a 'net-centric' environment:
PROBLEM: A group of watch officers are to sign messages that recipients can validate as having been issued by some authorized group member. (In this scenario, recipients don't care which individual signed a given message, they only need assurance that an authorized member of the group did so.)
SOLUTION SETUP: An asymmetric key pair is generated for the watch officer role, a special role certificate is issued on the public component, and the role private key is put under the control of a DAS server that is configured to perform signing operations with that key only for individuals on the active duty roster for this role. The role certificate is loaded into the CSPid clients on all watch officer systems and CSPid is registered with all security-enabled client applications on those systems. (In fact, all watch officer logins may be hosted on a single system.)
OPERATION: When a watch officer attempts to sign an outgoing message using the role credentials with any security-enabled client application on his system, his CSPid client automatically establishes a TLS-secured connection (with client authentication) to the appropriate DAS server where the signature computation is performed using its protected role private key. As usual, recipients use the watch officer role certificate to validate all signed messages.
Watch Officers Sign Messages with Shared Role Key on DAS Server
RESULT: Recipients can be assured that an authorized watch officer issued each validly-signed message while the DAS server’s audit trail keeps track of the identities of the individuals who actually performed each signing operation. Since the watch officer private key is securely protected by the DAS server (possibly on an independent HSM), at no time is it available for compromise even by authorized signers.
PROBLEM: Documents and e-mail messages encrypted for a particular commander (e.g., CMDR CENTCOM) must be available (without re-keying) to his successor in that role.
SOLUTION SETUP: An asymmetric key pair is generated for the commander, a special role certificate is issued on the public component, and the private component is put under the control of a DAS server that is configured to perform decrypt operations with that key only for the active commander. The certificate is loaded into the CSPid client on the commander's system and CSPid is registered with all security-enabled client applications. All documents and e-mail messages are encrypted for the commander using the role certificate.
OPERATION: When the commander attempts to decrypt a document or e-mail message encrypted with the role certificate, the CSPid client on his system automatically establishes a TLS-secured connection (with client authentication) to the appropriate DAS server where the required asymmetric key unwrapping operation is performed using its protected private key. When the commander is replaced, an administrator need only update the access control list (ACL) for the corresponding DAS account.
Commander Decrypts Documents Using Role Key on DAS Server
RESULT: All sensitive documents and e-mail messages remain encrypted under a single certificate and can only be decrypted by the current commander after strong authentication using his current individual credentials (e.g., CAC card). No re-keying is necessary as different individuals inherit the commander role and the critical private key is securely stored on a DAS server or, even more securely, on an attached HSM. The DAS server's audit trail provides a centralized record of all decrypt operations and, optionally, of the true identity of the individual who performed them.
PROBLEM: Sensitive documents must be securely shared among the members of a community of interest (CoI) with a dynamic membership roster.
SOLUTION SETUP: An asymmetric key pair is generated for the CoI, a special group certificate is issued on the public component, and the private component is put under the control of a DAS server that is configured to perform decrypt operations with that key only for active CoI members. The certificate is loaded into the CSPid client on the systems of all CoI members, and CSPid is registered with all security-enabled client applications on those systems. All sensitive documents and e-mail messages intended for the CoI are encrypted under the group certificate.
OPERATION: When a CoI member attempts to decrypt a document or e-mail mesesage encrypted with the group certificate, the CSPid client on his system automatically establishes a TLS-secured connection (with client authentication) to the appropriate DAS server where the required asymmetric key unwrapping operation is performed using its protected private key. When the CoI membership roster changes, an administrator need only update the access control list (ACL) for the corresponding DAS account.
CoI Member Decrypts Documents Using CoI Key on DAS Server
RESULT: All sensitive documents and e-mail messages remain encrypted under a single certificate and can only be decrypted by active CoI members after strong authentication using their current individual credentials. No re-keying is necessary as changes are made to the CoI membership roster. The critical private key is securely stored on a DAS server or, even more securely, on an attached HSM. The DAS server's audit trail provides a centralized record of all decrypt operations and, optionally, of the identities of the individual CoI members who performed them.
PROBLEM: Key rollover results in a new certificate and private key being loaded onto a high-ranking officer's smartcard where limited storage causes an older certificate and private key to be displaced. Suddenly the officer has lost the ability to decrypt documents and e-mail messages encrypted with the older credentials.
SOLUTION SETUP: Load the officer's entire key history into an account on a DAS server and install his certificate history into a CSPid client on his own system.
OPERATION: Once CSPid has been registered with all security-enabled applications on the officer's system, they will use his smartcard for cryptographic operations requiring his latest private key but transparently establish a TLS-secured CSPid/DAS connection when access to an older private key is required. Going forward, key rollover simply involves moving the officer's retiring certificate to CSPid and the corresponding keypair to his account on the DAS server.
Officer Retains Use of His Entire Key History
RESULT: By relying on the virtually unlimited storage of the DAS server (and the potentially greater security of its keystore which may be located on an HSM), an (on-line) user can maintain use of his entire key history. He thereby retains access to all encrypted documents and e-mail messages ever sent to him in a completely seamless manner.
PROBLEM: Access to a sensitive resource needs to be controlled with a set of finely-tuned access control rules that might vary over time.
SOLUTION SETUP: Generate a "resource key pair," obtain a "resource certificate" on the public key, and distribute it to all users who might require access to that resource; ensure that the certificate is loaded into the CSPid client on each user's system (this step may be automated in several ways). Create a DAS account for the resource and install its certificate and private key along with a custom "authenticator" that implements the access control rules. (An authenticator is a simple Java function that implements the access control predicate: it takes as input the user's credentials and returns a boolean response indicating whether the user should be allowed or denied access to the requested resource. Sample predicates based on LDAP group membership, certificate extension and/or attribute values, etc., can be provided.)
OPERATION: An application attempting to access the sensitive resource will ask CSPid to provide the required authentication (which normally takes the form of a "proof of possession" of the resource private key — typically in the form of a digital signature). CSPid will attempt to obtain this signature from the appropriate DAS server as illustrated in the following diagram:
A DAS Server Used to Impose Strong "Need-to-Know" Controls Over Sensitive Resources
Only if the user's credentials pass the custom authenticator's test will the DAS server provide the required signature for resource access.
RESULT: Together, CSPid and DAS provide assurance that the sensitive resource is securely protected. Maintenance of the entire system is simplified by reliance on a custom "authenticator" that may be easily modified whenever access control policies change. A single DAS server can be used to protect an unlimited number of sensitive resources in this way.
- Intuitive graphical user interface for credential management; command line interface for batch operations and automated tasks under end-user or administrative control
- Exports a PKCS#11 version 2.20 compliant API
- Imports and exports PKCS#12, PKCS#7, and ASN.1 DER-encoded X.509 certificates
- Generates RSA keys of 1024 to 8192 bits; manages RSA keys of any size
- Employs password-protected PKCS#15 PDUs for key storage on local, removable, or network-attached drives, using AES-256 for confidentiality and HMAC-SHA-512 for integrity checking
- NEW! DAS integration now allows CSPid to provide to all security-enabled applications (including Outlook and Thunderbird S/MIME) high-assurance, "role-based" remote signing and decryption operations that optionally rely on HSM-based private keys; standards-based interoperable RSA decryption and signing, ECDSA signing, and ECDH key agreement operations are all available via connections secured by TLS w/ client authentication
CSPid works with all PKCS#11- or CAPI-enabled applications, as well as with all Java applications based on J2SE 5.0 or above, including, but not limited to, the following:
- Microsoft Internet Explorer 5.0 and above
- Outlook 2000, 2002, 2003, 2007, 2010, 2013, and Outlook Express
- Mozilla 1.1, 1.6, and above
- FireFox 1.0 and above
- Thunderbird 1.0 and above
- Netscape Communicator 4.75 and above
- Lotus Notes 6 and above
- SecretAgent 5.x/6.x and SpyProof! 1.x/6.x
- Cisco and Checkpoint VPNs
CSPid is built upon ISC's FIPS 140-certified Cryptographic Development Kit (CDK) version 7.0 and is FIPS 140-2 compliant. It works with X.509v3 credentials from most leading PKI vendors, including Entrust, Microsoft, RedHat, RSA Security, VeriSign, and ISC.
Section 508 VPAT for CSPid (PDF updated 5/15/09)
In general, CSPid supports IPv6 addressing wherever IPv4 addressing is supported. If IPv6 support is not provided by the underlying operating system (either because the OS does not support IPv6 or because the IPv6 stack for the operating system or network adapter has not been properly configured), CSPid will recognize IPv6 addresses, but not use IPv6 transport mechanisms.
CSPid running on Windows XP SP3, Vista, and 7/8.x/10.x fully supports IPv6 in both pure and mixed environments.