Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)

OpenSSL - User mailing list
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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)

Richard Levitte - VMS Whacker-2
Note: these are my personal answers.  I'm sure (and hope) that other
in our team will chip in (and possibly disagree with me)

On Fri, 15 Feb 2019 04:55:38 +0100,
Jakob Bohm 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.

Yes.

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

Broken link fixed.  It was a typo...

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

Are you asking us to provide a link to the git repo?  Should we do
that in each of our HTML files?  (I'm not trying to be a smartass,
this is something we could actually do, and quite easily for these
documents specifically)

BTW, more direct answer: the underlying documents are written in
markdown, and the repo links are:

- [our own repo]
  https://git.openssl.org/?p=openssl-web.git;a=blob;f=docs/OpenSSL300Design.md;h=30a02eb08f574e06e827386ce9fa1830eb3b8070;hb=HEAD
  https://git.openssl.org/?p=openssl-web.git;a=blob;f=docs/OpenSSLStrategicArchitecture.md;h=ecc8fd11e48ec62eb4bfb7e4a60ab799c26971c7;hb=HEAD
- [github]
  https://github.com/openssl/web/blob/master/docs/OpenSSL300Design.md
  https://github.com/openssl/web/blob/master/docs/OpenSSLStrategicArchitecture.md

> 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).

The trouble with this is that it limits what providers can actually
provide.  I've used the example of someone inventing an algorithm
"BLARGH", with some parameters and properties they define.  How would
they be represented with a binary number?  How would an application
know what number they should ask for?

We've chosen strings to have the flexibility.

> - 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 see no issue with that.  The well-known directory would work as a
fallback, the same way we do with ENGINESDIR today.

> - 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.

You may have noticed in the packaging view that the default provider
will be part of libcrypto.  To allow that, we must allow exactly the
construct that you're talking about, and the step to make it possible
for applications to link statically with providers is very small.

(as for "possibly not the FIPS provider", that's exactly right.  That
one *will* be a loadable module and nothing else, and will only be
validated as such...  meaning that noone can stop you from hacking
around and have it linked in statically, but that would make it
invalid re FIPS)

> - 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.

The way to do that would be to divide the default provider into a
number of smaller providers, one for each algorithm, and then leave
you free to link with exactly those you want and none other.  We
haven't really made any explicit plans to do this initially, but I
can't see any reason why it shouldn't be doable.  I can't say if it
will happen in time for 3.0.0, there's already enough to work on and
this is not in the top priorities.

> - 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.

The new design is at that higher level, centered around the EVP API.
The lower level / raw RSA abstraction level isn't there, and we have
not planned for the kind of lower level "default" algorithm support
that ENGINE did.

> - 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).

That would mean some key information passing between providers in a
generic form to allow them to store the key data internally as they
see fit.  Otherwise, those two providers will have to share pretty
damn intimate knowledge about each other's internals.

> - 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.

I don't understand...  the BIGNUM library is available in libcrypto
and as far as I know, there are no plans to remove it.  What did I
miss?

> - 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.

There's nothing stopping the providers to set such properties, and
there's nothing stopping an application from having them in their
method queries.  And finally, there's nothing stopping a provider to
not provide functionality that goes against their properties, either
by simple not providing that specific function, or by having it return
with an error if it finds a call invalid.

> - 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).

Are you thinking descriptions that can be displayed back to the user,
or something that's usable programmatically?  Do you have an idea that
doesn't involve inventing a mini language?

> - 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.

We have also explicitely said that current code must work as much as
possible.  This means that while we could certainly provide all kinds
of new functions, our priority is to make this work with the current
EVP API as much as humanly possible.

> - 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).

A note here: "provider property" is meaningless in this case.
Properties are tied to each algorithm implementation, as can be seen
in the definition of OSSL_ALGORITHM.  And yes, that could be done.  I
can't say that it *will* be done, and you'll probably have to remind
us later on (via github issue, please).

> - 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.

Noted.

> - 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/ .

Ah, I see what you're talking about.  Okie, simple example change.
BTW, many other applications use /usr/lib/{appname}/ or
/usr/local/lib/{appname} for this, so I assume that replacing
"/usr/share/openssl/providers/foo.so" with
"/usr/lib/openssl/providers/foo.so" would be a fine enough example.

> 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).

I'm not sure how important you think the libcrypto version is.  A goal
of the new internal design is to make providers fairly agnostic to
libcrypto versions and vice versa.

> - 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.

We could have mentioned something else.  It's just an example.
(I'm surprised you didn't mention that we consistently specified
'-cbc' as well...  I know some folks who raise an eyebrow at that
these days)

> - 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.

It will only mean that the bleeding edge FIPS module source will be in
a "validation pending" for some time, i.e. you'll have to run your
latest libcrypto build with a previous version of the module for a bit
of time.

> - 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.

From a building perspective, I see nothing that would stop such
bundles to emerge.  Some bundling code that appears as one provider to
libcrypto, maybe?

> - 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

Likewise

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)

Matt Caswell-2
In reply to this post by OpenSSL - User mailing list


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
>  https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html
>  (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:

https://github.com/openssl/web/blob/master/docs/OpenSSL300Design.md
https://github.com/openssl/web/blob/master/docs/OpenSSLStrategicArchitecture.md

Pull requests and issues can be made via github in the normal way:

https://github.com/openssl/web/pulls
https://github.com/openssl/web/issues

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.


> - 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)


>
> - 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.

>
> - 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.

>
> - 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.

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)


> - 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.

>
> - 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
here?

>
> - 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.

>
>
> 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.


> - 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.

> - 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
consistent.

>
> - 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.

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.


>
> - 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.

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)

Tomas Mraz-2
On Fri, 2019-02-15 at 11:23 +0000, Matt Caswell wrote:

>
> On 15/02/2019 03:55, Jakob Bohm via openssl-users wrote:
> > yout - but this is useful input.
>
> >
> > 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.

+1 to Matt. The integrity check of FIPS standard was never ment to be a
mitigation against active attacks. Its purpose always was just
protection against inadvertent HW or SW errors.

Building the checksum into a binary overly complicates things and it is
not worth the hassle as it would not protect against active attacks
either, it would just complicate them a little.

>
> > - 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.

+1

--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)

OpenSSL - User mailing list
In reply to this post by Matt Caswell-2
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
>>   https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html
>>   (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:
>
> https://github.com/openssl/web/blob/master/docs/OpenSSL300Design.md
> https://github.com/openssl/web/blob/master/docs/OpenSSLStrategicArchitecture.md
>
> Pull requests and issues can be made via github in the normal way:
>
> https://github.com/openssl/web/pulls
> https://github.com/openssl/web/issues
>
> 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
protocols.

>
>> - 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
>>   obvious.
> 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
implementations.

>
>> - 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
> here?
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
> consistent.
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
>>   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.
> 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
blocked.

>
>> - 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.
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Comments on the recent OpenSSL 3.0.0 specification (Monday 2019-02-11)

OpenSSL - User mailing list
In reply to this post by Richard Levitte - VMS Whacker-2
>    (as for "possibly not the FIPS provider", that's exactly right.  That
    one *will* be a loadable module and nothing else, and will only be
    validated as such...  meaning that noone can stop you from hacking
    around and have it linked in statically, but that would make it
    invalid re FIPS)
 
To be pedantic: this is true only *if you are using the OpenSSL validation.*  If you are getting your own validation (such as using OpenSSL in an HSM device or whatnot), this is not true.
   
    > - If permitted by the CMVP rules, allow an option for
    >   application provided (additional) entropy input to the RNG
    >   from outside the module boundary.
 
This is allowed, but it does not count toward the "minimum entropy" requirements.  Anything after the first seeding falls into that category.

Reply | Threaded
Open this post in threaded view
|

Re: Comments on the recent OpenSSL 3.0.0 specification

OpenSSL - User mailing list
(Resend from correct account)

On 15/02/2019 18:35, Salz, Rich via openssl-users wrote:

>> (as for "possibly not the FIPS provider", that's exactly right. That
> one *will* be a loadable module and nothing else, and will only be
> validated as such... meaning that noone can stop you from hacking
> around and have it linked in statically, but that would make it
> invalid re FIPS)
> To be pedantic: this is true only *if you are using the OpenSSL
> validation.* If you are getting your own validation (such as using
> OpenSSL in an HSM device or whatnot), this is not true.
> > - If permitted by the CMVP rules, allow an option for
> > application provided (additional) entropy input to the RNG
> > from outside the module boundary.
> This is allowed, but it does not count toward the "minimum entropy"
> requirements. Anything after the first seeding falls into that category.
>

Thanks, the document wording made it look like the OpenSSL 3 FIPS RNG would
only accept the system entropy source.

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