Encryption

Understanding Public Key Infrastructure and X.509 Certificates

Jeff Woods — Fri, 21 Jun 2019 12:30:00 +0000

An introduction to PKI, TLS and X.509, from the ground up.

Public Key Infrastructure (PKI) provides a framework of encryption and data communications standards used to secure communications over public networks. At the heart of PKI is a trust built among clients, servers and certificate authorities (CAs). This trust is established and propagated through the generation, exchange and verification of certificates.

This article focuses on understanding the certificates used to establish trust between clients and servers. These certificates are the most visible part of the PKI (especially when things break!), so understanding them will help to make sense of—and correct—many common errors.

As a brief introduction, imagine you want to connect to your bank to schedule a bill payment, but you want to ensure that your communication is secure. "Secure" in this context means not only that the content remains confidential, but also that the server with which you're communicating actually belongs to your bank.

Without protecting your information in transit, someone located between you and your bank could observe the credentials you use to log in to the server, your account information, or perhaps the parties to which your payments are being sent. Without being able to confirm the identity of the server, you might be surprised to learn that you are talking to an impostor (who now has access to your account information).

Transport layer security (TLS) is a suite of protocols used to negotiate a secured connection using PKI. TLS builds on the SSL standards of the late 1990s, and using it to secure client to server connections on the internet has become ubiquitous. Unfortunately, it remains one of the least understood technologies, with errors (often resulting from an incorrectly configured website) becoming a regular part of daily life. Because those errors are inconvenient, users regularly click through them without a second thought.

Understanding the X.509 certificate, which is fully defined in RFC 5280, is key to making sense of those errors. Unfortunately, these certificates have a well deserved reputation of being opaque and difficult to manage. With the multitude of formats used to encode them, this reputation is rightly deserved.

An X.509 certificate is a structured, binary record. This record consists of several key and value pairs. Keys represent field names, where values may be simple types (numbers, strings) to more complex structures (lists). The encoding from the key/value pairs to the structured binary record is done using a standard known as ASN.1 (Abstract Syntax Notation, One), which is a platform-agnostic encoding format.

Go to Full Article

Why Smart Cards Are Smart

Kyle Rankin — Wed, 12 Jun 2019 11:30:00 +0000

by Kyle Rankin

If you use GPG keys, learn about the benefits to storing them on a smart card.

GPG has been around for a long time and is used to secure everything from your email to your software. If you want to send an email to someone and be sure that no one else can read or modify it, GPG signing and encryption are the main method you'd use. Distributions use GPG to sign their packages, so you can feel confident that the ones you download and install from a package mirror have not been modified from their original state. Developers in many organizations follow the best practice of GPG-signing any code they commit to a repository. By signing their commits, other people can confirm that the changes that claim to come from a particular developer truly did. Web-based Git front ends like GitHub and GitLab let users upload their GPG public keys, so when they do commit signed code, the interface can display to everyone else that it has been verified.

Yet, all of the security ultimately comes down to the security of your private key. Once others have access to your private key, they can perform all of the same GPG tasks as though they were you. This is why you are prompted to enter a passphrase when you first set up a GPG key. The idea is that if attackers are able to copy your key, they still would need to guess your password before they could use the key. For all of the importance of GPG key security, many people still just leave their keys in ~/.gnupg directories on their filesystem and copy that directory over to any systems where they need to use GPG.

There is a better way. With OpenPGP smart cards, you can store your keys on a secure device that's protected with a PIN and not only store your keys more securely, but also use them more conveniently. Although some laptops come with integrated smart card readers, most don't. Thankfully, these devices are available as part of multi-function USB security token devices from a number of different vendors, and Linux Journal has published reviews of such products in the past. In this article, I discuss all the reasons OpenPGP smart cards are a better choice for storing your keys than your local filesystem.

Reason 1: Tamper-proof Key Storage

One of the main benefits of a smart card is that it stores your GPG keys securely. When you store your keys on a filesystem, anyone who can access that filesystem can copy off the keys. On a smart card, once keys go in, they never leave, neither accidentally nor from tampering. The smart card chips themselves are designed to be tamper-proof and resist attempts to extract key data even when someone has physical access. By putting keys on a smart card, you can have a reasonable assurance that your keys are safe, even from a determined attacker.

Go to Full Article

Disk Encryption for Low-End Hardware

Zack Brown — Thu, 07 Feb 2019 13:15:15 +0000

by Zack Brown

Eric Biggers and Paul Crowley were unhappy with the disk encryption options available for Android on low-end phones and watches. For them, it was an ethical issue. Eric said:

We believe encryption is for everyone, not just those who can afford it. And while it's unknown how long CPUs without AES support will be around, there will likely always be a "low end"; and in any case, it's immensely valuable to provide a software-optimized cipher that doesn't depend on hardware support. Lack of hardware support should not be an excuse for no encryption.

Unfortunately, they were not able to find any existing encryption algorithm that was both fast and secure, and that would work with existing Linux kernel infrastructure. They, therefore, designed the Adiantum encryption mode, which they described in a light, easy-to-read and completely non-mathematical way.

Essentially, Adiantum is not a new form of encryption; it relies on the ChaCha stream cipher developed by D. J. Bernstein in 2008. As Eric put it, "Adiantum is a construction, not a primitive. Its security is reducible to that of XChaCha12 and AES-256, subject to a security bound; the proof is in Section 5 of our paper. Therefore, one need not 'trust' Adiantum; they only need trust XChaCha12 and AES-256."

Eric reported that Adiantum offered a 20% speed improvement over his and Paul's earlier HPolyC encryption mode, and it offered a very slight improvement in actual security.

Eric posted some patches, adding Adiantum to the Linux kernel's crypto API. He remarked, "Some of these patches conflict with the new 'Zinc' crypto library. But I don't know when Zinc will be merged, so for now, I've continued to base this patchset on the current 'cryptodev'."

Jason A. Donenfeld's Zinc ("Zinc Is Not crypto/") is a front-runner to replace the existing kernel crypto API, and it's more simple and low-level than that API, offering a less terrifying coding experience.

Jason replied to Eric's initial announcement. He was very happy to see such a good disk encryption alternative for low-end hardware, but he asked Eric and Paul to hold off on trying to merge their patches until they could rework them to use the new Zinc security infrastructure. He said, "In fact, if you already want to build it on top of Zinc, I'm happy to work with you on that in a shared repo or similar."

He also suggested that Eric and Paul send their paper through various academic circles to catch any unanticipated problems with their encryption system.

But Paul replied:

Go to Full Article

At Rest Encryption

Kyle Rankin — Wed, 18 Jul 2018 11:45:00 +0000

by Kyle Rankin

Learn why at rest encryption doesn't mean encryption when your laptop is asleep.

There are many steps you can take to harden a computer, and a common recommendation you'll see in hardening guides is to enable disk encryption. Disk encryption also often is referred to as "at rest encryption", especially in security compliance guides, and many compliance regimes, such as PCI, mandate the use of at rest encryption. This term refers to the fact that data is encrypted "at rest" or when the disk is unmounted and not in use. At rest encryption can be an important part of system-hardening, yet many administrators who enable it, whether on workstations or servers, may end up with a false sense of security if they don't understand not only what disk encryption protects you from, but also, and more important, what it doesn't.

What Disk Encryption Does

In the context of Linux servers and workstations, disk encryption generally means you are using a system such as LUKS to encrypt either the entire root partition or only a particularly sensitive mountpoint. For instance, some Linux distributions offer the option of leaving the root partition unencrypted, and they encrypt each user's /home directories independently, to be unlocked when the user logs in. In the case of servers, you might leave root unencrypted and add encryption only to specific disks that contain sensitive data (like database files).

In a workstation, you notice when a system is encrypted at rest because it will prompt you for a passphrase to unlock the disk at boot time. Servers typically are a bit trickier, because usually administrators prefer that a server come back up after a reboot without manual intervention. Although some servers may provide a console-based prompt to unlock the disk at boot time, administrators are more likely to have configured LUKS so that the key resides on a separate unencrypted partition. Or, the server may retrieve the key from the network using their configuration management or a centralized secrets management tool like Vault, so there is less of a risk of the key being stolen by an attacker with access to the filesystem.

The main thing that at rest encryption protects you from is data loss due to theft or improper decommissioning of hard drives. If someone steals your laptop while it's powered off, your data will be protected. If someone goes into a data center and physically removes drives from a server with at rest encryption in place, the drives will spin down, and the data on them will be encrypted. The same goes for disks in a server that has been retired. Administrators are supposed to perform secure wiping or full disk destruction procedures to remove sensitive data from drives before disposal, but if the administrator was lazy, disk encryption can help ensure that the data is still protected if it gets into the wrong hands.

Go to Full Article

The Wire

Shawn Powers — Mon, 30 Oct 2017 12:09:27 +0000

by Shawn Powers

In the US, there has been recent concern over ISPs turning over logs to the government. During the past few years, the idea of people snooping on our private data (by governments and others) really has made encryption more popular than ever before. One of the problems with encryption, however, is that it's generally not user-friendly to add its protection to your conversations. Thankfully, messaging services are starting to take notice of the demand. For me, I need a messaging service that works across multiple platforms, encrypts automatically, supports group messaging and ideally can handle audio/video as well. Thankfully, I found an incredible open-source package that ticks all my boxes: Wire.

There are some other great software packages for encrypting conversations. Programs like Signal do end-to-end encryption, but fall short when it comes to audio and video. Telegram is great for sending encrypted file transfers, but it doesn't handle direct communication. Thankfully, Wire not only encrypts text, video, audio and media, but it also does end-to-end encrypted group interactions. Plus, it has clients for just about any platform imaginable.

Users have a user name that is identified much like a Twitter handle. My account, for instance, is @shawnp0wers. And since Wire is open source, there aren't any targeted ads, popups or banners. It's just encrypted communication done in a convenient way. Check it out today at https://wire.com.

Go to Full Article

Jetico's BestCrypt Container Encryption for Linux

James Gray — Fri, 16 Jun 2017 16:22:09 +0000

by James Gray

Cyber-attacks are now constant, threats to privacy are increasing, and more rigid regulations are looming worldwide. To help IT folks relax in the face of these challenges, Jetico updated its BestCrypt Container Encryption solution to include Container Guard.

This unique feature of Jetico's Linux file encryption protects container files from unauthorized or accidental commands—like copying, modification, moving, deletion and re-encryption—resulting in bolstered security and more peace of mind. Only users with the admin password can disable Container Guard, increasing the security of sensitive files.

The BestCrypt update also adds the Resident feature, an automatic password prompt for mounting containers at startup. That same feature will dismount containers after a time period of inactivity as set by the user.

While user-friendly and time-saving, these added features also provide an extra layer of protection when working on shared computers. On endpoints or in the cloud, data encrypted with BestCrypt can be accessed via Linux, Android, Windows and Mac devices.

Go to Full Article

Flat File Encryption with OpenSSL and GPG

Charles Fisher — Tue, 04 Apr 2017 09:46:42 +0000

by Charles Fisher

The Pretty Good Privacy (PGP) application, which has long been known as a primary tool for file encryption, commonly focused on email. It has management tools for exchanging credentials with peers and creating secure communication channels over untrusted networks. GNU Privacy Guard (GPG) has carried on this legacy with a free and open implementation included in most major Linux distributions. PGP/GPG has proven highly resistant to cryptographic attack and is a preeminent tool for secure communications.

OpenSSL is more known for network security, but it also has tools useful for most aspects of encrypting flat files. Although using OpenSSL requires more knowledge of specific algorithms and methods, it can be more flexible in a number of scenarios than other approaches. OpenSSH keys can be used transparently for flat file encryption with OpenSSL, allowing user and/or host SSH keys to pervade any number of unrelated services.

OpenSSL is also useful for illustrating the sequence of encryption techniques that create secure channels. This knowledge is applicable in many other situations, so the material is worth study even if there is no immediate need for the tools.

OpenSSL Flat File Processing

Many common programs in UNIX have implementations within the OpenSSL command-line utility. These include digest/checksum tools (md5sum, sha1sum, sha256sum), "ASCII-Armor" tools (base64/uuencode/uudecode), "safe" random number generation and MIME functions in addition to a suite of cipher and key management utilities. Because OpenSSL often is found on non-UNIX platforms, those utilities can provide a familiar interface on unfamiliar systems for UNIX administrators.

Let's begin with a complete script for flat file encryption with OpenSSL, using asymmetric exchange of a session key, SHA-256 digest checksums and the use of a symmetric cipher. This entire exchange, both to encode and decode, is presented in the following text for the Korn shell (GNU Bash also may be used with no required changes):

Go to Full Article

smbclient Security for Windows Printing and File Transfer

Charles Fisher — Tue, 28 Mar 2017 12:53:56 +0000

by Charles Fisher

Microsoft Windows is usually a presence in most computing environments, and UNIX administrators likely will be forced to use resources in Windows networks from time to time. Although many are familiar with the Samba server software, the matching smbclient utility often escapes notice.

The "map network drive" function of Windows relies upon the Server Message Block network protocol that has evolved chiefly within the descendents of NT. The smbclient utility presents an interface reminiscent of FTP that allows file transfer to and from disk directories and printers on an NT server over SMB where sharing is enabled.

In this article, I present connection examples for Windows services, then develop a general script for pushing content to Windows shares. I discuss when the SMB protocols should be used and, more important, when they should not.

Connection Examples

Samba for UNIX is well known for server software that interoperates with clients on Windows networks. However, it also includes the smbclient program that can manipulate any SMB server. The smbclient program will be immediately familiar to those experienced with command-line FTP.

The smbclient program can query SMB servers for a list of visible shares using the -L option:


$ smbclient -L dc.somecompany.com -U nt_username -W nt_domain

Enter nt_username's password:

Domain=[NT_DOMAIN]
OS=[Windows Server 2008 R2 Standard 7601 Service Pack 1]
Server=[Windows Server 2008 R2 Standard 6.1]

     Sharename       Type      Comment
     ---------       ----      -------
     C$              Disk      Default share
     file_stash      Disk
     Fancy_laser     Printer   Really Expensive
     Cheap_laser     Printer   What a deal!

After cataloging the file and printer shares on a server, you can connect to a specific share and manipulate it. Below are examples of several types of transfers:

Go to Full Article

Preseeding Full Disk Encryption

Kyle Rankin — Thu, 16 Mar 2017 17:48:18 +0000

by Kyle Rankin

Usually I try to write articles that are not aimed at a particular distribution. Although I may give examples assuming a Debian-based distribution, whenever possible, I try to make my instructions applicable to everyone. This is not going to be one of those articles. Here, I document a process I went through recently with Debian preseeding (a method of automating a Debian install, like kickstart on Red Hat-based systems) that I found much more difficult than it needed to be, mostly because documentation was so sparse. In fact, I really found only two solid examples to work from in my research, one of which referred to the other.

In this article, I describe how to preseed full-disk encryption in a Debian install. This problem came up as I was trying to create a fully automated "OEM" install for a laptop. The goal was to have an automated boot mode that would guide users through their OS install and use full-disk encryption by default, but would make the process as simple as possible for users. Normally, unless you are going to encrypt the entire disk as one big partition, the Debian installer makes you jump through a few hoops to set up disk encryption during an install.

In my case, I couldn't just use the full disk, because I needed to carve off a small section of the disk as a rescue partition to store the OEM install image itself. My end goal was to make it so users just had to enter their passphrase, and it would set up an unencrypted /boot and rescue disk partition and an encrypted / and swap. As an additional challenge, I also wanted to skip the time-consuming disk-erasing process that typically happens when you enable disk encryption with Debian, since the disk was going to be blank to start with anyway.

Unfortunately, although there is a lot of documentation on how to automate ordinary partitioning and LVM with preseeding (I actually wrote a whole section on the topic myself in one of my books), I had a hard time finding much documentation on how to add encryption to the mix. After a lot of research, I finally found two posts (and as I mentioned, one of them referenced the other) that described the magic incantation that would enable this. Unfortunately, the only supported mode for encrypted disks in Debian preseed requires the use of LVM (something I confirmed later when I read the source code responsible for this part of the install). That's not the end of the world, but it would have been simpler in my mind if it didn't have that requirement.

Since you need a basic unencrypted /boot partition to load a kernel and prompt the user for a passphrase, I had to account for both and preserve a small 2GB rescue disk partition that already was present on the disk. After that, the remaining / and swap partitions were encrypted. Here is the partition section of the preseed config:

Go to Full Article

Secret Agent Man

Kyle Rankin — Tue, 28 Feb 2017 13:50:44 +0000

by Kyle Rankin

It used to be that only the paranoid among us focused on strict security practices, yet these days, it seems like people are stepping up their games with respect to encryption, password policy and how they approach their computers in general. Although I always have considered myself more inside that paranoid camp than outside of it, I even have found myself stepping up my game lately. Security is often at odds with convenience, yet whenever I need a good example of better security practices that are more convenient than the alternative, I turn to SSH keys.

With SSH keys, you generate a private and public key pair with the ssh-keygen command and distribute the public key to servers to which you want to connect. SSH keys use your private key to authenticate yourself instead of a password on the remote server, so if you are one of those people who are worried about SSH brute-forcing, if you use SSH keys, you can disable password SSH authentication altogether and not care about those SSH brute-force attempts you see in your logs. When I used to set up SSH key pairs, I wouldn't provide a passphrase to unlock the key. Without a passphrase, I could just ssh in to a machine without typing any sort of password—a case where you can increase security against brute-force SSH attacks while also increasing your convenience.

Of course, the problem with skipping the passphrase when you generate SSH keys is that all of your security relies on keeping your private key (usually found at ~/.ssh/id_rsa or ~/.ssh/id_dsa) secret. If others were able to get a copy of that file, they could log in to any machine to which you distributed the public key. Lately I decided I didn't like that kind of risk, so when I generate SSH keys, I now use a passphrase. This means if others got my private key, they couldn't immediately use it, but it also means I now have to type in a passphrase to use my SSH key. This is less convenient, but I've found that by using SSH agent, I can get back to a similar level of convenience but with a few added bonuses that I discuss in this column.

SSH Agent

On most systems that use sudo, after you type in your sudo password, it is cached for some period of time, so if you run a few sudo commands in a row, you don't have to keep typing in your password. SSH agent works in a similar way for SSH passphrases, caching your unlocked key in memory for a defined period of time. This is particularly useful if, like me, you use Git on a routine basis with SSH—it would be a pain to have to type in your passphrase every time you do a git push or git pull. So for instance, if I wanted to cache my passphrase for 15 minutes, I could type:


$ ssh-add -t 15m

Then after I provide my password a single time, it would be cached for the remainder of SSH commands I run within that 15 minutes, after which it would expire.

Go to Full Article