Introduction

P6R has implemented a PKCS 11 Baseline Consumer as part of a SSH server’s Public Key Authentication protocol (i.e., RFC 4252). This implementation provides centralized Public Key management for SSH installations via the use of KMIP. With our PKCS 11 Consumer, the SSH server looks up a user’s Public Key on a remote KMIP server rather than some file system directory. This scheme makes adding or removing a user’s SSH login authentication as easy as creating or removing a set of keys from a KMIP server. This PKCS 11 Consumer is both a PKCS 11 and KMIP client.
(See PKCS11 Cryptographic Token Interface Profiles Version 2.40, 16-Sep-2014, OASIS Committee Specification 01, for the definition of a PKCS 11, Version 2.40, Baseline Consumer).

A PKCS 11 Consumer

This initial Consumer implementation was done as part of the
P6R’s SSH Server, but in the future it will be ported to other SSH servers. P6R’s SSH server includes support for the following authentication protocols: “The Secure Shell (SSH) Authentication Protocol”, RFC 4252, “Secure Shell Public Key Subsystem, RFC 4819, and “P6R’s Secure Shell Public Key Subsystem, RFC 7076. All three of these protocols have been implemented using PKCS 11 and comprise parts of the overall PKCS 11 Consumer client.

In the above figure, the Consumer is composed of all the blue boxes. The SecureCRT SSH client implements RFC 4252 & 4819, thus allowing a user to upload Public Keys into the SSH server for use in the Public Key Authentication protocol. SecureCRT also allows the user to list all uploaded Public Keys and to delete any from his account. Our server based implementation of RFC 4819 allows all keys to be stored on a KMIP server. After a user uploads a Public Key (initially logged in via a password) he can then switch his client to use Public Key Authentication instead of passwords. On his next login, the RFC 4252 plugin will find his matching Public Key on a KMIP server and he will be logged on.

The RFC 7076 plugin allows a user to upload Certificates as well as Public Keys. It supports the concept of namespaces which map directly to KMIP groups. P6R provides a SSH client that implements this protocol.

Why use PKCS 11?

P6R’s PKCS 11 Consumer is built using the P6R’s PKCS 11 provider. Currently this provider supports two token types: a KMIP server, and the P6R Software token with Keystore. The PKCS 11 API allows our SSH implementation to use either of these tokens with no code change. The token type in use is defined by a configuration file. Thus a customer using our PKCS 11 Consumer can easily choose to store their SSH Public Keys on a KMIP server, or a local Keystore using a remote Postgres database (see figure above), or a local Keystore using a local Sqlite database. In the future, when additional token types are supported more options for key storage become available again with no SSH server code changes.

Why use KMIP?

KMIP provides a standard way to manage all types of keys, certificates, and various opaque objects. It is supported by a growing list of vendors thus allowing choice and mobility from one vendor to another.
An introduction to its benefits appears in the following article: The rising danger to data is making KMIP important.