Klaus Knopper answers your Linux questions

Ask Klaus

Article from Issue 155/2013

SSL Encryption and Signature Compilation

Worrying About Privacy and Security




Tons of tools are available that allow intersecting and manipulating network connections. Most of these tools are legal for security checks, network administration, and fixing problems, but some of them can also be used for not-so-nice activities by crackers. Making network manipulation tools illegal does not help against criminals who just don't care about the law; however, it does make network administrators' work harder, so you shouldn't expect much help from the legal side to protect your data. Basically, you are on your own if you want to protect your data and its transfer to a certain destination.

However, many useful algorithms, tools, and plugins can help protect your data – once they are activated. For example, the technology for encrypting email messages and digitally signing them (S/MIME) has existed for many years now and is built into most of the popular mail programs; yet, hardly anyone is taking advantage of this capability. In a later answer, I will explain how to set up secure email for Thunderbird, which works similarly to other mail programs, even on the Windows operating system.

So, the short answer is: The Internet is still safe for transfer of sensible data, if you are handling your own data protection. You can encrypt data with standardized tools and make sure that your browser talks to your bank and to web stores only over encrypted HTTP (HTTPS). Additionally, you should take the security warnings of your browser very seriously and understand what they mean. Attackers can break into encrypted connections if they can obtain encryption keys or if they can trick you into accepting a key that is not from the genuine website you tried to connect to.

Security is not a matter of having someone else make the Internet safe; it is a matter of taking responsibility and taking advantage of existing security technology. Adding security to your Internet life does not make things more difficult, but it does mean you don't have to rely on the promises of providers who claim to have "built in security – at a certain price."

Cloud Safety

Is it safe to store sensible data in a cloud drive? Can I trust providers of cloud services?

In theory, cloud services can be very safe, if their architects use standard encryption technologies, so you get a point-to-point encryption where third parties are unable to decrypt or manipulate data that you transfer to or from the cloud drive. You get a key, stored in your browser or some VPN software, and the connection to the drive is safe. Again, in theory.

The catch is that cloud service providers may want to, or legally be required to, keep a second key for unlocking the encryption in order to provide your data to authorities if a court order forces them to do so. Also, a provider may want to store your data in unencrypted form at the endpoint (which is technically possible, yet nobody will admit doing so) to be able to restore data in case you lose your decryption key. So, either you have to trust your provider to handle encryption correctly at every point of data transfer and storage or you have to handle the entire encryption procedure yourself. I recommend the latter if you want to be sure that nobody except yourself has access to the data.

In a practical scenario, this approach means you should not store the original files on the cloud drive but instead use locally installed encryption software to create an encrypted "container" to be sent to the network drive. Thus, the data is already encrypted before it is transferred. Software for doing this under Linux is the built-in dm-crypt block device and/or cryptoloop. These tools let you encrypt hard disk partitions and create files that are used as virtual hard disks with selectable encryption algorithms. Alternatively, you can use custom disk encryption software like TrueCrypt [1], which comes with a nice GUI. Encrypting individual files also is an option if the cloud device does not support blockwise transfer of data; you could use PGP or SSL to do this, but the capability must be supported by your file manager.

Please note that the old and often used ZIP archive encryption provides very weak protection; you should instead use a standard that encrypts the real data with a symmetric key of at least 256 variable bits. The 7-Zip archiver [2] does a better job, because it encrypts contained files using 256-bit AES and can be used as a file manager plugin.

Encryption and Signature, Secret and Public Keys

How does S/MIME mail and document encryption and signature work? How do I get the keys?

S/MIME is based on the Secure Socket Layer (SSL) standard and uses an asymmetric (i.e., "public key") scheme for encryption and decryption. Under this scheme, two complementary keys are created: the "secret" key, which is only known to its owner and never leaves his property, and the "public" key, which must be distributed to all communication partners.

The very shortened description is: One key encrypts or signs data, but only the complementary key is able to decrypt or verify the data. For example, if you encrypt communication using someone's "public key," it is impossible to decrypt the data using the same key. The receiving side must use the matching "secret key" instead.

In reality, the mechanism is somewhat more complex and involves an electronic handshake, a symmetric session key, and checksums being sent via this secure "one-way" communication. For now, I will cover only the public/secret keypair.

For signatures, you would create a checksum for a document and sign this using the secret key, only known to yourself: Nobody else can create the signature. Using your matching public key, anyone can verify that the checksum was created by the person owning the secret key (you). If the document changes, the checksum will not match anymore and verification will fail, which is the intended behavior in case of unauthorized manipulation.

Knowing that, it becomes evident that the public/secret key method has a weakness: To ensure that you are talking to the right person or to verify his/her signature, you must be definitely sure that the public key is really associated with that person. Just the fact that the signature shows the correct personal information (name, contact address) is not sufficient.

For this reason (although it is not technically required), public keys are checked for a signature of someone "trustworthy" before they are accepted and stored for later use by SSL-aware programs. The signature of the trustworthy person or organization, who is allowed to declare the public key correct (sometimes called a "notary"), is preinstalled in the program.

A signed public key is called a certificate, which suggests some (unproven) level of reliability. When signed by a "trusted" notary, such a certificate is considered valid and correct by the program with no further dialogs or warnings.

You can see a list of trusted organizations when opening the Authorities settings in Firefox (Figure 1). However, you probably do not personally know any of the authorities listed, so if you are worried that they may assign a signature erroneously to the wrong person, you can still verify a public key by contacting the key's owner by phone or in person to compare the fingerprint of his alleged public key, which can be displayed in the certificate details.

Figure 1: Firefox Certificate Manager with the default set of "trusted" signers.

If you want to use SSL for secure communication and signatures, you can just sign your public key by yourself, using your matching secret key. It costs no money – just a few seconds for generating the keys – but the receiver will have to verify the origin of your self-signed certificate using the fingerprint and can then save the public key as a "trusted signer."

If you want to spend some money on letting one of the preinstalled signing organizations do the verification procedure to save your correspondents the verification dialogs, you can do that (the organization usually will want to see your ID, make phone calls, or verify your identity in other ways), but it's not a precondition for SSL to work.

Everything you need to create the SSL keypair is, most likely, already installed on your computer or is easily available as the OpenSSL software package for your distribution.

Graphical front ends for this one-time task exist, but the method of using OpenSSL on the command line on your computer is quicker. To begin, open a shell terminal and start creating the public/secret keypair, including the signature, with the following openssl command. Use your normal user account for this.

openssl req -new -x509 -nodes -days 3650 -keyout private.pem -out public.pem

The preceding command first creates a new unsigned keypair (subcommand req -new), signs the public key using the generated private key (option -x509), then avoids saving the secret key with another layer of encryption that would require a password (option -nodes). The signature is valid for 10 years (option -days 3650), the private key is placed in file private.pem, and the public key in file public.pem.

Personally, I use encryption for my entire disk, so I don't require additional passwords for unlocking each and every key, but if you feel this approach is insecure, you can remove the -nodes option to protect your private key on disk with a password.

During command execution, OpenSSL will ask interactively for information to be included in the certificate  – the signed public key part that will get distributed  – so it is easy to identify. Part of this information is essential: the Common Name (which is the official hostname for a web server certificate or the real name of the person owning the personal certificate) and the email address that is associated with the personal certificate (Figure 2). Only one value is allowed here, which means you cannot use multiple domain names, addresses, or wildcards within the same certificate.

Figure 2: Sample openssl one-time key generation.

To import the private key and the certificate in various programs, you need to store them in a single file in PKCS12 format, as shown in the following command. For extra protection of the private key, the output file will be protected by a password that you can choose freely.

openssl pkcs12 -export -inkey private.pem -in public.pem -name "My Name" -out keys.p12

The file keys.p12 now contains your public/secret keypair and is ready to be imported into an S/MIME-enabled program. Make sure it is stored in a safe place and never sent over a network.

For signature verification and encrypting to your address, you and your friends need only the self-signed certificate in file public.pem, which does not contain any secrets. Read on to the next question to learn how to include self-signed certificates into Firefox/Thunderbird.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95