Tag Archives: encryption

SSH from RHEL 9 to RHEL 5 or RHEL 6

RHEL 9 no longer lets you ssh to RHEL ≤ 6 hosts out of the box. You can weaken security of the whole system but there’s no easy way to set security policy per remote host. Here’s how to set up ssh so it works for a RHEL 5 or RHEL 6 host:

First edit your .ssh/config file, adding an entry for the host:

Host rhel5or6-host
KexAlgorithms +diffie-hellman-group14-sha1
MACs +hmac-sha1
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

(The lines except the first “Host” line should be indented. WordPress screws up the formatting …)

That’s not enough on its own, because RHEL 9 also maims the openssl library by disabling SHA1 support by default. To fix that, create /var/tmp/openssl.cnf with:

.include /etc/ssl/openssl.cnf
alg_section = evp_properties
rh-allow-sha1-signatures = yes

Now you can ssh to RHEL 5 or RHEL 6 hosts like this:

OPENSSL_CONF=/var/tmp/openssl.cnf ssh rhel5or6-host

Thanks Laszlo Ersek for working out most of this. Related bugs:

2064740 – RFE: Make it easier to configure LEGACY policy per service or per host

2062360 – RFE: Virt-v2v should replace hairy “enable LEGACY crypto” advice which a more targeted mechanism

Leave a comment

Filed under Uncategorized

nbdkit now supports LUKS encryption

nbdkit, our permissively licensed plugin-based Network Block Device server can now transparently decode encrypted disks, for both reading and writing:

qemu-img create -f luks --object secret,data=SECRET,id=sec0 -o key-secret=sec0 encrypted-disk.img 1G

nbdkit file encrypted-disk.img --filter=luks passphrase=+/tmp/secret

We use LUKSv1 as the encryption format. That’s an older version [more on that in a moment] of the format used for Full Disk Encryption on Linux. It’s much preferable to use LUKS rather than using qemu’s built-in qcow2 encryption, and our implementation is compatible with qemu’s.

You can place the filter on top of other nbdkit plugins, like Curl:

nbdkit curl https://example.com/encrypted-disk.img --filter=luks passphrase=+/tmp/secret

The threat model here is that you can store the encrypted data on a remote server, and the admin of the server cannot decrypt the disk (assuming you don’t give them the passphrase).

If you try this filter (or qemu’s device) with a modern Linux LUKS disk you’ll find that it doesn’t work. This is because modern Linux uses LUKSv2, although they are able to create, read and write LUKSv1 if you use set them up that way in advance. Unfortunately LUKSv2 is significantly more complicated than LUKSv1. It requires parsing JSON data(!) stored in the header, and supports a wider range of password derivation functions, typically the very slow and memory-intensive argon2. LUKSv1 by contrast only requires support for PBKDF2 and is generally far more straightforward to implement.

The new filter will be available in nbdkit 1.32, or you can grab the development version now.


Filed under Uncategorized

nbdkit finally supports TLS (encryption)

nbdkit is a liberally licensed NBD server which a stable plugin API for serving disks from unconventional sources.

Finally I got around to adding TLS (encryption and authentication) support. The support is complete and appears to interoperate with QEMU. It also supports a certificate authority, client certificate verification, certificate revocation, server verification (by the client), and configurable algorithms.

Actually using TLS with NBD is no easy matter. It takes a few pages of instructions just to explain how to set up the public-key infrastructure. On the client (QEMU) side, the command line parameter for connecting to a TLS-enabled NBD server is lengthy.

Then there’s the question of how you ensure TLS is being used. In nbdkit as in other NBD servers you can either turn on TLS in which case it’s used when the client requests it, or you can require TLS. In the latter case nbdkit will reject non-TLS connections (thus ensuring TLS is really being used), but most clients won’t be able to connect to such a server.

As usual, where SSH got it right, SSL/TLS/HTTPS got it all horribly wrong.


Filed under Uncategorized

guestfish -i now decrypts encrypted guests

$ guestfish --ro -i /tmp/encrypted.img
Enter key or passphrase ("/dev/vda2"): ***

Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.

Type: 'help' for help on commands
      'man' to read the manual
      'quit' to quit the shell

Operating system: Fedora release 13 (Goddard)
/dev/vg_f13x64encrypted/lv_root mounted on /
/dev/vda1 mounted on /boot


I was asked yesterday how to use these features direct from the API. The simplest thing is probably to add the guestfish -x option which will trace out all the API calls that guestfish uses, eg:

$ guestfish --ro -x -i /tmp/encrypted.img
add_drive_opts "/tmp/encrypted.img" "readonly:true"
vfs_type "/dev/vda1"
vfs_type "/dev/vda2"
Enter key or passphrase ("/dev/vda2"): ***
luks_open "/dev/vda2" "***" "luksvda2"
vg_activate_all true

and you can use the same API calls from your own program.

Leave a comment

Filed under Uncategorized

USB Hardware Random Number Generator

This is a USB Entropy Key, cost £42 inc VAT and delivery from a company up in Lancashire.

usb 2-1: new full speed USB device using uhci_hcd and address 2
usb 2-1: New USB device found, idVendor=20df, idProduct=0001
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1: Product: Entropy Key
usb 2-1: Manufacturer: Simtec Electronics
usb 2-1: SerialNumber: M/xxx

I can report that it works fine in Fedora 13 with the open source daemon provided. The entropy can be collected in a file, passed to egd, but by default it is added to the kernel entropy pool for use by /dev/random and things like ASLR.

I love how overengineered (yet cheap) this thing is. From the documentation:

“The Entropy Key uses P-N semiconductor junctions reverse biased with a high enough voltage to bring them near to, but not beyond, breakdown in order to generate noise. In other words, it has a pair of devices that are wired up in such a way that as a high potential is applied across them, where electrons do not normally flow in this direction and would be blocked, the high voltage compresses the semiconduction gap sufficiently that the occasional stray electron will quantum tunnel through the P-N junction. (This is sometimes referred to as avalanche noise.) When this happens is unpredictable, and the occurrence of these events is what the Entropy Key measures.

These noise generators are then coupled to a 72MHz ARM Cortex-M3 CPU on the device. This processor samples the generators at a high frequency, forming a stream of random bytes. These streams of bytes are then analyzed using Ueli Maurer’s universal test for random bit generators whereby the amount of entropy in the streams is estimated rather conservatively. The streams are also exclusive-ORed together and that stream’s entropy is estimated in the same manner. If the raw streams appear to have severely reduced entropy then it indicates a fault in that generator, if the third stream has low entropy then it indicates that the generators have correlated and are not independently gathering entropy. Any of those three states are considered a failure mode and will result in the eKey locking itself out of the host, returning only an error code instead of generating entropy packets.

The two raw streams are then processed further in a de-biasing process invented by John von Neumann. Their entropy is estimated after the de-biasing process has been performed. Again, if the estimated entropy in the streams is seen to vary too wildly at this stage, the Entropy Key will lock itself out. The processed streams are then mixed into a pool made with a secure hashing function. Once at least 50% more (estimated) entropy has been mixed into the pool than it could possibly hold it is finalised and another pool initialised. Once enough pools have been processed to fill 20000 bits, the totality is subjected to the tests stipulated in FIPS 140-2. These tests produce a PASS/FAIL indicator for the block. On its own, this is not useful, since a perfectly random block could quite plausibly fail the tests. The Entropy Key therefore keeps running statistics on the FIPS 140-2 tests and will lock itself out if the ratio of failed blocks to passed blocks rises above a conservative estimate of the statistical likelihood of failure.

Once the block has been analysed, regardless of its PASS/FAIL indication, it is chopped up into 32 byte packets and these are handed off to the protocol handler in the device. Through this process therefore, each 256 bit block of data handed to the host was formed from somewhere in the region of between 3000 and 5000 bits read from the generators.”


Filed under Uncategorized

More support for Linux encrypted VMs in libguestfs

I added support for creating new LUKS disk images and managing existing key slots.

Leave a comment

Filed under Uncategorized

libguestfs support for encrypted Linux VMs

Two people asked me in about as many days if libguestfs supports encrypted VMs, so with the help of LUKS I added this feature.

A typical session in guestfish looks like this:

$ guestfish --ro -a encrypted.img
><fs> run
><fs> list-devices
><fs> list-partitions
><fs> vfs-type /dev/vda2
><fs> luks-open /dev/vda2 luksdev
Enter key or passphrase ("key"):
><fs> vgscan
><fs> vg-activate-all true
><fs> vgs
><fs> lvs
><fs> mount /dev/vg_f13x64encrypted/lv_root /
><fs> ll /
total 132
dr-xr-xr-x.  24 root root  4096 Jul 21 12:01 .
dr-xr-xr-x   20 root root     0 Jul 21 20:06 ..
drwx------.   3 root root  4096 Jul 21 11:59 .dbus
drwx------.   2 root root  4096 Jul 21 12:00 .pulse
-rw-------.   1 root root   256 Jul 21 12:00 .pulse-cookie
dr-xr-xr-x.   2 root root  4096 May 13 03:03 bin

Since it’s a little clumsy to use in guestfish at the moment, I hope we can add some convenience commands in a future release.

PS. WTF are dbus and pulseaudio doing creating those files and directories under /?

Leave a comment

Filed under Uncategorized