Ockam logo
Product
OverviewCloud SDKEdge SDKEmbedded SDKRegistryRouter
Contact us

Key Agreement - XX

This proposal specifies a key agreement protocol for two entities to agree on a shared secret without ever transporting that secret over the network. This protocol design is based on the XX design pattern that is defined in the Noise Protocol Framework.

As part of the protocol both entities share their long term static public keys and prove to each other that they possess the corresponding private keys. This type of key agreement is most useful in scenarios where the two entities have never encountered each other before and neither has pre-existing knowledge of the other entities static public key.

Description

The Key Agreement protocol begins with two entities exchanging handshake messages.

During this handshake phase the entities exchange Diffie-Hellman public keys and perform a sequence of Diffie-Hellman operations, hashing the results of those operations into a shared secret.

After the handshake phase each party can use this shared secret to send encrypted data messages.

The two participating entities are called Initiator and Responder:

  • Initiator: The entity that initiates the key agreement protocol by sending the first message (Message A).\
  • Responder: The entity that responds to the initiator's message with the second message (Message B).

Key Agreement Protocol Diagram

1Initiator | Responder
2------------------------------------------|----------------------------------------
3
4
5Message A (Send)
6-> e
7
81. Pick a static 25519 keypair for
9this handshake and set it to s
10
112. Generate an ephemeral 25519
12keypair for this handshake and set
13it to e
14
153. Set k to empty, Set n to 0
16
174. Set h and ck to
18'Noise_XX_25519_AESGCM_SHA256'
19
205. h = SHA256(h || prologue),
21prologue is empty
22
236. h = SHA256(h || e.PublicKey),
24Write e.PublicKey to outgoing message
25buffer, BigEndian
26
277. h = SHA256(h || payload),
28payload is empty
29
30
31------------------------------------------|----------------------------------------
32
33
34 Message A (Receive)
35 -> e
36
37 1. Pick a static 25519 keypair for
38 this handshake and set it to s
39
40 2. Generate an ephemeral 25519
41 keypair for this handshake and set
42 it to e
43
44 3. Set k to empty, Set n to 0
45
46 4. Set h and ck to
47 'Noise_XX_25519_AESGCM_SHA256'
48
49 5. h = SHA256(h || prologue),
50 prologue is empty
51
52 6. Read 32 bytes from the incoming
53 message buffer, parse it as a public
54 key, set it to re
55 h = SHA256(h || re)
56
57 7. read remaining message as payload
58 h = SHA256(h || payload),
59 payload should be empty
60
61
62------------------------------------------|----------------------------------------
63
64
65 Message B (Send)
66 <- e, ee, s, es
67
68 1. h = SHA256(h || e.PublicKey),
69 Write e.PublicKey to outgoing message
70 buffer, BigEndian
71
72 2. ck, k = HKDF(ck, DH(e, re), 2)
73 n = 0
74
75 3. c = ENCRYPT(k, n++, h, s.PublicKey)
76 h = SHA256(h || c),
77 Write c to outgoing message
78 buffer, BigEndian
79
80 4. ck, k = HKDF(ck, DH(s, re), 2)
81 n = 0
82
83 5. c = ENCRYPT(k, n++, h, payload)
84 h = SHA256(h || c),
85 payload is empty
86
87------------------------------------------|----------------------------------------
88
89
90Message B (Receive)
91<- e, ee, s, es
92
931. Read 32 bytes from the incoming
94message buffer, parse it as a public
95key, set it to re
96h = SHA256(h || re)
97
982. ck, k = HKDF(ck, DH(e, re), 2)
99n = 0
100
1013. Read 48 bytes the incoming
102message buffer as c
103p = DECRYPT(k, n++, h, c)
104h = SHA256(h || c),
105parse p as a public key,
106set it to rs
107
1084. ck, k = HKDF(ck, DH(e, rs), 2)
109n = 0
110
1115. Read remaining bytes of incoming
112message buffer as c
113p = DECRYPT(k, n++, h, c)
114h = SHA256(h || c),
115parse p as a payload,
116payload should be empty
117
118
119------------------------------------------|----------------------------------------
120
121
122Message C (Send)
123-> s, se
124
1251. c = ENCRYPT(k, n++, h, s.PublicKey)
126h = SHA256(h || c),
127Write c to outgoing message
128buffer, BigEndian
129
1302. ck, k = HKDF(ck, DH(s, re), 2)
131n = 0
132
1333. c = ENCRYPT(k, n++, h, payload)
134h = SHA256(h || c),
135payload is empty
136
137
138------------------------------------------|----------------------------------------
139
140
141 Message C (Receive)
142 -> s, se
143
144 1. Read 48 bytes the incoming
145 message buffer as c
146 p = DECRYPT(k, n++, h, c)
147 h = SHA256(h || c),
148 parse p as a public key,
149 set it to rs
150
151 2.ck, k = HKDF(ck, DH(e, rs), 2)
152 n = 0
153
154 3. Read remaining bytes of incoming
155 message buffer as c
156 p = DECRYPT(k, n++, h, c)
157 h = SHA256(h || c),
158 parse p as a payload,
159 payload should be empty
160
161
162------------------------------------------|----------------------------------------
163
164
165 1. k1, k2 = HKDF(ck, zerolen, 2)
166 n1 = 0, n2 = 0
167 Use (k1, n1) to encrypt outgoing
168 Use (k2, n2) to decrypt incoming
169
1701. k1, k2 = HKDF(ck, zerolen, 2)
171n1 = 0, n2 = 0
172Use (k1, n1) to decrypt incoming
173Use (k2, n2) to encrypt outgoing
174

Message A

Message A, sent by the initiator, does not benefit from sender authentication and does not provide message integrity. It could have been sent by any party, including an active attacker. Message contents do not benefit from message secrecy even against a purely passive attacker and any forward secrecy is out of the question.

Message B

Message B, sent by the responder, benefits from sender authentication and is resistant to Key Compromise Impersonation. Assuming the corresponding private keys are secure, this authentication cannot be forged. However, if the responder carries out a separate session with a separate, compromised initiator, this other session can be used to forge the authentication of this message with this session's initiator. Message contents benefit from some message secrecy and some forward secrecy, but not sufficiently to resist any active attacker.

Message C

Message C, sent by the initiator, benefits from sender and receiver authentication and is resistant to Key Compromise Impersonation. Assuming the corresponding private keys are secure, this authentication cannot be forged. Message contents benefit from message secrecy and strong forward secrecy: if the ephemeral private keys are secure and the responder is not being actively impersonated by an active attacker, message contents cannot be decrypted.

Message D

Message D, sent by the responder, benefits from sender and receiver authentication and is resistant to Key Compromise Impersonation. Assuming the corresponding private keys are secure, this authentication cannot be forged. Message contents benefit from message secrecy and strong forward secrecy: if the ephemeral private keys are secure and the initiator is not being actively impersonated by an active attacker, message contents cannot be decrypted.

Message E

Message E, sent by the initiator, benefits from sender and receiver authentication and is resistant to Key Compromise Impersonation. Assuming the corresponding private keys are secure, this authentication cannot be forged. Message contents benefit from message secrecy and strong forward secrecy: if the ephemeral private keys are secure and the responder is not being actively impersonated by an active attacker, message contents cannot be decrypted.

Discussion

We’re discussing the Ockam key agreement protocol in the following Github issues: #32

References

  1. Perrin, T., The Noise Protocol Framework.
    https://github.com/noiseprotocol/noise_spec/blob/v34/output/noise.pdf
  2. Krawczyk, H., SIGMA: The ‘SIGn-and-MAc’ approach to authenticated Diffie-Hellman and its use in the IKE protocols.
    https://link.springer.com/content/pdf/10.1007/978-3-540-45146-4_24.pdf
  3. Marlinspike, M. and Perrin, T., The X3DH Key Agreement Protocol.
    https://signal.org/docs/specifications/x3dh/x3dh.pdf
  4. Kobeissi, N., Nicolas, G. and Bhargavan, K., Noise Explorer: Fully Automated Modeling and Verification for Arbitrary Noise Protocols.
    https://ia.cr/2018/766
  5. Girol, G., Formalizing and verifying the security protocols from the Noise framework.
    https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/information-security-group-dam/research/software/noise_suter-doerig.pdf
  6. IETF, The Transport Layer Security (TLS) Protocol Version 1.3
    https://tools.ietf.org/html/rfc8446
Previous

Secure Channels

Next

Wire Protocol

On this page
  • Description
  • Message A
  • Message B
  • Message C
  • Message D
  • Message E
  • Discussion
  • References
Edit this page
Star Ockam repo