Version: crypto (using KDE KDE 3.4.3) Installed from: Unspecified Hello, Currently KDE cannot make use of smartcards in a simple way. I've added support for PKCS#11 based token into OpenVPN (www.openvpn.net), OpenSSH (has not been merged yet). I think I can do the same for KDE. The problem is that I am not a GUI programmer... So I need help in implementing the right dialogs. I've looked at the kdelibs code, and it seems that it should be quite simple. My PKCS#11 implementation support using many providers at the same time, specifying key name by token label, certificate subject it allows the user to remove/insert his card into a different slot (reader), it also does not caches PIN and caches sessions. It is OpenSSL method ready, so it can be integrated into OpenSSL based applications. Suggested components: 1. Certificate based authentication using HTTPS protocols. 2. KMail signature and encryption. Please tell me if you are interested in this. Best Regards, Alon Bar-Lev.
as far as kde's x-session level authentication functions are concerned ... is there an appropriate pam module that would work with 'login' (and, *cough*, gdm)? before we have that, i needn't even start coding. anyway, your suggestions seem to aim at PIM, so why do you file against kdm?
Oh... Sorry... It should have filed as KDE (general)... Can you reassign....? Regarding login... I've talked to you before... there is pam-pkcs#11 (http://www.opensc.org/pam_pkcs11/) that I use with a patch for kdm (bug#105631). I want to make KDE work with smartcard regardless of initial authentication. Thanks for the quick response!!!
ah, so this is where i know your name from. :) and i *knew* that i already talked about this with *somebody*. :))) btw, this touches an interesting point: SSO. i'm considering to build something like a generic credential caching agent based on d-bus, but i have to check with the ssh and gnupg guys first. maybe you want to initiate the discussion.
Hello, I am waiting for a reply... Maybe I did not make my-self clear... PKCS#11 is the standard interface to access cryptographic tokens. PKCS#11 is a free standard (http://www.rsasecurity.com/rsalabs/node.asp?id=2133). Most cryptographic devices support this interface, OpenSC also supports this interface. Making KDE support PKCS#11 will allow users to use hardware protected secret keys. Current applications are expected to support cryptographic tokens, and KDE lacks this feature. If you like to merge this feature, I have the knowledge to help and maintain. All I need is some help with the GUI framework after I finish the prototype. I think the first component should be the TLS/SSL implementation. Are you interested? Best Regards, Alon Bar-Lev.
this "hey-asshole-i'm-talking-to-you" attitude does not work, particularly for outsiders. if you want to join the community, go to developer.kde.org and see how to get involved. i'm putting the people i reckon to be responsible for the areas you touch into the cc list. this would have been your task in the first place.
Hello Oswald, > this "hey-asshole-i'm-talking-to-you" attitude does not work This was not my intention, I just thought that I was not clear enough at my original post. If this is the attitude of most of kde developers community, I skip my efforts. I don't like this kind of language, even for none native English speaker like me, this is way out of line. > i'm putting the people i reckon to be responsible for the areas > you touch into the cc list Thank you. > if you want to join the community, go to developer.kde.org and see > how to get involved I've read it, and it states that I should open a wish in the bug/wish database. > this would have been your task in the first place I thought it is better to approach through the feature channel. How could I know who is relevant?!?!?
> it states that I should open a wish in the bug/wish database. > filing a report is a first step, yes. attaching a patch is even better. but that's not enough if you want to get involved deeper - and you clearly did not check out the usual ways of doing so. > How could I know who is relevant?!?!? > in the first place by filing reports against the *relevant* products. other than that, there are copyrights in the sources and there is svn annotate. if you want to be taken seriously, do your homework. otherwise wait patiently. and no, not all kde developers are as direct as i am.
Adding PKCS#11 support to KDE (for authentication in konqueror and signing/encrypting in kmail) is quite important. E.g. in Austria we now have the "Buergerkarte", which is an official signature on a banking or on a health card. The OS of the chip card is proprietory, but there is a PKCS#11 library available to work with them (it works fine in mozialla/firefox/thunderbird). Unfortunately, I can't use that official crypto card with KDE... All that would be needed (yeah, I know, if things sound that simple, they rarely are) is KDE's ability to use PKCS#11 libraries. Cheers, Reinhold
This is the only thing missing from KDE. Storing RSA keys on harddisk is IMHO stupid, using smartcards and other security enabled devices is wise. There are many ways to connect to smartcards and other devices, using PKCS#11 interface is easiest to implement and we would allow us to use any kind of device as long as it has PKCS#11 driver. And it would be great to have kioslave (token://) that would allow to browse devices, read certificates, write certificates... that would be something :) Must have for KDE 4.
For emails this has been supported for several years now.
Am Dienstag, 24. Januar 2006 20:45 schrieb Thiago Macieira: > ------- Additional Comments From thiago kde org 2006-01-24 20:45 ------- > For emails this has been supported for several years now. Oh, really? Then can you please tell me how I can use my government-provided key on our personal ID cards with KMail? The Card OS is proprietary (www.austriacard.at), but they make available a PKCS#11 library that provides access to the card (actually via another government-certified application that does the actual talking to the card). For Mozilla/Firefox, you just install the module from the .xpi file http://www.a-trust.at/xpi/atrusttools/info.asp (there's basically only the libasign.so in that package) and you can sign mails. For kmail I haven't yet found any way to install any crypto plugins like that pkcs#11 library. And as far as I can see from mails to the gpa-dev mailinglist, gpgsm also doesn't implement an interface for pkcs#11 libraries... Applications like pkcs11-tools work just fine. Only KMail doesn't provide an interface to use PKCS#11 libraries. Cheers, Reinhold
See here for information on PKCS 11 support: http://www.gnupg.org/aegypten/ The German government funded the creation of these open-source tools and solutions. Maybe your government decided to go all-proprietary and it's not compatible.
Hello, PKCS#11 and not gpg is the standard to access cryptographic tokens. It is true that the open-source community tries to invent standards of its own, and have several competing projects (OpenSC vs GPG, pcsc-lite vs OpenCT, OpenSSL vs anyone else). As a result there is *NO* decent smartcard support in open-source environment. gpg does not support PKCS#11 tokens as a policy, they claim that it violates GNU licensing. I am in touch with FSF in order to strait this out. Applications should follow standards. Just like you follow S/MIME, TLS/SSL; PKCS#11 should be followed in order to access cryptographic tokens. OpenSC realized this and supply PKCS#11 provider that can access OpenSC cards. GPG also understood this by adding implementation of PKCS#11 provider (Provider NOT Access others') to the roadmap. Application that support PKCS#11 natively have the advantage of working with all environments. A simple PKCS#11 software token provider implementation of KDE Wallet, will allow KDE to access all cryptographic secrets through one standard API. This way the user will be able to use his secret key throughout KDE, including TLS/SSL, S/MIME, Certificate manager etc... I've implemented the PKCS#11 support for OpenVPN and OpenSSH, and may users are now happily using their smartcards whether they are OpenSC or proprietary to authenticate to peer. I can tell you that people expect and wait for application to support PKCS#11 and no other API. I offer my help. Best Regards, Alon Bar-Lev.
Am Mittwoch, 25. Januar 2006 09:51 schrieb Thiago Macieira: > See here for information on PKCS 11 support: > http://www.gnupg.org/aegypten/ While they claim that they support PKCS#11 (which is a defined API to access tokens on a smartcard, kind of an abstraction layer for smart cards), they really don't. They support cards that use the PKCS#15 standard (which is a data format) as their data format on the chip. This excludes many proprietary cards. See http://marc.theaimsgroup.com/?l=gpa-dev&m=105722061900566&w=2 Officially the Aegypten project supports PKCS#11, since opensc is part of Aegypten: http://marc.theaimsgroup.com/?l=gpa-dev&m=105722091000803&w=2 Never mind that gpgsm doesn't make use of pkcs#11, so the pkcs#11 support of opensc doesn't matter since it won't be used anyway :-((( > The German government funded the creation of these open-source tools and > solutions. Maybe your government decided to go all-proprietary and it's not > compatible. No, it just doesn't use a PKCS#15 compatible card. Instead they provide a driver that implements an PKCS#11 interface to access the card. As I said, applications like mozille/firefox/thunderbird (and probably also pam_opensc, although I haven't tried that) work just fine. It's just that Werner Koch is unwilling not to support the generic PKCS#11 API, but wants to access the cards directly using PKCS#15 or custom code: http://marc.theaimsgroup.com/?l=gpa-dev&m=105713450720974&w=2 So you might argue this is a problem in gnupg, but bottom line is that I can't use KMail to sign using my official certificate. Cheers, Reinhold
*** This bug has been confirmed by popular vote. ***
Hello Alon, if you find a simple way to include pkcs11-support in konqueror (for https) it would be a major step forward. Please go ahead. Thank you! Regards, Phil
This is also fairly important in Estonia as we can identify ourselves with ID-cards at banks and various other websites. Estonian legislation also says that a digital signature is as valid as a handwritten one. So this could make Konqueror an ID-card ready browser and that would be another obstacle removed from going Konq 24/7.
Same in finland, digital signature is legal one, even thou finland lags far behind Estonia in service development as I found out when moved to Tallinn. Anyway, I would definately use this, this is the only reason I've firefox installed.
I have to agree with Andres and Juha. If someone starts to implement the PKCS#11/15 etc support to Kmail and Konqueror, please do not forget those who actually have/can to use ID-Cards :) There is also a tool called cdigidoc (http://www.openxades.org/). Can this be somehow helpful?
Hello, We have recently finished initial release of gnupg-pkcs11-scd, it may be used in-place of gnupg scdaemon in order to access standard PKCS#11 smartcards. We will appreciate any comments regarding this. gnupg-pkcs11-scd is available at the following location: http://gnupg-pkcs11.sourceforge.net KMail is using gnupg (gpgsm) for S/MIME, so gnupg-pkcs11-scd actually enables KMail to use standard PKCS#11 smartcards. Another effort was made in the direction of QCA (Qt Cryptographic Architecture), a PKCS#11 plug-in was implemented, I hope Konqueror 4.0 will use QCA, so it benafit from its smartcard support. Maybe even KMail developers will be able to benafit from QCA, using it to S/MIME instead of GnuPG, and achieve better integration with smartcards as well. Conclusion We have KMail solution now, although quite complex none Qt integrated. I hope Konqueror will be modified to use QCA, so next major KDE version will also have smartcard support. After these two major application will support smartcards, I hope many more application will choose to do the same. Best Regards,
Any news at this front? Firefox in fc6 doesn't work anymore with opensc pkcs11 module :(
UPDATE: After some discussion with KDE developers, there will be no smartcard support in KDE at least until KDE4.1. As no one is committed into make this happen also in KDE4.1, I really don't know when this will be available.
Hmm, why so? If I understand correctly, there is already underlying technology (QCA - see http://www.kdedevelopers.org/node/2965 ) and all you need is to implement it in applications (though, my knowledge about this is quite restricted, so maybe there is something more...)
Now when 4.0 is closer and plans for 4.1 are underway, http://techbase.kde.org/Schedules/KDE4/4.0_Release_Schedule could this please see the daylight finally in 4.1? That was outlined in comment #22. There are people who really use these cards. See the list of national id cards: http://www.opensc-project.org/opensc/ 12 countries. Including the other cards and use cases, business use etc.
One of these 12 countries must have a C++ programmer capable of adding the support.
> One of these 12 countries must have a C++ programmer capable of adding > the support. Direct claim => Direct response... There is no problem in people willing to help. However, adding smartcard support should not imply rewriting the whole TLS/SSL KIO layer for KDE. Current situation, as I understand as none KDE developer, is that KDE developers did not completely agree which TLS/SSL layer to use now and in recent future. There are three options: a. Current OpenSSL implementation of KSSL, which is complex and does not conform to QtNetwork? This implementation is marked as one to be replaced. Any effort of making this support smartcard, may be waisted. b. Moving to Trolltech's QtSSLSocket implementation. This implementation does not allow many features required by a web browser: http://lists.kde.org/?l=kde-core-devel&m=118119612213249 But mainly, it will *NOT* allow smartcard integration as its private key is forced to be exportable. We can wait for Trolltech to support smartcards, but I believe this is out of scope for Qt implementation, the proof is the current QtSSLSocket design. c. Moving to QCA. This option was the one we aimed to. I added smartcard support into QCA for KDE to use it. So it is not a matter of developer help you require, you need to decide which TLS/SSL implementation you go with for KDE 4.x series, implement a working KIO interface which takes into account that keys are not exportable, and then (if it is possible) maybe someone will help modify this implementation to support smartcards. I can do this for KSSL and done this for QCA. I am waiting for you to decide so I can help adding this feature (comment#0).
> So it is not a matter of developer help you require, you need to decide > which TLS/SSL implementation you go with for KDE 4.x series, implement a > working KIO interface which takes into account that keys are not > exportable, and then (if it is possible) maybe someone will help modify > this implementation to support smartcards. > > I can do this for KSSL and done this for QCA. I am waiting for you to > decide so I can help adding this feature (comment#0). As an outsider who doesn't know much about KSSL or QCA, I can say the following: SSL support in kdelibs is currently broken. One person is working on fixing that, I suggest you contact him, he might know more (Andreas Hartmetz <ahartmetz at gmail dot com>). Maybe you can work together on that, but I really can't tell. I don't think SSL support will be ready for 4.0, but probably for 4.1.
> So it is not a matter of developer help you require, you need to > decide which TLS/SSL implementation you go with for KDE 4.x series, 4.0 was released recently, any updates to this roadmap?
SSL is basically working in KDE 4.0. Due to the changes in the SSL infrastructure it should be entirely possible to add smartcard support for SSL. I tried to make it possible as far as I could.
> Due to the changes in the SSL infrastructure it should be entirely possible > to add smartcard support for SSL Hi! Can you please refer me to the new implementation? As i don't see any change, kio/kssl is still used... Thanks!
Created attachment 23616 [details] OpenSSL engine certificate support for KDE3.5 this patch adds available certificates from OpenSSL engines to KDE store ( ksslcertificatehome ) and modifies ksslpkcs12 to make use of them. Tested to work against https kioslave, UI is far from optimal, i.e. it uses the username/password dialog to get PIN.
it would be great if kdm/kde would support smart card login! i think it's only a frond-end gui issue as back-ends are already here (opensc-project). people are using the smart card pam module to login, but kdm still asks for username and password and it's sometimes not needed (you have to press <enter> in the blank dialog). it would be great to add a picture asking to insert the smart card and to bypass the username/password dialogs when possible. (login name is not needed, it can be set depending on the certificate on the smart card, and password/pin is not needed if you have a pinpad reader that ask you to input the PIN on it's own keyboard). as said the pam module is already here, you don't have to pass him username/PIN but kdm still shows the dialogs on login and you have to press enter twice to login. it could be merged someway with the fingerprint login bug as they are similar (tweak kdm login gui) to make it look nice with this new tecnologies..
>>b. Moving to Trolltech's QtSSLSocket implementation. This implementation does not allow many features required by a web browser: >>But mainly, it will *NOT* allow smartcard integration as its private key is forced to be exportable. I am working on a patch like that for KDE trunk as well, which incorporates support for OpenSSL engines as means of authentication, so smartcards and any other authentication mechanism that has an OpenSSL engine exporting necessary RSA ops can be supported.
> OpenSSL engines as means of authentication This is not enough, as you cannot read the certificate from the engine. And it is difficult to detect card removal/insert, session expiration and much more. The problem is that I don't know if the kssl worth investment as it may be replaced. But if you like we can work on this together, my pkcs11-helper [1] solves the OpenSSL/PKCS#11 issues, but I lack the knowledge of Qt development. There is also QCA PKCS#11 plugin I wrote based on pkcs11-helper [2], but I don't know if QCA was added to KDE-4.1 roadmap. [1] http://www.opensc-project.org/pkcs11-helper/ [2] http://delta.affinix.com/qca/
FYI: Nobody of target kde developers* left to monitor this bug. All removed them-selves from the CC at some point in time. This shows the chances to have this in near future KDE version. * ossi is not responsible for kssl, konqueror or kmail.
>>This is not enough, as you cannot read the certificate from the engine. Yes, you can. Look at the attached patch. >>And it is difficult to detect card removal/insert, session expiration and much more. This does not need to happen through OpenSSL/Engine layer. >>The problem is that I don't know if the kssl worth investment as it may be replaced. It has already been replaced in KDE trunk, and i am working with a new patch against the trunk.
>> The problem is that I don't know if the kssl worth investment as >> it may be replaced. > It has already been replaced in KDE trunk, and i am working with a new > patch against the trunk. Replaced with what? QCA? QtSSL? Other?
With QtSSL, and KDE-specific code on top of that. Check out the sources in head. My patching work so far has been updating the latest QtSSL to properly handle client certificates ( they didnt even fire notifications about server requiring certificates ) and adding in possibility to use certificates and keys off of a OpenSSL Engine in addition to already supported PKCS12 files.
Does these changes involve gui modifications and if so, what kind of?
So you actually patching Qt to support engine? And provide the certificate from manual configuration? This is not a valid solution for smartcard users. It should be similar to firefox or IE.
::So you actually patching Qt to support engine? And provide the certificate from manual configuration? Qt needs to be patched anyway. Previously, in KDE3.5 kssl talked directly to OpenSSL. Now, QtSSL does that and kssl is hands off. So Qt needs to work with client certificates first. Look at my previously posted patch for 3.5 The certificate is still selected through a popup list on the UI, very much like FireFox, IE and previous KDE. In case there is only one applicable certificate, it can be autoselected, exactly like IE does. It is a very valid solution for smartcard, and other pkcs11 token uses. My last patch did not modify the existing UI in any way. In fact, i made it as unobtrusive as humanly possible so it can be painlessly applied without breaking anything, and i intend to do the same in KDE/Qt trunk. I will stop wasting time commenting here and just post a patch when (if ever) its ready, that worked better with the last version. Unfortunately i dont have much free time to dedicate to this in next coming weeks.
I won't waste your time. But I think the solution based on engine_pkcs11 cannot be complete. I don't understand why QtSslSocket was used and not QCA... Which already ready for all requested features. Anyway... I will wait to see what you are doing to Qt first.
http://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2008/Ideas mentions "Qt Cryptographic Architecture"
In response to 37: Replaced with KTcpSocket mostly. It is supposed to offer a simple and KDE-integrated way to use secure connections for KDE applications. It is also not very capable in that regard, yet. In response to 42: The reason to choose QSslSocket as the first backend to KTcpSocket was simply time pressure. Note however that KTcpSocket can as well use QCA::TLS as a backend and I tried as far as I could to make that possible. Note also that KTcpSocket is not even exported yet so necessary changes can be made. Alon: If you want to do something you should start ASAP so KTcpSocket can be made public soon, with Smartcard support. We'd need to figure out how to handle UI interaction and while doing that some related backend<->UI problems could be solved in one go.
> Alon: If you want to do something you should start ASAP so KTcpSocket > can be made public soon, with Smartcard support. We'd need to figure > out how to handle UI interaction and while doing that some > related backend<->UI problems could be solved in one go. Hi! This is the work already done in QCA, so supporting its interface will enable you to know that all OK. Highlights: 1. Application should not make any assumption regarding the number of certificates available for user. The certificates should be gotten from a "store". 2. Access to certificate store may be with or without authentication, even to the public part of the store. There are some tokens which requires authentication to public objects. 3. Access to the private key may be with or without authentication. 4. Authentication may be triggered several times during session, as there is session expiration feature for some tokens. 5. If user removes a token, then a a private operation is required, the user should be prompted to insert his token. For example: A user uses his token within a browser, then remove it, after several minutes during renegotiation the key is not there, failing the session will sometime fail an application, so the most friendly approach would be to ask the user to insert his token. 6. There should be an option to match between a specific operation and a specific key, so user will not be forced to select the correct certificate over and over, example: mail signing certificate or a certificate for a specific site. This can be achieved by allowing certificate/key serialization. 7. Public objects should be cached as it takes a long time to reload them each time from hardware. 8. As there are a lot of vendors and behaviors, configuration should be separate from applications, and allow specifying custom settings to allow backends behave correctly. The singer example at QCA demonstrate most of the above. I truly beleive that users will benefit greatly if QCA is used, as most of the work already done. I am sure QCA development team will do whatever needed to support such activity. Thanks!
Forgot one more... 9. Application should be notified if token is removed, so it can disconnect or clean whatever needed.
Any status update for this one?
Well... KDE 4.1 is about to be released... And no news for users regarding this. Even simple discussion as suggested in comment#44 did not take place.
Comment #22 > After some discussion with KDE developers, there will be no smartcard support > in KDE at least until KDE4.1. > > As no one is committed into make this happen also in KDE4.1, > I really don't know when this will be available. Comment #27 > I don't think SSL support will be ready for 4.0, but probably for 4.1. http://www.kde.org/announcements/4.1/ 4.1 is now out.
Hello, Can you still reproduce the bug with the latest KDE 4 release? Thanks.
Andreas, Alon: is there any progress for this matter?
Looking at http://delta.affinix.com/qca/, there is qca-pkcs11: PKCS#11 (for smart cards). http://delta.affinix.com/docs/qca/ http://websvn.kde.org/trunk/kdesupport/qca/plugins/qca-pkcs11/ : qca-pkcs11.cpp : last modifief 2 months ago. http://delta.affinix.com/2007/08/21/qca-and-smartcards/ is a blob about an example application called CMS Signer of the QCA distribution:interesting, can parts of it source be used to integrate it into konqueror? Is anybody working on integrating QCA into konqueror?
KDE team decided not to integrate QCA into KDE.
comment #53 is misleading, if nothing else. it was decided not to make qca part of the kde api by using it visibly. but it was explicitly stated that using qca to implement backend functionality is welcomed, and i think a few kde apps actually do that. of course that makes everyone's life harder, but oh, well. moving the bug to kdelibs to attract some attention and finally get a resolution. http://lists.kde.org/?l=kde-core-devel&m=117983487823873&w=2 (and the renamed subthread spawned from it) is the relevant discussion from back then.
Duplicate bug #215032
PKCS#11 based hardware tokens are now coming to USA too: http://www.nist.gov/nstic/ http://youtube.com/v/32P-IEmBfEA If KDE is not going to support this, this might become a selection factor for desktops. It's not just one app, but needs an integrated framework that takes time to get implemented and polished in all libs and apps. That's likely years than months. Firefox/Thunderbird/Gnome already have a long head start in this game.
Germany has changed their Personalausweis / id-card to X.509 based card at 2010. https://www.sit.fraunhofer.de/fileadmin/dokumente/info-material/deutsch/ePa_de.pdf http://en.wikipedia.org/wiki/National_identity_cards_in_the_European_Union what is the obstacle that we would: a) recognize X.509 certificates as is done with PGP-keys? b) properly support using / handling them?: * browser support * email signatures + encryption * display hw-token information * desktop login- / screenlock support sure there are more uses but that browser support is most important here. It would be interesting to count population sum of each country listed in Wikipedia article, we're talking about +100 million people here (not sure if they all use KDE thou... :)
Hello: In my OS Ubuntu 18.04 LTS, I install Cleopatra, it software presented this message: The GnuPG configuration self-check failed. Error code: 1 Diagnostics: gpgconf: error running '/usr/lib/gnupg/scdaemon': probably not installed scdaemon:Smartcards:/usr/lib/gnupg/scdaemon:0:0: Thx
This thread is super old and contains nothing particularly useful. There is some support for some smartcards in the implementations used in some KDE software. This bug doesn't request anything actually specific. Closing.
As a smartcard daily user, I can comment following: (In reply to David Edmundson from comment #59) > This thread is super old and contains nothing particularly useful. This is only thing on topic at KDE. There is nothing else, that I'm aware of. > There is some support for some smartcards in the implementations used in > some KDE software. There are some attempts, none of them work. User's point of view they don't exist. > This bug doesn't request anything actually specific. > > Closing. Title says: Add support of PKCS#11 (Smartcards) into KDE _what_ it should have said? It's a feature request.