[ILUG] SSH dictionary attacks.

[Badger]

I agree with what Colm Mac Carthaigh said in the alternate reply
to your post Aine, but I just wanted to drill down on some of the 
other points: 


On Fri, Aug 25, 2006 at 11:35:53AM +0100, Aine Douglas wrote:
> On 8/25/06, Badger <badger at scattermail.com> wrote:
> >I'm not sure that I fully understand your description of the
> >ROS service. For instance, when you say the user's password is
> >XOR'd, what exactly is it XOR'd with? Also, could you clarify
> >if there are two passwords in operation: one for the private
> >key, and one for the keystore (the pkcs12 file).
> 
> A PKCS12 file is both, check the RSA faq for more details. I forget
> what its XOR'd with, probably itself, or itself backways. If its
> really important to you, I can check it out, still have the rebuilt
> code here somewhere.
> 

Well it's not going to be XOR'd with itself and then have it's last
bit flipped - they'd have just used the number 1 instead. In asking 
this question I was trying to ascertain whether the password for the 
file was trivial to attain from the password the user provided. From
your reply I gather that you think it is a trivial transformation. If 
this is the case then it should also be a trivial matter for someone 
to write a tool that changed that password to something that defies 
the company password policy.

It's possible that it's not a trivial transformation though - perhaps
it uses a private key on the ROS server to generate a HMAC of the 
user's cleartext password which is then sent to the client to be 
XOR'd with the password the user provides, or something like that. 
Under these circumstances then, it would not be trivial to write a 
tool to change the password/passphrase which guards the users private 
key. Having said this, it's important to note that nothing like this is
covered in the PKCS12 spec. 

I'm no security geek, so please patch my understanding if you see fit. 
I've skimmed through the PKCS12 spec as posted at:

    http://www.rsasecurity.com/rsalabs/node.asp?id=2138

Is this the document that you are talking about when you say "RSA faq"?
If not, could you provide a link to the document you are talking about
as I would like to understand this stuff a lot better than I presently
do. 

Found the following document from Peter Gutmann (Professional Paranoid
and author of the Godzilla Tutorial) quite amusing:

    http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html

It's titled "PFX - How Not to Design a Crypto Protocol/Standard".

> >The reason that the ROS can control policy with respect to
> >key passwords is that the user is running ROS's client. This
> >java client, which you download from their site, can apply
> >policy in any manner that it wants. The whole PKCS#12 thing
> >is incidental. In fact, there's really no need for them to
> >store the private key on the user's disk at all - they could
> >have stored them in some encrypted form on their own servers
> >in a similar vein to what Hush Communications do with HushMail.
> 
> There would be legal implications of that with respect to non
> repudiation, and ROS couldn't actually legally depend on signed tax
> returns in such a manner. The key must be in the posession and control
> of the signer. Thats stipulated by law. Hushmail provide a secure
> communications platform, they're not interested in the legal validity
> of digital signatures for the purposes of non repudiation.
> 

That's a fair point about the legality of the situation, I hadn't
considered it from that perspective. It's ironic though, from a
technical point of veiw I would imaging that keys are a hell of a lot
less likely to be abused when they are sitting encrypted on Hush's
servers, than when sitting password-protected on the average
user's hard disk.

While the private key is in possession of the user, I think it's more
than a stretch to say that it's in their control. Even though this is
somewhat off-topic, I comment on it more below.

> >The actually service carried out by ROS occurs over a closed
> >protocol. I imagine that if you could reverse engineer your own
> >client that could communicate with the ROS server using that
> >protocol then you could store the private key in plaintext if
> >you wanted.
> 
> No. The PKCS12 format does not permit this, check the RSA faq... 

Perhaps you could elaborate on what you understand PKCS12 to be. From
what I understand it can be used for (at least) two different things.
First, it can be used as a basic keystore format for saving you private
keys (and a bunch of other stuff). And, Secondly, it can be used as a
transit envelope to transfer personal information from one computer to
another. In the second case, the "personal information" is usually
private keys in PKCS#8 format that are symmetrically encrypted in 
their own right. 

I would imagine the ROS are using PKCS12 as a keystore format only (as
in the first case above). Their applet would access the PKCS12 keystore
(utilizing code that is not in the Java Standard library since PKCS12 
is not natively supported in Java) to extract your private key. After
extracting said key and using it to sign tax return, the applet would 
submit that tax return via a HTTP post. I doubt that ROS would 
bother to use PKCS12 on the wire (second case above) as a format to 
transmit your tax return - what would be the point?

Thus, if I were to reverse engineer a client I could store the key on
the disk in plaintext bypassing the whole PKCS12 thing altoghther. In
other words, the 'PKCS12 format' would not be in any position to permit
or restict my client.

> ... Also,
> understand that the ROS applet is purely for authentication and for
> signing. Everything else is carried out through webservices. Signing,
> for legal purposes, takes place on the client machine, not the server,
> thats a legal stipulation surrounding the non repudiation of digital
> signatures. It boils down to, did I sign the doc electronically on my
> machine, or did I send my doc and my key to ROS and get them to sign
> it for me. Personally, I wish it was the otherway, but the drink
> driving law experts were busy or drunk that day, and the guys who
> don't leave loopholes were on this case.
> 

Just in case misunderstood something that I said, I certainly didn't
advocate sending the private key to the ROS service to have it used to
sign a tax return there. In the case with Hush that I mentioned above,
Hush use a java applet which runs client side and does all the signing
and encryption there. 

It's a little off-topic, but it's worth noting that the ROS were a
corporate, rather than a Governmental, entity, it's highly unlikely that
the would have been able to role out such a service: 

- They provide you with your private cert
- They keep a copy of your passphrase for customer support reasons 
- They provide you with the code to manage your private key
- They provide you with the code that extracts that key for use
- They probably use the standard java api to sign with the key 

It's comical that all of this exists so that the user of the ROS 
service cannot repudiate a signature made with 'their' private key. If
your local bookmakers provided you with such a fancy service which
allowed you to place bets on credit with them, would you use it?

> 
> >> So... if you want to manage users passwords for certificate files, you
> >> need to wrap with something like that which uses software traps to
> >> archive passwords etc if necessary. Its really what PKI is all about,
> >> scnearios and policies and mitigating the risks. The joys of
> >> opensource software is that this can easily be implemented in an
> >> organisation without having to invest heavily in employing a large PKI
> >> implementor!
> >>
> >
> >Hmm! PKI == kludge
> 
> Actually, if you read the Sunday Business Post "comptuers in business"
> magazine whenever they run a security story, you'll see the same three
> or four names crop up, the boys who pay their way in to comment on
> security in the magazine. So PKI actually == an expensive date with
> one of those three or four ugly models!
> 
> :-)
> 

me = new Guise(Role.PKI_EXPERT);
pkiScallywags++;
me.sellKludge();