Re: questions to the security of softraid_crypto
On Monday 02 March 2015, Peter J. Philipp wrote:
On 03/01/15 23:17, Ted Unangst wrote:
Peter J. Philipp wrote:
Hi,
I am not the best C reader and programmer out there so I try to make
myself tools that may seem useless in order to better understand. I see
this in /sys/dev/softraid_crypto.c
int
sr_crypto_encrypt(u_char *p, u_char *c, u_char *key, size_t size, int
alg) {
rijndael_ctxctx;
int i, rv = 1;
switch (alg) {
case SR_CRYPTOM_AES_ECB_256:
This function is only used to encrypt the master key, which is a small
chunk of random data.
Thanks for taking a look Tedu, I really appreciate it. I'm wondering
does this master key use salt to protect against rainbow tables? At a
glance at the code I see not mention of salt.
I would strongly suggest that you follow the entire path through, rather than
reading small pieces of code and guessing as to how the rest of the code may
be implemented. In other words, you might want to undertake some research and
see if you can answer the following questions (the questions that you are
asking will likely be answered in the process):
- What encryption algorithm/mode is used for disk block encryption?
- Where do the keys come from that are used for the disk block
encryption/decryption?
- How are the keys that are used to encrypt the disk blocks stored?
- When creating a new softraid crypto volume, where does the key come from?
- What happens if you use a keydisk instead of a passphrase?
dd if=/dev/zero of=EFS2 bs=1g count=1
vnconfig vnd0 EFS2
bioctl -c C -l /dev/vnd0a softraid0
And I created a filesystem on it and populated it. In fact I use this
EFS2 file for storing work related things in it (so I can never share
it). I ran this program over the EFS2 file:
so it says that there is 652063 occurences where AES blocks were
duplicated, to me that's near 10 MB of material someone can use like the
above [1] where it says it could describe the data pattern.
It seems more likely you found the 652063 zero blocks that haven't been
written to yet.
Note that if you are concerned about people doing stat analysis on your
encrypted disk, you should be sure to overwrite the entirety of it.
Either with /dev/random on the outside, or /dev/zero on the inside, to
ensure the used and unused portions look the same.
That's good advice I'll try to fill up the space inside with a file and
see if the number of those blocks goes down. It isn't all zero blocks
but the majority of it could be.
By design softraid does not scrub or overwrite what is on the underlying disk
chunks until such time as you actually write data to the softraid volume. As
Ted noted, you will need to fill the disk chunks (or softraid volume)
yourself if you want to guarantee such a state.
--
Action without study is fatal. Study without action is futile.
-- Mary Ritter Beard
questions to the security of softraid_crypto
Hi,
I am not the best C reader and programmer out there so I try to make
myself tools that may seem useless in order to better understand. I see
this in /sys/dev/softraid_crypto.c
int
sr_crypto_encrypt(u_char *p, u_char *c, u_char *key, size_t size, int alg)
{
rijndael_ctxctx;
int i, rv = 1;
switch (alg) {
case SR_CRYPTOM_AES_ECB_256:
if (rijndael_set_key_enc_only(ctx, key, 256) != 0)
goto out;
for (i = 0; i size; i += RIJNDAEL128_BLOCK_LEN)
rijndael_encrypt(ctx, p[i], c[i]);
rv = 0;
break;
default:
DNPRINTF(SR_D_DIS, %s: unsupported encryption algorithm
%d\n,
softraid, alg);
rv = -1;
goto out;
}
so it says SR_CRYPTOM_AES_ECB_256:
^^^
1. wikipedia has this to say about the ECB mode:
The disadvantage of this method is that identical plaintext blocks are
encrypted into identical ciphertext blocks; thus it does not hide data
patterns well.
http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
section 4.1
2. In the book Cryptographic Engineering by Niels Ferguson, Bruce
Schneier and Tadayoshi Kohno, it says on page 65, section 4.2
Do not ever use ECB for anything.
So I slept on this many nights and wondered if perhaps I read the code
wrong, misunderstood something. So then I wrote a program to analyse a
sparse file which contains a softraid encrypted volume. The sparse file
I created with something like (not true sequence):
dd if=/dev/zero of=EFS2 bs=1g count=1
vnconfig vnd0 EFS2
bioctl -c C -l /dev/vnd0a softraid0
And I created a filesystem on it and populated it. In fact I use this
EFS2 file for storing work related things in it (so I can never share
it). I ran this program over the EFS2 file:
#include sys/types.h
#include sys/stat.h
#include sys/mman.h
#include fcntl.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
int mycmp(const void *, const void*);
void uniq(char *addr, u_int64_t size);
int
main(void)
{
int fd;
uint64_t i, j;
uint64_t count;
struct stat sb;
char *addr;
printf(opening file\n);
fd = open(/tmp/EFS2, O_RDWR, 0600);
if (fd 0) {
perror(open);
exit(1);
}
if (fstat(fd, sb) 0) {
perror(fstat);
exit(1);
}
addr = mmap(NULL, sb.st_size, PROT_READ | PROT_WRITE, MAP_SHARED
| MAP_ANON, -1, 0);
if (addr == MAP_FAILED) {
perror(mmap);
exit(1);
}
printf(reading in file, %lld bytes\n, sb.st_size);
count = 1;
for (i = sb.st_size, j = 0; i = 0; i -= (16), j += (16)) {
if (read(fd, addr[j], 16) == 0)
break;
if (j = count) {
printf(%d, , count);
fflush(stdout);
count = 1;
}
}
close(fd);
printf(\nsorting memory\n);
heapsort((void*)addr, sb.st_size / 16, 16, mycmp);
printf(finding duplicates\n);
uniq(addr, sb.st_size);
printf(munmaping file\n);
munmap(addr, sb.st_size);
exit(0);
}
int
mycmp(const void *p, const void *e)
{
return (memcmp(p, e, 16));
}
void
uniq(char *addr, u_int64_t size)
{
char *last = addr;
u_int64_t i, j;
int uniq = 0;
for (j = size, i = 0; j 0; j -= 16, i += 16) {
if (i memcmp(last, addr[i], 16) == 0) {
uniq++;
}
last = addr[i];
}
printf(duplicates ( 1) == %d\n, uniq);
}
The program mmaps anonymous space the size of the EFS2 file (1GB) then
copies the sparse file to this memory region, sorts it and does
something like a uniq only counting how many times there is a duplicate
occurance. The output looks like this:
mercury$ ./probe
opening file
reading in file, 1073741824 bytes
1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384,
32768, 65536, 131072, 262144, 524288, 1048576, 2097152, 4194304,
8388608, 16777216, 33554432, 67108864, 134217728, 268435456, 536870912,
sorting memory
finding duplicates
duplicates ( 1) == 652063
munmaping file
so it says that there is 652063 occurences where AES blocks were
duplicated, to me that's near 10 MB of material someone can use like the
above [1] where it says it could describe the data pattern.
So I'm sorta stuck with this still, was there any point of me doing this
program, or is softraid_crypto still safe from cryptanalysis?
If indeed it is ECB would it be worth it to listen to [2] and not use
it? Would a counter mode be better for this perhaps?
Regards,
-peter
Re: questions to the security of softraid_crypto
Peter J. Philipp wrote:
Hi,
I am not the best C reader and programmer out there so I try to make
myself tools that may seem useless in order to better understand. I see
this in /sys/dev/softraid_crypto.c
int
sr_crypto_encrypt(u_char *p, u_char *c, u_char *key, size_t size, int alg)
{
rijndael_ctxctx;
int i, rv = 1;
switch (alg) {
case SR_CRYPTOM_AES_ECB_256:
This function is only used to encrypt the master key, which is a small chunk
of random data.
dd if=/dev/zero of=EFS2 bs=1g count=1
vnconfig vnd0 EFS2
bioctl -c C -l /dev/vnd0a softraid0
And I created a filesystem on it and populated it. In fact I use this
EFS2 file for storing work related things in it (so I can never share
it). I ran this program over the EFS2 file:
so it says that there is 652063 occurences where AES blocks were
duplicated, to me that's near 10 MB of material someone can use like the
above [1] where it says it could describe the data pattern.
It seems more likely you found the 652063 zero blocks that haven't been
written to yet.
Note that if you are concerned about people doing stat analysis on your
encrypted disk, you should be sure to overwrite the entirety of it. Either
with /dev/random on the outside, or /dev/zero on the inside, to ensure the
used and unused portions look the same.
Re: questions to the security of softraid_crypto
On 03/01/15 23:17, Ted Unangst wrote:
Peter J. Philipp wrote:
Hi,
I am not the best C reader and programmer out there so I try to make
myself tools that may seem useless in order to better understand. I see
this in /sys/dev/softraid_crypto.c
int
sr_crypto_encrypt(u_char *p, u_char *c, u_char *key, size_t size, int alg)
{
rijndael_ctxctx;
int i, rv = 1;
switch (alg) {
case SR_CRYPTOM_AES_ECB_256:
This function is only used to encrypt the master key, which is a small chunk
of random data.
Thanks for taking a look Tedu, I really appreciate it. I'm wondering
does this master key use salt to protect against rainbow tables? At a
glance at the code I see not mention of salt.
dd if=/dev/zero of=EFS2 bs=1g count=1
vnconfig vnd0 EFS2
bioctl -c C -l /dev/vnd0a softraid0
And I created a filesystem on it and populated it. In fact I use this
EFS2 file for storing work related things in it (so I can never share
it). I ran this program over the EFS2 file:
so it says that there is 652063 occurences where AES blocks were
duplicated, to me that's near 10 MB of material someone can use like the
above [1] where it says it could describe the data pattern.
It seems more likely you found the 652063 zero blocks that haven't been
written to yet.
Note that if you are concerned about people doing stat analysis on your
encrypted disk, you should be sure to overwrite the entirety of it. Either
with /dev/random on the outside, or /dev/zero on the inside, to ensure the
used and unused portions look the same.
That's good advice I'll try to fill up the space inside with a file and
see if the number of those blocks goes down. It isn't all zero blocks
but the majority of it could be.
Cheers,
-peter
