Compilation

Get the source from OpenBSD FTP, verify its checksum and compile it using some of the hardened Gentoo compilation flags :

sha256sum libressl-2.0.1.tar.gz # Compare with http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/SHA256
./configure CFLAGS="-O2 -march=native -fstack-protector-all -fPIE" LDFLAGS="-Wl,-z,now -Wl,-z,relro -pie"
make -j 2

Install the binary and libraries in the /opt repertory, to leave the default OpenSSL usuable :

# mkdir /opt/libressl
# cp ./ssl/.libs/libssl.so.27 /opt/libressl
# cp ./crypto/.libs/libcrypto.so.30 /opt/libressl
# cp apps/.libs/openssl /opt/libressl/libressl
# chmod 555 /opt/libressl/*.so*
# chmod 755 /opt/libressl/libressl

Then create a script to start it, for example /usr/local/bin/libressl :

#!/bin/bash

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/libressl
/opt/libressl/libressl "$@"

Then :

$ libressl version
LibreSSL 2.0

LibreSSL can now be used as a standalone tool to make some tests on its command line functions (generate keys, certificates, and so on), but the other programs will still use the OpenSSL library, until the port system makes changes to allow multiple versions of OpenSSL.

Build on Gentoo

There is no Gentoo package available yet for Password Safe, but it can be built easily from source. Once the .tar.gz archive for source and its corresponding signature are downloaded, import the key used to sign the packages, and verify the archive :

$ gpg --keyserver pgp.mit.edu --recv-keys 5CCF8BB3
$ gpg --verify pwsafe-0.93BETA-src.tgz.sig

Then, install the packages required as dependencies :

# emerge -va x11-libs/wxGTK:2.8 dev-libs/xerces-c

Then build Password Safe without Yubikey support :

$ NO_YUBI=1 make release

Security

Password safe had a few vulnerabilities since its creation, especially in its key derivation function [1] [2].
A quick look at the current code will show the bases are serious : /dev/random is used as source of entropy, Twofish is used as encryption cipher and the difficulty for the password key derivation function can be adjusted (but I found a little bug – patch for V0.93 beta available here).

The latest doubt about Password Safe was related to a SHA-256 calculation speed increase for brute-force attacks [3].
Short explanation : FUD.
Long explanation : Password Safe processes the SHA-256 iterations directly using the last SHA-256 hash result as input. The SHA-256 hash calculation is done in a main loop and internal values can be kept between iterations, so pre-processing and final hash calculations can be avoided for the intermediate iterations in order  to increase hash speed [4]. No weakness here, only an implementation optimization, pushed last year into John the Ripper and which brings a speed increase of about 10% for a brute-force attack. Since then, Password Safe offers the possibility to increase the number of iterations for key derivation from 2048 (default) to 4194304, hardening this type of attacks.

But keep in mind that GPUs, ASIC hardware or even the next Intel microarchitecture [5] can process SHA-256 operations extremely fast, so the required number of iterations (a.k.a. “Unlock Difficulty” in the security options) must be increased and a strong passphrase must be used.
The maximum difficulty can also be adjusted to a higher value in src/core/PWSfile.h (patch here). A value of 2^25 requires about 30s for unlocking on my current laptop, but greatly decreases the efficacy of a brute-force attack.

Additionally, it could also be a good idea to add some compilation flags to the default Makefile, as provided in this patch.

—
[1] : http://cxsecurity.com/cveshow/CVE-2005-3801
[2] : http://sourceforge.net/p/passwordsafe/bugs/334/
[3] : http://www.ballastsecurity.net/2012/07/auditing-of-password-safe-continues.html
[4] : http://csrc.nist.gov/groups/STM/cavp/documents/shs/sha256-384-512.pdf (page 7)
[5] : http://en.wikipedia.org/wiki/Intel_SHA_extensions

# cd /usr/src && svninfo

Move the previously used src and obj repertories :

# mv /usr/src /usr/src.9_1
# mv /usr/obj /usr/obj.9_1

Then, fetch the source from the releng/9.2 branch (in my case, from the UK mirror) :

# svn co https://svn0.eu.freebsd.org/base/releng/9.2 /usr/src

Start to compile the world the usual way :

# cd /usr/src && make -j<NUMBER_OF_CPU> buildworld

Unfortunately, GCC failed to build some part of a llvm lib on my host :

/usr/src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp:1665: internal compiler error: in memory_address_length, at config/i386/i386.c:13897

No matters what kind of error the good old GCC 4.2 could generate, I decided to switch to clang/llvm, which will be the default compiler on FreeBSD 10 anyway. This is done via /etc/src.conf :

CC=clang
CXX=clang++
CPP=clang-cpp
CPUTYPE?=native

Then I cleaned and rebuilt world. And guess what ? It worked.
After that, follow the normal way to build / install a new version [1]. Don’t forget to add the auditdistd user as requested by mergemaster, and to cleanup with make delete-old and make delete-old-libs.

New features

In FreeBSD 9.2, ZFS now include LZ4 compression, available after a pool upgrade via :

# zpool upgrade

Remember : an upgraded pool could not be used anymore by the previous versions of FreeBSD, and this operation can not be reverted. Another useful ZFS change in this release is the display of the ARC cache usage in top.

But FreeBSD 9.2 also include the long awaited OpenSSH 6.2 instead of 5.8 [2]. This version now include the AuthenticationMethods option [3] required to use SSH keypair in combination with Google Authenticator [4] (this was not possible before, because only one successful method out of all possible methods was required for a valid authentication).
So, if you want to use an SSH keypair along with with Google Authenticator, first install the port :

# portmaster security/pam_google_authenticator

Then generate a configuration file with the desired user account :

$ google-authenticator

And enable PAM in /etc/ssh/sshd_config :

ChallengeResponseAuthentication yes
UsePAM yes

As well as the authentication requirement for both public key and validation code (first require the public key) :

AuthenticationMethods publickey,keyboard-interactive

And enable the Google Authenticator module for PAM in /etc/pam.d/sshd (it replaces the password authentication for SSH, as a public key is already required by OpenSSH) :

auth            required        /usr/local/lib/pam_google_authenticator.so
#auth           required        pam_unix.so             no_warn try_first_pass

—
[1] : http://www.freebsd.org/doc/handbook/makeworld.html
[2] : http://www.freebsd.org/releases/9.2R/relnotes.html
[3] : http://lwn.net/Articles/544640/
[4] : http://code.google.com/p/google-authenticator/issues/detail?id=40

System setup

FreeBSD 9.1 is a release of choice for this kind of installation, it brings support of TRIM and SHA-512 hash for passwords. ECC based protocols are included in OpenSSH since 9.0.

Before the setup, start the installation media in single user mode, then :

• Check if TRIM is listed on the tunables of the SSD drive : /sbin/tunefs -p /dev/<drive_id>
• If required, enable TRIM : tunefs -t enable /dev/<drive_id>

The system can be installed including src and ports.
If required, new user can be assiged to wheel (for su access) and operator (for shutdown / restart) groups.

At first boot, perform the classic configuration operations :
# echo 'ifconfig_<interface_name>="inet <host_IP> netmask <host_mask>"' >>
/etc/rc.conf
# echo 'ifconfig_<interface_name>="defaultrouter="<router_IP>""' >>
/etc/rc.conf
# echo 'nameserver <DNS_IP>' >> /etc/resolv.conf

For SSH, check if root login is disabled and restrict connections to host IP only to avoid conflicts with jails. In /etc/ssh/sshd.conf :

PermitRootLogin no
ListenAddress <host_IP>

Enable password for single user mode in /etc/ttys :

console none unknown off insecure

Enable SHA-512 for system passwords (/etc/login.conf) :

default:\
     :passwd_format=sha512:\

# cap_mkdb /etc/login.conf
# passwd
# passwd <existing_users>

Then, configure the build environment :
# cp /usr/share/examples/etc/make.conf /etc/

And adapt /etc/make.conf :

CPUTYPE?=native   #'?=' allows to buildworld for a different CPUTYPE
MAKE_JOBS_NUMBER=<number_of_CPU_cores>

Install subversion :
# portsnap fetch extract && cd /usr/ports/devel/subversion
# make install clean

Then configure it and update the local source [1] :
# svn co https://svn0.eu.FreeBSD.org/base/releng/9.1 /usr/src

And rebuild the system :
# make buildworld
# make buildkernel
# make installworld
# make installkernel
# reboot

Configure tcsh (~/.login_conf) :

me:\
     :charset=UTF-8:\
     :lang=fr_FR.UTF-8:

This settings can be checked with the locale command.

Install some essentials :
# portsnap fetch extract
# cd /usr/ports/ports-mgt/portmaster && make install clean
# portmaster editors/vim-lite
# portmaster sysutils/ataidle

Enable power-savings options in /etc/rc.conf :

powerd_flags="-b min"
powerd_enable="YES"
ataidle_enable="YES"
ataidle_devices="ada<id> ada<id> ada<id>"
ataidle_ada<id>="-I 150"
ataidle_ada<id>="-I 150"
ataidle_ada<id>="-I 150"

Some kernel configuration is also necessary (/boot/loader.conf) :

• Force ZFS prefetch, which is disabled by default if the host have less than 4096MB of RAM.
• Enable AHCI for NCQ support.
• Enable thermal monitoring for AMD CPU ($ sysctl dev.cpu.0.temperature).

loader_logo="beastiebw"
vfs.zfs.prefetch_disable=0
ahci_load="YES"
amdtemp_load="YES"

And finally, import the existing pool without mounting it (it will be mounted inside a jail) :
zpool import -N
At this point, the host system is configured and all other features will be running in separate jail environments (in my case, in /usr/jails).

Jails configuration

Create the jail for the NAS environment :
# cd /usr/src
# make buildworld #If not already done
# make installworld DESTDIR=/usr/jails/
# make distribution DESTDIR=/usr/jails/
# mount -t devfs devfs /usr/jails//dev

Next, configure this jail in /etc/rc.conf :

ifconfig_<interface_ID>_alias<jail_id>="inet <IP>/<mask_prefix>"
jail_<jail_name>_hostname="<hostname>"
jail_<jail_name>_rootdir="/usr/jails/<path>"
jail_<jail_name>_devfs_enable="YES"
jail_<jail_name>_ip="<IP>"
jail_<jail_name>_exec_poststart0="/usr/jails/config/<configuration_script>.sh"

The scripts located in /usr/jails/config and declared with exec_poststart0 are launched at the jail startup, and could be used to set no-persistent configuration.
Finally, enable the jail :

jail_enable="YES"
jail_list="<jail_name>"

Generic jail configuration

After the jail is started (jls), start a shell inside it :
# jexec <jail_id> tcsh

By default in jails, there is no password for the root user, therefore the first thing to do is to set one :
# passwd
Or disable the user by adding a ‘*’ character in the second field of /etc/passwd (using vipw).

Then, basic configuration for jails :
# tzsetup
# echo 'nameserver <DNS_IP>' >> /etc/resolv.conf

NAS specific configuration

First, enable SSH in /etc/rc.conf :

sshd_enable="YES"

In jails, SSH server must be binded to the IP alias of the jail, using the listenadress directive in /etc/ssh/sshd_config :

ListenAddress <jail_IP>

and I chose to disable all authentication methods except for certificates :

PasswordAuthentication no
UsePAM no
ChallengeResponseAuthentication no
PermitRootLogin no

SSH will be used with sshfs for NAS files access.

Now, existing ZFS pool can be imported into the jail. First, make sure there is no zfs_enable="YES" directive in the /etc/rc.conf file of the host so the pool will not be  mounted automatically at host level during the boot, but only when the NAS jail will start and explicitly mount the filesystems by calling the zfs command.

The ZFS datasets must be explicitly configured to be allow mouting in a jail with the jailed property (which is permanent) :

# zfs set jailed=on <pool_or_dataset>

Then, create one or more users with the same uids than the owner of the files in the pool (in wheel group if necessary).

The operations required to mount the pool in the jail are performed in this script, which must be called at jail startup using the jail_exec_poststart0 directive.

Once the ZFS filesystem are mounted inside the jail, the ZFS mountpoints will remain the same in zfs list, but on the host, those mountpoints will be mounted under /usr/jails/<jail_name> from the df view.


Jail for remote access

On my host, I also made a other dedicated jail for remote SSH access with port-knocking.
Once logged into this jail, the other hosts / jails are reachable through another SSH connection on the local network.
After the generic configuration of the jail, SSH was also configured to accept only certificates :

ListenAddress <jail_IP>
PasswordAuthentication no
UsePAM no
ChallengeResponseAuthentication no
PermitRootLogin no

Then SSH was configured to accept only connections from specific usernames and source IPs :

AllowUsers <username1>@<remote_IP1> <username2>@<remote_IP2>

sshd is only started on demand via a port-knocking mechanism, via knockd :
# /usr/ports/security/knock
# make config #only server part
# make install clean

This feature require a specific devfs ruleset to allow bpf* devices to be accessible from the jail. If the configuration file does not already exists, copy the default file :

# cp /etc/defaults/devfs.rules /etc/devfs.rules

Then, in /etc/devfs.rules, add a specific section :

# Knockd
[devfsrules_unhide_knockd=5]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path 'bpf*' unhide

This ruleset must be declared in /etc/rc.conf :

jail_<jail_name>_devfs_ruleset="devfsrules_unhide_knockd"

The knockd configuration is available here. It start the sshd, and modify the sshd_config file to accept connections from the knocking IP.
It must be enabled with :

echo 'knockd_enable="YES"' >> /etc/rc.conf

sshd is automatically shutdown every five minutes via crond in order to refuse new connections and hide the service :

*/5     *       *       *       *       root    /etc/rc.d/sshd onestop &> /dev/null

But sshd keeps existing connections until they are intentionally closed, so this shutdown is transparent for existing sessions.

Updating

Source tree can be updated via svn update, and ports with portmasters -Da.
In order to recompile only the required parts and save time recompile existing kernel and world with the following options :
# make -DNO_KERNELCLEAN buildkernel
# make -DNO_CLEAN -j<NUMBER_OF_CORES> buildworld

Jails can be updated with the usual installworld target :
make installworld DESTDIR=/usr/jails/<jail>

—
[1] : http://www.freebsd.org/doc/handbook/svn.html

DLNA Streaming

The first step was to setup a classic DLNA streaming source with Rygel using a Pulseaudio module available in the pulseaudio-module-rygel-media-server package. This is done by adding the following options to /etc/pulse/default.pa :

#dlna
load-module module-http-protocol-tcp
load-module module-rygel-media-server
load-module module-null-sink sink_name=dlna format=s16be channels=2 rate=44100 sink_properties="device.description='DLNA' device.bus='network' device.icon_name='network-server'"

At this point, Pulseaudio create a new virtual output device named dlna.
Then, Rygel is used to serve this output with the DLNA protocol. In ~/.config/rygel.conf :

[GstLaunch]
enabled=true
launch-items=pulseaudio_out
pulseaudio_out-title=Audio output on @HOSTNAME@
pulseaudio_out-mime=audio/mpeg
pulseaudio_out-launch=pulsesrc device=dlna.monitor

Here, no shameful on-the-fly encoding with lamemp3, first because Rygel already provides built-in transcoding in MP3, and also because a WiFi network is strong enough to handle a PCM stream. This format has the advantage to avoid an additional encoding in an other lossly codec, which is a bad idea for audio quality.
The LPCM transcoding is set this way in the Rygel configuration :

transcoders=lpcm

All other features of Rygel (Tracker, MediaExport and Playbin) are disabled in my case.

At this point, an URL providing the stream is available on the local machine, but there is no way for me to call it directly from the DMR.
This is why the gupnp-dlna-tools package is required. It provides a few tools to manage DLNA devices, and more especially the gupnp-av-cp command. This command manages all the URL calls (for example, it sends the CurrentURI parameter) in order to control the DMR and fetch the laptop output from it.
So after starting rygel and set the default audio output to the DLNA device, just launch gupnp-av-cp to define the source and the destination of the stream : the output must be redirected.

Spotify

By default, wine don’t use Pulseaudio, so Spotify started with wine can’t be streamed via DLNA with this method. The working solutions are the web-based player (but it uses MP3 instead of OGG, and Flash. : two good reasons to avoid it), or the native client for Linux.

This client can be downloaded from the Spotify official repo, but it requires openssl in a version not provided in Jessie.
In order to keep standard versions of the system libraries, I manually downloaded openssl (for x86_64), then I installed Spotify in /opt :

# mkdir /opt/spotify
# dkpg -x <spotify_package.deb> /opt/spotify
# cd /opt/spotify && mv opt/spotify/spotify-client .
# dpkg -x <ssl_package.deb> /opt/spotify
# cd /opt/spotify && mv usr/lib .
# rm -rf /opt/spotify/usr && rm -rf /opt/spotify/opt

It can now be started after setting the LD_LIBRARY_PATH variable manually :

#!/bin/bash
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/spotify/lib /opt/spotify/spotify-client/spotify

The following tools were used for the compression :

• FAAC 1.28 :
  faac input.wav -q <quality> -o output.aac
• Vorbis tools 1.4.0 :
  oggenc -q <quality> input.wav
• Spectral analysis was made using a python script to compare spectral bands (available here) and Audacity to display the masking impact.

Here are the results (attenuation (dB) / frequency (Hz)). For AAC :

For OGG :

And the corresponding quality parameter / filesize :

First thoughts :

• AAC with quality < 110 must be avoid if the file is not voice only, because it cuts middle and high frequencies .
• At quality 200, AAC have a real good spectral resolution, close to the original file.
• As frequencies > 20 kHz is humanly inaudible or not rendered by the audio devices [1], OGG at quality 5 is the right choice to encode music and minimize the space usage (better resolution than ACC at level 110 for the same file size). This is also the quality level used by default by Spotify [2].
• OGG at quality 6 provides a quite good spectral resolution, very close to OGG quality 7 and 8.
• OGG at quality 6 is also the first level to enable lossless coupling [3], even if the (lossly) coupling can be disabled at fewer levels [4] (quality 5 -> quality 5 without coupling : size increased by 7%, still smaller files than quality 6).

More specifically, here is the representation of the spectral removal. Original file :

AAC at quality 200 :

OGG at quality 7 :

As we can see at the middle and the end of the sample, the amount of data required by the large spectral resolution of AAC is balanced by frequency cuts in the audible domain, more especially by a more agressive temporal masking [5], and to a lesser extent, by a more important simultaneous masking  [6] than for OGG, which only cuts high (and inaudibles anyway) frequencies.

In summation, the first thing to do is to realize you likely did not hear high frequencies anymore [1, again] (and if you don’t trust your equipment, just look at your cat/dog face while running the test).
The best candidate for the specified usage seems to be OGG at quality 5, for the restrained masking in audible domain, the limited size and the good spectral resolution. It could be improved by disabling (lossly) coupling and it is also natively supported under Linux / Android.
If you are young enouth to hear 20 kHz, OGG at quality 6 or AAC at quality 140 seems fine. And if, for weird reasons, you want to keep all inaudibles frequencies (music for your dog, maybe ?), AAC at quality 200 is the right choice.

—

[1] : http://www.audiocheck.net/audiotests_frequencycheckhigh.php
[2] : http://support.spotify.com/se/learn-more/faq/#!/article/What-bitrate-does-Spotify-use-for-streaming
[3] : http://wiki.hydrogenaudio.org/index.php?title=Recommended_Ogg_Vorbis#Recommended_Encoder_Settings
[4] : http://wiki.hydrogenaudio.org/index.php?title=Recommended_Ogg_Vorbis#Enabling_and_disabling_Vorbis_5.1.2F7.1_Channel_Coupling_for_Use_in_Mainline
[5] : https://en.wikipedia.org/wiki/Auditory_masking#Temporal_masking
[6] : https://en.wikipedia.org/wiki/Auditory_masking#Simultaneous_masking

Data export

First, export the data from SQLite :

$ sqlite3 data.db
sqlite> .mode csv
sqlite> .separator ','
sqlite> .output mydb.csv
sqlite> select field1, field2, field3 from mytable where param='value';

The rows are now saved in the selected order in a CSV file.

Data migration

In my case, the size of the dump was small enough to make the following changes using a spreadsheet :

• Insert the ‘\’ escape character before carriage returns, commas and existings ‘\’ in text fiels.
• Replace ‘0’ or ‘1’ by ‘true’ or ‘false’ values for the boolean fields.

The database schema can be exported :

sqlite> .schema

PostgreSQL import

The data can now be imported in PostgreSQL : first recreate the previously exported schema with the statement CREATE <table>. The rows import can be started with :

psql # COPY <table> FROM '/path/to/my/file' DELIMITER ',';

All data is now imported in the new database. It could be required to adjust the sequence of the generated primary key.
If SELECT MAX(<id>) FROM <table>; is greater than SELECT nextval('<table>_<id>_seq'); the sequence must be adjusted with the statement :

SELECT setval('your_table_id_seq', (SELECT MAX(id) FROM your_table));

Installation media preparation

First of all, copy the DVD1 into an USB stick :

# cat debian.iso > /dev/sdX
# sync

After a boot from this support, proceed with the classical installation, including the “Laptop” packages.

Energy saving bug

In the current kernel version (3.2.32-1) the power savings mechanism of Ivy Bridge platform is affected by a bug which leads to a random complete system freeze, more especially while using Firefox.

To get rid of this, the power savings mechanism can be disabled [1]. In /etc/default/grub, set the following :

GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.i915_enable_rc6=0"

Then re-install grub with update-grub.
This bug was corrected in more recent kernel versions.

Drivers installation

Once installed from scratch, the kernel does not detect neither the ethernet controller (Atheros AR813x), nor the WiFi chip (Dell 1704 / Broadcom 43142).

The WiFi driver is available here. Before installation, dkms must be installed from the ISO file (stored on an other partition for example) :

# mount -t iso9660 /path/to/debian-wheezy-DI-b3-amd64-DVD-1.iso /media/cdrom
# apt-cdrom add
# apt-get install dkms
# dpkg -i /path/to/wireless-bcm43142-dkms_<version>_amd64.deb

The alx driver for the ethernet card is available here. The installation must be done as documented in the project homepage :

tar xvf compat-wireless-2012-05-10-p.tar.bz2
cd compat-wireless-2012-05-10-p/
./scripts/driver-select alx
make && make install
modprobe alx

The touchpad is detected as aPS/2 mouse by default. In fact this is an ALPS touchpad :

# tpconfig
Found Synaptics Touchpad.
Firmware: 8.96 (multiple-byte mode).

The driver version 1.0 corrects the detection issue. To install it [2] :

# mv psmouse-alps-dst-1.0 /usr/src
# cd /usr/src
# dkms build psmouse/alps-dst-1.0
# dkms install psmouse/alps-dst-1.0
# rmmod psmouse && sudo modprobe -v psmouse

Since september 2013, update the CPU microcode on boot is also recommended [3] :

# apt-get install iucode-tool intel-microcode

Apt repositories configuration

Since the sources list was not completed during installation, edit the /etc/apt/sources.list to add the closest repositories :

deb http://ftp.fr.debian.org/debian/ wheezy main contrib non-free
deb http://ftp.fr.debian.org/debian/ wheezy-updates main

and comment the entry added by the apt-cdrom add :

# deb cdrom:[Debian GNU/Linux wheezy-DI-b3 _Wheezy_ - Official Snapshot amd64 DVD Binary-1 20121012-12:02]/ wheezy contrib main

Then, add te source for the source for the WiFi driver.

Miscellaneous

Flash is included in the flashplugin-nonfree package and the official JRE must be declared via alternatives :

# update-alternatives --install /usr/bin/java java /usr/java/jre1.7.0_09/bin/java 1
# update-alternatives --config java

For Gnome 3, shortcuts can be added in the applications list with alacarte or in any repertory with gnome-desktop-item-edit.
The *slightly* too thick title bar can be reduced to a decent size with :

sed -i "/title_vertical_pad/s/value=\"[0-9]\{1,2\}\"/value=\"0\"/g" /usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml

To mount filesystems via ssh, Fuse is the best solution, especially for video playing with VLC. It can be installed with :

# apt-get gvfs-fuse sshfs fuse-utils
# adduser <username> fuse

In the same domain, usbmount is required to mount external HDDs via USB with ntfs-3g.
By default, the firefox theme is poorly suited to Gnome 3, but this can be adjusted by disabling the menu bar, and by enabling the dedicated theme with an extension to disable title bar [4].

Finally, to avoid bips during completion with the tabulation key, uncomment set bell-style none in /etc/inputrc and add set vb in the file ~/.vimrc.

Power management and temperature

The graphics chip sleep mode (i915.i915_enable_rc6) is available only from the current unstable kernel (3.8.13). To install it, add the unstable repo in /etc/apt/sources.list :

deb http://ftp.fr.debian.org/debian/ unstable main

Then lock system upgrade from unstable by modifying its priority with the file /etc/apt/preferences :

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 102

The kernel can be installed :

# apt-get -t unstable install linux-image-3.8-2-amd64

Compatible drivers are available for WiFi and touchpad (the install is done the same way than for previous kernel versions).
At this point, the power saving options can be enabled in /etc/default/grub :

GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.i915_enable_rc6=3 i915.i915_enable_fbc=1 i915.lvds_downclock=1 pcie_aspm=force acpi_osi=Linux"

Followed by a grub update for application :

# update-grub

The CPU scaling governor can also be set to conservative via cpufrequtils to limit the CPU frequency [5]. Temperature monitoring can me done with the i8kctl temp command, provided in the i8kutils package.

Finally, the kernel module for SD card reader can be disabled (it makes a lot of cpu events), and power saving mode for the audio chipset can be forced. In a new /etc/modprobe.d/power_savings.conf file, set :

blacklist rts5139
options snd-hda-intel power_save=5
options snd-hda-intel power_save_controller=Y

And to prevent powerd to overwrite this settings, disable the corresponding module via the /etc/pm/config.d/modules configuration file :

HOOK_BLACKLIST="intel-audio-powersave"

H264 hardware acceleration

To enable the MPEG2 and H.264 decoding by the graphics chipset, install the packages libva-intel-vaapi-driver and vainfo. The vainfo command will return all the video codecs supported by the GPU. Hardware acceleration is also natively supported by VLC, after enabling it in the preferences, and by mplayer in this this build [6].

—
[1] : http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1075486.html
[2] : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238/comments/227
[3] : http://lists.debian.org/debian-user/2013/09/msg00126.html
[4] : http://libre-ouvert.toile-libre.org/index.php?article117/toi-aussi-gnome3-firefox-adwaita-htitle-movable-firefox-button-tab-bar-omnibar
[5] : http://wiki.debian.org/HowTo/CpuFrequencyScaling
[6] : http://devel.mplayer2.org/ticket/17

Recommandations

L’échange de clés Diffie-Hellman basé sur les courbes elliptiques (ECDH) est devenue la méthode recommandée pour le chiffrement asymétrique ces dernières années, notamment dans la “Suite B” publiée par la NSA en 2010[2], qui exclue totalement les protocoles basés sur le RSA ou le logarithme discret (DSA).

La NSA recommande l’utilisation de ECDH avec des clés de 256 bits ou 384 bits selon le niveau de confidentialité des informations. En France, l’ANSSI recommande une taille de clé d’au moins 256 bits pour l’ECDH[3]. Étant donné son fonctionnement, le protocole ECDH nécessite des clés de taille beaucoup plus réduite que ses prédécesseurs tout en assurant le même niveau de sécurité. Il est conseillé d’utiliser des clés de 256 bits pour ECDH lorsqu’il est couplé avec AES en 128 bits, tandis que RSA nécessite une clé de 3072 bits pour assurer une sécurité équivalente[4].

Protocole de l’échange de clés

En résumé, l’échange de clé se déroule de la façon suivante :

• Accord entre A et B sur les paramètres de la courbe et un point commun P choisi au hasard sur cette courbe.
• Génération de grands nombres aléatoires K par chacun des protagonistes. Ces nombres correspondent à leur clé privée.
•  A envoie Qa à B. Qa est un point sur la courbe correspondant à la multiplication du point P par la clé privée Ka de A. Qa correspond à la clé publique de A.
• B envoie également sa clé publique Qb générée à partir de P et de sa clé privée privée Kb.
• A et B peuvent maintenant calculer le secret partagé (Ka.Kb).P à partir de Kb.(Qa) et Ka.(Qb).
• La clé utilisée pour le chiffrement proprement dit de la communication (avec AES par exemple) est générée  à partir d’un hash du secret partagé.

Pour plus d’explication sur les mécanismes mathématiques en jeu dans cet échange, voir cette présentation.

Sécurité

Il est couramment admis que la sécurité de cet échange repose sur le fait qu’il est facile de calculer Qa et Qb à partir de P, Ka et Kb, mais qu’il est impossible de retrouver les clés privées K à partir des éléments publics P, Qa et Qb.

En effet, aucune méthode permettant de résoudre le logarithme discret sur la courbe elliptique (donc retrouver Ka à partir de Qa et P) n’est connue publiquement à ce jour.
Au premier abord, il est parait simple de retrouver K “à la main” puisque la multiplication scalaire est réalisée très rapidement par les deux protagonistes. Cependant, le calcul du point Q repose sur des optimisations qui permettent de réduire très fortement le nombre de points intermédiaires à calculer[5] (un peu à l’image de l’exponentiation rapide[6] pour les échanges de clé reposants sur le logarithme discret). Une recherche exhaustive de K à partir de Q et P implique un calcul de chaque point Q possible et donc un temps de calcul mettant hors de portée cette solution.

D’autres méthodes ont été trouvées pour accélérer ce calcul (Shanks’ Method, Baby-step giant-step[7], Pollard’s Rho[8][9]) avec une complexité O(√(n)). Un “challenge”[10] est d’ailleurs en cours pour casser ECDH à l’aide de ces outils et donne un bon aperçu du temps et des ressources nécessaires pour un challenge sur 131 bits (estimation : 2466 Playstation 3 utilisées pendant 1 an[11]).

En pratique

Pour mes clés SSH, j’ai donc tendance à favoriser d’abord des clés ECDSA, puis RSA de grande taille, et s’il y n’y a pas d’autre solution, une paire en DSA.

ECDSA n’a pas fait l’objet pour le moment d’attaque significative[12], mais n’est pas encore disponible sur toutes les distributions (notamment Fedora, qui exclut ECDSA conformément à sa licence, puisque le protocole est encore couvert par un brevet en cours de validité).

RSA est toujours fiable, à condition d’utiliser des clés de taille supérieure à 4096 bits. Le dernier record de factorisation a été établi en 2010 sur 768 bits[13] (temps de calcul estimé à 6 mois avec 10000 stations de travail[14]).

Quant à DSA, la dernière attaque portant sur le logarithme discret avec des clés standard date de 2005 et a atteint 613 bits[15] (avec 4*16 processeurs pendant 17 jours[16]).
Les spécifications actuelles de DSA empêchent son utilisation avec une clé de plus de 1024 bits, et même si cette taille peut être considérée comme sûre, elle ne permet pas une fiabilité à très long terme de ces clés.
Il est intéressant de noter que l’ANSSI a révoqué en 2010 un des certificats racine de l’État (qui avait été émis en 2007, de type DSA 1024 bits) et continue par ailleurs à utiliser des certificats RSA de 2048 et 4096 bits[17].
Dans la documentation publiée à partir d’avril 2013, l’ANSSI ne recommande d’ailleurs plus l’utilisation de clés DSA [18].

—
[1] : http://www.openssh.com/txt/release-5.7
[2] : http://www.keylength.com/
[3] : http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf
[4] : http://www.nsa.gov/business/programs/elliptic_curve.shtml
[5] : https://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/fr//pubs/archive/37376.pdf – 3.3 Point multiplication with precomputation
[6] : https://en.wikipedia.org/wiki/Exponentiation_by_squaring
[7] : https://en.wikipedia.org/wiki/Counting_points_on_elliptic_curves#Baby-step_giant-step
[8] : http://math.ucalgary.ca/~mmusson/presentations/ECC09SummerSchool.pdf
[9] : http://www.ecc-challenge.info/anon.pdf
[10] : http://www.certicom.com/index.php/the-certicom-ecc-challenge
[11] : http://www.ecc-challenge.info/
[12] : https://en.wikipedia.org/wiki/Discrete_logarithm_records#Elliptic_curves
[13] : https://www.rsa.com/rsalabs/node.asp?id=3723
[14] : http://eprint.iacr.org/2010/006.pdf
[15] : https://en.wikipedia.org/wiki/Discrete_logarithm_records#Finite_fields
[16] : https://listserv.nodak.edu/cgi-bin/wa.exe?A2=ind0509&L=NMBRTHRY&P=R1490&D=0&I=-3&T=0
[17] : http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000022299271&dateTexte=&categorieLien=id
[18] : http://www.ssi.gouv.fr/fr/guides-et-bonnes-pratiques/recommandations-et-guides/securite-des-reseaux/recommandations-pour-un-usage-securise-d-open-ssh.html

Disk preparation

First, connect the backup disk to the computer, and make sure the device descriptor points to the correct drive :

# smartctl -i /dev/ad2
 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.3-RELEASE-p3 amd64] (local build)
 Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
 Model Family: Seagate Barracuda Green (Adv. Format)
 Device Model: ST2000DL003-9VT166
 Serial Number: xxxxxxx
 LU WWN Device Id: 5 000c50 044b0747a
 Firmware Version: CC3C
 User Capacity: 2,000,398,934,016 bytes [2.00 TB]
 Sector Sizes: 512 bytes logical, 4096 bytes physical
 Device is: In smartctl database [for details use: -P show]
 ATA Version is: 8
 ATA Standard is: ATA-8-ACS revision 4
 Local Time is: Wed Jun 20 19:04:15 2012 CEST
 SMART support is: Available - device has SMART capability.
 SMART support is: Enabled

Then, create a new pool on this drive, with no particular option :

# zpool create backup /dev/ad2
# zpool status backup
 pool: backup
 state: ONLINE
 scan: none requested
 config:
NAME STATE READ WRITE CKSUM
 backup ONLINE 0 0 0
 ad2 ONLINE 0 0 0
errors: No known data errors

This is followed by the datasets creation. The option copies=2 [1] is used for the “important” datasets in order to protect them against an hypothetical bit rot [2] (but this double the used disk space).

# zfs create backup/fichiers
# zfs create -o checksum=sha256 -o copies=2 backup/fichiers/Photos

Less critical datasets can be created in a more usual way :

# zfs create -o checksum=sha256 backup/fichiers/Videos

Backup

For my backups, I chose the send option [3] included in ZFS. This feature is mainly used for data replication between hosts, but it is not recommended for backups on a external storage support, for a good reason : if one block is corrupted in the flow, the whole backup becomes unusable, which explains the importance of not forgetting the copies=2 option previously mentioned.

These backups are made from existing snapshots and encrypted with openssl this way :

# zfs send data/fichiers/Photos@062012 | openssl enc -aes-256-cbc -salt > /backup/fichiers/Photos/Photos_062012.ssl

And for “compressible” data :

# zfs send data/fichiers/Documents@062012 | compress | openssl enc -aes-256-cbc -salt > /backup/fichiers/Documents/Documents_062012.z.ssl

Once the backup is finished, the pool can be exported :

# zfs export backup

Backup validation

To make sure the backup is usable, the drive must be checked from time to time, for example with the live CD mode integrated into FreeBSD 9.0 (in this mode, the keymap can be changed via the kbdmap command).

A global check (zpool scrub) is possible after a drive import. All available pools can be listed with the zpool import command, and an alternative mountpoint can be set with the -R option, since / is in read-only mode when the live CD is used :

# zpool import
# mkdir /tmp/zfsroot
# zpool import -R /tmp/zfsroot <pool>
# zpool scrub <pool>

To check backups integrity at the filesystem level, the pool can be mounted in read-only, and checked with zstreamdump [4] :

# zpool import -o readonly=on -R /tmp/zfsroot <pool>
# openssl enc -d -aes-256-cbc -in /tmp/zfsroot/path/to/file.ssl | zstreamdump

If zstreamdump returns only the checksum, the backup data is valid. Otherwise, the command returns the following error :

Expected checksum differs from checksum in stream.

—
[1] : http://docs.oracle.com/cd/E19253-01/820-2315/gevpg/index.html
[2] : http://www.linux-mag.com/id/8794/
[3] : http://docs.oracle.com/cd/E19963-01/html/821-1448/gbchx.html
[4] : http://blog.richardelling.com/2009/10/check-integrity-of-zfs-send-streams.html