DEV Community: Alessandro (Ale) Segala

Essential Cryptography for JavaScript Developers

Alessandro (Ale) Segala — Wed, 30 Mar 2022 00:19:03 +0000

In the fall of 2020, my first book came out: Svelte 3 Up and Running, published by Packt. When one of their acquisition editors contacted me some months prior, I was not new to writing, having blogged for many years, but the idea of writing an entire technical book was fascinating to me—and working with a reputable publisher like Packt seemed like a fantastic opportunity to try something new.

While writing about Svelte 3 was fun, shortly after the first book hit the (virtual) shelves, I had already an idea for a second one that I pitched to Packt: I wanted to write about cryptography, creating a handbook that was specifically meant for software developers.

I'm proud to share with you that this second book is now complete: Essential Cryptography for JavaScript Developers. You can find it on Amazon.

What the book is about

Obviously, my second book is about cryptography. However, it takes the somewhat unique approach of being written for an audience of software developers who may not have any background in cryptography, and yet they are interested in learning how to adopt common cryptographic operations in their applications, safely.

Throughout the book we focus on learning about four common cryptographic operations:

Hashing: A set of functions that allows generating a unique hash (also called digest or checksum) that is always of a fixed length. Unlike encryption, hashing is one-way: that is, it's an operation that cannot be reversed. Its uses include verifying the integrity of messages and files, generating unique identifiers, protecting passwords stored in databases, and deriving encryption keys from passwords. In the book, we cover algorithms such as SHA-2, scrypt, and Argon2… and we look at why outdated algorithms like MD5 and SHA-1 are not to be used anymore.
Symmetric encryption: This is about encrypting (and decrypting) data using a symmetric key: i.e. using the same key for both encryption and decryption. Most people are familiar with this concept, for example when they protect a ZIP file with a passphrase. In the book we cover how to encrypt and decrypt messages and entire files using two symmetric ciphers: AES and ChaCha20-Poly1305.
Asymmetric encryption: This is another class of encryption algorithms in which users have a pair of keys, consisting of a private key and a public one, and those are used to encrypt and decrypt messages when they're shared with other people. While asymmetric ciphers are much lesser known (and understood), they are used by virtually every human being, daily, given that they underpin protocols like HTTPS that is used to serve web pages securely. Within the book, we learn about asymmetric ciphers and hybrid ones (that combine an asymmetric cipher with a symmetric one), when they should be used and how. We're focusing on RSA and algorithms based on Elliptic Curve Cryptography (ECDH and ECIES).
Digital signatures: With digital signature schemes, developers can build solutions that leverage public key cryptography to authenticate messages and certify their integrity. For example, those QR codes that many people are familiar with these days to prove COVID test results or vaccination status embed a message that is digitally signed, allowing everyone to verify the integrity of the certification and who issued it. Although they often operate "behind the scenes" and are not immediately visible to users, digital signatures have a multitude of uses in software development, including securing software distribution, preventing tampering with messages, etc. In my book, you'll be able to learn when to use digital signatures and how, using RSA and schemes based on Elliptic Curve Cryptography (ECDSA and EdDSA).

As per the title of the book, it includes code samples written in JavaScript, for both Node.js (and platforms based on Node.js, like Electron) and for client-side code that runs within a web browser. I chose JavaScript because it's a very popular language and it has vast applications, from front-ends, to servers, to desktop and mobile apps.

However, if you primarily work with another programming language or framework, you will still be able to learn principles and techniques that can be ported to your preferred stack.

Why I wrote this book

I believe that having at least some knowledge of cryptography is an important skill for every software developer, and it's becoming even more important every day.

Us developers are facing increased pressure to build apps that are safe against more widespread and more sophisticated attacks. We are also being asked to design solutions that comply with more stringent privacy requirements, either due to external regulation (like GDPR) or simply because of business requirements—more commonly, privacy is a selling point for apps, and more customers are demanding that. For both these reasons and more, cryptography is an immensely powerful tool that we can leverage to accomplish those goals—not sufficient, but almost always necessary.

Yet, as a software developer, learning about cryptography is not always easy. To start, cryptography is a vast topic, has many confusing things, and mistakes are not always immediately clear.

There are of course lots of resources to learn cryptography, including many books that have already been written. However, a large part of those tutorials, videos, articles and lectures, and perhaps almost all books, seem to have a focus on cryptography as a science, and are generally written for an audience of aspiring cryptographers. As such, they spend a good chunk of time on the formal descriptions of the algorithms, with lots and lots of (complex) math.

While resources like those are incredibly valuable for people who want to learn the science and art of cryptography, as a software developer myself I was always more interested in the practical applications and found the math distracting—if not outright confusing at times.

With Essential Cryptography for JavaScript Developers I've attempted to collect all my learnings from over a decade of using cryptographic operations to develop many different apps and share them with other developers so they can avoid the same mistakes I've made.

It's a book written for other software developers who want to know which are the most common cryptographic operations, what they're used for, and how they can use them in their code, safely, relying on proven implementations such as those built-into JavaScript and Node.js.

This book took quite a lot of time to put together, but I'm very excited about the end result and I can't wait for other developers to read it and then see what they build with that! And please do share any feedback you have about the book with me—including showcasing the projects you've written!

You can order Essential Cryptography for JavaScript Developers on Amazon in any country, or directly from Packt.

Watch: JavaScript apps going Inter-Planetary

Alessandro (Ale) Segala — Thu, 23 Jan 2020 01:41:06 +0000

Last December, I gave a talk at Node+JS Interactive in Montreal, with the title JavaScript apps going Inter-Planetary.

I was very excited to have the opportunity to speak for the first time at a large tech event, and I got to explain and demo something I'm very passionate about: building static web apps for the Distributed Web, and making them "production ready".

After briefly explaining what is the Inter-Planetary File System (IPFS) and how to interact with it, I showed how to run a static JavaScript app (JAMstack) deployed through IPFS.

To make that app accessible to anyone in an easy manner, I then introduced using public IPFS gateways with Cloudflare, and simpler URLs thanks to the IPNS, or Inter-Planetary Name Service.

Lastly, I demoed how you can enable a full DevOps pipeline with Continuous Integration and Continuous Delivery, to automatically publish apps on the IPFS network.

📺 The full talk has been recorded and is now on YouTube:

🖥 You can also find all the slides in PDF here.

🧑‍💻 The code used for the demo, as well as all the instructions to replicate it yourself, are published on GitHub at ItalyPaleAle/calendar-next-demo.

📖 Lastly, if you're interested in reading more, check out my other articles about IPFS:

Hope you enjoy the content, and let me know if you have any feedback!

Auto-mounting encrypted drives with a remote key on Linux

Alessandro (Ale) Segala — Mon, 20 Jan 2020 06:06:07 +0000

I've been building a simple NAS for my home, and I wanted to store the data on a secondary disk, encrypted with dm-crypt/LUKS. There are plenty of articles on how to do that, but when it comes to automatically mounting the disk at boot, all of them recommend writing the encryption key in a keyfile and store it on the local filesystem.

This approach wasn't acceptable to me: while the data would be encrypted at rest, the key to open the encrypted partition would also be sitting in the same place. If someone were to steal the physical server (imagine this were a small Raspberry Pi!), they would have access to the data without any issue.

How could I have the LUKS encryption key stored in a secure, remote place, while at the same time being able to have the encrypted disk automatically mounted without manual intervention (e.g. in case of a reboot after a power outage)? In other words, how to have your cake and eat it too.

Turns out, there's a relatively simple solution, which requires just two systemd units.

Note: this approach can not be used with encrypted root volumes, but only with secondary disks.

Step 1: Generate and store the keyfile

The first thing we need to do is to generate a keyfile. This should be 256-bytes long, and can be generated with:

dd bs=256 count=1 if=/dev/random | base64 > keyfile

I'm piping the encryption key through base64 so we don't have to deal with binary files, making things more manageable.

You will then need to store the keyfile somewhere safe. You can pick and choose any place you'd like; some ideas include:

A key vault like Azure Key Vault
HTTPS servers, including object storage services such as AWS S3 or Azure Blob Storage; make sure you're using TLS to protect the data while in transit, rather than basic HTTP

For a simple (but effective enough) solution, you can store the keyfile in Azure Blob Storage. You can see an example of doing this in the Appendix below.

Step 2: Create a script returning the keyfile

You will need to create a script that can return the keyfile when invoked, stored as /etc/luks/key.sh

The content of the script completely depends on how and where you stored your keyfile. Following up on the example in the Appendix, with a keyfile stored on Azure Blob Storage, the script would look like this:

#!/bin/sh
# Request the file from Azure Blob Storage using the URL with the SAS token, then pipe it through `base64 -d` to decode it from base64
curl -s "https://ln5bxfzbl0tlf5z.blob.core.windows.net/keyfiles/keyfile?se=2022-01-19T23%3A02Z&sp=r&spr=https&sv=2018-11-09&sr=b&sig=gkaN2OSzN2zj1WSAPiLJMgtkcXLi2Y8EOVdBUmZQh88%3D" | base64 -d

Whatever the content of your script (which could be a shell script or written in any other language), it's important then to make it executable and readable by the root user only:

# Ensure the owner of this file is "root"
chown root:root /etc/luks/key.sh
# Allow only the owner (root) to read and execute the script
chmod 0500 /etc/luks/key.sh

Step 3: Encrypt the disk using LUKS

We're now ready to get to the fun part, and encrypt the disk or partition.

To start, check the name of the disk you want to use, using lsblk:

$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda       8:0    0   30G  0 disk
├─sda1    8:1    0 29.9G  0 part /
├─sda14   8:14   0    4M  0 part
└─sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0    4G  0 disk
└─sdb1    8:17   0    4G  0 part /mnt
sdc       8:32   0   32G  0 disk

In this example, I'm going to use the sdc disk. This is likely going to be different for you, so make sure you replace the disk name in all the commands below.

Watch out! The commands below will delete all files on the drive you select.

Before we start, install the cryptsetup utility:

# Debian, Ubuntu, Raspbian…
apt install -y cryptsetup

# CentOS, Fedora, RedHat
yum install -y cryptsetup-luks

First, if your disk doesn't have a partition yet (like mine), create a GPT partition table and a partition (without formatting it):

# Replace sdc with the drive you want to use
parted /dev/sdc mklabel gpt
parted -a opt /dev/sdc mkpart datadisk ext4 0% 100%

Encrypt the sdc1 partition using LUKS, create an ext4 volume in that partition, and then close the encrypted volume. In all commands that require a keyfile, we're invoking the /etc/luks/key.sh script that we created before, and telling cryptsetup to read the keyfile from stdin.

# Encrypt the disk
# Replace sdc1 with the correct partition!
/etc/luks/key.sh | cryptsetup -d - -v luksFormat /dev/sdc1

# Open the encrypted volume, with the name "data"
# Replace sdc1 with the correct partition!
/etc/luks/key.sh | cryptsetup -d - -v luksOpen /dev/sdc1 data

# Create a filesystem on the encrypted volume
mkfs.ext4 -F /dev/mapper/data

# Close the encrypted volume
cryptsetup -v luksClose data

Step 4: Enable auto-mounting the encrypted disk

We're almost done: ready to enable auto-mounting of the encrypted disk.

We'll do that with two systemd units: one unlocking the encrypted device, and the other one actually mounting the disk.

To start, get the UUID of the /dev/sdc1 partition, using lsblk --fs. For example:

$ lsblk --fs
NAME    FSTYPE      LABEL           UUID                                 MOUNTPOINT
[...]
sdc
└─sdc1  crypto_LUKS                 a17db19d-5037-4cbb-b50b-c85e3e074864

In my example, that is a17db19d-5037-4cbb-b50b-c85e3e074864; it will be different for you.

Create a systemd unit for unlocking the encrypted device and save it as /etc/systemd/system/unlock-data.service. Make sure you replace the UUID in the command below!

[Unit]
Description=Open encrypted data volume
After=network-online.target local-fs.target
StopWhenUnneeded=true

[Service]
Type=oneshot
ExecStart=/bin/sh -c '/etc/luks/key.sh | /sbin/cryptsetup -d - -v luksOpen /dev/disk/by-uuid/a17db19d-5037-4cbb-b50b-c85e3e074864 data'
RemainAfterExit=true
ExecStop=/sbin/cryptsetup -d - -v luksClose data

Note the StopWhenUnneeded=true line: this will make systemd stop the unit (including running the luksClose operation) automatically when the disk is unmounted.

Create another systemd unit with the mountpoint for /mnt/data, and save it as /etc/systemd/system/mnt-data.mount. Note that the unit's name must match the path of the mountpoint!

[Unit]
Requires=unlock-data.service
After=unlock-data.service

[Mount]
What=/dev/mapper/data
Where=/mnt/data
Type=ext4
Options=defaults,noatime

[Install]
WantedBy=multi-user.target

We're now ready, let's enable the mnt-data.mount unit so it's activated at boot, and then mount it right away:

systemctl enable mnt-data.mount
systemctl start mnt-data.mount

You can now check with lsblk to see the encrypted disk mounted:

$ lsblk
NAME     MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
[...]
sdc        8:32   0   32G  0 disk
└─sdc1     8:33   0   32G  0 part
  └─data 253:0    0   32G  0 crypt /mnt/data

Try rebooting the system, and you'll see the partition being mounted automatically.

We're done! However, keep in mind a few things:

To mount and un-mount the encrypted disk you must use systemctl rather than the usual mount and umount commands. Mount the disk with systemctl start mnt-data.mount, and un-mount with systemctl stop mnt-data.mount
The systemd units are executed only after the network and the other "normal" filesystems are mounted. If you have another service depending on the data disk's availability, you need to explicitly make its systemd unit depending on the mnt-data.mount unit (with Requires=mnt-data.mount and After=mnt-data.mount)
As mentioned at the beginning, this solution can't be used with the root filesystem, but only with secondary data disks.

Appendix: Keyfiles on Azure Blob Storage

In this example, I'm storing the keyfile in Azure Blob Storage. While this doesn't offer the same protection as a key vault, it can be enough for most people, depending on your threat model. I'm guaranteeing some level of security by:

Configuring the Storage Account to accept only secure connections that use HTTPS
Allowing connections only from the IP of my home (I have a "quasi-static" IP, that changes less than once per year)
Requiring clients to use a SAS token to download the file

My threat model involves people stealing the disk and/or the server. The attacker wouldn't be able to download the keyfile if they're not in my network. By having the keyfile on a remote server, I can delete it right away if I need to, e.g. if the physical disk is stolen. This protection is enough for me, but depending on your threat model, you might want to look into more complex solutions, for example involving key vaults.

If you're starting from scratch, you can create an Azure Storage Account, configure it per the requirements above, and upload your keyfile with the Azure CLI. You will need an Azure subscription, which is free and with this kind of usage you'll be comfortably within their free tier.

This example assumes that you've generated a base64-encoded keyfile available in the keyfile file, in the current working directory, just as per Step 1 above.

# Login to Azure if you need to
az login

# Location where to store the keyfile; choose an Azure region close to you
export LOCATION="eastus2"

# If you have a fixed (or almost) IP address, you can restrict access to the storage account from that IP.
# You can also use an IP range in the CIDR format.
# Otherwise, leave this variable as an empty string
export ALLOW_IP="1.2.3.4"

# Generate a random name for the Storage Account
export STORAGE_ACCOUNT_NAME=$(cat /dev/random | base64 | tr -dc 'a-zA-Z0-9' | tr '[:upper:]' '[:lower:]' | fold -w 15 | head -n 1)

# Create a Resource Group and a Storage Account
export RG_NAME="Keyfiles"
az group create --name $RG_NAME --location $LOCATION
az storage account create \
  --name $STORAGE_ACCOUNT_NAME \
  --resource-group $RG_NAME \
  --location $LOCATION \
  --sku Standard_LRS \
  --kind StorageV2

# Require using TLS/HTTPS only
az storage account update \
  --name $STORAGE_ACCOUNT_NAME \
  --https-only true

# Allow from a specific IP only, if the variable ALLOW_IP isn't empty
if [ ! -z "$ALLOW_IP" ]; then
  # Disallow access from anywhere by default
  az storage account update \
    --resource-group $RG_NAME \
    --name $STORAGE_ACCOUNT_NAME \
    --default-action Deny
  # Allow the IP or IP range
  az storage account network-rule add \
    --resource-group $RG_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --ip-address "$ALLOW_IP"
  # Disallow "Trusted Microsoft Services"
  az storage account update \
    --resource-group $RG_NAME \
    --name $STORAGE_ACCOUNT_NAME \
    --bypass None
fi

# Create a blob container
az storage container create \
  --name "keyfiles" \
  --public-access off \
  --account-name $STORAGE_ACCOUNT_NAME

# Upload the key
az storage blob upload \
  --account-name $STORAGE_ACCOUNT_NAME \
  --container-name "keyfiles" \
  --file "./keyfile" \
  --name "keyfile"

Now that the file has been uploaded, we can get a link to it. Since the file is in a "private" container, it requires a special authentication token (SAS token) to be retrieved. SAS tokens add some extra protection thanks to having an expiration date and being tied to an account key, which can be revoked at any time. You can also add additional requirements on the SAS tokens, such as restrictions on IPs; this is a (less ideal) alternative to setting IP restrictions on the Storage Account as shown above.

You can generate a URL with a SAS token for the blob with:

# Create an expiration date 2 years in the future
# On Linux:
SAS_EXPIRY=$(date -u -d "2 years" '+%Y-%m-%dT%H:%MZ')
# On macOS:
SAS_EXPIRY=$(date -v+2y -u '+%Y-%m-%dT%H:%MZ')

# Generate the URL with the SAS token
az storage blob generate-sas \
  --account-name $STORAGE_ACCOUNT_NAME \
  --container-name "keyfiles" \
  --name "keyfile" \
  --https-only \
  --permissions r \
  --expiry "$SAS_EXPIRY" \
  --full-uri

Result will be similar to:

https://ln5bxfzbl0tlf5z.blob.core.windows.net/keyfiles/keyfile?se=2022-01-19T23%3A02Z&sp=r&spr=https&sv=2018-11-09&sr=b&sig=gkaN2OSzN2zj1WSAPiLJMgtkcXLi2Y8EOVdBUmZQh88%3D

You can use the URL above in the /etc/luks/key.sh script, as per Step 2.