[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

Re: (OT) CoolKey build environment and packaging



On 1/26/07, Todd Denniston <Todd.Denniston@xxxxxxxxxxxxxxxxxx> wrote:
Question, are ssh-agent and gnupg-pkcs11-scd different enough that the
functionality of gnupg-pkcs11-scd could not be integrated into ssh-agent,
i.e., give ssh-agent the gpg-agent interface too?

Yes, they are.
For a matter of fact they agent was not designed to handle smartcards,
but to load keys for the user in order not to request passphrase more
than once.
And there were written apart with different interfaces.
Because all private key operation were removed from based program, it
was easy to add smartcard functionality.
But this functionality lacks many security aspects of smartcards,
example: what happens when card is removed? What happens if card
session timeout reached?

GnuPG has dealt with some of these issues, but still cannot support
more than one card available in the system... Which is a very bad
especially for OpenSC users who have multi-pin card, which is
refelected as several tokens.

Since there is a lack of standards in Open Source community regarding
the application interface to a cryptographic device, there is much
incompatibilities between these two.

Although, GnuPG agent can serve also as OpenSSH agent... But there is
a problem... It required gpgv1 gets and not pgpgsm keys.. We thought
how to fake it... But have not done this already.
http://sourceforge.net/mailarchive/forum.php?thread_id=30762871&forum_id=50505
http://sourceforge.net/mailarchive/forum.php?thread_id=30792073&forum_id=50505

But GnuPG agent has many downsides...

It would just be nice to have one agent handling the card.  When the pcsc-lite
and coolkeys libs are not compiled with threading it is annoying to have to
input the PIN all the time,

If the Open Source projects had used a standard interface such as
PKCS#11, no agent should have been required. And they could have
shared the same devices and such. This is what I am working at...

After this, a simple PKCS#11 provider can be written, which supports
protected authentication path. This provider does not access any
smartcards, but have his own daemon which loaded many smartcard
specific PKCS#11 providers. It is a "PKCS#11 router", what makes it
special is that it can cache PKCS#11 sessions for the users. And since
it support protected authentication the application should not prompt
for passphrase.

But first I thought I should make as many application PKCS#11 aware,
and later take care of the above.

but IIRC on the muscle list there has been some
discussion of the insecurity of /var/run/pcscd.* (readable by any user on the
system after the card has it's PIN, IIRC).

Well... if your card is transact, there should not be a problem with
pcsc-lite, since it is only a channel in order to communicate with the
card.
Also secure messaging makes it more secured...
But the meaning of this is that the authentication is good for one
transaction, so no other transaction can be opened to the card using
your credentials.

But there are cards that are not transact.

My thinking is /tmp/ssh-RAND/agent-#### is, at least from a file system
perspective, more locked to the particular user... to bad coolkeys could not
use it to provide to all the NSS apps (oh no! circular ref!).

I don't understand.

Best Regards,
Alon Bar-Lev.

_______________________________________________
Coolkey-devel mailing list
Coolkey-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/coolkey-devel

[Home]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Red Hat 9 Bible]     [Fedora Bible]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

Powered by Linux

Google
  Web www.spinics.net