Here's a scenario:<br><br>multiple rings of security with the innermost having FBI background checks and security clearances, vault doors, dedicated fiber lines, treason convictions etc. I work with the stuff outside of that arena and it has two layers: non-classified but sensitive and/or export controlled, and non-classified and not export controlled. Certain groups of people are not allowed to connect except to the outermost , unsecured network.<br>
<br>People need to be able to ssh into the controlled arena to "do things". The laptops are currently not full drive encrypted (windows is a problem and the Mac systems have a different issue - no one is use Linux laptops which don't have a problem with drive encryption). So the need to keep ssh keys encrypted is high. <br>
<br>In general, people are lazy. If they can find a way to remove the encryption from the key, they will. Thus the need to find a way to test if a users key is _still_ encrypted.<br><br>the only reason I have for keeping keys in the vault is for back checking in the event of a breach. The key hash is more important to me as it can be sent around and used to check if a key is encrypted or not. It the new key has matches the original bare key hash, bad times are in order.<br>
<br>The pub key in ldap gives a way to quickly add/remove access for a key user. I wish it was a standard thing in sshd.<br><br>I see your point about access keys and no need for escrow. I need to look at auditd logs a bit more but I think they don't have that level of detail during a connections authentication section.<br>
<br>These remote machine are OS controlled by me and the others I work with so it's possible to add in an sshd that allows a connection back triggered by a connection to my network. That back connect can run a hash on the connected user's priv key and compare it to the one hash of the unecrypted key stored earlier.<br>
<br>This would be easier if ssh had a patch that allowed a compile flag requiring a password on keys.<br><br>Happily, most of the people that need this access are mostly carbon-based life forms. A few are probably part silicon and sulfur...<br>
<br><div class="gmail_quote">On Thu, Dec 23, 2010 at 11:50 PM, Michael H. Warfield <span dir="ltr"><<a href="mailto:mhw@wittsend.com">mhw@wittsend.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hello,<br>
<br>
Good to have triggered some interesting discussion on this. I can see<br>
that I'll have a VERY lively session if I do my ssh talk at ALE. Aaron<br>
and I can work out the scheduling details later but I think this will<br>
have to go on the calendar for some upcoming month. Probably later that<br>
sooner, unfortunately, but we'll make it happen.<br>
<div class="im"><br>
On Thu, 2010-12-23 at 16:02 -0500, Jim Kinney wrote:<br>
> On Thu, Dec 23, 2010 at 3:29 PM, Michael H. Warfield <<a href="mailto:mhw@wittsend.com">mhw@wittsend.com</a>>wrote:<br>
><br>
> ><br>
> ><br>
> > I know I'm doing my IPv6 talk next month for ALE. Maybe I need to<br>
> > schedule my talk on "Securing the Secure Shell" some time in the next<br>
> > few months as well. I gave that talk in front of AUUG a while back but<br>
> > I don't think I've delivered it at ALE before.<br>
> ><br>
> > I am all for hearing it! Aaron please contact MHW ASAP before he changes<br>
> his mind! :-)<br>
<br>
> At work, I'm prepping an ssh-key repository to ensure that all keys use a<br>
> good password.<br>
<br>
</div>I'm not totally sure I perceive the threat vectors you hope to address<br>
or where they stand on an attack tree here, but... Ok... Lets work<br>
with this and see where it leads. Yes, I can see some similarity<br>
between strong passwords on PGP keys and this but the similarity is<br>
somewhat superficial since they keys are used for totally different<br>
things and other environmental factors come into play.<br>
<div class="im"><br>
> The repository will generate the ssh keys for the users and<br>
> archive the original, no password key in a vault (literal, steel vault with<br>
> key as text on paper with a barcode for fast input, placed there buy someone<br>
> with a firearms license at the federal level), then the user must enter a<br>
> password to encrypt the key.<br>
<br>
</div>As a cryptographer, any system generating keys for a user stands the<br>
hair up on the back of my neck. It also runs contrary to a number of<br>
strong crypto systems which would preclude it to some extent or another.<br>
To use my analogy a bit further, the idea of generating PGP keys for<br>
users would be totally abhorrent and unacceptable to me and violates<br>
many of the basic PGP principles. But, these are not the same thing and<br>
this very thing is common in X.509 client certificates where a site<br>
generates a complete PKS12 key and cert pair (which I also think is an<br>
abomination but that's grist for another rant on another day) for a<br>
client and then E-Mails it to them with a transport passphrase (sigh).<br>
<div class="im"><br>
> That encrypted key is then copied to their<br>
> thumb drive and the original unencrypted is hashed, wiped and the hash<br>
> stored. Their pub key is placed in the ldap server.The sshd is a modified<br>
> one that locates ssh pub keys from ldap. It is also configured to never<br>
> allow a password entry.<br>
<br>
</div>That sounds sort of reasonable but I'm not sure of the value-add in the<br>
complexity of this is unless the real goal is an escrow or backup of the<br>
private keying material. If that private keying material is intended<br>
primarily for authentication, then I have to feel this is all a bad<br>
idea. Having a backup for a key used to protect data at rest, such as<br>
PGP keys, is generally a good idea. Having a backup of private keying<br>
material primarily used for authentication is almost always a very bad<br>
idea. You don't gain anything by it. If someone loses an<br>
authentication key, you simply replace the authentication key and reset<br>
the public keys for the authentication and nothing is lost. If you lose<br>
a key for data at rest, the data is lost. That's not the case with an<br>
authentication key, like this, though. I don't see the value in the<br>
keystore and this complicated handoff.<br>
<div class="im"><br>
> The complicated (and unwritten) stage is to devise a method that checks the<br>
> connecting users priv key for being still password locked once they log in.<br>
> If it's NOT locked, they are kicked out and the pub key is removed from<br>
> ldap. Not sure yet on how to do this.<br>
<br>
</div>I would have to say this is just about impossible and should be<br>
impossible, even in principle, on several levels. How do you deal with<br>
the case of ssh-agent where the keys have been loaded and cached? What<br>
if they are hosted on an unlocked smart-card? How do you detect if they<br>
were originally password protected or not?<br>
<br>
What about if they are forwarded using authentication forwarding? This<br>
is actually an incredibly powerful facility allowing remote system to<br>
remote system authenticated key access while never hosting private<br>
keying materials on any remote server. How would you deal with<br>
automated processes (not all of this is run by a carbon based life form<br>
pounding at a keyboard)?<br>
<br>
Example... From an lbb (Little Black Box) located somewhere, a cron job<br>
runs a process that begins a process on a remote server. The key<br>
required for that process is stored on the lbb and loaded into an<br>
ssh-agent process for the duration of this operation. More so, the<br>
ssh-agent uses a script to validate each authentication request using<br>
the request acknowledgment hooks. The remote system, with no private<br>
keying material present, at some point initiates a connection to yet<br>
another remote server for, say, backup transfers. The connection is<br>
authenticated via ssh auth forwarding back to the lbb while the<br>
acknowledgment script confirms the authentication occurs at the correct<br>
times and the correct number of times during the process (and raises<br>
alarms if something takes place out of step or too many times). When<br>
the processes are complete, the connections are broken down and the<br>
first server has no way to authenticate to the second server, since it<br>
has no private keying materials present. No passwords are required,<br>
since the keys are stored on a system to which no remote login is<br>
permitted and which exists behind strict security barriers. You can<br>
build a complete state machine and engine based on this model using<br>
multiple keys to control highly complex interactions between multiple<br>
remote systems and keep them all secure with NO passwords and NO private<br>
key material present on the external sites and NO password on the<br>
private key on a highly secured staging engine.<br>
<br>
Second example... My laptop incorporates full hard drive (partition)<br>
encryption via LUKS (and has for years). All of my private keying<br>
material exists only on encrypted drives (or encrypted drive images).<br>
Passwords are merely static encryption on the keys. But, anyone with<br>
the ability to access those keys when the drives are unlocked (system<br>
running) would have the ability to trojan binaries or otherwise capture<br>
my passwords on those keys. I am required to have this level of<br>
encryption on my drives now for totally external reasons regardless of<br>
my use of ssh auth keys. I fail to see any value-add here at all where<br>
other, stronger, encryption prevails and dominates.<br>
<br>
In most environments I can envision where you would find this<br>
complicated scheme of insuring strong passwords on keys (even if that<br>
were possible) I would expect, just from a pure regulatory compliance<br>
standpoint, you would first require file system or drive encryption to<br>
protect other valuable private information. So, either you are not<br>
providing any value add with this additional layer of complexity or you<br>
are leaving other sensitive material exposed. I'm not sure I'm<br>
comfortable with that decision.<br>
<br>
This scheme also fails when you take into account hardware crypto<br>
devices such as smart cards and things like the tpm present on most<br>
decent laptops nowadays. These these are crypto devices that can store<br>
keys and even generate keys and can lock them in a way that they can not<br>
be retrieved from the device, protected only by a PIN, which is in no<br>
way shape or form going to comply with your idea of a strong password.<br>
Yet, this is vastly superior to a scheme of requiring strong passwords<br>
on ssh keys. If you are going to this much trouble, buy these people<br>
some OpenPGP smart-keys/smart-cards and save yourself a lot of time,<br>
expense, and headaches. You'll be more secure and your users will be<br>
one hell of a lot happier with strong security that's actually<br>
convenient and easy to use! Imagine that.<br>
<br>
<br>
So... I'd like to hear more about the requirements for this system<br>
you're working on. I've seen too many of these systems which are really<br>
designed to make the user's life more difficult but make them "feel<br>
secure" because it's an inconvenience being imposed on them rather than<br>
real security that is transparent and convenient but gains nobody any<br>
accolades and doesn't impress anyone that you're doing something to make<br>
them secure. A LOT of what I learn is from people in unique situations<br>
I never anticipated with problem requiring unique solutions I had not<br>
considered before. This sounds like one of them and I'm intrigued.<br>
<div class="im"><br>
<br>
> --<br>
> --<br>
> James P. Kinney III<br>
> I would rather stumble along in freedom than walk effortlessly in chains.<br>
<br>
</div>Regards,<br>
Mike<br>
<div><div></div><div class="h5">--<br>
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw@WittsEnd.com<br>
/\/\|=mhw=|\/\/ | (678) 463-0932 | <a href="http://www.wittsend.com/mhw/" target="_blank">http://www.wittsend.com/mhw/</a><br>
NIC whois: MHW9 | An optimist believes we live in the best of all<br>
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III<br>I would rather stumble along in freedom than walk effortlessly in chains.<br><br><br>