[ILUG] SSH dictionary attacks.

[Aine Douglas]

On 8/25/06, Badger <badger at scattermail.com> wrote:
> Sorry Aine. Clearly your not in the mood to discuss this further and I'm
> certainly not going to try and stong-arm you into doing so. I've been
> asking questions and making statements because things just don't add up
> in my mind. I had hoped the the answers would reveal themselves through
> discourse, but it doesn't look like that will happen. It's quite possible
> that all the answers have been provided but I'm just too dense to see
> them.

I assure you its more to do with the time of the week than the time of
the month. Its over burdensome getting into the bowels of the PKCS
standards on the back of a query about SSH dictionary attacks...

> I would just like to make a couple of points to finish, just to clarify
> where I was coming from. After all, I don't want this list left with the
> impression that I was making wild statements about security breaches.

Having thought about it more, I think one point your missing is the
difference between key creation and certificate creation. I can't
speak definitively for ros, I can only speak in respect of theory and
what I've done on other projects:

* Key creation is done locally, a private key and a public key
* The public key is sent to the CA for signing, and is signed with the
CA's private key, and the certificate is sent back to you
* The public and private key are put into a keystore package of some
description, such as PKCS12, or to a smartcard device through PKCS11
* A passphrase to protect the contents is created locally, and in the
case of ros, I believe that it is transmitted back to ROS for customer
services reasons.

Everything else depends on policy and enforcement of policy at every
level. Thats what PKI is about, defining policies and defining what
should be done to implement those policies. PKI would typically, in my
experience, be 90% policy documents and 10% tools.

There would be a policy for password retireval at ros, and I'm sure
passwords are not handed out willy nilly.

In the event of a courtcase, and you claiming that Ros had your
private key, if ros has such a policy in place they would be able to
show that every version of the ros applet that runs on their site was
tested for validity using signature verification, and they have
archived the codebase for every issued version of their software, and
thus can prove that no version of their software ever uploaded your
key. If they adopt long lived signatures on their archives, then
they'll be able to do that.

> My understanding is such that the Java does not natively support PKCS#12
> format. Therefore, for a java applet to access a PKCS#12 filestore, it
> needs extra code installed. Since this code doesn't ship with Sun's
> JVM, I assumed that it was installed by the ROS at some part of the
> signup process - hence my statement that "they provide you with the code
> that extracts the key" from your keystore.

The java specification provides stubs for the crypto functionality but
no implementation. This is done to satisfy export restrictions.

Digitally signed security providers can be inserted into your JVM to
provide this functionality. The digital signature proves that it is a
trusted security provider, and to attain this status, must undergo
some checks, either at a policy level or an implemention testing
level, I'm unsure which or if either, I've never been there. On a
personal level, I trust sun to only trust trustworty security
providers in my JVM. Thats a personal trust decision made by me.

> Another statement that I made was that "they provide you with the code
> to manage your private key". I said this because you previously said:
<snip>
> I read this to mean that you could only really manage your key with
> the java applet provided by ROS - not with standard tools like openssl.

Binary -v- source-code.

> When I added this up in my head it said that the same entity (ROS) that
> the held you accountable for the use of your key was the very one who
> controlled your access to your key. Personally, I would not like to
> be held accountable for my signatures under such circustances.

But thats the whole basis of their PKI system, that any fears or
doubts you have in their implementation can be elayed by examination
of their policies, and that they use cryptographic means, ie, signed
binaries etc to prove that they have maintained the standard set out
in their policies. So before making a judgement call, you got to
request their policies and see if you like them or not. If you feel
done by at a later date, its up to them to be able to prove in court
that they stuck by the policies. If they've adopted a proper non
repudiation scheme utilising trusted time stamps and long lived
signatures in signed data stores, they will be able to do so at a
level that you will be happy with, or in the case of a non techie,
that their technical expert witness will be unable to refute.

> >From a detailed technical veiwpoint I would rather that the code
> from ROS or whoever to run in the java sandbox and make calls to the
> standard java crypto libraries to request (rather than arrange) a
> signature from me. I would also like to be able to have full control
> over how my private key is stored so that I can use standard tools like
> openssl to protect it. But I guess we can't all get what we want.

Its a judgement call, and in my judgement, I'd prefer to have my keys
stored in a p12 as if used properly by properly created applications,
my private key should never touch the raw disk, or raw ram, or
pagefile. You go a route with a raw key which you'll protect using
openssl or someother crypto too, you're going to expose your private
key to potential extraction using a tool such as lazarus from the
coroners toolkit. Google for TCT.

> No need to reply to this, I just wanted to show that there was some
> trace of logic in what I was saying.

Well, for the sake of some poor sod researching ROS on google and
coming off with a statement that ROS is full of design flaws as it
says so on ILUG's web archives, I think its only fair to fill in the
picture.

> As for the other points, I'm sure you were right and I was just
> confused. I'll take a look at the RSA Faq, thanks for the tip.

Probably more appropriate to take this up with me further offlist if
you have more queries... I'm happy to share what I know, but I don't
think this is the forum.

Aine.