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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
