On 8/27/06, paul at clubi.ie <paul at clubi.ie> wrote:
> Your trust in Sun is appreciated. I suspect Sun (who have many
> excellent security people, from the top of the company on down,
> starting with Whit Diffie) perhaps would tell you the same thing as
> Colm is telling you - that the key file password protection is to
> protect the *user*, not the issuer (at least, when it is the user who
> 'opens' and decrypts the key file).
Yes, and when that user is part of a large organisation, the
organisation is the user, and there are no defined limitations in the
technology which would restrict the extension of this security to the
enterprise.
Its just clear from the experience found here that the technology
hasn't moved that way yet, but there is no doubt in my mind that it
will. The problem is obvious, the need is there, and the technology
exists to solve the problem. Stay tuned.
> Security is an old, old field. The tendency for people to place too
> much faith in the abilities of new technology to "solve" security is
> just as old, be it by the mistake of the inventor(s), and/or the
> misunderstanding of users. The latter of those possibly is what have
> fallen prey to.
No... I personally believe in the evolution of technologies, people
build on others successes and things get better. You can't always
stick your head in the sand and say definitively that what PKCS12
implementation schemes couldn't do ten years ago they can't do today.
Its not new fangled technology, its tried and tested and proven. The
security industry has been working with it for years applying it to
the business needs of the world at large. It appears the opensource
security movement haven't though.
> > 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.
>> The only way this is possible is if you have some hardware which
> never /ever/[1] gives up the secret key, hardware which handles the
> public key cryptography entirely internally.
>> Such hardware is available but AFAIK it's not something you could
> conveniently issue to every remote-access user, for reasons of price
> and size. The "never *ever* give up the secret key" aspect[1]
> particularly can make such hardware expensive. Cheaper, smaller
> 'smartcards' likely still allow a determined attacker to recover the
> secret key (e.g. the credit card and "ChipKnip" banking smartcards
> are vulnerable iirc).
That is the basis for the majority of PKCS11 devices. Values go in,
computation carried out on card, result comes out.
> Simply put: If the public key crypto is done in software on the host,
> it's just unavoidable for the secret key to end up in user-readable
> memory as things stand.
Technologies have moved on since you've learned this one. I'm not sure
about the opensource security toolkits, but the commercial ones allow
you to create encrypted memory allocations which avoid this, and in
those memory allocations, they specifically allocate in physical
memory and not virtual memory spaces else the allocation returns an
error and you can't do the operation. Check out the Baltimore jcrypto
api for more info.
> At best, you could make it just readable to administrator, but
> systems with privileged keystores[3] and public-key crypto are not
> common, and anyway such a system likely would still depend on the
> user to provide the keys for the keystore - it would protect the
> user[2], not the issuer of they key.
Subject to evolution... :-)
> If it is the user who must manipulate the keystore, they must have
> the secret key.
And there are no intractible computing problems which prevent the
application of centralised corporate policies to the password
protecting the keystore. Its simply that from what any of us have
experience of, we haven't seen it yet.
Since this whole thread got out of hand, i carried out a quick review
of freshmeat to see what opensource PKI elements exist. Its
practically non existent when taken in consideration against whats out
there in the commercial world. So until a group gets together and
replicates what exists in the commercial world, what you say above
regarding possibilities and capabilities under linux will possibly
hold. Just don't keep your eyes closed to the possibilities forever,
as the weaknesses expressed by yourself are so obvious it is only a
matter of time before someone addresses the issue.
Regards,
Aine.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
