Recently in Cryptography Category

Do you know how modern email protection works?
Not really? You are not alone.

For a simple picture of email encryption most people think of a box in which they place their message that can be locked with a single key. Once the message is in the box and the box is locked, it can safely be handed over to someone (the mailserver) taking care of the transport to the intended recipient. This simple picture is not too bad because, in a way, that's what happens. But on the other hand this picture is fundamentally misleading to understand how email encryption really works. In other words, the reality is different.

If you follow this simple model alone, and many of us have no alternative, chances are, that you will make dangerous mistakes when you use email encryption or that you simply don't know how to use it. And that is not your fault.

Let me help you understand the basic idea behind modern email encryption to get a realistic picture of how it really works. A picture, that can lead you to do the right thing and to know why.

Why is the simple picture fundamentally misleading?

Because modern email encryption has two very different boxes used to lock a message. You probably haven't heard of the other type of box yet. But the second one plays the most important role in the whole process.

The Ordinary, Single-Key Box

Of course, there is a place for the ordinary box in email encryption that can be locked with a single key. In the real world such a box would come with a pre-fabricated key attached when you buy one in the shops. But the single-key box for email encryption works a little bit differently. You can buy a single-key box without a key and pick any key afterwards in a way you like, because a key is only a very, very large number. Once you lock the box with the key you have deliberately chosen (and nobody knows which one you took) the internal mechanism of the box changes in a way that this box (once locked) can only be opened with the same key or a copy of the same key. The experts today call this box the AES-box and the number you've selected the AES-key.

Well, the message locked in the box is ready for travel and the recipient receiving your locked box will only be able to open it, if he has a copy of the key you used to lock it.

I'm sure you see the problem that arises here. How would your partner on the other side know the key? Without the key it will be impossible to open the box.

That's a really hard problem, because you cannot attach the key to the box or send it with another courier. The key has to reach your partner in a safe way, or all security is lost.

The Invention of a Double-Key-Box

Some three and a half decades ago three clever guys invented an entirely different kind of box that revolutionized the digital world. The new box opened up new possibilities that were unthinkable before. I admit, there is no real-world example of such a box and that may be the reason why most people don't understand what they do when they use this kind of box in practice. And we all do use it when we surf the internet. Believe me, everything we do today to secure our online life is based on this new double-key-box. Paying credit to the inventors, experts call the new box the RSA-box.

How Does the Double-Key Box Work?

You can put a message into the box and lock the box with one key that you own. But once you've locked the box with this key you cannot open it with this key again, it remains locked. The only chance to get the box open again is to use a second key, which is a totally different one but which is related to the key used to lock the box. Both keys form a tightly bound pair where one key can undo the locking done by the other.

For email encryption those double-key-boxes are used to make sure that only one person is able to open the box, the recipient of your encrypted message.

But there was a problem, do you remember? You cannot send the key across the world together with the locked box.

Well, actually you can, and the message in the box will remain secure, too.

Sounds like a miracle? No, not at all, we now have double-key-boxes.

Imagine, you can make copies of your keys very easily. After all, keys are only large numbers. For email encryption to work properly, all you have to do is, make a key pair and circulate copies of one of your keys to everyone who may wish to send you an encrypted email. There is no risk in sending one key (the public key) out into the world so that everyone can get a copy. As long as the other key (the secret or private key) remains secret, all is fine. The secret key, on the other hand, has to be guarded as carefully as the crown jewels. If it falls into the wrong hands, all is lost (again).

What is really going on?

Before we can start to encrypt a message we have to get the recipient's public key. If we don't have it, we cannot do anything. I suppose you know why? To prepare our message for safe travel, we want to use a double-key-box and lock it with the recipient's public key. In doing so we make sure that the only person that would be able to open the box will be our partner, because only he has the corresponding secret key.

And what would he find inside the box after he has opened it? I bet you will be convinced that he will find our message inside. But no, actually he will find a key for a single-key-box in which we have placed our real message for travel together with the double-key-box. With this clever trick we have solved the problem of safe key transmission.

But only if we have used the correct public key to lock the double-key-box. If we happen to select the wrong public key, we are going to make a dangerous mistake. Not only will we give someone else the ability to open the box unintentionally, but we also prevent the intended recipient from reading our message. We are doing the complete opposite of what we intend to do, and we do not recognize that we've done something terribly wrong.

I hope, understanding the crucial part of the double-key-box will help you to avoid such terrible mistakes when you use email encryption in future. Now that you've come to terms with the basics of email encryption you will be immune to making silly mistakes, so go ahead and use email encryption.

It's amazing what you can do with SSL certificates. In an earlier posting I showed you how to secure your email access by using SSL certificates. To achieve this, we had fortified our mail server to always establish pure SSL secured connections for the retrieval of an users' email. We did that to stop network snooping folks to read email passwords in transit and to make sure that someone who got to know a user's password would even need another secret information (the user's SSL secret key) to get at the mailbox content.

Now we will use the certificates we needed to fortify our IMAP server to make the other half of the mail system, the SMTP server, secure too. The SMTP servers today are used to accept email messages that are bound for a certain destination for which the server is authorative. But to deny spammers the chance to indulge in their nefarious activities SMTP servers usually refuse to relay email messages to other servers under normal circumstances. There's nothing wrong with it as long as the machine that is used to send the email has a public IP address that was never used to send spam before.

But once you've tried to send email via a dial-up connection or a public wireless access point, chances are that your dial-up IP address is marked as a dubious source and you cannot send your email because you are blocked by some intelligent software that pretend to know your're a spammer. There is no point in arguing, your only chance is to send your email into the internet via a "clean" relay host, with a static IP address, that is able to make a difference between you and all the spammers that pretend to be you.

In essence, we have to find a way to authenticate ourselves to the clean SMTP server in a secure way. Obviously, all the system users that are listed in the mail server's user database should be allowed to use the server as a mail relay host. But then, they have to submit their passwords to the mail server to authenticate and, as you probably would have known by now, this should only be permitted through a secure link using SSL or TLS.

Switching On Authentication

Most people sending email don't think about having to prove their identities to a mail server, they expect to be able to send email the same way as they are used to stuff anything into a real letter box. From the perspective of the mail server, a correct username password pair is the only thing that differentiates a valid user from the spammers. That's why it is important to educate people, that giving a password is not too much of an annoyance for the benefit of sending email while on the move. Anyway, once we have set up the system to use SSL certificates with an outgoing mail server, users will not see much of a difference except that they have to provide their password when sending the email out.

Adding A Secure Tunnel To SMTP

As the mail server is our main secure entry point for email into the internet our main objective is not to hide our message but to convince the mail server that we are the good guys that are allowed to inject email into the system.

SASL, the Simple Authentication and Security Layer, is being used to enable our mail server software to perform the necessary authentication checks. But before we can enable the use of SASL inside postfix, we have to start a deamon, the saslauthd

The following code is used to enable sasl in postfix and has to be added to the main postfix configuration file:

The last few lines of code will tell postfix to use TLS (the replacement for the older SSL mechanism) and the location where to find the mail server certificate and key as well as the CA file to verify the trust chain.

With these modifications of the server side, we have essentially locked out everyone from using our mail server who is unable to provide the correct username and password over the TLS connection to our mail server.

Don't Forget Your Client!

The first thing we'll notice when we send our next email is that it won't go out as our email software used to ignore TLS so far for outgoing mail. To be able to send email out again you have to change your settings in the "SMTP" section of you email client software. After selecting TLS encryption and providing the username for the mail server you should be back on track again. In my case I had to upgrade my email software to ALPINE 2.0 to get busy, because my old software (pine) didn't know a thing about TLS. But that could only happen to me as I tend to stick to the old reliable programs when the rest of the world has already moved on to the cutting edge solutions.

You may have followed my advice I gave in an earlier posting to set up a secure email server that will allow clients to fetch their email from the server only if they present a valid SSL certificate in addition to the usual password for the mailbox user. The most appealing aspect of this approach is that once the system had been set up, the client user, who has already stored his certificate on his local laptop will just have to provide the password as usual. This solution comes with no additional burden, and at the same time ensures that the email travels encrypted from the email server to the laptop. A clear boost of security, fine.

The only problem is that the email client software must be capable of establishing a SSL connection using the users certificate. Unfortunately not every prominent email software is able to do that. In my case I fetch my email from the server with fetchmail as I'm interested to archive all incoming email.
But email software usually tends to fetch the email on its own account. So the lack of being able to establish a SSL connection could clearly ruin the new approach.

What's Written On The Tin?

As a consequence I was very surprised to learn that Evolution, generally being celebrated as the Outlook killer software, actually is one of those culprits. Googling towards a solution I came across some well-intended advice "just" to upload the my certificate using the pertinent buttons in Evolution. This is good advice although it requires a little bit of openssl hacking to beat the two separate cert and key files in shape to form a p12 file, but it doesn't solve the problem at all. Evolution uses uploaded certificates to sign messages a user sends to other people, but it still refuses to use such a certificate to establish a SSL connection to the mail server. Strange, but true.

Let The Expert Do The Connecting

Fortunately there is a small but powerful piece of software that is rapidly becoming my favorite tool in such situations, called STUNNEL. Its primary goal is to read data from one port and to connect to an entirely different port on a different computer, initiating a clean SSL connection with the certs and key provided in a single configuration file. From the remote server's perspective it looks like some SSL capable software had connected to the server, while indeed any dumb non-SSL-aware code is using stunnel to do the hard work. This code could as well be Evolution, right? Let's have a look at the simple config file for stunnel:


Essentially, the "normal" IMAP port 143 on the laptop is wired as a secure IMAPS mail server to be used by Evolution. All certs and keys are stored in a secure place on the laptop.

Getting Evolution To Use The Tunnel

The remote mail server mail.kerrylinux.ie would usually be listed as the server in the settings for "Receiving Email". Now you just have to replace this entry with the local laptop's name and make sure that "no encryption" is selected. Remember it is STUNNEL's job to perform the SSL encryption not Evolution's. "Yes, but it should be evolution's", I can hear you say. You're right, but even if the evolution team decides to sex up their software in future, this solution will work for every other non-SSL capable email client as well, and that's the reason why I told you how to do it.

On the last day of the year my email stopped coming in. You may have read about my approach to fetch my email using a secure tunnel that uses SSL certificates in addition to a password to access my email. Well, on the last day of the year my ROOT CERTIFICATE, which I use for Kerry Linux, had expired after five years. Time flies by.

As I had other plans for the days ahead I thought just to renew the root certificate to buy time, but it seemed that my attempts to renew my root certificate did not result in a new usable certificate to replace the old one. My user certs, which are not up for expiration yet could not be reanimated with a quick fix like that.

After a while I thought, there is a reason for that and I began to think about root certificates more thoroughly. In the past five years we've definitively seen the crackdown of MD5 and SHA-1 is not invincible, too. Would it not be prudent to increase the key length and to use a more secure (i.e longer) hash and go through the trouble of creating a new root key and issue new user certs? I decided to go along that route and created a fresh new CA root key with 4096 bits for the Kerry Linux Certification Center. Although my openssl software does only permit using SHA-1, which is a pity, I felt content and everything was up and running for me in an hour or so.

Re-Animation of the old ROOT KEY

After a while I began to wonder if it was possible to reanimate the old key and out of curiosity tried to explore the way to do it in more detail. I googled and found this nice posting from Arsen Hayrapetyan which led me to success. My former attempts to recreate the old certificate always led me to the following error message when I tried to verify a user's certificate::

Unable to get the issuer certificate? I supplied it in the command, but it didn't work out as planned.

So I followed Arsen's hints and created a testbed for an experiment, where I set the serial number back to 00 and emptied the file "index.txt" so that my new certificate could inherit the properties of the old one including its serial number. Then I created a new certificate request based on the old root certificate "cacert.cert" and used this new request to sign it with the old key.

The result was a new root certificate "cacert_renewed.pem" that verified my old user certs perfectly.

It's good to have an alternative, isn't it?