30 Nov, 2016

1 commit

  • When using SGs, only heap memory (memory that is valid as per
    virt_addr_valid) is allowed to be referenced. The CTR DRBG used to
    reference the caller-provided memory directly in an SG. In case the
    caller provided stack memory pointers, the SG mapping is not considered
    to be valid. In some cases, this would even cause a paging fault.

    The change adds a new scratch buffer that is used unconditionally to
    catch the cases where the caller-provided buffer is not suitable for
    use in an SG. The crypto operation of the CTR DRBG produces its output
    with that scratch buffer and finally copies the content of the
    scratch buffer to the caller's buffer.

    The scratch buffer is allocated during allocation time of the CTR DRBG
    as its access is protected with the DRBG mutex.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

24 Aug, 2016

1 commit


16 Aug, 2016

1 commit

  • When calling the DRBG health test in FIPS mode, the Jitter RNG is not
    yet present in the kernel crypto API which will cause the instantiation
    to fail and thus the health test to fail.

    As the health tests cover the enforcement of various thresholds, invoke
    the functions that are supposed to enforce the thresholds directly.

    This patch also saves precious seed.

    Reported-by: Tapas Sarangi
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

20 Jun, 2016

2 commits


15 Jun, 2016

4 commits

  • The TFM object maintains the key for the CTR DRBG.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The CTR DRBG update function performs a full CTR AES operation including
    the XOR with "plaintext" data. Hence, remove the XOR from the code and
    use the CTR mode to do the XOR.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • Hardware cipher implementation may require aligned buffers. All buffers
    that potentially are processed with a cipher are now aligned.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The CTR DRBG derives its random data from the CTR that is encrypted with
    AES.

    This patch now changes the CTR DRBG implementation such that the
    CTR AES mode is employed. This allows the use of steamlined CTR AES
    implementation such as ctr-aes-aesni.

    Unfortunately there are the following subtile changes we need to apply
    when using the CTR AES mode:

    - the CTR mode increments the counter after the cipher operation, but
    the CTR DRBG requires the increment before the cipher op. Hence, the
    crypto_inc is applied to the counter (drbg->V) once it is
    recalculated.

    - the CTR mode wants to encrypt data, but the CTR DRBG is interested in
    the encrypted counter only. The full CTR mode is the XOR of the
    encrypted counter with the plaintext data. To access the encrypted
    counter, the patch uses a NULL data vector as plaintext to be
    "encrypted".

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

02 Jun, 2016

1 commit

  • The CTR DRBG code always set the key for each sym cipher invocation even
    though the key has not been changed.

    The patch ensures that the setkey is only invoked when a new key is
    generated by the DRBG.

    With this patch, the CTR DRBG performance increases by more than 150%.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

05 Apr, 2016

1 commit

  • The HMAC implementation allows setting the HMAC key independently from
    the hashing operation. Therefore, the key only needs to be set when a
    new key is generated.

    This patch increases the speed of the HMAC DRBG by at least 35% depending
    on the use case.

    The patch is fully CAVS tested.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

25 Jan, 2016

1 commit


10 Dec, 2015

1 commit


11 Jun, 2015

1 commit


10 Jun, 2015

2 commits

  • As required by SP800-90A, the DRBG implements are reseeding threshold.
    This threshold is at 2**48 (64 bit) and 2**32 bit (32 bit) as
    implemented in drbg_max_requests.

    With the recently introduced changes, the DRBG is now always used as a
    stdrng which is initialized very early in the boot cycle. To ensure that
    sufficient entropy is present, the Jitter RNG is added to even provide
    entropy at early boot time.

    However, the 2nd seed source, the nonblocking pool, is usually
    degraded at that time. Therefore, the DRBG is seeded with the Jitter RNG
    (which I believe contains good entropy, which however is questioned by
    others) and is seeded with a degradded nonblocking pool. This seed is
    now used for quasi the lifetime of the system (2**48 requests is a lot).

    The patch now changes the reseed threshold as follows: up until the time
    the DRBG obtains a seed from a fully iniitialized nonblocking pool, the
    reseeding threshold is lowered such that the DRBG is forced to reseed
    itself resonably often. Once it obtains the seed from a fully
    initialized nonblocking pool, the reseed threshold is set to the value
    required by SP800-90A.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The get_blocking_random_bytes API is broken because the wait can
    be arbitrarily long (potentially forever) so there is no safe way
    of calling it from within the kernel.

    This patch replaces it with the new callback API which does not
    have this problem.

    The patch also removes the entropy buffer registered with the DRBG
    handle in favor of stack variables to hold the seed data.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

04 Jun, 2015

1 commit


27 May, 2015

3 commits

  • During initialization, the DRBG now tries to allocate a handle of the
    Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
    pulls the required entropy/nonce string from get_random_bytes and
    concatenates it with a string of equal size from the Jitter RNG. That
    combined string is now the seed for the DRBG.

    Written differently, the initial seed of the DRBG is now:

    get_random_bytes(entropy/nonce) || jitterentropy (entropy/nonce)

    If the Jitter RNG is not available, the DRBG only seeds from
    get_random_bytes.

    CC: Andreas Steffen
    CC: Theodore Ts'o
    CC: Sandy Harris
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The async seeding operation is triggered during initalization right
    after the first non-blocking seeding is completed. As required by the
    asynchronous operation of random.c, a callback function is provided that
    is triggered by random.c once entropy is available. That callback
    function performs the actual seeding of the DRBG.

    CC: Andreas Steffen
    CC: Theodore Ts'o
    CC: Sandy Harris
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • In order to prepare for the addition of the asynchronous seeding call,
    the invocation of seeding the DRBG is moved out into a helper function.

    In addition, a block of memory is allocated during initialization time
    that will be used as a scratchpad for obtaining entropy. That scratchpad
    is used for the initial seeding operation as well as by the
    asynchronous seeding call. The memory must be zeroized every time the
    DRBG seeding call succeeds to avoid entropy data lingering in memory.

    CC: Andreas Steffen
    CC: Theodore Ts'o
    CC: Sandy Harris
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

23 Apr, 2015

1 commit


22 Apr, 2015

1 commit


21 Apr, 2015

6 commits

  • Initialising the RNG in drbg_kcapi_init is a waste of precious
    entropy because all users will immediately seed the RNG after
    the allocation.

    In fact, all users should seed the RNG before using it. So there
    is no point in doing the seeding in drbg_kcapi_init.

    This patch removes the initial seeding and the user must seed
    the RNG explicitly (as they all currently do).

    This patch also changes drbg_kcapi_reset to allow reseeding.
    That is, if you call it after a successful initial seeding, then
    it will not reset the internal state of the DRBG before mixing
    the new input and entropy.

    If you still wish to reset the internal state, you can always
    free the DRBG and allocate a new one.

    Finally this patch removes locking from drbg_uninstantiate because
    it's now only called from the destruction path which must not be
    executed in parallel with normal operations.

    Signed-off-by: Herbert Xu
    Acked-by: Stephan Mueller

    Herbert Xu
     
  • As we moved the mutex init out of drbg_instantiate and into cra_init
    we need to explicitly initialise the mutex in drbg_healthcheck_sanity.

    Signed-off-by: Herbert Xu
    Acked-by: Stephan Mueller

    Herbert Xu
     
  • As the DRBG does not operate on shadow copies of the DRBG instance
    any more, the cipher handles only need to be allocated once during
    initalization time and deallocated during uninstantiate time.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The creation of a shadow copy is intended to only hold a short term
    lock. But the drawback is that parallel users have a very similar DRBG
    state which only differs by a high-resolution time stamp.

    The DRBG will now hold a long term lock. Therefore, the lock is changed
    to a mutex which implies that the DRBG can only be used in process
    context.

    The lock now guards the instantiation as well as the entire DRBG
    generation operation. Therefore, multiple callers are fully serialized
    when generating a random number.

    As the locking is changed to use a long-term lock to avoid such similar
    DRBG states, the entire creation and maintenance of a shadow copy can be
    removed.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The drbg_generate returns 0 in success case. That means that
    drbg_generate_long will always only generate drbg_max_request_bytes at
    most. Longer requests will be truncated to drbg_max_request_bytes.

    Reported-by: Herbert Xu
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The buffer uses for temporary data must be cleared entirely. In AES192
    the used buffer is drbg_statelen(drbg) + drbg_blocklen(drbg) as
    documented in the comment above drbg_ctr_df.

    This patch ensures that the temp buffer is completely wiped.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

09 Mar, 2015

1 commit

  • Change the RNGs to always return 0 in success case.

    This patch ensures that seqiv.c works with RNGs other than krng. seqiv
    expects that any return code other than 0 is an error. Without the
    patch, rfc4106(gcm(aes)) will not work when using a DRBG or an ANSI
    X9.31 RNG.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

04 Mar, 2015

2 commits

  • The DRBG code contains memset(0) calls to initialize a varaible
    that are not necessary as the variable is always overwritten by
    the processing.

    This patch increases the CTR and Hash DRBGs by about 5%.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     
  • The CTR DRBG only encrypts one single block at a time. Thus, use the
    single block crypto API to avoid additional overhead from the block
    chaining modes.

    With the patch, the speed of the DRBG increases between 30% and 40%.

    The DRBG still passes the CTR DRBG CAVS test.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

05 Jan, 2015

1 commit


22 Dec, 2014

1 commit

  • This patch adds a panic if the FIPS 140-2 self test error failed.
    Note, that entire code is only executed with fips_enabled (i.e. when the
    kernel is booted with fips=1. It is therefore not executed for 99.9% of
    all user base.

    As mathematically such failure cannot occur, this panic should never be
    triggered. But to comply with NISTs current requirements, an endless
    loop must be replaced with the panic.

    When the new version of FIPS 140 will be released, this entire
    continuous self test function will be ripped out as it will not be
    needed any more.

    This patch is functionally equivalent as implemented in ansi_cprng.c and drivers/char/random.c.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

27 Nov, 2014

1 commit


26 Nov, 2014

1 commit


10 Nov, 2014

1 commit

  • The kernel module drbg.ko is currently not loaded automatically when a
    DRBG is requested by a consumer. This is due to missing MODULE_ALIAS
    flags for each of the implemented DRBG types.

    This patch adds aliases for each of the 22 defined DRBGs.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

24 Oct, 2014

1 commit

  • The DRBG internal buffer addition function is replaced with crypto_inc when
    a buffer is to be incremented by one.

    The function drbg_add_buf is moved to the CONFIG_CRYPTO_DRBG_HASH ifdef
    area as it is now only needed for the Hash DRBG.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

05 Sep, 2014

2 commits


26 Aug, 2014

1 commit