General Appliance Overview

Configurations

The Smartcrypt Enterprise Manager Appliance comes in four configurations

  • 200v :: A virtual appliance suitable for utilizing within your own virtual infrastructure.
  • 300h :: A hardware appliance that contains a hardware security module (HSM) for FIPS 140-2 Level 3 key storage.
  • 300r :: A hardware appliance that contains a quantum-powered true random number generator provided by Quintessence Labs.
  • 350 :: A hardware appliance that contains both an HSM and a quantum random number generator.

Note: A Smartcrypt Enterprise Manager can be configured to use a pre-existing, external Quintessence Labs Trusted Security Foundation for HSM backed secure key storage or quantum random number generation.

The following documentation applies to only the 200v

Hypervisor Support (200v only)

The Smartcrypt Enterprise Manager Appliance is officially supported on VMware vSphere v5.5+ but should run in any hypervisor including Microsoft Hyper-V, Citrix Xen Server and Linux KVM. It will also run in many Type-2 hypervisors including VMware Fusion, Workstation, VirtualBox and Hyper-V on Windows.

Note: For customers wishing to install the Smartcrypt Enterprise Manager onto their own application and database infrastructure, a software only (non-Appliance) version is available.

Appliance Setup and Configuration Quick Start

Before you set up the SEM Appliance, be sure you have these prerequisites in place:

  • VMware virtual machine set up to host the SEM
  • Active Directory account to serve as the SEM SuperAdmin
  • (Optional) A digital certificate to enable LDAP-S
  • PKWARE will supply access to the base OVA file to import into VMware. You will upgrade to the latest SEM version during the setup process.

To set up Smartcrypt Enterprise Manager in VMware:

  1. Import Smartcrypt OVA file.

    1. You should have received this file from PKWARE.
  2. Login and Accept End User License Agreement.

  3. Update to current SEM version. (17.7 and below only)

    1. You'll receive access to the upgrade files from PKWARE. This is a three-step process:
    2. Upgrade to 17.7 (This will allow large uploads to be enabled, as the base image doesn't allow large uploads)
    3. Upgrade to the OS Upgrade Pack
    4. Upgrade to the 18.1.X version
    5. See "Appliance 200v: Upgrading" for more information.
  4. Create the Server Identity Account.

    1. Add username and a master password for SEM.
  5. Acquire evaluation license

  6. Configure Network / Hostname

    1. Go to System > Network in SEM. Click Configure Network. Check Use DHCP to have the system identify available IP addresses for this SEM. You can also configure the network manually by filling out the remaining fields. If you do that, be sure to update the system's Hosts File; Click Host File on the Network page to edit this system file.
  7. Join Active Directory Domain

    1. If you're using Active Directory Integration to allow client agents to connect with the user's Active Directory credentials, you can (optionally) join the AD Domain to SEM. Go to System > Domain. Click Join Domain. Fill in the form. Click Join Domain. See the "Active Directory" section of the Basics page for more information.
  8. Configure TLS/SSL

    1. See "Security: Public Key Infrastructure and Certificates" for information on why this step is necessary.
    2. Upload Root: You need a root certificate, along with any intermediate certificates between the root and PKCS#12 certificate. Under System > SSL, click Upload Root under Custom Trusted Root Certificates. Browse to the *.cer file containing the fully qualified chain for your certificate. Click Upload.

    3. Upload PKCS#12 certificate. Under System > SSL, click Upload PKCS#12. Browse to the *.pfx file. Click Upload. This file will include at least the certificate’s private key and may include the entire certificate chain.

    4. Confirm connection. The Issuer of the SSL Certificates will have the same label as the Subject of the Custom Trusted Root Certificates on this page.

  9. Configure AD Connection for User Lookups

    1. Admins need to connect to Active Directory users to identify and manage clients, devices, and policies. Go to Basics and scroll to the Active Directory section. See the "Active Directory" section of the Basics page for more information.
  10. Set Master Database Password

    1. You cannot back up the database without defining a master database password. Go to System > Database. Click the Not Set line in Password. Type the master password.
  11. Set up a Cluster. See "Creating a New Cluster" for process.
  12. Join Slave

    1. See "Adding a new system to an existing Cluster" for process.
  13. Verify connectivity

    1. After pairing, you will be asked to reboot both systems. Go to System > Operations. Click Reboot. Following the system reboot, go to Advanced > Cluster. Both systems should be listed, and you should see the Polling active information at the bottom of the page.

  14. Advanced | Data Centers

    1. Setup first data center. See "Creating a New Data Center" for process.

Security: Public Key Infrastructure and Certificates

Use of digital certificates for encryption and digital signing relies on a combination of supporting elements known as a public key infrastructure (PKI). These elements include software applications such as Smartcrypt that work with certificates and keys as well as underlying technologies and services.

The heart of PKI is a mechanism by which two cryptographic keys associated with a piece of data called a certificate are used for encryption/decryption and for digital signing and authentication. One of the keys is private and must be kept secure so that only its owner can use it. The other is a public key that may be freely distributed for anyone to use to encrypt data intended for the owner of the certificate or to authenticate signatures. The keys look like long character strings but represent very large numbers. 

End entity certificates and their related keys are used for signing and authentication. They are created at the end of the trust hierarchy of certificate authorities. Each certificate is signed by its CA issuer and is identified in the “Issued By” field in the end certificate. In turn, a CA certificate can also be issued by a higher level CA. Such certificates are known as intermediate CA certificates. At the top of the issuing chain is a self-signed certificate known as the root.

How the Keys Are Used

With encryption/decryption, a copy of the public key is used to encrypt data such that only the possessor of the private key can decrypt it. Thus anyone with the public key can encrypt for a recipient, and only the targeted recipient has the key with which to decrypt.

With digital signing and authentication, the owner of the certificate uses the private key to sign data, and anyone with access to a copy of the certificate containing the public key can authenticate the signature and be assured that the signed data really proceeds unchanged from the signer.

Authentication for an X.509 key has one additional step. As an assurance that the signer is who he says he is—that the certificate with Bob’s name on it is not fraudulent—the signer’s certificate itself is signed by an issuing certificate authority (CA). The CA in effect vouches that Bob is who he says he is. The CA signature is authenticated using the public key of the CA certificate used. This CA certificate too may be signed, but at some point the trust chain stops with a self-signed root CA certificate that is simply trusted. The PKI provides for these several layers of end-user public key certificates, intermediate CA certificates, and root certificates, as well as for users’ private keys