[openssl-users] Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)
jb-openssl at wisemo.com
Fri Feb 15 16:54:35 UTC 2019
On 15/02/2019 12:23, Matt Caswell wrote:
> On 15/02/2019 03:55, Jakob Bohm via openssl-users wrote:
>> 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.
> Well the blog post was intended to *be* the announcement.
>> - The related strategy document is at
>> (This link is broken on the www.openssl.org front page).
> Fixed - thanks.
>> - The draft does not link to anywhere that the public can
>> inspect archived or version tracked document versions.
> These documents have only just reached the point where they were stable enough
> to make public and go into version control. Any future updates will go through
> the normal review process for the web repo and be version controlled. The raw
> markdown versions are here:
> Pull requests and issues can be made via github in the normal way:
> Other comments inserted below where I have an opinion or something to say. I'm
> hoping others will chip in on your other points:
>> 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).
> I believe this is the intention.
>> - 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.
> The plan is that Providers may choose to be linked against libcrypto or not as
> they see fit (the FIPS Provider will not be). They can be built entirely without
> using any libcrypto symbols at all. They just need to have the well known entry
> point. Any functions from the Core that the Provider may need to call are passed
> as callback function pointers. I can't think of a reason why there should be an
> issue with providers statically linking with libcrypto if they so wish.
This one is not about providers linked against libcrypto, it's
about applications linked against libcrypto3.a and provider-lib.a,
thus eliminating the DLL loading step.
>> - 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.
> I think this should be possible with the design as it stands. Providers make
> implementations of algorithms available to the core. I don't see any reason why
> they can't provide multiple implementations of the same algorithm (presumably
> distinguished by some properties)
The case here is that some providers (such as certain Gemalto USB
smartcards) offer hardware implementation of RSA over arbitrary
bignums, leaving the PKCS formatting to libraries such as OpenSSL.
Experience with upgrading to better hashes in the past tells me it
is more robust if the PKCS formatting code is not pushed into the
provider in those cases. I have other cards in my collection that
act the other way round (insisting on doing the PKCS formatting to
prevent chosen plaintext attacks).
>> - 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).
> Again I believe this should be possible with the current design. We split
> algorithm implementations into different "operations". I don't think there is
> any reason to require a provider to implement all operations that an algorithm
> is capable of (in fact I think that was the design intent). It might be worth
> making the ability to do this more explicit in the document.
>> - 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.
> There are no plans to remove access to bignum.
It was missing from the component diagrams and vague text about
deprecating "legacy APIs" was not reassuring.
>> - 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.
> We expect Provider authors to be able to define their own properties as they see
> fit. We plan to create a central repository (outside the main source code) of
> "common" names. So I think all of the above should be possible.
The idea was to make these standard properties, as they seem to
occur in many real world providers, from FIPS to MS CAPI. They also
affect which implementations can be used at various points in the
>> - 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).
There was a comment in the other reply. I think this simple list of
3 numeric properties (or perhaps a few more), would be enough to answer
the question "will this provider implementation handle this particular
key size"? No need for a mini language.
Examples: The FIPS provider 3.0.0 will explicitly enforce some minimum
key lengths for RSA and DH keys. A smart card in my collection requires
RSA keys to be a multiple of 64 bits (in addition to max and min lengths),
while another card from the same vendor has a different divider.
>> - 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
> Agreed that we will need to review the EVP interface to ensure that everything
> you can do in the low-level interface is still possible (within reason). Note
> though that in 3.0.0 we are only deprecating the low-level APIs not removing
> them. The Strategic Architecture document (which has a view beyond 3.0.0) sees
> us moving them to a libcrypto-legacy library (so they would still be available).*
> If you do use the low-level APIs in 3.0.0 then they won't go via the Core/Providers.
> (* I just spotted an error in the strategy document. The packaging diagram
> doesn't match up with the text and doesn't show libcrypto-legacy on it - althogh
> the text does talk about it. I need to investigate that)
Point would be to provide EVP methods to replace some already deprecated
low-level APIs. Currently fragile logic to do less when only changing the
IV is buried deep in each symmetric algorithm provider. Making this an
explicit provider method and making core dispatch that case accordingly
would improve code quality.
>> - 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).
> That's an interesting idea. Again Provider can define their own properties as
> they see fit. We can certainly give consideration to any other properties that
> we would like to have a "common" definition.
I believe this is a (non-public) property of some of default
>> - 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.
> The design allows for providers to make algorithm implementations
> available/not-available over time. So I think this addresses what you are saying
Loading a PKCS#11 module (or the equivalent for other APIs) has side
effects. Loading (or not) PKCS#11 modules (etc.) as needed should be
almost as easy as loading (or not) providers.
>> - 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/ .
> I don't believe we've got as far as specifying the installation file system
> layout - but this is useful input.
There were some unfortunate examples in the document.
>> 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).
> This is not an attack that we are seeking to defend against in 3.0.0. We
> consider the checksum to be an integrity check to protect against accidental
> changes to the module.
While FIPS 140 level 1 might not, the higher FIPS levels seem very
keen on defending against these attacks, and the checksum at level 1
seems to be a degenerated remnant of those defenses.
>> - 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.
> As above - this is not an attack we are seeking to defend against.
It is, however, a new attack made possible by moving the FIPS canister
into its own file.
>> - 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.
> No - there is no such restriction. The full list of what we are planning to
> support is in Appendix 3. Although I note that we explicitly mention key lengths
> for some algorithms/modes but not others. We should probably update that to be
Bad choices of examples then. I saw lots of mention of weak strength
stuff, such as 96 bits of entropy, AES-128 etc.
>> - 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
>> - 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
>> - 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
> The OpenSSL FIPS provider will provide algorithm implementations matching
> "fips=yes". I see no reason why other providers can't do the same - so the above
> should be possible.
Some wording in the document suggested this might be erroneously
>> - 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.
> Thanks for the input and all of the suggestions.
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
More information about the openssl-users