logauth
/
schastsp
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

format protocol steps

This commit is contained in:
Adrien Marquès 2018-09-09 19:47:50 +02:00
parent f58c8ff3a9
commit a33a3dba72
1 changed files with 43 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

84
PROTOCOL.md
View File

@ -33,7 +33,7 @@ A better solution would be to generate a private key on each client and use it t
**Technology requirements** **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)*). 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. 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** **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. 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*). 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. 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 ## General knowledge & Notations
##### Notation ##### Notations
| Symbols | Description | | 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)$. 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. | | $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. | | $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 #### 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. | | $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 | | $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 #### 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. | | $T$ | last valid token | The server stores the last valid token from the client to check the next one. |
## Protocol ## 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 - $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 : The client implements 3 protocols according to the **keyset state** :
- `normal` - default authentication algorithm. - 0 : `NORMAL` - default authentication protocol.
- `switch` - default algorithm variation to switch to a new keyset when the current one is consumed. - 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$*).
- `rescue` - process the proof of work after receiving the server's challenge when there is a desynchronisation and generate a new keyset. - 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 current keyset
- $(K',n',s')$ - the new 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$ | Step | Calculation |
3. $x\_1 = h^{n}(K) \oplus h(t\_c)$ |:--------:|:------|
4. $x\_2 = x\_1 \oplus (t\_c \ \mathbb{Z}\_{(2)})$ | `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$. Send $x_1$ and $x_2$.
If $i \leq min+sec$, go to `switch` protocol. #### B. `SWITCH` protocol
##### b. `switch` protocol | Step | Calculation |
|:--------:|:------|
1. $t\_c = \mid \frac{t\_{now}}{W}\mid$ | `1` | $t\_c = \mid \frac{t\_{now}}{W}\mid$ |
2. $x\_1 = h^{n}(K) \oplus h(t\_c)$ | `2` | $x\_1 = h^{n}(K) \oplus h(t\_c)$ |
3. Generate $(K',n',s')$ in a way where the following condition is met : | `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> |
- $[(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)$ |
4. $x\_2 = h^{n'}(K') \oplus h(t\_c)$
Send $x_1$ and $x_2$. 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$ | Step | Calculation |
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$ | `1` | $m_s = y_1 \oplus y_2$
4. $T = x\_1 \oplus h(t'\_s)$ | `2` | $t\_c = \mid \frac{t\_{now}}{W} \mid $, $m\_c = t\_c \mathbb{Z}\_{(2)}$
5. Find $N \in [min ; n-min[,\ h^{N}(K) = T$. | `3` | $t'\_s = t\_c - \parallel m\_c - m\_s\parallel$
6. $x\_1 = h^N(K) \oplus h(t\_c)$ | `4` | $T = x\_1 \oplus h(t'\_s)$
7. Generate $(K',n',s')$ in a way where the following conditions are met : | `5` | Find $N \in [min ; n-min[,\ h^{N}(K) = T$.
- $[(h^N(K) \oplus h^{n'}(K')) \And 1] \ \mathbb{Z}\_{(2)} = t\_c \ \mathbb{Z}\_{(2)} $ | `6` | $x\_1 = h^N(K) \oplus h(t\_c)$
- $[(h^N(K) \oplus h^{n'}(K')) \And 11110000] \ \mathbb{Z}\_{(3)} = 2$ | `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)$ | `8` | $x\_2 = h^{n'}(K') \oplus h(t\_c)$ |
Send $x_1$ and $x_2$. Send $x_1$ and $x_2$.