The Classical Authenticated Diffie-Hellman Exchange Revisited

with the Bladderwort Protocol Feature Addition

Thierry Moreau

Document Number C005802


Copyright (C) 2016 CONNOTECH Experts-conseils inc.

Verbatim redistribution of the present document is authorized.

This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Specifications subject to change without notice.

Table of contents

1. Abstract

2. Introduction

3. Protocol Overview

3.1 Classical Authenticated D-H Exchange

3.1.1 The Historic Perspective

3.1.2 Buttom Up Justification

3.1.3 Peripheral Work

3.2 Bulk Secure Communications Channel

3.3 What's in a Name

4. Preliminaries

4.1 Definitions

4.2 Algorithms

4.3 Major Software Components

4.4 Notation

4.5 Protocol Message Types

5. Original Authenticated Diffie-Hellman Exchange

5.1 First Round Trip of Messages

5.2 Key Derivation Details

5.3 Naming Conventions for the Second Round Trip of Messages

5.4 Second Round Trip of Messages

5.5 The AEAD Mechanism for Bulk Secure Communications

6. The Bladderwort Protocol Feature Addition

6.1 Use Case Description

6.2 Temporary Signature Key Pair Announcement

6.3 D-H Exchange with Recourse to Temporary Key Pair

6.3.1 Response with D-H Signature Based on the Temporary Key Pair Lein Harn Signature Scheme Details

6.3.2 Response with D-H Signature Based on the Long Term Key Pair

7. Discussion: Derived Design Challenges

7.1 Authentication Trustworthiness

7.2 Secrecy Protections

8. The Secure System Operator Model

9. References

A. Summary of Security Critical Number Generation Requirements

A.1 Cryptographically Strong Secret Random Numbers

A.2 Nonces Characterized by Cryptographically Critical Uniqueness

Document Revision History






Current version



Initial release.



Document revision a) following implementation experience, b) inserting a section about an operator mental model, and c) miscellaneous editorial and minor technical updates.

1. Abstract

When a secure data communications channel between two distant server systems must be established, the TLS (Transport Layer Security) is the solution that comes first to the mind of IT security experts. Departing from this default common wisdom, we revisit the authenticated Diffie-Hellman exchange as a solution well rooted in the early ideas in the field of public key cryptography, refined by the dedication of theoreticians, and entrenched in a few (less conspicuous) Internet secure protocol standards, namely IPSEC IKE and HIP. Under the name Bladderwort, we also propose a minor protocol addition for streamlined server operations where a long-term private signature key is better kept off-line during the operational phase of the secure communications channel.

2. Introduction

The original D-H cryptosystem publication [1] has been followed by the development of workable public key digital signatures (most notoriously RSA) and the concept of security certificates for automated trust decisions for a remote party public signature key. The authenticated D-H exchange combines these developments for the establishment of an authenticated shared session key between a local and remote party, with the authentication based solely on a trusted certification authority (CA) public key. This high level description of the field should be somehow familiar to most readers. In here, we reconstruct the D-H exchange from the early ideas, some recent revisions of security-relevant details, plus a couple consensus-supported cryptographic algorithms. We also propose an original protocol feature addition aimed at enhanced private key protection in a specific operational arrangement model.

A primary motivation for the present document is to fill some gaps between the academic work in the field of cryptographic protocols and the practice of applied cryptography. Few fielded cryptographic schemes are documented in a way that facilitates a security review based on validating the correspondence between implementation characteristics and peer reviewed publications. Actually, the implementation activities intrinsic to the applied cryptography field, including the high level design and the detailed design phases, would benefit from the documentation angle used here. Indeed, the present document offers an abstract specification focused on security aspects and from which some implementation design work may be derived.

The abstract design presented here favors simple concepts from early theoretic contributions over more elaborate schemes which may be more efficient and/or fashionable (e.g. original Diffie-Hellman scheme preferred over elliptic curve cryptography equivalent). An uniform level of abstraction is not a priority: whenever a specific cryptographic mechanism appears adequate for the conceptual presentation, it may be part of the document contents in place of a more abstract reference to an enclosing class of cryptographic mechanisms. The abstraction is more systematic in the protocol interoperability issues that has only indirect effect on a scheme security.

In essence, this is a simplification exercise aimed at an abstraction tacitly intended for an ad-hoc implementation project and for ease of security review. In the simplification part of the mandate we remove protocol features beyond the core shared secret establishment functionality and we select a single concrete algorithm where the standard documents favor algorithm agility. In the abstraction part of the mandate, protocol packet encoding is left unspecified and no attempt is made to define a service boundary (application programming interface).

The pretense to facilitate a security review is also tainted by the other document goals. As an abstraction, neither a security audit checkist nor a definite target of evaluation are provided. Both of these usually derive from a formal specification which the review had to follow, with a well defined security theory of operation. Serious security reviews in the absence of such formalism are possible if the reviewer is qualified to first postulate a threat model from evidence about the cryptography usage context and operational requirements, then document the applicable "industry best practice" (some expertise required), and finally review the cryptographic deployment against this threat model and relevant best practice. The present document is a contribution to best practice documentation.

3. Protocol Overview

3.1 Classical Authenticated D-H Exchange

3.1.1 The Historic Perspective

The industrial application of public key cryptography concepts for telecommunications were first envisioned for secure telephony, both as a US government controlled technology with the STU-III model ([2]) and as the then emerging ISDN technology (e.g. references 41 and 81 in [2]). Indeed, two detailed disclosures of the basic authenticated D-H exchange were made by researchers at two telephone equipment manufacturer research organisations, namely Bell Northern Research ([3]) and AT&T Bell Laboratories ([4]). The Bell Northern publication is known as the Station-to-Station (STS) protocol and is acknowledged as a source of inspiration for the later developments. Notably, this basic scheme was first standardized in the OSI network layer security protocol (NLSP, [5]) and transport layer security protocol (TLSP, [6]). These references are not to be confused with the reference [7] which is sometimes cited as an STS variant while actually making no use of the Diffie-Hellman cryptosystem. With the domination of Internet protocols over ISDN and OSI came the adoption of the SSL protocol that got IETF endorsement as the TLS protocol, without a connection to STS. The latter made a comeback in the IPSEC protocol suite as IKE and then IKE version 2 ([8]). It is in this form that the authenticated D-H exchange is present in modern networks, with security critical improvements explained in an essential article by Hugo Krawczyk ([9]). This state of the art gets a further endorsement in the Host Identity Protocol (HIP, [10]), a leading edge research proposal for secure Internet protocol.

However the seemingly endless IPSEC protocol standardization details obscure the essential characteristics of the authenticated D-H exchange, notably due to a dedication to interoperability in presence of many implementation options. A trend in the IPSEC options expansion is the adoption of optional authentication schemes other than public key cryptography digital signatures, e.g. Extensible Authentication Protocol (EAP). Also, the IKE protocol has provisions for cryptographic key management beyond the initial authenticated D-H exchange, notably for rekeying and establishment of parallel logical secure channels. The tutorial aspect of the present document partially addresses this opacity since it was derived from the IKE version 2 protocol with the proper options and configurations for compliance to the protocol and cryptographic security principles explained in the article by Hugo Krawczyk ([9]). In here, we also limit the specification to the initial authenticated D-H exchange.

The relatively small usage of the genuine authenticated D-H exchange might be explained by the practical deployment challenge of digital signature key pairs for every communicating entities (client security certificates in the TLS jargon which puts the user mental model remote from the inner working of digital signatures). In this historical perspective, the authenticated D-H exchange would be the core of the lost art of classical public key cryptography. Indeed, one may notice the prudent recommendation in section 5.2 of the original STS publication ([3]) that anticipated to the very root cause of the Logjam major vulnerability in Internet security protocols uncovered in 2015 ([11]).

3.1.2 Buttom Up Justification

Another approach to justify the relevance of the authenticated D-H exchange is bottom up, starting from a naive desire to establish a scrambled communication channel between two parties on the Internet. By some iterative learning and creativity process, the pitfalls of an home brewed encryption scheme might be understood and fixed. That would start with a conventional symmetric cipher, then the addition of symmetric integrity protection and the naked Diffie-Hellman exchange for setting up a shared key (a rudimentary hybrid cryptosystem). The MITM vulnerability would come next, and so on until the full authenticated D-H exchange is considered an essential requirement for key establishment. In this process, the benefits of forward secrecy and desirability of traffic flow confidentiality would further disqualify alternative solutions. At the end would remain the authenticated D-H exchange for key establishment and a bulk secure communication scheme for the actual data transmission (any rekeying requirement is explicitly omitted and may be the subject of further study). In the IPSEC world, the latter is the Encapsulating Security Payload (ESP) protocol [12]. The next subsection explains the abstraction strategy for bulk secure communications, motivated by the completeness of our abstract exposition focused on key establishment.

3.1.3 Peripheral Work

While standardization bodies adopted the reference [9] as a yardstick for authenticated and key agreement using public key cryptography with the RSA digital signature algorithm as a tacitly endorsed solution, the early ideas behind the ElGamal digital signature scheme ([13]) brought two development paths addressing the mutual authentication problem for the basic D-H exchange. These schemes rest on the discrete logarithm cryptography (as opposed to factoring-based cryptography for the RSA digital signatures).

In a first development path, the two-way authentication of Diffie-Hellman shared secret contributions is wholly achieved with discrete logarithm based cryptography (i.e. neither hash functions nor factoring based cryptography are needed), with digital signature schemes specialized for Diffie-Hellman shared secrets. This is a little noticed research direction, brought in the present work through publications by professor Lein Harn. The basic idea is in the reference [14]. However, when applied to mutual authentication in a Diffie-Hellman exchange, an attack ruins the forward secrecy property. This was fixed in reference [15], and a more elaborate proposal came in reference [16]. This alternate research direction hints that the standardization solution may not be the last word in every aspects. It may also help the structured study of the diversified set of discrete log cryptosystems.

Below, we make use of the basic idea from [14] for unilateral digital signature of a D-H shared secret contribution (this design desision is independent from the later developments in [15] and [16]).

The second discrete log intensive development path would now be known as MQV ([17], with refinements in [18] and [19]) although the seminal work seems to be from reference 30 in [18]. These are D-H exchange protocols whose communication is identical to the basic D-H protocol (i.e., no explicit authentication added except for the possible transmission of security certificates), yet they are implicitly authenticated by the sole ability of the parties to compute the resultant session key. This actually obsoletes the two round protocol at the core of the classical authenticated D-H exchange, with subtle implications discussed in the literature. The lack of deployment experience among applied cryptography communities for these schemes may be caused in part by debates among theoretical contribution authors.

3.2 Bulk Secure Communications Channel

In IPSEC, once a shared symmetric secret key is established with IKE version 2, the ESP protocol provides the bulk secure data transmission capability. Through the elimination of protocol details, ESP turns into an equivalent to secure data transport using a mode of operation for a block cipher and a symmetric integrity primitive called "authenticated encryption with auxiliary data" (AEAD). Actually, AEAD is a class of symmetric key cryptography modes of operation and we refer only to the subset of concrete schemes that require a nonce value in each encrypt-and-seal operation. A candidate AEAD scheme is AES-CCM ([20]). The abstraction is basically a substitution of the ESP convention by an AEAD convention. Accordingly, the secure communications channel is implemented by AEAD cryptogram transport in each direction of transmission along with a symmetric secret key reference and the AEAD nonce which fulfills the role of replay attack detection in the ESP protocol.

Also, the IPSEC architecture allows multiple ESP instances to be created and managed in the context of an authenticated D-H exchange. This multiplexing feature is not retained in the abstract model presented here.

Note that the ESP provisions for nonce generation include a fixed part and a variable part in an arrangement which is neither required by the AEAD properties nor justified by any explicit reasoning worth a citation in the present context. For sake of design economy, this ESP protocol provision is not kept in our proposal. A puzzled reader is invited to investigate this issue independently (and thus potentially come up with some critic of the AEAD model since an sound ESP rationale might apply to AEAD as well).

3.3 What's in a Name

The present author typically uses plant species names from the aquatic flora for identifying innovative concepts in applied cryptography. In the case of the D-H exchange feature addition presented here, the limited claim of practical benefit argued against any specific designation, but the distiction between the original D-H exchange and its augmented version is deemed useful: references to the present document without the Bladderwort proposal are more readily made with a specific name.

The aquatic plant bladderwort (botanical name utricularia vulgaris or utricularia macrorhiza) is a floating plant devoid of roots, which reminds the remoteness of the present document from any security protocol standard. The bladderwort is a carnivorous plant, but its subtle trapping mechanism is hard to observe, which reminds the subtle security benefit of the Bladderwort D-H exchange addition.

4. Preliminaries

The following description is the detailed abstract specification of a specific variant of the authenticated D-H exchange. The design choices are largely inspired from IKE version 2 (as a precise specification to be abstracted) and the Krawczyk article ([9]) (as academic principles to be rendered concrete). Also, in-band protocol option negotiations is left out of the abstract design, e.g. a fixed profile of cryptographic algorithms, modes, and key size restrictions is assumed. The abstract specification is protocol packet encoding agnostic.

One party is the initiator, and the other is the responder. The exchange protocol establishes shared secrets for the security association between the initiator and responder.

4.1 Definitions

Security Association
A relationship established between the initiator and responder to enable them to securely communicate, represented by a set of data independently a each end of the association. A foremost element of a security association is symmetric secret key(s) which are shared between the two legitimate parties if the D-H exchange proceeds well.
Refers to either to the initiator or responder as a digital computing environment performing the cryptographic operations on behalf of its respective entity.
Refers either to the initiator or responder as the person, organisation, or an organization's automated process (e.g. an on-line service) which controls the respective party's computing environment.

4.2 Algorithms

Here is the list of core cryptographic algorithms used in the present proposal.

This is the core Diffie-Hellman public key cryptosystem ([1]). It requires a common agreement on a large prime p, and a generator g. In the present proposal, no provision is made for selection of these common cryptographic parameters outside of fixed values present in a predefined security profile.
AEAD, Authenticated Encryption with Associated Data
The abstract design should use the AEAD model and thus leave some flexibility in the derived work (e.g. with a selection of an AEAD algorithm implicit in a predefined security profile). Merely due to laziness, a single AEAD instance is reviewed as acceptable, namely AES-CCM ([20]) and the review of the AEAD abstraction implications is deferred to a revision of the present document.
Digital Signature
An unspecified public key cryptography digital signature algorithm (e.g. [21], [22]) is used for remote entity authentication. The selection is implicit in a predefined security profile. Some signature schemes are probabilistic (e.g. RSASSA-PSS, [23]) and thus require the generation of unpredictable random salt for each digital signature operation.
The classical message authentiation code (MAC) algorithm class refers to symmetric-key data integrity algorithms that output a short integrity tag given a long input string and a secret key. Nowadays, the preferred MAC scheme is the HMAC construction (or mode of operation) [24] which allows the use of a cryptographic hash algorithm as the core element of a MAC algorithm. HMAC is an abstract specification because its implementation requires a specific hash algorithm (a selection being implicit in a predefined security profile). The use of the abstract MAC in the present document occurs in relation to authentication management, where the processing result is a local pass or fail indication with the fail outcome handled by an out of scope process.
This is a specific instance of an algorithm in the HMAC category ([25]). It is used in the key derivation procedure described below, where a well-defined path to interoperable implementations was found useful (i.e. with actual numbers for symmetric key and integrity tag sizes).
Lein Harn Diffie-Hellman Digital Signature
The reference [14] is applied in our Bladderwort protocol feature addition for a digital signature scheme specialized for Diffie-Hellman shared secret contributions. It is included in our design for its efficient signature key pair generation, its conceptual simplicity, and a natural fit for the exact unidirectional digital signature requirement created by operational consideration for secure handling of long-term private signature keys.

4.3 Major Software Components

The authenticated D-H exchange is by itself (and with the companion bulk secure communications channel) a computerized method, if not an algorithm with cleanly delineated interfaces. In the perspective of software functions structure, it may be broken down in three or four blocks.

Protocol and Security Association Management
This software function block interfaces with the network access facilities in the local computer system. It is exposed to the threats inherent to the network connections.
Bulk Secure Communications Channel
The bulk secure communications channel is either a separate software function block or an integral part of the overall protocol management function.
Key Derivation
The key derivation software function block is a formal component of the present proposal, completely specified in order for the exchange protocol to perform its stated function.
Identity and Access Control Management
This software function block interfaces with the local implementation of trust management in the remote entities' public signature keys. The naming conventions from the socio-legal environment may be an important source of detailed design guidelines for this software function block.

4.4 Notation

Concatenation of byte strings or encoded protocol message parameters.
[= a [# b #] =]k
AEAD (authenticated encryption with auxiliary data) processing of string a (authentication only) and b (encryption and authentication) with shared key k, implying some rule for the placement of AEAD nonce, ciphertext, and integrity tag in relation to cleartext string a. Implementation note: the algorithm is AES-CCM with 7 bytes nonces, 96 bits integrity tags, and 192 bits symmetric secret keys.
The result of the digital signature algorithm (according to the selection implicit in a security profile) applied to the byte string s. The applicable digital signature key pair is defined in the textual description of the protocol chart where this notation appears.
The result of the message authentication code algorithm (according to the selection implicit in a security profile) applied to the byte string s using the symmetric secret key k. Implementation note: the MAC algorithm is HMAC-SHA-256 with a 192 bits symmetric key size.
The result of a specific message authentication code algorithm ([25]) applied to the byte string s using the symmetric secret key k.
As an intrinsic part of the Bladderwort proposal, the result of a specific digital signature algorithm (see section " Lein Harn Signature Scheme Details") applied to the byte string KEr (by definition this signature scheme applies to a Diffie-Hellman public value). The applicable digital signature key pair is specified in the present document, with the key life-cycle covered in section "6.2 Temporary Signature Key Pair Announcement" and key usage covered in section "6.3.1 Response with D-H Signature Based on the Temporary Key Pair".
A byte string that uniquely and conventionally identifies a protocol message type T in the context of D-H exchange protocol hosting (see below for specific instances). Implementation note: the protocol message types are encoded as a single byte value.
A byte string that uniquely refers to a complete suite of cryptographic algorithms, modes, and key size restrictions plus the D-H global parameters p and g. Implementation note: the profile is a single byte with the value 1 for the profile made of the present implementation notes.
A data packet (byte string) transmitted by a secure protocol between a sending application and a receiving application, the data protection mechanisms being supported by an instance of the authenticated D-H exchange.

4.5 Protocol Message Types

"INIT i"
First round trip initiator message, devoid of recovery key pair usage. Implementation note: 51.
"INIT r"
First round trip responder message, devoid of recovery key pair usage or denying recovery attempt. Implementation note: 52, or 62 if immediately followed by a protocol message AUTH r or AUTH ANN r.
Protected key exchange, a generic protocol message type for various specific message types in the second round trip of messages, the generic type value being sent in the clear while the specific types are sent concealed by encryption. Implementation note: 53.
"AUTH i" and "AUTH r"
Second round trip message, devoid of Bladderwort recovery key pair announcement. Implementation note: 54 and 55.
"AUTH ANN i" and "AUTH ANN r"
Second round trip message with Bladderwort recovery key pair announcement. Implementation note: 56 and 57.
First round trip initiator message requesting Bladderwort recovery based on responder recovery private key. Implementation note: 58.
First round trip responder message providing Bladderwort recovery signature by responder. Implementation note: 59.
Second round trip initiator message acknowledging Bladderwort recovery and with new recovery key pair announcement. Implementation note: 60.
Application payload message in the context of bulk secure communications channel. Implementation note: 61.

5. Original Authenticated Diffie-Hellman Exchange

The complete authenticated D-H exchange requires two round trips of messages between the initiator and responder. Message transmission and message fields are shown in protocol charts like the following one which depicts the complete exchange.

     "INIT i"|SPIi|KEi|profile --->
<--- "INIT r"|SPIi|SPIr|KEr
     [= "PKE"|SPIr| [# "AUTH i"|CERTi|sign("INIT i"|profile|KEi|SPIr)|MAC(SK_pi,PUBi) #] =]SK_ei --->
<--- [= "PKE"|SPIi| [# "AUTH r"|CERTr|sign("INIT r"|profile|KEr|SPIi)|MAC(SK_pr,PUBr) #] =]SK_er

In the protocol charts, the background colors assist the understanding of cryptographic processing applied to message fields:

Implementation note: ASN.1 BER encoding of cleartext portion of messages, with an opaque trailer comprising the ciphertext and integrity tag; typically, the CCM auxiliary data fields are embedded in an ASN.1 structured value followed by the AES-CCM nonce encoded as the first ASN.1 OCTET STRING value (at this level of indentation), then followed by the ciphertext length as the first ASN.1 integer value.

5.1 First Round Trip of Messages

The initiator chooses a random secret xi and sets KEi=gxi mod p. The initiator chooses a random nonce SPIi as a locally unique identifier for the security association to be established.

The initiator sends the first message to the responder.

The responder chooses a random secret xr and sets KEr=gxr mod p. The responder chooses a random nonce SPIr as a locally unique identifier for the security association to be established.

The responder sends the response message back to the initiator.

Since the SPI values are used as nonces in the key derivation procedure described below, their range should be large enough as a cryptographically significant parameter. The inventory of similar requirements is found in the annex "A. Summary of Security Critical Number Generation Requirements". Implementation note: the SPI fields are 16 bytes long.

In the protocol chart below, the initiator message announces the initiator's SPIi value as the required field contents for the responder message which in turn announces the responder's SPIr value. These values are then used in further messages between these two ends of the security association.

     "INIT i"|SPIi|KEi|profile --->
<--- "INIT r"|SPIi|SPIr|KEr

This completes the first round trip of messages and allows both parties to compute a D-H shared secret gxi.xr mod p, respectively as KErxi mod p for the initiator and KEixr mod p for the responder. The term "forward secrecy protection" refers to the limited damages of a disclosure of the D-H shared secret (or any of its contributing elements): the future instances of the D-H exchange will remain secure.

From this D-H shared secret, a symmetric key derivation procedure produces computational-complexity-independent purpose-specific keys: the D-H shared secret is transformed into a long random-looking string from which portions are taken for different purposes. The IKE protocol is meant to provide cryptographic keys for a bulk encryption protocol called Encapsulating Security Payload or ESP (child security association). In our abstract specification, a single instance of this bulk encryption protocol is keyed as an integral feature of the authenticated D-H exchange. The key derivation procedure is a two phase process described in the next subsection.

At this point in the authenticated D-H exchange logic, both parties share useful symmetric secret keys in a context defined by the (non-secret) values SPIi and SPIr (plus the profile), with security against passive eavesdroping, but lacking authenticattion assurance. This is the full materialization of bare D-H security benefits, with the important residual vulnerability to the man-in-the-middle attack: either local party has no assurance about the identity of the remote party and some enemy may act as a surreptitious relay.

5.2 Key Derivation Details

The key derivation procedure is composed of two phases, with the 32 octet string K as an intermediate value.

In the first phase, let

   K=HMAC-SHA-256(SPIi|SPIr,gxi.xr mod p)

and proceed with the second phase:

   T1 = HMAC-SHA-256(K,   SPIi|SPIr|profile|0x0001)
   T2 = HMAC-SHA-256(K,T1|SPIi|SPIr|profile|0x0002)
   T3 = HMAC-SHA-256(K,T2|SPIi|SPIr|profile|0x0003)
   T4 = HMAC-SHA-256(K,T3|SPIi|SPIr|profile|0x0004)

then take





SK_e is the AEAD encryption and integrity key for key management transmissions (e.g. the second round trip in the authenticated D-H exchange),

SK_c is the AEAD encryption and integrity key for child security association transmissions, and

SK_p is used in the MAC operation binding the name of an entity (initiator or responder as indicated by the indice i or r) to the D-H shared secret in the second round trip.

For SK_e and SK_c, each direction of transmission has its own encryption and integrity key, as indicated by the indice i or r referring to the sender side.

Implementation note: the value field gxi.xr mod p is ASN.1 BER encoded; all other fields are fixed length octet strings simply concatenated (network byte order -- most significant byte first -- for the four hexadecimal digit integer field).

5.3 Naming Conventions for the Second Round Trip of Messages

For the next round trip in the complete exchange, some naming conventions are needed for the initiator and responder identities. However, irrespective of such convention, there is a single mechanism by which the local system implementation of the authenticated D-H exchange may assist the recognition of the remote entity: a digital signature verification. In our abstract specification, we follow the HIP model where "the entity that holds the private key from the key pair" is identified foremostly by the public signature key. Specifically, we replace an entity identification string with the entity public key in the protocol message specification in the second round trip.

For sake of reconciling the exchange scheme description with the more classical view of a socio-legal convention of an entity name, we include protocol fields as possible entity name placeholders. Only as a tutorial convenience, these protocol fields are labelled CERTi and CERTr as a reference to security certificates as known in the context of a public key infrastructure (PKI): CERTi for binding the initiator public key PUBi to the initiator name and CERTr for binding the responder public key PUBr to the responder name.

Various bases for the local confidence in the remote entity are conceivable:

Irrespective of the actual trust basis, the CERTi or CERTr component of protocol messages is a possible placeholder for an entity name according to a socio-legal convention. The important point for the cryptographic processing is that the remote entity public signature key must be known locally and be agreeable as a trusted public key (i.e. adequate confidence that the private key counterpart is used only by the legitimate remote entity agent).

The criticalness of remote private signature key protection should not be obscured by the complexity of the PKI security certification model (or its replacement by another local trust basis). What matters for the present explanation is that a party long term signature key pair is trusted by the other party. What is not compliant to the present abstract specification is the replacement of a public key cryptography digital signature verification by e.g. MAC-based authentication with pre-shared secrets.

Note that the entity names are not necessarily tied to network addressing information.

Implementation note: as a facilitating strategy for the development of concrete designs from the above abstract model, it is useful to define two variants of the public key PUB values, respectively for digital signature verification algorithm compatibility and entity naming, thus facilitating a departure from the HIP naming model (in which case the second variant is no longer the direct image of a signature public key value).

5.4 Second Round Trip of Messages

In essence, the second round trip verifies a digital signature by the remote party. It also includes an opportunity for protected data exchange (based on the keys derived in the first round trip of messages), which is used for various protocol option negotiation tasks. This opportunity is used by IKE for network connectivity configuration of one or more ESP security associations, an arrangement that gives the IPSEC technology its VPN character. In IKE and HIP, the second round trip is an occasion for secure metadata establishment targeting child security associations. The present abstraction differs since the unique child security association uses options implicit in the profile and symmetric keys derived in the first message round. The protected data exchange opportunity may be used for additional protocol features like below in the Bladderwort proposal for the trusted introduction of a context-specific signature key pair.

The possibility for the second round trip integrity verification to fail is an integral feature of the authenticated D-H exchange. Its very added value is like an alarm indication for a IT security breach and as such it should trigger some action in a perspective often beyond the normal scope of production software. A frequent problem is the false alarms (e.g. caused by an erroneous network addressing configuration) which may induce an habbit of blindly accepting any solution to the alarm condition. The issue is compounded by the difficult task of configuring the local system basis for the remote entity authentication: this activity is at once a security significant decision, and typically implemented as yet another system configuration element. The security significance should be understood as an affirmative provision rather than a defensive one since the configuration activity defines the recognized remote entities. It is in this overall context that the term authentication gets its full meaning.

Access control and authorization management logically comes after remote party authentication issues. Semantically, access control may be seen as the authorization for the secure communications mechanism. Authorization management focuses on access rules for informational resources in general. Either aspect of security management may trigger a need to terminate a security association between the D-H exchange initiator and responder. The relevant case for the present document is such a termination decision made prior to the conclusion of the second round trip of messages.

     [= "PKE"|SPIr| [# "AUTH i"|CERTi|sign("INIT i"|profile|KEi|SPIr)|MAC(SK_pi,PUBi) #] =]SK_ei --->
<--- [= "PKE"|SPIi| [# "AUTH r"|CERTr|sign("INIT r"|profile|KEr|SPIi)|MAC(SK_pr,PUBr) #] =]SK_er

The second round trip details are specified by the above protocol chart. However, each direction of transmission is mostly independent except for the possibility for one party having processed the remote party message, to abort the whole exchange prior to sending its own message, notably if the remote entity authentication fails (digital signature validation failure). There is a traffic flow confidentiality benefit for this local party in a position to abstain from revealing its entity name to an unauthenticated malignant remote party attempting a man-in-the-middle (MITM) attack. Accordingly, the present abstraction is agnostic about the above order of message transmission. In this aspect, the above protocol chart depicts the IPSEC IKE concrete specification; the HIP concrete specification does include an inversion of message transmission, with the side benefit of a three message exchange (instead of four messages).

The above protocol chart specifies the cryptographic processing done by either party as the sender, and reversed by the respective receiver party. The cryptographic processing comprises three elements:

The security rationale for the detailed arrangement for the first two elements is the main and undisputed contribution of reference [9]. The last element is presented as an independent layer of protection, providing some confidentiality protection for the initiator and responder names (partial traffic flow confidentiality). Specifically, entity names and party public keys are protected against passive eavesdropper of the authenticated D-H exchange, and limited name confidentiality for active attackers is provided under the circumstances described above.

Implementation note: the digital signature input data encoding is fixed size fields for message type, profile, and SPI values, and ASN.1 BER encoding for KE values; ASN.1 BER encoding is also used for the entity names reflected in the PUB values in the MAC algorithm input data.

5.5 The AEAD Mechanism for Bulk Secure Communications

As indicated in the two protocol charts below and following section "3.2 Bulk Secure Communications Channel", the bulk secure communications operates as a simple connectionless message transmission with protections provided by the AEAD mechanism. This includes data integrity and confidentiality for the application payload portion of the message, plus some replay attack mitigation if the receiver party appropriately monitors the received AEAD nonces. A concrete design based on the present abstraction may specify AEAD nonce generation rules for the sender side in order to make the receiver side monitoring more effective and easier to implement.

The direction of transmission from the initiator to the responder is depicted in the following protocol chart.

     [= "ESP"|SPIr| [# payload #] =]SK_ci --->
     ... (repeated as needed by higher layer logic) ...

Independently, the direction of transmission from the responder to the initiator is depicted in the following protocol chart.

<--- [= "ESP"|SPIi| [# payload #] =]SK_cr
     ... (repeated as needed by higher layer logic) ...

A reasonable arrangement for receiver nonce handling is specified in the section 3.4.4 in the ESP standard document [12]. For the initiator-sender, a nonce variable is set to zero prior to the first message transmission protected with the key SK_ci. Thereafter, the sender nonce variable is incremented by one after each message transmission. A nonce reuse occurrence (same nonce value for two different messages) creates a catastrophic security vulnerability with any counter mode encryption scheme, irrespective of the receiver attempt to detect message replays.

At the responder-receiver side, incoming messages containing nonce duplicates are rejected through the use of a sliding receive window. The "right" edge of the window represents the highest, validated nonce value received with the key SK_ci. Incoming messages with nonce values lower than the "left" edge of the window are rejected. Messages falling within the window are checked against a list of received messages within the window. Some suggestions are made in the ESP standard document about the receive window size.

The ESP standard document contains recommendations for avoiding the cryptographic integrity validation processing overhead when receiving bogus messages. This sabotage or denial-of-service concern is absent in our abstract model. In practice, denial-of-service risks and countermeasures are context and implementation dependent.

Implementation note: some adjustment to the note at section "5. Original Authenticated Diffie-Hellman Exchange" is needed when the ciphertext opaque trailer is extended by other opaque data (which need not be encrypted in the above CCM instance) introduced by metadata encrypted in the above CCM instance: the ciphertext length ASN.1 elementary value may then be followed by the total opaque data trailer length, giving a piggyback mechanism as an efficient alternative to a more regular protocol encapsulation mechanism.

6. The Bladderwort Protocol Feature Addition

6.1 Use Case Description

While the authenticated D-H exchange is a fairly generic secure protocol scheme, the additional feature proposed here fits a narrower usage pattern. Specifically, our proposal assumes a sufficient motivation for an entity to apply differentiated protection (typically requiring human intervention) for its authentication private key used in the second round of messages in the D-H exchange (the private key used for the digital signature). This might be the case whenever the entity authentication security is perceived as a long term asset, but the burden of differentiated protection is usually too important whenever the frequency of D-H exchange occurrences is anything but very low (e.g. nearly as infrequent as a production server reboot event). A similar differentiated protection requirement (also with human handling of authentication secret) has been studied by academia in the case of password authenticated key exchange, see the research motivation stated in reference [27]: the basic idea is to store no long term secret on the machines. The equivalency of differentiated protection with an on-line HSM arrangement is out of scope.

The concrete usage scenario is server to server secure channels established for an indeterminate duration. The threat model is a higher risk of server attack during normal operations than during a server reboot (e.g. prior to enabling the whole set of server applications). Then, the entity authentication private key is made available to the server by human intervention only during the server reboot phase when the risk exposure is reduced (or at other times when system state monitoring is deemed effective in mitigating risks). The difficulty addressed by our proposal is that server reboots at both ends may not be always coordinated.

In here, we qualify the digital signature private key used in the second round-trip of messages (the entity authentication private key) as an off-line private key and we introduce protocol provisions for mitigating the usability impact. In essence, a temporary digital signature key pair is set up whenever the entity authentication private key is used. The temporary public signature key is sent to the remote party in the modified authenticated D-H exchange and serves as an authentication basis (i.e. authenticating the local entity to the remote-relying party) whenever the remote party has to reboot and the local party happens to still hold the temporary private counterpart. The proposal is symmetrical for the temporary keys setup, but not for reboot. A two-way D-H exchange based on the temporary signature keys is neither required by the usage scenario nor advisable from a security perspective. Thus, as an authenticated entity, a local party sets up a temporary key pair to allow the remote-relying party to restart the D-H exchange without inducing a local requirement for the off-line signature private key. Converseley, as a local-relying party having authenticated the remote entity once with its long-term public key, the scheme offers an opportunity to restart the D-H exchange with little impact for the remote party (in spite of its duty to authenticate).

Here is the explanation for the insecurity of symmetrical reliance on the temporary signature key. An offer to the remote party to authenticate oneself with a temporary signature key could originate from a clone run by a successful hacker of the legitimate system, which is less probable with authentication based on the off-line entity authentication key. This attack would be impossible to detect through the regular protocol features. Its mitigation with periodic temporary key replacement would defeat the very purpose of temporary keys. Note that temporary key replacement is possible and useful whenever a local security breach is suspected.

Thus we propose an arrangement where the human direct control of a secret data element makes the overall security more effective (factoring the relative risks of data breach from storage inside or outside a computer system), and where the security related human involvement is coherent (or so we claim). While this proposal finds a justification in a specific use case for the authenticated D-H exchange, it nonetheless illustrates a gap reduction between academic and applied cryptography through a deliberate security scheme design pattern: attention paid to the mating point between automated security mechanisms and human intervention. This appears infrequent in the literature. It is present for the control of digital signatures in a corporate environment ([28], [29]) and encryption key management for laptop computer mass storage devices ([30], [31]). The human aspect suggests the need of a simplified mental model for the operators of secure systems who may not be interested in the full explanation. A contribution in this direction is made in section "8. The Secure System Operator Model".

6.2 Temporary Signature Key Pair Announcement

The authenticated D-H exchange requires a digital signature from both entities in the second round trip of messages. With the proposed protocol addition, when the digital signature operation occurs at either party, a new temporary signature key pair must be generated (reuse of an existing key or advance generation would only undermine a party security). The temporary signature key must be announced to the other party. This announcement (obviously limited to the public portion of the key pair, TPUBi or TPUBr) is integrity protected (in each direction of transmission) as tied to the new D-H shared secret just established. It is according to the spirit of reference [9] that the integrity protection is implemented with the MAC algorithm and not the digital signature: this reference tends to limit the digital signature semantic that could in theory be used as evidence to a third party, thus preserving deniability for the digital signatory.

The protocol charts below depict the proposed changes in the second round trip of messages, including a change of message types, the inclusion of temporary public key values in the message fields that are protected by the AEAD mechanism, and the scope expansion of the MAC integrity protection to include these public key values. Note that the profile field value may implicitly convey an indication that the temporary public key announcement feature is used.

     "INIT i"|SPIi|KEi|profile --->
<--- "INIT r"|SPIi|SPIr|KEr
     [= "PKE"|SPIr| [# "AUTH ANN i"|CERTi|sign("INIT i"|profile|KEi|SPIr)|TPUBi|MAC(SK_pi,PUBi|TPUBi) #] =]SK_ei --->
<--- [= "PKE"|SPIi| [# "AUTH ANN r"|CERTr|sign("INIT r"|profile|KEr|SPIi)|TPUBr|MAC(SK_pr,PUBr|TPUBr) #] =]SK_er

In support of the temporary signature key announcement, we selected a digital signature algorithm from the discrete logarithm family for its efficiency in signature key pair generation.

The digital signature operation requires momentary access to an entity's long-term private signature key, independently at each of the two parties. The long-term security requirement may well justify off-line storage for an entity private key, implying the large latency of a human intervention for the momentary private access and for which some advance scheduling is desirable. With the protocol charts showing the entity long-term private signature key usage at the responder side, the coordination of human intervention may become cumbersome.

The temporary private signature key storage may be on-line but limited to the computer main memory where it would be normally lost by a power down cycle (or at least harder to recover than with more permanent forms of storage). The storage strategy differential between the long term and temporary private keys at the responder side of the D-H exchange is the primary motivation for the present protocol feature addition.

Implementation note: the MAC algorithm input data encoding is the concatenation of two ASN.1 BER encoded values (i.e. not an ASN.1 structured value) with the TPUB values being ASN.1 BER encoded integers.

6.3 D-H Exchange with Recourse to Temporary Key Pair

Once local and remote temporary key pairs are established, the D-H exchange initiator in a new protocol instance may allow the responder to use its temporary private signature key if the responder is able to and willing to. Either side of the preceding D-H exchange may initiate the new one with recourse to the responder temporary key pair. This is mainly intended for a party that loses the local secret state associated with the preceding exchange, but still remembers the remote party public data, notably the remote party temporary public key. The main operational security benefit comes from the responder ability to complete the exchange without access to its long term private entity signature key at a time decided by the initiator.

In the protocol chart below depicting the initiator invitation to complete the D-H exchange with the optional recourse to the responder temporary private key, the field SPI_Rr is the responder's SPIx value from the preceding D-H exchange (either SPIr or SPIi depending of which party is the new initiator), this SPIx value being associated with the responder's TPUBx (either TPUBr or TPUBi) in the preceding announcement. The message type INIT REC is needed to differentiate the message from a possible message of the type INIT which may be sent by the same initiator. The field profile must hold the same value as in the preceding exchange (it is required for a responder that no longer recognizes the SPI_Rr value).

     "INIT REC i"|SPI_Rr|SPIi|KEi|profile --->

Either party in an established security association may initiate the D-H exchange with the above message, but it must remember the data fields SPI_Rr and TPUBx with some trust in this local knowledge integrity (i.e. no suspected adversarial tampering with the local storage since the D-H exchange that established the security association, even if the security association secret data has been lost). Logically, the remembrance requirement extends to the field CERTx (either CERTr or CERTi) or its equivalent in a design derived from the present abstraction (see section "5.3 Naming Conventions for the Second Round Trip of Messages").

The receiver of the above initiator invitation message has the option between answering with the temporary signature key, or processing the request as an initial D-H exchange with temporary signature key pair announcement. These two options are covered in the following two subsections.

6.3.1 Response with D-H Signature Based on the Temporary Key Pair

For this response option to be possible, the responder needs to remember the security association state, including the temporary private signature key.

The protocol chart below shows the single responder message in an overall exchange that uses three messages instead of four. The responder selection of this option is indicated by the message type INIT REC r.

     "INIT REC i"|SPI_Rr|SPIi|KEi|profile --->
<--- "INIT REC r"|SPIi|SPIr|KEr|DHsign(KEr)
     [= "PKE"|SPIr| [# "AUTH REC i"|CERTi|sign("INIT REC i"|profile|KEi|SPIr)|TPUBi|MAC(SK_pi,PUBi|TPUBi) #] =]SK_ei ---> response needed...

The single responder message merges the features of the first round trip of messages with a cryptographic integrity signal, DHsign(KEr), which is expected to prove to the initiator-relying-party that the responder carries forward the security critical information from the SPI_Rr security association to the new SPIr security association. This proof is based on the previously established bind between the responder public key TPUBr and an implicit trust that the responder party behaves according to the secure protocol elements given here. This trusted behavior comprises mainly four elements:

The above term "integrity signal" refers to the Lein Harn Diffie-Hellman digital signature scheme [14] (details recalled below) which functions as a digital signature applied strictly and implicitly to the D-H shared secret contribution KEr towards the new SPIr security association. This is a property of the signature scheme directly validated by the initiator-relying-party, not a matter of additional responder trusted behavior. The security minded reader should note that a signature scheme like sign(SPIi|KEr) (using the temporary signature key) would have turned the above fourth trusted behavior element into a property intrinsically validated by the digital signature (a design derived from the present abstraction may pursue this route). Furthermore, it may be noted that the responder deniability is preserved by avoiding a signature scheme like sign(KEi|KEr).

The second round trip of messages is truncated with the present optional responder behavior: only the initiator has to send a complete message to the responder-relying-party. This portion of the D-H exchange is the same as in section "6.2 Temporary Signature Key Pair Announcement", except for message types. Hence the second initiator message preparation is the occasion for a new temporary signature key pair generation. Note that entity names are wholly protected against an active attacker in this D-H exchange variant. Lein Harn Signature Scheme Details

For a knowledgeable cryptographer mastering the ElGamal cryptosystems operating principles ([13]), the specialized signature scheme specified here is a very simple instance of a discrete logarithm signature.

Here is the short explanation with notation specific to this document section. With the Diffie-Hellman prime parameter p and generator g, a party contribution to the D-H shared secret is made from a private number k and its public conterpart r=gk mod p and the party signature pair is made of the private number x its public signature key counterpart y=gx mod p. The signature is a number s.

The signature equation is

     r.x=k+s mod (p-1)

The verification equation is mod p

The following table reconciles the above notation with message fields and variable labels used elsewhere in the present document.

Variable Notation in this Subsection Notation Elsewhere in this Document
D-H prime parameter p p
D-H generator parameter g g
Temporary private signature key x temporary private signature key
Temporary public signature key y TPUBr
D-H secret random integer k xr
D-H public contribution to shared secret r KEr
Digital signature value s DHsign(KEr)

Ignoring for now the mod (p-1) portion, the equivalency of signature and verification equations is a simple algebraic transformation

     (gx) mod p mod p

The operating principle is explained now with the aim of highlighting the potential attacks, with a novice reader in mind (the recourse to a very simple variant in the ElGamal derivatives family is somehow motivated by the ease of security review).

A first operating principle element comes from the simple linear algebra formula A.X+B.Y+C=0 where A, B, and C are known, and X and Y are unknowns: with two unknowns and a single equation, the solution is impossible. In the signature equation, A=r, B=-1, C=-s, X=x and Y=k. The mod (p-1) portion will be explained shortly. The unknowns x and k are privy to the signatory party which sees the signature s as the single unknown, hence solvable. The unknowns are hidden from adversaries and the legitimate relying party as well. Some public key cryptography magic is used to allow the relying party to validate a proof that the signatory party had a solution for the two unknowns, but not any solution: the validated solution must be shown to include the signatory private signature key x and the D-H secret random integer k. For the record, the ElGamal original signature uses A=r, B=s, C=-H(m), X=x and Y=k, where H(m) is the hash fingerprint of the signed message m, and the per-signature k is a random secret not contributing towards a D-H shared secret.

Here is the public key magic. The unknowns x and k are one-way transformed (i.e. a kind of encryption which may not be reversed) into public values y=gx mod p and r=gk mod p respectively. Note that the signature s is a value not one-way transformed; it works as a witness of the signature generation. The large exponents in the verification equation are actually cyclic: gv mod p = gv+(p-1) mod p for any non-negative integer v, thus the signature equation uses mod (p-1) arithmetic. This is mainly a matter of computational efficiency, except for the loss of information implied by the modulus operation on the signature value s.

By the numerical exercise of validating the signature verification equation using these one-way transformed unknowns (y and r), the relying party is able to become confident that the party having computed the signature value s indeed had access to both unknowns (x and k). First, the relying party trusts the global parameters p and g, and the signatory public key y. The received D-H shared secret contribution r is tied to the signature by virtue of being present in the signature equation both before and after its one-way transform (respectively k and r).

The security based on the lack of solution for the equation A.X+B.Y+C=0 with X and Y unknown is spoiled by any additional equation offered to an adversary.

This explanation is to be considered a tutorial and should not used as definitive guidance for detailed design and implementation activities. Notably, the selection of global D-H parameters p and g should follow recommendations from the literature where a justification may be found for the suggestion that (p-1)/2 be a prime number. Overall, the selection of an ElGamal derivative for the temporary signature application presented in the present document is justified more by the ease of temporary public key generation and the relatively simple implementation details. At the design stage, the security pitfall relevance may be weighted against the limited life span of the temporary signature key pair and the cryptographic community acceptance of other ElGamal derivatives. At the later implementation and deployment stages, the implications of the security pitfall should be addressed by proper risk mitigation strategies (in any case a security system has to address similar requirements).

A final note about the selection of the Lein Harn signature scheme over an MQV variant (e.g. HMQV turned into a unilateral authenticated scheme by a party private key inhibited with the non-secret value one). The interested reader may be able to find compelling security arguments for the MQV alternative. Notably, these implicitly authenticated schemes are not vulnerable to single ephemeral secret disclosure as indicated above for Lein Harn and DSA schemes. However, in the present project, a deciding factor (against MQV) has been the MQV amalgamation of remote entity authentication failure (an alarm signal from the authentication validation logic) with numerous other failure causes for the overall exchange protocol. The troubleshooting of communications failure is deemed easier if the digital signature verification step is explicit in the software implementation logic. Looking at this implementation characteristic from an attacker perspective mainly focused on bypassing cryptographic mechanisms, the likely unsuccessful troubleshooting of a failure event by a victim's organization may be an opportunity (e.g. hoping to induce the recourse to a less secure process for the same operational requirement).

6.3.2 Response with D-H Signature Based on the Long Term Key Pair

This response option turns mandatory when the responder loses its temporary private signature key. A new security association state is established as was done initially, including new temporary signature key pairs.

As indicated in the protocol chart below, the complete exchange with this option is the same as in section "6.2 Temporary Signature Key Pair Announcement", except that the initiator signature includes the context indicated by the message type "INIT REC".

     "INIT REC i"|SPI_Rr|SPIi|KEi|profile --->
<--- "INIT r"|SPIi|SPIr|KEr
     [= "PKE"|SPIr| [# "AUTH ANN i"|CERTi|sign("INIT REC i"|profile|KEi|SPIr)|TPUBi|MAC(SK_pi,PUBi|TPUBi) #] =]SK_ei --->
<--- [= "PKE"|SPIi| [# "AUTH ANN r"|CERTr|sign("INIT r"|profile|KEr|SPIi)|TPUBr|MAC(SK_pr,PUBr|TPUBr) #] =]SK_er

7. Discussion: Derived Design Challenges

The security protocols and cryptographic algorithms explained in the previous sections have intrinsic limitations for which the academic contributions have little to offer. The general observation supporting the intrinsic qualification here is that cryptography merely shifts data controls to key holders instead of actually controlling the data. In the spirit of filling a gap between acedemic contributions and applied cryptography, the present section explicitly re-states the intrinsic limitations of the security technology fundamentals.

When procuring information security technology, a recourse to formal certification requirement is common practice, notably in the public administration and large organizations. It may be noted that such certification programs have a tendency to define the so called target of evaluation in ways that avoids the design challenges brought by the intrinsic limitations. For instance, a certified RSA digital signature implementation would be certified with little attention paid to practical means for controlling the private signature key (e.g. certifying that the private key is encrypted when not in use provides no assurance about the encrypted private key controls). By contrast, the present document is agnostic about a target of evaluation and suggests no delineation in a given design between the auditable features and the intrinsic limitations.

Broadly speaking, there are two design challenge areas derived from the authenticated D-H exchange mission, namely local secret protection and authentication in both directions. The authentication challenge occurs independently with the two messages in the D-H exchange second round trip. At the sender side is the digital signatory role in which local procedures allow the receiver party to trust the local entity, while at the message receiver side is the relying party role in which some local trust basis enables to trust the sender entity.

In addition, some security services may be perceived as a natural complement to the D-H exchange while being out of scope. Prevention of denial-of-service attacks is an obvious instance. More subtly, the privacy protection also falls out of scope: while the data communications confidentiality between authenticated entities is in scope, privacy protection requires authorization management such that application data is shared only with entities agreeable to some application-specific privacy rules.

7.1 Authentication Trustworthiness

Each direction of entity authentication has to rely on conventions about the semantic of public key cryptography digital signatures: the core mathematical concepts are a mental exercise loosely related to the operational abstraction that is entity authentication for the relying party (the required conventions links the two). In this respect, each direction of entity authentication is independent. These signature semantic conventions extend to the security certifiates included in the above abstract description of messages in the second round trip (see section "5.3 Naming Conventions for the Second Round Trip of Messages" for the security certificate abstraction).

The required signature semantic conventions may vary from very ad-hoc or rudimentary provisions to a full-fledged PKI (public key infrastructure) with supporting doumentation such as certificate practice statements. The reference [22] contains an investigation of minimal signature semantic conventions, suggesting that a bare digital signature algorithm (without security certificates) may be used as the single cryptographic basis for the entity authentication within the D-H exchange. This arrangement may be reasonable if the target application comprises a limited number of allowed remote entities (e.g. an on-line service offered by a single server entity), or if an application service provider self-provivions the client entity enrollment function maintaining a local database of client entity signature keys.

Implementation note: the proof of concept profile uses the Scirpo digital signature convention from reference [22] with the signatory public key embedded in the ASN.1 digital signature encoding, and an empty security certificate field (i.e. ASN.1 NULL value). Any signature public key is implicitly trusted and no authorization management logic is implemented. Nonetheless, the virtual function mechanism (from the C++ object oriented programming language concepts) is present in the source code at the two logic steps where remote entity authentication and authorization granting should be implemented. This suggests that adhoc approaches for entity authentication might be based on an entity name equated to its public key and no certificate field in the protocol. This also illustrates that derived design challenges may not be built-in the abstract specification implementation.

For the relying party role, a more or less formal requirement exists for a trust basis. With the introduction of security certificates, one or more certification authority public signature key turn into a trust anchor which is the main formal component in the trust basis. More generally, any scheme for the relying party role may require some system configuration for the trust basis, thus some local data integrity protection is implied in the overall arrangement (e.g. a trusted database of remote entity public signature key needs some update privilege management). Actually, the integrity protection concern applies to the relying party system as a whole. The trust anchor cryptographic protection may be seen as a single point of failure, but this view is somehow arbitrary when a single relying party is considered. This discussion of the relying party system integrity is an illustration that a target of evaluation boundary can never cover all required elements of a given application security.

7.2 Secrecy Protections

The generic challenge of secret data protection for cryptographic processing within modern digital computing devices appears constantly expanding with increasingly complex digital processors and sophisticated attack exploits, e.g. in the side channel category.

The generic secrecy protection applies to key material according to the cryptographic mechanisms used in the deployed D-H exchange profile, and also to working variables used in computations, and further to the memory swap media in the case of a digital computing environment having virtual memory support.

The secrecy protection requirements for the local entity signature private key deserves special attention. If a secret data leak threatens any element of the D-H exchange other than the digital signature allowed by this entity private key, the data leak is readily stopped and recovered with the termination of the secure data transmission followed by a brand new D-H exchange instance. Conversely, the private signature key is a single point of failure for secret data breaches. But there is more to this private key secrecy criticalness: the very private key usage must be controlled such that each digital signature computation occurs in legitimate circumstances that match the entity intent. E.g. consuming some on-line service from a given supplier instead of any supplier requires the prevention of diversion attacks. In this attack angle, the private signature key remains secret and under the apparent control of the legitimate entity, but digital signatures are surreptitiously applied in some unintended application contexts. Typically, the security incident root cause will be identified as inadequate process surrounding a sound arrangement for digital signatures. Indeed, this is a consequence of the mere shift of controls that can be achieved with the cryptographic techniques. In the present author experience, the HSM technology fails to address the signature diversion attack threat as an issue outside of the certification scope.

This is part of the justification for the Bladderwort proposal: the private signature key usage requires only momentary presence of the private key, thus limiting the diversion attack exposure. Ideally, the (non-cryptographic) controls for the initiation of a digital signature operation should ensure that a sign of well-informed volition by the entity is always required before the signature operation by the computing device.

8. The Secure System Operator Model

To the extent the long-term private signature key is actually kept off-line, some human intervention is expected from secure system operators, if and when the local digital signature operation needs this private key. In these operational contexts, we recommend a good match between the operator understanding of what is going on and the IT protections provided by the protocol elements: the simple instruction to insert some removable digital device in a USB port at some step in a written procedure is not enough for appreciating the impact of not removing the device at some later step.

In this document section, we record a logical process intended to facilitate the development of a specific mental model for operator training program and material. The possible variations in the mental model are due to assumptions about prior knowledge of public key cryptography techniques, and/or the intended operator contributions towards the derived design challenges explained in the previous section.

The overall procedure is aimed at an agreement (in the form of common configuration data derived by some mathematical formulations) between the local party (the computer being interacted with) and a remote party. The remote party may, under circumstances explained below, participate in the agreement process without operator assistance (automated party). The operator role is to make sure the agreement takes place in the appropriate circumstances and completes successfully. This statement refers to organizational arrangements more than proper software logic integrity, the latter being an act of faith from the operator position. Note that the operator involvement does not increase the assurance about the remote party identity unless specific arrangements are made (e.g. out-of-band agreement confirmation). In each variant of the operator assignment for the agreement process, there are three phases:

First Contact
The first contact phase establishes the context in which the long term private signature key has to be present in the computing environment (either as the private key data value present in the computer memory or as a digital signature capability implemented in an HSM type of device). It is implemented by the first round trip of nessages. The first contact phase determines which party is the initiator; an ambiguity in this determination would cause a key derivation failure.
Connection Authentication
The connection authentication phase is when the digital signature operation (enabled by the long-term private key) occurs. It is implemented by the second round trip of nessages.
Final Acknowldgment
The final acknowledgment allows the operator to remove the long term private key from the computing environment. The final acknowledgment is not specified in the other document subsections, being implemented as a transmission instance of the bulk secure communications sub-protocol.

When the operator assignment requirement is present, it includes the above three phases. Otherwise, the protocol operations may be entirely supported by an automated party. The automated protocol operation occurs notably when the temporary signature key pair achieves the intended security association recovery exchange (per section "6.3.1 Response with D-H Signature Based on the Temporary Key Pair"). The automated mode of protocol operations is also possible if the long term private signature key remains on-line.

The operator assignment comprises elementary interactions of three kinds: 1) the software notification that a protocol step has been completed (a notification may turn into an alert if the operator is not attending the system and a follow-up action is expected), 2) the operator trigger of the next step in the logical sequence of protocol steps, and 3) the private key insertion into, or removal from, the local computer environment. The operator involvement usefulness depends on an understanding of the security significance of each elementary interaction step.

A bird's eye view of the agreement processes may now be stated, closely linked to the protocol specifications. The individual operator perspective is presented later based on bird's eye view but augmented with the possible operator incremental contributions towards security assurance.

The initial agreement process between the local and remote parties requires some coordination when both parties are committed to the operator assisted mode, because operator attendance has to occur at the same time (a telephone conversation may facilitate the procedure completion).

Initiator Party Responder Party
* * * First Contact * * *
Trigger First contact
Notification First contact (alert operator if not attending)
Trigger First contact acknowledgment
Notification First contact acknowledgment
* * * Connection Authentication * * *
Insert Long term private signature key Insert Long term private signature key
Trigger Connection authentication Trigger Connection authentication
--------------\ /--------------
<-------------/ \------------->
Notification Connection authentication (or alert authentication failure) Notification Connection authentication (or alert authentication failure)
* * * Final Acknowledgment * * *
Trigger Final acknowledgment Trigger Final acknowledgment
--------------\ /--------------
<-------------/ \------------->
Notification Final acknowledgment Notification Final acknowledgment
Remove Long term private signature key Remove Long term private signature key

Once the initial agreement is done, either party may recover agreed secrets with the procedure as described in section "6.3 D-H Exchange with Recourse to Temporary Key Pair".

Initiator Party Automated Response
* * * First Contact * * *
Trigger First contact
Automatic reply
Notification First contact acknowledgment
(proceeding with automated recovery)
* * * Connection Authentication * * *
Insert Long term private signature key
Trigger Connection authentication
Alert in case of authentication failure,
* * * Final Acknowledgment * * *
else automatic final acknowledgment
Notification Final acknowledgment
Remove Long term private signature key

If the automated agreed secrets recovery is not possible, then the above automatic reply is replaced by a first contact notification (or alert) and trigger, and the process turns identical to the initial agreement.

Operator contributions towards overall security: a) coherency between the agreement process instance and operational context (i.e. that the agreement instance occurs when appropriate and completes before starting activities depending on it), b) secrecy support for the long-term private signature key, and c) assistance towards remote party identity assurance. Note that the central issue of remote party identity assurance is closely connected to the operating principles of digital signatures (the operator role may be central in providing the local entity with the signature relying party assurance). Also note that this remote identity assurance is only a prerequisite to the remote entity authorization question.

The operator contribution towards remote identity assurance may take diverse forms, including prior validity determination for the remote entity public signature key, in which case the above final acknowledgment trigger may be automated. The PKI model suggests such prior validity determination through delegation to a certification authority (PKI refinements seem to extend to authorization management delegation). The PKI model is basically antagonistic to the notion that operator contribution towards security may be an efficient use of resources.

A supplemental protection may be embedded in detailed rules for the instantiation of the present model. In the above chart for the initial agreement process, the connection authentication transmissions occur independently in each direction. In practice, if one direction is subordinate to the other one, the second sending party benefits from identity concealment against active eavesdropers.

9. References

[1] W. Diffie and M. Hellman, "New directions in cryptography", IEEE Transactions on Information Theory 22 (6) (1976): pp 644–654, available at

[2] Whitfield Diffie, "The First Ten Years of Public-Key Cryptography", invited paper, Proceedings of the IEEE, Vol. 76, No. 5, MAY 1988, available at

[3] Whitfield Diffie, Paul C. Van Oorschot, and Michael J. Wiener "Authentication and Authenticated Key Exchanges", in Designs, Codes and Cryptography, 2, 107-125 (1992) (received by editor Nov. 22, 1991 and revised Mar. 6, 1992), available at

[4] Steven M. Bellovin and Michael Merritt, "Cryptographic protocol for secure communications", United States Patent number 5,241,599, August 31, 1993, filed October 2, 1991.

[5] ITU-T Recommendation X.273 (1994) | ISO/IEC 11577:1995, "Information technology - Open Systems Interconnection - Network layer security protocol", available at

[6] ITU-T Recommendation X.274 (1994) | ISO/IEC 10736:1995, "Information technology - Telecommunications and information exchange between systems - Transport layer security protocol", available at

[7] ISO/IEC 9798-3:1993, "Entity authentication mechanisms -- Part 3: Entity authentication using asymmetric techniques".

[8] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", IETF RFC 7296, Internet Engineering Task Force (IETF), October 2014, available at

[9] Hugo Krawczyk, "SIGMA: the 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", 2003, proceedings of Crypto'03 (LNCS Series, Vol. 2729), extended version available at

[10] R. Moskowitz (editor), T. Heer, P. Jokela, and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", IETF RFC 7401, Internet Engineering Task Force (IETF), April 2015, available at

[11] David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thom'e, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-B'eguelin, and Paul Zimmermann, "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" in proceedings of 22nd ACM Conference on Computer and Communications Security, October, 2015, DOI:, also visit

[12] S. Kent, "IP Encapsulating Security Payload (ESP)", IETF RFC 4303, Network Working Group, December 2005, available at

[13] Taher El Gamal, "A public key cryptosystem and a signature scheme based on discrete logarithms", IEEE Trans. Information Theory 31(4): 469-472 (1985), available at

[14] L. Harn, "Digital signature for Diffie-Hellman public keys without using a one-way function", Electron. Lett., vol. 33 (1997), no 2, pp 125-126, available at

[15] L. Harn and H.-Y. Lin, "Authenticated key agreement without using one-way hash functions", Electron. Lett., vol. 37 (2001), no. 10, pp 629-630, available at

[16] L. Harn, W.-J. Hsin, and M. Manish, "Authenticated Diffie-Hellman key agreement protocol using single cryptographic assumption", IEE Proceedings Communications, Vol. 152, No. 4, pp. 404-410, Aug 2005, available at

[17] Laurie Law, Alfred Menezes, Minghua Qu, Jerry Solinas, and Scott Vanstone, "An Efficient Protocol for Authenticated Key Agreement", Technical report CORR 98-05, Dept. of C&O, University of Waterloo, August 1998, available at

[18] Hugo Krawczyk, "HMQV: A High-Performance Secure Diffie-Hellman Protocol", Cryptology ePrint Archive: Report 2005/176, July 2005, available at

[19] Andrew C. Yao and Yunlei Zhao, "A New Family of Implicitly Authenticated Diffie-Hellman Protocols", Cryptology ePrint Archive: Report 2011/035, October 2012, available at

[20] D. Whiting, R. Housley, and N. Ferguson, "Counter with CBC-MAC (CCM)", IETF RFC 3610, Network Working Group, September 2003, available at

[21] R. Rivest, A. Shamir, and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM 21 (2) (February 1978): pp 120–126, available at

[22] Thierry Moreau, "Scirpo, a Basic Rabin-Williams Digital Signature Specification", CONNOTECH Experts-conseils inc., Document Number C005521, 2013/12/18, available at

[23] J. Jonsson and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", IETF RFC 3447, Network Working Group, February 2003, available at

[24] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", IETF RFC 2104, Network Working Group, February 1997, available at

[25] M. Nystrom, "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", IETF RFC 4231, Network Working Group, December 2005, available at

[26] Wikipedia, "Web of trust",

[27] Alexandra Boldyreva, Shan Chen, Pierre-Alain Dupont, and David Pointcheval, "Human Computing for Handling Strong Corruptions in Authenticated Key Exchange", Cryptology ePrint Archive, Report 2017/559, 2017, available at

[28] Christopher J. Holloway, "Controlling Digital Signatures Services Using A Smartcard", Computers & Security, Vol. 14(1995) pp.681-690.

[29] George M. Dolan, Christopher J. Holloway, and Stephen M. Matyas, Jr., "Public key data communications system under control of a portable security device", United States Patent number 5,604,801, February 18, 1997, filed February 3, 1995, assigned to International Business Machines Corporation.

[30] Mark D. Corner and Brian D. Noble, "Zero-Interaction Authentication", International Conference on Mobile Computing and Networking, Atlanta, September 23-28, 2002.

[31] Brian D. Noble and Mark D. Corner, "Method and system to maintain portable computer data secure and authentication token for use therein", United States Patent number 7,302,571, November 27, 2007, filed April 9, 2002.

[32] Phong Q. Nguyen, Igor Shparlinski, "The insecurity of the elliptic curve digital signature algorithm with partially known nonces", Designs, Codes and Cryptography 30 (2003), 201­217.

A. Summary of Security Critical Number Generation Requirements

This document subsection is a mere tabulation of cryptographically significant number generation requirements specified elsewhere, as a convenience for security reviews of implementation work derived from the present document.

A.1 Cryptographically Strong Secret Random Numbers

Locally unique security association references SPIi and SPIr
The reference numbers SPIi and SPIr must be locally unique. This uniqueness is required for the local administration of protocol state data (including dynamic security association data). The uniqueness is also highly desirable for the authentication processing in the second round trip of messages. In the latter purpose, the uniqueness scope is preferably larger than the local system, hence a large enough random value is preferred. The randomness desirability for these values is also justified by the key derivation procedure where it contributes to the entropy of symmetric key material.
Diffie-Hellman private keys xi and xr
This randomness requirement is intact from the Diffie-Hellman cryptosystem. When the Lein Harn specialized digital signature scheme is used, a further requirement is strong statistical and computational independence between successive values.
Random salt generation for digital signatures (if a probabilistic signature scheme is used)
This randomness requirement is intact from any probabilistic signature scheme implicit in the security profile.
Generation of temporary signature keys TPUBi and TPUBr
This randomness requirement is intact from the Lein Harn specialized digital signature scheme used in our proposed protocol feature addition.

A.2 Nonces Characterized by Cryptographically Critical Uniqueness

Nonce associated with SK_ci and SK_cr
This uniqueness requirement is present the AEAD modes of operation based on counter mode encryption. In the present proposal, the purpose of these nonces is overloaded with replay attack prevention in the bulk secure communications.
Nonce associated with SK_ei and SK_er
This uniqueness requirement is present the AEAD modes of operation based on counter mode encryption. If the present proposal is extended with additional protected data communications for security association management (as in the IPSEC IKE protocol or e.g. by the definition of security association termination packets), the purpose of these nonces would be overloaded with replay attack prevention in the security association management secure communications.