thanks for the reply! i am trying to keep the keys safe in the scenario whereby an attacker steals someone's computer, takes out the hard drive, mounts it in another machine and bypasses access rights specified by the filesystem.
On 16 April 2014 23:57, Joachim Schipper <joac...@joachimschipper.nl> wrote: > On Mon, Apr 14, 2014 at 12:28:15AM -0700, alexander taylor wrote: >> The problem I'm trying to solve is that casual users [...] may not bother >> creating >> passphrases for their private ssh keys. [...] [T]hese keys could be >> cryptographically protected under the user's Windows/Linux logon >> password [...] For example, Chrome on linux uses any available >> keychain program to encrypt saved passwords under the user's logon >> credential, if a keychain program is available, and uses the Data >> Protection API on Windows. >> >> More on Windows DPAPI: >> http://msdn.microsoft.com/en-us/library/ms995355.aspx >> >> My idea is to add a "--protect" (e.g.) option to ssh-keygen that >> encrypts the private key with the user's logon credential (windows or >> linux password) instead of prompting for a passphrase. For Windows, >> it can protect the file using Windows DPAPI, but for Linux I would >> need to create a similar "data protection" service. This "data >> protection" service is also something I want to create, with >> ssh-keygen being the main motivation. The linux data protection >> service would generate a master key for the user, protected on disk by >> encryption under the user's password, captured by a PAM module. The >> same PAM module decrypts and re-encrypts the master key when the user >> changes her password. Then, the data protection service allows >> ssh-keygen to encrypt the private key using the user's master key, >> available only when logged on. Now, ssh can use the same service to >> decrypt the key if the user is logged on (another feature I'd need to >> add). If the user is not logged on, the private key is unusable. >> >> Using eCryptfs, hard-drive encryption, or simply making a passphrase >> and keeping it in a keyring solve the same problem, but require more >> effort by the user. >> >> More details on my research: >> https://docs.google.com/document/d/1mibuwHRJpzCFYuQJZ30Cgw6nBjyp6qod19tZnw-Rzv8/edit?usp=sharing > > (I'm on the train, and unable to access the Google Doc. Sorry.) > > I'm a bit unclear on what exact attack scenario you're trying to solve. > > If you just want to ensure that a key is readable only while the user is > logged in, you could just give the user sudo access to scripts like > > #!/bin/sh > # Write to secure storage > set -eu > umask 077 > mkdir -p /var/secure/storage/`id -ru` > cat - >/var/secure_storage/`id -ru`/"`basename "$1"`" > > #!/bin/sh > # Read from secure storage > cat /var/secure_storage/`id -ru`/"`basename "$1"`" > > (and/or write a suid program for a more convenient interface). However, > I'm not clear on what that would accomplish - ssh already enforces that > the key has mode 700, so that it is only readable by the user. I don't > see how adding crypto, PAM or login tracking to the above system really > helps. > > If you just want to ensure the key cannot be simply copied, you might > want to investigate running ssh-keygen as a different user (e.g. > "joachim-ssh-keygen"); IIRC, this already works - but it's a bit painful > to set it up. > > Joachim
