simplified protocol
This commit is contained in:
parent
8519769b37
commit
f567b75f4e
100
PROTOCOL.md
100
PROTOCOL.md
|
@ -40,8 +40,11 @@ A better solution would be to generate a private key on each client and use it t
|
||||||
|
|
||||||
This document will define and bundle 2 distinct protocols to make up a token system that implements the previous statements.
|
This document will define and bundle 2 distinct protocols to make up a token system that implements the previous statements.
|
||||||
|
|
||||||
1. a <u>Stateless Time Scrambling Protocol</u> to take care of the request's expiration 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 generate several public tokens from a private key 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.
|
||||||
|
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
|
## General knowledge & Notations
|
||||||
|
|
||||||
|
@ -52,23 +55,17 @@ This document will define and bundle 2 distinct protocols to make up a token sys
|
||||||
| $\parallel a\parallel $ | The absolute value of $a$ ; *e.g.* $\parallel -12 \parallel = 12$ |
|
| $\parallel a\parallel $ | The absolute value of $a$ ; *e.g.* $\parallel -12 \parallel = 12$ |
|
||||||
| $\mid a \mid$ | The integer value of $a$ ; *e.g.* $\mid 12.34 \mid = 12$ |
|
| $\mid a \mid$ | The integer value of $a$ ; *e.g.* $\mid 12.34 \mid = 12$ |
|
||||||
| $a \oplus b$ | The bitwise operation XOR between binary words $a$ and $b$ |
|
| $a \oplus b$ | The bitwise operation XOR between binary words $a$ and $b$ |
|
||||||
|
| $a \And b$ | The bitwise operation AND between binary words $a$ and $b$ |
|
||||||
| $h(m)$ | The digest of the message $m$ by a (consistent) secure cryptographic hash function $h()$ ; *e.g. sha512* |
|
| $h(m)$ | The digest of the message $m$ by a (consistent) secure cryptographic hash function $h()$ ; *e.g. sha512* |
|
||||||
| $h^n(m)$ | The digest of the $n$-recursive hash function $h()$ with the input data $m$ ; <br>$h^2(m) \equiv h(h(m))$, $h^1(m) \equiv h(m)$, and $h^0(m) \equiv m$. |
|
| $h^n(m)$ | The digest of the $n$-recursive hash function $h()$ with the input data $m$ ; <br>$h^2(m) \equiv h(h(m))$, $h^1(m) \equiv h(m)$, and $h^0(m) \equiv m$. |
|
||||||
| $a \mod b$ | The result of $a$ modulo $b$ ; *i.e.* the remainder of the Euclidean division of $a$ by $b$ |
|
| $a \ \mathbb{Z}_{(b)}$ | The result of $a$ modulo $b$ ; *i.e.* the remainder of the Euclidean division of $a$ by $b$ |
|
||||||
| $t_{now}$ | The current *Unix Timestamp* in seconds |
|
| $t_{now}$ | The current *Unix Timestamp* in seconds |
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
##### Entities
|
|
||||||
|
|
||||||
- A client $C$ (*typically a client*)
|
|
||||||
- A server $S$ (*typically a server*)
|
|
||||||
|
|
||||||
## Variables
|
## Variables
|
||||||
|
|
||||||
The whole system share a common **context**, each client holds a **private keyset**, and the server stores the **last valid token** of each client.
|
The whole system share a common **context**, each client holds a **private keyset**, and the server stores the **last valid token** of each client.
|
||||||
|
|
||||||
##### Common context
|
#### 1. Common context
|
||||||
|
|
||||||
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)$.
|
||||||
|
|
||||||
|
@ -79,7 +76,7 @@ These variables are both on the server and clients. They are specific to the ser
|
||||||
| $sec$ | security range | A number that is used to resynchronize the client if there is a communication shift (*e.g. lost request, lost response, attack*). It corresponds of the number of desynchronizations the client can handle before never being able to gain the authentication again. |
|
| $sec$ | security range | A number that is used to resynchronize the client if there is a communication shift (*e.g. lost request, lost response, attack*). It corresponds of the number of desynchronizations the client can handle before never being able to gain the authentication again. |
|
||||||
| $max$ | maximum nonce | A number that is used to cap the value of client's nonces. A too high value will result on keys that will never be replaced, thus making them open to long-processing attacks (*e.g. brute-force*). |
|
| $max$ | maximum nonce | A number that is used to cap the value of client's nonces. A too high value will result on keys that will never be replaced, thus making them open to long-processing attacks (*e.g. brute-force*). |
|
||||||
|
|
||||||
##### 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 as a **one-way function** to generate all the tokens from the keyset.
|
||||||
|
|
||||||
|
@ -87,19 +84,72 @@ Every client holds a **keyset** $(K, n, s)$. It represents its private key and i
|
||||||
|:--------:|:----:|:------------|
|
|:--------:|:----:|:------------|
|
||||||
| $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 before each request. 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 use the new key<br>- $2$ : resynchronization processed, waiting for the server's acknoledgement |
|
| $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 |
|
||||||
|
|
||||||
The token generation algorithm is :
|
#### 3. Server variables
|
||||||
1. Decrement $n$
|
|
||||||
2. Process token $= h^n(K)$
|
|
||||||
|
|
||||||
##### Server variables
|
|
||||||
|
|
||||||
| Notation | Name | Description |
|
| Notation | 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. |
|
||||||
|
|
||||||
If a client sends its token $h^n(K)$ ; if valid the server stores it inside $T$. Note that for the system's **initialisation**, the server has to be given $T = h^{n-1}(K)$.
|
|
||||||
|
## Protocol
|
||||||
|
|
||||||
|
#### 1. Client authentication
|
||||||
|
|
||||||
|
In each request, the client will send a pair of tokens $(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
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
- $(K,n,s)$ - the current keyset
|
||||||
|
- $(K',n',s')$ - the new keyset
|
||||||
|
|
||||||
|
##### 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)})$
|
||||||
|
|
||||||
|
Send $x_1$ and $x_2$.
|
||||||
|
|
||||||
|
If $i \leq min+sec$, go to `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)$
|
||||||
|
|
||||||
|
Send $x_1$ and $x_2$.
|
||||||
|
|
||||||
|
#### c. `rescue` protocol
|
||||||
|
|
||||||
|
The rescue protocol is processed when receiving $y_1$ and $y_2$ from the server instead of the standard response.
|
||||||
|
|
||||||
|
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)$
|
||||||
|
|
||||||
|
Send $x_1$ and $x_2$.
|
||||||
|
|
||||||
|
|
||||||
|
## blablabla
|
||||||
|
|
||||||
##### Check a token
|
##### Check a token
|
||||||
|
|
||||||
|
@ -135,7 +185,7 @@ The receiver has to guess $t_s$ with the following steps:
|
||||||
|
|
||||||
As a result, the receiver will only be able to retrieve the sender's time id if the reception time is at most $W$ seconds after the sending time :
|
As a result, the receiver will only be able to retrieve the sender's time id if the reception time is at most $W$ seconds after the sending time :
|
||||||
|
|
||||||
$$t\_{now}^r \leq t\_{now}^s + W \implies t\_s = t'_s2$$
|
$$t\_{now}^r \in [t\_{now}^s ; t\_{now}^s + W] \Longrightarrow t\_s = t'_s2$$
|
||||||
|
|
||||||
In practice, the time id is **hashed** and used to achieve a [one-time pad](https://en.wikipedia.org/wiki/One-time_pad) with the token. Because they both result from the same hash function their sizes are the same.
|
In practice, the time id is **hashed** and used to achieve a [one-time pad](https://en.wikipedia.org/wiki/One-time_pad) with the token. Because they both result from the same hash function their sizes are the same.
|
||||||
|
|
||||||
|
@ -145,11 +195,11 @@ As a result from the sent token $x_1 = token \oplus h(t_s)$, it is impossible to
|
||||||
* The time id corresponds to the index of the time slice where slices are $W$ seconds wide. By dividing the time in slices of $W$ seconds, if we process the same calculation at an interval of $W$ or less seconds, we will have either the same result or a result greater by 1.
|
* The time id corresponds to the index of the time slice where slices are $W$ seconds wide. By dividing the time in slices of $W$ seconds, if we process the same calculation at an interval of $W$ or less seconds, we will have either the same result or a result greater by 1.
|
||||||
* The time id parity $m_s$ allows us to adjust the receiver's time id $t_r$ when it receives the request. This difference of 1 second is caused by the division of time in slices, the precision is also divided by $W$.
|
* The time id parity $m_s$ allows us to adjust the receiver's time id $t_r$ when it receives the request. This difference of 1 second is caused by the division of time in slices, the precision is also divided by $W$.
|
||||||
|
|
||||||
- $ t_{now}\mod W = 0 \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid $; no need for adjustment
|
- $t\_{now}\mod W = 0 \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now+(W-1)}}{W} \mid $; no need for adjustment
|
||||||
- $ t_{now}\mod W = 1 \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$
|
- $t\_{now}\mod W = 1 \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now+(W-1)}}{W} \mid + 1 $; need to subtract $1$
|
||||||
- $ t_{now}\mod W = 2 \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$
|
- $t\_{now}\mod W = 2 \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now+(W-1)}}{W} \mid + 1 $; need to subtract $1$
|
||||||
- $...$
|
- $...$
|
||||||
- $ t_{now}\mod W = (W-1) \implies \mid \frac{t_{now}}{W} \mid = \mid \frac{t_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$
|
- $t\_{now}\mod W = (W-1) \Longrightarrow \mid \frac{t\_{now}}{W} \mid = \mid \frac{t\_{now}+(W-1)}{W} \mid + 1 $; need to subtract $1$
|
||||||
|
|
||||||
## Protocol properties
|
## Protocol properties
|
||||||
|
|
||||||
|
@ -243,7 +293,7 @@ The server receives $(x_1, x_2)$. It does have to :
|
||||||
| `s5` | Calculate the time hash $h_{t'_c}$ | $h_{t'_c} = h(t'_c)$ |
|
| `s5` | Calculate the time hash $h_{t'_c}$ | $h_{t'_c} = h(t'_c)$ |
|
||||||
| `s6` | Extract the token $T'_c$ | $T'\_c = x_1 \oplus h\_{t'\_c}$ |
|
| `s6` | Extract the token $T'_c$ | $T'\_c = x_1 \oplus h\_{t'\_c}$ |
|
||||||
| `s7` | Extract the next token $T_{next}$ | $T\_{next} = x\_2 \oplus m\_c \oplus h\_{t'\_c}$ |
|
| `s7` | Extract the next token $T_{next}$ | $T\_{next} = x\_2 \oplus m\_c \oplus h\_{t'\_c}$ |
|
||||||
| `s8` | Check the token | $h(T'\_c) = T \implies T = T_{next}$ |
|
| `s8` | Check the token | $h(T'\_c) = T \Longrightarrow T = T_{next}$ |
|
||||||
|
|
||||||
If the token is valid on step `s8`, the next validation token $T_{next}$ is stored and the request can be processed by the server. If the token mismatches, the recovery mode is enabled.
|
If the token is valid on step `s8`, the next validation token $T_{next}$ is stored and the request can be processed by the server. If the token mismatches, the recovery mode is enabled.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue