KID0005 - Next Key Commitment (Pre-Rotation) - Commentary

Navigation

Back to table of contents |Link|Commentary|Section |—|—|—| |0000|X|Glossary, overview, how to use| |0001|X|Prefixes, Derivation and derivation reference tables| |0002|X|Data model (field & event concepts and semantics)| |0003|X|Serialization| |0004|X|Key Configuration (Signing threshold & key set)| |0005|X|Next Key Commitment (Pre-Rotation)| |0006|X|Seals| |0007|X|Delegation (pending PR by Sam)| |0008|X|Key-Event State Machine| |0009|X|Indirect Mode & Witnesses| |0010||Recovery/consensus Algorithm (KAACE)| |0011||Database & Storage Considerations| |0097|n/a|Non-Normative Implementation Guidance| |0098|n/a|Use Cases| |0099|n/a|Test Vectors and Normative Statement Index|

Rationale for Nextkey design

Note: For the sake of simplicity and ease of understanding, in this section, event configuration is simplified to only include the most relevant details. Likewise all key sets are simplified to have only a single key. Fully explicated event configuration including key sets with multiple keys is described in detail in section { link }.

Each inception operation involves two sets of keys that each play a role in the event. The two roles are labeled initial current or initial for short, and next. The inception operation creates both sets of key-pairs. The first set consists of the initial (original incepting) key-pairs bound to the identifier prefix as the current root control authority. The second set consists of the next (ensuing) pre-rotated key-pairs. The inception event itself includes the public keys from the initial set of key-pairs and a cryptographic digest the public keys from the next set of key-pairs. They are all qualified. Recall from fig. 7.3 above the basic format of a key event message. The set of next (ensuing) pre-rotated public keys is in hidden form as a qualified digest of the set of keys. A simplified inception event with a single key per set and a hidden next key as a digest is diagrammed as follows:

{Figure 9.1}Simple Inception Event. The configuration includes the initial (original incepting) public key and a digest of the next (ensuing) public key (pre-rotation). The next public key is therefore hidden. Event is signed with initial current private key.

Upon emittance of the inception event the initial key-pairs become the current authoritative signing key-pairs for the identifier. Emittance issues the identifier. Moreover, to be verifiably authoritative, the inception event must be signed by the initial private keys. The inception event may be verified against the attached signatures given the included initial public keys. The inception event provides the incepting information (including the initial public keys) from which the identifier prefix was originally derived.

Note: Inclusion of the next set of public keys in the event effectively performs a pre-rotation operation on that set and the set itself may be called a pre-rotation set or pre-rotation for short. One important function of an inception event when initializing a pre-rotated self-certifying identifier is to declare, designate and perform a pre-rotation on the next set of keys. Besides confirming that the controller of the private keys authorized the inception event, verifying the signatures also proves control over the identifier prefix. Furthermore, the inception event also makes a verifiable commitment to its designated set of pre-rotated next public keys.

To be authoritative, a rotation operation must be signed by the current set of authoritative keys. Consequently, only the current set is exposed and the next set remains unexposed. By virtue of the rotation, the former set of next pre-rotated keys from the more recent prior rotation becomes the newly current set of signing keys, and the new next set of newly created pre-rotated keys will become the ensuing set of current signing keys upon the next rotation. Each rotation operation makes a signed commitment to its set of next pre-rotated key-pairs. This commitment is realized by the following rotation that is signed by the newly rotated-to-current controlling sets of key-pairs. Each subsequent rotation operation in turn creates a new next set of pre-rotated key-pairs and includes the associated set of public keys (hidden or not) in its rotation event.

Because former set of next (ensuing) pre-rotation keys is hidden behind a digest, the following rotation must include the associated unhidden public keys. By virtue of the rotation, these have become the newly current public keys and are included in the configuration with that label. The rotation event also hides its next (ensuing) rotated public key(s) behind a qualified digest.

Figure 9.2. Simplified Rotation Event. The configuration includes both the current public key (formerly next) and the digest of the new next (ensuing) public key (pre-rotation). Next public key is therefore hidden. Event is signed with the new current private key (formerly next).

Explanatory diagram

To help clarify an example rotation history is diagrammed below. In the diagram all the keys are taken from to a single indexed key sequence. Each each key labeled with its index and each key element is labeled by role.

Simplified events showing only sequence number (SN) element from header. Inception and rotations showing key-pair sequence indexing where C1 represent key 1 and C1 represents hidden key 1:

Security

For many exploits, the likelihood of success is a function of exposure to continued monitoring or probing. Narrowly restricting the exposure opportunities for exploit in terms of time, place, and method, especially if the time and place happens only once, makes exploit extremely difficult. The exploiter has to either predict the one time and place of that exposure or has to have continuous universal monitoring of all exposures. By declaring the very first pre-rotation in the inception event, the window for its exploit is as narrow as possible. Likewise, each subsequent rotation event is a one time and place signing exposure of the former next (pre-rotated) rotation key. Because each pre-rotation makes a cryptographic future commitment to a set of one-time firsttime rotation keys, later exploit of the current authoritative signing key(s) may not capture key rotation authority as it has already been transferred via the pre-commitment to new unexposed set of keys. To elaborate, The next (ensuing) pre-rotated key-pairs in an inception event serve as one-time first-time rotation keys in the next rotation operation. Thereafter those key-pairs may be activated as the new current (root) authoritative signing key(s) but no longer have rotation authority. Likewise the next (ensuing) pre-rotated key-pairs in each rotation event serve as onetime first-time rotation keys in the next rotation operation. Thereafter those key-pairs may be activated as the new current (root) authoritative signing key(s) but likewise not longer have rotation authority. In administrative identity systems the binding between keys, controller, and identifier may be established by administrative fiat. As a result administrative fiat may be used as well as a recovery mechanism for compromised administrative keys. This may permit more exposure through multiple use of each key. In contrast when the binding between keys, controller, and identifier is purely cryptographic (decentralized) such as is the case with this protocol, there is no recovery mechanism once the keys for the root control authority have been fully captured. Therefore security over those keys is more critical. As a result in this protocol administrative (establishment operation) keys are one-time first-time use as administrative keys. By definition a dead attack occurs sometime after creation and propagation of a given rotation event. A successful dead attack must first compromise the set of current signing keys for some past rotation event and then create an alternate verifiable version of that past rotation event and then propagate this alternate event to a given validator before the original event has had time to propagate to that validator or any other component the validator may access. The pre-commitment to the next set of keys means that no other successful dead exploit is possible. A subsequent rotation event that was not signed with the pre-committed next keys from the previous rotation would not be verifiable. But compromising a set of keys, after first-use, given best practices for key storage and key signing, may still be very difficult. Nonetheless, some time later should an attack succeed in compromising a set of keys and thereby creating an alternate but verifiable event, a validator or other component may still be protected as long as the original version of the event has had time to propagate to that validator or other component (such as witness, watcher, juror, judge) that the validator may access. In order to successfully detect duplicity and thereby be protected, any validator need merely compare any later copy of the event with any copy of the original event as propagated to any component it may access. The attacker, therefore must get ahead of the propagation of a past rotation event. Recall that the original version of the event is the one that first exposes the keys to be compromised. This may only allow a very narrow window of time for an attacker to get ahead of propagation. In other words, in order for a dead attack to be successful it must completely avoid detection as duplicitous. To do this it must either prevent the validator from gaining access to any original copy of the key event history or equivalently must first destroy all extant copies of the original key event history accessible to the validator. This may be very difficult. Moreover a controller merely needs to receive confirmation of receipt by a validator of its last rotation event to ensure that that validator is protected from future dead exploit. To summarize, an alternate but verifiable version of a rotation event would be detectably inconsistent with the original version of the event stored in any copy of the original key event history (KEL/KERL). Consequently any validator (or other component or entity) that has access to the original key event history is protected from harm due to a later successful compromise of the keys of any event already in that history. To further protect the initial key-pairs in an inception event from a dead exploit, a controller may coincidently create both the inception event and an immediately following rotation event and then emitting them together as one. The initial (original incepting) key-pairs may therefore be discarded (including removing all traces from signing infrastructure) after creation but before emission of the coincident events thereby minimizing the exposure of these initial key-pairs.

In this diagram, the event key elements are labeled with their key-pair sequence index, such as, C^2 for key 2, C-2for exposed key 2, and C-~2 for compromised exposed key 2. In a dead attack key C2 is compromised some time after and a result of its first exposure in event 2. Time of exposure is shown in diagram by appearance of C-2and time of compromise is shown by appearance of C-~2. Given compromised C-~2, attacker may create verifiable but alternate version of event 2 with new next key D^3 under attacker’s control. But original event 2 has already been emitted, therefore a validator may already have access to a copy of original event 2 and will detect alternate event 2 as duplicitous. This prevents dead attack success. In order to be successful attacker must prevent a validator from first seeing event 2 until after attacker has first seen event 2 and then compromised key C^2 and then created alternate version of event 2. By emitting event 2 directly to validator or other component validator may access such as witness, controller may thereby prevent a successful dead exploit at any later time. In contrast, a live attack is defined as an attack that somehow compromises the unexposed next (pre-rotated) set of keys from the latest rotation event before that event has been propagated. This means compromise must occur at or before the time of first use of the keys to sign the event itself. Such a compromise is extremely difficult and the primary reason for employing pre-rotation as a live exploit protection mechanism. Moreover, assuming such a compromise, duplicity detection may not protect against a resulting live attack. This is because such a live attack would be able to create a new verifiable rotation event with next keys under the exploiter’s control and propagate that event in advance of a new rotation event created by the original controller. Such a successful live exploit may effectively and irreversibly capture control of the identifier. Moreover, in the case of successful live exploit new rotation events from the original controller would appear as duplicitous to any validator or other component that already received the exploited rotation event. Protection from live exploit comes exclusively from the difficulty of compromising a set of keys at or before the time of first-use. To elaborate, a successful live exploit must compromise the unexposed next set of private keys from the public-keys declared in the latest rotation. Assuming the private keys remain secret, compromise must come either by brute force inversion or by a side channel attack at the first-use of the private keys to sign the rotation event. By construction, no earlier signing use sidechannel attack is possible. This makes successful live exploit from such side channel attacks extremely difficult. Given the cryptographic strength of the key generation algorithm, a successful brute fore live attack may be practically impossible. Hiding the unexposed next (pre-rotated) public keys behind digests, provides additional protection not merely from pre-quantum brute force attacks but from unexpected post-quantum brute force attacks as well. In this case, a brute force attack would first have to invert the post-quantum resistant one-way hashing function used to create the digest before it may attempt to invert the one-way public key generation algorithm. Moreover as computation capability increases the controller need merely rotate to correspondingly strong cryptographic one-way functions including post-quantum hashing functions. This makes brute force live attack practically impossible indefinitely.

In fig. 9.6 the event key elements are labeled with their key-pair sequence index, such as, C3for key 3, C-3 for exposed key 2, C_3 for hidden key 3, and C_~3 for hidden, unexposed, but compromised key 3. Suppose a live attack. Recall that a live attack requires that somehow key C_3 be compromised sometime after it is declared in original event 2 but before it is first exposed in original event 3. Indeed, before the existence of event 3. Time of exposure is shown in diagram by appearance of C-3 and time of compromise is shown by appearance of C_~3. Given compromised C_~3, attacker may create verifiable but alternate version of event 3 with new next hidden key D_4 under attacker’s control. As a result of the pre-exposure compromise of C_~3, the alternate version of event 3 may be created before the original and therefore preempt it. Nonetheless, given that the private key for C^3 remains private prior to its exposure, the only way to compromise C^3 is to invert C_3, a practical impossibility. This prevents live attack success.

Summary

In summary, pre-rotation with duplicity detection protects a validator from harm due to both dead and live attacks. With dead exploits, the caveat is that in order for a validating party to able to detect and discard any later forged alternate rotation events it must needs have access to a copy of the original key event history. But with pre-rotation, any verifiable alternate rotation event must undetectably replace a specific preexistent rotation event in every copy a validator may access from any other component. This makes successful dead exploit difficult. Replay of any original copy allows the validator to verify the provenance of the original chain of rotations with respect to any alternate copy. In other words, a successful dead attack must not only compromise a given set of rotation keys in order to create a specific alternate but verifiable version of the rotation but must also ensure its version is the first version propagated to every component the validator may access. Furthermore a controller merely needs to directly propagate any new rotation event to a validator or other component the validator may access such as a witness to protect that validator from any later (dead) attack on that rotation. On the other hand, a successful live exploit must compromise a set of pre-rotated keys at or before first use of those keys. This constrains the time and place of first use to the controller’s choosing and makes exploit extremely difficult. This difficulty protects against live exploits.

Other Features

Besides enhanced protection (security), the pre-rotation approach has some other useful features. In its simplest form, pre-rotation does not require any special rotation key infrastructure. This makes the approach self-contained. As discussed earlier, a common approach to key rotation management is to have a special purpose management (administrative) rotation key-pair whose function is to authorize rotation operations on a signing key-pair. This poses the problem that after multiple rotations the management rotation key becomes exposed and may be vulnerable to exploit. Consequently another higher tier of management rotation key may be needed to authorize rotation’s of the lower tiers management rotation key and so on. In contrast, in it simplest form pre-rotation uses just one tier of rotation keys. In essence a pre-rotated key set is effectively a one-time first-time use rotation key set on the next (ensuing) rotation. When that ensuing rotation is executed, a new pre-rotation key set is created and the old rotation key set may be repurposed as the current signing key for operations other than rotation. This thereby avoids the infinite regress of successively higher tier rotation keys. The design aesthetic behind this approach is that of minimally sufficient means. A key state verification engine may employ this single tier or solo architecture as a compositional primitive. Using the primitive, rotation keys are one-time first-tim use but then may be optionally repurposed as signing keys. More complex hierarchical architectures may then be supported via composition of this primitive into multi-tier designs as opposed to building a bespoke primitive for each architecture. The following section will discuss how to compose systems with different features using the core primitive. For the sake of simplicity the examples in the following subsections use single-signature versions of the events but without loss of generality may be extended to thresholded multiple-signature versions as well.