"
No. For following reason. Originally idea was to attempt to gather "OS
noise". I mean entropy would come from interrupts, interaction with say
DMA, etc. Therefore no explicit attempts to perform the experiment
"outside" OS were made. Besides it would be impossible for me to set it
up in most cases (because normally access is remote non-privileged). But
having observed it in OS-free environment made me wonder...
"
I think you underestimate the contribution that OS noise makes to security.
Even if the 'entropy' we are seeing really is just a hardware PRNG, at
least it's a free running one. i.e. it's generating new samples
continuously and we get a sample from a continuous stream when we read that
PRNG. (We don't just get the next sample in a sequence as we would reading
a software PRNG).
So those minor disturbances have a significant effect on the data we
actually collect becasue they perturb the timing of the sampling. Someone
trying to predict the output of our RNG has to be able to either sample at
exactly the same times as us (down to timer resolution) or know the
hardware PRNG sequence and predict when we sampled it (again, down to timer
resolution) - quite a hard thing to do even from from another process on
the same machine. It's not like attacking a software PRNG where once you
know where you are now, you can predict the future output.
Again, that's why I'm happier about the security of this approach on a
multi-user system than on a single user embedded system where there's no
additional timing perturbation. But provided you can show you don't get
repeated sequences at boot, it's at least as good as anything else you have
even in those scenarios.
Peter
From: Andy Polyakov <ap...@openssl.org>
To: openssl-dev@openssl.org
Date: 18/01/2012 18:19
Subject: Re: OS-independent entropy source?
Sent by: owner-openssl-...@openssl.org
>> Come on, having me preparing bootable CF card image for a gizmo I'm not
>> familiar with is unrealistic. Don't you have anything you can compile
>> 10-lines C code and some assembler to add to?
>
> Well you mentioned tests on x86 in your paper, I thought you
> do have some minimal test setup ready for it.
No. For following reason. Originally idea was to attempt to gather "OS
noise". I mean entropy would come from interrupts, interaction with say
DMA, etc. Therefore no explicit attempts to perform the experiment
"outside" OS were made. Besides it would be impossible for me to set it
up in most cases (because normally access is remote non-privileged). But
having observed it in OS-free environment made me wonder...
> No problem to compile
> something here, I just do not want to run it under an operating
> system that sets the hardware who knows how (disabling
> ints is not enough if something is trying to do a DMA
> or something).
Arguably OS only adds entropy, and it appears to be rather little on
idle system. So just running it under low load is good enough.
>> "but ARM" might be too "weak" requirement. OPENSSL_instrument_bus is
>> dependent on presence of clflush instruction which is normally available
>> with SSE2. Does your Geode support it? It's exposed in /proc/cpuinfo
>> under Linux. And of course rdtsc.
>
> Yes, the processor does have tsc and clflush.
>
> FWIW on the ARMs I have I am able to manipulate/disable cache
> (on some there is no cache) and to read a counter ticking
> synchronously with the processor clock.
I know that newer ARM even allows you to make tick counter accessible to
user-land and there is even a way to flush cache line, but it's all
privileged operations and I work under assumption that code runs in
user-land. Therefore OPENSSL_instrument_bus is reduced to return 0; on ARM.
> What data do you need? OPENSSL_instrument_bus with 128k probes
> taken?
Yes, as simple as
#include <stdio.h>
#define N (128*1024)
main()
{ int i,n;
static int arr[N];
memset(arr,0,sizeof(arr));
n=OPENSSL_instrument_bus(arr,N);
for (i=0;i<n;i++)
printf("%d\n",arr[i]);
}
would do. I also collect for n=OPENSSL_instrument_bus2(arr,N,0);...
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
