From nobody Fri Jun 12 10:38:08 2015 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186191ACDE8 for ; Fri, 12 Jun 2015 10:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k2V-LxTWuwJ for ; Fri, 12 Jun 2015 10:38:04 -0700 (PDT) Received: from mail-la0-x242.google.com (mail-la0-x242.google.com [IPv6:2a00:1450:4010:c03::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCA51ACDE7 for ; Fri, 12 Jun 2015 10:38:03 -0700 (PDT) Received: by labgd6 with SMTP id gd6so6684007lab.1 for ; Fri, 12 Jun 2015 10:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=MFoGZITEQspHjxX4Lf6SvGn+cJwfUeHBCUdH7pc/SZc=; b=OMD/K8twgFLL4GITZO8/FdVffIdx3aHKwtDeovAvL05t5vJZlLYYS165h9KdKo/HQJ cwAkO3an4+NTyJA4IcClIhddlxUJNIp4wOkkSoC8D+KZk/RETK+Q3h3n4M57iQ3Kkjlh 54QphfrwztoJ2o27QmkiZ7Kl0hb03hpjBgv/z8P5IH/Z6QSRWJjm6tjmWk+3dKpPMFUL fZHopDg2X8e8B/abXRUUMZcsld33zA6pQT4IxDIkEh6CqoaB5cmlnVry1XRxGwDHt65Y 1kMUgb1tcksjYifxdeTxhbDjVGiRjN7lFIK4AJ+kAQXo/uTLsPCQazV3fbBaVkG+auVz OvQw== MIME-Version: 1.0 X-Received: by 10.112.40.99 with SMTP id w3mr16513073lbk.55.1434130681887; Fri, 12 Jun 2015 10:38:01 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Fri, 12 Jun 2015 10:38:01 -0700 (PDT) Date: Fri, 12 Jun 2015 13:38:01 -0400 X-Google-Sender-Auth: G_FKlrWvLWZ-Gh_gj_J24YP12zs Message-ID: From: Phillip Hallam-Baker To: "therightkey@ietf.org" Content-Type: multipart/alternative; boundary=001a11336f96db035b0518559174 Archived-At: Subject: [therightkey] Private Key Manager X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 17:38:07 -0000 --001a11336f96db035b0518559174 Content-Type: text/plain; charset=UTF-8 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? --001a11336f96db035b0518559174 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All, I am currently in the final stages of work on a perso= nal 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.=C2=A0

The objective is to have a m= echanism 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 relati= on to machine size. We didn't have protocols for managing them. So we e= nded up with an approach where we try to share keys between machines and a = CA business model based on selling certificates rather than service.
<= div>
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 t= he 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. F= urther we are going to be using OpenPGP style fingerprint type approaches t= o support direct trust.



<= div>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.
=C2=A0 =C2=A0* End entity Decryption key= s MAY be escrowed under a personal recovery key
=C2=A0 =C2=A0* En= d entity Decryption keys are rotated on a monthy cycle to mitigate conseque= nces of lost devices
* Authorizing a new device is a simple, mini= mal process requiring no skill or technical knowledge
* All devic= e management processes apart from authorization/deauthorization are automat= ic


Some nomenclature:
* Principal =3D Owner of the personal hierarchy, in PKIX terms = the 'subject'. the change of nomenclature here is deliberate becaus= e the point is to enfranchise every Internet user as a principal in their o= wn right, not a serf or subordinate of another.=C2=A0

<= div>* Device =3D a computer, mobile phone, light switch, dalek, sous vide, = set top box, Han in Carbonite

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

=
* Private Key Management Service =3D 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 perfo= rm a DoS attack and MAY be changed at any time at the option of the princip= al, a principal may use multiple services at the same time. The operation o= f the service is also transparent.


= Behind the scenes we have a PKIX style PKI:

* I ha= ve one master key signing key that is backed up using offline techniques th= at make compromise virtually impossible. It has a 150 year lifespan.
<= div>
* 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 lifesp= an.
* I have a personal escrow key that is used to enable recover= y of keys used for stored data

* End Entity keys f= or 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,=C2=A0update=C2=A0= once a month)

By 'update', I mean generate= new keys.=C2=A0

A mobile phone would typically ha= ve:

* A device key used to authenticate interactio= ns with the Key Service
* A device key used to decrypt private ke= ys used in key distribution
* The current month's email signa= ture key for that device
* Email decryption keys for this month a= nd possibly for prior months.

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


Any type of key, public, private or symmetric MAY be r= epresented as a fingerprint. fingerprints may be used with addresses to cre= ate a strong address.

So lets say the private key = service has a public key with fingerprint MOFWH-O23KM-VTGW4-LXNJU-HEZTM. Th= e config file for a user's master client might specify the use of the J= PKM 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:

<= div>=C2=A0 =C2=A0Cert chain MUST contain a keyinfo with fingerprint MOFWH-O= 23KM-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 s= ee that our data has been registered correctly.

The private keys for the Master and Recovery keys are encrypte= d 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 encrypte= d blob is stored in the cloud through the JPKE service using the fingerprin= t of the symmetric key as an index.

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


I have= not fully defined all the modes of device management yet. It seems to me t= hat these need to be very different for devices with network capability, di= splays and/or input capability than pure IoT devices where QR codes are lik= ely 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 accou= nt name and chosen private key manager service.
** App displays k= ey fingerprint of my PPH proving I have bound to the correct hierarchy
** App displays fingerprint of device key
* Go to my deskto= p, start the app, see that I have a pending request to bind the phone
=
** Check that the fingerprint matches that of the phone
** A= ccept it

'Magic happens automatically till the= phone is stolen'

* Start app on my desktop
* Deauthorize stolen phone

'Phone is f= ound again'

* Start app on my desktop
* Reauthorize stolen phone

'phone= is to be sold'
* Deauthorize phone using app on the phone it= self

The operations supported by the PKM are thus:=

General Service Management:
1) R= equest Service Description=C2=A0
2) Register Client
Key Escrow:
1) Store encrypted private key
2) Recover encrypted private key
3) Verify encrypted key h= ash

Device Management [Potential Host Device re= quests]
1) Register device keys
2) Retrieve device = certs and decryption keys [as needed]
3) Deregister device
<= div>
Device Management [Admin Device]
1)= Download pending requests
2) Accept/reject requests
A Private Key Manager may be a member of a transparency/fallov= er cloud.

To make sure the Private Key Manager has= n't defected and has only stored the keys locally, we can contact any m= ember of the cloud and ask them if they have a copy of the encrypted privat= e 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?
--001a11336f96db035b0518559174--