1. 19 2月, 2013 3 次提交
  2. 04 2月, 2013 1 次提交
  3. 20 1月, 2013 2 次提交
  4. 06 12月, 2012 6 次提交
  5. 09 11月, 2012 2 次提交
  6. 24 10月, 2012 7 次提交
  7. 15 10月, 2012 3 次提交
  8. 11 10月, 2012 1 次提交
  9. 10 10月, 2012 3 次提交
  10. 08 10月, 2012 7 次提交
    • D
      X.509: Add a crypto key parser for binary (DER) X.509 certificates · c26fd69f
      David Howells 提交于
      Add a crypto key parser for binary (DER) encoded X.509 certificates.  The
      certificate is parsed and, if possible, the signature is verified.
      
      An X.509 key can be added like this:
      
      	# keyctl padd crypto bar @s </tmp/x509.cert
      	15768135
      
      and displayed like this:
      
      	# cat /proc/keys
      	00f09a47 I--Q---     1 perm 39390000     0     0 asymmetri bar: X509.RSA e9fd6d08 []
      
      Note that this only works with binary certificates.  PEM encoded certificates
      are ignored by the parser.
      
      Note also that the X.509 key ID is not congruent with the PGP key ID, but for
      the moment, they will match.
      
      If a NULL or "" name is given to add_key(), then the parser will generate a key
      description from the CertificateSerialNumber and Name fields of the
      TBSCertificate:
      
      	00aefc4e I--Q---     1 perm 39390000     0     0 asymmetri bfbc0cd76d050ea4:/C=GB/L=Cambridge/O=Red Hat/CN=kernel key: X509.RSA 0c688c7b []
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      c26fd69f
    • D
      RSA: Fix signature verification for shorter signatures · 0b1568a4
      David Howells 提交于
      gpg can produce a signature file where length of signature is less than the
      modulus size because the amount of space an MPI takes up is kept as low as
      possible by discarding leading zeros.  This regularly happens for several
      modules during the build.
      
      Fix it by relaxing check in RSA verification code.
      
      Thanks to Tomas Mraz and Miloslav Trmac for help.
      Signed-off-by: NMilan Broz <mbroz@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      0b1568a4
    • D
      RSA: Implement signature verification algorithm [PKCS#1 / RFC3447] · 612e0fe9
      David Howells 提交于
      Implement RSA public key cryptography [PKCS#1 / RFC3447].  At this time, only
      the signature verification algorithm is supported.  This uses the asymmetric
      public key subtype to hold its key data.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      612e0fe9
    • D
      KEYS: Provide signature verification with an asymmetric key · 4ae71c1d
      David Howells 提交于
      Provide signature verification using an asymmetric-type key to indicate the
      public key to be used.
      
      The API is a single function that can be found in crypto/public_key.h:
      
      	int verify_signature(const struct key *key,
      			     const struct public_key_signature *sig)
      
      The first argument is the appropriate key to be used and the second argument
      is the parsed signature data:
      
      	struct public_key_signature {
      		u8 *digest;
      		u16 digest_size;
      		enum pkey_hash_algo pkey_hash_algo : 8;
      		union {
      			MPI mpi[2];
      			struct {
      				MPI s;		/* m^d mod n */
      			} rsa;
      			struct {
      				MPI r;
      				MPI s;
      			} dsa;
      		};
      	};
      
      This should be filled in prior to calling the function.  The hash algorithm
      should already have been called and the hash finalised and the output should
      be in a buffer pointed to by the 'digest' member.
      
      Any extra data to be added to the hash by the hash format (eg. PGP) should
      have been added by the caller prior to finalising the hash.
      
      It is assumed that the signature is made up of a number of MPI values.  If an
      algorithm becomes available for which this is not the case, the above structure
      will have to change.
      
      It is also assumed that it will have been checked that the signature algorithm
      matches the key algorithm.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      4ae71c1d
    • D
      KEYS: Asymmetric public-key algorithm crypto key subtype · a9681bf3
      David Howells 提交于
      Add a subtype for supporting asymmetric public-key encryption algorithms such
      as DSA (FIPS-186) and RSA (PKCS#1 / RFC1337).
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      a9681bf3
    • D
      KEYS: Asymmetric key pluggable data parsers · 46c6f177
      David Howells 提交于
      The instantiation data passed to the asymmetric key type are expected to be
      formatted in some way, and there are several possible standard ways to format
      the data.
      
      The two obvious standards are OpenPGP keys and X.509 certificates.  The latter
      is especially useful when dealing with UEFI, and the former might be useful
      when dealing with, say, eCryptfs.
      
      Further, it might be desirable to provide formatted blobs that indicate
      hardware is to be accessed to retrieve the keys or that the keys live
      unretrievably in a hardware store, but that the keys can be used by means of
      the hardware.
      
      From userspace, the keys can be loaded using the keyctl command, for example,
      an X.509 binary certificate:
      
      	keyctl padd asymmetric foo @s <dhowells.pem
      
      or a PGP key:
      
      	keyctl padd asymmetric bar @s <dhowells.pub
      
      or a pointer into the contents of the TPM:
      
      	keyctl add asymmetric zebra "TPM:04982390582905f8" @s
      
      Inside the kernel, pluggable parsers register themselves and then get to
      examine the payload data to see if they can handle it.  If they can, they get
      to:
      
        (1) Propose a name for the key, to be used it the name is "" or NULL.
      
        (2) Specify the key subtype.
      
        (3) Provide the data for the subtype.
      
      The key type asks the parser to do its stuff before a key is allocated and thus
      before the name is set.  If successful, the parser stores the suggested data
      into the key_preparsed_payload struct, which will be either used (if the key is
      successfully created and instantiated or updated) or discarded.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      46c6f177
    • D
      KEYS: Implement asymmetric key type · 964f3b3b
      David Howells 提交于
      Create a key type that can be used to represent an asymmetric key type for use
      in appropriate cryptographic operations, such as encryption, decryption,
      signature generation and signature verification.
      
      The key type is "asymmetric" and can provide access to a variety of
      cryptographic algorithms.
      
      Possibly, this would be better as "public_key" - but that has the disadvantage
      that "public key" is an overloaded term.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      964f3b3b
  11. 03 10月, 2012 1 次提交
  12. 27 9月, 2012 4 次提交