[v6,1/3] ima-evm-utils: Allow manual setting keyid for signing

Commit Message

Vitaly Chikunov May 11, 2021, 11:56 a.m. UTC

Allow user to set signature's keyid using `--keyid' option. Keyid should
correspond to SKID in certificate, when keyid is calculated using SHA-1
in libimaevm it may mismatch keyid extracted by the kernel from SKID of
certificate (the way public key is presented to the kernel), thus making
signatures not verifiable. This may happen when certificate is using non
SHA-1 SKID (see rfc7093) or just 'unique number' (see rfc5280 4.2.1.2).
As a last resort user may specify arbitrary keyid using the new option.

This commit creates ABI change for libimaevm, because of adding
additional parameter to imaevm_params - newer libimaevm cannot work
with older clients.

Signed-off-by: Vitaly Chikunov <[e-mail]>
Reported-by: Elvira Khabirova <[e-mail]>
Reviewed-by: Stefan Berger <[e-mail]>
---
 README                 |  1 +
 src/evmctl.c           | 15 +++++++++++++++
 src/imaevm.h           |  1 +
 src/libimaevm.c        |  8 +++++---
 tests/sign_verify.test |  1 +
 5 files changed, 23 insertions(+), 3 deletions(-)

Comments

Mimi Zohar June 25, 2021, 12:21 p.m. UTC | #1

On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote:
> Allow user to set signature's keyid using `--keyid' option. Keyid should
> correspond to SKID in certificate, when keyid is calculated using SHA-1
> in libimaevm it may mismatch keyid extracted by the kernel from SKID of
> certificate (the way public key is presented to the kernel), thus making
> signatures not verifiable. This may happen when certificate is using non
> SHA-1 SKID (see rfc7093) or just 'unique number' (see rfc5280 4.2.1.2).
> As a last resort user may specify arbitrary keyid using the new option.
> 
> This commit creates ABI change for libimaevm, because of adding
> additional parameter to imaevm_params - newer libimaevm cannot work
> with older clients.

Thank you for highlighting the ABI change.

> 
> Signed-off-by: Vitaly Chikunov <[e-mail]>
> Reported-by: Elvira Khabirova <[e-mail]>
> Reviewed-by: Stefan Berger <[e-mail]>
> ---
>  README                 |  1 +
>  src/evmctl.c           | 15 +++++++++++++++
>  src/imaevm.h           |  1 +
>  src/libimaevm.c        |  8 +++++---
>  tests/sign_verify.test |  1 +
>  5 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/README b/README
> index 321045d..8cd66e0 100644
> --- a/README
> +++ b/README
> @@ -48,6 +48,7 @@ OPTIONS
>        --xattr-user   store xattrs in user namespace (for testing purposes)
>        --rsa          use RSA key type and signing scheme v1
>    -k, --key          path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)
> +      --keyid val    overwrite signature keyid with a value (for signing)
>    -o, --portable     generate portable EVM signatures
>    -p, --pass         password for encrypted signing key
>    -r, --recursive    recurse into directories (sign)
> diff --git a/src/evmctl.c b/src/evmctl.c
> index 7a6f202..d853d34 100644
> --- a/src/evmctl.c
> +++ b/src/evmctl.c
> @@ -2514,6 +2514,7 @@ static void usage(void)
>  		"      --xattr-user   store xattrs in user namespace (for testing purposes)\n"
>  		"      --rsa          use RSA key type and signing scheme v1\n"
>  		"  -k, --key          path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)\n"
> +		"      --keyid val    overwrite signature keyid with a value (for signing)\n"
>  		"  -o, --portable     generate portable EVM signatures\n"
>  		"  -p, --pass         password for encrypted signing key\n"
>  		"  -r, --recursive    recurse into directories (sign)\n"
> @@ -2594,6 +2595,7 @@ static struct option opts[] = {
>  	{"ignore-violations", 0, 0, 141},
>  	{"pcrs", 1, 0, 142},
>  	{"verify-bank", 2, 0, 143},
> +	{"keyid", 1, 0, 144},
>  	{}
> 
>  };
> @@ -2638,6 +2640,8 @@ int main(int argc, char *argv[])
>  {
>  	int err = 0, c, lind;
>  	ENGINE *eng = NULL;
> +	unsigned long keyid;
> +	char *eptr;
> 
>  #if !(OPENSSL_VERSION_NUMBER < 0x10100000)
>  	OPENSSL_init_crypto(
> @@ -2785,6 +2789,17 @@ int main(int argc, char *argv[])
>  		case 143:
>  			verify_bank = optarg;
>  			break;
> +		case 144:
> +			errno = 0;
> +			keyid = strtoul(optarg, &eptr, 16);
> +			if (errno || eptr - optarg != strlen(optarg) ||

Before using eptr, shouldn't there be a null test?  It's unclear what
verifying the resulting string length against the user provided length
provides.   Requiring the optarg value to be prefixed with "0x" would
simplify the strlen test.  The length would be 2 * sizeof uint + 2.  
(The subsequent patch wouldn't need a contrived prefix.)

> +			    keyid == ULONG_MAX || keyid > UINT_MAX ||

Why are both of these tests required?  When ULONG_MAX and UINT_MAX
aren't the same, wouldn't ULONG_MAX always be bigger than UINT_MAX?

> +			    keyid == 0) {
> +				log_err("Invalid keyid value.\n");
> +				exit(1);
> +			}
> +			imaevm_params.keyid = keyid;
> +			break;
>  		case '?':
>  			exit(1);
>  			break;
> diff --git a/src/imaevm.h b/src/imaevm.h
> index 4503919..9f38059 100644
> --- a/src/imaevm.h
> +++ b/src/imaevm.h
> @@ -196,6 +196,7 @@ struct libimaevm_params {
>  	const char *hash_algo;
>  	const char *keyfile;
>  	const char *keypass;
> +	uint32_t keyid;		/* keyid overriding value, unless 0. */

If keyid is suppose to be big endiran format, please annotate it in the
comment.

>  };
> 
>  struct RSA_ASN1_template {
> diff --git a/src/libimaevm.c b/src/libimaevm.c
> index fa6c278..481d29d 100644
> --- a/src/libimaevm.c
> +++ b/src/libimaevm.c
> @@ -45,6 +45,7 @@
>  #include <sys/param.h>
>  #include <sys/stat.h>
>  #include <asm/byteorder.h>
> +#include <arpa/inet.h>
>  #include <unistd.h>
>  #include <dirent.h>
>  #include <string.h>
> @@ -894,7 +895,6 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
>  	const EVP_MD *md;
>  	size_t sigsize;
>  	const char *st;
> -	uint32_t keyid;
> 
>  	if (!hash) {
>  		log_err("sign_hash_v2: hash is null\n");
> @@ -932,8 +932,10 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
>  		return -1;
>  	}
> 
> -	calc_keyid_v2(&keyid, name, pkey);
> -	hdr->keyid = keyid;
> +	if (imaevm_params.keyid)
> +		hdr->keyid = htonl(imaevm_params.keyid);
> +	else
> +		calc_keyid_v2(&hdr->keyid, name, pkey);
> 
At what point should imaevm_params.keyid be converted to big endian -
on usage or setting it?

Mimi

>  	st = "EVP_PKEY_CTX_new";
>  	if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL)))
> diff --git a/tests/sign_verify.test b/tests/sign_verify.test
> index 3d7aa51..eccf5fa 100755
> --- a/tests/sign_verify.test
> +++ b/tests/sign_verify.test
> @@ -365,6 +365,7 @@ sign_verify  rsa1024  sha256  0x0301 --rsa
>  sign_verify  rsa1024  md5     0x030201:K:0080
>  sign_verify  rsa1024  sha1    0x030202:K:0080
>  sign_verify  rsa1024  sha224  0x030207:K:0080
> +expect_pass check_sign TYPE=ima KEY=rsa1024 ALG=sha256 PREFIX=0x030204aabbccdd0080 OPTS=--keyid=aabbccdd
>  sign_verify  rsa1024  sha256  0x030204:K:0080
>    try_different_keys
>    try_different_sigs

Vitaly Chikunov June 26, 2021, 12:42 a.m. UTC | #2

Mimi,

On Fri, Jun 25, 2021 at 08:21:46AM -0400, Mimi Zohar wrote:
> On Tue, 2021-05-11 at 14:56 +0300, Vitaly Chikunov wrote:
> > Allow user to set signature's keyid using `--keyid' option. Keyid should
> > correspond to SKID in certificate, when keyid is calculated using SHA-1
> > in libimaevm it may mismatch keyid extracted by the kernel from SKID of
> > certificate (the way public key is presented to the kernel), thus making
> > signatures not verifiable. This may happen when certificate is using non
> > SHA-1 SKID (see rfc7093) or just 'unique number' (see rfc5280 4.2.1.2).
> > As a last resort user may specify arbitrary keyid using the new option.
> > 
> > This commit creates ABI change for libimaevm, because of adding
> > additional parameter to imaevm_params - newer libimaevm cannot work
> > with older clients.
> 
> Thank you for highlighting the ABI change.
> 
> > 
> > Signed-off-by: Vitaly Chikunov <[e-mail]>
> > Reported-by: Elvira Khabirova <[e-mail]>
> > Reviewed-by: Stefan Berger <[e-mail]>
> > ---
> >  README                 |  1 +
> >  src/evmctl.c           | 15 +++++++++++++++
> >  src/imaevm.h           |  1 +
> >  src/libimaevm.c        |  8 +++++---
> >  tests/sign_verify.test |  1 +
> >  5 files changed, 23 insertions(+), 3 deletions(-)
> > 
> > diff --git a/README b/README
> > index 321045d..8cd66e0 100644
> > --- a/README
> > +++ b/README
> > @@ -48,6 +48,7 @@ OPTIONS
> >        --xattr-user   store xattrs in user namespace (for testing purposes)
> >        --rsa          use RSA key type and signing scheme v1
> >    -k, --key          path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)
> > +      --keyid val    overwrite signature keyid with a value (for signing)
> >    -o, --portable     generate portable EVM signatures
> >    -p, --pass         password for encrypted signing key
> >    -r, --recursive    recurse into directories (sign)
> > diff --git a/src/evmctl.c b/src/evmctl.c
> > index 7a6f202..d853d34 100644
> > --- a/src/evmctl.c
> > +++ b/src/evmctl.c
> > @@ -2514,6 +2514,7 @@ static void usage(void)
> >  		"      --xattr-user   store xattrs in user namespace (for testing purposes)\n"
> >  		"      --rsa          use RSA key type and signing scheme v1\n"
> >  		"  -k, --key          path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)\n"
> > +		"      --keyid val    overwrite signature keyid with a value (for signing)\n"
> >  		"  -o, --portable     generate portable EVM signatures\n"
> >  		"  -p, --pass         password for encrypted signing key\n"
> >  		"  -r, --recursive    recurse into directories (sign)\n"
> > @@ -2594,6 +2595,7 @@ static struct option opts[] = {
> >  	{"ignore-violations", 0, 0, 141},
> >  	{"pcrs", 1, 0, 142},
> >  	{"verify-bank", 2, 0, 143},
> > +	{"keyid", 1, 0, 144},
> >  	{}
> > 
> >  };
> > @@ -2638,6 +2640,8 @@ int main(int argc, char *argv[])
> >  {
> >  	int err = 0, c, lind;
> >  	ENGINE *eng = NULL;
> > +	unsigned long keyid;
> > +	char *eptr;
> > 
> >  #if !(OPENSSL_VERSION_NUMBER < 0x10100000)
> >  	OPENSSL_init_crypto(
> > @@ -2785,6 +2789,17 @@ int main(int argc, char *argv[])
> >  		case 143:
> >  			verify_bank = optarg;
> >  			break;
> > +		case 144:
> > +			errno = 0;
> > +			keyid = strtoul(optarg, &eptr, 16);
> > +			if (errno || eptr - optarg != strlen(optarg) ||
> 
> Before using eptr, shouldn't there be a null test?

AFAIK, strtoul() should never return NULL there. strtoul(3):

  If endptr is not NULL, strtoul() stores the address of the first
  invalid character in *endptr.  If there were no digits at all,
  strtoul() stores the original value of nptr in *endptr (and returns
  0). In particular, if *nptr is not '\0' but **endptr is '\0' on
  return, the entire string is valid.

> It's unclear what
> verifying the resulting string length against the user provided length
> provides.

It shows that whole string is parsed by strtoul, otherwise there is some
unparsed garbage, which mean this was not valid number.

> Requiring the optarg value to be prefixed with "0x" would
> simplify the strlen test.  The length would be 2 * sizeof uint + 2.  
> (The subsequent patch wouldn't need a contrived prefix.)

(I do not understand this remark at the moment.)

Base 16 will let user pass keyid just as a string, copy-pasting from
somewhere else.

> 
> > +			    keyid == ULONG_MAX || keyid > UINT_MAX ||
> 
> Why are both of these tests required?  When ULONG_MAX and UINT_MAX
> aren't the same, wouldn't ULONG_MAX always be bigger than UINT_MAX?

ULONG_MAX is special return value of strtoul. UINT_MAX is a maximum
capacity of our keyid variable. So, in the case they are different there
is two tests. This also shows that both conditions are checked, without
need to solve them in the head.

> 
> > +			    keyid == 0) {
> > +				log_err("Invalid keyid value.\n");
> > +				exit(1);
> > +			}
> > +			imaevm_params.keyid = keyid;
> > +			break;
> >  		case '?':
> >  			exit(1);
> >  			break;
> > diff --git a/src/imaevm.h b/src/imaevm.h
> > index 4503919..9f38059 100644
> > --- a/src/imaevm.h
> > +++ b/src/imaevm.h
> > @@ -196,6 +196,7 @@ struct libimaevm_params {
> >  	const char *hash_algo;
> >  	const char *keyfile;
> >  	const char *keypass;
> > +	uint32_t keyid;		/* keyid overriding value, unless 0. */
> 
> If keyid is suppose to be big endiran format, please annotate it in the
> comment.

It isn't.

> 
> >  };
> > 
> >  struct RSA_ASN1_template {
> > diff --git a/src/libimaevm.c b/src/libimaevm.c
> > index fa6c278..481d29d 100644
> > --- a/src/libimaevm.c
> > +++ b/src/libimaevm.c
> > @@ -45,6 +45,7 @@
> >  #include <sys/param.h>
> >  #include <sys/stat.h>
> >  #include <asm/byteorder.h>
> > +#include <arpa/inet.h>
> >  #include <unistd.h>
> >  #include <dirent.h>
> >  #include <string.h>
> > @@ -894,7 +895,6 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
> >  	const EVP_MD *md;
> >  	size_t sigsize;
> >  	const char *st;
> > -	uint32_t keyid;
> > 
> >  	if (!hash) {
> >  		log_err("sign_hash_v2: hash is null\n");
> > @@ -932,8 +932,10 @@ static int sign_hash_v2(const char *algo, const unsigned char *hash,
> >  		return -1;
> >  	}
> > 
> > -	calc_keyid_v2(&keyid, name, pkey);
> > -	hdr->keyid = keyid;
> > +	if (imaevm_params.keyid)
> > +		hdr->keyid = htonl(imaevm_params.keyid);
> > +	else
> > +		calc_keyid_v2(&hdr->keyid, name, pkey);
> > 
> At what point should imaevm_params.keyid be converted to big endian -
> on usage or setting it?

On usage (when storing into header).

Thanks,

> 
> Mimi
> 
> >  	st = "EVP_PKEY_CTX_new";
> >  	if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL)))
> > diff --git a/tests/sign_verify.test b/tests/sign_verify.test
> > index 3d7aa51..eccf5fa 100755
> > --- a/tests/sign_verify.test
> > +++ b/tests/sign_verify.test
> > @@ -365,6 +365,7 @@ sign_verify  rsa1024  sha256  0x0301 --rsa
> >  sign_verify  rsa1024  md5     0x030201:K:0080
> >  sign_verify  rsa1024  sha1    0x030202:K:0080
> >  sign_verify  rsa1024  sha224  0x030207:K:0080
> > +expect_pass check_sign TYPE=ima KEY=rsa1024 ALG=sha256 PREFIX=0x030204aabbccdd0080 OPTS=--keyid=aabbccdd
> >  sign_verify  rsa1024  sha256  0x030204:K:0080
> >    try_different_keys
> >    try_different_sigs
>

Mimi Zohar June 28, 2021, 8:50 p.m. UTC | #3

Hi Vitaly,

Thank you for the detailed explanation.

On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote:

> > Requiring the optarg value to be prefixed with "0x" would
> > simplify the strlen test.
> > (The subsequent patch wouldn't need a contrived prefix.)
> 
> (I do not understand this remark at the moment.)
> 
> Base 16 will let user pass keyid just as a string, copy-pasting from
> somewhere else.

strtoul() supports prefixing the ascii-hex string with "0x".  To
differentiate between a keyid and pathname, why not require the keyid
be prefixed with "0x", as opposed to requiring the pathname to be
prefixed with '@', like "--keyid @/path/to/cert.pem".

The new test would be "OPTS=--keyid=0xaabbccdd"

thanks,

Mimi

Vitaly Chikunov June 29, 2021, 1:32 a.m. UTC | #4

Mimi,

On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote:
> 
> Thank you for the detailed explanation.
> 
> On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote:
> 
> > > Requiring the optarg value to be prefixed with "0x" would
> > > simplify the strlen test.
> > > (The subsequent patch wouldn't need a contrived prefix.)
> > 
> > (I do not understand this remark at the moment.)
> > 
> > Base 16 will let user pass keyid just as a string, copy-pasting from
> > somewhere else.
> 
> strtoul() supports prefixing the ascii-hex string with "0x".  To
> differentiate between a keyid and pathname, why not require the keyid
> be prefixed with "0x", as opposed to requiring the pathname to be
> prefixed with '@', like "--keyid @/path/to/cert.pem".

I wanted to avoid (filename vs keyid) ambiguity of the argument to
`--keyid' - if user have file named "0x00112233" they would have hard
time passing it to `--keyid'. But, it's impossible to have keyid string
starting with "@". So, "@" perfectly distinguish type of `--keyid'
argument but "0x" isn't.

Also, in some software (zip, rar) "@" is common prefix meaning value
should be taken from the specified file. But, yes, "@" is not common
in Unix environments. Do you want me to create separate option like
`--keyid-from-file'?

Thanks,

> 
> The new test would be "OPTS=--keyid=0xaabbccdd"
> 
> thanks,
> 
> Mimi

Mimi Zohar June 30, 2021, 4:39 p.m. UTC | #5

Hi Vitaly,

On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote:
> Mimi,
> 
> On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote:
> > 
> > Thank you for the detailed explanation.
> > 
> > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote:
> > 
> > > > Requiring the optarg value to be prefixed with "0x" would
> > > > simplify the strlen test.
> > > > (The subsequent patch wouldn't need a contrived prefix.)
> > > 
> > > (I do not understand this remark at the moment.)
> > > 
> > > Base 16 will let user pass keyid just as a string, copy-pasting from
> > > somewhere else.
> > 
> > strtoul() supports prefixing the ascii-hex string with "0x".  To
> > differentiate between a keyid and pathname, why not require the keyid
> > be prefixed with "0x", as opposed to requiring the pathname to be
> > prefixed with '@', like "--keyid @/path/to/cert.pem".
> 
> I wanted to avoid (filename vs keyid) ambiguity of the argument to
> `--keyid' - if user have file named "0x00112233" they would have hard
> time passing it to `--keyid'. But, it's impossible to have keyid string
> starting with "@". So, "@" perfectly distinguish type of `--keyid'
> argument but "0x" isn't.
> 
> Also, in some software (zip, rar) "@" is common prefix meaning value
> should be taken from the specified file. But, yes, "@" is not common
> in Unix environments. Do you want me to create separate option like
> `--keyid-from-file'?

It's highly unlikely that both the filename and pathname would be
prefixed with "0x".  Defining a new option might be a good idea. 
Possibly naming it --extract-cert-keyid,  ---cert-keyid, or --keyid-
from-cert.  

thanks,

Mimi

Vitaly Chikunov June 30, 2021, 7:44 p.m. UTC | #6

Mimi,

On Wed, Jun 30, 2021 at 12:39:02PM -0400, Mimi Zohar wrote:
> On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote:
> > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote:
> > > 
> > > Thank you for the detailed explanation.
> > > 
> > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote:
> > > 
> > > > > Requiring the optarg value to be prefixed with "0x" would
> > > > > simplify the strlen test.
> > > > > (The subsequent patch wouldn't need a contrived prefix.)
> > > > 
> > > > (I do not understand this remark at the moment.)
> > > > 
> > > > Base 16 will let user pass keyid just as a string, copy-pasting from
> > > > somewhere else.
> > > 
> > > strtoul() supports prefixing the ascii-hex string with "0x".  To
> > > differentiate between a keyid and pathname, why not require the keyid
> > > be prefixed with "0x", as opposed to requiring the pathname to be
> > > prefixed with '@', like "--keyid @/path/to/cert.pem".
> > 
> > I wanted to avoid (filename vs keyid) ambiguity of the argument to
> > `--keyid' - if user have file named "0x00112233" they would have hard
> > time passing it to `--keyid'. But, it's impossible to have keyid string
> > starting with "@". So, "@" perfectly distinguish type of `--keyid'
> > argument but "0x" isn't.
> > 
> > Also, in some software (zip, rar) "@" is common prefix meaning value
> > should be taken from the specified file. But, yes, "@" is not common
> > in Unix environments. Do you want me to create separate option like
> > `--keyid-from-file'?
> 
> It's highly unlikely that both the filename and pathname would be
> prefixed with "0x".  Defining a new option might be a good idea. 
> Possibly naming it --extract-cert-keyid,  ---cert-keyid, or --keyid-
> from-cert.  

It's not unlikely, because people may want to keep cert files named or
symlinked by keyid. (For example, local cert database keep cert files
symlinked like `f30dd6ad.0'.)

I will add an option, most understandable, perhaps, is `--keyid-from-cert'.

Also, I will remove base 16 from --keyid argument.

Thanks,

> 
> thanks,
> 
> Mimi

Mimi Zohar June 30, 2021, 8:47 p.m. UTC | #7

Hi Vitaly,

On Wed, 2021-06-30 at 22:44 +0300, Vitaly Chikunov wrote:
> On Wed, Jun 30, 2021 at 12:39:02PM -0400, Mimi Zohar wrote:
> > On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote:
> > > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote:
> > > > 
> > > > Thank you for the detailed explanation.
> > > > 
> > > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote:
> > > > 
> > > > > > Requiring the optarg value to be prefixed with "0x" would
> > > > > > simplify the strlen test.
> > > > > > (The subsequent patch wouldn't need a contrived prefix.)
> > > > > 
> > > > > (I do not understand this remark at the moment.)
> > > > > 
> > > > > Base 16 will let user pass keyid just as a string, copy-pasting from
> > > > > somewhere else.
> > > > 
> > > > strtoul() supports prefixing the ascii-hex string with "0x".  To
> > > > differentiate between a keyid and pathname, why not require the keyid
> > > > be prefixed with "0x", as opposed to requiring the pathname to be
> > > > prefixed with '@', like "--keyid @/path/to/cert.pem".
> > > 
> > > I wanted to avoid (filename vs keyid) ambiguity of the argument to
> > > `--keyid' - if user have file named "0x00112233" they would have hard
> > > time passing it to `--keyid'. But, it's impossible to have keyid string
> > > starting with "@". So, "@" perfectly distinguish type of `--keyid'
> > > argument but "0x" isn't.
> > > 
> > > Also, in some software (zip, rar) "@" is common prefix meaning value
> > > should be taken from the specified file. But, yes, "@" is not common
> > > in Unix environments. Do you want me to create separate option like
> > > `--keyid-from-file'?
> > 
> > It's highly unlikely that both the filename and pathname would be
> > prefixed with "0x".  Defining a new option might be a good idea. 
> > Possibly naming it --extract-cert-keyid,  ---cert-keyid, or --keyid-
> > from-cert.  
> 
> It's not unlikely, because people may want to keep cert files named or
> symlinked by keyid. (For example, local cert database keep cert files
> symlinked like `f30dd6ad.0'.)
> 
> I will add an option, most understandable, perhaps, is `--keyid-from-cert'.
> 
> Also, I will remove base 16 from --keyid argument.

I must be missing something.  "openssl x509", "keyctl show
%keyring:<keyring name>", and "getfattr -m security.ima -e hex --dump"  
all display the skid in hex.  Why would anyone provide the skid as
something other than in hex?

thanks,

Mimi

Vitaly Chikunov June 30, 2021, 9:10 p.m. UTC | #8

Mimi,

On Wed, Jun 30, 2021 at 04:47:53PM -0400, Mimi Zohar wrote:
> On Wed, 2021-06-30 at 22:44 +0300, Vitaly Chikunov wrote:
> > On Wed, Jun 30, 2021 at 12:39:02PM -0400, Mimi Zohar wrote:
> > > On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote:
> > > > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote:
> > > > > 
> > > > > Thank you for the detailed explanation.
> > > > > 
> > > > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote:
> > > > > 
> > > > > > > Requiring the optarg value to be prefixed with "0x" would
> > > > > > > simplify the strlen test.
> > > > > > > (The subsequent patch wouldn't need a contrived prefix.)
> > > > > > 
> > > > > > (I do not understand this remark at the moment.)
> > > > > > 
> > > > > > Base 16 will let user pass keyid just as a string, copy-pasting from
> > > > > > somewhere else.
> > > > > 
> > > > > strtoul() supports prefixing the ascii-hex string with "0x".  To
> > > > > differentiate between a keyid and pathname, why not require the keyid
> > > > > be prefixed with "0x", as opposed to requiring the pathname to be
> > > > > prefixed with '@', like "--keyid @/path/to/cert.pem".
> > > > 
> > > > I wanted to avoid (filename vs keyid) ambiguity of the argument to
> > > > `--keyid' - if user have file named "0x00112233" they would have hard
> > > > time passing it to `--keyid'. But, it's impossible to have keyid string
> > > > starting with "@". So, "@" perfectly distinguish type of `--keyid'
> > > > argument but "0x" isn't.
> > > > 
> > > > Also, in some software (zip, rar) "@" is common prefix meaning value
> > > > should be taken from the specified file. But, yes, "@" is not common
> > > > in Unix environments. Do you want me to create separate option like
> > > > `--keyid-from-file'?
> > > 
> > > It's highly unlikely that both the filename and pathname would be
> > > prefixed with "0x".  Defining a new option might be a good idea. 
> > > Possibly naming it --extract-cert-keyid,  ---cert-keyid, or --keyid-
> > > from-cert.  
> > 
> > It's not unlikely, because people may want to keep cert files named or
> > symlinked by keyid. (For example, local cert database keep cert files
> > symlinked like `f30dd6ad.0'.)
> > 
> > I will add an option, most understandable, perhaps, is `--keyid-from-cert'.
> > 
> > Also, I will remove base 16 from --keyid argument.
> 
> I must be missing something.  "openssl x509", "keyctl show
> %keyring:<keyring name>", and "getfattr -m security.ima -e hex --dump"  
> all display the skid in hex.  Why would anyone provide the skid as
> something other than in hex?

Ah, I thought you want '0x' prefix mandatory. Will not remove base 16
then. Also, /proc/keys shows keyid without '0x' prefix.

Thanks,


> 
> thanks,
> 
> Mimi 
>

Mimi Zohar June 30, 2021, 9:32 p.m. UTC | #9

On Thu, 2021-07-01 at 00:10 +0300, Vitaly Chikunov wrote:
> Mimi,
> 
> On Wed, Jun 30, 2021 at 04:47:53PM -0400, Mimi Zohar wrote:
> > On Wed, 2021-06-30 at 22:44 +0300, Vitaly Chikunov wrote:
> > > On Wed, Jun 30, 2021 at 12:39:02PM -0400, Mimi Zohar wrote:
> > > > On Tue, 2021-06-29 at 04:32 +0300, Vitaly Chikunov wrote:
> > > > > On Mon, Jun 28, 2021 at 04:50:42PM -0400, Mimi Zohar wrote:
> > > > > > 
> > > > > > Thank you for the detailed explanation.
> > > > > > 
> > > > > > On Sat, 2021-06-26 at 03:42 +0300, Vitaly Chikunov wrote:
> > > > > > 
> > > > > > > > Requiring the optarg value to be prefixed with "0x" would
> > > > > > > > simplify the strlen test.
> > > > > > > > (The subsequent patch wouldn't need a contrived prefix.)
> > > > > > > 
> > > > > > > (I do not understand this remark at the moment.)
> > > > > > > 
> > > > > > > Base 16 will let user pass keyid just as a string, copy-pasting from
> > > > > > > somewhere else.
> > > > > > 
> > > > > > strtoul() supports prefixing the ascii-hex string with "0x".  To
> > > > > > differentiate between a keyid and pathname, why not require the keyid
> > > > > > be prefixed with "0x", as opposed to requiring the pathname to be
> > > > > > prefixed with '@', like "--keyid @/path/to/cert.pem".
> > > > > 
> > > > > I wanted to avoid (filename vs keyid) ambiguity of the argument to
> > > > > `--keyid' - if user have file named "0x00112233" they would have hard
> > > > > time passing it to `--keyid'. But, it's impossible to have keyid string
> > > > > starting with "@". So, "@" perfectly distinguish type of `--keyid'
> > > > > argument but "0x" isn't.
> > > > > 
> > > > > Also, in some software (zip, rar) "@" is common prefix meaning value
> > > > > should be taken from the specified file. But, yes, "@" is not common
> > > > > in Unix environments. Do you want me to create separate option like
> > > > > `--keyid-from-file'?
> > > > 
> > > > It's highly unlikely that both the filename and pathname would be
> > > > prefixed with "0x".  Defining a new option might be a good idea. 
> > > > Possibly naming it --extract-cert-keyid,  ---cert-keyid, or --keyid-
> > > > from-cert.  
> > > 
> > > It's not unlikely, because people may want to keep cert files named or
> > > symlinked by keyid. (For example, local cert database keep cert files
> > > symlinked like `f30dd6ad.0'.)
> > > 
> > > I will add an option, most understandable, perhaps, is `--keyid-from-cert'.
> > > 
> > > Also, I will remove base 16 from --keyid argument.
> > 
> > I must be missing something.  "openssl x509", "keyctl show
> > %keyring:<keyring name>", and "getfattr -m security.ima -e hex --dump"  
> > all display the skid in hex.  Why would anyone provide the skid as
> > something other than in hex?
> 
> Ah, I thought you want '0x' prefix mandatory. Will not remove base 16
> then. Also, /proc/keys shows keyid without '0x' prefix.

Why?  One doesn't preclude the other.   "keyid = strtoul(optarg, &eptr,
16);" recognizes an "0x" prefixed string as being ascii-hex.

Mimi

Patch

diff --git a/README b/README
index 321045d..8cd66e0 100644
--- a/README
+++ b/README
@@ -48,6 +48,7 @@  OPTIONS
       --xattr-user   store xattrs in user namespace (for testing purposes)
       --rsa          use RSA key type and signing scheme v1
   -k, --key          path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)
+      --keyid val    overwrite signature keyid with a value (for signing)
   -o, --portable     generate portable EVM signatures
   -p, --pass         password for encrypted signing key
   -r, --recursive    recurse into directories (sign)
diff --git a/src/evmctl.c b/src/evmctl.c
index 7a6f202..d853d34 100644
--- a/src/evmctl.c
+++ b/src/evmctl.c
@@ -2514,6 +2514,7 @@  static void usage(void)
 		"      --xattr-user   store xattrs in user namespace (for testing purposes)\n"
 		"      --rsa          use RSA key type and signing scheme v1\n"
 		"  -k, --key          path to signing key (default: /etc/keys/{privkey,pubkey}_evm.pem)\n"
+		"      --keyid val    overwrite signature keyid with a value (for signing)\n"
 		"  -o, --portable     generate portable EVM signatures\n"
 		"  -p, --pass         password for encrypted signing key\n"
 		"  -r, --recursive    recurse into directories (sign)\n"
@@ -2594,6 +2595,7 @@  static struct option opts[] = {
 	{"ignore-violations", 0, 0, 141},
 	{"pcrs", 1, 0, 142},
 	{"verify-bank", 2, 0, 143},
+	{"keyid", 1, 0, 144},
 	{}
 
 };
@@ -2638,6 +2640,8 @@  int main(int argc, char *argv[])
 {
 	int err = 0, c, lind;
 	ENGINE *eng = NULL;
+	unsigned long keyid;
+	char *eptr;
 
 #if !(OPENSSL_VERSION_NUMBER < 0x10100000)
 	OPENSSL_init_crypto(
@@ -2785,6 +2789,17 @@  int main(int argc, char *argv[])
 		case 143:
 			verify_bank = optarg;
 			break;
+		case 144:
+			errno = 0;
+			keyid = strtoul(optarg, &eptr, 16);
+			if (errno || eptr - optarg != strlen(optarg) ||
+			    keyid == ULONG_MAX || keyid > UINT_MAX ||
+			    keyid == 0) {
+				log_err("Invalid keyid value.\n");
+				exit(1);
+			}
+			imaevm_params.keyid = keyid;
+			break;
 		case '?':
 			exit(1);
 			break;
diff --git a/src/imaevm.h b/src/imaevm.h
index 4503919..9f38059 100644
--- a/src/imaevm.h
+++ b/src/imaevm.h
@@ -196,6 +196,7 @@  struct libimaevm_params {
 	const char *hash_algo;
 	const char *keyfile;
 	const char *keypass;
+	uint32_t keyid;		/* keyid overriding value, unless 0. */
 };
 
 struct RSA_ASN1_template {
diff --git a/src/libimaevm.c b/src/libimaevm.c
index fa6c278..481d29d 100644
--- a/src/libimaevm.c
+++ b/src/libimaevm.c
@@ -45,6 +45,7 @@ 
 #include <sys/param.h>
 #include <sys/stat.h>
 #include <asm/byteorder.h>
+#include <arpa/inet.h>
 #include <unistd.h>
 #include <dirent.h>
 #include <string.h>
@@ -894,7 +895,6 @@  static int sign_hash_v2(const char *algo, const unsigned char *hash,
 	const EVP_MD *md;
 	size_t sigsize;
 	const char *st;
-	uint32_t keyid;
 
 	if (!hash) {
 		log_err("sign_hash_v2: hash is null\n");
@@ -932,8 +932,10 @@  static int sign_hash_v2(const char *algo, const unsigned char *hash,
 		return -1;
 	}
 
-	calc_keyid_v2(&keyid, name, pkey);
-	hdr->keyid = keyid;
+	if (imaevm_params.keyid)
+		hdr->keyid = htonl(imaevm_params.keyid);
+	else
+		calc_keyid_v2(&hdr->keyid, name, pkey);
 
 	st = "EVP_PKEY_CTX_new";
 	if (!(ctx = EVP_PKEY_CTX_new(pkey, NULL)))
diff --git a/tests/sign_verify.test b/tests/sign_verify.test
index 3d7aa51..eccf5fa 100755
--- a/tests/sign_verify.test
+++ b/tests/sign_verify.test
@@ -365,6 +365,7 @@  sign_verify  rsa1024  sha256  0x0301 --rsa
 sign_verify  rsa1024  md5     0x030201:K:0080
 sign_verify  rsa1024  sha1    0x030202:K:0080
 sign_verify  rsa1024  sha224  0x030207:K:0080
+expect_pass check_sign TYPE=ima KEY=rsa1024 ALG=sha256 PREFIX=0x030204aabbccdd0080 OPTS=--keyid=aabbccdd
 sign_verify  rsa1024  sha256  0x030204:K:0080
   try_different_keys
   try_different_sigs