alt="Infineon TPM 1.2 chip" width="180" height="135" border="0" />
Solaris platforms use
the TPM 1.2 chip
In Solaris 11.1, Wyllys Ingersoll added the ability to migrate keys
from one TPM to another TPM.
TPM migration is is especially useful when upgrading hardware, migrating a
system to a new platform, or after reinitializing the TPM.
The following describes this new feature.
Since the introduction of TPM Support in Solaris 11, Solaris has had
the ability to generate keys that are bound to a specific TPM and which
cannot be used anywhere else. This tight binding to a specific device
is a security feature of the TPM and TPM keys. Whenever a user or application
creates a persistent TPM key, internally it is put into a key hierarchy
that is organized in a tree-like fashion with a Storage Root Key (SRK)
at the top of the tree and all other user and system keys that get
created are either a child of the SRK or a child to a key somewhere
below the SRK. SRK keys can never be migrated or moved from one TPM to
another. This can cause a problem if the platform (motherboard, TPM, etc)
ever has to be replaced because if the underlying TPM is changed, as this
would cause all keys that were tied to the old TPM to become unusable and
any data encrypted with those keys would not be recoverable. It is also
a problem in situations where the disk containing the TPM persistent keys
is moved to a new platform with a different TPM.
TPM Key Scheme before the TPM Migration feature:
The Trusted Computing Group (TCG)
specifications allow for keys to be created with a "migratable"
attribute which allows them to be migrated from one parent key to another.
By enforcing a new key hierarchy, we can ensure that keys can be migrated
and recovered in the event that the underlying device has changed.
This features generates a sub-SRK (called a Migratable Root Key or MRK) that
all applications that wish to preserve the ability to migrate keys can use as
the parent key. This new Migratable Root Key can then be migrated if necessary and
automatically enables all of the descendent keys to be migrated. Only the
root of the tree needs to be migrated and all children in the hierarchy
automatically continue to work as usual since they are only bound to
New TPM Key Scheme with the TPM Migration feature:
Persistent (stored) TPM keys are identified by UUID values.
UUIDs are always stored in network byte order, aka Big Endian (see RFC 4122).
When the platform owner issues the "tpmadm init" command to take ownership of the
TPM and establish an owner passphrase, tpmadm also creates the new Migratable
Root Key in the system key database. Additionally, it will establish the
migration key and migration data that will be used in the event of a future
migration request. The software migration data and migration key is stored in
The migration key data will be protected with the same passphrase entered as
the TPM owner passphrase. However, if the administrator later changes the
TPM owner passphrase with the "tpmadm auth" command, the migration key
passphrase will not be changed.
Directory /var/tpm/system/ is read-only for root:sys and requires
elevated privileges to access and perform a migration. See "Privileges" section below.
Any system application that creates persistent TPM keys
(libkmf(3LIB) through PKCS#11 provider pkcs11_tpm(5) or tpmadm(1M))
uses the "MRK" key as the parent.
The tpmadm(1M) application administers TPM migration.
The tpmadm migrate sub-command
useful for anyone who wants to export their persistent keys and move them
to another TPM.
The tpmadm sub-commands are explained here and in the tpmadm(1M) man page.
The "tpmadm keyinfo" command lists your keys:
$ tpmadm keyinfo
[SYSTEM] 00000000-0000-0000-0000-000000000001 (loaded)
To create the initial migration blob and key for the persistent key "UUID", use:
# tpmadm migrate export UUID [MigDataFile MigKeyfile]
For example to export the MRK, use:
# tpmadm migrate export 00000000-0000-0000-0000-00000000000b
The "tpmadm migrate export" command:
To Import a key into the users persistent key database, use:
# tpmadm migrate import [MigDataFile MigKeyFile [ParentUUID] [NewKeyUUID]]
The "tpmadm migrate import" command:
Any TPM keys that a user may have already created that were not created with
the "migratable" flag, can never be moved to a new parent key. Unfortunately,
the existing key hierarchy created and used by pkcs11_tpm does not create
migratable keys and so any existing pkcs11 TPM tokens will never be able to
be migrated. However, the impact of an upgrade to the new key scheme introduced by
this project should be minimal for these reasons:
The tpmadm(1M) "tpmadm init", and "tpmadm migrate" subcommands
require elevated privileges because they need to access root-owned files. The existing
"TPM Administration" rights profile supports this ability without
requiring tpmadm to be setuid or requiring the user to have full root privilege.
Users with the TPM Administration profile may use the
"tpmadm init" and "tpmadm migrate" sub-commands without becoming root.
The following is the security profile entry in file
TPM Administration:RO::Administer Privileged TPM Operations:auths=solaris.smf.manage.tcsd,solaris.smf.value.tcsd
solaris.smf.value.tcsd:::Change TPM Administation value properties::
solaris.smf.manage.tcsd:::Manage TPM Administration service states::