From a33a3dba7254540f296242a28c7b4422ffdb6c1f Mon Sep 17 00:00:00 2001 From: xdrm-brackets Date: Sun, 9 Sep 2018 19:47:50 +0200 Subject: [PATCH] format protocol steps --- PROTOCOL.md | 84 +++++++++++++++++++++++++++-------------------------- 1 file changed, 43 insertions(+), 41 deletions(-) diff --git a/PROTOCOL.md b/PROTOCOL.md index 41604b4..9e817bd 100644 --- a/PROTOCOL.md +++ b/PROTOCOL.md @@ -33,7 +33,7 @@ A better solution would be to generate a private key on each client and use it t **Technology requirements** 1. Mixing 2 hashes in a way that without one of them, the other is *cryptographically impossible* to guess (*i.e. [one-time pad](https://en.wikipedia.org/wiki/One-time_pad)*). -2. Having a time-dependent unique hash, that could be found only a few seconds after sending it (as for *[TOTP](https://tools.ietf.org/html/rfc6238)*). +2. Having a time-dependent unique feature, that could be found only a few seconds after sending it (as for *[TOTP](https://tools.ietf.org/html/rfc6238)*). 3. A cryptographic hash function that, from an input of any length, outputs a fixed-length digest in a way that is *impossible* to guess the input back from it. **Protocols to define** @@ -43,12 +43,12 @@ This document will define and bundle 2 distinct protocols to make up a token sys 1. a Stateless Time Scrambling Protocol to take care of the request's invalidation over time. 2. a Stateless Cyclic Hash Algorithm to use a private key as a one-time token generator in a way that no clue is given over published tokens (*i.e. one-way function*). 3. A key renewal mechanism in a way that no clue is given over neither the old nor the new key. -4. A rescue protocol to resynchronise the client with a new key in a way that no clue is given over the network and the client has to process a "proof of work". +4. A rescue protocol to resynchronise the client with a new key in a way that no clue is given over the network and the client has to process a "proof of work". ## General knowledge & Notations -##### Notation +##### Notations | Symbols | Description | |:-----:|:----------| @@ -69,7 +69,7 @@ The whole system share a common **context**, each client holds a **private keyse These variables are both on the server and clients. They are specific to the server so each client must match its values. These variables shape the system's **context** $(W, min, belt, max)$. -| Notation | Name | Description | +| Variable | Name | Description | |:--------:|:----:|:------------| | $W$ | time window | A number of seconds that is typically the maximum transmission time from end to end. It will be used by the *time-scrambling aspect*. The lower the number, the less time an attacker has to try to brute-force the tokens. | | $min$ | resynchonization range | A number that is used to resynchronize the client if there is a communication issue (*e.g. lost request, lost response, attack*). The higher the value, the higher the challenge for the client to recover the authentication, thus the harder for an attacker to guess it. | @@ -78,73 +78,75 @@ These variables are both on the server and clients. They are specific to the ser #### 2. Client keyset -Every client holds a **keyset** $(K, n, s)$. It represents its private key and is used to generate the tokens. The secure hash function is extended as a **one-way function** to generate all the tokens from the keyset. +Every client holds a **keyset** $(K, n, s)$. It represents its private key and is used to generate the tokens. The secure hash function is extended to a **one-way function** to generate all the tokens from the keyset. Note that the client may hold a secondary keyset between the generation of a new keyset and the server's validation of it. -| Notation | Name | Description | +| Variable | Name | Description | |:--------:|:----:|:------------| | $K$ | private key | A secret binary data that must be large and *random* enough not to be brute forced. | -| $n$ | key nonce | A number that is decremented before each request. Before $n$ reaches 0, a new keyset must be generated. | +| $n$ | key nonce | A number that is decremented at each token generation. Before $n$ reaches 0, a new keyset must be generated. | | $s$ | key state | A number that reflects the state of the keyset. It is used to know what to do on the **next request** :
- $0$ : normal request
- $1$ : will switch to the new key
- $2$ : rescue proof of work sent, waiting for the server's acknowledgement | #### 3. Server variables -| Notation | Name | Description | +| Variable | Name | Description | |:--------:|:----:|:------------| | $T$ | last valid token | The server stores the last valid token from the client to check the next one. | ## Protocol -#### 1. Client authentication +## 1. Client request generation -In each request, the client will send a pair of tokens $(x_1, x_2)$ : +In each request, the client will send a pair of time-scrambled hashes $(x_1, x_2)$ : - $x1$ will hold the current one-time token -- $x2$ will hold data to check the next one-time token to be used +- $x2$ will hold the necessary data to check the next token -The client's current keyset has 3 states : -- `normal` - default authentication algorithm. -- `switch` - default algorithm variation to switch to a new keyset when the current one is consumed. -- `rescue` - process the proof of work after receiving the server's challenge when there is a desynchronisation and generate a new keyset. +The client implements 3 protocols according to the **keyset state** : +- 0 : `NORMAL` - default authentication protocol. +- 1 : `SWITCH` - default protocol variation to switch to a new keyset when the current one is consumed (*i.e. when $n$ if less or equal to $min+sec$*). +- 2 : `RESCUE` - process the proof of work after receiving the server's challenge when there is a desynchronisation and generate a new keyset. -When the client switches to a new key, it has to the new keyset along the current one, in order not to lose its authentication if the network fails. +When the client switches to a new key, it has to store the new keyset along the current one, in order not to lose its authentication if the network fails. - $(K,n,s)$ - the current keyset - $(K',n',s')$ - the new keyset -##### a. `normal` protocol +#### A. `NORMAL` protocol -1. Decrement $i$ -2. $t\_c = \mid \frac{t\_{now}}{W}\mid$ -3. $x\_1 = h^{n}(K) \oplus h(t\_c)$ -4. $x\_2 = x\_1 \oplus (t\_c \ \mathbb{Z}\_{(2)})$ + +| Step | Calculation | +|:--------:|:------| +| `1` | Decrement $i$ | +| `2` | $t\_c = \mid \frac{t\_{now}}{W}\mid$ | +| `3` | $x\_1 = h^{n}(K) \oplus h(t\_c)$ | +| `4` | $x\_2 = x\_1 \oplus (t\_c \ \mathbb{Z}\_{(2)})$ | Send $x_1$ and $x_2$. -If $i \leq min+sec$, go to `switch` protocol. +#### B. `SWITCH` protocol -##### b. `switch` protocol - -1. $t\_c = \mid \frac{t\_{now}}{W}\mid$ -2. $x\_1 = h^{n}(K) \oplus h(t\_c)$ -3. Generate $(K',n',s')$ in a way where the following condition is met : - - $[(h^n(K) \oplus h^{n'}(K')) \And 1] \ \mathbb{Z}\_{(2)} = t\_c \ \mathbb{Z}\_{(2)} $ -4. $x\_2 = h^{n'}(K') \oplus h(t\_c)$ +| Step | Calculation | +|:--------:|:------| +| `1` | $t\_c = \mid \frac{t\_{now}}{W}\mid$ | +| `2` | $x\_1 = h^{n}(K) \oplus h(t\_c)$ | +| `3` | Generate $(K',n',s')$ until
| +| `4` | $x\_2 = h^{n'}(K') \oplus h(t\_c)$ | Send $x_1$ and $x_2$. -#### c. `rescue` protocol +#### C. `RESCUE` protocol -The rescue protocol is processed when receiving $y_1$ and $y_2$ from the server instead of the standard response. +This protocol is processed when the server sends the 2 hashes $(y_1, y_2)$ to the client (instead of the standard response). It means that the server has received a wrong hash, so it sends the rescue challenge to the client. -1. $m_s = y_1 \oplus y_2$ -2. $t\_c = \mid \frac{t\_{now}}{W} \mid $, $m\_c = t\_c \mathbb{Z}\_{(2)}$ -3. $t'\_s = t\_c - \parallel m\_c - m\_s\parallel$ -4. $T = x\_1 \oplus h(t'\_s)$ -5. Find $N \in [min ; n-min[,\ h^{N}(K) = T$. -6. $x\_1 = h^N(K) \oplus h(t\_c)$ -7. Generate $(K',n',s')$ in a way where the following conditions are met : - - $[(h^N(K) \oplus h^{n'}(K')) \And 1] \ \mathbb{Z}\_{(2)} = t\_c \ \mathbb{Z}\_{(2)} $ - - $[(h^N(K) \oplus h^{n'}(K')) \And 11110000] \ \mathbb{Z}\_{(3)} = 2$ -8. $x\_2 = h^{n'}(K') \oplus h(t\_c)$ +| Step | Calculation | +|:--------:|:------| +| `1` | $m_s = y_1 \oplus y_2$ +| `2` | $t\_c = \mid \frac{t\_{now}}{W} \mid $, $m\_c = t\_c \mathbb{Z}\_{(2)}$ +| `3` | $t'\_s = t\_c - \parallel m\_c - m\_s\parallel$ +| `4` | $T = x\_1 \oplus h(t'\_s)$ +| `5` | Find $N \in [min ; n-min[,\ h^{N}(K) = T$. +| `6` | $x\_1 = h^N(K) \oplus h(t\_c)$ +| `7` | Generate $(K',n',s')$ until :
| +| `8` | $x\_2 = h^{n'}(K') \oplus h(t\_c)$ | Send $x_1$ and $x_2$.