Skip to content
This repository has been archived by the owner on Dec 1, 2022. It is now read-only.

Latest commit

 

History

History
89 lines (72 loc) · 3.33 KB

Key-Management-Proposal.md

File metadata and controls

89 lines (72 loc) · 3.33 KB
Raw

Key Management between nodes using GPG tools / encrypted email for key exchange

#Background

DPN will use a messaging infrastructure (RabbitMQ) and transfer mechanisms that will have a need for secured channels, for the exchange of messages and for exchanging objects. RabbitMQ supports SSL, as does HTTPS, and Rsync supports SSH. We may also have a need for VPN’s over SSH/SSL. The best practice is to secure the channels via cryptographic mutual authentication, which require a Public Key Infrastructure. This entails the use of a private key (held at each node), and a public key (generated by each node), which each node in a channel setup having access to the Public key of known nodes. There are two ways that public keys are made available during the setup, through the use of a Certificate Authority, dynamically, or by storing a copy of the Public Keys locally.

A note about SSH (also applies to SSL) (Wikipedia)

SSH uses public-key cryptography to authenticate the remote computer and allow it to authenticate the user, if necessary. Anyone can produce a matching pair of different keys (public and private). The public key is placed on all computers that must allow access to the owner of the matching private key (the owner keeps the private key secret). While authentication is based on the private key, the key itself is never transferred through the network during authentication.

SSH only verifies if the same person offering the public key also owns the matching private key. Hence, in all versions of SSH it is important to verify unknown public keys , i.e. associate the public keys with identities , before accepting them as valid. Accepting an attacker's public key without validation will authorize an unauthorized attacker as a valid user.

Proposal for Public Key exchange

Because DPN only has 5 nodes, the proposal suggests not using a Certificate Authority (CA).
The reasons for this are two fold

  1. reduce administrative overhead and simplicity
  2. direct control over the exchange of Public Keys is more secure and private than exchanging Public Keys through the use of a CA.

So, by the numbers...

  1. Each site to maintain their own self signed certificates for ssh and ssl. - We will need to agree on the process, but it is straight forward.
  2. Each site to exchange Signed Public Keys with the other sites
  3. The designated person at each site will be responsible for maintaining a GPG (Open PGP) email account with public keys at a well known CA
  4. The designated person will use encrypted email to do 2

GPG Tools are easy and the CA’s are maintained at secure sites
To make sure that this is really really secure, we should exchange the keys while on the telephone.

Fortunately, Public Key exchange in this manner is easy, and we have a limited number of nodes. If in the future we feel that it is becoming burdensome, we can create a private CA for the exclusive use by DPN Replicating Nodes.

We may also want to utilize InCommon for general key management for DPN member sites. This will in essence create a two tier security structure. 

Setup Process

  1. Create GPG key
  2. Create SSL keys and SSH keys\