Ubuntu Manpage: AuditVerify - Command-Line utility for verifying Certificate System signed audit logs.

Provided by: pki-tools_10.6.0-1ubuntu2_amd64

NAME

       AuditVerify - Command-Line utility for verifying Certificate System signed audit logs.

SYNOPSIS

       AuditVerify -d <dbdir> -n <signing_certificate_nickname> -a <logListFile> [-P cert/key_db_prefix] [-v]

DESCRIPTION

       The  AuditVerify  command  provides  command-line utility to verify that signed audit logs
       were signed with the appropriate CS audit private signing key and that the audit logs have
       not  been compromised.  Auditors can verify the authenticity and integrity of signed audit
       logs using the AuditVerify tool. This tool uses the public key of  the  signed  audit  log
       signing  certificate to verify the digital signatures embedded in a signed audit log file.
       The tool result indicates either that the signed audit log was  successfully  verified  or
       that  the  signed  audit  log  was not successfully verified. An unsuccessful verification
       warns the auditor that the signature failed to verify, indicating the log  file  may  have
       been tampered with (compromised).

       Note: An auditor can be any user that has the privilege to peruse the pki audit logs.

OPTIONS

-d <dbdir>
Specifies the directory containing the security databases with the imported audit
log signing certificate. This directory is almost always the auditor's own personal
certificate databases in a personal directory, such as ~jsmith/auditVerifyDir/.

-n <signing_certificate_nickname>
Gives the nickname of the certificate used to sign the log files. The nickname is
whatever was used when the log signing certificate was imported into that database.

[-P cert/key_db_prefix]
Optional. The prefix to prepend to the certificate and key database filenames. If
used, a value of empty quotation marks (“”) should be specified for this argument,
since the auditor is using separate certificate and key databases from the
Certificate System instance and it is unlikely that the prefix should be prepended
to the new audit security database files.

-a <logListFile>
Specifies the file which contains the comma-separate list of file paths (in
chronological order) of the signed audit logs to be verified. This file should be
created in a directory which is writeable by the auditor, such as a special
auditing directory like ~jsmith/auditDir. The contents of the logListFile are the
full paths to the audit logs. For example:

/var/log/pki/pki-ca/ca/signedAudit/ca_audit,/var/log/pki/pki-ca/ca/signedAudit/ca_audit.20030227102711,/var/log/pki/pki-ca/ca/signedAudit/ca_audit.20030226094015

[-v] Optional. Specifies verbose output.

Setting up the Auditor's Database

       AuditVerify needs access to a set of security databases (usually  the  auditor's  personal
       security  databases)  containing the signed audit log signing certificate and its chain of
       issuing certificates. One of the CA certificates in the issuance chain must be  marked  as
       trusted in the database.

       Auditors  should  import  the  audit  signing  certificate into their personal certificate
       database before running AuditVerify. The auditor should not use the security databases  of
       the Certificate System instance that generated the signed audit log files. If there are no
       readily accessible certificate and  key  database,  the  auditor  must  create  a  set  of
       certificate and key databases and import the signed audit log signing certificate chain.

       To create the security databases and import the certificate chain:

   Create a special directory in the auditor's home directory to use to perform the verification.
       For example:
       mkdir ~jsmith/auditVerifyDir

   Use the certutil tool to create an empty set of certificate databases in  the  auditor's  home
       directory.
       certutil -d ~jsmith/auditVerifyDir -N

   Download  the  CA  certificate  from the CA's Retrieval page. The certificates can be obtained
       from the CA in ASCII format.
       https://server.example.com:ca_https_port/ca/ee/ca/

   Import the CA certificate and log signing certificate into the databases and set trust of  the
       certificates
       If the CA certificate is in a file called cacert.txt and the log signing certificate is in
       a file called logsigncert.txt, then the certutil can be used to set the trust for the  new
       audit security database directory pointing to those files, as follows:

       certutil -d ~jsmith/auditVerifyDir/ -A -n "CA Certificate" -t "CT,CT,CT" -a -i cacert.txt

       certutil  -d  ~jsmith/auditVerifyDir  -A  -n  "Log  Signing  Certificate"  -t  ",,P" -a -i
       logsigncert.txt

       Note: The signedAudit directory kept by the  subsystem  is  not  writeable  by  any  user,
       including auditors.

Operation

       After a separate audit database directory has been configured, do the following:

   Create a text file containing a comma-separated list of the log files to be verified. The name
       of this file is referenced in the AuditVerify command.
       For example, this file could be logListFile in the ~jsmith/auditVerifyDir/ directory.  The
       contents   are   the   comma-separated  list  of  audit  logs  to  be  verified,  such  as
       "auditlog.1213, auditlog.1214, auditlog.1215."

   If the audit databases do not contain prefixes and are located in  the  user  home  directory,
       such  as ~jsmith/.mozilla, and the signing certificate nickname is Log Signing Certificate
       , the AuditVerify command is run as follows:
       AuditVerify    -d    ~jsmith/auditVerifyDir    -n    Log    Signing     Certificate     -a
       ~jsmith/auditVerifyDir/logListFile -P "" -v

       Note: It has been observed that if audit signing is enabled after system is first started,
       the first audit signature would not be verified. What happens is that the signature starts
       calculating  from it's in-memory audit log message when it signs, and since log signing is
       turned on mid-way (not from a fresh new log file), the previous content  were  not  signed
       along for calculating the first signature (and rightfully so). When AuditVerify is run, it
       does not know where the log signing begins, so it assumes it starts from the beginning  of
       the  file  till the first signature. This is why the first signature (if signing is turned
       on mid-way) will always appear to be incorrect.

AUTHORS

       Christina Fu <cfu@redhat.com>.

COPYRIGHT

       Copyright (c) 2016 Red Hat, Inc. This is licensed under the GNU  General  Public  License,
       version 2 (GPLv2). A copy of this license is available at http://www.gnu.org/licenses/old-
       licenses/gpl-2.0.txt.