NV Counter Index
An NV counter is a 64-bit value that can only increment. At the beginning of the first increment command, it's initialized to the largest value that any counter has ever had on the TPM. This includes counter indexes currently defined and counters that were defined in the past but are no longer on the TPM. Thus a counter can never roll back, even by deleting and re-creating the index.
TPM 1.2 users might be familiar with monotonic counters. These NV counters are the equivalent, but the user is free to define none or as many as are needed up to TPM resource limits.
a key holder wants to revoke access to a key. the key is created with a policy that says the key can be used (the policy can be satisfied) as long as the counter value is equal to its current value. Incrementing the counter revokes access.
the tpM commands are as follows:
TPM2_NV_DefineSpace: counter index, password of key holder, password to write, and a policy to read. the policy is TPM2_PolicyCommandCode with the command TPM2_PolicyNV. this policy allows anyone to use the index in a policy essentially without authorization.
TPM2_Create: Create a key with userWithAuth clear, requiring a policy to authorize the key. the policy is TPM2_PolicyNV with the NV value equal to all zero.
TPM2_NV_Increment: revokes authorization to use the key.
NV Bit Field Index
A bit field contains 64 bits, initialized to all bits clear at the beginning of the first write, which can also optionally set bits. A bit (or bits) can then be set but never cleared.
a key holder wants to grant and later revoke access to a key for up to 64 users. the key is created with a policy with up to 64 Or terms. each term combines some authorization specific to each user (a biometric or smart card digital signature, for
example) and an assigned bit being clear. the key is revoked for that user by setting the bit in the NV bit field.
TPM2_NV_DefineSpace: bit field index, password of key holder, password to write, and a policy to read. the policy is TPM2_PolicyCommandCode with the command TPM2_PolicyNV. this policy allows anyone to use the index in a policy essentially without authorization.
TPM2_Create: Create a key with userWithAuth clear, requiring a policy to authorize the key. the policy is TPM2_PolicyNV with the operand TPM_EO_ BITCLEAR (the bit assigned to the user is clear).
TPM2_NV_SetBits: setting the bit assigned to the user, thus revoking authorization to use the key.
NV Extend Index
An extend index is defined with a specified hash algorithm, and it's fixed for the lifetime of the index. The data size of the index is based on its hash algorithm. It's initialized to all zero before the first write. The write is an extend operation, similar to that performed on a PCR.
The most likely use case combines an extend and a hybrid index to create flexible PCRs, as discussed in the “Hybrid Index” section. Another general use case is a secure audit log, because any extend operation creates a cryptographic history that can't be reversed.
a certificate authority wants to log each time its key is used to sign a certificate.
It wants to be able to detect whether the log, kept on disk, has been altered. It creates an NV extend index for which it has exclusive write authority through a policy.
each time the Ca signs a new certificate, it logs the certificate and extends a digest of the certificate into the NV index. to validate the log, it walks the log, re-creating the extend value, and compares it to the NV index value. For additional security, it can even get a signature over the NV index value.
the tpM commands are as follows:
• TPM2_NV_DefineSpace: extend index, policy to write by Ca, and a policy to read by anyone. the Ca signs a certificate, logs the certificate in an audit log, and digests the certificate.
• TPM2_NV_Extend: adds the digest to the NV audit log. If the certificate is small enough, it can be extended directly. however, it's probably faster to digest outside the tpM and extend just a digest.
Yet another new TPM 2.0 feature is the hybrid index. As with a nonhybrid, the NV index metadata (its index handle, size, attributes, policy, and password) are nonvolatile; its data is created in volatile memory. Except for hybrid counters (described later) the index data is only written to NV memory on an orderly shutdown. Any of the four index types (ordinary, counter, bit-field, or extend) can be a hybrid index.
Hybrid indexes may be appropriate when the application expects frequent writes. Because NV technology is often subject to wear out, a TPM may protect itself by refusing to write at a high rate. Volatile memory doesn't have wear-out issues, so a hybrid index can be written as often as required.
Hybrid index data may only be present in volatile memory if the index is deleted before an orderly shutdown. An application could define the index, write data, use the values in a policy, and then delete the index.
the simplest use case is adding pCrs beyond the number the tpM vendor provides, typically 24 for a pC Client tpM. as with the permanent pCrs, the index persists through power cycles, but the value is reset back to zero. this means pCrs are no longer a scarce resource (“beach front property,” in tCG work group slang).
the tpM commands are as follows:
• TPM2_NV_DefineSpace: hybrid extend index, well known null password, so that anyone can read and extend
• TPM2_NV_Extend: Now equivalent to TPM2_PCR_Extend
an application requires pCrs, but the standard tpM pCrs have fixed attributes specified by the platform. For example, the operating system may restrict access, the application may want pCr authorization restrictions, the application may need a hash algorithm different from those in effect for the tpM pCrs, or the application might want extends restricted to an extended locality.
the application creates a hybrid extend index with the desired attributes,
uses them as pCrs, and then deletes the index when the application terminates. Note that, because the index is a hybrid, the extend doesn't write NV memory, avoiding performance and wear-out issues.
• TPM2_NV_DefineSpace: hybrid extend index, applicationspecific digest algorithm, application-specific extend policy more restrictive than “anyone can extend.”
• TPM2_NV_Extend: as needed by the application.
• TPM2_NV_UndefineSpace: when the application terminates.
these pCrs can have read authorizations: policy authorizations for either read or write different from those of the platform. they can be used in virtual tpMs to record the state of a helper VM inside the vtpM of a VM (see the Virtualization specification).
a VMM creates an NV extend hybrid index for each VM. When the VMM creates a VM, it creates a corresponding pCr using a hybrid extend index. as the VMM starts the VM, it uses introspection to read and measure the VM's boot code, extending the measurements into the VM's pCr.
this requires a single command:
TPM2_NV_DefineSpace: Create a hybrid extend index
Hybrid ordinary, extend, and bit-field indexes are only written to NV memory on an orderly shutdown. Hybrid counters are more complicated because of the restriction that they never roll back or miss an increment operation. This must be ensured even if the shutdown isn't orderly, when the volatile value would be written to NV memory.
To achieve this, the value is written (flushed) to NV memory every so many increments. Thus a hybrid counter may not be solely in volatile memory, even if it's deleted before an orderly shutdown. If an application wants to avoid the flush, or at least
determine when it will occur, a get capability command can report the flush period.
The second hybrid counter complication occurs on startup. If the most recent value wasn't flushed to NV (through an orderly shutdown), the count is set to the highest value it could have had without causing a flush. That is, it might skip some counts, but it will never roll back or miss an increment.
NV Access Controls
We previously discussed the major NV attributes: whether it's an ordinary, counter,
bit-field, or extend index, and whether it's a hybrid index. An NV index also has unique controls that are different from objects like keys. Perhaps the most interesting is that it can
have separate controls for read and write. In particular, each index can be defined to use its policy, its password authorization, or the owner password or authorization, and the attributes can be set independently for read and write.
The TPM supports a set of NV index read and write locks. An index may be writelocked permanently. It can be writeor read-locked until the next TPM reset or restart. An index may be part of one set of indexes that can be locked in one operation (a global lock), again until the next reset or restart.
Finally, many TPM entities are protected by the dictionary-attack protection mechanism. After some number of failed authorization attempts, the TPM rejects authorization until a certain amount of time has passed. An NV index may be protected as well, but an attribute can be set to remove the protection. Removing the protection might be applicable if the authorization password is known to be a strong secret.