Pinentry and GNOME issues

Two weeks have passed since last post, what happened since then?

Pinentry Prompts

Pinentry is an application to handle prompts for GnuPG, it should be able to ask for passwords and make questions.
Passwords of gpg keys can be stored in gnome-keyring through pinentry-gnome3.

As I talked in last post, some prompt types are not handled by gcr, these types are confirm prompts with one button, and confirm prompts with three buttons.

One button prompts are to inform/notify of something. They have only one way out, clicking the button, which means the message has been read and understood by the user. If the prompt is not system modal it still can be closed through right upper corner X button, but the outcome is the same as if the user clicked the button.

One-button prompt – Your passphrase is insecure

Three button prompts are to ask user a question and provide three answer options, the answers are, by default, “Cancel”, “Not ok”, and “Ok”. They are useful in situations when answering “Not ok” should trigger something that “Cancel” doesn’t, sounds obviuos. An example, can help explain:

Three-button prompt – Check trust in certificate

The prompt above is shown when adding a new root S/MIME certificate. If you cancel the operation, the certificate won’t be added, and that’s it. Clicking in No, will add the certificate to the trust list as not trusted, and future attempts to add the certificate will be denied automatically. Whereas clicking in Yes will proceed to the following prompt.

Three-button prompt – Check fingerprint

Here, this prompt has the same behavior for the three buttons.

Not supporting these prompts doesn’t mean that pinentry-gnome3 will not work, but user experience might not be the expected.

GnuPG supports pinentry programs without one-button and three-button prompts. In situations where there would be only one button, there will be two buttons, and one of them providing weird functionality.
Let me explain what I mean, in the sample one-button prompt above the user is generation a new gpg-key, passphrase constraints are enforced and the user has entered a short passphrase, so GnuPG has issued that prompt. The user must choose another passphrase!
Wether the user chooses to cancel, or enter the new passphrase, the return of the prompt is ignored and is unconditionally taken again to the password prompt to enter a new passphrase. The cancel button won’t work as expected and the user has to click cancel again in the prompt password to cancel the operation.
In the three-button prompt use case presented above, the certificate won’t be added to trust list as not trusted if the user does not trust the certificate or finds out that certificate fingerprint is wrong.

I started implementing these button prompts in Gcr and GNOME Shell right away, but I realized that to be a mistake without first discussion.

Stef is concerned with usability issues that may come up with a non-cancelable one button prompt. These one-button prompts could also be presented as gnome-shell notifications, but as cited before, in the presented use case a system modal prompt is issued again, and the notification may go unnoticed. Also, checking the fingerprint of certificates can be very difficult with system modal prompts, since it locks the entire screen.

GNOME Shell Prompt and mnemonics

You can see through above prompts that some buttons have a leading underscore, those are mnemonics for buttons set by GnuPG. Currently, gnome-shell system modal prompts don’t support mnemonics. So a fix has been made to strip out mnemonics indicators. An other usability issue here a feature existent in many pinentry programs is not available in pinentry-gnome3.

pinentry-gnome3 and gnome-keyring together

A new version of Pinentry which includes pinentry-gnome3 was released and Stef removed gpg-agent component from gnome-keyring.

We were looking for ways to tie pinentry-gnome3 and gnome-keyring together.
Our concern is to ensure that when gnome-keyring is running along with gpg in a GNOME session it can cache gpg passphrases if opted to. It may be easier to thinking the other (practical) way, how to ensure that gpg launches pinentry-gnome3 when running a GNOME session.

The suggested work is to make gnome-keyring depend on pinentry-gnome3 and tie gpg to pinetry-gnome3 through update-alternatives, gpgconf or pinetry-wrapper. I might discuss more about this in future posts.

Currently working

Current efforts are directed to resolving a possible bug between gpg and pinetry-gnome3 related to DBUS.

GSoC 2015 Project Intro and Progress

GNOME Keyring GSoC project

Hi, I’m Yuuma Sato and this summer I’ll be working on gnome-keyring as part of GSoC.

This project is about saving GnuPG passphrases in GNOME Keyring, which is not possible in newer versions of GnuPG due to a GNOME gpg-agent that can no longer attend the needs of GnuPG.

GnuPG provides a way to configure applications to ask for passphrases, these applications are called pinentry. And that is the proposed way to solve this issue. The pinentry will allow GNOME Keyring to manage GnuPG passphrases without interfering with other functionalities provided by GnuPG gpg-agent.

More about the project in GNOME wiki.

How did it start?

It’s been a week since coding period started, but before it even begins something that totally affects the project happened.
The development of a gnome3 based pinentry on GnuPG side to solve the same issue this project is about, its is not finished though.

Talking to Stef, we decided to change route of the project so that same thing is not implemented twice.
So, part of the work has shifted from building a pinentry from ground up to improving the one started on GnuPG.

Neal Walfied, who is working on the pinentry, explained that GnuPG requires some prompts not supported by gcr, those would be one button and three button prompts.
GnuPG uses a prompt with only one button to just notify the user, no input is taken. These prompts are used, for example, when passphrase constraints are enforced, a new key is being generated and the user has provided no passphrase. GnuPG informs that an empty passphrase is not allowed, and asks for the passphrase again.

The three button prompts are used in two situations, when marking a certificate as trusted, and when verifying the fingerprint of the certificate being added.
In both scenarios gpg prompts with a question to which you can give one of three answers.
When gpg prompts you to verify the fingerprint, for example, it gives you three options: “Correct”, “Wrong” and “Cancel”.

The changes to support new system prompts need to be made on gcr and gnome-shell.
Currently I’m working on adding support for one button prompts, but it still needs work.

GSoC Final Report

Since last report I have done some fixes and updates in the module and looked for the best way to load the module.

Fixes
I have resolved some memory leaks and updated the build system

Multiple sessions
I Changed the module to support more than one session at a time, it was faking multiple sessions to users while it was actually using only one.
I decided for a mechanism limiting the number of sessions to 16, no hard restrictions at all. But it can easily be changed to a mechanism with unlimited sessions.

Trust
NSS relies on some objects to check for trust on a certificate. These objects are created by NSS when a trust relationship is added. All certificate accessible to NSS were not trusted, the user  needed to set a trust relation with the certificate manually.
Now the module mimetizes these objects to NSS so that all certificates found by the module are trusted to protect e-mail communication.

Loading the module
There are some ways the module can be loaded by an application, using p11-kit, libgck, or NSS. A particularity is that the module will be loaded by Evolution,  but it won’t actually use it. The real user of the module is NSS, who performs the crypto operations. So, Evolution needs to load it and make it available to NSS.
I could not find a way to it with libgck. To do it via p11-kit you can use pkcs11-proxy.so, and with NSS it can be done directly via SECMOD_LoadUserModule(). To keep things simple for now, I’m going for NSS’ method.

Who does the loading?
Evolution, or Evolution Data Server,  needs to load the module at some point. For testing purposes I created a patch to load the module in Evolution (the most appropriate place may be in EDS). And I’m happy to say that the module can do its job.

You finished the module?

The core of the module is finished, it is able to perform the task it was built for.

• To expose X509 Certificate from Evolution Contacts;
• To allow sending of encrypted mail using a certificate retrieved from a contact in Evolution.

But it’s a PKCS#11 module, lots of application can use it in a different way, and the module needs to survive whatever situation it comes to face.
For example, it did not work with p11tool correctly. When p11tool wanted to list all objects the  module would return no objects at all. Situations like these will be corrected as they are found.

There are some issues I know that may affect the module, like:

• Certificate Decoding, it is done using SEC_QuickDERDecodeItem(), but I still have doubts about its robustness;
• NSS trust, although NSS trusts the certificate it only trusts it for real use when the trust is set through UI.

GSoC period has come to its end, but work is never over. I hope to keep working on the module and contributing to the community.

Thanks to Google and GNOME organizations for supporting this work. And thank you David Woodhouse for mentoring and helping me on this project.

GUADEC 2014

This year’s GUADEC was in Strasbourg, a very beautiful city with its old streets and architecture.

Core Event

The talks…
I really enjoyed watching talks about the work done, or is about to be done. You get to admire those people, and wonder how can they work so hard. And then you are working to make things better too, because GNOME is such a  welcoming community. And despite all the work done, still there is tons of things to do.
A few remarkable talks to me were Marina Zhurakhinskaya’s, Karen Sandler’s, Christophe Fergeau’s and Zeeshan Ali’s talks and Matthew Garett’s keynote.
All talks were not only great, but very inspiring too.

Birds of a Feather sessions

I attended to two BoFs after the core event.
During the Privacy BoFs I could realize how much work needs to be done to provide privacy, or safety, to GNOME users. I couldn’t help much, but I could get the idea of the current state of some applications and worries addressing users and applications.
The other BoFs attended was about GPG, the aim was to help setup a separated master GPG key from its signing and encryption keys (I didn’t even know that was possible!). The idea is to allow for normal usage, like signing and encrypting mail, while avoiding carrying around the secret part of the key that identifies you.

GNOME Intern 

As a GNOME intern via GSoC, I gave a lighting talk about the project, hopefully it was not too crappy ;).
Unfortunately I couldn’t get much GSoC work done during the conference.
The city called for some sightseeing and I couldn’t refuse to have a beer, although a bit expensive.

Thanks to GNOME Foundation for partially sponsoring my first GUADEC, surely  it’s a conference to remember for a lifetime.

GSoC Report #3 – Certificate Handing PKCS#11 Module

Journey to nowhere

Well, last time I posted the PKCS#11 module was not loading with modutil.

Looking up Evolution Data Server code to see what e_source_registry_new_sync() was up to, I found an interesting comment about a deadlock on e_source_registry_new_sync() that was occurring, the bug mentioned in the comment is a duplicate of a bug not marked as fixed.
Well, so I decided to try the asynchronous version, e_source_registry_new(), which calls a callback when done.
Changed the function flow, wrote the callback, tested. Nothing happened. I waited forever and the callback was  never called back.

After spending half a week trying to find out what was deadlocking the module,  I decided to test it in another machine. (Luckily I have two machines at my disposal). Settled up everything, modutil, and voila, loaded!
There is some kind of misconfig in the first machine causing the problem, which I don’t know what may be, since both run a Fedora 20 64-bit distro.

I decided put that problem aside and started coding on this new machine. But I will surely have to address this problem again, as someone else may get deadlocked too.

Edit: After all things described below were implemented  I tested it again, and magically it loads in that machine too.

Onward to fetching contacts!

Yay!

Improving queries

When asking for contacts, I only have interest in contacts which have a X509 certificate. So, I changed all queries done to Evolution to query for contacts with an E_CONTACT_X509_CERT field. There are times the PKCS#11 module will ask Evo for contacts which have a specific email address and has a certificate field, and there are times the module will require all contacts which have a certificate, regardless of email address.
The two queries look like this:

(and (exists "x509Cert") (is "email" "email@address.com") )
(and (exists "x509Cert") )

But every query asking for x509cert field returned nothing, as if there were no contacts with a X509 certificate. It turned out there was a little bug [0] in which only queries for existence of fields of type string returned correctly.
Thanks to Milan Crha it was fixed quickly, ;).

Stepping through contacts

The number of contacts returned when asking for all contacts’ certificates can be enormous. So I changed from e_book_client_get_contacts_sync(), which returns a list of contacts, to  e_book_client_get_cursor_sync(), which returns a cursor that can navigate through the contacts and fetch the required number of contacts.

Session management

PKCS#11 modules can serve a number of applications, or threads, concurrently. To separate context from one application to another, there are sessions.
I elaborated a small structure to store all info needed for an application, or thread context. For now, the module only know one session, every application that opens up a session will unknowingly share it with other applications. I wanted to avoid problems with data structures and sessions while implementing the main feature.
When the work is settled, the module can be expanded to be true multi-session.

Object management

Object management does need improvements. At first I believed that the module would be stateless, go to Evolution, get certificates, return and forget them.
Objects have an object handle assigned to them by the module. It can change from one session to another, or between two instances of sessions used one after another. But PKCS#11 API defines that objects are expected to have the same handle during a session’s life time.
So, the module needs to keep track of the objects and it’s handles. Currently the module assigns a new handle to every object found.
This is not a priority and will be implemented soon.

Certificate structure

The certificate received from Evolution is now converted and put in a CERTCertificate structure.
I tried to do it before but without success. This time I have figured out a way to convert the DER encoded certificate into the mentioned structure (no crashes or SECFailure’s).
The conversion is beneficial as many DER encodings fields become available right away, like the DER encoding of the certificate issuer or subject. It eliminated some auxiliary functions used to parse the DER certificate.
The contact’s certificate in a CERTCertificate may ease future work as well.

So, where are those certificates

As Evolution still was not capable of sending encrypted mail, guided by the logs generated by PKCS#11 Module Debugger [1], I started to answer other queries the module was receiving, which I was not responding to. For example NSS asks for certificates issued by a specif issuer during a search, and for some objects NSS would ask for the CKA_ID of the object, an identifier of the object used to bind corresponding certificate, public and private keys.

Issuer name search

The data received in the search template is a DER encoding of the issuer name, and the certificate returned from Evo is DER encoded. A simple comparison of the issuer name encoding was enough.

Get attribute CKA_ID

I spent a lot of time and effort on this one, and I couldn’t do it. NSS has lots of useful functions, but most of them are only available internally. They are not exported in their libraries. Or maybe I’m the one who couldn’t find them.
The only solution at sight was to parse the certificate and calculate the CKA_ID myself. But that would be too much time consuming and error prone, as the value differs by algorithm. RSA, DSA, ECDSA each one of them has a way to calculate CKA_ID.

Got lucky

Seeing no way to get out of the situation, and in a last effort, I started to search around randomly.

And by chance, navigating on the certificates list shown by Evolution in ‘Preferences’ menu, right clicking the certificate I found out that Evolution (or NSS) did not trust the contact’s certificate.
I marked it as trusted, and I could send a message encrypted, wohooo!

Receiving encrypted mail

You can’t see it, but this email was encrypted using a certificate retrieved  from Evolution addressbook by a PKCS#11 module.

Next steps

• Take a look at this trust mechanism, and check if it is possible or secure to mark it as trusted from the module.
• Refine the module
• Start working on integration with Evolution

Well, time to pack my stuff cause

[0] https://bugzilla.gnome.org/show_bug.cgi?id=732983

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Tech_Notes/nss_tech_note2

GSoC Report #2 – Certificate Fetching PKCS#11 module

Last week I had some slack from college classes / projects and I could get some work done.

Automagic

Compiling the module obviously needs to be easy, so adding autotools was mandatory. Despite having used configure, make, make install commands several times, I have never added autotools into a project.
After some work the project compiles using autootols, it certainly needs some improving, but now is not the time. I had other concerns at that time…

Fetching Contacts

The way the contacts would be accessed from the PKCS#11 module was still uncertain to me. My mentor, David Woodhouse, said that I could run into access control issues, so I was eager to know if there would be trouble.

Using the interface provided by libebook.h I built an application that asked Evolution for contacts, actually, it was very straight forward to do it. ;)
Having learnt the way of getting contacts’ data, I mimicked the logic into the PKCS#11 module.

Now I needed to test the module’s new capability, but I wanted to have more control than simply loading it into NSS and reading debug logs.
So I wrote another test application, which loads the PKCS#11 module and calls for PKCS#11 methods.
Well, this application can successfully fetch X509 certificates from a contact in Evolution address book! yey!

So, I happily rushed to load the module into NSS to see that it…Hangs, and NSS doesn’t even get to load the module.
It is hanging on its initialization, while asking for Evolution’s source registry. Looks like it’s having problems with DBus and waiting on a pthread_cond_wait(). Hopefully I’ll get through this quickly.

Progress and schedule 

Surely there are some edges to round up but I am pretty much satisfied with the progress till now.
But rough June is not done yet, and I still have an exam to go through.

What comes next

I’ll focus on finishing the fetching and handling of certificates.
After that I’ll go on to implement module internals like proper session object management.

July looks promising, with more time to work on GSoC, vacations, and  I could not not forget to mention that I’ll be attending GUADEC.

Lots of thanks to GNOME Foundation for helping me attend the conference by sponsoring me.

 

 

GSoC Report#1 – Mini PKCS#11 module

A week has passed since coding period started, so what have been done? Actually I started coding earlier, as I’ll be attending to classes until end of June.

Dummy module

First thing to do was to build a mininal do-nothing PKCS#11 module loadable by NSS.

That was pretty much easy, got the headers defining the API from RSA Labs version v2.20 as it’s the current, implemented a lot of dummy functions and a few functions regarding information about the module, available slots and tokens. PKCS#11 standard requires you to implement every function, even if it is not going to be implemented by your module. So you’ll see functions like this:

CK_RV C_SeedRandom (CK_SESSION_HANDLE hSession,
	CK_BYTE_PTR pSeed,
	CK_ULONG ulSeedLen)
{
	return CKR_FUNCTION_NOT_SUPPORTED;
}

All you have to do is return CKR_FUNCTION_NOT_SUPPORTED.

The one and only certificate

Next, effort was around embedding a hard coded certificate into this minimal module and make NSS list it.
The intent of this was to get to know how applications requests for certificates. The module still is very simple, implementing functions to search objects and getting attribute were enough.

During module initialization I instantiate my certificate. When a search query comes, and searched attributes matches my certificate’s attributes, a handle to the certificate object  is returned. (It may be worth to post about PKCS#11 related stuff, like how these objects, attributes and handles work)

Also, NSS requests for a list of mechanisms implemented by the module. The proposed module does not need to implement any cryptographic mechanism. It will only care about object queries and responding to them. After loading the module with modutil, we can use certutil to ask for certificates, both are NSS tools.

Oddly, commanding certutil to look for our certificate yields nothing. But when asking certutil to serch specifically in our module, it does find it.
I believe it is related to an NSS flag/mechanism called FRIENDLY, which indicates whether a module allows to retrieve some public information without the need to login. Looks like only NSS uses such flag/mechanism, as Evolution and Firefox, both were capable of listing the hard coded certificate.

Hard coded certificate listed

What comes next

I realized that I did not publish the proposed schedule anywhere (it is here now)
I’m a little bit ahead of schedule but that was the intent as my exams are still to come and I’ll have to slow down a bit, June is going to be a rough month.

I believe now is the time to study how I’m going to get a certificate in Evolution addressbook, along do some minor improvements to the module, like using autotools.

Links

Source code can be found here.

Work on Evolution

So I got into GSoC 2014, and what am I going to work on?

My project is for Evolution, a personal information manager from GNOME. Among the many features it provides, it can manage contacts and send encrypted and signed email to them.

To send encrypted mail you need to have your addressee’s certificate at hand, and that’s when trouble comes up. You need to have the certificate in a place where NSS can find it, as Evo uses it as its backend. Certificates installed in NSS certificate database can be used to encrypt mail, but if it is somewhere else, like in an Evo contact, Evolution will fail to encrypt the email. NSS can also look for certificates in installed PKCS#11 modules. PKCS#11 modules can be seen as providers of cryptographic keys and certificates.

That’s where the proposed module comes in, connecting NSS to Evolution address book.
The module will receive queries for certificates issued for a specific email, and will return the certificate if found amid the contacts.
There will be some work on answering the queries so that NSS understands the module’s answers, the module should be simple and minimalist, so required functions will be implemented as needed; then some work on searching for certificates in Evolution’s address book, here there may be some access control issues; and then making Evo load  the module on NSS .

More details to come…

The first step

I have been accepted into Google Summer of Code 2014!

This is my first GSoC project, and my first time contributing to open source. Feels like the very first step into an awesome journey.

During this summer (winter, in my case) I’ll be working on building a simple PKCS#11 module for Evolution, GNOME’s personal information manager. The module will allow Evolution to send encrypted mail using X509 S/MIME certificates coming from Evolution’s address book. For more info check the  wiki project page.

My mentor is David Woodhouse, lucky me to be in such good hands. I promise not to trouble you (so much), David.

Thanks to Google and GNOME for this great opportunity.

I’m quite sure it’s going to be a great experience,
so let the fun begin!