Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2018-04-09 at 15:10 +0100, Martin Townsend wrote:
> Hi Mimi,
> 
> On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> > On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote:
> >> Hi,
> >>
> >> I'm trying to get to the bottom of an issue I'm seeing when enabling
> >> the CAAM in the kernel with IMA/EVM enabled.  I'm using the official
> >> NXP (imx_4.9.11_1.0.0_ga) vendor Kernel.
> >>
> >> Here's the error message I'm getting.
> >>
> >> caam_jr 2142000.jr1: 40000789: DECO: desc idx 7: Protocol Size Error -
> >> A protocol has seen an error in size. When running RSA, pdb size N <
> >> (size of F) when no formatting is used; or pdb size N < (F + 11) when
> >> formatting is used.
> >> integrity: Problem loading X.509 certificate (-129): /etc/keys/ima-x509.der
> >
> > This error message indicates that the kernel is trying to load a key
> > onto the IMA keyring, but any key added to the trusted IMA keyring
> > (.ima) must be signed by a key on the builtin (or secondary) keyring.
> >
> > Please verify that the public key used to sign the ima-x509.der is on
> > the builtin keyring (eg. "keyctl show %keyring:.builtin_trusted_keys)
> > or the secondary keyring.  Depending on how the kernel was configured,
> > loading the public CA onto the builtin (or secondary) keyring might be
> > possible.
> >
> > Some distros are carrying patches which load the UEFI keys onto the
> > secondary keyring.  The other (preferred) method would be to insert
> > the CA certificate into the kernel and resign the kernel.  This
> > requires reserving memory for the key when the kernel is built.
> >
> > CONFIG_SYSTEM_EXTRA_CERTIFICATE=y
> > CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE=4096
> >
> > Mimi
> 
> I think the integrity error message is a side effect of the previous
> error, ie we are getting this error message because the CAAM is
> failing to verify the certificates signature and hence IMA fails to
> load the certificate onto the keyring.  If I disable CAAM then
> everything works as expected.

Thanks!

> What I'm trying to get to the bottom of
> is why CAAM is failing to verify the signature.  Further below in the
> email I have determined that the signature is 257 bytes do you think
> this is correct?

Sorry, I'm not going to be of much help here.  Remember everything
that CAAM uses (eg. kernel crypto modules) must be builtin to the
kernel until a key is loaded onto to the IMA keyring.  Perhaps
enabling pr_devel/pr_debug in crypto/asymmetric_keys/ might provide
some additional information.

Mimi


> I've read a post here:
> https://crypto.stackexchange.com/questions/3505/what-is-the-length-of-an-rsa-signature

> That says that for PKCS#1 the signature should always be of the size
> of the modulus, then it goes on to say: "In some protocols, there can
> be some wrapping around the signature, e.g. to indicate which
> algorithm was used,"  I'm wondering if that's what I'm seeing, an
> extra byte in the signature that is the type of algorithm used but
> this extra byte is also passed to the CAAM and causes it to fail as
> then the signature is now larger than the modulus.  But I don't know
> what I can do about this, I'm not even sure what protocol is being
> used to generate this extra byte, any suggestions on how to find this
> out would be appreciated.
> 
> >
> >
> >> I put a dump_stack in the error handling routine in CAAM and in the
> >> caam_jr_enqueue to get (I removed some of the caam_jr_enqueue
> >> dump_stacks during initialisation to highlight the one of interest)
> >>
> >> caam 2140000.caam: ERA source: CCBVID.
> >> caam 2140000.caam: Entropy delay = 3200
> >> caam 2140000.caam: Instantiated RNG4 SH0
> >> caam 2140000.caam: Instantiated RNG4 SH1
> >> caam 2140000.caam: device ID = 0x0a16030000000000 (Era 8)
> >> caam 2140000.caam: job rings = 3, qi = 0
> >> caam algorithms registered in /proc/crypto
> >> caam_jr_enqueue
> >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4
> >> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> >> caam_jr_enqueue
> >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4
> >> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> >> caam_jr 2141000.jr0: registering rng-caam
> >> caam 2140000.caam: caam pkc algorithms registered in /proc/crypto
> >> caam_jr_enqueue
> >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4
> >> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> >> caam_rsa_set_pub_key
> >> caam_rsa_max_size
> >> caam_rsa_enc
> >> caam_jr_enqueue
> >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4
> >> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> >> [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14)
> >> [<8010b8cc>] (show_stack) from [<80608f74>] (caam_jr_enqueue+0x3c/0x2bc)
> >> [<80608f74>] (caam_jr_enqueue) from [<8061fb84>] (caam_rsa_enc+0x210/0x3ac)
> >> [<8061fb84>] (caam_rsa_enc) from [<803ed910>] (pkcs1pad_verify+0xa8/0xe4)
> >> [<803ed910>] (pkcs1pad_verify) from [<804134e4>]
> >> (public_key_verify_signature+0x17c/0x248)
> >> [<804134e4>] (public_key_verify_signature) from [<804132a0>]
> >> (restrict_link_by_signature+0xa8/0xd4)
> >> [<804132a0>] (restrict_link_by_signature) from [<803cadd4>]
> >> (key_create_or_update+0x12c/0x370)
> >> [<803cadd4>] (key_create_or_update) from [<80c253a0>]
> >> (integrity_load_x509+0x70/0xc4)
> >> [<80c253a0>] (integrity_load_x509) from [<80c256bc>] (ima_load_x509+0x28/0x3c)
> >> [<80c256bc>] (ima_load_x509) from [<80c2510c>] (integrity_load_keys+0x8/0x10)
> >> [<80c2510c>] (integrity_load_keys) from [<80c00de0>]
> >> (kernel_init_freeable+0x1bc/0x1cc)
> >> [<80c00de0>] (kernel_init_freeable) from [<80844ccc>] (kernel_init+0x8/0x114)
> >> [<80844ccc>] (kernel_init) from [<801078d8>] (ret_from_fork+0x14/0x3c)
> >> CPU: 0 PID: 112 Comm: irq/214-2142000 Not tainted 4.9.11-1.0.0+gc27010d #4
> >> Hardware name: Freescale i.MX6 UltraLite (Device Tree)
> >> [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14)
> >> [<8010b8cc>] (show_stack) from [<8060a0e8>] (report_deco_status+0x30/0xf8)
> >> [<8060a0e8>] (report_deco_status) from [<8061f3c8>] (rsa_pub_done+0x20/0x60)
> >> [<8061f3c8>] (rsa_pub_done) from [<80608d94>] (caam_jr_threadirq+0x1dc/0x29c)
> >> [<80608d94>] (caam_jr_threadirq) from [<80165dcc>] (irq_thread_fn+0x1c/0x54)
> >> [<80165dcc>] (irq_thread_fn) from [<80166024>] (irq_thread+0x114/0x1d4)
> >> [<80166024>] (irq_thread) from [<801415b4>] (kthread+0xe4/0xec)
> >> [<801415b4>] (kthread) from [<801078d8>] (ret_from_fork+0x14/0x3c)
> >> caam_jr 2142000.jr1: 40000789: DECO: desc idx 7: Protocol Size Error -
> >> A protocol has seen an error in size. When running RSA, pdb size N <
> >> (size of F) when no formatting is used; or pdb size N < (F + 11) when
> >> formatting is used.
> >> integrity: Problem loading X.509 certificate (-129): /etc/keys/ima-x509.der
> >> [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14)
> >> [<8010b8cc>] (show_stack) from [<8060a0d0>] (report_deco_status+0x30/0xf8)
> >> [<8060a0d0>] (report_deco_status) from [<8061db94>] (rsa_pub_done+0x20/0x60)
> >> [<8061db94>] (rsa_pub_done) from [<80608d94>] (caam_jr_threadirq+0x1dc/0x29c)
> >> [<80608d94>] (caam_jr_threadirq) from [<80165dcc>] (irq_thread_fn+0x1c/0x54)
> >> [<80165dcc>] (irq_thread_fn) from [<80166024>] (irq_thread+0x114/0x1d4)
> >> [<80166024>] (irq_thread) from [<801415b4>] (kthread+0xe4/0xec)
> >> [<801415b4>] (kthread) from [<801078d8>] (ret_from_fork+0x14/0x3c)
> >>
> >> So it's failing to verify the signature on my x509 certificate because
> >> pdb size M < (size of F) ...
> >>
> >> On the NXP mailing lists there is someone with a similar issue and the
> >> response was
> >> “The error appears to be saying that the public RSA modulus is shorter
> >> than the signature being verified.
> >>
> >> RSA uses modular arithmetic, and all valid values are smaller than the
> >> public RSA modulus. However, the signature (F in the error message
> >> below), is too large.
> >>
> >> The customer should try to determine why their public RSA Modulus (N)
> >> is shorter than the signature (F).”
> >>
> >> I have to admit I'm not really sure what this means, I've created my
> >> certificate using openssl and a configuration file (shown below) that
> >> set the keysize to 2048 bits so I'm not sure how the signature in the
> >> x509 is greater than the RSA modulus which in my limited understanding
> >> is the key size in bits.
> >>
> >> I added the following to public_key_verify_signature()
> >>
> >> printk("%s: Public Key: Keylen: %u\n", __func__, pkey->keylen);
> >> printk("%s: Signature: %u\n", __func__, sig->s_size);
> >>
> >> and get
> >>
> >> public_key_verify_signature: Public Key: Keylen: 270
> >> public_key_verify_signature: Signature: 257
> >>
> >> I'm assuming they are both in bytes which kind of suggests the key
> >> length is larger than the signature but then again this keylen may
> >> include other information.  I'm a bit suspicious of the signature
> >> length of 257 maybe this is causing the problem which could point to
> >> creating the certificate incorrectly??  Here's the configuration I'm
> >> using for the root cert:
> >> [ ca ]
> >> default_ca                      = CA_default
> >>
> >> [ CA_default ]
> >> dir                             = ./ca
> >>
> >> certs                           = $dir/certsdb                  #
> >> Where the issued certs are kept
> >> new_certs_dir                   = $certs                        #
> >> default place for new certs.
> >> database                        = $dir/certdbindex.txt          #
> >> database index file.
> >> certificate                     = $dir/certs/ima-local-ca.x509  # The
> >> CA certificate
> >> private_key                     = $dir/private/ca-privkey.pem   # The
> >> private key
> >> default_days                    = 3650
> >> default_md                      = sha256
> >> preserve                        = no
> >> email_in_dn                     = no
> >> nameopt                         = default_ca
> >> certopt                         = default_ca
> >> policy                          = policy_ima_ca
> >>
> >> [ policy_ima_ca ]
> >> countryName                     = match                   # Must be
> >> the same as the CA
> >> stateOrProvinceName             = match                   # Must be
> >> the same as the CA
> >> organizationName                = supplied
> >> organizationalUnitName          = optional
> >> commonName                      = supplied                # Must be there
> >> emailAddress                    = optional
> >>
> >> [ req ]
> >> default_bits                    = 2048                    # Size of keys
> >> default_keyfile                 = privkey.pem             # name of
> >> generated keys
> >> string_mask                     = utf8only                # permitted characters
> >> distinguished_name              = req_distinguished_name  # where to
> >> get DN for reqs
> >> prompt                          = no                      # No prompting
> >> x509_extensions                 = v3_ca                   # The
> >> extentions to add to self signed certs
> >> req_extensions                  = v3_req                  # The
> >> extensions to add to req's
> >>
> >> [ req_distinguished_name ]
> >> O                               = xxx
> >> OU                              = IMA
> >> CN                              = xxx IMA-EVM Root CA
> >> emailAddress                    = ca-ima-evm@xxxxxxx
> >> L                               = xxx
> >> ST                              = Dorset
> >> C                               = xxx
> >>
> >> [ v3_ca ]
> >> basicConstraints                = CA:TRUE
> >> subjectKeyIdentifier            = hash
> >> authorityKeyIdentifier          = keyid:always,issuer:always
> >> subjectAltName                  = email:move
> >>
> >> [ v3_req ]
> >> subjectAltName=email:move
> >>
> >>
> >> Then the openssl (1.0.2n  7 Dec 2017) command to create the self
> >> signed root CA certificate.
> >>
> >> openssl req -new -x509 -utf8 -sha256 \
> >>             -days $((365 * $duration)) \
> >>             -passout file:$rootcadir/private/key_pass.txt \
> >>             -keyout $rootca_privkey \
> >>             -outform DER \
> >>             -out $rootca_pubcert_der \
> >>             -config $rootcadir/$ima_root_openssl_cnf
> >>
> >> I'm not sure what I can do further to debug this so any help or
> >> suggestions would be really appreciated.  If there is any further
> >> debug that would help let me know and I'll try it out.
> >>
> >> Many Thanks,
> >> Martin.
> >>
> >
> 




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux