nsacyber / paccor Goto Github PK

v1.1 introduces delta certificates. paccor can generate both base and delta certificates.

Base certificates require an EK certificate referenced in their holder attribute. Delta certificates require a platform certificate to be referenced as their holder. The user guide wasn't updated to describe this enhancement to the command line argument.

Problem:

get_ek.sh gathers the EK certificate with the assumption that the NVRAM index contains only the certificate. We recently encountered a case where the index contained pad bytes after the certificate. Querying the size of the NVRAM index area showed the EC was 1600 bytes. The EC itself was only 1169 bytes. An attempt to give the 1600 byte file as the EC to the paccor signer resulted in Bouncycastle returning an IOException due to the extra data in the stream.

The fix:

get_ek.sh can detect the ASN1 length sequence in the data returned from NVRAM. The script can then truncate anything after the specific number of bytes from the data.

This includes a few bug fixes.

On Linux, lshw does not list NVMe SSDs in the same way as other disks. paccor will need to be updated to gather details on those components.

On Windows, NVMe disks appear to have an incorrect serial number. The serial number reported by Windows is actually the eui, with some special formatting, recorded in the EEPROM on the physical component. An NVMe utility can reveal the correct serial number, which is also stored in the EEPROM. The NVMe SSD being loaded with SCSI drivers dated in 2006 might have something to do with the problem.

Problem

TPM tools for 1.2 can have the same problem as 2.0 when reading large blocks of data from NVRAM.

Fix

Similar to functionality for TPM 2.0 get_ek.sh must support reading small amounts of data from NVRAM at once.

BIOS information is collected. That information is not being added to the final JSON object produced by allcomponents.sh.

In the course of setting up Docker for HIRS testing, I've run into an issue wherein the CentOS Docker Image doesn't include xxd by default, and since this makes use of it, it should be added as a dependency when packaging this project. A cursory glimpse as to packages that provide the xxd binary suggests that vim-common is the recommended one. Any other packages that supply it would also be acceptable.

dmidecode in Linux appears to perform an automatic conversion of SMBIOS data if the field has an enumerated list of values. Windows will output the numerical value.

The OS commands the allcomponents script uses on Linux retrieves the MAC address of a NIC with each octet separated by dashes. On Windows, the separators are colons. Comparison of these values shouldn't depend on separators. Paccor can ensure a standard representation for the MAC address.

Paccor should provide a function to inject a certificate into the TPM NVRAM.

Ensure requirements are met for the base platform certificate

Issue:

The component class value field is an octet string of fixed size: 4 bytes. Currently, while trying to set the component class value of a component identifier, the created octet string will only be as large as the value requires.

Fix:

The component class value field must have a maximum and minimum size of 4 bytes. Fill in with leading zeros.

Perform a check for each platform to ensure they reference compatible data sources per component

Certificates are being generated with all field replaceable fields set to false, even when the Components JSON file specifies otherwise.

Command line might need to be updated to support the creation of base or delta platform certificates.

Physical components which are not enabled are being skipped by the allcomponents.sh script.

Encountered a case where the nguid field is empty when looking at details for a NVMe component. The eui64 field also contains the data needed for comparison.

Bug fixes.

An issue was discovered with the way strings are gathered from the SMBIOS table. Those strings are referenced in order from the body each individual table. My parser does not properly account for the case that an empty string is included in that list of strings.

Prior to PACCOR 1.1.3r3, the components serial number was being populated. Some of the system tests are now failing, since the HIRS ACA is expecting a serial number for the components to keep track of. Looks like we can update the allcomponents.sh script to put in some default serial numbers.

Even though PACCOR has a debian distribution, it contains a line in allscripts.sh that reads a file called /etc/centos-release that is not available on debian systems.

Problem:

Paccor does not provide a reasonable message when it cannot read the EC.

The stack trace below shows the error returned for the problem described in Issue #6. The fix proposed in that issue would handle situations similar to the case we saw for that issue. It could still not represent a valid EC.

Fix:

Better errors will help when paccor is not able to process the EC. pc_certgen.sh should not reach the validation step if a platform certificate is not created.

Stack trace:

Generating a signed Platform Credential
Exception in thread "main" org.bouncycastle.openssl.PEMException: problem parsing cert: java.io.IOException: Extra data detected in stream
        at org.bouncycastle.openssl.PEMParser$X509CertificateParser.parseObject(Unknown Source)
        at org.bouncycastle.openssl.PEMParser.readObject(Unknown Source)
        at cli.DeviceObserverCli.handleCommandLine(DeviceObserverCli.java:66)
        at cli.SigningCli.handleCommandLine(SigningCli.java:100)
        at cli.SigningCli.main(SigningCli.java:192)
Caused by: java.io.IOException: Extra data detected in stream
        at org.bouncycastle.asn1.ASN1Primitive.fromByteArray(Unknown Source)
        at org.bouncycastle.cert.CertUtils.parseNonEmptyASN1(Unknown Source)
        at org.bouncycastle.cert.X509CertificateHolder.parseBytes(Unknown Source)
        at org.bouncycastle.cert.X509CertificateHolder.<init>(Unknown Source)
        ... 5 more
Validating the signature
File "/opt/paccor/scripts/pc_testgen/platform_cert.20181005074720.crt" does not exist.
PC Credential Creation Complete.
Platform Credential has been placed in /opt/paccor/scripts/pc_testgen/platform_cert.20181005074720.crt

This platform configuration attribute received the many changes in the updated spec.

All fields one level into the attribute are still optional.

Linux will randomize the MAC address of NICs when they are either disabled or not in use. Hardware verification relies on finding the consistent, permanent, MAC address of the NIC.

get_ek.sh specifically calls out yum to determine version of tpm2-tools. The script could be updated to check apt instead. The rest of the script might work the same.

Powershell can echo data and pipe it to a file just like on Linux. The difference is that pipe function in Powershell will place two bytes at the beginning of the file (0xFFFE). These two bytes have unknown functionality in Windows. They are not valid in a JSON file and break non-Windows JSON parsers.

The component gathering script was updated a while ago to print the component json file without those extra bytes. The policy and extension scripts were not updated at that time. Until it is fixed, pc_certgen.ps1 will produce a non-functional platform certificate because the policy and extension JSON files are not valid.

Work on making a script which gathers the EK certificate on Windows.

OEM changed their SMBIOS value for CPU from
Serial number = "To Be Filled By O.E.M."
to
Serial number = " "

This causes the localhost-componentlist.json file to be corrupt when read in by pc_certgen.ps1.

Potential problem on line 495 of allcomponents.ps1

The packaging scripts should contain them in the dependencies list.

Might have broken something with the validator signature check.

While investigating an issue related to the ACA, there as a mismatch for the platform information in the supply chain validator matching test. Upon further investigation I noticed that the localhost-compenentlist.json and the platform_cert associated didn't have the same information for platform. The platform information is missing from the certificate and just has "Not Specified".

However this is on in the emulator and not on the host machine in the same scenario.

Everything was uploaded with the release last week except for unit tests.

get_ek.sh will not detect the abrmd service correctly if the service is launched with any flags.

Ensure requirements are met for the delta platform certificate

The class provides constant references for ASN1 OIDs related to this project.

The constants should make use of ASN1ObjectIdentifier branching to reduce chance of mistyping a number. The same variable names should be maintained.

Received report of a potential bug where the credential type may always be set to "base certificate" when both an observer file and a holder are specified in the command line arguments to the signer program.

Verify/fix behavior as needed.

Certificate Type is a new attribute

Targeting Information is a new extension

Holder is an existing attribute but changes based on the Certificate Type

The paccor signer program accepts the CA cert and the CA private key each in DER or PEM format as separate command line arguments. This requires the private key to be stored unencrypted on the file system.

OpenSSL makes it easy to format the private key into DER/PEM. Most other tools require the private key to be exported into a PKCS12 file- protected by a password. Powershell is one of those other tools.

The issue in front of me is that Powershell only allows the key to be exported into PKCS12. I don't want to expect Windows users will have installed OpenSSL. The signer should also be able to accept a key store instead.

Problem

get_ek.sh uses dmesg to detect version of TPM. dmesg will contain that information for hardware TPMs. We've noticed that TPM emulator(s) will not make that information available through dmesg.

Fix:

I will need to find another way to detect the version of TPM running. /sys/class/tpm/tpm0/ does have the information available in separate files. The differing file structures for 1.2 and 2.0 has made me think this method would be inconsistent. At this point, it would be more reliable than dmesg.

The distribution packages for v1.1.0r1 contain Linux script files which were checked out on Windows. Git for Windows will place carriage return and new line characters at the end of every line.

The distribution packages need to be built again and replace the old ones.