ELFSIGN(1) User Commands ELFSIGN(1)

NAME


elfsign - sign binaries

SYNOPSIS


/usr/bin/elfsign sign [-a] [-v] -k private_key -c certificate_file
-e elf_object [-F format] [file]...


/usr/bin/elfsign sign [-a] [-v] -c certificate_file
-e elf_object -T token_label [-P pin_file] [-F format] [file]...


/usr/bin/elfsign verify [-c certificate_file]
[-v] -e elf_object [file]...


/usr/bin/elfsign request -r certificate_request_file
{-k private_key | -T token_label}


/usr/bin/elfsign list -f field -c certificate_file


/usr/bin/elfsign list -f field -e elf_object


DESCRIPTION


list
Lists on standard output information from a single
certificate file or signed elf object. The selected field
appears on a single line. If the field specified does not
apply to the named file, the command terminates with no
standard output. This output of this subcommand is
intended for use in scripts and by other commands.


request
Generates a private key and a PKCS#10 certificate request.
The PKCS#10 certificate request for use with the Solaris
Cryptographic Framework. If the private key is to be
created in a token device, elfsign prompts for the PIN
required to update the token device. The PKCS#10
certificate request should be sent to the email address
solaris-crypto-req@sun.com to obtain a Certificate.

Users of elfsign must first generate a certificate request
and obtain a certificate before signing binaries for use
with the Solaris Cryptographic Framework.


sign
Signs the elf object, using the given private key and
certificate file.


verify
Verifies an existing signed object. Uses the certificate
given or searches for an appropriate certificate in
/etc/crypto/certs if -c is not given.


OPTIONS


The following options are supported:

-a

Generates a signed ELF Sign Activation (.esa) file. This option
is used when a cryptographic provider has nonretail export
approval for unrestricted use and desires retail approval by
restricting which export sensitive callers (for example, IPsec)
can use the provider. This option assumes that the provider
binary has previously been signed with a restricted certificate.


-c certificate_file

Specifies the path to an X.509 certificate in PEM/PKCS#7 or ASN.1
BER format.


-e elf_object

Specifies the path to the object to be signed or verified.

The -e option can be specified multiple times for signing or
verifying multiple objects.


-F format

For the sign subcommand, specifies the format of the signature.
The valid format options are

rsa_md5_sha1
Default format Solaris 10 and updates, The
rsa_md5_sha1 format is Obsolete.


rsa_sha1
Default format for this release.

Formats other than rsa_md5_sha1 include an informational
timestamp with the signature indicating when the signature was
applied. This timestamp is not cryptographically secure, nor is
it used as part of verification.


-f field

For the list subcommand, specifies what field should appear in
the output.

The valid field specifiers for a certifiicate file are:

subject
Subject DN (Distinguished Name)


issuer
Issuer DN

The valid field specifiers for an elf object are:

format
Format of the signature


signer
Subject DN of the certificate used to sign the object


time
Time the signature was applied, in the locale's default
format


-k private_key

Specifies the location of the private key file when not using a
PKCS#11 token. This file is an RSA Private key file in a Solaris
specific format. When used with the request subcommand, this is
the ouput file for the newly generated key.

It is an error to specify both the -k and -T options.


-P pin_file

Specifies the file which holds the PIN for accessing the token
device. If the PIN is not provided in a pin_file, elfsign prompts
for the PIN.

It is an error to specify the -P option without the -T option.


-r certificate_request_file

Specifies the path to the certificate request file, which is in
PKCS#10 format.


-T token_label

Specifies the label of the PCKS#11 token device, as provided by
pktool, which holds the private key.

It is an error to specify both the -T and -k options.


-v

Requests more detailed information. The additional output
includes the signer and, if the signature format contains it, the
time the object was signed. This is not stable parsable output.


OPERANDS


The following operand is supported:

file
One or more elf objects to be signed or verified. At least
one elf object must be specified either via the -e option or
after all other options.


EXAMPLES


Example 1: Signing an ELF Object Using a Key/Certificate in a File



example$ elfsign sign -k myprivatekey -c mycert -e lib/libmylib.so.1


Example 2: Verifying an elf Object's Signature



example$ elfsign verify -c mycert -e lib/libmylib.so.1
elfsign: verification of lib/libmylib.so.1 passed


Example 3: Generating a Certificate Request



example$ elfsign request -k mykey -r req.pkcs10
Enter Company Name / Stock Symbol or some other globally
unique identifier.
This will be the prefix of the Certificate DN: SUNW

The government of the United States of America restricts the export of
"open cryptographic interfaces", also known as "crypto-with-a-hole".
Due to this restriction, all providers for the Solaris cryptographic
framework must be signed, regardless of the country of origin.

The terms "retail" and "non-retail" refer to export classifications for
products manufactured in the USA. These terms define the portion of the
world where the product may be shipped.) Roughly speaking, "retail" is
worldwide (minus certain excluded nations) and "non-retail" is domestic
only (plus some highly favored nations).
If your provider is subject to USA export control, then you
must obtain an export approval (classification)
from the government of the USA before exporting your provider.
It is critical that you specify the obtained (or expected, when
used during development) classification to the following questions
so that your provider will be appropriately signed.

Do you have retail export approval for use without restrictions
based on the caller (for example, IPsec)? [Yes/No] No

If you have non-retail export approval for unrestricted use of your
provider by callers, are you also planning to receive retail
approval by restricting which export sensitive callers
(for example, IPsec) may use your provider? [Yes/No] No

[...]


Example 4: Determining Information About an Object



example$ elfsign list -f format -e lib/libmylib.so.1
rsa_md5_sha1

example$ elfsign list -f signer -e lib/libmylib.so.1
CN=VENDOR, OU=Software Development, O=Vendor Inc.


EXIT STATUS


The following exit values are returned:


VALUE MEANING SUBCOMMAND
0 Operation successful sign/verify/request
1 Invalid arguments
2 Failed to verify ELF object verify
3 Unable to open ELF object sign/verify
4 Unable to load or invalid certificate sign/verify
5 Unable to load private key, private sign
key is invalid, or token label is
invalid
6 Failed to add signature sign
7 Attempt to verify unsigned object or verify
object not an ELF file


FILES


/etc/crypto/certs
Directory searched for the verify subcommand if
the -c flag is not used


ATTRIBUTES


See attributes(7) for descriptions of the following attributes:


+--------------------+-----------------+
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
+--------------------+-----------------+
|Interface Stability | See below. |
+--------------------+-----------------+


The elfsign command and subcommands are Committed. While applications
should not depend on the output format of elfsign, the output format
of the list subcommand is Committed.

SEE ALSO


date(1), pktool(1), libpkcs11(3LIB), attributes(7), cryptoadm(8)

April 9, 2016 ELFSIGN(1)

tribblix@gmail.com :: GitHub :: Privacy