|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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]