EToken-ca

EToken-ca is a package that provides full privilege and user separation for a MyProxy server running in CA mode where the private key is store on a SafeNet® eToken.

Security, privilege and user separation

A MyProxy server typically runs under a dedicated account myproxy. Instead of using its builtin functionality, myproxy-server can also run a callout program, configured as certificate_issuer_program, to produce certificates based on the input consisting of a username, lifetime and certificate signing request. We use this to implement a privilege separated setup, where the myproxy-server process and myproxy account do not have access to the pincode needed to unlock the private key.

Boundary conditions

In order to comply as much as possible with the EUGridPMA Guidelines on Private Key Protection and at the same time keep the tool relatively light-weight and simple we impose the following boundary conditions:

• Only root may have permanent in-memory access to the pincode
• One other account may temporarily have in-memory access to the pincode
• The pincode may not be written to disk (assuming no swap)
• Upon removal of the eToken:
  • the pincode must be reread
  • anything signed around that time must be discarded
• We use an OpenSSL CA in combination with a PKCS11 engine: this implies that the pincode must be exported as environment variable at some stage.

Implementation

We developed a simple daemon, etoken-ca-server, that runs as root and reads the pincode from the console only, via a virtual terminal, such that physical access to the box is enforced. The pincode is only stored in memory, in a shell variable, that is only exported during signing operations. These signing operations are done by yet another user, causer, to keep it separate from the myproxy server.

In order for the issuer program (the etoken-ca client) to communicate new requests to the server, we use a 'request' directory, where new files are created by the client using mktemp. Upon success, the client tries to create a symlink (with fixed name) to this new file, which functions at the same time as a lockfile. The server reads those files and produces certificates. This ensures that there is no direct interaction between the server and the client.

Since the user has access to the private key, we also use the daemon for signing new CRLs (see #Components below).

Whilest running, the daemon process monitors whether the token is removed or replaced (removed and replaced). It will then trigger a reread of the pincode (and stop processing requests for the time being) and can optionally also call a notifier hook, e.g. for sending email to the CA operator. When unplugging is noticed after signing a certificate, it is directly marked revoked and not returned to the user (there is no new CRL produced as that requires the pincode). Likewise for CRLs, the latest-CRL link is not updated.

Components

• etoken-ca-client
  MyProxy server CA certificate_issuer_program
• etoken-ca-server
  daemon reading new CSRs and calling out to openssl CA tool for producing certificates. Also producing CRLs using openssl CA.
• revoke-cert
  command line tool for queueing revocation requests. Actual revocation and updating of CRL is triggered by sending a SIGUSR1 to the etoken-ca-server. Optionally, a post-crl hook can be configured, which runs after the CRL has been updated successfully. This can be used e.g. for calling a backup.

Configuration

All configuration is done with a single sysconfig file, /etc/sysconfig/etoken-ca. A few variables do not have default values:

• DN_FORMAT - used to set the printf format for the subject DN of certificates.
• CA_OIDS - comma separated list of policy OIDs to be inserted in issued certificates as certificatePolicies.
• CRL_URLS - comma separated list of URI:<entry> CRL download entries to be inserted in issued certificates as crlDistributionPoints.
• USB_DEVICE - Vendor:Product identifiers as returned by e.g. lsusb.
• KEY - it has as default only the slot (0:) but no key_id. It is adviseable to set this in any case.