While checking new test pattern certificates for v2, it was noted that the Authority Information Access property isn't showing up in the issuer field of the certificate details page. Upon inspection, there is no code to parse this information out for the Attribute Certificate. CAs and EK certificates are showing this information.

Endorsement, Platform, and Trust Chain Certificates all have the ability to be deleted on the ACA portal. The Issued Attestation Certificates do not. When demonstrating the ACA is sometimes useful to delete the older Attestation Credentials when performing the demo multiple times. The Issued Attestation Certificates page should have a working icon for deleting issued attestation certificates.

Amazon AWS has a set of supported Amazon Machine Images (AMI). "Amazon Linux" is a commonly used AMI. Amazon Linux defines the OS version within the /etc/system-release file which ,as example, currently contains "Amazon Linux release 2 (Karoo)" for the Amazon Linux AMI.

Currently the HIRS RPMs are looking for similar files (e.g. /etc/rehat-release) but will not install properly on Amazon Linux. Adding a /etc/redhat-release file in the AWS instance will fix the problem for that install. To support Amazon linux a check for the /etc/system-release file should be put in the install scripts if /etc/redhat is not found.

Some new certificate fields to display:

1. Certificate Version: not showing for Trust Chain or Endorsement Certificates
2. Public Key Algorithm & Key Length (in bits) example: 2048 bit RSA
3. Signature algorithm & Key Length: example sha256WithRSAEncryption,singaturelength (in bits)
4. Key Usage
5. Extended Key Usage
6. Create an Issuer section
   a. Display Issuers Distinguished Name (currently labeled as Issuer)
   b. Authority Key Identifier (link to issuers subject key identifier)
   c. Authority Information Access (URL with link) option to donwload into the trust chain.

While working #25 it has been discovered that the ACA is not retrieving uploaded EK Certs during TPM 2.0 Provisioning. It will look for uploaded Platform Certificates, but the equivalent check for Endorsement Certificates is not performed. This should be fixed such that the TPM 2.0 Provisioning process behaves like the old TPM 1.2 Provisioning process.

Change the behavior of getPolicy to not return default policies in the case where no policy is assigned to an (appraiser, device group) pair, as this is never used in actual HIRS operation.

Multiple occurances of a Version Error appear in the AttestationCA.log file:

2018-09-04 14:28:36 [hirs.utils.VersionHelper.getVersion] WARN  : Error reading version
java.lang.IllegalArgumentException: resource VERSION not found.
        at com.google.common.base.Preconditions.checkArgument(Preconditions.java:145) ~[guava-18.0.jar:?]
        at com.google.common.io.Resources.getResource(Resources.java:197) ~[guava-18.0.jar:?]
        at hirs.utils.VersionHelper.getFileContents(VersionHelper.java:53) ~[HIRS_Utils-1.0.1-SNAPSHOT.jar:?]
        at hirs.utils.VersionHelper.getVersion(VersionHelper.java:42) [HIRS_Utils-1.0.1-SNAPSHOT.jar:?]
        at hirs.utils.VersionHelper.getVersion(VersionHelper.java:29) [HIRS_Utils-1.0.1-SNAPSHOT.jar:?]
        at hirs.data.persist.DeviceInfoReport.<init>(DeviceInfoReport.java:145) [HIRS_Utils-1.0.1-SNAPSHOT.jar:?]
        at hirs.attestationca.AbstractAttestationCertificateAuthority.parseDeviceInfo(AbstractAttestationCertificateAuthority.java:593) [AbstractAttestationCertificateAuthority.class:?]
        at hirs.attestationca.AbstractAttestationCertificateAuthority.processDeviceInfo(AbstractAttestationCertificateAuthority.java:654) [AbstractAttestationCertificateAuthority.class:?]
        at hirs.attestationca.AbstractAttestationCertificateAuthority.doSupplyChainValidation(AbstractAttestationCertificateAuthority.java:432) [AbstractAttestationCertificateAuthority.class:?]
        at hirs.attestationca.AbstractAttestationCertificateAuthority.processIdentityClaimTpm2(AbstractAttestationCertificateAuthority.java:387) [AbstractAttestationCertificateAuthority.class:?]
        at hirs.attestationca.rest.RestfulAttestationCertificateAuthority.processIdentityClaimTpm2(RestfulAttestationCertificateAuthority.java:93) [RestfulAttestationCertificateAuthority.class:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_171]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_171]

Even though the current version of the ACA only supports RSA public key based EK certs, TPM manufacturers can use Ecc keys to sign RSA public keys within an EK certs. Specifically Nuvoton_TPM_Root_CA_2110.cer is an ECC based certificate which is used to validate some Nuvoton produced RSA based EK certs.

EK cert:
Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
Signature Algorithm: ecdsa-with-SHA256

The ACA should be able to upload an Ecc based intermediate or root Trust Chain CA Certificate. Furthermore the ACA should be able to validate and use the ECC based certs to validate the Certificate chain of any EK certificate.

In HIRS_Utils we have the Certificate class in charge of parsing Certificates of all varieties. There is a small problem in that they come in as a byte array that has no guarantees of being of having all the required fields in a parsable format.

The entire Certificate class hierarchy should be scanned for locations where this assumption is made and null checks introduced appropriately. Required fields may need to throw an error.

Issue comes out of merge request #16

PlatformSerial is defined as an optional value in the Subject Alternative Name. Most platforms should have the information that goes into this value available. If they don't, then the platform certificate might not include the value.

The specification says:

During certificate validation, the Privacy-CA MUST check that the platform manufacturer, model, version, serial numbers, and manufacturer ID are acceptable.

Currently, if the ACA finds that the value is not present in the certificate, then it throw a null error.

Since the value is optional, the appraisal should fail only if the value is not the same in the device info and the certificate. If neither have a platform serial number, appraisal should continue.

These are additional fields that weren't included in issue #43:

1. CRL distribution Points: (include URL with link)
2. Certificate Policies: label exists, data seems to be missing
3. Certificate Practice Statements (URL which links to CPS document if present)
4. Basic Contraints

Made in error

Release 1.0.3 will have several updates:

• Added a User's Guide document for the ACA and TPM provisioner(s)
• Added several certificate display fields
• Cleaned up some error logs
• Put in a check for ResourceMgr or TPM2-Abmrd for the TPM2 provisioner
• PACCOR is now a dependency for the TPM Provisioner

When provisioning a tpm2 log4cplus prints an initialization error

TPM 2.0 detected.
log4cplus:ERROR No appenders could be found for logger (root).
log4cplus:ERROR Please initialize the log4cplus system properly.--> Provisioning
----> Collecting endorsement credential from TPM
----> Creating attestation key
----> Collecting platform credential from TPM
...

Both component.getComponentSerial() and component.getComponentRevision() can return null. The call to getString() in any of the referenced lines will cause a NullPointerException on the server. This results in a 500 error for the client.

Component manufacturer and model are required fields, and should not return null. Making the assumption that the object will never be null could lead to the vague 500 error described above.

I suggest adding additional null checking for the referenced code.

Currently the provisioner and ACA expect the EKcert to be on TPM's NvRAM with no leading or trailing bytes within the space allocated for the EKcert storage. In one case the EKcert had several trailing bytes which caused the following events to occur:

1. The TPM2 provisioner pulled the entire memory allocated for EKcert which included extra bytes of non used data appended to the EKcert.
2. The TP2 provisioner sent the entire blob to the ACA, but the ACA failed to parse the EKcert. The ACA sent back a 500 error to the provisioner.
3. When the EKcert was edited to remove the trailing bytes and uploaded to the ACA it had no effect on the process. The ACA did not search for a stored EKcert when the EKcert sent failed.

Suggested improvements:

1. Update the ACA to process the length parameter of all sent certs (including the platform cert) and trim off any extra data.
2. If the ACA fails to process the EKcert the ACA should log an error and send back an error to the provisioner indicating the EKCert was malformed and could not be processed.

hirs-provisioner-tpm2 not on path after installation. Something is going wrong in the RPM installation.

The ACA presently sends nondescript 500 error messages to the client Provisioners when an error occurs during the provisioning process. These messages should be made more descriptive and parsed by the Provisioners appropriately to provide more helpful feedback to the user for troubleshooting.

New test pattens are introducing a new field within the ComponentIdentifier :
OCTET STRING SIZE(4). This needs to be accounted for when parsing the Platform Credential. No processing of this field is current needed.

Presently, both Gradle and the packaging scripts for the TPM 2.0 Provisioner perform a simple delete of the build directory anytime you attempt to build or package this particular subproject. This creates an issue in environments where Internet service is spotty due to the deletion of downloaded external dependencies.

While these dependencies cannot be removed, we can avoid deleting them to at least "cache" the dependencies.

Both the building and packaging scripts should be updated to prevent deletion of these external dependencies so as to prevent having to redownload them everytime the package requires packaging or a Gradle build.

Presently, the Travis CI pipeline has two separate stages for Packaging and System Tests. Since part of the System Tests involves packaging on the CentOS platform, we can and should combine the two. Ideally this will result in the System Tests occurring while we test packaging on the Ubuntu platform. Thus we maintain packaging tests on both main development platforms while simultaneously supporting systems tests, which run in the CentOS7 environment.

PersistenceConfiguration in HIRS_Utils subproject should avoid using magic Strings for Spring Bean Names. If anyone references one and it changes, then their code will break unnecessarily. A small refactor should be done to ensure they could reference a dedicated, statically defined String, that if an update occurs, they will also receive the update.

The "Import Baseline" (for TPM Whitelist or Blacklist) feature is removing one or more PCR entries during import. The baseline has all 24 PCR values (0-23) before performing the import. It appears random as to which PCR(s) is/are being deleted from the TPM baseline.

Presently, the TPM 2.0 Provisioner relies on having the TPM2-Abrmd running, or for much older versions of the TPM2 Software Stack, the Resourcemgr daemon is required. Either way, a check should be added in at the start of provisioning to ensure that either of these daemons are running, otherwise we should abort the provisioning process and alert the user.

Some status has been inadvertently removed from the hirs-provision process
This is what is currently displayed from a tpm_aca_provision:

TPM 1.2 detected.
--> Configuring provisioner
----> Deleting existing key store
----> Downloading truststore
--> Provisioning
----> Removing old provisioner scripts, if any
----> Provisioning TPM

An what used to be displayed

TPM 1.2 detected.
--> Configuring provisioner
----> Deleting existing key store
----> Downloading truststore
--> Provisioning
----> Provisioning TPM
----> Collecting Device Information
----> Got Endorsement Credential from TPM
----> Sending Attestation Identity Credential Request
----> Attestation Identity Provisioning succeeded 
----> TPM successfully Provisioned

It was recently discovered that package.ubuntu.sh was broken due to an update to the project build structure a week or two ago. In light of this fact, it seems like it would be a good idea to update Travis CI to include packaging of the RPM and DEB as part of the build process to ensure this doesn't happen again in the future.

The preprocessor is expanding FILE in the error message to the full path of the file where the error occurred. See Process.h. Unfortunately, it is the *full path which contains non relevant information.

With the recent closure of #46 and the ongoing work in #67, an effort should be made to bring the old TPM 1.2 Provisioner in line with the ACA and TPM 2.0 Provisioner insofar as systems tests are concerned. The initial step is to make the TPM 1.2 Provisioner able to be run from within a Docker container. This ticket will track work towards that end.

In support of Issue #74 the VERSION file needs to be updated to reflect the version number on future builds.

HIRS_ProvisionerTPM2/CMakeLists.txt claims the Ubuntu deb package depends on libcurl4-openssl-dev; it should actually depend on libcurl3 which provides libcurl.so.4. The former package depends on the later, so it would install the right package, but it is preferable to only require what is needed.

Both ACA and and Provisioner* support for Ubuntu 18.04 LTS using repo tpm tools.

The paccor rpm on the releases page (https://github.com/nsacyber/HIRS/releases/) is a couple versions behind and lacks some later functionality, such as working with simulated TPMs.

You may want to either update the version on the releases page or refer back to the upstream project for the latest version.

At the moment, the packaging scripts build all of the subprojects with no fine grain selection of packages allowed. Subprojects that are packaged into RPMs or DEBs should receive their own individualized package script that can be called from the current master packaging script to still allow for building all at one time if desired without precluding the ability to individually package subprojects.

This is would be helpful as we move forward with the Integration Testing work via Docker, because Docker will be using a shared volume among all of the Docker Containers spawned with Docker Compose. Each of these containers should be able to individually package their target subproject without stepping on the toes of the other containers also using the same Shared Volume.

IMA baselines are typically used to match measurement records against baseline records using both their paths and hashes. In certain cases, it is useful to be able to match IMA measurements solely based on their hashes and not filenames. ImaAcceptableRecordBaseline and its subclasses should be updated to include a containsHashes which performs this operation.

After installing ACA on a CentOS 7 system, navigating to the ACA Portal URL (https://:8443/HIRS_AttestationCAPortal/) displayed a blank page. Looking in the tomcat logs, shows:
192.168.103.1 - - [16/Oct/2018:19:04:20 +0000] "GET /HIRS_AttestationCAPortal HTTP/1.1" 404 -
SELinux was blocking the connection from tomcat to mysqld, indicated in the audit logs by: node=server22.simp.test type=AVC msg=audit(1539714234.510:4782): avc: denied { name_connect } for pid=12058 comm="java" dest=3306 scontext=system_u:system_r:tomcat_t:s0 tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket
Could you add a SELinux policy to the RPM to enable this out of the box?

Per the result of the Travis-Ci job here: https://travis-ci.org/nsacyber/HIRS/jobs/485543350

We can see from the above job that the systems tests do not currently detect when they have failed. Some additional logic may need added to run-system-tests.sh to detect if the systems-tests have failed and then exit with a non-zero error code in order to indicate to Travis-Ci that something went wrong.

Otherwise, the run-system-tests.sh ends with a call to docker-compose down, which is almost always guaranteed to return successfully, thus Travis will then the Systems Tests passed.

The Platform Certificate page does not currently display the holder information (EK certificate info). The holder is defined as:

 Holder ::= SEQUENCE {
     baseCertificateID   [0] IssuerSerial OPTIONAL,
            -- the issuer and serial number of
            -- the holder's Public Key Certificate
     entityName          [1] GeneralNames OPTIONAL,
            -- the name of the claimant or role
     objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
            -- used to directly authenticate the
            -- holder, for example, an executable
 }

 IssuerSerial ::= SEQUENCE {
     issuer     GeneralNames,
     serial     CertificateSerialNumber,
     issuerUID  UniqueIdentifier OPTIONAL
 }

The baseCertificateID should be displayed with a hyperlink to the EK cert page (if it exists). Per the Platform Certificaate specification, "the BaseCertificateID choice MUST be used." As such, the entityName and objectDigestInfo optional entries, valid for attribute certificates in general, are never found in Platform Certificates.

When the platform certificate processing has detected that a component did not match the device the ACA Validation report page shows an error symbol with a tooltip that provides a generic error such as "There are unmatched components" . It would be beneficial to display information about the component that failed. Listing the failed components Manufacturer and Model would suffice.

Per @iadgovuser19 in Merge Request #16

Something that has a lot of room for improvement is how we deal with the GeneralName. The GeneralName can be any one of many, many types. We could/should run the getType() function to see what type of name it is before trying to parse it. It should always be an X500Name type (option '4'), because that is what the "issuer" field in an X.509v3 certificate is, which is what should be replicated into the holder of a Platform Certificate. Then, when we do the getName(), we know that the returning type can be cast as an X500Name. It is very tempting to immediately do a toString() to the X500Name, but this is not the best idea. An X500Name is a complex structure, and is subject to different interpretations when trying to read it as a string. We are using BouncyCastle when getting the string representation of the X500Name in the holder, but we are using the java.security representation when doing the same to the issuer field. Although these have always returned the same string in the past, there is no guarantee that they will always be the same. They should however be an identical ASN.1 structure, but that structure includes both SEQUENCEs (ordered sets) and SETs (not-necessarily-ordered sets). Two "identical" X500Name structures could theoretically be different sequences of bytes, with different string representations. We can either hope that this will never be different, or guarantee that we validate the similarity properly.

As a result of this, perhaps we should make some type of small Helper class in HIRS_Utils that can be employed around the rest of the HIRS subprojects as needed.

Work done in Issue #46 "Setup Integration Tests in Travis CI" , should provide a set of Docker files and images for performing integration test for HIRS_ProvisionerTPM2 with the ACA.

This tasks ports the existing test to Travis using the containers set up in Issue 46.

The Travis CI build is currently building/testing everything in about 13 minutes. This could be optimized if the subprojects are built/tested in parallel and a pre-built Docker image is provided to the test environments to prevent having to build a new Docker image on every test job.

When building HIRS_ProvisionerTpm2 off of the master branch a make error occurs:

includes: -Iinclude/
Platform:Native
8/10 files checked 82% done
Checking src/Tpm2ToolsUtils.cpp ...
Defines:
Undefines:
Includes: -Iinclude/
Platform:Native
[src/Tpm2ToolsUtils.cpp:61] -> [src/Tpm2ToolsUtils.cpp:66]: (style) Local variable oor shadows outer variable
9/10 files checked 90% done
Checking src/Utils.cpp ...
Defines:
Undefines:
Includes: -Iinclude/
Platform:Native
[src/Utils.cpp:86] -> [src/Utils.cpp:89]: (style) Local variable ss shadows outer variable
10/10 files checked 100% done
make[2]: *** [bin/hirs-provisioner-tpm2] Error 1
make[1]: *** [CMakeFiles/hirs-provisioner-tpm2.dir/all] Error 2
make: *** [all] Error 2

The HIRS ACA lacks a simple user guide for the ACA and TPM provisioner applications. Document should cover:

• Trusted Computing Based Supply Chain Validation Concepts background
• ACA Portal usage
• TPM 1.2 and TPM 2.0 provisioner command line applications
• Links to the installation and setup guides
• An appendix on TPM Provisioning details

Document should be placed in https://github.com/nsacyber/HIRS/tree/master/HIRS_AttestationCAPortal/src/main/webapp/docs for access via the portal under the help tab.

As discovered when working on #23 and referenced in MR #26, there is a bug in the EndorsementCredential class regarding parsing of the TPMSecurityAssertions class. The parser doesn't take into account the complete structure of the TPMSecurityAssertions object as defined in TCG EK Credential Profile For TPM Family 2.0; Level 0 (pg. 19).

Specifically, it makes assumptions about the presence of default values and strictly defines where certain fields should be as a result.

The parser should be made slightly more flexible to handle the lack of default values and populate them accordingly. Additionally, it should handle the other fields more flexibly but still in keeping with the specification.

A CI server should be put in place to at least run Unit Tests for the HIRS project. Travis CI appears to have the lowest barrier to entry and easily integrates with GitHub.

This task is meant to set up a rudimentary Travis CI build.

The Alert class should possess a field to hold a human-readable title.

Instead of having device info collection implemented twice -- once in Java from 1.2 Provisioning and once in C++ for 2.0 Provisioning, just use PACCOR to collect the device info.

With the completion of #71 and merging of #77 imminent, we'll need to wrap up work on the System Testing by getting the TPM 1.2 Provisioner Docker image to run the system tests to ensure that everything is running properly.

Already seems to run fine locally, so this may only be a couple line update to get the Python System Tests to run.

Presently we have Style Checking, Static Analysis, Unit Testing and Project Packaging covered/performed by Travis CI to hedge against regressions. Travis CI still needs updated to perform some level of Integration Tests to ensure that at the very minimum it's guaranteed that Provisioning service is always functioning in supported environments between the ACA and the 1.2 and 2.0 Provisioners.

An initial glimpse suggests Docker Compose may be a useful tool to accomplish this.

When testing the platform validation process found a condition where the Platform Cert wasn't loaded but the Attributes seemed to pass.

Another condition where this possible is if the Platform cert was loaded but the signature was invalid (e.g. the Platform Certs Trust Chain is missing) then this case could be possible. The error indicated by hovering over the Platform cert red circle indicated that "cant validate a platform cert without a trust store".

Proposed solution: Platform Attributes should not pass if the Platform Certificate is invalid. This implies that the EK certificate needs to be valid as well.