xaptum/xaptum-tpm

Utilities for interacting with the TPM2.0 used to access the Xaptum Edge Network Fabric, an IoT Network Solution.

Xaptum TPM

Utilities for interacting with a TPM2.0 used for access to the Xaptum Edge Network Fabric.

Installation

xaptum-tpm is available for the following distributions. It may also be built from source.

Debian (Stretch, Buster) and Ubuntu (Bionic)

DIST=$(lsb_release -cs)

# Install the Xaptum API repo GPG signing key.
sudo apt-get install dirmngr
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys c615bfaa7fe1b4ca

# Add the repository to your APT sources
echo "deb https://xaptum.jfrog.io/artifactory/debian ${DIST} main" | sudo tee /etc/apt/sources.list.d/xaptum.list
sudo apt-get update

# Install the library
sudo apt-get install libxaptum-tpm-dev

Homebrew (MacOS)

# Tap the Xaptum repository.
brew tap xaptum/xaptum

# Install the library.
brew install xaptum-tpm

Installation from Source

Build Dependencies

• CMake (version 3.0 or higher)
• A C99-compliant compiler
• A POSIX-compliant platform

Building

# Create a subdirectory to hold the build
mkdir -p build
cd build

# Configure the build
cmake .. -DCMAKE_BUILD_TYPE=Release

# Build the library
cmake --build .

CMake Options

The following CMake configuration options are supported.

Option	Values	Default	Description
CMAKE_BUILD_TYPE	Release		With full optimizations.
	Debug		With debug symbols.
	RelWithDebInfo		With full optimizations and debug symbols.
	RelWithSanitize		With address and undefined-behavior sanitizers.
CMAKE_INSTALL_PREFIX		/usr/local	The directory to install the library in.
BUILD_SHARED_LIBS	ON, OFF	ON	Build shared libraries.
BUILD_STATIC_LIBS	ON, OFF	OFF	Build static libraries.
BUILD_TESTING	ON, OFF	ON	Build the test suite.
STATIC_SUFFIX			Appends a suffix to the static lib name.
CMAKE_POSITION_INDEPENDENT_CODE	ON, OFF	ON	Compile static libs with -fPIC.

Testing

By default, the tests use a device-file-based TCTI. For this reason, sudo privileges may be required to run them.

The tests can instead be build to use a TCP-socket-based TCTI, by using the CMake option TEST_USE_TCP_TPM=ON.

If using the TCP-socket-based TCTI, the tests require a TPM 2.0 simulator running locally on TCP port 2321.

Use the following commands to start the simulator before running the tests.

.travis/install-ibm-tpm2.sh <installation dir>
.travis/run-ibm-tpm2.sh

To run the tests:

cd build
ctest -V

Installing

cd build
cmake --build . --target install

License

Copyright 2017-2018 Xaptum, Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this work except in compliance with the License. You may obtain a copy of the License from the LICENSE.txt file or at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

xaptum-tpm's Issues

Add support for TPM2_GetRandom

The TPM provides a TRNG, which would be useful for seeding the RNG provided by the host kernel.

Add unit tests for marshaling code

The functions in the marshal.c file convert from the C structures to on-the-wire format, and vice-versa. Currently, this code is only tested implicitly, by testing the higher-level functions that use the (un)marshaling code.

As a quick first step to testing this important code, we should add tests that simply create each of the tss2_tpm_types.h structs, marshals each one to a buffer, un-marshals it to a new struct, and checks that the two structs are the same.

Remove signature-output test that breaks in newer TPM spec's

The test in tss2_sys_sign-test that checks that the signatureR value is the same as the hash value we input (which we just set to all 0s) fails for any TPM conforming to Errata v1.5 to TPM spec 1.16 (and, presumably, new spec's as well).

Because there isn't a very meaningful version of this test for the newer TPMs (simply checking that it's not equal isn't a useful test), and because the simulator that we use for continuous integration testing still conforms to pre-errata v1.16, this test should simply be removed.

Add support for firmware upgrades

Add ECDSA signature support

Support device tcti in utils

See this similar issue for details: xaptum/xtt#37

Support device file TCTI

Explore supporting newer TSS revisions

The newest version of the IBM TPM2.0 (1119) simulator has some nice features:

• Support for a device file interface (rather than TCP)
• Support for building against openssl v1.1 rather than v1.0
  • This is nice for building on Stretch, which uses v1.1

However, the 1119 version of the simulator says it's off the revision 146 of the TSS spec. Running our unit tests against this version of the simulator fails:

• create_load_evict_test fails when initially run, then magically succeeds on subsequent runs
• tss2_sys_create-test fails, somewhere in the create call

It might be nice to support this newest revision of the spec, and thus of the simulator. However, we also need to make sure this still works with the current Infineon chips we actually use.

Support full clearing ability

Support TPM2_ChangePPS (to clear any existing platform keys) and TPM2_UndefineSpaceSpecial (in case an NV index was created with POLICY_DELETE)

Regarding storing 100 bytes of data in Slb9670 (Tpm -2.0) in nv memory

Hello,

actually main problem is we interfaced slb 9670(tpm-2.0) with 16 bit msp430 controller which does not support linux kernel or any OS.

now our task is to store a 100 byes of data in NV memory, without any authorisation technique, as simple as possible.

please guide me in that way.

slb 9670 is interfaced with msp430 controller through SPI protocol. I able to read device id , version id of slb9670 , so spi communication is working fine with our controller .

what is packet format to be send with our data , i am not able to find in TCG documents .

theoretically iam able to understand we have to do nvdefinespace , nvwrite ,nvread .. internaly what is the format i have to be send not able to understand

can you please guide me , or share any code snippet .

sorry if i trouble you or any irrelevant questions.

Regards,
Manoj
[phone]

Root ID and public key are now combined in NVRAM

With our current issuing, we're combining the root ID and public key into a single structure, the "xtt" certificate. This project needs to be updated to reflect that change.

Buffer-too-small check for device TCTI doesn't work

The check in tss2_tcti_device.c for a too-small buffer, using EOF return from read, doesn't work, as determined by tss2_tdcti_device-test.c.

I think the driver always returns whatever it can (either everything, or just what can fit in the buffer), then always closes the fd. So, this will always return EOF, so this check doesn't work.

Variable-length x509 certificate and basename in NVRAM

The XTT NVRAM indices currently have two problems:

• The variable-length basename uses two NVRAM indices, one for the basename itself and one for its length. That's silly.
• The x509 root certificate has a hard-coded length, which currently is wrong. This should be updated to allow a variable length, like is required for the basename.

We could simply add an index for the x509 certificate's length, like we do with the basename. But, that's unnecessary. Both values should be variable-length single-index values.

This can be done by simply putting the length at the beginning of the NVRAM, and doing two reads (one of constant, say 2byte, length to get the length, then the second of that length).

However, a more-elegant solution probably exists, to query the TPM for the index's length first, before reading.