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. It has been developed as part of the CILogon_Pre-Pilot_Work and is working as back-end for the RCauth.eu Online CA.

Security, privilege and user separation

A MyProxy server typically runs under a dedicated account myproxy. Instead of using its built-in functionality, myproxy-server can also run a call-out 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 pin-code 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 pin-code
• One other (not myproxy) account may temporarily have in-memory access to the pin-code
• The pin-code may not be written to disk (assuming no swap)
• Upon removal of the eToken:
  • the pin-code 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 pin-code 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 pin-code from the console only, via a virtual terminal, such that physical access to the box is enforced. The pin-code 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(1). Upon success, the client tries to create a symbolic link (with fixed name) to this new file, which functions at the same time as a lock-file. 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 section below).

Whilst running, the daemon process monitors whether the token is removed or replaced (removed and replaced). It will then trigger a reread of the pin-code (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 pin-code). Likewise for CRLs, the latest-CRL link is not updated.

Components

• etoken-ca-client
  MyProxy server CA certificate_issuer_program. It expects as input a on STDIN a list of key-value pairs, followed by a PEM-encoded CSR.
• 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, expects list of (hexadecimal) serial number(s) as only input. 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.

See the respective man-pages for more information.

At the same time, a cron job is provided to periodically send a SIGUSR1 to trigger creation of a new CRL.

Configuration files

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

• 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 advisable to set this in any case.

For all possible variables, we refer to the man-page for etoken-ca(5).

Log files

• The etoken-ca-server (the background daemon) keeps its own log file, which is by default /var/log/myproxy/etoken-ca.log.
• The etoken-ca-client, which is run by the myproxy-server, will return errors to the latter, which has its own logs by default in syslog. That can be customized via the myproxy-server.config file by setting a custom syslog_facility.

Man pages

• etoken-ca-client.1
• etoken-ca-server.8
• revoke-cert.8
• etoken-ca.5
• null-mapapp.1

Software

The current version of etoken-ca is 0.0.4-1

• SVN
• release tarball
• EL7 RPM