format protocol steps
This commit is contained in:
parent
f58c8ff3a9
commit
a33a3dba72
84
PROTOCOL.md
84
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 <u>Stateless Time Scrambling Protocol</u> to take care of the request's invalidation over time.
|
||||
2. a <u>Stateless Cyclic Hash Algorithm</u> 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 <u>rescue protocol</u> 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** : <br>- $0$ : normal request<br>- $1$ : will switch to the new key<br>- $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 <br><ul><li>$[(h^n(K) \oplus h^{n'}(K')) \And 1] \ \mathbb{Z}\_{(2)} = t\_c \ \mathbb{Z}\_{(2)}$</li></ul> |
|
||||
| `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 :<br><ul><li>$[(h^N(K) \oplus h^{n'}(K')) \And 1] \ \mathbb{Z}\_{(2)} = t\_c \ \mathbb{Z}\_{(2)} $</li><li>$[(h^N(K) \oplus h^{n'}(K')) \And 11110000] \ \mathbb{Z}\_{(3)} = 2$</li></ul> |
|
||||
| `8` | $x\_2 = h^{n'}(K') \oplus h(t\_c)$ |
|
||||
|
||||
Send $x_1$ and $x_2$.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue