Cryptography abstraction concept

by Sergei Vyshenski

OpenXPKI as a software product is a collection of building blocks and construction tools meant for deployment of an arbitrary complex and fully functional Public Key Infrastructure (PKI) as specified by the X.509 standard. Of course full functionality is a goal to be reached in versions to come.

From the system point of view, PKI is a special purpose information system for processing, storing and propagation of a certain class of data units: requests, certificates and revocation stuff. At certain stages of the data processing, PKI deals with cryptographic calculations and transformations. But the general structure and workflow of data processing is independent of the employed cryptography. </p>

For the first time in the open source world, OpenXPKI is offering a trustcenter concept which is totally decoupled from the cryptographic details.

Technically, this is achieved by

providing a cryptographic layer (see Architecture White Paper). It forms a universal cryptographic interface, to which arbitrary (software or hardware) cryptographic backends can be plugged in.
introducing a cryptographic talking policy: all constituents of PKI in their OpenXPKI realization (ones that are higher than the cryptographic layer) are only allowed to speak to cryptographic tools in a specially designed high level language for cryptographic needs of PKI.

High level language for cryptographic needs of PKI at server side

Our analysis shows that all cryptographic needs of PKI at the server side can be expressed by just the following 19 commands.

convert_cert: if given a certificate, transform it from PEM into DER or TXT
if given more than one certificates, transform them into a PKCS#7 structure in PEM, DER or TXT
convert_crl: transform CRL from PEM into DER or TXT
convert_key: transform a key from RSA, DSA or PKCS#8 into PEM, DER or PKCS#8
convert_pkcs10: transform a request from PEM into DER or TXT
create_cert: create self-signed certificate
create_key: create a secret key
create_pkcs10: create a certificate request
create_pkcs12: store a secret key and related chain of certificates into a PKCS#12 structure
create_random: generate a random number
is_prime: check if a number is prime
issue_cert: issue a certificate which is signed by a Certificate Authority (CA)
issue_crl: issue a Certificate Revocation List (CRL)
list_algorithms: return list of supported public key algorithms and their parameters
pkcs7_decrypt: decrypt data
pkcs7_encrypt: encrypt data
pkcs7_get_chain: check a chain of certificates, used for signature, and/or encryption/decryption
pkcs7_sign: sign data
pkcs7_verify: verify signature for data
symmetric_cipher: encrypt/decrypt data with one of the algorithms for symmetric encryption

Please note that only one of these commands, namely create_key, obligatoryly requires apriori knowledge of the fact that a certain cryptographic set of tools exists with a specific name (like RSA, DSA, GOST, etc). This apriori knowledge can be acquired with another command: list_algorithms. In interactive scripts you can ask your system to list algorithms and show the list to the user. So that the user can pick up the preferred algorithm with a pointing device. To facilitate automatic processing of this list, severall formats of list presentation is provided. As a result, the high-level programmer needs no knowledge about which cryptographic backend and which cryptographic algorithms will be available in a really installed system.

All other commands could deduce necessary cryptographic details from the data which they process.

N.B.:

PKCS#7

Cryptographic Message Syntax Standard. See RFC 2315. Used to sign and/or encrypt messages under a PKI. Used also for certificate dissemination (for instance as a response to a PKCS#10 message). Structure contains data and (possibly) a signature, which signs the data.

PKCS#8

Private-Key Information Syntax Standard. Structure contains encrypted (or not encrypted) secret key.

PKCS#10

Certification Request Standard. See RFC 2986. Format of messages sent to a Certification Authority to request certification of a public key. Structure contains a request.

PKCS#12

Personal Information Exchange Syntax Standard. Defines a file format commonly used to store private keys with accompanying chain of public key certificates protected with a password-based symmetric key.

A list of cryptographic backends recognized by OpenXPKI

Today this list consists of the following entries:

OpenSSL cryptographic library ver. 0.9.8x with x = a, b, c, d, e.
OpenSSL-0.9.8d-gost a clone of OpenSSL cryptographic library with additional support for russian national (GOST) cryptographic algorithms.

Our Cryptography abstraction concept still pays a lot even with that modest choice:

If one day OpenSSL acquires a new cryptographic algorithm, then it will take a minute to add support of it to the OpenXPKI.
If one day OpenSSL acquires a support for new hardware security module, then it will take a minute to add support of it to the OpenXPKI.
If one day we get an alternative to OpenSSL, that is some totally different (software or hardware) cryptographic product, then we have a ready template to fill in to add support of this product to the OpenXPKI.

With cryptographic backend #2 plugged in, OpenXPKI supports both sets of cryptography:

the same set of algorithms as with cryptographic backend #1, and plus to that:
russian national cryptographic algorithms GOST. See Working with russian (GOST) cryptography.

This makes OpenXPKI the very first example of an open source trustcenter product which supports two absolutely different sets of cryptography (western and russian) at the same time. So that RSA, DSA, and GOST certificates can coexist in the same working database and move around the same PKI.

Future version OpenSSL-0.9.9 is scheduled to link together both cryptographic backends listed above into a single product. It will provide simultaneous and default support of arbitrary cryptographic sets. And OpenXPKI is ready to support this new version of OpenSSL due to the same Cryptography abstraction concept. </p>