[openssl-users] Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)

[Jakob Bohm]

These comments are on the version of the specification released on
Monday 2019-02-11 at https://www.openssl.org/docs/OpenSSL300Design.html

General notes on this release:

- The release was not announced on the openssl-users and
  openssl-announce mailing lists.  A related blog post was
  announced two days later.

- The related strategy document is at
  https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html
  (This link is broken on the www.openssl.org front page).

- The draft does not link to anywhere that the public can
  inspect archived or version tracked document versions.

Non-FIPS architecture issues:

- The identifiers for predefined parameters and values (such as
  "fips", "on", "off", "aes-128-cbc" should be binary values that
  cannot be easily searched in larger program files (by attackers).
   This rules out both text strings, UUID values and ASN OID values.
  Something similar to the function ids would be ideal.  Note that
  to make this effective, the string names of these should not
  appear in linked binaries.
   (The context of this is linking libcrypto and/or libssl into
  closed source binary programs, since open source binaries cannot
  hide their internal structure anyway).

- It should be possible for applications to configure OpenSSL to
  load provider DLLs and config files from their own directories
  rather than the global well-known directory (isolation from
  system wide changes).

- It should be possible for providers (possibly not the FIPS
  provider) to be linked directly into programs that link
  statically to libcrypto.  This implies the absence of
  conflicting identifiers, a public API to pass the address of
  a |OSSL_provider_init|function, all bundled providers provided
  as static libraries in static library builds, and a higher
  level init function that initializes both libcrypto and the
  default provider.

- Static library forms of the default provider should not
  force callers to include every algorithm just because they
  are referenced from the default dispatch tables.  For example,
  it should be easy to link a static application that uses only
  AES-256-CBC and SHA-256, and contains little else.  Such limited
  feature applications would obviously have to forego using the
  all-inclusive high level init function.

- For use with engine-like providers (such as hardware providers
  and the PKCS#11 provider), it should be possible for a provider
  to provide algorithms like RSA at multiple abstraction levels.
   For example, some PKCS#11 hardware provides the raw RSA
  algorithm (bignum in, bignum out) while others provide specific
  forms such as PKCS#1.5 signature.  There are even some that
  provide the PKCS#1.5 form with some hashes and the RSA form
  as a general fallback.

- Similarly, some providers will provide both ends of an
  asymmetric algorithm, while others only provide the private
  key operation, leaving the public key operation to other
  providers (selected by core in the general way).

- The general bignum library should be exposed via an API, either
  the legacy OpenSSL bignum API or a replacement API with an overlap
  of at least one major version with both APIs available.

- Provider algorithm implementations should carry
  description/selection parameters indicating limits to access:
  "key-readable=yes/no", "key-writable=yes/no", "data-internal=yes/no",
  "data-external=yes/no" and "iv-internal=yes/no".  For example,
  a smartcard-like provider may have "key-readable=no" and
  "key-writable=yes" for RSA keys, while another card may have
  "key-writable=no" (meaning that externally generated keys cannot
  be imported to the card.  "data-internal" refers to the
  ability to process (encrypt, hash etc.) data internal to the
  provider, such as other keys, while "data-external" refers to
  the ability to process arbitrary application data.

- Variable key length algorithm implementations should carry
  description/selection parameters indicating maximum and minimum
  key lengths (Some will refuse to process short keys, others will
  refuse long keys, some will require the key length to be a
  multiple of some number).

- The current EVP interface abuses the general (re)init operations
  with omitted arguments as the main interface to update rapidly
  changing algorithm parameters such as IVs and/or keys.  With the
  removal of legacy APIs, the need to provide parameter changing
  as explicit calls in the EVP API and provider has become more
  obvious.

- A provider property valuable to some callers (and already a known
  property of some legacy APIs) is to declare that certain simple
  operations will always succeed, such as passing additional data
  bytes to a hash/mac (the rare cases of hardware disconnect and/or
  exceeding the algorithm maximums can be deferred to "finish"
  operations).  A name for this property of an algorithm
  implementation could be "nofail=yes", and the list of non-failing
  operations defined for each type of algorithm should be publicly
  specified (a nofail hash would have a different list than a
  no-fail symmetric encryption).

- Providers that are really bridges to another multi-provider API
  (ENGINE, PKCS#11, MS CAPI 1, MS CNG) should be explicitly allowed
  to load/init separately for each underlying provider.  For example,
  it would be bad for an application talking to one PKCS#11 module to
  run, load or block all other PKCS#11 modules on the system.

- Under normal file system layout conventions, /usr/share/ (and
  below) is for architecture-independent files such as man pages,
  trusted root certificates and platform-independent include files.
   Architecture specific files such as "openssl/providers/foo.so"
  and opensslconf.h belong in /usr/ or /usr/local/ .


FIPS-specific issues:

- The checksum of the FIPS DLL should be compiled into the FIPS-
  capable OpenSSL library, since a checksum stored in its own file
  on the end user system is too easily replaced by attackers.  This
  also implies that each FIPS DLL version will need its own file name
  in case different applications are linked to different libcrypto
  versions (because they were started before an upgrade of the shared
  libcrypto or because they use their own copy of libcrypto).

- If possible, the core or a libcrypto-provided FIPS-wrapper should
  check the hash of the opensslfips-3.x.x.so DLL before running any
  of its code (including on-load stubs), secondly, the DLL can
  recheck itself using its internal implementation of the chosen MAC
  algorithm, if this is required by the CMVP.  This is to protect the
  application if a totally unrelated malicious file is dropped in
  place of the DLL.

- The document seems to consistently only mentions the
  shortest/weakest key lengths, such as AES-128.  Hopefully the
  actual release will have no such limitation.

- The well-known slowness of FIPS validations will in practice
  require the FIPS module compiled from a source change to be
  released (much) later than the same change in the default
  provider.  The draft method of submitting FIPS validation
  updates just before any FIPS-affecting OpenSSL release seems
  overly optimistic.

- Similarly, due to the slowness of FIPS validation updates,
  it may often be prudent to provide a root-cause fix in the
  default provider and a less-effective change in the FIPS
  provider, possibly involving FIPS-frozen workaround code in
  libcrypto, either in core or in a separate FIPS-wrapper
  component.

- The mechanisms for dealing with cannot-export-the-private-key
  hardware providers could also be used to let the FIPS provider
  offer algorithm variants where the crypto officer (application
  writer/installer) specify that some keys remain inside the
  FIPS blob, inaccessible to the user role (application code).
   For example, TLS PFS (EC)DHE keys and CMS per message keys
  could by default remain inside the provider.  Extending this
  to TLS session keys and server private key would be a future
  option.

- In future versions, it should be possible to combine the
  bundled FIPS provider with providers for FIPS-validated hardware,
  such as FIPS validated PIV smart cards for TLS client
  certificates.

- Support for generating and validating (EC)DH and (EC)DSA
  group parameters using the FIPS-specified algorithms should
  be available in addition to the fixed sets of well-known
  group parameters.  In FIPS 800-56A rev 3, these are the
  DH primes specified using a SEED value.  Other versions of
  SP 800-56A, and/or supplemental NIST documents may allow
  other such group parameters.

- If permitted by the CMVP rules, allow an option for
  application provided (additional) entropy input to the RNG
  from outside the module boundary.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded