calc_keyid_v2 producing different keyid for non-sha1 SKIDs

calc_keyid_v2 producing different keyid for non-sha1 SKIDs

[Vitaly Chikunov]

Hi,

I am reported that IMA signatures where SKID is not just sha1 of the
public key (but something different, for example different hash algo,
such as Streebog) have "wrong" keyid in the signature. This is because
a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID)
x509 extension, (or if this fails it takes just serial, perhaps, we can
disregard this corner case), it never does sha1 over the public key).
But, b) evmctl, when signing, uses just private key (not even knowing
certificate where SKID should be) and calculating sha1 of public key.
Thus, keyids could mismatch each other, and it's even not easy to fix
evmctl, because there is no cert at the time of signing.

Perhaps, we should fix this somehow. For example, when signing,
introduce new option --cert, where SKID should be extracted. Does it
looks reasonable?

Vitaly,

Re: calc_keyid_v2 producing different keyid for non-sha1 SKIDs

[Stefan Berger]

On 4/26/21 3:37 PM, Vitaly Chikunov wrote:
> Hi,
>
> I am reported that IMA signatures where SKID is not just sha1 of the
> public key (but something different, for example different hash algo,
> such as Streebog) have "wrong" keyid in the signature. This is because
> a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID)
> x509 extension, (or if this fails it takes just serial, perhaps, we can
> disregard this corner case), it never does sha1 over the public key).


Is it wrong for ecrdsa keys? What is the spec?

Here's the spec that describes using sha1 for the skid which seems to 
work like this for RSA and ECDSA keys from what I can tell:

https://tools.ietf.org/html/rfc3280#section-4.2.1.2


> But, b) evmctl, when signing, uses just private key (not even knowing
> certificate where SKID should be) and calculating sha1 of public key.
> Thus, keyids could mismatch each other, and it's even not easy to fix
> evmctl, because there is no cert at the time of signing.
>
> Perhaps, we should fix this somehow. For example, when signing,
> introduce new option --cert, where SKID should be extracted. Does it
> looks reasonable?
>
> Vitaly,
>
>
>

Re: calc_keyid_v2 producing different keyid for non-sha1 SKIDs

[Vitaly Chikunov]

Stefan,

https://tools.ietf.org/html/rfc7093

On Mon, Apr 26, 2021 at 04:21:26PM -0400, Stefan Berger wrote:
> 
> On 4/26/21 3:37 PM, Vitaly Chikunov wrote:
> > Hi,
> > 
> > I am reported that IMA signatures where SKID is not just sha1 of the
> > public key (but something different, for example different hash algo,
> > such as Streebog) have "wrong" keyid in the signature. This is because
> > a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID)
> > x509 extension, (or if this fails it takes just serial, perhaps, we can
> > disregard this corner case), it never does sha1 over the public key).
> 
> 
> Is it wrong for ecrdsa keys? What is the spec?

It seems, some CA provide by default certs with Streebog-256 hash as
drop-in replacement for SHA1, so their users forced to (re-)request the
certs with a compatible SHA1 SKID.

> Here's the spec that describes using sha1 for the skid which seems to work
> like this for RSA and ECDSA keys from what I can tell:
> 
> https://tools.ietf.org/html/rfc3280#section-4.2.1.2

Perhaps, you meant https://tools.ietf.org/html/rfc5280#section-4.2.1.2

  "Other methods of generating unique numbers are also acceptable."

Also, see https://tools.ietf.org/html/rfc7093

Thanks,

> 
> 
> > But, b) evmctl, when signing, uses just private key (not even knowing
> > certificate where SKID should be) and calculating sha1 of public key.
> > Thus, keyids could mismatch each other, and it's even not easy to fix
> > evmctl, because there is no cert at the time of signing.
> > 
> > Perhaps, we should fix this somehow. For example, when signing,
> > introduce new option --cert, where SKID should be extracted. Does it
> > looks reasonable?
> > 
> > Vitaly,
> > 
> > 
> > 

Re: calc_keyid_v2 producing different keyid for non-sha1 SKIDs

[Vitaly Chikunov]

On Tue, Apr 27, 2021 at 01:01:48AM +0300, Vitaly Chikunov wrote:
> Stefan,
> 
> https://tools.ietf.org/html/rfc7093
> 
> On Mon, Apr 26, 2021 at 04:21:26PM -0400, Stefan Berger wrote:
> > 
> > On 4/26/21 3:37 PM, Vitaly Chikunov wrote:
> > > Hi,
> > > 
> > > I am reported that IMA signatures where SKID is not just sha1 of the
> > > public key (but something different, for example different hash algo,
> > > such as Streebog) have "wrong" keyid in the signature. This is because
> > > a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID)
> > > x509 extension, (or if this fails it takes just serial, perhaps, we can
> > > disregard this corner case), it never does sha1 over the public key).
> > 
> > 
> > Is it wrong for ecrdsa keys? What is the spec?
> 
> It seems, some CA provide by default certs with Streebog-256 hash as
> drop-in replacement for SHA1, so their users forced to (re-)request the
> certs with a compatible SHA1 SKID.
> 
> > Here's the spec that describes using sha1 for the skid which seems to work
> > like this for RSA and ECDSA keys from what I can tell:
> > 
> > https://tools.ietf.org/html/rfc3280#section-4.2.1.2
> 
> Perhaps, you meant https://tools.ietf.org/html/rfc5280#section-4.2.1.2
> 
>   "Other methods of generating unique numbers are also acceptable."
> 
> Also, see https://tools.ietf.org/html/rfc7093

And, I think all v2 signatures potentially affected.

> > > But, b) evmctl, when signing, uses just private key (not even knowing
> > > certificate where SKID should be) and calculating sha1 of public key.
> > > Thus, keyids could mismatch each other, and it's even not easy to fix
> > > evmctl, because there is no cert at the time of signing.
> > > 
> > > Perhaps, we should fix this somehow. For example, when signing,
> > > introduce new option --cert, where SKID should be extracted. Does it
> > > looks reasonable?

Additionally, we could add `--keyid' option, so users could manually set
keyid without extracting it from the cert file.

> > > 
> > > Vitaly,
> > > 
> > > 
> > > 

Re: calc_keyid_v2 producing different keyid for non-sha1 SKIDs

[Stefan Berger]

On 4/26/21 6:14 PM, Vitaly Chikunov wrote:
> On Tue, Apr 27, 2021 at 01:01:48AM +0300, Vitaly Chikunov wrote:
>> Stefan,
>>
>> https://tools.ietf.org/html/rfc7093
>>
>> On Mon, Apr 26, 2021 at 04:21:26PM -0400, Stefan Berger wrote:
>>> On 4/26/21 3:37 PM, Vitaly Chikunov wrote:
>>>> Hi,
>>>>
>>>> I am reported that IMA signatures where SKID is not just sha1 of the
>>>> public key (but something different, for example different hash algo,
>>>> such as Streebog) have "wrong" keyid in the signature. This is because
>>>> a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID)
>>>> x509 extension, (or if this fails it takes just serial, perhaps, we can
>>>> disregard this corner case), it never does sha1 over the public key).
>>>
>>> Is it wrong for ecrdsa keys? What is the spec?
>> It seems, some CA provide by default certs with Streebog-256 hash as
>> drop-in replacement for SHA1, so their users forced to (re-)request the
>> certs with a compatible SHA1 SKID.
>>
>>> Here's the spec that describes using sha1 for the skid which seems to work
>>> like this for RSA and ECDSA keys from what I can tell:
>>>
>>> https://tools.ietf.org/html/rfc3280#section-4.2.1.2
>> Perhaps, you meant https://tools.ietf.org/html/rfc5280#section-4.2.1.2
>>
>>    "Other methods of generating unique numbers are also acceptable."
>>
>> Also, see https://tools.ietf.org/html/rfc7093
> And, I think all v2 signatures potentially affected.

I have been using evmctl successfully with RSA and ECDSA keys now and 
certificates created by **OpenSSL**. Problems may occur if the 
certificate-generating tool uses something else than a sha1 to calculate 
the subject key identifier (skid) and therefore the key id calculated by 
evmctl (with a sha1) does not match. For the non-working case one could 
pass in a keyidv2 that the user would have to determine from the 
certificate's subject key identifier's last 4 bytes.

It would be interesting to know which tools do not use a sha1 to 
calculate the subject key identifier or what types of keys those are so 
that one could give recommendations for tools to use. GnuTLS's certtool 
for example does not seem to use the same algorithm to calculate the 
skid, so I would not recommend using it for generating the certs to be 
used in conjunction with evmctl and IMA signatures.

Also, evmctl could for example use a different hash if for example tools 
creating certs for ecrdsa keys most often use a streebog hash. This 
would make it easier for the user not having to determine the keyid.

>
>>>> But, b) evmctl, when signing, uses just private key (not even knowing
>>>> certificate where SKID should be) and calculating sha1 of public key.
>>>> Thus, keyids could mismatch each other, and it's even not easy to fix
>>>> evmctl, because there is no cert at the time of signing.
>>>>
>>>> Perhaps, we should fix this somehow. For example, when signing,
>>>> introduce new option --cert, where SKID should be extracted. Does it
>>>> looks reasonable?
> Additionally, we could add `--keyid' option, so users could manually set
> keyid without extracting it from the cert file.


Agreed.

    Stefan

Re: calc_keyid_v2 producing different keyid for non-sha1 SKIDs

[Vitaly Chikunov]

Stefan,

On Fri, Apr 30, 2021 at 01:19:02PM -0400, Stefan Berger wrote:
> 
> On 4/26/21 6:14 PM, Vitaly Chikunov wrote:
> > On Tue, Apr 27, 2021 at 01:01:48AM +0300, Vitaly Chikunov wrote:
> > > Stefan,
> > > 
> > > https://tools.ietf.org/html/rfc7093
> > > 
> > > On Mon, Apr 26, 2021 at 04:21:26PM -0400, Stefan Berger wrote:
> > > > On 4/26/21 3:37 PM, Vitaly Chikunov wrote:
> > > > > Hi,
> > > > > 
> > > > > I am reported that IMA signatures where SKID is not just sha1 of the
> > > > > public key (but something different, for example different hash algo,
> > > > > such as Streebog) have "wrong" keyid in the signature. This is because
> > > > > a) kernel extracting keyid from the cert's subjectKeyIdentifier (SKID)
> > > > > x509 extension, (or if this fails it takes just serial, perhaps, we can
> > > > > disregard this corner case), it never does sha1 over the public key).
> > > > 
> > > > Is it wrong for ecrdsa keys? What is the spec?
> > > It seems, some CA provide by default certs with Streebog-256 hash as
> > > drop-in replacement for SHA1, so their users forced to (re-)request the
> > > certs with a compatible SHA1 SKID.
> > > 
> > > > Here's the spec that describes using sha1 for the skid which seems to work
> > > > like this for RSA and ECDSA keys from what I can tell:
> > > > 
> > > > https://tools.ietf.org/html/rfc3280#section-4.2.1.2
> > > Perhaps, you meant https://tools.ietf.org/html/rfc5280#section-4.2.1.2
> > > 
> > >    "Other methods of generating unique numbers are also acceptable."
> > > 
> > > Also, see https://tools.ietf.org/html/rfc7093
> > And, I think all v2 signatures potentially affected.
> 
> I have been using evmctl successfully with RSA and ECDSA keys now and
> certificates created by **OpenSSL**. Problems may occur if the
> certificate-generating tool uses something else than a sha1 to calculate the
> subject key identifier (skid) and therefore the key id calculated by evmctl
> (with a sha1) does not match. For the non-working case one could pass in a
> keyidv2 that the user would have to determine from the certificate's subject
> key identifier's last 4 bytes.
> 
> It would be interesting to know which tools do not use a sha1 to calculate
> the subject key identifier or what types of keys those are so that one could
> give recommendations for tools to use. GnuTLS's certtool for example does
> not seem to use the same algorithm to calculate the skid, so I would not
> recommend using it for generating the certs to be used in conjunction with
> evmctl and IMA signatures.

You can also reproduce non-sha1 skid with openssl using subjectKeyIdentifier=
config option, see x509v3_config(5).

Thanks,

Re: calc_keyid_v2 producing different keyid for non-sha1 SKIDs

[Stefan Berger]

On 4/30/21 2:33 PM, Vitaly Chikunov wrote:
> Stefan,
> .
>> I have been using evmctl successfully with RSA and ECDSA keys now and
>> certificates created by **OpenSSL**. Problems may occur if the
>> certificate-generating tool uses something else than a sha1 to calculate the
>> subject key identifier (skid) and therefore the key id calculated by evmctl
>> (with a sha1) does not match. For the non-working case one could pass in a
>> keyidv2 that the user would have to determine from the certificate's subject
>> key identifier's last 4 bytes.
>>
>> It would be interesting to know which tools do not use a sha1 to calculate
>> the subject key identifier or what types of keys those are so that one could
>> give recommendations for tools to use. GnuTLS's certtool for example does
>> not seem to use the same algorithm to calculate the skid, so I would not
>> recommend using it for generating the certs to be used in conjunction with
>> evmctl and IMA signatures.
> You can also reproduce non-sha1 skid with openssl using subjectKeyIdentifier=
> config option, see x509v3_config(5).

"Subject Key Identifier.

This is really a string extension and can take two possible values. 
Either the word hash which will automatically follow the guidelines in 
RFC3280 or a hex string giving the extension value to include. The use 
of the hex string is strongly discouraged.

Example:

subjectKeyIdentifier=hash"

 From what I know it offers also the possibility of 'none'. It doesn't 
seem to be all that bad when using OpenSSL.

    Stefan