Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

alexander taylor
I need advice on a contribution I'd like to make as part of my
research with a cryptography professor at UC San Diego.  I mostly want
to know if there are any obvious practical problems with my idea.

The problem I'm trying to solve is that casual users trying to ssh
into Github or their home / school server may not bother creating
passphrases for their private ssh keys.  This means that they are
probably relying on hardware security to keep their private key safe.
However, with no added effort, these keys could be cryptographically
protected under the user's Windows/Linux logon password in the same
way that your saved passwords are protected in the web browser.  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

Thanks for any help/insights!

alexander taylor

Reply | Threaded
Open this post in threaded view
|

Re: Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

Giancarlo Razzolini-3
Em 14-04-2014 04:28, alexander taylor escreveu:
> The problem I'm trying to solve is that casual users trying to ssh
> into Github or their home / school server may not bother creating
> passphrases for their private ssh keys.
This happens to be true not only with casual users. You would be
surprised with the vast amount of sys admins that should know better,
but end up creating ssh keys with no passphrases.
>   This means that they are
> probably relying on hardware security to keep their private key safe.
Very little security here. Only thing that can help a little is disk
encryption. Not that many users use it.

> However, with no added effort, these keys could be cryptographically
> protected under the user's Windows/Linux logon password in the same
> way that your saved passwords are protected in the web browser.  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
This looks like something useful. But a documentation from 2001? SHA-1
to keep things safe? Security isn't Microsoft's thing.

> 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.
Unless this would work across all the platforms where openssh runs, I
don't see that many people using, nor it getting included in openssh.
> 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.
On the contrary. I believe that many distributions include nowadays
right on the installation process the possibility of enabling ecryptfs,
luks, or even both. So it's simpler for the users now. Again not that
many do actually use it. I use ssh-agent and I only need to type the key
passphrase once, twice a day. All this saving me from typing 20, 30
times a password when logging in to my machines, or pushing things to my
git server.
> More details on my research:
> https://docs.google.com/document/d/1mibuwHRJpzCFYuQJZ30Cgw6nBjyp6qod19tZnw-Rzv8/edit?usp=sharing
>
> Thanks for any help/insights!
>
> alexander taylor
>

I think that your idea is doable, but you'll find that this problem is a
very hard one to solve, in a portable way, across all the platforms
where openssh runs on. Anyway, good luck.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

Reply | Threaded
Open this post in threaded view
|

Re: Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

Joachim Schipper-2
In reply to this post by alexander taylor
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

Reply | Threaded
Open this post in threaded view
|

Re: Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

Hugo Osvaldo Barrera-2
In reply to this post by alexander taylor
On 2014-04-14 00:28, alexander taylor wrote:

> I need advice on a contribution I'd like to make as part of my
> research with a cryptography professor at UC San Diego.  I mostly want
> to know if there are any obvious practical problems with my idea.
>
> The problem I'm trying to solve is that casual users trying to ssh
> into Github or their home / school server may not bother creating
> passphrases for their private ssh keys.  This means that they are
> probably relying on hardware security to keep their private key safe.
> However, with no added effort, these keys could be cryptographically
> protected under the user's Windows/Linux logon password in the same
> way that your saved passwords are protected in the web browser.  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.

These features only work if you've all the right optional dependencies
installed, and a manager/daemon running that handles all that.
AFAIK, the GNOME and KDE implementation use d-bus, which I think would
be an unwanted dependency for SSH.

Most "popular" linux distros do disk encryption by default. Especially
those used by the less tech-inclined users.

OpenBSD users, and more tech inclined users generally know not to keep
their keys passwordless. Even if they do so, they already know the risks.

>
> 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.
>

Sounds like you'd need a way to export the keys to move them to other
computers as well. Also, what happens if root changes the password? Does
the user lose his keys?

> 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-Rz
v8/edit?usp=sharing

You mention gnome-keyring as an example, that can double up as an
ssh-agent, and unlocks on login with the user password. I belive this
pretty much covers the initial scenario. At most, gnome-keyring should
have (if it doesn't already), an "generate ssh keys" option, and that
would cover the problem.

>
> Thanks for any help/insights!
>
> alexander taylor
>

--
Hugo Osvaldo Barrera

[demime 1.01d removed an attachment of type application/pgp-signature]

Reply | Threaded
Open this post in threaded view
|

Re: Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

alexander taylor
In reply to this post by Joachim Schipper-2
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

alexander taylor-2
In reply to this post by Hugo Osvaldo Barrera-2
thanks for the reply, hugo!  good points.  let me try to address them:

i would like to avoid any dependencies for ssh as well.  maybe if the
user tries to use "--protect", only then would it prompt the user to
install dependencies, such as the linux data protection service i'd
like to create, which in turn may use dbus.

linux distros do encryption by default, but they don't actually start
encrypting your files by default, so i'd say the ultimate default here
is to not have anything actually encrypted.  of course the experts
will get their keys encrypted somehow, but i am worried about all my
college friends who use ssh to sign into github but don't use
passphrases.

good point--to move keys, decrypting and encrypting in another form
would be necessary.  perhaps --unprotect would prompt the user to
choose a passphrase for encryption during transport.

yes, forcibly changing the user's password will cause data loss
(unless the user still remembers the old password), but this is
already the status quo on windows.  you get a long warning message
when you reset without the old password because all encrypted files
and saved passwords are lost.

gnome-keyring does the trick on linux, but for the feature to be
popular and easy to use, pehaps it's better if it the solution is
cross platform / built into ssh-keygen.

thanks again!
alex


On 17 April 2014 01:40, Hugo Osvaldo Barrera <[hidden email]> wrote:

> On 2014-04-14 00:28, alexander taylor wrote:
>> I need advice on a contribution I'd like to make as part of my
>> research with a cryptography professor at UC San Diego.  I mostly want
>> to know if there are any obvious practical problems with my idea.
>>
>> The problem I'm trying to solve is that casual users trying to ssh
>> into Github or their home / school server may not bother creating
>> passphrases for their private ssh keys.  This means that they are
>> probably relying on hardware security to keep their private key safe.
>> However, with no added effort, these keys could be cryptographically
>> protected under the user's Windows/Linux logon password in the same
>> way that your saved passwords are protected in the web browser.  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.
>
> These features only work if you've all the right optional dependencies
> installed, and a manager/daemon running that handles all that.
> AFAIK, the GNOME and KDE implementation use d-bus, which I think would
> be an unwanted dependency for SSH.
>
> Most "popular" linux distros do disk encryption by default. Especially
> those used by the less tech-inclined users.
>
> OpenBSD users, and more tech inclined users generally know not to keep
> their keys passwordless. Even if they do so, they already know the risks.
>
>>
>> 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.
>>
>
> Sounds like you'd need a way to export the keys to move them to other
> computers as well. Also, what happens if root changes the password? Does
> the user lose his keys?
>
>> 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
>
> You mention gnome-keyring as an example, that can double up as an
> ssh-agent, and unlocks on login with the user password. I belive this
> pretty much covers the initial scenario. At most, gnome-keyring should
> have (if it doesn't already), an "generate ssh keys" option, and that
> would cover the problem.
>
>>
>> Thanks for any help/insights!
>>
>> alexander taylor
>>
>
> --
> Hugo Osvaldo Barrera

Reply | Threaded
Open this post in threaded view
|

Re: Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

Stuart Henderson
On 2014-04-17, alexander taylor <[hidden email]> wrote:
> gnome-keyring does the trick on linux, but for the feature to be
> popular and easy to use, pehaps it's better if it the solution is
> cross platform / built into ssh-keygen.

The way you are talking about doing this is dependent on PAM so it's
only available on systems using that.. gnome-keyring is possibly *more*
portable; for one thing, it works on OpenBSD.

Reply | Threaded
Open this post in threaded view
|

Re: Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

Giancarlo Razzolini-3
In reply to this post by alexander taylor
Em 17-04-2014 08:05, alexander taylor escreveu:
> 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.
>
If this is what you're trying to accomplish, you're better off
instructing your friends and colleagues to using full disk encryption.
On windows there is bitlocker, which I advise against but is on the
system right after installation, and there truecrypt, which is better.
On mac there is filevault, but it does encryption on file level rather
than disk level. On linux there is dm-crypt, luks, ecryptfs, and
probably some more options out there. On OpenBSD there are options also.
The benefits of having full disk encryption go way beyond of just
protecting a ssh key without a passphrase.

It's worth noting that if an attacker has repeated physical access it's
pretty much game over, even with FDE. There are way too many attacks he
can do, the evil maid being just one of them. Also, in the case of
theft, if the FDE password is weak and you're just using a password
(truecrypt, luks, and others can have one or more keyfiles) there the
old fashioned brute-force attack.

As I mentioned before, I think it will be very difficult for you to
implement a solution that is portable across all the platforms. And
probably even if you can, I don't see it getting into upstream OpenSSH.
Now, the data store you are wanting to implement for linux is a good idea.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

Reply | Threaded
Open this post in threaded view
|

Re: Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

alexander taylor
thank you giancarlo!  sorry i hadn't known to look for inline
responses when i read your first email, which i read on my phone.

ok, so i had some trouble formally expressing an attack scenario, but
i'm glad you agree that crypto is important and underused even for
some non-casual users.  actually i want to protect everyone in the
world like me who don't want to keep track of another password, will
always prefer default options and are scared of full profile/disc
encryption, but could still benefit from crypto in case their device
is stolen or tampered with (and they know it's been tampered with soon
after the fact), so not just my college friends.

i think overall this feature would still add utility.  i'm glad
ecryptfs is just a matter of checking a box, but i think there is a
reason why people don't check it.  for me it is because i'm afraid of
losing all of my files if something goes wrong (forget the password,
delete the key on accident).

you're certainly right about repeated physical access.  but i wonder
about how much more difficult it is for the adversary to deal with
cryptography in a practical situation.  as an example, i could install
a keylogger on the machines at my school, but this takes more time
than i have, and leaves a trace that may allow me to get caught.
however, as it is, i can copy the plaintext file onto a flash drive
without leaving a trace.  so, the crypto would be at least a little
bit helpful, and not a false sense of security for people smart enough
to be able to use ssh anyway.  i will have to devise a realistic and
scary threat model.

very interesting point about portability.  i was hoping that
ssh-keygen could prompt the user to install the necessary dependencies
if they try to use the --protect feature, instead of having package
dependencies.  also, since it couldn't be implemented for every
platform, perhaps it could simply say that the feature is not
supported for that platform.  not sure if practical.

i'm glad you like the linux data protection service idea.  that would
need to come first anyway so i can focus my initial research on that
if the ssh ideas seem unlikely.

thank you for your time and ideas!


On 17 April 2014 08:44, Giancarlo Razzolini <[hidden email]> wrote:

> Em 17-04-2014 08:05, alexander taylor escreveu:
>> 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.
>>
> If this is what you're trying to accomplish, you're better off
> instructing your friends and colleagues to using full disk encryption.
> On windows there is bitlocker, which I advise against but is on the
> system right after installation, and there truecrypt, which is better.
> On mac there is filevault, but it does encryption on file level rather
> than disk level. On linux there is dm-crypt, luks, ecryptfs, and
> probably some more options out there. On OpenBSD there are options also.
> The benefits of having full disk encryption go way beyond of just
> protecting a ssh key without a passphrase.
>
> It's worth noting that if an attacker has repeated physical access it's
> pretty much game over, even with FDE. There are way too many attacks he
> can do, the evil maid being just one of them. Also, in the case of
> theft, if the FDE password is weak and you're just using a password
> (truecrypt, luks, and others can have one or more keyfiles) there the
> old fashioned brute-force attack.
>
> As I mentioned before, I think it will be very difficult for you to
> implement a solution that is portable across all the platforms. And
> probably even if you can, I don't see it getting into upstream OpenSSH.
> Now, the data store you are wanting to implement for linux is a good idea.
>
> Cheers,
>
> --
> Giancarlo Razzolini
> GPG: 4096R/77B981BC

Reply | Threaded
Open this post in threaded view
|

Re: Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

Stuart Henderson
On 2014-04-18, alexander taylor <[hidden email]> wrote:
>                                         as an example, i could install
> a keylogger on the machines at my school, but this takes more time
> than i have, and leaves a trace that may allow me to get caught.

how long does that really take? swap a keyboard for a similar looking
one with a transmitter in? once installed it just needs to transmit
via radio, so the attacker doesn't need to go back to the machine.

Reply | Threaded
Open this post in threaded view
|

Re: Insight needed on new encryption feature for ssh-keygen and ssh: "ssh-keygen --protect" and a linux data protection service

Giancarlo Razzolini-3
Em 18-04-2014 07:54, Stuart Henderson escreveu:
> On 2014-04-18, alexander taylor <[hidden email]> wrote:
>>                                         as an example, i could install
>> a keylogger on the machines at my school, but this takes more time
>> than i have, and leaves a trace that may allow me to get caught.
> how long does that really take? swap a keyboard for a similar looking
> one with a transmitter in? once installed it just needs to transmit
> via radio, so the attacker doesn't need to go back to the machine.
>
    As I mentioned, physical access means game over, pretty much always.
In the case where the user isn't using full disk encryption, you can
even bypass their security by booting off some usb disk and simply
installing a software keylogger, which will report you the keystrokes
through the internet. In this case, having the ssh key encrypted won't
help. Because the attacker will already have a copy of it, and just need
to wait the user type the password. And in this case it's even worse,
cause the user will most likely never know it was attacked.

    I believe that instead of promoting a false sense of security, we
should encourage people to think for themselves. I believe one of the
main reasons why Snowden revelations didn't spawned a major outcry
across the world, is because people tend to be lazy. And us, as
programmers, also tend to favor that behavior. I'm not saying for us to
create overly complex programs that will end up not being used. I'm just
saying that we should teach then into using the software more wisely.
Security is, and always will be, a trade-off. The more security, more
the inconvenience. But in this case of the ssh keys, I believe it's more
worth teaching people to always create then with passwords.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC