Re: [tpm2] tpm2-tss and /dev/urandom seed

* Re: [tpm2] tpm2-tss and /dev/urandom seed
@ 2018-10-26 12:20 Tomasz Przybysz
  0 siblings, 0 replies; 3+ messages in thread
From: Tomasz Przybysz @ 2018-10-26 12:20 UTC (permalink / raw)
  To: tpm2

[-- Attachment #1: Type: text/plain, Size: 3554 bytes --]

Resolved,

Using haveged daemon making entropy really fast.
/dev/urandom is ready in a few secs.

Tomasz Przybysz

W dniu 2018-10-25 o 15:48, Tomasz Przybysz pisze:
When I use --with-crypto=ossl switch during tpm2-tss compilation, tss doesn't use libgcrypt, it uses openssl.
In such case there it not such 120 secs delay. Instead there is about 7 secs delay before each sessions establishing, when openssl generates random data.

I need to add that we use ESAPI and encrypted session to communicate with TPM device.
Encrypted session needs random data.

I found that on the linux is the problem with drivers/char/random.c

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/char/random.c?h=v4.14.78&id=6e513bc20ca63f594632eca4e1968791240b8f18

random: fix crng_ready() test
commit 43838a23a05fbd13e47d750d3dfd77001536dd33 upstream. The crng_init variable has three states: 0: The CRNG is not initialized at all 1: The CRNG has a small amount of entropy, hopefully good enough for early-boot, non-cryptographical use cases 2: The CRNG is fully initialized and we are sure it is safe for cryptographic use cases. The crng_ready() function should only return true once we are in the last state. This addresses CVE-2018-1108.

https://access.redhat.com/security/cve/cve-2018-1108

Those changes causes that /dev/urandom is ready after 120 secs from system reboot.

Tomasz Przybysz

Hi,

I have found that there is a problem with tpm2-tss and /dev/urandom.
On our company embedded cpu board there is Infineon TPM-2.0 device and we want to have access to the TPM device immediately after board reboot.
As I found tpm2-tss library is based on libgcrypt library.

TSS2_RC iesys_cryptogcry_random2b(TPM2B_NONCE * nonce, size_t num_bytes)
{
    if (num_bytes == 0) {
        nonce->size = sizeof(TPMU_HA);
    } else {
        nonce->size = num_bytes;
    }
    /*
     * possible values for random level:
     *  GCRY_WEAK_RANDOM GCRY_STRONG_RANDOM  GCRY_VERY_STRONG_RANDOM
     */
    gcry_randomize(&nonce->buffer[0], nonce->size, GCRY_STRONG_RANDOM);
    return TSS2_RC_SUCCESS;
}

The problem is that with the new kernel Linux buildroot 4.14.74-xilinx
/dev/urandom seed is ready after 120 secs from system reboot.
It's not acceptable for us to wait such long to get TPM device ready.

I test it on Zynq cpu:
processor       : 0
model name      : ARMv7 Processor rev 0 (v7l)
BogoMIPS        : 666.66
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0

processor       : 1
model name      : ARMv7 Processor rev 0 (v7l)
BogoMIPS        : 666.66
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0

I think that there is no problem with cpu  performance.

I looked into kernel sources:
drivers/char/random.c
and it changed on april 2018

Previous it was:
#define crng_ready() (likely(crng_init > 0))

Now It's:
#define crng_ready() (likely(crng_init > 1))

 * crng_init =  0 --> Uninitialized
 *        1 --> Initialized
 *        2 --> Initialized from input_pool

Is it possible that random level of gcry_randomize in tss library could be configurable, not fixed ?
Please add such functionality, maybe it could be determined while compilation.

Thanks,
Tomasz Przybysz

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 6756 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread