this is the proper way to handle such situations. destruction of
drive content then reduces to permanent destruction of the disk
encryption keys (much, much smaller and easier to irreversibly
destroy).
> ... Then store the key in a SRAM that can get electronically
> erased. It would be needed to occassionally swap the bits in the SRAM to
> prevent their "burn-in"
loop-aes [0] supports "key scrubbing" so that disk keys are regularly
rotated in system memory while utilized. some other FDE solutions do
too...
> Make the device
> tamper-sensitive so an attempt to open the dongle or enter a wrong
> key-unlocking PIN too many times will lead to zeroing of the key. Realize
> the disk encryption either in hardware (eg. www.opencores.org contains
> open-source implementation of AES for an FPGA, allowing design of a
> pass-through IDE module), or in software (eg. using Linux with a suitably
> hacked bootloader, or booting from ROM with code that asks the key storage
> module for the disk key and then loads the OS).
without getting off topic, key management for disk and file encryption
is difficult, and very context dependent. expect to spend most of
your effort here.
padlock hardware acceleration in VIA cores gives you enough throughput
that drive or network interfaces will be the bottle neck. you'll need
to do some work to integrate acceleration into your host OS and
applications, but well worth the performance. [1]
physical tamper resistant / evident packaging is hard. there are some
decent key storage / authentication fobs out there. in some
situations a password encrypted USB device is sufficient.
read only ISO or TPM authenticated bootloader must be used to ensure
pre-boot/boot initialization and authentication integrity.
> The key has to be truly randomly generated (a hash of couple seconds of
> noisy audio?). To generate a 256-bit hex key of a decent strength we can
> use eg. this line of code (assumptions: Linux, noisy audio of suitable
> level at /dev/dsp):
> for x in 1 2; do dd if=/dev/dsp bs=512 count=1 2>/dev/null | md5sum |tr -d '\n -'; done
don't do this. use a strong cryptographically secure generator (like
Yarrow [2]) or a true hardware entropy source. rngd or mtrngd for
linux with the afore mentioned padlock core works great. [3]
> Some common pitfalls:
> * Unencrypted swapfile. Don't use it or place it on the encrypted disk.
swap must be encrypted, along with any hibernate storage partitions if
used. most FDE solutions handle this too.
> * <lots of threats to consider>
indeed. the cipher itself will not be the weak link. physical
security and software integrity are the killers...
best regards,
0. loop-aes README
http://loop-aes.sourceforge.net/loop-AES.README
1. padlock openssl patches / performance:
1.5Ghz C7 with patched openssl speed test:
SHA-1 throughput 268,405.03kB/sec with 8k blocks
SHA2-256 throughput 263,643.08kB/sec with 8k blocks
AES-128-CBC throughput 1,029,006.84kB/sec with 8k blocks
AES-256-CBC throughput 779,103.35kB/sec with 8k blocks
[ montmult accel via openssl 0.9.9 bn_mont_mult via-mont.pl asm optimization ]
rsa 1024 394.1 sign/sec, 8710.6 verify/sec
rsa 2048 84.0 sign/sec, 2973.4 verify/sec
rsa 4096 14.2 sign/sec, 866.8 verify/sec
dsa 1024 1024.0 sign/sec, 852.5 verify/sec
dsa 2048 349.2 sign/sec, 294.6 verify/sec
[ to gather your own stats invoke "openssl speed" ]
2. Yarrow cryptographically secure PRNG
http://www.schneier.com/yarrow.html
3. It is poor practice to use hardware entropy sources directly.
usually a daemon of some kind reads from the hardware, performs
various sanity/FIPS checks to ensure the generator is not obviously
broken, and then mixes and feeds into /dev/random. the VIA padlock
entropy sources support a high bit rate mode with less entropy density
that can be used with AES or other compression and masking of entropy
output (to obscure generator bias/state) for extremely high
throughput:
root_at_c7dev:/var/entropy# time head -c 50000000000 /dev/hwrng > setlg2.bin
real 211m48.342s
user 0m25.522s
sys 143m9.313s
root_at_c7dev:/var/entropy# ls -lh setlg2.bin
-rw-r--r-- 1 root root 47G 2007-03-21 18:24 setlg2.bin
Received on Sat Mar 02 2024 - 00:57:18 CST