Re: SOLVED: Force use of engine all the time
Frederick Gotham wrote: > I don't think any code other than "libcrypto.so" is using the TPM2, and so > I don't know why I'm getting "device or resource busy" (considering I'm > using a global named mutex)". I see that there's also a TPM2 tcti called > "abrmd", and I'm not sure if this purpose is exactly what it's for. I tweaked my global mutex a bit and now it's working fine.
SOLVED: Force use of engine all the time
I know I've called this "solved", but I've achieved my objective about 98%
so there's only a little bit left to go.
My changes to the source code for LibOpenSSL are confined to the file
"rand_lib.c".
Firstly, I've added the following code:
#include
#include
#include
static int Dummy__seed(const void *buf, int num) { (void)buf; (void)num;
return 1; }
static void Dummy__cleanup(void) { /* Do Nothing */ return; }
static int Dummy__add(const void *buf, int num, double randomness) {
(void)buf; (void)num; (void)randomness; return 1; }
static int Dummy__status(void) { /* Do Nothing */ return 1; }
static void Do_Whatever_Needs_Done_For_TPM2(void)
{
CRYPTO_THREAD_write_lock(rand_meth_lock);
CRYPTO_THREAD_write_lock(rand_engine_lock);
/* Initialize the dynamic engine loader */
ENGINE_load_dynamic();
ENGINE *tpm2_engine;
/* If the first fails, try the second one */
(tpm2_engine = ENGINE_by_id("tpm2tss")) || (tpm2_engine =
ENGINE_by_id("libtpm2tss"));
if ( NULL == tpm2_engine )
{
assert( 0 == "Do_Whatever_Needs_Done_For_TPM2: NULL ==
ENGINE_by_id" );
abort();
}
# define TPM2TSS_SET_TCTI (ENGINE_CMD_BASE + 1)
if ( 0 == ENGINE_ctrl(tpm2_engine, TPM2TSS_SET_TCTI, 0, "device",
NULL) )
{
assert( 0 == "Do_Whatever_Needs_Done_For_TPM2: 0 ==
ENGINE_ctrl(tcti:device)" );
abort();
}
int const init_res = ENGINE_init(tpm2_engine);
if ( 0 == init_res )
{
assert( 0 == "Do_Whatever_Needs_Done_For_TPM2: 0 ==
ENGINE_init" );
abort();
}
RAND_METHOD const *const p_rm = ENGINE_get_RAND(tpm2_engine);
if ( NULL == p_rm )
{
assert( 0 == "Do_Whatever_Needs_Done_For_TPM2: NULL ==
ENGINE_get_RAND" );
abort();
}
static RAND_METHOD funcptrs = {
Dummy__seed, /* seed() */
0, /*
bytes() */
Dummy__cleanup, /* cleanup() */
Dummy__add, /* add() */
0, /* pseudorand() */
Dummy__status /* status() */
};
funcptrs.bytes = p_rm->bytes; //rand_meth.bytes;
funcptrs.pseudorand = p_rm->bytes; //rand_meth.pseudorand;
funct_ref = tpm2_engine;
default_RAND_meth =
rand_meth = funcptrs; /* Even set the Drbg func pointers */
/* DON'T DO THIS - - - ENGINE_set_default(tpm2_engine,
ENGINE_METHOD_RAND); */
CRYPTO_THREAD_unlock(rand_meth_lock);
CRYPTO_THREAD_unlock(rand_engine_lock);
}
And then I add one line to the funciton "do_rand_init":
Do_Whatever_Needs_Done_For_TPM2();
So my device starts up just fine, and the first thing I notice is that it
takes a little longer to boot up (maybe because it takes a long longer to
get random numbers from hardware?).
So, when I do the following at the command line:
openssl rand -hex 128
It sometimes gives me back 128 bytes immediately, although sometimes it
gives this:
ERROR:tcti:src/tss2-tcti/tcti-device.c:319:Tss2_Tcti_Device_Init() Failed
to open device file /dev/tpm0: Device or resource busy
WARNING:esys:src/tss2-esys/esys_tcti_default.c:83:tcti_from_init() TCTI
init for function 0x7f6528b376f6 failed with a000a
WARNING:esys:src/tss2-esys/esys_tcti_default.c:113:tcti_from_info() Could
not initialize TCTI named: tcti-device
ERROR:esys:src/tss2-esys/esys_tcti_default.c:150:tcti_from_file() Could
not initialize TCTI file: libtss2-tcti-default.so
WARNING:esys:src/tss2-esys/esys_tcti_default.c:137:tcti_from_file() Could
not load TCTI file: libtss2-tcti-tabrmd.so
In order to try get around this problem of more than one thread (or
process) acessing /dev/tpm0 simultaneously, I added a global named mutex
to my code, and while it does improve things, it doesn't irradicate the
problem completely.
I don't think any code other than "libcrypto.so" is using the TPM2, and so
I don't know why I'm getting "device or resource busy" (considering I'm
using a global named mutex)". I see that there's also a TPM2 tcti called
"abrmd", and I'm not sure if this purpose is exactly what it's for.
Any ideas?
Re: Latest idea to force usage of custom engine
Frederick wrote: > > CRYPTO_THREAD_write_lock(rand_meth_lock); > CRYPTO_THREAD_write_lock(rand_engine_lock); This is what's causing the segfault in libpthread.so I can only imagine that the same thread is trying to re-lock a single-lock mutex. So my code should be something like: int already_locked_meth = is_already_locked(rand_meth_lock); int already_locked_engine = is_already_locked(rand_engine_lock); if (!already_locked_meth) CRYPTO_THREAD_write_lock(rand_meth_lock); if (!already_locked_engine) CRYPTO_THREAD_write_lock(rand_engine_lock); /* DO STUFF */ if (!already_locked_meth) CRYPTO_THREAD_unlock(rand_meth_lock); if (!already_locked_engine) CRYPTO_THREAD_unlock(rand_engine_lock);
Re: Latest idea to force usage of custom engine
> I'm going to keep at this until every process (including ssh-keygen) is
> using my custom engine for random numbers.
Now every process that links with 'libcrypto.so' is segfaulting in
libpthread-2.28.so. Here's the error:
openssl[1744]: segfault at 18 ip 7f1798d44930 sp 7ffcf46bb1b8
error 4 in libpthread-2.28.so[7f1798d38000+1a000]
Here's the totality of the changes I've made. . . I added the following to
"rand_lib.c":
/* === The fields in RAND_METHOD ==
int (*seed) (const void *buf, int num);
int (*bytes) (unsigned char *buf, int num);
void (*cleanup) (void);
int (*add) (const void *buf, int num, double randomness);
int (*pseudorand) (unsigned char *buf, int num);
int (*status) (void);
*/
#include
static int Supplemented_seed(const void *buf, int num) { (void)buf; (void)
num; return 1; }
static void Supplemented_cleanup(void) { /* Do Nothing */ return; }
static int Supplemented_add(const void *buf, int num, double randomness)
{ (void)buf; (void)num; (void)randomness; return 1; }
static int Supplemented_status(void) { /* Do Nothing */ return 1; }
static CRYPTO_ONCE crypto_once_tpm2_init = CRYPTO_ONCE_STATIC_INIT;
DEFINE_RUN_ONCE_STATIC(Do_Whatever_Needs_Done_For_TPM2)
{
/* Initialize the dynamic engine loader */
ENGINE_load_dynamic();
ENGINE *tpm2_engine;
/* If the first fails, try the second one */
(tpm2_engine = ENGINE_by_id("tpm2tss")) || (tpm2_engine =
ENGINE_by_id("libtpm2tss"));
if ( NULL == tpm2_engine )
{
assert( 0 == "Do_Whatever_Needs_Done_For_TPM2: NULL == tpm2
_engine" );
abort();
}
int const init_res = ENGINE_init(tpm2_engine);
if ( 0 == init_res )
{
assert( 0 == "Do_Whatever_Needs_Done_For_TPM2: 0 ==
init_res" );
abort();
}
RAND_METHOD const *const p_rm = ENGINE_get_RAND(tpm2_engine);
if ( NULL == p_rm )
{
assert( 0 == "Do_Whatever_Needs_Done_For_TPM2: NULL ==
p_rm" );
abort();
}
static RAND_METHOD funcptrs = {
Supplemented_seed, /* seed() */
0, /*
bytes() */
Supplemented_cleanup, /* cleanup() */
Supplemented_add, /* add() */
0, /* pseudorand() */
Supplemented_status /* status() */
};
CRYPTO_THREAD_write_lock(rand_meth_lock);
funcptrs.bytes = p_rm->bytes;
funcptrs.pseudorand = p_rm->pseudorand;
funct_ref = tpm2_engine;
default_RAND_meth =
rand_meth = funcptrs; /* Even set the Drbg func pointers */
CRYPTO_THREAD_unlock(rand_meth_lock);
return 0;
}
const RAND_METHOD *RAND_get_rand_method(void)
{
RUN_ONCE(_once_tpm2_init, Do_Whatever_Needs_Done_For_TPM2);
Re: ssh-keygen freezes if you force use of engine
Jordan Brown wrote: > Note that __pthread_once_slow is in the stack twice, called from > OPENSSL_init_crypto and CRYPTO_THREAD_run_once. > > "once" functions ensure that they call their function argument exactly > once, even if they are called multiple times in parallel while their > function is running. They do that by locking a mutex around the > execution of the function. The second call attempted to lock the mutex > to wait for the first call to complete, and deadlocked. I still don't know what to do about this. For them moment I'm continuing with my idea in the thread "Latest idea to force usage of custom engine".
Latest idea to force usage of custom engine
I have abandoned my old idea of trying to get libOpenSSL to always read my
engine info from the config file (/etc/ssl/openssl.cnf).
Instead I'm going to try to manually load my own engine in the source code
for libOpenSSL.
I have created a new function in "rand_lib.c" as follows:
static void Do_Whatever_Needs_Done_For_TPM2(void)
{
CRYPTO_THREAD_write_lock(rand_meth_lock);
{
/* Initialize the dynamic engine loader */
ENGINE_load_dynamic();
ENGINE *tpm2_engine;
/* If the first fails, try the second one */
(tpm2_engine = ENGINE_by_id("tpm2tss")) || (tpm2_engine =
ENGINE_by_id("libtpm2tss"));
if ( NULL == tpm2_engine )
{
assert( 0 == "Do_Whatever_Needs_Done_For_TPM2: tpm2
_engine == NULL" );
abort();
}
int init_res = ENGINE_init(tpm2_engine);
if ( !init_res )
{
assert( 0 == "Do_Whatever_Needs_Done_For_TPM2: init_res
== 0" );
abort();
}
RAND_METHOD const *const p_rm = ENGINE_get_RAND(tpm2_engine);
if ( NULL == p_rm )
{
assert( 0 == "Do_Whatever_Needs_Done_For_TPM2: p_rm ==
NULL" );
abort();
}
funct_ref = tpm2_engine;
default_RAND_meth = p_rm;
rand_meth = *default_RAND_meth; /* Even set the Drbg func
pointers */
}
CRYPTO_THREAD_unlock(rand_meth_lock);
}
And then the next thing I've done is added the following code to the start
of "RAND_get_rand_method":
const RAND_METHOD *RAND_get_rand_method(void)
{
static int first_time_for_entire_process = 1;
if ( first_time_for_entire_process )
{
first_time_for_entire_process = 0;
Do_Whatever_Needs_Done_For_TPM2();
}
/* The rest of the function goes here */
}
I'm testing it now but it still seems that something isn't right.
I'm going to keep at this until every process (including ssh-keygen) is
using my custom engine for random numbers.
Re: ssh-keygen freezes if you force use of engine
> My temporary solution is to link "ssh-keygen" statically with a normal > version of "libcrypto.a", and then have every other program link > dynamically with my altered version of "libcrypto.so". > > I'll at least see if that works. Yeah the problem is **definitely** that the function "OPENSSL_init_crypto" is calling itself recursively. I might have to put in a thread-duration variable to keep track of the stack depth, and only tell it to load the config file on the first call. I also tried playing around with OPENSSL_SSL_CLIENT_ENGINE_AUTO at compile time, but I can't seem to get it to work. Here's my latest stack trace when I link statically with libcrypto.a: OPENSSL_init_crypto, with the following backtrace: == FUNCTION CALL STACK BACKTRACE == /usr/lib/libcrypto.so.1.1(OPENSSL_init_crypto+0xb3) [0x7fce24d6ca6a] /usr/lib/libcrypto.so.1.1(+0x143126) [0x7fce24d6a126] /lib/libpthread.so.0(+0xf407) [0x7fce2460c407] /usr/lib/libcrypto.so.1.1(CRYPTO_THREAD_run_once+0x9) [0x7fce24dc7fbe] /usr/lib/libcrypto.so.1.1(+0x14317c) [0x7fce24d6a17c] /usr/lib/libcrypto.so.1.1(CRYPTO_new_ex_data+0x1b) [0x7fce24d6a4d3] /usr/lib/libcrypto.so.1.1(BIO_new+0x73) [0x7fce24cc8d37] /usr/lib/libcrypto.so.1.1(BIO_new_fp+0x16) [0x7fce24ccca06] openssl() [0x41fe6e] /lib/libc.so.6(__libc_start_main+0xe7) [0x7fce2426ae77] openssl() [0x42019a] === OPENSSL_init_crypto, with the following backtrace: == FUNCTION CALL STACK BACKTRACE == /usr/lib/libcrypto.so.1.1(OPENSSL_init_crypto+0xb3) [0x7fce24d6ca6a] /usr/lib/libcrypto.so.1.1(+0xd163b) [0x7fce24cf863b] /usr/lib/libcrypto.so.1.1(+0x1456cf) [0x7fce24d6c6cf] /lib/libpthread.so.0(+0xf407) [0x7fce2460c407] /usr/lib/libcrypto.so.1.1(CRYPTO_THREAD_run_once+0x9) [0x7fce24dc7fbe] /usr/lib/libcrypto.so.1.1(OPENSSL_init_crypto+0x2c9) [0x7fce24d6cc80] /usr/lib/libcrypto.so.1.1(+0x143126) [0x7fce24d6a126] /lib/libpthread.so.0(+0xf407) [0x7fce2460c407] /usr/lib/libcrypto.so.1.1(CRYPTO_THREAD_run_once+0x9) [0x7fce24dc7fbe] /usr/lib/libcrypto.so.1.1(+0x14317c) [0x7fce24d6a17c] /usr/lib/libcrypto.so.1.1(CRYPTO_new_ex_data+0x1b) [0x7fce24d6a4d3] /usr/lib/libcrypto.so.1.1(BIO_new+0x73) [0x7fce24cc8d37] /usr/lib/libcrypto.so.1.1(BIO_new_fp+0x16) [0x7fce24ccca06] openssl() [0x41fe6e] /lib/libc.so.6(__libc_start_main+0xe7) [0x7fce2426ae77] openssl() [0x42019a]
Re: ssh-keygen freezes if you force use of engine
Dmitry Belyavsky wrote in news:CADqLbz+6WbCpday_1Gq-Zmst1y-17Hbc1S9OvYtE4=b=njp...@mail.gmail.com: > Could you please reproduce this behavior without your patches? > > On Wed, Nov 6, 2019 at 2:04 PM Frederick Gotham > wrote: > >> >> >> > I used GDB on the core file and saw the following backtrace: >> >> >> I think I'm actually getting a stack overflow from "openssl_config_int" >> calling "OPENSSL_init_crypto" because of the recursion. >> >> > My temporary solution is to link "ssh-keygen" statically with a normal version of "libcrypto.a", and then have every other program link dynamically with my altered version of "libcrypto.so". I'll at least see if that works.
Re: ssh-keygen freezes if you force use of engine
> I used GDB on the core file and saw the following backtrace: I think I'm actually getting a stack overflow from "openssl_config_int" calling "OPENSSL_init_crypto" because of the recursion.
ssh-keygen freezes if you force use of engine
I have edited the source code for OpenSSL in the init functions so that the config file always gets loaded. My config file specifies a custom engine, so this means that every process that links with "libssl.so" or "libcrypto.so" will use my custom engine. The problem I'm having is that my device won't boot up. It gets as far as running "ssh-keygen" and then it freezes. In order to troubleshoot this, I recompiled "ssh-keygen" with the flag "- rdynamic" so that I can see function names in a stack trace. Next I enabled core dumps with "ulimit -c unlimited". Then I ran "ssh-keygen", and it froze as expected, but this time I pressed "Ctrl + \", and so it produced a core dump file. I used GDB on the core file and saw the following backtrace: Core was generated by `/home/service/ssh-keygen'. Program terminated with signal SIGQUIT, Quit. #0 0x7f656e35e3c7 in __pthread_once_slow () from /lib/libpthread.so.0 (gdb) bt #0 0x7f656e35e3c7 in __pthread_once_slow () from /lib/libpthread.so.0 #1 0x7f656f730fbe in CRYPTO_THREAD_run_once () from ./libcrypto.so.1.1 #2 0x7f656f6d5c80 in OPENSSL_init_crypto () from ./libcrypto.so.1.1 #3 0x7f656f66163b in openssl_config_int () from ./libcrypto.so.1.1 #4 0x7f656f6d56cf in ossl_init_config_ossl_ () from ./libcrypto.so.1.1 #5 0x7f656e35e407 in __pthread_once_slow () from /lib/libpthread.so.0 #6 0x7f656f730fbe in CRYPTO_THREAD_run_once () from ./libcrypto.so.1.1 #7 0x7f656f6d5c80 in OPENSSL_init_crypto () from ./libcrypto.so.1.1 #8 0x55a8d125708b in main () Can anyone see what might be going on here?
Re: Force the use of engine in config file
> Okay first I'll show the changes that I've made to the source code and > build setup for "libopenssl". I added one more change, I added to the beginning of the function "OPENSSL_init_crypto" these two lines: opts &= ~(uint64_t)OPENSSL_INIT_NO_LOAD_CONFIG; opts |= OPENSSL_INIT_LOAD_CONFIG; I think that this might finally have made **every** process load the libssl.so library and use the engine I specify. Unfortunately though, when my device boots up, it doesn't get past this point: random: crng init done random: 7 urandom warning(s) missed due to ratelimiting It freezes at that point. . . I don't know what it's doing (if anything) in the background. The machine isn't **totally** frozen though, because when I plug in a USB stick, I get: usb 1-6: new high-speed USB device number 6 using xhci_hcd
Re: Force the use of engine in config file
Okay first I'll show the changes that I've made to the source code and
build setup for "libopenssl".
I have added two compiler flags: OPENSSL_NO_RDRAND, OPENSSL_LOAD_CONFIG
Not that the following compiler flag is NOT set:
OPENSSL_NO_AUTOLOAD_CONFIG
And here are the source code changes:
(1) File: ssl_init.c
Purpose of Alteration: Clear the option flag bit for not loadind conf
Alteration: In the function "OPENSSL_init_ssl", insert the following
line at the beginning of the function:
opts &= ~(uint64_t)OPENSSL_INIT_NO_LOAD_CONFIG; /* Clear the bit for
not loading TPM2 engine */
(2) File: drbg_lib.c
Purpose of Alteration: Make a log of all uses of the built-in
generator
Alteration: Rename the function definition "drbg_bytes" to
"drbg_bytes_REAL", and then append the following to the end of the file:
#include
static int drbg_bytes(unsigned char *out, int count)
{
int const retval = drbg_bytes_REAL(out, count); /* I renamed the
real function */
int const fd_lock = open("/tmp/locker_for_randomness_log", O_CREAT);
flock(fd_lock, LOCK_EX);
{
FILE *const pfile = fopen("/var/log/bad_randomness.log", "a");
if ( NULL != pfile )
{
time_t ltime;
struct tm result;
char stime[32];
ltime = time(NULL);
localtime_r(, );
asctime_r(, stime);
stime[ strlen(stime) - 1 ] = ' '; /* Get rid of
newline
char at the end */
fprintf(pfile, "%s - - - %u bytes\n", stime, (unsigned)
count);
fclose(pfile);
}
}
flock(fd_lock, LOCK_UN);
return retval;
}
I have reconfigured and rebuilt "libopenssl", and so I boot up my device
and then I run the following command:
tail -F /var/log/bad_randomness.log
This file shouldn't exist if the built-in generator is never used -- but
some how, some way, even with all the changes I've made above, at least
one of the running processes that links with "libssl.so" is NOT using the
engine I specify in the config file "/etc/ssl/openssl.cnf". Looking at the
output from the 'tail' command above, it's requesting 16 bytes of random
data every 6 seconds. Here's the repeated line:
Mon Nov 04 12:41:06 2019 - - - 16 bytes
Here's how I get a list of all the procesess currently using "libssl.so":
grep libssl /proc/*/maps | cut -d ':' -f 1 | cut -d '/' -f 3 | uniq |
xargs -n1 -i ls -l /proc/{}/exe
And there's the output I'm getting:
lrwxrwxrwx1 root root 0 Feb 16 02:54 /proc/1622/exe ->
/usr/sbin/lighttpd
lrwxrwxrwx1 root root 0 Feb 16 02:54 /proc/1681/exe ->
/opt/prodanko/bin/callar_plugin
So this means that one of these two progams is some how managing to load
up the 'libopenssl' library and get it to use its internal random number
generator. I wonder if this is being achieved with explicit library calls
to functions such as "OPENSSL_add_all_algorithms_noconf"?
I suppose I could also add a stack trace to my log file to try figure out
which process is requesting those 16 bytes every 6 seconds.
And idead on what to try next?
Re: Force the use of engine in config file
Since I already have a well-formed config file, I think it would be a minimalistic change to hijack the "OPENSSL_noconfig" function (instead of changing the code for Init). But your idea could work too. Even if I do implement your idea though, I will still remove the random number generation routines in drbg_lib.c, as there should not be any software psudeorandomness generator on my embedded device. On Saturday, November 2, 2019, Salz, Rich wrote: > If you are changing openssl, why not just change the init function to load > your engine and abort/exit/fail if it doesn’t load? > > >
Force the use of engine in config file
>> int OPENSSL_config(void)
>> {
>> return OPENSSL_config();
>> }
That first line should be:
int OPENSSL_noconfig(void)
Force the use of engine in config file
I have a config file, "/etc/ssl/openssl.cnf". This config file gives the
details of an engine to use for random number generation. I know that this
config file is well-formed because I have confirmed that it uses my engine
when I try to use the "openssl" utility at the command line to generate a
random number.
I have been able to determine though that some other programs which link
with "libssl.so" are NOT using my engine.
Since I already know that my
config file is well-formed, I can only conclude that these other programs
are initialising the OpenSSL library as follows:
OPENSSL_noconfig();
So in order to make sure that every program that links with "libssl.so"
actually uses my engine, I think I need to go into the OpenSSL source code and
replace the OPENSSL_noconfig function like this:
int OPENSSL_config(void)
{
return OPENSSL_config();
}
Can anyone think of any other ideas to ensure that "libssl.so" always uses
the engine specified in the config file?
Re: Remove All Software Generators
Frederick Gotham wrote:
> static int drbg_bytes(unsigned char *out, int count)
> {
> int const retval = drbg_bytes_REAL(out, count);
>
> /* Try to get a semi-unique value for the first byte */
> char unsigned rotating_value = (unsigned)out ^ ((unsigned)count <<
> 4u);
>
> while ( count-- )
> *out++ = rotating_value++;
>
> return retval;
> }
Ugh This doesn't work either. It fails to boot up when it tries to
generate keys for SSH.
Next I'll try to make every nibble sequential -- instead of just every byte.
Re: Remove All Software Generators
Frederick Gotham wrote:
>
> I will change the random number generator built into OpenSSL to always
> return sequential numbers, something like:
Here's what I have:
static int drbg_bytes(unsigned char *out, int count)
{
int const retval = drbg_bytes_REAL(out, count);
/* Try to get a semi-unique value for the first byte */
char unsigned rotating_value = (unsigned)out ^ ((unsigned)count <<
4u);
while ( count-- )
*out++ = rotating_value++;
return retval;
}
Re: Remove All Software Generators
Frederick Gotham
wrote:
>
> And anyway this behaviour didn't come from deleting /dev/random, but
> rather from making the default generator inside OpenSSL always give 0
> for a random byte.
I will change the random number generator built into OpenSSL to always
return sequential numbers, something like:
{
static char unsigned val = 0;
while ( num-- )
*buff++ = val++;
}
This shouldn't break anything.
Then if ever I am in doubt about where a random number came from, I just
check to see if it's something like 0102030405.
Re: Remove All Software Generators
Frederick Gotham wrote in news:XnsAAF8BACC24C3Bfgotham@195.159.176.226: > Jochen Bern > wrote: > >> SSH logins from remote that fail > > > This is my exact problem right now. My device has booted up and I > can't SSH into it.But this doesn't entirely make sense since it should > be getting random numbers from the TPM2 chip anyway. And anyway this behaviour didn't come from deleting /dev/random, but rather from making the default generator inside OpenSSL always give 0 for a random byte.
Re: Remove All Software Generators
Jochen Bern wrote: > SSH logins from remote that fail This is my exact problem right now. My device has booted up and I can't SSH into it.But this doesn't entirely make sense since it should be getting random numbers from the TPM2 chip anyway.
Re: Remove All Software Generators
Dmitry Belyavsky wrote: > You should do in your engine the following: Just so you know, I'm not a developer of the TPM2 engine for OpenSSL. Of course though I can still go in and edit the code here and there. > Implement the TPM-provided RAND_METHOD in the engine > call ENGINE_set_RAND for RAND method in the engine bind fuction > > and write a config file similar to > Even if I do all that, there is still the possibility that OpenSSL might use its built-in generator (for example if my library fails to load). So it seems I must get the built-in generator to either: 1) Always return 0 2) Call 'abort'
Re: Remove All Software Generators
Dmitry Belyavsky wrote
in
news:cadqlbz+jctu_yqiw9w-fyo0o56mqua2nri6helr6pggxqdh...@mail.gmail.com:
> On Wed, Oct 30, 2019 at 6:39 PM Frederick Gotham
> wrote:
>
>> Dmitry Belyavsky
>> wrote:
>>
>> >> You still have the OpenSSL built-in RNG.
>>
>>
>>
>> Is there a simple compiler flag to remove this?
>>
>> Or do I need to go into the source code and stick a "return -1;"
>> somewhere?
>>
>> No. Openssl will not work if you do not provide a valid RAND_METHOD
>> except
> a very minimal set of operations.
>
So I have to go into the source code and do the following?
int RAND_bytes(unsigned char *buf, int num)
{
memset(buf,0,num);
return 1;
}
I can either make this function fail (e.g. call 'abort'), or I can always
make it return 0.
What do you think?
Re: Remove All Software Generators
Dmitry Belyavsky wrote: >> You still have the OpenSSL built-in RNG. Is there a simple compiler flag to remove this? Or do I need to go into the source code and stick a "return -1;" somewhere?
Re: Remove All Software Generators
Dmitry Belyavsky wrote >> /etc/ssl/openssl.cnf > > Yes, or any custom. > But the engine must provide the RAND_METHOD and set it as default. > > But if my TPM2 engine fails to load, then OpenSSL will just use the 'rdrand' engine. So my defense agains this is to rebuild OpenSSL with the flag OPENSSL_NO_RDRAND. After I rebuild OpenSSL, I can then remove my TPM2 engine so that there's no engine at all. I tried running OpenSSL at my commandline just now, and here's what I got: ~# openssl OpenSSL> engine (dynamic) Dynamic engine loading support OpenSSL> rand -hex 10 f49ca711e3056cf9064a OpenSSL> Where is it it getting that random data from ? ? ? There's no engine and yet it can still get a random number! I even tried deleting /dev/random and /dev/urandom, but it somehow is still getting random data from somewhere! But where?
Re: Remove All Software Generators
Dmitry Belyavsky wrote: >> It can be done via the engine code and config. Do you mean /etc/ssl/openssl.cnf ?
Re: Remove All Software Generators
Dmitry Belyavsky wrote: > Did you try to create your own RAND_METHOD and set it as default on > loading the engine? No, I didn't try that. Note that I'm only using the OpenSSL binary, I'm not interfacing with an API.
Remove All Software Generators
I'm working on Linux with a x86-64 CPU. I have a TPM2 chip, and so I want OpenSSL to do all of its encryption and random number generation through the TPM2 chip. In the event that the chip fails, I do NOT want there to be a backup system. I do NOT want any kind of software psuedorandom number generator nor any software encryption routines. The engine that I'm using for OpenSSL is "libtpm2tss.so". This engine library requires two more libraries, "libtss2-tcti-device.so" and "libtss2-tcti-mssim.so". (The former is for using the TPM2 chip, whereas the latter is a software simulator). As I don't want to have a simulator, I tried simply deleting the simulator library, but this caused linkage problems for the mother engine library. As an alternative, I made a new dummy library in which all of the functions return an error value, and I put this dummy library in the place of the simulator. This transplant went fine. It appears that OpenSSL will kick and scream and refuse to die not matter how hard you hit it. If I try to generate a random number like this: openssl rand -hex 8 Then it seems it will try in this order: 1) The TPM2 chip 2) The software simulator of the TPM2 chip 3) The built-in RDRAND number 4) Another one that I can't find I have recompiled OpenSSL with the flag OPENSSL_NO_RDRAND to get rid of the in-built engine. I have even done "rm /dev/random" and "rm /dev/urandom", but SOME HOW, SOME WAY, I'm still getting output when I run openssl rand -hex 8. How on earth to get OpenSSL to simply give up? I simply cannot have it use anything other than my TPM2 chip. Frederick
