[therightkey] Private Key Manager

[Phillip Hallam-Baker <[e-mail]>]

All, I am currently in the final stages of work on a personal private key
manager. At this point I have rough drafts of code for the UI, services and
persistence logs. I just thought I would sanity check the design at this
point.

The objective is to have a mechanism that allows for convenient management
of personal private keys for any sort of application or device. Secure
email requires public key pairs, so does SSH, so do IoT devices. Back in
1995 when OpenPGP and S/MIME were getting started, key generation took
minutes. Keys were quite big in relation to machine size. We didn't have
protocols for managing them. So we ended up with an approach where we try
to share keys between machines and a CA business model based on selling
certificates rather than service.

For reasons that will become apparent, it is easiest to describe this
approach in PKIX terms and to use PKIX for the management of the personal
hierarchy. But remember that this is a personal hierarchy so the only trust
relationships are of the form Alice trusts Alice's device. And further we
are applying least privilege at each step. The use of PKIX to form the
personal hierarchy does not commit us to use the same approach for Alice
trusts Bob type trust relationships. These are quite separate. Further we
are going to be using OpenPGP style fingerprint type approaches to support
direct trust.



This is where I want to end up in 2020

* Every device I own has a unique device key.
* Every device I own uses a separate key for application level
authentication-type purposes.
* For applications such as end-to-end email, groups of devices MAY share a
common decryption key.
   * End entity Decryption keys MAY be escrowed under a personal recovery
key
   * End entity Decryption keys are rotated on a monthy cycle to mitigate
consequences of lost devices
* Authorizing a new device is a simple, minimal process requiring no skill
or technical knowledge
* All device management processes apart from authorization/deauthorization
are automatic


Some nomenclature:

* Principal = Owner of the personal hierarchy, in PKIX terms the 'subject'.
the change of nomenclature here is deliberate because the point is to
enfranchise every Internet user as a principal in their own right, not a
serf or subordinate of another.

* Device = a computer, mobile phone, light switch, dalek, sous vide, set
top box, Han in Carbonite

* Admin Device = a device, typically a computer or tablet reserved for the
purpose that is authorized to authorize new devices.
* Host Device = any device that is authorized but not a master device
* Potential Host Device = a device that isn't authorized with a key yet

* Private Key Management Service = An *untrusted* JSON/HTTP style service
that helps manage the keys.

By untrusted, I mean that the degree of trust in the service is strictly
bounded. The service never has an unencrypted private key. The service has
no means of obtaining an unencrypted private key. The service cannot
perform a DoS attack and MAY be changed at any time at the option of the
principal, a principal may use multiple services at the same time. The
operation of the service is also transparent.


Behind the scenes we have a PKIX style PKI:

* I have one master key signing key that is backed up using offline
techniques that make compromise virtually impossible. It has a 150 year
lifespan.

* I have an intermediate key signing key that is used to sign or cross sign
every one of my end-entity certs with a ten year lifespan.
* I have a personal escrow key that is used to enable recovery of keys used
for stored data

* End Entity keys for Authentication
* End Entity keys for personal code Signing
* End Entity Keys for email encryption (update once a month)
* End entity keys for signed email (unique per device, update once a month)

By 'update', I mean generate new keys.

A mobile phone would typically have:

* A device key used to authenticate interactions with the Key Service
* A device key used to decrypt private keys used in key distribution
* The current month's email signature key for that device
* Email decryption keys for this month and possibly for prior months.

Note that the client can use the same keys for S/MIME and OpenPGP. Though
in practice this is probably more interesting for encryption than signature.


Any type of key, public, private or symmetric MAY be represented as a
fingerprint. fingerprints may be used with addresses to create a strong
address.

So lets say the private key service has a public key with fingerprint
MOFWH-O23KM-VTGW4-LXNJU-HEZTM. The config file for a user's master client
might specify the use of the JPKM service at example.com as:

ws:example.com:jpkm:MOFWH-O23KM-VTGW4-LXNJU-HEZTM

This can be automatically expanded to a well known service endpoint and
trust anchor:

https://example.com/_well-known/jpkm/
   Cert chain MUST contain a keyinfo with fingerprint
MOFWH-O23KM-VTGW4-LXNJU-HEZTM

OK, can't get fooled by the key service but it isn't trusted. What we do
need to trust however is our connection to whatever audit services we might
want to contact to see that our data has been registered correctly.


The private keys for the Master and Recovery keys are encrypted under a
randomly generated symmetric key which is then split using Shamir's K of N
scheme (I have implemented this up to 15 of 16). The encrypted blob is
stored in the cloud through the JPKE service using the fingerprint of the
symmetric key as an index.

To prevent DoS attack on the key servers, registration may require a proof
of work for unauthenticated registrations.


I have not fully defined all the modes of device management yet. It seems
to me that these need to be very different for devices with network
capability, displays and/or input capability than pure IoT devices where QR
codes are likely to be more appropriate.

If I set up my PPH on my desktop, I should be able to enable my phone as a
Host Device as follows:

* Start app on my mobile phone, give it my account name and chosen private
key manager service.
** App displays key fingerprint of my PPH proving I have bound to the
correct hierarchy
** App displays fingerprint of device key
* Go to my desktop, start the app, see that I have a pending request to
bind the phone
** Check that the fingerprint matches that of the phone
** Accept it

'Magic happens automatically till the phone is stolen'

* Start app on my desktop
* Deauthorize stolen phone

'Phone is found again'

* Start app on my desktop
* Reauthorize stolen phone

'phone is to be sold'
* Deauthorize phone using app on the phone itself

The operations supported by the PKM are thus:

*General Service Management:*
1) Request Service Description
2) Register Client

*Key Escrow:*
1) Store encrypted private key
2) Recover encrypted private key
3) Verify encrypted key hash

*Device Management [Potential Host Device requests]*
1) Register device keys
2) Retrieve device certs and decryption keys [as needed]
3) Deregister device

*Device Management [Admin Device]*
1) Download pending requests
2) Accept/reject requests

A Private Key Manager may be a member of a transparency/fallover cloud.

To make sure the Private Key Manager hasn't defected and has only stored
the keys locally, we can contact any member of the cloud and ask them if
they have a copy of the encrypted private key. To do this we simply ask
them to give us the HMAC of the private key file under a randomly chosen
nonce.

Longer than I intended. Does this make sense?