<br><br><div class="gmail_quote">On Fri, Dec 24, 2010 at 12:59 AM, 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;">
<div class="im">On Fri, 2010-12-24 at 00:21 -0500, Jim Kinney wrote:<br>
> Here's a scenario:<br>
<br>
> multiple rings of security with the innermost having FBI background checks<br>
> and security clearances, vault doors, dedicated fiber lines, treason<br>
> convictions etc. I work with the stuff outside of that arena and it has two<br>
> layers: non-classified but sensitive and/or export controlled, and<br>
> non-classified and not export controlled. Certain groups of people are not<br>
> allowed to connect except to the outermost , unsecured network.<br>
<br>
</div>Yeah, pretty much standard fare.<br>
<div class="im"><br>
> People need to be able to ssh into the controlled arena to "do things". The<br>
> laptops are currently not full drive encrypted (windows is a problem and the<br>
> Mac systems have a different issue - no one is use Linux laptops which don't<br>
> have a problem with drive encryption). So the need to keep ssh keys<br>
> encrypted is high.<br>
<br>
> In general, people are lazy. If they can find a way to remove the encryption<br>
> from the key, they will. Thus the need to find a way to test if a users key<br>
> is _still_ encrypted.<br>
<br>
</div>What you have just described, to me, screams "smart keys". Putty,<br>
Absolute telnet, et al ssh clients support these things and this is the<br>
only really effective way to deal with this. The keys are on a USB<br>
smart-key (NOT a USB memory key or SSD) or a smart card w/ reader and<br>
you don't need to worry about this. They CANNOT screw it up. They have<br>
to enter a PIN and get it right. No intruder, NO INTRUDER, can extract<br>
that private key. The gov has these keys now. I forget the acronym but<br>
it's something like UAC (Universal Access Control) or some such. This<br>
is a solved problem and ssh works with it very well. I have keys on my<br>
Aladden smart key for ssh access. You would have to steal the key and<br>
beat the PIN out of me (3 failures locks the key and requires a security<br>
officer key to reactivate).<br></blockquote><div><br>Ah ha! CAC. I've seen this acronym around. crypto-access-card maybe. I will start the push for more info on those and some details on usage.<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> the only reason I have for keeping keys in the vault is for back checking in<br>
> the event of a breach. The key hash is more important to me as it can be<br>
> sent around and used to check if a key is encrypted or not. It the new key<br>
> 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.<br>
> 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<br>
> auditd logs a bit more but I think they don't have that level of detail<br>
> during a connections authentication section.<br>
><br>
> These remote machine are OS controlled by me and the others I work with so<br>
> it's possible to add in an sshd that allows a connection back triggered by a<br>
> connection to my network. That back connect can run a hash on the connected<br>
> user's priv key and compare it to the one hash of the unecrypted key stored<br>
> earlier.<br>
<br>
> This would be easier if ssh had a patch that allowed a compile flag<br>
> requiring a password on keys.<br>
<br>
</div>This is intrinsicly and inherently impossible. It would violate a very<br>
principle of cryptography. Such a thing could only be enforced at the<br>
client but the server would have to depend on the client and the client<br>
must be assumed to be NOT trustworthy, only the key is the key and to be<br>
the determining factor. Therein you have a conflict. How does the<br>
server validate that the client truthfully enforces the policy that<br>
allows or disallows the keys. This can not be. Such schemes can not<br>
work.<br></blockquote><div><br>It would be the ssh client side thing only. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> Happily, most of the people that need this access are mostly carbon-based<br>
> life forms. A few are probably part silicon and sulfur...<br>
<br>
</div>:-P<br>
<div><div></div><div class="h5"><br>
> On Thu, Dec 23, 2010 at 11:50 PM, Michael H. Warfield <<a href="mailto:mhw@wittsend.com">mhw@wittsend.com</a>>wrote:<br>
><br>
> > 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>
> ><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><br>
> > >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<br>
> > 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>
> > 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>
> ><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<br>
> > with<br>
> > > key as text on paper with a barcode for fast input, placed there buy<br>
> > someone<br>
> > > with a firearms license at the federal level), then the user must enter a<br>
> > > password to encrypt the key.<br>
> ><br>
> > 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>
> ><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>
> > 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>
> ><br>
> > > The complicated (and unwritten) stage is to devise a method that checks<br>
> > the<br>
> > > connecting users priv key for being still password locked once they log<br>
> > 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>
> > 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>
> ><br>
> ><br>
> > > --<br>
> > > --<br>
> > > James P. Kinney III<br>
> > > I would rather stumble along in freedom than walk effortlessly in chains.<br>
> ><br>
> > Regards,<br>
> > Mike<br>
> > --<br>
> > Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw@WittsEnd.com<br>
> > /\/\|=mhw=|\/\/ | (678) 463-0932 |<br>
> > <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<br>
> > all<br>
> > PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!<br>
> ><br>
><br>
><br>
><br>
> --<br>
> --<br>
> James P. Kinney III<br>
> I would rather stumble along in freedom than walk effortlessly in chains.<br>
><br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">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>