OTC VOTE: EVP_PKEY private/public key components

[Nicola Tuveri]

In light of recently working more closely to `EVP_PKEY_check()` I
would add to the discussion on this vote that it is not entirely true
that we were not enforcing the keypair assumption and that the current
strict behavior of the EC keymgmt in 3.0 is a breaking change w.r.t.
some uses that work in 1.1.1.

In particular in 1.1.1, the key created as depicted in #12612 that
triggered this discussion (Matt posted a useful reproducer among the
first comments), is indeed capable of signing in the used pattern, but
the pattern is conveniently omitting the validation pass that should
be required in any serious use of the API.

`EVP_PKEY_check()`
(https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html) is
one of the many places in 1.1.1 where both the documentation and the
behavior assume that an `EVP_PKEY` object is a keypair.
Even in the version used by the user that posted the issue, running
`EVP_PKEY_check()` on the created key would have revealed that the
user was abusing the API.

The "lack of enforcement" argument, that was partially at the base of
formulating the vote text as it is, and conditioned our votes, seems
to me an intentional design choice, as part of preferring the usage
pattern "validate once, and reuse many times": for performance reasons
we are not running `EVP_PKEY_check()` on every single key loaded from
a PEM file or created by the user, but there is an assumption that the
user did validate at least once the key material using
`EVP_PKEY_check()` or `openssl pkey -check`.
So enforcement was never lacking, but it was relegated together with
more expensive checks, into functions that the user should execute at
least once, possibly according to well documented security policies
concerning the management of key material in transit and at rest.

Omitting the `EVP_PKEY_check()` in the reproducer and the user
application, would for example allow me to write a DoS attack: the
secret scalar could easily be hand-picked to trigger an endless loop
in the sign operation.


--

Nicola



On Tue, Nov 3, 2020 at 2:11 PM Matt Caswell <matt at openssl.org> wrote:
>
> Background to the vote:
>
> The OTC meeting today discussed the problems raised by issue #12612. In
> summary the problem is that there has been a long standing, widespread
> and documented assumption that an EVP_PKEY with a private key will
> always also have the public key component.
>
> In spite of this it turns out that in the EC implementation in 1.1.1 it
> was perfectly possible to create an EVP_PKEY with only a private key and
> no public key - and it was also possible to use such an EVP_PKEY in a
> signing operation.
>
> The current 3.0 code in master introduced an explicit check (in line
> with the long held assumption) that the public key was present and
> rejected keys where this was not the case. This caused a backwards
> compatibility break for some users (as discussed at length in #12612).
>
> The OTC discussed a proposal that we should relax our conceptual model
> in this regards and conceptually allow EVP_PKEYs to exist that only have
> the private component without the public component - although individual
> algorithm implementations may still require both.
>
> It is possible to automatically generate the public component from the
> private for many algorithms, although this may come at a performance and
> (potentially) a security cost.
>
> The proposal discussed was that while relaxing the conceptual model,
> most of the existing implementations would still require both. The EC
> implementation would be relaxed however. This essentially gives largely
> compatible behaviour between 1.1.1 and 3.0.
>
> The vote text is as follows:
>
> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> * relax the conceptual model to allow private keys to exist without public
>   components;
> * all implementations apart from EC require the public component to be
> present;
> * relax implementation for EC key management to allow private keys that
> do not
>   contain public keys and
> * our decoders unconditionally generate the public key (where possible).
>
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-11-03
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
>
>   Matt       [+1]
>   Mark       [  ]
>   Pauli      [+1]
>   Viktor     [  ]
>   Tim        [  ]
>   Richard    [+1]
>   Shane      [+1]
>   Tomas      [+1]
>   Kurt       [  ]
>   Matthias   [  ]
>   Nicola     [-1]