[RFC] Keychain for GPG, SSH, X.509 etc. (inspired by Split GPG)

[Andrey Utkin]

TL;DR: Generalization of "Split GPG" concept.
Any comments?
Anybody likes the idea?
Ready to join development or early adoption?


What is this: Concept of flexible solution for usage of private keys
without disclosing them. Key usage is always confirmed by user (as a
form of AnyNumber-factor auth).

What is planned to guard: OpenPGP keys, SSH keys, X.509 client certificates.

Inspiration: Split GPG (https://www.qubes-os.org/doc/split-gpg/),
PGP-smartcards, SSH-smartcards.

Implementation form: portable libraries/toolkit.

Elements:
 - keychain server (KS): the process which is accessible via specified
protocols and has access to the unprotected keys, so that it can use them:
 --- encrypt/decrypt/sign;
 --- create challenge responses;
 - keychain key usage client (KUC): the process which makes requests for
key usage;
 - keychain confirmation server (KCS): the process conveying User's
decision (approval or rejection) to each key usage request;

The following elements must run in trusted environment (including
trusted physical security system, trusted hypervisor, trusted machine OS);
 - keychain server;
 - keychain confirmation server.
Keychain key usage client can work in entirely hostile environment.
Keychain usage client (KUC) may be entirely spoofed by attacker, no data
from KUC is trusted and it must be verified by User.

The above restriction is not a show-stopper ("oh, too much restricted
scheme - how to get such trusted environments?"). It is an improvement
comparing to default scheme, which supposes secret keys exposition in
same hostile environment. The point is in decoupling these three
essential entities of key material, key usage agent (gpg-agent,
ssh-agent) and key control (usually underdeveloped in mainstream systems
- you just MAY get asked to enter passphrase if you use it).
This scheme is an improvement comparing to hardware smartcard usage
because it brings flexiblility and fine-grained control to key usage
confirmation procedure.

Q: How confirmation happens?
A: This function is outsourced to plugin system. Different systems would
find different ways as most fit. Used/allowed plugins configuration is
set up in keychain server. It possibly will look similar to Linux PAM.

Q: How to have keychain server data encrypted?
A: As long as KS must actually use the keys in their unencrypted form,
it is required that safety of KS is trusted. If we cannot assume KS
environment trusted, then keys are compromised as soon as they get
loaded in unencrypted form. See http://blog.invisiblethings.org/keys/ "I
proudly use empty passphrases on all of my private keys...". Encryption
of KS data is out of scope of this scheme, but it may be implemented as
the adopter decides, as additional safety measure.

Q: How to ensure unspoofability of confirmation dialog?
A: Confirmation app must run in trusted environment, so this is not
needed. If environment is not trusted, the unspoofability of
confirmation dialog is only one of countless unresonvable security issues.

Q: Which protocols are used to convey key usage dialogs and confirmation
dialogs?
A: The ones that can be considered handy and trusted in specific case.
The following ones are offered for adopters consideration:
 - SSH;
 - other end-to-end (KUC-KS, KS-KCS, KUC-KCS) encrypted connections:
 --- XMPP via TLS chat with PGP or OTR encryption;
 --- HTTPS online session with realtime notifications;
 --- encrypted VoIP or VVoIP call communication (smart audio
synthesis/recognition software are probably required);
 --- confirmation HTTPS link in encrypted email;
 - NFC (near-field communication protocol, hardware) - NFC crypto chip
prepares signature which shows approval to KS;
 - (bad, use as fallback) SMS, PSTN call;
It should be stated that KC may want to gather more than one approval,
by more than one communication channel (thus we have multi-factor
authorization). Or system may query several confirmation channels in
parallel or serial fashion.


Examples of viable platforms for trusted elements (KC, KCS), review of
potential risks:
 - Android device: so-so to bad (depending on whether the system is
fully dedicated, and on system configuration):
 --- risk for KC: vendor-provided OS system services tend to spy on user;
 --- risk for KC: normally every app has its kernel-guarded storage, but
processes with system privilegee (gained by exploit or by user
permission) may access this data;
 --- risk for KCS: potential spoofing of KCS app dialogs;

 - Remote sever: bad to so-so to good (depending on whether VPS or owned
and guarded physical machine):
 --- risk for any component: remote attack (TODO elaborate, review more
in-depth);

 - Pluggable micro-PC with dedicated system (like
http://inversepath.com/usbarmory.html): potentially good, but there's
lack of interactive peripheral for dialog, a gadget like androids
without bloatware would be nice.

 - Virtual machines: good, but must be used properly - untrusted env
mustn't be supervising trusted env.

 - Different UNIX system accounts from untrusted component: bad, trusted
elements are owned on privilege escalating exploitation.

 - LXC: same as with UNIX accounts (kernel exploit owns everything)?


Example elements layouts:

 - keychain server (KC) and confirmation server (KCS) on Android device,
keychain usage client (KUC) on a workstation: simple, affordable, bad
security;
 - keycnain server (KC) on remote server, usage client (KUC) on a
workstation, confirmation client (KCS) on another, trusted workstation:
pretty good, if remote server is safe;


Further expansion of this scheme:
 - X.509 client cert auth challenge forwarding (using browser plugin);
 - HTTP DIGEST auth challenges forwarding from KUC (using browser
plugin) to KS;
 - forwarding requests for file access, i.e. implementation of
filesystem in userspace, with manual access control on sensitive data
exposed to untrusted environment.

-- 
OpenPGP usage is appreciated (it also helps your letter to bypass spam
filters). To email me with encryption easily, go
https://encrypt.to/0xC6FCDB11

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20151127/2e433b66/attachment.sig>