13 Aug, 2015

3 commits

  • A PKCS#7 or CMS message can have per-signature authenticated attributes
    that are digested as a lump and signed by the authorising key for that
    signature. If such attributes exist, the content digest isn't itself
    signed, but rather it is included in a special authattr which then
    contributes to the signature.

    Further, we already require the master message content type to be
    pkcs7_signedData - but there's also a separate content type for the data
    itself within the SignedData object and this must be repeated inside the
    authattrs for each signer [RFC2315 9.2, RFC5652 11.1].

    We should really validate the authattrs if they exist or forbid them
    entirely as appropriate. To this end:

    (1) Alter the PKCS#7 parser to reject any message that has more than one
    signature where at least one signature has authattrs and at least one
    that does not.

    (2) Validate authattrs if they are present and strongly restrict them.
    Only the following authattrs are permitted and all others are
    rejected:

    (a) contentType. This is checked to be an OID that matches the
    content type in the SignedData object.

    (b) messageDigest. This must match the crypto digest of the data.

    (c) signingTime. If present, we check that this is a valid, parseable
    UTCTime or GeneralTime and that the date it encodes fits within
    the validity window of the matching X.509 cert.

    (d) S/MIME capabilities. We don't check the contents.

    (e) Authenticode SP Opus Info. We don't check the contents.

    (f) Authenticode Statement Type. We don't check the contents.

    The message is rejected if (a) or (b) are missing. If the message is
    an Authenticode type, the message is rejected if (e) is missing; if
    not Authenticode, the message is rejected if (d) - (f) are present.

    The S/MIME capabilities authattr (d) unfortunately has to be allowed
    to support kernels already signed by the pesign program. This only
    affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).

    The message is also rejected if an authattr is given more than once or
    if it contains more than one element in its set of values.

    (3) Add a parameter to pkcs7_verify() to select one of the following
    restrictions and pass in the appropriate option from the callers:

    (*) VERIFYING_MODULE_SIGNATURE

    This requires that the SignedData content type be pkcs7-data and
    forbids authattrs. sign-file sets CMS_NOATTR. We could be more
    flexible and permit authattrs optionally, but only permit minimal
    content.

    (*) VERIFYING_FIRMWARE_SIGNATURE

    This requires that the SignedData content type be pkcs7-data and
    requires authattrs. In future, this will require an attribute
    holding the target firmware name in addition to the minimal set.

    (*) VERIFYING_UNSPECIFIED_SIGNATURE

    This requires that the SignedData content type be pkcs7-data but
    allows either no authattrs or only permits the minimal set.

    (*) VERIFYING_KEXEC_PE_SIGNATURE

    This only supports the Authenticode SPC_INDIRECT_DATA content type
    and requires at least an SpcSpOpusInfo authattr in addition to the
    minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
    an S/MIME capabilities authattr because the pesign program doesn't
    remove these).

    (*) VERIFYING_KEY_SIGNATURE
    (*) VERIFYING_KEY_SELF_SIGNATURE

    These are invalid in this context but are included for later use
    when limiting the use of X.509 certs.

    (4) The pkcs7_test key type is given a module parameter to select between
    the above options for testing purposes. For example:

    echo 1 >/sys/module/pkcs7_test_key/parameters/usage
    keyctl padd pkcs7_test foo @s
    Signed-off-by: David Howells
    Reviewed-by: Marcel Holtmann
    Reviewed-by: David Woodhouse

    David Howells
     
  • Since CMS is an evolution of PKCS#7, with much of the ASN.1 being
    compatible, add support for CMS signed-data messages also [RFC5652 sec 5].

    Signed-off-by: David Howells
    Reviewed-By: David Woodhouse

    David Howells
     
  • We only support PKCS#7 signed-data [RFC2315 sec 9] content at the top level,
    so reject anything else. Further, check that the version numbers in
    SignedData and SignerInfo are 1 in both cases.

    Note that we don't restrict the inner content type. In the PKCS#7 code we
    don't parse the data attached there, but merely verify the signature over
    it.

    Signed-off-by: David Howells
    Reviewed-By: David Woodhouse

    David Howells
     

08 Jul, 2014

1 commit