Quelques digressions sous GPL...

Aller au contenu | Aller au menu | Aller à la recherche

Hardware RNG in Via CPU (on debibox)

Par Julien Vehent, le lundi, août 19 2013 (General)

4 years ago I was writing about getting an eKey to generate more entropy. Well, I never bought the eKey, and it took me 4 years to look at entropy generation again, but I found some interesting results today.

I was trying to set up /dev/hw_random on an Intel Xeon E3-1270. While /proc/cpuinfo indicates support for rdrand instructions, intel-rng refuses to load and I am still figuring out why.

While reading the readme of rng-tools, I stumbled across "The VIA Hardware RNG". Remembering that my Dedibox from online.fr uses a VIA Nano processor U2250, I ssh-ed into it, and discovered the awesomeness of this tiny CPU.

# cat /proc/cpuinfo 
processor	: 0
vendor_id	: CentaurHauls
cpu family	: 6
model		: 15
model name	: VIA Nano processor U2250 (1.6GHz Capable)
< ... snip ...>
flags		: ...  rng rng_en ...
< ... snip ...>

Note the 'rng' cpu flag above. That all that's needed to use the hwrng. Well, that and a few kernel modules:

# modprobe rng-core

# modprobe via_rng

# file /dev/hwrng 
/dev/hwrng: character special

The harware RNG is loaded in /dev/hwrng. Using the tools from the 'rng-tools' package, we can test the quality of the randomness provided.

# rngtest -c 100 < /dev/hwrng 
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 2000032
rngtest: FIPS 140-2 successes: 100
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=140.395; avg=339.623; max=369.441)Kibits/s
rngtest: FIPS tests speed: (min=3.289; avg=48.125; max=57.798)Mibits/s
rngtest: Program run time: 5790927 microseconds

All FIPS tests pass. Now a small bandwidth test:

# dd if=/dev/hwrng of=awesomerandom bs=128 count=10240
10240+0 enregistrements lus
10240+0 enregistrements écrits
1310720 octets (1,3 MB) copiés, 27,9087 s, 47,0 kB/s

47kB/s, or 385024 bits per second, is pretty damn good for a random number generator! Now let's feed that into the kernel's entropy pool using rngd.

The initial entropy pool, while using SSH on the server:

# cat /proc/sys/kernel/random/entropy_avail
153

RNGD being installed, I configured the default parameters in /etc/default/rng-tools as shown below. I tried using the more recent viapadlock driver, but it doesn't seem to be supported on my architecture. The viakernel worked fine.

# cat /etc/default/rng-tools 
# Configuration for the rng-tools initscript
# $Id: rng-tools.default,v 1.1.2.5 2008-06-10 19:51:37 hmh Exp $

# This is a POSIX shell fragment

# Set to the input source for random data, leave undefined
# for the initscript to attempt auto-detection.  Set to /dev/null
# for the viapadlock driver.
HRNGDEVICE=/dev/hwrng
#HRNGDEVICE=/dev/null

# Additional options to send to rngd. See the rngd(8) manpage for
# more information.  Do not specify -r/--rng-device here, use
# HRNGDEVICE for that instead.
#RNGDOPTIONS="--hrng=intelfwh --fill-watermark=90% --feed-interval=1"
RNGDOPTIONS="--hrng=viakernel --fill-watermark=90% --feed-interval=1"
#RNGDOPTIONS="--hrng=viapadlock --fill-watermark=90% --feed-interval=1"

Then restart rngd:

# /etc/init.d/rng-tools restart
Stopping Hardware RNG entropy gatherer daemon: rngd.
Starting Hardware RNG entropy gatherer daemon: rngd.

# ps aux|grep rngd
root      6539  3.2  0.0  30628   616 ?        SLsl 17:42   0:00 /usr/sbin/rngd -r /dev/hwrng --hrng=viakernel --fill-watermark=90% --feed-interval=1

And, as a result, the entropy pool filled up immediatly:

# cat /proc/sys/kernel/random/entropy_avail
3968

A simple test shows the immense difference in entropy available. The results below show that retrieving 120kB of randomness takes 3.4s with rngd enabled, and forever without it. I had to kill dd after several minutes because it was getting nowhere. As soon as I restarted rngd, the pool filled up again.

# dd if=/dev/random of=randomstuff bs=128 count=1024
768+256 enregistrements lus
768+256 enregistrements écrits
120181 octets (120 kB) copiés, 3,47491 s, 34,6 kB/s

# /etc/init.d/rng-tools stop
Stopping Hardware RNG entropy gatherer daemon: rngd.

# dd if=/dev/random of=randomstuff bs=128 count=1024
^C2+10 enregistrements lus
2+10 enregistrements écrits
450 octets (450 B) copiés, 114,238 s, 0,0 kB/s

# cat /proc/sys/kernel/random/entropy_avail
103

# /etc/init.d/rng-tools start
Starting Hardware RNG entropy gatherer daemon: rngd.

# cat /proc/sys/kernel/random/entropy_avail
3968

I've had this server for 3 years, and I never thought it supported a hardware RNG. Today is a good day :)

Home made Keystore with OpenSSL and Bash

Par Julien Vehent, le vendredi, juin 28 2013

Storing password and confidential data across multiple computer is always a complex problem to solve. They are great tools, such as keypass, that can do this in a secure manner, but for some reason I always felt uneasy about giving my bank password to a 3rd party software.

So, I made my own. It's a simple file encrypted in aes-256-cbc using openssl.

Create a new encrypted file using this command:

echo "my new credential file" | openssl aes-256-cbc -e -a -salt -out mycredentials.encrypted

This creates the file "mycredentials.encrypted". You can then use the scripts below to read your credentials:

getsecret,sh

#!/usr/bin/env bash
if [[ -x "$1" || ! -r "$1" ]]; then
    echo "usage: $0 <ciphered file>"
    exit 1
fi
SECFILE=$1
CLEARTEXT=$(openssl aes-256-cbc -d -a -salt -in $SECFILE)
if [ $? -gt 0 ]; then
    echo "Wrong password, cannot decrypt"
    exit $?
else
    echo "$CLEARTEXT"
fi

storesecret.sh

#!/usr/bin/env bash
# store a password in a ciphered file
if [[ $1 = "" || ! -r $1 ]]; then
    echo "usage: $0 <ciphered file>"
    exit 1
fi
SECFILE=$1

# decipher access file
CLEARTEXT=$(openssl aes-256-cbc -d -a -salt -in $SECFILE)
if [ $? -gt 0 ]; then
    echo "Wrong password, cannot decrypt"
    exit $?
fi

# get new value to store
echo "enter value to append (1 line)"
echo -n "> "
read PASSWD
UPDATED_CLEARTEXT=$(echo -e "$CLEARTEXT\n$PASSWD")

# cipher access file and delete temporary file
echo "$UPDATED_CLEARTEXT"| openssl aes-256-cbc -e -a -salt -out $SECFILE.updated
if [ $? -gt 0 ]
then
    echo "Password encryption failed, password not stored in $SECFILE"
else
    mv "$SECFILE.updated" "$SECFILE"
    echo "information successfully encrypted and store in $SECFILE"
fi
#clean up
CLEARTEXT=$(dd if=/dev/urandom bs=128 count=128 2>/dev/null)
PASSWD=$(dd if=/dev/urandom bs=128 count=128 2>/dev/null)
UPDATED_CLEARTEXT=$(dd if=/dev/urandom bs=128 count=128 2>/dev/null)

There is a couple of drowbacks with this method:

  • Your decrypted credentials are stored in cleartext in a BASH variable at some point, The variables are flushed at the end of the storage process, but you don't want to run this script on an untrusted machine
  • Credentials are displayed in your terminal. Make sure you don't leave that open, and use ./getsecret.sh <credential_file> | grep "bank" to retrieve only the credentials you want, and not the whole file.
  • The storage password requires that you type your password 3 times. That's the only safe way to encrypt/decrypt without passing the password on the command line.

It's definitely not a perfect solution, but I like to do things the hard way :)

DKIM:1, Phisher:0

Par Julien Vehent, le mercredi, juin 12 2013 (General)

I received this morning a very good phishing attempts in my mailbox. The email is almost perfectly crafted to match the usual Bank of America communications, except for two details:
  1. BoA-Phishing-20130611.pngThere is no DKIM signature. It shows right away because of the little icon on the "From" line, displayed by my DKIMStatus plugin for roundcube.
  2. The link below "To get start" (with a spelling mistake that I didn't notice at first) point to http://oncu*****.com/bura****.com.tr/index4.html, which is obviously not the BoA website...

Still, this phishing is one of the most dangerously well crafted I've seen in a long time... Stay sharp, and don't click on these links!

Introducing AutOssec: automated Ossec deployment for Chef

Par Julien Vehent, le dimanche, juin 9 2013 (General)

Ossec is a great tool to monitor the security of a set of systems. Servers, VMs, PCs... Ossec can keep an eye on your systems and send alerts when "something" happens. "something" being defined by Ossec rules that can be a little tricky to write and keep under control.

GITS-InformationAge_clip_image003.jpg

While working at AWeber, I had to integrate the deployment of Ossec agents in Chef. The security model of Ossec requires one agent and one server to share a secret key, and this usually means that someone has to go into the server, generate the key, and push it to the agent. Ossec solved in early 2011 with a daemon called ossec-authd, but the lack of access-control and confidence in the code prevented us from using it. Instead, I wrote a cookbook for chef called chef-autossec that takes care of the entire provisioning of an ossec infrastructure:

  • Provision the Ossec server, including decoders and custom rules, using node attributes
  • Provision the Ossec agents and generate the keys based on the server configuration automatically
  • Help keep agents online by cleaning up broken connections, and forcing agents restarts
  • hostname_search leverages Chef search capability to automatically populate a list of hosts in a rule. If you want a given rule to apply to all postgres database server, and only those, you could create the rule with ':hostname_search => "roles:postgres"' and the resulting rule would have all the postgres hostnames in the "<hostname>" parameter.
  • event_location_tag and event_location_search do the same thing as hostname_search but for <email_alerts> blocks

The cookbook is available on github: https://github.com/jvehent/AutOssec

Feel free to use it, comment on it, and contribute code !

AFW at Netfilter Workshop 2013

Par Julien Vehent, le dimanche, mai 26 2013 (General)

It's been a busy 2013 so far! So busy that I'm only now processing the videos I recorded over 2 months ago... But here it is, the recording of my presentation of AFW from the Netfilter Workshop 2013 at Open Source Days in Copenhagen. I was there for a few days, and had a great time with the Netfilter core team and folks passionate enough to attend 3 days of really good technical discussions.

Oh, and I just joined Mozilla as Operations Security Engineer! Really excited about that one, there's a lot of exciting things going on. Stay tuned. My talk: (click here for the slides)

AFW, Automating host-based firewalls with Chef, Julien Vehent from Julien Vehent on Vimeo.

All of the talks I recorded are here: link. Check it out, they are all really good !

- page 2 de 30 -